计算机网络总结-运输层TCP---连接管理，流量控制和拥塞控制v1.0

TCP协议详解的简介里面介绍了TCP协议主要关注的问题

1、TCP连接是怎么建立和结束的。

2、TCP是怎么估计每个连接的RTT和怎么样基于这个估计设置重传超时的

3、正常的输出传输是怎么样的。

4、窗口是如何管理的，以及流量是如何控制的。

5、TCP是怎么做到拥塞控制的。

对于在自顶向下计算机网络里面这些问题也是做了非常详细的解释。

TCP报文的结构如下：

 

首先是第一个问题，连接是怎么建立和结束的。

TCP被称为是面向连接的协议。也就是在连接建立前必须要握手，相互发送一些报文，用于建立连接的数据传输参数。

主要这个连接的状态是保存在端系统中的，中间元素不会保存状态。

在了解连接建立之前，先了解一下序号（seq）和确认号（ack).  序号是建立在传送的字节流之上的，而不是建立在传送的报文段的序列上，因此序号就是该报文段首字节的字节流编号。主机A填充进报文的确认号是主机A期望从主机B收到的下一个字节的序号。TCP只确认流中至第一个丢失字节为止的字节，所以TCP被称之为累计确认。某个服务器的起始序号是不一定的。

 

下面的图描述了连接是如何建立的。

 

 

开始建立：client_isn的选择是随机的，为了避免syn洪泛攻击。

连接关闭：需要分别有两次Fin和ACK。因为TCP是全双工的，一个发送Fin，只是告知这个方向上不会再有数据发送过来。

 

 

TCPIP协议详解里面的示意图如下所示：

 

 

 客户端和服务器连接状态管理如上图所示.

其中有一个TimeWait状态需要重点说明一下，他被称为2MSL等待状态，任何主动关闭连接并发送了最后一个ACK的一端都将进入该状态。TCP将会等待两倍于最大段生存期的时间，有时又叫做加倍等待。最大段等待时长通常是2分钟。在linux的net.ipv4.tcp_fin_timeout记录了2MSL需要等待的超时时间。在Winodws里面也有对应的TCPTIMEWAITDELAY设置

TimeWait状态存在有两个目的：

1、为了确保另外一端收到Fin对应的ACK----因为Fin可能重传，我们要给出响应。

2、确保在这个时间段内，这个连接不会被别的应用使用。

RST报文是当发现一个到达的报文段对于相关连接而言是不正确的时候发送的。在某一些情况下会接收到：

1、针对不存在端口的连接请求。

2、终止一条连接。(1)任何排队的数据将会被清空。(2)重置报文段的接收方会知道另外一端是正常关闭的。

3、半开连接。服务器端并不记得这条连接，所以会回复一条重置命令

4、时间等待错误。timewait状态不应该对rst命令做出响应。

TCP连接相关的常见选项（参考TCPIP协议详解）：

 

 

可靠数据传输：

可靠数据传输是基于网络层的服务是尽力而为的，TCP在此基础上要实现上层应用通信的无损坏、无间隔、非冗余和按序。

往返时间的估计：

SampleRTT就是从某报文段发出到对该报文段的确认之间的时间量。

TCP在任意时刻都只为一个已发送但是还未确认的报文段估计SampleRTT。

 

 

 TCP重传

TCP发送数据之后启动一个定时器，等待对方回复ACK。这个时候有两个事件可能会发生。

1.收到ACK：

收到ACK表明对端接收成功，这边发送窗口可以继续移动，发送下一个数据包。

2 超时：

首次超时时间RTO是根据EstimatedRTT来设定的，如果第一次没有收到，后面将根据指数回退。但是总的时间不会超过MAX_RTO（通常linux设定为120s）

快速重传

超时重传增加了端到端的时延，所以TCP还引入了快速重传的机制。当接收方接收到的报文段序号大于他期望收到的序号时，他显式地发送最后一个接收到报文段的序号对应的ACK，以告诉发送端中间有报文段没有收到。

选择重传

就是允许接收方有选择地确认中间丢失的报文段。

 

TCP数据传输和窗口管理（ 流量控制）

延时确认：TCP并不是收到一个报文段就立即回复，而是会延时一会儿，等待相同方向的数据一起发送，这样以降低网络负载。

