计算机网络——应用层

一、HTTP报文结构

（1）请求

1. 请求行：
2. 请求头：
3. 空行：
4. 请求体：

（2）响应

1. 状态行：
2. 响应头：
3. 空行：
4. 响应体：

（3）补充说明

1. 空行的作用：严格区分头部与主体，无空行会导致服务器解析错误
2. 请求体与响应体的存在条件：
   1. GET请求通常无请求体（数据通过URL参数传递）
   2. POST/PUT请求需包含请求体（如提交表单或JSON）
   3. 响应体在状态码为 204 No Content 或 304 Not Modified 时可能为空
3. 常见头部字段：
   1. 请求头：
      1. Cookie：客户端发送的Cookie信息
      2. Authorization：身份验证凭证（如Bearer Token）
   2. 响应头：
      1. Set-Cookie：服务器设置Cookie
      2. Location：重定向目标地址（如状态码 301/302）

（4）完整示例

1. HTTP请求报文

   GET /api/data?page=1 HTTP/1.1
   Host: example.com
   User-Agent: Mozilla/5.0
   Accept: application/json（空行，无请求体）

2. HTTP响应报文

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 27
   Server: Apache{"status": "success", "data": []}

二、常见HTTP状态码

（1）1XX（信息性状态码）

1. 这类状态码表示服务器已收到客户端的请求，需要客户端继续操作或提供更多信息
2. 以 100 Continue 为例，客户端在发送包含大量数据（如文件上传、大型表单提交）的请求前，会先发送一个带有 Expect: 100-continue 头部的请求。如果服务器能够处理后续数据，就会返回状态码 100，客户端收到后，才会将完整数据包含在请求体中发送

（2）2XX（成功状态码）

1. 表示服务器成功接收并处理了客户端请求
2. 200 OK：最常见的成功响应码，表明服务器已成功处理请求，并将请求的资源返回给客户端。例如，当请求一个网页时，服务器返回 200 状态码，同时将网页内容一并返回
3. 204 No Content：服务器已成功处理请求，但无需返回任何内容，常用于 PUT、DELETE 等操作。比如删除某个资源成功后，服务器会返回 204 状态码，此时响应头中可能包含一些元信息，但没有响应体
4. 206 Partial Content：当客户端发起范围请求（如请求一个大文件的部分内容、视频的某一片段），服务器会返回 206 状态码，并在响应头中通过 Content-Range 字段告知客户端返回的是哪一部分内容

（3）3XX（重定向状态码）

1. 指示客户端需要采取进一步操作以完成请求，通常涉及资源位置的变更
2. 301 Moved Permanently：资源已永久移动到新位置，搜索引擎等会更新索引。服务器返回 301 状态码时，必须在响应头中包含 Location 字段，指定新的 URL 地址。客户端后续应使用新地址进行请求
3. 302 Found（在 HTTP/1.1 中已更名为 307 Temporary Redirect）：资源临时移动到新位置，客户端应继续使用原 URL 发起后续请求，且请求方法和请求体保持不变。服务器同样会在响应头的 Location 字段中指明临时新地址

（4）4XX（客户端错误状态码）

表示客户端发送的请求存在错误，导致服务器无法处理

1. 400 Bad Request：客户端请求存在语法错误或格式问题，例如请求参数缺失、请求体格式错误等，导致服务器无法理解该请求
2. 401 Unauthorized：客户端未提供有效的身份验证信息（如缺少或错误的用户名 / 密码、Token），需要进行身份验证后才能访问资源。与 403 不同，401 侧重于身份验证，403 侧重于权限不足
3. 403 Forbidden：客户端已通过身份验证，但权限不足，无法访问请求的资源，例如普通用户尝试访问管理员页面
4. 404 Not Found：服务器无法找到请求的资源，可能是由于 URL 错误、资源已被删除或移动且未更新链接等原因

（5）5XX（服务器错误状态码）

1. 表示服务器在处理请求时发生内部错误
2. 500 Internal Server Error：服务器内部发生未知错误，可能是代码逻辑错误、数据库连接失败、服务器配置问题等导致，需要服务器端排查日志以定位问题
3. 502 Bad Gateway：代理服务器收到无效响应（如后端服务崩溃）
4. 504 Gateway Timeout：代理服务器未在超时时间内收到响应（如后端服务处理过慢）

