04传输层

一、传输层概述

传输层的主要任务是向应用进程提供端到端的逻辑通信服务
传输层协议是在网络边缘部分的主机中实现的,只有主机的协议栈才有传输层。
路由器在转发分组时只用到协议栈的下三层。

传输层协议的作用范围是发送方进程到接收方进程

在发送方,传输层协议实体从发送方应用进程接收数据,并依据传输层协议约定的方法,将数据封装到传输层数据单元内,交给下层实体处理;
在接收方,传输层实体从下层实体收到传输层数据单元,解封后将数据取出交给接收方应用进程。

1、传输层的两个重要协议

传输层中最重要的协议是传输控制协议(TCP)用户数据报协议(UDP)
TCP和UDP都是互联网的正式标准。
在这里插入图片描述

2.传输层复用、分用和端口

传输层复用是指将多种应用数据封装在同一种传输层协议数据单元中。
传输层分用是指将封装在同一种传输层协议数据单元中的数据分发给不同的应用进程。
实现传输层的复用和分用,需要一个标识符来标识不同的应用进程。

在计算机的操作系统中,一般采用进程标识符来标识进程。但不同的操作系统,其进程标识符格式不尽相同。
为了使不同操作系统上的进程能够互相通信,就必须选择与操作系统无关的、统一的标识符来标识通信中的进程。
传输层协议使用端口号来标识应用进程,端口号也简称为端口

TCP和UDP的首部中均包含源端口字段和目的端口字段,端口字段长度为16位,其取值范围在0~65535之间
源端口字段用来标识发送方进程,目的端口字段用来标识接收方进程。
在接收方进行处理时,源端口通常用作“返回地址”的一部分。

传输层的端口仅具有本地意义,即它所标识的是本计算机中的应用进程。
传输层利用端口实现复用和分用。

IANA将端口号分为三类:系统端口、用户端口和动态端口

在这里插入图片描述

二、用户数据报协议

1.用户数据报协议概述

UDP提供传输层最小服务,包括复用分用功能和差错检测功能
在这里插入图片描述

UDP保留应用层报文边界:
将应用进程传递来的报文作为UDP的数据部分直接封装进UDP用户数据报。

UDP对应用层报文,既不拆分,也不合并,一次发送一个报文。

UDP报文的长度是由应用进程决定的。

典型的UDP应用进程,将报文长度限制在512字节以内。如DNS、DHCP。
在这里插入图片描述

2.UDP用户数据报格式

UDP报文实例:

在这里插入图片描述
格式:
在这里插入图片描述

  • 源端口

源端口是发送方的端口号,占16位。
源端口号是可选的,如果UDP的发送方不需要对方回复,该字段允许置为全0。
UDP通信实例截获的用户数据报中,源端口值为0xc15e,即49502。该端口为短暂端口

  • 目的端口

目的端口是接收方的端口号,占16位。
接收方UDP向应用层交付报文时需要使用该字段。
UDP通信实例截获的用户数据报中, 目的端口值为0x1193,即4499。该端口为登记端口

  • 长度

长度指UDP首部和UDP数据部分的总长度,占16位。
长度的最小取值是8字节。
UDP通信实例截获的用户数据报中,长度字段的值为0x0013,即19。本例中,UDP数据部分长度11字节、UDP首部长度8字节。

  • 检验和

检验和也称为校验和。 UDP检验和是一个端到端的检验和,占16位。
UDP检验和由初始发送方计算得到由最终接收方进行检验,用于检验端到端的传输过程中,是否出现了比特差错。
对于不能通过检验的用户数据报,UDP仅做丢弃处理。
UDP通信实例截获的用户数据报中,检验和字段的值为0x92be,检验通过。

  • UDP检验和的计算

UDP检验和的计算范围覆盖UDP首部UDP数据部分和一个伪首部

伪首部衍生自IP首部和UDP首部中的某些字段,共12字节长。
伪首部并不是用户数据报真正的首部,只是在计算机检验和时,临时添加到UDP用户数据报前面,参加UDP检验和的计算。
伪首部既不向下层传送,也不向上层提交,更不会被封装传输。

在传输层的TCP协议中,TCP检验和的计算也采用了相似的伪首部。

伪首部
源IP地址和目的IP地址均来源于IP首部。
协议号字段也来源于IP首部,对于IP-UDP数据报来说,该字段值为17
UDP长度字段来源于UDP首部。

在这里插入图片描述
在这里插入图片描述

三、可靠传输原理

所谓可靠传输服务是指为上层实体提供一条可靠的逻辑信道,通过该信道传输的数据,不会发生比特差错或者丢失,并且所有数据都按照其发送顺序进行交付。

提供可靠传输服务的协议称为可靠传输协议

理想的可靠信道,满足以下两个假定:
⑴ 传输的数据不会产生比特差错、丢包或
延迟;
⑵ 接收方的接收速率能够与发送方的发送速率一样快。

本节从理想的可靠信道开始,逐步去除假定条件,直至在不可靠信道上实现可靠传输。

