01 HTTP请求报文协议（Request）

1）Request简述

HTTP协议请求报文是以字符文本的格式传输，具体包含以下四大部分：

• 请求行（首行）：[方法]+[url]+[版本号]，分别使用空格分隔；

• 请求头（Header）：请求的属性，每个键值对独占一行，冒号+空格来分割键和值；

• 空行：遇到空行表示Header部分结束；

• 正文（Body）：空行后面的内容都是Body，Body允许为空字符串。

• 示例
  字符串展示形式：

POST /dologin.action HTTP/1.1
Host: wiki.tope365.com
Content-Length: 86
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://wiki.tope365.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.112 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://wiki.tope365.com/login.action?logout=true
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: JSESSIONID=B59940DF4F57CFB4D23D9AC8C7DF0C98
Connection: closeos_username=yewenhai&os_password=Lovenier7777&login=%E7%99%BB%E5%BD%95&os_destination=

16进制展示形式：

2）请求行（首行）

首行包括：HTTP方法+URL+版本号

• HTTP方法
  根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
  

• URL
  

拆解上述图中的URL，格式分段详解：

1. 协议名：表示使用的协议类型，常见的有http和https，也有其他的类型。(例如访问
   mysql时用的jdbc:mysql)可以省略，省略后默认为http://；

2. 登陆信息：现在的网站进行身份认证一般不再通过URL进行了，一般都会省略。

3. 服务器地址（ip地址/域名）：此处是一个“域名”，域名会通过DNS系统解析成一个具体的IP地址。在HTML中可以省略(比如img，link，script，a标签的src或者href属性)，省略后表示服务器的ip/域名与当前HTML所属的ip/域名一致；

4. 端口号：当端口号省略的时候，浏览器会根据协议类型自动决定使用哪个端口。例如http协议默认使用80端口，https协议默认使用443端口。

5. 带层次的文件路径：表示需要访问的资源在服务器中的层次。可以省略，省略后相当于/.有些服务器会在发现/路径的时候自动访问/index.html；

6. 查询字符串(query string)：本质是一个键值对结构，键值对之间使用&分隔，键和值之间使用=分隔。可以省略；

7. 片段标识：片段标识主要用于页面内跳转。可以省略；

• 版本号
  表示HTTP的协议版本，如：HTTP/1.0、HTTP/1.1、HTTP/2.0

3）请求头（Request Headers）

• Host
  表示服务器主机的地址和端口（这个信息在URL中也存在的）。

• Content-Length
  表示Body中的数据长度（请求报文里有Body，才有该属性存在）。

• Content-Type
  表示请求的Body中的数据格式（请求报文里有Body，才有该属性存在）。
  HTTP协议的请求格式一般有：json格式、form表单、form-data格式。
  后续给服务器提交给请求，不同的Content-Type，服务器处理数据的逻辑是不同的。

服务器返回数据给浏览器，也需要设置合适的Content-Type，浏览器也会根据不同的Content-Type 做出不同的处理。

• Upgrade-Insecure-Requests
  这个请求头指示客户端（通常是浏览器），要求服务器使用 HTTPS 加载资源，并在加载过程中升级所有不安全的请求。这有助于提高网站的安全性，防止未加密的内容被加载。

• Origin
  这个请求头包含了当前文档或脚本的来源信息，通常用于跨域资源共享（CORS）。它告诉服务器请求的源自哪里，以帮助服务器决定是否允许该请求。

• X-Forwarded-For
  通过名字就知道，X-Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。

X-Forwarded-For 请求头格式非常简单，就这样：

X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。

如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，那么按照 XFF 标准，服务端最终会收到以下信息：

X-Forwarded-For: IP0, IP1, IP2
Proxy3 直连服务器，它会给 XFF 追加 IP2，表示它是在帮 Proxy2 转发请求。列表中并没有 IP3，IP3 可以在服务端通过 Remote Address 字段获得。我们知道 HTTP 连接基于 TCP 连接，HTTP 协议中没有 IP 的概念，Remote Address 来自 TCP 连接，表示与服务端建立 TCP 连接的设备 IP，在这个例子里就是 IP3。

Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。不同语言获取 Remote Address 的方式不一样，例如 php 是 $_SERVER[“REMOTE_ADDR”]，Node.js 是 req.connection.remoteAddress，但原理都一样。

• User-Agent
  User-Agent简称UA，表示浏览器/操作系统的属性，现在主要用来区分PC端还是移动端设备。
  UA表述了主机操作系统版本和浏览器的版本，通俗点说，UA表示你用什么设备上网。

