TCP报文协议：
TCP头部字段主要有序列号， 确认号， 源端口， 目的端口号， 标记位，头部长度， 窗口大小等， 其中源端口和目的端口都是16位，源端口是发送方使用的端口号， 目的端口是接收方使用的端口号， 序列号和确认号都是32位， 序列号可以保证数据的有效性，确认号可以保证数据的可靠性， 下面我们来逐个分解。
- 源端口 ：16位字节，发送方进程。
- 目的端口 ：16位字节，接收方进程。
- 序列号 ：32位字节，给每一个字节都设置一个序号，接收方可以根据序号对接收到的数据进行排序。
- 确认号 ：32位字节，告诉发送法我收到了序号 N-1 之前的所有数据，并且通知对方下次从序号N开始发送。
- 数据偏移／首部长度 ：4位字（一字是4字节），因为TCP的首部长度是不固定的，用来表示真正有效的数据，相对于整个TCP段的起始位置偏移了多少, 有利于接收方裁剪识别。
- 保留 ：6位字节，是协议设计者为未来预留的"空白地盘"。
- 校验和 ：16位字节，用来检查数据在接收的时候是否损坏。
- 窗口 ：16位字节，告诉发送法我这里还能存储多少字节的数据。
- 紧急指针 ：16位字节，一个特殊的插队机制。
- 选项和填充 ：选项MSS - 告诉对方，我能接收的单个数据包最大是多少，填充SACK - 如果丢了第 5 个包，但收到了第 6、7 个，SACK 可以告诉发送方"只重传第 5 个"，不用全重传。
- 数据部分 ：应用层的数据。
TCP建立连接：
TCP三次握手， 我们来详细了解一下这个过程
- 初始状态双方的TCP都处于close， 但是服务器会监听一个端口， listen来监听。
- 第一次握手， 客户端会生成一个随机的序列号 x 放到TCP协议的序列号当中，req=x， 然后会将SYN标志设置为1，发送给客户端，之后服务端处于SYN-SENT状态。
- 服务器接收到了客户端发送来的数据， 然后生成一个随机的序列号 y 放到TCP报文中，发送SYN=1, ACK=1，req=y, ack=x+1 之后服务器也处于SYN-SENT状态。
- 客户端接收到服务端发送来的数据，客户端会回一个ACK确认报文， 该报文的确认号就是ack=y+1, 序列号为服务端的确认号seq=x+1, 之后客户端处于ESTABLISHED状态。
- 服务端接收到ACK确认报文后， 服务端也处于ESTABLISHED状态。
为什么是三次握手而不是二次握手？
如果只有二次握手就会导致以下两个问题
- 无法确定客户端是否具备接收能力， 第一次握手可以确定客户端有发送能力， 第二次握手可以确定服务端具备接收和发送的能力， 如果没有第三次握手就无法确定客户端是否具备接收的能力。
- 资源浪费，当服务端接收到客户端发来的SYN并且确定建立连接时，服务器就会立即为连接分配资源， 如果接收到了一个过期的历史资源包，这个资源包有不需要客户端的确认， 就会在服务端一直挂着，耗费内存。
TCP断开连接
TCP四次挥手
- 初始状态都是WSTABLISHED
- 客户端向服务端发送FIN报文， 客户端进入FIN_WAIT_1状态。
- 服务端接收到了客户端发来的报文， 于是向服务端发送ACK确认报文，之后服务端进入CLOSE_WAIT状态。
- 客户端接受到服务端发送来的ACK报文， 于是进入了FIN_WAIT_2状态。
- 服务端处理完数据之后， 向客户端发送FIN报文，之后服务端处于LAST_ACK状态。
- 客户端接受到了服务端的FIN报文，向服务端回了一个ACK报文， 然后进入TIME_AWIT状态。
- 服务端接收到ACK报文， 进入CLOSE状态， 断开链接。
- 客户端在TIME_AWIT状态经过2个MSL后，就进入了CLOSE状态， 客户端的连接也断开。
为什么是四次挥手而不是三次挥手？
- TCP是全双工协议， 客户端和服务端都具备发送和接收的能力， 所以我们要保证双方的数据都发送处理完成 ，才能断开。当客户端向服务端发送了一个FIN报文， 这个时候就表示客户端的数据已经处理好了， 可以断开连接了， 然后服务端接收到客户端发来的FIN报文， 于是发了一个ACK确认报文， 说同意断开连接， 但是这个时候服务端还可能没把数据处理完，所以需要等服务端处理完成之后才可以发送FIN报文给客户端，所以二次挥手不可与三次挥手合并， 所以需要四次挥手，如果只有三次挥手，可能会导致数据丢失。