Chapter 3

3.1

Knowledge checks 知识检查

Where is transport-layer functionality primarily implemented? 传输层功能主要在哪里实现？

Transport layer functions are implemented primarily at the hosts at the “edge” of the network. 传输层功能主要在网络“边缘”的主机上实现。
Transport layer functions are implemented primarily at each end of a physical link connecting one host/router/switch to another one host/router/switch. 传输层功能主要在将一台主机/路由器/交换机连接到另一台主机/路由器/交换机的物理链路的每一端实现。
Transport layer functions are implemented primarily at the routers and switches in the network. 传输层功能主要在网络中的路由器和交换机上实现。

传输层功能主要在网络“边缘”的主机上实现。这是因为传输层负责端到端的通信，包括数据流控制、可靠性、错误检测和修复等，主要涉及源主机和目标主机之间的数据传输。

因此，正确选项是：

Transport layer functions are implemented primarily at the hosts at the “edge” of the network.

True or False: The transport layer provides for host-to-host delivery service? 对还是错：传输层提供主机到主机的传送服务？

False 错误的
True. 真的

True. 真的

传输层确实提供主机到主机的传送服务，它负责在源主机和目标主机之间的通信和数据传输。

Check all of the services below that are provided by the TCP protocol. 检查 TCP 协议提供的以下所有服务。

A guarantee on the minimum amount of throughput that will be provided between sender and receiver. 保证发送方和接收方之间提供的最小吞吐量。
A message abstraction, that preserves boundaries between message data sent in different socket send calls at the sender. 消息抽象，保留发送者处不同套接字发送调用中发送的消息数据之间的边界。
A byte stream abstraction, that does not preserve boundaries between message data sent in different socket send calls at the sender. 字节流抽象，不保留在发送方的不同套接字发送调用中发送的消息数据之间的边界。
Reliable data delivery. 可靠的数据传输。
A flow-control service that ensures that a sender will not send at such a high rate so as to overflow receiving host buffers. 一种流量控制服务，可确保发送方不会以如此高的速率发送以致溢出接收主机缓冲区。
A guarantee on the maximum amount of time needed to deliver data from sender to receiver. 保证将数据从发送方传送到接收方所需的最大时间。
In-order data delivery 按顺序传送数据
A congestion control service to ensure that multiple senders do not overload network links. 拥塞控制服务可确保多个发送方不会使网络链路过载。

TCP 协议提供的服务包括：

A byte stream abstraction, that does not preserve boundaries between message data sent in different socket send calls at the sender.

Reliable data delivery. 可靠的数据传输。

A flow-control service that ensures that a sender will not send at such a high rate so as to overflow receiving host buffers.

In-order data delivery 按顺序传送数据

A congestion control service to ensure that multiple senders do not overload network links.

不包括的服务：

A guarantee on the minimum amount of throughput that will be provided between sender and receiver.（TCP 不提供最小吞吐量的保证）

A message abstraction, that preserves boundaries between message data sent in different socket send calls at the sender.

A guarantee on the maximum amount of time needed to deliver data from sender to receiver.（TCP 不提供最大传输时间的保证）

Check all of the services below that are provided by the UDP protocol. 检查以下由 UDP 协议提供的所有服务。

A guarantee on the maximum amount of time needed to deliver data from sender to receiver. 保证将数据从发送方传送到接收方所需的最大时间。
A guarantee on the minimum amount of throughput that will be provided between sender and receiver. 保证发送方和接收方之间提供的最小吞吐量。
A flow-control service that ensures that a sender will not send at such a high rate so as to overflow receiving host buffers. 一种流量控制服务，可确保发送方不会以如此高的速率发送以致溢出接收主机缓冲区。
A byte stream abstraction, that does not preserve boundaries between message data sent in different socket send calls at the sender. 字节流抽象，不保留在发送方的不同套接字发送调用中发送的消息数据之间的边界。
A message abstraction, that preserves boundaries between message data sent in different socket send calls at the sender. 消息抽象，保留发送者处不同套接字发送调用中发送的消息数据之间的边界。
Reliable data delivery. 可靠的数据传输。
In-order data delivery 按顺序传送数据
A congestion control service to ensure that multiple senders do not overload network links. 拥塞控制服务可确保多个发送方不会使网络链路过载。

UDP 协议提供的服务主要是消息抽象，允许在发送者的不同套接字发送调用中保留消息数据之间的边界。它不提供其他服务，如可靠数据传输、顺序传输或流量控制。

The transport layer sits on top of the network layer, and provides its services using the services provided to it by the network layer. Thus it’s important that we know what is meant by the network layer’s “best effort” delivery service. True or False: 传输层位于网络层之上，并使用网络层提供给它的服务来提供其服务。因此，了解网络层的“尽力而为”交付服务的含义非常重要。对或错：

The network layer’s best-effort delivery service means that IP makes its “best effort” to deliver segments between communicating hosts, but it makes no guarantees. In particular, it does not guarantee segment delivery, it does not guarantee orderly delivery of segments, and it does not guarantee the integrity of the data in the segments. 网络层的尽力传送服务意味着 IP 尽最大努力在通信主机之间传送数据段，但它不做任何保证。特别是，它不保证段交付，不保证段的有序交付，也不保证段中数据的完整性。

Correct! The network layer’s best effort service doesn’t really provide much service at all, does it? 正确的！网络层的尽力服务并没有真正提供太多服务，不是吗？、
Nope. The network layer’s best effort service doesn’t really provide much service at all, does it? 没有。网络层的尽力服务并没有真正提供太多服务，不是吗？

正确的！网络层的尽力而为服务确实没有提供太多的保障。它尽最大努力将数据包传递到目标主机，但不保证数据包的到达、顺序或完整性。因此，传输层必须建立在此基础之上，提供更可靠的服务。

解释：

网络层的“尽力而为”交付服务主要体现在以下几个方面：

无保证交付：网络层（例如，IP 协议）会尽力将数据包（称为分段）传送到目标主机，但并不保证这些数据包一定会到达。例如，数据包可能会因为网络拥堵、路由器故障或目标主机不可达而丢失。

无序交付：即使数据包成功到达，它们的到达顺序也可能与发送顺序不一致。网络中的路由器可能会根据网络条件选择不同的路径传送数据包，从而导致顺序颠倒。

数据完整性不保证：网络层不负责检查数据包中的数据是否在传输过程中发生了损坏。虽然 IP 协议中有简单的校验和（checksum）机制来检测错误，但这并不等同于保证数据的完整性。

由于这些原因，传输层（如 TCP）需要提供更高层次的服务，确保数据的可靠性和有序性。它通过实现重传机制、序列号和流量控制等技术来弥补网络层的不足，从而为应用层提供可靠的通信服务。

3.2

Knowledge checks 知识检查

What is meant by transport-layer demultiplexing? 传输层解复用是什么意思？

Taking data from one socket (one of possibly many sockets), encapsulating a data chuck with header information – thereby creating a transport layer segment – and eventually passing this segment to the network layer. 从一个套接字（可能是多个套接字之一）获取数据，用标头信息封装数据块 - 从而创建传输层段 - 并最终将该段传递到网络层。
Receiving a transport-layer segment from the network layer, extracting the payload (data) and delivering the data to the correct socket. 从网络层接收传输层报文段，提取有效负载（数据）并将数据传递到正确的套接字。
Taking data from multiple sockets, all associated with the same destination IP address, adding destination port numbers to each piece of data, and then concatenating these to form a transport-layer segment, and eventually passing this segment to the network layer. 从多个套接字获取数据，所有数据都与相同的目标 IP 地址相关联，为每条数据添加目标端口号，然后将它们连接起来形成传输层段，并最终将该段传递到网络层。
Receiving a transport-layer segment from the network layer, extracting the payload, determining the destination IP address for the data, and then passing the segment and the IP address back down to the network layer. 从网络层接收传输层数据段，提取有效负载，确定数据的目标 IP 地址，然后将该数据段和 IP 地址传回网络层。

传输层解复用（demultiplexing）是指将接收到的传输层数据段（segment）中的有效负载（payload）分发到正确的套接字的过程。这一过程的关键步骤如下：

接收传输层段：传输层首先从网络层接收数据段，这些数据段包含了多个信息，包括源端口号、目标端口号和有效负载。

提取有效负载：解复用过程提取数据段中的有效负载部分。这是实际需要传递给应用程序的数据。

确定目标套接字：解复用过程中，传输层使用目标端口号来确定将有效负载传递给哪个套接字。每个套接字都对应于一个特定的端口，因此，通过匹配目标端口号，传输层可以识别出正确的接收应用程序。

传递给正确的套接字：最后，解复用过程将提取到的有效负载交给对应的套接字，使得应用层能够处理接收到的数据。

所以，正确的描述是：
Receiving a transport-layer segment from the network layer, extracting the payload (data), and delivering the data to the correct socket.
这体现了如何将传输层的段中的数据分发到相应的应用程序，这就是解复用的核心概念。

What is meant by transport-layer multiplexing? 传输层复用是什么意思？

Receiving a transport-layer segment from the network layer, extracting the payload, determining the destination IP address for the data, and then passing the segment and the IP address back down to the network layer. 从网络层接收传输层数据段，提取有效负载，确定数据的目标 IP 地址，然后将该数据段和 IP 地址传回网络层。
Receiving a transport-layer segment from the network layer, extracting the payload (data) and delivering the data to the correct socket. 从网络层接收传输层报文段，提取有效负载（数据）并将数据传递到正确的套接字。
Taking data from multiple sockets, all associated with the same destination IP address, adding destination port numbers to each piece of data, and then concatenating these to form a transport-layer segment, and eventually passing this segment to the network layer. 从多个套接字获取数据，所有数据都与相同的目标 IP 地址相关联，为每条数据添加目标端口号，然后将它们连接起来形成传输层段，并最终将该段传递到网络层。
Taking data from one socket (one of possibly many sockets), encapsulating a data chuck with header information – thereby creating a transport layer segment – and eventually passing this segment to the network layer. 从一个套接字（可能是多个套接字之一）获取数据，用标头信息封装数据块 - 从而创建传输层段 - 并最终将该段传递到网络层。

传输层复用（multiplexing）是指将来自多个应用程序或套接字的数据组合在一起，以便通过网络层发送的过程。具体来说，这个过程包括以下几个关键步骤：

数据聚合：传输层从多个套接字（可能来自不同的应用程序）接收数据。这些套接字可能都与同一个目的地 IP 地址相关联，但每个套接字都有其独特的端口号。

封装数据：在复用的过程中，传输层会将每个套接字的数据段封装（encapsulate）在一个传输层段中，并添加必要的头部信息。头部信息通常包括源端口号和目标端口号，这些信息帮助识别数据的来源和去向。

传递给网络层：最后，组合后的传输层段被传递到网络层，以便通过网络发送到目标主机。这样，多个应用程序的传输数据可以在一个网络连接中有效地发送。

因此，Taking data from one socket (one of possibly many sockets), encapsulating a data chunk with header information – thereby creating a transport layer segment – and eventually passing this segment to the network layer 是对传输层复用过程的正确描述。这个选项强调了从多个套接字获取数据并进行封装的关键操作，正是这一过程使得传输层能够有效地管理多个应用程序的数据流。

True or False: When multiple UDP clients send UDP segments to the same destination port number at a receiving host, those segments (from different senders) will always be directed to the same socket at the receiving host. 对或错：当多个 UDP 客户端将 UDP 数据段发送到接收主机上的同一目标端口号时，这些数据段（来自不同的发送方）将始终定向到接收主机上的同一套接字。

False 错误的
True 真的

True. 真的

当多个 UDP 客户端将 UDP 数据段发送到接收主机上的同一目标端口号时，这些数据段将始终定向到接收主机上的同一套接字。UDP 协议是无连接的，接收主机根据目标端口号将接收到的数据段分发到对应的套接字。因此，所有发送到同一目标端口的 UDP 数据段都会被定向到与该端口关联的同一套接字。

True or False: When multiple TCP clients send TCP segments to the same destination port number at a receiving host, those segments (from different senders) will always be directed to the same socket at the receiving host. 对或错：当多个 TCP 客户端将 TCP 段发送到接收主机上的同一目标端口号时，这些段（来自不同的发送方）将始终定向到接收主机上的同一套接字。

False 错误的
True 真的

False. 错误的

当多个 TCP 客户端将 TCP 段发送到接收主机上的同一目标端口号时，这些段（来自不同的发送方）不会始终定向到接收主机上的同一套接字。每个 TCP 连接由源 IP 地址、源端口号、目标 IP 地址和目标端口号唯一标识。因此，即使目标端口相同，不同源 IP 地址和端口号的 TCP 段会被定向到不同的套接字。这意味着对于每个独立的 TCP 连接，接收主机会创建不同的套接字来处理这些连接。

True or False: It is possible for two UDP segments to be sent from the same socket with source port 5723 at a server to two different clients. 对或错：两个 UDP 段可以从服务器上源端口 5723 的同一套接字发送到两个不同的客户端。

False 错误的
True 真的

True. 真的

两个 UDP 段确实可以从服务器上源端口 5723 的同一套接字发送到两个不同的客户端。UDP 是无连接的协议，允许从同一源端口的套接字向多个目的地址发送数据。因此，服务器可以使用同一套接字（源端口 5723）同时向不同的客户端（不同的目标 IP 地址和目标端口）发送多个 UDP 段。这种特性使得 UDP 非常适合需要广播或多播的应用场景。

True or False: It is possible for two TCP segments with source port 80 to be sent by the sending host to different clients. 对或错：源端口为 80 的两个 TCP 段有可能由发送主机发送到不同的客户端。

True 真的
False 错误的

True. 真的

源端口为 80 的两个 TCP 段确实可以由发送主机发送到不同的客户端。TCP 是面向连接的协议，允许同一源端口与多个目的端口之间建立独立的连接。因此，尽管源端口相同（在这种情况下为 80），发送主机仍然可以同时与多个客户端（不同的目标 IP 地址和目标端口）建立连接并发送 TCP 段。这种能力使得 Web 服务器能够同时处理来自多个客户端的请求。

