网络协议基础

作者:Atom

字数统计:7.5k 字

阅读时长:24 分钟

本文用于归纳自己所学的网络知识, 网络协议的知识众多, 平时的点点滴滴的积累最终就能分解并吸收这些内容, 因此也是出于这个目的

常见 HTTP 状态码

1xx: 信息响应

• 100 Continue：客户端应继续其请求。通常在发送POST请求时使用，以表明服务器已经接收到请求头，客户端可以继续发送请求体(上传大文件前使用)

• 101 Switch Protocols：协议升级使用

• 102 Processing：服务器已经收到并正在处理请求，但无响应可用

2xx: 成功

• 200 OK：请求成功，并且服务器返回所请求的数据

• 201 CREATED：请求成功并且服务器创建了新的资源(用户新建或修改数据成功)

• 202 Accepted：请求已接受，但处理尚未完成(表示一个请求已经进入后台排队的异步任务)

• 204 NO CONTENT：用户删除数据成功, 服务器不返回任何内容

• 206 Partial Content：表示服务器成功处理了部分GET请求(它在支持断点续传和分段下载等功能时非常有用)

3xx: 重定向

• 300 Multiple Choices：是一个特殊的重定向状态码，会返回一个有多个链接选项的页面，由用户自行选择

• 301 Moved Permanently：请求的资源已永久移动到新位置

• 302 Found（临时重定向）：请求的资源临时移动到新位置

• 303 See Other：请求的资源存在于另一个URL，应使用GET方法获取资源

• 304 Not Modified：资源未被修改，可以使用缓存的版本

• 307 Temporary Redirect：类似于 302，表示请求的资源临时被移动到另一个URL, 重定向后请求的方法和实体不允许变动

• 308 Permanent Redirect：类似于 301，代表永久重定向，重定向后请求的方法和实体不允许变动

4xx: 客户端错误

• 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的

• 401 Unauthorized：请求未经授权，需要用户验证

• 403 Forbidden：服务器拒绝请求，即使经过认证，客户端也没有访问权限

• 404 Not Found：请求的资源不存在

• 405 Method Not Allowed：请求方法不被允许

• 407 Proxy Authentication Required：表示客户端必须通过代理服务器进行身份验证才能继续处理请求

• 408 Request Timeout：服务器等待客户端发送请求的时间超时

5xx: 服务器错误

• 500 Internal Server Error：服务器内部错误，无法完成请求

• 501 Not Implemented：服务器不支持请求的方法

• 502 Bad Gateway：作为网关或代理的服务器接收到无效响应

• 503 Service Unavailable：服务器当前无法处理请求，可能是超载或维护中

• 504 Gateway Timeout：作为网关或代理的服务器，无法在规定时间内获得响应

• 505 HTTP Version Not Supported：表示服务器不支持请求所使用的HTTP协议版本

HTTP 预检请求

HTTP的预检请求（Preflight Request）是跨域资源共享（CORS）机制的一部分，用于在跨域请求之前确认服务器是否允许请求中的具体操作。

概念

预检请求是由浏览器自动发起的一次HTTP OPTIONS 请求，用于探测目标服务器是否接受接下来的跨域请求（即实际请求）。当跨域请求满足一定条件时，浏览器会在实际请求之前发起预检请求。

简单请求和复杂请求

属性	简单请求	复杂请求
请求方法	GET, POST, HEAD	其他方法（如 PUT）
请求头	简单头部	自定义头部等
是否发起预检	否	是

简单请求的判定条件

1. 使用GET、POST、HEAD其中一种方法
2. 仅使用了如下的安全头部字段，如果设置了其他头部字段就属于复杂请求

• Accept
• Accept-Language
• Content-Language
• Content-Type仅为: text/plain、multipart/form-data、application/x-www-form-urlencoded

3. 请求中的任意XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问
4. 请求中没有使用 ReadableStream 对象

预检请求的触发流程

浏览器会对“复杂的跨域请求”发起预检请求。凡是非简单请求均会被视为复杂请求。以下是预检请求的具体工作流程

发起预检请求

浏览器先发送一条 OPTIONS 请求到服务器，询问是否允许该实际请求

• 请求内容包括：
  • 请求方法（通过 Access-Control-Request-Method 指定）。
  • 自定义头部（通过 Access-Control-Request-Headers 指定）。

服务器响应预检请求

