常見のTCP通信の20の質問-面接必須

一、OSI 参考モデルと TCP/IP 参考モデル#

図に示すように、OSI 参考モデルは 7 層モデルで、上から順にアプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、物理層です。TCP/IP モデルは OSI 参考モデルを基にして簡略化された 4 層モデルです。階層関係では、両者とも階層的な構造を採用しており、対等な階層間通信を行います。異なる点は、TCP/IP 参考モデルがより明確で簡潔な階層構造を持っていることです。機能的にはほとんど変わりませんが、いずれも 2 つ以上の端末間の通信を実現するためのものです。

二、TCP 通信はネットワークモデルのどの層に位置しますか？#

TCP（Transmission Control Protocol）は、接続指向、信頼性のある、バイトストリームベースのトランスポート層通信プロトコルです。OSI 参考モデルでも TCP/IP 参考モデルでも、TCP はトランスポート層に位置しています。TCP は、信頼性のないインターネット上でエンドツーエンドの信頼性のあるバイトストリームを提供するために特別に設計されたトランスポートプロトコルです。

三、接続指向、信頼性、バイトストリームとはどう理解すればよいですか？#

接続指向：TCP はポイントツーポイントの通信であり、UDP のように 1 つのホストから複数のホストに同時にメッセージを送信することはできません。つまり、1 対多の状況を実現することはできません。
信頼性：ネットワークリンクがどのように変化しても、TCP はパケットが受信側に到達することを保証します。
バイトストリーム：バイトストリームベースの通信であり、メッセージのサイズに関係なく送信することができます。また、メッセージは順序が保持され、前のメッセージが受信されていない場合は後続のバイトもアプリケーションレイヤに渡すことはできません。また、重複したパケットは自動的に破棄されます。

四、なぜ TCP プロトコルが必要なのですか？#

IP 層は信頼性がなく、パケットの配信や順序の保証、完全な配信を保証しません。したがって、ネットワークデータパケットの信頼性を確保するためには、トランスポート層の TCP プロトコルを使用する必要があります。

五、TCP と UDP の違いと関係は何ですか？#

TCP と UDP はいずれもトランスポート層のプロトコルですが、以下のような違いがあります：

接続メカニズム：TCP は接続指向のトランスポート層プロトコルですが、UDP は接続を必要としません。
サービス対象：TCP は 1 対 1 のポイントツーポイントのサービスですが、UDP は 1 対 1、1 対多、多対多のサービスをサポートします。
信頼性：TCP はデータの損失や重複を防ぎ、必要に応じてデータを到達させますが、UDP はデータの配信を保証しません。
輻輳制御、フロー制御：TCP には輻輳制御とフロー制御のメカニズムがありますが、UDP にはありません。

六、TCP ヘッダの解析#

TCP ヘッダは少なくとも 20 バイトを占め、ソースポート番号、宛先ポート番号、シーケンス番号、応答番号、制御ビット、チェックサムなどの情報を含んでいます。具体的な内容は以下の通りです：

七、TCP の 3 ウェイハンドシェイクを簡単に説明してください#

サーバーとクライアントの両方が CLOSE 状態にあります。
サーバーは最初に特定のポートをリッスンし、LISTEN 状態になります。
クライアントは SYN パケットを送信し、seq=x、SYN=1 となります。
サーバーは SYN+ACK パケットを返信し、seq=y、ack=x+1、SYN=1、ACK=1 となります。
クライアントは ACK パケットを返信し、ack=y+1、ACK=1 となります。

八、TCP の 4 ウェイハンドシェイクを簡単に説明してください#

サーバーとクライアントの両方が ESTABLISHED 状態にあります。

クライアントは接続を閉じる意図があり、FIN パケットを送信し、FIN_WAIT_1 状態に入ります。
サーバーは ACK パケットを返信し、CLOSED_WAIT 状態に入ります。
クライアントは ACK 応答パケットを受け取り、FIN_WAIT_2 状態に入ります。
サーバーはデータの処理が完了した後、FIN パケットをクライアントに送信し、LAST_ACK 状態に入ります。
クライアントは ACK 応答パケットを返信し、その後 TIME_WAIT 状態に入ります。
サーバーは ACK 応答パケットを受け取り、CLOSE 状態に入り、接続の終了が完了します。
クライアントは 2MSL（Maximum Segment Lifetime）の一定時間経過後、CLOSE 状態に自動的に入り、接続の終了が完了します。

九、なぜ TCP のハンドシェイクはちょうど 3 回ですか？#

TCP 接続の確立には、3 回のハンドシェイクがあれば理論的には十分です。2 回のハンドシェイクでは、過去の接続の確立を防ぐことができず、両者の不要なリソース消費が発生し、両者のシーケンス番号の初期化を同期させることができません。4 回のハンドシェイクは理論的には最小の信頼性接続の確立ですので、さらなる通信回数は必要ありません。

十、なぜ TCP のハンドシェイクには 4 回必要ですか？#

