コンピュータネットワークの完了 (応答ページへの URL の入力から --> HTTP での一般的な面接の質問 --> TCP の 3 方向ハンドシェイクと手を振る --> TCP タイムアウト再送信およびその他の機能 --> IP アドレス)

1. 基本：URL入力から応答ページまで

1. URLを解析する

HTTPリクエスト情報の生成

URL を解析した後、ブラウザは Web サーバーとファイル名を特定し、その情報に基づいて HTTP リクエスト情報を生成します。

2.実アドレスクエリDNS

DNSサーバー:

最初のステップで URL を解析して対応する HTTP リクエスト情報を取得した後、HTTP リクエスト情報を対応するサーバーに送信する必要があります。まず対応する IP アドレスを取得する必要があります。Webサーバーのドメイン名とIPアドレスの対応関係を求めることで、対応するIPアドレスを取得することができます。同時に、対応関係がDNSサーバーに保存されます。

DNSサーバーのドメイン名の構造:

DNS サーバーのドメイン名は、www.alibaba.com のように . で区切られ、最後のドットはルートドメイン名を表します。

右に行くほどDNSドメイン名のレベルが高くなります。つまり、. はルート DNS サーバー、.com はトップレベルドメイン DNS サーバー、alibaba.com は権威 DNS サーバーです。

DNS サーバーはドメイン名プロセスを解決します。

1. まず、クライアントは www.alibaba.com の IP アドレスを尋ねる DNS リクエストを送信し、それをローカル DNS サーバーに送信します。

2. クライアントのリクエストを受信した後、ローカル DNS サーバーはまずキャッシュされたテーブルで www.alibabab.com の IP を検索します。見つかった場合は IP を直接返します。見つからない場合は、ローカル DNS サーバーはルートに問い合わせます。ルートドメイン名のドメインネームサーバー。サーバーはローカルドメインネームサーバーに .com の方向を返し、ローカルドメインネームサーバーは .com のトップレベルドメインネームサーバーにアクセスします。次に、トップレベルのドメインネームサーバーは、alibaba.com の権威ドメインネームサーバーに指示を返します。権限のあるドメインネームサーバーは、クエリされた IP アドレスをローカルドメインネームサーバーに伝えます。

キャッシュ：

まずブラウザ自体に対応するドメイン名のキャッシュがあるかどうかを確認し、ない場合はオペレーティングシステムにアクセスしてキャッシュを確認します。そうでない場合は、hosts ファイルを確認してください。最終的には、ローカルドメインネームサーバーにアクセスできなくなる場合があります。

3.プロトコルスタック

DNS を通じて対応する IP アドレスを取得した後、送信サービスをオペレーティングシステムのプロトコルスタックに引き渡すことができます。

プロトコルスタックの内部はいくつかの部分に分割されており、それぞれが異なるタスクを担当します。上下関係には一定のルールがあり、上は下に仕事を委任し、下は委託された仕事を受け取って実行します。

まず、ブラウザはソケットライブラリを呼び出してプロトコルスタックの作業を委任します。

プロトコルスタックの上部には、TCP プロトコルと UDP プロトコルという 2 つのプロトコルがあります。これらは、データの送受信操作を実行するためにアプリケーション層によって使用されます。

IP プロトコルは、ネットワークパケットの送受信操作を実行するために使用されます。インターネット上でデータを送信する場合、IP は IP データパケットを分割してネットワークパケットを相手に送信する役割を果たします。

ICMP: ネットワークパケットの送信中にエラーと制御情報を返すために使用されます。

ARP: IP アドレスに基づいて、対応する MAC アドレスを問い合わせます。

IP より下のネットワークカードドライバーはネットワークカードハードウェアの制御を担当し、最下位のネットワークカードは実際の送受信操作、つまりネットワークケーブル内の信号の送受信を完了する責任を負います。

4.TCP _

HTTPはTCPプロトコルに基づいて送信されます

1. 送信元ポート番号と宛先ポート番号

これら 2 つのポート番号がないと、データはどのアプリケーションに送信されません (ポート番号は受信アプリケーションを識別するために使用されます)。

2. シリアル番号

パケット障害の問題を解決するために使用されます

3. シーケンスを確認する

送信したデータが受信されたかどうかを確認することが目的です。パケットロスの問題を解決するために使用されます

4. ステータスビット

SYNリクエスト接続

ACK は受信を確認します

RST 再接続

FIN で接続が終了します

5. ウィンドウサイズ

