The Transport Layer

考纲 6.2 传输协议的要素（寻址、建立连接三次握手、释放连接三次握手、流控制和缓冲） 6.4 UDP 6.5 TCP（TCP服务模型、TCP协议、TCP连接建立、TCP连接释放、TCP滑动窗口协议、Nagle算法、愚笨窗口综合症、TCP拥塞控制、slow start）

传输层架构在网络层提供的服务之上，把数据传递服务从两台计算机之间扩展到了两台计算机上的进程之间，并且服务所需的可靠性程度独立于当前的物理网络

6.1 传输给上层的服务

传输层的最终目标是：向高层提供高效的、可靠的和资源开销合理的数据传输服务

  • 传输层提供了无连接（UDP协议）和面向连接（TCP协议）的服务给应用层

引入传输层的原因：

  • 消除网络层的不可靠性
  • 提供从源端到目的端可靠的、与实际使用的网络无关的的信息传输

传输服务： 传输实体：(Transport Entity):完成传输层功能的硬软件

  • 传输实体利用网络层提供的服务向高层提供有效的、可靠的服务

6.2 传输协议的要素

传输协议与数据链路协议的关系 相似之处：差错控制、流量控制、顺序性 不同之处：以传输层的视角

  • 需要显式明确的地址
  • 连接过程更加复杂（由于网络缓存带来的重复数据）
  • 缓冲区使用方式(传输层同时存在多个连接，带宽变化大，不适用给每个连接固定数量缓冲区的方法)

寻址

当一个应用进程希望与另一个远程应用进程建立连接时，它必须指定要连接到哪个应用进程 通常使用的方法：为那些能够监听连接请求的进程定义相应的传输地址 传输服务访问点（TSAP，Transport Service Access）/端口port

  • 一个应用使用一个TSAP，多个TSAP可以共享一个NSAP，每台主机只有一个IP address
  • TSAPs 是TCP/UDP的端口ports

端口映射器：将服务名字解析为端口

  • 找到一个给定服务名字相对应的TSAP地址，用户需要与端口映射器建立一个连接
  • 用户通过该连接发送一条消息指定想要的服务名字
  • 端口映射器返回相应的TSAP地址
  • 之后，用户释放它与端口映射器之间的连接，再与所需服务建立一个新的连接，一个新服务建立时，必须向端口映射器注册

初始连接协议（进程服务器）：代理不常使用的进程

  • 服务器上存在很多不常使用的服务进程，保持活跃状态是一种浪费
  • 每台希望提供服务的机器由进程服务器充当不频繁使用的服务器的代理
  • 在同一个时间监听一组端口，等待连接请求的到来
  • 一个用户发出连接请求，并制定TSAP地址
  • 如果TSAP对应的服务不在活跃状态，则与进程服务器连接。
  • 进程服务器收到请求，派生出被请求的服务器进程，允许该服务器进程继承与用户的现有连接。

由进程服务器（Process Server）充当代理按需创建服务器--一些服务必须独立于进程服务器

一个特殊的进程称为Name Server名字服务器或Directory Server目录服务器(TSAP众所周知)：用户与名字服务器建立连接，发送服务名称，获得服务进程的TSAP, 释放与名字服务器的连接，与进程服务器建立连接

连接建立

关键问题是：即使数据包可能发生丢失、损坏、延迟和重复，也要保证传输的可靠性

  • 不要把旧的数据包或重复的数据包当作新的数据包来处理 解决方案：
  • 使用一次性的传输地址
    • 每个传输都需要一个地址而且是一个新产生的地址
    • 当连接被释放时，该地址被丢弃，并从来不被重复利用
    • 问题：首次与一个进程建立连接变得异常困难
      • 服务进程没有固定入口，客户端难以知道首次连接应该发往哪个 TSAP
  • 连接发起方为每个连接分配一个唯一标识符（一个序号，每建立一个连接，该序号就递增
    • 该标识符放在每个段（Transport Protocol Data Unit，TPDU）上
    • 当释放某个连接时，每个传输实体可以更新一张内部表，该表列出了所有过期的连接
    • 每当到达一个连接请求，传输实体就检查该表，看它是否属于某一个以前已被释放过的老连接
    • 问题：每个传输实体长时间保存历史信息。如果系统崩溃，将造成信息丢失
  • 不再允许数据包在网络中无期限地生存下去，而是设计一种机制删除在子网中“徘徊”的过时分组
    • 将分组的生命周期限制在一个已知的最大值内：
      • 受限制的子网设计
      • 在每个分组内设计一个跳数计数器
      • 为每个分组加上时间标记(路由器时钟同步)

三次握手方案(three-way handshake) image.png

连接释放

释放连接三次握手 非对称 非对称释放连接是电话系统的工作方式：当一方挂机后，连接就被中断了。 不对称释放（当一侧断开连接时）是突然的，可能会丢失数据。 image.png 对称

对称释放连接是把连接看成两个独立的单向连接，要求单独释放每一个单向连接。 难点在于两个分布式实体需要达成一个共识（确定两方都要断开连接） 类似三次握手：断开请求发送方收到确认后即可断开连接，并返回确认。请求接收方收到请求后回确认，在规定时间内收不到确认也会断开连接 两军对垒问题（two－army problem）可以证明不存在安全的通过 N 次握手实现对称式连接释放的方法 这个协议不总能正确地工作 正常情况下，一个用户发送一个DR (DISCONNECTION QUEST）段来启动释放连接过程。 当该段到达对方，接收端也发回一个DR段，并启动一个计时器，设置计时器的目的是为了防止它的DR丢失。 当这个DR到达时，最初的发送端发回一个ACK段，并且释放连接。最后，当ACK返回后，接收端也释放连接。 image.png

三次握手法释放连接的错误情况： image.png

(a) 最后一个ACK丢失：可以使用计时器来补救。当计时器超时，无论如何连接都被释放 (b) 响应丢失（第二个DR被丢失的情形。发起释放连接的用户接收不到期望的响应，所以它将超时，于是再次尝试释放连接） (c) 响应和随后的DR都丢失（发送端所有重传DR的尝试都失败，经过N次尝试，发送端放弃了，并且释放连接。同时，接收端超时，退出连接）

流控制和缓冲

差错控制确保数据传输具备所需的可靠性，通常指所有的数据均被无差错地传送到目的地。

流量控制是防止快速发送端淹没慢速接收端。

流量控制不考虑子网，仅考虑端到端，拥塞控制要考虑整个收发子网的情况。

发送端窗口大小>cr（网络每秒钟能够处理c个段，往返时间是r） 对于buffer的使用与数据链路层不同： image.png (a) 如果段长度的差异范围很大，如果将缓冲区设置成最大可能的段长，那么当短数据包到来时就会浪费空间：如果将缓冲区设置成比最大的段要小，则长的段就需要多个缓冲区，从而带来额外的复杂性。 (b) 大小可变的缓冲区，优点是能获得更好的内存利用率，付出的代价是缓冲区的管理更加复杂。 (c) 为每个连接使用一个大的循环缓冲区 image.png

6.4 UDP

User Datagram Protocol用户数据报协议 UDP为应用程序提供了一种无需建立连接就可以发送封装的IP数据报的方法

为什么会有UDP

  • 不需要建立连接，延迟小
  • 简单，没有连接状态
  • 报文头小
  • 可以尽快地发送，没有拥塞控制，差错控制，不会重传出错的数据段 image.png

image.png

UDP数据包的格式： image.png UDP检验：

image.png image.png

  • 回卷：加回最低位

6.5 TCP

传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网上提供可靠的端到端字节流而专门设计的一个传输协议。

TCP协议的设计目标是能够动态的适应互联网异构特性 每台支持TCP的机器都有一个TCP传输实体，TCP实体可以是一个库过程、一个用户进程或者内核的一部分。 TCP实体管理TCP流以及与IP层之间的接口 TCP传输实体接收用户数据流，分割成64KB的分段 TCP负责足够快的发送数据报，充分使用网络容量，又不能引起网络拥塞。 TCP要进行重传并且保证递交的数据报在正确的顺序

TCP服务模型

CP提供可靠的端到端字节流服务。发送端和接收端创建套接字（Socket），套接字编号包括32位IP地址和16位端口号 1024以下的端口号保留，用作某些知名的服务，知名端口 image.png 一个TCP连接就是一个字节流，而不是消息流。端到端之间不保留消息的边界。

TCP协议

TCP协议 TCP的一个关键特征是：TCP连接上的每个字节都有它独有的32位序号（按照字节流传输）。 发送端和接收端的TCP实体以段的形式交换数据。

  • TCP段由1个固定的20字节的头以及随后0个或多个数据字节构成。TCP软件决定了段的大小。
  • TCP软件可以把多个写操作的数据积累起来，放到一个段中发送，也可以把一次写操作中的数据分割成多段发送
  • 有两个因素限制了段的长度：
    • ① 包括在TCP头在内的每个段，必须适合IP的65515个字节的有效载荷的要求
    • ② 要考虑每个网络的最大传输单元（MTU, maximum transfer unit），如以太网的1500字节
  • TCP 实体使用的基本协议是具有动态窗口大小的滑动窗口协议。当发送端传送一段时，它启动一个计时器。当该段到达接收方时，接收端的TCP实体返回一个携带了确认号和剩余窗口大小的段（如果有数据要发送的话，则包含数据，否则就不包含数据〉，并且确认号的值等于接收端期望接收的下一个序号。如果发送端的计时器在确认段到达之前超时，则发送端再次发送原来的段。

TCP段格式

image.png

  • 源端口号、目的端口号的取值范围：0-65534

  • 序号seq：用于标记数据部分第一个字节在原始字节流中的位置

    • 起始序号是发送方自己设置的，不一定从0开始

  • 确认号ack/ack_seq:用于反馈，表示序号在该确认号之前的所有字节都已经正确收到（累计确认）

  • 数据偏移/TCP头长度：TCP首部长度 ×4B为单位（4字节的整数倍）

    • 在TCP头部中，并不会专门记录TCP数据部分长度（会根据IP首部、TCP首部的信息计算出来）

  • URG 表示紧急数据应该尽快插队发送

    • URG=1 表示紧急指针有效
    • 紧急指针：紧急数据专用序号，原理与上述序号相同

  • ACK 1bit

    • ACK=0 ack_seq无效
    • ACK=1 ack_seq有效
    • 只有握手1的ACK=0，其他所有TCP报文段都是ACK=1

  • PSH PSH=1 表示希望接收方尽快恢复（用于交互式通信）

  • RST RST=1表示发送方出现严重的差错，必须释放连接

  • SYN SYN=1表示这是一个连接请求或连接接收报文

    • 只有握手1和握手2的SYN=1，其他所有TCP报文段都是SYN=0

  • FIN FIN=1表示此报文段的发送方的数据已发送完毕，要求释放传输连接

    • 只有挥手1和挥手2的FIN=1，其他所有TCP报文段都是FIN=0

  • 窗口rwnd/rcvwnd：表示接收窗口的大小，即从本报文段首部的ack_seq算起，接收方还能接收多少数据（以字节为单位）

TCP连接管理

三次握手： image.png image.png image.png image.png 1）客户端向服务端发送SYN包，其中SYN标志位被置为1，表示客户端请求建立连接。序列号Seq=x 2）服务端接收到SYN包后，向客户端发送一个SYN/ACK包，其中SYN和ACK标志位都被置为1，表示服务端已经接收到客户端的连接请求，并准备好建立连接。序列号Seq=y, 确认号Ack=x+1（表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值） 3）客户端接收到服务端的SYN/ACK包后，向服务端发送一个ACK包，其中ACK标志位被置为1，表示客户端确认服务端的SYN/ACK包已收到。序列号Seq=x+1（表示收到服务器端的确认号Ack，并将其值作为自己的序号值）, 确认号Ack=y+1（表示收到服务器端序号seq，并将其值加1作为自己的确认号Ack的值） 通过三次握手协议，客户端和服务端都确认了彼此的身份，并同意建立连接，从而可以开始传输数据。

释放连接（四次挥手） image.png image.png 释放连接的三次握手（四次挥手）过程：

1）客户端（主动关闭连接的一方）向服务端（被动方）发送一个FIN包，其中FIN标志位被置为1，表示客户端不再发送数据。序列号Seq=u 2）服务端接收到FIN包后，向客户端发送一个ACK包，其中ACK标志位被置为1，表示服务端已经接收到客户端的FIN包。序列号Seq=v，确认号Ack=u+1 3）当服务端不再发送数据时，服务端向客户端发送一个FIN包，其中FIN标志位被置为1，表示服务端不再发送数据。序列号Seq=w，确认号Ack=u+1 4）客户端接收到FIN包后，向服务端发送一个ACK包，其中ACK标志位被置为1，表示客户端已经接收到服务端的FIN包。序列号Seq=u+1，确认号Ack=w+1 通过四次挥手协议，客户端和服务端都确认了彼此的关闭请求，并释放了TCP连接。

TCP滑动窗口

TCP滑动窗口协议 在TCP中，发送方维护一个发送窗口，接收方则会维护一个接收窗口，它们是一个连续的字节序列，表示发送方可以发送的数据范围大小。窗口由两个参数定义：窗口的起始字节和窗口的大小。

工作原理： 发送方和接收方分别维护着发送窗口和接收窗口，发送窗口表示发送方可以发送的数据的范围，接收窗口表示接收方可以缓冲的字节数。

  • 在建立TCP连接时，确定初始的拥塞窗口大小。
  • 当发送方发送数据包后并接收到接收方传来的ACK确认应答后，将发送窗口向前滑动，这样，发送方可以继续发送新的数据。
  • 接收方更新、通告接收窗口大小：接收方在根据已经成功接收的字节数和初始窗口大小计算可用的接收窗口大小，并将新的接收窗口的大小通过TCP 报文段中的窗口大小字段通告给发送方。这个值告诉发送方接收方的当前可用缓冲区空间。
  • 动态调整窗口大小：接收方通过ACK确认号通知发送方已成功接收的数据。发送方可以根据接收方通告的窗口大小进行数据发送控制——如果接收方的窗口变大，发送方可以发送更多的数据；如果接收方的窗口变小，发送方需要适应减少的窗口大小。
  • 流量控制：通过滑动窗口机制，接收方可以动态调整窗口大小以限制发送方的数据发送速率。接收方通过通告窗口大小，告知发送方自己的可用缓冲区空间。发送方根据接收方的窗口大小调整发送速率，确保不会超出接收方的处理能力。

Nagle算法 尽管通过延迟确认减少了接收端给予网络的负载，但是发送端发送多个小数据包的工作方式仍然非常低效（比如， 41 字节的数据包只包含 1 个字节的数据）。避免这种用法的一种办法是采用Nagle算法： 当数据每次以很少量方式进入到发送端时，发送端只是发送第一次到达的数据字节，然后将其余后面到达的字节缓冲起来，直到发送出去的那个数据包被确认；然后将所有缓冲的字节放在一个TCP段中发送出去，并且继续开始缓冲字节，直到下一个段被确认。

这就是说，任何时候只有第一个发送的数据包是小数据包。如果在一个来回时间内应用程序发送了许多数据，那么Nagle 算法可以将这些数据放置在一个段中发送，由此大大地减少所需的带宽。另外，如果应用传递来的数据足够多，多到可以填满一个最大数据段，则该算法也允许发送一个新的段。

愚笨窗口综合症（sillywindow syndrome) 降低TCP性能的另一个问题是低能窗口综合症（sillywindow syndrome) 。当数据以大块形式被传递给发送端TCP实体，但是接收端的交互式应用每次仅读取一个字节数据的时候，这个问题就会发生。 image.png

初始时，接收端的TCP 缓冲区为满，发送端知道这一点（即它有一个大小为0的窗口〉。然后，交互式应用从TCP 流中读取一个字符，这个动作使得接收端的TCP欣喜若狂，它立刻发送一个窗口更新段给发送端，告诉它现在可以发送 1个字节过来。发送端很感激，立即发送1个字节。现在缓冲区又满了，所以，接收端对这 1 字节的数据段进行确认，同时设置窗口大小为 0。这种行为可能会永久地持续下去。

解决方法为：禁止接收端发送只有 1 个字节的窗口更新段。它强制接收端必须等待一段时间，直到有了一定数量的可用空间之后再通告给对方。特别是，只有当接收端能够处理它在建立连接时宣告的最大数据段，或者它的缓冲区一半为空时（相当于两者之中取较小的值〉，它才发送窗口更新段。

TCP拥塞控制

当提供给任何网络的负载超过它的处理能力时，拥塞便会产生。 TCP 维持一个拥塞窗口，窗口大小是任何时候发送端可以往网络发送的字节数。相应的速率则是窗口大小除以连接的往返时间。 流量控制窗口，该窗口指出了接收端可以缓冲的字节数。（流量控制窗口就是接收端窗口）

发送窗口大小=min(接收窗口,拥塞窗口)发送窗口大小=min(接收窗口,拥塞窗口)

slow start 一开始将拥塞窗口大小设为1，然后成倍增加(指数级)拥塞窗口的大小，直到到达所设定的阈值或发生网络拥塞。当达到阈值时，慢启动结束，TCP进入拥塞避免阶段，此时拥塞窗口大小变为线性增长；当网络出现拥塞时，TCP慢启动会减缓发送速度，从而避免网络过载和拥塞的发生。

留下你的想法