【计算机网络】| 【05】运输层

1、运输层概述

该层协议为端到端协议;
主要负责为运行在不同主机上的应用进程提供直接的通信服务,并使用端口号来区分不同的应用进程(PID);
运输层为应用层提供了两种不同的运输协议,面向连接的TCP和无连接的UDP;

在这里插入图片描述

2、端口号、复用与分用

由于在不同系统上的进程标识符不同,但在网络通信时需要有统一的方法对其进行标识:
TCP/IP采用端口号来(0~65535)进行区分:
	- 熟知端口号:0~1023,IANA将其指派给TCP/IP中重要的应用协议;
	- 登记端口号:1024~49151,为没有熟知端口号的应用程序使用;
	- 短暂端口号:49152~65535,留给客户进程选择暂时使用;
	端口号只具有本地意义,标识计算机应用层中的各进程;

2.1 发送方的复用和接收方的分用

在这里插入图片描述
TCP/IP常用协议以及端口号
在这里插入图片描述
案例:页面访问
在这里插入图片描述
在这里插入图片描述

3、UDP和TCP对比

UDP:可以随时发送数据;
	- 支持一对一、一对多、一对全的通信;	
	- 对应用层交付的报文直接打包;
	- 不可靠传输;
	- 首部开销小,仅8字节;
TCP:在数据传输之前,必须使用三次握手建立连接,才可进行数据传输,传输好后还需要使用四报文挥手来释放连接;
	- 仅支持一对一通信;
	- 面向字节流;
	- 可靠传输,使用流量控制和拥塞控制;
	- 首部最小20字节,最大60字节;

在这里插入图片描述
应用报文的处理
在这里插入图片描述
传输服务
在这里插入图片描述
首部格式
在这里插入图片描述

4、TCP详细介绍

4.1 TCP流量控制

控制发送方发发送速率,要让接收方来得及接收,采用滑动窗口机制;

- 当发送窗口发送满足,即需要等待ACK后才能继续发送;
- 当数据丢失后,等待超时重传;
- 当收到被接收的数据,响应给A后,其缓存会被删除;

在这里插入图片描述
当B的报文丢失了

【当B的报文丢失了】:
- TCP为每个连接设置一个持续计时器;
- 只要TCP连接的一方收到对方的零窗口通知,就起到该计时器;
- 若超时,就发送一个0窗口探测报文,仅有1字节的数据;

在这里插入图片描述

4.2 TCP拥塞控制

在某段时间内,对网络中某一资源的需求超过了该资源所提供的可用部分,网络性能降低;
- 若出现拥塞不进行控制,增共网络的吞吐量将随输入负荷的增大而下降;
- 发送方维护一个拥塞窗口cwnd的状态变量,取决于网络的拥塞程度(动态变化);
	- 只要网络没有出现拥塞,cwnd就再增大一些;若出现拥塞,则就减少一些;
	- 判断网络拥塞的依据,即没有按时收到应当到达的确认报文(发生超时重传);
- 发送方将拥塞窗口作为发送窗口swnd,即swnd=cwnd;
- 维护一个慢开始门限ssthresh状态量:
	- 当cwnd < ssthresh时,使用慢开始算法;
	- 当cwnd > ssthresh时,停止使用慢开始算法而改用拥塞避免算法;
	- 当cwnd = ssthresh时,即可使用慢开始算法,也可使用拥塞避免算法;

【四种拥塞控制方法】:
- 慢开始:是一开始向网络注入的报文段少,并不是指拥塞窗口cwnd增长速度慢;
- 拥塞避免:并非指完全能够避免拥塞,而是再拥塞阶段将拥塞窗口控制位按线性规律增长,使网络比较不容易出现拥塞;
- 快重传:避免误认为发生网络拥塞,从而降低传输效率,让发送方尽早知道了个别报文段的丢失,尽快重传,而不是等计时器超时再重传;
-  快恢复;

慢开始和拥塞避免
在这里插入图片描述
快重传

- 要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认;
- 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认;
- 发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的超时重传计时器超时再重传;
- 对于个别丢失的报文段,发送方不会出现超时重传,也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%;

在这里插入图片描述
快恢复

发送方一旦收到3个重复确认,即知道丢失了个别的报文段,故不启动慢开始算法,而执行快恢复算法;
- 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法;
- 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh + 3;
	- 既然发送方收到3个重复的确认,即表明有3个数据报文段已经离开了网络;
	- 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;
	- 可见现在网络中不是堆积了报文段而是减少了3个报文段,因此可以适当把拥塞窗口扩大些;

在这里插入图片描述

4.3 TCP超时重传时间的选择

超时重传时间(RTO)小于往返时间时,将会引起报文段不必要的重传,使网络负荷增大;
若设置远大于往返时间,会使网络的空闲时间增大,降低了传输效率;
故应设置位略大于往返时间的值;

【解决方法】:
- 不能直接使用某次测量得到的RTT样本来计算超时重传时间,由于下次往返时间并不一致;
- 利用每次测量得到的RTT样本,计算加权平均往返时间RTT;

在这里插入图片描述
往返时间RTT的测量复杂

当出现以下问题时,无法推测RTT时间,故再计算TRRs时,只要报文段重传了,即不采用该RTT样本;

在这里插入图片描述
会使用超时重传时间无法更新,导致报文段反复被重传

即报文段每重传一次,就将超时重传时间增大一些;

4.4 TCP可靠传输

