TCPプロトコル伝送の特徴は、主にバイト指向、信頼性の高い伝送、および接続指向です。このブログでは、TCPプロトコルが伝送の信頼性を確保する方法に焦点を当てます。
伝送の信頼性を確保する方法
データ伝送の信頼性を確保するためのTCPプロトコルの主な方法は次のとおりです。
- チェックサム
- シリアル番号
- 確認応答
- タイムアウト再送
- 接続管理
- フロー制御
- 輻輳制御
チェックサム
計算方法：データ送信の過程で、送信されたデータセグメントは16ビット整数と見なされます。これらの整数を追加します。そして、前面のキャリーは破棄できず、背面を埋め、最後に反転してチェックサムを取得します。
送信者：データを送信する前にチェックサムを計算し、チェックサムを入力します。
受信者：データを受信した後、同じ方法でデータを計算し、チェックサムを見つけ、送信者と比較します。
注：受信者のチェックサムが送信者と一致しない場合、データは誤って送信される必要があります。ただし、受信者のチェックサムが送信者と一致している場合、データは正常に送信されない可能性があります。（チェックサムはデータの正確性を保証します。以下で紹介するメカニズムは、データが正常に受信されることを保証するためのものです）
応答とシリアル番号を確認する
シリアル番号：データの各バイトには、TCP送信中に番号が付けられます。これはシリアル番号です。
確認応答：TCP送信中に、受信者がデータを受信するたびに、送信側を確認します。それはACKメッセージを送ることです。このACKメッセージには、対応する確認シーケンス番号が含まれています。これにより、送信者はどのデータが受信され、次のデータがどこに送信されるかがわかります。
通し番号の機能は応答だけではなく、通し番号で受信データを振り分けたり、通し番号が重複したデータを削除したりすることができます。これは、TCP伝送の信頼性の保証の1つでもあります。
タイムアウト再送
TCP送信中、確認応答とシーケンス番号メカニズムにより、つまり、送信者がデータの一部を送信した後、受信者によって送信されたACKメッセージを待ち、ACKメッセージを解析して、データが正常に送信されたかどうかを判断します。データを送信した後、送信者が受信者からのACKメッセージを待機しない場合はどうなりますか？ACKメッセージを受信しない理由は何ですか？
まず、送信者が応答ACKメッセージを受信しなかった理由は2つ考えられます。
- 送信プロセス中、ネットワーク上の理由およびその他の直接的なパケット損失のため、受信者はそれをまったく受信しませんでした。
- 受信側は応答データを受信しましたが、送信されたACKパケット応答はネットワーク上の理由により失われました。
TCPがこの問題を解決したとき、タイムアウト再送信メカニズムと呼ばれる新しいメカニズムが導入されました。簡単に理解すると、送信者はデータを送信した後、しばらく待機し、その時間が到着してACKメッセージが受信されない場合、送信されたばかりのデータが再送信されます。それが最初の理由である場合、再送信されたデータを受信した後、受信者はACKで応答します。2番目の理由の場合、受信者は受信したデータが既に存在することを検出し（存在を判断する基準はシリアル番号であるため、シリアル番号は重複データを削除する効果もあります）、そのデータは直接破棄され、ACK応答は引き続き送信されます。
それでは、送信者は送信後どのくらい待機しますか？この待ち時間が長すぎると、TCP転送全体の効率に影響を与え、待ち時間が短すぎると、繰り返しパケットが頻繁に送信される原因になります。重さは？
TCP伝送は、あらゆる環境で高性能の通信を保証するため、最大タイムアウト期間（つまり、待機時間）は動的に計算されます。
在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间
都是500ms的整数倍。重发一次后，仍未响应，那么等待2*500ms的时间后，再次重传。等待4*500ms的时间继续
重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。
接続管理
接続管理は、3ウェイハンドシェイクと4ウェイウェーブのプロセスであり、このプロセスは前に詳細に説明されているため、ここでは繰り返さない。信頼性の高い接続を確保することは、信頼性を確保するための前提条件です。
フロー制御
データを受信した後、受信側はそれを処理します。送信側の送信速度が速すぎると、受信側のエンドバッファがすぐにいっぱいになります。この時点で、送信側がまだデータを送信している場合、次に送信されるデータは失われ、パケット損失、時間の経過に伴う再送信などの一連の連鎖反応が発生します。TCPは受信側のデータ処理能力に応じて、送信側の送信速度を決定しますが、これがフロー制御です。
TCPプロトコルのヘッダ情報には、16ビットフィールドのウィンドウ（受信機フィードバックウィンドウ）サイズがあります。このウィンドウサイズを導入すると、ウィンドウサイズの内容は実際には受信側の受信データバッファーの残りのサイズであることがわかります。数値が大きいほど、受信側の受信バッファの残りのスペースが大きくなり、ネットワークスループットが大きくなります。受信側は、確認応答でACKメッセージを送信するときに、即時ウィンドウのサイズを入力し、ACKメッセージと一緒に送信します。送信者は、ACKメッセージのウィンドウサイズの変更に応じて、送信速度を変更します。受信したウィンドウサイズの値が0の場合、送信側はデータの送信を停止します。そして、定期的にウィンドウ検出データセグメントを受信側に送信し、受信側に送信側にウィンドウサイズを通知させます。
注：16ビットウィンドウサイズは最大65535バイト（64K）を表すことができますが、最大TCPウィンドウサイズは64Kではありません。TCPヘッダーの40バイトオプションには、ウィンドウ拡張係数Mも含まれています。実際のウィンドウサイズは、Mビットだけ左にシフトしたウィンドウフィールドの値に対して16です。1ビット移動するたびに、2倍になります。
輻輳制御
TCP送信の処理において、送信側がデータの送信を開始したときに、最初に大量のデータが送信されると、問題が発生する場合があります。最初はネットワークが非常に混雑している可能性があり、ネットワークに大量のデータを投入すると、混雑が増加します。輻輳が激化すると、大量のパケット損失が発生し、長時間の再送の送信に影響します。
そのため、TCPではスロースタートメカニズムが導入されており、データを送信するときに、少量のデータが送信されて経路が検出されます。現在のネットワークステータスを確認し、送信速度を決定します。このとき、輻輳ウィンドウという概念が導入されました。送信の開始時に、輻輳ウィンドウは1として定義されます。ACK応答が受信されるたびに、輻輳ウィンドウは1ずつ増加します（1ビットが2倍になります）。データを送信する前に、まず輻輳ウィンドウを受信側からフィードバックされたウィンドウのサイズと比較し、小さい方の値を実際の送信ウィンドウとして使用します。
輻輳ウィンドウの増加は指数関数的です。スロースタートのメカニズムは、最初は送信が少なく送信が遅いことを示しているだけですが、成長率は非常に高速です。輻輳ウィンドウの増加を制御するために、輻輳ウィンドウを単純に2倍にすることはできません。輻輳ウィンドウのしきい値が設定されています。輻輳ウィンドウのサイズがしきい値を超えると、指数関数的に増加させることはできませんが、線形的に増加します。スロースタートの開始時に、スロースタートのしきい値はウィンドウの最大値に等しくなります。ネットワークが輻輳してタイムアウトの再送信が発生すると、スロースタートのしきい値は元のしきい値の半分になります（ここで元はネットワークの輻輳が発生したときの輻輳ウィンドウを指します）。サイズ）、および輻輳ウィンドウは1にリセットされます。
輻輳制御とは、TCPが送信中にデータを可能な限り迅速に送信し、輻輳によって引き起こされる一連の問題を回避することです。信頼性の保証であり、伝送効率も維持します。
元のアドレス：https : //blog.csdn.net/liuchenxia8/article/details/80428157
