《计算机网络自顶向下方法》知识梳理——第三章：运输层

运输层：为进程之间提供逻辑通信

• 运输层：面向通信部分的最高层，用户功能中的最低层。
• 真正通信的实体是进程。

运输层功能：

• 为运行在不同主机上的应用进程之间提供了逻辑通信
• 复用（transport-layer multiplexing）：发送方不同的应用进程可以使用同一个运输层协议通信。
• 分用（demultiplexing）：接收方的运输层能够将其正确地送至不同的应用进程。
  运输层得到的数据报文并不直接交给应用进程，而是交付给相应的套接字

两个主要协议：

• 用户数据保协议UDP（User Datagram Protocol）：
  • UDP用户数据报。
  • 无连接。
• 传输控制协议TCP（Transmission Control Protocol）：
  • TCP报文段（segment）。
  • 面向连接。

TCP提供的服务：

• 面向连接服务
  • 客户端套接字和服务器套接字之间建立一个全双工的TCP连接（客户端既可以下载，也可以上传）
  • “面向连接”而非“连接”，是因为TCP连接是一种非常松散的、抽象的连接
• 可靠传输服务
• 拥塞控制服务
  • 对整个因特网数据的传输有好处，但是抑制传输速率对一些实时应用非常致命，因此它们会选择UDP
• 报文分组传输
• 多路复用/多路分解

UDP提供的服务

• 数据交付
• 差错检测
• 多路复用/多路分解
• 与TCP的区别：
  1. 轻量级，提供最小服务
  2. 无连接，通信前后无需握手
  3. 不可靠传输服务
  4. 无拥塞控制机制（可以保证一定的吞吐量，为实时应用所需）
  5. 不可分组，无分组开销
     因为很多防火墙都设置为阻塞UDP流量，因此多媒体和实时应用越来越多的使用TCP

应用举例：

分用实现：使用协议端口号。

• 与硬件端口不同，软件端口是应用进程的“地址”。
• 长16位。
• 只在本主机上有效。
  用户在发起通信请求时，必须知道对方的IP和端口号

套接字标识符

• UDP套接字使用 { 目的IP地址，目的端口号 } 二元组来全面标识
  因此一个端口只对应一个UDP套接字
• TCP套接字使用 { 源IP地址，源端口号，目的IP地址，目的端口号 } 四元组来全面标识
  一个端口可以对应很多个TCP套接字
  具有不同源IP地址或源端口号的TCP报文将被定向到两个不同的套接字，除非TCP携带了初始创建连接的请求（带有初始创建连接请求的所有TCP报文段都会被定位到一个welcoming套接字，welcoming套接字再为其创建一个专用套接字（新的线程），像开房一样）
  一个进程可以有多个线程，意味着可以有多个连接

端口号分类:

• 服务器使用的端口号：分为熟知端口号（系统端口号，0~1023）和登记端口号。
  • HTTP 80
  • FTP 21
• 客户端使用的端口号：短暂端口号，客户进程通信时才分配。

用户数据报协议UDP：

• 特点：无连接、尽最大努力交付（不可靠）、面向报文（对应用程序送来的报文不合并也不拆分，对IP层上交的数据报直接去除头部就交给应用进程。）、无拥塞控制、支持一对一、多对多、一对多和多对一的交互通信、首部开销小（只有8字节）。
• UDP用户数据报格式：
  
• 接收方UDP发现报文中的目的端口号不存在：丢弃报文，并用ICMP回复“端口不可达”差错报文。
• 检验和计算方法：检验和字段置零，然后将伪首部和UDP用户数据报看成是由许多16位字串接在一起（数据部分奇数个字节则要补一个全零字节），按二进制求和取反计算这些字的和（求和时若溢出要回卷），最后将和写入检验和字段。检验方法：伪首部连同UDP用户数据报按16位字的二进制求和取反求和，无差错则为全1。
• 检验和既检验了UDP用户数据报数据和端口号，又检验了IP地址。
• 为什么UDP要提供差错检测？
  因为虽然数据链路层提供差错检测，但是不能保证每一条链路都会进行差错检测，而且数据在存储和处理的过程中也会引入比特差错，因此UDP必须在端到端基础上在运输层提供差错检测，这符合端到端原则。
