TCP / IPで通信遅延を定式化するにはどうすればよいですか？

TCP / IPを使用して通信する2つのノード間のラウンドトリップレイテンシを推定するための数学モデル/方程式を導出するのは困難です。ノードは、HTTPプロトコルに基づいてデータを交換しています。このモデルでは、調査する最も重要な要因は、ネットワーク内の2つのノード間の物理距離、中間ホップの数、帯域幅、各ホップでの処理遅延です。Webを検索しましたが、この意味では何も見つかりませんでした。むしろ、回線交換ネットワークとUDPプロトコルについて何かを見つけました。TCPに合わせてカスタマイズできますか？

これは非常に複雑なプロセスであるため、RTTを正確に予測するのに役立つ方程式を定式化することは非常に困難です。せいぜい、各段階の平均値を使用するモデルを作成でき、特定の状況で「よく知っている」場合に調整できるモデルを作成できると思います。これは私が現在勉強しているものですので、私はこれまでに知っていることを伝えることができます（最初から、物理層から）：

• Electronics SEに関する私の質問をご覧ください。イーサネットのエンコード遅延、およびケーブルの周波数定格と通信遅延のための銅線を介した電気の速度（信号伝搬？）との関係。標準化された速度（100 Mbps、1 Gbps、10 Gbpsなど）を使用するため、ファイバーや銅を別の方法で処理しないでください。2つの「遅延」はそれと同じくらい近いですが、銅は明らかに信号を伝えることができません。私が持っているこの質問を、私は今の答えを知っていますか物理SEサイト上で。私はちょうどそれを正す時間を見つける必要があるので、あなたが興味を持っているなら、それに注意してください）。

• リンクの終わりに、デバイスによってさらに多くの遅延が追加されます。「パスに沿った2つのスイッチはXms遅延、4つのスイッチは2 * Xms、2つのルーターはYms ...など」と言う標準的な方法はありません。たとえば、1Gpbsを使用し、パス内のデバイスをラインレートで転送すると仮定すると、1000000000bpsであることがわかっているため、物理インターフェイスは固定エンコードレート（ビットあたり1ナノ秒から最大使用中のシンボルエンコーディングスキームは、10bなど）

• 認識して考慮に入れる必要がある遅延には、物理​​層での3つの主要な種類があります。シリアル化遅延、エンコード遅延、伝搬遅延（および処理遅延、キューイング遅延、エンコードおよびデコード遅延、これらは物理層の上にありますが、言及する必要があります！）。これらは、インターネット、VoIP：詳細分析、スライド13 、Google Scholarにロードされているほか、さらに多くの資料で十分に文書化されています。

• プロトコルスタックを上に移動するとき、宛先MACは各スイッチカムテーブルにあり、IP層ではARPテーブルの宛先MACにあるという前提で作業します。これらのディスカバリプロセスによって引き起こされる余分な遅延は、フローの最初のパケットでのみ発生するため、タイムアウトを上げてgratuitous ARPなどを送信することで回避できます。

• アプリケーション層に到達すると、これは非常に困難になります。これは、要求を処理するサーバー（たとえば）に依存するためであり、割り込み遅延の影響を受けます。負荷による要求とコンテキストの切り替えを処理するために必要な割り込みの数は予測できません。

私はあなたの質問であなたを助けたいと思います、悲しいことにこれは私が今のところ時間があるだけです。この回答を今夜遅くか明日に更新するかもしれません。これまでの投稿を掲載したいと思いました。

それまでの間、ほとんどの人は、約0.6 * c（C =光の速度）の物理的な銅/繊維層での遅延の数値で作業する傾向があります。また、XパケットごとのTCPのACKの交換について考える必要があります。これは、たとえばSACKを使用している場合や、ジャンボフレームや大きなMSSサイズを使用している場合は異なります（MTUも考慮する必要があります！） 、より多くの中間ACKを送信する場合（転送されるデータの量が重要な場合）。また、悪名高いBandwidth Delay Productを考慮に入れる必要があり、そのページで私がやった愚かな誤解をしないでください。ここでさまざまなシンプルな（そして非常にい）データ計算機の作成を開始しました。進行中の作業を繰り返しますが、すぐに更新してみます。あなたがやろうとしているものに似た計算機を追加する予定です。興味のある方のために光とファイバーの計算機もいくつか作成しましたが、再び、時間がない！、まだそれらをアップロードすることはできません。近日中にこの回答を更新するために、できるだけ早く試してみます。

