网络工程 - 什么可能导致 TCP 仅重新传输（完全确认的）段的结尾？ - 吾爱随笔录

这个问题的要点在标题中：什么可能导致 TCP 仅重新传输（完全确认的）段的末尾？

这是两台主机之间的 TCP 对话：SSH 服务器（172.16.6.249，物理机）和 SSH 客户端，执行命令“ssh-keyscan”（192.168.0.18，虚拟机）。此捕获是在 192.168.0.18 的网络接口上完成的。

No.     Time        Source                Destination           Protocol Length Info
  1 0.000000    192.168.0.18          172.16.6.249          TCP      74     46180 > 22 [SYN] Seq=0 Win=28200 Len=0 MSS=1410 SACK_PERM=1 TSval=173592928 TSecr=0 WS=128
  2 0.001274    172.16.6.249          192.168.0.18          TCP      74     22 > 46180 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3139755418 TSecr=173592928 WS=128
  3 0.001309    192.168.0.18          172.16.6.249          TCP      66     46180 > 22 [ACK] Seq=1 Ack=1 Win=28288 Len=0 TSval=173592929 TSecr=3139755418
  4 0.010710    172.16.6.249          192.168.0.18          TCP      109    22 > 46180 [PSH, ACK] Seq=1 Ack=1 Win=29056 Len=43 TSval=3139755421 TSecr=173592929
  5 0.010741    192.168.0.18          172.16.6.249          TCP      66     46180 > 22 [ACK] Seq=1 Ack=44 Win=28288 Len=0 TSval=173592931 TSecr=3139755421
  6 0.010886    192.168.0.18          172.16.6.249          TCP      91     46180 > 22 [PSH, ACK] Seq=1 Ack=44 Win=28288 Len=25 TSval=173592931 TSecr=3139755421
  7 0.010965    192.168.0.18          172.16.6.249          TCP      1464   46180 > 22 [ACK] Seq=26 Ack=44 Win=28288 Len=1398 TSval=173592931 TSecr=3139755421
  8 0.011950    172.16.6.249          192.168.0.18          TCP      66     22 > 46180 [ACK] Seq=44 Ack=26 Win=29056 Len=0 TSval=3139755421 TSecr=173592931
  9 0.011959    192.168.0.18          172.16.6.249          TCP      284    46180 > 22 [PSH, ACK] Seq=1424 Ack=44 Win=28288 Len=218 TSval=173592931 TSecr=3139755421
 10 0.012227    172.16.6.249          192.168.0.18          TCP      66     22 > 46180 [ACK] Seq=44 Ack=1424 Win=31872 Len=0 TSval=3139755421 TSecr=173592931
 11 0.033124    172.16.6.249          192.168.0.18          TCP      1714   22 > 46180 [PSH, ACK] Seq=44 Ack=1424 Win=31872 Len=1648 TSval=3139755421 TSecr=173592931
 12 0.033153    192.168.0.18          172.16.6.249          TCP      66     46180 > 22 [ACK] Seq=1642 Ack=1692 Win=31616 Len=0 TSval=173592937 TSecr=3139755421
 13 0.033173    172.16.6.249          192.168.0.18          TCP      316    [TCP Retransmission] 22 > 46180 [PSH, ACK] Seq=1442 Ack=1642 Win=34688 Len=250 TSval=3139755424 TSecr=173592931
 14 0.033184    192.168.0.18          172.16.6.249          TCP      78     [TCP Dup ACK 12#1] 46180 > 22 [ACK] Seq=1642 Ack=1692 Win=31616 Len=0 TSval=173592937 TSecr=3139755424 SLE=1442 SRE=1692
 15 0.035635    192.168.0.18          172.16.6.249          TCP      114    46180 > 22 [PSH, ACK] Seq=1642 Ack=1692 Win=31616 Len=48 TSval=173592937 TSecr=3139755424
 16 0.047742    172.16.6.249          192.168.0.18          TCP      690    22 > 46180 [PSH, ACK] Seq=1692 Ack=1690 Win=34688 Len=624 TSval=3139755430 TSecr=173592937
 17 0.047869    192.168.0.18          172.16.6.249          TCP      66     46180 > 22 [FIN, ACK] Seq=1690 Ack=2316 Win=34304 Len=0 TSval=173592940 TSecr=3139755430
 18 0.049738    172.16.6.249          192.168.0.18          TCP      66     22 > 46180 [FIN, ACK] Seq=2316 Ack=1691 Win=34688 Len=0 TSval=3139755430 TSecr=173592940

我不明白第 13 帧和第 14 帧。172.16.6.249 已经发送了一个序列号为 44 + 长度为 1648 = 1692（第 11 帧）的段，192.168.0.18只用 ACK 1692（第 12 帧）回答了该段。

什么可以让 172.16.6.249 再次发送段的结尾（第 13 帧）？我检查了段有效负载，它确实与第 11 帧中有效负载的最后 250 个字节匹配。

我还假设对第 14 帧中最后 250 个字节的选择性确认是客户端因两次接收相同数据而感到困惑的结果，但也许我在这里遗漏了一些东西。

不幸的是，我在 172.16.6.249 上没有相应的捕获，因为我正在调查难以重现的网络问题。

主机在物理上非常接近，它们之间只有一个 (Linux) 路由器和一个物理交换机，但有一些 SDN 正在进行（Linux 网桥 + VXLAN）。然而，这对端点应该是透明的。

接下来我应该看什么？