第5层 运输层

运输层专业英语

进程标识符PID(Process Identification)

传输控制协议TCP(transmission control protocol)

用户数据报协议UDP(user datagram protocol)

序列号seq(sequence number)

接收端窗口rwnd(request window)

发送端窗口swnd(send window)

拥塞窗口cwnd(crowd window)

慢开始门限ssthreshold(slow start threshold)

流量控制(flow control)

拥塞(congestion)

慢开始(slow strat)

拥塞避免(congestion avoidance)

快重传(fast retransmit)

快恢复(fast recovery)

同步序列编号SYN(Synchronize sequence number)

最长报文段寿命MSL(maximum segment lifetime)

紧急标志位URG(urgent)

确认标志位ACK(ackowledge)

重置位RST(reset)

推送位PSH(push)

5.1 运输层概述

  • 之前介绍的物理层,数据链路层和网络层实现了主机与主机的通信
  • 但是计算机网络通信的实体时通信两端的进程
  • 如何让通信在端到端之间进行,就是运输层完成的任务,所以运输层协议又被称为就称为端到端协议

在这里插入图片描述

信息传输的整个过程:

在这里插入图片描述

逻辑通信是指数据好像是通过运输层水平传输的,但是这两个运输层之间没有一个水平方向的物理连接

  • 运输层与上层提供端到端的服务,并屏蔽了下面网络执行的核心细节,上层往下看就好像两个运输层实体水平传输了数据一样
  • 运输层向上层提供两种不同的运输协议,即面向连接的TCP协议和无连接的UDP协议

5.2 运输层的端口号,复用和分用的技术

  • 运行在计算机上的进程都是用进程标识符PID来标志

  • Internet网上并不是使用统一的标识符(有windows,linux等等),又使用不同格式的进程标识符

  • 要用统一的方法对对TCP/IP的应用进程进行标识

  • TCP/IP体系的运输层使用端口号来区分应用层不同的应用进程

    • 端口号使用16比特表示,0-65535
    • 熟知端口号:0-1023,这些端口号存放的是TCP/IP协议种一些重要的协议端口
    • 登记端口号:1024-49151,为没有熟知的应用程序使用
    • 短暂端口号:49152-65535,留给客户暂时使用

复用和分用技术

在这里插入图片描述

TCP/IP协议常用的端口号:

在这里插入图片描述

用户访问网页的过程

1.用户先向DNS服务器提出DNS查询请求,查询www.porttest.com对应的IP地址是什么?

在这里插入图片描述

2.再将DNS查询请求封装为IP数据报,用UDP首部,源端口为随机分配的短暂端口49152,目的端口为DNS协议对应的53号端口号

在这里插入图片描述

3.将封装好的数据报发送给DNS服务器,DNS服务器找到对应的IP地址,随后发送DNS响应,用UDP首部封装,UDP首部的源端口为53,目的端口为49512,这时,用户PC得到了网站的IP地址192.168.0.3

在这里插入图片描述

4.用户PC中的HTTP客户端进程向Web服务器发送HTTP请求了,使用TCP首部进行封装,源端口号为:49152,目的端口号为:80

在这里插入图片描述

5.Web服务器发送HTTP响应报文给用户,告诉用户PC的HTTP客户端进程,HTTP客户端进程解析HTTP相应,得到了首页内容并显示出来

在这里插入图片描述

5.3 TCP和UDP协议

TCP,UDP的重要程度仅次于IP协议

在这里插入图片描述

1.TCP和UDP支持的传播方式:

  • UDP协议支持单播,多播以及广播
  • TCP只支持单播:(先通过3次握手建立连接,再进行数据的传输)

在这里插入图片描述

2.TCP和UDP在传输报文时面向对象的区别:

在这里插入图片描述

其中发送方如果交付给TCP10个数据块,而接收方的TCP可以给接收方4个数据块,但是必须保证这4个数据块和发送方的数据块中的信息是相同的

3.TCP和UDP提供的服务的区别

在这里插入图片描述

4.TCP和UDP首部字段对比

