目录
6. 拥塞控制
7. 延时应答
8. 捎带应答
9. 面向字节流
10. 异常情况
总结：
6. 拥塞控制
虽然 TCP 有了滑动窗口这个大杀器，就能够高效可靠的发送大量的数据，但是如果在刚开始阶段就发送大量的数据，仍然可能引起大量的问题。
我们前面提到了流量控制，是站在接收方的角度来制约发送方的速率。
但也可能出现下面的情况：
如果当前接收方处理的速度非常快，但是在发送到到达接收方的中间的通信路径出现问题，某个地方发生“堵车”了，即当前的网络状态比较拥堵了，此时发送方再怎么发送，都是无济于事的~~
针对于上面的情况，我们解决的核心思路：把中间路径经过的所有设备，视为是一个整体，然后通过“实验”的方式，找到一个比较合适的传输速率。（毕竟有句话讲的好嘛，实践才是检验真理的唯一标准）。
如果按照某个窗口大小发送数据之后，出现丢包情况了，就视为是中间路径存在拥堵，就减小窗口大小，如果没出现丢包情况，就视为中间路径不存在拥堵，就增大窗口大小。
上述方案，一方面就把整个问题给简化了，另一方面，也能够很好的适应当前网络环境的复杂性，中间这些节点，啥时候出现拥堵，啥时候不用读，就都是“随机” 的，此时按照上述策略，就可以让发送速率，来进行动态变化。
总的原则是，流量控制和拥塞控制，谁产生的窗口大小，谁更小，就谁说了算~~~
那我们上述方案中，是具体怎么把这个窗口大小给试出来的呢？？？
1. 慢启动：刚开始传输的数据，速率都是比较小的，采用的窗口大小也就比较小，也就采用的拥塞窗口的大小，（这里的实际的窗口大小，应该是拥塞窗口和流量控制的较小值，但一般拥塞窗口的初始值肯定是小于流量控制的）。此时，网络的拥堵情况未知，如果一上来就搞得窗口很大，可能就会让本来就不富裕的网络带宽，更加雪上加霜了。
2：指数增长，如果上述传输的数据，没有出现丢包的情况，说明网络还是很畅通的，就要增大窗口大小了。此时，增大的方式是按照指数来增长的（* 2）当下的窗口持久
（由于使用慢启动，开始的时候，窗口大小非常非常小，也有可能网络上就是很通畅，通过指数增长的方式可以让上述的窗口大小快速变大，这样就可以保证传输的效率了~~~）
3. 线性增长：指数增长并不会一直持续保持的，可能会增长太快，一下子就导致网络拥堵，这里就引入了一个“阈值”，当拥塞窗口达到阈值之后，此时，指数增长也就成为了线性增长。
（线性增长能够使得当下的窗口，持久的保持在一个比较高的速率，并且也不容易一下就造成丢包情况）
4.动态调整：线性增长也是一直在增长，积累一段时间之后，传输的速度可能太快，此时还是会引起丢包情况。一旦出现丢包，就把拥塞窗口重置成比较小的值了，然后又会重新回到最初的慢启动过程（又要重新的指数增长，并且这里也会根据刚才丢包时候的窗口大小，重新设置指数增长到线性增长的阈值）
情况如下：
这里存在两种版本，TCP Tahoe 版本和 TCP Reno 版本，虚线部分是经典的版本，就是当线性增长知道出现丢包情况的时候，此时拥塞窗口的大小，就会回到非常小的值，重新指数增长，重新线性增长。而在新版本中，后续就没有指数增长了，拥塞窗口的大小会回到丢包时候的 1 / 2，然后进行线性增长。
（之所以有这两个版本的更迭，主要是因为，网络环境发生了大的变化，TCP 诞生于 1981 年，当年，网络的带宽，网络的通信质量的稳定性，与现在的网络，都是无法相提并论的~~~当年的时候，网络会经常的出现大规模的网络波动，一旦出现拥塞，网络带宽就非常捉襟见肘了，按照比较小的速率发送，是一种更加稳健的做法~~~）
7. 延时应答
延时应答机制，也是基于滑动窗口，进一步的提升效率的机制，结合滑动窗口以及流量控制，再通过延时应答 ack 的方式，把反馈的窗口大小，搞大一点~~
如果接收数据的主机立刻返回 ack 应答，这时候返回的窗口大小可能就比较小：
假设接收端的接收缓冲区为 1M，一次收到了 500K 的数据，如果立刻应答，返回的窗口就是 500K，但实际上可能处理端的速度非常快，10ms 之内就把 500K 的数据从缓冲区给消费掉了。在这种情况下，接收端处理还远远没有到达自己的极限，即使窗口再放大一些， 也能处理的过来，如果接收端稍微等待一会，再进行应答，比如等待 200ms 再应答，那么这个时候返回的窗口大小就是 1M 了~~~
窗口越大，网络的吞吐量就越大，传输效率就越高，我们期望的是，在保证网络不拥塞的情况下，尽量的提高传输效率~~~
我们前面讲，通过滑动窗口来传输数据，如果 ack 丢了，其实并不会有太大的影响。延时应答具体怎么延时，也不是单纯的按照时间，而是可以按照“ack 丢了”的方式来进行处理~~~
正常每个数据都有 ack，此时就可以每隔几个数据，再返回一个 ack 了（每隔几个数据，就能起到延时应答的效果）另外也能够减少 ack 传输的数量，也能起到节省开销的效果。
这里也不仅仅是数据的数量，也是和时间有关的~~~这个情况，如果延时时间达到一定程度了，即使个数没够，也会返回 ack了，一般情况下，数量限制是每个 N（一般取 2）个包就应答一次，超过最大延时时间（一般取 200ms）就应答一次~（这里的数值都是可以进行调整的，重点的理解这个策略~~）
8. 捎带应答
这个捎带应答机制，又是基于延时应答，引入的机制，能够提升传输效率~
修改窗口大小，的确是提升效率的有效途径。捎带应答，就是走另一条路，尽可能把能合并的数据报进行合并，从而起到提高效率的结果。
我们发现，很多情况下，客户端服务器在应用层也是“一发一收”的，意味着客户端给服务器说了“How are you”，服务器也会给客户端回复一个“Fine，thank you ~”，那么这个时候，ack，就可以搭乘顺风车，和服务器回应的“Fine，thank you”一起回复给客户端了（这里也是因为有延时应答的存在~~）
如下图所示：
客户端在给服务器发送 request 之后，因为一问一答的机制，服务器会返回一个 ack（这个 ack 是 TCP 机制控制的，由内核进行自动返回的~），然后服务器在收到请求 request 之后，就要执行对应的业务逻辑，根据请求计算响应，然后再返回对应的 response。
因为有了延时应答机制，ack 的应答时间就会推迟一些~
就会有如上的情况出现~ 在 ack 延时的这段时间里，响应数据刚好准备好了，此时就可以把 ack 和应答的响应数据合并成一个 TCP 数据报了。
而且，本身 ack 也不携带载荷，只是把报头中的 ack 标志位设置为 1，并且设置确认序号以及窗口大小，这几个属性，本身一个正常的 response 报文也用不到，也不会冲突，就可以讲 ack 和 response 一起传输过去~
注意：这里和三次握手是有本质的区别的~
三次握手，是相当于一个打招呼的过程，是一个没有意义的数据报，没有载荷，而后续的传输过程都是有载荷的~~
而且，很多时候，客户端和服务器之间都是长连接，要进行若干次请求的。在捎带应答的加持之下，后续的每次传输请求响应，都可能触发捎带应答，都可能把接下来要传输的业务数据和上次的 ack 合二为一。（注意：这里是有可能触发捎带应答，也不是一定能触发，具体是否能触发，就取决于我们程序员代码是如何写的了~~~取决于我们的下一个数据来的快不快，如果下一个数据来的很快，在延时应答的延时时间之内，就可以触发合并，如果下一个数据来的慢，就无法触发了~）
因为延时应答 + 捎带应答，就有可能使得后续的四次挥手，合并为三次~~
9. 面向字节流
我们创建一个 TCP 的 socket，同时在内核中创建一个发送缓冲区和一个接收缓冲区；
- 调用 write 的时候，数据会先写入发送缓冲区中
- 如果发送的字节数太长，就会被拆分成多个 TCP 的数据报发送
- 如果发送的字节数太短，就会现在缓冲区里面等待，等到缓冲区的长度差不多了，或者其他合适的实际再发送出去~
- 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区
- 然后应用程序可以调用 read 从接收缓冲区拿到数据
- 另一方面，TCP 的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既可以读数据，也可以写数据，这个概念就是我们前面提到的 全双工。
由于缓冲区的存在，TCP 的程序的读和写都不需要意义匹配，即：
写 100 个字节的数据时候，可以调用 1 次 write 写 100 个字节，也可以调用 100 次 write 每次写 1 个字节~~~
读 100 个字节数据的时候，也完全不需要考虑写的时候，是怎么写的，既可以一次 read 100 个字节，也可以一次 read 一个字节，重复 100 次~~
这就会导致一个“粘包问题”！！此处的包，指的是 TCP 载荷中的应用数据包~~
在 TCP 的协议报头中，没有如同 UDP 一样的“报文长度”这样的字段，但是有一个序号这样的字段
站在传输层的角度，TCP 是一个一个报文过来的， 按照序号排列好放在缓冲区中
站在应用层的角度，看到的只是一串连续的字节数据
那么当应用程序看到了这么一连串的字节数据，就不知道要从那个部分开始，到那个部分结束，算是一个完成的应用层数据包了。
举个栗子：
此处假定，这三个 TCP 数据报都是携带的完整的应用层数据包（因为也可能一个 TCP 数据包可以携带多个或者半个应用层数据包）
当发送方发送数据给接受方之后，接收方的接收缓冲区和传输层角度，这几个数据都是按照序号拍好的顺序：
但是站在应用层的角度，应用程序调用 read 读取数据，由于此处是字节流，读取过程非常灵活，一次可以读出一个 a，也可以一次读出 aa，也可以一次读出 aaa，也可以一次读出 aaab........ 多个应用层数据包之间混淆不清了，这种情况就称为“粘包问题”。应用程序要读出数据之后，将里面的数据转成应用层数据包，然后这个数据才能正确的被使用，但由于“粘包”的存在，究竟是那种读法，读出来的才是完整的应用层数据包呢？？？
粘包问题，并不是 TCP 所独有的问题，只要是面向字节流传输，都会有这样的问题，解决这个问题的关键，就是要明确“包之间的边界”。
1. 通过特殊符号，作为分隔符。只要一见到分隔符，应用程序视为一个包结束了~我们前面在写回显服务器的时候，就是使用了分隔符作为边界（空白符 + Scanner）
这里并非必须使用空白符，使用任意字符作为分隔符都是可以的，不过前提是要去报当前这个分隔符不会在正式的数据中存在~~~
2. 指定出包的长度，比如在包开始的位置，加上一个特殊的空间来表示整个数据的长度。
上述的问题，都应该是我们在设计应用层协议的时候，把相关的问题考虑进去，提前设计好~~
对应的，UDP 其实就没有这个问题。UDP 传输的基本单位是 UDP 数据报，在 UDP 这一层，就已经分开了，只要约定好，每个 UDP 数据报都只承载一个应用层数据包，就不需要额外的手段来进行区分了~~~
UDP 的接收缓冲区并不是一个队列的结构，而是类似一个链表
UDP 的接收缓冲区类似于一个链表，每个链表的结点都是一个 UDP 数据报，通过代码来读取的时候，一次取一个，也就是一个应用层数据包了~~
补充：粘包问题，是 TCP 面向字节流引起的，但 TCP 本身是不会有机制负责解决，需要我们程序员知道 TCP 存在粘包问题，通过代码，写应用层逻辑的时候，自己去解决~~~ 我们前面提到过的各种常用的应用层协议的格式，xml，json，protobuffer，都能够很好的处理粘包问题~~~
10. 异常情况
异常情况，是一种比丢包更严重的情况，甚至说就是网络直接出现了故障的情况，此时该如何处理呢？？？
1. 其中有一方，出现了进程崩溃。
进程无论是正常结束，还是异常崩溃，都会触发到回收文件资源，关闭文件这样的效果（都是系统自动完成的），就会触发四次挥手。TCP 连接的生命周期，可以比进程更长一些，即虽然进程已经退出了，但是 TCP 连接还在，仍然可以继续进行四次握手。
（即，虽然说是异常崩溃，但是实际上和正常的四次挥手结束，没啥区别，进程不在了，但是可以通过系统中仍然存在的连接信息，完成后续的回收过程的）
2. 其中有一方出现了 关机（按照正常流程进行关机）
当有主机，触发关机操作，就会先强制终止所有的进程（强杀进程），终止进程自然就会触发 4 次挥手。点了关机之后，此时，四次挥手不一定能挥完，系统马上就关闭了。
如果挥的快，能够顺利的挥完，本端和对端都能正确的删除掉保存的连接信息。（四次挥手的核心任务）
如果挥的不快，至少也能把第一个 fin 发送给对方，至少能告诉对方，我这边要结束了。对端在收到 fin 之后，对端也就要进入释放连接的过程了，返回 ack，并且也返回 fin，对端如果这时候已经关闭，这里发的 fin 就不会有 ack 了，fin 没有收到 ack 之后，势必会进入重传（超时重传的流程~~~）当重传几次之后，发现还是不行，还是没有 ack，这个时候，也就会单方面的释放连接信息了~~~
正常来说的四次挥手，是确认双方都删除干净，但是，如果四次挥手没那么顺利，没挥完手，对端就挂了，没 ack，挥不下去了，重试几次，也就会直接单方面的删除连接信息~~~
3. 其中一方出现断电（直接拔电源，此时也是关机，不过是更突然性的关机）
如果直接断电，机器瞬间关机，此时，肯定是来不及发送 fin 的，这里分两种情况：
a）断电的是接收方，发送方就会突然发现，没有 ack 了，就要重传，重传几次之后，发现还是不行，TCP 就会尝试“复位”连接（相当于清除 TCP 中的各种临时数据，重新开始）这里复位操作，也需要用到一个 TCP 的“复位报文段”，即六个关键字之一的 -- RST，通过这个报文，直接复位，既往不咎，过往就翻篇了~~此时的 RST 也不会有 ack，发送方就想，重置了还不行？？？ ==》 直接单方面放弃连接~~~
b）断电的是发送方呢？？？接收方本来就是在阻塞等待发送方的消息，结果迟迟没有等来消息，怎么办呢？？？
这个情况下，接收方就需要区分了，到底是发送方挂了，还是好着呢，但是暂时没法数据。这个时候，接收方在等待一段时间之后，没有收到对方的消息，就会触发“心跳包”来询问一下对方的情况。（心跳包，也是一种不带应用层数据的特殊数据报 ==》 1. 周期性的 2. 如果没有心跳，就会认为对端挂了~~）
如果对端没心跳了，此时本段也就会尝试复位并且进行单方面的释放连接了~~
4. 网线断开
这种情况就是 3 情况的 a b 情况结合了~~~
总结：
前面的内容，就是对 TCP 协议中，一些比较重要的，需要我们了解的一些机制的介绍~~~TCP 协议也有其他重要协议，这里只是挑了几个比较核心的进行介绍~
