目录
前言
本文是接着上一篇：https://blog.csdn.net/qq_36652619/article/details/99194290
延续TCP的几个特点的实现
TCP如何实现可靠传输
网络层只负责把数据包从一个网段转移到另一个网段，丢包是不管的，可靠传输是由传输层负责的。
停止等待协议
停止等待协议（stop-and-wait）是最简单但也是最基础的数据链路层协议。很多有关协议的基本概念都可以从这个协议中学习到。
停止等待就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
1. 出现差错或丢失情况
下图左边是正常情况，如果对方没有收到则超时重传。
2. 确认丢失和确认迟到情况
确认丢失：B发的确认的包丢失了，A没有收到确认，重发M1，这样B就收到两个M1，这时候B就会丢弃重复的M1，重传确认M1
确认迟到：B收到M1，发出确认，但是确认的包在网络里可能走了一条比较远的路，时间较久，A没有收到确认，重新发M1，然后B丢掉重复的M1，重发确认，然后A收到确认发出M2，发出M2后，第一次迟到的M1的确认来了，但是A收到后什么也不做。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠通信。
这种可靠传输协议通常被称为自动重传请求ARQ
优缺点
停止等待协议的有点是简单，缺点是信道利用率低（发一个数据包，要等待的时间比发数据包的时间长很多）。
解决信道利用率低：【流水线传输】发送方连续发送多个分组，这样发数据包的时间就增加了，不用一直等着确认，不必每发完一个分组就停顿等到对方确认。
流水线传输实现可靠传输（连续ARQ协议）
可以看到下图的a图，发送窗口是5，那么1~5的数据包可以连续的发出去，第六个数据包不能发了，因为发送窗口是5。这时候就开始等到确认，第一个数据包收到确认，发送窗口就往后移。
以字节为单位的滑动窗口技术
图解滑动窗口：
正常不丢包的情况
（上图的窗口没到10，大家理解成10）
包丢失的情况
选择确认情况
TCP协议如何实现流量控制
图解：
TCP协议如何避免网络拥塞
当一个网络里面有很多个计算机一起在上网的时候就有可能造成网络堵塞。
网络中的计算机只要发现丢包情况就主动的降低发送数据的速度避免堵死。
出现拥塞的条件：对资源需求的总和 > 可用资源
可以看到，比如我们的带宽有限，对吧，凡事都有理想状态，理想的世界是美好的，现实的世界是残酷的，哦不，是凄惨的。那么理想状态，我们的流量没到带宽对应的吞吐量上限，那么来多少我就应该收多少，对吧，是一条45度角的直线上升，然后到了吞吐量上限之后平缓，以最大值一直传输。
那么理想是美好的，现实肯定不能让你如意，看上图，没有拥塞控制的绿色的线，可以看到它的流量还没有到上限，就开始往下降了，是不是有问题，那么问题在哪？路由器是一台机器吧，那么我们吧路由器类比成一个主机，那么一个主机处理一个应用程序的速度可以达到理想状态吧，但是处理一万个应用程序的速度，还能有“按理来说”的那种速度嘛，有人说，那可能就没速度了。
对吧，随着流量的增多，网络的处理速度变慢，传输速度自然没有理想状态那么多，而且到了绿线的后期，直接堵死了。
实际的拥塞控制就是去避免了堵死的情况，但也达不到理想的情况。
慢开始算法
cwnd可以把它理解成窗口，可以看到一开始的时候试探性的小窗口发少量的包，然后指数型的增长
看上图，涨到一个ssthresh的初始值就开始加法的方式增大，增大到拥塞的时候，拥塞窗口下降为1，然后重新设置门限值ssthresh，新的门限值为达到拥塞那个点除以2。
快重传和快恢复机制
传输过程中，如果出现丢包，接收方会连续给发送方发送三个确认（网应该还没堵，堵了就收不到了，有可能快拥塞了），发送方收到后快恢复，拥塞窗口值为新的ssthresh值。
发送窗口的实际上限值
上面流量控制又会变更发送窗口的大小，发送窗口又会由接受窗口的大小来决定，拥塞控制也会调整窗口大小。
发送方的发送窗口的上限值应当取为接收方窗口和拥塞控制窗口这两个变量中较小的一个，公式：发送窗口上限值 = Min[ rwnd, cwnd ]
以上是对计算机网络基础（TCP如何 可靠传输 | 流量控制 | 避免网络拥塞）的粗浅认识
转载请注明出处：https://blog.csdn.net/qq_36652619
7840
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
