CN-TCP-ReadingComplement

[[计算机网络]]

TCP发送方必须处理的第三个主要事件：接受方确认的报文段的到达

当时间发生的时候将ACK y的值和变量SendBase相比较，如果y大于SendBase,也就是说ACK在确认先前没有被确认的报文段，所以更新SendBase为y。

A向B发送了序号为92的8字节数据，主机B向A返回ACK=100但是在过程中丢失，在超时之后将会进行重传，N再重新传回ACK=100

可以看出第一次超时两个ACK都没有收到，之后第二次超时重新发送了Seq=92,在第二个超时时间内收到ACK=120，这样第二个报文段就不会被重传

这就和第二种情况中一样，但是ACK在第一次的超时间隔内就就收到了，虽然ACK 100没有正确接收，但是ACK 120正确接收了，说明119之前的所有数据都正确接收了，也就不用重新传输第一段报文

超时间隔加倍

每当超时时间发生，重传具有序号最小的还没有被确认的报文段

将超时时间间隔设为先前值的两倍

超时间隔在每次重传之后会呈现指数型增长

提供了形式受限的拥塞控制

定时器过期很可能是由网络拥塞引起的

[!TIP] 太多的分组到达源和目的地之间路径上的一台（或者多台）路由器的队列中，造成分组丢失或者长时间的排队时延

拥塞的时候，如果源持续重传分组，会让拥塞 更加严重

快速重传

超时周期因为每次的指数形式增长会让超市周期可能相对较长

增加了端到端的时延

注意到冗余ACK来检测丢包情况

[!TIP] 冗余ACK代表的是在其确认某个报文段的ACK

当接受方检测到了数据流中的一个间隔，这样就是报文段的丢失。

TCP不使用否定确认，所以接收方不能向发送方发送一个显示的否定确认（NAK），所以TCP对接收到的最后一个按序字符进行重复确认

如果一个报文段丢失，就很可能引起许多一个接一个的冗余ACK。如果TCP发送方接收到对相同数据的冗余ACK，可以当作一种指示，这个已经被确认过3次的报文段之后的报文段已经丢失。

一旦收到3个冗余ACK，TCP就执行快速重传

[! TIP] 在这个报文段的定时器过期之前重传丢失的报文段

代表ACK的收到的事件的伪代码

event : ACK RECEIVED, with ACK field value of y
	if(y > SendBase){
		SendBase = y
		if( ther are currently any not yet acknowledged segments)
		start timer
	}
	else { 
	// 一个对确认过的重复的ACK进行发送了三次
	increment number of duplicate ACKs received for y=3
	// TCP fast retrasment
	resend segment with sequence number y
	}
	break

是回退N步还是选择重传

TCP Sender 只维护 SendBase 和NextSeqNum，所以TCP看起来像是一个GBN风格的协议

但是和GBN有着显著的区别

[!TIP] TCP实现会将正确接收但是失序的报文段缓存起来。

发送报文段 1，2，3，…… N

假设分组n < N确认报文丢失，但是其余的确认报文都分别在超时之前到达发送端。

如果是GBN，就会重传n+1，…… N的所有分组

但是TCP只会重传分组n，而且如果对报文段n+1的确认报文在报文段n超时之前到达，TCP都不重传报文n

选择确认

允许TCP的接收方有选择的确认失去顺序的报文段

所以当这个机制和选择重传机制结合起来使用的时候（也就是跳过那些已经被接受方确认过的报文段），TCP看起来就像是SR协议

[!INFO] 所以TCP的差错恢复机制就最好被分类为GBN协议和SR协议的混合体

流量控制

流量控制因此是一个速度匹配服务，也就是发送方的发送速率和接收方的应用程序的读取速率相匹配。

Previous : TCP发送方也可能因为IP网络的拥塞而被遏制。

要区分流量控制和拥塞控制

接收窗口

发送方维护接收窗口的变量来提供流量控制。

TCP是全双工通信，所以两端都要维护接收窗口

LastByteRead: 主机B上的应用进程从缓存读出的数据流的最后一个字节的编号

LastByteRcvd: 从网络中到达的并且已经放入主机B接收缓存中的数据流的最后一个字节的编号

所以接收的数据的大小是前编号减去最后一个编号也就是 Data = LastByteRcvd - LastByteRead

所以接收窗口大小就等于rwnd = RcvBuffer - Data

接收窗口大小是动态的，开机的时候rwnd = RcvBuffer

A主机跟踪两个变量：LastByteSent & LastByteAcked

两者之差就是A发送到连接中但是没有被确认的数据量。

TCP连接管理

就只用研究这一张图

发起TCP连接，发送SYN信号，接收到SYN 和ACK信号就建立连接

关闭TCP连接，发送FIN信号，进入FIN等待，接收到ACK确认信号，不发送，再等待FIN，再发送最后一次ACK，等待三十秒然后断开连接。

监听套接字Socket，进入监听状态；得到SYN信号就发送SYN和ACK，进入下一状态，接收到ACK之后不发送，建立好了连接

关闭连接的时候，接收到FIN之后就发送ACK，进入等待状态，再次发送FIN，接收到了ACK便不发送，关闭连接。

拥塞控制

拥塞原因和代价

Situation 1 :

两个发送方和一台无穷大缓存的路由器

没有执行差错恢复，不用流量控制和拥塞控制

吞吐率的上线就是R/2，因为这是两条连接之间的共享链路容量造成的。

而且当发送的速率接近R/2的时候，平均排队分组的数量就会无限增长