3.3

Knowledge checks 知识检查

True or False: On the sending side, the UDP sender will take each application-layer chunk of data written into a UDP socket and send it in a distinct UDP datagram. And then on the receiving side, UDP will deliver a segment’s payload into the appropriate socket, preserving the application-defined message boundary. 对或错：在发送端，UDP 发送方会将每个应用层数据块写入 UDP 套接字，并以不同的 UDP 数据报形式发送。然后在接收端，UDP 会将数据段的有效负载传送到适当的套接字，从而保留应用程序定义的消息边界。

False 错误的
True 真的

True. 真的

在 UDP 协议中，发送方确实会将每个应用层数据块（chunk）写入 UDP 套接字，并以不同的 UDP 数据报形式发送。UDP 是一个无连接的协议，它允许应用程序在发送数据时保留消息的边界。每个通过 UDP 发送的消息都与一个独立的数据报相对应，因此接收方可以准确地获取每个数据块而不需要进一步的处理。

在接收端，UDP 会将每个接收到的数据报的有效负载传递到适当的套接字，并保持应用程序定义的消息边界。这意味着接收方能够识别并处理每个单独的消息，而不会混淆来自不同发送的消息。这种特性使得 UDP 特别适合需要快速传输且不需要复杂连接管理的应用程序，如实时音频和视频流。

Which of the fields below are in a UDP segment header? [Hint: note the use of the word "header" in this question statement.] 以下哪些字段位于 UDP 段标头中？ [提示：请注意此问题陈述中使用的“标题”一词。]

Source IP address 源 IP 地址
Upper layer protocol 上层协议
Internet checksum 互联网校验和
Source port number 源端口号
Data (payload) 数据（有效负载）
Destination port number 目的端口号
Length (of UDP header plus payload) 长度（UDP 标头加负载）
Sequence number 序号

在 UDP 段标头中包含以下字段：

Source port number 源端口号

Destination port number 目的端口号

Length (of UDP header plus payload) 长度（UDP 标头加负载）

Internet checksum 互联网校验和

其他字段如下所述：

Source IP address 源 IP 地址：不在 UDP 段标头中，而是位于 IP 标头中。

Upper layer protocol 上层协议：UDP 标头中没有直接指明，而是在 IP 标头中指定的协议字段（如 TCP 或 UDP）。

Data (payload) 数据（有效负载）：虽然有效负载是 UDP 段的一部分，但它不在标头中，而是附加在标头之后。

Sequence number 序号：此字段属于 TCP 标头而不是 UDP 标头，UDP 不提供序列号功能。

Why is the UDP header length field needed? 为什么需要 UDP 头长度字段？

1. and (b) above 上述(a)和(b)
Because this field is needed in TCP as well. 因为 TCP 中也需要这个字段。
Because the payload section can be of variable length, and this lets UDP know where the segment ends. 因为有效负载部分的长度可以是可变的，这让 UDP 知道该段的结束位置。
To make the header and even number of bytes 使头部和字节数为偶数

UDP 头长度字段的必要性是：

因为有效负载部分的长度可以是可变的，这让 UDP 知道该段的结束位置。

这个字段允许接收方确定 UDP 数据报的总长度，从而正确地解析出有效负载的边界。这在网络通信中非常重要，因为不同的 UDP 数据报可能携带不同长度的数据。

Over what set of bytes is the checksum field in the UDP header computed over? UDP 标头中的校验和字段是根据哪一组字节计算的？

The entire UDP segment, except the checksum field itself. 整个 UDP 段，除了校验和字段本身。
Just the UDP header but not the payload. 只有 UDP 标头，但没有有效负载。
The entire UDP segment, except the checksum field itself, and the IP sender and receive address fields 整个 UDP 段，除了校验和字段本身以及 IP 发送方和接收地址字段

UDP 头中的校验和字段是根据：

整个 UDP 段，除了校验和字段本身以及 IP 发送方和接收地址字段 计算的。

校验和计算包括 UDP 头和有效负载，但不包括校验和字段自身和 IP 地址字段。这样做是为了确保传输的数据完整性，能够检测到在传输过程中发生的错误。

Which of the following statements are true about a checksum? Hint: more than one statement is true. 以下关于校验和的哪些说法是正确的？提示：不止一个陈述是正确的。

The sender-computed checksum value is often included in a checksum field within a packet header. 发送方计算的校验和值通常包含在数据包标头内的校验和字段中。
The receiver of a packet with a checksum will add up the received bytes, just as the sender did, and compare this locally-computed checksum with the checksum value in the packet header. If these two values are the same then the receiver knowsthat all of the bits in the received packet are correct, i.e., that no bits have been changed during transmission from sender to receiver. 带有校验和的数据包的接收方将像发送方一样将接收到的字节相加，并将本地计算的校验和与数据包标头中的校验和值进行比较。如果这两个值相同，则接收器知道接收到的数据包中的所有位都是正确的，即在从发送器到接收器的传输期间没有改变任何位。
The receiver of a packet with a checksum field will add up the received bytes, just as the sender did, and compare this locally-computed checksum with the checksum value in the packet header. If these two values are different then the receiverknows that one of the bits in the received packet has been changed during transmission from sender to receiver. 带有校验和字段的数据包的接收方将像发送方一样将接收到的字节相加，并将本地计算的校验和与数据包标头中的校验和值进行比较。如果这两个值不同，则接收方知道接收到的数据包中的一位在从发送方传输到接收方的过程中已发生更改。
A checksum is computed at a sender by considering each byte within a packet as a number, and then adding these numbers (each number representing a bytes) together to compute a sum (which is known as a checksum). 发送方通过将数据包中的每个字节视为一个数字，然后将这些数字（每个数字代表一个字节）相加来计算总和（称为校验和），从而在发送方计算校验和。

以下关于校验和的说法是正确的：

发送方计算的校验和值通常包含在数据包标头内的校验和字段中。

带有校验和字段的数据包的接收方将像发送方一样将接收到的字节相加，并将本地计算的校验和与数据包标头中的校验和值进行比较。如果这两个值不同，则接收方知道接收到的数据包中的一位在从发送方传输到接收方的过程中已发生更改。

发送方通过将数据包中的每个字节视为一个数字，然后将这些数字（每个数字代表一个字节）相加来计算总和（称为校验和），从而在发送方计算校验和。

第一个和第二个选项描述了校验和在数据传输中的基本功能和验证过程，而第三个选项说明了校验和的计算方法。

Compute the Internet checksum value for these two 16-bit words: 11110101 11010011 and 10110011 01000100 计算这两个 16 位字的互联网校验和值： 11110101 11010011 和 10110011 01000100

答案：

计算方法：

将 16 位字分成两组：将每个字分成 16 位。
将这两个 16 位字转换为二进制数并相加：将这两个 16 位字进行二进制相加。
处理进位：如果在相加的过程中有进位产生（即结果超过 16 位），需要将进位加到结果的最低有效位上。
取反：将最终的结果进行按位取反以得到校验和。

结果：$01010110 11100111 $

Compute the Internet checksum value for these two 16-bit words: 01000001 11000100 and 00100000 00101011 计算这两个 16 位字的互联网校验和值： 01000001 11000100 和 00100000 00101011

答案：进行一样的处理，结果为$10011110 00010000$。

True or False: When computing the Internet checksum for two numbers, a single flipped bit (i.e., in just one of the two numbers) will always result in a changed checksum. 对或错：当计算两个数字的互联网校验和时，单个翻转位（即，仅在两个数字之一中）将始终导致校验和发生变化。

True 真的
False 错误的

正确答案是 True 真的。

当计算两个数字的互联网校验和时，单个翻转位（即，仅在两个数字之一中）将始终导致校验和的变化。这是因为校验和的计算是通过将两个 16 位字相加，并对其进行求反。翻转一个位将改变该数字的总和，从而影响最终计算得到的校验和。因此，单个翻转位一定会导致校验和发生变化。

True or False: When computing the Internet checksum for two numbers, a single flipped bit in each of the two numbers will always result in a changed checksum. 对或错：计算两个数字的互联网校验和时，两个数字中每个数字的单个翻转位将始终导致校验和发生变化。

True 真的
False 错误的

这个陈述是 False 错误的。

当计算两个数字的互联网校验和时，如果在每个数字中各翻转一个位，可能会出现一种情况，即校验和仍然保持不变。这是因为在加法运算中，一个数字的位翻转可能会影响总和，但如果两个翻转的位相互抵消或在校验和计算的过程中互相影响，最终的校验和可能不发生变化。

还有一道，直接跳过。

3.4

Knowledge checks 知识检查

Consider the purposes/goals/use of different reliable data transfer protocol mechanisms. For the given purpose/goal/use match it to the RDT mechanism that is used to implement the given purpose/goal/use. 考虑不同可靠数据传输协议机制的目的/目标/使用。对于给定的目的/目标/用途，将其与用于实现给定的目的/目标/用途的 RDT 机制相匹配。

Question List: 问题清单：

Lets the sender know that a packet was NOT received correctly at the receiver. 让发送方知道接收方未正确接收数据包。
Used by sender or receiver to detect bits flipped during a packet’s transmission. 发送方或接收方使用它来检测数据包传输过程中翻转的位。
Allows for duplicate detection at receiver. 允许在接收器处进行重复检测。
Lets the sender know that a packet was received correctly at the receiver. 让发送方知道接收方已正确接收到数据包。
Allows the receiver to eventually receive a packet that was corrupted or lost in an earlier transmission. 允许接收方最终接收到在先前传输中损坏或丢失的数据包。

Answer List: 答案列表：

ACK 确认
Checksum 校验和
Retransmission 重传
Sequence numbers 序列号
NAK

答案： 52413。

好的，让我们逐一匹配问题清单中的每个目的/目标/用途与相应的 RDT 机制：

Let the sender know that a packet was NOT received correctly at the receiver. > 让发送方知道接收方未正确接收数据包。

匹配机制：NAK

解释： NAK（Negative Acknowledgment）用于通知发送方接收方未正确接收到某个数据包。接收方发送一个 NAK 消息，告诉发送方哪个数据包需要重新发送。

Used by sender or receiver to detect bits flipped during a packet’s transmission. > 发送方或接收方使用它来检测数据包传输过程中翻转的位。

匹配机制：Checksum

解释： 校验和（Checksum）是一种用于检测数据包传输过程中错误的技术。发送方计算数据包的校验和并附带发送，接收方收到数据包后重新计算校验和并与发送方的校验和进行比较，如果不一致则说明数据包在传输过程中发生了错误。

Allows for duplicate detection at receiver. > 允许在接收器处进行重复检测。

匹配机制：Sequence numbers

解释： 序列号（Sequence numbers）用于标识每个数据包的顺序。接收方通过检查序列号来检测重复的数据包，避免重复处理同一个数据包。

Let the sender know that a packet was received correctly at the receiver. > 让发送方知道接收方已正确接收到数据包。

匹配机制：ACK

解释： 确认（ACK）用于通知发送方接收方已正确接收到某个数据包。接收方发送一个 ACK 消息，告诉发送方哪个数据包已被成功接收。

Allows the receiver to eventually receive a packet that was corrupted or lost in an earlier transmission. > 允许接收方最终接收到在先前传输中损坏或丢失的数据包。

匹配机制：Retransmission

解释： 重传（Retransmission）是指当接收方检测到数据包丢失或损坏时，发送方重新发送该数据包，以确保接收方最终能够接收到完整且正确的数据包。

综上所述，匹配结果如下：

Let the sender know that a packet was NOT received correctly at the receiver.

匹配机制：NAK

Used by sender or receiver to detect bits flipped during a packet’s transmission.

匹配机制：Checksum

Allows for duplicate detection at receiver.

匹配机制：Sequence numbers

Let the sender know that a packet was received correctly at the receiver.

匹配机制：ACK

Allows the receiver to eventually receive a packet that was corrupted or lost in an earlier transmission.

匹配机制：Retransmission

Consider the rdt 2.0 sender and receiver shown below, with FSM transitions at the sender labeled S1, S2, and S3; and receiver transitions labeled R1 and R2. 考虑如下所示的 rdt 2.0 发送方和接收方，发送方处的 FSM 转换标记为 S1、S2 和 S3；接收器转换标记为 R1 和 R2。

Which of the following sequences of transitions could possibly occur as a result of an initial rdt_send() call at the sender, and possible later message corruption and subsequent error recovery. 作为发送方的初始 rdt_send() 调用的结果，可能会发生以下哪种转换序列，以及可能的后续消息损坏和随后的错误恢复。

S1, R1, S3
S1, R2, S2
S1, S2, S3
S1, R1, S2, R2,S3
S1, R1, S2, R1, S3
S1, R2, S3
S1, R1, S2

为了理解为什么答案是 4、6、7，我们需要详细分析 rdt 2.0 协议的工作原理及其状态转换图。rdt 2.0 是一个简单的可靠数据传输协议，用于在不可靠的网络中实现可靠的数据传输。以下是 rdt 2.0 的状态转换图及其解释：

发送方（Sender）的状态转换

初始状态（Idle）: 等待调用 rdt_send()。

等待确认（Wait for ACK）: 发送数据包后，等待接收方的确认。

接收方（Receiver）的状态转换

初始状态（Idle）: 等待接收数据包。

等待数据包（Wait for Data Packet）: 接收到数据包后，发送确认。

状态转换

S1: 发送数据包，从初始状态（Idle）转移到等待确认状态（Wait for ACK）。

S2: 超时后重传数据包，保持在等待确认状态（Wait for ACK）。

S3: 收到正确的 ACK，从等待确认状态（Wait for ACK）返回初始状态（Idle）。

R1: 收到正确的数据包，发送 ACK，从初始状态（Idle）转移到等待数据包状态（Wait for Data Packet）。

