web-dev-qa-db-ja.com

モバイルネットワークの待ち時間が長いのはなぜですか？どうすれば削減できますか？

モバイルネットワーキングテクノロジーが他の方法では利用できない領域でインターネットアクセスを取得するために使用されるのをますます目にしています。

モバイルネットワーキングは通常、主要なインターネット接続としてまだ実行可能ではありませんが、緊急時のフォールバックにはモバイルテクノロジーが適切なオプションのように見えます。

帯域幅は問題ではありません。HDSPAでは、数MBitの速度が可能で、適切なアップリンクを提供します。ただし、個人的な経験から、モバイルネットワークのインターネットリンク（GPRS、UMTSなど）のレイテンシは通常のDSLよりはるかに長い（UMTSの場合は200〜400 ms、GPRSの場合はさらに長い）ことを知っています。これはもちろん、VoIPや電話会議などの多くのアプリケーションに適していません。

  • この待ち時間はどこから来るのですか？
  • UMTSを低遅延アプリケーションで実行可能にするために、この問題を軽減できる利用可能なテクノロジーはありますか？

固有の技術的理由があるに違いないと思いますが、それは何ですか？データが無線で送信される方法と関係がありますか？ワイヤレス伝送が原因である場合、WLANのレイテンシがはるかに低いのはなぜですか？

networkinglatencymobile-devicesgprs
40
sleske

Ilya Grigorikの本「High Performance Browser Networking」は、まさにこれに答えています。モバイルネットワークに特化した章全体（7日）があります。この本は、高いパフォーマンスの問題はほとんど常にレイテンシに関係していると述べており、通常、十分な帯域幅がありますが、プロトコルが邪魔をします。 TCP slow start 、 Radio Resource Controller （RRC）または次善の構成である。モバイルネットワークでのみ遅延が発生している場合それは彼らが設計されている方法です。

本には典型的な待ち時間についての表があります：

表7-2。アクティブなモバイル接続のデータレートと遅延

世代|データレート|レイテンシ
 2G | 100〜400 Kbit/s | 300〜1000 ms 
 3G | 0.5〜5 Mbit/s | 100〜500 ms 
 4G | 1〜50 Mbit/s | 100ミリ秒未満

TCP=特徴的な3ウェイハンドシェイクまたはスロースタートは、有線接続に等しく影響するため、質問には実際には答えません。モバイルネットワークの遅延に実際に影響するものはIPの下のレイヤーです。IPの下のレイヤーの待ち時間が0.5秒の場合、TCPサーバーへの接続には1.5秒（0.5秒* 3）かかります。数字はかなり速く加算されます。前述のように、それはモバイルがアイドル状態ではないことを前提としています。ハンドセットがアイドル状態の場合、最初にネットワークに「接続」する必要があります。これは、リソースの予約をタワーと簡略化してネゴシエートする必要があります。 LTEでは50〜100ミリ秒、3Gでは最大数秒、以前のネットワークではそれ以上かかります。

図7-12。 LTEリクエストフローのレイテンシ

  1. コントロールプレーン レイテンシ：RRCネゴシエーションと状態遷移で発生する固定された1回限りのレイテンシコスト：アイドルからアクティブへの場合<100ミリ秒、休止状態からアクティブへの場合<50ミリ秒。
  2. ユーザープレーン レイテンシ：デバイスと無線タワー間で転送されるすべてのアプリケーションパケットの固定コスト：<5ミリ秒。
  3. コアネットワークレイテンシ：無線塔からパケットゲートウェイにパケットを転送するためのキャリア依存のコスト：実際には30〜100ミリ秒。
  4. インターネットルーティングレイテンシ：キャリアのパケットゲートウェイと公衆インターネット上の宛先アドレス間の変動レイテンシコスト。

実際には、デバイスが接続状態になると、デプロイされた多くの4Gネットワ​​ークのエンドツーエンドのレイテンシは30〜100 msの範囲になる傾向があります。

したがって、1つのリクエストに対して必要です（図8-2。「単純な」HTTPリクエストのコンポーネント）：

  1. RRCネゴシエーション50-2500 ms
  2. DNSルックアップ1 RTT
  3. TCPハンドシェイク1 RTT（既存の接続）または3 RTT（新しい接続）
  4. TLSハンドシェイク1-2 RTT
  5. HTTPリクエスト1-n RTT

そして実際のデータで：

表8-1。単一のHTTPリクエストのレイテンシオーバーヘッド

 | 3G | 4G 
コントロールプレーン| 200〜2,500ミリ秒| 50〜100 ms 
 DNSルックアップ| 200ミリ秒| 100 ms 
 TCPハンドシェイク| 200ミリ秒| 100 ms 
 TLSハンドシェイク| 200〜400 ms | 100〜200 ms 
 HTTPリクエスト| 200ミリ秒| 100 ms 
合計遅延オーバーヘッド| 200〜3500 ms | 100〜600 ms

さらに、モバイルネットワークで適度に実行したいインタラクティブアプリケーションがある場合、Nagleアルゴリズムを無効にして実験することができます（カーネルは、複数の小さなパケットを送信するのではなく、データが大きなパケットに合体するのを待ちます）、それをテストする方法を探します https://stackoverflow.com/a/17843292/869019 にあります。

Velocity Conferenceが後援する https://hpbn.co/ には、誰でも無料で本全体を読むオプションがあります。これは非常に強く推奨される本で、ウェブサイトを開発している人だけでなく、ネットワークを介してクライアントにバイトを提供するすべての人に役立ちます。

46
Jorge Nerín

「セルラーブロードバンド」テクノロジーを使用する場合に発生する可能性のあるレイテンシの大部分は、多くの事柄の複合的な問題であると思います。

距離はありますが、syneticon-djが述べたように、実際には往復時間のごく一部にすぎません。

ここで考慮すべき点があります...顧客（特に自宅または中小企業の顧客）として経験する遅延は、少なくともある程度は、おそらく人為的に引き起こされます。 M2Mの利用、SCADAなどの3GおよびGSM通信のクラスがあり、これらにより、信頼性が向上し、伝送遅延が低減される場合があります。その結果、それらは通常法外に高価です。

つまり、基本的に、トラフィックシェーピングに反対しています。 ISP/Telcoは、より良い料金の顧客を優先するためにそれを行っているか、接続しているセルが少しビジーであるか、ネットワーク全体が少し遅い（2012年1月1日00:00 GMTを試してください。例）。

しかし、これを回避する方法はありますが、少しこっそりです。トラフィックがモバイルWWANを経由する前に、基本的にTCP接続プロキシが必要です。実際のACKはISPによって遅延される可能性があるため、このプロキシは基本的に偽装ACKをアプリケーションに送信しますトラフィックシェーピング。
明らかに疑わしいですが、多くの衛星プロバイダーはこのメカニズムを使用して、レイテンシを実際よりも低く見せています。

4
Tom O'Connor

ちょっとゲームに遅れましたが、パフォーマンスカレンダーのトピックに関する記事をチェックしてみてください： http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-リンク/

tl; dr-モバイルレイテンシの主要な部分は、バックホールでの最適化されていないルーティングによるものです。

2
r0u1i

携帯電話のモデムテクノロジーは、オープンエア通信の性質上、レイテンシが高くなります。通常、WLANの伝送距離は、他のテクノロジーよりもはるかに短いため、レイテンシが低くなります。

1
Isaac Butt