• 为什么选择UDP？
  1. 应用层能够更好地控制要发送的数据和发送时间（无流量、拥塞控制抑制发送端）
  2. 无需建立连接，延时更小（这是DNS选择UDP的一大原因）
  3. 无连接状态，服务器减小了状态维护开销
  4. 分组首部开销小（UDP只有8字节，TCP至少有20字节），效率更高
• 这些应用都选择了UDP
  1. DNS：追求响应速度，所以选择没有连接时延的UDP
  2. RIP选路表更新：更新报文被周期性地发送，新数据会自动覆盖旧数据，因此对于丢失和过时的更新报文无需重传
  3. SNMP：SNMP时常工作在网络负载较大的时候，此时可靠、拥塞受控的传输难以实现
     使用UDP的应用程序依然可以实现可靠数据传输，这可通过在应用程序自身中建立可靠性机制实现

可靠按数据传输协议

• 完全可靠信道上的可靠数据传输：rdt1.0、
  

• 具有比特差错信道上的可靠数据传输：rdt2.0
  rdt2.0及以后均为自动重换请求协议（Automatic Repeat reQuest，ARQ）和停等协议（stop-and-wait）
  

  • rdt2.0的致命缺陷：没有确认报文出错的情况。
    解决办法：若发送方收到受损的确认报文就重传数据，为了辨别是新的数据还是重传的数据，需要在发送方对数据分组进行编号（停等协议只需要1比特），如果接收方收到重传数据就要重传确认报文。序号还可以辨识出信道中的冗余数据分组。
    rdt2.1：
    
  • rdt2.1改进：取消NAK报文，使用冗余ACK（duplicate ACK）—— 接收方若收到受损的数据，就对上一次收到的好数据进行冗余确认。
    此时数据报文和确认报文都使用1比特序号
    
    

• 具有比特差错和丢包的信道上的可靠数据传输：rdt3.0
  rdt3.0被称为比特交替协议（alternating-bit protocal）
  
  

• 停等协议（rdt3.0）的信道利用率：
  U = (L/R) / (RTT + L/R)
  

流水线协议

• 信道利用率：
  U = (NL/R) / (RTT + L/R) （N为一次连续发送的分组数量）
  

• 滑动窗口协议（Sliding Window Protocal，SWP）

  • 亦称为回退N步协议（Go-Back-N，GBN）
  • 序号：
    • 设序号字段长度为k比特，则共有2^k的序号，[0, 2^k - 1]
    • 序号是按字节计数的而不是按分组计数。

• 选择重传协议（SR）

  • SWP中一个分组的差错可能导致许多不必要的重传，SR使用接收方缓存避免了这种浪费
  • 与SWP不同之处：
    1. 不再累计确认，而是单独确认
    2. 每个分组设置单独的计时器
    3. 接收方设置接收窗口（接收缓存）
  • 为了避免序号的重复使用，除了使发送窗口和接收窗口长度之和≤2^k，还可假定一个分组在网络中“存活”的时间不会超过某个固定最长时间，并在该固定最长时间设为序号重用的最短时间间隔。

传输控制协议TCP：

• 特点：面向连接、只支持点对点（TCP连接只能有两个端点）、可靠交付、全双工通信（配合缓存使用）、面向字节流（TCP将应用进程交下来的数据看成无结构的字节流，TCP根据对方的窗口值和网络拥塞状况来决定一个报文段应包含多少字节）。
• TCP连接的端点是套接字（Socket）/插口。
• 套接字 = （IP地址：端口号）。
• 每一条TCP连接都被两个套接字唯一的确定。
• 首部格式：
  
  • 序号：TCP是面向字节流的，因此每一个字节都需要编号。该字段存放本报文段所发送数据的第一个字节的序号。
  • 确认号：确认报文中，存储期望收到的下一个报文的第一个字节的编号。
  • 数据偏移：首部长度（数据起始点距报文开始处的距离），最小20最大60.
  • 紧急URG：=1时表示为紧急数据。
  • 确认ACK：=1时确认号字段才有效。TCP连接建立后所有报文的确认ACK须为1。
  • 推送PSH：=1时不待缓存慢立刻发送，接收方收到后立刻回复。
  • 同步SYN：连接请求报文段（SYN=1，ACK=0）、连接接受报文段（SYN=1，ACK=1）。
  • 终止FIN：=1时请求释放连接。
  • 窗口：（发送方的接收窗口大小）自该报文的确认号算起，允许对方发送的数据量。对方的发送窗口长度应小于该值。
  • 检验和：与UDP相同，伪首部第四个字段（协议号）从17改为6。
  • 选项：
    • 最大报文段长度MSS：规定数据字段的最大长度。数据太长在IP层就需要分片，既降低效率又增加错误率；数据太短就会降低网络利用率。MSS应使数据在IP层不再需要分片。
    • 窗口扩大选项：对于卫星信道的网络（传播时延和带宽很大），提高吞吐率需扩大窗口的最大长度。
    • 时间戳选项：计算往返时间，防止序号绕回PAWS（传输速率很高时，极有可能在一次TCP连接里发生序号回环）。