R2: 收到错误的数据包，发送 NAK，保持在等待数据包状态（Wait for Data Packet）。

分析每个选项

S1, R1, S3

发送数据包（S1），接收方收到正确的数据包并发送 ACK（R1），发送方收到正确的 ACK 并回到初始状态（S3）。

这是一个有效的序列。

S1, R2, S2

发送数据包（S1），接收方收到错误的数据包并发送 NAK（R2），发送方不会进入超时重传状态（S2），因为 NAK 不会触发超时。

这不是一个有效的序列。

S1, S2, S3

发送数据包（S1），超时后重传数据包（S2），收到正确的 ACK 并回到初始状态（S3）。

这是一个有效的序列，但前提是必须先有一个超时事件。

S1, R1, S2, R2, S3

发送数据包（S1），接收方收到正确的数据包并发送 ACK（R1），发送方没有立即收到 ACK，超时后重传数据包（S2），接收方收到错误的数据包并发送 NAK（R2），发送方继续等待，最后收到正确的 ACK 并回到初始状态（S3）。

这是一个有效的序列。

S1, R1, S2, R1, S3

发送数据包（S1），接收方收到正确的数据包并发送 ACK（R1），发送方没有立即收到 ACK，超时后重传数据包（S2），接收方再次收到正确的数据包并发送 ACK（R1），发送方收到正确的 ACK 并回到初始状态（S3）。

这是一个有效的序列，但与选项 4 类似，只是没有 NAK。

S1, R2, S3

发送数据包（S1），接收方收到错误的数据包并发送 NAK（R2），发送方继续等待，最后收到正确的 ACK 并回到初始状态（S3）。

这是一个有效的序列，假设发送方在收到 NAK 后继续等待并最终收到正确的 ACK。

S1, R1, S2

发送数据包（S1），接收方收到正确的数据包并发送 ACK（R1），发送方没有立即收到 ACK，超时后重传数据包（S2）。

这是一个有效的序列，但前提是发送方在超时后重传数据包，但还没有收到 ACK。

结论

根据以上分析，选项 4、6、7 都是可能发生的序列。因此，正确答案是 4、6、7。

Consider the rdt2.1 sender and receiver FSMs shown below, with labeled transitions S1 through S6 at the sender, and transitions R1 through R6 at the receiver. The sender and receiver start in the “Wait for call 0 from above” and “Wait for 0 from below” states, respectively. 考虑如下所示的 rdt2.1 发送器和接收器 FSM，其中发送器处标记为 S1 到 S6 转换，接收器处标记为 R1 到 R6 转换。发送方和接收方分别开始于“等待来自上方的呼叫 0”和“等待来自下方的 0”状态。

Suppose that no channel errors occur. A sequence of interleaved sender and receiver transitions is given below. Transitions S1 and S4 are already provided. Choose the sender or receiver transition for the unlabeled transitions x1, x2, x3, and x4 below to indicate the time-ordered sequence of transitions (interleaved sender and receiver transitions) that will result in two messages being delivered at the receiver, with the sender and receiver returning to their initial states (again, given that no channel errors occur). 假设没有发生信道错误。下面给出了交错的发送器和接收器转换序列。已经提供了转换 S1 和 S4。为下面未标记的转换x 1 、 x 2 、 x 3和x 4选择发送者或接收者转换，以指示转换的时间顺序序列（交错的发送者和接收者转换），这将导致在接收者处传递两条消息，发送方和接收方返回到其初始状态（同样，假设没有发生通道错误）。

S1, x1, x2, S4, x3, x4

Question List: 问题清单：

transition x1 过渡x 1
transition x2 过渡x 2
transition x3 过渡x 3
transition x4 过渡x 4

Answer List: 答案列表：

为了确定正确的转换序列，我们需要详细分析 rdt 2.1 协议的状态转换图及其工作原理。以下是详细的步骤和解释：

发送方（Sender）的状态转换

初始状态（Wait for call 0 from above）: 等待调用 rdt_send()。

等待确认状态（Wait for ACK 0 from below）: 发送数据包后，等待接收方的确认。

等待确认状态（Wait for ACK 1 from below）: 发送数据包后，等待接收方的确认。

接收方（Receiver）的状态转换

初始状态（Wait for 0 from below）: 等待接收数据包。

等待数据包状态（Wait for 1 from below）: 接收到数据包后，发送确认。

状态转换

S1: 发送数据包 0，从初始状态（Wait for call 0 from above）转移到等待确认状态（Wait for ACK 0 from below）。

S2: 发送数据包 1，从等待确认状态（Wait for ACK 0 from below）转移到等待确认状态（Wait for ACK 1 from below）。

S3: 收到正确的 ACK 0，从等待确认状态（Wait for ACK 0 from below）返回初始状态（Wait for call 0 from above）。

S4: 收到正确的 ACK 1，从等待确认状态（Wait for ACK 1 from below）返回初始状态（Wait for call 0 from above）。

S5: 超时后重传数据包 0，保持在等待确认状态（Wait for ACK 0 from below）。

S6: 超时后重传数据包 1，保持在等待确认状态（Wait for ACK 1 from below）。

R1: 收到正确的数据包 0，发送 ACK 0，从初始状态（Wait for 0 from below）转移到等待数据包状态（Wait for 1 from below）。

R2: 收到正确的数据包 1，发送 ACK 1，从等待数据包状态（Wait for 1 from below）转移到初始状态（Wait for 0 from below）。

R3: 收到错误的数据包 0，发送 NAK 0，保持在等待数据包状态（Wait for 0 from below）。

R4: 收到错误的数据包 1，发送 NAK 1，保持在等待数据包状态（Wait for 1 from below）.

R5: 收到重复的数据包 0，发送 ACK 0，保持在等待数据包状态（Wait for 1 from below）。

R6: 收到重复的数据包 1，发送 ACK 1，保持在等待数据包状态（Wait for 0 from below）。

给定序列

初始状态：

发送方：Wait for call 0 from above

接收方：Wait for 0 from below

序列：S1, x1, x2, S4, x3, x4

S1: 发送方发送数据包 0，转移到等待确认状态（Wait for ACK 0 from below）。

发送方：Wait for ACK 0 from below

接收方：Wait for 0 from below

x1: 接收方收到数据包 0，发送 ACK 0，转移到等待数据包状态（Wait for 1 from below）。

发送方：Wait for ACK 0 from below

接收方：Wait for 1 from below

匹配转换：R1

x2: 发送方收到 ACK 0，返回初始状态（Wait for call 0 from above）。

发送方：Wait for call 0 from above

接收方：Wait for 1 from below

匹配转换：S3

S4: 发送方发送数据包 1，转移到等待确认状态（Wait for ACK 1 from below）。

发送方：Wait for ACK 1 from below

接收方：Wait for 1 from below

x3: 接收方收到数据包 1，发送 ACK 1，返回初始状态（Wait for 0 from below）。

发送方：Wait for ACK 1 from below

接收方：Wait for 0 from below

匹配转换：R2

x4: 发送方收到 ACK 1，返回初始状态（Wait for call 0 from above）。

发送方：Wait for call 0 from above

接收方：Wait for 0 from below

匹配转换：S4

结论

根据以上分析，未标记的转换 x1、x2、x3 和 x4 应分别为：

x1: R1

x2: S3

x3: R2

x4: S4

因此，答案是6324。

Suppose that the initial message transmission by the sender is corrupted, but that no other message transmissions are corrupted. Match the unlabeled transitions x1, x2, x3, x4, x5 in the time-ordered sequence of transitions below (interleaved sender and receiver transitions) that will occur following the initial S1 transition (which is corrupted), that will result in two messages being delivered at the receiver, with the sender and receiver returning to their initial states (again, given that the initial message transmission by the sender is corrupted). Note that transitions S1, S4, and S6 are already provided below. 假设发送方的初始消息传输已损坏，但其他消息传输没有损坏。将在初始 S1 转换（已损坏）之后发生的以下按时间排序的转换序列（交错的发送器和接收器转换）中的未标记转换x 1 、 x 2 、 x 3 、 x 4 、 x 5进行匹配，这将导致两条消息在接收方处传递，发送方和接收方返回到其初始状态（同样，假设发送方的初始消息传输已损坏）。请注意，下面已经提供了转换 S1、S4 和 S6。

S1 (message corrupted), x1, x2, x3, x4, S4, x5, S6.

Question List: 问题清单：

transition x1 过渡 x 1
transition x2 过渡 x 2
transition x3 过渡 x 3
transition x4 过渡 x 4
transition x5 过渡 x 5

Answer List: 答案列表：

答案：24536 。按照图片进行分析即可。

Suppose that the first packet from the sender is correctly received at the receiver but that ACK message sent from receiver-to-sender is corrupted; all other messages (before or after that ACK) are transmitted error-free. Match the unlabeled transitions x1, x2, x3, x4, x5 in the time-ordered sequence of transitions below (interleaved sender and receiver transitions) that will occur following the initial S1 transition, which is followed by a corrupted ACK transmission, that will result in a message being delivered at the receiver, with the sender and receiver returning to their initial states. Note that some transitions are already provided below. 假设接收方正确接收到来自发送方的第一个数据包，但从接收方到发送方发送的 ACK 消息已损坏；所有其他消息（在该 ACK 之前或之后）均无差错地传输。匹配以下按时间排序的转换序列（交错的发送器和接收器转换)中的未标记转换x 1 、 x 2 、 x 3 、 x 4 、 x 5 ，这些转换将在初始 S1 转换之后发生，随后是损坏的 ACK 传输，这将导致消息被传递到接收者，发送者和接收者返回到它们的初始状态。请注意，下面已经提供了一些转换。

S1, x1 (ACK corrupted), x2, x3, x4, S4, x5, S6.

Question List: 问题清单：

transition x1 过渡 x 1
transition x2 过渡 x 2
transition x3 过渡 x 3
transition x4 过渡 x 4
transition x5 过渡 x 5

Answer List: 答案列表：

答案：15463，按图分析即可。

What is meant by a cumulative acknowledgment, ACK(n)? 累积确认 ACK (n)是什么意思？

A cumulative ACK(n) allows the receiver to let the sender know that it has not received any packets with a new sequence number since the last cumulative ACK(n) was sent. 累积 ACK (n)允许接收方让发送方知道自上次发送累积 ACK (n)以来，它尚未收到任何具有新序列号的数据包。
A cumulative ACK(n) allows the receiver to let the sender know that it has not yet received an ACK for packet with sequence number n. 累积 ACK (n)允许接收方让发送方知道它尚未收到序列号为n 的数据包的 ACK。
A cumulative ACK(n) acks all packets with a sequence number up to and including n as being received. 累积 ACK (n)确认收到的序列号最多为n（包括 n）的所有数据包。

正确的定义是：

累积 ACK (n)确认收到的序列号最多为 n（包括 n）的所有数据包。

具体解释如下：

在传输控制协议（TCP）和其他类似的可靠传输协议中，累积确认（Cumulative Acknowledgment, ACK）是一种机制，用于确认已成功接收到的数据包。具体来说：

累积 ACK (n) 表示接收方已经成功收到了所有序列号小于或等于 n 的数据包。

这种确认方式简化了确认过程，因为接收方不需要为每个单独的数据包发送确认，而是可以一次性确认多个数据包。

例如，如果接收方发送了一个累积 ACK(5)，这意味着接收方已经成功收到了序列号为 0, 1, 2, 3, 4, 和 5 的所有数据包。

这种机制有几个优点：

减少网络流量：通过一次确认多个数据包，减少了确认消息的数量，从而降低了网络负载。

简化处理：发送方可以更容易地跟踪哪些数据包已经被确认，哪些需要重传。

提高效率：减少了不必要的确认消息，提高了整体通信效率。

Suppose a packet is 10K bits long, the channel transmission rate connecting a sender and receiver is 10 Mbps, and the round-trip propagation delay is 10 ms. What is the maximum channel utilization of a stop-and-wait protocol for this channel? 假设数据包长 10K 位，连接发送方和接收方的信道传输速率为 10Mbps，往返传播延迟为 10ms。该通道的停止等待协议的最大通道利用率是多少？

答案：$0.1$。

我们来详细解释如何计算停止等待协议的最大通道利用率。

已知条件：

数据包长度 = 10,000 位（10K 位）

信道传输速率 = 10 Mbps

往返传播延迟 = 10 毫秒（ms）

最大通道利用率计算公式：

停止等待协议的最大通道利用率可以用以下公式表示：

\[ \text{利用率} = \frac{\text{传输时间}}{\text{传输时间} + \text{往返时间}} \]

其中：

传输时间 是指将一个数据包发送到信道上所需的时间。

往返时间（RTT） 是指从发送方到接收方发送数据包、接收方返回 ACK 的整个往返时间。

步骤 1：计算传输时间

传输时间的计算公式是：

\[ \text{传输时间} = \frac{\text{数据包长度}}{\text{信道传输速率}} \]

将已知条件代入：

\[ \text{传输时间} = \frac{10,000 \text{ 位}}{10 \times 10^6 \text{ 位/秒}} = 0.001 \text{ 秒} = 1 \text{ 毫秒} \]

所以，传输时间为 1 毫秒。

步骤 2：确定往返时间（RTT）

题目已给出往返传播延迟为 10 毫秒，因此：

\[ \text{RTT} = 10 \text{ 毫秒} \]

步骤 3：计算通道利用率

将传输时间和往返时间代入通道利用率公式：

\[ \text{利用率} = \frac{\text{传输时间}}{\text{传输时间} + \text{RTT}} = \frac{1 \text{ 毫秒}}{1 \text{ 毫秒} + 10 \text{ 毫秒}} = \frac{1}{11} \approx 0.0909 \]

结论

因此，该信道在停止等待协议下的最大通道利用率约为 0.1（即 10%）。

答案：0.1