三、GET vs POST

（1）含义与用途

1. Get 的核心目的是获取资源，例如从服务器获取网页内容、查询数据等
2. Post 则侧重于提交数据，像提交表单、上传文件、创建订单等操作都通过 Post 实现

（2）参数传递与安全性

1. Get 请求会将参数附加在 URL 中，如https://example.com?key=value，在浏览器地址栏、服务器日志中都会暴露，若包含敏感信息（如密码）存在安全隐患
2. Post 一般把请求参数和数据放置在请求体里，不会显示在地址栏，但如果未使用加密协议（如 HTTPS），数据传输依然存在被截取的风险，并非绝对安全

（3）数据长度限制

1. Get 受限于 URL 长度（不同浏览器、服务器对 URL 长度限制不同，常见限制在 2000 字符左右），只能携带少量参数
2. Post 对请求体数据长度理论上无严格限制，不过实际受服务器配置（如 Nginx 默认限制请求体大小为 1M）和网络环境等因素制约，并非真正 “无上限”

（4）缓存策略

1. 由于 Get 常用于获取静态资源，且相同请求通常返回相同结果，所以浏览器、代理服务器等可能会对其响应进行缓存，提升访问效率
2. Post 请求通常用于数据提交，每次请求可能产生不同结果（如重复提交订单），默认不会被浏览器缓存，但可通过设置响应头（如Cache-Control）来控制是否缓存

（5）幂等性

1. Get 请求是幂等的，多次发送相同请求，对服务器资源的影响一致（多次获取同一资源，资源状态不变）
2. Post 请求一般是非幂等的，每次提交都可能在服务器端产生新的资源或状态变更（如多次提交订单会生成多个订单），不过也存在特殊情况，若服务器通过唯一标识避免重复操作，Post 也能实现幂等

四、HTTP长连接（Keep-Alive）

1. 短连接：每次发送请求都需要通过 TCP 三次握手建立连接，请求完成后再通过四次挥手断开连接。频繁的连接建立与断开会产生较大开销，降低传输效率
2. 长连接：首次通过 TCP 三次握手建立连接后，在一定时间内保持连接不中断，后续多个请求可复用该连接，减少连接建立的开销，提升数据传输效率
3. 建立方式：在 HTTP/1.0 中，需要在请求头添加Connection: Keep-Alive字段来启用长连接；而在 HTTP/1.1 协议中，长连接是默认启用的，无需显式设置该字段。此外，连接的持续时间可由客户端或服务器通过相关参数（如Keep-Alive: timeout=X）配置，超过空闲时间连接将自动关闭

五、HTTP vs HTTPS

（1）默认端口

1. HTTP 协议默认使用80 端口
2. HTTPS 协议默认使用443 端口

（2）数据传输安全性

1. HTTP 协议采用明文传输，数据在网络中传输时不经过加密处理，因此存在被第三方窃听、篡改或伪造的风险
2. 而 HTTPS 协议在表示层通过SSL/TLS 加密技术，将数据加密为密文传输，有效防止数据泄露和篡改，保障通信安全

（3）连接建立过程

1. HTTP 仅通过TCP 三次握手建立连接，随后直接传输数据
2. HTTPS 在 TCP 三次握手建立可靠连接后，还需进行SSL/TLS 握手（一般为四次交互），用于协商加密算法、交换密钥和验证服务器身份，之后才开始加密数据传输

（4）身份验证机制

1. HTTP 协议不涉及服务器身份验证，无法确保访问的服务器是否可信
2. HTTPS 协议要求服务器必须拥有CA（证书颁发机构）签发的数字证书，客户端在连接时会验证证书有效性，确认服务器身份，防止中间人攻击

六、SSL/TLS握手流程（RSA算法为例）