在这里插入图片描述

总结

UDPTCP
支持单播,多播和组播仅支持单播
面向应用报文进行传播面向字节进行传播
提供无连接的不可靠服务提供面向连接的可靠传输服务(可靠传输,流量控制,拥塞控制)
首部数据报只有8个字节首部数据报最小20个字节,最大60字节(像IP数据报)

5.4 TCP的流量控制

采用滑动窗口机制,假设TCP的一个数据块为从1到100,而滑动窗口大小为400,如下图seq为序列号

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UaWvRds0-1616571949263)(C:\Users\86131\AppData\Roaming\Typora\typora-user-images\image-20210321214755232.png)]

接下来,主机B向主机A发送了ACK=1,ack=201,rwnd=300(ACK=1是确认报文段,ack=201表示期待下一次发送的报文的seq=201 ,rwnd=300表示即将接受窗口的大小调整为300),随后发送发送窗口中可以发送的301到500号字节的数据,A超时重传201-300号数据,然后B再对501号以前的数据进行累计确认,将接受窗口调整为100,对A进行流量控制

在这里插入图片描述

A 把发送窗口的大小调整为100,窗口前移,发送501到600共100个字节的数据,B接收到了,但是又把接受窗口值调整为0,这样下去,A的窗口也为0,无法再接收和发送数据,过了一段儿时间,B接收窗口又变为了300,但是发送的rwnd=300在中途被丢失了

这个时候就陷入了一个死锁的局面,就是A等待B发送窗口,B等待A发送数据

因而就为A设置了一个持续计时器,当时间到了,就像B发送0窗口探测报文,进而打破了死锁的局面

在这里插入图片描述

408真题:

在这里插入图片描述

5.5 TCP的拥塞控制

  • 拥塞:网络中对某一资源的请求数量超过了这个资源的已有数量,网络性能变坏的现象
  • 如果出现拥塞现象而不加控制,整个网络的吞吐量(单位时间内传输的数据的数量)会随输入荷载的增大而下降

在这里插入图片描述

四种情况:

  1. 慢开始(slow strat)

  2. 拥塞避免(congestion avoidance)

  3. 快重传(fast retransmit)

  4. 快恢复(fast recovery)

发送方维护一个叫做拥塞窗口的cwnd的变量,这个变量的值取决于网络的拥塞程度,并动态变化

  • cwnd的维护原则:超时情况多就减小cwnd,超时少就增大cwnd
  • 发送方将拥塞窗口作为发送窗口swnd=cwnd
  • 维护一个慢开始门限ssthresh(slow start threshold)变量:
    • 当swnd<ssthresh时,使用慢开始算法
    • 当swnd>ssthresh时,使用拥塞避免算法
    • 当swnd=ssthresh时,使用拥塞避免算法or慢开始算法

举例说明

慢开始门限值和拥塞避免控制算法

下图中的传输轮次就是一个往返,刚开始cwnd=1,在这个问题中cwnd等于多少,swnd就等于多少,在慢开始算法中cwnd呈指数型增长,一直增长到慢开始门限值16,随后采用拥塞避免算法,窗口值开始线性增长(即每次cwnd+1),直到出现超时重传的情况后,将慢开始门限值调整为当下情况的cwnd的一半,随后,将cwnd调为1,再像开始一样指数型增长,达到慢开始门限值后再线性增长。

下图采用慢开始算法

在这里插入图片描述

接下来用拥塞避免算法:

在这里插入图片描述

引起了超时重传,并将ssthresh减小一半,cwnd取为1,继续:

在这里插入图片描述

再进行一轮慢开始算法和拥塞避免算法,

在这里插入图片描述

随后就继续这样的循环即可

快重传和快恢复算法

在上述情况下,如果个别报文段发生丢失而不是因为拥塞引起的超时重传,就会使得发送方启动慢开始算法,即将cwnd重置为1,再进行重传,这样无疑会减小传送的效率,所以引入了快重传算法

举例:

在这里插入图片描述

快重传算法的目的:为了使发送方尽快确认是个别报文段丢失引起的超时重传而不是拥塞引起的超时重传

于是就有了以下几个要求

  • 要求接受方即使收到了未按序到达的报文段也必须要重复确认
  • 接收方收到发送过来的报文时必须马上确认(不能等到自己发送数据时才开始稍待确认)
  • 发送方一旦收到3个以上的重复确认,则将相应的报文段立即重传,而不是等待超时计时器超时后再重传

举例:

在这里插入图片描述

快恢复算法:

  • 发送方一旦受到了3个重复确认,就知道了现在只是丢失了个别报文段,于是采用快恢复算法
    • 快恢复算法中的一种:将慢开始门限值ssthresh和拥塞窗口cwmd都调整位当前的一半

下面这个例子综合了

上述4种算法总结图:

在这里插入图片描述

408真题:

在这里插入图片描述

5.6 TCP超时重传的时间选择

按理来说,应选择超时重传的时间RTO,应略大于往返时间RTT

在这里插入图片描述

但是由于传输层下的各层的传输时间不一样,所以大家的RTT不一样,会导致上图中RTT2>RTO的情况,使得有多余的重传报文段1发生,所以应该采用平均往返时间RTTs,计算方法如下:

在这里插入图片描述

上述α一般取值1/8,而RTO的值会略高于平均往返时间RTTs,计算公式如下:

在这里插入图片描述

5.7 TCP可靠传输的实现

TCP是基于字节为单位的滑动窗口来实现可靠传输

为了描述现在滑动窗口的状态,引入了3个指针,p1之前的指针是以发送但未收到确认的数据,P1-P2的部分是已经发送的数据,P2-P3的部分是在窗口内还可以发送的数据,P1-P3的部分是滑动窗口的大小,P3之后就是不允许发送的数据

在这里插入图片描述

这里的发送方发送数据和接收方接收数据的过程与之前的选择重传(SR)协议相同,

尤其注意:接收方在收到未按序到达的数据时,会给按序收到的数据的最高序号给予确认(即ACK=31,即接收方发送31号数据的确认帧),如下图:

在这里插入图片描述

需要注意的几点:

  • 同一时刻,发送方的窗口和接收方的窗口不一定一样大
  • 对于未按序到达的数据,TCP协议中未明确说明如何处理,一般是先把未按序到达的数据缓存在接收方的缓存中,当收到了重复确认的报文段时(上图中是31号),再进行累计确认,发送ack=34即可
  • TCP是全双工通信,即通信双方各自都有发送窗口和接收窗口
  • TCP要求接收方必须有累计确认和捎带确认的功能

408真题:

在这里插入图片描述

在这里插入图片描述

5.8 TCP运输连接的管理

  • TCP连接管理就是指TCP连接的建立和释放都能正常进行

  • TCP是面向连接的协议(也是面向比特的协议),基于运输连接来传送报文

  • TCP运输连接有3个阶段:

    • 3报文握手建立TCP连接
    • 数据传送
    • 4报文挥手释放TCP连接

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yB0ffKlr-1616571949284)(C:\Users\86131\AppData\Roaming\Typora\typora-user-images\image-20210322093622765.png)]

5.8.1 TCP连接的建立

三次握手的具体过程:

  • 第一次握手:TCP主机主动打开,进入同步已发送状态,向被动打开的TCP服务器发送TCP连接请求报文段,其中的SYN=1,seq=x
  • 第二次握手:TCP服务器进入同步已接收状态,并向TCP主机回复一个针对TCP连接请求报文段的确认,其中SYN=1,ACK=1,ack=x+1(因为seq=x),seq=y
  • 第三次握手:主机收到TCP服务器发送的报文段后,开始进入连接状态,并向TCP服务器发送一个连接确认的确认报文段,其中SYN=1,ACK=1,ack=y+1,TCP主机接收到报文段后也进入了连接状态,两者此时就建立了连接,可以相互发送数据

举例如下:

在这里插入图片描述

上述三次握手能否变成两次握手?