Suppose a packet is 10K bits long, the channel transmission rate connecting a sender and receiver is 10 Mbps, and the round-trip propagation delay is 10 ms. What is the channel utilization of a pipelined protocol with an arbitrarily high level of pipelining for this channel? 假设数据包长 10K 位，连接发送方和接收方的信道传输速率为 10Mbps，往返传播延迟为 10ms。对于该通道具有任意高水平的流水线的流水线协议的通道利用率是多少？

答案：$1.0$。

在具有任意高水平的流水线的情况下（即可以在一个往返时间内发送多个数据包），通道的利用率将接近 100%。让我们具体分析一下原因。

已知条件：

数据包长度 = 10,000 位

信道传输速率 = 10 Mbps

往返传播延迟 = 10 毫秒（ms）

流水线协议的通道利用率

在停止等待协议中，每发送一个数据包后，发送方必须等待接收方的确认（ACK）才能发送下一个数据包，因此会浪费大量等待时间，导致通道利用率较低。

而在具有任意高水平的流水线的情况下，发送方不需要等待确认，而是可以在一个往返时间内连续发送多个数据包。这种情况下，通道利用率的计算公式为：

\[ \text{利用率} = \frac{\text{发送数据的时间}}{\text{发送数据的时间} + \text{RTT}} \]

步骤 1：计算传输时间

传输时间计算方法如下：

\[ \text{传输时间} = \frac{\text{数据包长度}}{\text{信道传输速率}} \]

将数据代入：

\[ \text{传输时间} = \frac{10,000 \text{ 位}}{10 \times 10^6 \text{ 位/秒}} = 0.001 \text{ 秒} = 1 \text{ 毫秒} \]

步骤 2：计算在一个 RTT 内可以发送的数据包数量

往返时间（RTT）为 10 毫秒，而每个数据包的传输时间是 1 毫秒。因此，在一个 RTT 时间内可以发送的数据包数量为：

\[ \frac{\text{RTT}}{\text{传输时间}} = \frac{10 \text{ 毫秒}}{1 \text{ 毫秒}} = 10 \text{ 个数据包} \]

在高水平的流水线协议下，发送方可以在一个 RTT 内连续发送 10 个数据包，从而保持信道始终忙碌，因此通道的利用率趋向于 100%。

结论

对于具有任意高水平流水线的协议，通道利用率可以接近 1.0 或 100%，因为信道始终在传输数据，没有浪费时间。

答案：1.0

Suppose a packet is 10K bits long, the channel transmission rate connecting a sender and receiver is 10 Mbps, and the round-trip propagation delay is 10 ms. How many packets can the sender transmit before it starts receiving acknowledgments back? 假设数据包长 10K 位，连接发送方和接收方的信道传输速率为 10Mbps，往返传播延迟为 10ms。发送方在开始接收回确认之前可以传输多少个数据包？

答案： $10$。

在这种情况下，发送方在开始接收确认之前可以传输的数据包数量等于一个往返时间（RTT）内能够传输的总数据量除以每个数据包的大小。

已知条件：

数据包长度 = 10,000 位

信道传输速率 = 10 Mbps

往返传播延迟（RTT） = 10 毫秒（ms）

步骤 1：计算在一个 RTT 内可以传输的总数据量

一个 RTT 表示从发送方发送数据到接收方收到并回复 ACK，发送方再接收到 ACK 的时间。因此，发送方在一个 RTT 内可以传输的数据量为：

\[ \text{RTT 内可以传输的总数据量} = \text{信道传输速率} \times \text{RTT} \]

将数值代入：

\[ \text{RTT 内可以传输的总数据量} = 10 \times 10^6 \text{ 位/秒} \times 0.01 \text{ 秒} = 100,000 \text{ 位} \]

步骤 2：计算发送的数据包数量

每个数据包的大小为 10,000 位，因此在一个 RTT 内可以传输的数据包数量为：

\[ \text{数据包数量} = \frac{\text{RTT 内可以传输的总数据量}}{\text{数据包大小}} = \frac{100,000 \text{ 位}}{10,000 \text{ 位/包}} = 10 \text{ 个数据包} \]

结论

因此，发送方在开始接收确认之前可以传输 10 个数据包。

Which of the following statements about pipelining are true? One or more statements may be true. 以下哪些有关管道的说法是正确的？一项或多项陈述可能是正确的。

With pipelining, a receiver will have to send fewer acknowledgments as the degree of pipelining increases 通过流水线，随着流水线程度的增加，接收者将不得不发送更少的确认
A pipelined sender can have transmitted multiple packets for which the sender has yet to receive an ACK from the receiver. 流水线发送方可能已经传输了多个数据包，但发送方尚未收到来自接收方的 ACK。
With a pipelined sender, there may be transmitted packets “in flight” – propagating through the channel – packets that the sender has sent but that the receiver has not yet received. 对于管道式发送方，可能会存在“传输中”的数据包（通过通道传播），即发送方已发送但接收方尚未收到的数据包。
With pipelining, a packet is only retransmitted if that packet, or its ACK, has been lost. 通过管道传输，仅当数据包或其 ACK 丢失时才会重新传输该数据包。

让我们逐条分析这些关于流水线的陈述，以判断它们是否正确。

1. 随着流水线程度的增加，接收者将不得不发送更少的确认

错误。即使流水线程度增加，接收方仍需为每个数据包发送 ACK。虽然有些协议（如累积确认协议）可以减少 ACK 的数量，但流水线本身不会减少 ACK 的发送量。流水线仅意味着发送方可以连续发送多个数据包，而无需等待每个数据包的 ACK。

2. 流水线发送方可能已经传输了多个数据包，但发送方尚未收到来自接收方的 ACK

正确。流水线允许发送方在不等待 ACK 的情况下发送多个数据包。因此，发送方可能会有多个数据包已发送但还未收到 ACK 的情况，这是流水线的核心特性之一。

3. 对于管道式发送方，可能会存在“传输中”的数据包（通过通道传播），即发送方已发送但接收方尚未收到的数据包

正确。在流水线协议中，数据包可以在通道中传播，即“在途”状态。此时，这些数据包尚未到达接收方，也未被确认，因此在接收方尚未收到的情况下，这些数据包仍在通道中传输。

4. 通过管道传输，仅当数据包或其 ACK 丢失时才会重新传输该数据包

错误。在一些管道协议中（例如 Go-Back-N 协议），即使 ACK 只丢失了一个，但仍可能导致后续的多个数据包被重传。这是因为 Go-Back-N 协议要求接收顺序连续的数据包。如果某个数据包或 ACK 丢失，可能会触发整个“窗口”内的数据包的重传，而不仅仅是丢失的数据包。这种协议会导致比所需更多的重传，流水线协议并不总是仅在数据包或 ACK 丢失时重传特定数据包。

结论

正确的陈述是：

流水线发送方可能已经传输了多个数据包，但发送方尚未收到来自接收方的 ACK。

对于管道式发送方，可能会存在“传输中”的数据包（通过通道传播），即发送方已发送但接收方尚未收到的数据包。

What are some reasons for discarding received-but- out-of-sequence packets at the receiver in GBN? Indicate one or more of the following statements that are correct. GBN 中接收端丢弃已接收但失序的数据包的原因有哪些？指出下列一项或多项正确的陈述。

Discarding an out of sequence packet will really force the sender to retransmit. 丢弃失序的数据包实际上会迫使发送方重新传输。
The sender will resend that packet in any case. 无论如何，发送者都会重新发送该数据包。
If some packets are in error, then its likely that other packets are in error as well. 如果某些数据包有错误，那么其他数据包也可能有错误。
The implementation at the receiver is simpler. 接收器的实现更简单。

我们来逐一分析这些选项，确定哪些是正确的，并解释它们在 Go-Back-N (GBN) 协议中的原因。

1. 丢弃失序的数据包实际上会迫使发送方重新传输

错误。在 GBN 协议中，接收方丢弃失序的数据包并不会直接“迫使”发送方重新传输该数据包。虽然接收方不确认失序的数据包，发送方在未收到 ACK 时会重新发送整个窗口中的数据包，但丢弃失序的数据包并不是强制性因素。发送方可能会在其他条件下（例如超时）重新发送数据包，而不是单纯因为丢弃了失序的数据包。

2. 无论如何，发送者都会重新发送该数据包

正确。在 GBN 协议中，发送方在没有收到确认（ACK）时，会重传包括失序数据包在内的整个窗口中的所有未确认数据包。因此，即使接收方丢弃失序数据包，发送方也会在超时后重新发送这些数据包，直到收到正确的确认。

3. 如果某些数据包有错误，那么其他数据包也可能有错误

错误。虽然在实际传输中存在数据包出错的可能性，但数据包的错误通常是随机的，并且与单个丢失或错误的数据包不一定相关。这意味着一个数据包出错并不必然导致其他数据包也有错误。丢弃失序数据包的原因并不是基于假设其他数据包也会有错误。

4. 接收器的实现更简单

正确。丢弃失序数据包使得 GBN 协议的接收方实现更简单，因为接收方只需检查当前收到的数据包序号是否是期望的序号。如果序号不对，它可以简单地丢弃该数据包，无需缓存失序包、等待缺失的包到达并按顺序重组。相比于接收方需要处理乱序数据包的复杂性（如在选择重传协议中），GBN 的这种简单实现更适合于低复杂度需求的应用。

结论

因此，正确的陈述是：

无论如何，发送者都会重新发送该数据包。

接收器的实现更简单。

这些特点使 GBN 协议的实现更直接，但同时也增加了重传量。

What are some reasons for not discarding received-but- out-of-sequence packets at the receiver in GBN? Indicate one or more of the following statements that are correct. GBN 中接收端不丢弃已接收但失序的数据包的原因有哪些？指出下列一项或多项正确的陈述。

Complex protocols are always better. 复杂的协议总是更好。
By not discarding, the receiver can implicitly let the sender know that it (the sender) does not necessarily have to retransmit that packet. 通过不丢弃，接收方可以隐式地让发送方知道它（发送方）不一定必须重新传输该数据包。
Even though that packet will be retransmitted, its next retransmission could be corrupted, so don’t discard a perfectly well-received packet, silly! 即使该数据包将被重新传输，它的下一次重新传输也可能会被损坏，所以不要丢弃一个完全接收良好的数据包，愚蠢！

选项分析（重新审视）

复杂的协议总是更好。

错误。复杂性并不一定带来好处，反而可能增加错误和实现难度。

通过不丢弃，接收方可以隐式地让发送方知道它（发送方）不一定必须重新传输该数据包。

错误。在 GBN 中，接收方实际上无法向发送方提供关于失序包是否需要重传的隐式信息。由于 GBN 协议的特性，接收方通常只会期望接收顺序的数据包，并不对已接收但失序的包做出相应的确认。

即使该数据包将被重新传输，它的下一次重新传输也可能会被损坏，所以不要丢弃一个完全接收良好的数据包，愚蠢！

正确。这一说法确实反映了不丢弃已接收包的有效理由，保持已接收包可以避免因网络不可靠性带来的潜在数据丢失。

正确结论

即使该数据包将被重新传输，它的下一次重新传输也可能会被损坏，所以不要丢弃一个完全接收良好的数据包，愚蠢！

In the SR receiver window (see diagram below, taken from PPT slides and video), why haven’t the red packets been delivered yet? Check the one or more reasons below that apply. 在 SR 接收窗口中（见下图，来自 PPT 幻灯片和视频），为什么红包还没有发送？检查以下一项或多项适用的原因。

There is a packet with a lower sequence number than any of the red packets that has yet to be received, so in-order delivery of data in the red packets up to the application layer is not possible. 由于有一个数据包的序列号比尚未收到的任何红包的序列号都低，因此无法将红包中的数据按顺序传递到应用层。
Red packets have a lower delivery priority up to the application. 红包对于应用程序来说具有较低的传送优先级。
There is a packet with a higher sequence number than any of the red packets that has yet to be received, so in-order delivery of data in the red packets to the application layer is not yet possible. 由于存在序列号高于尚未接收到的任何红包的数据包，因此尚无法将红包中的数据按顺序传递到应用层。

在选择为什么 SR（Selective Repeat）接收窗口中的红色数据包尚未被传递到应用层的原因时，我们需要考虑 SR 协议的工作方式。SR 协议允许接收方接收出-of-sequence 数据包，但仍然要求按照序列号顺序将数据传递到应用层。

选项分析

由于有一个数据包的序列号比尚未收到的任何红包的序列号都低，因此无法将红包中的数据按顺序传递到应用层。

正确。这是原因之一。在 SR 协议中，如果接收方尚未接收到一个比红色数据包序列号更低的包，则接收方无法将红色包传递给应用层，因为它们依赖于先前的数据包的接收。

红包对于应用程序来说具有较低的传送优先级。

错误。在 SR 协议中，数据包的交付是基于序列号的，所有包（无论颜色或状态）都具有相同的交付优先级。接收方只会传递按顺序到达的包。

由于存在序列号高于尚未接收到的任何红包的数据包，因此尚无法将红包中的数据按顺序传递到应用层。

错误。在 SR 协议中，尽管接收方可能接收到了序列号更高的包，但这并不会阻止红色包的传递。相反，红色包的交付是由较低序列号包的缺失所阻碍的，而不是由于较高序列号包的存在。

正确答案

基于以上分析，正确的选项是：

由于有一个数据包的序列号比尚未收到的任何红包的序列号都低，因此无法将红包中的数据按顺序传递到应用层。

In SR, why does the receiver have to acknowledge packets with sequence numbers that are less than (and to the left of) those in its window, which starts at rcv_base. 在 SR 中，为什么接收方必须确认序列号小于（且位于其左侧）窗口（从rcv_base开始）中的序列号的数据包。

Actually, this ACK retransmission can be ignored and the protocol will still function correctly, but its performance won’t be as good. 实际上，这个 ACK 重传可以忽略，协议仍然可以正常工作，但性能不会那么好。
Because, at the time of the data packet arrival at the receiver, the sender has definitely still not received an ACK for that packet. 因为，当数据包到达接收方时，发送方肯定还没有收到该数据包的 ACK。
Because the sender may not have received an ACK for that packet yet. 因为发送方可能尚未收到该数据包的 ACK。

