実用的な（理論上の）最大制限TCPパケットサイズ
私は業界にかなり新しいWeb開発者です。就職の面接でコーディングの課題が提示されました。メッセージングシステムを設計し、メッセージ、不正な形式のメッセージ、さまざまなメッセージタイプ、ステータスロギングなどを処理するシステムを設計する必要があります。
私の質問は、TCPを介したパケットサイズに関するものです。
着信メッセージは、メッセージあたり2KBのサイズで10,000メッセージ/秒の速度です。 max、max-safe、またはmax-practicalのパケットサイズ制限を見つけようとしています。いくつかの未確認の場所（つまり、技術文書にはない）で、理論上の最大サイズが64KBであることがわかりました。あれは正しいですか？その場合、2KBメッセージを送信する私の例は、1つのパケットに簡単に収まり、このシステムの複雑さを軽減します。
64KBが間違った数である場合、正しい数は何でしょうか？さらに、私は単に理論上の最大サイズではなく、実際の最大サイズを理解しようとしています。メッセージがターゲットの2KBよりわずかに大きい可能性があるエッジのケースをカバーし、TCPが必要とするさまざまなヘッダーのための余地を残したいと思います。
イーサネットは常にTCP/IPパケットサイズに影響を与えてきました。イーサネットの標準MTUは1500バイトで、通常のIPv4ヘッダーオーバーヘッドが20バイト、最新のTCPヘッダーオーバーヘッドが32バイト（以前は20バイトでしたが、現在は12バイトのタイムスタンプオプションが追加されています） ）、結果はTCP最大セグメントサイズ1448バイトになります。
DSLベースのISPで人気のあるPPPoEは、さらに8バイトのオーバーヘッドを追加するため、TCPリンクを通過するPPPoE接続は、最終的にTCPMSSになります。の1440バイト。他のテクノロジーは、より多くのオーバーヘッドを追加する可能性があります。
最新のTCP/IPスタックのほとんどは「パスMTUディスカバリー」（PMTUD）を実行するため、IPフラグメンテーションに依存する必要はありません。残念ながら、一部のサイトはPMTUDが機能するために必要なICMPメッセージをブロックし、PMTUDが機能しない「PMTUDブラックホール」を誤って作成します。 PMTUDブラックホールの背後にいる人々が引き続きサービスに接続できるようにするために、Googleサイトは非常に保守的なTCP MSS 1380バイト（前回チェックしたとき）をネゴシエートすることを選択します。
したがって、アプリケーションの書き込み方法を調整したい場合は、ほとんどの場合、単一のパケットのみを埋めるようにし、書き込みを1448バイト以下にし、おそらくはしないという、かなり良い議論をすることができます。 1380バイトより大きい。
IPv4データグラムは64KibiBytesまで大きくなる可能性がありますが、インターネット全体で64KiB MTUを持つパスは非常に少ないため、その数はほとんどのパケットサイズ計画とは無関係です。理論上のメッセージングプロトコルサーバーは、おそらく標準の1500バイトフレームを使用するイーサネットのようなネットワークに接続されているため、サーバーのIPスタックは、64KiBの書き込みを46程度の個別のパケットにフラグメント化してから、送信を開始する必要があります。最初のホップで。非標準の「ジャンボフレーム」を使用するように設定されているイーサネットネットワークでさえ、通常は9000バイトのMTUで最大になります。頭から離れて、64KiB MTUを可能にする物理/データリンク（レイヤー1/2）ネットワークテクノロジーに名前を付けることすらできません。たぶんIPoverThunderbolt。