本节讨论的可靠传输原理协议,仅考虑单向数据通信的情况,对于全双工数据通信的情况,在可靠传输的实现方法上,与本节所述原理一致。
为方便描述,我们将发送方称为A(Alice),将接收方称为B(Bob)
本节讨论的可靠传输原理适用于一般的计算机网络协议,因此本节采用术语协议数据单元PDU进行后续的讨论

1.停止等待协议

  • 无比特差错、丢包或延迟信道上的可靠传输:

在理想的可靠信道上传输数据,不需要任何协议就可以实现可靠传输。
我们去除理想信道的第⑵个假定,保留第⑴个假定,即信道是无比特差错、丢包或延迟的。
为了保证接收方B能够正确的接收和处理收到的数据,需要增加流量控制机制:
当B收到一个PDU,处理完毕,做好接收下一个PDU的准备时,B发送给A一个包含肯定应答(Acknowledgment)PDU,记为ACK
A每次发送完一个PDU就必须停止发送,等待B发来的ACK。在收到ACK后,A才能够发送下一个PDU。
这种具有流量控制的,每发一个PDU就停下来等待的协议称为停止等待协议,简称为停等协议,SW协议。
仅具有流量控制功能的停等协议记为SW1.0协议
在这里插入图片描述

  • 有比特差错、丢包或延迟信道上的可靠传输

若去除理想信道的第⑴个假定,那么信道中传输的数据有可能出现比特差错、丢包或延迟。
分别考虑以下几种情况:

(1)数据PDU出错或丢失
在SW1.0基础上,增加如下措施,得到SW2.0协议:
B在接收PDU时,可以通过检验和计算等措施检测到差错。对于出错的PDU,B直接丢弃,不发送ACK。
为发送方增加超时重传机制:A每发送一个PDU后,设定一个超时计时器,如果超时计时器到期仍然没有收到B发送的ACK,A就重传前面发过的PDU。
如果超时计时器到期之前收到了B发送的ACK,则撤销超时计时器。
显然,如果A发送的数据PDU在传输过程中丢失,B将收不到PDU,也就不会发送ACK,超时计时器到期后,A也会重发丢失的PDU。
具有超时重传机制,不需要接收方的请求就能自动重传出错或丢失的PDU,这种协议称为自动重传请求ARQ协议

在这里插入图片描述

(2)ACK出错或丢失
如果B发送给A的ACK在传输过程中出现差错或丢失,由于A收不到正确的ACK,当超时计时器到期后,A将重发前面发过的PDU。
但是B曾经正确接收到该PDU,为了避免B将重复的PDU交给上层协议实体,在SW2.0基础上,为数据PDU增加序号字段,得到SW3.0协议
A每发送一个PDU,将序号加1,写入新PDU的序号字段
超时重传的PDU与出错或丢失的PDU具有相同的序号。
B可以根据序号判断收到的PDU是否是重复的,如果是重复的PDU,说明B发给A的ACK没有正确送达,于是B丢弃重复的PDU,并重传ACK。
在这里插入图片描述
(3)ACK延迟
B发给A的ACK在信道中传输时,有可能会延迟到达A。
如果A曾经重传过某个PDU,当迟到的ACK到达时,A不能判断该ACK对应哪一个数据PDU,SW3.0将失效。
在SW3.0基础上,为ACK增加肯定应答号字段,得到SW4.0协议
B每收到一个数据PDU,取出该PDU的序号,在发送ACK时,将序号写入ACK的肯定应答号字段,以此说明该ACK对应哪个数据PDU。
A可以根据肯定应答号判断收到的ACK是否重复,如果是重复的ACK,则A忽略该重复的ACK,不做任何其他处理。
在这里插入图片描述

停止等待协议的控制措施:
停等协议增加如下几条控制措施,在不可靠信道上实现了可靠传输。

  1. 基于确认反馈的流量控制机制;
  2. 基于超时计时器的自动重传机制;
  3. 基于序号和确认号的重复PDU识别机制。

停止等待协议的信道利用率:
在这里插入图片描述
在这里插入图片描述

2.连续ARQ协议

为了提高传输效率,可以采用流水线传输的方式。
流水线传输方式使信道上不断有数据在传送,可以获得较高的信道利用率。

采用流水线传输方式的可靠传输协议称为连续ARQ协议,也称为滑动窗口协议
根据差错恢复方式的不同,连续ARQ协议分为两种:回退N步(GBN)的连续ARQ协议和选择重传(SR)的连续ARQ协议。

  • 滑动窗口

执行滑动窗口协议的通信双方根据自己的缓存空间,各自维护一个窗口。
发送方维持发送窗口swnd,接收方维持接收窗口rwnd。
在这里插入图片描述

在这里插入图片描述
指针P1指向最早未收到ACK的PDU,
指针P2指向下一个待发送的PDU,
指针P3指向发送窗口外的第一个PDU。
[P1,P3-1] 区间称为发送窗口
发送窗口长度N=P_3−P_1,本例中,发送窗口长度为固定值10