• 可靠传输：
  • 停止等待ARQ协议：
    • 是自动重传请求ARQ（Automatic Repeat reQuest）。
    • 每发送完一个分组就停止发送，等待对方的确认。收到确认后再发送下一个分组。
    • 发送方动作：发送一个有编号的分组，同时创建一个计时器。超时未收到确认则重传（要求发送方缓存未收到确认的分组），收到重复确认则丢弃。
    • 接收方动作：收到分组就发送带有该分组编号的确认，重复则丢弃。
    • 信道利用率底下。
  • 连续ARQ协议：
    • 是自动重传请求ARQ（Automatic Repeat reQuest）。
    • 发送方维持一个发送窗口，窗口内的分组可以连续发送。
    • 若窗口前端的分组已收到确认，就将窗口向前滑动。
    • 接收方采用累积确认：只为连续收到的最后一个分组发送确认。
    • 缺点：不能反映出接收方的全部接受信息（丢失分组后面的分组即使成功接收，发送方也会重传，称为Go-Back-N）。
  • 滑动窗口协议：
    • 发送方维护发送窗口，接收方维护接收窗口。
    • 以字节为单位滑动。
    • 接收方需采用累积确认。
    • 前沿一般不向后伸缩←|。
    • 发送缓存存放：应用程序传给TCP准备发送的数据；已发但未确认的数据。
    • 接收缓存存放：按序到达但尚未被应用程序读取的数据；乱序到达的数据。
    • 两窗口大小不一定一样。
  • 超时重传时间自适应算法：
    • 报文段往返时间RTT = 某报文收到确认时间 - 某报文发出时间。
    • 加权平均往返时间RTTs = （1-α）×（旧的RTTs）+α×（新的RTT样本）。
    • 初始值为第一个RTT样本。0<α<1，越小平滑程度越大，建议值0.125。
    • RTT偏差的加权平均值RTTD = （1-β）×（旧的RTTD）+β×|RTTs - 新的RTT样本|。初始值为第一个RTT样本的一半。0<β<1，建议值0.25。
    • 超时重传时间RTO（RetransmissionTime-Out）= RTTs + 4×RTTD
    • 不采用重传报文的样本时间（避免把确认当成对原始报文或者重传报文造成的差异）。
    • 每当有报文重传，就把RTO增加为原来的两倍。不再发生重传后再使用上述算法。
  • 选择确认SACK：
    • 接收乱序到达但位于接收窗口中的字节块，发送确认报文告知发送方已经接收到的乱序报文段。
    • 确认报文的选项中添加SACK选项（1字节）和指明共使用多少字节的字段（1字节），每指明一个乱序字节块边界需用8个字节，因此最多指明4个字节块的边界。
• 流量控制：让发送方的发送速率不要太快，让接收机来得及接收。
  • 利用滑动窗口实现流量控制：修改窗口字段限制发送方的发送窗口大小。
  • 持续计时器：接收方不想接收数据并将窗口设为零，之后若又想接收数据，则发送报文通知接收方更新状态。若该报文不幸丢失，则双方会陷入无限等待。因此，当发送方接收到窗口为零的通知后，开启一个持续计时器，到时未收到新通知则发送一个零窗口探测报文段（仅携带1字节的数据）。
• 发送控制：
  • 三种简单机制：
    1. 缓存中的数据达到MSS个字节后就组成TCP报文段发送。
    2. 发送方应用进程指明要立即发送报文段，即推送功能（PSH字段）。
    3. 发送方的计时器到时，就发送（不超MSS）。
  • Nagle算法：
    • 目的：提高TCP的传输效率，减少小分组数目，从而减少网络拥塞的出现。
    • 发送方：先发送1字节的数据，缓存随后到达的数据；收到确认后把到达缓存的所有数据组装成一个报文段发送，并缓存随后到达的数据；收到上一个报文段的确认后再发送一个数据报。
    • 糊涂窗口综合征：若接收方缓存已满，应用进程一次只读取一个字节，则接收方会一个字节一个字节地发送确认，发送方也会一个字节一个字节的发送数据（接受窗口限制）。
    • 接收方（避免糊涂窗口综合征）：接收方等待至接收缓存能容纳一个最长报文段，或者已有一半缓存空间。
• 拥塞控制：
  • 造成拥塞的直接原因：∑资源需求 > 可用资源。
  • 拥塞往往趋于恶化，因为拥塞造成的重传会加重网络拥堵。
  • 拥塞控制与流量控制的区别：流量控制只考虑通信两端的资源使用情况，而拥塞控制需要考虑整个通信网的资源使用情况。
  • 拥塞曲线：
    
  • TCP的拥塞控制算法（基于窗口）：加法增大AI、乘法减小MD的AIMD算法。
    • 发送方维持一个拥塞窗口cwnd，使得发送窗口长度等于拥塞窗口。
    • 判断拥塞的依据：出现超时。
    • 是加法增大AI、乘法减小MD的AIMD算法。
    • 慢开始（slow-start）：
      • 初始时刻不知道网络的状况，因此要慢开始。
      • cwnd初始长度设为：
        1. 若SMSS > 2190，则cwnd = 2×SMSS，不得超过2个报文段；
        2. 若SMSS > 1095且SMSS <= 2190，则cwnd = 3×SMSS字节，不得超过3个报文段；
        3. 若SMSS <= 1095，则cwnd = 4×SMSS，不得超过4个报文段。
      • （指数增长）每收到一个对新的报文段的确认后，把拥塞窗口增加min(N，SMSS)。N为刚刚确认的总字节数。于是每经过一个传输轮次（一个RTT），cwnd就加倍。
      • 实际的TCP允许每收到一个确认报文就把cwnd + 1，并可以立即发送新的报文段，而不需要等到这个轮次中的所有确认都收到后再发送。
      • 慢开始门限ssthresh：cwnd < ssthresh时使用慢开始，>则使用拥塞避免算法。
    • 拥塞避免（congestion avoidance）：
      • （线性增长）每经过一个RTT，把cwnd + 1。
    • 快重传（fast retransmit）：
      • 避免拥塞误判（非拥塞造成地丢失导致超时）。
      • 要求接收方不进行捎带确认，收到有序/乱序的报文段立即发送确认。当发送方收到对同一报文段的3个重复确认后，就立即重传该报文段的下一报文段。
      • 原理：接收方只有收到后续报文段才会发送重复报文段，而这正表明并没有发生拥塞。
    • 快恢复（fast recovery）：
      • 快重传后令ssthresh = cwnd/2，同时设置cwnd = ssthresh。
• 运输连接管理：
  • 连接建立（3次握手）：
    • 采用客户服务器模式。主动发起连接的是客户，被动等待连接的是服务器。
    • 前两次握手完成后连接处于“半开启”状态。
    • 第三次握手是为了避免已过期的连接请求到达服务器，导致建立新的连接。
    • 过程图解：
      
  • 连接释放（4次握手）：
    • 过程图解：
      
    • 等待2MSL时间是为了使该连接上的所有报文段都从网络中消失，防止迟到的报文段建立新的连接；同时应对最后一个ACK报文丢失的情况。
  • 保活计时器：
    • 服务器使用。
    • 避免因客户主机故障导致无法释放连接。
    • 服务器一收到客户的数据就重置计时器。超时后发送一个探测报文段，并每隔75sec发送一次。一连发送10个探测报文并且无响应则关闭该连接。
  • 状态转移图：