在选择关于为什么接收方必须确认序列号小于其窗口（从 rcv_base 开始）中的数据包的选项时，我们需要理解 SR（Selective Repeat）协议的工作机制和确认（ACK）过程。

选项分析

实际上，这个 ACK 重传可以忽略，协议仍然可以正常工作，但性能不会那么好。

部分正确，但不适用。尽管忽略 ACK 重传可能不会导致协议的功能失效，但在 SR 协议中，接收 ACK 是确保发送方和接收方之间可靠通信的重要部分，以维护正确的窗口和序列号的状态。

因为，当数据包到达接收方时，发送方肯定还没有收到该数据包的 ACK。

错误。发送方可能已经接收到了某些 ACK，特别是如果接收方在确认一个包的同时接收了多个包。这个选项并没有考虑到 ACK 可能是由于之前的数据包而被接收。

因为发送方可能尚未收到该数据包的 ACK。

正确。这是主要原因。接收方在发送 ACK 时需要确认所有已经接收且按顺序的包。即使这些包的序列号低于接收方窗口的起始序列号（rcv_base），接收方仍然需要确认它们，以便告知发送方这些包已成功接收。这有助于发送方确定哪些包可以安全地从其发送缓存中移除，并防止重复发送。

正确答案

因此，正确的选项是：

因为发送方可能尚未收到该数据包的 ACK。

这个确认过程对于确保数据传输的可靠性至关重要，特别是在发生丢包或错误时。接收方的 ACK 不仅告知发送方哪些数据包已被接收，还允许发送方进行相应的重传或清理其缓冲区。

3.5

Knowledge checks 知识检查

True or False: On the sending side, the TCP sender will take each application-layer chunk of data written into a TCP socket and send it in a distinct TCP segment. And then on the receiving side, TCP will deliver a segment’s payload into the appropriate socket, preserving the application-defined message boundary. 对或错：在发送端，TCP 发送方会将每个应用层数据块写入 TCP 套接字，并在不同的 TCP 段中发送。然后在接收端，TCP 会将数据段的有效负载传送到适当的套接字，从而保留应用程序定义的消息边界。

False. 错误的。
True. 真的。

答案：False 。

这个陈述是错误的。

解释

TCP 数据分段：

在发送端，TCP 发送方会将应用层数据块写入 TCP 套接字。但是，TCP 并不会简单地将每个应用层数据块直接封装成一个单独的 TCP 段发送出去。相反，TCP 会根据当前的拥塞窗口（cwnd）、接收窗口（rwnd）和最大报文段大小（MSS）等因素，将数据分成合适的大小进行发送。

因此，一个应用层数据块可能会被分割成多个 TCP 段，或者多个小的应用层数据块可能会被合并成一个 TCP 段。

消息边界：

TCP 是一个面向字节流的协议，它不保留应用程序定义的消息边界。这意味着，即使应用程序在发送端将数据分成多个独立的消息，这些消息在传输过程中可能会被合并或拆分。

在接收端，TCP 会将接收到的数据按顺序重组，并将其传递给应用程序。接收端的应用程序需要自行处理数据流，以恢复原始的消息边界。

举例说明

假设应用程序发送了两个消息，分别是 "Hello" 和 "World"。

发送端：

应用程序将 "Hello" 写入 TCP 套接字。

应用程序将 "World" 写入 TCP 套接字。

TCP 可能会将这两个消息合并成一个段，例如 "HelloWorld"，或者将它们分成多个段，例如 "Hel" 和 "loWorld"。

接收端：

TCP 将接收到的数据按顺序重组，并传递给应用程序。

应用程序需要自行处理接收到的数据流，以恢复原始的消息边界。例如，应用程序可能需要读取固定长度的数据，或者查找特定的分隔符来区分不同的消息。

因此，TCP 并不保证保留应用程序定义的消息边界，而是提供了一个可靠的字节流服务。应用程序需要自己处理消息边界的问题。

For the given function of a field in the TCP segment, select the name of that field from the pull-down list. 对于 TCP 段中字段的给定功能，从下拉列表中选择该字段的名称。

Question List: 问题清单：

This field contains the port number associated with the sending socket for this TCP segment. 该字段包含与该 TCP 段的发送套接字关联的端口号。
This field contains application data that was written into a socket by the sender of this TCP segment. 该字段包含由该 TCP 段的发送方写入套接字的应用程序数据。
This field contains the index in the sender-to-receiver byte stream of the first byte of that data in the payload carried in this segment. 该字段包含该段中携带的有效负载中该数据的第一个字节在发送方到接收方字节流中的索引。
This field contains the index in the byte stream of the next in-order byte expected at the receiver 该字段包含接收方期望的下一个有序字节在字节流中的索引
If set, this segment cumulatively ACKs all data bytes up to, but not including, the byte index in the ACK value field of this segment. 如果设置，则该段将累积确认所有数据字节，直至（但不包括）该段的 ACK 值字段中的字节索引。
This field contains the number of available bytes in the TCP receiver’s buffer. 该字段包含 TCP 接收方缓冲区中的可用字节数。
This field contains the Internet checksum of the TCP segment and selected fields in the IP datagram header. 该字段包含 TCP 段的 Internet 校验和以及 IP 数据报报头中的选定字段。
This field contains the number of bytes in the TCP header. 该字段包含 TCP 标头中的字节数。

Answer List: 答案列表：

Source port number 源端口号
Header length field 标头长度字段
Sequence number 序号
ACK number field ACK 号字段
Data (or payload). 数据（或有效负载）。
ACK bit 确认位
Receiver advertised window 接收者广告窗口
Checksum 校验和

好的，让我们逐一匹配问题清单中的每个字段功能与相应的字段名称：

This field contains the port number associated with the sending socket for this TCP segment. > 该字段包含与该 TCP 段的发送套接字关联的端口号。

匹配字段：Source port number 源端口号

This field contains application data that was written into a socket by the sender of this TCP segment. > 该字段包含由该 TCP 段的发送方写入套接字的应用程序数据。

匹配字段：Data (or payload). 数据（或有效负载）。

This field contains the index in the sender-to-receiver byte stream of the first byte of that data in the payload carried in this segment. > 该字段包含该段中携带的有效负载中该数据的第一个字节在发送方到接收方字节流中的索引。

匹配字段：Sequence number 序号

This field contains the index in the byte stream of the next in-order byte expected at the receiver > 该字段包含接收方期望的下一个有序字节在字节流中的索引

匹配字段：ACK number field ACK 号字段

If set, this segment cumulatively ACKs all data bytes up to, but not including, the byte index in the ACK value field of this segment. > 如果设置，则该段将累积确认所有数据字节，直至（但不包括）该段的 ACK 值字段中的字节索引。

匹配字段：ACK bit 确认位

This field contains the number of available bytes in the TCP receiver’s buffer. > 该字段包含 TCP 接收方缓冲区中的可用字节数。

匹配字段：Receiver advertised window 接收者广告窗口

This field contains the Internet checksum of the TCP segment and selected fields in the IP datagram header. > 该字段包含 TCP 段的 Internet 校验和以及 IP 数据报报头中的选定字段。

匹配字段：Checksum 校验和

This field contains the number of bytes in the TCP header. > 该字段包含 TCP 标头中的字节数。

匹配字段：Header length field 标头长度字段

综上所述，匹配结果如下：

Source port number 源端口号

Data (or payload). 数据（或有效负载）。

Sequence number 序号

ACK number field ACK 号字段

ACK bit 确认位

Receiver advertised window 接收者广告窗口

Checksum 校验和

Header length field 标头长度字段

希望这些解释对你有所帮助！

Consider the TCP Telnet scenario below (from Fig. 3.31 in text). Why is it that the receiver sends an ACK that is one larger than the sequence number in the received datagram? 考虑下面的 TCP Telnet 场景（来自文本图 3.31）。为什么接收方发送的 ACK 比接收到的数据报中的序列号大 1？

Because TCP sequence numbers always increase by 1, with every new segment, and the TCP receiver always send the sequence number of the next expected segment 因为 TCP 序列号总是随着每个新数据段而增加 1，并且 TCP 接收方总是发送下一个预期数据段的序列号
Because the send-to receiver segment carries only one byte of data, and after that segment is received, the next expected byte of data is just the next byte (i.e., has an index that is one larger) in the data stream. 因为发送到接收方的段仅携带一个字节的数据，并且在接收到该段之后，下一个预期的数据字节就是数据流中的下一个字节（即，具有更大的索引）。

在 TCP 通信中，接收方发送的 ACK（确认号）是基于接收到的数据段中最后一个字节的序列号。让我们分析给出的两个选项，以确定为什么接收方发送的 ACK 比接收到的数据报中的序列号大 1。

选项分析

因为 TCP 序列号总是随着每个新数据段而增加 1，并且 TCP 接收方总是发送下一个预期数据段的序列号。

部分正确，但不够具体。确实，TCP 序列号是单调递增的，ACK 中确认的序列号是基于最后一个成功接收的字节之后的字节。虽然这个选项强调了序列号的递增性，但没有直接说明 ACK 的计算依据。

因为发送到接收方的段仅携带一个字节的数据，并且在接收到该段之后，下一个预期的数据字节就是数据流中的下一个字节（即，具有更大的索引）。

正确。在 TCP 中，ACK 的确认号指的是接收方期望接收到的下一个字节的序列号。如果接收到的数据段仅包含一个字节，那么接收方在成功接收后，期望的下一个字节的序列号将比接收到的字节序列号大 1。因此，如果接收到的数据报的序列号是 N，则发送的 ACK 为 N + 1，表示接收方已成功接收序列号 N 的字节，并期待下一个字节。

正确答案

因此，正确的选项是：

因为发送到接收方的段仅携带一个字节的数据，并且在接收到该段之后，下一个预期的数据字节就是数据流中的下一个字节（即，具有更大的索引）。

这个选项清楚地说明了 ACK 确认的逻辑，即接收方确认的是下一个预期字节的序列号，而不仅仅是接收到的字节。通过这种机制，TCP 确保了可靠的、有序的数据传输。

Suppose that as shown in the figure below, a TCP sender is sending segments with 100 bytes of payload. The TCP sender sends five segments with sequence numbers 100, 200, 300, 400, and 500. Suppose that the segment with sequence number 300 is lost. The TCP receiver will buffer correctly-received but not-yet-in-order segments for later delivery to the application layer (once missing segments are later received). 假设如下图所示，TCP 发送方正在发送具有 100 字节有效负载的数据段。 TCP 发送方发送序列号为 100、200、300、400 和 500 的五个报文段。假设序列号为 300 的报文段丢失。 TCP 接收器将缓冲正确接收但尚未按顺序排列的段，以便稍后传送到应用程序层（一旦稍后接收到丢失的段）。

Complete the sentences below .... 完成下面的句子....

Question List: 问题清单：

After receiving segment 100, the receiver responds with an ACK with value: 接收到段 100 后，接收方用 ACK 进行响应，其值：
After receiving segment 200, the receiver responds with an ACK with value: 收到段 200 后，接收方用 ACK 进行响应，其值：
After receiving segment 500, the receiver responds with an ACK with value: 接收到段 500 后，接收方用 ACK 进行响应，其值：
After receiving the retransmitted segment 300, the receiver responds with an ACK with value: 接收到重传的段 300 后，接收方用 ACK 进行响应，其值为：
The TCP receiver does not respond in the example, with an ACK with value: 在示例中，TCP 接收方没有响应，其 ACK 值如下：

Answer List: 答案列表：

300
200
300, a duplicate ACK 300，重复的 ACK
600
400

答案：200，300，300 duplicate，600，400 。

好的，我们逐项解释每个接收方的 ACK 响应值，尤其是在丢失序列号为 300 的段的情况下。

接收到段 100 后，接收方用 ACK 进行响应，其值为 200：
当接收方收到序列号为 100 的段时，它知道自己已经接收到的字节是 100。由于 TCP 的接收确认机制是基于下一个期望的字节序列号，因此接收方会发送一个 ACK，确认它期待下一个字节的序列号是 200。这表明接收方已经成功接收了所有字节，直到 100，但尚未接收到 200。

收到段 200 后，接收方用 ACK 进行响应，其值为 300：
同样，当接收方收到序列号为 200 的段时，它会更新自己的 ACK 值为 300。这意味着它已成功接收到的字节序列是从 100 到 200，并且它现在期待下一个字节序列号为 300。

接收到段 500 后，接收方用 ACK 进行响应，其值为 300，重复的 ACK：
在此情况下，接收方成功接收了序列号为 500 的段，但由于序列号为 300 的段丢失，它无法交付 300 及后续的段。由于接收方仍然在等待序列号为 300 的段，因此它会发送一个 ACK 值为 300 的响应，这被称为重复 ACK。这表明接收方仍在期待接收 300。

接收到重传的段 300 后，接收方用 ACK 进行响应，其值为 600：
当丢失的段 300 被重新传输并成功接收后，接收方会更新它的 ACK 值为 600。这意味着它已经成功接收到字节序列从 100 到 500，并期待下一个字节序列号为 600。

在示例中，TCP 接收方没有响应，其 ACK 值为 400：
在此示例中，接收方没有收到序列号为 400 的段，因此也不会发送 ACK 确认值为 400。只有在成功接收到某个序列号的段之后，接收方才会确认该序列号加一。因此，它不会对 400 进行响应。

总结一下，接收方通过发送 ACK 确认已接收到的数据，确保发送方能够正确地进行重传。这种机制有助于维护 TCP 的可靠性和有序性。

Consider TCP use of an exponentially weighted moving average (EWMA) to compute the nth value of the estimated RTT: 考虑 TCP 使用指数加权移动平均值 (EWMA) 来计算估计 RTT 的第 n 个值：

