本文已参与「新人创造礼」活动，一同敞开创造之路。

前语

在网络数据包剖析中，如何选取捕获点，是一个很基础也很重要的作业。通用的方法论中捕获点或许会包含客户端、服务端和中心端，一起依据中心端设备才能的不同，像是否具有直接抓包的才能，或许又会分为多个捕获点，譬如某个设备的前后。这样在多点捕获数据包的成果下，再进行必定的处理过滤，进而剖析定位故障原因。

但许多真实的事务场景是无法取得这么多数据包信息的，或许仅有客户端或服务端的数据包、或许仅有中心端的数据包等，那么它们详细有什么不同嘛？或许说当你拿到一个数据包文件时，是否能判别出它的捕获点，是客户端、服务端仍是中心端？

对我来说，捕获点一直是一个很深奥的论题 ，尽管或许最终的剖析成果指向是一样，可是数据包在不同的捕获点所展现出来的现象有时是彻底不一样的。

本文仅从个人视点，简略概括不同捕获点下的 TCP 三次握手数据包的相关内容。

TCP 三次握手

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

TCP 三次握手简图如上，主要从几个方面论述：

  1. IRTT 篇
  2. Length 篇
  3. TTL 篇
  4. Offload 篇
  5. 其他篇

TCP 三次握手的数据包剖析所涉及到知识点许多，所选取的 IRTT、Length、TTL、Offload 几个方面，主要是和捕获点关联可打开剖析的较多。

IRTT 篇

什么是 IRTT ? Wireshark 中所界说的 IRTT 是 TCP 三次握手中的初始化 RTT ，对应的显现过滤字段和意义如下

tcp.analysis.initial_rtt
How long it took for the SYN to ACK handshake(iRTT)

示例

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

IRTT 值为 [iRTT: 0.001654000 seconds] ，即 TCP 三次握手中第三个包 ACK 与第一个包 SYN 之间的时刻差值。

关于客户端、服务端和中心端等不同捕获点，上述其实是一个核算 IRTT 的通用方法。

那么对应于客户端、服务端和中心端三个不同捕获点，每一个值或差值又有什么实际差异呢？

客户端

当在客户端上捕获数据包时，从客户端宣布 SYN , 通过中心网络设备传输至服务器，再由服务器处理宣布 SYN/ACK 到客户端收到，此刻 SYN/ACK 与 SYN 之间的时刻差值为 a 。客户端之后再回来承认 ACK，此刻 ACK 与 SYN/ACK 之间的时刻差值为 b 。

综合考虑各端协议栈的处理才能和时延、网络传达时延和传输时延等等，正常状况下联系式应该是 a > b 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

所以说在客户端抓包的状况下，SYN-SYN/ACK 之间时刻差值高于 SYN/ACK-ACK 时刻差值 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

那么这种定论反过来说是否正确？在 SYN-SYN/ACK 之间时刻差值高于 SYN/ACK-ACK 时刻差值 的状况下，能否承认该数据包必定是在客户端上所抓取的？答案是否定的。 很显着的一种状况是在接近客户端的当地捕获数据包（本文把这种捕获点场景界说为是中心端，详见下文）。

服务端

当在服务端上捕获数据包时，从收到客户端的 SYN 开端，服务器处理回来 SYN/ACK，此刻 SYN/ACK 与 SYN 之间的时刻差值为 a ，再通过中心网络设备传输至客户端，客户端回复承认 ACK 至服务端收到，此刻 ACK 与 SYN/ACK 之间的时刻差值为 b 。

综合考虑各端协议栈的处理才能和时延、网络传达时延和传输时延等等，正常状况下联系式应该是 a < b 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

所以说在服务端抓包的状况下，SYN-SYN/ACK 之间时刻差值低于 SYN/ACK-ACK 时刻差值 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

