编辑
阿华代码，不是逆风，就是我疯
你们的点赞收藏是我前进最大的动力！！
希望本文内容能够帮助到你！！
目录
一：拥塞控制（重点）
通过“流量控制”的学习，我们可以通过从接收方的角度来制约发送方的发送速率，（即：动态控制窗口大小）。接下来我们引入的拥塞控制也是要限制发送方发送数据的速率。
1：情境引入
我们知道，数据在传输的过程当中需要经过交换机和路由器的转发，进而可以选择很多条路径到达接受方，现在假设数据在路径上阻塞了，此时就算接收方，接受数据的速度非常快也无济于事。
2：解决方案
假设发送方按照某个窗口大小进行数据发送，发生了丢包情况，就视为“路径拥塞”，此时就要缩小窗口；如果没有拥塞，就扩大窗口
3：如何找寻最佳窗口
编辑
（1）慢启动：不知道网络拥塞情况，所以起始传输速率很小，使用小窗口，避免网络带宽吃紧。
（2）如无丢包，指数增大窗口大小（增加传输速率）
（3）指数增大到“阈值”，改用线性增大窗口大小（求稳）
（4）线性增大到一定数值，发生“丢包”，重新把窗口设置为较小值（旧版本是设置为非常小的值，已被废弃，TCP Reno版本重新设置的值是以一个较高的值为起点，看图）
此时指数增长转变为线性增长的阈值也会被重新设置
4：总结
“流量控制”和“拥塞控制”遵循谁的窗口更小，谁说的算
二：延时应答
编辑
“延时应答”机制也是以“流量控制”机制和“拥塞控制”机制为基础，通过延迟返回ack来达到，尽可能增大窗口的目的
可以形象想象成，以前是一个数据就对应一个ack，现在是每隔几个数据再返回一个ack，这样不仅提高了效率，还节省了ack的开销
当然这里即使接收的数据没有达到一定的数量，也会返回ack
三：捎带应答
“捎带应答”机制是基于“延时应答”机制的，我们不仅可以通过改变窗口大小来提高数据传输效率，还可以通过尽可能的合并数据包提高传输效率。
编辑
正常情况下②③发送数据包之间会有一定时间间隔，通过“延时应答”机制，把②③合并成一个TCP数据包，进行发送
因为ack报文本身并不带有载荷，我们只需要把合并后的数据包中六位标志符中ack的值设置为1，并且设置确认序号以及窗口大小即可，这几个属性与一个response报文并不冲突
注：这里的模型，不能理解成“三次握手”，因为数据传输的连接一般都是“长连接”，中间可能有好几次ack+response
编辑
四：面向字节流
1：粘包问题
粘（nian）引入：从之前的学习我们知道，一个TCP数据报到达接受方之后，需要调用server 的API中的read方法，read出来的结果就是应用层数据包。
由于read的过程非常灵活，就无法区分出来从哪到哪是一个完整的数据包，
编辑
编辑
2：解决方案
明确包与包之间的边界
（1）分隔符标志
通过特殊符号作为分隔符，见到分隔符，就视为一个包结束了
例如：之前的写的TCP回显服务器中就应用到了这种思想
编辑
（2）指定包的长度
例如：在包的首部，加上一个特殊的空间来表示整个数据的长度
注：粘包问题，不是TCP独有的问题，只要是面向字节流，就会存在这样的问题
注：我们之前学习的UDP数据报包不存在这样的问题，UDP的传输单位是UDP数据报，每一个数据报，只承载一个应用层数据包。
UDP的接收缓冲区类似于一个链表。
（3）应用层协议格式
——xml，json，protobuffer
（4）知识回顾
数据报（Datagram）
UDP无连接的数据传输单元，通常用于网络层，每个数据报独立传输，传输不可靠
数据包（Packet）
是TCP/IP协议通信传输中的数据单位，处于网络层。数据包是一个完整的数据单元，它包含了网络层传输所需的所有信息
有连接，可靠传输
两者关系
数据包是整个的数据单元，而数据报是组成这个数据单元的分组
每一层封装后的数据都可以称作数据报，也就是说，一个完整的数据包是由若干个数据报组成的。
五：异常情况
考虑比“丢包”严重的情况，我们应该如何处理呢？
1：一方出现进程崩溃
进程无论是正常结束还是崩溃，都会触发回收文件资源，关闭文件这样的效果，（即四次挥手）
TCP的连接生命周期比进程更长，虽然进程退出了，但是TCP连接仍然存在，可以进行四次挥手
2：正常流程关机
主机关机，强杀进程，“四次挥手”挥的快，可以在数据结构中删除掉对端的连接信息；
挥的不够快，至少也能发送一个FIN给对方，如果久久收不到ack，会进行“超时重传”，重传几次后还是收不到ack，就单方面的释放连接信息。
3：一方断电
（1）断电的是接收方
发送方发送FIN后，收不到ack，重传后，还是没反应，进入“复位连接”
下面这张图是TCP数据报中六位标志符
编辑
RST——复位报文段
URG——TCP中有一些特殊的数据包，携带一些特殊功能的数据
PSH——push催促对方快点发送信息
（2）断电的是发送方
①问题引入
接受方本来就是在阻塞等待“发送方”发送数据，如果发送方“挂了”，接受方怎么区分出，发送方是“挂了”还是暂时刚好没有发送数据。
②心跳包
TCP中，接收方一段时间没有接受到发送方的数据，就会发送一个“心跳包”来确认发送方是否还处于“存活状态”
③特点
心跳包是周期性的发送
没有心跳，视为对端挂了，那就单方面的断开连接
4：网线断开
哦吼~~~~属于是物理打击了
六：应用场景
如果需要可靠传输：首选TCP
需要传送数据包很大：首选TCP
绝大部分的场景都可以优先考虑TCP
UCP相比较于TCP最大的优势就是，传输效率，比如有些场景中，对可靠性要求不高，对效率要求很高，那就可以考虑UDP
如何用UDP来实现可靠性传输（重点）
我们的思路就是借鉴TCP传输的这些特性（不止这些）进行类比
编辑