EstimatedRTTn = (1- a)*EstimatedRTTn-1 + a*SampleRTTn 估计 RTT n = (1- a)*估计 RTT n -1 + a*SampleRTT n

True or False: with this EWMA algorithm the value of EstimatedRTTn has no dependence on the earlier sample, SampleRTTn-1 对或错：使用此 EWMA 算法， EstimatedRTT n的值不依赖于早期样本SampleRTT n -1

True 真的
False 错误的

答案：错

解释：

在 TCP 使用的指数加权移动平均值 (EWMA) 算法中，估计的 RTT（记为 EstimatedRTTn）是根据前一个估计值 EstimatedRTTn-1 和当前测量的样本 RTT（记为 SampleRTTn）来计算的。具体的公式如下：

$ n = (1 - ) {n-1} + _n $

其中，() 是一个介于 0 和 1 之间的权重因子。

这个公式的含义是：

EstimatedRTTn 是当前估计的 RTT。

EstimatedRTTn-1 是前一个估计的 RTT。

SampleRTTn 是当前测量的样本 RTT。

((1 - )) 是前一个估计值的权重。

() 是当前样本值的权重。

从这个公式可以看出，EstimatedRTTn 的值不仅依赖于当前的样本 SampleRTTn，还依赖于前一个估计值 EstimatedRTTn-1。而 EstimatedRTTn-1 本身又是由更早的样本和估计值计算出来的，因此 EstimatedRTTn 实际上间接地依赖于所有的历史样本值。

具体来说，EstimatedRTTn 的值可以通过递归展开来表示：

$ _n = (1 - ) + _n $

$ n = (1 - )^2 {n-2} + (1 - ) _{n-1} + _n $

继续展开，可以看到 EstimatedRTTn 实际上依赖于所有先前的样本值 SampleRTTn-1, SampleRTTn-2, 等等。

因此，使用此 EWMA 算法，EstimatedRTTn 的值确实依赖于早期样本 SampleRTTn-1。所以，题目中的说法是错误的。

Consider the TCP Telnet scenario below (from Fig. 3.36 in text). What timer-related action does the sender take on the receipt of ACK 120? 考虑下面的 TCP Telnet 场景（来自文本图 3.36）。发送方在收到 ACK 120 后采取什么与计时器相关的操作？

Cancels any running timers. 取消任何正在运行的计时器。
Restarts a timer for the segment with sequence number 92. 重新启动序列号为 92 的段的计时器。
Leaves any currently-running timers running. 让所有当前正在运行的计时器保持运行。

答案：取消任何正在运行的计时器。

解释：

在 TCP 协议中，当发送方收到 ACK（确认）时，它会执行一些与计时器相关的操作，以确保有效地管理数据传输和重传。

取消任何正在运行的计时器：收到 ACK 120 后，发送方确认了序列号为 120 的数据段已经被接收。根据 TCP 的机制，发送方在发送数据段时会启动计时器以监控该数据段的传输。如果该数据段的 ACK 已被接收，表示该数据段成功传输，因此发送方可以取消与该数据段相关的任何计时器。

为什么不重新启动或保持计时器运行：

重新启动计时器的选项通常适用于尚未确认的段。如果 ACK 120 之前的段（如序列号 92）还未被确认，则发送方可能会重启对应的计时器。但是在此情境中，我们假设 ACK 120 是针对有效且已确认的段。

让当前计时器保持运行是不合理的，因为收到 ACK 表明相关数据段已成功传输，继续计时只会浪费资源并可能导致不必要的重传。

因此，正确的操作是取消任何正在运行的计时器。

正确或错误：使用 TCP 的流量控制机制，接收方告诉发送方它有多少可用缓冲区空间（并且发送方始终将未完成的、未确认的、正在传输的数据量限制为小于此数量），但它不是发送方发送的数据可能多于接收方缓冲空间。

False 错误的
True 真的

答案：True 真的

解释：

在 TCP 的流量控制机制中，接收方通过窗口大小（即可用缓冲区空间）来告诉发送方它能够接收的最大数据量。这个窗口大小是动态的，会根据接收方的缓冲区状态不断更新。发送方在发送数据时，会根据接收方反馈的窗口大小来限制未确认的、正在传输的数据量，确保不会超过接收方的可用缓冲区空间。

因此，这个机制的目的是防止发送方发送过多的数据而导致接收方的缓冲区溢出，从而造成数据丢失。因此，陈述是正确的。

Match the description of a TCP connection management message with the name of the message used to accomplish that function. 将 TCP 连接管理消息的描述与用于完成该功能的消息名称相匹配。

Question List: 问题清单：

A message from client to server initiating a connection request. 从客户端到服务器发起连接请求的消息。

A message from server to client ACKing receipt of a SYN message and indicating the willingness of the server to establish a TCP connection with the client. 从服务器到客户端的消息，确认收到 SYN 消息并表明服务器愿意与客户端建立 TCP 连接。

A message indicating that the sending side is initiating the protocol to terminate a connection. 指示发送方正在启动终止连接的协议的消息。

A message sent in response to a request to terminate a connection, ACKing that the side receiving this message is also willing to terminate the connection 响应终止连接请求而发送的消息，确认接收此消息的一方也愿意终止连接

A general purpose error message used during connection set up or tear down to let the other side know that an error has occurred, and that the referenced connection should be shut down. 在连接建立或断开期间使用的通用错误消息，让对方知道发生了错误，并且应该关闭引用的连接。

Answer List: 答案列表：

FIN message FIN 报文
SYNACK message SYNACK 消息
RESET message 重置消息
FINACK message FINACK 消息
SYN mesage 同步消息

以下是 TCP 连接管理消息的描述与相应消息名称的匹配：

A message from client to server initiating a connection request.
选择答案： SYN message 同步消息

A message from server to client ACKing receipt of a SYN message and indicating the willingness of the server to establish a TCP connection with the client.
选择答案： SYNACK message SYNACK 消息

A message indicating that the sending side is initiating the protocol to terminate a connection.
选择答案： FIN message FIN 报文

A message sent in response to a request to terminate a connection, ACKing that the side receiving this message is also willing to terminate the connection.
选择答案： FINACK message FINACK 消息

A general purpose error message used during connection set up or tear down to let the other side know that an error has occurred, and that the referenced connection should be shut down.
选择答案： RESET message 重置消息

总结：

SYN message 用于初始化连接请求。

SYNACK message 用于确认收到 SYN 消息并表示服务器愿意建立连接。

FIN message 用于发送方发起连接终止。

FINACK message 用于响应连接终止请求并确认。

RESET message 用于指示连接中发生错误并应关闭。

Consider TCP’s Fast Retransmit optimization (see Figure 3.37 from the text, below). Of course, the sender doesn't know for sure that the segment with sequence # 100 is actually lost (it can’t see into the channel). Can a sender get three duplicate ACKs for a segment that in fact has not been lost? Which of the following statements are true? Suppose a channel can lose, but will not corrupt, messages. 考虑 TCP 的快速重传优化（参见下文中的图 3.37）。当然，发送方无法确定序列号为#100 的段实际上已丢失（它无法查看通道）。发送方能否获得实际上没有丢失的数据段的三个重复 ACK？以下哪些说法是正确的？假设通道可能会丢失但不会损坏消息。

If the channel can reorder messages, a triple duplicate ACK can occur even though a message is not lost; since it's possible that a message has just been reordered and has not yet arrived when the three duplicate ACKs were generated. 如果通道可以重新排序消息，即使消息没有丢失，也可能会出现三次重复 ACK；因为当生成三个重复的 ACK 时，消息可能刚刚被重新排序并且尚未到达。
If the channel cannot reorder messages, a triple duplicate ACK indicates to the sender that a segment loss has happened for sure. Actually (again assuming the channel cannot corrupt or reorder messages), even a single duplicate ACK would indicate that a segment loss has happed for sure. 如果通道无法重新排序消息，则三次重复 ACK 会向发送方表明肯定发生了分段丢失。实际上（再次假设通道不能损坏或重新排序消息），即使是单个重复的 ACK 也表明肯定发生了分段丢失。

对于 TCP 的快速重传优化，以下是对所给陈述的分析：

If the channel can reorder messages, a triple duplicate ACK can occur even though a message is not lost; since it's possible that a message has just been reordered and has not yet arrived when the three duplicate ACKs were generated.
正确。如果通道允许消息重新排序，则发送方可能会在接收到一条消息（例如序列号为 100 的段）之前，收到针对先前已确认消息的三个重复 ACK。这是因为通道可能已经重新排序了消息，而不是丢失了它。

If the channel cannot reorder messages, a triple duplicate ACK indicates to the sender that a segment loss has happened for sure. Actually (again assuming the channel cannot corrupt or reorder messages), even a single duplicate ACK would indicate that a segment loss has happened for sure.
正确。如果通道不允许重新排序，并且假设消息不会损坏，则收到的三个重复 ACK 确实表明发生了分段丢失。在这种情况下，发送方可以确定由于后续的 ACK 指向同一序列号，意味着某个段在传输过程中确实丢失了。实际上，单个重复的 ACK 也意味着在接收到的 ACK 之前的一个段没有被确认，即很可能是丢失的。

结论：

第一个陈述是正确的，因为重新排序可能导致发送方在未收到特定段的情况下获得重复 ACK。

第二个陈述也是正确的，因为在通道不允许重新排序的情况下，三次重复 ACK 确实表示丢失的段。

3.6

Knowledge checks 知识检查

Consider the five images below. Indicate which of these images suggest the need for flow control (the others would suggest the need for congestion control). 考虑下面的五张图片。指出这些图像中哪些表明需要流量控制（其他图像表明需要拥塞控制）。

A glass overflowing 满溢的玻璃杯
A crowd of people 一群人
A talking head 会说话的头
Car traffic 汽车交通
A penguin crowd 一群企鹅

答案： 1 和 3 。

流量控制和拥塞控制的主要区别在于它们的关注点和作用：

流量控制：主要关注发送方和接收方之间的数据传输速率，确保发送方不会以过快的速度发送数据，导致接收方的缓冲区溢出。流量控制的目的是防止接收方被淹没，确保数据能够被有效处理。

拥塞控制：关注的是整个网络的状态，确保网络中的数据流不会导致拥塞。这涉及到网络的带宽、路由器的处理能力等。

根据这个定义：

满溢的玻璃杯（A glass overflowing）：这个图像直观地传达了接收方的缓冲区溢出的情况，表明发送方发送的数据过快，导致接收方无法处理，反映出需要流量控制。

会说话的头（A talking head）：这个图像可能表示在一种互动或数据交换中，强调了单个发送方与接收方之间的关系。它可能象征着一个有效的交流需要适当的流量控制，以避免信息的溢出或丢失。

相对而言：

一群人（A crowd of people）、汽车交通（Car traffic）、和一群企鹅（A penguin crowd）这三个图像更多地反映了网络层面的拥塞情况，即许多人或车辆集中在一起，可能导致交通拥堵，而不是直接涉及发送和接收之间的流量控制。因此，这些图像更适合用来表示拥塞控制的需求。

所以，答案是 1 和 3，表明需要流量控制的原因是它们直接指向了数据发送和接收之间的处理能力和速率问题。

Consider the figure below, which shows the application-to-application throughput achieved when two senders are competing at a shared bottleneck link. Suppose that when the overall arrival rate, lambdain' (for each sender) is close to R/2, the throughput to the application layer (at each receiver), lambdaout, is equal to 0.8 _ lambdain'. 考虑下图，它显示了当两个发送方在共享瓶颈链路上竞争时所实现的应用程序到应用程序的吞吐量。假设当总体到达率 lambda in ' （对于每个发送方）接近 R/2 时，应用层（在每个接收方）的吞吐量 lambda out 等于 0.8 _ lambda in '。

What fraction of the packets transmitted at the sender are retransmissions? 发送方传输的数据包中有多少部分是重传？

要确定发送方传输的数据包中有多少部分是重传，我们可以使用以下公式和概念：

定义吞吐量：

发送方的到达率为 $\lambda_{\text{in}}' = R/2$。

应用层的吞吐量为 $\lambda_{\text{out}} = 0.8 \cdot \lambda_{\text{in}}'$。

计算有效吞吐量：

因此，每个发送方的有效吞吐量为： \[ \lambda_{\text{out}} = 0.8 \cdot \frac{R}{2} = 0.4R \]

重传率：

设 $X$ 是发送方传输的所有数据包数量，其中包括重传的数据包。

发送的数据包数中，重传的部分可以表示为 $X - \lambda_{\text{out}}$（因为有效的传输是非重传的）。

为了计算重传的比例，我们可以使用重传率：

\[ \text{重传比例} = \frac{\text{重传包数}}{\text{总包数}} = \frac{X - \lambda_{\text{out}}}{X} \]

由于$\lambda_{\text{in}}'$是到达率，即发送的数据包数，所以可以认为 $X = \lambda_{\text{in}}' = R/2$。

代入值：

\[ \text{重传比例} = \frac{\left(\frac{R}{2} - 0.4R\right)}{\frac{R}{2}} = \frac{0.1R}{0.5R} = 0.2 \]

结果：

所以，重传的比例为 0.2 或者说 20% 的数据包是重传的。

因此，发送方传输的数据包中重传的部分占比为 20%。

Which of the following actions are used in network-assisted congestion control (say versus end-end congestion control) to signal congestion. Check all that apply. 以下哪些操作用于网络辅助拥塞控制（例如相对于端到端拥塞控制）来发出拥塞信号。检查所有适用的内容。