相同，那么这种定论反过来说是否正确？在 SYN-SYN/ACK 之间时刻差值低于 SYN/ACK-ACK 时刻差值的状况下，能否承认该数据包必定是在服务端上所抓取的？答案也是否定的。 相同很显着的一种状况是在接近服务端的当地捕获数据包（本文把这种捕获点场景界说为是中心端，详见下文）。

中心端

当在中心端上捕获数据包时，从收到客户端的 SYN 开端，之后服务器处理回来 SYN/ACK ，再由中心端收到，此刻 SYN/ACK 与 SYN 之间的时刻差值为 a 。之后服务器 SYN/ACK 传输至客户端，客户端回复承认 ACK ，返至中心端收到，此刻 ACK 与 SYN/ACK 之间的时刻差值为 b 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

依据中心端选取的不同，a 与 b 值的联系式不定。如上文所说，假如是在接近客户端的中心端抓包，a > b ；假如是在接近服务端的中心端抓包，a < b ；假如刚好是在真的中心端， a ≈ b 也是有或许的。

小结

以上为正常状况下不同捕获点的 TCP 三次握手 IRTT 剖析，着重正常状况下，是考虑客户端、服务端操作体系协议栈处理极快的状况，假如客户端或服务端的负载、功用或其他原因，导致处理慢，这个只能依据实际场景详细再判别。

相同关于 a 和 b 值的比较，详细是大多少或是小多少，这个要依据客户端和服务端两者之间的间隔来判别。假如客户端和服务器在同一台接入交流机上进行通讯，在客户端或服务端所抓包显现的 a 和 b 的差值会很小，又假设是个低时延交流机使得中心网络时延极低，此刻 a 和 b 的联系就更不好说了，这个得从同一个捕获点多个数据包样例来剖析规则。假如客户端和服务器在广域网或互联网上进行通讯，在客户端或服务端所抓包显现的 a 和 b 的差值就会很大。

综合上述，汇总如下

捕获点 IRTT 差值联系 备注
客户端 SYN-SYN/ACK 之间时刻差值高于 SYN/ACK-ACK 时刻差值
中心端 SYN-SYN/ACK 之间时刻差值高于 SYN/ACK-ACK 时刻差值 接近客户端
SYN-SYN/ACK 之间时刻差值低于 SYN/ACK-ACK 时刻差值 接近服务端
SYN-SYN/ACK 之间时刻差值和 SYN/ACK-ACK 时刻差值联系不定 其他
服务端 SYN-SYN/ACK 之间时刻差值低于 SYN/ACK-ACK 时刻差值

Length 篇

什么是 Length ？Wireshark 中所界说的 Length 是指 Packet length 数据包或是分组长度（以字节为单位），对应的显现过滤字段和意义如下

frame.len
Frame length on the wire

最小长度

众所周知，以太网帧最小长度为 64 字节，而一般捕获到的数据包是不包含有 FCS ，所以数据包最小长度是 60 字节，其中数据字段最小长度便是 46 字节，也便是往常所说的 MTU 最小值 。

14 字节 ( Ethernet II 首部长度 ) + 46 字节 ( 数据字段最小长度要求 ) + 4 字节 ( FCS ) = 64 字节

那么关于一个规范的纯 ACK （不带数据）来说，它是多大呢？54 字节 ，显着小于数据包最小长度 60 字节的要求，

14 字节 ( Ethernet II 首部长度 ) + 20 字节 ( IPv4 首部长度 ) + 20 字节（TCP 首部长度） = 54 字节

因而在以太网传输中是需要填充全 0 数据，以满意最小长度 60 字节的要求。以下示例中 No.7 ACK 数据包填充了 6 字节的 0 值 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

可是为什么在上述示例中，仍能够看到 Length 长度为 54 字节 的数据包呢？No.3 （ TCP 三次握手的第三个包 ） 、No.6（含 FIN ） 和 No.9 等纯 ACK 。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

