TCP首部

TCP报文格式.png

• 源端口和目的端口
  用于确定发送端和接收端的应用进程。
  { 客户IP：客户端口，服务IP：服务端口 } 四元组唯一确定互联网中的每一个TCP连接双方。

  • 服务端最大并发数是多少？
    理论上是这个4元组的所有数量。

• 序号
  用来标识从TCP发送端向TCP接收端发送的数据字节流，表示这个报文段中的第N个数据字节。范围 0 ~ (2^32-1)

• 确认序号
  发送端所期望收到的下一字节序号。确认序号应该是 上次已成功收到的数据字节序+1

• 4位首部长度
  包括TCP首部长度，为什么要只包括首部长度而不是像UDP中包括首部和数据的总长度？因为TCP首部长度是不固定的，而UDP的首部长度是固定的。

• 标志位

  • URG 紧急指针有效
  • ACK 确认序号有效
  • PSH 接收方应该尽快将这个报文段交给应用层
  • RST 重建连接
  • SYN 同步序号用来发起一个连接
  • FIN 发送端完成发送任务

• 窗口大小
  用于流量控制，参考TCP流量控制。

• 选项
  最常见的可选字段是最长报文大小，又称为MSS(Maximum Segment Size)，每个连接方通常都在通信的第一个报文段（SYN报文）中指明这个选项，它指明本端所能接收的最大长度的报文段，这样做，通常是为了避免报文分段。

TCP完整状态迁移图

TCP状态迁移图.png

TCP连接建立

• 客户发送一个SYN报文段指明客户打算连接的服务器的端口，以及初始序号ISN。

• 服务器发回包含服务器的初始序号的SYN报文段作为应答，同时将确认序号设置为客户的ISN+1以对客户的SYN报文段进行确认。所以1个SYN报文将用一个字节序。

• 客户发回一个确认序号为服务器的ISN加1的ACK报文对服务器的SYN报文进行确认。

  
  
  TCP连接建立.png

• TCP连接为什么需要3次握手，为什么不是2次或者4次？

  总的来说是为了防止已失效的的连接请求报文段突然又传送到了服务端，因而产生错误。

  假设client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。

  本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。

  采用 "三次握手" 的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

连接建立超时

当服务器

半打开连接

TCP连接的一端异常崩溃，或者在未通知对端的情况下关闭连接。比如一个常见的情况是TCP连接的一端异常断电，就会导致TCP的半开连接。如果没有数据传输，对端就不会知道本端的异常而一直处于ESTABLISHED状态（TCP也可以自己配置keepalive选项实现心跳）。此时如果发生数据传输，会产生RST。

注意区分半打开连接和半关闭连接。

同时打开

对于TCP，同时打开，它仅仅建立一条连接而不是2条。同时是4次握手

同时打开.jpg

TCP连接的终止

因为TCP的连接是一个全双工的，所以每一个方向必须单独关闭。

当一方完成它的数据发送任务就发送一个FIN给对方来终止这个方向上的连接。收到一个FIN只是意味着在这一方向上没有数据流动。
1、客户端发送一个FIN，用来终结客户到服务端的连接。
2、服务端收到这个FIN，它发回一个确认客户的ACK报文，和SYN一样，FIN也将占用一个字节序列。
3、服务端也向客户发送一个FIN报文。
4、客户发回一个确认已收到服务端的FIN报文的ACK报文。

TCP正常连接关闭.png

• 2MSL等待状态
  TIME_WAIT状态也称为2MSL状态。
  而MSL是指任何报文段在被丢弃前在网络内最长时间。

  为什么需要等待2MSL？

  • 当TCP执行主动关闭，并发送最后一个ACK，在TIME_WAIT状态停留的时间为2倍的MSL，这样可以让TCP可以有时间再次发送最后一个ACK，防止丢失（另一端超时并重发最后的FIN）
  • 在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段

  处于2MSL等待期间，插口中使用的本地端口在默认情况下不再使用，所以任何处于2MSL等待时，任何迟到的报文将被丢弃。

• FIN_WAIT_2状态
  在FIN_WAIT_2状态我们已经发出了FIN，并且另一端已对它进行确认。但只有当另一端的进程完成关闭（对端发送FIN），我们这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。这意味着我们这端可能永远保持这一状态，另一端也就处于CLOSE_WAIT状态。

异常关闭

终止一个连接的正常方式是一方发送FIN。有时这种也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。
但也有可能发送一个RST报文段而不是FIN来中途释放一个连接，这被称为异常释放。
收到RST报文段不会产生任何响应，也不会进行确认。收到RST的一方将终止该连接，并通知应用层连接复位。

半关闭

TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，这就是所谓的半关闭。

半关闭.jpg

同时关闭

同时关闭.jpg

参考资料
《TCP/IP详解 卷1：协议》[美] W.Richard Stevens