目次
質問: なぜ tcp は接続を確立するために 3 ウェイ ハンドシェイクが必要なのですか? 2 回行うことはできませんか?
パケットをキャプチャしてtcpのシーケンス番号と確認シーケンス番号を調べる
結論: 純粋な ACK パケットはシーケンス番号を消費しない
インタビューの質問 1: TIME_WAIT の掘り下げ分析はどこにありますか
インタビューの質問 2: 状態が TIME_WAIT 状態から CLOSED 状態に変わる前に、アクティブに切断している側が 2MSL 待機する必要があるのはなぜですか?
インタビューの質問 3: サーバー側に多数の TIME_WAIT 状態がある場合、プロセスをすばやく再起動するにはどうすればよいですか?
1.つながり志向
スリーウェイ ハンドシェイク:
まず、スリーウェイ ハンドシェイクがいつ行われたかを思い出してください。
結論 1:サーバーはリッスン状態にあり、クライアントは接続関数を呼び出してスリーウェイ ハンドシェイク フェーズに入る
結論 2:スリーウェイ ハンドシェイク フェーズでは、プログラマーは特に関与せず、クライアントとサーバー間の接続は TCP プロトコルによって行われます
1. 両当事者から送信されたデータ パッケージの名前
パケットをキャプチャすることで、次のスリーウェイ ハンドシェイクのパケット名を確認できます。
2. 両当事者の接続ステータス:
質問: なぜ tcp は接続を確立するために 3 ウェイ ハンドシェイクが必要なのですか? 2 回行うことはできませんか?
1.州ごとに説明する
アイデア: 2 回のハンドシェイク。クライアントは接続が確立されたと見なし、サーバーは接続が確立されていないと見なします。
2. サーバーが接続が確立されていないと判断するのはなぜですか?
3 番目の ACK がないと、サーバーは SYN+ACK パケットがクライアントに到達したかどうかを確認する方法がないためです。
3. パッケージの順序管理 (重要!!!)
最初に TCP_socket の内容を確認しましょう
サーバーとクライアントはネットワーク経由でデータを送信します。
結論は：
tcp は送信バッファと受信バッファを保持しており、send 関数で送信された内容は最初に tcp の送信バッファに置かれ、tcp は送信する機会を選択します (tcp は送信するタイミングと送信するデータの量を選択します)。 . rev 関数で受信した内容は tp の受信バッファから受信し、受信量は
プログラマが呼び出した recv 関数の第 3 パラメータによって決まります。
では、これはパッケージ管理とどのような関係があるのでしょうか?
上の図では、サーバーがクライアントにデータを送信するか、クライアントがサーバーにデータを送信するかに関係なく、2 つのことを保証する必要があります。
信頼できる: 確実に相手に到達できる必要があります
Ordered : アプリケーション層の場合、送信者が送信したデータは正常であり、受信者が受信したデータも正常です。
結論: TCP は信頼性と順序を確保する必要があります.TCP 送信者がデータを送信するとき、送信されたデータにはシリアル番号が付けられます。
シリアル番号と確認シリアル番号
サーバーがクライアントにデータを送信するとき、シリアル番号はありますか?
あるに違いない、シリアルナンバーが2セットある
パケットをキャプチャしてtcpのシーケンス番号と確認シーケンス番号を調べる
シリアル番号：送信者がデータを送信するとき、データのシリアル番号
確認シーケンス番号:受信者は、送信者が次にデータの送信を開始することを期待するシーケンス番号を送信者に通知します. 拡張された意味: 受信者は、シーケンス番号の前のコンテンツが受信されたことを確認するよう送信者に通知します
以前の HTTP データ パケットを直接分析し、内部の TCP 部分のみを分析できます。
トレースすることで取得できます：
このプロセスを分析しましょう。
面接の質問：
2 者間の接続を確立する過程で、シリアル番号は 0 から開始する必要がありますか?
必ずしもそうではありませんが、後で送信するデータが満たされている限り、前のシリアル番号に従って番号が付けられます。
結論: 純粋な ACK パケットはシーケンス番号を消費しない
前に書いた tcp_demo でこれをよりよく理解しましょう:
このプロセスを分析するためにパケット キャプチャを使用してみましょう
上記のプロセスを図にすると、
データを送信するとき、各バイトに番号が付けられます
ack = 送信者が送信したデータの開始シーケンス番号 + 送信者が送信したデータの長さ
2 つまたは 4 つの波
2.1 接続データパッケージの名称 両者の接続状態
強調: 接続が確立されると、両者は切断のアクションを開始できます
インタビューの質問 1: TIME_WAIT の掘り下げ分析はどこにありますか
クライアントは最初にサーバーに接続が切断されたことを通知します. この時点でサーバーに多数の TIME_WAIT 状態がある場合はどうすればよいですか?
1. クライアントが最初に切断要求をサーバーに送信するため、TIME_WAIT 状態はサーバーではなくクライアントに存在します。
2. インタビュアー、クライアントに TIME_WAIT 状態が多いことを尋ねますか? ----"最後の問題は、サーバーが最初に切断され、多数の TIME_WAIT 状態が発生していることが原因である可能性があります。それを解決するにはどうすればよいですか?
インタビューの質問 2:状態が TIME_WAIT 状態から CLOSED 状態に変わる前に、アクティブに切断している側が2MSL 待機する必要があるのはなぜですか?
インタビューの質問 3: サーバー側に多数の TIME_WAIT 状態がある場合、プロセスをすばやく再起動するにはどうすればよいですか?
ポートの再利用、setsockopt 関数を設定すると、この問題を解決できます。
