TCP拥塞控制，拥塞窗口，携带应答，捎带应答，面向字节流，异常情况处理，最终完结弹

之前我们已经将TCP的前面一些性质介绍过了，接下来来介绍剩余的一些性质

1.确认应答

2.超时重新传输

3.连接管理

4.滑动窗口

5.流量控制

目录

一、拥塞控制

二、拥塞窗口

三、携带应答

四、粘包问题

方法1:应用层协议引入分隔符

方法2:应用层协议引入包长度

五、TCP异常情况的处理

---

一、拥塞控制💛

总的传输效率，是一个木桶效应，取决于最短板

A和B连接的时候，很多交换机/路由器，中间如果某个环节，转发能力特别差，此时A的速度就不应该超过这里的阈值。

所以，所以我们并不对对中间设备的转发能力进行量化，把中间设备都看成一个整体，而是采取‘实验’的方式，动态调整（工程师思维，一个一个慢慢试，看看哪个好使），产生一个合适窗口大小，

1.使用较小的窗口传输，如果传输通畅，会调大窗口，

2.使用较大的窗口传输，如果传输丢包（不通畅），就调小窗口

二、拥塞窗口 💙

在拥塞控制机制之下，采用的窗口大小，

TCP中拥塞控制，具体这样展开。

1.慢启动：开始进行通信的时候，会使用是一个非常小的窗口，先试试水（看一看当前线路，如果网络堵塞，一上来搞了一个小的，也不影响什么。（如果网络拥堵，一上来搞了一个很大的流量，就让（原本网络不通畅的环境，本来不富裕的条件，雪上加霜🌝🌝）

2.指数增长：在传通畅的过程中，拥塞窗口会指数级增长（*2）

3.线性增长：指数增长，当拥塞窗口达到一个阈值之后，就会从指数级增长，转换成线性增长（y=kx，这种，每次固定+n)这里的指数增长和线性增长：都是按传输的轮次（你交互完成一次，就是一个轮次），现按照传输的轮次，现给窗口定一个大小比如说4000，发出去之后，这一轮完事了，当收到ACK的之后，继续往下发数据。（当然也不会无限增长，增长到一定程度，接近网络传输极限，就可能会出现丢包）

4.拥塞窗口重新回到小窗口：当窗口大小增长的过程，如果使传输出现丢包，认为当前网络出现了作用，此时就会把当前窗口大小调整出最初的小窗口，继续回到之前的套路，->指数增长->线性增长，当然我们还是要根据当前出现丢包的窗口大小，去调整阈值。

拥塞窗口，就是在这个过程中，不断的进行变化，不断的调整的过程，（这样的调整可以更好的适应多变的网络环境，当然也会有不少的性能损失，每次回到慢开始这里，都会使传输速度大打折扣，因此，拥塞控制这里后续诞生一些优化算法（尽可能小窗口窗口传输时间缩短），实际发送方窗口=min(拥塞窗口，流量控制窗口）

（拥塞控制和流量控制），共同限制了滑动窗口机制，可以使用滑动窗口，能够在可靠性大前提下，提高传输的效率（保证可靠性机制）

三、携带应答💜

基于延迟应答，让数据合并

能合并的原因，一方面时间上是可以同时的，另一方面ACK数据本身不需要携带载荷和正常的返回响应的信息不冲突

完全就可以让这个数据报既能携带载荷数据，又能带有ACK的信息（ACK标志，窗口大小，确认序号）

四、粘包问题❤️

这里粘的是指‘应用层数据报’

通过TCP read/write的数据，都是TCP报文的载荷，也就是应用层数据，发送方一次性是报文的载荷，也就是应用册层数据。

发送方一次性可以发送多个应用册数据报的，但接收的时候，如何区分，从哪里得到一个完整的数据报？如果没有设计好，接收方难以区别，甚至会有BUG.

发送两个，半个，一个半都可能出现问题

接收方应用程序，读取这里的数据，read可能是一次一个字节，若一次若干个字节，没办法，一次读一个应用层数据。

做法：合理设计应用层协议，传输层这方面没有办法，需要站在应用层角度，来解决问题。

方法1:应用层协议引入分隔符

使用\n约定包之间分隔符

方法2:应用层协议引入包长度

粘包问题——只要是面向字节流机制都会存在这个问题（文件也有同样的粘包问题，解决的方案也是大同小异，分隔符或者好似长度）

五、TCP异常情况的处理💚

网络本身就会存在一些变数，导致TCP连接不能正常工作了。

(1)进程崩溃

进程就直接没了->PCB没了->文件描述符表也被释放了，相当于调了socket.close()->socket在系统内核中也是一个文件，也会放到文件描述符表中。->崩溃的这一方就会发出FIN，进一步触发四次挥手，此时连接就正常释放了，此时TCP的处理和进程会正常退出，和自动关闭没有区别

(2)主机关机

（正常步骤的关机）正常关机，就尝试先干掉所有的进程（强制终止进程）就和刚才所说的那个，崩溃的处理是一样的，主机关机会有一定时间，在这个时间之内，四次挥手可能正好挥手完毕

(3)主机掉电（直接拔电源没有任何反应时间）

此时没有任何的操作空间了，此时A无法给B发起任何的FIN的

这个时候分为两种情况

(a)如果B正在给A发信息（接收方掉电）

这个情况好办，B发的消息就没有ACK了，B就会触发超时重新传输，假如重传仍旧失败，就会触发复位报文（是RST为1）尝试重置连接，重置操作仍然是比啊，此时会单方面释放连接（B没有什么负面影响）

(b)如果此时A正在给B发送消息（发送方掉电了）

此时会更复杂一点，B在等A的消息，A突然不发了，B也不知道A是掉电了，还是等一会继续发，所以B会陷入阻塞等待，具体等多久，我们也不知道。

此处涉及到“心跳包”，B这边虽然是接收方，也会周期性给对方发起一个不携带任何业务数据（载荷）tcp接收包，发起这个包的目的，就是触发ACK，确认一下A是否正常工作/确认网路是否畅通。->A返回不了ACK，则A就挂了，和之前的流量控制，窗口探测是一个东西。

虽然TCP已经有心跳包支持了，但是还不够，往往还需要在应用层，应用程序中重新实现心跳包（TCP心跳包，周期太长，分钟级别是不够的，需要秒级或者毫秒级别的心跳包，可以更短时间内，发现某个服务器的问题。

(4)网线断开

以上TCP十大核心特性：

1.确认应答（可靠性）

2.超时连接（可靠性

3.连接管理（三次握手，四次挥手可靠性）

4.滑动窗口（效率）

5.流量控制（可靠性）

6.拥塞控制（可靠性）

7.延时应答（效率）

8.捎带应答（效率）

9.面向字节流->粘包问题（注意事项）

10.异常情况处理（心跳包->异常情况）