私は、iPhone クライアントから大きな影響を受けるネットワーク サービスを設計するという、良い面と悪い面の両方を抱えた開発者です。この iPhone アプリは過去 1 年間で 1,000 万回以上ダウンロードされており、現在、ユーザー同士がオンラインでやり取りできるようにしています。
TCP ベースのネットワーク サービスをホストするサーバーの TCP 実装を調整したいと思います。送信されるリクエストごとのサイズは「小さい」ものになります (たとえば、256 バイト未満)。わかりましたね。これはゲーム サーバーです (驚きです!)。
ちなみに、この特定のサービスでは、ゲームが Quake のようなものではないため、UDP (または、たとえば ENet や RakNet で見られるような UDP 上の信頼性の高いレイヤー) には興味がありません。すべてのパケットを確実に受信する必要があり、そのために TCP が設計されています。したがって、iPhone クライアントとサービス間の接続は「長期間」持続します (可能な限り、トンネルやエレベーターは関係ありません)。
参考までに、私は Linux 2.6.18-164.9.1.el5 を実行するサーバー上で 100Mbps アップリンクでサービスを実行しています。
私の目標は、次のことを同時に達成することです。
- レイテンシを可能な限り低く抑える
- 接続されたクライアントごとに使用されるメモリの量を最小限に抑えます。
あります大きいTCP関連の調整すべきノブの数！基本的な調査を行った結果、ほとんどの人が設定をそのままにしておくことを推奨しているようです。しかし、思われる特定のケースに合わせて調整する必要があるようです。少し漠然としていることは承知していますが、だからこそ助けを求めているのです。
メモリを可能な限り最小限に抑えながら、不安定なネットワーク上の小さなリクエスト/レスポンスのチューニングを検討すべき事項は次のとおりです。
- TCP/IP実装に使用可能なメモリ
- 「nodelay」オプションを設定する（これは半リアルタイムのゲームサーバーなので、Nagleアルゴリズムを無効にする）
- 輻輳制御アルゴリズム
- など（他には何がありますか？）
TCPを検討する輻輳制御アルゴリズム:
- reno: 他のほぼすべてのOSで使用される従来のTCP
- キュービック: CUBIC-TCP
- bic: BIC-TCP
- htcp: ハミルトン TCP
- ラスベガス: TCP ラスベガス
- westwood: ロスのあるネットワーク向けに最適化
私のサーバーのデフォルトはビックその「目標は、強力な公平性、安定性、TCP フレンドリ性を維持しながら、高速長距離ネットワーク上でパフォーマンスを毎秒数十ギガビットまで拡張できるプロトコルを設計することです。」
ほんの少しの説明から、ウエストウッド「帯域幅と遅延の積が大きいパス (大きなパイプ)、伝送エラーやその他のエラーによるパケット損失の可能性 (リークのあるパイプ)、および動的負荷 (動的パイプ) をより適切に処理することを目的としている」ため、より適切に聞こえます。
私はここで深入りしすぎているのでしょうか、それともこれは当然のことなのでしょうか?
皆さんは一般的にどのような目的で TCP/IP を調整しますか? どのように調整しますか? 知っておくべき経験則は何ですか?
私の特定のケースに対して、どのような知恵の言葉をお持ちでしょうか?
どうもありがとう！
答え1
ご存知のとおり、TCP 輻輳制御は非常に複雑な領域です。
この特定のケースでは、リクエストが小さいため、接続をできるだけ開いたままにしておく必要があります。リクエストごとに 1 つの接続で 5 つのパケットが必要になるのに対し、接続を維持すれば平均を 2 パケット強にまで下げることができるからです。
NODELAY はゲーム サーバーに適しています。256 バイトをすぐに配信する必要がありますが、これはセグメント全体ではないため、NODELAY を使用しない限り Nagle は一時停止します。
サーバーに大量のメモリがある場合、メモリ オプションは大きな問題にはなりません。新しいカーネルには適切なメモリ オプションが組み込まれています。
輻輳制御アルゴリズムについては、Westwood を見つけました。もう 1 つのオプションは CUBIC です。1 つだけ使用することもできますし、調査してベンチマークすることもできます。これはかなりの作業になる可能性がありますが、1,000 万クライアントの場合は価値があります。したがって、トラフィック ジェネレーターを 1 台または 3 台の Mac (電話と同じ TCP 実装があるため)、ルーターとして機能する Linux ボックス (これについては後ほど詳しく説明します)、およびサーバーの 1 つを使用してシミュレーションを実行し、結果を確認することをお勧めします。
さて、中央のLinuxボックスはns-3イーサネットスイッチよりも複雑なパスをシミュレートできます。次に、TCP接続の送信側でパケットトレースをキャプチャし、tcpトレースまたは、wireshark の tcptrace グラフ モード。tcptrace ドキュメントは、TCP 輻輳の動作を分析するための優れた入門書です。