TCP プロトコルと UDP プロトコルの違いと原則
最近、TCPとUDPの原理と違いを再理解して、簡単にまとめてみました。
1.機能
まず、tcp と udp はどちらもトランスポート層で動作し、プログラム間でデータを送信するために使用されます。データには通常、ファイル タイプ、ビデオ タイプ、jpg 写真などが含まれます。
2. 違い
TCP はコネクションベースですが、UDP はコネクションレスです。
TCP伝送データは安定性と信頼性が高く、ファイル転送やメール送信、Web閲覧など、高いネットワーク通信品質が要求され、相手への正確な送信が求められるシーンに適しています。
UDP の利点は高速であることですが、パケット損失が発生する可能性があるため、高いリアルタイム パフォーマンスは必要だが、少量のパケット損失に対する高い要件は必要ないシナリオに適しています。例: ドメイン名のクエリ、音声通話、ビデオ ライブ ブロードキャストなど。udp のもう 1 つの非常に重要なアプリケーション シナリオは、次のようなトンネル ネットワークです。
人と人とのコミュニケーションを例にとると、UDP プロトコルは相手に手紙を書くことに相当し、手紙を送った後は、相手が手紙を受け取ったかどうか、手紙の内容が完全であるかどうかはわかりません。タイムリーなフィードバックを得ることができますが、TCP プロトコルは電話をかけて通信することで、この一連のプロセスでタイムリーなフィードバックを得ることができ、相手はそれを時間内に確実に受け取ることができます。以下に示すように:
3. TCP通信プロセス：
tcp はどのようにして上記のプロセスを保証しますか?
スリーウェイハンドシェイク、送達確認、4 ウェーブの3 つのステップに分かれています。3 ウェイ ハンドシェイクは、接続を確立するプロセスです。
4. 3 回の握手:
クライアントがサーバーへの接続を開始すると、まず接続要求データのパケットが送信されます。接続を確立できるかどうか尋ねてください。このデータ パケットは SYN パケットと呼ばれます。ピアが接続に同意すると、SYN+ACK パケットで応答します。クライアントはそれを受信すると、ACK パケットを送信し、接続が確立されます。データ パケットが 3 つあるためです。このプロセスでは相互に送信されるため、これを 3 ウェイ ハンドシェイクと呼びます。
なぜ 2 方向ハンドシェイクではなく 3 方向ハンドシェイクなのでしょうか?
これは不正なリクエストメッセージが突然サーバーに送信されることによるエラーを防ぐためですが、 これはどういう意味ですか?
接続の確立に双方向ハンドシェイクが使用されているとします。クライアントは、サーバーに syn パケットを送信して、接続の確立を要求します。何らかの理由で、パケットはサーバーに到達せず、ネットワーク ノードでスタックします。接続を確立するために、クライアントは syn パケットを再送信しますが、今回はデータ パケットが正常に配信され、サーバーが syn+ack を送信した後に接続が確立されます。
しかし、最初のデータ パケットによってブロックされていたネットワークが突然回復し、最初の syn パケットがサーバーに配信されました。この時点で、サーバーはクライアントが新しい接続を開始したと認識し、その後データ待機状態に入ります。 2 つのハンドシェイクです。クライアントは 2 つの接続があると考えていますが、クライアントはそれが 1 つの接続であると考えているため、ステータスに一貫性がありません。サーバーが 3 ウェイ ハンドシェイク中に最後の ack パケットを受信しない場合、サーバーは当然のことながら、接続が 2 つあると認識しません。接続が正常に確立されました。
したがって、スリーウェイ ハンドシェイクは本質的に、信頼性の低いネットワーク チャネルの問題を解決し、信頼性の低いチャネル上で信頼性の高い接続を確立することを目的としており、スリーウェイ ハンドシェイクの後、クライアントとサーバーの両方がデータ送信状態に入ります。
5. データ送信
データ送信：
1 つのデータ パケットが複数のパケットに分割されて送信される場合があります。パケット損失の問題にはどのように対処しますか? これらのデータ パケットは異なる順序で到着します。順序外れの問題にはどのように対処しますか?
これらの問題に対応するため、TCP プロトコルではコネクションごとに送信バッファを設け、コネクション確立後の最初のバイトのシーケンス番号を 0 として、以降の 1 バイトごとにシーケンス番号を 1 ずつ増やしていきます。データ バッファはデータの一部を取得して送信メッセージを形成します。シーケンス番号と長さは TCP プロトコル ヘッダーに付加されます。受信側はデータを受信した後、確認メッセージで応答する必要があります。確認メッセージの ack は次のとおりです。受信したシーケンス番号に長さを加えたものに等しく、これは次のデータパケットを送信するための開始シーケンス番号でもあり、このような質疑応答の送信方法により、送信側は送信されたデータが受信されたことを確認できます。送信側は連続した複数パケットのデータを一度に送信することもできますが、受信側は一度ackを返信するだけで済みます。図に示すように:
6 つまたは 4 つの波:
接続状態にあるクライアントとサーバーの両方が接続を閉じるリクエストを開始できますが、この時点で接続を閉じるには 4 回のウェーブが必要です。クライアントが積極的に接続終了要求を開始すると仮定します。クライアントは FIN パケットをサーバーに送信して、接続が終了することを示します。終了待機 1 に入り、満たされます。サーバーは FIN パケットを受信し、ACK パケットをサーバーに送信します。シャットダウン待ち状態に入ったことを示すと、クライアントは終了待ち 2 状態に入ります。これは 2 番目の波です。この時点では、サーバーはまだ未送信のデータを送信でき、クライアントはデータを受信することもできます。サーバーが送信を終了した後、データを受信すると、FIN パケットを送信し、最後に確認状態に入ります。これが3 番目の波です。ACK パケットを受信した後、クライアントは ACK パケットを回復し、タイムアウト待ち状態に入ります。タイムアウト時間が経過すると、接続は確立されます。 Closed. ACK パケットを受信した後、サーバーはすぐに接続を閉じます。これは 3 回目です。4 回の波です。
なぜクライアントはタイムアウトまで待たなければならないのでしょうか? これは、クライアントが最後の ACK パケットを送信した後に接続を解放すると仮定すると、ネットワーク内で ACK パケットが失われると、サーバーは最終確認状態に留まるため、相手が ACK パケットを受信したことを確認するためです。このとき、サーバーは ACK パケットを受信していないため、FIN パケットを再送信します。クライアントは、FIN パケットに応答し、ACK パケットを再送信し、タイムアウトを更新します。このメカニズムは次のとおりです。 3回目の握手と同じです。また、信頼性の低いネットワーク リンクでの接続切断確認を確実に行うためでもあります。
7. UDPプロトコル
udp: まず第一に、udp プロトコルは非接続です。データを送信するには、単純なデータ パケットをカプセル化してネットワーク カードから送信するだけです。データ パケット間にステータスの接続はありません。 udp は処理方式が単純なため、パフォーマンスの低下が非常に小さく、CPU やメモリの使用量も tcp に比べてはるかに少ないですが、ネットワーク伝送時のパケットロスを保証できないため、伝送性能は tcp よりも劣ります。安定性。
したがって、tcp と udp の主な違いは次のとおりです。 Tcp 送信データは安定していて信頼性があり、高いネットワーク通信品質が要求され、相手に正確に送信する必要があるシナリオに適しています。たとえば、ファイルの転送、メールの送信、Web の閲覧などを行う場合、UDP の利点は高速であることですが、パケットロスが発生する可能性があるため、高いリアルタイム性が必要だが、リアルタイム性が低いシナリオに適しています。少量のパケット損失に対する高い要件。例: ドメイン名のクエリ、音声通話、ビデオ ライブ ブロードキャストなど。
udp のもう 1 つの非常に重要なアプリケーション シナリオは、VXLAN などのトンネル ネットワークです。