乱序报文可以完成TCP三次握手吗-CSDN博客

如下TCP握手时序：

问加粗的那个报文可以完成TCP握手吗？server端的accept会返回吗？
答案是肯定的：

• 只要到达server报文的ack字段等于server syn+1，即可完成握手。

TCP协议属全双工，3rd ack实属server到client方向syn的确认，server只需以验证其ack字段作为根本，seq可看作client到server方向ack的捎带data，验证并不严格。

下列packetdrill脚本可演示：

+0  socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0  setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8000], 4) = 0

+0  bind(3, ..., ...) = 0
+0  listen(3, 1) = 0

// 开始握手
+0  < S 0:0(0) win 1000 <mss 1000,sackOK,nop,nop>
+0  > S. 0:0(0) ack 1<...>
// 用乱序报文完成握手
+.1 < P. 1000:5380(4380) ack 1 win 32792
// 下面是正常的按序报文，打开注释做对比
//+.8 < . 1:1(0) ack 1 win 32792
+0  accept(3, ..., ...) = 4
+.2 %{ assert 1 == tcpi_state }%
+.3 %{ print tcpi_state, tcpi_ca_state }%
+.3 %{ print tcpi_rcv_space }%
// 乱序的第三次ACK
+.8 < . 1:1(0) ack 1 win 32792
// 乱序的第一个报文
+.8 < . 1:1000(999) ack 1 win 32792

另起一终端，输入下示命令行后执行packetdrill结果如下：

~/test$ sudo bpftrace -e 'kr:inet_csk_accept/comm == "pdrill"/{$tp = (struct tcp_sock*)retval;$sk = (struct sock*)retval;printf("state:%d rcv_nxt:%d ofo_pkts:%d\n", $sk->sk_state, $tp->rcv_nxt, $tp->rcv_ooopack);}' --include "linux/tcp.h"
Attaching 1 probe...
state:1 rcv_nxt:1 ofo_pkts:1  # 解释：连接已ESTABLISHED，期待接收1号，乱序报文进入ofo queue

在accept正当时，来自client的第三个握手ACK尚未到达，却到达了乱序报文，握手亦可成功。最最关键在于第12行的"ack 1"，若改为其它，握手将无法完成。

开篇提到，server所收的data属于3rd ack的捎带，需容忍乱序，只需在server容忍范围，即可完成握手，此容忍范围由server通告窗口度量。若乱序报文如下所示：

+.1 < P. 11000:15380(4380) ack 1 win 32792

此报文超出通告窗口，server可确定其为伪造或超发，报文被丢弃，握手无法完成，accept便将永久等下去了。

按常理，client遵守通告窗口的限定，即使乱序也终被窗口覆盖，故如此设计属实合理。但根本原因，还在于TCP全双工，两个方向要各自对待。

上述文字亦可通过tcpdump抓包验证。

TCP syncookie握手亦可容忍乱序，此即未将seq编码进cookie的原因，但若seq不参与cookie计算，便可能产生下列丢数据问题：

故cookie握手情形下，容忍乱序与数据完整性不可得兼，舍数据完整性而保鲁棒性。

临了，简短总结TCP握手。

TCP握手实属4次而非3次，每个方向2次。只是server到client方向对syn的确认与server到client方向的syn合为1次，展现出3次握手而已：

反观挥手阶段，因两方向的传输彼此独立，故无法合并被动关闭端对fin的确认以及自己的fin。

表象之下，挥手和握手本质相同，其核心即TCP之全双工。

浙江温州皮鞋湿，下雨进水不会胖。