TCP标准的报头长度是20字节，但是由于有选项这一浮动项，所以报头长度是浮动的。所以报头中有一个字段为4位首部长度：代表报头有多少四字节，4位的空间最大值为15，所以报头最大长度为4*15位60字节。可以看到TCP是没有标识有效载荷的长度的，这也体现出面向字节流的特性（可能会存在粘包问题）。

16位窗口大小：接收缓冲区剩余空间的大小。

6个标志位：

SYN标志位：建立连接标志，如果该标志位被标记，说明是建立连接的数据包。
FIN 标志位：断开连接标志，如果该标志位被标记，说明是断开连接的数据包。
ACK标志位：确认标志位
PSH标志位：提示接收端应用程序立刻从TCP缓冲区把数据读走
RST标志位：对方要求重新建立连接，我们把携带RST标识的称为复位报文段

以下四种情况会发送RST包：

端口未打开。
请求超时。
提前关闭。
在一个已关闭的socket上收到数据。

注意：服务器崩溃后的重启是不会收到RST的。

URG标志位：紧急指针标志位，和16位紧急指针相关。

16位校验和：CRC校验，校验整个TCP报文（报头+数据）。

TCP是以段为单位发送数据

由于TCP是以段为单位进行发送数据，MSS（Maximum Segment Size）为该段的最大消息长度。最理想的情况下，最大消息长度正好是IP中不会被分片处理的最大数据长度（IP是否分片又取决于底层MAC帧的最大传输长度（MTU），默认情况下MTU = 1500字节）。

通信双方在建立连接时进行协商MSS值的大小，也就是在发送SYN时会在TCP头部写入自己能支持的MSS值，通信双方选择最小的MSS值作为双方通信最终的MSS，MSS的值就是在TCP首部的40字节变长选项中。下图为协商MSS大小的示意图：

超时重传

如果发送端在一定时间内没有等到确认应答的数据包，发送端就认为该数据包丢失，此时需要重传，可以看到，这也是TCP可靠性的一种体现。

发送端认为数据包的丢失有两种情况

1、数据包没有到达接收端。

可能因为网络拥堵等原因，数据包未到达对方，接收端等待一个特定的时间后未收到确认应答，就会将数据进行重发。

特定的时间

这个时间的长短其实和网络环境相关。

等待时间太长重传的效率变低，等待时间太短频繁的发送数据包会造成网络负担变大。

重发超时的时间 > 数据包的往返时间（RTT）+ 偏差。

在Linux中，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次后仍得不到应答，则下一次的重发时间将是2倍、4倍的指数函数延长。当然这个时间也不是无限的延长，在重发一定次数后仍没有任何应答返回，发送端判定对方发生异常，强制关闭连接，并通知上层通信异常终止。

2、数据包到达了接收端，但发送端没有收到确认应答。

这种情况就是接收端会受到重复的数据包，那么对于重复的数据包该如何处理呢？

因为存在序号，出现相同的序号说明之前有收到过同样的包，则丢弃相同序号的数据包。

TCP三次握手

TCP是面向连接的，所以在双方正式通信之前得先建立连接。建立连接的过程如下图所示：

上图就是经典的三次握手的过程，站在实际编程的角度来看，双方都得先创建套接字，服务器还需要绑定ip地址和端口号，并将套接字变为监听套接字。

一旦客户端调用connect函数，就会发出建立连接的请求，接下来的任务交给操作系统完成。

首先客户端发送SYN，状态为SYN_SENT状态。

当服务器收到SYN时，服务器会进入SYN_RCVD状态。

服务器接下来发送SYN+ACK，当客户端收到SYN+ACK时会立即进入ESTABLISHED状态，并发送ACK。

当服务器收到ACK后也进入ESTABLISHED状态，三次握手建立连接结束。

注意：accept发生在三次握手之后，三次握手的过程其实是监听就完成了，accept只是为了取走连接。