• 服务器通过返回的 CORS 响应头，明确表示是否允许该请求。
• 常见响应头包括：
  • Access-Control-Allow-Origin：指定允许的域名。
  • Access-Control-Allow-Methods：允许的HTTP方法。
  • Access-Control-Allow-Headers：允许的请求头部。
  • Access-Control-Max-Age：预检结果的缓存时间（秒）。

发送实际请求

如果预检请求通过（响应允许），浏览器会继续发送实际请求；否则请求会被拦

预检请求示例

预检请求（OPTIONS 请求）

OPTIONS /api/data HTTP/1.1
Host: example.com
Origin: http://my-website.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-Custom-Header

服务器响应

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://my-website.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Custom-Header
Access-Control-Max-Age: 86400

实际请求

如果预检通过，浏览器会发起实际请求：

POST /api/data HTTP/1.1
Host: example.com
Origin: http://my-website.com
Content-Type: application/json
X-Custom-Header: CustomValue

优化预检请求

由于预检请求增加了一次额外的网络请求，可能会对性能产生影响。以下方法可以减少或优化预检请求：

• 简化请求：尽量使用简单请求（简单方法和头部）。
• 缓存预检结果：通过 Access-Control-Max-Age 缓存预检结果。
• 合并请求：减少跨域请求的频率或批量处理数据。

预检请求是CORS机制中保证跨域安全的重要组成部分，它为开发者提供了一种控制跨域请求的安全手段，同时要求前端和后端协作处理好预检请求及其响应头配置。

GET 和 POST 的区别

主要是以下区别

GET 的特点

GET 请求参数放在 URL, 安全性较于 POST 略差, 且 URL 的参数长度在各个浏览器的实现中有最大限制(chrome4K), 请求能被缓存, 可以保存在浏览器历史记录中,也可以置于收藏夹中, 这种请求是无副作用的, 也就是幂等的, 常用于向服务器获取数据

根据URL最大长度限制探究得出的结果如下

	URL	Request Line	URL过长的结果
HTTP/1.1 标准		推荐服务端至少支持8KB
HTTP/2 标准		无限制
URL、URI 标准	无限制
Chromium	2MB		打开失败
Firefox	1MB		打开失败
Safari	无限制
IE8	~2083字节		打开失败
IE9-IE11	无限制
Node.js >= v13.13.0		16KB	抛出Header overflow异常
Node.js < v13.13.0		8KB	抛出Header overflow异常
nginx		8KB	返回 4xx 错误
httpd		8190字节	返回 4xx 错误

注意

根据木桶效应，如果不考虑旧版IE，URL长度和请求头大小不应该超过 8KB

POST 的特点

POST 请求的参数是放在 body 中的, 参数可以是任意的类型, 无大小限制, 安全性比 GET 好,请求无法被缓存, 也无法保存在收藏夹; 这样的请求是有副作用的, 也就是非幂等的, 用途广泛, 可以修改服务器的数据

TCP 相关知识

TCP(Transmission Control Protocol) 传输控制协议是主机对主机层的传输控制协议，提供可靠的连接服务

TCP 标志位

TCP协议的标志位（Flags）是TCP头部中的一部分，用于控制TCP连接的状态以及数据的传输。常见的TCP标志位有以下几种：

标志位	全称	作用	值
SYN	Synchronize	用于发起连接请求。在三次握手的第一步中，客户端向服务器发送SYN标志，表明希望建立连接。	1 表示请求建立连接
ACK	Acknowledgment	用于确认接收到的数据。此标志位为1时，Acknowledgment Number 字段的值有效。	1 表示确认已收到，0 表示未确认
FIN	Finish	请求断开连接，表示发送方的数据已发送完毕，请求关闭连接。	1 表示发送方请求关闭连接
RST	Reset	用于重置连接，强制立即断开连接，常用于非正常关闭连接。	1 表示重置连接
PSH	Push	表明数据需立即传送给应用层，而不等待缓冲区填满后再发送。	1 表示数据需立即处理
URG	Urgent	表示数据具有紧急优先级。Urgent Pointer 字段指向紧急数据的位置。	1 表示数据紧急
ECE	Explicit Congestion Notification Echo	用于显示网络拥塞，是TCP拥塞通知机制的一部分。	1 表示检测到网络拥塞
CWR	Congestion Window Reduced	发送方响应接收到的ECE标志，减少发送速率，告知接收方已减小拥塞窗口。	1 表示已响应网络拥塞并减少发送速率

三次握手

