我有一个很难理解的问题。我有一台由业务合作伙伴在其网络上托管的服务器，但我的团队负责为该服务器安装和配置软件（实际上有 3 台服务器都表现出相同的行为）。作为配置的一部分，我们尝试通过 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
这将停滞几分钟并最终超时。我已经从我这边捕获了数据包，虽然我不太擅长阅读数据包捕获，但似乎服务器端停止响应几分钟并最终重置连接。我在 tshark 上找到了一个片段另一个问题我稍加修改后得到了这个：
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 | |
===================================================================================
我知道这不是很好，但我不太确定它告诉我什么。我可以在数据包跟踪中看到几分钟内服务器没有响应（或者没有响应到达我），然后最终设置了 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 访问权限）。我想我认为我们之间有一些网络配置问题，因为所有三台服务器的问题都是一样的，而上周的情况并非如此。
答案1
这可能可能是 MTU 问题。您可以使用以下命令快速验证是否存在：
ping -M do -s 1472 other.end.address
（1472 = 1500 - 20（ip 报头） - 8（icmp 报头））。
您可以尝试使用 来缩小问题范围tracepath。如今，可能导致此类问题的常见故障是 VPN/隧道等。
如果是这种情况，请考虑启用 TCP 路径 MTU 发现：
sysctl -w net.ipv4.tcp_mtu_probing=1
答案2
解决方案不是很令人满意，但事实证明，我们的合作伙伴的 IPS 在周末自动更新了新规则/签名，导致了此行为。他们现在已经能够为我们解决这个问题。