求职笔记-网络-tcp

TCP报文结构

流量控制
原理

TCP的滑动窗口主要有两个作用

滑动窗口基本原理
滑动窗口的流控特性

拥塞控制
拥塞控制四种算法慢开始拥塞避免快重传快速恢复
慢开始

拥塞避免算法

快重传

快速恢复

TCP报文结构

源端口号 （2字节）

目的端口号 （2字节）

序号 （4字节）

确认序号 （4字节）

首部长度 （4位）

保留长度6位

标志位 （6）

窗口大小 （2字节）

检验和 （2字节）

紧急指针 （2字节）

任选字段 （0 - 40字节）：

流量控制

让发送发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制。

原理

这就是运用 TCP 报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小

TCP的滑动窗口主要有两个作用

一是提供TCP的可靠性

二是提供TCP的流控特性

滑动窗口基本原理

对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类，“已经发送并得到对端ACK的”，“已经发送但还未收到对端ACK的”，“未发送但对端允许发送的”，“未发送且对端不允许发送”。* “已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口（中间两部分）。*



当收到接收方新的ACK对于发送窗口中后续字节的确认是，窗口滑动，滑动原理如下图。



当收到ACK=36时窗口滑动。

对于TCP的接收方，在某一时刻在它的接收缓存内存在3种。 “已接收”，“未接收准备接收”，“未接收并未准备接收”（由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”）。 其中“未接收准备接收”称之为接收窗口。

滑动窗口实现面向流的可靠性

最基本的传输可靠性来源于“确认重传”机制。

TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。

发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。

接收窗口只有在前面所有的段都确认的情况下才会移动左边界。 当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

滑动窗口的流控特性

TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。 这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。

来源： https://my.oschina.net/xinxingegeya/blog/485650

拥塞控制

在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞

网络拥塞往往是由许多因素引起的，简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。

例如:

当某个结点缓存容量扩展到非常大，于是凡到达该结点的分组均可在结点的缓存队列中排队，不受任何限制。由于输出链路的容量和处理机的速度并未提高，因此在这队列中的绝大多数的分组在排队等待时间会大大增加，结果上层软件只好把他们进行重传。

拥塞控制四种算法：慢开始、拥塞避免、快重传、快速恢复

慢开始

慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。 当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以 一次传输轮次之后拥塞窗口就加倍。

为了防止 cwnd 增长过大引起网络拥塞，还需设置一个 慢开始门限 ssthresh 状态变量。 ssthresh 的用法如下：

当 cwnd

拥塞避免算法

让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1 ，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

无论是在 慢开始阶段 还是在 拥塞避免阶段 ，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把 慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为 1 ，执行慢开始算法

快重传

要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。（为什么会收到重复序号，因为ack_num必须是连续的，当某个ack丢失时，后面的ack_num都会是这个ack_num）.

快速恢复

快恢复算法 有以下两个要点：

当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 慢开始门限减半 ，这是为了预防网络发生拥塞。

考虑到如果网络出现拥塞的话就不会收到好几个重复的确认, 发送方现在 认为网络很可能没有发生拥塞 ，因此现在不执行慢开始算法，而是把cwnd值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，是拥塞窗口的线性增大

http://blog.csdn.net/sicofield/article/details/9708311