传输层
第五章_传输层
5.1 传输层提供的服务
传输层提供的服务如下图所示：
特别的，针对传输层协议、端口和进程，需做如下图所示的简单说明：
5.2 UDP 协议
5.2.1 UDP 与 TCP 的特点对比
UDP:
- UDP 首部很小，只占 8B
- UDP 每次传输一个完整的报文，不支持报文自动拆分、重装，如果应用层交给 UDP 的数据超过了 UDP 数据报允许的最大大小，一般会出现 发送失败或需要应用层自己拆分。
- UDP 是无连接的、不可靠的（可靠性可以交给应用层处理），也不支持拥塞控制
- UDP 支持一对一（封装成单播 IP 数据报）、一对多传输（封装成广播 / 多播 IP 数据报）
- UDP 接收方检验出错会直接丢弃数据报，不通知发送方。
TCP:
- TCP 首部更大，占 20~60B
- TCP 支持报文自动拆分、重装，因此可以传输长报文
- TCP 是有连接的、可靠的、支持拥塞控制
- TCP 仅支持一对一传输（因为通信双方的传输层必须先建立连接）
- TCP 接收方检验出错会丢弃数据报之后通知发送方重传。
因此，UDP 无法传输大数据，常用于一次性传输少量数据的应用（如 DHCP、DNS）等，提醒一下，在网络层 IP 数据报在超过 MTU 时候还会分片，不只是 TCP 会拆分数据。
5.2.2 UDP 数据报
UDP 数据报格式如下图所示：
5.2.3 UDP 检验
在发送方进行 UDP 检验和的计算前，需添加一个伪首部，计算完成后再去掉。如图所示：
接着 发送方 先将 检验和字段置为全 0，然后将 伪首部 + 首部 + 数据部分 视为一连串 16 位字。若 UDP 数据部分的长度为奇数个字节，则在计算时末尾补全一个 0B。然后 进行二进制反码求和（就多个回卷），算出来的结果 再取反码 就是校验位的结果。二进制反码求和计算过程如图所示：
在 接收方 进行验证：将伪首部添上，然后将伪首部 + 首部（包括校验和） + 数据部分 视为一连串 16 位字（有需要补 0B），直接进行二进制反码加法（就多个回卷）即可，若结果全为 1 代表对的，反之则检验出错。记住 UDP 检验出错，直接丢弃数据报，不通知发送方！！
我原来的思想是这样：先将首部校验和设为全 0，按照发送方计算校验位的方法计算出结果再和首部校验和相比较，这样有些 多此一举。
以一个真题为例进行练习：
5.3 TCP 协议
5.3.1 TCP 协议的框架梳理
TCP 协议分为“三大阶段”，如图所示：
对于其中一些模糊的概念，我们先要进行明晰：
- TCP 报文和 TCP 报文段（TCP 段），指的是一个东西，因为 TCP 协议支持报文拆分重装，因此应用层的报文较长也是可以的。
- 一次链接可以传输多个报文（初学者易混，但我不是初学者，嘿嘿），如图所示：
5.3.2 TCP 报文段格式
我们需要理解并记住各个 TCP 报文段各个字段的作用，接下来我将从上到下，挨个探讨各个字段：
-
ACK、ack 和 序号： 注意：只有握手 1 报文段的 ACK 都必须置为 0，其余必须全置为 1。
-
数据偏移、保留 和 填充：
-
URG、PSH、RST 和 紧急数据：
-
SYN 和 FIN：
-
接收窗口：
-
检验和：
-
选项：
5.3.3 TCP 连接管理（建立连接）
TCP 建立连接阶段通常会有三个考点：
- SYN、ACK、FIN、seq、ack_seq 的值是多少？
- 每发出/收到一个握手/挥手报文段之后，进程的 TCP 状态转换。
- 建立连接、断开连接的最短耗时分析。
SYN、ACK、FIN、seq、ack_seq 的值：
SYN 和 FIN 段即使不带数据也会消耗一个序号，注意是消耗的自身的序号，是让关于这个段的 返回的 ACK 段的 ack + 1，不是 seq + 1。
以一个真题来熟悉：
TCP 状态转换：
建立连接、断开连接的最短耗时分析：
5.3.4 TCP 连接管理（释放连接）
TCP 释放连接阶段和建立连接阶段具有同样的三个考点：
- SYN、ACK、FIN、seq、ack_seq 的值是多少？
- 每发出/收到一个握手/挥手报文段之后，进程的 TCP 状态转换。
- 建立连接、断开连接的最短耗时分析。
SYN、ACK、FIN、seq、ack_seq 的值：
SYN 和 FIN 段即使不带数据也会消耗一个序号，注意是消耗的自身的序号，是让关于这个段的 返回的 ACK 段的 ack + 1，不是 seq + 1。
TCP 状态转换：
以一个真题来熟悉：
建立连接、断开连接的最短耗时分析：
以一个真题来熟悉：
5.3.5 TCP 可靠传输和流量控制
可靠传输：
关于可靠传输，详细要点如下：
由于可靠传输需要动态的过程进行演示，所以首先给出原理示意图，后续的过程都可以在这张图上进行演示，如图所示：
关于这张原理示意图，值得注意的是同一端口是可以绑定多个 TCP 连接的，如图所示：
对于可靠传输要点挨个举例如下，可在上方的原理示意图中自行进行动态演示：
累计确认和捎带确认：
超时重传机制：
快重传机制：
采用延迟确认机制和超时重传机制可能会出现如下图所示的问题，由此引出快重传（立即确认）机制。
以一个真题来熟悉快重传机制：
现实中，这些可靠传输机制一般以下三者共存： 立即确认是现代TCP的默认行为（收到失序包时） 快重传是现代TCP的默认行为（收到3个重复ACK时） 超时重传是现代TCP的兜底机制（快重传失效或极端情况时）
流量控制（滑动窗口机制）：
要点如下图所示，就是滑动窗口机制，与数据链路层的三个滑动窗口协议都有些不同：能够进行累计确认，对于发现出错的 TCP 段（超时了，或者收到连续三个冗余ACK），只会重传那一个段。 与数据链路层的三个滑动窗口协议相比，除了数据粒度不同、TCP 能够乱序存储、发送窗口大小能动态变化外，TCP 的滑动窗口就像是支持累计确认的 SR。
注意：发送了但还没确认的段还是在发送窗口里，会占用一部分窗口（占用发送缓存区），不是非得等 ACK 确认了前面的段才能发后面的（那是 P-W 协议），有空的滑动窗口了就能进行发送。
5.3.6 TCP 拥塞控制
TCP 采用四种算法进行拥塞控制：慢开始、拥塞避免、快重传 和 快恢复。
TCP 拥塞控制的基本思想是基于发送方维护的 拥塞窗口（cwnd）（注意做题时问的是什么窗口） 进行实现，其控制原则如下图所示：
对于 慢开始 和 拥塞避免：
只需要掌握下面这张图，便能解决绝大多数问题：
通过两个真题来熟悉 慢开始 和 拥塞避免 算法：
注意：上面竖着的 01234 表示的都是时刻！不是 RTT! 它们中间夹的空白才是 RTT! 别搞混了。
对于 快重传 和 快恢复：
与上图类似，不过上图 第 12 轮次遇到的是“严重拥塞”，而下图处理的是网络遇到“有点拥塞”，故采用快恢复。
附言
快结束了，差个应用层（睡..睡..）