和前面文件刷新关联一下
保证可靠性的策略&确认应答机制
序号&确认序号
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发送缓冲区里数据包装，发给服务端，放到对端的接收缓冲区，被削掉报头，有效载荷放入其中，其中，有效载荷是面向字节流的，服务器上层应用读取接收缓冲区的数据，****必须定制好应用层协议，保证读到的是一个完整请求。因此对方发的时候，应该要求把数据 按定好的协议 结构化拼接，转成序列化的字符串，然后服务端 通过协议，读取完整请求，并反序列化，**进而处理请求做出应答
- 粘包问题就是这么产生的，它本质上就是如何读取一个完整的请求，就是在请求之间、在发送之前、手动添加 分隔符，在每个报文开头，手动添加包的长度
底层机制
完。