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 报文给客户端，所以二次挥手不可与三次挥手合并， 所以需要四次挥手，如果只有三次挥手，可能会导致数据丢失。