当发送方收到对PDU-3和PDU-4的ACK后,发送窗口将向前滑动(习惯上,“向前”指向时间增大的方向,“向后”指向时间减少的方向),如图(b)所示。P1指针滑动后指向PDU-5,
由于本例中窗口长度是固定值,所以P3指针也随之向前滑动,保持发送窗口长度值10不变。
在这里插入图片描述
指针P4指向下一个待接收的PDU,
指针P5指向接收窗口外的第一个PDU。
[P4,P5-1] 区间为接收窗口
接收窗口长度N′=P5−P4,在本例中,接收窗口长度为固定值10。

当接收方收到PDU-3后,由于之前接收方已经缓存了PDU-4,接收方可以连续发送对PDU-3和PDU-4的ACK。
发送ACK-4后,接收窗口将向前滑动,如图(b)所示。P4指针滑动后指向PDU-5;
由于本例中窗口长度是固定值,所以P5指针也随之向前滑动,保持接收窗口长度值10不变

累积肯定应答的概念
接收方允许采用累积肯定应答的方式发送ACK。
累积肯定应答指接收方不必对收到的分组逐个发送ACK,而是在收到几个分组后,对按序到达的最后一个PDU发送ACK,该ACK表示到这个分组为止的所有分组都已经正确收到了。
采用累积肯定应答后,ACK中的肯定应答号是最后一个按序到达的PDU的序号。

回退N步(GBN)协议
对比停等协议和滑动窗口协议的基本概念,不难发现,停等协议实质上是发送窗口长度为1,接收窗口长度也为1的滑动窗口协议。
GBN协议是发送窗口长度大于1,接收窗口长度等于1的滑动窗口协议。

我们观察一个发送窗口长度为4,接收窗口长度为1的GBN协议运行的例子
在这里插入图片描述
GBN协议中的发送方行为
① 若发送窗口未满,则用发送缓存中的数据组装一个PDU,发送出去,登记超时计时器;若发送窗口已满,则等待发送窗口滑动。
② 若收到ACK,则取消该ACK对应的PDU以及之前的PDU的超时计时器。然后根据ACK的肯定应答号和发送窗口长度,计算并滑动当前发送窗口。
③ 若检测到超时事件,则重传超时的PDU。

GBN协议中的接收方行为
① 若收到的PDU落在接收窗口内,则接收该PDU,发送对该PDU的ACK,并滑动接收窗口。
② 若收到的PDU未落在接收窗口内,则丢弃该PDU,发送对最后一个正确PDU的ACK。

GBN的信道利用率
观察GBN协议的运行过程,可以发现流水线方式的传输使信道中不断有数据在传送,确实可以提高信道利用率。
但由于接收窗口仅为1,造成丢失或差错的PDU之后到达的所有PDU均被发送方重传,即使这些失序到达的PDU都是正确的。这种处理方式造成了信道资源的浪费。
从发送方角度来看,一旦发生超时重传事件,则需要回退N步,从超时的PDU开始重新发送所有后续PDU。

选择重传(SR)协议
停等协议是发送窗口长度为1,接收窗口长度也为1的滑动窗口协议。
GBN协议是发送窗口长度大于1接收窗口长度等于1的滑动窗口协议。
SR协议是发送窗口长度大于1,接收窗口长度也大于1的滑动窗口协议。
SR协议中,接收方使用按序到达的最后一个PDU序号对所有按序到达的PDU进行累积肯定应答,同时使用选择肯定应答(Selective Acknowledgement,SACK)对失序到达的PDU单独进行肯定应答。
选择肯定应答是SR协议必须具备的功能,累积肯定应答是SR协议的可选功能。
我们观察一个发送窗口长度为4,接收窗口长度也为4的SR协议运行的例子。本实例同时使用了上述两种肯定应答。

在这里插入图片描述

在这里插入图片描述
SR协议中的发送方行为
在这里插入图片描述
SR协议中的接收方行为
在这里插入图片描述
否定确认NAK的概念
选择重传SR协议可以跟否定策略结合在一起使用,即当接收方检测到错误的PDU时,它就发送一个否定应答(Negative Acknowledgement,NAK)。
在发送方,收到NAK可以触发该PDU的重传操作,而不需要等到对应的超时计时器超时,因此可以提高协议性能。

四、传输控制协议

1.传输控制协议概述

TCP协议是面向连接的可靠传输协议,提供连接管理、可靠传输、流量控制和拥塞控制等功能。
在这里插入图片描述

  • TCP的连接

TCP连接是逻辑连接,TCP把连接作为最基本的抽象。
TCP连接的端点称为套接字(socket)
RFC793中定义套接字由端口号拼接到IP地址构成:
套接字=(𝐈𝐏地址:端口号)
每一条TCP连接有且仅有两个端点,每一条TCP连接唯一地被通信两端的两个套接字确定
TCP连接两端的主机需要维护TCP连接状态
一旦建立连接,主机中的TCP进程将设置并维护发送缓存和接收缓存

  • 面向字节流

TCP不保留应用层报文边界
应用进程和TCP进程的交互是每次一个数据块,但TCP进程把这些数据块看成一串无结构的字节流
TCP在合适的时候从发送缓存中取出字节流封装成报文段发送出去

