「200 バイトを送信すると、120 バイトと 60 バイトが別々に取得される可能性があると想定する必要がありますか?」
UDP データグラムを送信する場合、読み取りサイズは書き込みサイズと同じになります。これは、TCP のストリームプロトコルに対して UDP がデータグラムプロトコルであるためです。ただし、パケットがルーターによってフラグメント化またはドロップされる前に、MTU のサイズまでしかデータを書き込むことができません。一般的なインターネットの使用では、安全な MTU はヘッダーを含めて 576 バイトです。
「同じポートで別の接続が不正なデータを送信することを心配する必要がありますか?」
接続はありません。ポートがあります。そのポートに送信されたデータは、送信元に関係なく受信されます。それが正しいアドレスからのものかどうかを判断するのはあなた次第です。
通常、データが届かない場合、（通常）データが表示されない時間はどれくらいですか（250ミリ秒？1秒？1.75秒？）
データは永遠に失われる可能性があり、データが遅延する可能性があり、データが順不同で到着する可能性があります。 これらのいずれかが気になる場合は、TCP を使用してください。 UDP の上に信頼できるプロトコルを作成することは非常に簡単な作業ではなく、ほとんどすべてのアプリケーションでそうする理由はありません。
別の接続が同じポートに不良データを送信することを心配する必要がありますか？
はい、あなたはそれについて心配する必要があります。どのアプリケーションも、開いているUDPポートにいつでもデータを送信できます。recvfromUDPの大きな用途の1つは、ピアを区別するために、中に渡されたアドレスを使用して、単一のポートで複数のピアとの通信を多重化する多対1スタイルの通信です。
ただし、これを回避し、単一のピアからのパケットのみを受け入れる場合は、実際にconnectUDPソケットで呼び出すことができます。これにより、IPスタックは、通信するホスト以外のhost：portコンボ（ソケット）からのパケットを拒否します。
UDPソケットで呼び出すことの2番目の利点はconnect、多くのOSで速度/遅延が大幅に改善されることです。接続されていないUDPソケットを呼び出すsendtoと、OSは実際に一時的にソケットに接続し、データを送信してからソケットを切断し、かなりのオーバーヘッドを追加します。
接続されたUDPソケットを使用する3番目の利点は、クラッシュが原因で不明なルーティングやホストなど、アプリケーションにICMPエラーメッセージを受信できることです。UDPソケットが接続されていない場合、OSはネットワークからICMPエラーメッセージを配信する場所を認識せず、サイレントに破棄します。クラッシュしたホストからの応答を待っている間（またはタイムアウトするように選択します）。
パケットが届かない場合があります。
パケットが 2 回またはそれ以上の頻度で到着する場合があります。
パケットが正しくない可能性があります。
基盤となるネットワーク層によってパケットにサイズ制限が課せられています。パケット サイズは非常に小さい場合があります (おそらく576バイト)。
これには、「UDPを使用しないでください」とは書かれていません。ただし、上記のすべてを認識し、どの回復オプションを使用するかを検討する必要があります。
断片化と再構成は IP レベルで行われるため、心配する必要はありません(Wikipedia)。(これは、分割または切り捨てられたパケットを受信しないことを意味します)。
UDP パケットにはデータとヘッダーのチェックサムがあるため、偽のデータを受信する可能性は低いですが、可能です。パケットが失われたり重複したりする可能性もあります。いずれにしても、データを確認する必要があります。
輻輳制御がないため、多数の UDP パケットでチューブを詰まらせる予定がある場合は、これを考慮する必要があります。
UDP はコネクションレス プロトコルです。UDP 経由でデータを送信すると、受信者に到達する可能性がありますが、送信中に失われる可能性もあります。UDP は、オーディオやビデオのブロードキャストやストリーミングなどに最適です (つまり、これらの状況ではパケットのドロップは問題になりません)。そのため、データが確実に相手側に届くようにする必要がある場合は、TCP を使用してください。
UDP は TCP よりもオーバーヘッドが少ないため、高速です。(TCP は最初に接続を確立する必要があり、データパケットのデータ破損もチェックしますが、これには時間がかかります。)
断片化された UDP パケット (約 0.5 Kb より大きいパケット) はおそらくルーターによって破棄されるため、データを送信する前に小さなチャンクに分割してください。（場合によっては、OSがそれを処理できます。）成功するかどうかは常にパケットであることに注意してください。ハーフ パケットは処理されません。
長距離での遅延は非常に大きくなる可能性があります。データの再送信を行いたい場合は、現在の接続での経過時間の 5 倍から 10 倍の遅延時間を使用します。(いくつかのパケットを送受信することで、レイテンシーを測定できます。)
お役に立てれば。
これに答えた他の人たちには従いません。彼らは皆、あなたを TCP に向かわせているようです。ログイン/チャット情報を除いて、それはゲーム用ではありません。順番に行きましょう：
ソケット内の不良データについて心配する必要はありますか?
はい。UDP にはルーターなどの非常に単純なチェックサムが含まれていますが、100% 効率的ではありません。独自のチェックサム デバイスを追加できますが、ほとんどの場合、信頼性が問題にならない場合に UDP が使用されるため、準拠していないデータは削除する必要があります。
200 バイトを送信すると、120 バイトと 60 バイトが別々に取得される可能性があると想定する必要がありますか?
いいえ、UDP は直接データの書き込みと読み取りを行います。ただし、データが大きすぎると、ルーターによっては切り捨てられ、データの一部が完全に失われます。一部の人は、ヘッダーで約 576 バイトと言っていましたが、個人的には 256 バイトを超えて使用することはありません (ナイス ラウンド log2 数値)。
同じポートで別の接続が不正なデータを送信することを心配する必要がありますか?
UDP はポート上の任意のコンピュータからの任意のデータをリッスンするため、この意味ではイエスです。また、UDP はプリミティブであり、生の形式を使用して送信者を偽造できることにも注意してください。そのため、リスナーが IP に対して送信者を検証するには、ある種の「キー」を使用する必要があります。
通常、データが届かない場合、(通常) どれくらいの時間 (250 ミリ秒? 1 秒? 1.75 秒?) データが表示されない可能性がありますか?
UDP で送信されるデータは通常使い捨てであるため、データを受信しない場合は簡単に無視できます...ただし、「半信頼性」が必要な場合もありますが、TCP が使用するような「順序付けされた信頼性」は必要ありません。 1 秒は、ドロップの適切な見積もりです。ローテーションでパケットに番号を付け、独自の ACK 通信を作成できます。パケットが受信されると、番号が記録され、受信したパケットを送信者に知らせるビットフィールドが返されます。詳細については、この未完成のドキュメントを読むことができます (未完成ですが、それでも有効な情報が得られます)。
UDP を使用する際に知っておくべき重要なことは次のとおりです。
パケットがすべて回線を通過するとは限りません。つまり、データが破損する可能性があります。
機能を提供するために 100% のデータが確実に到着する必要があるアプリケーションで作業している場合は、TCP を使用します。いくらかの損失が許容されるアプリケーション (ストリーミング メディアなど) で作業している場合は、UDP を使用しますが、パイプの 1 つから別のパイプにすべてが完全に到達するとは思わないでください。
UDP と TCP に適したアプリケーションの違いを見る 1 つの方法は、TCP はデータ配信が「遅くないよりはまし」である場合に優れており、UDP はデータ配信が「決して遅くないよりはまし」である場合に優れているということです。
もう 1 つの側面は、ほとんどの UDP ベースのアプリケーションのステートレスでベスト エフォート型の性質により、スケーラビリティの達成が少し容易になるということです。また、UDP はマルチキャストできますが、TCP はできません。
TCP を使用するという don.neufeld の推奨に加えて。
ほとんどのアプリケーションでは、TCP の方が実装が簡単です。TCP ストリームでパケット境界を維持する必要がある場合は、データの前に 2 バイトのヘッダーを送信してメッセージを区切ることをお勧めします。ヘッダーにはメッセージの長さが含まれている必要があります。受信側では、2 バイトを読み取って値を評価するだけです。次に、そのバイト数を受信するまで待ちます。これで完全なメッセージが得られ、次の 2 バイト ヘッダーを受信する準備が整います。
これにより、データの損失や順不同のパケット到着などの問題が発生することなく、UDP の利点の一部が得られます。
途中で一部のルーターによってパケット サイズの制限が課された場合、UDP パケットはそのサイズに切り捨てられる可能性があります。
また、パケットを送信した場合、そこに到達したと想定しないでください。
2つのこと：
1) 送信されたものを受信する場合と受信しない場合があります
2) 受け取ったものは、送信された順序とは異なる場合があります。