TCPヘッダフォーマット
送信元ポート番号、宛先ポート番号が不可欠であり、それはUDPと同じです。これらの2つのポート番号なし。データが送信されるべきアプリケーション分かりません。
なぜ、パケット番号を与えますか？もちろん、アウトオブオーダーの問題を解決するためです。それに対するの必要があり、その後、最初に来る必要がありますどのように良いの数を確認するためにプログラムされていません。番号は、この問題を解決するための外にあります。
また、いくつかの確認番号があるはずです。パッケージには、確認するために送り出されるべき、または他の私は、他の側がそれを受信していないことを知っていますか？あなたが受け取っていない場合は役立っまで、再送信する必要があります。この問題は、パケットロスなしに解決することができます。
TCPトランスポート層のためにトリッキーですが、パイプのネットワーク層でのパケット損失の問題がより少ないですが、信頼性の確保しようとします。
次に、ステータス・ビットの数があります。例えば、接続が開始し、SYN、ACK応答がFINは、エンド・コネクションで、RSTが再接続されます。TCPは接続指向であるので、2つの側面は、パッケージとこれらのステータスビットを送信し、それが両側の状態変化の原因となります、接続の状態を維持する必要があります。
もう一つ重要なことは、ウィンドウサイズです。ドゥTCPフロー制御、通信、各側は窓を宣言し、対処する彼らの現在の能力を識別し、あまりにも速く送信しない、チェンSiの私は、遅すぎる送信、私は餓死しないでください。
フロー制御以外のことに加えて、TCPの輻輳制御を行います。
順序の問題、安定していない混乱。
パケット損失、コミットメントフライ。
接続の維持、始まりと終わり。
フロー制御、妥当性の感覚。
知られているに戻し知られている輻輳制御、。
TCP 3ウェイハンドシェイク
A：こんにちは、私は
B：こんにちは、私はBです
：こんにちはB
接続が確立された後、Aがデータを送信すると、ほとんどのケースでは、AとBは、Aが、すぐにデータが送信されます、多くの問題が解決されました。応答がBに送られ、例えば、紛失、データに後続の到着を送信するとき、Bはこの接続が確立されている、または彼らはBをハングアップしていると思うかもしれ、Aはその後、それはBが到達不能であること与えられているので、データを送信しますBは事を知っています。
シャットダウンするためのイニシアチブをとることができ、クライアントを契約していないような長い時間のために、サーバBプログラムデザイナーとしてのあなたは、それによって、他のクライアントで使用するリソースを解放します。
主にTCPパケットのシリアル番号を除いて、ある一つのことを、通信するために、外部接続の問題を確立するためのスリーウェイハンドシェイク。
TELL B号パッケージは数は、BもAを伝えるために持っているの先頭から私の顔を立ち上げ、そこから始まるパッケージのBナンバーは番号の先頭を開始しました。なぜ1からのすべての数字は、開始するにはできないのですか？それは、常に競合になりますので。、例えば、AもBの後に、それはパケット1,2,3 3を送信するが、変速機3、中間紛失、または迂回するので、再送は、その後、Aも再Bの後に、ダウンしている場合第1および最初から、その後2を送信するが、3を送信するために思ったことはありませんが、Bに送信された3バックが、これは次のパケットであることをB、自然、エラーが発生したことを最後に迂回。
このように、各接続が異なるシリアル番号を持っている必要があります。この数は、時間をかけて、32ビットカウンタとして見ることができる開始シーケンス番号の変更、4ms毎プラスワンであるかの計算、もし4時間以上繰り返し必要性、迂回パケットすでに死んアリスアリス、あるTTL、生存時間を持つIPヘッダ、我々はすべて知っているので。
最初に、クライアントとサーバはCLOSED状態になっています。まず、サーバは、積極的にLISTEN状態では、ポートで待機します。次に、クライアントはで後に接続SYN、SYN-SENT状態を開始します。サーバーは、以下に復帰SYN、ACKおよびクライアントSYN、SYN-RCVD状態を開始された接続を受け取ります。クライアントが受信した後、SYNとACKを送信し、サーバーから送信された
それピッチキャッチ成功するので、その後、ESTABLISHED状態で、ACK ACKを。サーバーの後、それはピッチキャッチアップするので、ESTABLISHED状態で、ACK ACKを受け取ります。
TCP 4波
A：Bああ、私はプレーしたくありません。
B：ああ、あなたは私が知っている、ああ、プレーする必要はありません。
半密閉ケース
B：Aああ、まあ、私はさようなら、再生されません。
A：OK、さようなら。
オフは、我々は、彼らがBを受信した後の状態FIN_WAIT_1を入力して、Aが言うとき、「再生されない」ことを確認することができ、ニュースを「Aは、再生されない」CLOSE_WAITの状態に、それを知って送信します。
A 收到“B 说知道了”，就进入 FIN_WAIT_2 的状态，如果这个时候 B 直接跑路，则 A 将永远在这个状 态。TCP 协议里面并没有对这个状态的处理，但是 Linux 有，可以调整 tcp_fin_timeout 这个参数，设 置一个超时时间。
如果 B 没有跑路，发送了“B 也不玩了”的请求到达 A 时，A 发送“知道 B 也不玩了”的 ACK 后，从 FIN_WAIT_2 状态结束，按说 A 可以跑路了，但是最后的这个 ACK 万一 B 收不到呢？则 B 会重新发一 个“B 不玩了”，这个时候 A 已经跑路了的话，B 就再也收不到 ACK 了，因而 TCP 协议要求 A 最后等 待一段时间 TIME_WAIT，这个时间要足够长，长到如果 B 没收到 ACK 的话，“B 说不玩了”会重发 的，A 会重新发一个 ACK 并且足够时间到达 B。
A 直接跑路还有一个问题是，A 的端口就直接空出来了，但是 B 不知道，B 原来发过的很多包很可能还 在路上，如果 A 的端口被一个新的应用占用了，这个新的应用会收到上个连接中 B 发过来的包，虽然序 列号是重新生成的，但是这里要上一个双保险，防止产生混乱，因而也需要等足够长的时间，等到原来 B 发送的所有的包都死翘翘，再空出端口来。
等待的时间设为 2MSL，MSL是Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网 络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 域，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数 据报将被丢弃，同时发送 ICMP 报文通知源主机。协议规定 MSL 为 2 分钟，实际应用中常用的是 30 秒，1 分钟和 2 分钟等。
还有一个异常情况就是，B 超过了 2MSL 的时间，依然没有收到它发的 FIN 的 ACK，怎么办呢？按照 TCP 的原理，B 当然还会重发 FIN，这个时候 A 再收到这个包之后，A 就表示，我已经在这里等了这么 长时间了，已经仁至义尽了，之后的我就都不认了，于是就直接发送 RST，B 就知道 A 早就跑了。
TCP状态机
end