コンピュータネットワーク面接のよくある質問
トランスポートプロトコルの概要
コンピュータ ネットワーク アーキテクチャの物理層、データ リンク層、およびネットワーク層は、異種ネットワークを介してホストを相互接続する際に直面する問題を共同で解決し、ホスト間通信を実現します。
しかし実際には、コンピュータ ネットワーク内で通信する実際のエンティティは、通信の両端のホストにあるプロセスです。
異なるホスト上で実行されているアプリケーション プロセスに直接通信サービスを提供する方法は、トランスポート層のタスクです。トランスポート層プロトコルは、エンドツーエンド プロトコルとも呼ばれます。
トランスポート層は、基礎となるネットワーク コアの詳細を上位ユーザーから保護し、アプリケーション プロセスに、2 つのトランスポート層エンティティ間にエンドツーエンドの論理通信チャネルがあるかのように見せます。
トランスポート層には、TCP と UDP という 2 つの主要なプロトコルがあります。
- TCPの正式名は、Transmission Control Protocol (伝送制御プロトコル) です。これは、コネクション指向プロトコルと呼ばれます。これは、あるアプリケーションが別のアプリケーションにデータの送信を開始する前に、2 つのプロセスが最初にハンドシェイクを実行する必要があるためです。ハンドシェイクは論理的な接続です。 2 つのホスト間の実際のハンドシェイク。
- UDPの正式名称は User Datagram Protocol で、接続を制御するコネクションレス型のプロトコルとして知られています。IP電話、ビデオ会議、ライブブロードキャストなどのリアルタイムアプリケーションに適しています パケットの形で送信されるため効率が高く、たとえ破損したパケットが破損していることがわかっていても、パケットは破損しません再送信されました。
1. TCPの詳しい説明
TCP は、コネクション指向で信頼性の高いバイト ストリーム ベースのトランスポート層通信プロトコルです。
- 接続指向: 接続は「1 対 1」である必要があります。UDP プロトコルのように 1 つのホストが同時に複数のホストにメッセージを送信することはできません。つまり、1 対多は実現できません。 ;
- 信頼性: ネットワーク リンクでどのようなリンク変更が発生しても、TCP はメッセージが受信側に到達できることを保証します。
- バイト ストリーム: メッセージには「境界がない」ため、メッセージがどれほど大きくても送信できます。そして、メッセージは「順序付けされています。「前の」メッセージが受信されていない場合、たとえ後続のバイトを最初に受信したとしても、それをアプリケーション層にスローして処理することはできません。同時に、「重複」メッセージは処理できません。処理のためにアプリケーション層にスローされ、パケットは自動的に破棄されます。
0. TCPとUDPの利用シナリオ
TCP アプリケーション シナリオ:効率要件は比較的低いが、精度要件は比較的高いシナリオ。送信時にはデータの確認や再送、並び替えなどが必要となるため、UDPほど効率は高くありません。例: ファイル転送 (精度と要件は高いですが、速度は比較的遅い場合があります)、電子メールの受信、リモート ログインなどです。
UDP アプリケーション シナリオ:効率要件が比較的高く、精度要件が比較的低いシナリオ。例: QQ チャット、オンライン ビデオ、インターネット音声通話 (インスタント メッセージング、高速要件はありますが、時折の断続は大きな問題ではなく、ここでは再送信メカニズムはまったく使用できません)、ブロードキャスト通信 (ブロードキャスト、マルチキャスト)。
1. TCPプロトコルの簡単な説明
TCP は、データの送信前に接続を確立し、データの送信が完了したら接続を解放する必要があるコネクション指向の通信伝送を提供します。いずれかの当事者がもう一方の当事者にデータを送信するには、その前に 2 つの当事者間で接続を確立する必要があります。TCP/IP プロトコルでは、TCP プロトコルは信頼性の高い接続サービスを提供し、接続は 3 ウェイ ハンドシェイクを通じて初期化されます。
同時に、伝送制御プロトコル (TCP) はコネクション指向で信頼性の高いバイト ストリーム ベースのトランスポート層通信プロトコルであるため、TCP は全二重モードであるため、接続を閉じるには 4 つの波が必要です。
2. TCPパケットヘッダー
ネットワーク内で送信されるデータ パケットは 2 つの部分で構成されます。1 つはプロトコルで使用されるヘッダー、もう 1 つは上位層から送信されるデータです。ヘッダーの構造はプロトコル仕様によって詳細に定義されています。データ パケットのヘッダーには、プロトコルがデータを読み取る方法が明確に示されています。一方、ヘッダーを見れば、プロトコルや処理対象のデータの必要な情報が分かります。パッケージの最初の部分は契約書の表面のようなものです。
したがって、TCP プロトコルを学ぶ前に、まずネットワーク伝送における TCP の位置とそのプロトコルの仕様を知る必要があります。ネットワーク伝送における TCP ヘッダーの役割を見てみましょう: 下の図は TCP ヘッダー仕様の定義です
。これは、TCP プロトコルがデータを読み取って解析する方法を定義します。
TCP ヘッダーには、TCP プロトコルに必要なさまざまな情報が含まれています。以下で分析してみましょう。
-
TCP ポート番号:
TCP 接続には、一意の接続を決定するために 4 つの要素が必要です:
(送信元 IP、送信元ポート番号) + (宛先 IP、宛先ポート番号)。
そのため、TCP ヘッダーはポート番号のストレージとして 2 つの 16 ビットを予約します。 IP アドレスは上位層の IP プロトコルによって送信され、
送信元ポート番号と宛先ポートはそれぞれ 16 ビットと 2 バイトを占め、ポートの範囲は 2^16=65535 になります。また、次の
1024 1024 ～ 65535 はシステムによって予約されており、ユーザーが使用するポート範囲 -
TCP シーケンス番号と確認番号:
32 ビットのシーケンス番号 seq:シーケンス番号の略称 seq、TCP 通信における特定の送信方向のバイト ストリームの各バイトのシーケンス番号で、送信されたデータが正しいことを確認するために使用されます。 、今のように、シリアル番号は 1000 で、1000 が送信され、次のシリアル番号は 2000 です。
32 ビット確認番号 ack:確認番号 (ack と略します) は、最後の seq シーケンス番号に対して TCP によって作成される確認番号です。TCP セグメントに応答し、受信した TCP セグメントのシーケンス番号 seq に 1 を加算するために使用されます。 。 -
TCP フラグ
各 TCP セグメントには目的があり、これは TCP フラグ オプションを使用して決定され、送信側または受信側がセグメントが相手側で正しく処理されるようにどのフラグを使用するかを指定できます。
最も広く使用されているフラグは SYN、ACK、および FIN で、接続を確立し、セグメント転送が成功したことを確認し、最後に接続を終了するために使用されます。
SYN: S と略され、同期フラグ ビット、セッション接続と同期シーケンス番号を確立するために使用されます;
ACK: . と略され、確認フラグ ビット、受信したデータ パケットを確認します;
FIN: F と略され、完了フラグ ビット、データが存在しないことを示します送信するデータがあり、接続を終了しようとしている、
PSH: P と略され、プッシュ フラグであり、データ パケットが相手によって受信された後、バッファーにキューに入れられることなく、すぐに上位層アプリケーションに渡される必要があることを示します。 RST: R と省略され
、リロード 接続をリセットし、エラーおよび不正なデータ パケットを拒否するために使用されるフラグ ビットを設定します; URG:
U と省略され、データ パケットの緊急ポインタ フィールドが有効であることを示す緊急フラグ ビット接続がブロックされていないことを確認し、中間デバイスにできるだけ早く対処するよう促すために使用されます。
要約すると次のようになります。
- 送信元ポート番号/宛先ポート番号: データがどのプロセスから送信され、どのプロセスに送信されるかを示します。
- 32 ビットのシリアル番号:
- 4 ビットヘッダー長: TCP ヘッダーが 4 バイト (32 ビット) で何個あるかを示します。
- 6 桁の予約: 名前が示すように、念のために最初に予約されます。
- 6ビットフラグ
- 16 ビットのウィンドウ サイズ:
- 16ビットチェックサム：送信側が記入し、チェックフォームにはCRCチェックなどが含まれる 受信側がチェックに失敗した場合、データに問題があるとみなされます ここでのチェックサムにはTCPヘッダーだけでなく、だけでなく、TCP データ部分も含まれます。
- 16 ビット緊急ポインタ: データのどの部分が緊急データであるかを識別するために使用されます。
- オプションとデータは今のところ無視されます
3. TCP スリーウェイ ハンドシェイクによる接続の確立
いわゆる 3 ウェイ ハンドシェイクとは、TCP 接続を確立するときに、クライアントとサーバーが合計 3 つのメッセージを送信する必要があることを意味します。スリーウェイ ハンドシェイクの目的は、サーバーの指定ポートに接続し、TCP 接続を確立し、双方のシーケンス番号と確認番号を同期し、TCP ウィンドウ サイズ情報を交換することです。ソケット プログラミングでは、クライアントが connect() を実行するとき。スリーウェイ ハンドシェイクがトリガーされます。
3 ウェイ ハンドシェイク プロセスの概略図は次のとおりです。
三次握手
第一次:
客户端 - - > 服务器 此时服务器知道了客户端要建立连接了
第二次:
客户端 < - - 服务器 此时客户端知道服务器收到连接请求了
第三次:
客户端 - - > 服务器 此时服务器知道客户端收到了自己的回应
- 最初のハンドシェイク:
クライアントは、TCP メッセージ フラグSYN を 1 に設定し、シーケンス番号値 seq=J をランダムに生成し、それを TCP ヘッダーのシーケンス番号フィールドに格納します。これは、クライアントが接続するサーバーのポートを示します。 、データ パケットをサーバーに送信し、送信が完了すると、クライアントは SYN_SENT 状態になり、サーバーからの確認を待ちます。 - 2 番目のハンドシェイク:
データ パケットを受信した後、サーバーは、クライアントがフラグ ビット SYN=1 から接続の確立を要求していることを認識し、TCP メッセージ フラグ SYN と ACK の両方を 1、ack=J+1 に設定し、ランダムに設定します。シーケンス番号値 seq=K を生成し、接続要求を確認するためにデータ パケットがクライアントに送信され、サーバーは SYN_RCVD 状態に入ります。 - 3 回目のハンドシェイク:
クライアントは確認を受信した後、ack が J+1 であるかどうか、および ACK が 1 であるかどうかを確認します。それが正しければ、フラグ ACK を 1 (ack=K+1) に設定し、データ パケットを送信します。最後に、サーバーは、ack が K+1 であり、ACK が 1 であるかどうかを確認します。正しければ、接続は正常に確立されます。クライアントとサーバーは ESTABLISHED 状態に入り、3 ウェイ ハンドシェイクを完了します。その後、クライアントとサーバーは、データの送信を開始できます。
注:上で書いた ack と ACK は同じ概念ではありません。小文字の ack はヘッダーの確認応答番号を表し、省略形の ack は前のパケットのシーケンス番号を確認する番号 (ack=seq+1) です。大文字の ACK は、上で説明した TCP ヘッダーのフラグ ビットです。TCP パケットが前のパケットを確認したかどうかをマークするために使用されます。確認された場合、ACK フラグ ビットは 1 に設定されます。次に、独自の実験を行い、HTTP サービスを開き、ポート 80 をリッスンし、Tcpdump コマンドを使用してパケットをキャプチャし、TCP 3 ウェイ ハンドシェイク プロセスを見てみましょう
。実際の戦闘でのハンドシェイクプロセスの方法:
- 最初のハンドシェイクでは、クライアントはポート番号 51323 でサーバーのポート 80 に接続を開始しますが、このときのフラグ flags=S、つまり SYN=1 フラグは、サーバーへの接続の開始要求を示します。 、シーケンス番号 seq=84689409 が生成されます。
- 2回目のハンドシェイクでは、サーバフラグflags=[S.]、つまり最後の接続要求メッセージが確認されたことを示すSYN+ACKフラグが1に設定され、ack=seq+1=184689410が設定される。シーケンスを生成します。番号 seq=1893430205
- 3回目のハンドシェイクでは、クライアントはサーバーの応答を確認するため、このときのフラグビットは[.]、つまりACK=1となり、同時に前のメッセージのシーケンスの確認番号が返されます。 , ack=1893430206. この時点で 3 ウェイ ハンドシェイクが完了し、TCP 接続が確立された後、次のステップは両端からデータを送信することです。
4. スリーウェイ ハンドシェイクが必要なのはなぜですか?
クライアントによって送信された最初の接続要求メッセージ セグメントは失われずに、特定のネットワーク ノードに長時間留まったため、接続が解放されてからサーバーに到達するまでに一定の時間が経過するまで遅延したと想定します。これはすでに有効期限が切れたセグメントであることが判明しました。ただし、サーバーはこの無効な接続要求セグメントを受信すると、それがクライアントによって再度送信された新しい接続要求であると誤って認識します。したがって、確認メッセージ セグメントをクライアントに送信し、接続の確立に同意します。「スリーウェイ ハンドシェイク」が使用されていないと仮定すると、サーバーが確認を送信する限り、新しい接続が確立されます。クライアントは接続を確立するリクエストを発行していないため、サーバーの確認には注意を払わず、サーバーにデータを送信しません。しかし、サーバーは新しいトランスポート接続が確立され、クライアントがデータを送信するのを待っていると考えます。このようにして、サーバーの多くのリソースが無駄になります。したがって、「スリーウェイ ハンドシェイク」方式を使用すると、上記の現象の発生を防ぐことができます。たとえば、先ほどの状況では、クライアントはサーバーの確認に確認を送信しません。サーバーは確認を受信できないため、クライアントが接続の確立を要求しなかったことを認識します。
TCP の 3 方向ハンドシェイクは、実際に電話をかけるのとよく似ています。3 方向ハンドシェイク:
「ねえ、聞こえますか?」
「聞こえます、聞こえますか?」
「聞こえます、今日はバラバラです…」 3回の相互確認を経て、誰もが相手は自分の言うことを聞いていると思い、次のステップでコミュニケーションをとろうとします。そうでないと、会話が正常に続かない可能性があります。
なぜ 2 回使用しないのでしょうか?
主な理由は、失敗した接続要求メッセージが突然サーバーに再度送信されてエラーが発生するのを防ぐためです。接続を確立するために 2 つのハンドシェイクが使用される場合、クライアントによって送信された最初のリクエストが接続され、TCP の遅延によりネットワーク内に長時間留まりすぎたために失われなかったというシナリオがあるとします。クライアントは、確認メッセージを受信した後、サーバーがそれを受信していないと判断し、この時点でメッセージをサーバーに再送信します。その後、クライアントとサーバーは 2 回のハンドシェイクを通じて接続を完了し、データを送信し、その後、接続を閉じます。この時点では、ネットワークのブロックが解除されているため、以前に停止していた接続要求がサーバーに到達しています。このメッセージは無効であるはずです。ただし、2 ハンドシェイク メカニズムにより、クライアントとサーバーは再度接続を確立できるため、不要な接続が発生します。エラーとリソース料金。
3 ウェイ ハンドシェイクを使用する場合、無効なメッセージが送信された場合でも、サーバーは無効なメッセージを受信して確認メッセージを返信しますが、クライアントは再度確認を送信しません。サーバーは確認を受信しないため、クライアントが接続を要求しなかったことを認識します。
5. TCP は 4 回手を振って接続を閉じます
TCP 接続は 4 回手を振ることによって終了します。つまり、TCP 接続が切断されると、クライアントとサーバーは切断を確認するために合計 4 つのパケットを送信する必要があります。ソケット プログラミングでは、このプロセスはクライアントまたはサーバーが close を実行することによってトリガーされます。
TCP 接続は全二重であるため、各方向は個別に閉じる必要があります。この原則は、一方の当事者がデータ送信タスクを完了した後、FIN を送信してこの方向の接続を終了するというものです。FIN を受信するということは、単に FIN を受信することを意味します。データはこの方向に流れます。つまり、それ以上データは受信されませんが、FIN もこの方向に送信されるまで、この TCP 接続でデータを送信できます。最初にシャットダウンを行う側がアクティブ シャットダウンを実行し、もう一方がパッシブ シャットダウンを実行します。
4 つのウェイビング プロセスの概略図は次のとおりです:
ウェイビング リクエストはクライアントまたはサーバーによって開始できますが、クライアントによって開始されるものとします。
-
最初のウェーブ: クライアントはウェーブ リクエストを開始し、フラグ ビットをサーバー (FIN セグメント) に送信し、シーケンス番号 seq を設定します。この時点で、クライアントは FIN_WAIT_1 状態に入ります。サーバーに送信するデータ。
-
2 番目の分割: サーバーはクライアントから送信された FIN セグメントを受信し、フラグ ビット ACK を含むセグメントをクライアントに返します。ack は seq プラス 1 に設定されます。クライアントは FIN_WAIT_2 状態に入ります。サーバーはクライアントに伝えます。私は確認します。閉鎖リクエストに同意します。
-
3 番目の切断: サーバーは、フラグ ビット FIN を含むメッセージ セグメントをクライアントに送信して、接続を閉じるように要求し、クライアントは LAST_ACK 状態に入ります。
-
4 番目の分割: クライアントはサーバーから送信された FIN セグメントを受信し、ACK フラグを含むセグメントをサーバーに送信し、クライアントは TIME_WAIT 状態に入ります。サーバーはクライアントから ACK セグメントを受信した後、接続を閉じます。このとき、クライアントが 2MSL 待ってもサーバーから再送された FIN メッセージを受信しない場合は、サーバーが正常に閉じられたことを証明し、クライアントが接続を閉じることもできます。
データ転送が完了したら、双方とも接続を解放できます。
この時点では、クライアントとサーバーの両方が ESTABLISHED 状態にあり、クライアントはアクティブに切断し、サーバーはパッシブに切断します。
1. クライアント プロセスは接続解放メッセージを送信し、データの送信を停止します。
データ メッセージのヘッダー FIN=1 を解放し、そのシーケンス番号は seq=u (以前に送信したデータの最後のバイトのシーケンス番号に 1 を加えたものに等しい) このとき、クライアントは FIN-WAIT- に入ります。 1 ( 1 の待機を終了) 状態。TCP では、FIN セグメントがデータを伝送しない場合でも、シーケンス番号を消費することが規定されています。
2. サーバーは接続解放メッセージを受信し、確認メッセージ ACK=1、確認シーケンス番号は u+1、独自のシーケンス番号 seq=v を送信します。このとき、サーバーは CLOSE-WAIT (クローズ済み) に入ります。待機中))状態。
TCP サーバーは上位アプリケーション プロセスに通知し、クライアントはサーバーの指示で解放されます。この時点では、クライアントは送信するデータを持たないセミクローズ状態ですが、サーバーがデータを送信しても、クライアントはそれを受け入れる必要があります。この状態は、CLOSE-WAIT 状態全体の期間である一定期間継続します。
3. クライアントがサーバーから確認要求を受信した後、クライアントは FIN-WAIT-2 (終了待機 2) 状態に入り、サーバーが接続解放メッセージを送信するのを待ちます (この前に、最終データを受け入れる必要があります)サーバーによって送信されます）
4. サーバーは最後のデータの送信を完了した後、接続解放メッセージ (FIN=1、確認シーケンス番号は v+1) をクライアントに送信します。セミクローズ状態にあるため、サーバーはおそらくさらにデータを送信します。この時点でのシーケンス番号は seq=w であるとします。この時点で、サーバーは LAST-ACK (最終確認応答) 状態に入り、クライアントからの確認を待ちます。
5. サーバーから接続解放メッセージを受信した後、クライアントは確認 (ACK=1、確認シーケンス番号は w+1、自身のシーケンス番号は u+1) を送信する必要があります。このとき、クライアントは TIME を入力します。・WAIT（時間待ち）状態。この時点では TCP 接続は解放されておらず、CLOSED 状態に入る前にクライアントが対応する TCB をキャンセルする前に 2*MSL (最大セグメント寿命) が経過する必要があることに注意してください。
6. サーバーはクライアントから確認を受信するとすぐに CLOSED 状態に入ります。同様に、TCB を取り消した後、TCP 接続は終了します。サーバーがクライアントよりも早く TCP 接続を終了することがわかります。
6. 接続するときは 3 ウェイ ハンドシェイクが行われるのに、閉じるときは 4 ウェイ ハンドシェイクが行われるのはなぜですか?
接続を確立するとき、サーバーはクライアントから SYN 接続要求メッセージを受信した後、SYN+ACK メッセージを直接送信できます。ACK メッセージは応答に使用され、SYN メッセージは同期に使用されます。したがって、接続を確立するために必要なハンドシェイクは 3 回だけです。TCP プロトコルはコネクション指向で信頼性の高いバイト ストリーム ベースのトランスポート層通信プロトコルであるため、TCP は全二重モードです。
これは、接続が閉じられたとき、クライアントが FIN セグメントを送信したとき、それはクライアントがサーバーにデータが送信されたことを通知したことだけを意味することを意味します。サーバーが FIN メッセージを受信して ACK セグメントを返した場合、それはクライアントに送信するデータがないことがすでにわかっていることを意味しますが、サーバーはまだクライアントにデータを送信できるため、サーバーは、次のメッセージが返されるまですぐに SOCKET を閉じない可能性があります。サーバーにもデータが送信されました。
サーバー側も FIN セグメントを送信する場合、サーバー側には送信するデータがないことを意味し、送信するデータがないことをクライアント側に伝え、その後、双方が喜んで TCP 接続を中断します。
よくある回答:
接続を確立するとき、サーバーは LISTEN 状態にあり、接続を要求する SYN メッセージを受信した後、ACK と SYN を 1 つのメッセージに入れてクライアントに送信します。
接続を閉じるとき、サーバーが相手の FIN メッセージを受信したとき、それは相手がデータを送信しなくなったがまだデータを受信できることを意味するだけであり、すべてのデータを相手に送信していない可能性があるため、接続を閉じることができます。相手に何らかのデータを送信した後、相手に FIN メッセージを送信して、今すぐ接続を閉じることに同意することを表明するため、通常、自分の ACK と FIN は別々に送信され、結果的に 1 回送信されます。
7. なぜ 2MSL を待つ必要があるのでしょうか?
MSL: セグメントの最大存続期間。セグメントが破棄されるまでにネットワーク内に留まることができる最長時間です。
理由は 2 つあります。
最初のポイント: TCP プロトコルの全二重接続が確実に閉じられることを確認します。IP
プロトコルの信頼性の低さ、またはその他のネットワークの理由により、サーバーがクライアントから ACK メッセージを受信しない場合、サーバーは再送信します。クライアントの接続が閉じられており、この時点で CLOSED 状態にある場合、再送信された FIN は対応する接続を見つけることができず、接続が混乱します。そのため、クライアントは、FIN を送信した後に直接 CLOSED 状態に入ることができません。 TIME_WAIT を維持するために、FIN を再度受信するときに、相手が ACK を受信していることを確認し、最終的に接続を正しく閉じることができます。
2 番目のポイント: この接続の重複データ セグメントがネットワークから消えることを確認します。
クライアントが最終 ACK を送信して直接 CLOSED 状態に入り、その後サーバーへの新しい接続を開始した場合、新しく接続された接続が確実に行われるという保証はありません。接続のポート番号が異なる、つまり、新しい接続と古い接続のポート番号が同じである場合、問題が発生する可能性があります。以前の接続がネットワーク内でスタックしている場合、これらの遅延データは新しい接続が確立された後に到着します。クライアント側では、古い接続と新しい接続のポート番号と IP が同じであるため、TCP プロトコルは遅延したデータが到着するとみなします。は新しい接続に属しており、新しい接続はダーティ データを受信するため、データ パケットの混乱が発生します。したがって、TCP 接続は、この接続のすべてのデータがネットワークから確実に消えるように、TIME_WAIT 状態で MSL の 2 倍待機する必要があります。
一般的な説明:
MSL (最大セグメント存続期間。ネットワーク上にメッセージが存在できる最長時間です。この期間を過ぎると、メッセージは破棄されます。)、TCP では、実装ごとに異なる MSL 値を設定できます。
まず、クライアントによって送信された最後の ACK メッセージがサーバーに到達できることを確認します。この ACK メッセージは失われる可能性があるためです。サーバーの観点からは、切断を要求するために FIN+ACK メッセージを送信しましたが、クライアントはまだ存在します。私に応答がありません。私が送信した切断要求メッセージは受信されなかったはずです。そのため、サーバーはそれを再送信し、クライアントはこの 2MSL 時間内に再送信されたメッセージを受信して、応答メッセージを送信します。が送信され、2MSL タイマーが再起動されます。
2 番目に、「スリーウェイ ハンドシェイク」で言及されているものと同様の「無効な接続要求セグメント」がこの接続に出現しないようにします。クライアントが最後の確認メッセージを送信した後、この 2MSL 時間の間に、この接続中に生成されたすべてのメッセージ セグメントがネットワークから消える可能性があります。これにより、古い接続のリクエスト メッセージが新しい接続に表示されなくなります。
8. 接続は確立されているが、クライアントが突然失敗した場合はどうすればよいですか?
TCP にはキープアライブ タイマーがあり、クライアントに障害が発生した場合、サーバーは永遠に待機することができず、リソースを浪費することはできません。サーバーはクライアントからリクエストを受信するたびにこのタイマーをリセットします。この時間は通常 2 時間に設定されます。2 時間クライアントからデータを受信しなかった場合、サーバーは検出セグメントを送信し、75 秒ごとに検出セグメントを送信します。秒後、1分ごとに送信されます。プローブ メッセージを 10 回続けて送信しても応答がない場合、サーバーはクライアントに障害があると判断し、接続を閉じます。
2. TCP は信頼性を確保するためにどのようなメカニズムを使用しますか?
CP (Transmission Control Protocol) は、上位層アプリケーションにエンドツーエンドの接続指向通信サービスを提供する、接続ベースの信頼性の高いトランスポート層プロトコルです。次のメカニズムを通じてデータの信頼性が保証されます。
1. バイト ストリーム送信: TCP はバイト ストリーム送信を使用して、アプリケーション層によって送信されたデータをバイト単位のセグメント (セグメント) に分割し、それらにシーケンス番号をマークして、順序どおりのデータ送信を保証します。
2. 確認および再送信メカニズム: TCP は 3 ウェイ ハンドシェイクを使用して接続を確立し、通信プロセス中に確認および再送信メカニズムを使用して、データが効果的に送信されることを保証します。受信者はメッセージセグメントを受信すると、確認応答 (Ack) 操作を実行します。送信者が確認応答を受信しない場合、メッセージは再送信されます。
3. スライディング ウィンドウ メカニズム: TCP は、スライディング ウィンドウ メカニズムを使用してフロー制御と輻輳制御を実現します。送信側のウィンドウサイズを制限することで、送信速度が速すぎることによるパケットロスや受信側の処理の遅延などの問題を防ぎます。同時に、ネットワークの輻輳に応じてウィンドウ サイズを動的に調整して、ネットワークの安定性と信頼性を確保できます。
4. ヘッダー チェックサム: TCP 送信プロセス中に、送信中にデータが破損または改ざんされていないかどうかを検出するために、ヘッダー チェックサムが各メッセージ セグメントに追加されます。データの破損が判明した場合は、データの整合性と正確性を確保するために再送信されます。
TCP は上記のメカニズムにより、送信中のデータの信頼性を確保し、効率的で安定したものを提供するため、インターネットのトランスポート層プロトコルの重要な部分となっています。
1. 確認応答機構（ACK機構）
TCP はデータの各バイトに番号を付けます。これはシーケンス番号です。
各 ACK には、対応する確認シーケンス番号 (ack) が含まれています。これは、受信したデータと次回どこから送信を開始するかを送信者に伝えることを意味します。
たとえば、クライアントが 1005 バイトのデータをサーバーに送信し、サーバーからクライアントに返された確認シーケンス番号が 1003 の場合、サーバーはデータ 1 ～ 1002 のみを受信したことを意味します。
1003、1004、1005 は受信されませんでした。
このときクライアントは1003から再送信します。
2. タイムアウト再送メカニズム
ホスト A がホスト B にデータを送信した後、ネットワークの混雑などの理由により、データがホスト B に届かない場合があります。
ホスト A が特定の時間間隔内に B から確認応答を受信しない場合、ホスト A は再送信します。
ただし、ホスト A が確認応答を受信しない場合は、ACK が失われた可能性があり、
この場合、ホスト B は大量の重複データを受信することになります。
次に、TCP プロトコルはどのパケットが重複しているかを識別し、重複を破棄する必要があります。
このとき、前述のシリアル番号を使用すると、重複を簡単に削除できます。
タイムアウトはどのように決定されますか?
最も理想的な状況では、「この時間内に確認応答が返されなければならない」ことを保証するための最小限の時間を見つけます。
ただし、この時間の長さはネットワーク環境によって異なります。
タイムアウトの設定が長すぎると、全体的な再送効率に影響します。タイムアウトの設定が短すぎると、重複したパケットが頻繁に送信される可能性があります。
あらゆる環境で高パフォーマンスの通信を保証するために、TCP はこの最大タイムアウトを動的に計算します。
Linux (BSD Unix、Windows も同様) では 500ms 単位でタイムアウト制御されており、
再送信ごとのタイムアウト時間は 500ms の整数倍となります 1 回再送信しても応答が得られない場合は 2 秒お待ちください * 500ms後に再送する、
それでも応答がない場合は4500ms待って再送する、というように指数関数的に増えていき、一定回数の再送が累積すると、TCPはネットワーク異常または相手ホスト異常と判断し
、強制的に閉じられ、接続されます。
3. 引き違い窓
確認応答のメカニズムについて説明しましたが、送信されたデータ セグメントごとに ACK 確認応答が与えられ、ACK を受信した後、次のデータ セグメントが送信されます。
これには、特にデータの往復時間が長い場合にパフォーマンスが低下するという大きな欠点があります。
では、複数のデータセグメントを一度に送信できるのでしょうか?
例えば：
コンセプト：窓
ウィンドウ サイズとは、確認応答を待たずにデータを送信し続けることができる最大値を指します。
上の図のウィンドウ サイズは 4000 バイト (4 セグメント) です。
最初の 4 つのセグメントを送信する場合、ACK を待つ必要はなく、直接送信するだけです。
最初の ACK 確認応答を受信した後、ウィンドウは後方に移動し、データの 5678 番目のセグメントの送信を続けます。
この窓は後ろにスライドし続けるため、スライディングウィンドウと呼ばれます。
このスライディング ウィンドウを維持するために、オペレーティング システム カーネルは送信バッファを開いて、現在応答していないデータを記録する必要があります。
バッファから削除できるのはACKが確認できたデータだけですが、
パケットロスが発生した場合はどうやって再送すればよいのでしょうか？
今回は、次の 2 つの状況について説明します。
- データ パケットは受信されましたが、確認応答 ACK が失われました。
この場合、一部の ACK が失われたとしても、後続の ACK を使用して相手がどのデータ パケットを受信したかを確認できるため、大きな問題にはなりません。\
- パケットロス
メッセージの特定のセグメントが失われると、送信者は常に 1001 のような ACK を受信します。これは、送信者に「私が欲しいのは 1001 です」と思い出させるようなものです。
送信ホストが同じ「1001」応答を 3 回連続で受信した場合、対応するデータ 1001 ～ 2000 を再送信します。
このとき、受信側が1001を受信した後、再度返されるACKは7001です。
なぜなら、2001-7000 の受信側は以前に実際にそれを受信しており、受信側のオペレーティング システム カーネルの受信バッファに置かれていたからです。
この仕組みを「高速再送制御」（「高速再送」ともいいます）といいます。
4. フロー制御
受信側のデータ処理速度には限界があり、送信側の送信速度が速すぎると受信側のバッファが一杯になってしまいますが、このとき送信側が送信を続けるとパケットロスが発生し、パケット損失と再送信の連鎖反応。
したがって、TCP は、受信側の処理能力に基づいて送信側の送信速度を決定することをサポートしています。
この仕組みをフロー制御(Flow Control)といいます。
受信側は、受信できるバッファ サイズを TCP ヘッダーの「ウィンドウ サイズ」フィールドに入れます。
ACK を通じて送信側に通知します。
ウィンドウ サイズが大きいほど、ネットワークのスループットは高くなります。
受信側は、バッファがほぼいっぱいであることを検出すると、ウィンドウ サイズをより小さい値に設定し、送信側に通知します。
送信側がこのウィンドウ サイズの通知を受信すると、送信速度が遅くなります。
受信バッファがいっぱいの場合、ウィンドウは 0 に設定されます。
このとき、送信側はデータを送信しなくなりましたが、受信側が送信側にウィンドウ サイズを知らせるために、定期的にウィンドウ検出データ セグメントを送信する必要があります。
TCP ヘッダーには、ウィンドウ サイズ情報を格納する 16 ビット ウィンドウ サイズ フィールドがあります。
最大 16 桁の数字は 65536 を表します。つまり、最大 TCP ウィンドウは 65536 バイトですか?
実際、TCP ヘッダーの 40 バイト オプションには、ウィンドウ拡張係数 M も含まれています。実際のウィンドウ サイズは、M ビットだけ左にシフトされたウィンドウ フィールドの値です (1 ビットを左にシフトすることは、2 を乗算することに相当します)。 。
5. 輻輳制御
TCP にはスライディング ウィンドウという大きな欠点がありますが、大量のデータを効率的かつ確実に送信できます。
ただし、最初に大量のデータを送信すると、依然として問題が発生する可能性があります。
ネットワーク上には多数のコンピュータが存在するため、現在のネットワーク状況は非常に混雑している可能性があります。
現在のネットワークの状態を把握せずに、むやみに大量のデータを送信すると、状況がさらに悪化する可能性があります。
そこで、TCP ではスロー スタート メカニズムを導入し、最初に少量のデータを送信して経路を探索し、現在のネットワークの輻輳状態を理解した後、どの速度でデータを送信するかを決定します。ここで輻輳ウィンドウという概念が導入されてい
ます。
送信開始時に、輻輳ウィンドウ サイズを 1 として定義します。
ACK 応答が受信されるたびに、輻輳ウィンドウは 1 ずつ増加します。
データ パケットが送信されるたびに、輻輳ウィンドウと受信ホストからフィードバックされたウィンドウ サイズが比較され、小さい方の値が実際の送信ウィンドウとして使用されます。
上記のような輻輳ウィンドウの増加率は指数関数的です。
「スロースタート」とは、最初は遅いが、成長速度が非常に速いということだけを意味します。
急激に増加しないようにするために、スロー スタートと呼ばれるしきい値がここに導入されています。輻輳ウィンドウのサイズがこのしきい値を超えると、指数関数的に増加することはなくなり、直線的に増加します。TCP が開始されると、スロー スタートのしきい値は次の値に等しくなります
。ウィンドウの最大値まで
タイムアウトと再送信のたびに、スロー スタートしきい値は元の値の半分になり、輻輳ウィンドウは 1 にリセットされます。
少量のパケット損失の場合は、タイムアウトと再送信をトリガーするだけです。
大量のパケットが失われた場合、ネットワークの輻輳が考えられます。
TCP 通信が開始されると、ネットワーク スループットは徐々に増加します。
ネットワークの輻輳が発生すると、スループットがすぐに低下します。
輻輳制御は、最終的には、TCP プロトコルがデータをできるだけ早く相手に送信する一方で、ネットワークに過剰な負荷がかかるのを避けるという妥協的な解決策です。
3. UDPの詳しい説明
UDP は複雑な制御メカニズムを提供せず、IP を使用して「コネクションレス」通信サービスを提供します。
UDP の正式名は、ユーザー データグラム プロトコル (UDP、ユーザー データグラム プロトコル) で、アプリケーションが接続を確立せずにカプセル化された IP データ パケットを送信する方法を提供します。アプリケーション開発者が TCP ではなく UDP を選択した場合、アプリケーションは IP を直接処理することと同等になります。
UDP プロトコルの特徴は、コネクションレスで信頼性が低く、データグラム指向であることです。プロセス全体は手紙を送るプロセスに似ており、データを送受信するたびに、データ全体が送信されます。
- コネクションレス: ピアの IP とポート番号がわかれば、接続を確立せずに直接送信できます。
- 信頼性が低い: 確認メカニズムも再送信メカニズムもなく、ネットワーク障害によりセグメントを相手に送信できない場合、UDP プロトコル層はアプリケーション層にエラー メッセージを返しません。
- データグラム指向: データの読み取りおよび書き込みの数と量を柔軟に制御できない。
UDP プロトコルは非常にシンプルで、ヘッダーはわずか 8 バイト (64 ビット) で、UDP ヘッダーの形式は次のとおりです。
-
宛先ポートと送信元ポート: 主に、メッセージをどのプロセスに送信する必要があるかを UDP プロトコルに指示します。
-
パケット長: このフィールドには、UDP ヘッダーの長さとデータの長さの合計が格納されます。
-
チェックサム: チェックサムは、信頼性の高い UDP ヘッダーとデータを提供するように設計されています。
4. TCPとUDPの違い
1:接続する
- TCP はコネクション指向のトランスポート層プロトコルであり、データを送信する前に接続を確立する必要があります。
- UDP は接続を必要とせず、すぐにデータを送信します。
2: サービスオブジェクト
- TCP は 1 対 1 の 2 ポイント サービスです。つまり、接続には 2 つのエンドポイントしかありません。
- UDP は、1 対 1、1 対多、および多対多の対話型通信をサポートします。
3: 信頼性
- TCP は、エラー、損失、重複がなく、オンデマンドでデータを確実に配信します。
- UDP はベスト エフォート型の配信であり、信頼性の高いデータ配信を保証するものではありません。
4: 輻輳制御、フロー制御
- TCP には、データ送信のセキュリティを確保するための輻輳制御およびフロー制御メカニズムがあります。
- UDP はそうではなく、ネットワークが非常に混雑している場合でも、UDP の送信速度には影響しません。
5：初期費用
- TCP ヘッダーの長さは長く、ある程度のオーバーヘッドが発生します。オプション フィールドを使用しない場合、ヘッダーは 20 バイトですが、オプション フィールドを使用するとさらに長くなります。
- UDP ヘッダーはわずか 8 バイトで固定されているため、オーバーヘッドは小さくなります。
5、TCP および UDP アプリケーション シナリオ
TCP は接続指向であり、信頼性の高いデータ配信を保証できるため、次の用途によく使用されます。
- FTPファイル転送
- HTTP / HTTPS
UDP はコネクションレス指向であるため、いつでもデータを送信でき、UDP 自体の処理がシンプルで効率的であるため、次の用途によく使用されます。
- DNS、SNMPなどの少量のパケットによる通信。
- ビデオ、オーディオ、その他のマルチメディア通信
- ブロードキャスト通信
- IP テレフォニー、ビデオ会議、ライブ ブロードキャストなどのリアルタイム アプリケーションに適しています。