《计算机网络》课程笔记——Transport Layer（传输层）

1. transport-layer services（传输层服务）

1.1 Transport services and protocols（传输层服务与协议）

当我们的应用程序需要在不同的计算机之间通信时，我们需要使用传输层服务和协议。传输层协议是运行在计算机上的软件，用于将应用程序消息分段，并在网络上传输这些消息。接收方计算机在接收到这些分段后，会将它们重新组装成原始的应用程序消息，并将它们传递给应用层处理。

在互联网中，有两个主要的传输协议：TCP 和 UDP。TCP 提供可靠的、面向连接的传输服务，可以确保应用程序消息的完整性和可靠性。UDP 则提供了简单的、无连接的传输服务，适合一些对数据可靠性要求不高的应用程序。在编写应用程序时，我们可以根据需要选择使用 TCP 或 UDP 进行数据传输。

1.2 Transport vs. network layer（传输层与网络层对比）

计算机网络中，通信需要在多个层次进行。

• 网络层是在不同主机之间进行通信的层
• 传输层则是在主机内部的不同应用程序进程之间进行通信的层。
• 传输层依赖于网络层提供的服务，同时也增强了网络层的服务能力，实现了应用程序进程之间的可靠通信。
• 通过传输层，不同主机上的应用程序可以通过网络层提供的逻辑通信实现互相传输数据。

通过一个家庭类比来解释计算机网络的层次结构。我们可以将一个家庭视为一个主机：

• 家庭中的孩子们则是主机中的进程。
• 信件是应用程序中的消息
• 将信件分发给家庭中的孩子则相当于传输协议的工作
• 将信件送到对方家庭则类似于网络层协议的工作，就像邮政服务一样。

1.3 Internet transport-layer protocols（Internet传输层协议）

互联网传输层使用的两种协议：

• TCP，它提供了可靠的、有序的数据传输，并实现了拥塞控制、流量控制和连接建立等功能。
• UDP，它提供了不可靠的、无序的数据传输，相当于在IP层的基础上增加了一些简单的功能。
• 这两种协议都不能保证数据传输的延迟和带宽。

2. multiplexing and demultiplexing（多路复用和多路分用）

• 多路复用是指在发送端，将来自多个应用程序的数据打包在一起，并加上一个头部信息，以便在接收端进行多路解复用。
• 多路分用则是指在接收端，根据头部信息将数据解包并交付给正确的应用程序。
• 可以将多路复用比作将多个人的包裹打包成一个大的包裹并标记好收件人和地址，而多路分用就像是根据标记将大包裹拆分成小包裹并送到正确的收件人那里。这样可以确保数据能够正确、高效地传输。

2.1 How demultiplexing works（多路分用如何工作）

• 当数据从源主机发送到目标主机时，数据会被分成多个数据包进行传输，每个数据包会被分配一个源IP地址和目标IP地址，这些地址用于确定数据包的路由和目的地。同时，每个数据包中还会携带一个传输层的数据段，其中包含源端口号和目标端口号。端口号用于将数据包传递到正确的应用程序，因为在同一主机上可能有多个应用程序在同时进行数据通信。

• 接收方主机会使用数据包中的IP地址和端口号将数据包传递到正确的套接字，套接字是应用程序和传输层之间的接口，它用于接收和发送数据。通过使用IP地址和端口号，主机可以将数据包分配给正确的套接字，并确保数据被正确传输和接收。
  

2.2 Connectionless demultiplexing（无连接的多路分用）

当我们在一个主机上创建一个UDP socket时，系统会为该socket分配一个本地端口号，用来标识该socket。

当我们要发送一个UDP数据包时，需要指定目标IP地址和端口号。

当主机收到UDP数据包时，会检查数据包中的目标端口号，然后将数据包分配给对应的本地端口号的socket，这样就可以将数据包正确地交付给相应的应用程序处理。

多个具有相同的目标端口号但不同的源IP地址或源端口号的数据包将被分配给同一个socket来处理。

2.3 Connectionless demux: example（无连接多路分用：示例）

2.4 Connection-oriented demux（面向连接的多路分用）

