课件：课程包列表 (51zhy.cn)

目录

运输层协议概述

用户报协议UDP

传输控制协议TCP概述

可靠传输的工作原理

TCP可靠传输的实现

TCP的流量控制

TCP的拥塞控制

TCP的运输连接管理

运输层协议概述

• 进程之间的通信

  • 运输层的位置——只有位于网络边缘部分的主机的协议栈才有运输层，而在网络核心部分中的路由器在转发分组时都只用到下三层的功能。

  • 运输层的作用：之前的协议包括从网络层往下，的工作都是负责完成两台主机之间的通信。但是在计算机实际运行过程中，主机可能会同时运行多个应用程序（比如，你会在打开浏览器的同时，也打开了微信），这就会产生了多个不同的进程。我们说的“主机A与主机B进行通信”实际上是指“运行在主机A上的某个程序和运行在主机B上的另一个程序进行通信”。而运输层负责完成的就是两台主机中应用进程的相互通信。

  • 在举个例子。在过去用写信的年代，一村人写信以后，会统一交给邮递员送信；然后经过一系列匀速，送到另一个村的邮递员里。然后由这个邮递员再把这些信分别送到村里不同人的手里。信在运送的过程，就是网络层及以下协议层在做的事，而邮递员收集信件以及分发信件的工作，就是运输层在做的工作

  • 基于端口的复用和分用功能

    • 通过看图可以知道，复用就是把多个进程的信息合并成一个报文段；分用就是在接收端把一个报文段按照进程分开，送往相对应的进程

• 运输层的两个主要协议（这里只略微的讲一下基本概念，具体内容在后面讨论）

  • 基本概念：

    • 两个对等的运输实体在通信时传送的数据单位叫做：运输协议数据单元

    • TCP传送的数据单位——TCP报文段

    • UDP传送的数据单位——UDP报文或用户数据报

• 运输层的端口

  • 问题的提出与解决：由于进程的创建和撤销是动态的，发送发几乎无法识别其他机器上的进程。 解决方案：在发送信息时，我们给每个进程分配一个端口号，用端口号来标识这个进程。需要注意的是，端口号只有本地意义，只是为了表示本计算机应用层中的各进程。在互联网中，不同计算机的相同端口号是没有联系的。

  • 由此可知，两个计算机的进程要相互通信，不仅需要知道对方的IP地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）

  • 两大类端口

    • 服务器端使用的端口号端口

    • 客户端使用的端口

用户报协议UDP

• UDP概述

  • UDP只在IP的数据服务工程之上增加了很少的功能：复用和分用功能；差错检测功能

  • UDP的主要特点

    • 

    • 

      • 发送发UDP对应用程序叫下来的报文，在添加首部后就向下交付IP层。UDP对交下来的报文，既不合并也不拆分，而是保留这些报文的边界。

      • 接收方UDP对IP层交上来的UDP用户数据，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完成的报文。

    • 

• UDP的首部格式

  • 

  • 关于检验和的计算

    • 

    • 

传输控制协议TCP概述

• TCP最主要的特点

  • TCP面向流的概念：TCP不关心应用程序一次把多长的报文发送到TCP换成，TCP会吧连续的字节流进行分段，形成TCP报文段然后进行发送。

  • 简单来说就是，TCP会把太长的数据块划分短一些再传送，也可等待积累足够多的字节后再构成报文段发送出去

• TCP的连接

  • 每一条TCP连接都有两个端点。这个端点叫做“套接字（socket）”。

  • 

  • 套接字可以这么理解，假设有信要邮寄的你代表应用层，在你门外等待的邮递员就是运输层或者说是TCP连接，那你们这件的这道门，就是套接字。通过套接字，进程把信息送出去给TCP形成报文

可靠传输的工作原理

• 首先，我们需要知道IP网络并不提供可靠的传输。所谓不可靠的传输，就是指当数据到达接受方是，如果接收方发现数据出错，它就只是丢弃数据，然后什么都不做。而可靠的传输，会要求发送方重传，知道得到无差错的数据。

