0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |          source address           |
                 +--------+--------+--------+--------+
                 |        destination address        |
                 +--------+--------+--------+--------+
                 |  zero  |protocol|   UDP length    |
                 +--------+--------+--------+--------+

						Pseudo  Header  Format
Copy

1. 准备数据：将 UDP 头部（除了校验和字段，该字段在计算时设为0）和数据载荷分为16位的字（2字节）。如果数据的字节总数不是偶数（即不能完全分成16位的字），则在最后添加一个额外的字节的填充（通常是0）以使之成对
2. 添加伪头部 ：根据 UDP 协议，校验和的计算应包含一个"伪头部"，它包括发送者和接收者的 IP 地址（各占4字节），一个8位的全0字段（用于占位，确保伪头部的格式与传输层数据段的其余部分保持一致），1字节的协议号（UDP 是17, 0x11），以及 UDP 数据报的长度
3. 反码求和：使用 16 位反码运算，将所有的 16 位字加到一起。在这种加法中，如果任何一次加法结果超过 16 位，即最左边产生了进位，那么进位会被加回到计算结果的最低位。这就是所谓的“环绕”或“端到端进位”
4. 求和的反码：将最终的求和结果进位的一部分和基本部分相加之后取反码，即将所有位从 0 变为 1 或从 1 变为 0，这就是要存储在校验和字段的值
5. 特殊情况：如果计算出的检验和为 0，为防止将合法的检验和值 0 解释为没有使用检验和，发送端将检验和字段为 0 的情况下置为全 1

1. 端到端原则 [@EndtoendPrinciple2023](end-eend principle)：因为某种功能（在此时为差错检测）必须基于端到端实现："与在较高级别提供这些功能的代价相比、在较低级别上设置的功能可能是冗余的或几乎没有价值的。"
   1. 虽然许多链路层协议提供了差错检测，但是不能保证源和目的之间所以链路都提供
   2. 报文段存储在路由器的内存中，也可能引入比特差错
2. 虽然 UDP 提供差错检测，但是 UDP 对差错恢复无能为力

• 考虑底层信道是完全可靠的，既不出现比特损坏(位元错误)，也不丢失分组，分组还是按序到达的
  

1. 水平线上方为造成转移的事件，下方为事件发生时所采取的动作，若不采取任何动作则为空白
2. 发送端和接收端均只有一种状态即等待上/下层的调用
3. 函数作用
   1. rdt_send(data)：从上层接收数据 (如果可靠数据传输实现在 Layer4，那么这些数据就是 Layer5 注入 socket 的报文 (message)(可以是 HTTP 报文，SMTP 报文...))
   2. make_pkt(packet, data)：将上层数据(根据需要拆分)加上头部建立分组 (注意⚠️：这里的分组指的是封包，在不同网络层级中的名称不同)
   3. udt_send(packet)：将此分组送入下层信道
   4. rdt_rcv(packet)：从下层信道接收分组
   5. extract(packet,data)：从分组中取出数据
   6. deliver_data(data)：将数据交给上层

                              ┌────────────┐               ┌────────────┐
                              │            │               │            │
                              │   sender   │               │  receiver  │
                              │            │               │            │
                              └────────────┘               └────────────┘
   layer 5           layer 4                    layer 3              layer 4             layer 5
                                     │                           │
┌────────────┐      waiting for      │                           │
│datadatadata│      layer 5          │                           │
│datadata    │      invocation       │                           │
└────────────┘                       │                           │
 layer 5 call   rdt_send(data)       │                           │  waiting for
                ───────────────────► │                           │  layer 3
                packet=make_pkt(data)│                           │  invocation
                udt_send(packet)     │                           │
                      ┌────────────┐ │                           │
                      │headdatadata│ │ layer 3 channel delivery  │
                      │datadatadata│ │         reliable          │
                      └────────────┘ │ ────────────────────────► │ ┌────────────┐
                                     │                           │ │headdatadata│
                                     │                           │ │datadatadata│
                                     │                           │ └────────────┘
                                     │              layer 3 call │ rdt_rcv(packet)
                    waiting for      │                           │ ────────────────────►
                    layer 5          │                           │ extract(packet,data)
                    invocation       │                           │ deliver_data(data)  ┌────────────┐
                                     │                           │                     │datadatadata│
                                     │                           │                     │datadata    │
                                     │                           │                     └────────────┘
                                     │                           │
                                     │                           │
                                     │                           │  waiting for
                                     │                           │  layer 3
   From:                             │                           │  invocation
   Chris White                       │                           │
                                     ▼                           ▼
Copy

• 考虑经过底层信道后分组的比特可能受损(1 变 0，0 变 1)

1. 通过肯定确认 (positive acknowledgement) 和否定确认 (negative acknowledgement)，接收方让发送方知道那些内容能被正确接收，哪些内容需要重传，于是有自动重传请求 (Automatic Repeat reQuest, ARQ) 协议
2. ARQ 协议基于三种机制
   1. 差错检测：让接收端能够发现比特差错，UDP 使用反码求和的方式来检验
   2. 接收端反馈：接收端反馈信息给发送端，ACK 代表成功，NAK 代表失败
   3. 重传：分组有差错，就重传分组
3. 函数作用
   1. make_pkt(data,checksum)：计算 data 的 checksum 并且将数据封包
   2. isNAK(rcvpkt)：received packet为 NAK
   3. isACK(rcvpkt)：received packet 为 ACK
   4. corrupt(rcvpkt)：rcvpkt 有比特错误
   5. notcorrupt(rcvpkt)：rcvpkt 没有比特错误
   

• 注意在 make packet 的过程中同时还有计算 checksum 的过程

1. 发送端具有两种状态
   1. 等待来自上层的调用，当接收上层的数据后进入状态 2，
   2. 等待接收端传送 ACK 或 NAK ，收到 ACK 转移到状态 1 并等待上层的下一个调用，收到 NAK 重传一次分组并重复状态 2
2. 接收端只有一种状态
   1. 根据收到的分组回传 ACK 或 NAK
3. 停等 (stop-and-wait)：发送方将不会发送一块新数据，除非发送方确信接收方已正确接收当前分组
4. 缺陷：未考虑 ACK 或 NAK 受损的可能性

1. 除了比特受损以外，底层信道还会出现丢包的情况
2. 这里将检测和回复丢包的工作都交给发送端处理
3. 发送方发送的数据分组或接收方对该分组的 ACK 发生了丢失，发送方都接收不到来自接收方的响应，如果发送方愿意等待足够长的时间以便确定分组已丢失，则它只需重传该数据分组即可
4. 理想的协议应尽可能快地从丢包中回复过来，所以对等待时间的选择非常重要，如果在这段时间内没收到 ACK 则重传该分组，如果分组经历了一个特别大的时延，发送端也会重传该分组，即使数据分组和 ACK 都没丢失，于是在信道中引入了冗余数据分组 (duplicate data packet)
5. 倒数定时器 (countdown timer)：在一个给定时间量后，可中断发送方
   1. 发送方每次发送一个分组，便启动一个定时器
   2. 响应定时器中断
   3. 中止定时器
6. 因为分组序号在 0 和 1 之间交替，rdt 3.0 被称为比特交替协议 (alternating-bit protocol)
   

• 数据传输协议的要点
  • 检验和
  • 序号
  • 定时器
  • 肯定的否定确认

1. 基序号 (base)：最早未确认的分组
2. 下一个序号 (nextseqnum)：下一个待发分组的序号
3. N 常被称为窗口长度 (window size)，GBN 协议也常被称为滑动窗口协议 (sliding-window protocol)
4. 分组的序号承载在分组首部的定长字段中，如果分组序号字段的比特数是 k，则该序号的范围是 ，TCP 有一个 32bit 的序号字段，TCP 序号是按字节流中的字节进行计数的，而不是按分组计数
5. GBN 发送方需要相应三种类型的事件：
   1. 上层调用：当收到来自上层的调用时需要检查窗口是否已满，如果未满则发送一个分组，如果已满则将数据返回给上层让上层一会再试，实际情况中发送方可能缓存这个数据，或者使用同步机制允许上层在窗口不满时才调用
   2. 收到一个 ACK ：更新 base，如果有已发送但未被确认的分组，则定时器被重新启动，如果没有已发送但未被确认的分组，则停止定时器
   3. 超时事件：如果出现超时，发送方重传所有已发送但未被确认过的分组
6. 接收方动作：
   1. 如果序号为 n 的分组按序到达，则为分组 n 发送一个 ACK n，如果到达的分组不是 n (失序)，则丢弃该分组等待发送端重传
7. 基于事件的编程 (event-based programming) 方式：在协议栈中对拓展 FSM 的实现以各种过程形式出现，每个过程实现了在响应可能出现的事件时要采取的动作，可能出现的事件
   1. 上层实体调用
   2. 定时器中断
   3. 下层实体调用

1. GBN 本身存在着一些性能问题，当窗口长度和带宽时延积都很大时，流水线中有很多分组，单个分组的差错就能引起 GBN 重传大量分组
2. 选择重传 (SR) 协议通过让发送方仅重传怀疑在接收方出错的分组避免了不必要的重传
3. SR 发送方的事件与动作：
   1. 从上层收到数据：若 ，则将数据打包并发送，否则将数据缓存或返回给上层
   2. 超时：每个分组必须拥有自己的逻辑定时器，超时发生后只能发送一个分组
   3. 收到ACK：若分组序号在窗口内，则 SR 发送方将被确认的分组标记为已接收，若分组的序号等于 send_base 则将窗口基序号向前移动到最小的未确认分组处，如果窗口已到了有序号落在窗口内的未发送分组，则发送这些分组
4. SR 接收方的事件与动作：
   1. 序号在[rcv_base, rcv_base + N - 1] 内的分组被正确接收：回传选择 ACK (与当前收到分组 seq 对应) ，在接收端如果该分组以前没收到过，且序号大于接收窗口的基序号 (图中 rcv_base + 123的黑框框) 时，这些分组是失序分组，由接收端缓存，如果序号等于接收窗口的基序号 (rcv_base) 时，则将该分组及以前缓存的序号连续失序分组 (图中的 rcv_base + 1, rcv_base + 2, rcv_base + 3 的黑框框)交付给上层，接收窗口向前移动到下一个未交付的分组处 (图中 rcv_base + 4)
   2. 序号在[rcv_base - N, rcv_base - 1] 内的分组被正确接收：必须产生一个 ACK (与分组 seq 对应)，此分组出现的原因是接收端已经收到分组移动窗口，但返回的 ACK 损坏，发送端重传该分组，为了让发送端接收到 ACK 确认并让发送端窗口向前移动，所以要产生 ACK
   3. 其他情况：若出现分组损坏等情况则忽略该分组等待发送端重传
5. 发送方和接收方件的窗口长度必须小于或等于序号空间大小的一半否则会引起歧义，接收方不知道接收到的下个分组是重传的还是发送方窗口滑动后发送的新分组
6. 先前假定分组在发送方和接收方的信道中不能被重新排序，但是实际上重新排序有可能发生，以前被发向信道但被认为丢失了的分组可能会突然出现，为了确保序号不被重新使用，发送方在发送序号为 x 的分组时需要确信任何先前发送过的序号为 x 的分组都不在网络中，通过假定分组在网络中的存活时间不会超过某个固定最大时间量来做到这一点

1. TCP 序号建立在传送的字节流之上，而不是建立在传送的报文段序列之上
2. 一个报文段的序号 (sequence number for a segment) 是该报文段首字节的字节流编号，TCP 根据 MSS 将文件数据划分为 TCP 报文段，并将每个报文段对应的首字节的编号被填入相应报文段首部的序号字段中
3. TCP 是全双工的，如果主机 A 在向主机 B 发送数据的同时，主机 B 也在向主机 A 发送数据，那么主机 A 填充进报文段的确认号是主机 A 期望从主机 B 收到的下一字节的序号
4. 如果主机 A 已经收到主机 B 包含字节 0～535 的报文段和包含字节 900～1000 的报文段，但主机 A 还没有收到字节 536 ～ 899 的报文段，那么 A 到 B 的下个报文段将在确认号中包含 536，而不会发送确认号位 1001 的报文段，TCP 只确认该流中至第一个丢失字节为止的报文段，收到的失序报文段不发送对应的确认报文段，而对失序报文段的处理方式由编程人员决定，所以 TCP 提供 累积确认 (cumulative acknowledgement)(注意与 回退N步 和 选择重传 确认机制区分，回退 N 步中接收端直接将收到的分组(先前对于 rdt 的讨论不是基于特定 Layer 而言的，所以用 packet 来指代)丢弃，所以不存在累积确认的说法，而选择重传中是接收端收到分组，无论是不是失序分组，均回传与收到分组对应的 ACK，所以发送端能够知道失序的分组已经被接收了，在累积确认机制中，TCP 发送端(主机 B)是不知道字节 900～1000 的报文段(失序)已经被接收了，只能通过下个 A 到 B 的报文段中的确认号 536 知道到丢失字节(536)之前的所有报文段被正确接收了)
5. TCP 编程人员对失序报文段有两种处理方式：
   1. 接收方立即丢弃失序报文段(简化接收当设计)
   2. 接收方保留失序的报文段，并等待缺失的报文段填补间隔(有可能在传送的过程中丢失或损坏由发送端重传)
