前言

说来惭愧，大二时候学的计算机网络好多都不太记得了，不过还好有认真学过，捡起来也挺快的，就是对于现在业界中使用的网络算法的不是很懂；

1 TCP报文段结构

序号，是报文段首字节的字节流编号；
确认号，是发送端期望从接收端收到的下一个字节的序号；

TCP只接受数据流中国至第一个丢失字节为止的字节，所以TCP被称为累积确认；

怎么样才能算是对数据进行可靠传输呢？这就要求确保一个进程从其接收缓存中读出 非损坏的、无间隔的、非冗余的、按序的数据流；

如果发生超时的现象，则TCP通过重传引起超时的报文段来响应超时事件，再重启定时器，每次重传都会将下一次的超时间隔设为先前值的两倍；
因为发送方经常连续发送大量的报文段，所以如果一个报文段丢失，就很可能引起许多一个接着一个的冗余ACK，如果TCP发送方接收到相同数据的3个冗余ACK，TCP就执行快速重传，即在报文段的定时器过期之前重传丢失的报文段；

流量控制服务是为了消除发送方使接受方缓存溢出的可能性，因为有可能应用程序读取数据时相当缓慢，而发送方发送数据太多、太快，会很容易造成该连接的接受缓存溢出；

接收窗口用于告诉发送方，该接受方还有多少可用的缓存空间；因为TCP是全双工通信，在连接两端的发送方都各自维护一个接受窗口；

例子1：

窗口大小为6，窗口向右移动；

例子2：

设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。

上面的图中经历了三次流量控制；

发送方的发送窗口不能超过接收方给出的接收窗口的数值（TCP的窗口单位是字节，不是报文段）
只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就周期性的发送一个零窗口探测报文段（仅仅携带1个字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值；
持续计时器的出现是为了解决这么一种特殊的情况：接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

略

拥塞发生的主要原因是因为网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。

TCP的拥塞退避由4个核心的算法组成：慢启动、拥塞避免、快速重传和快速恢复；

从小到大逐渐指数增加拥塞窗口的大小；

如果超过某个阀值后，慢启动则结束，进入到拥塞避免阶段；拥塞避免的思想就是将指数增加转变为线性增加，这样就可以避免增长过快而导致网络阻塞，慢慢的增加调整到网络的最佳值；

如果当前的cwnd达到慢启动的阈值，则试探性的发送一个segment，如果服务器没有响应，TCP认为网络能力下降，必须降低慢启动阈值，同时为了避免形式继续恶化，有可能将窗口降低为1

快速重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置重传计时器时间到期。

除了经典的三次ACK，还包括ER、FACK，以及最新的基于时间序的RACK的包丢失快速重传算法，做出了很多改良。

在经历过快速重传后，如果依然接收到重复的ACK，说明网络没有阻塞，这里并不会进入到慢启动的状态，而是直接进入到拥塞避免的状态；

基于丢包反馈：通过ACK所带回来的丢包信息来调整源端的拥塞窗口；
基于路径延时反馈：RTT相对于丢包信息反应更加灵敏，更能及时反映出一般网络的拥塞情况，适用于小缓存的中间节点，效率较理想。但是对于路由器经常缓存数据促使RTT延长调节拥塞窗口，实际上没有发生拥塞情况。
基于显示拥塞反馈：典型的ECN利用中间节点自己检测本身的拥塞状态，如路由器的反馈状态，直接反馈给TCP源端，以此调节源端的窗口值和发送速率。