Http实战之Wireshark抓包分析

❝Http相关的文章网上一搜一大把，所以笔者这一系列的文章不会只陈述一些概念，更多的是通过实战（抓包+代码实现）的方式来跟大家讨论Http协议中的各种细节，帮助大家理解那些反反复复记不住的的概念！ ❞

搭建测试项目

我们选用netty搭建一个服务端，使用httpclient来实现http客户端。

❝对netty或者httpclient不熟悉的同学不用担心，涉及到的代码都非常简单。 服务端我之所以选用这两个框架是因为相对来说，它们对http协议的封装较浅，在后面的文章中我可以带大家看看代码层次上http协议是如何封装的，这样可以将http协议理解的更加透彻，在本文中大家将注意力放到抓包的分析过程即可！ ❞

代码如下：

pom文件引入依赖：

<dependency>
  <groupId>io.netty</groupId>
  <artifactId>netty-all</artifactId>
  <version>4.1.65.Final</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient -->
<dependency>
  <groupId>org.apache.httpcomponents</groupId>
  <artifactId>httpclient</artifactId>
  <version>4.5.13</version>
</dependency>

服务端代码：

public class HttpServer {
  public static void main(String[] args) throws Exception {
    EventLoopGroup bossGroup = new NioEventLoopGroup(1);
    EventLoopGroup workerGroup = new NioEventLoopGroup();
    try {
      ServerBootstrap b = new ServerBootstrap();
      b.option(ChannelOption.SO_BACKLOG, 1024);
      b.group(bossGroup, workerGroup)
        .channel(NioServerSocketChannel.class)
        .handler(new LoggingHandler(LogLevel.INFO))
        .childHandler(new HttpHelloWorldServerInitializer());
      Channel ch = b.bind(8080).sync().channel();
      ch.closeFuture().sync();
    } finally {
      bossGroup.shutdownGracefully();
      workerGroup.shutdownGracefully();
    }
  }
}


public class HttpHelloWorldServerInitializer extends ChannelInitializer<SocketChannel> {
  @Override
  public void initChannel(SocketChannel ch) {
    ChannelPipeline p = ch.pipeline();
    // 我们搭建的是一个http服务器，要使用http编解码器
    p.addLast(new HttpServerCodec());
    // http请求处理核心类
    p.addLast(new HttpHelloWorldServerHandler());

  }
}

/**
 * 这个类是处理http请求的核心类，这里我们简单处理
 * 不论收到什么信息我们都返回Hello World
 */
public class HttpHelloWorldServerHandler extends SimpleChannelInboundHandler<HttpObject> {
  private static final byte[] CONTENT = { 'H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd' };

  @Override
  public void channelReadComplete(ChannelHandlerContext ctx) {
    ctx.flush();
  }

  @Override
  public void channelRead0(ChannelHandlerContext ctx, HttpObject msg) {
    if (msg instanceof HttpRequest) {
      HttpRequest req = (HttpRequest) msg;
      FullHttpResponse response = new DefaultFullHttpResponse(req.protocolVersion(), OK,Unpooled.wrappedBuffer(CONTENT));
      response.headers()
        .set(CONTENT_TYPE, TEXT_PLAIN)
        .setInt(CONTENT_LENGTH, response.content().readableBytes());
      ctx.write(response);
    }
  }

  @Override
  public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
    cause.printStackTrace();
    ctx.close();
  }
}

客户端代码如下：

public class HttpClient {
    public static void main(String[] args) throws Exception {
        final CloseableHttpClient httpClient =
                HttpClientBuilder.create()
                        .setConnectionManager(new BasicHttpClientConnectionManager())
                        .build();
        final HttpGet httpGet = new HttpGet("http://127.0.0.1:8080");
        final CloseableHttpResponse execute = httpClient.execute(httpGet);
        System.out.println(EntityUtils.toString(execute.getEntity()));
        // 这里代码并不规范哈,正常应该try catch finally,不过这不是本文重点
        execute.close();
    }
}

我们将服务端启动后，运行客户端正常输出“Hello World”说明项目搭建成功

Wireshark简单介绍

Wireshark（前身 Ethereal）是一个网络包分析工具。该工具主要是用来捕获网络数据包，并自动解析数据包，为用户显示数据包的详细信息，供用户对数据包进行分析。

❝下载链接：https://www.wireshark.org/download.html ❞

下载成功后，我们打开主界面如下：

WireShark

这里我们看到的这个列表是我们本机的网卡列表，我们在抓包之前要确认具体的网卡，常用的网卡就是我在图中框选的两个

• lo0：回环网卡，对应localhost/127.0.0.1等本地服务 举个例子，如果我要请求 http://localhost:12345/xxx 这个服务，对应的网卡就选择lo0。127.0.0.1的服务同理。
• en0：外网请求，比如，我要在浏览器访问 www.baidu.com/ 这个服务，对应的网卡一般选en0。

那么如何确定我们要抓取的数据包对应的网卡是哪个呢？

现在要确定当我们访问www.baidu.com使用的是哪个网卡，我们可以执行如下操作：

1. 监听www.baidu.com数据：sudo tcpdump host www.baidu.com -xnt -v -A | grep -C3 www.baidu.com
2. 访问百度：curl www.baidu.com。

从这里可以看到我们访问百度时使用的ip地址（图中马塞克部分）

之后，通过执行ifconfig命令，就能查询到这个ip对应的网卡

在我本机对应的就是en0这张网卡。确认了具体网卡后，我们在主界面选定此网卡，双击即可，此时可能会出现如下报错：

这是因为网卡权限问题，我们只需要在终端中输入如下命令即可：sudo chmod 777 /dev/bpf*。执行完后记得要重启WireShark。

重启完成后，选定网卡双击会进入如下界面：

一进这个界面可能会有点懵，因为我们没有输入任何过滤表达式，所以此时整个界面上展示的是en0这个网卡上所有的数据包。关于WireShark的表达式不是本文重点，笔者也不打算过多介绍，本文用到的表达式都非常简单，每个表达式我会做简单解释。

此时我们想要抓取访问百度时的数据包，我们只需要输入如下表达式：

http and ip.addr==112.80.248.76

表达式中的第一个http代表，我们要抓取的是http协议相关的数据包，同理，你可以输入tcp,icmp等协议名称过滤出对应协议相关的数据包。这个表达式的意思是，我要抓取http协议的数据包，同时通信的某一方的ip地址为112.80.248.76，这个ip地址可以通过ping www.baidu.com得到。

根据上述表达式我们可以抓到如下数据包：

我们选中对应的报文，右键跟踪http流，即可得到具体的http报文信息

那么接下来我们正式开始抓包实验，确保你的测试项目及Wireshark都是ok的哦～

Http抓包分析

1. wireShark要抓取的网卡是回环网卡（测试项目中客户端发起请求的URL是127.0.0.1:8080）
2. 我们server在搭建时绑定的端口是8080，所以wireShark可以配置如下表达式： http and tcp.port==8080，代表我们要抓取8080端口上所有http协议的包（因为是抓取回环网卡网卡上的数据包，所以我们可以不指定IP）

接下来我们启动sever端，然后运行client端发起一个http请求，在WireShark上可以抓取到如下数据：

按照前文所述，我们追踪下这个http流可以看到如下数据：

协议格式

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

「起始行」（start line）：描述请求或响应的基本信息，在请求中我们称之为请求行，响应中我们称之为状态行；

「头部字段集合」（header）：使用 key-value 形式更详细地说明报文，在请求中我们称之为请求头，响应中我们称之为响应头。

「消息正文」（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据，也称之为请求体或响应体

HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。

将抓包得到的报文用上述结构描述即如下图所示：

请求行

如下图所示，请求行中主要包含三部分信息

1. 请求方法
2. 请求URI
3. 本次发起http请求时使用的http协议版本

三部分之间使用空格进行分隔

常见的请求方法

❝RESTful架构下，会使用四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：「GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。」 ❞

Get跟Post常见误区

1. 请求参数长度限制：GET请求长度最多1024kb，POST对请求数据没有限制 答：GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。
2. GET请求一定不能用request body传输数据 答：RFC 规范并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。只是因为 RFC 规范定义的 GET 请求是获取资源，所以根据这个语义不需要用到 body。另外，URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。我们在传统的Spring环境下会发现下面两种写法都可以正常工作

状态行

如下图所示，请求行中主要包含三部分信息

1. 使用的http协议版本
2. 数字状态码
3. 作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