在这里插入图片描述
TCP报文段长度由TCP进程决定
TCP进程从发送缓存中取出并放入报文段的字节流长度受最大报文段长度(Maximum Segment Size,MSS)限制,与应用层报文边界无关
MSS指TCP报文段中数据部分的最大长度,不包含TCP首部
TCP在建立连接时,通过协商确定MSS值。

  • 可靠交付、流量控制、拥塞控制

TCP采用以字节为单位的滑动窗口协议实现可靠交付服务。
通过TCP连接传送的数据,可以保证无差错、不丢失、不重复,按序到达。
TCP采用基于窗口的流量控制机制,接收方将接收窗口值发给发送方,发送方根据该值调整发送窗口长度,并以此控制发送速率。
TCP可以根据超时重传事件和快重传事件检测网络的拥塞情况,减缓发送速度,进行拥塞控制。
TCP也支持用显式拥塞通知(Explicit Congestion Notification,ECN)的方式进行拥塞控制。
TCP发送报文段的发送时机是由TCP进程控制的

2.TCP报文格式

在这里插入图片描述
实例:
在这里插入图片描述

(1)源端口
源端口是发送方的端口号,占16位。
本实例中,源端口值为0xdca6,即56486。该端口为短暂端口。

(2)目的端口
目的端口是接收方的端口号,占16位。
本实例中,目的端口值为0x1193,即4499。该端口为登记端口

(3) 序号
序号是本报文段中数据部分首字节的编号,占32位。
TCP在建立连接时,通信双方各自选择一个随机值作为初始序号。
本实例中,序号值为0x23af ff7b,即598736763
为方便分析,Wireshark软件将序号处理成“相对序号”,初始相对序号记为0。

⑷ 确认号
确认号是期待收到的对方下一个报文段中数据部分首字节的编号,占32位。
只有标志位ACK=1,确认号字段才有效。
TCP的确认号具有累积肯定应答功能。
本实例中,1号报文段ACK位未置1,确认号字段未生效。
5号报文段中确认号字段值为598736775,说明ns57C已经正确收到598736774为止的所有字节,期待接收的下一个报文段序号为598736775。

⑸ 数据偏移
该字段的实际含义是TCP首部长度,占4位。
数据偏移以4字节(32比特)为单位,因此,TCP首部长度必须是4字节的整数倍。
数据偏移最大取值为15,因此TCP首部最大长度为60字节。
本实例中,数据偏移字段值为10,代表首部长度为40字节。
说明该TCP报文段首部由20字节的固定首部和20字节的选项构成。

⑹ 保留
RFC793规定了6位作为保留位。
后来RFC3168将保留位的最低两位定义为显式拥塞通知的标志位。
目前,保留位共占4位。
保留位应置零。

CWR:拥塞窗口缩减。当CWR=1时,表明根据ECN回显,发送方已经降低发送速率。
ECE:ECN回显。ECE=1的报文段是一个来自接收方的显示拥塞通知,表明发送方之前发送的报文段曾经遇到了网络拥塞。
CWR和ECE用于TCP的显式拥塞控制。
URG:紧急数据标志。当URG=1时,紧急指针字段生效,表明报文段中包含紧急数据,紧急数据的位置由紧急指针字段指明。
2011年RFC6093,建议不再使用紧急数据。
ACK:肯定应答标志。当ACK=1时,确认号字段生效,表明报文段中包含肯定应答信息。
TCP规定,连接建立后的所有报文段都必须把ACK置1。
PSH:推送标志。当PSH=1时,表明发送方要求接收方尽快将报文段中的数据交付给上层。
在包括Berkeley Socket在内的多数TCP/IP实现中,PSH标志置1代表发送方缓存中已经没有待发送数据。
在处理telnet等交互模式的连接时,该标志总是置1的
RST:重置连接。当RST=1时,表明TCP连接中出现了错误,需要取消连接。
RST=1的报文段通常称为RST报文段
SYN:同步连接。当SYN=1时,表明报文段是一个TCP建立连接请求。
SYN=1的报文段通常称为SYN报文段
FIN:终止连接。当FIN=1时,表明发送方的数据已经发送完毕,并请求释放TCP连接。
FIN=1的报文段通常称为FIN报文段

⑻ 窗口
窗口值代表接收窗口长度,用来进行流量控制,占16位。也称为通知窗口
发送方根据通知窗口设置发送窗口长度。
发送窗口范围
开始指针P1:接收方报文段中的确认号
结束指针P3:接收方报文段中的确认号+通知窗口

在这里插入图片描述
在这里插入图片描述
⑼ 检验和
TCP检验和与UDP检验和类似,也是端到端的检验和,占16位。
TCP检验和的计算也需要覆盖12字节的伪首部,伪首部的格式与UDP伪首部的格式一致。
TCP检验和的计算方法与UDP检验和的计算方法一样。
本实例中,检验和为0xa51b,检验通过。。

⑽ 紧急指针
当标志位URG置1时,紧急指针指出本报文段中紧急数据的位置,占2字节。
RFC6093规定,本报文段的序号值加紧急指针值等于紧急数据后的首字节的编号。
RFC6093建议,利用TCP通信的新应用,不再使用紧急指针。