A datagram experiences delay at a congested network router, which is then measured by the sender and used to decrease the sending rate. 数据报在拥塞的网络路由器处经历延迟，然后由发送方测量该延迟并用于降低发送速率。
The sender decreases its sending rate in response to a measured increase in the RTT. 发送方响应测量到的 RTT 增加而降低其发送速率。
A router drops a packet at a congested router. 路由器在拥塞的路由器处丢弃数据包。
A router sends an ICMP message to a host telling it to slow down its sending rate. 路由器向主机发送 ICMP 消息，告知其降低发送速率。
A router marks a field in the datagram header at a congested router. 路由器在拥塞路由器的数据报报头中标记一个字段。
The transport-layer receiver informs sender of the size of its (transport-payer receiver) receive window. 传输层接收方通知发送方其（传输付款方接收方）接收窗口的大小。
A sender decreases its sending rate in response to packet loss detected via its transport-layer ACKing. 发送方响应于通过其传输层 ACK 检测到的数据包丢失而降低其发送速率。

选项分析：

A datagram experiences delay at a congested network router, which is then measured by the sender and used to decrease the sending rate.

数据报在拥塞的网络路由器处经历延迟，然后由发送方测量该延迟并用于降低发送速率。

这是端到端拥塞控制的一部分，因为发送方通过测量延迟来调整发送速率，而不是网络设备主动发出信号。因此，不适用。

The sender decreases its sending rate in response to a measured increase in the RTT.

发送方响应测量到的 RTT 增加而降低其发送速率。

这也是端到端拥塞控制的一部分，因为发送方通过测量 RTT 来调整发送速率，而不是网络设备主动发出信号。因此，不适用。

A router drops a packet at a congested router.

路由器在拥塞的路由器处丢弃数据包。

尽管丢包可以间接指示拥塞，但这并不是网络设备主动发出的拥塞信号。因此，不适用。

A router sends an ICMP message to a host telling it to slow down its sending rate.

路由器向主机发送 ICMP 消息，告知其降低发送速率。

这是网络辅助拥塞控制的一种方法，通过 ICMP 消息直接通知发送方降低发送速率。因此，适用。

A router marks a field in the datagram header at a congested router.

路由器在拥塞路由器的数据报报头中标记一个字段。

这是网络辅助拥塞控制的一种方法，通过标记报头中的字段来指示拥塞情况。因此，适用。

The transport-layer receiver informs sender of the size of its (transport-payer receiver) receive window.

传输层接收方通知发送方其（传输付款方接收方）接收窗口的大小。

这是传输层协议（如 TCP）中的一种机制，用于流量控制，但不是网络辅助拥塞控制的一部分。因此，不适用。

A sender decreases its sending rate in response to packet loss detected via its transport-layer ACKing.

发送方响应于通过其传输层 ACK 检测到的数据包丢失而降低其发送速率。

这是端到端拥塞控制的一部分，因为发送方通过 ACK 来检测丢包。因此，不适用。

结论：

正确的选项是：

A router sends an ICMP message to a host telling it to slow down its sending rate.

路由器向主机发送 ICMP 消息，告知其降低发送速率。

A router marks a field in the datagram header at a congested router.

路由器在拥塞路由器的数据报报头中标记一个字段。

这两个方法都是网络设备（如路由器）用来向发送方发出拥塞信号的网络辅助拥塞控制技术。希望这次解释更符合您的需求。

Which of the following actions are associated with end-end congestion control (say versus network-assisted congestion control). Check all that apply. 以下哪些操作与端到端拥塞控制相关（例如与网络辅助拥塞控制相比）。检查所有适用的内容。

A router marks a field in the datagram header at a congested router. 路由器在拥塞路由器的数据报报头中标记一个字段。
A sender decreases its sending rate in response to packet loss detected via its transport-layer ACKing. 发送方响应于通过其传输层 ACK 检测到的数据包丢失而降低其发送速率。
A router drops a packet at a congested router, which causes the transport-layer sender to infer that there is congestion due to the missing ACK for the lost packet. 路由器在拥塞的路由器处丢弃数据包，这会导致传输层发送方由于丢失数据包的 ACK 丢失而推断存在拥塞。
The transport-layer receiver informs sender of the size of its (transport-payer receiver) receive window. 传输层接收方通知发送方其（传输付款方接收方）接收窗口的大小。
The transport-layer sender decreases its sending rate in response to a measured increase in the RTT. 传输层发送方响应测量到的 RTT 增加而降低其发送速率。
A router sends an ICMP message to a host telling it to slow down its sending rate. 路由器向主机发送 ICMP 消息，告知其降低发送速率。
A datagram experiences delay at a congested network router, which is then measured by the sender and used to decrease the sending rate. 数据报在拥塞的网络路由器处经历延迟，然后由发送方测量该延迟并用于降低发送速率。

答案：答案如下，解析看上面即可。

A sender decreases its sending rate in response to packet loss detected via its transport-layer ACKing. 发送方响应于通过其传输层 ACK 检测到的数据包丢失而降低其发送速率。
A router drops a packet at a congested router, which causes the transport-layer sender to infer that there is congestion due to the missing ACK for the lost packet. 路由器在拥塞的路由器处丢弃数据包，这会导致传输层发送方由于丢失数据包的 ACK 丢失而推断存在拥塞。
The transport-layer sender decreases its sending rate in response to a measured increase in the RTT. 传输层发送方响应测量到的 RTT 增加而降低其发送速率。
A datagram experiences delay at a congested network router, which is then measured by the sender and used to decrease the sending rate. 数据报在拥塞的网络路由器处经历延迟，然后由发送方测量该延迟并用于降低发送速率。

Use the pulldown menu to match a congestion control approach to how the sender detects congestion. 使用下拉菜单将拥塞控制方法与发送方检测拥塞的方式相匹配。

Question List: 问题清单：

The sender infers segment loss from the absence of an ACK from the receiver. 发送方根据接收方未收到 ACK 来推断分段丢失。
Bits are set at a congested router in a sender-to-receiver datagram, and bits are in the returned to the sender in a receiver-to sender ACK, to indicate congestion to the sender. 在发送方到接收方的数据报中，在拥塞路由器处设置比特，并且在接收方到发送方的 ACK 中返回给发送方，以向发送方指示拥塞。
The sender measures RTTs and uses the current RTT measurement to infer the level of congestion. 发送方测量 RTT 并使用当前 RTT 测量来推断拥塞程度。

Answer List: 答案列表：

delay-based 基于延迟的
end-end 端对端
network-assisted 网络辅助

好的，让我们逐一匹配每个拥塞控制方法与发送方检测拥塞的方式：

问题清单：

The sender infers segment loss from the absence of an ACK from the receiver.

发送方根据接收方未收到 ACK 来推断分段丢失。

匹配： 这是 端对端 拥塞控制的一部分。发送方通过未收到 ACK 来推断数据包丢失，进而调整发送速率。

Bits are set at a congested router in a sender-to-receiver datagram, and bits are in the returned to the sender in a receiver-to sender ACK, to indicate congestion to the sender.

在发送方到接收方的数据报中，在拥塞路由器处设置比特，并且在接收方到发送方的 ACK 中返回给发送方，以向发送方指示拥塞。

匹配： 这是 网络辅助 拥塞控制的一部分。路由器在数据报中设置比特来指示拥塞，并通过 ACK 返回给发送方。

The sender measures RTTs and uses the current RTT measurement to infer the level of congestion.

发送方测量 RTT 并使用当前 RTT 测量来推断拥塞程度。

匹配： 这是 基于延迟的 拥塞控制。发送方通过测量 RTT 来判断网络拥塞程度。

匹配结果：

The sender infers segment loss from the absence of an ACK from the receiver.

匹配： 端对端 拥塞控制

Bits are set at a congested router in a sender-to-receiver datagram, and bits are in the returned to the sender in a receiver-to sender ACK, to indicate congestion to the sender.

匹配： 网络辅助 拥塞控制

The sender measures RTTs and uses the current RTT measurement to infer the level of congestion.

匹配： 基于延迟的 拥塞控制

最终答案：

The sender infers segment loss from the absence of an ACK from the receiver.

匹配： 端对端

Bits are set at a congested router in a sender-to-receiver datagram, and bits are in the returned to the sender in a receiver-to sender ACK, to indicate congestion to the sender.

匹配： 网络辅助

The sender measures RTTs and uses the current RTT measurement to infer the level of congestion.

匹配： 基于延迟的

希望这些匹配结果符合您的需求。

3.7

Knowledge checks 知识检查

Which of the following statements about TCP’s Additive-increase-multiplicative-decrease (AIMD) algorithm are true? Check all that are true. 以下关于 TCP 的加法-增加-乘法-减少 (AIMD) 算法的陈述哪些是正确的？检查所有内容是否属实。

AIMD cuts the congestion window size, cwnd, in half whenever loss is detected by a triple duplicate ACK. 每当三次重复 ACK 检测到丢失时，AIMD 将拥塞窗口大小 cwnd 减少一半。
AIMD is a end-end approach to congestion control. AIMD 是一种端到端的拥塞控制方法。
AIMD uses the measured RTT delay to detect congestion. AIMD 使用测量的 RTT 延迟来检测拥塞。
AIMD is a network-assisted approach to congestion control. AIMD 是一种网络辅助的拥塞控制方法。
AIMD always cuts the congestion window size, cwnd, in half whenever loss is detected. 每当检测到丢失时，AIMD总是将拥塞窗口大小 cwnd 减少一半。
AIMD cuts the congestion window size,cwnd, i to 1 whenever a timeout occurs. 每当发生超时时，AIMD 就会将拥塞窗口大小 cwnd 、 i 削减为 1。
AIMD uses observed packet loss to detect congestion. AIMD 使用观察到的数据包丢失来检测拥塞。

答案为 1、2 和 6，以下是每个陈述的解释：

AIMD cuts the congestion window size, cwnd, in half whenever loss is detected by a triple duplicate ACK.

这是正确的。当 TCP 接收到三次重复 ACK，表示某个数据包可能丢失，此时 AIMD 算法将拥塞窗口大小cwnd减少一半，以应对潜在的拥塞。

AIMD is an end-to-end approach to congestion control.

这是正确的。AIMD 是一种端到端的拥塞控制方法，主要依靠发送端与接收端之间的反馈进行调整，而不是依赖网络设备的辅助。

AIMD cuts the congestion window size, cwnd, to 1 whenever a timeout occurs.

这也是正确的。当出现超时时，AIMD 会将拥塞窗口大小cwnd重置为 1，这是一种更激进的拥塞控制措施，适用于严重拥塞的情况。

不正确的陈述：

AIMD uses the measured RTT delay to detect congestion.

这是错误的。AIMD 算法主要使用数据包丢失（例如三次重复 ACK 或超时）来检测拥塞，而不是通过测量 RTT（往返时间）延迟来判断。

AIMD is a network-assisted approach to congestion control.

这也是错误的。AIMD 是端到端的控制方法，而不是依赖网络中设备的直接信号或辅助。

AIMD always cuts the congestion window size, cwnd, in half whenever loss is detected.

这是不完全正确的。虽然在三次重复 ACK 时会将cwnd减半，但在超时时，AIMD 会将cwnd重置为 1，而不是减半。

最后一个陈述错误的原因在于，AIMD 不单纯依赖观察到的数据包丢失来检测拥塞。虽然 AIMD 确实会在检测到丢包时减少窗口大小，但它并非直接“观察”数据包丢失，而是通过传输层的机制（例如三次重复 ACK 或超时）间接感知拥塞。因此，这个选项不准确。

How is the sending rate typically regulated in a TCP implementation? TCP 实现中通常如何调节发送速率？

By using the retransmission timeout timer and counting the number of bytes sent since the last timeout to compute the sending rate since that last timeout, and then making sure its sending rate never exceed the rate set by AIMD. 通过使用重传超时定时器，统计上次超时后发送的字节数，计算出上次超时后的发送速率，并保证其发送速率不超过 AIMD 设定的速率。
By keeping a window of size cwnd over the sequence number space, and making sure that no more than cwnd bytes of data are outstanding (i.e, unACKnowledged). The size of cwnd is regulated by AIMD. 通过在序列号空间上保留大小为 cwnd 的窗口，并确保不超过 cwnd 字节的数据未完成（即未确认）。 cwnd 的大小由 AIMD 规定。

正确答案是：

“通过在序列号空间上保留大小为 cwnd 的窗口，并确保不超过 cwnd 字节的数据未完成（即未确认）。cwnd 的大小由 AIMD 规定。”

解释如下：

在 TCP 中，发送速率的调节通过控制拥塞窗口（cwnd）来实现。发送端会确保在任意时刻未确认的数据量不超过当前的 cwnd 大小。cwnd 的大小由 AIMD 算法控制：遇到拥塞时减少，未遇到拥塞时逐步增加。这种机制有助于在不增加丢包或拥塞的情况下适当提高发送速率，并保证网络的稳定性和传输效率。

Which of the following best completes this sentence: "In the absence of loss, TCP slow start increases the sending rate ... " 以下哪一项最能补充这句话：“在没有丢失的情况下，TCP 慢启动提高了发送速率……”

... slower than AIMD, that’s why it’s called Slowstart." ...比 AIMD 慢，这就是它被称为 Slowstart 的原因。”
" ... faster than AIMD. In fact, slowstart increases the sending rate exponentially fast per RTT." “......比 AIMD 更快。事实上，slowstart 使每个 RTT 的发送速率呈指数级快速增长。”
"... at the same rate as AIMD." “……与 AIMD 的速度相同。”

选项 2 是正确的，因为 TCP 的慢启动机制在没有检测到数据包丢失的情况下，会迅速增加发送速率。具体而言，慢启动通过每次接收一个 ACK 时将拥塞窗口 $cwnd$ 增加一倍，使得 $cwnd$ 呈指数级增长（每个 RTT 增加一倍），因此它的发送速率远比 AIMD 的线性增长更快。因此，虽然称为 "slow start"（慢启动），但其实它的增速在初期比 AIMD 更快，直到遇到丢包或达到阈值。

Consider the transport-layer flows interacting at a congested link. In the face of such congestion, what happens at this link to a transport-layer flow that does not cut back on its sending rate? 考虑在拥塞链路上交互的传输层流。面对这样的拥塞，在不降低发送速率的情况下，传输层流的链路会发生什么情况？

