目次
TCPプロトコル
TCP、つまり伝送制御プロトコル、Transmission Control Protocol。
TCPプロトコルのデータ形式
- 16 ビットの送信元ポート番号と 16 ビットの宛先ポート番号は、データの送信元と送信先のプロセスを示します。
- 32 ビットのシーケンス番号は、TCP 通信中（TCP 接続の確立から切断まで）、ある送信方向のバイト ストリームの各バイトの番号を表します（TCP はデータの各バイトに番号を付け、シリアル番号と呼びます）。
- 32は、送信された TCP メッセージ セグメントに対する受信者の応答を示す確認応答シーケンス番号です。その値は、受信した TCP セグメントのシリアル番号の値に 1 を加えたものです。
- 4 ビット TCP パケット長は、TCP ヘッダーに 32 ビット ビットが何個（4 バイトが何個）あるかを示すため、TCP ヘッダーの最大長は 15 * 4 = 60 バイトになります。
6 つのフラグ:
URG: 緊急ポインタが有効かどうかを示します。
ACK: 確認番号が有効かどうかを
示します。 PSH: 受信側アプリケーションに TCP バッファからデータをすぐに読み取るように要求します。
RST: 接続のリセット、つまり接続の再確立を示します。
SYN: 同期を示します。SYN マークが付いているものを同期メッセージと呼びます
。 FIN: ローカルエンドが閉じられることを相手に知らせるため、FIN マークが付いているものをエンドメッセージセグメントと呼びます。
- 16 ビット ウィンドウ サイズ: 受信側 TCP が最大 65535 バイトのバッファを提供できることを示します。
- 16 ビット チェックサム: 送信者が TCP ヘッダーとメッセージ データに一定の数学的計算を実行して得られた結果を入力し、受信者が同じ数学的方法で計算し、チェックサムが同じであれば検証は成功します。
- 16 ビット緊急ポインタ: データのどの部分が緊急データであるかを識別します。
TCPの原則
確認応答
送信者のデータを受信した後、受信データの最後のバイトの次のバイト シーケンス番号を含む ACK メッセージの送信に戻ります。
たとえば、最後に受信したバイトのシリアル番号が 1000 の場合、返されるシリアル番号は 1001 です。これは、データの最初の 1000 バイトがすべて受信されたことを意味します。
この問題を解決するために、tcp は受信バッファ (カーネル内のメモリ空間) を持ち、各ソケットには独自の受信バッファがあり、tcp は受信したメッセージをシリアル番号に従ってバッファにキューに入れることができます。
タイムアウト再送信
ネットワーク送信時にパケットロスが発生する場合があります。
- 送信されたデータグラムは受信者によって受信されませんでした
- 受信者がそれを受信した後、返送された ack メッセージは送信中に失われます。
応答戦略
送信者が ack 応答メッセージを受信しない場合、一定間隔でメッセージを再送信します。再送信回数が増えると、間隔時間も増加します。複数回連続して再送信しても、ack メッセージは取得できません。tcp は、接続のリセットを試みます。リセットが失敗した場合は、接続が解放されます (TCP は、どのような環境でも高パフォーマンスの通信を保証するために、最大タイムアウト期間を動的に計算します)。
再送データを受信し、データが重複した場合、tcpは受信データのシリアル番号に基づいて自動的に重複排除を行います。
TCP はどのようにして信頼性を実現しますか?
答:确认应答+超时重传
接続管理
3回の握手
上記のプロセスはカーネルによって自動的に完了し、アプリケーション プログラムは介入できません。
ハンドシェイクの目的は、クライアントとサーバーに相当する 2 つの通信当事者間でネットワーク インタラクションを実行することです。3 つのインタラクションを通じて、接続が確立されます。確立（双方がお互いの情報を記録） スリーウェイ
ハンドシェイクの目的 指示を求めたり、クライアントとサーバーの送受信能力が正常か確認することです！
クライアントはサーバーに SYN メッセージを送信して、準備ができているかどうかをサーバーに尋ね、サーバーは「準備はできていますが、あなたはどうですか?」という SYN+ACK メッセージを返します。クライアントは、準備ができていることをサーバーに伝えるために ACK を送信します。となり、接続が正常に確立されました。
四回手を振った
切断するには、サーバーとクライアントの両方が最初に FIN 終了メッセージを開始する場合がありますが、
なぜ 3 回ではなく 4 回振られるのでしょうか?
一定の確率で ack と fin が 1 つにマージされます!! しかし、通常はマージできません。 ack はシステム カーネルによって完了されますが、fin はアプリケーション プログラムによって制御され、ソケットの close メソッドの
呼び出しによって fin がトリガーされるため、ack と fin は同時にトリガーされません。
スライドウィンドウ
送信側は一度に複数のデータを送信し、ある程度送信を停止し、一度に複数の ACK を待ち、ACK メッセージを受信してから 1 つのデータを送信する、スライディング ウィンドウのように見えます。
パケットロスが発生する場合:
- データ パケットが到着し、ACK メッセージが失われます。
この状況には影響はありません。最後の数個の ACK メッセージが受信されている限り、前の ACK も受信されていることを意味します (確認シーケンス番号の意味は、すべての ACK メッセージが受信されていることを意味します)。シーケンス番号が受信される前のデータ）受信）。 - パケットが到着しませんでした
この場合、応答メッセージは常に 1001 を受信したことを示し、1001 ～ 2000 はタイムアウトして再送信され、以降のデータの受け入れには影響しません。1001 ～ 2000 を受信した場合は、受け付けたデータ 最終バイトの次のバイトのシーケンス番号
上記のタイムアウト再送を高速再送と呼びます。
フロー制御
本質的には、受信側が送信側の速度を制限できるようにすること、つまり受信側の処理能力に応じて送信側の送信速度を決定することです。ACK
メッセージのヘッダーの ACK ビットが 1 の場合、ウィンドウ サイズ フィールドはヘッダーのヘッダーが有効になり、ウィンドウのサイズが送信者の送信速度を決定します。
送信者は、相手の受信バッファがいっぱいであることを検出すると、送信を一時停止しますが、それでも「ウィンドウ」がトリガーされます。検出」メッセージが時々表示されます。検出でウィンドウが見つかった場合、サイズが 0 でない場合は、送信を続けます。
輻輳制御
TCP はスロー スタート メカニズムを導入しており、最初に少量のデータを送信し、経路を探索し、現在のネットワークの輻輳状態を調べてから、データを送信する速度を決定します。伝送経路の処理能力が測定されます - バレル
効果（ある伝送路は強いですが、ルーターの利用可能な伝送速度は非常に小さいので、このルーターの伝送容量はその伝送路の最大伝送容量となります） 実験を通じて適切な伝送速度を見つけ、一定の速度で送信を開始します
。パケット損失なしで、最初に小さいレートを設定します。その場合はレートを上げます。パケットが失われた場合は、動的なバランスを達成するためにすぐにレートを下げます。
实际发送的窗口大小=将拥塞窗口和接收端主机反馈的窗口大小(流量控制窗口)做比较，取较小的值作为
実際の送信ウィンドウは
次の図で説明されています。輻輳ウィンドウは最初は小さい値で送信され、パケット損失がない場合レートは指数関数的に増加し始め、特定のしきい値に達すると直線的に増加します (上限を超えないように注意してください)。パケットロスが発生すると、現在のウィンドウがパスの上限に達したとみなされ、ウィンドウはより小さい値に戻り、しきい値は上限の半分に更新されます。
遅延応答
遅延応答の核心は、ACK 応答メッセージの応答をしばらく遅らせることであり、その場合、応答メッセージ内の受信側のバッファ サイズが即時応答よりも大きくなる可能性があります (アプリケーションは受信バッファからデータを読み取っています)。 , このとき、送信者はもう少し多くのデータを送信できます。
ウィンドウが大きいほど、ネットワークのスループットが向上し、伝送効率が高くなります。ネットワークが混雑しないようにしながら、伝送効率の向上を目指してください。数量制限:
ごとN パケット 1 回応答;
制限時間: 最大遅延時間を超えた場合 1 回応答。
便乗
受信側の応答メッセージ ack は、受信側の応答メッセージが 1 つのデータグラムに結合されて送信されるまでしばらく待機するため、効率が向上します
。
ストリーム指向
スティッキーパケットの問題
A が複数のアプリケーション層のデータグラムを B に送信し続けると、これらのデータは B の受信バッファに蓄積されます。このとき、B のアプリケーションプログラムがこれらのデータグラムを読み取って、どれが完全なデータグラムであるかを区別することが困難になります。データグラムの半分を読み取るのは簡単です ( TCP プロトコルのヘッダーには、UDP のような「メッセージ長」のようなフィールドはなく、アプリケーション層の観点から見ると、目に見えるのは一連の連続したバイトだけです)データ、どの部分から始めればよいかわかりません、それは完全なアプリケーション層パケットです)
。
- 慣例的な区切り文字。
- 合意された長さ (たとえば、合意されたデータの最初の 4 バイトは、データグラムの長さを示すために使用されます)。
異常な問題
- プロセスのシャットダウン/プロセスのクラッシュ
プロセスは消滅し、ソケットはファイルであり、閉じられています プロセスは消滅しても、接続はまだ存在しており、通常は 4 回手を振ることができます。 - ホストがシャットダウンします
。すべてのユーザー プロセスがシャットダウンされ、ハンドの 4 つのウェーブがトリガーされます。ウェーブが終了していない場合、たとえばサーバーが fin を送信すると、ACK が到着する前にクライアントがシャットダウンします。このとき、ピアは再送信します。
fin...数回の再送信後 ACK がないことがわかったら、接続のリセットを試み、失敗した場合は接続を解放します。 - 停電・ネットワーク障害
- 相手が送信者の場合、
相手はackを受信しない=>タイムアウト再送→接続リセット→接続解放 - 相手が受信側の場合
、相手は、こちら側がデータを送信する時間がなかったのか、それとも単に消えてしまったのかをすぐに知ることができないため、TCP ハートウォッチング
パケットキープアライブ メカニズムが役割を果たします。
- 相手が送信者の場合、
受信者は送信者に定期的にハートビート パケットを送信します。応答があればピアはまだ生きていることを意味します。応答がなければピアはハングアップしたことを意味します（ハートビート パケットは定期的に送信されるわけではありません）。判定はそれほど厳しくありません）。