SSHは時々高速接続で一時的に中断されます。

数秒間パケットが受信されなかった後、約6個のパケットがすぐに連続して再送信されます。

これは、ネットワーク輻輳またはネットワークハング（通常輻輳による）という2つの同様の現象の症状です。

最初のケースでは、こことそこの間のルーターでユーザーアクティビティとは無関係のトラフィックバーストが発生し、トラフィックはいくつかの中間ルーターでバッファリングされます。彼らは帯域幅が利用可能になるまで自分のターンを待ちます。このような輻輳は、YouTubeトラフィックの突然の急増（新しい子猫の動画!!!）やSYN_ACK攻撃の試みによっても発生する可能性があります。地球上のどこかにランダムデバイスにトラフィックを自発的に送信する多数の感染システムがあるため、実際に私たちが考えるよりも悪意のある攻撃の試みがあります。 SYN_ACK と同様の攻撃は検出後すぐにキャンセルされますが、検出とキャンセルでもルータを数秒間使用できます。

2番目のシナリオは、トラフィックが過負荷になっているデバイスに到達し、確かにバッファトラフィック。これは、追加のバッファメモリがないか、バッファリングがしばしばそれ自体で問題を引き起こすためです。たとえば、「1ホップの距離にあるルータは現在忙しくてトラフィックをバッファリングしています。したがって、一度使用できるようになると、保存されたトラフィックでルータを攻撃して過度に忙しくなります。」無期限。この場合、TCP接続が開始されます指数バックオフこれにより発信者が遅れることがあります。歴史的に、これは爆発的なインターネットを処理する良い方法でした。たくさんあります問題の中核部分です転送プロトコルですが、良い解決策はありません。

残念ながら、これらの遅延の急増は、ISP、通信事業者、およびさまざまなシステム管理者の情熱的な助けなしに診断することはほとんど不可能です。ピークトラフィックによって超過購読されたデバイスは、ユーザーがまったくアクセスできない場所にある可能性があり、オペレータはそのデバイスが超過購読または管理されているという事実さえ知らないかもしれません。

インターネットプロトコルは次のように設計されています。頑張って配送パケットが宛先に到達する保証はありません。私が想像していなかった負荷にもかかわらず、まだ動作していることは私の小さな奇跡です。公共のインターネットが提供できるよりも優れたサービスが必要な場合は、誰かが喜んで高い価格で目的地まで専用線を販売できます。さもなければ、高速道路交通や食料品店のランダムに長く並んでいるように、それはただ監修しなければならない現代生活の不便​​かもしれません。

ところで、物理的近接性は位相的近接性と低い相関関係があります。余暇には、traceroute destination-hostここから別の場所に移動するためにトラフィックがどのくらいのデバイスを通過する必要があるかを考えてみてください。 1kmの伝送が1メガメートルと20のデバイスを経由して目的地に到達することは珍しいことではありません。

返信コメントを追加してください。

同じコンピュータ上のWindowsパーティションでPuTTYを使用しても問題が見つかりませんでした。

「Windowsパーティションで」という言葉は、「Windowsで実行中」を意味しますか？そうだと思います。

より正確なデータがなければ、最初は気付かなかった可能性がありますが、わかりません。別の仮説は、PuTTYが明らかに異なるSSH実装を使用しているため、待ち時間スパイクが発生しないことです。上記のpingチャートのように、待ち時間の増加がないことを数量化できる場合は、ネットワークの問題とクライアントの問題を区別するのに役立ちます。

より多くのデータを転送するには、PuTTYを使用してscpコンピュータとそのホスト間に大容量ファイルをコピーします。あなたはそれを使用することができますラインシャークパケット間の時間を記録します。

チャートのpingテストにはいくつかの欠陥があります。 1つ目は、pingがTCP / IPとはまったく異なり、通常はIPトラフィックよりも優先順位が低く、中間ルーターで破棄される可能性が高いICMPパケットを使用することです。クイックチェックでこのデータは便利ですが、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/configsshを再起動してください。

実際のネットワークトポロジを知らずにジャンボフレームを使用するギガビットネットワークと関連があると考えました。 sshはジャンボフレームが好きではありません。標準の1500バイトサイズのパケットに最適化されており、パケットがそれより大きい場合は問題が発生します。 （例：6000バイト）

ジャンボフレームが有効になっている2つのワークステーションを持つイントラネットでこれを確認できます。 （もちろん、それらの間にギガビットネットワークがあります！）

遠くからサーバーに接続し、パケットが不均一に転送されると（ネットワーク設定によっては）、ルーターがパケットを最適化し、サーバーがジャンボフレームを受信して​​通信が失敗することがあります。

サーバー構成でジャンボフレームが有効になっていることを確認する必要があります。

SSHが再び停止するまでpingを実行し続けました。数秒間パケットが受信されなかった後、約6個のパケットがすぐに連続して再送信されます。

vmwareには2つの仮想サーバーがあります。それらのどれもDNSにありません。両方の仮想サーバーは同じESXにあります。パテは1つだけ凍結します。 vmware仮想マシンコンソールがハングしない

だから私はWindowsクライアントからサーバーにTRACERTをしました。マシンが停止し、古いDNS名が表示されます。サーバーIPアドレスを変更したばかりで問題が解決しました。