いい加減にして！ボジを盗む
今日見た詩は灰色です
空は灰色、
道路は灰色、
建物は灰色、
雨は灰色、
死んだ灰の中で、
2人の子供が通り過ぎ、
1人は真っ赤、もう1人は
薄緑-
「感じ」1980年7月
ポイントへ
1. TCP：コネクション型通信
1. TCP：概要（RFC：793、1122、1323、2018、2581）
説明：
・
いわゆるメッセージなしの境界：
送信者は2つの小さなメッセージを送信し、受信者は1つの大きなメッセージを受信するか、またはその逆です。
送信バッファと受信バッファ、
タイムアウト再送信またはエラー検出再送信の場合、送信速度と受信速度の一致に一貫性がありません
・
MTU：
最大伝送ユニット、最大データ伝送ユニット、最大ネットワーク伝送パケット。最大イーサネットMTUは1500B
です
。MSS ：最大セグメントサイズアプリケーションプロセスは、トランスポート層のTCPエンティティに配信されたセグメント、及びTCPセグメント（セグメント）にMSSのTCPヘッダ情報のサイズに応じてセグメント化される処理
・
したがって、（メッセージはバイトストリームに変換し、そして個々のMSSに分割）
MSS + TCPヘッダー情報+ IPヘッダー情報<= MTU（Ethernet MTU1500Bなど）、（「断片化に問題はありませんか？」どの断片化...）
・
それ以外の場合、IPデータグラムが送信されるデータリンクレイヤーのMTUが大きいため、データグラムを送信できません。
このネチズンの共有も参照できます：MSSとMTUの関係
2.TCPセグメント構造
説明をしてください：
16
ビットの送信元ポート、16ビットの宛先ポート、32ビットのシリアル番号、確認番号。
したがって、スマートで同じことが得られます：オプションの32ビット;チェックサムなど16ビット
バイトシーケンス番号：
アプリケーション層がメッセージに引き渡すために、各層のMSSと各TCPセグメント（セグメント）の本体を分割しますこの部分はペイロード部分（MSSに対応）であり、バイトストリーム全体のペイロードの最初のバイトのオフセット（オフセット）はバイトシーケンス番号です。
3. TCPシリアル番号、確認番号
受信者が順不同で処理するセグメントは、キャッシュまたはドロップすることができ、規制はありません。に応じて...
説明：
- ホストA→ホストBSeq = 42、ACK = 79、データ= 'C'：
ホストA、ネゴシエートされた初期シーケンス番号はSeq = 42であり、ホストBの初期シーケンス番号は79から始まり、バイトCはエコーする必要があります- 次に、ホストB→ホストA Seq = 79、ACK = 43、データ= 'C'：
ホストBは以前にSeq42を受信したため、処理後にACK = 43を確認します。同時に、ACK = 43は、ホストBが42以前を受信したことを意味し、ホストAが43から開始することを期待しています。
…それだけです
4. TCPラウンドトリップ遅延（RTT）とタイムアウト
RTTを適切に設定し、測定/推定します。
-
Q：TCPタイムアウトを設定するにはどうすればよいですか？
RTTより長いしかしRTTの変化
短すぎる：タイムアウトが早すぎる不要な再送信
長すぎる：セグメント損失に反応するには遅すぎる、マイナス -
Q：RTTを見積もる方法は？
SampleRTT：メッセージセグメントが送信されてから確認を受信するまでの時間を測定します
再送信がある場合は、この測定を無視し
ますSampleRTTが変更されるため、推定RTTはよりスムーズになります
現在のSampleRTT
TimeoutIntervalは、適応測定と計算され
、現在EstimatedRTT計算：
`" EstimatedRTT =（1-α）EstimatedRTT + αSampleRTT "：
等号の左側は現在の平均RTTであり、等号の右側の推定RTTは最新の平均RTTです。他のすべてのサンプリングの前時間、もう1つ（1-α）、現在の平均への寄与は指数関数的に減少します。
`
推定：調整推定。
このDevRTT（偏差RTT）は、標準偏差と非常によく似ています。これは、SampleRTTとEstimatedRTTの間の偏差/変化値です
。DevRTT=（1-β）DevRTT +β（| SampleRTT-EstimatedRTT |）：平滑化された値の差を計算します。 RTTと実際の（加重）移動平均）
次に、RDTを実行しているTCPを見てください
2. TCP：信頼性の高いデータ転送
TCPはIPの信頼できないサービスに基づいてrdtを確立しました
- パイプラインセグメント（•GBNまたはSR）
- 累積確認（GBNなど）
- 単一の再送信タイマー（GBNなど）
- 順不同で受け入れることができますか、標準はありません
再送信は、次のイベントによってトリガーされます
- タイムアウト（最も早い未確認のセグメントのみが再送信されます：SRのように）
- 繰り返し確認
- 例：ACK50を受信した後、3つのACK50を受信した（冗長確認応答）
まず、簡略化されたTCP送信者について考えます:(以下のポイント1）
- 繰り返しの確認を無視する
- フロー制御と輻輳制御を無視する
1. TCP送信者（簡略版
次の図についての私の説明：
・
最初に、TCP接続を確立します。点線から始めて、初期化次のシーケンス番号とSendBase、そこにある
（最初の送信者として、最初のバイトのシーケンス番号て送信は、初期シーケンス番号からです）
・
次に、イベントを待ち、
その後、時計回りに見ては。
したがって、待機が始まり、アプリケーションプロセスがデータに到達し、セグメントを作成して、ウィンドウのフロントシーケンスを送信します。
次に、下位層を見つけて、IPカプセル化データグラム
送信の最前線のスライディングウィンドウを送信します：（NextSeqNum NextSeqNum + = length（Data））
はカウントされず、タイマーが開始されます
・
タイムアウトの場合、SRのような未確認のセグメントの最小数のみを送信
します、一度にすべての未確認のものを渡すのではありません
`
ACKを受信し、ACKの値がyの
場合、y> SendBaseの場合、SendBase = yです。これは
、送信ウィンドウの後端を位置yにスライドするのと同じ
です。タイマー操作用のタイマー、写真を見てください
1.1TCP送信者イベント:(上の図の説明へのppt）
アプリケーション層からデータを受信します。
- nextseqでセグメントを作成する
- シーケンス番号nextseqは、メッセージセグメントの最初のバイトのバイトストリーム番号です。
- 実行されていない場合は、タイマーを開始します
- タイマーは、最も古い未確認のセグメントに関連付けられています
- 有効期限間隔：TimeOutInterval
タイムアウト：
再送信後の最も古いセグメント
タイマーを再起動します
確認の受領：
- 未確認のセグメントを確認する場合
- 確認されたメッセージのシーケンス番号を更新しますまだ確認されていないメッセージセグメントがある場合は、タイマーを再起動します
1.TCPの送受信画像を実現するための擬似コードを楽しみましょう
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running)
start timer
pass segment to IP
NextSeqNum = NextSeqNum + length(data)
event: timer timeout
retransmit not-yet-acknowledged segment with smallest sequence number start timer
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
} /* end of loop forever */
/*注释：• SendBase-1: 最后一个累积确认的字节例：
• SendBase-1 = 71;
y= 73, 因此接收方期望73+ ;
y > SendBase，因此新的数据被确认
*/
最後に、別の画像に移動
して、順番に受信した最上位バイトを確認します。
2. TCPACKを生成するための推奨事項[RFC1122、RFC 2581]
3.高速再送信
高速再送信：タイマーが切れる前にメッセージセグメントを再送信します
繰り返しのACKによるメッセージセグメントの損失の検出
- 送信者は通常、多数のセグメントを継続的に送信します
- メッセージセグメントが失われると、通常、複数のACKが繰り返されます（受信されます）。
送信者が同じデータに対して3つの冗長ACKを受信した場合（下図に示すように3つの冗長ACK50）、
- シーケンス番号が最小のセグメントを再送信します。
- 確認されたデータに続くデータが失われたものと想定
•最初のACKは正常です。
•このセグメントの2番目のACKが受信されます。これは、受信者がこのセグメントの後にシーケンス外のセグメントを受信したことを意味します。
•このセグメントの3番目と4番目のACKが受信されたことを意味します。レシーバーこのセグメントを受信した後、2つまたは3つのシーケンス外のセグメントが失われる可能性が非常に高くなります
3.1高速再送信アルゴリズム：
dup：重複：形容詞まったく同じ、冗長
3、TCP：フロー制御
受信者は送信者を制御し、受信者のバッファがオーバーフローするの
を
防ぐために送信者が送信しすぎたり速すぎたりすることを許可しません
TCPソケットレシーバーバッファー：TCPソケットレシーバーバッファー
その場合、TCPは全二重であるため、次のようになります。
- 受信者は、 TCPセグメントヘッダーのrwndフィールドにある空きバッファサイズを送信者に「アドバタイズ」します。
（個別の確認メッセージではなく、エクスプレスボックスの小さなマーク「空きバッファスペース」）- RcvBufferサイズはソケットオプションによって設定されます（通常のデフォルトサイズは4096バイトです）
- 多くのオペレーティングシステムは、RcvBufferを自動的に調整します
- 送信者は、受信者が圧倒されないように、未確認（「実行中」）バイト数≤
受信者から送信されるrwnd値を制限します。
受信ウィンドウと受信バッファを確認します（受信ウィンドウ&&受信バッファフィールド）
4、TCP：接続管理
正式にデータを交換する前に、送信者と受信者は握手して通信関係を確立します。
- 接続を確立することに同意します（各当事者は、相手が接続を確立する意思があることを知っています）
- 接続パラメータに同意する
1.接続を確立することに同意します
双方向ハンドシェイクの失敗シナリオ：
半接続、
左側のクライアントホストプロセスは、acc_conn（x）タイムアウトにより、新しい接続要求（req_conn（x））を再送信
し、サーバーホストプロセスが半接続を維持する結果になります
2. TCP 3ウェイハンドシェイク（2ウェイハンドシェイクソリューション）
TCPにはフラグビットSYNがあります。
SYN = 1は接続要求を表します
Seq = xはxバイトからの送信を表します
通常、最初のデータ転送と3番目のハンドシェイクは一緒に行われます。
2.1スリーウェイハンドシェイクソリューション：半分の接続と古いデータの受信の問題
固定シーケンス番号ではなく、TCPセグメントのシーケンス番号として初期化シーケンス番号を使用します。
これにより、古い接続のデータが新しい接続のデータに干渉するのを
効果的に回避できます。
2.2スリーウェイハンドシェイク：FSM（有限ステートマシン）
いくつか送って見てください〜
3.TCP：接続を閉じます
- クライアントとサーバーはそれぞれ独自の側で接続を閉じます（両方向の接続は別々に削除されます）
FINビット= 1でTCPセグメントを送信します（FIN = 1は接続を閉じることを意味します） - FINを受信したら、ACKで応答し
ます。FINセグメントを受信すると、ACKはそれ自体が送信するFINセグメントと一緒に送信できます。 - 同時FIN交換を処理できます
面白いことがいくつかありますが
、FINの確認が届かない場合はどうなりますか？
FINがまったく通過できない場合はどうなりますか？
誰かがFINを偽造して相手に送信した場合はどうなりますか？
ハハハ
TCP接続の解放は完全ではなく、タイマーメカニズムを使用して接続を切断します。
この記事の終わり