目录
引言
报头和有效载荷
确认应答机制
捎带应答机制
超时重传机制
排序和去重
连接管理机制
个人主页：东洛的克莱斯韦克-CSDN博客
引言
TCP是传输层协议，全称传输控制协议。TCP报头中有丰富的字段以及协议本身会制定完善的策略来保证网络传输的可靠性。
TCP是全双工（可以同时读写）的，因为TCP协议维护了两块缓冲区，一个用来读，一个用来写。建立链接成功会返回给应用层文件描述符，应用层调用该文件描述符写入，数据就刷到写缓冲区，应用层调用该文件描述符读，就会从读缓冲区读取数据。
报头和有效载荷
数据部分称为有效载荷，剩下的称为报头。报头是结构化数据。
源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去
4 位TCP首部长度 : 表示该 TCP 头部有多少个 32 位 bit( 有多少个 4 字节 ); 所以TCP 头部最大长度是 15 * 4 = 60，上述选项中报头去掉选项固定大小是20字节，报头的选项可带可不带，所以报头的长度是20到60字节
标志位
URG: 紧急指针是否有效
ACK: 确认号是否有效，应答
PSH: 提示接收端应用程序立刻从 TCP 缓冲区把数据读走
RST: 对方要求重新建立连接 ; 我们把携带 RST 标识的称为 复位报文段
SYN: 请求建立连接 ; 我们把携带 SYN 标识的称为 同步报文段
FIN: 通知对方 , 本端要关闭了 , 我们称携带 FIN 标识的为 结束报文段
16 位窗口大小 ：用于流量控制
16 位校验和 : 发送端填充 , CRC 校验 . 接收端校验不通过 , 则认为数据有问题 . 此 处的检验和不光包含 TCP 首部 , 也包含 TCP 数据部分 .
16 位紧急指针 : 标识哪部分数据是紧急数据 ;
32位序号：TCP 将每个字节的数据都进行了编号 . 即为序列号。
32位确认序号：每一个 ACK 都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发
数据：整个报文的有效载荷
确认应答机制
在网络通信中，主机A向主机B发消息，主机A不可能知道数据包是否到达了主机B。所以需要主机B向主机A应答，让主机A知道数据包并没有丢失。
需要通过应答来确保单方向上通信的可靠性，单方向是因为主机B不知道自己的应答是否丢失，如果主机B要确认自己的应答是否丢失就需要主机A再向主机B发送应答，这样的话就套娃了，所以没有完全可靠的通信，只能确保单方向上的通信。
捎带应答机制
捎带应答是指TCP发送方在发送数据包时，如果此时正好有确认消息（ACK）需要发送给接收方，则将确认消息捎带在数据包中一起发送，从而减少网络中的确认消息数量，提高网络利用率。这种策略通常建立在延时应答的基础上，因为延时应答使得发送方有机会在等待ACK的过程中积累更多的数据或确认消息进行合并发送。
超时重传机制
基于上述的应答机制可以再思考一下，主机A发出的数据包可能丢了，可能在某个路由下排队。对应的，主机B收到了数据包，那应答的数据包万一丢失了呢？
为了应对上述情况，TCP在发出一个数据包时，会设个时间，只要超出这个时间主机A都认为主机B没有收到数据包，会重新发送。
Linux 中 (BSD Unix 和 Windows 也是如此 ), 超时以 500ms 为一个单位进行控制, 每次判定超时重发的超时时间都是 500ms 的整数倍。 如果重发一次之后, 仍然得不到应答 , 等待 2*500ms 后再进行重传 。如果仍然得不到应答, 等待 4*500ms 进行重传。 依次类推 , 以指数形式递增。 累计到一定的重传次数, TCP 认为网络或者对端主机出现异常 , 强制关闭连接。
排序和去重
主机A可能向主机B发了很多数据包，由于网路问题，数据包到达主机B可能乱序了。认识了上述重传机制后主机A可能向主机B发送同样的数据包。那么主机B怎么做到排序和去重呢——TCP报头中的序列号。
主机B收到数据包后会给主机A响应，即发送的TCP报头中的确认序号分别为1001，2001，3001。那么此时，我们时允许主机B响应的数据包可以有部分丢失，如果拿到了带有3001序号的TCP报头，那么主机A就知道前3000个字节已经成功发送给B，即使前两个响应的数据包丢失了也没关系，此时主机A知道下次应该从3001开始传。
连接管理机制
在TCP协议通信之前是要建立链接的，OS也要创建对应的内核数据结构管理链接。通信双方发送TCP的报头协商——包头中的标志位。
建立链接要三次握手，握手是个形象的说法，本质是通过TCP报头中的标志位协商
上图中只画了标志位，实际传输时双方用TCP报头协商。
客户端发起SYN请求，服务端响应SYN和ACK表示自己也要建立链接并告诉客户端自己已经收到链接请求，此时客户端才的OS才创建相关的内核数据结构管理该链接，客户端在给服务端发送ACK只要服务器收到了ACK，服务端才建立链接，OS也会创建相关的内核结构来管理该链接，至此双方完成握手。
如果第三次的ACK丢包了呢？ 那么客户端和服务端在短时间内会有认知偏差，在三次握手规定中，第三次的ACK不会得到服务端的响应，那么只要客户端把该报头发送出去，就认为双方握手成功，但该数据包丢失了，服务端会认为握手失败，并给客户端发送带有 RST标志位的数据包来要求客户端重新握手。
完成三次握手就可以让双方知道前两次通信一定没有问题，可以验证全双工。
三次握手建立链接可以有效避免 SYN洪水问题，可以拿一次握手，两次握手来比较差别。
从图中可以看出，只要客户端发起SYN请求服务端就要建立链接，服务端维护链接耗费的资源先不谈，如果客户端在握手期间出异常了服务端并不清楚的情况下要一直维持链接，链接资源是有限的，如果客户量大的话就要维持很多无效链接。如果有大量的肉机不断地发送SYN请求，服务器上地服务很容易挂掉。
断开链接要四次挥手
整个过程如下图