That sender’s datagrams will be preferentially dropped at the congested link. 该发送者的数据报将优先在拥塞的链路处被丢弃。
The router will send a signal to the TCP sender that would force the TCP sender to cut its rate in half. 路由器将向 TCP 发送方发送一个信号，迫使 TCP 发送方将其速率减半。
Nothing different from the other flows crossing the congested link. 与穿过拥塞链路的其他流没有什么不同。

答案是 3，因为在拥塞链路上，所有的流量都面临相同的丢包或延迟等拥塞影响，并不会对某一特定流量进行“优先”丢弃。链路拥塞发生时，不会自动针对不降低发送速率的流量采取特殊措施，除非该流明确使用了网络辅助的拥塞控制机制来接收网络信号。而在默认情况下，这样的传输层流与其他流量没有区别，都会平等地面临拥塞所带来的影响。

Assuming that the congestion window size,cwnd, has not yet reached Wmax, TCP CUBIC will ... (check all that apply) 假设拥塞窗口大小， cwnd ，尚未达到 W max ，TCP CUBIC 将...（选中所有适用项）

... always have a window size, cwnd, and hence a sending rate, higher than that of AIMD (assuming a given window size, Wmax, at which loss would occur).
...总是有一个窗口大小 cwnd ，因此发送速率高于 AIMD （假设给定的窗口大小 W max ，此时会发生丢失）。
... increase its sending rate faster than AIMD when cwnd is far away from Wmax, but increase slower than AIMD when cwnd is closer to Wmax ...当 cwnd 远离 W max 时，其发送速率比 AIMD 增加得更快，但当 cwnd 接近 W max 时，其发送速率比 AIMD 增加得慢

答案：1 和 2 。

答案选项是 1 和 2 的原因如下：

选项 1：TCP CUBIC 确实在很多情况下拥有更高的 $ cwnd $ 和更高的发送速率。相比 AIMD 的线性增长，CUBIC 的拥塞窗口在大部分时间内保持在更高的水平，因此在相同条件下，CUBIC 的发送速率往往比 AIMD 高。特别是在远离 $ W_{max} $ 时，CUBIC 的窗口会增长得更快，从而维持更大的 $ cwnd $。

选项 2：CUBIC 使用的是非线性的窗口增长函数，当窗口 $ cwnd $ 远离 $ W{max} $ 时，增长更快；而接近 $ W{max} $ 时增长变慢。因此，TCP CUBIC 会在距离 $ W{max} $ 较远时比 AIMD 增长更快，但在接近 $ W{max} $ 时增长较慢。这种设计是为了在接近拥塞点时更平稳地增长，以减少丢包的概率。

因此，这两个选项都适用于 TCP CUBIC 的行为特点。

For delay-based congestion control, match the sender action to the relationship of the currently measured throughput to the value of cwnd/RTTmin 对于基于延迟的拥塞控制，将发送方操作与当前测量的吞吐量与 cwnd/RTT min 值的关系相匹配

Question List: 问题清单：

The currently measured throughput is greater than cwnd/RTTmin 当前测量的吞吐量大于 cwnd/RTT min
The currently measured throughput is equal to or a bit less than than cwnd/RTTmin 当前测量的吞吐量等于或略小于 cwnd/RTT min
The currently measured throughput is much less that than cwnd/RTTmin 当前测量的吞吐量远小于 cwnd/RTT min

Answer List: 答案列表：

increase the sending rate 提高发送速率
decrease the sending rate 降低发送速率
This should never happen. 这绝对不应该发生。

答案： 312 。

当然，以下是对基于延迟的拥塞控制中发送方操作与吞吐量与 ( ) 关系的详细解释：

1. 当前测量的吞吐量大于 ( )

答案：3（这绝对不应该发生）

解释：

在正常情况下，TCP 的发送速率应该与其拥塞窗口 ( cwnd ) 和最小往返时间 ( RTT*{} ) 保持一致。具体来说，吞吐量的理论上限是 ( )。如果实际测量的吞吐量超过这个值，说明网络存在异常情况，可能是因为网络没有被充分利用，或者是出现了错误的吞吐量测量。这种情况下，发送方应该检测到异常，并采取措施来重新评估网络状况。

2. 当前测量的吞吐量等于或略小于 ( )

答案：1（提高发送速率）

解释：

当吞吐量等于或略小于 ( ) 时，表明网络的带宽正在被充分利用。此时，TCP 发送方可以安全地增加发送速率，以充分利用网络资源。例如，TCP 可能会根据当前的吞吐量增长其拥塞窗口，进而增加数据发送的速率，以更有效地使用可用的带宽。

3. 当前测量的吞吐量远小于 ( )

答案：2（降低发送速率）

解释：

如果吞吐量远小于 ( )，则说明网络可能处于拥塞状态，或存在其他性能问题。在这种情况下，TCP 应该降低发送速率，以避免进一步增加网络的负载，从而加重拥塞。发送方会减少其拥塞窗口的大小，降低发送速率，以寻找网络的最佳操作点。

总结

在基于延迟的拥塞控制中，发送方的操作与当前吞吐量的比较反映了网络状况的变化：

如果吞吐量超出理论值，意味着有异常发生，需谨慎处理。

如果吞吐量与理论值相等或略小，可以适当提高发送速率以提升利用率。

如果吞吐量显著低于理论值，应立即降低发送速率，以防止网络拥塞并保护数据传输的稳定性。

这种方式确保了 TCP 在各种网络条件下保持良好的性能，同时尽量减少丢包和延迟。

3.8

Knowledge checks 知识检查

What are advantages of the streams concept in QUIC? Select all that apply. QUIC 中的流概念有哪些优点？选择所有适用的选项。

Since each stream has its own error control, if one stream experiences an error (e.g., lost or damaged segment), the other streams are unaffected. 由于每个流都有自己的错误控制，因此如果一个流遇到错误（例如，丢失或损坏的段），其他流不会受到影响。
With N streams, the overall throughput can be increased by a factor of N, since each stream has its own separate congestion control. 对于N 个流，总体吞吐量可以增加N倍，因为每个流都有自己单独的拥塞控制。
Streams allow concurrent retrieval of web objects, while avoiding Head of the Line (HOL) blocking. 流允许并发检索 Web 对象，同时避免队头 (HOL) 阻塞

答案： 1 和 3 。

在 QUIC 中，流的概念确实带来了多种优势，以下是每个选项的分析：

由于每个流都有自己的错误控制，因此如果一个流遇到错误（例如，丢失或损坏的段），其他流不会受到影响。

优点：正确。每个流在 QUIC 中都有独立的错误控制机制，这意味着一个流的错误（如丢包或损坏）不会影响到其他流的数据传输。这种特性提高了传输的可靠性和灵活性。

对于 N 个流，总体吞吐量可以增加 N 倍，因为每个流都有自己单独的拥塞控制。

优点：部分正确。虽然理论上可以通过并行流增加整体吞吐量，但实际增加的吞吐量并不一定是 N 倍。它依赖于网络条件和流的配置等因素。每个流有独立的拥塞控制机制确实有助于更好地利用带宽，但在实践中可能会受到竞争和网络瓶颈的影响。

流允许并发检索 Web 对象，同时避免头部阻塞（HOL）阻塞。

优点：正确。流的并发性允许多个数据流同时进行，避免了传统 TCP 中的头部阻塞问题。在 TCP 中，如果一个数据包丢失，后续所有数据包必须等待该数据包的重传，这导致了延迟。而在 QUIC 中，流之间是独立的，因此即使一个流遇到问题，其他流仍然可以继续传输数据，从而提高了整体性能。

结论

适用的选项为：

由于每个流都有自己的错误控制，因此如果一个流遇到错误（例如，丢失或损坏的段），其他流不会受到影响。

流允许并发检索 Web 对象，同时避免头部阻塞（HOL）阻塞。

第二个选项在理论上是有利的，但在实践中可能受限于其他因素，因此不完全适用。

What are advantages of implementing transport-layer functionality in QUIC at the application layer? Select all that apply. 在应用层实现 QUIC 传输层功能有哪些优势？选择所有适用的选项。

QUIC can establish all connection parameters (security, reliability, flow and congestion control)in just one handshake rather than separately in two. QUIC 可以在一次握手中建立所有连接参数（安全性、可靠性、流量和拥塞控制），而不是分别在两次握手中建立。
As an application-layer protocol, QUIC can be updated/modified at “app frequency” rather than at the frequency of operating system updates. 作为应用层协议，QUIC 可以以“应用程序频率”而不是操作系统更新的频率进行更新/修改。
QUIC’s performance can be better optimized at the application-layer, so it will have better performance than if these functions were implremented in the operating system. QUIC 的性能可以在应用层得到更好的优化，因此比在操作系统中实现这些功能会有更好的性能。
QUIC performs both congestion control and error recovery different from TCP, leveraging all of the knowledge that has built up since TCP was first standardized, and therefore has better performance than TCP. QUIC 执行与 TCP 不同的拥塞控制和错误恢复，利用了自 TCP 首次标准化以来积累的所有知识，因此具有比 TCP 更好的性能。

答案：1 和 2 。

理解为什么答案是 1 和 2，我们需要仔细分析每个选项的优势以及它们与 QUIC 的设计目标和实际实现方式的关系。

选项 1:

QUIC can establish all connection parameters (security, reliability, flow and congestion control) in just one handshake rather than separately in two. > QUIC 可以在一次握手中建立所有连接参数（安全性、可靠性、流量和拥塞控制），而不是分别在两次握手中建立。

这是正确的。QUIC 的设计目的是为了减少连接建立的时间。传统的 TCP + TLS 握手需要多个往返时间（通常至少两个 RTT），而 QUIC 通过在一个握手过程中完成所有必要的协商（包括安全性和其他传输层参数），只需要一个 RTT 即可完成连接建立。这显著提高了连接建立的效率，特别是在高延迟网络中。

选项 2:

As an application-layer protocol, QUIC can be updated/modified at “app frequency” rather than at the frequency of operating system updates. > 作为应用层协议，QUIC 可以以“应用程序频率”而不是操作系统更新的频率进行更新/修改。

这也是正确的。QUIC 作为一个应用层协议，其更新和修改不受操作系统的限制。这意味着 QUIC 可以更频繁地进行改进和修复，而不需要等待操作系统更新。这种灵活性使得 QUIC 能够更快地适应新的网络条件和技术进步。

选项 3:

QUIC’s performance can be better optimized at the application-layer, so it will have better performance than if these functions were implemented in the operating system. > QUIC 的性能可以在应用层得到更好的优化，因此比在操作系统中实现这些功能会有更好的性能。

这个说法虽然有一定的道理，但并不是 QUIC 的主要优势之一。虽然应用层实现可以提供更多的灵活性和优化空间，但这并不意味着 QUIC 一定会在所有情况下都比内核中的实现有更好的性能。实际上，内核中的实现也可以非常高效，而且某些情况下可能更适合高性能需求。因此，这个选项不是最准确的。

选项 4:

QUIC performs both congestion control and error recovery different from TCP, leveraging all of the knowledge that has built up since TCP was first standardized, and therefore has better performance than TCP. > QUIC 执行与 TCP 不同的拥塞控制和错误恢复，利用了自 TCP 首次标准化以来积累的所有知识，因此具有比 TCP 更好的性能。

这个说法也是正确的，但并不是直接回答“在应用层实现 QUIC 传输层功能的优势”。QUIC 确实利用了现代网络技术和研究成果，提供了比传统 TCP 更好的性能，但这更多是 QUIC 协议设计上的优势，而不是应用层实现的优势。

综上所述，选项 1 和 2 直接回答了在应用层实现 QUIC 传输层功能的优势，因此是正确的答案。

Chapter 3

3.1

Knowledge checks 知识检查

解释：

3.2

Knowledge checks 知识检查

3.3

Knowledge checks 知识检查

3.4

Knowledge checks 知识检查

发送方（Sender）的状态转换

接收方（Receiver）的状态转换

状态转换

分析每个选项

结论

发送方（Sender）的状态转换

接收方（Receiver）的状态转换

状态转换

给定序列

结论

已知条件：

最大通道利用率计算公式：

步骤 1：计算传输时间

步骤 2：确定往返时间（RTT）

步骤 3：计算通道利用率

结论

已知条件：

流水线协议的通道利用率

步骤 1：计算传输时间

步骤 2：计算在一个 RTT 内可以发送的数据包数量

结论

已知条件：

步骤 1：计算在一个 RTT 内可以传输的总数据量

步骤 2：计算发送的数据包数量

结论

1. 随着流水线程度的增加，接收者将不得不发送更少的确认

2. 流水线发送方可能已经传输了多个数据包，但发送方尚未收到来自接收方的 ACK

3. 对于管道式发送方，可能会存在“传输中”的数据包（通过通道传播），即发送方已发送但接收方尚未收到的数据包

4. 通过管道传输，仅当数据包或其 ACK 丢失时才会重新传输该数据包

结论

1. 丢弃失序的数据包实际上会迫使发送方重新传输

2. 无论如何，发送者都会重新发送该数据包

3. 如果某些数据包有错误，那么其他数据包也可能有错误

4. 接收器的实现更简单

结论

选项分析（重新审视）

正确结论

选项分析

正确答案

选项分析

正确答案

3.5

Knowledge checks 知识检查

解释

举例说明

选项分析

正确答案

总结：

结论：

3.6

Knowledge checks 知识检查

选项分析：

结论：

问题清单：

匹配结果：

最终答案：

3.7

Knowledge checks 知识检查

不正确的陈述：

1. 当前测量的吞吐量大于 ( )

2. 当前测量的吞吐量等于或略小于 ( )

3. 当前测量的吞吐量远小于 ( )

总结

3.8

Knowledge checks 知识检查

结论

选项 1:

选项 2:

选项 3:

选项 4: