sshが高速接続で一時的にハングする
自宅のルーターに接続されているラップトップでUbuntu 13.04を使用しています。自宅で仕事をしているときは、X11転送を使用して、VPN経由でキャンパスのサーバーにSSH接続します。
ssh -X server.address.on.campus
私は通常約40 Mb/sの接続を使用しており、わずか数マイル離れた場所に住んでいるため、キャンパスネットワークでsshを使用しているかのようにターミナルの応答性が同じです。ただし、違いは、ホームからの接続が再開する前に、数分ごとに約10〜15秒間「ハング」する傾向があることです（ハング中に私が行ったすべてのキーストロークは、ハング後に画面が更新されるため、明確に送信されます）。 。ハングに認識できるパターンはありません。私が何かをタイプしているとき、それは通常起こります（または最も顕著です）。
私がこの問題をどのように軽減できるか、または何がそれを引き起こしているのか、誰かが何かアイデアを持っていますか？インターネットの周りを読んで、sshハング（通常は永久）にはさまざまな問題がありますが、私の特定の問題の解決策はありません。
更新：私はまだこの問題を抱えています。 @Anthonの提案に従い、sshが再びハングするまでpingを実行したままにしました。以下の結果をプロットしましたが、一時的なハングがどこで発生するかは明らかです。パケットが数秒間受信されず、〜6が連続して送り返されます。
また、同じマシンのWindowsパーティションでPuTTYを使用するときに発生する問題に気づいたことはありません。
数秒間パケットが受信されず、その後〜6が連続して送り返されます。
これは、ネットワークの輻輳またはネットワークの廃棄（通常は輻輳が原因）の2つの類似した現象の症状です。
最初のケースでは、あちこちにあるルーターにアクティビティとは関係のないトラフィックのバーストがあり、トラフィックが中間ルーターにバッファリングされます。途中で送信するための帯域幅が開かれるまで、順番を待ちます。このような輻輳は、YouTubeトラフィックの突然の急増（新しい子猫のビデオ!!!）や、試みられたSYN_ACK攻撃のようなものから発生する可能性があります。実際には、地球上のどこかでランダムなデバイスに自発的にトラフィックをスローする感染したマシンが非常に多く存在するため、私たちが望んでいるよりもはるかに多くの不正な攻撃が試みられています。 SYN_ACKおよび類似の攻撃は検出後すぐにクウォッシュされますが、検出とクウォッシュによっても、ルーターを数秒間ビジー状態に保つことができます。
2番目のケースは、トラフィックが過負荷のデバイスにヒットし、トラフィックがバッファリングされない場合です。余分なバッファメモリがないか、バッファリングが原因で問題が発生することが多いためです。たとえば、「1ホップオーバーしたルーターが現在ビジー状態だったため、トラフィックをバッファリングしました。利用可能になり次第、保存されているトラフィックにヒットして、ビジー状態にします…」ad infinitum。この場合、あなたのTCP接続がその 指数バックオフ を開始し、これにより（送信側）で遅延が発生します。これまで、これは、非常にバースト性の高いインターネット伝送プロトコルには このコアパーツの問題 が少数ありますが、優れた解決策はありません。
残念ながら、ISP、電話会社、およびさまざまなシステム管理者の献身的な支援がなければ、このような遅延スパイクを診断することはほぼ不可能です。おそらく、ピークトラフィックのためにオーバーサブスクライブされたデバイスは、完全にアクセスできない場所に配置されており、オペレーターは、デバイスが過負荷になっているか、気にかけていないかもしれません。
インターネットプロトコルは ベストエフォート配信 用に設計されており、パケットが宛先に到達することを保証するものではありません。想像もしていなかったような負荷がかかってもうまく機能することは、私にとっては小さな奇跡です。公共のインターネットが提供できる以上のものが必要な場合は、おそらく誰かがあなたから目的地への専用線を恣意的に高値で販売してくれるでしょう。そうでなければ、高速道路の交通や食料品店での無作為に長い行列のように、それはあなたがただ一緒に暮らさなければならない現代生活の不便でなければならないかもしれません。
補足として、物理的近接性はトポロジー的近接性とあまり相関していません。良い時間のために、traceroute destination-Hostそして、トラフィックがあちこちを行き来するデバイスの数に驚嘆します。 1 kmの転送でメガメーターと20台のデバイスが目的地に到着するのは珍しいことではありません。
コメントへの応答として追加：
同じマシンのWindowsパーティションでPuTTYを使用するときに発生する問題に気づいたことはありません。
「Windowsパーティションで」という文は「Windowsで実行」を意味しますか？そうだと思います。
より正確なデータがなければ、私は最初に、あなたがそれに気付かないことにおそらく気付かない可能性が高いと思いますが、私はそれを確信していません。別の仮説は、明らかに異なるSSH実装を使用しているPuTTYではレイテンシのスパイクが発生していないというものです。上記のpingグラフで行ったように待ち時間スパイクの欠如を定量化できれば、ネットワークとクライアントの問題を区別するのに役立ちます。
さらに転送データを取得するには、PuTTY scpを使用して、マシンと問題のホストの間で大きなファイルをコピーします。 wireshark を使用して、パケット間の時間を記録できます。
グラフのpingテストにいくつかの欠陥があります。 1つ目は、pingが使用するICMPパケットがTCP/IPとはまったく異なり、IPトラフィックよりも優先度が低く、中間ルーターによって破棄される可能性が高いことです。簡単なチェックとして、これらのデータは役立ちますが、TCP/IP接続を追跡する場合は、IPパケットを使用するのが最善です。そのため、scpをお勧めします。比較のために、UNIXで同じscp/wiresharkの組み合わせを使用することもできます。
Pingテストのもう1つの問題は、60秒では期間が短すぎて、定期的な動作を適切に把握できないことです。あなたはすでに手元に要約ツールを持っているように見えるので、10分は1分よりも1時間よりも優れています。
テストするとき、マシン間で渡すデータを変化させます。エントロピーが多く、ほとんどエントロピーがないファイルを生成するための、非常に迅速で汚いスクリプトを次に示します。
#!/usr/bin/env python2.7
import random
def data_bytes(outf, ordered=False):
"""write a series of ordered or random octets to outf"""
for block in range(1024):
for char in range(1024):
if ordered:
c = char % 0x100
else:
c = random.randint(0, 0xff)
outf.write(chr(c))
def main():
with open('random.dat', 'wb') as outf:
data_bytes(outf, ordered=False)
with open('sequen.dat', 'wb') as outf:
data_bytes(outf, ordered=True)
if __name__ == '__main__':
main()
このビットが明らかに明白であるかどうか私を許してください。
あなたの事例観察はこれを興味深い質問にします。さらに取得するにはハードデータが必要です。
まだ試していない機会があれば、sshクライアントのキープアライブを追加してみてください。追加するだけ
ServerAliveInterval 30
~/.ssh/configのどこかにあり、sshを再起動します。
Sshが再びハングするまで、pingを実行したままにしました。パケットが数秒間受信されず、その後〜6が連続して送り返されます。
VMware上に2つの仮想サーバーがあります。それらのどれもDNSにありません。同じESX上の両方の仮想サーバー。 PuTTYは1つだけにフリーズします。 VMware仮想マシンコンソールがフリーズしない。
そこで、Windowsクライアントからサーバーに追跡します。そして、マシンがフリーズして、初期のDNS名を表示します。サーバーのIPアドレスを変更するだけで問題が解決しました。
実際のネットワークトポロジがわからないので、ジャンボフレームのあるギガビットネットワークに関連しているのではないかと思います。 sshはジャンボフレームが好きではありません。標準の1500バイトサイズのパケットに最適化されており、パケットがこれより大きい場合（たとえば6000バイト）
ジャンボフレーム対応の2つのワークステーションを使用して、イントラネットでこれを確認できます。 （もちろん、それらの間にギガビット対応のネットワークがあります！）
遠くからサーバーに接続し、パケットが不均一に配信されると、ネットワーク設定によっては、ルーターがパケットを最適化し、サーバーがジャンボフレームを取得して通信が失敗する場合があります。
ジャンボフレームが有効になっている場合は、サーバーの構成を確認する必要があります。