关于netty:netty系列之自建客户端和HTTP服务器交互

31次阅读

共计 4471 个字符,预计需要花费 12 分钟才能阅读完成。

简介

上一篇文章,咱们搭建了一个反对中文的 HTTP 服务器,并且可能从浏览器拜访,并获取到相应的后果。尽管浏览器在日常的利用中很广泛,然而有时候咱们也有可能从自建的客户端来调用 HTTP 服务器的服务。

明天给大家介绍如何自建一个 HTTP 客户端来和 HTTP 服务器进行交互。

应用客户端构建申请

在上一篇文章中,咱们应用浏览器来拜访服务器,并失去到了响应的后果,那么如何在客户端构建申请呢?

netty 中的 HTTP 申请能够分成两个局部,别离是 HttpRequest 和 HttpContent。其中 HttpRequest 只蕴含了申请的版本号和音讯头的信息,HttpContent 才蕴含了真正的申请内容信息。

然而如果要构建一个申请的话,须要同时蕴含 HttpRequest 和 HttpContent 的信息。netty 提供了一个申请类叫做 DefaultFullHttpRequest,这个类同时蕴含了两局部的信息,能够间接应用。

应用 DefaultFullHttpRequest 的构造函数,咱们就能够结构出一个 HttpRequest 申请如下:

HttpRequest request = new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, uri.getRawPath(), Unpooled.EMPTY_BUFFER);

下面的代码中,咱们应用的协定是 HTTP1.1,办法是 GET,申请的 content 是一个空的 buffer。

构建好根本的 request 信息之后,咱们可能还须要在 header 中增加一下额定的信息,比方 connection,accept-encoding 还有 cookie 的信息。

比方设置上面的信息:

request.headers().set(HttpHeaderNames.HOST, host);
            request.headers().set(HttpHeaderNames.CONNECTION, HttpHeaderValues.CLOSE);
            request.headers().set(HttpHeaderNames.ACCEPT_ENCODING, HttpHeaderValues.GZIP);

还有设置 cookie:

request.headers().set(
                    HttpHeaderNames.COOKIE,
                    ClientCookieEncoder.STRICT.encode(new DefaultCookie("name", "flydean"),
                            new DefaultCookie("site", "www.flydean.com")));

设置 cookie 咱们应用的是 ClientCookieEncoder.encode 办法,ClientCookieEncoder 有两种 encoder 模式,一种是 STRICT,一种是 LAX。

在 STRICT 模式下,会对 cookie 的 name 和 value 进行校验和排序。

和 encoder 对应的就是 ClientCookieDecoder,用于对 cookie 进行解析。

设置好咱们所有的 request 之后就能够写入到 channel 中了。

accept-encoding

在客户端写入申请的时候,咱们在申请头上增加了 accept-encoding,并将其值设置为 GZIP,示意客户端接管的编码方式是 GZIP。

如果服务器端发送了 GZIP 的编码内容之后,客户端怎么进行解析呢?咱们须要对 GZIP 的编码格局进行解码。

netty 提供了 HttpContentDecompressor 类,能够对 gzip 或者 deflate 格局的编码进行解码。在解码之后,会同时批改响应头中的“Content-Encoding”和“Content-Length”。

咱们只须要将其增加到 pipline 中即可。

和它对应的类是 HttpContentCompressor,用于对 HttpMessage 和 HttpContent 进行 gzip 或者 deflate 编码。

所以说 HttpContentDecompressor 应该被增加到 client 的 pipline 中,而 HttpContentCompressor 应该被增加到 server 端的 pipline 中。

server 解析 HTTP 申请

server 须要一个 handler 来解析客户端申请过去的音讯。对于服务器来说,解析客户端的申请应该留神哪些问题呢?

首先要留神的是客户端 100 Continue 申请的问题。

在 HTTP 中有一个独特的性能叫做,100 (Continue) Status,就是说 client 在不确定 server 端是否会接管申请的时候,能够先发送一个申请头,并在这个头上加一个 ”100-continue” 字段,然而临时还不发送申请 body。直到接管到服务器端的响应之后再发送申请 body。