三次握手用于在客户端和服务器之间建立可靠的TCP连接, 确保客户端和服务器双方都准备好开始数据传输。通过三次握手可以防止旧的连接请求报文段出现在网络中，从而避免误连接。

客户端发送 SYN

• 发送方：客户端
• 内容：客户端向服务器发送一个SYN（synchronize）报文段，表明请求连接。
• 作用：此时客户端进入SYN-SENT状态，等待服务器响应，同时在报文中携带一个初始序列号（Sequence Number），用于之后的数据传输确认。

服务器发送 SYN + ACK

• 发送方：服务器
• 内容：服务器收到SYN请求后，回应一个SYN + ACK（acknowledgment）报文段，表示同意连接，并回应客户端的SYN，同时也包含服务器的初始序列号。
• 作用：服务器进入SYN-RECEIVED状态，确认了客户端的请求并发送ACK确认客户端的序列号+1，等待客户端的确认。

客户端发送 ACK

• 发送方：客户端
• 内容：客户端接收到服务器的SYN + ACK后，再发送一个ACK确认报文段，确认连接已建立。
• 作用：客户端和服务器均进入ESTABLISHED状态，TCP连接建立完成。

四次挥手(断开连接)

四次挥手用于在客户端和服务器之间安全地终止连接，确保双方不再发送和接收数据。其目的是确保双方在关闭连接前均确认数据传输完毕。当客户端进入TIME-WAIT状态，防止服务器可能未收到ACK而重发FIN，避免出现“半关闭”状态。

客户端发送 FIN

• 发送方：客户端
• 内容：客户端向服务器发送一个FIN（finish）报文段，表示数据发送完毕，请求关闭连接。
• 作用：客户端进入FIN-WAIT-1状态，等待服务器的确认。

服务器发送 ACK

• 发送方：服务器
• 内容：服务器收到FIN报文段后，发送一个ACK确认报文段，确认客户端的FIN。
• 作用：服务器进入CLOSE-WAIT状态，表示确认了客户端的请求，但可能还有数据需要发送。客户端则进入FIN-WAIT-2状态，等待服务器的FIN报文段。

服务器发送 FIN

• 发送方：服务器
• 内容：服务器在确认没有数据需要发送后，向客户端发送一个FIN报文段，请求关闭连接。
• 作用：服务器进入LAST-ACK状态，等待客户端的确认。

客户端发送 ACK

• 发送方：客户端
• 内容：客户端接收到服务器的FIN后，发送一个ACK确认报文段，确认服务器的FIN。
• 作用：客户端进入TIME-WAIT状态，确保服务器接收到ACK后进入CLOSED状态。客户端在等待一段时间后也进入CLOSED状态，释放资源。

差异和目的

三次握手与四次挥手的差异与目的

• 三次握手用于建立连接，双方需确认彼此的发送和接收能力。
• 四次挥手用于关闭连接，双方在关闭前确认数据已发送完毕。四次挥手比三次握手多两个步骤，以避免数据丢失。

SSL/TLS 的链接建立

SSL/TLS 协议建立的详细流程：

SSL/TLS握手流程是HTTPS建立安全连接的核心，它在客户端（如浏览器）和服务器之间建立起加密通信通道。整个握手流程主要涉及身份验证、密钥交换以及加密算法协商等。以下是详细的步骤：

当然，以下是SSL/TLS握手过程中的每条消息的内容与作用的详细分解：

第一阶段、客户端问候

Client Hello

客户端发送Client Hello消息，内容包含以下具体信息：

• 协议版本：客户端支持的最高版本，比如TLS 1.2或TLS 1.3。
• 支持的加密套件列表：加密算法（如AES、3DES）和密钥交换方法（如RSA、DHE、ECDHE）组合成的加密套件集合。客户端通过列出它支持的加密套件，供服务器选择。
• 客户端随机数：32字节随机数，用于后续会话密钥的生成。
• 会话ID：如果客户端之前连接过服务器，此处会携带会话ID，服务器可选择恢复该会话，实现会话重用。
• 支持的压缩方法：通常为空，因为TLS大多数情况下不压缩。
• 扩展字段：包含客户端支持的功能，如SNI（Server Name Indication）指定主机名、OCSP Stapling、以及密钥共享算法列表（在TLS 1.3中使用）。

目的：提供客户端的加密能力，开始协商加密通信参数

第二阶段、服务器应答与身份确认

这个阶段服务器主要会发送下面的几条消息

Server Hello

