标签：HTTP 请求 TCP 学习 响应 手记 服务器 连接 wireshark
wireshark
WireShark是非常流行的网络封包分析工具，可以截取各种网络数据包，并显示数据包详细信息。
使用
捕获过滤
展示过滤
1. 协议过滤
比如TCP，只显示TCP协议。
2. IP 过滤
比如 ip.src ==192.168.1.102 显示源地址为192.168.1.102，
ip.dst==192.168.1.102, 目标地址为192.168.1.102
3. 端口过滤
tcp.port ==80, 端口为80的
tcp.srcport == 80, 只显示TCP协议的愿端口为80的。
4. Http模式过滤
http.request.method=="GET", 只显示HTTP GET方法的。
5. 逻辑运算符为 AND/ OR
协议分析
tcp协议分析
（版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。本文链接：Wireshark-TCP协议分析（包结构以及连接的建立和释放）_三哥的博客-CSDN博客）
TCP：传输控制协议
TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接： 面向连接意味着使用tcp的应用程序在传输数据前必须先建立连接，就如打电话一样，要先进行拨号，等待对方响应才能开始说话。
可靠性：tcp协议通过下列方式来提高可靠性：
- 应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。由TCP传递给I P的信息单位称为报文段或段
- 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
- 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
- TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
- 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
- 既然I P数据报会发生重复，TCP的接收端必须丢弃重复的数据。
-
TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲
区溢出。字节流：两个应用程序通过TCP连接交换8 bit字节构成的字节流。
另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。
TCP首部格式
tcp数据是被封装在IP数据包中的，和udp类似，在IP数据包的数据部分。tcp数据包的格式如下：
源端口号和目的端口号与udp中类似，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接，在网络编程中，一般一个IP地址和一个端口号组合称为一个套接字（socket）。
序号：用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。在tcp中tcp用序号对每个字节进行计数（这个值与发送的帧数没有关系，而是与发送的数据字节数有关系，后面会有说明）。
确认序号：包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加 1（不是单纯的序号加1，还包括数据字节数）。
首部长度：用于记录tcp数据报首部的长度，一般为20字节，实际值为首部长度除以4。
URG： 紧急指针（ urgent pointer）有效。
ACK： 确认序号有效。
PSH： 接收方应该尽快将这个报文段交给应用层。
RST： 重建连接。
SYN： 同步序号用来发起一个连接。
FIN： 发端完成发送任务。
窗口大小：用于流量控制。
检验和：检验和覆盖了整个的 TCP报文段： TCP首部和TCP数据，与udp相似需要计算伪首部。
Wireshark抓包分析TCP结构
利用wireshark抓取一个tcp数据包，查看其具体数据结构和实际的数据：
TCP连接的建立
利用TCP传输数据前，需要建立tcp连接，tcp连接的建立有3个主要过程，叫做3次握手，具体过程如下图所示：
过程：
1. 首先客户端发送一个SYN包给服务器（SYN=1，Seq为主机选择的这个连接的初始序号），然后等待应答。
2. 服务器端收到SYN包，回应给客户端一个ACK =x+1、SYN=1的TCP数据段(ACK表示确认序号有效，即收到上一个包，这里加1并不是ACK的值加1，ACK是一个标志位，这里会变成1，而x+1则是希望收到的下一个包的序列号，这个值放在包的确认序列号字段中，而只有ACK=1时，确认序列号才有效)。
3. 客户必须再次回应服务器端一个ACK确认数据段（这里的Seq为x+1）。
经过上面3个过程就建立了一个tcp连接，接着就可以发送数据了，因为建立连接使用了一个序列号x，所以发送数据的第一个字节序号为x+1。
注意：这里tcp为应用层提供全双工服务，意味数据能在两个方向上独立地进行传输，因此连接的每一段都有各自的传输数据序号（对应于上图中的x和y，这两个值是没有必然联系的）。
Wireshark抓包分析TCP3次握手
下面通过利用http应用层连接一个网络，实现tcp的3次握手和简单的数据交换过程，下面通过抓包来实际观察这个过程，首先我们先看看抓到的包：
从第一行的tcp往下看，前面3个tcp包为3次握手的过程，接着http包说明成功建立连接，主机向服务器发送一个http应用请求，服务器收到请求后，返回一个tcp确认帧，接着发送一个http应答给主机，主机收到服务器的http应答数据后，又发送一个tcp确认帧，确认收到了数据。这样图中的前7个包实现了主机和服务器建立连接，并实现一次简单的数据请求应答过程。即下图所示的交互按键回显过程：
接下来是按照顺序的７个数据帧的数据结构。数据帧顺序分别为：
1. 主机发起一个tcp连接请求（tcp），
2. 服务器响应连接请求（tcp），
3. 主机返回ACK完成3次握手成功建立连接（tcp），
4. 主机发送一个http网页请求（http），
5. 服务器收到请求返回一个ACK帧（tcp），
6. 服务器根据请求发送数据到主机（http），
7. 主机收到服务器数据返回一个ACK帧（tcp），具体帧细节见下图：
TCP连接的释放
当通信双方完成数据传输，需要进行TCP连接的释放，由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。因为正常关闭过程需要发送4个TCP帧，因此这个过程也叫作4次挥手。具体过程如下图：
过程（默认客户端发起关闭）：
1. TCP客户端发送一个FIN，关闭客户端到服务器端的数据传送。（客户端不再发送报文给服务器端，但可接受服务器端报文）
2. 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。
3.服务器关闭客户端的连接，发送一个FIN给客户端。（服务器端关闭到客户端的数据传送）
4.客户段发回ACK报文确认，并将确认序号设置为收到序号加1。
下面通过wireshark抓包了解具体的释放连接过程，通过断开一个连接，抓取到4个TCP帧，帧顺序依次为：
1. 主动关闭放发送一个FIN帧给被动方
2. 被动方收到关闭信息返回一个确认ACK帧
3. 被动方发送一个FIN帧给主动方
4. 主动方收到被动方的FIN关闭信息返回一个ACK帧，连接释放
下面为按照顺序的帧数据结构详细信息：
TCP的最大报文段长度
上面介绍了TCP连接的建立和释放过程，下面介绍一下TCP的最大报文段长度。
最大报文段长度（MSS）表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。一般来说，MSS越大越好，因为报文段越大允许每个报文段传送的数据就越多，相对IP和TCP首部有更高的网络利用率。
MSS选项只能出现在SYN报文段中，所以只能在SYN=1的帧中才会有MSS选项说明报文的最大段长度。
具体参考：
报文段_百度百科
其他
关于TCP的内容还有很多，这里不再详细说明，但是需要知道，TCP连接的建立和释放还有几种比较特殊的情况，同时打开（SYN）建立连接，同时关闭或半关闭来释放连接的情况都是存在的，还有一些TCP的可选字段，这里都不再讲了，具体可以参考：TCP/IP 详解卷1。
HTTP协议分析（转载）
1. 什么是HTTP
HTTP（HyperText Transfer Protocol，超文本传输协议）是Web系统最核心的内容，它是Web服务器和客户端直接进行数据传输的规则。Web服务器就是平时所说的网站，是信息内容的发布者。最常见的客户端就是浏览器，是信息内容的接受者。
HTTP（HyperText Transfer Protocol，超文本传输协议）协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。HTTP是一个应用层协议，有请求和响应构成，是一个标准的客户端服务器模型。HTTP具有以下几个特点：
1. 支持客户/服务器模式，支持基本认证和安全认证
2. 简单快速；客户端向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. HTTP 0.9和1.0使用非持续连接：限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。HTTP 1.1使用持续连接：不必为每个web对象创建一个新的连接，一个连接可以传送多个对象。
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
2HTTP请求方法
HTTP/1.1协议中共定义了8种动作（方法）来表明Request-URI指定的资源的不同操作方式。
1. OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向Web服务器发送"*"的请求来测试服务器的功能性。
2. HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
3. GET：向特定的资源发出请求。注意：get方法不应当被用于产生“副作用”的操作中。例如在Web APP中，其中一个原因是GET可能会被网站蜘蛛等随意访问。
4. POST：向指定资源提交数据进行处理请求（比如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立或已有资源的修改。
5. PUT：向指定资源位置上传其最新内容。
6. DELETE：请求服务器删除Request-URI所标识的资源。
7. TRACE：回显服务器收到的请求，主要用于测试或者诊断。
8. CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
在大部分情况下，只会用到GET和HEAD方法，并且这些方法是区分大小写的，当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405，当服务器不认 识或不支持对应的请求方法的时候，应当返回状态行501。
3. HTTP工作流程
HTTP是一个无状态的协议。无状态是指客户端（Web浏览器）和服务器之间不需要建立持久的链接。这意味着当一个客户端向服务器端发出请求，然后Web服务器返回响应”*”(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP遵 循请求(Request)/应答(Response)模型。客户端（Web浏览器）向Web服务器发送请求，Web服务器处理请求并返回适当的应答。所有HTTP连 接都被构造成一套请求和应答。在该过程中要经过4个阶段，包括建立连接、发送请求信息、发送响应信息和关闭连接，如下图所示:
面详细介绍上图中描述的HTTP工作流程，如下:
1. 客户端通过TCP三次握手与服务器建立连接。
2. TCP建立连接成功后，向服务器发送HTTP请求。
3. 服务器接收客户端的HTTP请求后，将返回应答，并向客户端发送数据
4. 客户端通过TCP四次断开，与服务器断开TCP连接。
4. 持久性连接与非持久性连接
浏览器与web服务器建立TCP连接后，双方就可以通过发送请求信息和应答信息进行数据传输。在HTTP协议中，规定TCP链接既可以是持久的，也可以是非持久的。具体采用哪种链接方式，可以由通用头域中的Connection指定。在HTTP/1.0版本中，默认使用的是非持久性连接，在HTTP/1.1版本中，默认使用的是持久性连接。
非持久连接
非持久性连接就是每个TCP连接只用于传输一个请求消息和一个响应消息。用户每请求一次Web页面，就产生一个TCP连接。为了更详细的了解非持久连接，下面简单介绍一个例子。
假设在非持久连接的情况下服务器向客户端传送一个web页面。假设该贝面由1个基本HTML文件和10个JPEG图像构成，而且所有这些对象都存放在同一台服务器主机中。 再假设该基本HTML文件的URL为鎴戠殑绉佷汉灏忕珯，则传输步骤如下所示：
（1）HTTP客户段首先与主机www.example.cn中的Web服务器建立TCP连接。Web服务器使用默认端口号80监听来自HTTP客户的连接建立请求。
（2）HTTP客户段通过TCP连接向服务器发送—个HTTP请求消息。这个消息中包含路径名/somepath/index.html。
（3）Web服务器通过TCP连接接收这个请求消息后，从服务器主机的内存或硬盘中取出对象/somepath/index.html，经由同一个套接字发出包含该对象的响应消息。
（4）Web服务器告知本机的TCP协议栈关闭这个TCP连接。但是TCP协议栈要到客户端收到刚才这个应答消息之后，才会真正终止这个链接。
（5）HTTP客户经由同一个套接字接收这个响应消息。TCP连接随后终止。
（6）该消息标明所封装的对象是一个HTML文件。客户从中取出这个文件，加以分析后发现其中有10个JPEG对象的引用。
（7）这时候客户端在重复步骤（1）~（5），从服务器得到所引用的每一个JPEG对象。
上述步骤之所以称为使用非持久连接，原因是每次服务器发出一个对象后，相应的TCP连接就被关闭，也就是说每个连接都没有持续到可用于传送其他 对象。每个TCP连接只用于传输一个请求消息和一个响应消息。就上述例子而言，用户每请求一次那个web页面，就产生一个TCP连接。
实际上，客户端还可以通过并行的TCP连接同时取得其中的某些JPEG对象。这样可以大大提高数据传输速度，缩短响应时间。目前的浏览器允许用户通过配置来控制并行连接的数目，大多浏览器默认可以打开5-10个并行的TCP连接，每个连接处理一个请求/应答事务。
根据以上例子的描述，可以发现非持久连接具有如下几个缺点。
首先，客户得为每个待请求的对象建立并维护一个新的连接。对于每个这样的连接，TCP得在客户端和服务器端分配 TCP缓冲区，并维持TCP变量。对于有可能同时为来自数百个不同客户的请求提供服务的web服务器来说，这会严重增加其负担。
其次，每个对象 都有2个RTT（Round-Trip Time，往返时延）的响应延长。一个RTT用于建立TCP连接，另—个RTT用于请求和接收对象。最后，每个对象都要经过TCP缓启动，因为每个TCP连接都 起始于缓启动阶段。不过并行TCP连接的使用能够部分减轻RTT延迟和缓启动延迟的影响。
持久连接
持久连接是指服务器在发出响应后让TCP连接继续打开着。同一对客户/服务器之间的后续请求和响应可以 通过这个连接发送。整个Web页面(上例中为包含一个基本HTMLL文件和10个图像的页面)自不用说可以通过单个持久TCP连接发送:甚至存放在同一个 服务器中的多个web页面也可以通过单个持久TCP连接发送。
通常，HTTP服务器在某个连接闲置一段特定时间后关闭它，而这段时间通常是可以配置的。持 久连接分为不带流水线(without pipelining)和带流水线(with pipelining)两个版本。如果是不带流水线的版本，那么客户只在收到前一个请求的响应后才发出新的请求。这种情况下，web页面所引用的每个对象 (上例中的10个图像)都经历1个RTT的延迟，用于请求和接收该对象。与非持久连接2个RTT的延迟相比，不带流水线的持久连接已有所改善，不过带流水 线的持久连接还能进一步降低响应延迟。不带流水线版本的另一个缺点是，服务器送出一个对象后开始等待下一个请求，而这个新请求却不能马上到达。这段时间服 务器资源便闲置了。
HTTP/1.1的默认模式使用带流水线的持久连接。这种情况下，HTTP客户每碰到一个引用就立即发出一个请求，因而HTTP客户可以一个接一个 紧挨着发出各个引用对象的请求。服务器收到这些请求后，也可以一个接一个紧挨着发出各个对象。与非流水线模式相比，流水线模式的效率要高得多。
分析HTTP数据包
HTTP报文格式
HTTP由请求和响应两部分组成，所以对应的也有两种报文格式。下面分别介绍HTTP请求报文格式和HTTP响应报文格式。
HTTP请求报文格式
以上表格中，第1行为“请求行”，第2、3、4行为“请求头部”，第5行为空行，第6行为“请求正文”。下面分别介绍这4部分
（1）请求行：由3部分组成，分别为：请求方法、URL（见备注1）以及协议版本，之间由空格分隔，请求方法包括GET、POST等。协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1。
（2）请求头部包含很多客户端环境以及请求正文的有用信息。请求头部由“关键字：值”对组成，每行一堆，关键字和值之间使用英文“：”分隔。
（3）空行，这一行非常重要，必不可少。表示请求头部结束，下面就是请求正文。
（4）请求正文：可选部分，比如GET请求就没有请求正文；POST比如以提交表单数据方式为请求正文。
HTTP响应报文格式
以上表格中，第1行为“状态行”，第2、3、4行为“响应头部”，第5行为空行，第6行为“响应正文”。下面分别介绍这4部分：
（1）状态行由由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔。状态代码为3位数字，200~299的状态码表示成功，300~399的状态码指资源重定向，400~499的状态码指客户端请求出错，500~599的状态码指服务端出错（HTTP/1.1向协议中引入了信息性状态码，范围为100~199）。这里列举几个常见的：
（2）响应头部与请求头部类似，也包含了很多有用的信息。
（3）空行，这一行非常重要，必不可少。表示响应头部结束
（4）响应正文，服务器返回的文档，最常见的为HTML网页。
HTTP的头域
在HTTP的请求消息和应答消息中，都包含头域。头域分为4种，其中请求头域和应答头域分别只在请求消息和应答消息中出现，通用头域和实体头域在两种消息中都可以出现，但实体头域只有当消息中包含了实体数据时才会出现。下面分别介绍这4种头域中的域名城和功能。
HTTP请求头域
应答头域只在应答消息中出现，是Web服务器向浏览器提供的一些状态和要求。如下
HTTP 应答头域
通用头域既可以用在请求消息中，也可以用在应答消息。
HTTP通用头域
只有在请求和应答消息中包含实体数据时，才需要实体头域。请求消息中的实体数据是一些由浏览器向web服务器提交的数据，如在浏览器中采用POST方式提交表单时，浏览器就要把表单中的数据封装在请求消息的实体数据部分。应答消息中的实体数据是web服务器发给浏览器的媒体数据，如网页，图片和文档等。实体头域说明了实体数据的一些属性。如下图
HTTP实体头域
分析GET方法的HTTP数据包
我们以HTTP-Get数据包为例，分析GET方法的HTTP请求和响应数据包。
分析HTTP请求包
我们打开数据包，输入过滤条件ip.addr == 10.1.1.33,如下
前三个是TCP的三次握手，第四个数据包则是客户端向服务器发送的HTTP请求包，我们来学习分析下
HTTP之前的协议，本次我们不做讲解，不懂的同学可以看之前的实验，我们来看下HTTP协议。
Hypertext Transfer Protocol
GET / HTTP/1.1rn #请求行信息
Expert Info (Chat/Sequence): GET / HTTP/1.1rn #专家信息
GET / HTTP/1.1rn
Severity level: Chat
Group: Sequence
Request Method: GET #请求方法为GET
Request URI: / #请求的URI
Request Version: HTTP/1.1 #请求的版本为HTTP/1.1
Host: 10.1.1.33:8080rn #请求的主机
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0rn #浏览器类型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8rn #请求的类型
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3rn #请求语言
Accept-Encoding: gzip, deflatern #请求的编码格式
Connection: keep-alivern #使用持久连接
rn #空行
Full request URI: http://10.1.1.33:8080/ #请求的URI为10.1.1.33:8080
HTTP request 1/8
Response in frame: 2770 #应答是第2770帧
Next request in frame: 2775 #下一个请求是第2775帧
以上就是HTTP请求包的相关信息，可以看到客户端使用HTTP/1.1版本向服务器发送了GEY请求，请求访问10.1.1.33的服务器。将以上信息填入到报文格式中，如下
分析HTTP响应包
根据请求包的信息，我们已经知道，响应包是第2770帧，下面我们来看下
在HTTP之前，我们看到了下图显示的，TCP重组片段，这些片段共有2270个字节，由于超过了TCP数据包的最大数据分段（MSS），所以将数据在TCP层进行了分段。从下面的信息，可以看到分断后的数据包及包大小，如#2767（247），其中2767表示帧号，大小为247个字节。
下面来看HTTP的具体部分
Hypertext Transfer Protocol
HTTP/1.1 200 OKrn #响应行信息
Expert Info (Chat/Sequence): HTTP/1.1 200 OKrn #专家信息
HTTP/1.1 200 OKrn #HTTP响应信息，响应码为200
Severity level: Chat
Group: Sequence
Request Version: HTTP/1.1 #请求吧
Status Code: 200 #状态码
Response Phrase: OK #响应短语
Content-Type: text/htmlrn #响应的内容类型
Content-Length: 2023rn #包的长度
Content length: 2023
Accept-Ranges: bytesrn #服务器支持的请求：字节
Server: HFS 2.3 betarn #服务器类型
Set-Cookie: HFS_SID=0.248448607278988; path=/; rn #设置Http Cookie
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1rn #缓存控制
Content-Encoding: gziprn #实体数据的压缩格式
rn #空行
HTTP response 1/8 #HTTP响应
Time since request: 0.015248000 seconds #响应使用的时间
Request in frame: 2763 #请求的帧号为2763
Next request in frame: 2775 #下一个请求的帧号2775
Next response in frame: 2778 #下一个响应的帧号是2778
Content-encoded entity body (gzip): 2023 bytes -> 4375 bytes #内容编码（gzip）
Line-based text data: text/html #基于行的文本数据
根据以上信息，可以知道服务器使用HTTP/1.1 200 OK响应了客户端的请求。将信息填入到报文格式中，如下
分析POST方法的HTTP数据包
分析HTTP请求包
下面我们以HTTP-Post为例，分析POST方法的HTTP请求和响应。打开数据包，输入过滤条件ip.addr ==10.1.1.33,显示出的HTTP中，Info列中还有POST的即可，如下
我们展开分析下
Hypertext Transfer Protocol #HTTP协议
POST /hfs2_3b287/ HTTP/1.1rn #请求行
Expert Info (Chat/Sequence): POST /hfs2_3b287/ HTTP/1.1rn #专家信息
POST /hfs2_3b287/ HTTP/1.1rn
Severity level: Chat
Group: Sequence
Request Method: POST #请求方法为POST
Request URI: /hfs2_3b287/ # 请求的URI
Request Version: HTTP/1.1 #请求的版本
Host: 10.1.1.33:8080rn #使用的主机
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0rn #使用的浏览器类型
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8rn #浏览器接受的类型
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3rn #希望使用的语言
Accept-Encoding: gzip, deflatern #可使用的编码格式，这里是gzip和deflate
Referer: http://10.1.1.33:8080/hfs2_3b287/rn #从包含的URL页面发起请求
Cookie: HFS_SID=0.248448607278988rn #Cookie信息
Cookie pair: HFS_SID=0.248448607278988
Authorization: Basic ZGVtbzpkZW1vrn #授权证书信息
Credentials: demo:demo #登录的用户名密码
Connection: keep-alivern #使用持久连接
Content-Type:multipart/form-data;boundary=---------------------------54542580413055rn #请求的内容类型
Content-Length: 367rn #包的长度
Content length: 367
rn #空行
Full request URI: http://10.1.1.33:8080/hfs2_3b287/ #请求的URI为http://10.1.1.33:8080/hfs2_3b287/
HTTP request 1/6
Response in frame: 3800 #响应的帧号
Next request in frame: 3802 #下一个请求的正好
以上就是使用POST方法的HTTP请求包，可以看到请求的连接及登录的用户名密码等。将上面的信息填入到报文格式中，如下
另外，我们在HTTP的下面，看到了如下的内容
类型的Multipart/form-data是上传文件的一种方式。Multipart/form-data其实就是浏览器用表单上传文件的方式。最常见的情境是：在写邮件时，向邮件后添加附件，附件通常使用表单添加，也就是用multipart/form-data格式上传到服务器。我们实验中向服务器上传了一个文件，所以就是此类型。
在看Wireshark中的使用
首先看：
wireshark中字段与Multipart/form-data的对应关系： MIME Multipart Media Encapsulation：代表整个Multipart/form-data上传文件中的数据。
Encapsulated multipart part：代表表单中不同部分的数据。
Boundary：用来隔开表单中不同部分的数据。
其次：
1) MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------54542580413055"
这行指出这个请求是multipart/form-data格式的，且boundary是“----------54542580413055”这个字符串。
2）关于Boundary： Boundary：用来隔开表单中不同部分的数据。实际上，每部分数据的开头都是由“--”+boundary开始的（这是MIME标准中讲述的标准内容）。
3） Encapsulated multipart part：紧跟着boundary的是该部分数据的描述：Content-Dispostion:form-data;name="Filename"rn
每一个part至少一个name和一个content部分。
可以从上面的multipart/form-data中，看到我们上传的文本名字为http-post.txt，内容为“This is demo for HTTP POST”。
分析HTTP响应包
根据Wireshark现实的响应包帧数，我们来看下第3800帧。
Hypertext Transfer Protocol #HTTP协议
HTTP/1.1 200 OKrn #响应行
Expert Info (Chat/Sequence): HTTP/1.1 200 OKrn #专家信息
HTTP/1.1 200 OKrn #响应信息
Severity level: Chat
Group: Sequence
Request Version: HTTP/1.1 #请求版本
Status Code: 200 #状态码
Response Phrase: OK #响应短语
Content-Type: text/htmlrn # #响应包类似
Content-Length: 570rn #响应包长度
Content length: 570
Accept-Ranges: bytesrn #服务器支持的请求：字节
Server: HFS 2.3 betarn #web服务器类型
Content-Encoding: gziprn #实体数据的压缩格式
rn #空行
HTTP response 1/6 #响应
Time since request: 0.008774000 seconds #响应请求的时间
Request in frame: 3798 #请求的帧号
Next request in frame: 3802 #下一个请求的帧号
Next response in frame: 3804 #下一个响应的帧号
Content-encoded entity body (gzip): 570 bytes -> 866 bytes #内容编码（gzip）
Line-based text data: text/html #文本内容
以上就是POST方法的HTTP响应包，可以看到服务器向客户端发送了HTTP/1.1 200 OK响应了HTTP请求包。服务器类型为HFS 2.3 beta，将数据填入到报文格式中。
标签：HTTP,请求,TCP,学习,响应,手记,服务器,连接,wireshark 来源： https://blog.csdn.net/qq_35683407/article/details/120696389
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。