一）过滤出三次握手的第一次：
tcp.flags.syn == 1 //YN置1就表示这是一个连接请求或连接接受报文。首先由Client发出请求连接即 SYN=1 ACK=0 (请看头字段的介绍), TCP规定SYN=1时不能携带数据，但要消耗一个序号,因此声明自己的序号是 seq=0
二)跟踪一个IP和另一个IP的数据包：
(ip.addr eq 123.130.127.180 and ip.addr eq 172.20.156.35) and (tcp.port eq 80 and tcp.port eq 16616)
ip.addr == 123.130.127.180 and ip.addr == 172.20.156.35 //注意，一是两个等号，二是ip不用双引或单引号想起来，否则属于错误语句。
(ip.addr == 123.130.127.180 and ip.addr == 172.20.156.35) and (tcp.port == 80 and tcp.port == 16616)
ip.addr==123.130.127.180 and ip.addr==172.20.156.35
三）三次握手分析：
（1）frame也就是帧编号值并不是1，2，3可以是任意值。
（2）下图：
首先，由Client发出请求连接即 SYN=1 ACK=0 (请看头字段的介绍), TCP规定SYN=1时不能携带数据，但要消耗一个序号,因此声明自己的序号是 seq=0：
然后，Server 进行回复确认，即 SYN=1 ACK=1 seq=y=0, ack=x+1=0+1=1：
再然后 Client 再进行一次确认，但不用SYN 了，这时即为 ACK=1, seq=x+1=0+1=1, ack=y+1=0+1=1.
然后连接建立
ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1
SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。
FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
出现端口可能被中间设备代答，可以通过ttl值进行减少：
如80回包55,110端口回包是60，说明两个走的路径不一样：
可以的 — 在 Wireshark 里看 TTL（以及用它估算“过了几道设备”）很简单，步骤 + 说明如下：
在 Wireshark 里查看单包的 TTL
用 Wireshark 打开 pcap 文件（或直接抓包）。
在 Packet Details（中间窗格） 展开 Internet Protocol（IPv4）的条目，里面会有一项 Time to live: XX，XX 就是该包的 TTL。
对 IPv6 包，该字段叫 Hop Limit，在 Internet Protocol Version 6 下显示为 Hop Limit: YY（字段名 ipv6.hlim）。
把 TTL 显示到列表栏（便于查看/排序）
在中间窗格找到 Time to live 字段，右键 → “Apply as Column”（应用为列）。
这样在 Packet List（上方列表）就会出现一个 TTL 列，可以直接排序或统计。
用过滤器快速筛选
过滤某个具体 TTL：ip.ttl == 51
筛选 IPv6 的 Hop Limit：ipv6.hlim == 64
用 tshark/tcpdump 提取 TTL（命令行）
tshark -r file.pcap -T fields -e frame.number -e ip.src -e ip.dst -e ip.ttl
tcpdump -n -r file.pcap -v（-v 会输出更多信息，包含 TTL）
怎么把 TTL 换算成“过了几道设备”？
路由器/中间设备在转发 IPv4 包时会把 TTL 减 1（直到到 0 时丢弃并发回 ICMP TTL exceeded）。所以你看到的 TTL 是“剩余跳数”而不是“已过跳数”。
要估算已经经过的跳数，需要知道包发送方的初始 TTL（不同系统默认不同），常见初始值有：64（Linux/macOS/许多UNIX）, 128（Windows）, 255（部分网络设备/嵌入式设备）。
估算方法：已过跳数 = 初始TTL - 观测到的TTL（选择最接近且大于等于观测值的常见初始TTL）。
例：观测 TTL = 51。最可能的初始 TTL 是 64（因为 51 < 64 而且接近），则已过跳数 ≈ 64 - 51 = 13 跳。
如果观测 TTL = 200，那通常初始可能是 255，则已过跳数 ≈ 255 - 200 = 55 跳。
注意事项 / 限制
这是一个估算：发送端可能用了非典型初始 TTL（程序自定义），或中间设备可能对 TTL 做了特殊处理，所以不能 100% 确定具体经过了哪些设备。
若要精确查看路径（每一跃点），请用 traceroute / tracert（主动探测每跳），而不是仅靠被动抓到的单包 TTL。
IPv6 用 Hop Limit，计算方法同上（初始值通常 64、128 或 255，视系统而定）。
如果你需要，我可以给你一个 tshark/tcpdump 命令，把 pcap 中每个源 IP 的平均/最小/最大 TTL 列出来，或者直接把某个 pcap 的 TTL 列导出成表格 —— 需要我直接做的话把 pcap 发上来或告诉文件名。
tcp.flags.syn == 1 //YN置1就表示这是一个连接请求或连接接受报文。首先由Client发出请求连接即 SYN=1 ACK=0 (请看头字段的介绍), TCP规定SYN=1时不能携带数据，但要消耗一个序号,因此声明自己的序号是 seq=0
二)跟踪一个IP和另一个IP的数据包：
(ip.addr eq 123.130.127.180 and ip.addr eq 172.20.156.35) and (tcp.port eq 80 and tcp.port eq 16616)
ip.addr == 123.130.127.180 and ip.addr == 172.20.156.35 //注意，一是两个等号，二是ip不用双引或单引号想起来，否则属于错误语句。
(ip.addr == 123.130.127.180 and ip.addr == 172.20.156.35) and (tcp.port == 80 and tcp.port == 16616)
ip.addr==123.130.127.180 and ip.addr==172.20.156.35
三）三次握手分析：
（1）frame也就是帧编号值并不是1，2，3可以是任意值。
（2）下图：
首先，由Client发出请求连接即 SYN=1 ACK=0 (请看头字段的介绍), TCP规定SYN=1时不能携带数据，但要消耗一个序号,因此声明自己的序号是 seq=0：
然后，Server 进行回复确认，即 SYN=1 ACK=1 seq=y=0, ack=x+1=0+1=1：
再然后 Client 再进行一次确认，但不用SYN 了，这时即为 ACK=1, seq=x+1=0+1=1, ack=y+1=0+1=1.
然后连接建立
ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1
SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。
FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
出现端口可能被中间设备代答，可以通过ttl值进行减少：
如80回包55,110端口回包是60，说明两个走的路径不一样：
可以的 — 在 Wireshark 里看 TTL（以及用它估算“过了几道设备”）很简单，步骤 + 说明如下：
在 Wireshark 里查看单包的 TTL
用 Wireshark 打开 pcap 文件（或直接抓包）。
在 Packet Details（中间窗格） 展开 Internet Protocol（IPv4）的条目，里面会有一项 Time to live: XX，XX 就是该包的 TTL。
对 IPv6 包，该字段叫 Hop Limit，在 Internet Protocol Version 6 下显示为 Hop Limit: YY（字段名 ipv6.hlim）。
把 TTL 显示到列表栏（便于查看/排序）
在中间窗格找到 Time to live 字段，右键 → “Apply as Column”（应用为列）。
这样在 Packet List（上方列表）就会出现一个 TTL 列，可以直接排序或统计。
用过滤器快速筛选
过滤某个具体 TTL：ip.ttl == 51
筛选 IPv6 的 Hop Limit：ipv6.hlim == 64
用 tshark/tcpdump 提取 TTL（命令行）
tshark -r file.pcap -T fields -e frame.number -e ip.src -e ip.dst -e ip.ttl
tcpdump -n -r file.pcap -v（-v 会输出更多信息，包含 TTL）
怎么把 TTL 换算成“过了几道设备”？
路由器/中间设备在转发 IPv4 包时会把 TTL 减 1（直到到 0 时丢弃并发回 ICMP TTL exceeded）。所以你看到的 TTL 是“剩余跳数”而不是“已过跳数”。
要估算已经经过的跳数，需要知道包发送方的初始 TTL（不同系统默认不同），常见初始值有：64（Linux/macOS/许多UNIX）, 128（Windows）, 255（部分网络设备/嵌入式设备）。
估算方法：已过跳数 = 初始TTL - 观测到的TTL（选择最接近且大于等于观测值的常见初始TTL）。
例：观测 TTL = 51。最可能的初始 TTL 是 64（因为 51 < 64 而且接近），则已过跳数 ≈ 64 - 51 = 13 跳。
如果观测 TTL = 200，那通常初始可能是 255，则已过跳数 ≈ 255 - 200 = 55 跳。
注意事项 / 限制
这是一个估算：发送端可能用了非典型初始 TTL（程序自定义），或中间设备可能对 TTL 做了特殊处理，所以不能 100% 确定具体经过了哪些设备。
若要精确查看路径（每一跃点），请用 traceroute / tracert（主动探测每跳），而不是仅靠被动抓到的单包 TTL。
IPv6 用 Hop Limit，计算方法同上（初始值通常 64、128 或 255，视系统而定）。
如果你需要，我可以给你一个 tshark/tcpdump 命令，把 pcap 中每个源 IP 的平均/最小/最大 TTL 列出来，或者直接把某个 pcap 的 TTL 列导出成表格 —— 需要我直接做的话把 pcap 发上来或告诉文件名。
作者：jackx@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://www.jackxiang.com/post/8908/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackx 编辑于2025-10-28 16:06
Linux下/var/log/btmp文件 
使用redis-trib.rb-官方推出的管理redis集群的工具。评论列表
