和前面文件刷新关联一下

保证可靠性的策略&确认应答机制

序号&确认序号

16位窗口大小

6个标志位-----tcp报头完事

具体机制

确认应答机制，前面已经讲过啦，这里谈一下序号

超时重传机制&丢包

连接管理机制-3次握手建立连接&4次挥手断开连接

• 操作系统知道客户端发了 FIN，但它不知道服务端的业务逻辑：
  • 是不是还有数据要回写给客户端？
  • 是不是要等业务处理完再关？
• 所以它必须把这个决定权交给服务端的应用程序，自己不能擅自把连接关了，close(fd)要等上层自己调用
• 如果应用层一直不调用 close() 关闭这个 socket，内核中的连接就会一直处于 CLOSE_WAIT 状态，既操作系统不发 FIN 给客户端，也不释放文件描述符。
• 客户端那边早就 CLOSED 了，服务端这边却一直挂着 CLOSE_WAIT，资源被白白占着

穿插一个话题--TCP连接异常情况

进程终止，文件描述符和正常close(fd)一样，连接 正常四次挥手并被释放，因为打开文件的生命周期随进程

机器重启，也是同上，关机之前，OS要关闭所有进程

网线断开\机器掉电，

连接保活--TCP自带，几十分钟级别的，应用层自己完成，请求一下对方，有响应就活着呢！

滑动窗口 并行发送

流量控制

其实上文已经谈完了，这里再说一下流程

如果发送端发送的数据超过接收端缓冲区的容量，就会造成丢包，进而引起丢包重传等问题

解决方案

• 接收端将自己可以接收的容量-也就是接收缓冲区剩余空间大小放入 TCP 报文 的“16位窗口大小”中-65535字节（TCP首部选项40字节中 还包含窗口扩大因子M，让窗口左移M位），通过ACK发送给 对端
• 发送端 知道了 对方可以接收的 容量大小，改变自己的 发送缓冲区的 滑动窗口大小，发送 该窗口内的一批数据，这时 一定不会 超出 对方的接受能力
• 如果 对方接收缓冲区满了，我将滑动窗口 start = end，发送端 不再向 对方发送数据，但需要定时的 发送 不携带数据的报文，根据对方的ACK，探测对方的 接收缓冲区是否可以 继续放数据（上层把数据取走），然后判断是否继续给对方发数据

上层如果一直不取走数据，发送端 发送的报文里 携带选项 PSH，要求对方上层应用 尽快将 数据取走

拥塞控制

发送端 给 对方 发送的数据容量，不仅受 对方接收缓冲能力的影响，还受网络环境的控制，假如对方能力很强，但网络拥堵，这些数据发到网络上后，会使网络雪上加霜，数据也很难发到对端，所以 我们要 在网络状况允许的 情况下，在对方接收能力允许的条件下，尽可能多的 发送 数据。

延迟应答--确认序号是底层支持

捎带应答

上文已经说过了，这里浅谈一下

很多时候，客户端给服务端发请求，基于延时应答的基础上，客户端发多个请求报文，服务端给对方ACK应答一次，但有时候，服务端不仅要应答（无有效载荷），这是一个报文，还要给客户端发数据，这又是一个报文，那我们可以把两个报文合并，给对方发过去一个报文，捎带上应答ACK，也就是对应报文的标志位置1。

捎带应答也是用来提高效率的

其他话题：

TCP是面向字节流&粘包问题

• 比如客户端给服务器发消息的时候，客户端OS把TCP发送缓冲区里数据包装，发给服务端，放到对端的接收缓冲区，被削掉报头，有效载荷放入其中，其中，有效载荷是面向字节流的，服务器上层应用读取接收缓冲区的数据，必须定制好应用层协议，保证读到的是一个完整请求。因此对方发的时候，应该要求 把数据 按定好的协议 结构化拼接，转成序列化的字符串，然后 服务端 通过协议，读取完整请求，并反序列化，进而处理请求做出应答
• 粘包问题就是这么产生的，它本质上就是如何读取一个完整的请求，就是在请求之间、在发送之前、手动添加 分隔符，在每个报文开头，手动添加包的长度

底层机制

---

完。