TCP はフローを制御する必要があり、各パーティは現在の処理能力を識別するウィンドウ (キャッシュサイズ) を宣言します。

輻輳制御。独自の通信速度を制御するために使用されます。

スリーウェイハンドシェイク: HTTP データ送信の前に TCP 接続が必要です。これは 3 ウェイハンドシェイクです。

最初、サーバーはリッスン状態にあり、その後クライアントが積極的に接続を開始し、SYN をサーバーに送信します。その後、サーバーは SYN-SENT 状態になります。その後、クライアントは SYN を返し、クライアントの要求に対して ACK (受信確認) を返します。このとき、サーバーはACK-RCVD状態となり、クライアントはサーバーから送信されたSYN/ACKを受信後、確認のためACKを送信し、ESTABLISHED状態となります。サーバーは ACK それを受信した後、送受信も行っているため、状態にACK なります。ESTABLISHED

TCP 3 ウェイハンドシェイクは主に、双方が送受信できることを確認します。

断片化: HTTP リクエスト情報が長すぎる場合、TCP はデータパケットをデータの断片に分解して送信します。

メッセージの生成:

5.知財

TCP データパケットの接続、切断、送受信などを行う場合、IP モジュールにデータをネットワークパケットにカプセル化して通信オブジェクトに送信する必要があります。

送信元アドレス：データを出力するサーバーのIPアドレス

宛先アドレス: データを受信するサーバーの IP アドレス

HTTP は TCP プロトコルを通じて送信されるため、IP ヘッダーのプロトコル番号は 06 (16 進数を表す) である必要があります。

6.MACアドレス

MAC ヘッダーには、送信者の MAC アドレスと受信者の MAC アドレスが含まれている必要があります。2点間の伝送に使用します。

送信者の MAC アドレス: MAC アドレスはネットワークカードの製造時に ROM に書き込まれており、この値を読み取って MAC ヘッダーに書き込むだけで済みます。

受信者の MAC アドレス: ARP プロトコルを使用して、すべてのイーサネットデバイスにブロードキャストします。相手が自分と同じサブネット内であればMACアドレスを取得できます。

ARP キャッシュ: 最初に ARP キャッシュをクエリします。キャッシュ内に対応する MAC アドレスがある場合は、MAC アドレスが直接返されます。ARP ブロードキャストクエリがない場合は、

7.ネットワークカード

ネットワークパケットはメモリに格納されたバイナリ情報の文字列にすぎず、それを相手に直接送信する方法はありません。したがって、デジタル情報を電気信号に変換する必要があります。ネットワークケーブルを介して送信できます。

これを担うのがネットワークカードであり、ネットワークカードを制御するにはネットワークカード制御プログラムが必要です。

ネットワークカードドライバーはネットワークパケットを取得すると、それをネットワークカードのバッファー領域にコピーし、ヘッダーとそのヘッダーの前に開始フレーム区切り文字を追加します。エラーを検出するために最後にフレームチェックシーケンスを追加します

開始フレーム区切り文字もパケットの始まりを示します。

最後のFCSはパッケージが破損していないかをチェックするために使用されます

最後に、ネットワークカードはネットワークパケットを電気信号に変換して送信します。

8.スイッチ_

スイッチはMAC層で動作します

まず、受信した電気信号をデジタル信号に変換します。次に、ネットワークパケットの FCS を介して、ネットワークパケットにエラーがあるかどうかを確認します。問題がなければ、ネットワークパケットを直接バッファに入れてください。

パソコン自体はMACアドレスを持っていますが、受信したMACアドレスが自分のMACアドレスと一致しない場合は、そのまま破棄されます。

スイッチのポートは受信者のアドレスをチェックせず、すべてのネットワークパケットをバッファに直接入れます。したがって、ネットワークカードとは異なり、スイッチポートには MAC アドレスがありません。

スイッチの MAC アドレステーブルには、主に次の 2 つの情報が含まれています。

1. 1 つはデバイスの MAC アドレスです

2. もう 1 つは、デバイスがどのポートに接続されているかです。

したがって、スイッチは MAC アドレステーブルに従って MAC アドレスを検索し、対応するポートに信号を送信します。

スイッチが対応する MAC アドレスを見つけられない場合、スイッチはすべてのポートに信号を送信します。対応する受取人のみが荷物を受け取ることができます。

9.ルーター_

ルーターとスイッチの価格の違い

ネットワークパケットはスイッチを通過してルーターに到達します

2 つの違い:

1. ルーターは IP に基づいて設計されており、一般に 3 層ネットワーク機器として知られています。各ポートにはIP、MACアドレスが含まれています

