计算机网络--运输层

运输层

---

• 概述
• TCP 与 UDP区别
• TCP
  • TCP 报文段首部格式
  • 流量控制
  • 拥塞控制
  • 超时重传
• TCP 可靠连接的实现
  • 连接建立
  • 连接释放

---

概述

物理层，数据链路层，网络层共同解决了主机与主机之间的通信问题

但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程

• 运输层协议【端到端协议】

  解决：如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务

  根据需求不同，运输层为应用层提供了两种不同的运输协议

  • 面向连接的 TCP
  • 无连接的 UDP

• 运输层端口号

  不是物理层面的接口，而是运行在计算机的进程使用的进程标识符 PID

  在不同操作系统中，使用不同格式的进程标识符，想要顺利通信就必须使用统一的方法对 TCP/IP 体系的应用进程进行标识

  TCP/IP 体系的运输层使用端口号区分应用层的不同应用进程

  • 端口号使用 16 比特表示，取值 0 ~ 65535

    • 熟知端口号：0 ~ 1023，IANA 把这些端口号指派给 TCP/IP 体系中最重要的一些应用协议，例如：PTF-21/20、HTTP-80，DNS-53
    • 登记端口号：1024 ~ 49151，为没有熟知端口号的应用程序使用，使用这类端口号必须在 IANA 按照规定手续登记，防止重复
    • 短暂进程号：49152 ~ 65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道客户进程所使用的动态端口号。通信结束后，可以提供给其他客户进程以后使用

  • 端口号只具有本地意义，在不同计算机中相同端口是没有联系的

• 常用协议的运输层熟知端口号

  • (RIP-520、DNS-53、TFTP-69、SNMP-161、DHCP-67/68) -> UDP

  UDP 协议字段为 17

  • (SMTP-25、FTP-20/21、BGP-179、HTTP-80、HTTPS-443) -> TCP

  TCP 协议字段为 6

TCP 与 UDP 区别

• 用户数据协议 UDP: User Datagram Protocol
• 传输控制协议 TCP: Transmisson Control Protocol

UDP	TCP
无连接	有连接
支持单播、多播、广播	仅支持单播
面向应用报文	面向字节流
向上层提供无连接不可靠传输服务【适用于 IP 电话、视频会议等实时应用】	向上层提供面向连接的可靠传输服务【适用于要求可靠传输的应用，例如文件传输】
用户数据报首部仅 8 字节	报文首部最小 20 字节，最大 60 字节
不使用流量控制和拥塞控制	使用流量控制和拥塞控制

TCP

TCP 报文段首部格式

--------------------------------------------------------------------------
|[0]|        源端口               |[16]|             目的端口        |[31]|
|                              序        号                               |
|                                确 认 号                                 |
|数据偏移|保留|URG|ACK|PSH|SYN|FIN|[16]|               窗口          |[31]|
|[0]|        校验和               |[16]|             紧急指针        |[31]|
=                                                                         =
|                   选项  ( 长度可变 )              |       填充          |
---------------------------------------------------------------------------

固定首部 【 20 字节 】

• 源端口和目的端口【 各占2个字节 】：端口是传输层和应用层的服务接口，传输层的复用和分用功能都有要通过端口才能实现。

• 序号【 4 】：首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号

• 确认号【 4 】：是期望收到对方下一个报文段的第一个数据字节的序号。

• 数据偏移【4】：它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远

• 保留【 6 】：保留为今后使用，应置为0

• 标识符【 6 】

  • 紧急URG：占1位，当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快发送，而不要按原来的排队顺序来传送
  • 确认ACK：占1位， 仅当ACK = 1时确认号字段才有效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。
  • 推送PSH：占1位，表示Push功能是否启用
  • 复位RST：占1位，当RST=1时，表名TCP连接中出现了严重错误，必须释放连接，然后再重新建立传输连接
  • 同步SYN：占1位，在连接建立时用来同步序号
  • 终止FIN：占1位，用来释放一个连接

• 窗口【 2 】：窗口指的是发送本报文段的一方的接受窗口

• 紧急指针【 2 】：紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数

扩展首部 【 最大 40 字节 】

• 选项：长度可变，最长可达40字节，对 TCP 功能的额外扩充
• 填充：为了使整个首部长度是 4 字节的整数倍

流量控制

限制发送方的发送速率，让接收方能够完整的接收数据

实现：使用TCP协议的滑动窗口机制实现

• TCP 接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
• TCP发送方收到接收方的零窗口通知后，应启动持续计数器。计数器超时会发送一个零窗口探测报文

拥塞控制

处理和缓解网络拥塞问题，避免无意义的网络资源浪费

TCP 拥塞控制算法

• Tahoe 版

  • 慢开始：指数级增长，达到 ssthresh 门限改为 拥塞避免
  • 拥塞避免：线性增长，超时重传触发，ssthresh / 2, cwnd = 1

• Reno 版

  • 快重传：不再以超时重传为基准，而是收到 3 个重复确认触发
  • 快恢复：在 ssthresh 更新为 ssthresh / 2 基础上更新 cwnd 值为 ssthresh 直接进入拥塞避免阶段

超时重传

超时重传时间 RTO 应该略大于 往返时间 RTT

RFC6298 计算超时重传时间 RTO

$$RTO = RTT_S + 4 \cdot RTT_D$$

计算 加权平均往返时间 $RTT_S$

$RTT_{S1} = RTT_1 \\ new RTT_S = (1 - \alpha) \cdot old RTT_S + \alpha \cdot new RTT_{test}, \qquad 0 \leqslant \alpha < 1$

已经成为建议标准的 RFC6298 的推荐 $\alpha = 1 / 8 = 0.125$

计算 $RTT$ 偏差的加权平均 $RTT_D$

$RTT_{D1} = RTT_1 \div 2 \\ new RTT_D = (1 - \beta) \cdot old RTT_D + \beta \cdot \mid RTT_S - new RTT_{test} \mid, \qquad 0 \leqslant \beta < 1$

已经成为建议标准的 RFC6298 的推荐 $\beta = 1 / 4 = 0.25$

TCP 可靠连接的实现

基于以字节为但我的滑动窗口来实现可靠传输

TCP 运输连接有一下三个阶段

• 建立 TCP 连接
• 数据传输
• 释放 TCP 连接

连接建立

TCP 建立连接所需要解决的问题

• 使 TCP 双方能够确认对方的存在
• 达成双方的一些基础参数的确认
• 使双方能够对运输实体资源进行分配

TCP 建立连接被称为“三次握手”

• 客户端发送 TCP 连接请求：SYN=1, seq=x
• 服务器发送针对 TCP 连接请求的确认：SYN=1, ACK=1, seq=y, ack=k+1
• 客户端发送对服务器的回复确认：ACK=1, seq=x+1, ack=y+1

注：SYN=1 的报文段不能携带数据

分析：第三次回复确认的必要性

这是为了防止已经失效的连接请求报文段突然又传送到TCP服务器，导致TCP服务器单方面进入已建立连接状态造成不必要的资源浪费

连接释放

TCP 释放连接被称为“四次挥手”

• 客户端发送 TCP 连接释放：FIN=1, ACK=1, seq=u, ack=v
• 服务器回复确认：ACK=1, seq=v, ack=u+1
• 服务器发送最终连接释放报文：FIN=1, ACK=1, seq=w, ack=u+1
• 客户端回复确认完成释放：ACK=1, seq=u+1, ack=w+1

在客户端发送最终确认后，需要经过 2MSL (Maximum Segment Lifetime) 进入关闭状态，RFC793 建议为 2 分钟

分析： 2MSL 等待的必要性

防止第四次挥手丢失，服务器再次发送第三次挥手，出现客户端已关闭的错误

保活计时器：确保客户端出现故障，无法释放连接

当保活计时器到时后，TCP 服务器进程就会向 TCP 客户进程发送一个探测报文段，以后每隔 75 秒发送一次，当连续累计 10 次无响应，则认为客户端故障