答案是否定的,因为如果TCP客户先向一个TCP服务器发送一个连接请求报文,而这个报文又在一定传输过程中超时了,则TCP客户会发送另一个连接请求报文段,TCP服务器收到后建立了连接,并与TCP客户发送了连接确认报文,TCP客户收到该报文后与TCP服务器进行了连接,并传递数据,传完数据后连接关闭,而这个时候,TCP客户最开始发送的TCP连接报文段被TCP服务器检测到,TCP服务器开始建立连接,而向TCP客户发送连接确认,而此时的TCP客户处于连接关闭状态,无法建立连接,而此时的服务器就会一直建立连接等待TCP客户发送数据,造成了资源的浪费

在这里插入图片描述

408真题:

在这里插入图片描述

4.8.2 TCP连接释放

四次握手的过程:

  • TCP客户在连接状态下主动发送TCP连接释放报文段,自己进入终止等待1状态,报文段中FIN=1,ACK=1,seq=v,ack=u(连接建立时的最后一个确认帧),使得TCP服务器进入关闭等待状态
  • TCP服务器向TCP客户发送一个TCP普通确认的报文段,其中ACK=1,seq=u,ack=v+1,TCP服务器进入关闭等待的状态,TCP客户收到报文端后进入终止等待2状态
  • 有可能还需要进行数据传输,传输完数据后,发送一个连接释放报文段,FIN=1,ACK=1,seq=w,ack=u+1,进入最后确认状态
  • TCP客户收到连接释放报文段后,发送一个TCP普通确认,即ACK=1,ack=w+1,seq=u+1,进入时间等待的状态,再过2个最长报文段寿命MSL(maxmium segment lifetime)后,进入关闭状态,而TCP服务器收到这个确认帧后就进入关闭状态

在这里插入图片描述

保活计时器:即当TCP客户在连接的过程中出现了故障,导致无法正常收到TCP服务器的信息,也就无法发送对TCP服务器的确认,这时就会很浪费TCP服务器的资源,所以在TCP服务器中设置一个保活计时器(计时2小时),当保活计时器时间到了之后,TCP服务器向TCP客户发送一个探测报文段,之后每隔75s发送1次,连续发送10次,若再无相应,则关闭连接

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HVBB0ZeH-1616571949290)(C:\Users\86131\AppData\Roaming\Typora\typora-user-images\image-20210322102649458.png)]

5.9 TCP 报文的首部格式

在这里插入图片描述

上图中:

源端口号和目的端口号各占16字节,用来标识发送该TCP报文段的应用进程的端口和要接收该应用进程的端口号

序号(seq):用来标识数据载荷的第一位序号是多少

确认号(ack):假设ack=101,表示前100号的数据都接收成功,现在需要接收第101号数据

数据偏移:占4个比特,(以4字节为单位)用来标识TCP首部的长度,例如(0101)2就表示5,而数据偏移的单位是4字节,所以,表示TCP首部长度为20字节

保留字段:保留为今后使用,置为0

URG:(urgement)紧急标志位,和下面的紧急指针联合在一起使用:

当URG=1时,看下面的紧急指针会指出此TCP报文段中有多少个紧急数据,而紧急数据之后是普通数据,接收方收到URG=1的报文段,会将其中的数据直接上交给应用进程

ACK:确认字段,表示收到了发送方的TCP数据报

PSH:(push)推送标志位:接收方收到PSH=1的报文段,就将TCP收到该标志位为1的报文段尽快上交给进程,而不用等到TCP报文填满后再上传

SYN:(synchronize)同步标志位:同步标志位为1时,说明要建立TCP连接

FIN:(final)结束标志位:FIN=1时,说明要释放TCP连接

RST(reset):RST=1时,表示要重新建立TCP连接

窗口字段:占16比特,表示发送本报文段的一方的接收窗口

校验和字段:占16比特,检查范围包括TCP报文段的首部和数据载荷两部分,计算校验和时,向UDP协议一样,要加上12位的伪首部

在这里插入图片描述

UDP首部:

在这里插入图片描述

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值