如果服务器收到 100Continue 申请的话,间接返回确认即可:

if (HttpUtil.is100ContinueExpected(request)) {send100Continue(ctx);
            }

    private static void send100Continue(ChannelHandlerContext ctx) {FullHttpResponse response = new DefaultFullHttpResponse(HTTP_1_1, CONTINUE, Unpooled.EMPTY_BUFFER);
        ctx.write(response);
    }

如果不是 100 申请的话,server 端就能够筹备要返回的内容了:

这里用一个 StringBuilder 来存储要返回的内容:

StringBuilder buf = new StringBuilder();

为什么要用 StringBuf 呢?是因为有可能 server 端一次并不能齐全承受客户端的申请,所以将所有的要返回的内容都放到 buffer 中,等全副承受之后再一起返回。

咱们能够向 server 端增加欢送信息,能够能够增加从客户端获取的各种信息:

buf.setLength(0);
            buf.append("欢送来到 www.flydean.com\r\n");
            buf.append("===================================\r\n");

            buf.append("VERSION:").append(request.protocolVersion()).append("\r\n");
            buf.append("HOSTNAME:").append(request.headers().get(HttpHeaderNames.HOST, "unknown")).append("\r\n");
            buf.append("REQUEST_URI:").append(request.uri()).append("\r\n\r\n");

还能够向 buffer 中增加申请头信息:

HttpHeaders headers = request.headers();
            if (!headers.isEmpty()) {for (Entry<String, String> h: headers) {CharSequence key = h.getKey();
                    CharSequence value = h.getValue();
                    buf.append("HEADER:").append(key).append("=").append(value).append("\r\n");
                }
                buf.append("\r\n");
            }

能够向 buffer 中增加申请参数信息:

            QueryStringDecoder queryStringDecoder = new QueryStringDecoder(request.uri());
            Map<String, List<String>> params = queryStringDecoder.parameters();
            if (!params.isEmpty()) {for (Entry<String, List<String>> p: params.entrySet()) {String key = p.getKey();
                    List<String> vals = p.getValue();
                    for (String val : vals) {buf.append("PARAM:").append(key).append("=").append(val).append("\r\n");
                    }
                }
                buf.append("\r\n");
            }

要留神的是当读取到 HttpContent 的时候的解决形式。如果读取的音讯是 HttpContent,那么将 content 的内容增加到 buffer 中:

if (msg instanceof HttpContent) {HttpContent httpContent = (HttpContent) msg;

            ByteBuf content = httpContent.content();
            if (content.isReadable()) {buf.append("CONTENT:");
                buf.append(content.toString(CharsetUtil.UTF_8));
                buf.append("\r\n");
                appendDecoderResult(buf, request);
            }

那么怎么判断一个申请是否完结了呢?netty 提供了一个类叫做 LastHttpContent,这个类示意的是音讯的最初一部分,当收到这一部分音讯之后,咱们就能够判断一个 HTTP 申请曾经实现了,能够正式的返回音讯了:

if (msg instanceof LastHttpContent) {log.info("LastHttpContent:{}",msg);
                buf.append("END OF CONTENT\r\n");

要写回 channel,同样须要构建一个 DefaultFullHttpResponse,这里应用 buffer 来进行构建:

FullHttpResponse response = new DefaultFullHttpResponse(HTTP_1_1, currentObj.decoderResult().isSuccess()? OK : BAD_REQUEST,
                Unpooled.copiedBuffer(buf.toString(), CharsetUtil.UTF_8));

而后增加一些必须的 header 信息就能够调用 ctx.write 进行回写了。

总结

本文介绍了如何在 client 构建 HTTP 申请,并具体解说了 HTTP server 对 HTTP 申请的解析流程。

本文的例子能够参考:learn-netty4

本文已收录于 http://www.flydean.com/19-netty-http-client-request-2/

最艰深的解读,最粗浅的干货,最简洁的教程,泛滥你不晓得的小技巧等你来发现!

欢送关注我的公众号:「程序那些事」, 懂技术,更懂你!

正文完
 0