我有一个难以理解的问题。 我有一个由他们的networking上的业务参与者托pipe的服务器，但我的团队负责安装和configuration软件到这个服务器（实际上有3个服务器都显示相同的行为）。 作为configuration的一部分，我们试图通过rsync（通过SSH）复制文件，但是我们遇到了我们和合作伙伴不理解的问题。
从本质上来说，我们似乎能够rsync小于32768字节的文件，但之后，连接停顿。 我们通过SSH来做这件事，我可以在服务器上获得一个响应式shell。 我通过互联网连接，但我已经从两个地点尝试，结果相同。 这是我看到的一个例子：
rsync -aP ~/Downloads/file.zip servername:~ -vvv opening connection using ssh servername rsync --server -vvvlogDtpr --partial . "~" building file list ... [sender] make_file(file.zip,*,2) 1 file to consider server_recv(2) starting pid=2610 send_file_list done send_files starting received 1 names recv_file_list done get_local_name count=1 /home/me generator starting pid=2610 delta-transmission enabled recv_files(1) starting recv_generator(file.zip,0) send_files(0, /Users/me/Downloads/file.zip) send_files mapped /Users/me/Downloads/file.zip of size 54965002 calling match_sums /Users/me/Downloads/file.zip file.zip 32768 0% 0.00kB/s 0:00:00 这将停顿几分钟，最终超时。 我已经捕获了从我身边的数据包，而我不是特别精通阅读数据包捕获，似乎服务器端停止响应几分钟，最终重置连接。 我在另一个问题上find了一个tshark snippet，为了得到这个，我稍微调整了一下：
tshark -r ~/rsync-timeout.pcap -q -z io,stat,20,"COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission","COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack","COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment","COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission" =================================================================================== | IO Statistics | | | | Duration: 395.924510 secs | | Interval: 20 secs | | | | Col 1: COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission | | 2: COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack | | 3: COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment | | 4: COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission | |---------------------------------------------------------------------------------| | |1 |2 |3 |4 | | | Interval | COUNT | COUNT | COUNT | COUNT | | |--------------------------------------------| | | 0 <> 20 | 0 | 0 | 0 | 0 | | | 20 <> 40 | 2 | 1 | 0 | 0 | | | 40 <> 60 | 13 | 0 | 0 | 0 | | | 60 <> 80 | 4 | 0 | 0 | 0 | | | 80 <> 100 | 4 | 0 | 0 | 0 | | | 100 <> 120 | 0 | 0 | 0 | 0 | | | 120 <> 140 | 4 | 0 | 0 | 0 | | | 140 <> 160 | 0 | 0 | 0 | 0 | | | 160 <> 180 | 0 | 0 | 0 | 0 | | | 180 <> 200 | 4 | 0 | 0 | 0 | | | 200 <> 220 | 0 | 0 | 0 | 0 | | | 220 <> 240 | 4 | 0 | 0 | 0 | | | 240 <> 260 | 0 | 0 | 0 | 0 | | | 260 <> 280 | 4 | 0 | 0 | 0 | | | 280 <> 300 | 0 | 0 | 0 | 0 | | | 300 <> 320 | 4 | 0 | 0 | 0 | | | 320 <> 340 | 0 | 0 | 0 | 0 | | | 340 <> 360 | 4 | 0 | 0 | 0 | | | 360 <> 380 | 0 | 0 | 0 | 0 | | | 380 <> Dur | 0 | 0 | 0 | 0 | | ===================================================================================
我可以看到那不是很好，但我不确定它告诉我什么。 我可以在数据包追踪中看到，服务器没有响应（或没有find我）几分钟，然后最终设置了RST，双方都挂断了。
用tshark查看我的数据包跟踪结束如下所示：
... everything seems ok before this point 429 45.647732 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=15846 Win=60288 Len=0 TSval=8701862 TSecr=552453169 430 45.714775 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=17254 Win=63232 Len=0 TSval=8701928 TSecr=552453237 431 45.748600 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=18662 Win=64128 Len=0 TSval=8701963 TSecr=552453237 432 45.821013 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=21478 Win=64128 Len=0 TSval=8702035 TSecr=552453237 433 47.331298 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408) 434 49.243984 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188) 435 49.243989 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188) 436 49.244199 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188) 437 49.244203 192.168.1.18 -> 1.2.3.4 SSHv2 882 Client: [TCP Retransmission] , Encrypted packet (len=816) 438 52.678673 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188) 439 52.678677 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188) ... more of the same ... 472 309.358046 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408) 473 309.358166 192.168.1.18 -> 1.2.3.4 SSHv2 222 Client: [TCP Retransmission] , Encrypted packet (len=156) 474 335.714554 1.2.3.4 -> 192.168.1.18 TCP 60 22→53837 [RST, ACK] Seq=4050 Ack=5018 Win=0 Len=0 475 352.579591 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408) 476 352.579592 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408) 477 352.579595 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408) 478 352.579596 192.168.1.18 -> 1.2.3.4 SSHv2 222 Client: [TCP Retransmission] , Encrypted packet (len=156) 479 395.924510 192.168.1.18 -> 1.2.3.4 TCP 54 53839→22 [RST, ACK] Seq=29014 Ack=2438 Win=131072 Len=0
我希望对我们能做些什么来解决这个问题或帮助我们的合作伙伴解决他们的问题有一些想法。 我知道在我和远程服务器之间有防火墙和交换机（但我不知道详细信息，除了我应该有不受限制的SSH访问）。 我想我认为我们之间存在一些networkingconfiguration问题，因为所有三台服务器的问题都是一样的，上周也不是这样。
这可能是MTU问题。 您可以快速validation是否如此：
ping -M do -s 1472 other.end.address
（1472 = 1500 – 20（ip header） – 8（icmp header））。
您可以尝试用tracepath缩小问题范围。 现在，常见的可能导致这类问题的事情是VPN /隧道/等等。
如果是这种情况，请考虑启用TCPpathMTU发现：
sysctl -w net.ipv4.tcp_mtu_probing=1
不是很令人满意的解决scheme，但事实certificate，我们的合作伙伴有一个IPS，在周末导致这种行为的周末，新的规则/签名被自动更新。 他们现在能够为我们解决这个问题。