计算机网络-运输层

运输层协议层概述:

• 1.1 进程之间的通信:
  从 IP 层来说, 通信的两端是两台主机. 但是真正通信的实体是在主机的进程, 是这台主机中的一个进程和另一台主机中的一个进程在交换数据. 网络层为主机之间提供逻辑通信, 而运输层为应用进程之间提供端到端的逻辑通信.
• 1.2 运输层的两个主要协议:
  • 用户数据报协议 UDP (User Datagram Protocol): 不需要先建立连接
  • 传输控制协议 TCP (Transmission Control Protocol): 面向连接
• 1.3 运输层的端口:

  • 运输层使用协议端口(Protocol Port Number), 这种协议端口是软件端口, 是通过软件来实现的. 它是应用的各种协议进程与运输实体进行层间交互的一种地址.

  • 端口号只具有本地意义

  • 常用端口号:

    应用程序	FTP	TELET	SMTP	DNS	TFTP	HTTP	SNMP	SNMP(trap)	HTTPS
    熟知端口号	21	23	25	53	69	80	161	162	443

用户数据报协议 UDP:

• 2.1 UDP 概述:
  • UDP 是无连接的
  • UDP 使用尽最大努力交付, 即不保证可靠交付.
  • UDP 是面向报文的. UDP 不拆分应用层交下来的报文, 它保留这些报文的边界.
  • UDP 没有拥塞控制, 网络出现的拥塞不会使主机的发送速率降低.
  • UDP 支持一对一, 一对多, 多对一和多对多的交互通信.
  • UDP 首部开销小, 只有 8 个字节.
• 2.2 UDP 的首部格式:

  • 源端口: 源端口号. 在需要对方回信时选用. 不需要时可全为 0.

  • 目的端口: 目的端口号. 在重点交付报文时必须使用.

  • 长度: UDP 用户数据报的长度, 最小值是 8.

  • 检验和: 检测 UDP 用户数据报在传输中是否有错. 有错就丢弃.
    若接收方 UDP 发现收到的报文中的目的端口号不正确, 就丢弃该报文, 并由网际控制报文协议 ICMP 发送端口不可达差错报文给发送方. UDP 在计算校验和时, 需要在数据报前面增加 12 字节的伪首部, 得到一个临时的 UDP 用户数据报, 校验和就是按照这个临时的 UDP 用户数据报来计算的.

    

传输控制协议 TCP 概述

• 3.1 TCP 主要特点:
  • TCP 是面向连接的运输层协议.
  • 每一条 TCP 连接只能由两个端点(endpoint), 每一条 TCP 连接只能是点对点的.
  • TCP 提供可靠交付的服务. 通过 TCP 连接传送的数据, 无差错, 不丢失, 不重复, 并且能够按序到达.
  • TCP 提供全双工通信. TCP 连接的两端都设有发送缓存和接收缓存, 用来临时存放双向通信的数据.
  • 面向字节流. TCP 中的流(stream)指的是流入到进程或从进程流出的字节序列.
• 3.2 TCP 的连接:
  TCP 把连接作为最基本的抽象. TCP 连接的端点叫做套接字(socket), 端口号**拼接到(concatenated with)**IP 地址即构成了套接字.

可靠传输的工作原理:

• 4.1 停止等待协议:

  • 无差错情况

  • 出现差错:
    接收端接收分组检测出现了差错, 就丢弃分组, 其它什么也不做. 发送端超过了一段时间没有收到确认信息, 即认为发送的分组丢失了, 因而重传前面发送过的分组, 叫超时重传.

    发送端必须暂时保留已发送的分组的副本, 只有收到相应的确认后才能清除保留的分组副本; 分组和确认分组必进行编号, 这样才能明确是哪一个发送出去的分组收到了确认, 而哪一个分组还没有收到确认; 超市计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些.

  • 确认丢失和确认迟到:

    • 确认丢失: 接收端发送的确认丢失了. 这时发送端需要重传数据分组, 接收端又会收到这个分组, 接收端应该丢弃这个重复的分组, 并再次向发送端发送确认, 不能认为发送过确认就不再发送确认.
    • 确认迟到: 接收端发送的确认迟到了, 接收端会收到重复的确认, 然后丢弃重复的确认. 接收端收到重复的分组, 丢弃重复的分组, 并重传确认分组.
      利用确认和重传机制, 可以在不可靠的传输网络上实现可靠的通信, 上面这种可靠传输西医称为自动重传请求 ARQ(Automatic Repeat Request)

  • 信道利用率: 停止等待协议信道利用率太低. T_D 是发送分组所需时间, RTT 是往返时间, T_A 是确认分组发送时间. 则信道利用率计算公式如下:
    $$U=\frac{T_D}{T_D+RTT+T_A}$$

  