6. 图中初始序号为 0，实际上序号 TCP 连接的双方可以随机选择序号，可以减少将仍在网络中存在的来自两台主机之间先前已中止的连接的报文段，误认为新连接的有效报文段的可能性 (需要恰巧新连接和旧连接都在发送方和接收方的同一对端口上)

1. 客户端的用户键入的每个字符都会被发送到远程主机，远程主机会送每个字符的副本给客户，并将这些字符显示在 telnet 用户的屏幕上
2. 回显 (echo back) 用于确保由 Telnet 用户发送的字符已被远程主机收到并在远程站点上得到处理
3. 不妨试着用 Python 运行一个简单的 Telnet 服务端 (Generated by ChatGPT)

import socket
import threading


def client_thread(conn, addr):
    print(f"Connected to {addr}")
    conn.send(b"Welcome to the Telnet server!\n")

    while True:
        try:
            data = conn.recv(1024)
            if not data:
                break
            conn.sendall(b"Echo: " + data)
        except ConnectionResetError:
            break

    print(f"Connection with {addr} closed")
    conn.close()


def start_telnet_server(host, port):
    server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_socket.bind((host, port))
    server_socket.listen(5)
    print(f"Telnet server started on {host}:{port}")

    try:
        while True:
            conn, addr = server_socket.accept()
            threading.Thread(target=client_thread, args=(conn, addr)).start()
    except KeyboardInterrupt:
        print("Shutting down the server...")
    finally:
        server_socket.close()


if __name__ == "__main__":
    HOST = "127.0.0.1"  # 绑定到所有网络接口
    PORT = 23  # 标准Telnet端口号是23，但如果没有管理员权限，您可能需要选择1024以上的端口号
    start_telnet_server(HOST, PORT)

Copy

1. 当程序运行时，服务端套接字监听 localhost 上 23 端口，当 socket 没有连接被建立时，accept() 方法是阻塞的，直到有新连接建立时 accept() 方法返回一个 (conn, addr) 对，conn 是一个新的套接字对象，用于在此连接上收发数据，address 是连接另一端的套接字所绑定的地址 (IP 和端口号)，随后程序创建并启动新的线程调用 client_thread() 方法来处理这个连接，连接开始时服务端打印了客户端的地址，并调用 socket 对象发送欢迎文本，接着该子线程进入循环，recv 的参数 bufsize 指定 buffer 的大小 ( bufsize 参数指定了单次调用 recv方法时最多可以读取的字节数，这个大小是由程序员根据具体的网络应用程序而定的，它可以是任意非零的整数，告诉 recv 方法一次性从内部缓冲区中读取多少字节的数据)，当 TCP 缓冲中没有数据可用时，recv() 会阻塞，如果 buffer 中有可用数据，但小于 bufsize，recv() 会返回实际可用的数据量，如果到达的数据量大于 bufsize，数据会存放在操作系统的缓冲区中，recv() 一次读取 bufsize 大小的数据，将这些数据加上 Echo: 字节串头部后使用 socket 对象发送回客户端
2. 可以通过 lsof 命令查看 TCP 连接是否被建立，图中在回环地址的 56971 端口到 23 端口建立了一条 TCP 连接
3. 在 telnet 中执行一系列操作(telnet 开启了 character 模式)，通过 wireshark 可以看到执行这些输入时对应的网络活动 ( loopback 接口的好处是不容易 capture 到操作系统其他网络活动的奇怪分组)
4. 捎带 (piggybacked) ：需要注意的是，在上图的情况中对于携带数据的报文段的确认 (ACK) 均是是一个单独的不携带数据的 ACK 报文段，在实际情况下，对携带数据报文的确认有可能被装载在返回的承载数据的报文段中，这种确认称为是被捎带在数据报文段中

1. 样本 RTT (SampleRTT)：某报文段被发出 (交给 IP) 到对该报文段的确认被收到之间的时间量，通常 TCP 遵循以下规则来选择测量 SampleRTT 的报文段
   1. 单个报文确认原则：为了避免对 RTT 估计引入额外的变化，通常不对重传的报文段进行 SampleRTT 的测量。换句话说，TCP 只测量对于那些被首次传输的报文段的确认，而不是对重传的报文段的确认
   2. Karn/Partridge 算法：如果一个报文必须重传，那么它的 SampleRTT 就不会被采用，因为这个 RTT 可能包含了重传的延迟，这不利于准确计算网络的真实 RTT
   3. 避免并行测量：TCP 通常避免在同一时间测量多个报文段的 SampleRTT，通常是在任何给定的时间只对一个在传输路径上的数据段测量 SampleRTT。这样做是为了防止报文段的确认回应由于网络路径上的排队延迟而彼此影响，进而影响 RTT 的准确性
   4. 样本选择：在某些实现中，TCP 可能会选择性地估算 RTT，例如只在特定间隔或者对特定的报文段测量 SampleRTT
2. 为了估计一个典型的 RTT，需要采取对间隔测量到的 SampleRTT 取平均的方法，TCP 维护一个 SampleRTT 均值 (EstimatedRTT)，当获得一个新的 SampleRTT 时，TCP 会根据指数加权移动平均 (Exponential Weight Moving Average) 来更新 EstimatedRTT， 的推荐值通常是 0.125
3. EstimatedRTT 的新值是由以前的 EstimatedRTT 值与 SampleRTT 新值加权组合而成，这个加权平均对最近的样本赋予的权值要大于对旧样本赋予的权值，因为越近的样本越能更好地反映网络的当前拥塞状况，一个给定的 SampleRTT 的权值在更新的过程中呈指数型快速衰减
4. RFC 6298 定义了 RTT 偏差，用于估算 SampleRTT 会偏离 EstimatedRTT 的程度， 的推荐值通常为 0.25

1. 超时间隔应大于等于 EstimatedRTT ，否则将造成不必要的重传，超时间隔不应该比 EstimatedRTT 大太多，否则当报文段丢失时，TCP 不能很快重传该报文段，因此要求将超时间隔设为 EstimatedRTT 加上一定余量。当 SampleRTT 值波动较大时，这个余量应该大些；当波动较小时，这个余量应该小些
2. 推荐的初始 Timeoutlnterval 值为 1 秒 RFC 6298 [@sargentComputingTCPRetransmission2011]。同时，当出现超时后，Timeoutlnt­erval 值将加倍，以免即将被确认的后继报文段过早出现超时。然而，只要收到报文段并更新 EstimatedRTT , 就使用上述公式再次计算 Timeoutlnterval
3. TCP 通过使用肯定确认和定时器来实现可靠数据传输，当 TCP 认为报文段或其确认丢失或受损时，TCP 会重传这些报文段，有一些 TCP 还有一个隐式 NAK 机制 (快速重传（Fast Retransmit）: 当接收方收到一个失序的数据包时，它会立即发送一个重复的 ACK（也就是隐式 NAK），这是当前已正确接收的最高序列号的数据包。如果发送方收到三个或者更多连续的重复 ACK，它将推测在传输中出现了数据包丢失，并且会在定时器到期之前立即重传那些丢失的数据包)
4. TCP 无法分辨报文段或其 ACK 是丢失了、受损了还是时延过长了，但 TCP 对这些情况的处理方式是相同的，重传出现问题的报文段
5. TCP 也使用流水线，当报文长度和往返时延只比很小时，流水线能显著增加一个会话的吞吐量，一个发送方能够具有的未被确认报文段的具体数量是由 TCP 的流量控制和拥塞控制机制决定的

1. 当 TCP 的一个分组丢失或遭受延迟时，如果超时事件发生，TCP 发送端会重传该分组，但是如果是两个连续的分组，超时事件发生时，发送端会采取什么样的行动🤔️
2. 如图 2，当主机 A 连续发送了两个报文段，假设两个报文段在超时前都没有到达主机，当超时事件发生时，主机 A 重传序号 92 的第一个报文段，并重启定时器，只要第二个报文段 ACK 在新的超时发生以前到达，则第二个报文段将不会被重传
3. 还有一种情况，主机 A 像 2 中一样发送两个报文段但第一个报文段的 ACK 报文总在网络中丢失或者遭受延迟，而第二个报文在超时事件发生前正确到达了，根据累积确认机制，主机 A 知道主机 B 已经收到了序号为 119 及之前的所有字节，所以主机 A 不会重传这两个报文段中的任何一个

1. 考虑在大多数 TCP 实现中所做的一些改变，首先关注定时器 timeout 时超时间隔的长度，在这种修改中，当超时事件发生时，TCP 重传具有最小序号的未确认的报文段，但是每次 TCP 重传都会将下一次的超时间隔设为先前值的两倍，而不是用从 EstimatedRTT 和 DevRTT 推算出的值
2. 这种方法提供了一种形式受限的拥塞控制，在拥塞时，如果源持续重传分组会使拥塞更严重，所以 TCP 采用更优雅的方式

1. 发送方通常可在超时事件发生之前通过冗余 ACK 来较好地检测到丢包的情况
2. 冗余 ACK 是再次确认某个报文段的 ACK ，而发送方先前已经收到对该报文段的确认
3. 当接收方期望收到一个序列号为 N 的报文段，但是却收到了一个序列号大于 N 的报文段时，它会意识到一些数据丢失了（可能是因为网络中的某些报文段丢失或到达顺序错乱）。此时，为了通知发送方哪些报文段已成功接收，并请求重传丢失的报文段，接收方会发送一个确认最后成功接收报文段的冗余 ACK
4. 发送方经常一个接一个地发送大量的报文段，如果一个报文段丢失，就很可能引起许多一个接一个的冗余 ACK 。如果 TCP 发送方接收到对相同数据的 3 个冗余 ACK,，它把这当作一种指示，说明跟在这个已被确认过 3 次的报文段之后的报文段已经丢失，一旦收到 3 个冗余 ACK ，TCP 就执行 快速重传(fast retransmit)，即在该报文段的定时器过期前重传丢失的报文段

if (y > SendBase) { 
	SendBase = y;
	DupAck = 0;
	if (NextSeqNum > SendBase)
		timer_start();
} else { /*当收到对已经确认报文段的一个冗余ACK，此时 y = SendBase*/
	DupAck++;
	if (DupAck == 3) { //TCP快速重传
		udt_snd(sndpkt[y]) //重新发送具有序号 y 的报文段
	}
}
break;
Copy

1. TCP 协议更像 GBN 协议和 SR 协议的混合体
2. GBN 协议特征
   1. 累积式的，正确接收但失序的报文不会被接收方逐个确认
   2. TCP 发送方维护 已发送但未被确认的字节的最小序号(SendBase) 和 下一个要发送的字节的序号(NextSeqNum)
3. SR 协议特征
   1. 当发送方发送一组报文段，其中的一个报文段丢失时，TCP 至多重传一个类型的报文段 (这个报文段，若重传还丢失，那么仍旧重传该报文段)，GBN 则会重传所有的该报文段后的报文段
   2. 选择确认 (selective acknowledgement) RFC 2018 [@floydTCPSelectiveAcknowledgment1996] ，允许 TCP 接收方有选择地确认失序报文段，选择确认机制还能和选择重传机制结合起来使用，跳过重传那些被接收方选择性确认过的报文段

1. 经典的 Dos 攻击，攻击者发送大量 TCP SYN 报文段，但不完成第三次握手过程，服务器不断为半开连接分配资源，直至连接资源被消耗殆尽
2. 可以使用 SYN cookie 来记忆对应的发送端 IP 地址和端口号

1. 假设仅有 TCP 穿过瓶颈链路，所有的连接具有相同的 RTT 值，对于一个主机 - 目的地而言只有一条 TCP 连接与之相关联，TCP 趋于在多条连接之间平等地共享带宽
2. 影响 TCP 拥塞控制公平性的因素：
   1. RTT：多条连接共享一个共同的瓶颈链路时具有较小 RTT 的连接能够在链路空闲时更快地抢占可用带宽，将比具有较大 RTT 的连接享用更高的吞吐量
   2. UDP：UDP 没有内置的拥塞控制，有可能压制 TCP 流量
   3. 并行 TCP 连接：Web 浏览器通常使用多个并行 TCP 连接来传送一个 Web 页中的多个对象，多条并行连接在拥塞链路中通常会抢占更多的带宽

1. 明确拥塞通告 (Explicit Congestion Notification, ECN)：网络明确向发送方和接收方发出拥塞信号
2. 用于网络辅助拥塞控制的标志位：Accurate ECN ECE
3. RFC 3168 [@floydAdditionExplicitCongestion2001] 推荐仅当拥塞持续不断存在时才设置 ECN 比特
4. 对于具有 ECE 拥塞指示的 ACK ，TCP 发送方将拥塞窗口减半作为回应，并在下个发送方到接收方的报文段中对 CWR (拥塞窗口缩减) 置位
5. 其他能利用网络层发送 ECN 信号的协议有数据报拥塞控制协议 (Datagram Congestion Control Protocol, DCCP)，DCTCP (数据中心 TCP)