• TCP套接字（socket）由4元组标识：
  • 源IP地址
  • 源端口号
  • 目标IP地址
  • 目标端口号
• 多路分用：接收方使用这四个值将段（segment）定向到适当的套接字上
• 服务器主机可能支持许多同时的TCP套接字：
  • 每个套接字由其自己的4元组标识
• web服务器为每个连接的客户端使用不同的套接字
  • 非持久性HTTP将为每个请求使用不同的套接字

2.5 Connection-oriented demux: example（面向连接的多路分用：示例）

3. connectionless transport: UDP（无连接传输：UDP）

3.1 UDP: User Datagram Protocol [RFC 768]（用户数据报协议 [RFC 768]）

用户数据报协议（UDP）是一种互联网传输协议，被称为“不加装饰的”或“基本的”传输协议。

• UDP提供了一种“尽力而为”的服务，也就是说，它不能保证传输数据的可靠性，因为UDP数据报可能会丢失或以错乱的顺序到达应用程序。
• UDP是一种无连接的协议，发送方和接收方之间没有握手过程。
• 每个UDP数据报都是独立处理的，而不依赖于其他数据报。

UDP主要应用于流媒体应用程序（能容忍数据丢失，对数据传输速率敏感）、DNS（域名系统）和SNMP（简单网络管理协议）等场景。

• 如果需要可靠的数据传输，则需要在应用层添加一些错误恢复机制，这些机制通常是特定于应用程序的。

3.2 UDP: segment header（UDP：段头）

UDP协议的优点：

• 不需要进行连接建立，这可以减少一些延迟
• 设计非常简单，不需要在发送方和接收方维护连接状态
• UDP的报头很小，可以减少一些开销
• UDP没有拥塞控制，可以随意发送数据，适合在需要快速传输的情况下使用

3.3 UDP checksum（UDP校验和）

在传输数据时，可能因为信号干扰导致某些比特位被翻转。发送方将数据段看作是一系列16位整数，并对这些整数进行求和操作，得到一个校验和（checksum）。发送方将这个校验和值放入UDP数据段的校验和字段中。接收方在收到数据段后也对其进行校验和操作，并将计算得到的校验和值与发送方发送的校验和值进行比较。

• 如果两个值相同，则说明数据段在传输过程中没有发生错误；
• 如果两个值不同，则说明数据段在传输过程中出现了错误。
• 但是即使计算出的校验和值与发送方发送的校验和值相同，也不能保证数据段没有错误。

3.4 UDP checksum-checking contents（UDP校验和——检查内容）

包括以下三个部分：

• 伪首部（Pseudo head）
• UDP头（UDP head）
• 应用数据（Application data）
  

伪首部是在UDP检验和计算中使用的一种数据结构，用于增强UDP检验和的可靠性。它不是UDP头的一部分，而是在计算UDP检验和时添加到UDP头前面的一段虚构的头部。

伪首部中包括了源IP地址、目的IP地址、协议类型、UDP报文长度等信息，它们是用来保证在传输过程中UDP数据报不被篡改和丢失的。由于UDP没有像TCP那样的确认机制，因此伪首部是在保证UDP数据报传输可靠性方面的重要手段。

3.5 Internet checksum: example（网络校验和：示例）

注意：在加法中，如果最高有效位有进位，则需要将其加到结果中。

4. principles of reliable data transfer（可靠数据传输的原则）

可靠数据传输的原则在应用层、传输层和链路层中都非常重要。这是网络中最重要的十个主题之一！

• rdt_send()：由上层调用（例如，应用程序）。传递数据以传递到接收方上层。

• udt_send()：由rdt调用，将数据包通过不可靠信道传输到接收方。

• deliver_data()：由rdt调用，将数据传递给上层。

• rdt_rcv()：当数据包到达信道的接收端时调用。

不可靠的信道特性将影响可靠数据传输协议（rdt）的复杂程度。

接下来我们要：

• 逐步构建可靠数据传输协议（rdt）的发送方和接收方
• 仅考虑单向的数据传输
  • 但是控制信息会在两个方向上流动。