[!拥塞网络的一种代价]
分组的到达速率接近链路容量的时候，分组就会经历巨大的排队时延

Situation 2:

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

假如主机还是用$\lambda_{in}$的速率发送数据，运输层向网络中发送报文段（含有初始数据或者重传数据）的速率用$\lambda^{‘}_{in}$表示，这就被称为供给载荷

实现性能完全取决于重传的方式。

[!Graph a)]

Assumption: A能够确定路由器是否空闲，空闲的时候才会发送分组，这样就不会丢包 $\Rightarrow \lambda_{in} = \lambda^{‘}_{in}$

这个时候的性能是理想的，也就是说每个分组都能够接收到，但是传输速率吧还是不能超过R/2。

[!Graph b)]

More Real : 发送方仅在确定了一个分组已经丢失的时候才重传。

当供给载荷达到了R/2的时候，数据被交付的速率为R/3，所以说在0.5R的单位传输中，0.333R字节是初始数据，0.166R字节是重传数据

[!INFO]
网络拥塞的另一种代价

发送方必须执行重传来步长因为缓存溢出而丢失的分组

[!Graph c)]

发送方会提前发生超时并重传已经被推迟还没有丢失的分组，也就是初始数据分组和重传分组都可能到达接收方。重传分组将被丢弃。

假定每个分组被转发两次，当供给载荷接近R/2的时候，吞吐量就渐进R/4

[!INFO]
网络拥塞的另一种代价

发送方在遇到大时延的时候所进行的不必要的重传会引起路由器利用其链路带宽来转发不必要的分组副本。

Situation 3:

四台主机发送分组，通过交叠的两跳路径传输

采用超时重传机制实现可靠数据传输

所有路由器链路容量都是R字节/s

A $\to$ C的连接： Router R1&R2

A-C & D-B and A-C & B-D 连接共享路由器R1，R2

如果吞吐量很小，路由器缓存的溢出很少见，所以较小的$\lambda_{in}$会导致$\lambda_{out}$的增大

当$\lambda_{in}$很大的情况 Consider R2

到达路由器R2的最大速率就只能是R，当$\lambda^{‘}_{in}$无穷大的时候，此时的A-C链路会因为B-D链路的供给载荷升高而导致吞吐量逐渐减少 $\to 0$

当有一个分组在第二条路由器上被丢弃的时候，第一条路由器所做的努力都白费了，也就是”劳而无功”

[!INFO]
拥塞的另一种代价

当一个分组沿一条路径被丢弃的时候，每个上游路由器用于转发该分组到丢弃该分组而是用的传输容量最终被浪费掉了。

拥塞控制方法

端到端的拥塞控制

网络层没有为运输层拥塞控制提供显式支持

TCP报文段的丢失可以看作是网络拥塞的迹象，TCP会相应减少窗口长度

使用增加的往返时延值作为网络拥塞程度增加的指示

网络辅助的拥塞控制

网络层构件向发送方提供关于网络中拥塞状态的显式反馈信息。

ATM ABR拥塞控制形式，允许路由器显式的通知发送方，告知路由器能在输出链路上支持的传输速率。

XCP协议对每个源提供路由器计算的反馈，这个反馈携带在分组首部中

直接反馈信息

由网络路由器发给发送方

阻塞分组的形式 mainly “我拥塞了”

路由器标记字段

至少要经过一个完整的往返时间

ATM ABR 拥塞控制

一种采用网络辅助方法解决拥塞控制的协议

Goal : 说明该协议为拥塞控制所采用的方法明显不同于英特网TCP协议的方法

需要理解的几个方面：

ATM基本上采用一种面向虚电路（VC）的方法来处理分组交换

允许交换机跟踪各个发送方的行为（ex. 平均传输速率）

采取特定源的拥塞控制动作(交换机变得拥塞的时候，向发送方显式的发送信令减少速率)

这样的状态（逐VC）非常适合执行网络辅助拥塞控制

设计成一种弹性数据传输服务，该服务方式使人联想起TCP

轻载的时候会充分利用空闲的可用带宽；拥塞的时候会将传输速率抑制为min

资源管理信源（aka. 分组，RM）

主机和交换机之间传递和拥塞相关的信息。

RM到达目的地之后，会调转方向想发送方传送（Probably 已经被 Destination 修改）

交换机也能发送RM，并直接发送给源。

基于速率的方法。也就是发送方明确的计算处能发送的最大速率，并据此进行相应的调整。

[! EFCI bit]

显示转发拥塞指示比特

交换机把EFCI bit set为1，表示网络拥塞

Destination 检查收到的EFCIIbit是否有1，大多数为1 $\to$ set RM = 1

将RM信源发送回给发送方

用EFCI & RM中的CIbit，发送方就能在网络交换机拥塞的时候得到通知

[!CI & NI bit]

拥塞指示比特（CI）& 无增长比特（NI）

每32个数据单元有一个RM信元

交换机在轻微拥塞的时候将经过的RM中的NI set 1，严重的时候将CI set 1.

目的主机收到RM信元的时候将RM发回发送方，保持CI,NI不变

[!ER]
每一个RM信元都会包含两个字节的显式速率（ER）

一个拥塞的交换机会降低经过的RM信元中ER字段中包含的值

以这样的方式就可以将ER字段设置为在源到目的地路径上所有交换机的最小可支持速率

一个ATM ABR 以返回的RM信元中的CI、NI和ER值为函数，来调整发送信元的速率。进行速率调整的规划非常复杂而且繁琐。