tcpdump抓包-路小飞

抓包

tcpdump -i any -nn -A port 30540
-i any：指定监听的网卡
-nn：禁用域名和端口号解析
-A：以 ASCII 格式显示应用层数据（明文可读）
port 30540：过滤条件（仅抓指定端口的流量）
-w：写入文件供wireshark等工具分析	
# tcpdump -i any -nn -A port 30540 -w nginx_capture.pcap

抓包结果

数据格式：
时间戳 + 协议 + 源IP.源端口 > 目的IP.目的端口: 标志位 + 序号 + 窗口大小 + 选项 + 数据长度

00:27:39.482642 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [S], seq 2403663700, win 29200, options [mss 1460,sackOK,TS val 8417984 ecr 0,nop,wscale 10], length 0
E..<..@.@......n...x..wL.D.T......r.)..........
..r........

00:27:39.482836 IP 192.168.17.120.30540 > 192.168.17.110.36540: Flags [S.], seq 2940746722, ack 2403663701, win 28560, options [mss 1440,sackOK,TS val 8412010 ecr 8417984,nop,wscale 10], length 0
E..<..@.?......x...nwL...H;..D.U..o..e.........
..[j..r....

00:27:39.483748 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [.], ack 1, win 29, options [nop,nop,TS val 8417985 ecr 8412010], length 0
E..4..@.@......n...x..wL.D.U.H;......n.....
..r...[j

00:27:39.483771 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [P.], seq 1:85, ack 1, win 29, options [nop,nop,TS val 8417985 ecr 8412010], length 84
E.....@.@......n...x..wL.D.U.H;.....a......
..r...[jGET / HTTP/1.1
User-Agent: curl/7.29.0
Host: 192.168.17.120:30540
Accept: */*


00:27:39.483871 IP 192.168.17.120.30540 > 192.168.17.110.36540: Flags [.], ack 85, win 28, options [nop,nop,TS val 8412011 ecr 8417985], length 0
E..4`.@.?.7....x...nwL...H;..D.......].....
..[k..r.
00:27:39.484398 IP 192.168.17.120.30540 > 192.168.17.110.36540: Flags [P.], seq 1:235, ack 85, win 28, options [nop,nop,TS val 8412012 ecr 8417985], length 234
E...`.@.?.6....x...nwL...H;..D.......G.....
..[l..r.HTTP/1.1 200 OK
Server: nginx/1.13.3
Date: Sun, 09 Nov 2025 16:27:39 GMT
Content-Type: text/html
Content-Length: 4
Last-Modified: Sun, 09 Nov 2025 16:14:17 GMT
Connection: keep-alive
ETag: "6910bdd9-4"
Accept-Ranges: bytes


00:27:39.484522 IP 192.168.17.120.30540 > 192.168.17.110.36540: Flags [P.], seq 235:239, ack 85, win 28, options [nop,nop,TS val 8412012 ecr 8417985], length 4
E..8`.@.?.6....x...nwL...H<..D.......a.....
..[l..r.lxf

00:27:39.485092 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [.], ack 235, win 30, options [nop,nop,TS val 8417987 ecr 8412012], length 0
E..4..@.@......n...x..wL.D...H<......+.....
..r...[l
00:27:39.485114 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [.], ack 239, win 30, options [nop,nop,TS val 8417987 ecr 8412012], length 0
E..4..@.@......n...x..wL.D...H<......'.....
..r...[l
00:27:39.485484 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [F.], seq 85, ack 239, win 30, options [nop,nop,TS val 8417987 ecr 8412012], length 0
E..4..@.@......n...x..wL.D...H<......&.....
..r...[l
00:27:39.485879 IP 192.168.17.120.30540 > 192.168.17.110.36540: Flags [F.], seq 239, ack 86, win 28, options [nop,nop,TS val 8412013 ecr 8417987], length 0
E..4`.@.?.7....x...nwL...H<..D.......].....
..[m..r.
00:27:39.486190 IP 192.168.17.110.36540 > 192.168.17.120.30540: Flags [.], ack 240, win 30, options [nop,nop,TS val 8417988 ecr 8412013], length 0
E..4..@.@......n...x..wL.D...H<......#.....
..r...[m
...

我们逐帧解析这份12 帧完整抓包（从 TCP 三次握手到四次挥手全流程），结合 TCP 标志位、序列号、确认号 等核心字段，清晰拆解每一步的作用：

帧 1：客户端发送 SYN（三次握手第 1 步）

00:27:39.482642 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [S], seq 2403663700, win 29200, 
options [mss 1460,sackOK,TS val 8417984 ecr 0,nop,wscale 10], 
length 0

角色：客户端（192.168.17.110:36540）发起连接请求。
关键字段：
- Flags [S]：SYN 标志位，意为“请求建立连接”（同步序列号）。
- seq 2403663700：客户端初始序列号（随机生成，用于后续数据排序）。
- length 0：无数据，仅握手信号。
- 选项字段：协商最大报文段（MSS=1460）、支持 SACK 重传优化、时间戳（TS）等。
目的：告诉服务端“我想和你建立连接，我的初始序列号是 2403663700”。

帧 2：服务端回复 SYN+ACK（三次握手第 2 步）

00:27:39.482836 IP 192.168.17.120.30540 > 192.168.17.110.36540: 
Flags [S.], seq 2940746722, ack 2403663701, 
win 28560, 
options [mss 1440,sackOK,TS val 8412010 ecr 8417984,nop,wscale 10], 
length 0

角色：服务端（192.168.17.120:30540）响应连接请求。
关键字段：
- Flags [S.]：S（SYN，同意建立连接）+ .（ACK，确认收到客户端请求）。
- seq 2940746722：服务端的初始序列号（随机生成）。
- ack 2403663701：确认号 = 客户端 seq + 1（表示“已收到客户端第 1 帧的所有数据”）。
- 选项字段：服务端协商 MSS=1440（因网络环境可能与客户端不同），并回复客户端的时间戳（ecr=8417984）。
目的：告诉客户端“我同意连接，我的初始序列号是 2940746722，且已收到你的连接请求”。

帧 3：客户端回复 ACK（三次握手第 3 步）

00:27:39.483748 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [.], ack 1, win 29, 
options [nop,nop,TS val 8417985 ecr 8412010], 
length 0

角色：客户端确认收到服务端的同意，连接正式建立。
关键字段：
- Flags [.]：仅 ACK 标志位，意为“纯确认”。
- ack 1：确认号 = 服务端 seq（2940746722） + 1（简化显示为 1，实际是相对序列号）。
- win 29：窗口大小（告知服务端“我最多能接收 29*1024 字节数据”，用于流量控制）。
目的：告诉服务端“我已收到你的同意，连接可以开始用了”。
结果：三次握手完成，TCP 连接建立，可传输应用层数据。

帧 4：客户端发送 HTTP 请求（数据传输）

00:27:39.483771 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [P.], seq 1:85, ack 1, 
win 29, 
options [nop,nop,TS val 8417985 ecr 8412010], 
length 84

角色：客户端发送 HTTP GET 请求。
关键字段：
- Flags [P.]：P（PSH，推送数据，要求对方立即交给应用层） + .（ACK，确认之前的握手）。
- seq 1:85：发送的数据序列号范围（相对序列号，实际是 2403663701~2403663784），共 84 字节。
- 数据内容：GET / HTTP/1.1 及请求头（User-Agent、Host 等）。
目的：向服务端发送 HTTP 请求，获取根路径资源。

帧 5：服务端确认收到 HTTP 请求

00:27:39.483871 IP 192.168.17.120.30540 > 192.168.17.110.36540: 
Flags [.], ack 85, win 28, 
options [nop,nop,TS val 8412011 ecr 8417985], 
length 0

角色：服务端确认收到客户端的 HTTP 请求。
关键字段：
- Flags [.]：纯 ACK 帧。
- ack 85：确认号 = 客户端发送的最后序列号（84） + 1，表示“已收到 1~84 字节的 HTTP 请求”。
目的：告诉客户端“你的请求我收到了，不用重传”。

帧 6：服务端发送 HTTP 响应头（数据传输）

00:27:39.484398 IP 192.168.17.120.30540 > 192.168.17.110.36540: 
Flags [P.], seq 1:235, ack 85, 
win 28, 
options [nop,nop,TS val 8412012 ecr 8417985], 
length 234

角色：服务端（nginx）返回 HTTP 响应头。
关键字段：
- Flags [P.]：P（推送响应头） + .（ACK 确认客户端请求）。
- seq 1:235：服务端发送的数据范围（相对序列号），共 234 字节。
- 数据内容：HTTP/1.1 200 OK 及响应头（Server、Date、Content-Length 等），表示“请求成功，即将返回 4 字节正文”。
目的：告知客户端“请求已处理，响应头如下，正文随后发送”。

帧 7：服务端发送 HTTP 响应正文（数据传输）

00:27:39.484522 IP 192.168.17.120.30540 > 192.168.17.110.36540: 
Flags [P.], seq 235:239, ack 85, 
win 28, 
options [nop,nop,TS val 8412012 ecr 8417985], 
length 4

角色：服务端发送 HTTP 响应正文。
关键字段：
- Flags [P.]：推送 4 字节正文数据。
- seq 235:239：数据范围（承接帧 6 的序列号，共 4 字节）。
- 数据内容：lxf（实际业务数据，与 Content-Length:4 一致）。
目的：完成 HTTP 响应的完整传输（响应头 + 正文）。

帧 8：客户端确认收到响应头

00:27:39.485092 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [.], ack 235, win 30, 
options [nop,nop,TS val 8417987 ecr 8412012], 
length 0

角色：客户端确认收到服务端的响应头（帧 6 的 234 字节数据）。
关键字段：
- ack 235：确认号 = 服务端帧 6 的最后序列号（234） + 1，表示“已收到 1~234 字节的响应头”。
目的：告知服务端“响应头已收到，继续等正文”。

帧 9：客户端确认收到响应正文

00:27:39.485114 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [.], ack 239, win 30, 
options [nop,nop,TS val 8417987 ecr 8412012], 
length 0

角色：客户端确认收到服务端的响应正文（帧 7 的 4 字节数据）。
关键字段：
- ack 239：确认号 = 服务端帧 7 的最后序列号（238） + 1，表示“已收到 235~238 字节的响应正文”。
目的：告知服务端“完整的 HTTP 响应（头+正文）已收到，无需重传”。

帧 10：客户端发送 FIN（四次挥手第 1 步）

00:27:39.485484 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [F.], seq 85, ack 239, 
win 30, 
options [nop,nop,TS val 8417987 ecr 8412012], 
length 0

角色：客户端请求断开连接（数据已接收完毕）。
关键字段：
- Flags [F.]：F（FIN，终止连接） + .（ACK 确认服务端的响应）。
- seq 85：客户端最后发送的序列号（与帧 4 的 seq 1:85 对应，表示“我这边数据已发完”）。
目的：告诉服务端“我已收到所有数据，请求关闭连接”。

帧 11：服务端回复 FIN+ACK（四次挥手第 2 步）

00:27:39.485879 IP 192.168.17.120.30540 > 192.168.17.110.36540: 
Flags [F.], seq 239, ack 86, 
win 28, 
options [nop,nop,TS val 8412013 ecr 8417987], 
length 0

角色：服务端同意断开连接（自身数据也已发完）。
关键字段：
- Flags [F.]：F（FIN，服务端也准备断开） + .（ACK 确认客户端的断开请求）。
- ack 86：确认号 = 客户端 FIN 帧的 seq（85） + 1，表示“已收到你的断开请求”。
- seq 239：服务端最后发送的序列号（与帧 7 的 seq 235:239 对应，表示“我这边数据也发完了”）。
目的：告诉客户端“我收到你的断开请求，我这边也没数据了，同意关闭连接”。

帧 12：客户端回复 ACK（四次挥手第 3 步）

00:27:39.486190 IP 192.168.17.110.36540 > 192.168.17.120.30540: 
Flags [.], ack 240, win 30, 
options [nop,nop,TS val 8417988 ecr 8412013], 
length 0

角色：客户端确认服务端的断开请求，连接彻底关闭。
关键字段：
- Flags [.]：纯 ACK 帧。
- ack 240：确认号 = 服务端 FIN 帧的 seq（239） + 1，表示“已收到你的同意断开请求”。
目的：告诉服务端“我收到你的同意，连接可以彻底关闭了”。
结果：四次挥手完成，TCP 连接释放。

总结：完整流程逻辑

建立连接（帧 1-3）：三次握手确认双方序列号和连接参数，奠定可靠传输基础。
数据传输（帧 4-9）：客户端发请求 → 服务端回响应 → 双方互相确认数据接收，确保 HTTP 交互完整。
断开连接（帧 10-12）：四次挥手确保双方数据都已传输完毕，优雅释放资源。

每帧的标志位（S/F/P/.）和序列号、确认号严格对应，体现了 TCP “可靠、有序、双向”的核心特性。

TCP 标志位

TCP 协议最核心的标志位，下面用通俗的语言+实际场景拆解，让每个含义更易理解：

1. `S`（SYN，同步）：发起连接的“敲门信号”

核心含义：客户端向服务器发起 TCP 连接请求，相当于“敲门”，告知对方“我想和你建立连接”。
实际场景：你用 curl 访问 nginx 时，客户端（master01）会先发送 [S] 包（第一次握手），请求与服务器（node01:30540）建立连接。
关键特点：仅用于连接初始化，数据包中无业务数据（length 0）。

2. `.`（ACK，确认）：接收成功的“回执信号”

核心含义：收到对方的数据包后，返回“确认”，相当于“收到了”，告知对方“你的数据我已接收，可继续发送”。
实际场景：
- 服务器收到 [S] 包后，会回复 [S.] 包（SYN+ACK，第二次握手），既同意连接，又确认收到了客户端的“敲门”；
- 客户端收到 [S.] 后，再回复 [.] 包（第三次握手），连接正式建立。
关键特点：单独的 [.] 包通常无业务数据，仅用于确认；和其他标志组合（如 [P.]）时，既确认又传数据。

3. `P`（PSH，推送）：立即处理的“加急信号”

核心含义：推送应用层业务数据，并要求对方 立即处理，不要缓存等待其他数据包。
实际场景：
- 连接建立后，客户端发送 [P.] 包（带 ACK 确认），包含 HTTP 请求数据（如 GET / HTTP/1.1）；
- 服务器收到后，返回 [P.] 包，包含 nginx 欢迎页的 HTML 数据（业务数据）。
关键特点：数据包一定带业务数据（length > 0），是实际传输数据的核心标志。

4. `F`（FIN，结束）：主动断开的“关门信号”

核心含义：主动发起 TCP 连接断开请求，相当于“我这边数据传完了，要关门了”。
实际场景：你访问 nginx 后，客户端收到完整响应，会发送 [F.] 包（第一次挥手），告知服务器“我不需要再传数据了，可断开连接”；服务器回复确认后，连接正式关闭。
关键特点：仅用于连接终止，无业务数据；通常和 ACK 组合为 [F.]（断开+确认）。

补充：常见组合标志快速理解

[S.]（SYN+ACK）：同意连接+确认收到对方的连接请求（第二次握手）；
[P.]（PSH+ACK）：推送业务数据+确认收到对方之前的数据包（最常用的传数据标志）；
[F.]（FIN+ACK）：发起断开+确认收到对方数据。

简单总结：S 是“敲门”，. 是“回执”，P 是“传数据”，F 是“关门”，这四个标志构成了 TCP 连接从建立、传数据到断开的完整流程。

数据在网络中的传递

在计算机网络的分层模型中，数据帧（Frame）、数据包（Packet） 和数据段（Segment） 是不同层次对“数据单元”的称呼，核心区别在于所属的网络层次和功能，以下是详细对比：

对比项	数据帧（Frame）	数据包（Packet）	数据段（Segment）
所属层次	数据链路层（Layer 2）	网络层（Layer 3）	传输层（Layer 4）
核心功能	负责相邻设备间的物理传输，包含数据链路层头部（如 MAC 地址）和尾部（如 CRC 校验）	负责跨网段的路由转发，包含网络层头部（如 IP 地址）	负责端到端的可靠传输，包含传输层头部（如端口号、序列号、确认号）
典型协议	Ethernet、Wi-Fi（802.11）	IP（IPv4/IPv6）	TCP、UDP
封装关系	数据包 + 数据链路层头部/尾部 → 数据帧	数据段 + 网络层头部 → 数据包	应用层数据 + 传输层头部 → 数据段
示例场景	交换机转发以太网帧时，通过 MAC 地址识别目标设备	路由器转发 IP 数据包时，通过 IP 地址选择路由	TCP 传输 HTTP 数据时，通过端口号区分不同应用（如 80 端口对应 HTTP）

封装顺序：应用层数据 → 传输层封装为“数据段” → 网络层封装为“数据包” → 数据链路层封装为“数据帧” → 物理层以比特流发送。
拆包/重组：当数据过大时，网络层会将数据包拆分为“分片”（Fragment），数据链路层会将数据帧拆分为“分段”（Segment，此处为链路层分段，与传输层 Segment 含义不同）；接收端则按序重组，确保上层协议能拿到完整数据。

简单来说，三者是从下到上的分层封装产物，分别对应“链路层传输单元”“网络层路由单元”和“传输层端到端单元”。

抓包.png

目录CONTENT

tcpdump抓包

抓包

抓包结果

帧 1：客户端发送 SYN（三次握手第 1 步）

帧 2：服务端回复 SYN+ACK（三次握手第 2 步）

帧 3：客户端回复 ACK（三次握手第 3 步）

帧 4：客户端发送 HTTP 请求（数据传输）

帧 5：服务端确认收到 HTTP 请求

帧 6：服务端发送 HTTP 响应头（数据传输）

帧 7：服务端发送 HTTP 响应正文（数据传输）

帧 8：客户端确认收到响应头

帧 9：客户端确认收到响应正文

帧 10：客户端发送 FIN（四次挥手第 1 步）

帧 11：服务端回复 FIN+ACK（四次挥手第 2 步）

帧 12：客户端回复 ACK（四次挥手第 3 步）

总结：完整流程逻辑

TCP 标志位

1. `S`（SYN，同步）：发起连接的“敲门信号”

2. `.`（ACK，确认）：接收成功的“回执信号”

3. `P`（PSH，推送）：立即处理的“加急信号”

4. `F`（FIN，结束）：主动断开的“关门信号”

补充：常见组合标志快速理解

数据在网络中的传递

评论区

tcpdump抓包

抓包

抓包结果

帧 1：客户端发送 SYN（三次握手第 1 步）

帧 2：服务端回复 SYN+ACK（三次握手第 2 步）

帧 3：客户端回复 ACK（三次握手第 3 步）

帧 4：客户端发送 HTTP 请求（数据传输）

帧 5：服务端确认收到 HTTP 请求

帧 6：服务端发送 HTTP 响应头（数据传输）

帧 7：服务端发送 HTTP 响应正文（数据传输）

帧 8：客户端确认收到响应头

帧 9：客户端确认收到响应正文

帧 10：客户端发送 FIN（四次挥手第 1 步）

帧 11：服务端回复 FIN+ACK（四次挥手第 2 步）

帧 12：客户端回复 ACK（四次挥手第 3 步）

总结：完整流程逻辑

TCP 标志位

1. S（SYN，同步）：发起连接的“敲门信号”

2. .（ACK，确认）：接收成功的“回执信号”

3. P（PSH，推送）：立即处理的“加急信号”

4. F（FIN，结束）：主动断开的“关门信号”

补充：常见组合标志快速理解

数据在网络中的传递

评论区

1. `S`（SYN，同步）：发起连接的“敲门信号”

2. `.`（ACK，确认）：接收成功的“回执信号”

3. `P`（PSH，推送）：立即处理的“加急信号”

4. `F`（FIN，结束）：主动断开的“关门信号”