TCP はストリーム指向であるため、データは連続するバイト ストリームとして転送されます。しかし、私を混乱させているのは、TCP がセグメントを作成し、これを IP に渡すことです。IP はパケットを作成し、セグメントをカプセル化して転送します。では、連続したストリームは正確にはどこにあるのでしょうか?
一方、UDP はメッセージ指向です。アプリケーション層からメッセージを受信し、データグラムを作成して IP にプッシュします。ここまでは TCP と同じですが、代わりにデータグラムが作成されてプッシュされます。このプロトコルがメッセージ指向である理由は何ですか?
これらのプロトコルのユーザー (プログラマー) に提示されるインターフェイス/API は次のとおりです。
UDP
メッセージ指向の場合、1 つのデータグラムを送信し、1 つのデータグラムを受信する機能を提供する API (send/recv など) があります。send() を 1 回呼び出すと 1 データグラムが送信され、recv() を 1 回呼び出すと正確に 1 つのデータグラムが受信されます。
TCP
ストリーム指向で、バイト ストリームを送受信できる API (send/recv など) があります。メッセージの境界は保持されず、TCP は多くの send() 呼び出しからのデータを 1 つのセグメントにまとめることができます。または、1 つの send() 呼び出しからのデータを多くのセグメントに分割することもできますが、これは TCP の上にあるアプリケーションに対して透過的です。 recv() はデータを返すだけで、返されるデータを生成した send() 呼び出しの数とは関係ありません。
TCP は連続した形式でデータを組み立てることができるため、ストリーム指向です。たとえば、1 から 4000 バイトまでのデータがありました。これで、tcp セグメントに分割されます。各セグメントにはシーケンス番号があり、最初は 1 ～ 1200 バイト、2 番目は 1201 ～ 2400 などです。
ip データグラムを介して送信されている間は順不同で配信される可能性がありますが、後で連続したデータに組み立てられるため、ストリームとして表示されます。シーケンス番号は、パケットの並べ替えに役立ちます。
もう少し深い説明は次のとおりです。
バイト ストリームは、セグメントやその他の不規則性のない 1 つの大きなデータ チャンクで構成されます。データグラム (より小さい) では、データ チャンクが全体として一度に送受信されます。実際には、データグラムでは、各送信/書き込み呼び出しが 1 つのパケットを送信し、各読み取り/受信呼び出しが 1 つのパケットを受信することを意味しますが、ストリーム プロトコルでは、データを任意の方法で送受信できます。たとえば、送信者は send() を 10 回呼び出すことができますが、受信者は 1 回の recv 呼び出しでそのすべてのデータを受信します。データグラムでは、10 回の送信呼び出しは 10 個のパケットと 10 回の受信呼び出しを意味します
TCP は接続指向のプロトコルであり、最初に受信者への接続を設定し、次に IP パケットによって運ばれるセグメント (トランスポート層の PDU) でデータを送信します。このようにストリームと呼ばれるのは、転送中にエンド間のデータ ストリームを保持するためです。
UDP は、データグラムと呼ばれるデータ単位を使用するコネクションレス トランスポート プロトコル (IP と同様) です。そのため、tcp とは異なり、UDP は接続を設定せずにデータを転送するだけで、データグラム メッセージを IP 層に送信して転送します。
TCP の特徴は、この動作がユーザーに対して透過的であることです。アプリ。
アプリがしなければならない唯一のことは、データを送信して取得するためにsend()呼び出すことです。recv()
以下のレイヤーにより、データが送信された順序どおりに受信され、欠落しているデータが「欠落したまま」の場合は再送信されることが保証されます。
UDP、OTOH は、send()複数の IP パケットに分割されている場合でも、1 つの通話のデータをまとめて保持します。このように、これらのデータは 1 つのデータグラムとして見ることができます。
TCP と UDP はどちらもトランスポート層プロトコルであり、どちらも (クライアントからサーバーへ) 配信を処理するためのプロセスを提供しますが、サービスを提供する方法は互いに大きく異なります。UDP と TCP の主な違いは次のとおりです。UDP はコネクションレス サービスを提供しますが、TCP はコネクション型サービスを提供します。
それが TCP が信頼できる理由です。TCP をストリーム指向プロトコルと呼んだ理由は何ですか?
TCP プロトコルが送信または受信されるセグメントを追跡していることは周知のとおりです。これが信頼できる理由ですが、それでも TCP セグメント ヘッダーが表示された場合、セグメント ヘッダーにセグメント番号値のフィールドはありません。代わりに、シーケンス番号と確認番号と呼ばれる 2 つのフィールドがあります。これら 2 つのフィールドは、セグメント番号ではなく、バイト番号を参照します。
バイト番号: TCP は、接続で送信されるすべてのデータ バイト (オクテット) に番号を付けます。番号付けは各方向で独立しています。TCP がプロセスからデータのバイトを受信すると、TCP はそれらを送信バッファに格納し、番号を付けます。番号付けは必ずしも 0 から始まるとは限りません。代わりに、TCP は最初のバイトの番号として 0 から ((2)**32)−1 の間の任意の番号を選択します。たとえば、数値がたまたま 1,057 であり、送信されるデータの合計が 6,000 バイトである場合、バイトには 1,057 から 7,056 までの番号が付けられます。
シーケンス番号: バイトに番号が付けられた後、TCP は送信される各セグメントにシーケンス番号を割り当てます。各セグメントのシーケンス番号は、そのセグメントで運ばれるデータの最初のバイトの番号です。
TCP 接続が 5,000 バイトのファイルを転送しているとします。最初のバイトの番号は 10,001 です。データが 5 つのセグメントで送信され、それぞれが 1,000 バイトを運ぶ場合、各セグメントのシーケンス番号は何ですか?
セグメント 1 → シーケンス番号: 10,001 範囲: 10,001 から 11,000 セグメント 2 → シーケンス番号: 11,001 範囲: 11,001 から 12,000 セグメント 3 → シーケンス番号: 12,001 範囲: 12,001 から 13,000 セグメント 4 → シーケンス番号: 13,001 範囲: 13,001 から 14,000 セグメント 5 → シーケンス番号: 14,001 範囲: 14,001 ～ 15,000
これが、送受信されたすべてのバイトを追跡し、すべてのセグメントを確認するため、TCP をストリーム制御プロトコルと呼んだ理由です。
一方、なぜ UDP をメッセージ指向プロトコルと呼んだのでしょうか?
UDP はコネクションレス サービスを提供します。これは、各ユーザー データグラム (UDP パケット) が独立していて、送信元が同じで同じ宛先に送信されている場合でも、相互に関係がないことを意味します。コネクションレスであることの影響の 1 つは、UDP を使用するプロセスがデータのストリームを UDP に送信できず、UDP がそれらを (TCP のように) 関連するさまざまなユーザー データグラムに分割することを期待できないことです。代わりに、各リクエストは、1 つのユーザー データグラムに収まるほど小さくなければなりません。したがって、各データグラムには境界があり、メッセージは自己完結型であり、意味を持つことができます。そのため、UDP はメッセージ指向プロトコルとも呼ばれます。
詳細については、Behrouz A. Forouzan の TCP/IP プロトコル スイートの第 14 章と第 15 章をお読みください。
お役に立てれば！