服务器接收并处理Client Hello后，返回Server Hello消息，具体内容包括：

• 协议版本：从客户端支持的版本中选择一个版本，比如TLS 1.2或TLS 1.3。
• 加密套件：服务器从客户端的加密套件列表中选择一个最合适的套件。
• 服务器随机数：32字节随机数，用于后续会话密钥的生成。
• 会话ID：服务器返回的会话ID，用于会话重用。
• 扩展字段：确认的SNI信息，或在TLS 1.3中确认的密钥共享算法。

目的：告知客户端服务器选择的协议版本、加密算法以及生成随机数

服务器证书（Server Certificate）

服务器发送自己的数字证书，内容包括：

• 服务器公钥：用于加密密钥交换数据。
• 证书的签名者（CA）：服务器证书由受信任的第三方证书颁发机构（CA）签署。
• 证书信息：包括服务器的域名、证书有效期等。

客户端将会验证此证书的有效性，以确保服务器的身份。此步骤是确保安全的关键。

目的：提供服务器的身份信息和公钥，用于后续的加密通信

Server Key Exchange（可选）

当使用DHE或ECDHE等密钥交换算法时，服务器还会发送Server Key Exchange消息，该消息包括：

• 密钥交换参数：如椭圆曲线的参数或DH算法的参数。
• 签名：服务器对这些参数的签名，以确保密钥交换参数的完整性。

目的：提供必要的密钥交换信息，支持前向保密

Server Hello Done

服务器发送Server Hello Done消息，表示服务器端的消息已全部发送完毕，等待客户端响应。

目的：告知客户端，服务器的初始握手消息已发送完毕

第三阶段、客户端密钥生成与确认

该阶段主要发送以下几条消息

Client Key Exchange

客户端接收服务器的Server Hello和证书后，生成一个“预主密钥”（Pre-Master Secret）并将其发送给服务器：

• RSA密钥交换：客户端生成“预主密钥”，使用服务器的公钥加密后发送给服务器。
• DHE或ECDHE密钥交换：客户端基于服务器提供的密钥交换参数（如椭圆曲线的公钥）计算“预主密钥”。

双方之后会根据“预主密钥”和先前的两个随机数（客户端和服务器的随机数）生成会话密钥。这块的详细内容在之后有补充

目的：传递预主密钥，确保之后的会话密钥是双方一致的

Change Cipher Spec（客户端）

客户端发送Change Cipher Spec消息，内容简单明了：

• 内容：表明接下来客户端发送的所有消息将使用对称密钥加密。

目的：通知服务器切换到加密通信模式

Finished（客户端）

客户端发送Finished消息，使用对称加密算法和会话密钥对该消息加密。消息内容包括：

• 握手消息摘要：客户端在整个握手过程中记录的所有消息的摘要，用以验证握手完整性。

服务器收到并验证这条消息后，即可确认客户端已完成握手。

目的：确认握手的完整性，完成客户端的握手准备

💚 补充内容: Pre-Master Secret 💚

Pre-master Secret 作用及主要流程

• 生成 Pre-master Secret

  客户端在本地生成一个随机数，作为pre-master secret。如果使用的是TLS1.2或更早版本，pre-master secret的前两个字节通常包含客户端的协议版本号，以防止降级攻击。

• 加密 Pre-master Secret

  pre-master secret生成后，客户端会用服务器的公钥对其进行加密。服务器的公钥通常由服务器在握手开始时通过数字证书的方式传递给客户端。这个加密过程确保了pre-master secret只有服务器可以解密，任何中间人无法获得pre-master secret，从而保证了安全性。

• 传递 Pre-master Secret

  客户端将加密后的pre-master secret发送给服务器。服务器收到后，会使用自己的私钥解密出pre-master secret。如果服务器无法解密（比如因为中间人攻击或者私钥不匹配），握手会失败，连接无法建立。

• 生成主密钥 Master Secret

  pre-master secret本身并不会直接用于加密通信，而是作为生成主密钥（master secret）的一个基础。客户端和服务器将pre-master secret与ClientRandom和ServerRandom混合，通过伪随机函数（PRF）进行多次哈希操作（通常使用SHA-256或MD5）生成一个长度为48字节的master secret。这个过程对客户端和服务器是对称的，因此双方可以生成出相同的master secret

• 派生会话密钥 Session Keys

  生成的master secret并不会直接用于加密数据，而是继续派生出会话密钥（session keys）