选项
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
MSS值的设置与接收方的缓存以及接收窗口长度都没有关系,而是出于对传输效率的考虑。过小的MSS值和过大的MSS值都会影响通信效率。

在这里插入图片描述
TCP设置MSS值的作用是:在不引起IP分片的情况下,在一个报文段中能够尽可能多的封装数据。
在这里插入图片描述
引起IP分片的重要参数是最大传送单元MTU。MTU是数据链路层允许通过的网络层分组(最典型的是IP数据报)的最大长度。
如果IP数据报的总长度超过MTU值,IP就需要进行分片。
最典型的MTU值是1500字节,它是以太网中的MTU值。
TCP可以通过层间的调用,获得MTU值,据此计算MSS值。
在这里插入图片描述

TCP发送方在封装报文段时,需要计算有效最大报文段长度EMSS
EMSS受到对方发来的RMSS的限制,也受到发送方自己的MTU值、TCP选项长度以及IP选项长度的限制。
由于历史原因,RFC1122规定EMSS的计算公式比较复杂。
将RFC1122规定的EMSS的计算公式,做一个简单的变换,可以得到:
在这里插入图片描述
在TCP的具体实现中,有效最大报文段长度EMSS的计算还需要考虑路径MTU(PMTU)的限制。PMTU指整个网络路径上的所有链路中最小的MTU
TCP发送方发送数据时,为提高传输效率,会尽可能按照EMSS值封装TCP报文段,按照EMSS值封装的报文段称为全长报文段(Full-sized Segment)。

RFC1122中规定,RMSS的默认值为536字节
如果在SYN报文段中未包含MSS选项,则TCP将RMSS设置为536字节。
在早期的计算机网络中,X.25协议应用广泛,它的MTU值是576字节。该MTU值减去20字节的IP固定首部长度和20字节的TCP固定首部长度,刚好得到536字节。
当前的网络环境中,最典型的RMSS值是1460字节

TCP选项----WS
在这里插入图片描述
在这里插入图片描述在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
时间戳TS选项具有两大功能
在这里插入图片描述

五、TCP的连接管理

1.TCP的连接建立

主动建立连接的一端称为客户,被动等待连接建立的一端称为服务器
TCP建立连接的过程中需要在客户和服务器之间进行三次报文段交换,称为三次握手或三报文握手
首先,服务器进程B被动打开连接,从CLOSED状态进入LISTEN状态,等待来自客户的建立连接请求。
在这里插入图片描述

三报文握手

1.第一次握手
客户进程A将SYN标志置1,选择初始序号ISN(A),以服务器B的IP地址和端口号作为参数,构造TCP报文段,发送给B。
该报文段称为SYN报文段。
虽然SYN报文段的数据部分长度为0,但是占用1字节编号,以方便服务器对SYN请求进行肯定应答。
客户从CLOSED的状态进入SYN-SENT状态。
2.第二次握手
收到客户A的SYN报文段后,服务器进程B发送自己的SYN报文段作为响应。
报文段中,将SYN标志置1,选择初始序号ISN(B);并将ACK标志置1,将ISN(A)+1作为确认号。
该报文段称为SYN-ACK报文段。
SYN-ACK报文段也占用1字节编号。以方便客户对该SYN请求进行肯定应答。
服务器从LISTEN状态进入SYN-RCVD状态。
3.第三次握手
收到服务器B的SYN-ACK报文段后,客户进程A发送ACK报文段。
报文段中,将ACK标志置1,将ISN(B)+1作为确认号。序号字段为ISN(A)+1。
该报文段称为ACK报文段。
ACK报文段可以携带数据,也可以不携带数据。如果不携带数据,则不占用序号,客户A随后发送的数据报文段中序号字段任然是ISN(A)+1。
连接建立
发完ACK后,客户A从SYN-SENT状态进入ESTABLISHED状态。
此时,对于客户进程A,TCP连接已经建立,可以开始进行数据传输了。
服务器B收到客户A的ACK报文段后,从SYN-RCVD状态进入ESTABLISHED状态。
此时,服务器进程B也可以开始进行数据传输了。

2.TCP的连接释放

在这里插入图片描述

数据传输结束后,通信双方都可以主动释放TCP连接。
主动释放连接的一端称为客户被动释放连接的一端称为服务器。
TCP 释放连接的过程中需要在客户和服务器之间进行四次报文段交换,称为四次握手或四报文握手。
假定进程A主动释放连接。
将数据传输过程中,进程A发送给进程B的最后一字节编号记为x-1,进程B发送给进程A的最后一字节编号记为y-1。

