web-dev-qa-db-ja.com

TCP / IP-over-Ethernetネットワークの遅延

以下のリソース（書籍、Webページなど）をお勧めします。

  • tCP/IP-over-Ethernetネットワークにおける遅延の原因を説明します。
  • レイテンシの原因となるものを探すためのツールについて言及する（例：netstat -s）;
  • linuxを微調整する方法を提案TCPスタックを縮小してTCPレイテンシ（Nagle、ソケットバッファなど））。

私が認識している最も近いものは このドキュメント ですが、かなり簡単です。

または、上記の質問に直接回答することもできます。

edit明確にするために、問題は「異常な」待ち時間だけではなく、待ち時間全般についてです。さらに、それは特にTCP/IP-over-Ethernetに関するものであり、他のプロトコルに関するものではありません（より優れた遅延特性がある場合でも）。

linuxnetworkingtcpipethernetlatency
7
NPE

レイテンシのカーネル調整パラメータに関しては、次のことに注意してください。

echo 1 > /proc/sys/net/ipv4/tcp_low_latency

ドキュメント から：

設定されている場合、TCPスタックは、スループットが高くなるのではなくレイテンシが低くなるように決定します。デフォルトでは、このオプションは設定されていません。つまり、スループットが高い方が優先されます。このデフォルトのアプリケーションの例変更する必要があるのはBeowulf計算クラスタですデフォルト：0

アプリケーションでNagleのアルゴリズムを無効にすることもできます（これにより、TCP出力が最大セグメントサイズになるまで出力がバッファリングされます）。

#include <sys/types.h>
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <linux/tcp.h>

int optval = 1;
int mysock;