原因是 Wireshark 的抓包方法（或许说是原理）和方位，Wireshark 抓包方位假如是在本地，那么关于本地发生所宣布的数据包，是在进网卡之前所抓取的包，而填充数据以及 FCS 一般是由网卡硬件/驱动程序完结，所以 54 字节的组成并不包含填充数据。反过来说，60 字节的纯 ACK 是来自对方的数据包，包含了由对方网卡完结的填充数据，再由本端抓包时捕获到。

小结

所以说，调查 TCP 三次握手中的第三个包，也便是 ACK 的 Length ，假如是 54 字节的话，那么便是在 客户端 本地所抓取，而不是在 中心端 或是 服务端 所抓取。为什么能这样下界说？因为数据包从本地客户端传输出去后，在任意中心段捕获所看到的最小数据包长度都只会是 60 字节，相同 TCP 三次握手中的第三个包是由客户端所宣布的，在服务端捕获当然看到的也只会是 60 字节。

那么扩打开来，

  • 怎样判别是捕获点是服务端的状况？单独以 TCP 三次握手的数据包是无法判别的，只要结合后续数据包，调查服务端本地所宣布来的纯 ACK （或许其他数据包）是否 Length 小于 60 字节，辅佐判别得出定论。
  • 怎样判别是捕获点是中心端的状况？调查包含 TCP 三次握手在内的所有数据包，没有 Length 小于 60 字节的数据包的话，一般都是在中心端所捕获。

综合上述，汇总如下

捕获点 Frame Length 备注
客户端 TCP 三次握手中的第三个包以及其他纯 ACK 小于 60字节 带有时刻戳选项的状况在外
中心端 包含 TCP 三次握手在内的所有数据包，没有 Length 小于 60 字节 特殊状况，有剥离全0填充数据的
服务端 TCP 三次握手的数据包无法单独判别，需结合服务端宣布来的其他数据包，是否有 Length 小于 60 字节的

Length 中还有一种状况，是大于 MTU 的数据包长度，这和 Offload 特性相关，在后篇章节中概述。

TTL 篇

什么是 TTL ？ Wireshark 中所界说的 TTL 是指 IPv4 TTL 字段，对应的显现过滤字段和意义如下

ip.ttl
Time to Live,1byte

A timer field used to track the lifetime of the datagram. When the TTL field is decremented down to zero, the datagram is discarded.

尽管从 TTL 字面上解说，是能够存活的时刻，但实际上 TTL 是 IP 数据包在网络中能够转发的最大跳数。TTL 字段 由 IP 数据包的发送者设置，在 IP 数据包从源到意图的整个转发路径上，每通过一个路由设备，路由设备都会修改这个 TTL 字段值，详细的做法是把该 TTL 的值减 1，然后再将 IP 包转宣布去。假如在 IP 包到达意图 IP 之前，TTL 削减为 0，路由器将会丢掉收到的 TTL=0 的 IP 包并向 IP 包的发送者发送 ICMP time exceeded 音讯。

关于不同的操作体系，TTL值是不同的，扼要版本如下

设备/操作体系 TTL 备注
Linux 64/255
Windows 128

示例

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

考虑到 TTL 字段 由 IP 数据包的发送者设置，所以能够检查 TCP 三次握手数据包中的 TTL 值，假如非 64、128、255 等规范值，则能够初步判别为捕获点为中心端。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

那么反过来说，假如 TTL 值是 64、128、255 等规范值，是否能确定捕获点是在客户端或是服务端？答案是否定的。 因为假如端到端有相似二层交流机的设备，那么 TTL 值通过的时分是不会减 1 的，譬如在客户端或是服务端所在的接入交流机上抓包，TTL 值看到的值也会是 64、128、255 等规范值。因而这种景象下，需要结合实际环境，TTL 用以辅佐判别。

Offload 篇

关于网卡 Offload 特性，大多数操作体系都支撑多种形式的网络卸载，包含在 TCP/IP 协议栈中进行的 IP 分片、TCP 分段、重组、checksum 校验等操作，会转移到网卡硬件中进行，而不是 CPU 上，这样能够降低体系 CPU 的消耗，进步处理功用。