1.第一次握手
A向B发送释放连接请求报文段。
在该报文段内,将FIN标志置1,填写序号为x。
由于TCP建议连接建立后的所有报文段中ACK标志都置1,所以A也将ACK标志置1,并填写确认号为y,用以肯定应答收到的最后一字节数据。
该报文段一般称为FIN报文段。
FIN报文段数据部分长度为0,但是占用1字节编号,以方便通信中对方对FIN请求进行肯定应答。
客户从ESTABLISHED状态进入FIN-WAIN-1状态。
2.第二次握手
收到A的释放连接请求后,服务器进程B应立即发送ACK。
在ACK报文段中**,B将ACK标志置1**,填写确认号为x+1,填写序号为y。如果该ACK不含数据,则不占用字节编号。
服务器从ESTABLISHED状态进入CLOSE-WAIN状态。
客户收到ACK报文段后,从FIN-WAIT-1状态进入FIN-WAIT-2状态
这时的TCP连接处于半关闭状态
A不能再发送数据。B如果有数据,还可以继续发送,A仍然要接收
3.第三次握手
图示例中,半关闭状态下,B没有发送数据。
当进程B需要释放连接时,也需要发送一个FIN请求。
该报文段中,FIN标志置1,序号仍然为y。B也将ACK标志置1,确认号仍然为x+1
FIN报文段虽然不包含数据,但占用1字节编号
服务器从CLOSE-WAIT状态进入LAST-ACK状态。
4.第四次握手
收到B的FIN请求后,客户进程A应立即发送ACK。
在ACK报文段中,A将ACK标志置1,填写确认号为y+1,填写序号为x+1
客户A发送了ACK报文段后,从FIN-WAIT-2状态进入TIME-WAIT状态。
连接释放
服务器进程B收到最后一个ACK报文后,从LAST-ACK状态进入COLOSED状态。此时,对于B来说,TCP连接已关闭
客户进程A需要在TIME-WAIT状态等待2MSL时间之后,才能进入COLOSED状态。
MSL代表最长报文段生存期,RFC793建议MSL取值2分钟。
当2MSL计时器超时后,A从TIME-WAIT状态进入CLOSED状态。对于A来说,TCP连接才关闭

如果A发送的最后一个ACK在传输过程中丢失,
则在TIME-WAIT状态,A会收到B重传的FIN请求,
A需要重新发送确认并重置2MSL计时器

3.TCP的状态变迁

在这里插入图片描述
红色箭头为客户的正常变迁
紫色箭头为服务器正常变迁
黑色箭头为异常变迁

六、TCP的可靠运输

TCP的可靠传输协议是以字节为单位的滑动窗口协议

TCP可靠传输的特点
TCP窗口内的序号不是以PDU为单位编号,而是以字节为单位编号。
TCP的发送窗口和接收窗口均大于1。
TCP的发送窗口和接收窗口长度不是固定的,而是动态变化的。
TCP支持多种重传机制:超时重传、快重传和SACK重传。

1.超时重传

如果出现了报文段丢失或差错,TCP将会采用4.3节中介绍的超时重传机制,对超时且未收到ACK的报文段进行自动重传。
TCP的超时重传采用累积肯定应答,不能单独对失序到达的报文段进行肯定应答。
TCP的超时重传概念很简单,但实践中超时重传时间(RTO)的选择却比较复杂。
TCP测量
往返路程时间(RTT
),计算平滑往返时间,并计算超时重传时间(RTO)

(1)往返路程时间的估算
TCP记录一个报文段的发出时间,以及收到对应ACK的时间,二者之差作为一个RTT测量值,也称为RTT样本,记作RTTsam。
TCP维护一个RTT的加权平均值,称为平滑往返时间,记作SRTT
每进行一次测量,TCP按照如下公式计算新的平滑往返时间SRTT:
在这里插入图片描述
RFC6298中,建议 α 取值0.125。
SRTT的初值应设置为第一个有效的RTT样本。

类似SRTT这种加权平均值称为指数移动加权平均值,时间越靠近当前时刻的数据权重越大。

(2)RTT偏差的估算

RFC6298定义了RTT偏差,记作RTTV,用以估算RTT样本偏离SRTT的程度。
RTT偏差也是一个指数移动加权平均值,每取得一次RTTsam,TCP按照如下公式计算RTTV:

在这里插入图片描述RFC6298中,建议 β 取值0.25。
RTTV的初值设置为第一个RTT样本值的一半。

(3)超时重传时间RTO的估算
超时重传时间RTO应略大于平滑往返时间SRTT。
每取得一次RTTsam,TCP计算SRTT和RTTV,然后按照如下公式计算RTO:

在这里插入图片描述
上式中G代表系统的时钟粒度(clock granularity),即使计算得到的RTTV趋近零,RTO也应该比SRTT大1个时钟粒度。在Linux系统中,TCP时钟粒度为1ms,因此RTO至少比SRTT大1ms。
RFC6298建议给RTO设定上界和下界,上界的建议值是60秒,下界的建议值是1秒。
在尚未取得有效RTT样本之前,RFC6298建议将RTO初值设置为1秒。

(4)RTT样本测量
RFC6298不要求对每一个TCP报文段进行RTT样本测量,但要求在一个RTT时间间隔内,至少进行一次RTT样本测量。
在测量RTT样本的过程中,如果出现重传,就会带来二义性问题。
在这里插入图片描述
为了避免二义性,TCP采用Karn算法。
Karn算法包括两部分:
① 当报文段重传后,不采用该报文段作为RTT样本。
② 报文段每重传一次,将RTO增大为原来的2倍,直至不再发生重传。
Karn算法使TCP可以区分有效和无效样本,保证RTO计算结果更加合理。