• Accept
  告诉 WEB 服务器自己接受什么介质类型，/ 表示任何类型，type/* 表示该类型下的所有子类型，type/sub-type。

• Accept-Charset
  浏览器申明自己接收的字符集。

• Referer
  表示这个页面是从哪个页面跳转过来的。
  如果直接在浏览器中输入URL，或者直接通过收藏夹访问页面时是没有Referer属性的。

• Accept-Encoding
  这个请求头告诉服务器客户端支持的压缩算法，以便服务器在返回响应时可以选择适当的压缩方式。通过使用压缩算法，可以减少传输过程中的数据量，提高网站性能和加载速度。

• Accept-Language
  这个请求头用于指示服务器用户代理（通常是浏览器）接受的首选自然语言。服务器可以使用这个信息来返回特定语言版本的内容，以提供更好的用户体验。

• Cookie
  Cookie中存储了一个字符串，往往是从服务器返回的数据(也可以是页面自己生成的)。Cookie是按照键值对的形式来组织的，这里的键值对也都是程序猿自定义的(和query string差不多)。

• Authorization
  当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时，用该头部来回应自己的身份验证信息给 WEB 服务器。

• Range

表示头500个字节：bytes=0-499
表示第二个500字节：bytes=500-999
表示最后500个字节：bytes=-500
表示500字节以后的范围：bytes=500-
第一个和最后一个字节：bytes=0-0,-1
同时指定几个范围：bytes=500-600,601-999

但是服务器可以忽略此请求头，如果无条件 GET 包含 Range 请求头，响应会以状态码 206（PartialContent）返回而不是以 200 （OK）

• 通用头域
  通用头域包含请求和响应消息都支持的头域，通用头域包含 Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在 UPnP 消息中使用的通用头域。

• Cache-Control头域
  Cache -Control 指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control 并不会修改另一个消息处理过程中的缓存处理过程。

请求时的缓存指令包括：

no-cache、
no-store、
max-age、
max-stale、
min-fresh、
only-if-cached

响应消息中的指令包括：

Public 指示响应可被任何缓存区缓存；
Private 指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效；
no-cache 指示请求或响应消息不能缓存；
no-store 用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存；
max-age 指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应；
min-fresh 指示客户机可以接收响应时间小于当前时间加上指定时间的响应；
max-stale 指示客户机可以接收超出超时期间的响应消息。如果指定 max-stale 消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

• Pragma 头域
  Pragma 头域用来包含实现特定的指令，最常用的是 Pragma:no-cache。在 HTTP/1.1 协议中，它的含义和 Cache-Control:no-cache 相同。

• Connection头域
  Connection 表示连接状态
  请求

close（告诉 WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不要等待本次连接的后续请求了）。
keepalive（告诉 WEB 服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求）。

响应

close（连接已经关闭）。
Keep-Alive：如果浏览器请求保持连接，则该头部表明希望 WEB 服务器保持连接多长时间（秒）。例如：Keep-Alive：300

• Date 头域
  date 头域表示消息发送的时间，时间的描述格式由 rfc822 定义。例如，Date:Mon,31Dec200104:25:57GMT。Date 描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。

4）空行

5）正文（Request Body）

请求体，一般承载的内容是 POST 请求中的表单数据，对于 GET 请求，请求体为空。

除此之外，Content-type 还可以设为 application/x-www-form-urlencoded，这样内容就会以表单数据的形式放在请求体中提交，同时 Content-type 也可设为 multipart/from-data 来上传文件。

02 HTTP响应报文协议（Response）

响应，就是由服务器返回给客户端，可以分为三个部分： 响应状态码、响应头、响应体。

1）Response简述

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

• 示例

HTTP/1.1 200 OK
Date: Tue, 26 Mar 2024 23:30:34 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 29706
Connection: close
Server: Apache-Coyote/1.1
X-ASEN: YOU MAKE ME A SAD PANDA.
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Confluence-Request-Time: 1711495834783
X-Seraph-LoginReason: AUTHENTICATED_FAILED
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Vary: User-Agent<!DOCTYPE html>
<html>
<head><title>登录 - Confluence</title>****省略，反正就是返回html相关的源代码，效果如下，就是登陆失败的html页面*****

2）状态行（Resqonse Status Code）

状态码有很多种，主要分为五类：1xx、2xx、3xx、4xx、5xx

• 1xx：信息响应
  

• 2xx：成功响应

• 

• 3xx：重定向

• 

• 4xx：客户端错误

• 

• 5xx：服务器错误

• 

3）响应头（Response Headers）

响应头，包含了服务器对请求的应答信息，如 Content-Type、Server、Set-Cookie等。下面简要介绍一些常用的响应头信息

• Allow
  服务器支持哪些请求方法（如GET、POST等）。
• Date
  用于表示响应产生的时间，当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
• Last-Modified
  用于指定资源的最后修改时间，文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。
• Content-Encoding
  用于指定响应内容的编码，文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader(“Accept-Encoding”)）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。
• Content-Type
  Content-Type（内容类型），一般是指网页中存在的 Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件，这就是经常看到一些 PHP 网页点击的结果却是下载一个文件或一张图片的原因。
  Content-Type 标头告诉客户端实际返回的内容的内容类型。
  语法格式：

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

常见的媒体格式类型如下：

text/html ： HTML格式
text/plain ：纯文本格式
text/xml ： XML格式
image/gif ：gif图片格式
image/jpeg ：jpg图片格式
image/png：png图片格式
以application开头的媒体格式类型：
application/xhtml+xml ：XHTML格式
application/xml： XML数据格式
application/atom+xml ：Atom XML聚合格式
application/json： JSON数据格式
application/pdf：pdf格式
application/msword ： Word文档格式
application/octet-stream ： 二进制流数据（如常见的文件下载）
application/x-www-form-urlencoded ： <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）
另外一种常见的媒体格式是上传文件之时使用的：
multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式

• Content-Length
  表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。
  Expires
  应该在什么时候认为文档已经过期，从而不再缓存它？

• Server
  包含服务器的信息，例如名称、版本号…

• Set-Cookie
  设置 Cookie。响应头中 Set-Cookie 用于告诉浏览器需要将次内容放置 Cookie 中，下次请求将 Cookie 带上。

• Location
  表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。

• Refresh
  表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。
  注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV=“Refresh” CONTENT="5;URL=http://host/path"＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。

注意Refresh的意义是"N秒之后刷新本页面或访问指定页面"，而不是"每隔N秒刷新本页面或访问指定页面"。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV=“Refresh” …＞。

注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。

• WWW-Authenticate
  客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。
  注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。

4）空行

5）响应体（Response Body）

响应体，也能叫正文，响应的数据都存在正文中，例如请求一个网页，正文就是网页的 HTML代码。

03 抓包分析

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

1）GET（一个Hello接口）

• Postman

  • 请求报文
    postman做了很深层次的封装，基本看不到HTTP相关的报文信息，只有简单的Headers、Cookies等信息。
    

  • 响应报文
    只有Body、以及一些基本信息，同样封装的狠，看不到更多的信息。
    

• Burp Suite Community Edition
  这个工具，改报文重试使用会比较方便，但还是不太适合用于底层抓包学习。
  

• Wireshark
  Http协议其实只是“报文数据”，其实所有应用层也都是不同格式的“报文数据”而已，到达传输层都是依赖于TCP、UDP来建立传输通道，操作系统使用FD文件描述符来控制传输通道，通过4元组来识别，在不同硬件级别如路由器、网关、ECS上都会有不同程度的“操作系统”“嵌入式系统”来解析数据包，最终通过物理层进行光电信号的传输。

过滤条件：
(http or tcp) and ip.addr == 192.168.50.223

Java测试源代码：

@Slf4j
@RestController
public class TempController {// 支持以下几种方法：GET、POST、OPTIONS、HEAD、PUT、DELETE、PATCH、@RequestMapping(value = "/hello", method = {RequestMethod.GET, RequestMethod.POST, RequestMethod.OPTIONS, RequestMethod.HEAD,RequestMethod.PUT, RequestMethod.DELETE, RequestMethod.PATCH})public ResultVo hello() {return new ResultUtil().setSuccessMsg();}
}

• 请求报文：
  

响应报文：

• 第一层，数据比特（物理层）
  以太网帧表示了数据通过物理介质传输。
  给出了数据帧的全局信息，包括帧长，帧到达的时间，接口的编号和帧的类型。

Frame 20: 265 bytes on wire (2120 bits), 265 bytes captured (2120 bits) on interface \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}, id 0Section number: 1Interface id: 0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})Interface name: \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}Interface description: 以太网Encapsulation type: Ethernet (1)Arrival Time: Apr 10, 2024 08:38:07.322193000 中国标准时间UTC Arrival Time: Apr 10, 2024 00:38:07.322193000 UTCEpoch Arrival Time: 1712709487.322193000[Time shift for this packet: 0.000000000 seconds][Time delta from previous captured frame: 0.001178000 seconds][Time delta from previous displayed frame: 0.001178000 seconds][Time since reference or first frame: 1.648897000 seconds]Frame Number: 20Frame Length: 265 bytes (2120 bits)Capture Length: 265 bytes (2120 bits)[Frame is marked: False][Frame is ignored: False][Protocols in frame: eth:ethertype:ip:tcp:http][Coloring Rule Name: HTTP][Coloring Rule String: http || tcp.port == 80 || http2]

该数据包通过以太网传输，其内容涉及到了 IP、TCP 和 HTTP 协议。此信息有助于网络分析人员深入了解数据包的特征和通信情况。
根据提供的数据包分析信息，这是关于第 20 帧的详细信息：

• 数据包长度：265 字节（2120 位），采用以太网封装。
• 接口信息：
  接口ID：0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})
  接口名称：\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}
  接口描述：以太网
• 封装类型：以太网 (Ethernet)
• 到达时间：Apr 10, 2024 08:38:07.322193000 中国标准时间
• UTC 到达时间：Apr 10, 2024 00:38:07.322193000 UTC
• Epoch 到达时间：1712709487.322193000
• 时间偏移：0.000000000 秒
• 距上一个捕获帧的时间差：0.001178000 秒
• 距上一个显示帧的时间差：0.001178000 秒
• 自参考或第一个帧以来的时间：1.648897000 秒
• 数据包编号：20
• 帧长度：265 字节（2120 位）
• 捕获长度：265 字节（2120 位）
• 协议层次：以太网、以太网类型、IP、TCP、HTTP
• 着色规则名：HTTP
• 着色规则字符串：http || tcp.port == 80 || http2

Frame 23: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}, id 0Section number: 1Interface id: 0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})Interface name: \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}Interface description: 以太网Encapsulation type: Ethernet (1)Arrival Time: Apr 10, 2024 08:38:07.344797000 中国标准时间UTC Arrival Time: Apr 10, 2024 00:38:07.344797000 UTCEpoch Arrival Time: 1712709487.344797000[Time shift for this packet: 0.000000000 seconds][Time delta from previous captured frame: 0.002458000 seconds][Time delta from previous displayed frame: 0.002458000 seconds][Time since reference or first frame: 1.671501000 seconds]Frame Number: 23Frame Length: 60 bytes (480 bits)Capture Length: 60 bytes (480 bits)[Frame is marked: False][Frame is ignored: False][Protocols in frame: eth:ethertype:ip:tcp:http:json][Coloring Rule Name: HTTP][Coloring Rule String: http || tcp.port == 80 || http2]

该数据包通过以太网传输，内容涉及到了 IP、TCP、HTTP 和 JSON 协议。网络分析人员可利用这些信息进一步了解数据包的内容和通信情况，有助于进行网络故障排除或安全分析。
根据提供的数据包分析信息，这是关于第 23 帧的详细信息：

• 数据包长度：60 字节（480 位），采用以太网封装。

• 接口信息：
  接口ID：0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})
  接口名称：\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}
  接口描述：以太网

• 封装类型：以太网 (Ethernet)

• 到达时间：Apr 10, 2024 08:38:07.344797000 中国标准时间

• UTC 到达时间：Apr 10, 2024 00:38:07.344797000 UTC

• Epoch 到达时间：1712709487.344797000

• 时间偏移：0.000000000 秒

• 距上一个捕获帧的时间差：0.002458000 秒

• 距上一个显示帧的时间差：0.002458000 秒

• 自参考或第一个帧以来的时间：1.671501000 秒

• 数据包编号：23

• 帧长度：60 字节（480 位）

• 捕获长度：60 字节（480 位）

• 协议层次：以太网、以太网类型、IP、TCP、HTTP、JSON

• 着色规则名：HTTP

• 着色规则字符串：http || tcp.port == 80 || http2

• 第二行，数据帧（数据链路层）
  Ethernet II - MAC 地址用于在局域网中唯一标识设备。
  可以看到以太帧头部包括的三个字段，目的MAC地址，源MAC地址、类型字段，类型字段取值为十六进制的0800，说明数据帧中包含的是一个IP分组。

Ethernet II, Src: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a), Dst: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)Destination: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)Address: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55).... ..0. .... .... .... .... = LG bit: Globally unique address (factory default).... ...0 .... .... .... .... = IG bit: Individual address (unicast)Source: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)Address: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a).... ..0. .... .... .... .... = LG bit: Globally unique address (factory default).... ...0 .... .... .... .... = IG bit: Individual address (unicast)Type: IPv4 (0x0800)

这段信息提供了源地址、目标地址和数据包类型等信息，有助于网络分析人员识别和理解网络通信中不同设备之间的通信关系。MAC 地址用于在局域网环境中唯一标识设备，而类型字段可以告诉我们该帧中封装的数据包是什么类型的协议。
根据提供的以太网帧信息进行分析：

• 源地址（Source）：GigaByteTech_3f:c8:7a（MAC 地址为 e0:d5:5e:3f:c8:7a）
  • 地址类型：全球唯一地址（工厂默认）
  • 地址类型：单播地址
• 目标地址（Destination）：RuijieNetwor_1d:4c:55（MAC 地址为 c0:b8:e6:1d:4c:55）
  • 地址类型：全球唯一地址（工厂默认）
  • 地址类型：单播地址
• 类型：IPv4 (0x0800) 表示该帧中封装了一个 IPv4 数据包。

Ethernet II, Src: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55), Dst: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)Destination: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)Address: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a).... ..0. .... .... .... .... = LG bit: Globally unique address (factory default).... ...0 .... .... .... .... = IG bit: Individual address (unicast)Source: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)Address: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55).... ..0. .... .... .... .... = LG bit: Globally unique address (factory default).... ...0 .... .... .... .... = IG bit: Individual address (unicast)Type: IPv4 (0x0800)Padding: 00

这段信息提供了源地址、目标地址和数据包类型等信息，有助于网络分析人员识别和理解发送方和接收方之间的通信关系。MAC 地址用于在局域网环境中唯一标识设备，而类型字段可以告诉我们该帧中封装的数据包是什么类型的协议。填充字段主要用于数据包长度的调整和对齐。
根据提供的以太网帧信息进行分析：

• 源地址（Source）：RuijieNetwor_1d:4c:55（MAC 地址为 c0:b8:e6:1d:4c:55）

  • 地址类型：全球唯一地址（工厂默认）
  • 地址类型：单播地址

• 目标地址（Destination）：GigaByteTech_3f:c8:7a（MAC 地址为 e0:d5:5e:3f:c8:7a）

  • 地址类型：全球唯一地址（工厂默认）
  • 地址类型：单播地址

• 类型：IPv4 (0x0800) 表示该帧中封装了一个 IPv4 数据包。

• 填充（Padding）：填充字段为 00，用于确保数据包达到最小长度要求。

• 第三行，IP数据包（网络层）
  Internet Protocol Version 4 (IPv4) - 用于在网络上唯一标识设备，并提供路由功能。
  包括版本号4，头部长度20字节，服务类型，数据报总长度，用于分片的标志字0，分片偏移字段0，说明这是一个完整的IP数据报。没有被分片。生存周期128，表示最多允许经过128跳路由器的转发。协议字段1，说明IP分组里面封装的是一个ICMP报文，头部校验、源IP地址，目的IP地址。我们可以对照以太网IP协议规范的报文格式来检查ICMP报文该字段是符合规范的。

Internet Protocol Version 4, Src: 192.168.10.238, Dst: 192.168.50.2230100 .... = Version: 4.... 0101 = Header Length: 20 bytes (5)Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)0000 00.. = Differentiated Services Codepoint: Default (0).... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)Total Length: 251Identification: 0x8e9d (36509)010. .... = Flags: 0x2, Don't fragment0... .... = Reserved bit: Not set.1.. .... = Don't fragment: Set..0. .... = More fragments: Not set...0 0000 0000 0000 = Fragment Offset: 0Time to Live: 128Protocol: TCP (6)Header Checksum: 0x0000 [validation disabled][Header checksum status: Unverified]Source Address: 192.168.10.238Destination Address: 192.168.50.223

这些信息描述了IPv4数据包的各种属性，包括头部长度、差异化服务、总长度、标识、标记位、协议类型等。网络分析人员可以利用这些信息来深入了解数据包的特征以及网络通信中涉及的设备和协议。
根据提供的 IPv4 数据包信息进行分析：

• 版本（Version）：IPv4 版本为 4。
• 头部长度（Header Length）：20 字节（5 个 32 位字）。
• 区分服务字段（Differentiated Services Field）：0x00
• 差异化服务代码点（DSCP）：CS0（默认）
• 显式拥塞通知（ECN）：未启用
• 总长度（Total Length）：251 字节。
• 标识（Identification）：0x8e9d（36509）。
• 标记位（Flags）：0x2，表示"不分片"（Don’t fragment）。
• 分片偏移（Fragment Offset）：0。
• 存活时间（Time to Live）：128。
• 协议（Protocol）：TCP，协议编号为 6。
• 头部校验和（Header Checksum）：0x0000（校验和验证已禁用）。
• 源地址（Source Address）为 192.168.10.238，
• 目标地址（Destination Address）为 192.168.50.223。

Internet Protocol Version 4, Src: 192.168.50.223, Dst: 192.168.10.2380100 .... = Version: 4.... 0101 = Header Length: 20 bytes (5)Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)0000 00.. = Differentiated Services Codepoint: Default (0).... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)Total Length: 45Identification: 0xe673 (58995)010. .... = Flags: 0x2, Don't fragment0... .... = Reserved bit: Not set.1.. .... = Don't fragment: Set..0. .... = More fragments: Not set...0 0000 0000 0000 = Fragment Offset: 0Time to Live: 63Protocol: TCP (6)Header Checksum: 0x9639 [validation disabled][Header checksum status: Unverified]Source Address: 192.168.50.223Destination Address: 192.168.10.238

这些信息描述了该 IPv4 数据包的各种属性，如头部长度、差异化服务、总长度、标识、标记位、协议类型等。网络分析人员可以利用这些信息来深入了解数据包的特征以及网络通信中涉及的设备和协议。
根据提供的IPv4数据包信息进行分析：

• 版本（Version）：IPv4 版本为 4。

• 头部长度（Header Length）：20 字节（5 个 32 位字）。

• 区分服务字段（Differentiated Services Field）：0x00

• 差异化服务代码点（DSCP）：CS0（默认）

• 显式拥塞通知（ECN）：未启用

• 总长度（Total Length）：45 字节。

• 标识（Identification）：0xe673（58995）。

• 标记位（Flags）：0x2，表示"不分片"（Don’t fragment）。

• 分片偏移（Fragment Offset）：0。

• 存活时间（Time to Live）：63。

• 协议（Protocol）：TCP，协议编号为 6。

• 头部校验和（Header Checksum）：0x9639（校验和验证已禁用）。

• 源地址（Source Address）为 192.168.50.223，

• 目标地址（Destination Address）为 192.168.10.238。

• 第四行，TCP报文段（传输层）
  Transmission Control Protocol (TCP) - 提供可靠的数据传输，使用端口号来标识不同的应用程序通信。

Transmission Control Protocol, Src Port: 53387, Dst Port: 7778, Seq: 1, Ack: 1, Len: 211Source Port: 53387Destination Port: 7778[Stream index: 9][Conversation completeness: Incomplete, DATA (15)]..0. .... = RST: Absent...0 .... = FIN: Absent.... 1... = Data: Present.... .1.. = ACK: Present.... ..1. = SYN-ACK: Present.... ...1 = SYN: Present[Completeness Flags: ··DASS][TCP Segment Len: 211]Sequence Number: 1    (relative sequence number)Sequence Number (raw): 3565710654[Next Sequence Number: 212    (relative sequence number)]Acknowledgment Number: 1    (relative ack number)Acknowledgment number (raw): 41396661020101 .... = Header Length: 20 bytes (5)Flags: 0x018 (PSH, ACK)000. .... .... = Reserved: Not set...0 .... .... = Accurate ECN: Not set.... 0... .... = Congestion Window Reduced: Not set.... .0.. .... = ECN-Echo: Not set.... ..0. .... = Urgent: Not set.... ...1 .... = Acknowledgment: Set.... .... 1... = Push: Set.... .... .0.. = Reset: Not set.... .... ..0. = Syn: Not set.... .... ...0 = Fin: Not set[TCP Flags: ·······AP···]Window: 8212[Calculated window size: 2102272][Window size scaling factor: 256]Checksum: 0xc00b [unverified][Checksum Status: Unverified]Urgent Pointer: 0[Timestamps][Time since first frame in this TCP stream: 0.001515000 seconds][Time since previous frame in this TCP stream: 0.001178000 seconds][SEQ/ACK analysis][iRTT: 0.000337000 seconds][Bytes in flight: 211][Bytes sent since last PSH flag: 211]TCP payload (211 bytes)

在 TCP 数据包中，源端口和目标端口定义了通信所涉及的应用程序，标志字段描述了该数据包的状态，序列号和确认号用于 TCP 数据包的顺序控制和可靠性传输。窗口大小表示接收端的可用缓冲区大小，检验和用于数据完整性验证。这些信息有助于理解网络通信中传输的数据包特征和行为。
根据提供的传输控制协议（TCP）数据包信息进行分析：

• 源端口（Source Port）：53387
• 目标端口（Destination Port）：7778
• TCP 标志（Flags）：0x018 (PSH, ACK)
• PSH（Push）: 数据段应该立即被传送给应用层。
• ACK（Acknowledgment）: 确认号字段有效。
• 序列号（Sequence Number）：1 (相对序列号)，原始序列号为 3565710654。
• 下一个序列号：212 (下一个相对序列号)。
• 确认号（Acknowledgment Number）：1 (相对确认号)，原始确认号为 4139666102。
• 头部长度（Header Length）：20 字节 (5 个 32 位字)。
• 窗口大小（Window Size）：8212，经过窗口大小缩放后为 2102272。
• 数据长度（TCP Segment Length）：211 字节。
• 检验和（Checksum）：0xc00b（未验证）。
• 紧急指针（Urgent Pointer）：0。

Transmission Control Protocol, Src Port: 7778, Dst Port: 53387, Seq: 419, Ack: 212, Len: 5Source Port: 7778Destination Port: 53387[Stream index: 9][Conversation completeness: Incomplete, DATA (15)]..0. .... = RST: Absent...0 .... = FIN: Absent.... 1... = Data: Present.... .1.. = ACK: Present.... ..1. = SYN-ACK: Present.... ...1 = SYN: Present[Completeness Flags: ··DASS][TCP Segment Len: 5]Sequence Number: 419    (relative sequence number)Sequence Number (raw): 4139666520[Next Sequence Number: 424    (relative sequence number)]Acknowledgment Number: 212    (relative ack number)Acknowledgment number (raw): 35657108650101 .... = Header Length: 20 bytes (5)Flags: 0x018 (PSH, ACK)000. .... .... = Reserved: Not set...0 .... .... = Accurate ECN: Not set.... 0... .... = Congestion Window Reduced: Not set.... .0.. .... = ECN-Echo: Not set.... ..0. .... = Urgent: Not set.... ...1 .... = Acknowledgment: Set.... .... 1... = Push: Set.... .... .0.. = Reset: Not set.... .... ..0. = Syn: Not set.... .... ...0 = Fin: Not set[TCP Flags: ·······AP···]Window: 237[Calculated window size: 30336][Window size scaling factor: 128]Checksum: 0x3703 [unverified][Checksum Status: Unverified]Urgent Pointer: 0[Timestamps][Time since first frame in this TCP stream: 0.024119000 seconds][Time since previous frame in this TCP stream: 0.002458000 seconds][SEQ/ACK analysis][iRTT: 0.000337000 seconds][Bytes in flight: 423][Bytes sent since last PSH flag: 5]TCP payload (5 bytes)TCP segment data (5 bytes)

在这个 TCP 数据包中，源端口和目标端口定义了通信双方的应用程序，标志字段描述了数据包状态，序列号和确认号用于 TCP 数据包的顺序控制和可靠性传输。窗口大小表示接收方的可用缓冲区大小，检验和用于数据完整性验证。这些信息有助于理解网络通信中传输的数据包特征和行为。
根据提供的传输控制协议（TCP）数据包信息进行分析：

• 源端口（Source Port）：7778
• 目标端口（Destination Port）：53387
• TCP 标志（Flags）：0x018 (PSH, ACK)
• PSH（Push）: 数据段应该立即被传送给应用层。
• ACK（Acknowledgment）: 确认号字段有效。
• 序列号（Sequence Number）：419 (相对序列号)，原始序列号为 4139666520。
• 下一个序列号：424 (下一个相对序列号)。
• 确认号（Acknowledgment Number）：212 (相对确认号)，原始确认号为 3565710865。
• 头部长度（Header Length）：20 字节 (5 个 32 位字)。
• 窗口大小（Window Size）：237，经过窗口大小缩放后为 30336。
• 数据长度（TCP Segment Length）：5 字节。
• 检验和（Checksum）：0x3703（未验证）。

第五行，HTTP报文（应用层）
Hypertext Transfer Protocol (HTTP) - 用于在客户端和服务器之间传输超文本内容的协议。

Hypertext Transfer ProtocolGET /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): GET /hello HTTP/1.1\r\n][GET /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: GETRequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: 7a4a6ad5-ef7c-482b-b2bf-dcba41a4e281\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\n\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 1/1][Response in frame: 23]

在这个 HTTP 请求中，客户端（User-Agent）使用 PostmanRuntime/7.37.3 进行通信，请求的资源为 http://192.168.50.223:7778/hello。请求方法为 GET，表示获取指定资源。Accept 头部字段指示客户端可以接受任何类型的响应内容。请求头部中还包括了一些其他信息，如主机、压缩和连接方式等。通过这些信息，服务器可以解析请求并返回相应的响应。

根据提供的超文本传输协议（HTTP）请求信息进行分析：

• 请求行：GET /hello HTTP/1.1
• 请求方法（Request Method）：GET
• 请求 URI（Request URI）：/hello
• 请求版本（Request Version）：HTTP/1.1

接下来是请求头部信息：

• User-Agent: PostmanRuntime/7.37.3
• Accept: /
• Postman-Token: 7a4a6ad5-ef7c-482b-b2bf-dcba41a4e281
• Host: 192.168.50.223:7778
• Accept-Encoding: gzip, deflate, br
• Connection: keep-alive
• 最后是空行 \r\n，表示请求头部结束。

Hypertext Transfer Protocol, has 2 chunks (including last chunk)HTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nSet-Cookie: JSESSIONID=AC55C30B845F298471BDAC902F865616; Path=/; HttpOnly\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 00:38:08 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 1/1][Time since request: 0.022604000 seconds][Request in frame: 20][Request URI: http://192.168.50.223:7778/hello]HTTP chunked responseData chunk (86 octets)Chunk size: 86 octetsChunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323730393438383234332c2264617461223a6e756c6c7dChunk boundary: 0d0aEnd of chunked encodingChunk size: 0 octets\r\nFile Data: 86 bytes

在 HTTP 响应中，服务器返回了状态码 200，表示请求成功。响应内容采用了分块传输编码（chunked transfer encoding），数据被分成多个块传送，每个块包含一个块大小以及具体的数据。最后一个块的大小为 0，表示所有数据块已全部传输，即分块编码结束。
在这个响应中，返回了一段 JSON 数据，长度为 86 字节。数据块编码中，包含了经过编码处理的 JSON 数据和块边界标志 0d0a（回车换行）。通过这些信息，客户端可以解析数据块并处理对应的响应内容。
根据提供的超文本传输协议（HTTP）响应信息进行分析：

• 响应行：HTTP/1.1 200
• 响应版本（Response Version）：HTTP/1.1
• 状态码（Status Code）：200
• 状态码描述：OK

接下来是响应头部信息：

• Vary: Origin
• Vary: Access-Control-Request-Method
• Vary: Access-Control-Request-Headers
• Set-Cookie: JSESSIONID=AC55C30B845F298471BDAC902F865616; Path=/; HttpOnly
• Content-Type: application/json
• Transfer-Encoding: chunked
• Date: Wed, 10 Apr 2024 00:38:08 GMT
• Keep-Alive: timeout=60
• Connection: keep-alive

2）POST

请求报文

Hypertext Transfer ProtocolPOST /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): POST /hello HTTP/1.1\r\n][POST /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: POSTRequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: aa66df48-7879-4f4a-b447-46d47e0e3d73\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\nCookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\nCookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08EContent-Length: 0\r\n[Content length: 0]\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 1/1][Response in frame: 35]

这段文本是一个HTTP请求的数据包内容。下面是对该HTTP请求的分析：

• 请求行：POST /hello HTTP/1.1 表示这是一个使用POST方法，目标地址为/hello的HTTP/1.1版本的请求。
• 请求头部：
  • User-Agent: PostmanRuntime/7.37.3：标识客户端应用程序的用户代理信息。
  • Accept: /：指定客户端能够处理的MIME类型。
  • Postman-Token: aa66df48-7879-4f4a-b447-46d47e0e3d73：Postman工具生成的令牌。
  • Host: 192.168.50.223:7778：指定请求的主机和端口号。
  • Accept-Encoding: gzip, deflate, br：指定客户端可以支持的压缩算法。
  • Connection: keep-alive：指示客户端与服务器之间的连接保持活动状态。
  • Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含会话标识符的Cookie。
  • Content-Length: 0：指定请求正文的长度为0，表示请求中没有主体内容。
• 完整请求URI：http://192.168.50.223:7778/hello 表示完整的请求URI。
• 分析结论：此请求是使用POST方法发送到/hello的URL，客户端是通过Postman工具发送的，请求不包含任何主体内容（Content）。

综上所述，这是一个简单的HTTP POST请求，由Postman工具发起，针对http://192.168.50.223:7778/hello的目标地址，在请求头部中包含了各种元数据信息，但请求正文为空。

• 响应报文
  

Hypertext Transfer Protocol, has 2 chunks (including last chunk)HTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 01:12:10 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 1/1][Time since request: 0.008740000 seconds][Request in frame: 33][Request URI: http://192.168.50.223:7778/hello]HTTP chunked responseData chunk (86 octets)Chunk size: 86 octetsChunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313533303535362c2264617461223a6e756c6c7dChunk boundary: 0d0aEnd of chunked encodingChunk size: 0 octets\r\nFile Data: 86 bytes

这段文本是一个HTTP响应的数据包内容，主要针对一个使用了chunked传输编码的响应进行了分析。下面是对该HTTP响应的分析：

• 响应行：HTTP/1.1 200 表示这是一个HTTP/1.1版本的状态码为200（OK）的响应。
• 响应头部：
  • Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：表示服务器对缓存的响应做了变化，可能根据请求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值进行响应的变化。
  • Content-Type: application/json：指定响应内容的类型为JSON。
  • Transfer-Encoding: chunked：指示响应体使用了分块编码方式传输。
  • Date: Wed, 10 Apr 2024 01:12:10 GMT：指示响应生成的日期和时间。
  • Keep-Alive: timeout=60、Connection: keep-alive：表示保持连接活动状态，超时时间为60秒。
• 数据块：在Data chunk中，提供了一部分经过编码的数据。
• Chunk size: 86 octets：表示该数据块的大小为86字节。
• Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313533303535362c2264617461223a6e756c6c7d：该数据块的内容，可能是经过压缩或其他编码的JSON数据。
• Chunk boundary: 0d0a：表示数据块边界。
• 结束标志：End of chunked encoding 中的 Chunk size: 0 octets 表示编码的结束。
• 文件数据：总共有86字节的文件数据。

综上所述，这是一个以分块编码方式传输的HTTP响应，并且响应正文含有经过编码的数据块，最后以结束标志表示编码结束。

3）OPTIONS

• 请求报文

Hypertext Transfer ProtocolOPTIONS /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): OPTIONS /hello HTTP/1.1\r\n][OPTIONS /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: OPTIONSRequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: a6f51f30-a7b6-4dc2-bba9-355d269e5150\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\nCookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\nCookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 1/1][Response in frame: 4701]

这段文本是一个HTTP请求的数据包内容。下面是对该HTTP请求的分析：
请求行：OPTIONS /hello HTTP/1.1 表示这是一个使用OPTIONS方法，目标地址为/hello的HTTP/1.1版本的请求。
请求头部：

• User-Agent: PostmanRuntime/7.37.3：标识客户端应用程序的用户代理信息。
• Accept: /：指定客户端能够处理的MIME类型。
• Postman-Token: a6f51f30-a7b6-4dc2-bba9-355d269e5150：Postman工具生成的令牌。
• Host: 192.168.50.223:7778：指定请求的主机和端口号。
• Accept-Encoding: gzip, deflate, br：指定客户端可以支持的压缩算法。
• Connection: keep-alive：指示客户端与服务器之间的连接保持活动状态。
• Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含会话标识符的Cookie。
• 完整请求URI：http://192.168.50.223:7778/hello 表示完整的请求URI。
• 分析结论：此请求是使用OPTIONS方法发送到/hello的URL，客户端是通过Postman工具发送的，请求中包含了各种元数据信息，但没有主体内容（Content）。

综上所述，这是一个简单的HTTP OPTIONS请求，由Postman工具发起，针对http://192.168.50.223:7778/hello的目标地址，在请求头部中包含了各种元数据信息，但请求正文为空。

• 响应报文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)HTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 01:15:09 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 1/1][Time since request: 0.009532000 seconds][Request in frame: 4698][Request URI: http://192.168.50.223:7778/hello]HTTP chunked responseData chunk (86 octets)Chunk size: 86 octetsChunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313730393933362c2264617461223a6e756c6c7dChunk boundary: 0d0aEnd of chunked encodingChunk size: 0 octets\r\nFile Data: 86 bytes

这段文本描述了一个HTTP响应的数据包内容，主要涉及使用了chunked传输编码的响应。以下是对该HTTP响应的分析：

• 响应行：HTTP/1.1 200 表示这是一个状态码为200（OK）的HTTP/1.1版本的响应。
• 响应头部：
  • Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服务器对缓存的响应做了变化，可能会根据请求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值进行响应的调整。
  • Content-Type: application/json：指定响应内容的类型为JSON。
  • Transfer-Encoding: chunked：表明响应体使用了分块编码方式传输。
  • Date: Wed, 10 Apr 2024 01:15:09 GMT：表示响应产生的日期和时间。
  • Keep-Alive: timeout=60、Connection: keep-alive：说明保持连接活动状态，超时时间为60秒。
• 数据块：在Data chunk中，提供了一部分经过编码的数据。
  • Chunk size: 86 octets：表示该数据块的大小为86字节。
  • Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313730393933362c2264617461223a6e756c7c7d：该数据块的内容，可能是经过压缩或其他编码的JSON数据。
  • Chunk boundary: 0d0a：表示数据块的边界。
• 结束标志：End of chunked encoding 中的 Chunk size: 0 octets 表示编码的结束。
• 文件数据：共有86字节的文件数据。

综上所述，这是一个使用了分块编码方式传输的HTTP响应，响应正文包含了经过编码的数据块，并用结束标志表示编码的结束。

4）HEAD

• 请求报文

Hypertext Transfer ProtocolHEAD /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): HEAD /hello HTTP/1.1\r\n][HEAD /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: HEADRequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: 1ee6d1d3-34f1-4e83-9cb9-86f7e0ca4cb0\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\nCookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\nCookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 2/2][Prev request in frame: 4698][Response in frame: 5172]

这段文本是一个HTTP请求的数据包内容。以下是对该HTTP请求的分析：

• 请求行：HEAD /hello HTTP/1.1 表示这是一个使用HEAD方法，目标地址为/hello的HTTP/1.1版本的请求。
• 请求头部：
  • User-Agent: PostmanRuntime/7.37.3：标识客户端应用程序的用户代理信息。
  • Accept: /：指定客户端能够处理的MIME类型。
  • Postman-Token: 1ee6d1d3-34f1-4e83-9cb9-86f7e0ca4cb0：Postman工具生成的令牌。
  • Host: 192.168.50.223:7778：指定请求的主机和端口号。
  • Accept-Encoding: gzip, deflate, br：指定客户端可以支持的压缩算法。
  • Connection: keep-alive：表示客户端与服务器之间的连接保持活动状态。
  • Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含会话标识符的Cookie。
• 完整请求URI：http://192.168.50.223:7778/hello 表示完整的请求URI。
• 其他信息：
  • [HTTP request 2/2]：表示这是第二个HTTP请求中的第二个请求。
  • [Prev request in frame: 4698]：指明前一个请求是在帧 4698 中。
  • [Response in frame: 5172]：说明响应在帧 5172 中。

综上所述，这是一个使用HEAD方法发送到/hello的URL的HTTP请求。请求由Postman工具发起，包含了各种元数据信息，但没有主体内容（Content）。这次请求是第二个HTTP请求中的第二个，并且包含了前一个请求和响应的帧信息。

• 响应报文

Hypertext Transfer ProtocolHTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 01:15:51 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 2/2][Time since request: 0.004596000 seconds][Prev request in frame: 4698][Prev response in frame: 4701][Request in frame: 5171][Request URI: http://192.168.50.223:7778/hello]

这段文本描述了一个HTTP响应的数据包内容。以下是对该HTTP响应的分析：

• 响应行：HTTP/1.1 200 表示这是一个状态码为200（OK）的HTTP/1.1版本的响应。
• 响应头部：
  • Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服务器对缓存的响应做了变化，可能会根据请求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值进行响应的调整。
  • Content-Type: application/json：指定响应内容的类型为JSON。
  • Transfer-Encoding: chunked：表明响应体使用了分块编码方式传输。
  • Date: Wed, 10 Apr 2024 01:15:51 GMT：表示响应产生的日期和时间。
  • Keep-Alive: timeout=60、Connection: keep-alive：说明保持连接活动状态，超时时间为60秒。
• 其他信息：
  • [HTTP response 2/2]：表示这是第二个HTTP响应中的第二个响应。
  • [Time since request: 0.004596000 seconds]：距离发出请求的时间为0.004596秒。
  • [Prev request in frame: 4698]：说明前一个请求在帧 4698 中。
  • [Prev response in frame: 4701]：指明前一个响应在帧 4701 中。
  • [Request in frame: 5171]：表示请求在帧 5171 中。
• 请求URI：http://192.168.50.223:7778/hello 表示请求的完整URI。

综上所述，这是一个状态码为200（OK）的HTTP响应，响应内容为application/json类型，并且使用了分块编码方式传输。响应中包含了一些头部信息，以及与前一个请求和响应相关的帧信息。

5）PUT

• 请求报文

Hypertext Transfer ProtocolPUT /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): PUT /hello HTTP/1.1\r\n][PUT /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: PUTRequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: e6e536a0-17bd-44c3-a88d-f74f0055c630\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\nCookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\nCookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08EContent-Length: 0\r\n[Content length: 0]\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 3/3][Prev request in frame: 5171][Response in frame: 5958]

这段文本是一个HTTP请求的数据包内容。以下是对该HTTP请求的分析：

• 请求行：PUT /hello HTTP/1.1 表示这是一个使用PUT方法，目标地址为/hello的HTTP/1.1版本的请求。
• 请求头部：
  • User-Agent: PostmanRuntime/7.37.3：标识客户端应用程序的用户代理信息。
  • Accept: /：指定客户端能够处理的MIME类型。
  • Postman-Token: e6e536a0-17bd-44c3-a88d-f74f0055c630：Postman工具生成的令牌。
  • Host: 192.168.50.223:7778：指定请求的主机和端口号。
  • Accept-Encoding: gzip, deflate, br：指定客户端可以支持的压缩算法。
  • Connection: keep-alive：表示客户端与服务器之间的连接保持活动状态。
  • Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含会话标识符的Cookie。
  • Content-Length: 0：说明请求体中的内容长度为0字节。
• 完整请求URI：http://192.168.50.223:7778/hello 表示完整的请求URI。
• 其他信息：
  • [HTTP request 3/3]：表示这是第三个HTTP请求中的第三个请求。
  • [Prev request in frame: 5171]：说明前一个请求在帧 5171 中。
  • [Response in frame: 5958]：指明响应在帧 5958 中。

综上所述，这是一个使用PUT方法发送到/hello的URL的HTTP请求。请求由Postman工具发起，包含了各种元数据信息，但没有主体内容（Content），因为Content-Length为0。这次请求是第三个HTTP请求中的第三个，并且包含了前一个请求和响应的帧信息。

• 响应报文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)HTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 01:16:33 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 3/3][Time since request: 0.009709000 seconds][Prev request in frame: 5171][Prev response in frame: 5172][Request in frame: 5956][Request URI: http://192.168.50.223:7778/hello]HTTP chunked responseData chunk (86 octets)Chunk size: 86 octetsChunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313739333030322c2264617461223a6e756c6c7dChunk boundary: 0d0aEnd of chunked encodingChunk size: 0 octets\r\nFile Data: 86 bytes

这段文本描述了一个HTTP响应的数据包内容，其中包含了使用分块编码传输的数据。以下是对该HTTP响应的分析：

• 响应行：HTTP/1.1 200 表示这是一个状态码为200（OK）的HTTP/1.1版本的响应。
• 响应头部：
  • Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服务器对缓存的响应做了变化，可能会根据请求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值进行响应的调整。
  • Content-Type: application/json：指定响应内容的类型为JSON。
  • Transfer-Encoding: chunked：表明响应体使用了分块编码方式传输。
  • Date: Wed, 10 Apr 2024 01:16:33 GMT：表示响应产生的日期和时间。
  • Keep-Alive: timeout=60、Connection: keep-alive：说明保持连接活动状态，超时时间为60秒。
• 其他信息：
  • [HTTP response 3/3]：表示这是第三个HTTP响应中的第三个响应。
  • [Time since request: 0.009709000 seconds]：距离发出请求的时间为0.009709秒。
  • [Prev request in frame: 5171]：说明前一个请求在帧 5171 中。
  • [Prev response in frame: 5172]：指明前一个响应在帧 5172 中。
  • [Request in frame: 5956]：表示请求在帧 5956 中。
• 请求URI：http://192.168.50.223:7778/hello 表示请求的完整URI。
• 分块编码响应：
  • 第一个数据块：
    Chunk size: 86 octets
    Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313739333030322c2264617461223a6e756c6c7d
    Chunk boundary: 0d0a (CRLF)
  • 结束分块编码：
    Chunk size: 0 octets
• 文件数据：86字节

综上所述，这是一个状态码为200（OK）的HTTP响应，响应内容为application/json类型，并且使用了分块编码方式传输。响应中包含了一些头部信息，以及一个包含86个字节数据块的分块编码响应。

6）DELETE

• 请求报文

Hypertext Transfer ProtocolDELETE /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): DELETE /hello HTTP/1.1\r\n][DELETE /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: DELETERequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: 5baf4561-ec2e-4fa1-b5f7-c5a7fd7381ee\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\nCookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\nCookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 4/4][Prev request in frame: 5956][Response in frame: 6546]

这段文本是一个HTTP请求的数据包内容。以下是对该HTTP请求的分析：

• 请求行：DELETE /hello HTTP/1.1 表示这是一个使用DELETE方法，目标地址为/hello的HTTP/1.1版本的请求。
• 请求头部：
  • User-Agent: PostmanRuntime/7.37.3：标识客户端应用程序的用户代理信息。
  • Accept: /：指定客户端能够处理的MIME类型。
  • Postman-Token: 5baf4561-ec2e-4fa1-b5f7-c5a7fd7381ee：Postman工具生成的令牌。
  • Host: 192.168.50.223:7778：指定请求的主机和端口号。
  • Accept-Encoding: gzip, deflate, br：指定客户端可以支持的压缩算法。
  • Connection: keep-alive：表示客户端与服务器之间的连接保持活动状态。
  • Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含会话标识符的Cookie。
• 完整请求URI：http://192.168.50.223:7778/hello 表示完整的请求URI。
• 其他信息：
  • [HTTP request 4/4]：表示这是第四个HTTP请求中的第四个请求。
  • [Prev request in frame: 5956]：说明前一个请求在帧 5956 中。
  • [Response in frame: 6546]：指明响应在帧 6546 中。

综上所述，这是一个使用DELETE方法发送到/hello的URL的HTTP请求。请求由Postman工具发起，包含了各种元数据信息。这次请求是第四个HTTP请求中的第四个，并且包含了前一个请求和响应的帧信息。

• 响应报文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)HTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 01:17:10 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 4/4][Time since request: 0.006411000 seconds][Prev request in frame: 5956][Prev response in frame: 5958][Request in frame: 6544][Request URI: http://192.168.50.223:7778/hello]HTTP chunked responseData chunk (86 octets)Chunk size: 86 octetsChunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313833303937352c2264617461223a6e756c6c7dChunk boundary: 0d0aEnd of chunked encodingChunk size: 0 octets\r\nFile Data: 86 bytes

这段文本描述了一个HTTP响应的数据包内容，其中包含了使用分块编码传输的数据。以下是对该HTTP响应的分析：

• 响应行：HTTP/1.1 200 表示这是一个状态码为200（OK）的HTTP/1.1版本的响应。
• 响应头部：
  • Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服务器对缓存的响应做了变化，可能会根据请求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值进行响应的调整。
  • Content-Type: application/json：指定响应内容的类型为JSON。
  • Transfer-Encoding: chunked：表明响应体使用了分块编码方式传输。
  • Date: Wed, 10 Apr 2024 01:17:10 GMT：表示响应产生的日期和时间。
  • Keep-Alive: timeout=60、Connection: keep-alive：说明保持连接活动状态，超时时间为60秒。
• 其他信息：
  • [HTTP response 4/4]：表示这是第四个HTTP响应中的第四个响应。
  • [Time since request: 0.006411000 seconds]：距离发出请求的时间为0.006411秒。
  • [Prev request in frame: 5956]：说明前一个请求在帧 5956 中。
  • [Prev response in frame: 5958]：指明前一个响应在帧 5958 中。
  • [Request in frame: 6544]：表示请求在帧 6544 中。
• 请求URI：http://192.168.50.223:7778/hello 表示请求的完整URI。
• 分块编码响应：
  • 第一个数据块：
    Chunk size: 86 octets
    Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313833303937352c2264617461223a6e756c7c7d
    Chunk boundary: 0d0a (CRLF)
  • 结束分块编码：
    Chunk size: 0 octets
• 文件数据：86字节

综上所述，这是一个状态码为200（OK）的HTTP响应，响应内容为application/json类型，并且使用了分块编码方式传输。响应中包含了一些头部信息，以及一个包含86个字节数据块的分块编码响应。

7）PATCH

• 请求报文

Hypertext Transfer ProtocolPATCH /hello HTTP/1.1\r\n[Expert Info (Chat/Sequence): PATCH /hello HTTP/1.1\r\n][PATCH /hello HTTP/1.1\r\n][Severity level: Chat][Group: Sequence]Request Method: PATCHRequest URI: /helloRequest Version: HTTP/1.1User-Agent: PostmanRuntime/7.37.3\r\nAccept: */*\r\nPostman-Token: 777aa266-72c1-4c97-8134-a75cb82c5c0a\r\nHost: 192.168.50.223:7778\r\nAccept-Encoding: gzip, deflate, br\r\nConnection: keep-alive\r\nCookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\nCookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08EContent-Length: 0\r\n[Content length: 0]\r\n[Full request URI: http://192.168.50.223:7778/hello][HTTP request 5/5][Prev request in frame: 6544][Response in frame: 8109]

这段文本描述了一个使用PATCH方法的HTTP请求。以下是对该请求的分析：

• 请求行：PATCH /hello HTTP/1.1 表示这是一个使用PATCH方法，目标地址为/hello的HTTP/1.1版本的请求。
• 请求头部：
  • User-Agent: PostmanRuntime/7.37.3：标识客户端应用程序的用户代理信息。
  • Accept: /：指定客户端能够处理的MIME类型。
  • Postman-Token: 777aa266-72c1-4c97-8134-a75cb82c5c0a：Postman工具生成的令牌。
  • Host: 192.168.50.223:7778：指定请求的主机和端口号。
  • Accept-Encoding: gzip, deflate, br：指定客户端可以支持的压缩算法。
  • Connection: keep-alive：表示客户端与服务器之间的连接保持活动状态。
  • Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含会话标识符的Cookie。
  • Content-Length: 0：说明请求体内容长度为0字节。
• 其他信息：
  • [Full request URI: http://192.168.50.223:7778/hello]：完整的请求URI为http://192.168.50.223:7778/hello。
  • [HTTP request 5/5]：表示这是第五次HTTP请求中的第五个请求。
  • [Prev request in frame: 6544]：上一个请求在帧 6544 中。
  • [Response in frame: 8109]：响应在帧 8109 中。

综上所述，这是一个使用PATCH方法发送到/hello的URL的HTTP请求。请求由Postman工具发起，包含了各种元数据信息。请求体为空，并且这是第五个HTTP请求中的最后一个请求，响应位于帧 8109。

• 响应报文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)HTTP/1.1 200 \r\n[Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n][HTTP/1.1 200 \r\n][Severity level: Chat][Group: Sequence]Response Version: HTTP/1.1Status Code: 200[Status Code Description: OK]Vary: Origin\r\nVary: Access-Control-Request-Method\r\nVary: Access-Control-Request-Headers\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nDate: Wed, 10 Apr 2024 01:17:45 GMT\r\nKeep-Alive: timeout=60\r\nConnection: keep-alive\r\n\r\n[HTTP response 5/5][Time since request: 0.003991000 seconds][Prev request in frame: 6544][Prev response in frame: 6546][Request in frame: 8107][Request URI: http://192.168.50.223:7778/hello]HTTP chunked responseData chunk (86 octets)Chunk size: 86 octetsChunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313836353238362c2264617461223a6e756c6c7dChunk boundary: 0d0aEnd of chunked encodingChunk size: 0 octets\r\nFile Data: 86 bytes

这段文本描述了一个HTTP响应的数据包内容，其中包含了使用分块编码传输的数据。以下是对该HTTP响应的分析：

• 响应行：HTTP/1.1 200 表示这是一个状态码为200（OK）的HTTP/1.1版本的响应。
• 响应头部：
  • Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服务器对缓存的响应做了变化，可能会根据请求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值进行响应的调整。
  • Content-Type: application/json：指定响应内容的类型为JSON。
  • Transfer-Encoding: chunked：表明响应体使用了分块编码方式传输。
  • Date: Wed, 10 Apr 2024 01:17:45 GMT：表示响应产生的日期和时间。
  • Keep-Alive: timeout=60、Connection: keep-alive：说明保持连接活动状态，超时时间为60秒。
• 其他信息：
  • [HTTP response 5/5]：表示这是第五个HTTP响应中的最后一个响应。
  • [Time since request: 0.003991000 seconds]：距离发出请求的时间为0.003991秒。
  • [Prev request in frame: 6544]：前一个请求在帧 6544 中。
  • [Prev response in frame: 6546]：前一个响应在帧 6546 中。
  • [Request in frame: 8107]：请求在帧 8107 中。
• 请求URI：http://192.168.50.223:7778/hello 表示请求的完整URI。
• 分块编码响应：
  • 第一个数据块：
    Chunk size: 86 octets
    Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313836353238362c2264617461223a6e756c6c7d
    Chunk boundary: 0d0a (CRLF)
  • 结束分块编码：
    Chunk size: 0 octets
• 文件数据：86字节

综上所述，这是一个状态码为200（OK）的HTTP响应，响应内容为application/json类型，并且使用了分块编码方式传输。响应中包含了一些头部信息，以及一个包含86个字节数据块的分块编码响应。

04 HTTPS

1）简介

HTTPS 协议是 HyperText Transfer Protocol Secure（超文本传输安全协议）的缩写，是一种通过计算机网络进行安全通信的传输协议。
HTTPS = HTTP + SSL/TLS，HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包，HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。

HTTPS 的信任基于证书颁发机构（CA），与一个网站之间的 HTTPS 连线仅在这些情况下可被信任：

• 浏览器正确地实现了 HTTPS 且操作系统中安装了正确且受信任的证书颁发机构；
• 证书颁发机构仅信任合法的网站；
• 被访问的网站提供了一个有效的证书，也就是说它是一个由操作系统信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
• 该证书正确地验证了被访问的网站（例如，访问 https://www.runoob.com 时收到了签发给 www.runoob.com 而不是其它域名的证书）；
• 此协议的加密层（SSL/TLS）能够有效地提供认证和高强度的加密。

2）与Http的区别

HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：

• 1、TCP 三次同步握手
• 2、客户端验证服务器数字证书
• 3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
• 4、SSL 安全加密隧道协商完成
• 5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

区别如下：

• HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
• 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
• HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
• http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
• HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

3）https工作原理

• 1、客户端发起 HTTPS 请求
  这个没什么好说的，就是用户在浏览器里输入一个 https 网址，然后连接到 server 的 443 端口。
• 2、服务端的配置
  采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择，有 1 年的免费服务)。
  这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
• 3、传送证书
  这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
• 4、客户端解析证书
  这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
  如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
• 5、传送加密信息
  这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
• 6、服务端解密信息
  服务端用私钥解密后，得到了客户端传过来的随机值(对称秘钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
• 7、传输加密后的信息
  这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。
• 8、客户端解密信息
  客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

05 HTTP2

TLS（传输层安全性协议）和 SSL（安全套接字层）都是用于保护网络通信安全性的加密协议。它们在确保数据传输过程中的机密性、完整性和认证方面起着重要作用。

• SSL：最初由 Netscape 开发，旨在为互联网通信提供安全性。SSL 使用加密技术对传输的数据进行加密，防止第三方截取和窃取信息，同时具备解密的功能。
• TLS：传输层安全性协议（TLS）是 SSL 的继任者，目前广泛使用。TLS 提供了更强大的加密算法和安全性选项，并通过不断更新来保持网络通信的安全性。

1）TLS传输层加密

虽然理论上HTTP/2也是支持非加密连接传输的（这种非加密连接的HTTP/2简称为h2c），但实际上目前主流浏览器厂商都只实现了加密连接的模式，所以https变成了HTTP/2的事实上的标准。

2）HTTP/2 特点

下面是 HTTP/2 的一些特点和改进之处：

• 多路复用：HTTP/2 允许同时发送多个请求和响应，而不是像 HTTP/1.1 一样只能一个一个地处理。这样可以减少延迟，提高效率，提高网络吞吐量。
• 二进制传输：HTTP/2 使用二进制协议，与 HTTP/1.1 使用的文本协议不同。二进制协议可以更快地解析，更有效地传输数据，减少了传输过程中的开销和延迟。
• 头部压缩：HTTP/2 使用 HPACK 算法对 HTTP 头部进行压缩，减少了头部传输的数据量，从而减少了网络延迟。
• 服务器推送：HTTP/2 支持服务器推送，允许服务器在客户端请求之前推送资源，以提高性能。
• 改进的安全性：HTTP/2 默认使用 TLS（Transport Layer Security）加密传输数据，提高了安全性。
• 兼容 HTTP/1.1：HTTP/2 可以与 HTTP/1.1 共存，服务器可以同时支持 HTTP/1.1 和 HTTP/2。如果客户端不支持 HTTP/2，服务器可以回退到 HTTP/1.1。

06 HTTP3

在quic的协议基础上进行建设的。