TCP协议的相关机制

TCP全称为 “传输控制协议(Transmission Control Protocol”)。TCP拥有8大特性来保证稳定性）1.确认应答，2.超时重传，3.连接管理(分为三次握手和四次挥手，4.滑动窗口 , 5.流量控制，6拥塞控制，7.延迟应答，8.捎带应答，9面向字节流（粘包问题）. 10.TCP中的异常处理）

其中1.确认应答和2.超时重传是保证可靠传输最核心的机制（TCP设计出来就是为了解决可靠性）

3.连接管理验证通信双方的发送和接受能力是否各自正常（也对可靠性有一定的帮组）

4.滑动窗口 在前面三个保证了可靠性的同时 会牺牲传输效率 所以有了滑动窗口 让我们在保证了可靠性的同时 又尽可能的提高效率 （本质上是批量发送一波数据 然后批量的等待一波ACK  而这里的ACK不是需要全部等到之后在发送 而是来一个ACK就发送一个ACK 就不需要等待ACK就可以继续往后发送，而发送的数据的长度就称为窗口大小，滑动就是每收到一条ACK就发送一条 这样窗口看起来就很像滑动了）

5.流量控制和6.拥塞控是针对滑动窗口进行的补充（滑动的窗口越大 那么传输效率就越高  但是窗口无穷大的话 就和UPD一样变成不可靠的了）所以就有了5,6这两个控制  

5.流量控制是针对接收方的处理能力做出限制 接收方有一个接受的缓冲区 我们可以根据接收方的接受缓冲区剩余的大小 去衡量发送发需要按照多大的大小去发送

6.拥塞控制 衡量当前网络传输中的中间节点 查看这些中间节点是否出错 或者 丢包 堵塞

7.延迟应答 是一个提高传输效率的机制 也是基于流量控制来引入的提高效率的机制 为了让窗口的大小更大一些（举个例子水桶有20kb的容量 水桶有10kb的水位了  然后此时又来了1kb 其实剩余的大小就只有9kb了 如果立即返回ACK 那么此时的容量大小就为9kb 然后如果我们稍等一会(延迟应答)在返回ACK的话  应用程序就会从缓冲区里取走了一大波的数据 那么我们在返回ACK 此时返回的窗口大小就会变大了）

8.捎带应答 基于延迟应答的基础上引入的 在网络中 典型的通信模型就是一发一收 但如果稍等一会正好业务上也需要返回响应 就可以一起返回了 （比如我想去喝水 但是我不想动 我可以等我要去上厕所的时候 顺便喝一口水）

9.粘包问题 发送数据的时候 可能会粘在一起 但时候取出来就不完整了 可以通过

（1）通过分隔符 比如约定使用;作为包的结束标记

（2）通过指定包的长度 比如在包的开头位置声明长度

也可以通过自定义应用层协议（之前的大佬写的）

（1）.xml:分隔符就想到与结束标签

（2）json:分隔符就想当需)

（3）.protobuffer,里面通过声明长度的方式来确定边界

（4）.http;分隔符和长度两个都会用到

10.

（1）程序奔溃：进程异常退出 操作系统会回收进程的资源 包括释放文件描述符 相当于对应socket 的 close 就会触发FIN报文，进一步的开始四次挥手 （程序奔溃 和 普通的四次挥手没啥区别）

（2）电脑正常关机（桌面的关机）：关机的时候系统会强制结束所有的用户进程 和 进程奔溃类似  系统内核也会进行文件描述符的释放操作 进一步的进行四次挥手

（3）主机掉电关机（电源）：

掉电的是接收方：这时掉电的是接收方 但是发送发不知道对面挂了 就会继续发送数据 此时发送的数据没有ACK了 发送方就会触发超时重传 重传几次后仍然没有应答，就会尝试重置连接 但是也会失败 最终就放弃连接了。

掉电的是发送方：掉电的是发送方 此时接收方就一直等着等着等着一段时间后 就会发送一个心跳包（心跳包是周期性触发的 只是一个简单的不携带任何数据业务的包 存在的意义就是确认一下对方是否还在）如果对方正常就会返回一个心跳包 如果对方没有返回心跳包说明对方已经挂了 此时放弃连接

（4）网线断开：情况和主机掉电一样 只不过通信双方的主机都是好的 这两端这各自按照上诉两种情况进行

 

FIN：结束报文段

ACK：确认报文段

SYN：同步报文段

四次挥手在有些特定的情况下 也可以变成三次挥手