第四阶段、服务器密钥确认与完成握手

该阶段主要发送以下几条消息

Change Cipher Spec（服务器）

服务器接收客户端的Finished消息后，发送Change Cipher Spec消息，内容同样简明：

• 内容：表明接下来服务器发送的所有消息将使用对称密钥加密。

目的：通知客户端切换到加密通信模式

Finished（服务器）

服务器发送Finished消息，使用对称加密算法和会话密钥对该消息加密。消息内容包括：

• 握手消息摘要：服务器对握手过程中所有消息的摘要，验证握手的完整性。

客户端收到并验证这条消息后，即可确认服务器已完成握手。

目的：确认握手的完整性，完成服务器的握手准备

第五阶段、对称加密安全通信

安全通信

握手完成后，双方已生成一致的会话密钥，随后的数据传输将通过对称加密进行，确保通信的保密性、完整性和可靠性。

HTTP版本特点及区别

HTTP/1.0

• 文本协议：HTTP/1.0 是一个面向文本的协议，客户端和服务器之间的通信通过文本形式的请求和响应完成。
• 无状态性：每个 HTTP/1.0 请求都是独立的，不会保存请求之间的上下文。这意味着每个请求都需要重新建立 TCP 连接。
• 每次请求一个连接：HTTP/1.0 在每次请求时都会打开一个新的 TCP 连接，处理完请求后关闭连接。这导致了大量的连接建立和断开，增加了延迟。
• 有限的缓存支持：引入了一些基本的缓存控制头（如 Expires），但功能相对简单。

HTTP/1.1

• 持久连接（Keep-Alive）：引入持久连接机制，即在同一 TCP 连接上可以发送多个请求和响应，减少了连接建立和断开的开销。默认情况下，HTTP/1.1 使用持久连接。
• 分块传输编码：支持分块传输编码，使得服务器可以在生成内容的同时发送响应，适合动态内容生成。
• 管道化：允许客户端在收到响应之前发送多个请求，但由于队头阻塞的问题，实际应用中很少使用。
• 更多的缓存控制：引入了更多的缓存控制头（如 Cache-Control 和 ETag），提高了缓存管理的灵活性。
• 范围请求：支持范围请求，允许客户端请求部分资源，这对于断点续传和流媒体等场景非常有用。
• 更多的 HTTP 方法：引入了 PUT、DELETE 等 HTTP 方法，增强了对 RESTful 架构的支持。

HTTP/2.0

• 二进制协议：HTTP/2 使用二进制格式而非文本格式，减少了解析和传输的复杂性。
• 多路复用：允许在单个 TCP 连接中同时发送多个请求和响应，通过使用流 ID 区分不同的请求，解决了 HTTP/1.1 的队头阻塞问题。
• 头部压缩：引入了 HPACK 算法，使用动态表和静态表对头部进行压缩，减少了数据传输量。
• 服务器推送：允许服务器在客户端请求之前主动推送资源，减少了客户端的等待时间和请求次数。
• 流优先级：支持为不同的流设置优先级，使得客户端可以指定哪些资源应优先传输。

HTTP/3

• 基于 QUIC 协议：HTTP/3 使用 QUIC（Quick UDP Internet Connections）作为底层传输协议，替代了 TCP。QUIC 是一个基于 UDP 的协议，提供类似 TCP 的可靠性和流控制。
• 减少连接建立延迟：QUIC 协议将 TLS 和多路复用直接集成在其架构中，减少了建立连接的握手次数，仅需一个 RTT。
• 消除队头阻塞：HTTP/3 的多路复用在 QUIC 之上进行，丢失的包只会影响对应流，不会阻塞其他流的数据传输。
• 内置加密：QUIC 将 TLS 1.3 内置于协议中，所有的 QUIC 连接都是加密的，提高了连接的安全性。
• 更好的连接迁移：QUIC 支持连接迁移，当客户端的 IP 地址发生变化时，可以继续使用相同的连接 ID 进行通信，而不需要重新建立连接。

各版本区别

特点	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
发布年份	1996	1997	2015	2020
连接管理	每次请求一个新连接	持久连接	持久连接，单连接多路复用	基于 QUIC，单连接多路复用
数据传输格式	文本	文本	二进制	二进制
多路复用	不支持	部分支持（有队头阻塞）	支持（消除队头阻塞）	支持（基于 QUIC，无队头阻塞）
头部压缩	不支持	不支持	HPACK头部压缩	QPACK头部压缩
安全性	无内置加密	无内置加密（可选 HTTPS）	无内置加密（可选 HTTPS）	内置 TLS 1.3
服务器推送	不支持	不支持	支持	支持
流优先级	不支持	不支持	支持	支持
队头阻塞	严重	部分缓解	存在（TCP 层面）	无队头阻塞
连接迁移	不支持	不支持	不支持（基于 IP/端口）	支持连接迁移