1. Client Hello：客户端发送随机数（Random1）、支持的协议版本及加密算法列表，供服务器协商
2. Server Hello：服务器选定协议版本与加密算法，发送随机数（Random2）及 CA 证书，证书包含服务器公钥
3. 验证证书：客户端校验 CA 证书有效性，确认服务器身份，提取公钥用于后续加密
4. Pre-master Key：客户端生成预主密钥（Random3），用服务器公钥加密后发送，仅服务器可解密获取
5. 生成会话密钥：客户端和服务器分别根据两个随机数（Random1、Random2）及预主密钥（Random3），独立计算出相同的会话密钥，用于数据加密
6. 完成握手：双方用会话密钥加密握手结束消息互发验证，验证通过后，后续数据传输使用该密钥加密

七、SSL/TLS安全性核心

1. 非对称加密交换密钥：客户端生成预主密钥，用服务器 CA 证书公钥加密后传给服务器，服务器用私钥解密。此过程利用非对称加密保证预主密钥传输安全，客户端和服务器还各自生成一个随机数
2. 对称加密传输数据：双方基于两个随机数和预主密钥生成会话密钥，之后用该会话密钥对数据进行对称加密传输，既保障安全又兼顾效率
3. CA 证书防中间人攻击：CA 证书由权威机构颁发，客户端收到服务器证书后会验证其合法性。若有中间人伪造证书，客户端验证时会发现问题，从而防止攻击

八、TCP三次握手与四次挥手

（1）三次握手（建立连接）

1. 客户端发送SYN（seq=x），其中x为客户端随机生成的初始序列号，向服务器发起连接请求
2. 服务器收到后，回复SYN-ACK（seq=y，ack=x+1）。seq=y是服务器随机生成的初始序列号，ack=x+1表示确认收到客户端 SYN 报文，期望接收客户端下一个序列号为x+1的数据
3. 客户端发送ACK（ack=y+1），确认收到服务器的 SYN-ACK 报文，ack=y+1表示期望接收服务器下一个序列号为y+1的数据，至此 TCP 连接建立完成

（2）四次挥手（断开连接）

1. 主动请求断开连接的一方（主动方）发送 FIN（seq=x） 给被动方，其中 x 为主动方当前序列号，明确告知对方自身已无数据发送，请求断开连接
2. 被动方收到 FIN 后，发送 ACK（seq=y，ack=x+1） 进行回应。y 是被动方当前序列号，ack=x+1 确认收到主动方的断开请求。此时，主动方到被动方的单向连接关闭，但被动方仍可向主动方传输数据
3. 当被动方也完成数据发送后，发送 FIN（seq=a） 给主动方，a 为被动方新的序列号，表明自身也无数据待发，请求彻底断开连接
4. 主动方收到被动方的 FIN 后，发送 ACK（seq=b，ack=a+1） 确认。b 是主动方新的序列号，ack=a+1 表示确认收到断开请求。主动方发送完 ACK 后，会进入 TIME - WAIT 状态（通常为 2 倍 MSL 时长），确保被动方收到确认且连接安全关闭，随后连接彻底断开

九、TCP vs UDP

1. 连接与可靠性：TCP 在传输层通过三次握手建立连接后才发送数据，具备可靠传输特性。它通过确认机制、重传策略等确保数据完整到达目标端。而 UDP 无需建立连接，可直接发送数据，属于不可靠传输，存在数据丢包风险
2. 开销差异：TCP 建立连接需经历三次握手，且传输过程中需维护连接状态、处理确认和重传等机制，因此资源和时间开销较大。UDP 没有连接建立过程，也无需复杂的状态维护，所以开销较小，传输效率更高
3. 数据传输顺序：TCP 会对每个数据包编号，严格保证数据传输顺序，接收方按序重组数据。而 UDP 不保证数据顺序，数据包可经不同路由独立传输，导致到达顺序随机，接收端需自行处理乱序问题
4. 应用场景：TCP 适用于网页浏览、文件传输、邮件发送等对数据准确性和完整性要求高的场景。UDP 则常用于DNS 查询、视频直播、在线游戏等场景 ——DNS 查询需快速响应，少量丢包可容忍；视频直播和游戏更注重实时性，偶尔丢包不影响整体体验

十、DNS使用 UDP 的两个原因

1. 快速响应需求：用户在浏览器输入域名后，期望快速完成解析获取 IP 地址。UDP 协议无需像 TCP 那样进行三次握手建立连接，能够快速发送和接收 DNS 查询请求，极大缩短响应时间。同时，DNS 查询产生的数据包较小且数量少，符合 UDP 适合传输小数据量的特点，因此使用 UDP 可显著提升域名解析效率
2. 丢包容忍机制：DNS 系统具备丢包容忍能力。轻微丢包时，DNS 服务器仍可正常处理解析任务并返回 IP 地址。若丢包严重导致服务器无法响应，客户端内置的重试机制会在超时后重新发送查询请求，确保最终获取解析结果。此外，DNS 服务器的冗余部署也保障了即使某个请求因丢包失败，仍可从其他服务器获取有效解析，不影响整体服务

十一、DNS域名解析流程

1. 浏览器缓存查询：用户输入 URL 后，浏览器优先检查自身缓存，若存在对应域名的 IP 映射关系且未过期，则直接使用该 IP 地址发起请求；若未找到或已过期，则向操作系统发起域名解析请求
2. 系统 Hosts 文件查询：操作系统接收到请求后，会读取本地 Hosts 文件（Windows 路径为C:\Windows\System32\drivers\etc\hosts，Linux 路径为/etc/hosts），查找是否存在域名与 IP 的映射记录。若找到则返回 IP 地址，否则进入下一步
3. 本地 DNS 服务器查询：若 Hosts 文件中无对应记录，操作系统将请求发送至本地 DNS 服务器。本地 DNS 服务器可能由 ISP（如移动、联通）提供，也可能是学校或企业内部部署的服务器，其缓存中若有解析结果，会直接返回给操作系统
4. 根 DNS 服务器查询：若本地 DNS 服务器无缓存记录，则向根 DNS 服务器发起请求。以www.example.com为例，根 DNS 服务器会告知本地 DNS 服务器负责.com顶级域解析的顶级域 DNS 服务器地址
5. 顶级域 DNS 服务器查询：本地 DNS 服务器根据根 DNS 返回的信息，向对应顶级域 DNS 服务器（如.com域服务器）发送请求。顶级域 DNS 服务器会解析并返回负责example.com域名解析的权威 DNS 服务器地址
6. 权威 DNS 服务器查询：本地 DNS 服务器向权威 DNS 服务器发送请求，权威 DNS 服务器存储着具体域名（如www.example.com）与 IP 的映射关系，查询后将对应的 IP 地址返回给本地 DNS 服务器
7. 结果返回与缓存：本地 DNS 服务器将获取的 IP 地址回传至客户端浏览器，同时浏览器和本地 DNS 服务器会缓存该域名 - IP 映射关系，以便后续快速调用
8. 网络层数据封装：浏览器获取 IP 地址后，在网络层将请求数据封装，添加源 IP 地址和目标 IP 地址，发起网络请求。后续若用户再次访问相同 URL，浏览器会优先从缓存中读取 IP 地址，若缓存未过期则直接使用，避免重复解析流程

十二、Cookie vs Session vs Token

（1）Cookie的运作过程

1. 创建 Cookie：当用户初次访问启用 Cookie 机制的网站时，服务器会生成特定的 Cookie 数据，这些数据中涵盖了与用户相关的关键信息，比如用于标识会话的唯一标识（在不同的开发框架和系统中，该标识的名称和生成方式可能各异，常见的有 JSESSIONID，但并非唯一形式）。随后，服务器将这些 Cookie 数据设置到 HTTP 响应头的Set - Cookie字段内，并把包含该字段的响应发送给客户端浏览器。举例来说，服务器可能设置Set - Cookie: user_id=12345; expires=Thu, 18 Dec 2025 12:00:00 UTC; path=/，在此设置中，user_id=12345是用户标识，expires=Thu, 18 Dec 2025 12:00:00 UTC指定了 Cookie 的过期时间，path=/则明确了 Cookie 的作用路径为整个网站
2. 存储 Cookie：客户端浏览器在接收到服务器返回的 HTTP 响应头后，会对Set - Cookie字段中的内容进行提取，并依据提取到的信息创建相应的 Cookie 对象。在默认状态下，如果未对 Cookie 进行持久化设置（也就是没有指定过期时间，或者设置为会话级 Cookie），那么该 Cookie 将被存储在浏览器的内存之中，一旦用户关闭浏览器，此 Cookie 便会被自动删除。而当设置了持久化选项（例如指定了具体的过期时间）时，Cookie 会在其过期之前被保存到用户设备的硬盘上，这样一来，即使用户关闭了浏览器，下次再打开时，只要 Cookie 尚未过期，仍然可以继续使用
3. 发送 Cookie：当用户后续再次向该网站发起请求时，浏览器会自动从其存储的所有 Cookie 中筛选出与目标网站相关的 Cookie 信息（这些信息不仅仅局限于某个特定的 ID，可能包含多个键值对形式的 Cookie 数据），并将这些筛选出的 Cookie 信息放置在 HTTP 请求头的Cookie字段内，一同发送给服务器。例如，请求头中可能会出现Cookie: user_id=12345这样的内容，将用户之前存储的 Cookie 信息传递给服务器
4. 读取 Cookie：服务器接收到来自客户端的 HTTP 请求后，会对请求头中的Cookie字段进行解析，从中提取出 Cookie 信息。通过对这些 Cookie 信息的分析和处理，服务器能够识别出用户的身份，并根据用户身份查找与之对应的会话数据。利用这些会话数据，服务器可以进一步处理用户的请求，实现诸如保持用户的登录状态、记录用户的个性化偏好设置等功能，从而为用户提供更加个性化和便捷的服务体验

（2）Session的运作过程

1. 创建 Session：当用户首次访问启用 Session 机制的网站时，服务器会生成一个唯一的 Session ID。随后，将这个 Session ID 设置在响应头的Set - Cookie字段中，发送给客户端浏览器。同时，服务器内部会创建一个 Session 对象，该对象用于存储用户在此次会话期间的相关信息，如登录状态、购物车内容等
2. 使用 Session：用户后续再次访问该网站时，若浏览器中存储的包含 Session ID 的 Cookie 未丢失或过期，浏览器会自动将该 Cookie 信息提取出来，放在请求头的Cookie字段中发送给服务器。服务器接收到请求后，从Cookie字段里提取出 Session ID，依据这个 ID 查找对应的 Session 对象，进而获取用户的会话信息以处理请求
3. 销毁 Session：Session 的销毁通常有以下几种情况：一是达到服务器为 Session 设置的超时时间，在此期间若用户无操作，Session 会自动过期销毁；二是用户主动执行退出登录等操作，服务器会主动销毁该用户的 Session；三是服务器出现异常，如宕机、重启等情况，导致存储在服务器端的 Session 数据丢失

（3）Token的运作过程

十三、JWT

（1）JWT的组成

1. 头部（Header）：包含两个信息，Token 的类型（通常为 JWT）和签名使用的算法（如 HS256）。这两个信息会被 Base64 编码，形成 JWT 的第一部分
2. 载荷（Payload）：包含用户身份相关的信息，如用户名、用户 ID、用户权限等，还可设置 JWT 的过期时间等声明。需要注意的是，一般不会把密码放在载荷里，因为载荷只是简单的 Base64 编码，并非加密，密码放进去容易泄露。这些信息同样会被 Base64 编码，成为 JWT 的第二部分
3. 签名（Signature）：使用头部指定的算法，结合一个服务器端的密钥，对编码后的头部和载荷进行签名。签名用于验证 JWT 在传输过程中信息未被篡改，是 JWT 的第三部分

（2）JWT的运作过程

1. 创建与发送 JWT：用户首次登录使用 JWT 机制的网站时，服务器验证用户输入的信息（如用户名和密码），若验证通过，从数据库中查询该用户的相关信息作为载荷内容。接着，服务器使用指定的签名算法，结合服务器端密钥对编码后的头部和载荷进行签名，构建完整的 JWT。服务器将生成的 JWT 放入响应的Authorization字段（通常格式为Authorization: Bearer [JWT]）或响应体中，发送给客户端
2. 客户端存储与携带 JWT：客户端浏览器接收到 JWT 后，可选择将其存储在localStorage或sessionStorage中。后续客户端再次访问该网站时，会在请求头的Authorization字段中携带 JWT（格式为Authorization: Bearer [JWT]）发送给服务器
3. 服务器验证与处理：服务器收到客户端的请求后，从请求头的Authorization字段中提取 JWT。服务器将 JWT 拆解为头部、载荷和签名三部分，先对头部和载荷进行 Base64 解码，获取原始的头部和载荷信息。然后，服务器使用头部中指定的签名算法（例如 HS256），结合服务器端保存的相同密钥，对解码后的头部和载荷重新计算签名。最后，将计算得到的签名与 JWT 中携带的签名进行对比，如果二者一致，则说明 JWT 在传输过程中未被篡改，签名校验通过；若不一致，则签名校验失败，拒绝该请求。若验证通过，服务器从解码后的载荷中提取用户相关信息，根据这些信息判断用户权限，进而允许用户访问相应的资源。在此过程中，服务器无需使用传统的 Session 对象来维护用户状态

十四、localStorage vs sessionStorage

localStorage 和 sessionStorage 均属于 JavaScript 中的客户端数据存储技术，二者的区别主要体现在以下两个方面：

1. 存储期限：localStorage 的数据存储在客户端硬盘上，属于持久化存储。即便关闭浏览器或重启电脑，只要不手动删除或通过代码清除，数据依然存在。而 sessionStorage 的数据存储在客户端内存中，属于会话级存储。通常情况下，现代浏览器采用多进程模型，每个标签页对应一个独立进程，操作系统也会为浏览器本身分配管理进程所需的内存。当浏览器窗口或标签页关闭时，操作系统会回收分配给该窗口或标签页进程的内存资源，使得 sessionStorage 失去了存储数据的载体，因此其中存储的数据会立即丢失
2. 作用域范围：localStorage 作用域较广，只要是同一域名下的页面，无论何时访问、是否重新打开浏览器，甚至在不同标签页之间，都能访问和共享 localStorage 中的数据。sessionStorage 作用域相对较窄，仅在当前浏览器窗口或标签页的会话期间有效。重新打开浏览器，或在不同标签页之间，无法直接共享 sessionStorage 中的数据，即便这些页面属于同一域名

十五、Cookie vs JWT

1. 数据内容与安全性：Cookie 主要存储会话标识（如 session ID）等少量信息，一般不进行加密（不过可以通过 Secure 和 HttpOnly 属性增强安全性），主要用于在服务器端查找对应的会话。JWT 则包含用户相关信息，如用户名、用户 ID、用户权限、过期时间等，其头部和载荷采用 Base64 编码，签名部分基于头部、载荷内容，结合指定算法和服务器端密钥生成，用于验证数据完整性和真实性，相比普通 Cookie 安全性更高
2. 存储位置：Cookie 存储在客户端浏览器中；JWT 通常存储在客户端的 localStorage 或 sessionStorage 里，也可以存储在内存中（如通过 JavaScript 变量临时保存）
3. 数据传输方式：Cookie 通过请求头的 Cookie 字段在客户端和服务器间自动传递；JWT 一般通过请求头的 Authorization 字段传输，格式为 Bearer [JWT]
4. 跨域与传输机制：Cookie 的传输受浏览器同源策略限制，仅在同一域名下的请求中会被浏览器自动携带；JWT 本身不依赖浏览器同源策略，在跨域场景下，只要目标网站被浏览器允许访问特定域名下的 localStorage（通常通过 CORS 配置或代理机制等方式实现），该网站就可以通过 JavaScript 代码，如 localStorage.getItem('jwt_token')（假设存储时的键名为 jwt_token）获取到 JWT，然后将其设置到请求头的 Authorization 字段中（如 Authorization: Bearer [获取到的JWT]）发送给服务器，但跨域请求还需配合 CORS 等配置
5. 服务器状态管理：Cookie - Session 机制下，服务器需要维护 Session 对象，记录用户会话状态；JWT 是无状态的，服务器无需保存用户会话信息，仅通过验证 JWT 有效性和解析内容处理请求
6. 用户认证与权限处理：使用 Cookie 机制时，用户首次登录，服务器验证用户名和密码后创建会话并返回 Cookie，后续请求中服务器通过 Cookie 识别用户，每次处理请求时可能仍需从数据库或其他存储中查询用户权限；JWT 机制下，用户首次登录验证通过后，服务器将用户信息和权限等内容生成 JWT 返回，后续请求中服务器直接解析 JWT 中的权限信息进行处理，无需每次都查询数据库