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

モバイルネットワーキングテクノロジーがインターネットアクセスを取得するために使用されていることを、ますます見られなくなっています。

通常、モバイルネットワーキングはプライマリインターネット接続としてはまだ実行可能ではありませんが、モバイルテクノロジーは緊急フォールバックの良い選択肢のように見えます。

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

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

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

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

本には典型的なレイテンシーに関する表があります：

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

ジェネレーション| データレート| 待ち時間
2G | 100〜400 Kbit / s | 300〜1000ミリ秒
3G | 0.5–5 Mbit / s | 100〜500ミリ秒
4G | 1–50 Mbit / s | <100ミリ秒

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

図7-12。LTEリクエストフローの待ち時間

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

実際には、展開された多くの4Gネットワ​​ークのエンドツーエンド遅延は、デバイスが接続状態になると30〜100ミリ秒の範囲になる傾向があります。

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

1. RRCネゴシエーション50〜2500ミリ秒
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ミリ秒
DNSルックアップ| 200ミリ秒| 100ミリ秒
TCPハンドシェイク| 200ミリ秒| 100ミリ秒
TLSハンドシェイク| 200〜400ミリ秒| 100〜200ミリ秒
HTTPリクエスト| 200ミリ秒| 100ミリ秒
合計遅延オーバーヘッド| 200〜3500ミリ秒| 100〜600ミリ秒

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

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

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

距離はありますが、syneticon-djが述べたように、それは現実的には往復時間のごくわずかな割合にすぎません。

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

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

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

ゲームに遅刻しますが、トピックに関するパフォーマンスカレンダーの記事を参照してください：http : //calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/

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

携帯電話モデムテクノロジーは、屋外通信の性質により高いレイテンシーに悩まされます。WLANの伝送距離は、一般的にあなたが言及した他のテクノロジーよりもはるかに短いため、レイテンシーが低い理由の1つです。