三部分之间使用空格进行分隔

状态码

RFC 标准把状态码分成了五类，用数字的第一位表示分类，这样状态码的实际可用范围就大大缩小了，由 000~999 变成了 100~599。

这五类的具体含义是：

1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；

2××：成功，报文已经收到并被正确处理；

3××：重定向，资源位置发生变动，需要客户端重新发送请求；

4××：客户端错误，请求报文有误，服务器无法处理；

5××：服务器错误，服务器在处理请求时内部发生了错误。

❝实际上需要注意的是HTTP本身是一个协议，需要通信的双方共同遵守，但这并不是必须的。目前 RFC 标准里总共有 41 个状态码，但状态码的定义是开放的，允许自行扩展。所以 Apache、Nginx 等 Web 服务器都定义了一些专有的状态码。如果你自己开发 Web 应用，也完全可以在不冲突的前提下定义新的状态码。 ❞

1xx

1xx 类状态码属于「提示信息」，是协议处理中的一种中间状态。例如在需要进行协议升级时，服务器会响应101。如下图所示，使用websocket时，会进行一次协议升级：

2xx

2xx 类状态码表示服务器「成功」处理了客户端的请求，也是我们最愿意看到的状态。

• 「「200 OK」」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
• 「「204 No Content」」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 「「206 Partial Content」」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。状态码 「206」 通常还会伴随着头字段“Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-99/2000”，意思是此次获取的是总计 2000 个字节的前 100 个字节，这其实也就是http协议的「分段请求」功能，这部分内容我们之后会详细介绍！

3xx

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是「重定向」。

• 「「301 Moved Permanently」」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
• 「「302 Found」」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

• 「「304 Not Modified」」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx

4××类状态码表示客户端发送的请求报文有误，服务器无法处理，它就是真正的“错误码”含义了。

「「400 Bad Request」」是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是 URI 超长它没有明确说，只是一个笼统的错误，客户端看到 400 只会是“一头雾水”“不知所措”。所以，在开发 Web 应用时应当尽量避免给客户端返回 400，而是要用其他更有明确含义的状态码。

「「403 Forbidden」」实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等，如果服务器友好一点，可以在 body 里详细说明拒绝请求的原因，不过现实中通常都是直接给一个“闭门羹”。

「「404 Not Found」」可能是我们最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到，所以无法提供给客户端。但现在已经被“用滥了”，只要服务器“不高兴”就可以给出个 404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因，某种程度上它比 403 还要令人讨厌。

4××里剩下的一些代码较明确地说明了错误的原因，都很好理解，开发中常用的有：

• 405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许 POST 只能 GET；
• 406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文；
• 408 Request Timeout：请求超时，服务器等待了过长的时间；
• 409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态；
• 413 Request Entity Too Large：请求报文里的 body 太大；
• 414 Request-URI Too Long：请求行里的 URI 太大；
• 429 Too Many Requests：客户端发送了太多的请求，通常是由于服务器的限连策略；
• 431 Request Header Fields Too Large：请求头某个字段或总体太大；

5xx

5xx 类状态码表示客户端请求报文正确，但是「服务器处理时内部发生了错误」，属于服务器端的错误码。

• 「「500 Internal Server Error」」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
• 「「501 Not Implemented」」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
• 「「502 Bad Gateway」」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
• 「「503 Service Unavailable」」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

Header

ttp header 消息通常被分为4个部分：general header, request header, response header, entity header。但是这种分法就理解而言，感觉界限不太明确。根据维基百科对http header内容的组织形式，大体分为Request（请求头）和Response（响应头）两部分。

Requests部分

Responses 部分

总结

通过这篇文章我们搭建了测试项目，对wireShark有了一定了解，也知道了http协议的整体结构。仅仅是这样我们很难对http有一个直观深入的了解，所以下篇文章我会跟大家一起探讨目前的主流框架是如何实现http协议的，例如：http的长连接在代码层次是怎么实现？服务器跟客户端做了什么去实现长连接呢？

下篇文章将从代码实现的角度来分析http协议，跟着我卷起来～

参考：

1. 《图解Http》
2. https://xiaolincoding.com/network/2_http/http_interview.html
3. https://www.zhihu.com/column/c_1397958370813493248
4. https://kb.cnblogs.com/page/92320/