• 使用有限状态机（FSM）来描述发送方和接收方的行为。在状态机中，每个状态的下一个状态都是由下一个事件唯一确定的。当一个事件发生时，它会导致当前状态转换到下一个状态。在状态转换期间，会执行一系列操作。
  

rdt1.0: reliable transfer over a reliable channel（rdt1.0：在可靠信道上的可靠传输）

• 基础信道完全可靠
  • 没有位错误
  • 没有数据包丢失
• 发送方和接收方分别使用有限状态机
  • 发送方将数据发送到底层信道
  • 接收方从底层信道读取数据
    

rdt2.0: channel with bit errors（带比特错误的信道）

• 信道中可能存在比特错误
  • 使用校验和来检测数据包中是否出现错误。
• 如何从这些错误中恢复：
  • 当接收方收到数据包时，会发送确认（ACK）消息告诉发送方数据包已经接收
  • 如果数据包有错误，则会发送否定确认（NAK）消息。
  • 发送方在收到NAK时会重新发送数据包。
• 这些机制称为自动重传请求（ARQ）协议
• 在rdt2.0中，相比rdt1.0，引入了新的机制：
  • 错误检测
  • 反馈机制（ACK、NAK消息）
  • 重传

rdt2.0: FSM specification（FSM状态机规范）

rdt2.0 has a fatal flaw!（rdt2.0 有一个致命的缺陷！）

如果ACK/NAK损坏了会发生什么？

• 发送方不知道接收方发生了什么！
• 不能简单地进行重发：因为可能会产生重复。

处理重复：

• 如果ACK/NAK已损坏，则发送方会重新传输当前数据包。
• 发送方在每个数据包添加序列号。
• 接收方将丢弃（不会传递）重复的数据包。

rdt2.1: sender, handles garbled ACK/NAKs（rdt2.1：发送方处理错误的ACK/NAK）

rdt2.1: receiver, handles garbled ACK/NAKs（rdt2.1：接收方处理错误的ACK/NAK）

rdt2.1: discussion（rdt2.1：讨论）

发送方:

• 在数据包中添加序列号
• 两个序列号(0、1)就足够了，为什么?
• 必须检查接收到的ACK/NAK是否损坏
• 状态数量是原来的两倍
  • 状态必须“记住”预期数据包的序列号是0还是1

接收方:

• 必须检查接收到的数据包是否是重复的
  • 状态指明预期的数据包序列号是0还是1
• 注意: 接收方无法知道它上次收到的ACK/NAK在发送方是否正常接收

rdt2.2: a NAK-free protocol（rdt2.2：一个无NAK的协议）

• 和rdt2.1拥有相同的功能，但是只使用ACK。
• 接收方不发送NAK，而是发送最后一个正确接收的数据包的ACK。
  • 接收方必须在ACK中包含该数据包的序列号。
• 发送方如果收到重复的ACK，将执行与收到NAK相同的操作：重新传输当前数据包。

rdt2.2: sender, receiver fragments（发送方、接收方FSM部分图）

rdt3.0: channels with errors and loss（rdt3.0: 具有错误和丢失的信道）

新假设：底层通道可能会丢失数据包或ACK

• 因此仅仅依靠校验和、序号、ACK和重传已经不够

解决方案：发送方会在合理的时间内等待ACK

• 如果在此期间没有收到ACK，就会重新发送。
• 如果数据包（或ACK）仅被延迟（而不是丢失），则重传将是重复的
  • 但是序列号已经处理了这个问题。接收方必须指定要ACK的数据包的序列号，这需要倒计时计时器。

rdt3.0 sender

rdt3.0 in action

Performance of rdt3.0（rdt3.0的表现）

虽然 rdt3.0 协议是正确的，但其性能非常差。

比如，如果使用的是1 Gbps的网络，15ms的传输延迟，每个数据包大小为8000比特：

发送方的利用率只有0.00027，吞吐量也只 有33KB /秒，这意味着网络协议对物理资源的使用有一定的限制。简单来说，就是虽然协议是正确的，但在某些情况下，性能表现不佳，不能够充分利用网络带宽。

rdt3.0: stop-and-wait operation（rdt3.0: 停止等待操作）

Pipelined protocols（Pipelined协议）

管道传输协议是指发送方可以同时发送多个数据包（也就是多个数据包“在飞行中”），而不需要等待确认。这样可以利用更多的网络带宽，从而提高数据传输速率。

• 为了实现这种协议，需要对序列号范围进行扩展。
• 并且需要在发送方和/或接收方进行缓冲处理，以保持数据包的顺序。

Pipelining: increased utilization（Pipelining: 增加利用率）

Sliding-window protocol（滑动窗口协议）

窗口

• 已发送但尚未被确认的数据包的序列号范围，该范围位于序列号空间中，窗口大小为N。

窗口滑动：

• 当协议运行时，窗口向前滑动，覆盖序列号空间。

具有流水线处理的协议有两种通用形式：Go-Back-N和Selective Repeat。

Pipelined protocols: overview（Pipelined协议：概述）

Go-back-N:

• 发送方可以一次发送多个数据包，最多有N个未收到确认的数据包
• 接收方会回复一个累积确认，即只确认最后一个连续的数据包
  • 如果接收方发现中间有一个数据包丢失了，它不会确认已经接收到的数据包，直到丢失的数据包被接收到为止
• 发送方会设置一个定时器来检测最早未收到确认的数据包
  • 如果定时器超时，就会重新发送从这个未确认数据包开始的所有数据包

Selective Repeat:

• 发送方可以同时发送多达N个未确认的数据包
• 接收方会对每个已经接收到的数据包单独发送确认消息
• 发送方会为每个未确认的数据包分别维护一个定时器
  • 当定时器超时时，只会重新发送该数据包，而不是之前未确认的所有数据包。

Go-Back-N: sender

• 数据包头部中有一个k比特的序列号
• 可以允许有最多N个未被确认的连续数据包
• ACK会确认包含序列号n在内的所有数据包——“累计确认”
  • 接收方有可能会发送重复的ACK（详见接收方说明）
• 发送方维护一个最早未被确认的数据包的定时器
• 超时会重新发送序列号为n及之后的所有数据包。

GBN: sender extended FSM（GBN：发送方扩展状态机）

GBN: receiver extended FSM（GBN：接收方扩展状态机）

• ACK-only：在正确接收到具有最高顺序号的数据包后，总是发送确认应答
  • 可能会产生重复的确认应答
  • 只需要记住期望的序列号即可
• 如果收到了失序的数据包，则：
  • 直接丢弃（不缓存）
  • 并重新发送具有最高顺序号的数据包的确认应答

GBN in action

例题

数据链路层采用后退N帧（GBN）协议，发送方已经发送了编号为0～7的帧。当计时器超时时，若发送方只收到0、2、3号帧的确认，则发送方需要重发的帧数是多少？分别是那几个帧？

解：根据GBN协议工作原理，GBN协议的确认是累积确认，所以此时发
送端需要重发的帧数是4个，依次分别是4、5、6、7号帧。

Selective repeat（选择重传）

• 接收方会单独确认所有正确接收的数据包
  • 按照顺序缓存数据包，等待递交给上层协议
• 发送方只会重传没有收到确认的数据包
  • 为每个未确认的数据包设置定时器
• 发送窗口
  • N个连续的序列号
  • 限制了已发送但未被确认的数据包的序列号的范围

Selective repeat: sender, receiver windows

发送方：

• 从上层获取数据包：
  • 如果发送方当前窗口中的下一个可用的序列号可以被用来发送数据包，那么发送方就会发送这个数据包
• timeout(n):
  • 重传数据包n，并重新启动定时器
• ACK(n) 在[sendbase，sendbase+N]中：
  • 标记数据包n已接收
  • 如果n是最小的未确认数据包，则将窗口基向下一个未确认的序列号推进

接收方：

• 分组n在[rcvbase，rcvbase+N-1]中
  • 发送ACK(n)
  • 如果接收方收到了一个未按顺序到达的数据包，它将缓存该数据包
  • 当接收方接收到按顺序到达的数据包时，它将将它们交付给上层协议，并将已经缓存的数据包一并交付
• 数据包n在[rcvbase-N，rcvbase-1]中：
  • 发送ACK(n)
• 其他：
  • 忽视

Selective repeat in action

Selective repeat: dilemma（选择重传协议：困境）

考虑下面这种情况：

• 序列号范围：0，1，2，3
• 窗口大小：3
• 接收方无法察觉图中两种情况的区别！
• 在图b中之前已经接收过的数据被当作全新的数据进行接收

思考: 为了避免出现图b中的问题，序列号范围与窗口大小应满足什么关系？

三种滑动窗口协议的比较：

这三种滑动窗口协议都可以在实际环境中使用，它们之间的差异在于效率、复杂性和是否需要缓冲区等方面。

它们的差异在于发送和接收窗口的大小：

• 交替比特协议：
  • 0 ≤ 发送窗口大小 ≤ 1
  • 接收窗口大小为1
• 回退N步协议：
  • 0 ≤ 发送窗口大小 ≤ 序号空间大小 - 1
  • 接收窗口大小为：1
• 选择重传协议：
  • 0 ≤ 发送窗口大小 ≤ 序号空间大小/2
  • 接收窗口大小为：序号空间大小/2

5. connection-oriented transport: TCP（面向连接的传输：TCP）

TCP: Overview（TCP概述）

• 点对点的通信方式
  • 只有一个发送方和一个接收方
• 可靠、有序数据传输
  • 没有消息边界，因为TCP把数据看做一个连续的字节流
• pipelined
  • 拥有拥塞控制和流量控制机制，这两个机制共同作用决定了TCP窗口的大小
• 全双工数据
  • 支持双向数据流
  • MSS：最大分段大小
• 面向连接的协议
  • 通信双方在开始数据交换之前需要进行握手，以建立发送方和接收方的状态信息
• 流量控制机制
  • 确保发送方不会压倒接收方

5.1 segment structure（段结构）

• 序号:在一个TCP连接中传送的字节流中的每-一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号。
• 确认号:期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则证明到序号N-1为止的所有数据都已正确收到。是累积确认的。
• 数据偏移(首部长度) : TCP报文段的数据起始处距离TCP报文段的起始处有多远，以4B位单位，即1个数值是4B。
• 紧急位URG: URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。
• 确认位ACK: ACK=1时确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1。
• 推送位PSH: PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。
• 复位RST: RST=1时， 表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输链接。
• 同步位SYN: SYN=1时， 表明是一个连接请求/连接接受报文。
• 终止位FIN: FIN=1时， 表明此报文段发送方数据已发完，要求释放连接。
• 窗口:指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。
• 检验和:检验首部+数据，检验时要加上12B伪首部，第四个字段为6。
• 紧急指针: URG=1时才有意义，指出本报文段中紧急数据的字节数。
• 选项:最大报文段长度MSS、窗口扩大、时间戳、选择确认…

如果接收方收到了乱序的数据段，TCP 标准并没有规定应该如何处理，这需要实现者自己决定。

5.2 reliable data transfer（可靠数据传输）

• TCP在IP不可靠的服务之上创建了可靠的数据传输服务
  • 使用pipelined分段传输
  • 累积确认
  • 单个重传计时器
• 重传可以由以下事件触发：
  • 超时事件
  • 重复确认

我们首先考虑简化版的TCP发送方：

• 忽略重复的确认消息
• 忽略流量控制、拥塞控制

TCP sender events:（TCP发送方事件）

• 数据从应用层接收后
  • 创建带序列号的数据段
  • 序列号是该段数据中第一个数据字节的字节流编号
  • 如果定时器没有运行，就会启动一个定时器
    • 用于最旧的未确认的数据段
    • 过期时间为TimeoutInterval
• 超时
  • 重传导致超时的数据段
  • 重启计时器
• 收到ACK
  • 如果是之前未确认的数据段
    • 更新已确认的数据段信息
    • 如果仍然有未确认的数据段，则会重新启动定时器