• 4.2 连续 ARQ 协议:
  发送方维持一个发送窗口, 发送方每收到一个确认, 就把发送窗口向前滑动一个分组的位置.

TCP 报文段的首部格式:

• 源端口和目的端口: 分别写入源端口号和目的端口号
• 序号: 在一个 TCP 连接中传送的字节里中的每一个字节都按顺序编号. 首部中的序号字段则指的是本报文所发送的数据的第一个字节的序号.
• 确认号: 期望收到对方下一个报文段的第一个数据字节的序号. 若确认号为 N, 则序号 N-1 为止的所有数据都已正确收到.
• 数据偏移: TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远, 以 4 字节为单位, 最大值为 15, 即 TCP 首部的最大长度为 60 字节.
• 保留: 置为 0
• 紧急: 当 URG = 1时, 告诉系统此报文中有紧急数据, 应尽快传送. TCP 就把紧急数据插入到本报文段数据的最前面, 而在紧急数据后面的数据仍然是普通数据. 这时要与首部中**紧急指针(Urgent Pointer)**字段配合使用.
• 确认 ACK(Acknowledgment): 当 ACK = 1 时确认号字段才有效.
• 推送 PSH(PUSH): 接收方收到 PSH = 1 的报文段, 尽快交付应用进程, 不用等到缓存满了才交付, 类似于立即刷新缓存的作用.
• 复位 RST(Reset): 当 RST = 1 时, 表明 TCP 连接中出现严重差错, 必须释放连接, 然后重新建立运输连接.
• 同步 SYN(Synchonization): 在连接建立时用力啊同步序号. 当 SYN = 1 而 ACK = 0 时, 表明这时一个连接请求报文段. 若对方同意建立连接, 则应在相应的报文段中使 SYN = 1 和 ACK = 1. SYN 置为 1 表示这是一个连接请求或连接接受报文.
• 终止 FIN(Finish): 用来释放一个连接. 当 FIN = 1 时, 表明此报文段的发送方的数据已发送完毕, 并呀求释放运输连接.
• 窗口: 窗口值作为接收方让发送方设置其发送窗口的依据.
• 校验和: 校验范围包括首部和数据这两部分.
• 紧急指针: 当 URG = 1 时才有意义.
• 选项: 长度可变
  TCP 报文的最大报文长度 MSS(Maximum Segment Size)指的是 TCP 报文中的数据字段的最大长度. MSS 的默认值时 536 字节.
  

TCP 可靠传输的实现:

• 6.1. 以字节为单位的滑动窗口:

  • 发送窗口表示: 在没有收到 B 的确认的情况下, A 可以连续把窗口内的数据都发送出去. 凡事一斤个发送过的数据, 在未收到确认之前都必须暂时保留, 以便在超时重传时使用.

  • 发送缓存存放:

    • 发送应用程序传送给发送方 TCP 准备发送的数据
    • TCP 已经发送出但尚未受到确认的数据

  • 接收缓存存放:

    • 按序到达的、但尚未被接收应用程序读取的数据
    • 未按序到达的数据
• 6.2. 超时重传时间的选择:
  • 加权平均往返时间 RTT_S: \alpha 的推荐值为 0.125
    $$新的RT{T}_S=(1-\alpha )\times (旧的RT{T}_S)+\alpha \times (新的RTT样本)$$
  • 超时重传时间 RTO (RetransmissionTime-Out):
    $$RTO=RT{T}_S+4\times RT{T}_D$$
  • RTT_D 的测量为: 第一次测量时, RTT^D值为测量到的 RTT 样本值的一半. 在后面的测量中, 使用如下的计算公式, \beta 的推荐值为 0.25
    $$新的RT{T}_D=(1-\beta )\times (旧的RT{T}_D)+\beta \times |RT{T}_S-新的RTT样本|$$

TCP 的流量控制:

• 7.1. 利用滑动窗口实现流量控制:
  发送方的发送窗口不能超过接收方给出的接收窗口的数值. 为防止死锁, TCP 为每一个连接设有一个持续计时器(persistence timer), 只要 TCP 连接的一方受到对方的零窗口通知, 就启动持续计时器. 若持续计时器设置的时间到期, 就发送一个零窗口探测报文段, 而对方就在确认这个探测报文段时给出了现在的窗口值.