总的来说

• HTTP/1.0 和 HTTP/1.1：HTTP/1.1 是 HTTP/1.0 的改进版本，引入了持久连接、管道化和更多缓存控制等功能，解决了部分性能和延迟问题。
• HTTP/2：通过多路复用、二进制协议、头部压缩和服务器推送等特性，显著提升了传输效率和性能，适应了现代 Web 应用的需求。
• HTTP/3：基于 QUIC 协议，进一步优化了连接建立时间、消除了队头阻塞，提供了更好的安全性和连接迁移能力，适合高性能、低延迟的网络应用场景。

TCP 和 UDP 的区别

TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Datagram Protocol，用户数据报协议）是互联网协议族中的两种主要传输层协议。它们各有优缺点，适用于不同的应用场景。下面是 TCP 和 UDP 之间的主要区别：

连接性

TCP: 面向连接的协议。在数据传输前，TCP 需要建立一个连接（通过三次握手过程）。这意味着在发送数据前，必须确认发送方和接收方之间已经建立了连接。

UDP: 无连接的协议。UDP 在发送数据之前不需要建立连接，它直接将数据报发送给目标。这使得 UDP 的连接建立开销较小，传输速度更快。

可靠性

TCP: 提供可靠的数据传输。TCP 确保数据包按序到达，没有丢失、重复或损坏。它通过校验和、确认应答、重传丢失数据包等机制来保证数据的完整性和可靠性。

UDP: 不保证可靠性。UDP 不会确认数据是否正确到达接收方，也不进行重传。这意味着数据报可能会丢失、重复或无序到达。应用程序需要自己处理这些问题。

有序性

TCP: 保证数据按序到达。TCP 通过序列号和确认机制，确保数据包按发送顺序到达接收方。即使网络发生延迟，TCP 也会按顺序交付数据。

UDP: 不保证数据有序。UDP 数据报按发送顺序发出，但在到达接收方时可能是无序的。应用程序需要自行处理数据的顺序问题。

流量控制和拥塞控制

TCP: 具有流量控制和拥塞控制机制。TCP 调整数据发送速率以避免网络拥塞，确保网络的稳定性和公平性。

UDP: 没有流量控制和拥塞控制机制。UDP 以恒定的速率发送数据，网络拥塞时也不会降低发送速率，这可能导致网络拥塞加剧。

数据传输方式

TCP: 面向字节流传输。TCP 将数据看作连续的字节流，数据的边界不被明确划分。

UDP: 面向数据报传输。UDP 保留每个数据报的边界，即使发送的多个数据报大小不同，每个数据报都作为一个独立的整体进行传输。

开销

TCP: 开销较大。由于需要维护连接状态、序列号、确认机制等，TCP 的包头比较复杂，占用更多的资源。

UDP: 开销较小。UDP 头部只有 8 字节，结构简单，因此相对于 TCP 而言，传输效率更高，资源占用更少。

适用场景

TCP: 适用于对数据传输可靠性要求高的场景。例如，网页浏览（HTTP/HTTPS）、文件传输（FTP）、电子邮件（SMTP）等需要确保数据完整到达的应用。

UDP: 适用于对传输速度和效率要求高、对数据完整性要求较低的场景。例如，实时视频/音频流（如视频会议、VoIP）、在线游戏、DNS 查询等，这些应用更注重低延迟和快速响应。

常见端口号

TCP: 例如，HTTP（80）、HTTPS（443）、FTP（21）、SMTP（25）等协议通常使用 TCP 传输。

UDP: 例如，DNS（53）、DHCP（67/68）、SNMP（161/162）、TFTP（69）等协议通常使用 UDP 传输。

总结 TCP: 提供可靠、面向连接的服务，适合对数据完整性和顺序性有严格要求的应用。 UDP: 提供不可靠、无连接的服务，适合对传输速度和效率要求高、对数据丢失不敏感的应用。 两种协议各有优缺点，选择哪种协议应根据具体应用的需求而定。

参考资料

• URL最大长度限制探究