2. スイッチは、一般に 2 層ネットワークデバイスとして知られるイーサネットに基づいて設計されており、ポートには MAC アドレスが含まれません。

ルーターの基本

1. ルーターには MAC ポートがあるため、イーサネットの送信側および受信側として機能します。IPアドレスもあり、その意味ではネットワークカードに似ています。

2. パケットを転送する場合、ルーターポートは対応するイーサネットパケットを受け入れ、ルーティングテーブルを通じて転送ターゲットを照会します。次に、お楽しみのポートを転送します。

ルータのパケット受付動作

まず、電気信号がネットワークケーブルインターフェイスに到達し、ルーター内のモジュールが電気信号をデジタル信号に変換します。最後にFCSでエラーを確認してください

1. 問題がない場合は、ネットワークパケットの MAC ヘッダーを確認して、自分に送信されたパケットであるかどうかを確認します。そうであれば、それをバッファに送信します。

2. ルーターのポートはすべて MAC アドレスを持ち、それ自体に一致するパケットのみを受け入れます。

ルーティングテーブルをクエリして出力ポートを決定します。

10. お互いの肌を摘み合う

MAC アドレスは同じサブネット内で取得され、IP アドレスは異なるサブネット内の異なるホストを指します。

スイッチは主に同じサブネット内で使用されます

ルーターは別のサブネットにあり、サブネットの出口ゲートです。

_____________________________________________________________________________

2. HTTP でよくある面接の質問

1. HTTPの共通概念

HTTP: ハイパーテキスト転送プロトコル

平たく言えば：

HTTP は、コンピュータ世界の 2 点間でビデオ、テキスト、画像、その他の情報を送信するための規約および仕様です。

2. 一般的な HTTP ステータスコード

404: クライアントによって要求されたリソースがサーバー上に存在しないか、見つかりません。

500: 内部サーバーエラーが発生しました

3. HTTPの共通フィールド

1) ホスト: クライアントがリクエストを送信するときに、サーバーのドメイン名 (www.alibaba.com) を指定するために使用されます。

ホストフィールドを使用すると、同じサーバー上の異なるサブセグメントにリクエストを送信できます。

2) Content-Length: サーバーがフィールドを返すと、返されたデータの長さが表示されます。

3) 接続: 他のリクエストを再利用できるように、サーバーに HTTP 長い接続メカニズムの使用を要求するためにクライアントによってよく使用されます。

HTTP ロング接続の特徴: 一方が明示的に切断を提案しない限り、TCP 接続ステータスは維持されます。

4) Content-Type: サーバーが応答するときに使用され、応答データの形式をクライアントに伝えます。

5) Content-Encoding: データの圧縮方法を記述し、サーバーが使用する圧縮形式をクライアントに伝えるために使用されます。

2. 取得と投稿

違い：

GET: 指定されたリソースをサーバーから取得します

POST: リクエストの負荷に応じて指定されたリソースを処理します

安全かつ冪等:

セキュリティ: クライアントによる複数のリクエストメソッドによってサーバー上のリソースが破壊されることはありません

べき等: 同じ操作を複数回実行すると、同じ結果が得られます。

したがって、GET は安全かつ冪等であり、キャッシュすることができます。

POST は安全ではなく冪等であるため、ほとんどはキャッシュできません

開発者の観点から:

GET メソッドを使用して、データの追加または削除のリクエストを実装できますが、この方法で実装された GET メソッドは、当然のことながら安全で冪等ではありません。

POST メソッドを使用してデータクエリリクエストを実装できます。この方法で実装された POST メソッドは、当然のことながら安全で冪等です。

3. HTTPキャッシュ技術

2 つの実装方法: 強制キャッシュとネゴシエートキャッシュ

1. 強制キャッシュ: ブラウザは、キャッシュの有効期限が切れていないと判断する限り、ブラウザのローカルキャッシュを直接使用します。

強制キャッシュは主に 2 つの HTTP ヘッダーフィールドを使用して実装されます。これらはブラウザーでキャッシュの有効期間を示すために使用されます。

キャッシュ制御: 相対時間

Expires: 絶対時間。キャッシュ制御は Expires よりも優先されます。

2. キャッシュをネゴシエートする

キャッシュはサーバーとネゴシエートして、ブラウザーにローカルキャッシュの使用を許可するかどうかを決定します。

ネゴシエートされたキャッシュの具体的な実装

