RSyncは32768バイト後にストールします
理解に苦労している問題があります。私は彼らのネットワーク上でビジネスパートナーによってホストされているサーバーを持っていますが、私のチームはこのサーバーへのソフトウェアのインストールと構成を担当しています（実際には3つのサーバーがすべて同じ動作を示しています）。構成の一部として、rsyncを介して（SSH経由で）ファイルをコピーしようとしていますが、私たちとパートナーが理解していない問題が発生しています。
基本的に、32768バイト未満のファイルをrsyncできるようですが、その後接続が停止します。これはSSH経由で行っており、サーバー上でレスポンシブシェルを取得できます。インターネット経由で接続していますが、2つの場所から試しましたが同じ結果になりました。これが私が見るものの例です：
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アクセスが必要なことを除いて詳細はわかりません）。問題は3つのサーバーすべてで同じであり、先週はそうではなかったので、私たちの間でネットワーク構成の問題があると思います。
あまり満足のいく解決策ではありませんが、私たちのパートナーはIPSで、週末に新しいルール/署名で自動的に更新され、この動作を引き起こしていました。彼らはこれを解決することができました。今私たちのために。
これ可能性があります MTUの問題です。そうかどうかは、次の方法ですばやく確認できます。
ping -M do -s 1472 other.end.address
（1472 = 1500-20（ipヘッダー）-8（icmpヘッダー））。
tracepathで問題を絞り込むことができます。今日、この種の問題を引き起こす可能性のある通常の問題は、VPN /トンネルなどです。
その場合は、TCP Path MTU Discovery：を有効にすることを検討してください。
sysctl -w net.ipv4.tcp_mtu_probing=1