流量控制：
流量控制也是保证可靠性的机制
对于滑动窗口，批量发送数据而言，窗口越大，相当于批量发送的数据越多，整体的速度也就越快了，但是，速度越快越好吗？？（不一定哟）
如果你发送的太快了，瞬间就把接收方缓冲区给打满了，当接下来继续发送，此时数据就会丢包，这种情况下得不偿失，还不如发的慢点了！！通过流量控制，本质上就是让接收方来限制一下发送方的速度！让发送方慢点，甚至阻塞一下！！
拥塞控制：
滑动窗口的大小，取决于流量控制和拥塞控制！！
- 流量控制：衡量了接收方的处理能力！！
- 拥塞控制：衡量了传输路径的处理能力！！
其中的中间节点是一系列的交换机和路由器《——》木桶效率
很明显再传输路径上，任何一个设备处理能力，如果遇到瓶颈，都会对整体的传输速率产生明显影响！！
拥塞控制：就是要衡量中间节点的传输能力！
拥塞控制要衡量中间路径！但是中间路径上有多少节点？？（路由器，交换机）每个节点的当前情况？？甚至每次传输走的路径？？这些都是不一样的！！因此，可以通过实验的方式，找到一个合适的发送速率！！
开始的时候，按照一个小的速率发送，如果不丢包，就可以提高一下速率（扩大窗口的大小），如果出现丢包，则立即把速率调小，重复上述的过程，一直到动态平衡状态！！
另外：网络的拥堵情况，也不是一成不变的，处在时刻变化中，此时，处于拥塞控制，这样的策略也就能很好的适应变化的网络环境！
因此，拥塞窗口《——》拥塞控制，实验出来的窗口，则实际发送方的窗口大小为：拥塞窗口和流量窗口的最小值！！
延时应答：
提高传输效率！
TCP可靠性的核心是：确认应答！
ACK要发，但不是立即发，而是稍微磨蹭一会再发！
延时应答的效果就是通过这个延时，该接收方应用程序，趁机多消费点数据，此时反馈的窗口大小，就会更大一丢丢，此时发送方的发送速率也就能更快一些（同时也能满足让接收方能够处理过来！），当然，也不是所有的包都延迟，也得看情况！！
- 数量限制：每隔N个包就应答一次
- 时间限制：超过最大延迟时间就应答一次
捎带应答：
捎带应答基于延时应答！
补充：客户端服务器的通信模型：
- 一问一答：绝大部分服务器都是这样的
- 多问一答：上传大文件
- 一问多答：下载大文件
- 多问多答：游戏串流
当然，客户端服务器之间的通信模型，通常是“一问一答”这种模式的！！
面向字节流：
暗藏杀机——》粘包问题！
所谓的“一句话”就相当于一个“应用层数据报”；
当A给B连接发了多个应用层数据之后，这些数据都积累到B的接收缓冲区，紧紧挨在一起，此时B的应用程序在读数据的收获，就难以区分从哪到哪是一个完整的应用层数据报，很容易读成半个包/一个半包……
如：好啊好啊好个P不给拉倒，如何进行分开？？
那么，疑问就来了？如何解决粘包问题？？
- 定义分隔符：粘包问题的有效解决方案！（约定以“ . ”（点号）结尾
- 约定长度：约定数据的前4个字节，表示整个数据报的长度
这两点都是自定义应用层协议的注意事项！！
异常情况：
- 进程关闭/进程崩溃
进程没了，socket是文件，也随之被关闭
虽然进程没了，但是连接还在，仍然可以继续四次挥手
- 主机关机（正常流程关机）
先杀死所有的用户进程：进程没了，socket是文件，也随之被关闭，虽然进程没了，但是连接还在，仍然可以继续四次挥手，如果挥完，更好，如果没有挥完（比如：对方发来fin，咱们还没来得及ack就关机了，此时对端就会重传fin，重传几次之后，发现都没有ack，就尝试重置连接，如果还不行，就直接释放连接！！
- 主机掉电（拔电源，很快的，啪的一下就🆗了）《——台式机，不考虑笔记本
瞬间机器就关了，来不及进行任何挥手操作1.对端是发送方：
对端就会收不到ack——》超时重传——》重置连接——》释放连接
2.对端是接收方：
对端没有方法立即知道，你这边是没来得及发送数据？？还是直接就没了？？其实TCP内置了“心跳包”（保活机制）心跳包具有周期性，当心跳没了，那就挂了！
虽然对端是接收方，对端会定期给咱们发送一个心跳包（ping），咱们返回一个（pong），如果每个ping都有及时的pong，这个时候，说明当前对端的状态良好，如果ping过去之后，没有pong，说明心跳没了，怕是这边挂了！！
心跳包是周期性的，没有那么的及时，而发送方发过去的数据没ack，反馈的更快！！
- 网线断开
同上（主机掉电）
TCP小结：
小结一下瞬间开心！！
- 确认应答
- 超时重传
- 连接管理：三次握手，四次挥手
- 滑动窗口：批量传输
- 流量控制：接收方根据自己的处理能力，反向约束发送方传输速度，接收方缓冲区剩余空间的大小——》ack应答报文窗口的大小
- 拥塞控制
- 延时应答
- 捎带应答
- 面向字节流：粘包问题
- 异常处理：心跳包
TCP可靠传输，效率没那么高，绝大部分场景下，都可以使用TCP
UDP不可靠传输，效率高，对于效率要求较高，且可靠性要求不高的情况下可使用！
TCP是直接和咱们的代码打交道的，咱们就不得不多了解一些了！IP是在更深层的地方，很难直接解除到！
