计算机网络复习-第五章运输层

• 运输层协议概述

• 进程之间的通信

  • 从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层
  • 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层 ，而网络核心部分中的路由器在转发分组时都只用到下三层的功能

• 运输层的作用

  • 为相互通信的应用进程提供了逻辑通信

    • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JPt0Srne-1658979327241)(https://api2.mubu.com/v3/document_image/d49c7c24-1b2f-4c4e-a4e8-3e2ca0edf7c0-16574888.jpg)]

    • “逻辑通信”的意思是“好像是这样通信，但事实上并非真的这样通信”。

    • 从IP层来说，通信的两端是两台主机。但这种说法还不够清楚。严格地讲，两台主机进行通信就是两台主机中地应用进程互相通信

    • 从运输层地角度看，通信地真正端点并不是主机而是主机中地进程。也就是说，端到端地通信是应用进程之间的通信。

  • 这表明运输层有一个很重要的功能：复用和分用

    

  • 根据应用程序的不同需求，运输层需要两种不同运输协议

    • 面向连接TCP
      • 尽管下面的网络是不可靠的，但这种逻辑通信信道就相当于一条全双工的可靠信道
    • 无连接UDP
      • 不可靠信道

• 运输层两个主要协议

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

  • 用户数据报协议UDP

    DNS,TFTP,RIP,DHCP,SNMP,NFS,IGMP……

    • UDP传送的数据单位协议是UDP报文或用户数据报
    • 提供无连接服务
    • 在传送数据之前不需要先建立连接
    • 对方的运输层在收到UDP报文后不需要给出任何确认
    • 虽然UDP不提供可靠交付但某些情况下UDP比较有效

  • 传输控制协议TCP

    SMTP,TELNET,HTTP,FTP……

    • TCP传送的数据单位协议是TCP报文段
    • 提供面向连接服务
    • TCP不提供广播或多播服务
    • 由于TCP提供可靠的、面向连接的运输服务，要去询问反馈确认，因此不可避免地增加很多开销。这不仅使得协议数据单元地首部增大很多还要占用很多处理机资源。

• 运输层的端口

  • 背景

    • 运行在计算机中的进程是用进程标识符来标志的。但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。因为在互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须使用统一的办法对TCP/IP体系的应用进程进行标志。

  • 端口概念

    

    • 硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。这里说的是软件端口
    • 端口用一个16位的端口号进行标志
    • 端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程
    • 不同计算机的相同端口号是没有联系的

  • 常用熟知端口

    

• 用户数据报协议UDP

  • UDP概述

    • UDP只在IP数据报服务之上增加了很少一点的功能

      • 复用和分用的功能
      • 差错检测的功能

    • 主要特点

      • 无连接的

      • 使用尽最大努力交付

      • 面向报文的

        

        • 对应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界。UDP一次性交付一个完整的报文。
        • 如果应用层给的数据很大，UDP也不会拆分，但是UDP能发不代表网络层能发，网络层如果上层的数据太大了，则会进行分片，回头交给上层一定是拼好了交给上层。

      • 没有拥塞控制

        • 因此网络出现拥塞不会使得源主机的发送速率降低。这对某些实时应用是很重要的，很适合多媒体通信的要求。

      • UDP支持一对一、一对多、多对一、多对多的交互通信

      • UDP首部开销小

  • UDP首部格式

    

  • 在计算校验和时，临时把伪首部和UDP用户数据报连接在一起。伪首部仅仅是为了计算校验和，在传递给下层时伪首部丢弃。

• 传输控制协议TCP概述

  • TCP最重要的特点

    • 面向连接

    • 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的

    • 可靠交付服务（不重复不丢失不失序）

    • 全双工通信

    • 面向字节流

      

      • TCP中的“流”(stream)指的是流入或流出进程的字节序列。
      • 面向字节流的含义是虽然应用程序和TCP的交互是一次一个数据块,但TCP把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
      • TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。例如：校车从A地到B地，我不管校车几辆每辆车有多少学生，但我学生到达的人数和顺序是一样的。
      • 不一定序号后的就后到，序号先得先到，因为真正发送是靠下层IP ，但IP是不可靠交付。所以如果顺序打乱了，那我们就在接受缓存里等待，排好顺序再往上传递。重要的是没有漏到多到，而是全都到了。
      • TCP不关心应用进程一次把多长得报文发送到TCP缓存。TCP对连续的字节流进行分段，形成了TCP报文段。
        
      • TCP连接是一条虚连接而不是一条真正的物理连接。
      • TCP根据对方给出的窗口值和当前网络拥塞程度来决定一个报文段应当包含多少个字节。UDP发送的报文长度是应用进程给出的。TCP可把太长的数据块划分短一些再发送。TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

  • TCP连接

    • TCP把连接作为最基本的抽象，每一条TCP连接有两个端点。TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议端口，TCP连接的端点叫做套接字。
    • 端口号拼接到IP地址即构成了套接字
      

• 可靠传输工作原理

  • 理想的传输条件特点的两个特点

    然而实际网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时即时告诉发送方适当降低发送数据的速度。

    • 传输信道不产生差错
    • 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据

  • 停止等待协议

    使用确认和重传机制我们就可以在不可靠的传输网络上实现可靠通信，可靠传输协议常常称为自动重传请求ARQ，意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组

    • 概念

      • 停止等待就是每发送完一个分组就停止发送等待对方确认。在收到确认后再发送下一个分组。
      • 全双工通信的双方既是发送方也是接收方

    • 理想状态无差错情况

      • A发送分组M1，发完就暂停发送,等待B的确认(ACK)。B收到了M1向A发送ACK。A在收到了对M1的确认后，就再发送下一个分组M2。

    • 不理想三种情况

      • 请注意

        • 在发送完一个分组后，必须暂时保留已发送的分组的副本以备重发
        • 分组和确认分组都必须进行编号
        • 超市计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

      • 发送分组掉了or接受M1时检测出了差错丢弃了M1【这两种情况B都不会发送任何信息】

        

        • 解决办法：超时重传（发送方为每一个已发送的分组都设置了一个超时计时器，若超时没收到接收方的确认则重新发送）

      • 确认分组掉了

        

      • 都没掉但是堵车绕远路了

        

    • 优点

      • 简单

    • 缺点

      • 信道利用率太低
        
      • 解决
        • 连续ARQ协议

  • 连续ARQ协议

    • 概念
      • 通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不到确认,就说明通信线路太差,不能进行通信。使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ。意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
    • 发送方（滑动窗口协议）
      • 发送方维持的发送窗口，它的意义是：位于发送窗口内的分组都可以连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
      • 连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置（收到确认才移动窗口，否则不动）
      • 工作原理
        
    • 接收方（累计确认）
      • 接收方一般采用累计确认的方式，即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示到这个分组为止的所有分组都已正确收到了
      • 优点
        • 容易实现，即使确认丢失也不必重传
      • 缺点
        • 不能向发送方反映出接收方已经正确收到的所有分组的信息
    • Go-back-N回退N
      • 如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做回退N，表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响。
    • 选择确认SACK
      • 背景
        • 若收到的报文段无差错,只是未按序号,中间还缺少一些序号的数据,那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据?
      • 工作原理
        
    • TCP可靠通信的具体实现
      • TCP连接的每一端都必须设有两个窗口（一个发送窗口和一个接收窗口）
      • TCP可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段。
      • TCP两端的四个窗口经常处于动态变化之中
      • TCP连接的往返时间RTT也不是固定不变的。需要使用特点的算法估算较为合理的重传时间。

• TCP报文段的首部格式

  

  • 首部概念
    • TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段
    • 一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用
    • TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项。因此，TCP首部的最小长度是20字节
  • 首部解析
    • 源端口目的端口（2字节）
      • 只和本地主机有关
    • 序号（4字节）
      • TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
    • 确认号
      • 是期望收到对方的下一个报文段的数据的第一个字节的序号
      • 在同一个报头中，序号和确认号是没有任何关系的。在不同的报头中不好讲。
    • 数据偏移
      • TCP报文段的数据距离TCP报文段的起始处有多远。
    • 标志位
      • 【紧急URG】 为1时表明紧急指针字段有效，表示有紧急数据应当尽快传送
      • 【确认ACK】 为1表示确认号字段才有效。当K=0时确认号无效
      • 【推送PSH】 为1就尽快交付接收应用进程而不再等到整个缓存都填满了后再向上交付
      • 【复位RST】为1表明连接出现差错，如主机崩溃或其他原因，必须释放连接然后再重新建立运输连接
      • 【同步SYN】为2表示这是一个连接请求
      • 【终止FIN】为1表明此报文的发送端数据已经发送完毕，要求释放运输连接
    • 窗口
      • 用来让对方设置发送窗口的依据，单位为字节
    • 校验和
      • 检验和字段检验的范围包括首部和数据两部分，计算检验和时，要在TCP报文段前面加上12字节的IP伪首部

• TCP可靠传输的实现

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

    

    • 这些发送窗口和接收窗口会随着网络情况而随时调整。根据B给出的窗口值，A构造出自己的发送窗口发送窗口表示:在没有收到B的确认的情况下,A可以连续把窗口内的数据都发送出去。发送窗口里面的序号表示允许发送的序号。显然,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。
      
    • 发送缓存与接收缓存的作用
      • 发送缓存用来暂时存放
        • 发送应用程序传送给发送方TCP准备发送的数据
        • TCP已发送出但尚未收到确认的数据
      • 接收缓存用来暂时存放
        • 按需到达、但尚未被接收应用程序读取的数据
        • 不按序到达的数据
    • 强调三点
      • A的发送窗口不总是和B的接收窗口一样大（因为有一定的时间滞后）。
      • TCP标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
      • TCP要求接收方必须有累积确认的功能，这样可以减少传输开销
    • 接收方发送确认
      • 接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。
      • 请注意两点
        • 收方不应过分推迟发送确认,否则会导致发送方不必要的重传，这反而浪费了网络的资源。
        • 捎带确认实际上并不经常发生因为大多数应用程序很少同时在两个方向上发送数据。

  • 超时重传时间的选择

    • 背景
      • TCP每发送一个报文段，就对这个报文段设置一次计时器，只要计时器设置的重传使劲按到但还没有收到确认就要重传这一报文段
      • 如果把超时重传时间设置得太短,就会引起很多报文段的不必要的重传,使网络负荷增大。
      • 但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。
      • TCP采用了一种自适应算法,它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。
    • 加权平均往返时间RTT和超时重传时间RTO
      
      

• TCP流量控制

  • 概念
  • 让发送方的发送速率不要太快，既要让接收方来得及接收也不要使网络发送拥塞。利用滑动窗口机制可以很方便的再TCP连接上实现流量控制
  • 利用可变窗口进行流量控制举例
    
  • 死锁
  • 向A发送了零窗口的报文段后不久,B的接收缓存又有了一些存储空间。于是B向A发送了rwnd =400的报文段。
  • 但这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据（B只有收到A的报文才能回复确认报文）。
  • 如果没有其他措施,这种互相等待的死锁局面将一直延续下去
  • 解决方法
    • TCP为每一个连接设有一个持续计时器（rwnd=0后过了持续计时器A去试探一下）
    • 若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据）,而对方就在确认这个探测报文段时给出了现在的窗口值。
    • 只要TCP连接的一方收到对方的零窗口通知，就启动该持续计时器。
    • 若窗口不是零，则死锁的僵局就可以打破了。
    • 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
  • 发送方糊涂窗口综合征（试探容易产生这个问题）
    • 发送方TCP每次接收到一字节的数据后就发送。
    • 这样,发送一个字节需要形成41字节长的IP数据报。若接收方确认,并回送这一字节就需传送总长度为162字节共4个报文段。效率很低。
    • 解决方法
      • 使用Nagle算法。
  • 接收方糊涂窗口综合征
    • 当接收方的TCP缓冲区已满,接收方会向发送方发送窗口大小为0的报文。
    • 若此时接收方的应用进程以交互方式每次只读取一个字节,于是接收方又发送窗口大小为一个字节的更新报文，发送方应邀发送一个字节的数据（发送的IP数据报是41字节长）,于是接收窗口又满了，如此循环往复。
    • 解决方法
      • 让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段,或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方发出确认报文，并向发送方通知当前的窗口大小。
  • 必须考虑传输效率
    • 可以用不同的机制来控制TCP报文段的发送时机
      • 第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。
      • 第二种机制是由发送方的应用进程指明要求发送报文段，即TCP支持的推送(push)操作。
      • 第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。

• TCP拥塞控制

  • 拥塞控制的一般原理

    • 若对网络中某资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。

  • TCP拥塞控制方法

    • 增加资源（加大带宽或者路由器性能提升等）

      • 增加资源不能解决拥塞。
      • 这是因为网络拥塞是一个非常复杂的问题。简单地采用上述做法，在许多情况下，不但不能解决拥塞问题，而且还可能使网络的性能更坏。
        
      • 网络拥塞往往是由许多因素引起的。例如:
        • 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞
        • 提高处理机处理的速率会会将瓶颈转移到其他地方

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

      • 拥塞控制就是防止过多的数据注入到网络中,使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
      • 流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端)
      • 拥塞控制和流量控制之所以常常被弄混，是因为某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率这点又和量量控制是很相似的。

    • 拥塞控制作用

      

      • 实践证明,拥塞控制是很难设计的,因为它是一个动态的（而不是静态的）问题。
      • 当前网络正朝着高速化的方向发展,这很容易出现缓存不够大而造成分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。
      • 在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。这点应特别引起重视。

    • 检测网络拥塞的指标(这些指标的上升都标志拥塞的增长 )

      • 由于缺少缓存空间而被丢弃的分组的百分数;
      • 平均队列长度
      • 超时重传的分组数
      • 平均分组时延
      • 分组时延的标准差，等等。

    • TCP拥塞控制方法

      • 开环控制

        • 设计网络时事先将有关发生拥塞的因素考虑周到，力求在网络工作时不产生拥塞。但一旦整个系统运行起来，就不再中途进行改正。

      • 闭环控制

        • 措施
          • 检测网络系统以便检测到拥塞在何时何处发生
          • 把拥塞发生的信息传送到可采取行动的地方
          • 调整网络系统的运行以解决出现的问题

      • TCP采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。

      • TCP发送方维持一个拥塞窗口CWND

        • 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化
        • 发送端利用拥塞窗口根据网络地拥塞情况调整发送地数据量
        • 所以。发送窗口大小不仅取决于接收方公告地接收窗口，还取决于网络地拥塞状况，所以真正地发送窗口值为min（公告窗口值，拥塞窗口值）

      • 拥塞的判断

        • 重传定时器超时【严重】
        • 收到三个相同的ACK【轻微】
          

      • TCP拥塞控制算法（自动）

        • 慢开始

          

          • 每经过一个传输轮次，拥塞窗口cwnd就加倍。传输轮次其实就是RTT，其强调把拥塞窗口cwnd所允许发送的报文段都连续发送出去并收到了对已发送的最后一个字节的确认。
          • cwnd=4代表这时的往返时间RTT是发送方连续发送四个报文段并收到这四个报文段的确认总共经历的时间。

        • 拥塞避免

          

          • 控制发送方发送窗口的大小，控制拥塞窗口大小实际上就是控制发送窗口大小。拥塞窗口小就是发送窗口小，网络负担轻就越不容易堵车，堵住的车就会慢慢疏通，状况就缓解了。
          • 拥塞避免并非指能够完全避免拥塞，而是尽量让拥塞来的越晚越好。越晚，我们经过的传输轮次就多，就在传输轮次能发出的数据就越多，网络性能就更高。

        • 快重传

          • 发送方一连收到3个重复确认，就知道接收方确实没有收到报文，因而当即立即进行重传

        • 快恢复

          • 发送方知道现在只是丢失了个别报文段，于是不启动慢开始而是执行快恢复算法，调整门限值。

  • 主动队列管理AQM

    • 背景

      • 网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略

    • 先进先出处理规则

    • 路由器的队列通常都是按照“先进先出”FIFO的规则处理到来的分组。

    • 当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。这就叫做尾部丢弃策略

    • 路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使TCP进入拥塞控制的慢开始的状态。结果使TCP连接的发送方突然把数据的发送速率降低到很小的数值

    • 随机早期检测RED

      

      • 为什么以概率p丢弃而不是路由器一拥堵就全丢弃
        • 因为要错峰到达而不是丢弃全部后导致大量数据重传又一窝蜂到达

• TCP运输连接管理

  • TCP连接建立

    • 运输连接的三个阶段

      • 连接建立
      • 数据传送（上述）
      • 连接释放

    • TCP连接建立过程中要解决的三个问题

      • 要使每一方能够确知对方的存在
      • 要允许双方协商一些参数
      • 能够对运输实体资源进行分配

    • 客户服务器方式

      • TCP连接的建立采用客户服务器方式，主动发起连接建立的应用叫客户，被动等待连接建立的应用进程叫服务器

    • 三次握手

      

      客户服务器之间交换三个TCP报文段，主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误

      • 为什么要三次握手
        • 第一次一来一回是确认A发B能收，第二次一来一回是代表B发A能收。双方都能发能收才能表示连接建立。

  • TCP连接释放

    • 四次握手

      

      • 2MSL比超时时间更长。
      • 为什么一定要等到2MSL时间呢？
        • 第一，为了保证A发送的最后一个ACK报文段能够到达B。
        • 第二，防止“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种连接请求报文端。

    • 保活计时器

      • 客户主动与服务器建立TCP连接，但是客户端主机突然出现故障。这样服务器以后不能再收到客户发来的数据。因此，应当有措施使得服务器不要再白白等待下去。
      • 服务器每收到一次客户的数据就重新设置保活计时器，通常两小时。若两小时没收到客户数据服务器就发送一个探测报文段，以后没隔75秒钟发送一次，若一连发送10个探测报文段后仍无客户的响应，则服务器认为客户端出了故障，接着关闭连接。

  • TCP有限状态机

    
    状态个数是有限个