背景問題

デイリーのインタビュー、ほぼすべての研究コンピュータが知っている、TCPはUDPプロトコルが信頼できない、信頼性の高いプロトコルです。なぜTCPプロトコルは信頼性はありますか？それは、信頼性を保証するためにどのような仕組みですか？

質問をします

TCPセグメントを切断するには大きすぎる場合MTU IPので、パケットは、長さ制限を有します。ネットワークリンクの不確実性に、送出さに切断した後、受信機は、パケットの送信順序を受信し、順序が高い確率で矛盾しています。どのように受信側が受信した「同じグループ」TCPセグメントデータは、所望のバイナリデータにスプライシング？
送信者は受信者がこのメッセージを受信したことを確認する方法を、TCPパケットを送信しますか？
送信者が途中で改ざん「他の誰か」ではない、受信したデータセグメントの受信側を確実にするためにどのように、TCPパケットを送信しますか？

エントリレベル溶液TCPプロトコル

TCPパケット識別子のシリアル番号
- TCPセグメントヘッダは、シーケンス番号フィールドが存在する（シーケンス）
- 末端配列を受信すると、別のTCPパケットとソートスプライシングのために使用することができます
主なソリューション：ACKメカニズムの確認応答番号+
- 受信者は、TCPパケット、TCPパケットSEQ + 1を受信することが期待されるシーケンス番号のシーケンス番号SEQを受信した後、数は配列+ 1充填が確認されます
- ACKビットが受信確認応答TCPパケットを示すために1に設定されています
- タイムアウトACKは、デフォルトのTCPセグメントが再び、再送を失われ、送信者が受信されません
チェックサムTCPパケットヘッダフィールド試験及び検査セグメントデータは、チェックサムと実際のセグメントのデータの一貫性を受け取りました。矛盾が破棄されます

主要な問題の解決策

プライマリソリューション2の場合：二つの問題があり
、低効率1のは...
> ACKを待つ- - >送信-送信者が送信し続ける> ACKを待つ...単一行の仕事を、このような作業はストップアンドウェイトと呼ばれています。ストップアンドウェイトTCP通信の信頼性を達成するためにかかわらず、しかし、ネットワーク通信の効率を犠牲にして。一方、ACKを待っている期間において、ネットワークは、アイドル（IDLE）状態であります

2.少し欠陥
現在のTCPセグメントが確認されていない場合、それはその後の断片につながるが出て送信することはできません。

TCPプロトコルの最適化

スライディングウィンドウメカニズム
- あなたは非常に詳細な、画像のシーケンス内の参照リンクを参照してくださいすることができ、拡張しないでください。
- 窓付きTCPセグメントヘッダ
- 累積ACK応答を使用するため、消費端ACK応答を、受信フローを減少させます
- 送信側は、ACKが受信されない単一のTCPセグメントは、ほとんどの場合、ブロックされている送信を継続できません
- 確認番号と詳細SEQ
  - 受信したTCPパケットの配列のシーケンス番号を受信した後、確認応答パケットのACK番号は、必ずしも送信されない配列+ 1、配列+ Nであってもよい（N-1は、TCPセグメント配列の受信されたシーケンス番号でありますTCPセグメントの数）が受信される前に

概要

TCPプロトコルは、信頼性の確保するために、次のメカニズムを使用しています
- TCPセグメントヘッダシーケンスフィールドは、一意でなく、順序のアイデンティティとして、TCPセグメントを識別する
- 確認応答機構ACKのTCP受信確認番号を使用して通信+
- TCPパケットヘッダレコードセグメントのデータのチェックサムチェックサムフィールド
最適化されたTCPプロトコル
- 窓スライド機構、通信効率を向上させます

参考資料

なぜTCPプロトコルは信頼性はありますか？

TCPプロトコルは信頼性があるのはなぜ