【如何描述发送窗口的状态】:
- 使用三个指针描述,p1指向窗口头部,p2指向下一个未发送的字节序,p3指向窗口下一个;
- <p1表已发送,并收到确认的部分;
- >=p3不允许发送的部分;
- p3-p1 = 发送窗口尺寸;
- p2-p1 = 已发送但尚未收到确认的字节数;
- p3-p2 = 允许发送但当前尚未发送的字节数;

在这里插入图片描述

- 虽发送窗口是根据接收方设置的,但同一时刻,发送窗口并不总是和接收窗口一样大;
	- 网络传送窗口值需要经历一定的时间滞后,并且这个时间还是不确定的;
	- 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸;
- 对于不按序到达的数据应如何处理,TCP并无明确规定;
	- 若接收方把不按序到达的数据一律丢弃,即接收窗口的管理将会比较简单,但对网络资源的利用不利因为发送方会重复传送较多的数据;
	- TCP通常对不按序到达的数据是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程;
- TCP要求接收方必须有累积确认和捎带确认机制,以此减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上;
	- 接收方不应过分推迟发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络的资源;
	- 捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据;
- TCP的通信是全双工通信;一定要弄清楚是哪一方的窗口;

4.5 TCP运输连接管理

4.5.1 TCP连接建立
- TCP是面向连接的协议,它基于运输连接来传送TCP报文段;
- TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程;
- TCP的运输连接管理是使运输连接的建立和释放都能正常地进行;

【建立连接要解决的问题】:
- 使TCP双方能够确知对方的存在;
- 使TCP双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等);
- 使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。

三次握手
在这里插入图片描述
能否使用两次建立连接

TCP客户进程发送TCP连接请求报文段,若该报文段长时间滞留,将会超时重传;
若重传的被Server接收,server发送连接确认,进入连接状态,client收到该确认也进入已连接状态;故进行数据传输,传输完毕并关闭;
但原先滞留的报文到达server,会将其误认为未client进程继续建立连接;
而client处于关闭状态,不会理会该报文段,但server已进入连接状态,即进入等待接收数据,这将浪费server资源;

- 故使用三次是为了防止建立连接时,防止失效的连接请求报文突然又传送到了服务器,导致错误;
4.5.2 TCP连接释放

四报文挥手释放连接

在这里插入图片描述

为什么client进程不直接进入关闭状态
在这里插入图片描述

若该报文段丢失后,必然会使服务器对之前的报文段重传, 当重传时,若client处于关闭,将会造成server返回重传,一直处于无法关闭;

防止client主机故障

当clent故障时,TCP服务器将不在收到客户端发来的数据,服务器应如何察觉到该状况;使用保活计时器,每收到client的数据就
重新设置并启动保活计时器(2小时),若定期内没有收到,则向clent每隔75s发送以此探测报文,连发10各,若无响应,即关闭该连接;

5、TCP首部格式

一个TCP报文段由首部和数据载荷两部分构成;

在这里插入图片描述

【源端口】:占16比特,写入源端口号,用来标识发送该TCP报文段的应用进程;
【目的端口】:占16比特,写入目的端口号,用来标识接收该TCP报文段的应用进程;
【序号】:占32比特,取值范围[0, 65535],序号增加到最后一个后,下一个序号就又回到0;
	指出本TCP报文段数据载荷的第一个字节的序号;
【确认号】:占32比特,取值范围[0, 65535],确认号增加到最后一个号,下一个确认号就又回到0;
	指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号,同时也是对之前收到的所有数捅的确认。
	若确认号=n,则表明到序号n-1为止的所有数据都已正确接收,期望接收序号为n的数据。
【确认标志位ACK】:取值为1时确认号字段才有效;取值为0时确认号字段无效;
【数据偏移】:占4比特,并以4字节为单位;
	用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远;
【保留】:占6比特,保留为今后使用,但目前应置为0;
【窗口】:占16比特,以字节为单位。指出发送本报文段的一方的接收窗口;
	- 窗口值作为接收方让发送方设置其发送窗口的依据;
	- 这是以接收方的接收能力来控制发送方的发送能力,称为流量控制;
【校验和】:占16比特,检查范围包括TCP报文段的首部和数据载荷两部分;
【同步标志位SYN】:在TCP连接建立时用来同步序号;
【终止标志位FIN】:用来释放TCP连接;
【复位标志位RST】:用来复位TCP连接;
	当RST=1时,表明TCP连接出现了异常,必须释放连接,然后再重新这接;
	RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接;
【推送标志位PSH】:接收方的TCP收到该标志位为1的报文段会尽快上交应用进程,而不必等到接收缓存都填满后再向上交付;
【紧急标志位URG】:取值为1时紧急指针字段有效;取值为0时紧急指针字段无效;
【紧急指针】:占16比特,以字节为单位,用来指明紧急数据的长度;
	当发送方有紧急数据时,可将紧急数据插队到发送缓存的最前面,并立刻封装到一个TCP报文段中进行发送。
	紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据,紧急数据之后是普通数据;
【选项】:
	最大报文段长度MSS选项:TCP报文段数据载荷部分的最大长度;
	窗口扩大选项:为了扩大窗口(提高吞吐率);
	时间戳选项:
		- 用来计算往返时间RTT;
		- 用于处理序号超范围的情况,又称为防止序号绕回PAWS;
	选择确认选项;
【填充】:由于选项的长度可变,因此使用填充来确保报文段首部能被4整除;

猜你喜欢

转载自blog.csdn.net/weixin_45926547/article/details/124935751