4 回のハンドシェイクのプロセスを通じて、クライアントとサーバーは相互に FIN パケットを送信し、接続を正常に閉じることができます。クライアントが FIN パケットを送信すると、クライアントはデータの送信を停止しますが、データの受信は継続します。サーバーはクライアントの FIN パケットに ACK パケットを返信し、データの送信と受信を継続します。サーバーがデータの送信を完了し、接続を閉じる意図がある場合、サーバーは FIN パケットをクライアントに送信し、クライアントは ACK パケットを返信します。最後に、クライアントが ACK パケットを受け取り、一定時間の経過後に接続を閉じるために TIME_WAIT 状態に入ります。この 4 回のハンドシェイクにより、接続の終了が正常に行われます。

十一、4 回のハンドシェイク中の TIME_WAIT 状態とは何ですか？#

まず、明確にする必要があるのは、アクティブに接続を閉じる側にのみ TIME_WAIT 状態が存在するということです。TIME_WAIT 状態が必要な理由は次の 2 つです：

同じポートに再接続する場合、サーバーがネットワーク間に残っているパケットを受信することを防ぐためです。
パッシブに接続を閉じる側が正しく閉じられることを保証するためです。つまり、最後の ACK がパッシブに接続を閉じる側に到達し、正常に受信されることを保証します。

十二、なぜ TIME_WAIT 時間は 2MSL ですか？#

MSL（Maximum Segment Lifetime）は、パケットがネットワーク上に存在できる最大時間です。MSL を超えると、パケットは破棄されます。たとえば、パッシブに接続を閉じる側が最後の ACK パケットを受信しなかった場合、タイムアウト後に FIN パケットを再送信するための時間が必要です。2MSL の時間は、パッシブに接続を閉じる側が再送信する時間を確保するために設定されています。Linux システムでは、2MSL のデフォルト値は 60 秒です。

十三、TCP の保持機能とは何ですか？#

保持機能は、一定の時間内に接続に関連するアクティビティがない場合に作動します。一定の時間間隔で、保持機能はプローブパケットを送信し、パケットには非常に少量のデータが含まれます。連続していくつかのプローブパケットが応答を受け取らない場合、現在の TCP 接続が失われたと判断し、カーネルは上位アプリケーションにエラーメッセージを通知します。

十四、接続が確立されている状態でクライアントが故障した場合、どのように対処しますか？#

この場合、TCP の保持機能が作動し、関連するパラメータには保持時間、保持プローブの回数、保持プローブの時間間隔などが含まれます。保持時間内にクライアントが応答しない場合、カーネルはエラーメッセージを上位アプリケーションに通知します。デフォルトでは、保持時間は 7200 秒、保持プローブの回数は 9 回、保持プローブの時間間隔は 75 秒です。これらのパラメータは手動で設定することもできます。

十五、TCP/IP プロトコルとソケットの関係は何ですか？#

ネットワークには、TCP/IP というプロトコルスタックがあります。これは、オペレーティングシステムの動作メカニズムのように、具体的な実装が必要であり、外部の操作インターフェースを提供する必要があります。これは、オペレーティングシステムが提供する標準のプログラミングインターフェース（例：Win32 プログラミングインターフェース）のようなものです。TCP/IP は、プログラマがネットワーク開発に使用するためのインターフェースであるソケットプログラミングインターフェースを提供するために存在します。

したがって、ソケットは TCP/IP と直接関係があるわけではありませんが、TCP/IP スタックをより簡単に使用するための抽象化を提供するために、TCP/IP に基づいて設計された基本的な関数インターフェース（例：Send、Listen など）を提供します。

十六、SYN 攻撃とは何ですか？#

TCP SYN 攻撃は、攻撃者が短時間で異なる IP アドレスを偽装して SYN パケットを生成することです。サーバーは SYN パケットを受信するたびに SYN_RCVD 状態に入りますが、未接続キュー（SYN キュー）がサーバーのリソースを占有し、正常なユーザーのサービスを妨げる可能性があります。

十七、SYN 攻撃を回避する方法はありますか？#

SYN 攻撃を回避するための 2 つの方法：

カーネルパラメータを変更してキューサイズを制御し、キューがいっぱいになった場合の処理方法を決定します。たとえば、キューがいっぱいになった場合、新しい SYN に対して直接 RST を返信して接続を破棄します。
キューがいっぱいになった後、新しい SYN を SYN キューに直接入れずに、まず Cookie 値を計算して送信し、後で ACK パケットの正当性を検証します。

十八、TCP サーバーソケットプログラミングのフローはどのようになりますか？#

サーバーはソケットを初期化し、ファイルディスクリプタを取得します。
サーバーは Bind を呼び出して IP アドレスとポートにバインドします。
サーバーは Listen を呼び出して接続を待ちます。
サーバーは Accept を呼び出してクライアント接続を確立します。
Send を使用してクライアントにメッセージを送信します。
Receive を使用してクライアントからメッセージを受信します。

十九、TCP クライアントソケットプログラミングのフローはどのようになりますか？#

クライアントはソケットを初期化し、ファイルディスクリプタを取得します。
クライアントは Connect を呼び出してサーバーに接続します。
接続が成功したら、Send を使用してサーバーにメッセージを送信します。
Receive を使用してサーバーからメッセージを受信します。