【Java网络编程】TCP核心特性（下）

1. 拥塞控制

拥塞控制：是基于滑动窗口机制下的一大特性，与流量控制类似都是用来限制发送方的传送速率的

区别就在于："流量控制"是从接收方的角度出发，根据接收方剩余接收缓冲区大小来动态调整发送窗口的；而"拥塞控制"是从网络的拥堵状态出发，衡量当前网络拥塞程度从而动态调整拥塞窗口大小的

如上图所示：接收方和发送方并不是简单直接相连的，路径中间存在着多个通信设备（路由器、交换机等），因此传输过程网络环境错综复杂，因此就算接收方此时剩余接收缓冲区空间足够，发送方的发送窗口值较大也是不合理的！此时我们就需要一套合理的机制来得出针对当前网络拥堵状态、合适的发送窗口大小：也被称为 拥塞窗口

拥塞窗口调整过程：

• 首先是 慢启动 过程：即一开始拥塞窗口（后续写为cwnd）设立一个比较小的值，因为刚开始时网络状态未知，如果开始就设定一个较大值，可能会让本就不富裕的网络带宽雪上加霜
• 慢启动过程中，拥塞窗口的大小是 指数增长 的，如果没有丢包就让cwnd变为原来两倍（这样做是因为一开始cwnd值较小，指数增长可以快速提高发送效率）
• 指数增长不会一直持续下去，达到阈值（后续写为ssthresh）之后就转变为 线性增长（这样做的好处是尽可能保持较高的传输速率，并且不会立刻造成拥堵丢包情况）
• 线性增长也终究还是在增长，当出现丢包情况，就说明此时的网络情况拥堵，就将 新阈值 设定为出现丢包cwnd值的一半，并且让cwnd重新置为一个较小值继续开始慢启动过程

  

  其中因超时重传导致cwnd减少有两种版本：

  • 一种是TCP Reno版本：新的拥塞窗口值不会将为1，而是从新的ssthresh开始，然后保持线性增长
  • 另一种是TCP Tahoe版本（已废弃）：新的拥塞窗口值为1，慢启动过程仍为指数增长，阈值到达新的ssthress值则转变为线性增长

    2. 延迟应答

    延迟应答：是基于TCP的"滑动窗口"机制以及"流量控制"机制，为了进一步提高传输效率的，它的核心就在于接收方收到数据之后，不会立刻返回Ack报文，而是等待一会（留给应用程序处理接收缓冲区的数据），此时可以回馈的剩余接收缓冲区容量更多了，就可以适当增加发送窗口的大小

    

    通过滑动窗口机制来传输数据，这里的"延迟应答"的方式类似于按照"ACK报文丢了"的情况进行处理，即接收方连续收到多个ACK报文后，不会每一个都发送ACK报文，而是等待一段时间，例如100ms，然后再返回最后一个ACK报文，此时不仅能够起到"延迟应答"的作用，还可以减少数据传输量

    需要注意：这里并不是单纯的按照每隔多少个ACK，返回一个ACK报文，也是和相应的时间间隔相关的，例如每隔2个报文，时间间隔为200ms（不需要记住具体数值，这些都是参数，重要的是理解策略）

    3. 捎带应答

    捎带应答：是基于"延迟应答"，进一步提升传输效率的机制，其核心思想就是尽可能将可以合并的数据报进行合并，从而起到提升效率的作用

    我们最常见的通讯模型就是如下"一问一答型"的：

    

    按照之前的方式：那么当客户端给服务器发送请求后，服务端先返回ACK表示收到了，然后进行业务逻辑处理，返回响应结果response，但是由于 延迟应答机制 的加持，我们在一定条件下可以将ACK报文同response应用层数据报文一起发送（因为ACK报文只将ACK标志位置为1，不会与应用层报文其他内容冲突）

    此后后续所有的ACK应答报文都可能和应用层数据报文合并一起发送！也让后续四次挥手变成三次挥手提供可能性！

    4. 面向字节流

    粘包问题：这里重点讨论"面向字节流"中一个重要话题——粘包问题

    结合之前的内容进行理解，这里的包指的是"应用层数据包"，即TCP数据到达内核的接收缓冲区后，应用程序会调用socket.receive()进行读取，此时就会出现一个问题，TCP是面向字节流的，因此传输的数据可以看做是一连串字节数据，无法区分包与包之间的边界，例如一个包传送"aaa"，另一个包传送"bbb"，但是到了接收缓冲区呈现的形式就是"aaabbb"，这个问题就是"粘包问题"

    解决思路：

    "粘包问题"并不是TCP独有的，而是所有的面向字节流的协议都会产生的，解决的思路大体有如下两种：

    1. 通过特殊符号，作为分隔符，每次遇到分隔符就表示达到包结尾了，例如我们传输数据后面加上分隔符"\r\n"，那么上述情况中接收缓冲区的数据就是"aaa\r\nbbb\r\n"，此时我们就有办法进行区分了
    2. 另一种思路就是占用额外的存储空间用来存放该数据包的长度，例如上述情况我们可以表示为"[3]aaa[3]bbb"，此时我们读取的过程中就已知长度进行分隔读取了

    5. 异常处理

    异常情况：上述我们讨论的都是基于TCP正常状况下的网络传输过程，唯一存在的异常情况也就是"丢包"了，但是如果出现更为严重的故障呢？TCP会如何处理呢，这就是该特性需要讨论的地方：

    异常情况分类：

    1. 发送方或者接收方出现了进程崩溃：

       进程无论是正常结束还是异常崩溃，都会触发 文件资源回收 ，起到关闭文件这样的作用，此时就会完成四次挥手过程，由于TCP连接的生命周期会比进程更长一些，因此可以完成四次挥手，与正常情况基本没什么区别

    2. 发送方或者接收方正常关机

       当有个主机进行关机时，操作系统就会强制终止所有的进程（类似上述的强杀进程过程），自然就会触发四次挥手，但是此时由于很快就要关机，因此四次握手不一定会全部完成，但是大概率第一个FIN报文能够发送给对端，此时对端也会回复ACK报文以及FIN报文，但是这些报文都不会再收到ACK了，此时对端就会触发超时重传，当重传几次仍然没有ACK后就会 单方面释放连接

    3. 发送方或者接收方断电关机

       如果直接断电，那么肯定是来不及发送第一个FIN报文的，此时就要考虑断电的是发送方还是接收方了

       1. 断电的是接收方：此时发送方就会发现，发送的数据没有ACK了，此时就会触发超时重传，重传多次仍没有ACK后就会尝试置RST位为1表示复位重置连接（消除原来的临时数据），但是RST也不会出现ACK报文，此时就单方面释放TCP连接了
       2. 断电的是发送方：此时接收方等待长时间没有收到来自发送方的数据时，就会周期性的发送"心跳"探测报文（不携带应用层数据），如果对端没有"心跳"那么就会单方面释放连接

    4. 网线断开

       相当于3中的a、b进行结合了，这里不再赘述！