注意:在4.4节中,我们介绍了TCP的时间戳选项可以用于往返时间测量。
当发送方收到ACK时,用当前时间减去回显时间戳的时间,即可得到往返时间。
利用时间戳选项计算往返时间,显然可以避免上述二义性,因此不必采用Karn算法的第①部分。

2.快重传

超时重传机制可以实现可靠传输,但有如下缺点
超时周期相对较长,效率不高。
TCP的超时重传机制会带来更大的网络负载。
根据Karn算法的第②部分,超时重传事件还会引起RTO快速增长,因而会引起网络利用率下降。
RFC5681和RFC6582中定义了更为高效的快重传机制。

快重传机制不依赖重传计时器超时,而是基于接收方的反馈信息来引发重传
快重传机制通过检测重复ACK(duplicate ACK)事件发现丢包,触发重传。
由于TCP的确认号具有累积肯定应答功能,因此,当接收方TCP收到失序的报文段时,发送的ACK中的确认号,与确认最后一个按序到达的报文段的确认号一样。这种再次确认某个报文段的ACK称为重复ACK
我们首先介绍接收方发送ACK的策略
1.对于正常到达的数据报文段,最多延迟500ms就需要发送ACK;连续收到两个正常数据报文段时,必须立即发送ACK。
2.对于失序到达的数据报文段,必须立即发送ACK(重复ACK)。
在这里插入图片描述
在这里插入图片描述
快重传算法的要点

TCP NEWReno版本的快重传算法的要点可以总结如下:
① 收到3个重复ACK:记录恢复点,启动快重传算法,重传丢失的报文段;
②收到部分ACK:立即重传下一个丢失的报文段;
③收到完全ACK:退出快重传。

TCP的快重传机制,实际上以重复ACK的形式实现了隐式的否定应答(NAK)
优势:与超时重传相比,快重传能更加及时有效地修复丢包情况,提高重传效率。
不足:虽然可以对一个窗口内的多个丢失报文段进行快速重传,但是第2次重传是在收到第1次重传的触发的部分ACK之后,两次重传之间的时间间隔大于一个RTT,因此效率不高,并且仍然容易触发超时重传。

3.SACK重传

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

七、TCP的流量控制

如果接收方应用进程读取数据的速度相对缓慢,而发送方发送数据太多、太快,发送的数据就可能会造成接收缓存溢出。
TCP的流量控制机制完成了对发送速度的调节,它是基于ACK报文段中的通知窗口长度来实现的。这种方式提供了明确的来自接收方的状态信息,可以避免接收方缓存溢出。
停等协议和连续ARQ协议,两者都采用了固定长度的发送窗口,不能根据接收方的情况进行调节。
TCP协议采用了可变长度的发送窗口,其发送窗口根据接收方的通知窗口设定。

接收方每收到一个报文段,都重新计算自己的接收窗口长度。
较早的TCP实现中,TCP接收方被分配一个固定大小的接收缓存,用以下公式计算接收窗口长度:
在这里插入图片描述
较新版本的TCP实现中,增加了TCP接收窗口长度自动调优算法,该算法综合考虑当前可用缓存容量以及本连接的延迟带宽积等因素,调整分配给TCP连接的接收缓存,然后计算接收窗口长度。
接收方在发送ACK给发送方时,将计算得到的接收窗口长度填入TCP首部中的窗口字段通知给发送方
发送方的发送窗口必须小于等于通知窗口,在不考虑拥塞控制的影响时,发送方设置发送窗口等于通知窗口。
发送方根据自己的发送窗口发送报文段。

零窗口通知/窗口更新报文/窗口探测报文

在流量控制过程中,如果接收缓存耗尽,接收方会将通知窗口长度设置为0。发送零窗口通知给发送方,不允许发送方继续发送新数据。
在接收方重新获得可用缓存空间后,主动传送给发送方窗口更新报文。窗口更新报文通常不包含数据。属于“纯ACK”。
在TCP协议的设计中,对于不包含数据的“纯ACK”,没有肯定应答和重传的机制。如果窗口更新报文丢失,发送方将一直等待窗口更新报文,而接收方则一直等待新的数据,协议将陷入死锁状态。
为避免这种死锁状态的出现,TCP发送方会维持一个持续计时器
一旦收到零窗口通知,发送方就设定持续计时器,持续计时器超时则发送一个窗口探测报文,查询接收方通知窗口变化。

糊涂窗口综合征
如果应用进程读取数据后,接收方获得的可用缓存空间很小,这时发送窗口更新报文,会造成传输效率的下降。
在极端情况下,会造成发送方和接收方交互的都是仅包含1字节数据的报文段,这种现象在RFC813中称为糊涂窗口综合征。
为避免糊涂窗口综合征,RFC1122建议:在满足以下两种情况之一时,TCP才发送窗口更新报文。
① 可用缓存可以容纳一个全长报文段;
② 可用缓存达到接收缓存空间的一半。

Nagle算法
在这里插入图片描述

八、TCP的拥塞控制

1.拥塞原因及其影响

路由器无法处理过高的流量称为拥塞。拥塞可能引起路由器丢弃分组,处于拥塞状态的路由器称为拥塞结点。

拥塞产生的原因很多:
结点的缓存空间较少
输出链路的容量较低
结点处理机的运算能力较弱
等等

拥塞是一个复杂的综合问题,依靠增加资源等简单措施不能解决。
网络出现拥塞会带来很多负面影响,如增大排队延迟,加大网络负担,浪费通信资源等。

在这里插入图片描述

在这里插入图片描述
TCP的拥塞控制方法:
在这里插入图片描述

2.TCP的经典拥塞控制

在这里插入图片描述
TCP采用的拥塞控制方法是基于窗口的。
TCP增加了一个状态变量,叫拥塞窗口(congestion windows,cwnd)。
拥塞窗口长度取决于网络的拥塞程度,并能根据网络拥塞情况动态变化。
发送方要求自己的发送窗口必须小于等于拥塞窗口,以此控制发送速率
TCP进行拥塞控制的原则是:
如果网络中没有出现拥塞,就增大拥塞窗口,以此提高发送速率,提高吞吐量;
如果网络中出现了拥塞,就减小拥塞窗口,以此降低发送速率,降低网络负载。

在这里插入图片描述
在这里插入图片描述

TCP发送方如何监测网络的拥塞程度呢?
监测4.6节中介绍的三种重传事件:
超时重传:超时计时器超时事件
快重传:3个重复ACK事件
SACK重传:RFC6675规定的两个条件之一

出现了以上三种重传事件,TCP认为出现了不同程度的网络拥塞,应用不同的拥塞控制算法进行处理。

(1)慢开始
在TCP连接建立之初或者发生超时重传事件后,都需要执行慢开始算法。
TCP连接建立之后,需要设定初始拥塞窗口,记为初始窗口IW。
RFC5681规定IW值为2SMSS~4SMSS,具体规定如下:
在这里插入图片描述
每收到一个有效ACK,把拥塞窗口增加不超过1 SMSS的数值。
RFC5681规定的计算公式如下:

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
当监测到超时事件时, TCP停止cwnd的增长。
如果监测到快重传事件或SACK重传事件,就启动快恢复算法。
如果监测到超时重传事件时,按照以下公式计算ssthresh:

在这里插入图片描述
其中,FlightSize为在途数据量,代表已经发出但尚未被累积肯定应答的字节数。
在不考虑通知窗口的限制时,可以近似认为FlightSize≈cwnd,此时ssthresh的计算公式变换为:
在这里插入图片描述
然后,将cwnd设为1,重新执行慢开始算法。

在这里插入图片描述
(2)拥塞避免

当cwnd>ssthresh时,TCP启动拥塞避免算法。
拥塞避免中,每收到一个有效ACK,按照以下公式更新cwnd值:

在这里插入图片描述
如果以SMSS为单位,假定当前cwnd=k×SMSS,则每收到一个有效ACK,新的cwnd_n计算如下:

在这里插入图片描述
每个有效ACK的到达,cwnd增加1/k SMSS。
每经过一个轮次,cwnd增加1 SMSS。
在这里插入图片描述
(3)快恢复

在这里插入图片描述
(4)拥塞控制状态变迁
根据执行算法不同,TCP经典拥塞控制包括三个阶段:慢开始、拥塞避免、快恢复。三个阶段的作用如下:

慢开始阶段是TCP探测当前网络传输能力的阶段。
拥塞避免阶段是TCP的稳定运行阶段,在该阶段TCP继续探测可能利用的网络资源。
快恢复阶段是TCP发现网络拥塞后,调整和恢复稳定运行的阶段。

在这里插入图片描述TCP拥塞控制算法被称为AIMD算法:
在拥塞避免阶段,TCP线性增加拥塞窗口cwnd,缓慢探测网络传输能力,该特点被称为加法增大。
在快恢复阶段,经过快速的调整和恢复,TCP将慢开始阈值ssthresh和拥塞窗口cwnd设置为触发快恢复时的cwnd的一半,该特点被称为乘法减小。

拥塞控制下的cwnd变化示意图在这里插入图片描述

影响发送窗口swnd的两个因素为:
通知窗口awnd:TCP的流量控制要求TCP的发送窗口小于等于通知窗口
拥塞窗口cwnd:TCP的拥塞控制要求发送方的发送窗口小于等于拥塞窗口

在这里插入图片描述
上式说明:
当awnd较小时,决定发送方发送速率的是TCP的流量控制
当cwnd较小时,决定发送方发送速率的是TCP的拥塞控制

3.网络层辅助的拥塞控制

网络层辅助的拥塞控制方法包括:主动队列管理AQM和显式拥塞通知ECN

在这里插入图片描述
主动队列管理
在这里插入图片描述
随机早期检测RED:
在这里插入图片描述
显式拥塞通知:
RFC3168将IP首部中的两个比特定义为ECN字段,其取值及含义如表:
在这里插入图片描述
在这里插入图片描述

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

全糖去冰不加料

打赏一块钱💰也是钱

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值