ネゴシエーションキャッシュは、キャッシュを強制するキャッシュコントロールがヒットしないとき、つまり有効期限が切れたときにのみネゴシエーションキャッシュの使用を開始することに注意してください。

4.HTTP機能

アドバンテージ：

シンプル、柔軟、拡張しやすく、広く使用されており、クロスプラットフォームです

欠点:

1. 無国籍の諸刃の剣

利点：

ブラウザーは HTTP ステータスを記憶する必要がなくなり、ステータス情報を記録するための追加のリソースも必要なくなります。これにより、サーバーの負担が軽減され、より多くのリソースとメモリを外部で使用できるようになります。

危害：

彼には記憶がないため、関連する操作を完了するのが困難になります。

Cookie テクノロジーを使用してこの問題を解決できます

Cookie は、リクエストおよび応答メッセージに Cookie 情報を書き込むことで HTTP ステータスを変更します。

2. 平文伝送の諸刃の剣

利点：

読みやすい、

危害：

すべての HTTP 情報が公開されます。これは情報ストリーキングに相当します。情報は簡単に盗まれてしまいます。

3. 安全ではない

1) 平文送信を使用する: 内容が盗聴される可能性があります (盗聴のリスク)

2) 通信相手の本人確認を怠ると、偽装される可能性があります（なりすましの危険性）

3) メッセージの完全性は証明できず、改ざんされる可能性があります。（改ざんリスク）

HTTP パフォーマンス:

1. 長い接続:

一方が明示的に切断を提案しない限り、接続は継続します。これにより、TCP の繰り返し接続が減り、リソースが節約されます。Connection:Keep-Alive フィールドを通じて実装されます。

2. パイプラインネットワーク伝送：HTTP ロングコネクションを実装した場合、パイプライン伝送が可能です。

クライアントが複数のリクエストを同時に送信できるようにします。ただし、サーバーはこれらのリクエストに対して、受け付けられた順序で応答を送信する必要があります。ただし、サーバーが最初のリクエスト A の処理に時間がかかると、そのリクエストはサーバーキューの先頭でブロックされます。

したがって、HTTP/1.1 はブラウザの行頭ブロックを解決しますが、サーバーの行頭ブロックは解決しません。

5.HTTPとHTTPS

1. 2 つの違い:

1) セキュリティ: HTTP はプレーンテキスト送信を使用するハイパーテキスト転送プロトコルですが、HTTPS は HTTP の安全でない欠陥を解決し、TCP ネットワーク層と HTTP ネットワーク層の間に SSL/TLS セキュリティプロトコルを追加して、メッセージの暗号化された送信を可能にします。

2) 接続: HTTP 接続は比較的単純で、HTTP 平文送信は 3 回の TCP 接続後に実行できますが、HTTPS ではメッセージを送信するために 3 ウェイハンドシェイクの後に SSL/TLS ハンドシェイク接続が必要です。

3) ポート: HTTP のデフォルトポートは 80、HTTPS のデフォルトポートは 443 です。

4) 証明書: HTTPS は CA からデジタル証明書を申請する必要があります

2. HTTPS は HTTP のいくつかの問題を解決します

HTTP の欠点:

盗聴の危険性があるHTTP平文通信、情報漏洩を引き起こしやすい

改ざんのリスク: スパム広告の強制挿入

なりすましのリスク: Web サイトになりすまして金銭をだまし取ること。

HTTPS は、上記の点を解決するために、TCP および HTTP 情報に SSL/TLS プロトコルを追加します。

1. 情報の暗号化：データを取得できないようにメッセージを暗号化する（盗聴のリスクを解決）

2. 検証機構：通信内容が改ざんできない、通信内容が変更されると正常に表示できない（改ざんリスクを解決）

3. 本人確認: 本物の淘宝網ウェブサイト証明書であることを証明します。（なりすましリスクへの対応）

HTTPS が上記 3 つのリスクをどのように解決するか

1. ハイブリッド暗号方式で情報の機密性を実現。盗聴リスクに対処する

2. ダイジェストアルゴリズムは整合性を実現し、データの一意のフィンガープリントを生成して、改ざんのリスクを解決します。

3. なりすましのリスクを解決するために、サーバーの公開キーをデジタル証明書に含めます。

HTTPS接続を確立する方法

基本的なプロセス:

クライアントはサーバーにサーバーの公開鍵を要求し、検証します。

両者はセッションキーを生成するために交渉します。

双方がセッションキーを使用して暗号化して通信します

HTTPS がアプリケーションデータの整合性を保証する方法

実装は、ハンドシェイクプロトコルと記録プロトコルの 2 つの層に分かれています。