TCP 发送方 (简化版)

TCP: retransmission scenarios（TCP：重传场景）

TCP RTT, 超时时间

问：如何设置TCP的超时时间？

• 要比往返时间RTT长一些
  • 但是RTT是不固定的
• 过短会导致不必要的重传
• 过长则会导致对分组丢失的反应过慢

问：如何往返时间RTT？

• SampleRTT：发送数据段到接收方确认接收所需的单个样本测量时间
• SampleRTT会有变化，想得到更稳定的估算值
  • 对多个最近的SampleRTT进行平均处理

$EstimatedRTT=(1-\alpha )\ast EstimatedRTT+\alpha \ast SampleRTT$

• 指数加权移动平均
• 过去样本对估计的影响呈指数衰减
• 典型值：α = 0.125
  

超时时间：EstimatedRTT（估算的往返时延）加上一个安全时间余量

• 如果过去的样本中，估计的往返时延（EstimatedRTT）的变化很大，那么就需要在超时间隔（timeout interval）中添加一个更大的安全时间余量

SampleRTT和EstimatedRTT之间的偏差，称为DevRTT，计算公式如下：

$DevRTT=(1-\beta )\ast DevRTT+\beta \ast (SampleRTT-EstimatedRTT)$

$(typically,\beta =0.25)$

超时时间计算公式：

$TimeoutInterval=EstimatedRTT+4\ast DevRTT$

TCP ACK generation（TCK ACK的生成）

事件	TCP接收方的操作
接收到按顺序到达、序列号与期望序列号匹配的数据包	接收方会延迟发送ACK（确认信息），等待500ms，看是否有其他数据包一起到达。如果没有其他数据包，就发送ACK。
接收到按顺序到达、序列号与期望序列号匹配、但有一个数据包的ACK仍未发送的数据包	接收方会立即发送一个累计ACK（确认信息），确认两个按顺序到达的数据包
接收到序列号比期望序列号高、有间隔的数据包	接收方会立即发送一个重复的ACK，指示下一个期望的字节的序列号
接收到可以填补间隔的数据包	接收方会立即发送ACK，确认数据包的到达

TCP fast retransmit（TCP快速重传）

• TCP的超时时间通常相对较长：
  • 在重新发送丢失的数据包之前会有较长的延迟。
• 为了检测丢失的分段，TCP通过重复确认来检测丢失的分段。
  • 发送方通常会连续发送多个分段。
  • 如果分段丢失，那么就会产生许多重复的确认消息。

TCP快速重传算法的思想是，如果发送方接收到了3个以上的重复确认消息，就会马上重新发送未确认的分段中最小序列号的那个。因为如果有未确认的分段丢失了，那么这个分段很可能是那个丢失的分段，这时就没有必要等待超时时间了。

5.3 flow control（流量控制）

接收方会通过在发送给发送方的TCP头部中的rwnd值告诉发送方自己还有多少缓存空间可以用来接收数据

• 接收方的缓存大小是通过socket选项设置的，通常默认大小是4096字节
• 很多操作系统可以自动调整缓存大小

发送方会根据接收方的rwnd值来限制自己未被确认的数据量，确保接收方的缓存不会溢出。

5.4 connection management（连接管理）

在交换数据之前，发送方和接收方进行“握手”：

• 同意建立连接（双方都知道对方愿意建立连接）
• 同意连接参数
  

Agreeing to establish a connection（同意建立连接）

思考：两次握手在网络中总是有效吗？

• 不稳定的延迟
• 如果一个消息没有成功到达接收方，发送方会尝试重新发送该消息
• 消息重排（网络中的消息在传输过程中因为经过不同的路径或者在不同的时间到达接收方，导致消息接收的顺序与发送方发送的顺序不同的情况）
• 无法知道对方是否已经收到了它发送的消息

两次握手失败的场景：

TCP三次握手

TCP三次握手状态机

TCP：关闭连接
当客户端和服务器端要关闭连接时，它们各自关闭连接的一侧。客户端和服务器端会发送一个TCP段，其中FIN位被设置为1。收到FIN后，对方会回复ACK。在收到FIN的同时，自己也可以发送一个FIN和ACK的组合。同时关闭连接也可以被处理。

