本章旨在介绍传输层的两个主要协议 TCP (Transmission Control Protocol) 与 UDP (User Datagram Protocol)。

  • TCP 提供可靠的通信传输;
  • UDP 则常被用于让广播和细节控制交给应用的通信传输

6.1 传输层的作用

  • IP 首部有一个协议字段用来标识网络层(IP)的上一层(传输层)所采用的哪一种通信协议(TCP or UDP)
  • TCP/UDP 通信中,传输层首部也使用“端口号”指明上一层(应用层)所要进行处理的具体程序

  • 通信处理:传输协议 TCP、UDP 通过接收数据中的目标端口号识别目标处理程序,将数据传给相应的应用层协议

image.png

两种传输层协议 TCP 和 UDP

在 TCP/IP 中能实现传输层功能的、具有代表性的协议是 TCP 和 UDP 第 6 章 TCP 与 UDP - 图2

  • TCP 用于在传输层有必要实现可靠传输的情况
  • UDP 用于对高速传输和实时性有较高要求的通信或广播通信,eg.
    • IP 电话使用 UDP,数据如果在传送途中丢失,不会进行重发处理,避免声音大幅度延迟的问题,可以流畅传输通话人的声音。即使有部分数据丢失,也只会影响某一小部分的通话
    • 多播与广播通信中也使用 UDP 而不是 TCP

6.2 端口号

层次 地址 用途
数据链路层 MAC 地址 识别同一链路中不同的计算机
网络层(IP) IP 地址 识别 TCP/IP 网络中互连的主机和路由器
传输层 端口号/程序地址 识别同一台计算机中进行通信的不同应用程序
  • 根据端口号识别应用:传输层协议利用端口号识别本机中正在进行通信的应用程序,并准确地传输数据

image.png

  • 实际上并非只根据端口号来识别某一个通信,而是通过“源 IP 地址、目标 IP 地址、协议号(TCP or UDP)、源端口号、目标端口号”这 5 个数字来识别一个通信,只要其中某一项不同,就被认为不是同一个通信
    • 因此,TCP 和 UDP 可以使用同一个端口号,但出于不同的使用目的

image.png

  • 确定端口号的两种方法
    • 标准既定的端口号(静态方法):每个应用程序都有其指定的端口号,每个端口号都有其对应的使用目的。但要避免使用知名端口号(eg. HTTP、FTP 等固定使用某些端口号),以免造成冲突
    • 时序分配法(动态分配法):服务端需确定监听端口号,但客户端无需确定端口号。客户端应用程序无需自己设置端口号,而交给操作系统动态分配管理

6.3 UDP(User Datagram Protocol)

  • UDP 协议的特点

    • UDP 不提供复杂的控制机制,利用 IP 提供面向无连接的通信服务,可以随时发送数据
    • 收到应用程序发来的数据的那一刻,立刻按照原样发送到网络上
    • 即使出现网络拥堵,也无法进行流量控制等避免网络拥塞的行为
    • 传输途中即使丢包,UDP 也不负责重发
    • 包乱序到达时,UDP 也没有纠正功能
    • 以上提到的这些细节控制,交给采用 UDP 的上层应用程序处理
    • UDP 本身的处理既简单又高效,只提供作为传输层协议的最基本功能
    • 没有连接控制,因此即使对端从一开始就不存在 or 中途退出网络,数据报依旧发送(当 ICMP 错误返回时,有时也实现了不在发送的机制)
  • UDP 适用于

    • 包总量较少的通信(DNS、SNMP 等)
    • 视频、音频等多媒体通信(即时通信)
    • 限定于 LAN 等特定网络中的应用通信
    • 广播通信(广播、多播)

6.4 TCP(Transmission Control Protocol)

  • TCP 在 IP 这种无连接的网络上实现了高可靠性的通信,是对“传输、发送、通信”进行“控制”的“协议”,实现了各种控制功能,包括:

    • 丢包时的重发控制
    • 乱序到达的分包的顺序控制
    • 连接控制:TCP 是面向连接的协议,只有在确认对端存在时才会发送数据,从而控制通信流量的浪费
    • … …
  • TCP 通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等实现可靠传输

第 6 章 TCP 与 UDP - 图5

6.4.1 通过 序列号 与 确认应答(ACK) 提高可靠性

  • 三种数据传输情况(下图所示):
    • 正常的数据传输:发送端收到接收端的确认应答 ACK
    • 数据包丢失的情况:在一定时间内发送端没有等到确认应答,认为数据已丢失,重发
    • 确认应答丢失或延迟到达的情况:发送端未收到确认应答也可能是应答丢失或延迟到达,因此也会重新发送,而造成重复发送,接收端必须放弃重复的数据包

image.png

  • 上述这些确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现
    • 序列号初始值在建立连接后随机生成,每一个字节编号 +1,接收端根据收到数据 TCP 首部中的序列号和数据长度,将下一步应该接收的序号作为确认应答发回给发送发(上图所示)

6.4.2 重发超时如何确定

  • TCP 要求不论处在何种网络环境,都要提供高性能的同行,因此每次发包时都会计算往返时间及其偏差,重发超时的时间就是比 往返时间 + 偏差 稍大一点的值
  • Windows 下,重发超时时间设定为 0.5s 的整数倍。但由于最初的数据包不知道往返时间,因此其重发超时时间一般定为 6s
  • 数据重发后若仍收不到确认应答,再次发送,重发超时时间以 2 倍、 4 倍 的指数函数延长
  • 重发一定次数后,若仍收不到确认应答,则认为网络或对端主机异常,强制关闭连接,并通知应用通信异常强行终止

6.4.3 连接管理

  • 使用 TCP 首部用于控制的字段来管理 TCP 连接
  • 建立连接时发送 SYN 包请求建立连接
  • 断开连接时发送 FIN 包请求切断连接
  • 一个连接的建立与断开,正常情况至少需要来回发送 7 个包才能完成

image.png

6.4.5 利用窗口控制提高速度(窗口控制)

  • TCP 以段为单位,每发送一个段都要进行一次确认应答的处理,早先必须先收到确认应答才能发送下一个段,但这导致包的往返时间越长,网络的吞吐量越差
  • 因此,TCP 引入窗口概念,发送端主机在发送完一个段后不必一直等待确认应答,而是继续发送,实现并行处理
  • 窗口大小指无需等待确认应答就可以继续发送数据的最大值

image.png

6.4.6 窗口控制与重发控制

  • 如果有少部分数据的确认应答丢失,但收到了后面数据的确认应答,不需要重发
  • 高速重发控制:当某一报文段丢失后,接收端收到后面的数据,发现不是自己想要的序列号的数据,则重发发送丢失前的数据的确认应答,表明自己想要的是丢失的数据。发送端主机若连续三次收到同一个序列号的确认应答,则重发对应数据。这种机制比超时管理更为高效

image.png

6.4.7 流控制(流量控制)

  • 即,TCP 提供一种机制让发送端根据接收端的实际接收能力控制发送的数据量,不超过限度(即窗口大小
  • 窗口大小
    • TCP 首部有一个字段用来通知窗口大小,接收方主机将自己可以接收的缓冲区大小放入这个字段通知给发送方
    • 这个字段的值越大,说明网络的吞吐量越高
    • 当接收端的缓冲区面临数据溢出时,窗口大小的值也会被设置为一个更小的值通知给发送端,从而控制数据发送量
  • TCP 通信一个连接的最大吞吐量 第 6 章 TCP 与 UDP - 图10 由窗口大小 第 6 章 TCP 与 UDP - 图11 和往返时间 第 6 章 TCP 与 UDP - 图12 决定
    • 第 6 章 TCP 与 UDP - 图13

image.png

6.4.8 拥塞控制

  • 连续发包称为“爆发”,可能造成网络拥塞甚至瘫痪
  • TCP 为了防止网络拥塞,在通信一开始就通过“慢启动”算法对发送数据量进行控制
  • 拥塞窗口:用于在发送端调节所要发送数据的量
  • 慢启动初始时,将拥塞窗口大小设置为 1 个数据段(1 MSS)发送数据,之后每收到一次确认应答 ACK,拥塞窗口的值就 +1 数据段
  • 发送数据包时,比较拥塞窗口的大小和接收端主机通知的窗口大小(流控制的窗口大小),取较小值,发送的数据量不能超过该值

image.png

  • 慢启动阀值:避免拥塞窗口增长过大导致拥塞设定的
    • 初始时慢启动阀值 = 窗口的最大值
    • 超时重发时,将慢启动阀值设置为当前拥塞窗口一半的大小
    • 由重复确认应答触发高速重发控制时,慢启动阀值大小被设置为实际已发送但未收到确认应答的数据量的一半,然后将窗口大小设置为该慢启动阀值 + 3 个数据段的大小

image.png

6.4.9 提高网络利用率的规范

  • Nagle 算法
    • 仅在满足以下任意一种条件时才能发送数据,若都不满足则要暂停一段时间
      • 已发送的数据都已收到确认应答时
      • 可以发送最大段长度(MSS)的数据时
    • 缺点:虽然能提高网络利用率,但可能会发生某种程度的延迟,因此机械控制等领域使用 TCP 时,不启用该算法
  • 延迟确认应答
    • 接收数据的主机每次接收完数据,如果都立刻回复确认应答,由于刚接收数据可能缓冲区已满,可能会返回一个较小的窗口大小,而降低发送方的发送数据的大小,降低网络利用率,因此可以延迟确认应答,以提高网络利用率
    • 延迟机制:
      • 在未收到 2 × 最大段长度的数据为止不做确认应答
      • 其他情况下,最大延迟 0.5s 发送确认应答,这个时间设定越长越可能触发超时重传,越低则性能下降

image.png

  • 捎带应答
    • TCP 的确认应答和回执数据可以通过同一个包发送
    • 必须搭配延迟应答使用,不能立即返回确认应答

image.png

6.5 其它传输层协议

6.5.1 UDP-Lite

  • 功能与 UDP 基本相同,但计算校验和的范围可以由应用自行决定,使得可以只针对不允许发生错误的部分进行校验和的检查(eg. 首部 + 伪首部,or 伪首部 + 部分数据),其他部分发送错误也被忽略,这个包也不会被丢弃,而是传给应用继续处理

6.5.2 SCTP(Stream Control Transmission Protocol)

流传输控制协议

  • 与 TCP 一样,都是一种提供数据到达与否相关可靠性检查的传输层协议
  • 主要用于进行通信的应用之间发送众多较小消息的情况

6.5.3 DCCP(Datagram Congestion Control Protocol)

数据报拥塞控制协议

  • 是一个辅助 UDP 的传输层协议,提供拥塞控制机制
  • 与 UDP 一样,不能提供发送数据的可靠性传输
  • 面向连接
  • 能进行拥塞控制

6.6 UDP 首部格式

image.png

6.7 TCP 首部格式

image.png