私は、一般的な (つまり、質の悪い) ワイヤレス ホーム ネットワーク経由で Mac OS ラップトップを使用し、VPN 経由で仕事に接続します。職場のオフィスにある Linux (Ubuntu) デスクトップに SSH で接続します。(「SSH する」と言うときは、'SSH' を使用することを示すボタンをクリックし、「ターミナル」ウィンドウが開いてデスクトップにログインします。)
頻繁に (1 日に数回まで)、「vim」を使用しているときに、「vim」が応答しなくなり、1 ～ 2 分後にデスクトップへの接続が切断され、ターミナルに接続が切断されたことが通知されます。デスクトップで複数のターミナル ウィンドウを同時に開いていることがよくありますが、「vim」を使用しているターミナル ウィンドウだけが切断されます。他のウィンドウは接続されたままで、使用できます。
最近、tcpdump を使用して行き来するパケットをトレースしていたところ、vim セッションがハングして終了したトレースをキャプチャしました。停止の数分前に、デスクトップからのパケットが着実にウィンドウ サイズを縮小しながら到着し、最終的に 0 に達し、その後接続が切断されました。
これは、たとえば、挿入モードに入り、デスクトップがハングしているときに文字を入力し始め、デスクトップがめちゃくちゃになっているときに入力してウィンドウを埋め尽くした場合、ほぼ理解できます。開始ウィンドウ サイズは約 12,500 で、入力した文字ごとに 48 バイトのパケットが生成されるようです。したがって、約 250 文字で TCP バッファーがいっぱいになる可能性があります。
ただし、vim がハングする場合は、ページダウン (control-f) を実行してから挿入モードに入り、いくつかの文字を入力し始めるような感じになります。コマンドと文字がエコーされ、vim が文字を受け取って処理していることを示します。
tpc バッファがソケットと 'vim' の間のどこにあるのかはよくわかりません。おそらく、tty ドライバが実際に tcp バッファから文字を取り出し、それをエコーして vim に渡し、vim からの出力を私に返しているのでしょう。しかし、これらのアクションはすべて tcp バッファからバイトを取り出し、ウィンドウ サイズはゼロになりません。
ソフトウェア スタックの動作について理解していない点は何ですか? ウィンドウ サイズがゼロになるのはなぜですか? また、この問題を回避または修正するにはどうすればよいですか?
ボーナス質問:
1) デスクトップのウィンドウ サイズが 64K ではなく 12,500 に設定されるのはなぜですか?
2) Mac で tcpdump を使用する際、「host hostname」、「host ipaddress」、または「port 22」の式 (「hostname」と「ipaddress」はデスクトップの名前または IP アドレスに置き換えられます) を使用すると、出力が得られません。これらの式のいずれかを指定しないと、大量の出力が得られ、出力にはコマンド ラインで指定したホスト名、IP アドレス、またはポートが明確に含まれています。Mac で tcpdump が動作しない特別な理由があるのでしょうか。コマンド ラインを台無しにする標準的な方法があるのでしょうか。tcpdump に何を要求しているのかわかりません。
ありがとう、Cs
答え1
まず、TCP ウィンドウ サイズはバッファではなく、確認応答しきい値です。トラフィックを受信するノードは、x パケットごとに ACK パケットのみを送信します。信頼性の高いネットワークでは、スループットのためにこの数値をできるだけ大きくする必要があります。ただし、一部のデータが失われた場合は、ウィンドウ全体を再送信する必要があります。通常、これにより、TCP スタックは、将来のパケット損失が発生した場合に大量のデータを再送信する必要がないように、ウィンドウ サイズを段階的に縮小します。使用可能なメモリ (受信バッファ) に関連するコンポーネントがありますが、最近のシステムではほとんど関係ありません。ウィキペディア
この問題の根本的な原因は、ネットワーク接続の不良である可能性が高いです。VPN は、ワイヤレス ネットワークと同様に、遅延やパケット損失が頻繁に発生します。実験として、ワイヤレスではなくハードライン経由で接続すると、問題は改善/解決しますか?