☰

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

tag-icon • tag-icon linux networking tcpip ethernet latency
TCP/IP-over-Ethernet ネットワークの遅延

次のような場合に、どのようなリソース（書籍、Web ページなど）をお勧めしますか。

  • TCP/IP-over-Ethernet ネットワークにおける遅延の原因を説明します。
  • 遅延の原因となるものを監視するツールについて言及します (例: の特定のエントリnetstat -s)。
  • Linux TCP スタックを微調整して TCP レイテンシ (Nagle、ソケット バッファなど) を削減する方法を提案します。

私が知っている中で最も近いのはこのドキュメント、しかしそれはかなり短いです。

あるいは、上記の質問に直接回答していただいても結構です。

編集明確に言うと、質問は単に「異常な」遅延についてではなく、遅延全般についてです。さらに、これは具体的には TCP/IP-over-Ethernet に関するものであり、他のプロトコル (遅延特性が優れている場合でも) に関するものではありません。

答え1

レイテンシに関するカーネルの調整可能項目に関しては、次の点が注目に値します。

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、パケットを「再 Nagle」します。ただし、 はTCP_NODELAY常に期待どおりに動作するとは限らず、場合によってはパフォーマンスが低下する可能性があることに注意してください。たとえば、大量のデータを送信する場合は、パケットあたりのスループットを最大化する必要があるため、 を設定しますTCP_CORK。即時の対話性を必要とするアプリケーション (または応答が要求よりはるかに大きく、オーバーヘッドが打ち消されるアプリケーション) がある場合は、 を使用しますTCP _NODELAY。また、この動作は Linux 固有であり、BSD は異なる可能性が高いため、警告管理者。

アプリケーションとインフラストラクチャを徹底的にテストしてください。

答え2

私の経験では、異常な正常な高速ネットワークにおける遅延はTCPウィンドウ処理（RFC1323、セクション2) 障害は、TCP 遅延 ACK に関連する障害と密接に関連しています (RFC1122 セクション 4.2.3.2)。これらの方法は両方とも、高速ネットワークをより適切に処理するための TCP の拡張機能です。これらの方法が壊れると、速度が非常に遅いレベルに低下します。これらの場合の障害は、大規模な転送 (バックアップ ストリームなど) に影響しますが、非常にトランザクションの少ないトラフィック (平均データ転送が MTU サイズ未満で、大量のやり取りが発生する) は、これらの障害の影響をあまり受けません。

繰り返しになりますが、これら 2 つの問題で最も大きな問題は、2 つの異なる TCP/IP スタックが通信しているときに発生します。たとえば、Windows/Linux、2.4-Linux/2.6-Linux、Windows/NetWare、Linux/BSD などです。Like to like は非常にうまく機能します。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 の遅延 ACK タイマーのデフォルトは 200 ミリ秒) が原因で、スループットが急激に低下します。この場合、会話の両側で TCP 遅延 ACK を処理できませんでした。

TCPウィンドウの障害は、その影響があまり明らかではないため、気づきにくい。極端な場合、ウィンドウは完全に失敗し、パケット->ack->パケット->ack->パケット->ackとなり、10KBを超えるサイズのデータ​​を転送する場合に非常に遅くなり、基本的な遅延リンク上で。検出が難しいモードは、両側が継続的にウィンドウ サイズを再ネゴシエートし、一方 (送信側) がネゴシエーションを遵守できず、データの送信を継続する前にいくつかのパケットを処理する必要があるときです。この種の障害は、Wireshark トレースで赤色の点滅ライトとして表示されますが、予想よりも低いスループットとして現れます。

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

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

答え3

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

TCP の仕組みを思い出してください。クライアントが SYN を送信し、サーバーが SYN/ACK に応答し、クライアントが ACK に応答します。サーバーが ACK を受信すると、データを送信できるようになります。つまり、意味のあるデータの最初のビットを送信するには、ラウンドトリップ時間 (RTT) の 2 倍待つ必要があります。RTT が 500 ミリ秒の場合、開始から 1 秒の遅延が発生します。セッションの存続期間が短くても数が多い場合は、大きな遅延が発生します。

セッションが確立されると、サーバーはクライアントが確認応答する必要があるデータ ユニットを送信します。サーバーは、最初のデータ ユニットの確認応答が必要になるまで、一定量のデータしか送信できません。これにより、遅延も発生します。データ ユニットがドロップされると、そこから送信を拾う必要があり、余分な遅延が発生します。

IP レベルでは、断片化が発生します (現在では非常にまれですが)。1501 バイトのフレームを送信し、相手側が 1500 の MTU しかサポートしていない場合、最後のデータ ビットだけのために追加の IP パケットが送信されます。これは、ジャンボ フレームを使用することで解決できます。

TCP/IP スループットを向上させる最善の方法は、待ち時間をできるだけ短くし、伝送エラーをできるだけ避けることです。カーネルの調整については知りませんが、誰かがやってくれるはずです。

答え4

おそらく、これはあなたが探している答えではありません。WAN における遅延の主な原因は光の速度です (非常に遅いのです)。また、途中で大きなバッファを持つ飽和したリンクは、遅延が著しく大きくなる傾向があります。

関連情報