6. principles of congestion control（拥塞控制的原则）

拥塞控制：

• 网络拥塞指的是在网络中有太多的数据源同时发送过多的数据，导致网络无法处理。
• 与流量控制是不同的概念。
• 当网络拥塞时，可能会发生：
  • 数据包丢失（路由器缓冲区溢出）。
  • 导致长时间的延迟（路由器缓冲区排队等待）。
• 网络拥塞是网络中的一个重要问题，被称为十大问题之一。

Approaches towards congestion control（拥塞控制）

端到端拥塞控制：

• 没有网络显式反馈。
• 通过观察端系统观察到的丢失和延迟来推断拥塞。
• TCP采用的方法。

网络辅助拥塞控制：

• 路由器向端系统提供反馈，以帮助其控制拥塞。
  • 路由器可以提供一位表示网络拥塞情况的标志位（如SNA，DECbit，TCP/IP ECN，ATM）。
  • 提供一个明确的速率，表示发送方应该发送的速率。

7. TCP congestion control（TCP 拥塞控制）

TCP congestion control: additive increase multiplicative decrease（TCP拥塞控制：加性增加、乘性减少）

方法：发送方通过增加传输速率（窗口大小），来探测可用的带宽，直到出现数据包丢失为止。

• 加性增加：每经过一个往返时延（RTT），就将拥塞窗口（cwnd）增加一个最大段大小（MSS）的值，逐渐探测网络的可用带宽，直到出现数据包丢失情况。
• 乘性减少：当检测到数据包丢失时，将拥塞窗口的大小减半，以缓解网络拥塞的情况。这种方法通过在发送方和接收方之间进行通信，动态地调整拥塞窗口的大小，从而适应网络状况的变化。
  

TCP Congestion Control: details（TCP拥塞控制：细节）

• cwnd是动态的，取决于感知到的网络拥塞情况
• TCP的发送速率大致为：发送cwnd个字节，等待一个往返时间（RTT）来接收确认，然后再发送更多的字节。$rate\approx \frac{wnd}{RTT}bytes/sec$

TCP Slow Start（TCP慢启动）

当TCP连接开始时，发送方的传输速率会指数级地增加，直到第一个丢包事件发生为止

• 初始窗口（cwnd）大小为1个最大报文段长度（MSS）
• 然后每个经过一个RTT时间，cwnd窗口大小加倍
• 收到每个ACK后，就增大窗口大小。

这种增长方式使得初始发送速率较慢，但是会指数级地加快。

TCP: detecting, reacting to loss（TCP：检测和响应丢失）

如果数据包的丢失是由于超时引起的：

• TCP发送方将回到初始窗口（cwnd）大小为1个最大报文段长度（MSS）
• 它将以指数方式增加其窗口大小（和在慢启动一样），直到达到一个阈值，然后以线性方式增加。

如果数据包的丢失是由于三次重复确认引起的：

• 表明网络还可以传输一些数据包
• 窗口大小减半，并以线性方式增加窗口大小。

如果使用TCP Tahoe（TCP拥塞控制算法中的一种），不管是超时还是三次重复确认，窗口大小都将被设置为1。

TCP：TCP: switching from slow start to CA（从慢启动到拥塞避免的切换）

思考：指数增长何时切换为线性增长？

答：当 cwnd 到达超时之前值的一半时。

如何实现？

答：用一个变量叫做ssthresh（slow start阈值），当出现丢包事件时，ssthresh被设置为丢包事件之前cwnd（拥塞窗口大小）的一半。

Summary: TCP Congestion Control（总结：TCP拥塞控制）

8. 总结

传输层服务的原则：

• 多路复用和分用
• 可靠数据传输
• 流量控制
• 拥塞控制

在互联网中的实现：

• 用户数据报协议（UDP）
• 传输控制协议（TCP）

接下来：

• 离开网络“边缘”（应用程序、传输层）
• 进入网络“核心”
• 两个网络层章节：
  • 数据平面
  • 控制平面