PS QoSについて言及するのを忘れました！QoSがパスのどこかで機能している場合、RTTを計算するのは非常に困難になります！

（私は他の人が投稿したことを指摘したいの優れた基本モデルはシンプルで、あなただけの実施例番号にプラグインを知りたい場合は、。どのように遅延がら仕事とどのようなそれらの原因についての回答をしかし、OPはモデリングについて尋ねた理由遅延は彼らが何であるか、そして他のみんなの答えを見る：^）

ネットワークレイテンシは、1つのエンドポイントから他のエンドポイントまでの通過時間であり、Nホップにまたがっています。

したがって、N-1個の中間ノードを持つN個のセグメント（ホップ）があります。各ノードには遅延（キュー遅延、処理遅延など、そのノードに対するいくつかの事柄の累積的な影響）があり、各セグメントには通過遅延があります。全体としては2N-1個の独立変数です。したがって、それはseg1 + node1 + seg2 ... + node（N-1）+ segN 1ホップ、ただ= seg1、2つの希望はseg1 + node1 + seg2などです。

次に、これらすべてのピースが何であるかを定義する必要があります。したがって、CATVネットワーク、衛星リンク、光ファイバーリンク、イーサネットなどでモデルネットワークを構築できます。これらのテクノロジーのそれぞれについて、サンプル情報を調べる必要があります。

トランジット遅延は、ほぼデータサイズをセグメントの伝送速度で割ったものになります。より正確なモデルが必要な場合は、フライトタイムラグを追加します-およそセグメントの長さをデータフローの速度（光の速度に近似）で割った値です。これは、衛星リンクが関係している場合に重要です。静止衛星までの上下は重要です。

各ノードの遅延は、モデルに配置する機器に基づいて推定する必要があります。

アプリケーションの待ち時間（たとえば、FTP転送のデータフローの開始までの遅延）が必要な場合は、ネットワークの待ち時間が発生する回数をカウントすることで構築します。たとえば、3ウェイTCPハンドシェイクでは、ネットワークのレイテンシが3倍になり、アプリケーションが見るものまで蓄積されます。

どちらかの側でパケットキャプチャを取得することでラウンドトリップレイテンシを推定し、監視対象のマシンから送信される要求と応答が返される間の遅延を測定できます。たとえば、SYNがリモートマシンに送信された時間をマークし、SYN + ACK応答が入った時間をマークすると、その差は、ラウンドトリップTCPレイテンシのかなり良い目安となります。

これは実際のネットワーク遅延よりも大きくなり、どれだけ大きくなるかはどちらかのマシンの負荷に依存することに注意してください。

2つのホスト間の遅延は、いくつかの要因に依存します。

• 伝播遅延
• シリアル化遅延
• キューイング/バッファリングの遅延

伝播遅延は、パケットが2つの場所の間を移動するのに物理的にかかる時間です。ファイバー内の光の速度は約200000 km / sです。私が住んでいるスウェーデンは約1570 kmなので、7.85ミリ秒になりますが、実際にはそれは鳥のビューを介した距離であるためです。

シリアル化遅延とは、物理メディア、つまりネットワークデバイス上のインターフェイスを介してパケットをシリアル化するのにかかる時間です。2 Mbit接続があり、パケットをシリアル化するのに6ミリ秒になる1500バイトのパケットを送信している場合（12000/2000000）。

キューイング/バッファリング遅延は、パケットがインターフェイスに送信される前にキュー/バッファに留まる時間です。インターフェイスの速度と使用されるバッファの大きさに応じて、これは次に何もしないか、大幅な遅延になる可能性があります。

それから、ホストがパケットを生成し、アプリケーションがそれらを処理するための遅延が発生します。HTTP遅延を測定するアプリケーションがあります。人々はウェブサイトをあきらめる前にあまり遅れをとらないので、それは重要な要素です。