TLS ハンドシェイクプロトコルは、前述した TLS 4 ウェイハンドシェイクプロセスです。暗号化アルゴリズムのネゴシエーションと対称キーの生成を担当します。このキーは、その後、アプリケーションデータ (つまり、HTTP データ) を保護するために使用されます。

TLS レコードプロトコルは、アプリケーションデータを保護し、その整合性と送信元を検証する役割を担うため、HTTP データ暗号化ではレコードプロトコルが使用されます。

具体的なプロセスは次のとおりです。

6. HTTP/1.1 HTTP1 HTTP3

HTTP1.1 は HTTP1 と比べてどのようなパフォーマンスの向上がありますか?

1. 不要な繰り返し接続を減らすために、長い接続を使用します。リソースを節約する

2. パイプライン転送を使用して、ブラウザのブロックの問題を解決します。

HTTP2の最適化

1. ヘッド圧縮

ブラウザが複数のリクエストを送信するとき、それらのヘッダーが同じまたは類似している場合、プロトコルは重複を削除します。

2. バイナリ形式

HTTP/2 は HTTP/1.1 のプレーンテキストメッセージとは異なりますが、バイナリ形式を完全に採用しています。ヘッダー情報とデータ本体は両方ともバイナリであり、総称してフレームと呼ばれます:ヘッダーフレームとデータフレーム。

3. 同時送信

ブラウザによって送信された複数のリクエストは TCP 接続を共有できます

TCP 接続には複数のストリームが含まれます。ストリームには 1 つ以上のメッセージを含めることができます。メッセージは HTTP/1 のリクエストまたは応答に対応し、HTTP ヘッダーとパケット本体で構成されます。

4. サーバープッシュ

HTTP/2 では、従来の「リクエストとレスポンス」の動作モデルもある程度改善され、サーバーは受動的に応答するのではなく、クライアントにメッセージを能動的に送信できるようになりました。

Stream はクライアントとサーバーの両方で作成でき、ストリーム ID も異なります。クライアントが作成する Stream は奇数、サーバーが作成する Stream は偶数でなければなりません。

3. TCP 3 ウェイハンドシェイクと 4 ウェイウェーブ

1. TCP の基本的な理解

送信元ポート番号と宛先ポート番号:

データパケットがどのアプリケーションに送信されたかを確認するために使用されます

シリアルナンバー：

接続を確立する際、コンピュータが生成した乱数を初期値としてSYNパケットで受信側ホストに送信し、データを送信するたびにデータバイトのサイズを1回累積することで問題を解決します。パケット障害。

応答番号を確認してください:

次に受信する予定のデータのシーケンス番号を指します。送信者は確認応答を受信すると、以前に送信したリクエストが正常に受信されたとみなします。パケットロスの問題を解決するために使用されます。

制御ビット:

ACK この制御ビットが 1 の場合、確認応答フィールドが有効であることを示します。

RST この制御ビットが 1 の場合、TCP 接続で例外が発生し、強制的に中断する必要があることを意味します。

SYN この制御ビットが 1 の場合、接続を確立し、そのシーケンス番号フィールドに初期値を設定することを示します。

FIN この制御ビットが 1 の場合、切断を示します

TCPプロトコルを使用する理由

TCP プロトコルはトランスポート層で動作する信頼性の高いデータ送信サービスであるため、受信したネットワークパケットが損傷しておらず、ギャップがなく、冗長性がなく、秩序立ったものであることを保証できます。

TCPとは何ですか?

TCP は、コネクション指向で信頼性の高いバイトストリームベースのトランスポート層通信プロトコルです。

TCP接続とは何ですか?

信頼性とフロー制御の維持を確保するために特定の状態情報が使用され、ソケット、シーケンス番号、ウィンドウ番号サイズなどのこの情報の組み合わせを接続と呼びます。

TCP 接続を一意に決定するにはどうすればよいですか?

送信元アドレスと宛先アドレス: このフィールドは IP ヘッダー内にあり、IP プロトコルを通じて他のホストに送信するために使用されます。

送信元ポートと宛先ポート: このフィールドは TCP ヘッダー内にあり、他のホストのアプリケーションに送信するために使用されます。

TCP 接続の最大数:

クライアントポートの数 * クライアント IP の数

UDPとTCPの違い

違い：

1. コネクション数：TCP は通信サービスを実行する前にコネクションを確立する必要がありますが、UDP はコネクションを確立する必要がありません。

2. サービスオブジェクト: TCP は 1 対 1 のサービスのみを提供できますが、UDP は 1 対多および多対 1 のサービスを提供できます。

3. 信頼性: TCP は信頼性の高い転送を目的としており、データはエラーがなく、失われず、繰り返されず、順番に到着します。

UDP はベストエフォート型の配信であり、信頼性の高い配信を保証するものではありません。

4. 機能: TCP には、データのセキュリティを確保するための輻輳制御やフロー制御などの機能があります。UDPはそうではありません

5. 伝送方式：TCPは境界のないストリーミング伝送です。ただし、秩序と信頼性が保証されています

UDPはパケット単位で送信されるため境界がありますが、パケットロスなどの問題が発生する可能性があります。

6. 異なるフラグメント化: TCP データパケットが MSS より大きい場合、フラグメント化され、フラグメントが途中で失われた場合、クライアントは新しいフラグメントを再送信するだけで済みます。

TCPとUDPの応用シナリオ

TCP: FTP ファイル転送、HTTP および HTTPS など。

UDP: 合計パッケージサイズが小さい通信、ビデオ、オーディオなどの通信。

TCP と UDP は同じポートを共有できますか?

できる。トランスポート層の「ポート番号」の機能は、同じホスト上の異なるアプリケーションのデータパケットを区別することです。

2.TCP接続

3回の握手

クライアントはデータパケット (SYN ステータスビットが 1) をサーバーに送信して、接続を要求します。

サーバーはデータパケット (SYN と ACK を含む) を送信して、応答を確認し、接続を要求します。

クライアントは、ACK を含むデータパケットを送信して応答を確認し、接続を確立します。

クライアントとサーバーの両方がリクエストを送信して受け入れる能力があることを示すことができるのは、3 ウェイハンドシェイクのみです。

主にソケット、シーケンス番号、ウィンドウサイズを初期化し、接続（TCP接続の意味）を確立できるスリーウェイハンドシェイクです。

主に次の 3 つの側面に反映されます。

3 ウェイハンドシェイクにより、過去の接続が繰り返し初期化されるのを防ぐことができます。

双方のシリアル番号を同期するには、3 ウェイハンドシェイクが必要です。

3 ウェイハンドシェイクによりリソースの無駄を回避できます

「双方向ハンドシェイク」と「四方向ハンドシェイク」を使用しない理由:

「2 つのハンドシェイク」: 過去の接続の確立を防ぐことはできず、双方でリソースの無駄が発生します。また、双方のシリアル番号を確実に同期することも不可能です。

「4 ウェイハンドシェイク」: 3 ウェイハンドシェイクは、信頼性の高い接続を確立するための理論上の最小値であるため、それ以上の通信時間を費やす必要はありません。

TCP 接続が確立されるたびに初期化シーケンス番号が異なるのはなぜですか?

1. 同じ 4 タプルを使用した次の接続で履歴メッセージが受け入れられないようにするため (主な理由)

2. ハッカーによるシリアル番号が偽造されたメッセージが相手方に受信されることを防止する

IP 層は断片化されるのに、なぜ TCP 層を断片化する必要があるのでしょうか?

最初のハンドシェイクが失われた場合はどうなりますか?

クライアントがタイムアウトして SYN メッセージを 3 回再送信すると、tcp_syn_retries が 3 であるため、再送信の最大回数に達しているため、しばらく待機します (時間は最後のタイムアウト時間の 2 倍)。サーバーからの応答 2 回目のハンドシェイク (SYN-ACK メッセージ) の後、クライアントは切断されます。

2 回目のハンドシェイクが失われた場合はどうなりますか?

クライアントは SYN メッセージを再送信します (これが最初のハンドシェイクです)。再送信の最大回数は tcp_syn_retriesカーネルパラメータによって決まります。
サーバーは 2 回目のハンドシェイクである SYN-ACK メッセージを再送信します。再送信の最大回数は tcp_synack_retries カーネルパラメータによって決まります。

3回目の握手で失われるものは何ですか？

サーバーがタイムアウトして SYN-ACK メッセージを 2 回再送信すると、tcp_synack_retries が 2 であるため、再送信の最大回数に達しているため、しばらく待機します (時間は最後のタイムアウト時間の 2 倍です)。クライアントの 3 回目のハンドシェイク (ACK メッセージ) を受信すると、サーバーは切断されます。

4回手を振る

クライアントは、切断を示すために FIN を含むデータパケットをサーバーに送信します。

サーバーは、ACK を含むデータパケットをクライアントに送信して、リクエストの受信を示します。確認シーケンス番号は、受信したシーケンス番号に 1 を加えたものです。

サーバーセグメントは、切断を示すためにクライアントに FIN パケットを送信します。

クライアントは、応答の受信を示すために ACK を含むデータパケットをサーバーに送信し、正式に切断し、受信したシーケンス番号に 1 を加えた値に確認シーケンス番号を設定します。

なぜ切断するのに4回の電波が必要なのか

クライアントが切断を要求する FIN パケットを送信すると、サーバーは要求の受信を確認するために ACK を送信します。ただし、この時点ではサーバーにはまだ未処理のデータがある可能性があります。データが処理された後、FIN を次の宛先に送信できます。クライアント終了。これが、4 つの波を 3 つに減らすことができない理由です。

最初の波が失われた場合はどうなりますか?

トリガータイムアウト再送信メカニズム

クライアントがタイムアウトして FIN メッセージを 3 回再送信すると、tcp_orphan_retries が 3 であるため、再送信の最大回数に達しているため、しばらく待機します (時間は最後のタイムアウト時間の 2 倍)。サーバー Wave から 2 度目の応答 (ACK メッセージ) を受信すると、クライアントは切断されます。

2 回目に波が失われた場合はどうなりますか?

クライアントがタイムアウトして FIN メッセージを 2 回再送信すると、tcp_orphan_retries が 2 であるため、再送信の最大回数に達しているため、しばらく待機します (時間は前回のタイムアウト時間の 2 倍)。サーバーからの応答、第 2 波 (ACK メッセージ)、その後クライアントは切断されます。

第3波が失われたらどうなるでしょうか？

サーバーが第 3 ウェーブメッセージを 3 回再送信すると、tcp_orphan_retries が 3 であるため、再送信の最大数に達するため、サーバーはさらに一定時間待機します (時間は最後のタイムアウトの 2 倍です)。 4 番目の波 (ACK メッセージ) の受信に失敗すると、サーバーは切断されます。
クライアントは close 関数によって接続を閉じるため、FIN_WAIT_2 状態には時間制限があり、tcp_fin_timeout 時間内にサーバーからの 3 番目のウェーブ (FIN メッセージ) を受信できない場合、クライアントは切断されます。

第4波が失われたらどうなるでしょうか？

サーバーが wave メッセージを 3 回目に再送信して 2 に達すると、tcp_orphan_retries が 2 であるため、再送信の最大回数に達するため、しばらく待機します (時間は最後のタイムアウトの 2 倍です)。クライアントが 4 回目に手を振る (ACK メッセージ) と、サーバーは切断されます。
3 番目の波を受信した後、クライアントは TIME_WAIT 状態に入り、2MSL の継続時間でタイマーを開始します。途中で再び 3 番目の波 (FIN メッセージ) を受信すると、タイマーをリセットし、2MSL 後、クライアントは切断されます。

———————————————————————————————————————————

4. TCPタイムアウト再送スライディングウィンドウフロー制御輻輳制御

1.TCP再送信

TCP が信頼性の高いトランスポートを実現する方法の 1 つは、シーケンス番号と確認応答番号を使用することです。

1. タイムアウト再送信

クライアントがサーバーにデータパケットを送信する際、指定時間内に相手からのACK確認応答メッセージを受信しない場合、データパケットを再送します。これが再送信メカニズムです。

一般に、パケット損失は次の 2 つの状況で発生します。

1. パケットロス

2. 確認応答が失われました

RTT は、データが送信された時間と確認が受信された時間の差です。

RTO はタイムアウト再送信時間です

機能しない RTO の方法が 2 つあります。

1 つは、RTO が大きすぎるため非効率であり、データパケットが再送信されるまでに長時間にわたって失われることです。

1 つは、RTO が小さすぎる場合、パケットが損失なく再送信され、ネットワークの輻輳が発生する可能性があることです。

したがって、要約すると、RTO の値はパケット往復時間 RTT の値よりわずかに大きい必要があります。

2. 高速再送信

それは時間ではなく、データによって決まります。

したがって、高速再送信メカニズムは、3 つの同一の ACK 応答を連続して受信した場合に、タイマーが期限切れになる前に失われたセグメントを再送信することです。

高速再送信には問題があります。1 つの問題を再送信するか、すべての問題を再送信するかが不明です。

3.サック方式

スサック選択確認

TCP ヘッダーオプションに Sack メッセージを追加します。これにより、受信したデータに関する情報を送信者に送信できるため、送信者はどのデータが受信され、どのデータが受信されなかったかがわかります。この情報を知っていると、未受信の情報のみを再送信できます。

