Java の udp プロトコルの簡単な紹介

この記事では主にUDPプロトコルの導入に関する関連情報を詳しく紹介しますので、興味のある方は参考にしてください

1. UDPの概要

UDPはトランスポート層プロトコルです。 UDPプロトコルはTCPプロトコルと同じ階層にありますが、TCPプロトコルとは異なり、タイムアウト再送やエラー再送などの機能がなく、信頼性の低いプロトコルです。

2.UDPプロトコルヘッダー

UDPポート番号

多くのソフトウェアはUDPプロトコルを使用する必要があるため、UDPプロトコルはさまざまなプログラムが必要とするデータを区別するために特定のフラグを使用する必要がありますバッグ。これはポート番号の働きです。例えば、ある UDP プログラム A がポート 3000 をシステムに登録すると、外部から入ってくる宛先ポート番号 3000 の UDP パケットはすべてこのプログラムに渡されます。理論的には、ポート番号は 2^16 まで可能です。その長さは 16 ビットであるため

UDP チェックサム

これはオプションのオプションであり、すべてのシステムが UDP パケットのチェックサム データを実行するわけではありません (TCP プロトコルと比較して、これは言わなければなりません)。 RFC では、送信者がチェックサムを計算する必要があります。

UDP チェックサムは UDP プロトコル ヘッダーとデータをカバーしますが、IP チェックサムとは異なり、IP プロトコル チェックサムは IP データ ヘッダーのみをカバーし、すべてのデータはカバーしません。 UDP と TCP には両方とも、チェックサムを計算する目的で撮影された疑似ヘッダーが含まれています。擬似ヘッダーには、IP アドレスなどの IP プロトコルに含まれる情報も含まれており、その目的は、UDP がデータが宛先に正しく到着したかどうかを 2 回確認できるようにすることです。送信者がチェックサム オプションをオンにせず、受信者がチェックサムの計算でエラーを出した場合、UDP データはエラー メッセージを生成せずに静かに破棄されます (配信は保証されません)。

UDP の長さ

UDP は、65535 バイトまで非常に長くすることができます。ただし、一般的なネットワークが送信する場合、通常、そのような長いプロトコルを一度に送信することはできません (MTU の問題を含む)。そのため、当然ながら、これらは UDP などの上位レベルのプロトコルに対して透過的であり、データを断片化する必要があります。 UDP は、IP プロトコル層を考慮する必要はありません。データをシャーディングする方法については、次の章でいくつかのシャーディング戦略について簡単に説明します。

IP フラグメンテーション

IP は上位層からデータを受信した後、IP アドレスに基づいて (ルーティングを通じて) どのインターフェイスからデータを送信するかを決定し、データ サイズの場合は MTU クエリを実行する必要があります。 MTU を超えている場合は、データシャーディングを実行するだけです。データの断片化は上位層と下位層に対して透過的であり、データは宛先に到着したときにのみ再構築されます。ただし、IP 層はデータの再構築に十分な情報を提供しますので、ご安心ください。

IP ヘッダーでは、16 ビットの識別番号が同じ ID を持つ IP スライスの ID を一意に記録し、13 ビットのスライス オフセットは IP スライスに対する相対的な位置を記録します。 ; パケット全体。これら 2 つの間の 3 ビットのフラグは、フラグメントの後ろに新しいフラグメントがあるかどうかを示します。これら 3 つのインジケーターは IP フラグメンテーションのすべての情報を構成し、受信者はこの情報を使用して IP データを再編成できます (後のフラグメントが前のフラグメントより前に到着した場合でも、この情報で十分です)。

インターネットではフラグメンテーション技術が頻繁に使用されているため、IP フラグメンテーション パケットを偽造して不正な攻撃を実行するソフトウェアや人物が後を絶ちません。

単純な MTU 検出には Trancdroute プログラムを使用できます。教科書を参照してください。

UDP と ARP 間の対話型の使用

これはあまり注目されない詳細であり、これは一部の体系的な実装向けです。 ARP キャッシュがまだ空の場合。 UDP が送信される前に、宛先ホストの MAC アドレスを取得するために ARP 要求を送信する必要があります。UDP データ パケットが十分に大きく、IP 層がそれをフラグメント化する必要がある場合は、UDP データ パケットの最初のフラグメントが ARP を発行すると想定します。クエリ要求を送信すると、すべてのフラグメントはクエリが完了するまで待機してから送信されます。これは実際にそうなのでしょうか？

その結果、一部のシステムでは各フラグメントが ARP クエリを送信し、すべてのフラグメントが待機状態になります。ただし、最初の応答を受信すると、ホストは最後のデータ フラグメントのみを送信し、残りのデータ フラグメントは破棄されます。この方法では、断片化されたデータを時間内に組み立てることができないため、受信ホストは一定期間内に組み立てることができない IP データ パケットを破棄し、組み立てタイムアウトを指定して ICMP メッセージを送信します (実際、多くのシステムでは、このエラーは生成されません) を使用して、受信ホスト自身のシンク バッファーが決してアセンブルされないフラグメントで満たされないようにします。

ICMPソース抑制エラー

ターゲットホストの処理速度がデータ受信速度に追いつかない場合、受信ホストのIP層キャッシュがいっぱいになるため、ホストは送信を送信します。 「我慢できません」という ICMP メッセージ。

UDP サーバーの設計

UDP プロトコルの一部の機能はサーバー プログラムの設計に影響を与えます。これは次のように大まかに要約できます。

1. クライアントの IP アドレスとアドレスについて: サーバーは、クライアントの IP アドレスとポート番号に基づいてデータ パケットが正当であるかどうかを判断する機能を備えている必要があります (これはすべてのサーバーで必要とされるようです)
2. 宛先アドレスについて:サーバーには、ブロードキャスト アドレス機能をフィルタリングする機能が必要です。
3. データ入力について: 通常、サーバー システムの各ポート番号は入力バッファーに対応しており、受信した入力は先着順でサーバーによる処理を待つため、必然的にバッファー オーバーフローの問題が発生します。この場合、アプリケーション サーバー プログラム自体が問題を認識することなく、UDP パケットがドロップされる可能性があります。
4. サーバーはローカル IP アドレスを制限する必要があります。これは、サーバー自体を特定のネットワーク インターフェイスの特定のポートにバインドできる必要があることを意味します。

以上がJava の udp プロトコルの簡単な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。