TCP 的拥塞控制:

• 8.1 拥塞:
  对网络中某一资源的需求超过了改资源所能提供的可用部分, 网络的性能就要变坏. 拥塞控制就是防止过多的数据注入到网络中, 这样可以使网络中的路由器或链路不致过载.
• 8.2 TCP 的拥塞控制方法:
  • 慢开始
  • 拥塞避免
  • 快重传
  • 快恢

TCP 的运输连接管理:

• 9.1. TCP 的连接建立:
  一开始, B 的 TCP 服务器进程先创建传输控制块 TCB, 准备接受客户进程的连接请求. 然后服务器进程就处于 LISTEN(收听) 状态, 等待客户的连接请求.

  A 的 TCP 客户进程也是首先创建传输控制模块 TCB. 在打算建立 TCP 连接时, 向 B 发出连接请求报文段, 这时首部中的同步位 SYN = 1, 同时选择一个初始序号 seq = x. SYN 报文段不能携带数据, 但是要消耗掉一个序号. 此时, TCP 客户进程进入 SYN-SENT 状态.

  B 受到连接请求报文段后, 如同意建立连接, 则向 A 发送确认. 在确认报文段中把 SYN 和 ACK 位都置为 1, 确认号是 ack = x + 1, 同时为自己选择一个初始序号 seq = y. 这时 TCP 服务器进程进入 SYN-RCVD 状态.

  TCP 客户进程收到 B 的确认后, 还要向 B 给出确认. 确认报文段的 ACK 置 1, 确认号 ack = y + 1, 而自己的序号 seq = x + 1. A 进入 ESTABLISHED(已建立连接)状态.

  A 最好需要发送一次确认, 是为了防止已失效的连接请求报文段突然有传送到了 B. 假设 A 发出连接请求, 但因连接请求报文丢失而未收到确认. 于是 A 重传一次连接请求. 后来收到了确认, 建立了连接. 如果 A 发出的第一个连接请求报文段并没有丢失, 经过长时间滞留才到达 B. B 认为是 A 又发出了一次新的连接请求. 于是向 A 发出确认报文, 同意建立连接. 如果不采用 A 发送最后一次确认的方式, 此时 B 认为连接已经建立, 等待 A 发送数据, 但是 A 并没有发出建立连接的请求, 因此并不向 B 发送数据. B 的连接资源因此被浪费掉了.

• 9.2 TCP 的连接释放:
  A 的应用进程先向其 TCP 发出连接释放报文段, 并停止发送数据, 主动关闭 TCP 连接. A 把连接释放报文段首部的终止控制位 FIN 置 1, 其序号 seq = u, 它等于前面已传送过的数据的最后一个字节的序号加 1. 这时 A 进入 FIN-WAIT-1(终止等待 1) 状态, 等待 B 的确认.

  B 受到连接释放报文段后即发出确认, 确认号是 ack = u + 1, 而这个报文段自己的序号是 v, 等于前面已传送过的数据的最后一个字节的序号加 1. 然后 B 进入 CLOSE-WAIT(关闭等待)状态. TCP 服务器进程这时应通知高层应用进程, 因而从 A 到 B 这个方向的连接就释放了, 这时的 TCP 连接处于**半关闭(half-close)**状态. 此时从 B 到 A 这个方向的连接并未关闭, B 仍然可以向 A 发送数据.

  A 收到来自 B 的确认后, 就进入 FIN-WAIT-2(终止等待2)状态, 等待 B 发出的连接释放报文段.

  若 B 已经没有要向 A 发送的数据, 其应用进程就通知 TCP 释放连接. 这时 B 发出的连接释放报文段必须使 FIN=1. 这时 B 就进入 LAST-ACK(最后确认)状态, 等待 A 的确认.

  A 在受到 B 的连接释放报文段后, 必须对此发出确认. 然后进入到 TIME-WAIT(时间等待)状态. 此时 TCP 连接还没有释放掉, 必须经过**时间等待计时器(TIME-WAIT timer)**设置的时间 2MSL 后, A 才进入到 CLOSED 状态. 时间 MSL 叫做最长报文寿命(Maximum Segment Lifetime).

  A 在 TIME-WAIT 必须等待 2MSL 是为了保证 A 发送的最后一个 ACK 报文能够到达 B. 这个 ACK 报文可能丢失, 因而是处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认. B 会超时重传这个 FIN + ACK 报文段, 而 A 就能在 2MSL 时间内受到这个重传的 FIN + ACK 报文段.
  

参考:
[1] : 计算机网络