Nagle算法提出了一种自时钟的方法用于解决应用连续发送小报文段时导致的有效负载过低的问题。

Nagle算法提高了有效负载，但是却增加了延时，这个算法可以禁用：

 

 

 

 

 

 

根据上述公式，主机已发送到连接单位确认的数量一直小于接收窗口，就能实现流量控制。 窗口是一直变化的，如果出现零窗口，发送端讲不会再发送数据，而如果窗口更新消息没有被发送端接收到，将会出现死锁。所以引入一个TCP持续发送窗口检测消息。另外零窗口出现后还可能出现一种糊涂窗口综合征。也就是一直使用较小的窗口。

 大容量缓存和自动调优

 

 

TCP拥塞控制：

TCP拥塞控制主要是要解决网络中的通过的流量是有限的问题。

自顶向下里面的阐述方式比较好理解，从简单到复杂讲述了三种拥塞情况：

1、两个发送方和一台具有无穷大缓存的路由器。

 可以看到即使在这种理想化的情况下，分组达到的速率接近链路容量时，分组经历了巨大的排队时延。

 

2、两个发送方和一台具有有限缓存的路由器。

 网络拥塞时：在遇到大时延时所进行的不必要重传会引起路由器利用链路贷款来转发不必要的分组副本。

 又要拥塞而丢弃分组的代价：当一个分组沿着一条路径被丢弃前，每个上游路由器用于转发该分组到丢弃该分组的而是用的传输容量都被丢弃了。

 

TCP的拥塞控制：

网络拥塞主要是针对三个问题：

1、TCP如何限制它向其连接发送速率

2、TCP发送方如何感知它到目的方之间有拥塞

3、当感知到拥塞时，如何改变发送速率

 

针对第一个问题，如下所示，引入一个拥塞窗口。假定接收缓存无限大，所以发送速率就等于cwnd/rtt，调节cwnd的值就可以调节速率。

针对第二个问题

1、出现超时

2、收到来自接收方的3个冗余ACK。

针对第三个问题

1、如果有一个丢失的报文段，意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率。

2、一个确认报文段指示当前网络交付报文段较为顺利，因此当对先前未确认的报文段的确认到达时，可以增加发送速率。

3、带宽检测。TCP在收到ACK后增加速率，在发生丢包事件是则降低速度。

TCP的拥塞控制主要是三个部分：

1、慢启动：

CWND通常设置为一个较小的值：MSS. 也就是起始发送速率是MSS/RTT。每次收到确认ACK时则增加一个MSS。这样每一个RTT，速率就翻一番，指数增长。

如果存在丢包，则将cwnd设置为1MSS，并将慢启动阈值stresh设置为cwnd/2，然后重新启动慢启动。当cwnd等于ssthresh时，结束慢启动并转移到拥塞避免模式。或者如果收到3个冗余ACK，则快速结束慢启动进入快速恢复。

 2、拥塞避免模式：

这个时候改成线性递增，没过一个RTT，增加一个MSS。当出现超时的时候，再次将ssthresh设置为cwnd的一半。cwnd再次设置为1MSS，并且重新启动慢启动。但是如果收到三个冗余ACK，则转移到快速恢复阶段。

 

3、快速恢复

在这里每收到一个冗余的ACK，则cwnd增加一个MSS.

 

 

总结一下TCP拥塞控制：

 不考虑慢启动的阶段：每个RTT内cwnd线性增加1MSS（加性），然后出现3个冗余ACK事件时cwnd减半（乘性减）。

如果RTT和W不怎么变化，那么TCP传输速率在W/2*RTT----W/RTT之间变化。

 

 连接吞吐量公式如上。

 

 

经典问题汇总：

Suppose Host A sends two TCP segments back to back to Host B over a TCP
connection. The first segment has sequence number 90; the second has
sequence number 110.
a. How much data is in the first segment?
b. Suppose that the first segment is lost but the second segment arrives at B.
In the acknowledgment that Host B sends to Host A, what will be the
acknowledgment number?
解答：

a. 报文段的序号是首个字节的序号，前后发了两个报文段，所以可以知道第一个报文段的数据长度为20个字节。

b. ack是接收端期望从主机B接收到的下一个字节的序号。所以TCP被称之为累计确认。

 

 

 

转载于:https://www.cnblogs.com/amongv587/articles/7638653.html