网络协议面试题
本文最后更新于 2025年8月6日 下午
基础
OSI 七层模型和 TCP/IP 四层模型
OSI 七层模型：（从上到下）应用层，表示层，会话层，传输层，网络层，数据链路层，物理层。
TCP/IP 四层模型：（从上到下）应用层，传输层，网络层，数据链路层。
| TCP/IP 四层模型 | 典型协议 | 对应 OSI 七层模型 |
|---|---|---|
| 应用层 | HTTP、FTP | 应用层、表示层、会话层 |
| 传输层 | TCP、UDP | 传输层 |
| 网络层 | IP | 网络层 |
| 数据链路层 | - | 数据链路层、物理层 |
HTTP
通用头部
参考：https://juejin.cn/post/6952666141906960397?#heading-34
请求方式
参考：https://juejin.cn/post/6939691851746279437
http/1.1 规定如下请求方法：
- GET：获取数据
- HEAD：获取数据首部（没有数据主体）
- POST：提交数据
- PUT：修改或写入数据
- DELETE：删除数据
- CONNECT：建立连接隧道，用于代理服务器
- OPTIONS：列出可对资源实行的请求方法，常用于跨域
- TRACE：追踪请求-响应的传输路径
GET 和 POST
参考：
https://juejin.cn/post/7351301328206331939?#heading-0
GET 是从服务器请求数据，可以是静态的文本、页面、图片、视频等。而 POST 是提交数据。
安全性
从服务器的角度看，GET 方法是安全的，因为是只读操作，⽆论操作多少次服务器上的数据都是安全的。而 POST 方法是新增或者提交数据的操作，会修改服务器上的资源，而且多次提交数据就会创建多个资源，所以不安全。从传输数据的角度看，GET 请求的参数会暴露在 URL 之后，因此不能用于传输敏感信息，如密码等。而 POST 请求的参数在请求体中，不会在 URL 中显示，相对更加安全。幂等性
GET 请求是幂等的，即多次执行同一 GET 请求，服务器将返回相同的结果。而 POST 请求不是幂等的，因为每次提交都会创建新的资源，可能会修改服务器上的资源。请求参数位置
GET 请求的请求参数会附加在 URL 之后，参数间使用”&”连接，多个参数会造成 URL 长度增加。而 POST 请求的请求参数多包含在请求体中，不会在 URL 中显示。请求长度限制
由于 GET 请求的参数附加在 URL 之后，因此其请求长度受限于浏览器对 URL 长度的限制（通常浏览器对 URL 的长度有限制，而服务器对 URL 的长度限制更为宽松）。而 POST 请求则没有这个问题，请求参数包含在请求体中，因此可以传输大量数据。缓存
GET 请求可以被缓存，而 POST 请求则不会，除非在响应头中包含适当的 Cache-Control 或 Expires 字段。
状态码
| 类别 | 含义 | |
|---|---|---|
| 1xx | Information（信息状态码） | 提示信息，目前是协议中间态，还需要后续操作 |
| 2xx | Success（成功状态码） | 成功，报文已经收到并被正确处理 |
| 3xx | Redirection（重定向状态码） | 重定向，资源位置发送变动，需要客户端重新请求 |
| 4xx | Client Error（客户端错误状态码） | 客户端错误，请求报文错误，服务器无法处理 |
| 5xx | Server Error（服务端错误状态码） | 服务器错误，服务器在处理请求时内部出错 |
| 常用状态码 | 含义 |
|---|---|
| 101 | 表示服务器已接受客户端的请求，并将切换到新的协议 |
| 200 | 请求成功，一切正常 |
| 301 | 永久重定向，资源已经不存在，需用新 URL 访问，浏览器会自动重定向并缓存 |
| 302 | 临时重定向，资源还在但暂时需用新 URL 访问，浏览器会自动重定向并不缓存 |
| 303 | 临时重定向，重定向到新地址时，客户端必须使用 GET 方法请求新地址 |
| 304 | 缓存重定向，请求的资源未修改，重定向至已存在的缓存文件，用于缓存控制 |
| 307 | 临时重定向，和 302 相似，唯一区别是不允许将请求方法从 POST 改为 GET |
| 308 | 永久重定向，和 301 相似，唯一区别是不允许将请求方法从 POST 改为 GET |
| 400 | 客户端请求报文错误，但原因未知 |
| 401 | 用户身份验证未通过 |
| 403 | 服务器理解请求但拒绝授权禁止访问，不是客户端的请求出错 |
| 404 | 请求的资源在服务器上不存在或未找到 |
| 500 | 服务器处理错误，但原因未知 |
| 503 | 服务器繁忙，暂时无法响应 |
200 OK
成功，表示请求在服务器被正常处理。
301 Moved Permanently
永久重定向，表示请求的资源已经不存在，需用新 URL 访问，浏览器会自动重定向并缓存。
302 Found
临时重定向，表示请求的资源还在但暂时需用新 URL 访问，浏览器会自动重定向并不缓存。
通常用于以下场景：
- 页面临时跳转:
- 维护公告:
当网站需要进行维护或升级时，可以将用户重定向到维护页面，并使用 302 状态码表示此跳转是临时的。 - 测试新功能:
在开发新功能或进行 A/B 测试时，可以将部分用户重定向到新功能页面，并使用 302 状态码，以便随时切换回旧版本。 - 个性化推荐:
根据用户行为或偏好，将用户重定向到不同的内容页面，并使用 302 状态码，以便根据用户反馈进行调整。
- 维护公告:
- URL 重定向:
- 短链接:
将长 URL 转为短 URL 并将短 URL 指向长 URL，使用 302 状态码，方便用户分享和传播。 - 移动端适配:
根据用户设备是 PC 端还是移动端，将用户重定向到不同的 URL，使用 302 状态码。
- 短链接:
- 身份验证:
- 登录重定向:
在用户未登录时，将用户重定向到登录页面，登录成功后，再重定向回原来的页面，使用 302 状态码。 - 授权重定向:
在用户需要授权访问某些资源时，将用户重定向到授权页面，授权成功后，再重定向回原来的页面，使用 302 状态码。
- 登录重定向:
303 See Other
临时重定向，与 302 含义相同，不同的是，重定向到新地址时，客户端必须使用 GET 方法。
307 Temporary Redirect
临时重定向，与 302 含义相同，不同的是，重定向到新地址时，不允许把方法从 POST 改为 GET。
308 Permanent Redirect
永久重定向，与 301 含义相同，不同的是，重定向到新地址时，不允许把方法从 POST 改为 GET。
400 Bad Request
客户端请求报文错误，但原因未知。
401 Unauthorized
用户身份验证未通过。
403 Forbidden
服务器理解请求但拒绝授权禁止访问，不是客户端的请求出错。
404 Not Found
请求的资源在服务器上不存在或未找到，也可能是服务器端在拒绝请求且不想说明原因。
500 Internal Server Error
服务器处理错误，但原因未知。
503 Service Unavailable
服务器繁忙，暂时无法响应。
缓存机制
参考：
https://juejin.cn/post/6844903517702848526
https://juejin.cn/post/6844904021308735502
https://juejin.cn/post/7127194919235485733
规则
HTTP 缓存属于客户端缓存。浏览器中存在一个缓存数据库，用于储存一些不经常变化的静态文件。缓存分为强制缓存和协商缓存。这两类缓存机制同时存在，强制缓存的优先级高于协商缓存：当执行强制缓存时，如果缓存命中，则不再进行缓存协商。
强制缓存
当缓存数据库中已有所请求的数据，而且没有过期时，属于强制缓存命中，浏览器不会向服务器发送请求，而是直接返回状态码 200 并且从缓存数据库获取数据；当缓存数据库中没有所请求的数据或是数据已过期，属于强制缓存未命中，浏览器才会向服务器发起请求。
协商缓存
如果是缓存数据库的数据已过期，则浏览器向服务器发起请求前，会先从缓存数据库中获取一个缓存数据标识，得到标识后请求服务器来验证数据是否已失效。如果标识未失效（资源未更新），属于协商缓存命中，服务器返回状态码 304，并且告诉浏览器直接使用缓存数据库资源；如果标识失效（资源已更新），属于协商缓存未命中，服务器返回状态码 200 和新资源。
方案
浏览器和服务器是如何判断缓存是否过期和失效呢？浏览器和服务器进行交互的时候会发送一些请求数据和响应数据，我们称之为 HTTP 报文。报文中包含首部 header 和主体部分 body。与缓存相关的规则信息就包含在 header 中，body 中的内容是 HTTP 请求真正要传输的部分。HTTP 中缓存机制在首部 header 中相关参数为 Expires、Cache-Control、Last-Modified、If-Modified-Since、Etag、If-None-Match 等。
强制缓存
对于强制缓存，服务器响应的 header 中会用两个字段来表明：Expires 和 Cache-Control。
- Expires
Expires 的值为服务端返回的数据到期时间。当再次请求时的请求时间小于此时间，则直接使用缓存数据库的数据。但是服务器的时间和浏览器的时间可能并不一致，那服务器返回的这个过期时间可能就是不准确的，这将导致缓存命中的误差。
- Cache-Control
Cache-Control 有很多属性，不同的属性代表的意义也不同。最主要是 max-age，当 max-age 设为 300 时，则代表在这个请求正确返回时间的 300 秒（5 分钟）内再次加载资源，就会命中强制缓存。除 max-age 外，还有其它比较常用的设置值，可组合使用。
Expires 是 HTTP1.0 头字段，Cache-Control 是 HTTP1.1 头字段，如果 Expires 和 Cache-Control 同时存在，则 Cache-Control 会覆盖 Expires。
协商缓存
协商缓存需要进行对比判断是否可以使用缓存。浏览器第一次请求数据时，服务器会将缓存标识与数据一起响应给客户端，客户端将它们备份至缓存中。再次请求时，客户端会将缓存中的标识发送给服务器，服务器根据此标识判断数据是否失效。
- Last-Modified：
服务器在响应请求时，通过此字段告诉浏览器当前资源的最后修改时间。
- If-Modified-Since
浏览器再次请求服务器时，浏览器的请求报文头部会包含此字段，后面跟着缓存数据库中获得的最后修改时间 Last-Modified。服务器接收到此请求头后发现 If-Modified-Since，则与被请求资源的最后修改时间来进行对比。
- Etag
服务器在响应请求时，通过此字段告诉浏览器当前资源的唯一标识（生成规则由服务器决定）。
- If-None-Match
浏览器再次请求服务器时，浏览器的请求报文头部会包含此字段，后面跟着缓存数据库中获得的唯一标识 Etag。服务器接收到此请求头后发现 If-None-Match，则与被请求资源的唯一标识来进行对比。
在精准度上，ETag 优于 Last-Modified，因为 ETag 是按照内容给资源上标识，因此能准确感知资的变化，而 Last-Modified 不一样，它在一些特殊的情况并不能准确感知资源变化，主要有两种情况：① 资源文件被编辑，但是文件内容并没有更改，那这样也会造成缓存失效；②Last-Modified 感知的单位时间是秒，如果资源文件在 1 秒内被多次改变，那么此时 Last-Modified 也无法体现出被修改。
在性能上，Last-Modified 优于 ETag，因为 Last-Modified 仅仅只是记录一个时间点，而 Etag 需要根据文件具体内容生成哈希值。服务器会优先考虑 ETag。
缓存位置
当强制缓存命中或者协商缓存中命中时，我们直接从缓存中获取资源，那这些资源究竟缓存在什么位置呢？浏览器中的缓存位置一共有四种，按优先级从高到低排列分别是：
- Service Worker
- Memory Cache
- Disk Cache
- Push Cache
Service Worker 借鉴了 Web Worker 的思路，即让 JS 运行在主线程之外，由于它已经脱离浏览器的窗体，因此无法直接访问 DOM。虽然如此但它仍然能帮助我们完成很多有用的功能，比如离线缓存、消息推送和网络代理等功能。其中的离线缓存就是 Service Worker Cache。
Memory Cache 是内存缓存。已经加载过该资源且缓存在内存当中，直接从内存中读取数据。关闭浏览器后数据将不存在，再次打开相同的页面时不可能再是 from memory cache。从效率上讲它是最快的，但从存活时间讲又是最短的，当渲染进程结束后，内存缓存也就不存在了。
Disk Cache 是磁盘缓存。已经在之前的某个时间加载过该资源，直接从硬盘中读取数据，关闭浏览器后数据依然存在，再次打开相同的页面时可能仍然是 from disk cache。从效率上讲比内存缓存慢，但它的优势在于存储容量和存储时长。比较大的 JS 和 CSS 文件会直接被丢进 Disk Cache，反之丢进 Memory Cache。内存使用率比较高的时候，文件优先进入磁盘。
Push Cache 是推送缓存，这是浏览器缓存的最后一道防线。它是 HTTP/2 的内容，虽然现在应用并不广泛，但随着 HTTP/2 的推广，它的应用越来越广泛。
缓存优点
- 减少了冗余的数据传递，节省宽带流量
- 减少了服务器的负担，大大提高了网站性能
- 加快了浏览器加载网页的速度
不同请求
- 地址栏写入 URL：浏览器发现缓存中有这个文件，不用继续请求，直接从缓存拿（最快）
- F5：去服务器看看缓存中的文件是否过期，于是浏览器就发送一个请求
- Ctrl + F5：先将缓存中的文件删除，然后去服务器请求完整的资源文件
HTTPS
参考：
https://juejin.cn/post/6844904021308735502#heading-84
https://juejin.cn/post/6844903599303032845#heading-8
http://ruanyifeng.com/blog/2014/02/ssl_tls.html
HTTP 是明文传输，因此在传输的每一个环节的所有信息都是明文传播，存在三大风险：窃听风险（第三方可以获知通信内容）、篡改风险（第三方可以修改通信内容）和冒充风险（第三方可以冒充他人身份参与通信）。具体来说，就是 HTTP 数据经过 TCP 层，然后经过 WIFI 路由器、运营商和目标服务端，这些环节中都可能被中间人拿到数据并进行篡改，也就是常说的中间人攻击。而且客户端和服务端无法互相认证，无法确认对方是否是真正的而非伪装的服务端和客户端。
为了安全，我们引入新的加密方案，即 HTTPS。HTTPS 并不是一个新的协议，而是一个加强版的 HTTP。其原理是在 HTTP 和 TCP 之间建立一个中间层，HTTP 和 TCP 通信时不是像以前直接通信，而是经过了一个中间层进行加密，这个中间层也叫安全层。
安全层使用 TLS/SSL 协议，核心就是对数据加解密，希望达到：所有信息都是加密传播，第三方无法窃听；具有校验机制，一旦被篡改，通信双方会立刻发现；配备身份证书，防止身份被冒充。TLS/SSL 的功能实现主要依赖于有三类算法：散列函数、对称加密和非对称加密。其中，非对称加密实现身份认证和密钥协商，对称加密用协商的密钥对数据加密，散列函数验证数据的完整性。
HTTP2
参考：
https://juejin.cn/post/7351301328206331939?#heading-1
HTTP/2 相对于 HTTP/1.x 具有显著的优势和特点：
- 二进制分帧层
HTTP/2 不再用文本格式来传输数据，而是将所有传输的信息分割为更小的消息和帧（frame），并以二进制格式进行编码。这有助于更高效地解析 HTTP 消息，并减少了解析错误的可能性。 - 多路复用
HTTP/2 引入多路复用技术，允许在单个 TCP 连接中并行处理多个请求和响应。这消除了 HTTP/1.x 中的队头阻塞问题，极大地提高了网络性能和资源利用率。 - 头部压缩
HTTP/2 使用头部压缩技术，通过共享头部信息，可以显著减少传输数据量。这有助于减少延迟和网络带宽的消耗，特别是在传输大量小请求时效果更为显著。 - 服务器推送
HTTP/2 允许服务器主动向客户端推送资源而无需等待客户端的请求。这有助于减少往返时间，并提高网页加载速度。 - 流量控制
HTTP/2 通过流控制、消息控制和窗口控制等机制，实现了对流量的精细控制，有助于防止网络拥塞和资源浪费。
总之，HTTP/2 相对于 HTTP/1.x 在传输效率、安全性、网络性能等方面都有显著提升。这些优势使得 HTTP/2 成为现代 Web 应用中广泛采用的协议标准。
长连接
参考：
https://juejin.cn/post/7351301328206331939?#heading-8
HTTP 的 keep-alive，即 HTTP 长连接，是一种通过重用 TCP 连接来发送和接收多个 HTTP 请求的机制。其主要作用包括：
- 减少连接建立开销
没有 keep-alive 时，每次 HTTP 请求都需要经过 TCP 三次握手建立连接，这会导致较大的延迟和资源消耗。而使用 keep-alive 可以在一个 TCP 连接上发送多个 HTTP 请求，从而减少了建立连接的开销。 - 降低网络负载
每次建立和关闭连接时，都会消耗网络带宽和服务器资源。通过保持持久连接，可以减少连接的频繁建立和关闭，从而降低网络负载和服务器负载。 - 提高性能和响应时间
由于避免连接建立和关闭开销，keep-alive 可以提高请求的响应时间和整体性能。客户端可以在同一个连接上连续发送请求，而服务器也可以在保持连接的情况下更快地响应这些请求。 - 支持 HTTP 管道化
HTTP 管道化是允许客户端在同一 TCP 连接中连续发送多个请求，而无需等待每个请求的响应的技术。当与 keep-alive 结合使用时，可以进一步提高性能。
keep-alive 机制在 HTTP/1.0 和 HTTP/1.1 协议中都有支持。在 HTTP/1.0 中，需要在请求头显式添加“Connection: keep-alive”来启用该机制；而在 HTTP/1.1 中，keep-alive 是默认启用的。总的来说，HTTP 的 keep-alive 通过重用 TCP 连接和优化请求处理流程，提高了 HTTP 通信的性能和效率。
TCP/UDP
三次握手和四次挥手
参考：
https://juejin.cn/post/6939691851746279437#heading-6
https://yuanrengu.com/2020/77eef79f.html
https://juejin.cn/post/6844903625513238541
https://zhuanlan.zhihu.com/p/496244348
三次握手过程
刚开始时，客户端处于 CLOSED 状态，服务端处于 LISTEN 状态。
- 第一次握手：客户端主动发起连接，发送 SYN seq = x，客户端变为 SYN-SENT 状态。
- 第二次握手：服务端收到报文后，返回 SYN-ACK seq = y、ack = x + 1（对应客户端的 SYN），服务端变为 SYN-REVD 状态。
- 第三次握手：客户端收到报文后，返回 ACK seq = x + 1、ack = y + 1，客户端变为 EASTABLISHED 状态，服务端收到 ACK 后也变为 ESTABLISHED 状态。
服务端第一次收到客户端的 SYN 之后，会处于 SYN_RCVD 状态，此时双方还没有完全建立起连接，服务端会把此种状态下的请求连接放在一个队列中，这种队列为半连接队列。对应的有全连接队列，已经完成三次握手后建立起连接的就会放在全连接队列。如果队列满了就有可能会出现丢包现象。
服务端发送完 SYN-ACK 包，如果未收到客户确认包，服务端进行首次重传，等待一段时间仍未收到客户确认包会进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统会将该连接信息从半连接队列中删除。每次重传等待的时间不一定相同，一般是指数增长，如 1s，2s，4s，8s……
第三次握手时可以携带数据，但第一次和第二次握手时不可以携带数据。第一次握手不可以放数据，其中一个简单的原因就是会让服务端更加容易受到攻击。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说已经建立起连接，并且也知道服务端的接收、发送能力正常，所以能携带数据。
为什么需要三次握手，两次不行吗
不行，无法确认客户端的接收能力。
- 第一次握手：客户端发送网络包，服务端接收。
- 客户端就能得出结论：客户端的发送能力正常。
- 服务端就能得出结论：客户端的发送能力，服务端的接收能力正常。
- 第二次握手：服务端发送网络包，客户端接收。
- 客户端就能得出结论：客户端的发送、接收能力正常，服务端的发送、接收能力正常。
- 服务端就能得出结论：客户端的发送能力，服务端的发送、接收能力正常。
（服务端并不能确认客户端的接收能力是否正常，所以两次握手不行）
- 第三次握手：客户端发送网络包，服务端接收。
- 客户端就能得出结论：客户端的发送、接收能力正常，服务端的发送、接收能力正常。
- 服务端就能得出结论：客户端的发送、接收能力正常，服务端的发送、接收能力正常。
四次挥手过程
刚开始时，客户端和服务端都处于 ESTABLISH 状态，均可主动关闭，以客户端主动关闭为例：
- 第一次挥手：客户端向服务端发送 FIN seq = u 并变为 FIN_WAIT_1 状态。
- 第二次挥手：服务端收到客户端报文后向客户端发送 ACK seq = v、ack= u + 1 并变为 CLOSED_WAIT 状态。客户端收到服务端的报文之后变为 FIN_WAIT_2 状态。
- 第三次挥手：服务端向客户端发送 FIN-ACK seq = w、ack= u + 1 并变为 LAST_ACK 状态。
- 第四次挥手：客户端收到服务端报文后向服务端发送 ACK seq = u + 1、ack= w + 1 并变为 TIME_WAIT 状态，经过 2MSL 后变为 CLOSED 状态。服务端收到报文后变为 CLOSED 状态。
为什么需要四次挥手，三次不行吗
因为 TCP 的双向通道互相独立的。把先关闭连接的一方叫做主动方，后关闭连接的一方叫做被动方。当主动方关闭连接时，主动方到被动方的传输通过已经关闭，但被动方到主动方的传输通道还在打开状态，此时的连接处于半关闭状态，此时被动方可能还在传输数据，需要等被动方传输完数据再挥手关闭。三次挥手就直接关闭，可能导致数据丢失或未完全传输完毕。
2MSL 等待状态
TIME_WAIT 状态也称为 2MSL 等待状态。每个具体 TCP 实现必须选择一个报文段最大生存时间 MSL（Maximum Segment Lifetime），是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为 TCP 报文段以 IP 数据报在网络内传输，而 IP 数据报则有限制其生存时间的 TTL 字段。
对一个具体实现所给定的 MSL 值，处理的原则是：当 TCP 执行一个主动关闭并发回最后一个 ACK，该连接必须在 TIME_WAIT 状态停留的时间为 2 倍的 MSL。这样可让 TCP 再次发送最后的 ACK 以防上个 ACK 丢失（另一端超时并重发最后的 FIN）。这种 2MSL 等待的另一个结果是这个 TCP 连接在 2MSL 等待期间，定义这个连接的插口（客户的 IP 地址和端口号，服务器的 IP 地址和端口号）不能再被使用。这个连接只能在 2MSL 结束后才能再被使用。
为什么需要等待 2MSL
1 个 MSL 保证主动关闭方最后的 ACK 报文能最终到达对端。1 个 MSL 保证如果对端没有收到 ACK 报文，那么对端进行重传的 FIN-ACK 报文能够到达主动关闭方。如果主动关闭方不等待或者等不到 2MSL 就直接关闭，可能存在 ACK 丢失但没有收到新的 FIN-ACK 就关闭，被动关闭方无法正常关闭连接。同时等待超过 2MSL 则没有意义，因为即使两个报文先后分别传输，数据包都已不可能存在。主动关闭方超过这个时间没有收到报文，可以认为，被动关闭方已经收到主动关闭方最后发送的 ACK 报文，没有重传 FIN-ACK 报文，且已经正常关闭连接。
TCP 和 UDP 的区别
参考：
https://juejin.cn/post/6972027657047244837
https://juejin.cn/post/7356446170476068905
是否连接
面向连接，指发送数据之前必须在两端建立连接。在双方互相通信前，TCP 需要三次握手建立连接，确保两端的通信是同步的。UDP 不需要建立连接，直接将数据包发送给接收方。
传输可靠
TCP 的可靠性体现在有状态和可控制。TCP 会精准记录哪些数据被发送、哪些数据已被接收（接收端对已成功收到的数据会发回一个相应的确认）、哪些没有被接收到，而且保证数据包按序到达、不允许半点差错，这是有状态。当意识到丢包或者网络环境不佳，TCP 会根据具体情况调整行为，控制发送速度、流量控制、拥塞控制或者重发，这是可控制。
UDP 不可靠性首先体现在无连接上，通信都不需要建立连接；其次因为它是无状态和不可控。UDP 收到什么数据就传递什么数据，不会备份数据，发送数据时也不会关心对方是否正确接收到数据。
速度效率
TCP 需要进行连接管理、错误检测、恢复和维持连接状态，数据传输速度相对较慢，头部开销大。UDP 不需要建立连接，且几乎没有错误恢复机制，所以数据传输速度较快，头部开销小，效率较高。
总结
| TCP | UDP | |
|---|---|---|
| 是否连接 | 面向连接 | 无连接 |
| 传输方式 | 面向字节流 | 面向报文 |
| 传输可靠 | 可靠传输 | 不可靠传输 |
| 首部开销 | 开销大，20 字节到 60 字节不等 | 开销小，仅 8 字节 |
| 连接对象个数 | 只支持一对一 | 支持一对一、一对多、多对一、多对多 |
| 适用场景 | 要求可靠传输的应用，如文件传输 | 适用实时应用，如直播、视频会议 |