为什么是三次握手？

三次握手服务器和客户端至少有一次收和一次发。这样可以测量信道的好坏。

1、可以验证TCP的全双工（保证互相都能正常的通信）

双方都要发送数据，且双方都可以收到对方的数据，这样才能确保互相可以正常的通信。

一次握手和两次握手就存在至少有一方的信道状态是不确定的。

一次握手的问题

一次握手客户端向服务器发送请求就直接建立连接，这个过程和UDP没什么区别。根本无法知道服务器是否成功建立连接。

两次握手的问题

客户端发送SYN，服务器返回SYN+ACK，客户端收到SYN+ACK，连接建立，此时只知道客户端到服务器的信道是通畅的，但是服务器到客户端的信道是否通畅。其实和一次握手没有太大的区别

一次握手和两次握手都容易造成SYN洪水攻击。

2、不让服务器建立连接出现误判的情况

在三次握手过程中，这三次的报文都有可能丢失，但是最后一次的报文的丢失是影响最大的，原因是，最后一次客户端向服务器发送ACK之后，客户端这边默认是连接已经建立（在操作系统层面就是一批数据结构的创建和文件描述符的资源等）。

如果是四次握手，让最后一次握手在服务器这里，报文的是否丢失都会默认以为连接建立好，增加了服务器的开销，很明显，我们不想增加服务器的开销，毕竟服务器不是未一个客户端所服务的。

五次握手、七次握手等等也可以建立连接，但不是最优解。所以说三次握手是最优解。

绝对可靠性

网络通信不存在绝对可靠性，因为永远最近的一个ACK不可靠，不可能无限ACK下去。

相对可靠性

当client发送数据给server，server应答ACK，这个ACK是确保上一个数据的准确发出，如果client不管是什么原因没有收到ACK，client会重新发送一次数据给server（超时重传）。

TCP的四次挥手

通信双方都可以率先关闭连接，以客户端首先关闭连接为例。

客户端在应用层调用close函数关闭socket套接字，之后操作系统会发送FIN给服务器。

客户端这边发送FIN后进入FIN_WAIT_1状态，服务器收到FIN后进入CLOSE_WAIT状态，并发送ACK给客户端。，当客户端收到服务器返回的ACK时，两次挥手的过程完成，客户端的状态变为FIN_WAIT_2，客户端到服务器的通信信道关闭。

服务器这边也发起close关闭连接，发送FIN，服务器进入LAST_ACK状态。当客户端收到服务器的FIN数据包后进入TIME_WAIT状态，并返回ACK。服务器正常收到ACK，剩下两次挥手完成，服务器到客户端的信道也关闭。

两个状态：CLOSE_WAIT和TIME_WAIT

如果服务器存在大量的CLOSE_WAIT状态的连接，就是说明服务器没有close掉对应的文件描述符，文件描述符也是一种资源，会造成系统资源的浪费。

TIME_WAIT状态的作用是避免服务器没有收到最后一个ACK，或者说最后一个ACK丢失，则服务器不会进入CLOSED状态。

由于四次挥手的过程也是数据的通信，每一次都有可能会丢包，如果是最后一次ACK的包丢了，沿用上面的例子，如果不设置TIME_WAIT状态，客户端直接进入CLOSED状态，则不会进行超时重传的机制。导致服务器这边一直在超时重传FIN，迟迟无法进入CLOSED状态。

所以TIME_WAIT状态就是为了降低失败的概率，客户端会等待一段时间，如果没等到FIN就会认为服务器已经收到了ACK，接下来客户端就会断开连接，如果再次收到FIN，则客户端再次发送ACK。

TIME_WAIT等待的时间：2MSL（MSL报文最大的生存时间，超过这个时间报文就会被丢弃，通常为30s，1min，2min等）。

除此之外TIME_WAIT还可以保证历史数据在网络上消散，以及新的连接的到来不受之前延迟报文的影响。