- 本篇文章是对 湖科大计算机网络微课堂 中运输层的笔记总结,希望对大家有所帮助。
5.1运输层概述
在计算机网络中进行通信的真正实体是通信主机中的进程。
运输层的任务是为运行在不同主机的进程之间提供直接的通信服务,运输层协议又称为端到端协议。
根据应用需求不同,运输层为应用层提供两种不同的运输协议,即 面向连接的TCP 和 无连接的UDP。
5.2运输层端口号、复用与分用的概念
1.端口号
运行在计算机的进程使用 进程标识符PID 来标志的。
然而,因特网上的计算机并不是使用统一的操作系统,不同的操作系统(windows,linux,Mac OS)使用不同格式的进程标识符。
为了使运行不同操作系统的计算机的应用进程之间能够进行通信,就必须使用统一的方法对TCP/IP体系中的应用进程进行标识。
TCP/IP体系的运输层使用端口号来区分不同的应用进程。
- 端口号使用16比特表示,取值范围为0-65535,分为以下三种:
- 熟知端口号:0-1023,IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议,如:FTP使用21和20号端口,HTTP使用80号端口,DNS使用53端口号。
- 登记端口号:1024-49151,为没有熟知端口号的应用进程使用。使用这类端口号必须在IANA按照规定的手续登记,以防止重复,例如微软远程桌面RDP使用的端口号为3389。
- 短暂端口号:49152-65535,留给客户进程暂时使用。通信结束后,这个端口号可供其他客户进程使用。
- 端口号只具有本地意义,即端口号只是为了标识本计算机中各进程,不同计算机可能有相同的端口号,但是并没有任何关系。
2.发送方的复用和接收方的分用
3.应用层常用协议使用的端口号
TCP/IP体系的 应用层常用协议 所使用的 运输层熟知端口号 :
4.举例说明端口号的作用
应用场景:用户通过输入网址查询网页内容。
当用户使用浏览器访问Web服务器时,用户PC中的DNS客户端进程会发送一个DNS查询请求报文,其内容为 “域名为www.porttest.com"的IP地址是什么” 。
DNS查询请求报文 被 运输层的UDP协议封装成UDP用户数据报,数据报首部的源端口字段值在短暂端口号49151-65535中挑选一个未被使用过的,目的端口字段的值设置为53,这是DNS服务器端进程所使用的熟知端口号。
然后封装成IP数据报发送。
- DNS服务器收到IP数据报后,从中解封出UDP用户数据报,数据报中目的端口号为53表明应将UDP用户数据报的数据载荷部分(也就是DNS查询请求报文)上交给DNS服务器端进程。
- DNS服务器端进程 解析 DNS查询请求报文的内容,然后查找对应的IP地址,并发送DNS查询响应报文,其内容为*“域名为www.porttest.com"的IP地址是192.168.0.3”*。
- DNS响应报文被封装成UDP用户数据报,数据报首部的源端口号为53,目的端口号为49152。
- 然后封装成IP数据报进行发送。
- 用户PC收到IP数据报后,进行解封出UDP用户数据报,数据报中的目的端口号为49152表明应将UDP用户数据报的数据载荷部分(也就是DNS响应报文)上交给DNS客户端进程。
- DNS客户端进程 解析 DNS响应报文中的内容,知道之前请求的域名对应的IP地址。
- 现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文了。
- HTTP请求报文内容为*“首页内容是什么?”*,接着被运输层的TCP协议封装成TCP报文段,其首部的源端口值在短暂端口号49151-65535中挑选一个未被使用过的,目的端口号为80,这是HTTP服务器端进程所使用的熟知端口号。
- 然后封装成IP数据报进行发送。
剩余的流程和上面类似,于是这里不再赘述啦。
5.3 UDP和TCP的对比
UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议。
以下是从几个方面对两者的比较:
- UDP可以随时发送数据,也就是无连接的。
- TCP发送数据之前需要先建立连接,也就是面向连接的。
- 在局域网中,UDP可以发送单播,多播,广播数据
- 而TCP只能发送单播数据。
对应用报文的处理方式不同:
- UDP对应用层的应用层报文直接添加一个首部,然后直接进行发送。接收方接收数据报后去掉首部,上交给上层应用层。
- TCP把应用层交付下来的数据块仅仅看作是一连串的,无结构的字节流,并将它们进行编号,存储在自己的发送缓存中,TCP根据发送策略,从发送缓存中提取一定数量的字节,构建成TCP报文段进行发送。接收方一方面从所接受的TCP报文段中取出数据载荷部分并存储在接收缓存中,一方面将接收缓存的一些字节交付给应用进程。
- UDP协议向其上层提供的是无连接不可靠传输服务,数据报发生误码仅仅丢弃,并不会采取其他措施。
- TCP协议向其上层提供的是面向连接的可靠服务。
- UDP由于不提供可靠传输服务,首部比较简单。
- TCP由于要实现可靠传输,流量控制,拥塞控制等服务,其首部比较复杂。
小结:
![image-20210614224841012](https://gitee.com/oymn/img_upload/raw/master/img/20210614224841.png)
5.4 TCP的流量控制
流量控制:让发送方不要发送得太快,要让接收方来得及接受。
TCP协议中使用 滑动窗口 机制来实现流量控制。
举例说明:
假设主机A发送的每个TCP报文段可携带100字节数据。
在主机A和主机B建立TCP连接时,B告诉A:我的接收窗口为400,因此主机A将自己的发送窗口也设置为400。
主机A将发送窗口中1到100的数据封装成一个报文段发送出去,此时发送窗口还有300字节可以发送。
接着主机A将发送窗口中101到200的数据封装成一个TCP报文段发送出去,此时发送窗口还有200字节可以发送。
接着主机A将发送窗口中201到300的数据封装成TCP报文段发送出去,但该报文段在传输过程中丢失了,此时发送窗口还有100字节可以发送。
主机B对200之前的数据进行了确认,并在该确认中将窗口值调整为300(B根据自身情况进行调整的),对主机A进行第一次流量控制。
- 主机A收到该确认后,将发送窗口向前滑动,使那些已经发送并且收到确认的数据移出发送窗口,同时将自己的发送窗口调整为300。
- 主机A现在可将发送缓存中1到200的字节删除了,因为已经收到主机B对它们的累积确认了。
- 主机A将301到400的字节封装成报文段发送出去,发送窗口此时还有100个字节可以发送。
- 接着主机A将400到500的字节封装成TCP报文段发送出去,此时发送窗口没有数据可以发送了。
- 发送窗口内201到300这100个字节的重传计时器超时了,主机A重新封装并发送。
- 主机B对201到500的字节数据进行确认,并在累积确认中将窗口字段值改为100,这是主机B对主机A进行的第二次流量控制。
接下来的过程类似,这里仅通过图片描述,不再进行文字赘述。详细过程可看这个视频
注意:这里可能出现死锁,解决办法:启动持续计时器,超时后发送零窗口探测报文。
TCP为每一个连接设有一个持续计时器,只要一方收到对方的零窗口通知,就启动持续计时器,当计时器超时,就发送一个零窗口探测报文,仅携带一字节的数据, 接收方接受后给出自己的窗口值,如果还是零,持续计时器重新启动。
零窗口探测报文也可能丢失,解决办法:再来个重传计时器,超时重传。
练习题:
5.5 TCP的拥塞控制
1.基本概念
拥塞:对网络中某一资源的需求超过了该资源所能提供的,网络资源就要变坏。
网络资源:链路容量(即带宽),交换节点中的缓存和处理机等。
出现拥塞而不进行控制,整个网络的吞吐量将会随着输入负荷的增大而下降。
理想的拥塞控制、实际的拥塞控制,无拥塞控制的曲线如下图所示:
![image-20210616215832586](https://gitee.com/oymn/img_upload/raw/master/img/20210616215832.png)
2.拥塞控制算法
TCP的四种拥塞控制算法:
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
为了更好地介绍这几种算法,假定以下条件:
- 数据是单方向发送的,另一方向仅发送确认
- 接收方总是有足够大的缓存空间,因而发送方发送窗口的大小由网络的拥塞程度来决定。
- 以最大报文段的个数为讨论问题的单位,而不是以字节为单位。
真正的发送窗口值 = Min (接收方窗口值,拥塞窗口值)
(1)拥塞窗口和慢开始门限
发送方维护一个叫做拥塞窗口cwnd的状态变量,其值取决于网络的拥塞程度,并且动态变化。
- 拥塞窗口cwnd的维护原则:网络没有出现拥塞,拥塞窗口就大一些,网络出现拥塞,拥塞窗口就减少一些。
- 判断出现网络拥塞的依据:没有按时收到应当到达的确认报文(即发生了超时重传)
前面我们假定条件接收方有足够的缓存可以接受,所以这里发送方将拥塞窗口作为发送窗口swnd,即swnd=cwnd。
发送方还要维护一个慢开始门限ssthresh的状态变量:
- 当cwnd < ssthresh 时,使用慢开始算法。
- 当cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
- 当cwnd = ssthresh 时,即可使用慢开始算法,也可使用拥塞避免算法。
(2)慢开始算法
慢开始算法:每经过一个传输轮次,拥塞窗口就加倍。
传输轮次:发送方发送完报文段并且接收方进行确认,也就是一个往返时间。
下面通过举例来进行介绍:
在刚建立连接时,拥塞窗口值被设置为1,本例慢开始门限值为16。
由于拥塞窗口值为1,发送方只能发送一个报文段。
![image-20210616223426704](https://gitee.com/oymn/img_upload/raw/master/img/20210616223426.png)
发送方收到确认报文段后,将拥塞窗口值加1增大到2。此时发送方可以发送两个报文段。
![image-20210616223610626](https://gitee.com/oymn/img_upload/raw/master/img/20210616223610.png)
发送方收到确认报文段后,将拥塞窗口值加2增大到4。此时发送方可以发送四个报文段。
![image-20210616223746614](https://gitee.com/oymn/img_upload/raw/master/img/20210616223746.png)
发送方收到确认报文段后,将拥塞窗口值加4增大到8。此时发送方可以发送8个报文段。
![image-20210616223854750](https://gitee.com/oymn/img_upload/raw/master/img/20210616223854.png)
发送方收到确认报文段后,将拥塞窗口值加8增大到16,此时拥塞窗口值等于慢开始门限值,之后,改用拥塞控制算法,也就是拥塞窗口值只能线性加1。
![image-20210616224147489](https://gitee.com/oymn/img_upload/raw/master/img/20210616224147.png)
发送方收到确认报文段后,将拥塞窗口值加1增大到17。此时发送方可以发送17个报文段。
![image-20210616224258285](https://gitee.com/oymn/img_upload/raw/master/img/20210616224258.png)
随着传输轮次的增加,拥塞窗口值每轮次都线性加1。假设现在拥塞窗口值为24,发送方可以发送24个报文段,但是在传输过程中丢失了几个,这会导致发送方对这些报文段的超时重传,发送方以此判断网络很可能出现了拥塞,需要进行以下工作:
- 将慢开始门限值更新为发生拥塞时拥塞窗口的一半
- 将拥塞窗口值减少为1,并重新执行慢开始算法
![image-20210616224709936](https://gitee.com/oymn/img_upload/raw/master/img/20210616224710.png)
然后继续循环上述过程
![image-20210616224814850](https://gitee.com/oymn/img_upload/raw/master/img/20210616224815.png)
(3)拥塞避免算法
拥塞避免算法:每经过一个传输轮次,拥塞窗口 cwnd = cwnd + 1。
(4)快重传
有时候,个别报文段的丢失,并不是因为网络的拥塞,可能是目的地址不存在或者其他情况。
但这将会导致超时重传,发送方误认为是网络发生了拥塞,发送方会将拥塞窗口值设置为1,并错误地启动慢开始算法,降低了传输效率。
于是出现了快重传算法和快恢复算法。
采用快重传能使发送方尽早知道发生了个别报文段的丢失,并尽快进行重传,而不是等超时重传计时器超时再重传,这样发送方就不会误认为是网络拥塞了。
实现快重传:
- 要求接收方不要等到自己发送数据时才捎带确认,而是要立即发送确认。
- 即使收到了失序的报文段也要立即对已收到报文段的重复确认。
- 发送方一旦收到3个连续的重复确认后,就将相应的报文段立即重传,而不是等该报文段的超时重传计时器超时再重传。
举例说明:
(5)快恢复算法
发送方一旦收到3个重复确认,就知道现在只是丢失了个别报文段,于是不启动慢开始算法,而执行快恢复算法。
发送方将慢开始门限值和拥塞窗口值调整为当前窗口的一半,开始执行拥塞避免算法。
也有的快恢复是把拥塞窗口值再增大一些,即等于新的慢开始门限值+3。理由是:既然发送方已经收到了3个重复确认,说明有3个报文段离开网络到达接收方了,那么就不会消耗网络资源了,所以可以适当把拥塞窗口值扩大些。
举例: