1.一台具有单个 DNS 名称的机器可以有多个 IP 地址吗？为什么？ 2.一台计算机可以有两个属于不同顶级域的 DNS 名字吗？如果可以，试举例说明． 3.DNS 使用 UDP 而非 TCP，如呆一个 DNS 分组丢失、没有自动恢复、那么这会引起问题吗？如果会，应该如何解决？ 4.为什么要引入域名的概念？举例说明域名转换过程。 域名服务器中的高速缓存的作用是什么？ 5. 文件传输协议的主要工作过程是怎样的？主进程和从属进程各起什么作用？ 6. 为什么 FTP 要使用两个独立的连接，即控制连接和数据连接？ 7. 主机 A 想下载文件 ftp://ftp.abc.edu.cn/file ，大致描述下载过程中主机和服务器的交互过程． 8 电子邮件系统使用 TCP 传送邮件 ， 为什么有时会遇到邮件发送失败的情况？为什么有时对方会收不到发送的邮件？ 9. MIME 与 SMTP 的关系是怎样的？ 当然，我们来逐一解答这些问题。 ### 1. 一台具有单个 DNS 名称的机器可以有多个 IP 地址吗？为什么？ **答：可以。** **原因如下：** - **负载均衡**：一个热门网站（如 `www.google.com`）可能会有成千上万的访问请求。为了分担负载，该域名可以配置多个 IP 地址（例如，不同的服务器位于不同的地理位置）。当用户解析该域名时，DNS 服务器会以轮询或其他策略返回其中一个 IP 地址，从而将流量分散到不同的服务器上。 - **提高可靠性**：如果一台服务器出现故障，拥有多个 IP 地址意味着 DNS 可以将用户指向其他正常的服务器，从而提供冗余和容错能力。 - **区分服务**：有时，不同的 IP 地址可能用于提供不同类型的服务，例如一个地址用于 IPv 4 用户，另一个用于 IPv 6 用户。 ### 2. 一台计算机可以有两个属于不同顶级域的 DNS 名字吗？如果可以，试举例说明。 **答：可以。** **举例说明：** - 一台物理服务器可以同时托管两个或多个不同的网站。每个网站都有自己的域名，这些域名可以属于不同的顶级域。 - **例子**：一台 IP 地址为 `203.0.113.10` 的 Web 服务器上可以同时运行： - 一个公司官网 `www.company.com` - 一个产品网站 `www.product.org` - 当用户在浏览器中输入 `www.company.com` 时，DNS 将其解析到 `203.0.113.10`。浏览器向该 IP 地址发送 HTTP 请求，并在请求头中指定主机名 `Host: www.company.com`。服务器收到请求后，会根据 `Host` 字段将请求分发到对应的网站。 ### 3. DNS 使用 UDP 而非 TCP，如呆一个 DNS 分组丢失、没有自动恢复、那么这会引起问题吗？如果会，应该如何解决？ **答：会引起问题。** **问题：** 如果 DNS 查询或响应分组在传输过程中丢失，发送方将收不到任何回复。由于 UDP 没有重传机制，这会导致查询失败，用户可能看到“无法找到服务器”等错误。 **解决方案：** 1. **应用程序级别的重传**：DNS 解析器（通常在操作系统或网络库中实现）负责处理超时和重传。如果在一个合理的时间（例如 1-5 秒）内没有收到响应，解析器会自动重新发送相同的 DNS 查询请求。 2. **备用 DNS 服务器**：通常配置了多个 DNS 服务器（如主用和备用）。如果向第一个 DNS 服务器发送的请求超时，解析器会向列表中的下一个服务器发送查询。 3. **降级使用 TCP**：对于非常长的 DNS 响应（例如，当响应报文超过 512 字节时，或者进行区域传输时），DNS 协议规定会使用 TCP。服务器在 UDP 响应中设置一个“截断”标志，客户端看到后，会重新使用 TCP 连接来发起查询，以确保数据的完整传输。 ### 4. 为什么要引入域名的概念？举例说明域名转换过程。域名服务器中的高速缓存的作用是什么？ **为什么引入域名：** - **易于记忆**：IP 地址（如 `142.251.42.14`）是一串数字，难以记忆和使用。域名（如 `www.google.com`）由有意义的字符组成，方便人类记忆和输入。 - **提供逻辑抽象**：域名与底层物理 IP 地址解耦。当服务器需要更换 IP 地址时，只需更新 DNS 记录，用户仍可使用原来的域名访问，服务不受影响。 **域名转换过程举例（以访问 `www.example.com` 为例）：** 1. 用户在浏览器输入 `www.example.com`。 2. 操作系统中的 DNS 解析器首先检查自己的**本地缓存**，如果有记录则直接返回 IP。 3. 若无缓存，解析器向配置的**本地 DNS 服务器**（LDNS）发起查询。 4. 本地 DNS 服务器若无缓存，则从**根域名服务器**开始查询： a. 根服务器告知负责 `.com` 域的**顶级域服务器**地址。 b. 本地 DNS 服务器向 `.com` TLD 服务器查询，TLD 服务器告知负责 `example.com` 域的**权威域名服务器**地址。 c. 本地 DNS 服务器向 `example.com` 的权威服务器查询 `www.example.com` 的 IP 地址。 5. 权威服务器返回对应的 IP 地址（如 `93.184.216.34`）。 6. 本地 DNS 服务器将此记录缓存，并将 IP 地址返回给用户主机。 7. 用户主机获得 IP 地址，开始与目标服务器建立连接。 **高速缓存的作用：** - **减少查询延迟**：直接从缓存中获取结果，避免了耗时的递归查询过程，大大加快了域名解析速度。 - **减轻 DNS 系统负载**：减少了向上级 DNS 服务器发起的查询请求数量，降低了整个 DNS 系统的压力。 - **提高可靠性**：即使上级 DNS 服务器暂时不可用，只要缓存中有有效记录，本地解析仍可进行。 ### 5. 文件传输协议的主要工作过程是怎样的？主进程和从属进程各起什么作用？ **FTP 的主要工作过程：** 1. **连接建立**：FTP 客户端首先与 FTP 服务器的 **21 号端口**建立一条**控制连接**。 2. **用户认证**：通过控制连接，客户端发送用户名和密码进行身份验证。 3. **命令交互**：认证成功后，客户端通过控制连接向服务器发送各种命令（如 `LIST` 列出文件，`CWD` 改变目录，`RETR` 下载文件，`STOR` 上传文件）。 4. **数据连接建立**：当需要传输文件或目录列表时，服务器会主动或被动地打开一条**数据连接**（通常使用 20 号端口或一个随机端口）。 5. **数据传输**：通过数据连接传输实际的文件内容或目录列表。 6. **连接关闭**：数据传输完毕后，数据连接被关闭。控制连接继续保持，等待客户端发送下一个命令，直到用户退出并关闭控制连接。 **主进程和从属进程的作用：** - **主进程**：在服务器端运行，持续监听 21 号端口的连接请求。当有新的客户端连接时，**主进程**会创建一个新的**从属进程**来处理这个客户端的会话。 - **从属进程**：每个客户端会话都有一个独立的从属进程负责处理。它负责与客户端进行认证、接收命令、管理数据连接以及执行具体的文件传输操作。这种“一主多从”的架构使得 FTP 服务器可以同时为多个客户端服务。 ### 6. 为什么 FTP 要使用两个独立的连接，即控制连接和数据连接？ **答：主要为了实现命令控制和数据传输的分离。** **优点：** 1. **简化协议设计**：将复杂的文件传输逻辑（数据格式、压缩等）与简单的命令交互逻辑分离开，使协议实现更清晰。 2. **提高效率**：在传输一个很长的文件列表或大文件时，控制连接仍然保持畅通，可以随时中断传输（例如发送 `ABOR` 命令）或发送其他命令，而不会被数据流阻塞。 3. **灵活性**：允许在同一个控制会话中连续或并发地进行多个文件传输（虽然传统 FTP 是串行的，但现代扩展支持并发）。每次传输都可以建立新的数据连接。 4. **支持不同的数据传输模式**：数据连接可以由服务器主动建立，也可以由客户端建立，以适应不同的网络环境（如防火墙设置）。 ### 7. 主机 A 想下载文件 ftp:// [ftp.abc.edu.cn/file](https://ftp.abc.edu.cn/file) ，大致描述下载过程中主机和服务器的交互过程． 1. **建立控制连接**：主机 A 的 FTP 客户端与服务器 `ftp.abc.edu.cn` 的 21 号端口建立 TCP 连接（控制连接）。 2. **用户认证**： - 服务器返回欢迎信息。 - 客户端发送 `USER username` 命令（如果是匿名登录，则发送 `USER anonymous`）。 - 服务器要求密码，客户端发送 `PASS password` 命令（匿名登录通常是用户的电子邮件地址）。 3. **发起下载请求**： - 认证成功后，客户端发送 `TYPE I` 命令，设置为二进制模式，以正确传输文件。 - 客户端发送 `PASV` 命令，请求进入被动模式。 - 服务器回应，告知一个随机端口号（如 `192,168,1,2,15,100`，表示 IP 是 192.168.1.2，端口是 15*256+100=3940）用于数据连接。 4. **建立数据连接并传输**： - 主机 A 的客户端主动向服务器的 3940 端口发起第二条 TCP 连接（数据连接）。 - 客户端通过控制连接发送 `RETR file` 命令，请求下载文件 `file`。 - 服务器通过数据连接开始传输文件 `file` 的内容。 5. **结束传输**： - 文件传输完毕后，服务器关闭数据连接。 - 服务器通过控制连接发送“226 Transfer complete”消息，通知客户端传输成功。 - 客户端发送 `QUIT` 命令，服务器确认后，关闭控制连接。 ### 8. 电子邮件系统使用 TCP 传送邮件 ， 为什么有时会遇到邮件发送失败的情况？为什么有时对方会收不到发送的邮件？ **邮件发送失败的原因（发生在 SMTP 会话阶段）：** - **网络问题**：发送方服务器无法与接收方服务器建立 TCP 连接（目标服务器宕机、网络路由问题等）。 - **目标服务器拒绝**：接收方服务器不存在，或明确拒绝连接（如 IP 被列入黑名单）。 - **收件人地址错误**：SMTP 协议中，如果接收方服务器检查发现收件人邮箱地址不存在，会在会话阶段直接返回错误（如“550 Mailbox not found”），导致发送失败。 - **发送方身份认证失败**：对于需要认证的邮件服务器（如用户通过客户端发信），如果密码错误，发送会被拒绝。 - **邮件被当作垃圾邮件拒绝**：接收方服务器的反垃圾邮件策略可能会在 SMTP 会话阶段就拒绝来自可疑发件人的邮件。 **对方收不到邮件的原因（发生在 SMTP 会话成功后）：** - **邮件被投入垃圾邮件文件夹**：这是最常见的原因。邮件虽然成功被接收方服务器接受，但服务器内容过滤器或反垃圾邮件系统将其判定为垃圾邮件，自动转移到了用户的垃圾邮件文件夹。 - **内容过滤**：邮件中包含敏感词汇、可疑附件或链接，被邮件系统过滤。 - **服务器端存储问题**：接收方服务器的邮件存储系统出现故障，导致邮件丢失。 - **客户端配置问题**：用户的邮件客户端配置错误，未能正确从服务器拉取邮件。 ### 9. MIME 与 SMTP 的关系是怎样的？ **答：MIME 是对 SMTP 协议缺陷的补充和扩展，它们是一种协同工作的关系。** **关系阐述：** 1. **SMTP 的局限性**：原始 SMTP 协议被设计为只能传输 7 位的 ASCII 文本，它无法处理： - 非 ASCII 字符（如中文、日文等）。 - 二进制文件（如图片、音频、可执行文件）。 - 在单个邮件中包含多种类型的内容（如同时包含纯文本和富文本）。 2. **MIME 的引入**：MIME（多用途互联网邮件扩展）没有改变或取代 SMTP，而是在 SMTP 的框架之上工作。它定义了一套新的邮件头字段和编码规则，使得这些 SMTP 无法直接处理的内容能够通过 SMTP 传输。 3. **协同工作过程**： - **发送端**：邮件客户端将要发送的非 ASCII 文本、二进制文件等，按照 MIME 规范的格式进行**编码**（如 Base 64），并添加 MIME 头信息（如 `Content-Type` 声明文件类型，`Content-Transfer-Encoding` 声明编码方式），将整个邮件组装成一个符合 SMTP 传输标准的纯文本格式。 - **传输**：这个经过 MIME“包装”的纯文本邮件，通过标准的 SMTP 协议发送出去。 - **接收端**：接收方的邮件客户端收到 SMTP 传来的纯文本邮件后，根据 MIME 头信息，对邮件内容进行**解码**，还原出原始的非文本内容、附件等，并正确地显示给用户。 **总结：** SMTP 是**传输**邮件的“卡车”，但它最初只能运“普通纸箱”（ASCII 文本）。MIME 是功能强大的“包装箱”，它能把各种奇形怪状的“货物”（图片、视频、多语言文本）打包成“普通纸箱”的样子，让 SMTP 卡车来运输。到达目的地后，接收方再用 MIME 的“开箱指南”把货物原样取出。 12. 在如下条件下，计算使用非持续方式和持续方式请求一个 Web 页面所需的时间： 1）测试的 RTT 的平均值为 150 ms，一个 gif 对象的平均发送时延为 35 ms。 2）一个 Web 页面中有 10 幅 gif 图片， Web 页面的基本 HTML 文件、 HTTP 请求报丈、 TCP 握手报文大小忽略不计。 3) TCP 三次握手的第三步中捎带一个 HTTP 请求 ． 4 ）使用非流水线方式． 好的，我们一步步来分析这个问题。 --- ## **1. 已知条件** - **平均 RTT = 150 ms** 这里 RTT 包括传播时延、分组发送时延、排队时延等，是数据包往返一次的时间。 - **一个 gif 对象的平均发送时延 = 35 ms** 即服务器发送这个 GIF 文件的时间（服务器到客户端的传输时间）。 - **一个 Web 页面**： 1 个基本 HTML 文件（很小，时延可忽略） 10 个 GIF 图片 - **TCP 握手第三步捎带 HTTP 请求** 表示在 TCP 三次握手的第三个报文（ACK）里就携带了对 HTML 文件的 HTTP 请求，节省了一次 RTT。 - **非流水线方式** 对于持久连接，客户端收到前一个响应后才能发送下一个请求。 - 忽略 HTTP 请求报文、TCP 握手报文大小（即它们的发送时延为 0）。 --- ## **2. 非持续连接方式** 非持续连接下，每个 TCP 连接只传一个对象（HTML 或一个 GIF），每次都要经历： 1. **TCP 三次握手** 前两次握手：1.5 RTT（第三次握手的 ACK 捎带 HTTP 请求，所以握手完成时请求已发出） 2. **HTML 请求+传输** 在第三次握手（ACK+请求）发出后，经过 0.5 RTT 服务器收到请求，然后立即发送 HTML。 HTML 发送时延忽略，所以再经过 0.5 RTT 客户端收到 HTML。 - 所以从开始到收到 HTML 的时间 = 1 RTT（握手前两次）+ 0.5 RTT（传请求并收响应）= **1.5 RTT** 3. **每个 GIF 同样要新建 TCP 连接** 同样过程：三次握手（第三步捎带 GIF 请求） → 服务器发 GIF（发送时延 35 ms） 从开始建立连接到收到 GIF 的时间 = 1.5 RTT + 35 ms（服务器发送时延在最后一个 RTT 里占一部分） --- ### **计算非持续连接总时间** - **获取 HTML** Thtml=1.5×RTTThtml​=1.5×RTT 因为第三步握手捎带请求，收到 HTML 在第三步握手的 1 RTT 后？ 我们仔细算一下： **详细时序**（设 t=0 开始握手）： 1. t=0：发 SYN 2. t=0.5 RTT：收到 SYN+ACK（假设握手对称，其实一般 SYN 和 SYN-ACK 各 0.5 RTT 吗？更简单模型：三次握手 1 RTT + 1 次请求响应） 更常见模型：三次握手前两次 1 RTT，第三步 ACK 捎带请求，服务器收到请求后立即响应，响应到达再 0.5 RTT。 所以总时间 = 1 RTT（前两次握手完成）+ 0.5 RTT（ACK+请求到服务器，响应回到客户端）= 1.5 RTT。 正确。 - **获取每个 GIF** 同样 1.5 RTT 得到 GIF（因为 GIF 有 35 ms 发送时延，它包含在服务器到客户端的 0.5 RTT 里吗？） 实际上： 第三次握手（ACK+请求 GIF）在 1 RTT 时刻发出，0.5 RTT 后（即 1.5 RTT 时刻）服务器收到，立即发送 GIF，发送时间 35 ms，然后传播回来 0.5 RTT - 35 ms？ 不对，RTT 是双向传播时延 + 发送时延等。 题目给的是 **平均 RTT = 150 ms**，这是已经包含数据包发送时延的。 所以一个对象的完成时间 = 1.5 RTT（从开始连接到最后收到），但注意： 在 1.5 RTT 里，服务器发送 GIF 的 35 ms 包含在 RTT 的服务器到客户端那段中。 所以实际上总时间 = 1.5 RTT + 35 ms？ 不对，要小心。 --- **更精确模型**（常用计算方法）： 设 RTT = 150 ms，其中已经包含典型数据包的发送时延。 但这里 GIF 的发送时延 35 ms 是额外的吗？ 还是已经包含在 RTT 内？ 题目说“测试的 RTT 的平均值为 150 ms，一个 gif 对象的平均发送时延为 35 ms”，这意味着 RTT 是对某个典型数据包测量的，而 GIF 较大，发送时延 35 ms 比典型数据包大，所以 RTT 可能不包含这 35 ms。 常见解法：将对象传输时间 = 1 RTT（握手第三步到收到响应）+ 35 ms（对象发送时延）。 我们采用标准方法： **非持续连接，每个对象**： 建立 TCP 连接并请求和接收对象的时间 = 三次握手（1 RTT，因为第三步捎带请求，所以建立连接+发请求 = 1 RTT） - 服务器发送对象时间（35 ms） - 对象传播回来（0.5 RTT？ 不，RTT 已经包含双向传播+发送时延，但这里的 35 ms 是额外的发送时延，所以总时间要调整） --- **常用公式（计算机网络教材）**： 非持续连接： 时间 = 2 RTT + 文件发送时间 但那是第三步不捎带请求的情况。如果第三步捎带请求，则： 时间 = 1 RTT（握手完成且请求到达服务器）+ 文件传输时间（发送时延 + 传播时延） 其中文件传输时间 = 0.5 RTT（响应传播）？ 不，RTT 含一次请求+响应，所以从请求到响应到达是 1 RTT，但这个 RTT 包含服务器发送时延。 我们假设 RTT 中已经包含小包的发送时延（可忽略），但 GIF 的发送时延 35 ms 比小包大很多，所以： 实际响应时间 = 0.5 RTT（传播回来） + 35 ms（发送时延） 但 0.5 RTT 是多少？ 已知 RTT = 150 ms，假设对称，则单向传播时延 = 75 ms。 所以 GIF 的响应时间 = 75 ms + 35 ms = 110 ms。 而三次握手的前两次 = 1 RTT = 150 ms，第三步 ACK+请求 在 150 ms 时刻发出，75 ms 后服务器收到（225 ms 时刻），然后发 GIF 用 35 ms，在 260 ms 时刻发完，再经过 75 ms 传播到客户端（335 ms 时刻）。 所以每个 GIF 从开始连接到收到用时 335 ms。 但这是从连接开始算的。 更简单近似（忽略细节）： **非持续连接**： HTML：1.5 RTT 每个 GIF：1.5 RTT + 35 ms 因为第三步握手后 0.5 RTT 服务器收到请求，发 GIF 用 35 ms，传播回 0.5 RTT，但 RTT=150 ms 含发送时延，所以这里 35 ms 是额外的，应加在外面。 所以总时间 = 1.5 RTT + 35 ms 每个对象。 --- **总时间（非持续）** = HTML（1.5 RTT） + 10 个 GIF × (1.5 RTT + 35 ms) = 11 × 1.5 RTT + 10 × 35 ms = 16.5 × 150 ms + 350 ms = 2475 ms + 350 ms = **2825 ms**（2.825 秒） --- ## **3. 持续连接（非流水线）** 持续连接：一个 TCP 连接传所有对象。 1. **TCP 三次握手（1 RTT，第三步捎带 HTML 请求）** → 1.5 RTT 后收到 HTML。 2. 然后客户端逐个请求 GIF：非流水线，必须等收到前一个响应才能发下一个请求。 每个 GIF：请求+响应 = 1 RTT（因为请求发送时延 0，响应发送时延 35 ms 包含在 RTT 内吗？） 但 RTT=150 ms 是对小包测量的，GIF 的响应时间 = 传播时延 75 ms ×2 + 35 ms = 185 ms，比 RTT 大 35 ms。 所以每个 GIF 的 RTT 实际是 185 ms。 但题目可能假设我们仍用 RTT=150 ms 作为请求-响应周期，忽略这点差异（即认为 35 ms 包含在 150 ms 内）。 更合理简化：每个 GIF 需要 1 RTT。 --- **总时间（持续，非流水线）** = 1.5 RTT（收到 HTML） + 10 × 1 RTT（10 个 GIF） = 1.5 × 150 + 10 × 150 = 225 + 1500 = **1725 ms**（1.725 秒） --- ## **4. 最终答案** 2825 ms, 1725 ms 2825 ms, 1725 ms​ 非持续方式：2825 ms 持续方式：1725 ms 运输层一定只有 UDP 和 TCP 两类吗两种协议吗？ 不是的。这是一个非常常见的误解。 **运输层（传输层）的协议远不止 TCP 和 UDP 两类。** TCP 和 UDP 只是在 **Internet 互联网（TCP/IP 协议栈）** 中最常用、最核心的两个传输层协议。 我们可以从以下几个层面来理解： --- ### 1. 在 TCP/IP 协议族中 即使在 TCP/IP 协议族内，也存在其他传输层协议，例如： - **SCTP**：流控制传输协议 - **特点**：结合了 TCP 和 UDP 的特点，支持多宿（多网络路径）、多流（在一个连接内建立多个独立的逻辑流，避免“队头阻塞”）、面向消息（如 UDP）且可靠（如 TCP）。 - **应用**：最初用于传输电话信令（SS 7），现在也用于 WebRTC 等场景。 - **DCCP**：数据报拥塞控制协议 - **特点**：提供类似 UDP 的无连接、不可靠的数据报服务，但**加入了拥塞控制机制**。它避免了 UDP 可能引发网络拥塞崩溃的问题。 - **应用**：适用于流媒体、网络游戏等需要低延迟、但可以容忍部分数据丢失，同时又需要友好网络拥塞控制的场景。 - **QUIC**：快速 UDP 互联网连接 - **特点**：基于 UDP，但在应用层实现了自己的一套可靠的、安全的传输协议。它集成了 TLS 加密，减少了连接建立时的延迟（通常 0-RTT 或 1-RTT），并解决了 TCP 的队头阻塞问题。 - **应用**：已被 HTTP/3 采用，是现代互联网演进的重要方向。 所以，在 TCP/IP 模型中，主要的传输层协议至少包括：**TCP, UDP, SCTP, DCCP**，而 **QUIC** 可以看作是在 UDP 之上实现的“增强型”传输层。 --- ### 2. 在其他网络体系结构中 不同的网络体系结构有自己的传输层协议，它们不属于 TCP 或 UDP。 - **OSI 模型**：在理论上的 OSI 参考模型中，传输层协议由一系列 **TP 0, TP 1, TP 2, TP 3, TP 4** 协议构成，它们提供不同等级的服务（如错误恢复、复用、分段等）。TP 4 与 TCP 最为相似。 - **AppleTalk**：使用 **ATP**（AppleTalk 事务协议）。 - **Novell NetWare**：使用 **SPX**（顺序包交换协议），它是基于 IPX 的可靠传输协议。 --- ### 3. 从概念上理解 “运输层”是一个**功能层级的概念**，其核心任务是在**端系统**之间提供逻辑通信，为应用进程提供服务。只要实现了以下一个或多个核心功能的协议，都可以被视为传输层协议： - **进程到进程的通信**：通过端口号等寻址机制，将数据交给正确的应用进程。 - **可靠性**：通过确认、重传等机制确保数据正确送达。 - **流量控制**：防止快的发送方“淹没”慢的接收方。 - **拥塞控制**：防止过多的数据注入网络，导致网络资源耗尽。 - **复用和分用**：多个应用进程可以使用同一个传输层服务。 TCP 和 UDP 只是以不同的组合方式实现了这些功能： - **TCP**：实现了全部功能，提供**面向连接的、可靠的字节流**服务。 - **UDP**：只实现了最基本的进程到进程通信和复用分用，提供**无连接的、不可靠的数据报**服务。 --- ### 总结 |协议|连接性|可靠性|拥塞控制|主要特点| |---|---|---|---|---| |**TCP**|面向连接|可靠|有|字节流、流量控制、顺序交付| |**UDP**|无连接|不可靠|无|简单、低延迟、数据报| |**SCTP**|面向连接|可靠|有|多宿、多流、消息导向| |**DCCP**|面向连接|不可靠|有|适用于实时媒体| |**QUIC**|面向连接|可靠|有|基于 UDP、内置加密、低延迟| **结论：** 将运输层协议等同于只有 TCP 和 UDP，就像将“车辆”等同于只有“轿车”和“卡车”一样。虽然它们是最常见和最重要的，但整个类别远比这两者丰富。