依据 Offload 功用的不同，在数据包捕获和剖析上体现在两方面，一是与数据包 Checksum 相关，二是与数据包 Length 相关（前文提及）。

实际本篇部分现已超出 TCP 三次握手的规模，像是 Length 涉及到详细传输中大段数据的内容，因也是捕获点的不同表现，所以简略总结下。

数据包 Checksum

CheckSum Offload 实际上便是是将 TCP/UDP/IP 校验和作业交给了网卡硬件完结，以节省体系的 CPU 资源。譬如：以太网发送网卡核算以太网 CRC32 校验和，接纳网卡验证这个校验和。假如接纳到的校验和过错，Wireshark 乃至不会看到数据包，因为以太网网卡会丢掉该数据包。

TCP/UDP/IP 校验和

  • TCP 校验和核算三部分：TCP 头部、TCP 数据和 TCP 伪头部。TCP 校验和是有必要的。
  • UDP 校验和核算三部分：UDP 头部、UDP 数据和 UDP 伪头部。UDP 校验和是可选的。
  • IP 校验和只核算查验 IP 数据报的首部，但不包含 IP 数据报中的数据部分。

TCP/IP 协议栈不会自己核算校验和，而是简略地将一个空的校验和字段(零或随机填充)交给网卡硬件。

那么在根据端到端数据包正常传输的状况下，Wireshark 抓包方位假如是在本地，那么关于本地发生所宣布的数据包，是在进网卡之前所抓取，在 Wireshark 敞开 Validate the IPv4 checksum if possible 选项后，会显现校验和有问题。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

而对端发送的数据包，在本端抓取，IPv4 显现校验和验证正常。

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

Wireshark TCP/UDP 校验和场景与 IP 校验和基本一致，略微差异的是 TCP/UDP 校验和，TCP/IP 协议栈是随机填充校验和字段再交给网卡硬件，而 IP 校验和是填充零。

TCP 选项为 Validate the TCP checksum if possible

UDP 选项为 Validate the UDP checksum if possible

因而再次着重，根据端到端数据包正常传输的状况下（而不是校验和有问题的状况） ，客户端或服务端本地所宣布的数据包（譬如 SYN-SYN/ACK-ACK ），在 Wireshark 敞开 IP、TCP 或 UDP 等校验和功用的状况下，相对应的校验和会显现为过错（实际是正常的，网卡填充之前），而在中心端捕获数据包时，会显现为正常（网卡填充之后）。

数据包 Length

网卡 Offload 特性中的 TSO、GSO、LRO、GRO 等功用，意味着分片、分段和重组等功用会在网卡上卸载履行。

相同的原因， Wireshark 的抓包方法（或许说是原理）和方位，Wireshark 抓包方位假如是在本地，那么关于本地发生所宣布的数据包，是在进网卡之前所抓取，所以关于敞开 TSO、GSO 等功用的设备，会在抓包成果中或许看到大于 MTU 的数据包。（这儿指的是规范 MTU 大小 1500）

Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

反之，假如关于本地接纳的数据包，Wireshark 是在网卡之后所抓取，假如敞开了 LRO、GRO 等功用，会在抓包成果中或许看到大于 MTU 的数据包。

然后关于数据包传送出去，由于 MTU 的原因，数据包会发生分片、分段等，所以捕获点在中心端，捕获成果中是不会看到大于 MTU 的数据包。

其他篇

其他便是很常见会在网络传输中或许有所变化的字段，像是 Ethernet II 中的 MAC 地址、IPv4 中的 IP 地址、TCP/UDP 中的 Port 等等，这些字段在不同的场景以及不同的捕获点下，自然是或许不同的，在此不逐个赘述。

总结

一言蔽之，“站的视点不一样，看到的成果也不一样”。