void main() {
    void errmsg(char *msg) {perror(msg);exit(1);}

    if((mysock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
        errmsg("setsock failed");
    }

    if((setsockopt(mysock, SOL_SOCKET, TCP_NODELAY, &optval, sizeof(optval))) < 0) {
        errmsg("setsock failed");
    }

    /* Some more code here ... */

    close(mysock);
}

このオプションの「反対」はTCP_CORKで、パケットを「再ネーグル」します。ただし、TCP_NODELAYは期待どおりに動作しない場合があり、場合によってはパフォーマンスが低下する可能性があるので注意してください。たとえば、バルクデータを送信する場合は、パケットごとのスループットを最大化する必要があるため、TCP_CORKを設定します。即時の対話性を必要とするアプリケーションがある場合（または応答が要求よりはるかに大きく、オーバーヘッドが無効になる場合）、TCP _NODELAYを使用します。別の注記では、この動作はLinux固有であり、BSDはおそらく異なるため、警告管理者。

アプリケーションとインフラストラクチャで十分なテストを行っていることを確認してください。

9
Sam Halicke

私の経験では、他の点では正常な高速ネットワークでの異常レイテンシの最大の原因は、TCPウィンドウ処理（ RFC1323、セクション2 ）障害、2番目の障害に密接に関連するTCP Delayed Acks（ RFC1122 section 4.2.3.2 ）。これらの方法の両方TCPは高速ネットワークの処理を改善するための機能強化です。高速ネットワークが壊れると、速度は非常に遅いレベルに低下します。これらの場合の障害は、非常にトランザクションの少ないトラフィックである大規模な転送（バックアップストリームを考える）に影響します（平均データ転送はMTUサイズを下回り、LOTがback-n-forthです）これらの影響は少なくなります。

繰り返しますが、2つの異なるTCP/IPスタックが通信しているときに、これら2つの問題に関する最大の問題が発生しました。 Windows/Linux、2.4-Linux/2.6-Linux、Windows/NetWare、Linux/BSDなど。好きな作品は、とても、とてもうまくいきます。 MicrosoftはServer 2008でWindows TCP/IPスタックを書き直しました。これにより、Server 2003には存在しないLinux相互運用性の問題が発生しました（これらは修正されたと思いますが、100％確実ではありません）。

遅延または選択的確認応答の正確な方法の不一致は、次のような場合につながる可能性があります。

192.168.128.5-> 192.168.128.20：1500bペイロード、SEQ 1562 
 192.168.128.5-> 192.168.128.20：1500bペイロード、SEQ 9524 
 [200msパス] 
 192.168.128.20 -> 192.168.128.5：ACK 1562 
 192.168.128.5-> 192.168.128.20：1500bペイロード、SEQ 12025 
 192.168.128.5-> 192.168.128.20：1500bペイロード、SEQ 13824 
 [200msパス] 
 192.168.128.20-> 192.168.128.5：ACK 12025

すべての200ミリ秒のタイムアウトのため、スループットはフロアを通過します（Windowsのデフォルトでは、遅延確認タイマーは200ミリ秒に設定されています）。この場合、会話の両側が処理に失敗しましたTCP遅延確認。

TCP Windowingの障害は、その影響が明確ではない可能性があるため、わかりにくいです。極端な場合、ウィンドウ処理は完全に失敗し、packet-> ack-> packet-> ack-> packet-> ackを取得します。これは、約10KBを大幅に超えるものを転送する場合は非常に遅く、拡大しますリンクの基本的な待ち時間。検出が困難なモードは、両側が継続的にウィンドウサイズの再ネゴシエーションを行っており、一方の側（送信側）がネゴシエーションを順守できず、データの受け渡しを続ける前にいくつかのパケットを処理する必要がある場合です。この種類の障害は、Wiresharkトレースの赤い点滅ライトで表示されますが、予想されるスループットよりも低くなります。

すでに述べたように、上記は大きな転送を悩ませる傾向があります。ストリーミングビデオやバックアップストリームのようなトラフィックは、非常に大きなファイル（LinuxディストリビューションISOファイルなど）の単純なダウンロードだけでなく、それらによって実際に釘付けにすることができます。たまたま、TCPウィンドウ処理は、データのパイプライン化を可能にするため、基本的な遅延の問題を回避する方法として設計されました。送信される各パケットの往復時間を待つ必要はありません。大きなブロックを送信し、単一のACKを待ってから、さらに送信することができます。

とはいえ、特定のネットワークパターンはこれらの回避策の恩恵を受けません。データベースによって生成されるようなトランザクションの多い小さな転送は、回線でのnormalレイテンシの影響を最も受けます。 RTTが高い場合、これらのワークロードは大きな影響を受けますが、大きなストリーミングワークロードははるかに少なくなります。

6
sysadmin1138

この質問には多くの答えがあります。

TCPの動作を覚えておいてください。クライアントはSYNを送信し、サーバーはSYN/ACKに応答し、クライアントはACKに応答します。サーバーがACKを受信すると、データを送信できるようになります。つまり、2待機する必要があります。意味のあるデータの最初のビットを送信するために往復時間（RTT）を掛けます。RTSが500ミリ秒の場合は、最初から1秒の遅延が生じます。セッションが短期間で多数ある場合、これにより多くのことが作成されますレイテンシの。

セッションが確立されると、サーバーはデータユニットを送信します。データユニットは、クライアントが確認する必要があります。サーバーは、最初のデータユニットの確認を必要とする前に、実際に大量のデータを送信できます。これにより、レイテンシも発生する可能性があります。データユニットがドロップされた場合、そこから送信を取得する必要があるため、余分な遅延が発生します。

IPレベルでは、断片化があります（今日では非常にまれです）。 1501バイトのフレームを送信し、反対側が1500のMTUのみをサポートしている場合、データの最後のビットだけに追加のIPパケットを送信します。これは、ジャンボフレームを使用することで解決できます。

TCP/IPスループットを向上させる最良の方法は、レイテンシを可能な限り減らし、伝送エラーをできるだけ回避することです。カーネルの微調整については知りませんが、誰かが知っていると思います。

2
Antoine Benkemoun

WANの場合、レイテンシを導入する主な要因は、光の速度です。データが北米を通過するには、理論上の最小値〜36.2msかかります。

数秒で光ファイバーケーブルを一方向に移動：

  • $ _DISTANCE_IN_MILES *（Cable_Refraction/SPEED_OF_LIGHT）

1000を掛けて、秒からミリ秒に変換します。往復の場合は2倍にします。

  • $ _DISTANCE_IN_MILES *（Cable_Refraction/SPEED_OF_LIGHT）* 1000 * 2

Washington、DCからLos Angeles、CAまでのレイテンシは次のとおりです。

  • 2308 *（1.46/186000）* 1000 * 2 = 6.23311ms
  • 光速（マイル/秒）= 186000
  • 光ファイバーケーブルの屈折率= 1.46
  • 距離（DCからLAまでのマイル数））= 2308

式の詳細

2
JamesBarnett

次のWebサイトを参照してください。 http://www.29west.com/docs/THPM/index.html

1
Mike S

おそらくあなたが探している答えではないでしょう：WAN=のレイテンシの主な原因は光の速度です（速度が遅すぎます！）。また、方法は印象的な待ち時間を得る傾向があります。

1
Joris

TCPはエンドツーエンド（またはクライアントツークライアント）のプロトコルであり、中間のネットワークの損失はほとんどないと想定しています。より堅牢なプロトコルについては、 X.25 を参照してください。したがって、クライアントのみ（ネットワークではない）のプロトコルパラメータをほとんど制御できます。

イーサネットはローカルエリアネットワーク（LAN）です（ただし、この定義は過去10年間で広域ネットワークを含むように広く拡張されています）。共有セグメントで70％以上のトラフィックに直面しない限り、伝送損失はほとんどありません。 。最近のイーサネットネットワークでは、ほとんどすべてのイーサネットセグメントが切り替えられているため、再送信はまれにしか発生しません。

したがって、LANの遅延に関しては、輻輳が最大の敵です。しかし、それでは単なる待ち時間よりも深刻な問題が発生します。

通信プロトコルの遅延の問題を真剣に考えている場合は、UDPやRTMPなどの仮想回線プロトコルではなく、パケット交換を検討する必要があります。

0
PP.