• 停止-等待协议

  • • 1.停止-等待的基本示意图

    • 2.出现差错的分析（对于出现差错的分析，可以让我们的停等协议更佳完善）：

      • 问题一：出现差错

        • 问题：在接收方 B 会出现两种情况： 1.B 接收 M1 时检测出了差错，就丢弃 M1，其他 什么也不做（不通知 A 收到有差错的分组）。 2.M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。 在这两种情况下，B 都不会发送任何信息。 但A都必须重发分组，直到B正确接收为止，这样才能实现可靠通信。

        • 解决方法：超时重传 A 为每一个已发送的分组都设置了一个超时计时器。 A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。 若A在超时计时器规定时间内没有收到B的确认，就认为分组错误或丢失，就重发该分组。

        • 还有一点要注意的是，TCP连接的往返时间RTT不是固定不变的，需要使用特点的算法估算较为合理的重传时间。

        • 

      • 问题二：确认丢失（1）

        • 若分组正确到达B，但B回送的确认丢失或延迟了，A未收到B的确认，会超时重发。B 可能会收到重复的 M1 。B如何知道收到了重复的分组，需要丢弃呢？

        • 解决方法：编号 A为每一个发送的分组都进行编号。若B收到了编号相同的分组，则认为收到了重复分组，丢弃重复的分组，并回送确认。 B为发送的确认也进行编号，指示该确认是对哪一个分组的确认。 A根据确认及其编号，可以确定它是对哪一个分组的确认，避免重发发送。若为重复的确认，则将其丢弃。

      • 问题三：确认丢失（2）

        • 问题：若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。

        • 假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动： 第一，丢弃这个重复的分组 M1，不向上层交付。 第二，向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。

      • 问题四：确认迟到

        • 传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了。 A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。 B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组。

        • 

      • 注意：

        • 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发。

        • 分组和确认分组都必须进行编号。

        • 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

    • 信道利用率低：

      • 计算公式：

      • 当往返时间RTT远大于分组发送时间TD时，信道的利用率就会非常低。若出现重传，这对传送有用的数据信息来说，信道的利用率还要降低。

      • 解决思路——流水线传输（具体的内容在连续ARQ会讨论） 发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率。

• 连续ARQ协议

  • 工作原理：发送方一次可以发出多个分组。每次可以发送分组的数量有滑动窗口协议来进行控制。接收方采用累积确认的方式来发送确认信息。发送方每收到一个确认，就把发送窗口向前滑动。如果出现差错，就采用回退N的方式进行重传

    • 滑动窗口协议

      • TCP连接的每一端都设有窗口——一个发送窗口和一个接受窗口。位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。 发送发没收到一个确认，就把发送窗口向前滑动一个分组的位置。 发送窗口W的取值：1<W<2^(n-1);n为分配的给分组编号的比特数。

    • 累积确认

      • 接收方不必对收到的分组逐个发送确认信息，而是对按序到达的最后一个分组发送确认，这样就表示到这个分组为止，所有分组都已正确收到了。这就是累积确认

      • 确认丢失的情况下，就会触发超时重传，然后再得到一个确认。

    • 回退N

      • 如果发送发发送了前五个分组，而中间的第三个分组丢失了。这是接收方只能对前两个分组发出确认。发送发无法知道后面三个分组的下落，只好把后面的三个分组都在重传一个。这就叫“回退N”（Go-banck-N），标识需要再退回来重传已发送过的N个分组。

    • 

  • 工作流程

    • 

    • 

    • 

    • 

    • 

TCP报文段的首部格式（大概看一眼，用到了再回来查效率更高，记得更牢）

TCP可靠传输的实现

• 以字节为单位的滑动窗口

  • 工作过程

    • 通过下面几张图，我们可以明白滑动窗口的工作过程

    • 

    • 通过P1,P2,P3三个指针，我们可以确定窗口的位置。

    • 

    • 

    • 

  • 缓存

    • 发送缓存用来暂时存放： 发送应用程序传送给发送方 TCP 准备发送的数据；TCP 已发送出但尚未收到确认的数据。 注意：已经发送但还没被确认的字节，仍然存放在缓存中；一旦被确认同时活动窗口离开该序号，字节就被缓存清除

    • 接收缓存用来暂时存放： 按序到达的、但尚未被接收应用程序读取的数据；不按序到达的数据。

• 超时重传时间的选择

  • 问题的由来：由于IP数据报所选择的路由变化很大，所以运输层的往返时间RTT的方差也很大。这就导致超时重传时间确定的困难——太短，容易引起不必要的重传；太长，网络空闲时间增大，降低了传输效率。

  • 自适应算法

    • 

    • 

    • 需要考虑的问题：TCP 报文段 1 没有收到确认。重传（即报文段 2）后，收到了确认报文段 ACK。如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？

      • 

      • 

• 选择确认SACK

  • 问题的提出：若收到的报文段无差错，只是为按需到达，例如：1,2,4都收到了，但是没有收到3。能否设法只传送缺少的数据而不选择重传已经正确到达接受方的数据？——解决方案：使用SACK（选择确认）

  • 

TCP的流量控制

• 利用滑动窗口实现流量控制

  • 流量控制：让发送发的发送速率不要太快，既要让接收方来得及接收，也不要让网络发生拥塞

  • 流量控制通过接收方给rwnd报文段来限制发送发的发送窗口

  • 死锁

    • 如果B想给发送零窗口的报文段后，A就不能再发送数据了。过了一会，B缓存有空间了，就给A发送rwnd=400的报文段，但是报文段在传送过程中丢失了。那么就会出现这么一种情况： A在等待B发送的非零窗口的通知，B在等待A发送的数据。 这就是死锁的局面。

    • 解决方案：持续计时器 只要TCP连接的一方收到对方的零窗口通知，就启动该持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段，而对方就在确认这个报文段时给出现在的窗口值。 若窗口仍是零，收到报文段的一份就重置计时器； 若窗口不是零，则死锁的局面打破。

TCP的拥塞控制

• 基本概念

  • 拥塞：在某段时间，若对网络中某资源的需求超过该资源所能提供的可用部分，网络的性能就要变坏，这种现象称为拥塞

  • 

  • 拥塞控制与流量控制的区别

  • 开环控制与闭环控制

  • 

• TCP拥塞控制方法

  • 基本原理：

  • 原则：只要网络没有出现拥塞，拥塞窗口1就可以再增大一些，以便把更多分组发送出去；但只要网络出现拥塞或可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入网络中的分组数，以便环节网络出现的拥塞

  • 判断准则： 1.重传定时器超时； 2.收到三个重复的ACK（预示网络可能出现拥塞）

  • 拥塞控制算法

    • 慢开始

      • 使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd就加倍（“慢”只是指初始的窗口比较小）

      • 慢开始门限 ssthresh 的用法如下： 当 cwnd < ssthresh 时，使用慢开始算法。 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法

    • 拥塞避免算法

      • 每经过一个传输轮子，拥塞窗口就+1。目的是让拥塞窗口缓慢的增大，避免出现拥塞

    • 无论慢开始还是拥塞避免阶段，只要发送发判断网络出现拥塞（重传定时器超时），就把慢开始门限减小为当前窗口的一般，然后缩小窗口为1，最后执行慢开始算法。 这样做的目的是迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的事件把队列中积压的分组处理完毕。

    • 

    • 快重传

      • 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

    • 快恢复算法

      • 当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法： 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ； 新拥塞窗口 cwnd = 慢开始门限 ssthresh ； 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

    • 

• 主动队列管理AQM

  • （简要了解即可）

  • 问题的由来：若路由器对某些分组的处理时间特别长，当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。 更为严重的是，在网络中通常有很多的 TCP 连接，这些连接中的报文段通常是复用在网络层的 IP 数据报中传送的。 在这种情况下，若发生了路由器中的尾部丢弃，就可能会同时影响到很多条 TCP 连接，结果使这许多 TCP 连接在同一时间突然都进入到慢开始状态。这在 TCP 的术语中称为全局同步

    • 解决思路：1998 年提出了主动队列管理 AQM 所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。 AQM 可以有不同实现方法，其中曾流行多年的就是随机早期检测 RED

  • 随机早期检测RED

    • 

    • 

TCP的运输连接管理

• TCP连接的建立

  • TCP连接建立过程中要解决的三个问题： 1.要使每一方能够确知对方的存在。 2.要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。 3.能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

  • 运输连接的三个过程

    • 连接建立

      • TCP建立连接的过程叫做握手，由于握手需要再客户和服务器之间交换三个TCP报文段，所以称为三报文握手。下面演示连接建立过程

      • 

      • 

      • 

      • 

      • 

    • 数据传送

    • 连接释放

      • TCP连接释放的过程是四报文握手

      • 

      • 

      • 

      • 在确认报文段中ACK = 1，确认号 ack = w + 1，自己的序号 seq = u + 1

      • • 

      • 

• TCP的有限状态机

  • 这张图总结了TCP从连接建立到连接释放不同状态的转变合指令，通过阅读上面这样图，再加深一下对TCP连接建立与释放的理解。

  •