学习思维导图
# 传输层
## 提供的服务
- 传输层功能
- 寻址和端口
- 无连接和面向连接服务
## UDP协议
- UDP数据报
- UDP校验
## TCP协议
- TCP段
- 连接管理
- 可靠传输
- 流量控制
- 拥塞控制
传输层功能
第三次握手可以携带应用层数据么？
当然可以，你可以想一下，如果发送方还需要收到第三次握手的确认才可以发送数据的话，不就变成四次握手了么，这是不合理的。
不同的 TCP 实现对此有不同的处理方式，有的 TCP 实现是不会将数据放到第三次握手的报文中，有的则会，正确的协议实现对于这两种情况应该都能够正确处理。
第一次挥手一定是客户端发起么？
第一次挥手是由发起连接关闭的一方发送的，通常情况下是客户端发送。但在某些特殊情况下，服务器端也可以主动发起连接关闭，不过这种情况相对较少见。
上图是滑动窗口的简图，滑动窗口代表当前 发送方正在发送 以及 接收方正在接收的 数据窗口，数据窗口是所有数据中的一部分。
每当发送方收到接收方的 ACK 确认后，滑动窗口就会向前滑动。这样，窗口中新位置允许新的数据发送
滑动窗口的大小表示发送方在未收到接收方确认（ACK）的情况下，最多可以发送多少字节的数据。窗口大小由接收方决定，并通过 ACK 报文中的窗口字段告知发送方。
绝对下标和序列号的概念区别
绝对下标（Absolute Number） 指的是在整个 TCP 会话期间，数据字节在传输流中的位置，其大小无上限。可以把它想象成一个 TCP 连接中从第一个字节开始的整体计数器。例如，如果一个 TCP 连接传输了 5000 字节的数据，那么这些数据的绝对下标范围是从 1 到 5000。
序列号（Seqno，Sequence Number）是一个 32 位的非负数（unsigned），是 TCP 报文段中实际使用的一个字段，从一个随机的初始序列号（ISN）开始计数。
在 TCP 发送和接收数据时，其需要将 序列号 和 绝对下标 进行转换，假设第一次握手使用的序列号为 ISN，那么绝对下标 index 对应的序列号为 (index + 1 + ISN) & UINT32_MAX。
如果接收方接收到的序列号为 seqno，那么对应的绝对下标为 (seqno - ISN - 1 + UINT32_MAX) % UINT32_MAX + n * UINT32_MAX，其中这里 n 为一个整数，取决于滑动窗口在 [0, UINT32_MAX] 的区间内移动了几个来回。
以上大家思考一下，不会具体考察，但是思考过程可以帮助大家理清楚这两个概念，并且能够加深对于滑动窗口的理解。
TCP 的可靠传输通过多种机制共同实现，下文将对三个关键机制进行介绍。
序列号（seqno, sequence number） 和 确认号（ackno, acknowledge number） 是 TCP 首部的两个字段，TCP 协议通过 序列号 来记录目前已经发送了哪些数据，通过 确认号 记录哪些数据已经被接收方所接收。
发送方发送序列号 和 接收方返回确认号 的交互可能存在以下几种情况：
TCP 协议在发送一个 数据段（segment） 时，它会记录目前正在传输的 segment，并为每一个 segment 设置一个定时器。
如果某个 segment 的定时器超时了，就说明发送方在 超时时间阈值 内没有接收到该 segment 的确认，发送方就会触发超时重传（Retransmission Timeout），重新发送超时的 segment。
超时重传的时间时如何确定的？（了解即可）
超时重传的时间 Timeout 可以通过如下公式计算得到： $$ \begin{align*} \text{\small Timeout} &= \text{\small EstimatedRTT} + 4*\text{\small DevRTT} \\ \text{\small EstimatedRTT} &= (1-\alpha) * \text{\small EstimatedRTT} + \alpha * \text{\small SampleRTT} \\ \text{\small DevRTT} &= (1-\beta) * \text{\small DevRTT} + \beta * \left|\text{\small SampleRTT} - \text{\small EstimatedRTT}\right| \end{align*} $$
SampleRTT 是每一次报文往返时间的样本，EstimatedRTT 是加权平均的往返时间，DevRTT 是往返时间的偏差，而 $\alpha$ 和 $\beta$ 是权重，通常取值为 $\alpha=0.125, \beta=0.25$。
TCP 首部包含一个校验和（Checksum）字段，用于检测数据在传输过程中的任何变化。如果接收方检测到校验和错误，该数据段会被丢弃，然后接收方会要求发送方重传该数据段。
TCP 的校验和计算方法和 IP校验和计算方法 一致，不过两者校验的范围和目的有所不同。
其IP校验和只针对IP头部进行校验，主要用于检测数据在传输过程中由于网络故障等原因造成的错误。 而TCP校验和不仅要校验TCP头部，还要校验TCP载荷（即数据部分）。因此，TCP校验和能提供更全面的错误检测。
TCP（Transmission Control Protocol）流量控制是一种机制，用于确保在网络中的发送方和接收方之间协调数据传输速率，以防止接收方不堪重负并避免数据包的丢失。TCP 流量控制的主要目标是保证数据的可靠传输，同时有效地利用可用的网络带宽。
TCP 通过 滑动窗口机制 来实现流量控制：发送方根据接收方通告的窗口大小发送数据，而接收方根据自己的处理速度和可用内存来控制窗口大小。
TCP 的发送窗口可以按照逻辑划分为四个部分：
其中第 2、3 个部分构成 TCP 的发送窗口，当发送方收到 ackno 在第 2 个部分内的确认报文时，调整滑动窗口的大小后向前移动滑动窗口，并且发送接下来可以发送的数据。
TCP 的接收窗口可以按照逻辑划分为四个部分：
tcp 的拥塞控制指的是 tcp 限制传输数据的速率，进而防止注入过多的数据到网络中，进而造成网络链路过载。
大家需要了解，tcp 不是一个 “自私” 的算法，一段链路上可以同时包含很多 tcp 连接，tcp 的拥塞控制的目的是尽量去实现一个总体的最优，而不是个体的最优。当 tcp 检测到数据传输出现拥塞之时，即一段时间内没有接收到一些确认，它就会降低自己传输数据的速率。
需了解如下的TCP拥塞控制算法：
慢开始是 TCP 连接开始时的一个阶段，相较于直接以较高的速率发送数据，慢开始会以一个较低的速率开始，然后逐步试探当前网络传输的能力，以指数的速率增加发送速率。慢开始的流程如下：
cwnd 设置为一个很小的值，通常是 1MSS （最大段大小）。ACK ， cwnd 会增加一个 MSS 。这意味着每个 RTT （往返时间） cwnd 都会翻倍，导致了指数增长。cwnd 达到 ssthresh （慢开始阈值）时， TCP 会从慢开始模式转换到拥塞避免模式。什么是MSS?
MSS 是 Maxium Segment Size 的简称，即最大段大小。MSS 通常是根据网络路径的MTU（最大传输单元）来确定的，MTU是网络层上一种数据包最大尺寸的限制，常见的MSS值为1460字节（MTU 1500字节减去IP头部和TCP头部的大小）。
cwnd 增加 1/cwnd 的大小。这导致了每个 RTT ， cwnd 只增加约一个 MSS ，这是一个线性的增长。ACK （意味着网络中的数据分段丢失），则认为发生了网络拥塞。此时， ssthresh 会被设置为当前 cwnd 的一半，并将 cwnd 重新设置为 1MSS ，然后重新进入慢开始阶段。传统的TCP重传是基于重传计时器的：当计时器到期而没有收到ACK时，TCP会重新发送数据（超时重传）。然而，在有高带宽或低延迟的网络中，等待这个计时器到期可能是低效的。
快速重传 机制是当发送方连续收到三个重复的ACK（表示同一个数据段）时，它会立即重传下一个待确认的数据段，而不是等待重传计时器到期。这三个重复的ACK是网络中丢失一个分段的一个早期指示。
一旦触发了快速重传，TCP进入 快速恢复 模式，按照书上的说法，触发了快速重传后，ssthresh 和 cwnd 都被设定为快速重传前 cwnd 值的一半，然后执行拥塞避免算法。
但是在实际 TCP 的实现中 ssthresh 被设定为当前 cwnd （拥塞窗口）的一半。同时， cwnd 也会被设定为 ssthresh 加上三个 MSS （最大段大小），然后执行如下策略：
cwnd 的增加：在快速恢复期间，每当收到一个重复的 ACK ， cwnd 都会增加一个分段的大小。这是为了用新的数据分段平衡可能在传输路径中出现的丢失。ACK ，这表示之前丢失的分段已被成功接收。这时， TCP 会退出快速恢复模式，并将 cwnd 设置为 ssthresh 的值，然后进入拥塞避免阶段。这里注意一下即可，考试考到的话按照书中方式计算 cwnd。
总结一下：
cwmd < ssthresh时，使用慢开始算法，swnd以指数增长cwmd >= ssthresh时，使用拥塞避免算法，swnd线性增长cwnd = ssthresh = cwnd / 2，开始使用拥塞控制算法ssthresh = cwnd / 2, cwnd = 1，开始使用慢开始算法初始窗口大小？
TCP连接的初始窗口大小可以根据TCP/IP协议栈的实现和操作系统的配置而有所不同。通常情况下，初始窗口大小是根据TCP的初始拥塞窗口（Initial Congestion Window，ICW）来确定的。
RFC 6928建议了一种用于确定TCP连接初始拥塞窗口大小的算法，该算法是根据实验和观察得出的最佳实践。根据这个RFC，初始拥塞窗口大小（ICW）的推荐值为10个MSS （了解即可）。
发送窗口的大小？
发送窗口大小为拥塞窗口和接收窗口中的较小值，swnd = min(cwnd, rwnd)，当发送方收到来自接收方的确认报文时，会根据其中的 window 字段来调整 rwnd 大小，也会根据收到的确认信息或者超时去调整 cwnd 的大小。当 cwnd 或者 rwnd 变化时，会调整 swnd 的大小。
接收窗口的大小？
接收方会根据自身处理能力和缓冲区的情况来动态调整窗口大小。如果接收方的应用程序不能及时处理接收到的数据，或者接收方的缓冲区已经满了，它就会减小窗口大小，以通知发送方降低发送速率。
UDP（User Datagram Protocol）首部的长度固定为 8 个字节（64 位），不论 UDP 携带的数据量大小如何，其首部都保持不变。UDP 首部的各个字段如下：
当传输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过 相应的端口，上交最后的终点一一应用进程，如下图所示：
若接收方 UDP 发现收到的报文中的目的端口号不正确（即不存在对应于端口号的应用进程），则就丢弃该报文，并由 ICMP 发送“端口不可达”差错报文给发送方。
UDP 的校验和（checksum）用于检测数据在传输过程中是否发生错误。它覆盖 UDP 头部、数据部分以及部分 IP 头部信息（伪头部），确保数据的完整性。
这种简单的差错检验方法的校错能力并不强，但它的好处是简单、处理速度快。
UDP 的发送方需要计算 checksum 字段的值，并且填充进 UDP 首部相应字段中。 发送方计算 checksum 包含构造伪首部、组合校验数据、计算 16 位和、按位取反四个步骤。
为了确保源和目的地址的正确性，UDP 校验和包含一个伪头部（不实际传输，仅用于计算）。伪头部包括：
将以下内容按 16 位分组：
1 0000 0000 0000 0001，则取低 16 位 0000 0000 0000 0001 并加 1，得 0000 0000 0000 0010。1111 1111 1111 1111（全 1），以避免与“校验和禁用”（全 0）混淆。注意
检验时，若 UDP 数据报部分的长度不是偶数个字节，则需填入一个全 0 字节进行填充
若 UDP 检验和检验出 UDP 数据报是错误的，则可以丢弃，也可以交付给上层，但是需要附上错误报告，即告诉上层这是错误的数据报。
计算 16 位和的过程中，如果有进位，不要忘记 “回卷”。
接收端通过以下步骤验证数据完整性：
1111 1111 1111 1111（全 1）。假设我们要发送一个 UDP 数据报，相关信息如下：
则得到 16 位组合数据和校验和计算过程如下所示：
计算得到的校验和为：00111011 00011111（十六进制：0x3B1F）。
当接收端接收到 UDP 数据报是，接收端将所有 16 位数（包括校验和 00111011 00011111）相加：
重复上述加法，最后一步加上校验和：11000100 11100000 + 00111011 00011111 = 11111111 11111111（全 1）
UDP 常用于 一次性传输较少数据 的网络应用，如 DNS、SNMP 等，因为对于这些应用，若采用 TCP，则将为连接创建、维护和拆除带来不小的开销。
UDP 也常用于 对延迟敏感 多媒体应用（如 电子游戏、实时视频会议、流媒体等），显然，可靠数据传输对这些应用来说并不是最重要的， 但 TCP 的拥塞控制会导致数据出现较大的延迟，这是它们不可容忍的。
UDP 不保证可靠交付，但这并不意味着应用对数据的要求是不可靠的，所有维护可靠性的工作可由用户在应用层来完成。应用开发者可根据应用的需求来灵活设计自己的可靠性机制。
比如 HTTP3 中使用的 QUIC 就是在 UDP 的基础上实现的一种可靠传输协议。