UDPパケット長，UDPパケットの理論長
udpパケットの理論的な長さと適切なudpパケットは何ですか？TCP-IPの詳細第1章のudpパケットのヘッダーからわかるように、udpの最大パケット長は2 ^16 -1バイトです。udpヘッダは8バイトであり、IPレイヤでカプセル化されたIPヘッダは20バイトであるため、udpパケットの理論上の最大長は2 ^16 -1-8-20= 6550 7である。
しかし、これはudpパケットの理論的最大長です。まず、TCP/IPは通常、リンク層、ネットワーク層、トランスポート層、アプリケーション層を含む4層プロトコルシステムと考えられていることがわかりました。UDPはトランスポート層に属し、転送中にUDPパケット全体が下位層プロトコルのデータフィールドとして転送され、その長さは下位層IP層とデータリンク層プロトコルによって制限されます。
MTU関連の概念
イーサネットデータフレームの長さは、イーサネットの物理特性に応じて46-1500バイトでなければなりません。この1500バイトをリンク层の（Maximum Transmission Unit）と呼ぶ。インターネットプロトコルはIPシャーディングを許可しており、パケットを元のサイズよりも小さい最大伝送ユニットを持つリンクを通過するのに十分な小さな断片に分割することができる。このシャーディングプロセスはネットワーク層で行われ、リンク上のネットワークインターフェイスにパケットを送信する最大伝送単位の値を使用します。この最大伝送ユニットの値が（MaxTransUnit）である。これは、通信プロトコルのレイヤー上で通過できる最大パケットサイズ（バイト単位）を指します。最大伝送ユニットこのパラメータは、通常、通信インタフェース（ネットワークインターフェースカード、シリアルポートなど）に関連しています。
インターネットプロトコルでは、インターネット伝送路の“Path Maximum Transmission Unit”は、送信元アドレスから宛先アドレスまでの“パス”上のすべてのIPホップの最大伝送単位の最小値として定義されている。
** ループバックのMTUは上記の制限の対象ではないことに注意してください。ループバックのMTU値を参照してください。
[root@bogon ~]# cat /sys/class/net/lo/mtu
65536
IPサブスクリプションUDPパケット長の影響
上述したように、ネットワークインタフェースカードの制約のため、mtuの長さは1500バイトに制限されており、この長さはリンク層のデータゾーンを指す。この値を超えるパケットは断片化されるか送信できず、パケット交換ネットワークは信頼性が低く、パケット損失が発生します。IPプロトコルの送信者は再送信を行いません。受信側は、すべてのシャードを受け取った後にのみ再アセンブルして上位層プロトコル処理コードに送信できます。さもなければ、パケットはアプリケーションに破棄されたように見えます。
ネットワークパケット損失の確率が同じであると仮定すると、フラグメントが失われるとIPデータ全体が受信されなくなるため、大きなIPデータグラムは破棄される可能性が高くなります。MTUを超えないパケットはシャーディングの問題がありません
MTU値には、リンク層のヘッダとテールの18バイトは含まれません。したがって、この1500バイトはネットワーク層IPデータグラムの長さ制限である。IPデータグラムのヘッダは20バイトであるため、IPデータグラムのデータゾーン長は最大で1480バイトになります。この1480バイトは、TCPからのTCPメッセージセグメントまたはUDPからのUDPデータグラムを格納するために使用されます。また、UDPデータグラムのヘッダが8バイトであるため、UDPデータグラムのデータ領域の最大長は1472バイトである。この1472バイトは、使用できるバイト数です。
1472より大きいUDPデータを送信するとどうなりますか？つまり、IPデータグラムは1500バイトより大きく、MTUよりも大きい。このとき、送信側IP層はフラグメント化を必要とする。データグラムをスライスに分割し、各スライスがMTUより小さくなります。受信側IP層はデータグラムの再編成を行う必要がある.さらに深刻なことに、UDPの特性により、データ伝送の一部が失われると、受信側はデータグラムを再編成することができません。UDPデータグラム全体を破棄します。したがって，通常のローカルエリアネットワーク環境下ではUDPのデータを1472バイト以下に抑えることが望ましい.
インターネット上のルータはMTUを異なる値に設定する可能性があるため、インターネットプログラミングは異なります。MTUが1500でデータを送信すると仮定し、MTU値が1500バイト未満のネットワークを経由する場合、システムは一連のメカニズムを使用してデータグラムが宛先に到達できるようにMTU値を調整します。インターネット上の標準MTU値は576バイトであるため、インターネットのUDPプログラミングを行う場合、UDPのデータ長は548バイト（576-8-20）以内に制御することが望ましい。
UDPパケットパケット損失
UDPパケット損失は、ネットワークカードがパケットを受信した後、UDPパケット処理プロセスにおけるLinuxカーネルTCP/IPプロトコルスタックのパケット損失を指し、主に2つの理由があります。
UDPパケットのフォーマットが間違っているか、チェックサムチェックに失敗した。
アプリケーションがudpパケットを処理する時間がありません。
理由1については、udpパケット自体のエラーはまれであり、アプリケーションが制御できないため、本稿では説明しません。
まず、netstatコマンドと-suパラメータを使用する一般的なudpパケット損失検出方法を紹介します。
# netstat -su
Udp:
2495354 packets received
2100876 packets to unknown port received.
3596307 packet receive errors
14412863 packets sent
RcvbufErrors: 3596307
SndbufErrors: 0
上の出力から、“packet receive errors”を含む行があり、netstat-suを一定間隔で実行すると、行頭の数字が大きくなり、udpパケット損失が発生していることがわかります。
** アプリケーションが処理できない場合にudpパケット損失が発生する一般的な原因を以下に示します。**
1、linux内核socket缓冲区设的太小 # cat /proc/sys/net/core/rmem_default
# cat /proc/sys/net/core/rmem_max
ソケットバッファのデフォルト値と最大値を表示できます。
rmem_defaultとrmem_maxの設定はどれくらい適切ですか？サーバーのパフォーマンス圧力が大きくない場合、処理遅延は非常に厳しい要件ではなく、約1Mに設定することができます。サーバーのパフォーマンス圧力が大きい場合、または処理遅延に非常に厳しい要件がある場合は、rmem_defaultとrmem_maxを慎重に設定する必要があります。設定が小さすぎるとパケットロスが発生し、設定が大きすぎると雪だるまが発生します。
サーバーの負荷が高すぎ、大量のCPUリソースを占有し、Linuxカーネルソケットバッファ内のudpパケットをタイムリーに処理できず、パケットロスにつながります。
一般的に、サーバの負荷が高すぎる理由は2つあります。受信するudpパケットの数が多すぎることと、サーバプロセスのパフォーマンスボトルネックです。UDPパケットが多すぎる場合は、拡張を検討してください。サーバプロセスのパフォーマンスボトルネックは、パフォーマンス最適化のカテゴリーに属し、ここではあまり議論しません。
3.ディスクIOビジー
サーバには大量のIO 操作があり、プロセスがブロックされ、CPUはディスクIOを待っており、カーネルソケットバッファ内のudpパケットをタイムリーに処理できません。ビジネス自体がIO集約的な場合は、アーキテクチャの最適化を検討し、キャッシュを合理的に使用してディスクIOを削減します。
見落とされやすい問題があります。多くのサーバーはローカルディスクにログを記録する機能を持っています。運用と保守の誤動作により、ロギングレベルが高すぎるか、またはいくつかのエラーが突然多数表示され、ディスクへのログI/O要求が大きくなり、ディスクI/Oがビジーであり、udpパケットロスが発生します。
運用·保守の誤操作に対しては、運用環境の管理を強化し、エラーを防止できます。ビジネスが本当に多くのログを記録する必要がある場合は、メモリログまたはリモートログを使用できます。
物理メモリが不十分でスワップスワップが発生
スワップスワップは本質的にディスクIOビジーでもあり、特別で見落とされやすいため、個別に表示されます。
物理メモリの使用を計画し、システムパラメータを合理的に設定すれば、この問題を回避できます。
5ディスクがいっぱいになるとIOができない
ディスクの使用計画が不十分で、監視が不十分で、ディスクがいっぱいになった後、サーバプロセスがIOできず、ブロック状態になります。最も基本的なアプローチは、ビジネスデータやログファイルがディスクを埋め尽くすのを防ぐためにディスクの使用を計画し、ディスク使用率が80%に達したときに常に警告し、十分な応答時間を確保する汎用ツールを開発するなど、監視を強化することです。
UDPパケット受信能力試験
テスト環境。
プロセッサー Intel ® ® CPU X3440 @ 2.53 GHz、4コア、8ハイパースレッディング、ギガビットEthernet NIC、8Gメモリ
モデル1モデル
シングル、シングルスレッド非同期UDPサービス、ビジネスロジックなし、パケット受信操作のみ、UDPヘッダーに加えて、1バイトのデータ。
テスト結果は
1、単一のUDPパケット処理能力は、毎秒約150Wに達することができます。
処理能力はプロセス数の増加に伴い増加します。
処理がピークに達しても、CPUリソースは枯渇しません。
** 結論：**
UDPの処理能力は非常に大きいです。
現象2と現象3では、パフォーマンスのボトルネックはCPUではなくネットワークカードにあり、CPUの増加と処理能力の上昇は、パケット損失（UDP_ERROR）の数の減少によるものであることがわかります。
モデル2モデル
その他の試験条件はモデル1と同じで、UDPヘッダを除いて100バイトのデータがあります。
テスト結果は
100バイトのパケットサイズは、通常のビジネス状況に沿っています。
UDPの処理能力は非常に大きく、単一のピークは毎秒75Wに達することができます。
4または8プロセスでは、CPU占有率は記録されていません（ネットワークカードトラフィック枯渇）が、CPUが枯渇していないことは確かです。
プロセス数が増えるにつれて、処理能力は大幅に向上しませんが、パケット損失（UDP_ERROR）の数は大幅に減少します。
モデル3.
シングルマシン、単一プロセス、マルチスレッド非同期UDPサービス、マルチスレッドはfdを共有し、ビジネスロジックはなく、UDPヘッダーに加えて、1バイトのデータ。
試験結果：
1、スレッド数が増えるにつれて、処理能力は上下しません。
** 結論：**
複数のスレッドがfdを共有すると、かなりのロック競合が発生します。
マルチスレッドはfdを共有し、パケットがあるときにすべてのスレッドをアクティブにし、頻繁なコンテキスト切り替えを引き起こします。
** 結論：**
UDPの処理能力は非常に大きく、日常のビジネス状況では、UDPは一般的にパフォーマンスのボトルネックにはなりません。
プロセス数が増えるにつれて、処理能力は大幅に増加しませんが、パケット損失の数は大幅に減少します。
このテスト中、ボトルネックはCPUではなくネットワークカードにありました。
複数のプロセスやマルチスレッドが同じポートをリッスンするのではなく、複数のプロセスが異なるポートをリッスンするモデルを採用します。
まとめまとめまとめ
