『computer network-4』transport layer

传输层

一、传输层协议概述

  • 传输层（应用层）功能：为上面的应用层提供（端到端）通信服务

    • 实现可靠传输：差错控制 + 顺序控制 + 拥塞控制

    注意：网络层实现主机之间的逻辑通信；传输层实现应用进程之间的逻辑通信（端到端通信）

  • 传输层主要协议：传输控制协议(TCP) + 用户数据报协议(UDP)

    • TCP协议：可靠传输协议，典型协议包括HTTP、FTP
      • 提供面向连接的服务（传输数据前建立连接 + 传输结束后释放连接）
      • 需进行确认、流量控制、计时器、连接管理，处理开销较大
    • UDP协议：不可靠传输协议，典型协议包括DNS、RIP
      • 传输时无需建立连接
      • 比TCP效率更高，但可能出现数据错误、丢包、顺序错误等问题

  • 传输层端口：用于为多个应用进程AP提供服务

    • 端口复用：应用层多个应用进程通过传输层发送数据（向下）

    • 端口分用：传输层收到的数据必须交付给指明的应用进程（向上）

    • 端口号：TCP/IP协议使用16位整数作为端口号，用于表示 源端口号 + 目的端口号

      • 熟知端口号（系统端口号）：0 ~ 1023，如 HTTP 服务使用80、FTP 服务使用21
      • 登记端口号：1024 ~ 49151，提供给没有熟知端口号的AP使用；须在IANA登记（以防重复）
      • 客户端口号（短暂端口号）：49152 ~ 65535，供客户进程临时使用

二、用户数据报协议 UDP

  • UDP概述：不可靠传输协议，只在IP数据报服务基础上增加了端口和差错检测，包含以下特点：

    • 无连接：发送数据前无需建立连接
    • 尽最大努力交付：不保证可靠交付，同时不使用拥塞控制（很适合多媒体通信）
    • 支持一对一、一对多、多对一、多对多的交互通信
    • 首部开销小，仅有8Byte

  • UDP首部格式：共8Byte，包含以下5个字段

    • 源端口：标注 源端口号（2Byte）
    • 目的端口：标注 目的端口号（2Byte）
      注意：若接收方的目的端口上没有AP接收数据，则会向源主机返回ICMP的"目的不可达"报文
    • 长度：UDP数据报长度（2Byte）
    • 校验和：UDP数据报的校验和（2Byte）
    • 伪首部：不实际传输，仅在计算校验和时使用（12Byte）

    注意：网络传输一般使用Big Endian，源端口号发送在前

  • 计算校验和：计算整个UDP数据报的二进制反码和，计算过程类似网络层IP首部校验和

    • 计算校验和前需要添加12Byte的伪首部
    • 若UDP数据报长度为奇数字节，先通过零填充将其转化为偶数字节再计算

三、传输控制协议 TCP

  • TCP概述：可靠传输协议，主要包括以下特点：

    • 面向连接：传输前必须建立连接，数据传输完毕后要释放连接

    • 点对点连接：每条TCP连接仅能有两个端点

    • 可靠交付服务：无差错、不丢失、不重复、按需到达

    • 全双工通信：在一个连接上，通信双方可同时向对方传输数据

    • 面向字节流：AP以数据块为单位与TCP交互，而TCP将数据块视为无结构的字节流
      注意：TCP可把过长的数据块划分短一些再发送，也可等积累足够多的字节后再发送

    • TCP对AP一次把多长的报文发送到TCP缓存中是不关心的

    • TCP根据对方给出的窗口值 + 当前网路拥塞程度决定一个报文段应该包含多少字节 UDP发送的报文段长度是由AP给出的

  • TCP的连接：TCP把连接看作最基本的抽象；TCP连接是虚连接而非真正的物理连接

    • 套接字：TCP连接的端点，socket ::= (IP地址, 端口号)
    • TCP连接唯一地由两个端点确定，TCP连接 ::= {(IP1: port1), (IP2: port2)}

