这个过程包括 TCP 三次握手 、HTTP 请求/响应 和 TCP 四次挥手。
我们使用以下命令来捕获与 httpbin.org 网站进行的一次简单 HTTP 交互：
sudo tcpdump -i any -n -s0 host httpbin.org
然后，在另一个终端使用 curl 发送一个请求：
以下是捕获到的数据包序列的详细解读。为了清晰起见，我对输出进行了精简和注释，并模拟了完整的流程。
完整的 HTTP 请求 tcpdump 输出样例与解读
阶段一：TCP 三次握手 (Establishing the Connection)
客户端（192.168.1.100）需要先与服务器（54.xxx.xxx.xxx）建立可靠的 TCP 连接。
1. Client -\> Server SYN Packet
13:37:01.123456 IP 192.168.1.100.58234 > 54.xxx.xxx.xxx.80: Flags S, seq 3920617153, win 64240, options mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7, length 0
- 解读 ：客户端发送一个
SYN(S) 包到服务器的 80 端口。seq是一个随机生成的初始序列号（ISN）。这是在说："你好，我想建立连接，我的初始序列号是 3920617153。"
2. Server -\> Client SYN-ACK Packet
13:37:01.234567 IP 54.xxx.xxx.xxx.80 > 192.168.1.100.58234: Flags S., seq 1982746241, ack 3920617154, win 65535, options mss 1440,sackOK,TS val 200 ecr 100,nop,wscale 9, length 0
- 解读 ：服务器回应一个
SYN-ACK(S.) 包。它确认了客户端的 SYN（ack 3920617154，即客户端的 ISN + 1），同时也发送了自己的 SYN 和初始序列号 (seq 1982746241)。这是在说："收到你的请求了，我同意建立连接，我的初始序列号是 1982746241。"
3. Client -\> Server ACK Packet
13:37:01.345678 IP 192.168.1.100.58234 > 54.xxx.xxx.xxx.80: Flags ., ack 1982746242, win 502, options nop,nop,TS val 101 ecr 200, length 0
- 解读 ：客户端发送一个
ACK(.) 包，确认服务器的 SYN（ack 1982746242，即服务器的 ISN + 1）。至此，TCP 三次握手完成，连接建立。 这是在说："收到你的同意了，连接已建立，我们可以开始传输数据了。"
阶段二：HTTP 请求与响应 (Data Transfer)
连接建立后，客户端开始发送 HTTP 请求。
4. Client -\> Server HTTP GET Request (PSH-ACK)
13:37:01.456789 IP 192.168.1.100.58234 > 54.xxx.xxx.xxx.80: Flags P., seq 3920617154:3920617251, ack 1982746242, win 502, options nop,nop,TS val 102 ecr 200, length 97
- 解读 ：客户端发送一个
PSH-ACK(P.) 包。PSH标志表示数据需要被立刻推送给应用层（HTTP服务器）。length 97表明这个包携带了 97 字节的应用层数据（即我们的 HTTP 请求）。-
HTTP数据内容 （可使用
tcpdump -A查看）：GET /get HTTP/1.1
Host: httpbin.org
User-Agent: curl/8.8.0
Accept: /
-
5. Server -\> Client ACK for the Request
13:37:01.567890 IP 54.xxx.xxx.xxx.80 > 192.168.1.100.58234: Flags ., ack 3920617251, win 1440, options nop,nop,TS val 201 ecr 102, length 0
- 解读 ：服务器发送一个
ACK(.) 包，确认已收到客户端的完整 HTTP 请求（ack 3920617251是客户端下一个期待的序列号）。
6. Server -\> Client HTTP Response (PSH-ACK)
13:37:01.678901 IP 54.xxx.xxx.xxx.80 > 192.168.1.100.58234: Flags P., seq 1982746242:1982746685, ack 3920617251, win 1440, options nop,nop,TS val 202 ecr 102, length 443
- 解读 ：服务器处理请求后，发回 HTTP 响应。同样使用了
PSH-ACK标志，length 443表示这个响应数据包有 443 字节。-
HTTP数据内容 （可使用
tcpdump -A查看）：HTTP/1.1 200 OK
Date: Tue, 25 Jan 2026 13:37:01 GMT
Content-Type: application/json
... (其他头部)
{
"args": {},
"headers": {
"Accept": "/ ",
"Host": "httpbin.org",
"User-Agent": "curl/8.8.0"
},
"url": "http://httpbin.org/get"
}
-
7. Client -\> Server ACK for the Response
13:37:01.789012 IP 192.168.1.100.58234 > 54.xxx.xxx.xxx.80: Flags ., ack 1982746685, win 501, options nop,nop,TS val 103 ecr 202, length 0
- 解读 ：客户端发送一个
ACK(.) 包，确认已收到服务器的 HTTP 响应。
阶段三：TCP 四次挥手 (Terminating the Connection)
数据交换完成后，连接被关闭。curl 默认使用 HTTP/1.1，通常会发起 Connection: close。
8. Client -\> Server FIN-ACK Packet
13:37:01.890123 IP 192.168.1.100.58234 > 54.xxx.xxx.xxx.80: Flags F., seq 3920617251, ack 1982746685, win 501, options nop,nop,TS val 104 ecr 202, length 0
- 解读 ：客户端发送一个
FIN-ACK(F.) 包，表示它已经完成了数据发送，希望关闭连接。
9. Server -\> Client ACK for the FIN
13:37:02.001234 IP 54.xxx.xxx.xxx.80 > 192.168.1.100.58234: Flags ., ack 3920617252, win 1440, options nop,nop,TS val 203 ecr 104, length 0
- 解读：服务器确认客户端的 FIN 包。
10. Server -\> Client FIN-ACK Packet
13:37:02.112345 IP 54.xxx.xxx.xxx.80 > 192.168.1.100.58234: Flags F., seq 1982746685, ack 3920617252, win 1440, options nop,nop,TS val 204 ecr 104, length 0
- 解读 ：服务器也发送一个
FIN-ACK包，表示它也准备关闭连接。
11. Client -\> Server Final ACK
13:37:02.223456 IP 192.168.1.100.58234 > 54.xxx.xxx.xxx.80: Flags ., ack 1982746686, win 501, options nop,nop,TS val 105 ecr 204, length 0
- 解读 ：客户端发送最后一个
ACK包，确认服务器的 FIN 包。至此，TCP 连接完全关闭。
总结
这个流程完美展示了一个完整 HTTP 事务的底层 TCP/IP 通信过程：
- 连接建立：3个包 (SYN -> SYN-ACK -> ACK)
- 数据传输：4个包 (HTTP请求 -> ACK -> HTTP响应 -> ACK)
- 连接终止：4个包 (FIN -> ACK -> FIN -> ACK)
总包数：11个
在实际捕获中，你可能会看到更多 ACK 包，因为 TCP 会持续确认收到的数据，或者数据包被分片传输。但这个样例清晰地展示了核心的、最精简的流程。