4. D-SACK方式

D-SACK いくつかの利点があることがわかります。

これにより、送信されたパケットが失われたのか、それとも受信者によって応答された ACK パケットが失われたのかを「送信者」に知らせることができます。

「送信者」のデータパケットがネットワークによって遅延されているかどうかを知ることができます。

「送信者」のデータパケットがネットワーク内にコピーされているかどうかを知ることができます。

2. 引き違い窓

リクエストを送信するたびに確認応答が必要となり、データパケットの往復時間が長くなると通信効率が低下します。

そこで、確認応答を待たずにデータを送信し続けることができる最大値をウィンドウサイズという概念が導入されました。

ウィンドウはオペレーティングシステムによって開かれるキャッシュ領域であり、送信者は確認応答を受信する前に送信データをバッファに保持する必要があります。応答が時間通りに受信された場合、データはクリアできます。

TCP ヘッダーにはウィンドウサイズを意味するフィールドウィンドウがあります。ウィンドウサイズは受信機によって決定されます。

このフィールドは、受信者が送信者に、データを受信するためにバッファーにどのくらいのスペースが残っているかを伝える場所です。したがって、送信側は受信側の処理能力に基づいてデータを送信できます。受信側で処理できなくなることはありません。

受信ウィンドウのサイズは、送信ウィンドウのサイズとほぼ同じです。

3. フロー制御

TCP は、送信者が受信者の実際の受信能力に基づいて送信されるデータの量を制御できるようにするメカニズム (フロー制御) を提供します。

受信者によって送信される確認メッセージのウィンドウフィールドは、送信者のウィンドウサイズを制御するために使用でき、それによって送信者の送信速度に影響を与えます。ウィンドウフィールドが 0 に設定されている場合、送信者はデータを送信できません。

1) オペレーティングシステムのバッファと送信ウィンドウおよび受信ウィンドウの関係

送信ウィンドウと受信ウィンドウに保存されるバイト数はオペレーティングシステムのバッファに保存され、バッファのサイズはオペレーティングシステムによって調整されます。

4. 輻輳制御

ネットワーク上のリソースに対する需要が、そのリソースの利用可能な部分を超える期間。ネットワークのパフォーマンスが低下することを輻輳といいます。輻輳制御は、これ以上のリクエストがネットワークに入るのを防ぐことです。制御の目的は、送信者のデータがネットワーク全体に溢れないようにすることです。

輻輳ウィンドウ

輻輳ウィンドウは、送信側によって維持される状態変数です。ネットワークの混雑度に応じて変化します

送信ウィンドウ swnd=min (cwnd, ewnd) 一般に、送信ウィンドウは受信ウィンドウ rwnd とほぼ同じです。

cwndはどう変わるのか？

ネットワークにネットワークの輻輳がない限り、cwnd は大きくなります

ネットワークが混雑している場合は小さくなります。

ネットワークの混雑を判断するにはどうすればよいですか?

データパケットが失われ、再送信メカニズムが開始された場合は、ネットワークの輻輳を示します。

輻輳制御のための 4 つのアルゴリズム:

1. スロースタート cwnd は、スロースタートしきい値 ssthresh を超えることなく、1、2、4、8、16 と徐々に大きくなります。

2. 輻輳回避: ssthresh を超えそうになったら、1、12、13、14 を追加し始めます。

3. 輻輳が発生するタイムアウト再送が発生すると、2 つのメカニズムが発生します

1. タイムアウト再送信

ssthresh に設定します cwnd/2。

cwnd Reset to 1 (cwnd 初期化値に復元します。ここでは cwnd 初期化値 1 を想定します)

2. 高速再送信

cwnd = cwnd/2 つまり、元の値の半分に設定されます。

ssthresh = cwnd;

高速リカバリアルゴリズムを入力してください

4. 素早い回復

一般に、高速リカバリと高速再送信が使用されます。

輻輳ウィンドウ cwnd = ssthresh + 3 (3 は 3 つのパケットが受信されたことの確認を意味します)。

失われたパケットを再送信します。

重複した ACK を再度受信すると、cwnd は 1 増加します。

新しいデータの ACK を受信した後、最初のステップで cwnd を ssthresh の値に設定した場合、その理由は、ACK が新しいデータを確認し、重複した ACK からのデータが受信され、回復プロセスが終了したことを示しているためです。復旧前の状態、つまり再度輻輳回避状態に戻すことができます。

———————————————————————————————————————————