四、TCP报文段首部

  • TCP报文的首部格式

    • 源端口 + 目的端口：各占2Byte
    • 序号字段：指明本报文段数据首字节的序号，占4Byte；TCP连接的数据流中的每个字节都按顺序编号
    • 确认号字段：期望收到对方下一个报文段数据的首字节序号，占4Byte
    • 数据偏移：数据部分相较起始位置的偏移（即首部长度），单位为4Byte，占4bit
    • 保留字段：无意义，占6bit
    • 紧急URG：值取1表示有紧急数据，应尽快传送（紧急数据放在数据的最前面），占1bit
    • 确认ACK：值取1时确认号字段有效，占1bit
    • 推送PSH：值取1时接收方将尽快向AP交付此报文段，不等到整个缓存填满，占1bit
    • 复位FST：值取1时表明TCP连接出现严重差错，须先释放连接再重新建立连接，占1bit
    • 同步SYN：值取1时表明这是一个 连接请求 or 连接接受 报文，占1bit
    • 终止FIN：值取1时表明要求释放TCP连接，占1bit
    • 窗口大小：用以向对方设置发送窗口的依据，单位为字节，占2Byte
    • 检验和：伪首部 + 首部 + 数据部分 的校验和，占2Byte
    • 紧急指针：指出报文中紧急数据字节数，占2Byte
    • 选项：一种选项被称为最大报文段长度，告知对方报文段数据部分最大长度；可变长，最长占40Byte
    • 填充字段：为了让整个首部长度是4Byte的整数倍

五、TCP的可靠传输

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

    • 发送窗口：包含 已发送但未收到确认 + 允许发送但尚未发送 的字节

      • window_size：由接收方发送过来，实现拥塞控制

      • ack_num：由接收方发送过来，控制窗口后沿；表示此序号之前的字节已被正确接收

      • 发送窗口前移：收到接收方的ack_num后，将窗口下沿挪至ack_num处

      • 若发送窗口已满，暂停发送

      注意：发送窗口的前沿不建议回退收缩（因为收缩部分的数据可能已经被发送出去了）

    • 接收窗口：包含 允许接受 的字节

      • 接收窗口前移：收到连续下沿字节后，窗口挪至首个尚未接收的字节处
      • 对于未按序收到的字节，先缓存，仅返回窗口下沿对应的ack_num；最后按序交付上层的AP

      注意：由于传送窗口值有一定的滞后，故发送窗口和接收窗口不总是一样大

    • 缓存：发送方 和 接收方 均设有缓存，如下图：

  • 超时重传时间的选择：发送方在规定时间内未收到确认，就要重传超时的报文段，直至收到应答

    • 加权平均往返时间\(\text{RTT}_S\)：平滑的往返时间，计算方式如下：

      • 首次测量到一个RTT样本时，\(\text{RTT}_S\) = RTT
      • 之后每测得一个新的RTT样本，更新\(\text{RTT}_S\)：\(\text{RTT}_S \gets (1 - \alpha) \times \text{RTT}_S + \alpha \times \text{RTT}\)；其中 \(0 \le \alpha \lt 1\)，越小更新越慢

    • 超时重传时间RTO：RTO = \(\text{RTT}_S + 4 \times \text{RTT}_D\)，其中 \(\text{RTT}_D\) 表示RTT的偏差的加权平均值，计算方式如下：

      • 首次测得一个RTT样本时：\(\text{RTT}_D \gets \dfrac{\text{RTT}}{2}\)
      • 之后每侧的一个新的RTT样本，更新\(\text{RTT}_D\)：\(\text{RTT}_D \gets (1-\beta) \times \text{RTT}_D + \beta \times |\text{RTT}_S - \text{RTT}|\)；其中 \(0 \le \beta \le 1\)

      注意：RTO 应略大于 \(\text{RTT}_S\)（从公式中也可看出）

六、TCP的流量控制

  • 流量控制的目的：让发送方的发送速率不要太快，使接收方来得及接收

    • TCP建立时，接收方将自己接收窗口的大小告知对方（window_size）
    • 发送方根据接收方发来的window_size调整发送窗口大小，发送窗口 \(\le\) 接收窗口rwnd

  • 持续计时器：防止接收方发送rwnd=0报文后，接收方发送的窗口报文丢失导致死锁

    • TCP为每个连接设置一个持续计时器；只要一方收到对方的零窗口通知、就启动持续计时器
    • 若持续计时器设置的时间到，发送方就发送一个零窗口探测报文段（1Byte），对方返回当前窗口值
    • 若窗口仍是0，重新设置持续计数器；若窗口不是0（接收缓存腾出了空间），继续发送数据

  • 传输效率：控制TCP报文段的发送时机

    • 缓存数据达到一定量就发送：若缓存中的数据累计达到MSS字节，就组装成一个TCP报文发送出去
    • 应用进程控制：由发送方AP指明要求发送报文段（push）
    • 定时发送：发送方计时器期限到了，就把当前缓存中已有数据装成报文段（\(\le\) MSS）发送出去

七、TCP的拥塞控制

  • 拥塞的产生原因：网络中对某资源的需求超过了该资源所能提供的部分

    • 网络资源：链路带宽、路由节点缓存、处理能力 等

    注意：网络拥塞是由多种原因导致的，通过简单增加某种资源数量并不能消除拥塞

  • 网络拥塞的表现：吞吐率下降、报文传输时延增大、丢包率增加，响应时间变长（主机未收到ack就说明拥塞了）
    注意：TCP重传机制是拥塞恶性循环的起因（网络中被注入了更多报文）

  • 慢启动：每收到一个ack，cwnd就加1 \(\Rightarrow\) 每经过一个传输轮次（RTT），cwnd就加倍（逐步增大cwnd）

    • 拥塞窗口cwnd：由发送方维持，根据网络的拥塞程度动态变化（无拥塞就增大、有拥塞就减小）
    • 慢启动门限ssthresh：防止cwnd增长过快导致拥塞
      • cwnd < ssthresh：使用慢启动算法
      • cwnd > ssthresh：改用拥塞避免算法
      • cwnd = ssthresh：两种算法都可以使用

  • 拥塞避免算法：每经过一个传输轮次（RTT），就把cwnd加1（而非翻倍）

    • 拥塞处理：
      1. 只要发送方判断网络出现拥塞（未按时收到ack），就令 ssthresh \(\gets\) cwnd / 2
      2. 令 cwnd \(\gets\) 1，并重新执行慢启动算法

  • 快重传：尽快对超时报文做处理

    • 拥塞处理：
      1. 接收方每收到一个失序的报文段，就只对最近按序接收的报文段回复重复确认
      2. 若发送方连续接收到3个重复确认，就立即重传对方尚未收到的报文段

  • 快恢复：跳过慢启动算法，直接执行拥塞避免算法

    • 拥塞处理：
      1. 发送端连续收到3个重复确认时，令 ssthresh \(\gets\) cwnd / 2
      2. 令 cwnd \(\gets\) ssthresh，直接执行拥塞避免算法

    注意：连续收到3个重复确认不代表发生拥塞（仅可能代表拥塞征兆）

  • 发送窗口的上限值 = min[rwnd, cwnd]，由该式可知：

    • 当 rwnd < cwnd 时：接收方的接受能力限制发送窗口最大值
    • 当 rwnd > cwnd 时：网络拥塞限制发送窗口的最大值

八、TCP的连接管理

  • TCP传输连接：

    • 连接三阶段：连接建立 + 数据传送 + 连接释放
    • 客户 / 服务器方式：TCP连接的方式
      • 客户：主动发起连接建立的AP
      • 服务器：被动等待连接建立的AP

  • 三次握手：TCP建立连接的方式

    • 采用3次而非2次握手的原因：2次握手可能导致“已在网络中失效的请求报文”突然又传送到服务器端，建立冗余连接占用资源
    • TCP SYN Flooding 攻击：攻击者发送大量SYN报文，但不对返回的SYN ACK报文做回应，导致挂有大量TCP半连接资源
      • 攻击效果：服务器内部资源满，无法相应正常用户的TCP连接请求
      • SYN_Cookies：服务器返回SYN_ACK时，根据自身特有信息计算Cookies作为seq返回，并在收到应答前不为其分配资源

  • 连接释放：该过程可由任意一方发起，设A主动关闭连接（FIN）

    • MSL：报文最大存活时间，建议2mins

    ‘

    注意：A发送完最后一个ACK后，再经过2MSL就可以让本连接产生的所有报文段都从网络中消失；新连接中不会残留旧连接的报文段

computer network
#UDP #TCP
『computer network-4』transport layer
http://larry0454.github.io/2024/04/09/computer_network/transport-layer/
Author
WangLe
Posted on
April 9, 2024
Licensed under