计算机网络 HTTP篇常见面试题总结

HTTP各版本区别

HTTP 1.0

无状态、无连接：每次请求都需要建立新的 TCP，处理完后立即关闭，导致开销较大。
队头阻塞：每个请求必须按照顺序依次处理，前面的请求未完成，后面的请求只能等待，减低了并发效率。
不支持持久连接：每个请求都建立一个新的 TCP 连接，增加了服务器的负担

HTTP 1.1

持久连接：引入了 Keep - Alive 机制，多个请求可以复用同一个 TCP 连接，介绍了建立连接的开销。
管道化：允许在同一个 TCP 连接上同时发送多个请求，提高了并发效率。
Host 字段：可以在同一个 IP 地址上允许多个虚拟主机。
断点续传：支持文件传输中断后从断点处继续传输。

HTTP 2.0

二进制分帧：将 HTTP 报文分割为更小的二进制，提高了传输效率，并支持多路复用。
头部压缩：减少了 HTTP 头部的大小，降低了网络开销。
服务器推送：服务器可以主动向客户端推送资源，减少了客户端的请求次数。
多路复用：在一个 TCP 连接上可以同时发送多个请求和响应，解决了 HTTP 1.1 的队头阻塞问题。

HTTP 3.0

基于 QUIC 协议：使用 UDP 协议，相较于 TCP 的可靠性，QUIC 通过自身实现可靠传输，减少了 RTT。
多路复用：在一个 QUIC 连接上可以同时传输多个请求和响应，并且支持流优先级。
更快的连接建立：减少了 TCP 的三次握手和 TLS 的握手时间。
更低的延迟：由于 QUIC 协议的特性，HTTP 3.0 具有很低的延迟。

常见HTTP状态码

1xx: 信息响应

100 Continue: 服务器已接收请求的初步部分，客户端应继续请求。
101 Switching Protocols: 服务器同意切换协议，如从 HTTP 切换到 WebSocket。

2xx: 成功

200 OK: 请求成功，服务器返回所请求的资源或数据。
201 Created: 请求成功并创建了新的资源，常用于 POST 请求。
204 No Content: 请求成功但服务器不返回任何内容，常用于删除操作。

3xx: 重定向

301 Moved Permanently: 资源已永久移动到新的 URL，客户端应使用新 URL 访问。
302 Found: 资源临时移动到新的 URL，客户端应继续使用原来的 URL。
304 Not Modified: 资源未修改，客户端可以使用缓存版本。

4xx: 客户端错误

400 Bad Request: 请求无效或语法错误，服务器无法处理。
401 Unauthorized: 请求需要身份验证，客户端未提供有效的凭证。
403 Forbidden: 服务器理解请求但拒绝执行，通常是权限问题。
404 Not Found: 请求的资源在服务器上未找到。

5xx: 服务器错误

500 Internal Server Error: 服务器内部错误，无法完成请求。
502 Bad Gateway: 服务器作为网关或代理，从上游服务器接收到无效响应。
503 Service Unavailable: 服务器暂时无法处理请求，通常是因为过载或维护。

HTTP请求内容组成

HTTP 请求组成：

请求行（Request Line）：包含请求方法（如 GET、POST）、请求的资源路径（如 /index.html ）、以及 HTTP 协议版本（如 HTTP/1.1）。
请求头（Request Headers）：包含各种键值对，用于传递客户端环境、请求内容、认证信息等。
空行（Blank Line）：用于分隔请求头和请求体。
请求体（Request Body）：通常在 POST、PUT 等方法中存在，包含需要发送到服务器的数据。

请求头用于传递附加信息：

1. 通用头（General Headers）

Cache-Control：控制缓存策略（如 no-cache、max-age=3600）
Connection：控制连接状态（如 keep-alive、close）
Date：请求时间（如 Wed, 30 May 2025 12:00:00 GMT）

2. 请求头（Request-Specific Headers）

Host：目标服务器域名（如 www.example.com）
User-Agent：客户端信息（如浏览器类型、操作系统）
Accept：客户端可接收的响应格式（如 application/json、text/html）
Accept-Language：客户端语言偏好（如 zh-CN,en-US;q=0.8）
Accept-Encoding：客户端支持的压缩格式（如 gzip、deflate）
Cookie：存储的会话信息（如 session_id=123456）
Authorization：身份验证信息（如 Bearer token123）

3. 实体头（Entity Headers）

Content-Type：请求体的媒体类型（如 application/json、multipart/form-data）
Content-Length：请求体的长度（如 128）
Content-Encoding：请求体的编码方式（如 gzip）

请求体的类型由 `Content-Type` 头决定，常见类型如下：

1. 无请求体（No Body）

适用方法：GET、HEAD、DELETE、OPTIONS

示例：

GET /api/users HTTP/1.1
Host: www.example.com

2. 表单数据（Form Data）

Content-Type：application/x-www-form-urlencoded
格式：键值对（key1=value1&key2=value2）

示例：

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27username=admin&password=123456

3. 多部分表单数据（Multipart Form Data）

Content-Type：multipart/form-data; boundary=----WebKitFormBoundary123456
用途：上传文件或复杂表单

示例：

POST /upload HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary123456------WebKitFormBoundary123456
Content-Disposition: form-data; name="username"admin
------WebKitFormBoundary123456
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg[二进制文件内容]
------WebKitFormBoundary123456--

4. JSON 数据

Content-Type：application/json
格式：JSON 对象

示例：

POST /api/users HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 27{"name": "John", "age": 30}

5. XML 数据

Content-Type：application/xml 或 text/xml
格式：XML 文档

示例：

POST /api/users HTTP/1.1
Host: www.example.com
Content-Type: application/xml
Content-Length: 81<user><name>John</name><age>30</age>
</user>

6. 原始数据（Raw Data）

Content-Type：text/plain、application/javascript 等
用途：传输任意格式文本

示例：

POST /api/script HTTP/1.1
Host: www.example.com
Content-Type: text/plain
Content-Length: 10Hello World

HTTP中GET和POST区别

从 HTTP 的定义来看：

GET：用于获取资源，通常用于请求数据而不改变服务器状态。
POST：用于提交数据到服务器，通常会改变服务器的状态或产生副作用（如创建或更新资源）。

由于 HTTP 和浏览器等规定，它们在应用过程中会出现一些区别：

参数传递方式：

GET：参数通过 URL 拼接传递，暴露在请求 URL 中，具有可见性，长度有限（取决于浏览器和服务器）。
POST：参数放在请求体中，通常不可见且长度理论上没有限制，更适合传递大量数据（但是注意，POST 也可以在 URL 上放参数！）。

安全性：

GET：参数可见，数据容易暴露在浏览器历史记录、日志和缓存中，不适合传递敏感信息。
POST：数据放在请求体中，相对安全，但需要 HTTPS 才能保证数据加密传输。

幂等性：

GET：幂等（重复请求不会改变服务器状态）。
POST：非幂等（多次请求可能导致重复创建资源或执行多次相同操作）。

GET 和 POST 的数据传输方式与限制

URL 长度限制：GET 请求中的参数通过 URL 传递，受 URL 长度限制。不同浏览器和服务器对 URL 长度限制不同，一般为 2048 字节左右，因此不适合大数据传输。
POST 请求体限制：POST 请求的数据放在请求体中，理论上无长度限制，适合传输较多的数据。但实际中服务器对请求体长度有配置限制，如 Nginx 默认限制为 1MB，可根据需求调整。

GET 和 POST 的数据安全性差异

GET 请求暴露数据：由于 GET 请求的参数出现在 URL 中，可能被浏览器缓存、日志记录或历史记录保存，增加了信息泄露的风险，不适合传输敏感信息，如用户名、密码等。
POST 请求相对安全：POST 请求数据位于请求体中，尽管这并不提供加密保护，但比 URL 中传递更隐蔽。配合 HTTPS 加密传输可进一步确保数据安全。

缓存机制的不同

GET 请求可缓存：GET 请求可以被浏览器和 CDN 缓存，当请求同一个 URL 时可以直接返回缓存内容，减少服务器负载。适用于不频繁变动的资源，比如图片、静态页面。
POST 请求默认不缓存：大部分浏览器和缓存服务器不缓存 POST 请求，主要因为 POST 请求通常会对服务器数据产生影响（如创建、修改数据），需要确保请求每次都传递到服务器。

HTTP和HTTPS区别

数据传输安全性：

HTTP：数据以明文传输，容易被窃听、篡改。
HTTPS：通过 SSL/TLS 协议对数据进行加密传输，提供数据机密性和完整性保障。

端口号：

HTTP：默认使用端口 80。
HTTPS：默认使用端口 443。

性能：

HTTP：无加密过程，连接建立速度稍快。
HTTPS：基于 HTTP 上又加了 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）协议来实现的加密传输，加解密过程增加了计算开销，握手时间较长，但现代硬件和协议优化已使性能差距减小。

SEO 影响：

HTTP：搜索引擎一般会降低未加密站点的排名。
HTTPS：搜索引擎更倾向于优先展示 HTTPS 网站。

HTTPS握手过程

TLS 握手过程概述

TLS 握手是客户端与服务器建立安全连接的关键步骤，主要目的是：

验证双方身份（通常验证服务器身份）。
协商加密算法和密钥（对称密钥和非对称密钥）。
确保通信内容的机密性和完整性。

基于 RSA 算法的 TLS 握手流程

核心流程（简化版）：

客户端发起请求（ClientHello）
- 客户端发送支持的 TLS 版本、加密算法列表（如 RSA 相关套件）、随机数（Client Random）等信息。
服务器响应（ServerHello）
- 服务器选择 TLS 版本、加密算法（如 RSA）、随机数（Server Random），并发送服务器证书（含 RSA 公钥）。
客户端验证服务器证书
- 客户端通过信任的 CA 验证服务器证书的合法性，提取服务器公钥。
客户端生成预主密钥（Pre-Master Secret）
- 客户端生成一个随机数作为预主密钥，用服务器公钥加密后发送给服务器（RSA 加密过程）。
服务器解密预主密钥
- 服务器用私钥解密获取预主密钥，结合双方随机数（Client Random 和 Server Random）生成 主密钥（Master Secret）。
生成对称密钥
- 客户端和服务器分别根据主密钥生成用于加密通信的对称密钥（如 AES 密钥）。
验证握手完整性
- 双方发送握手结束消息，使用新生成的密钥对消息进行加密和校验，确保握手过程未被篡改。

基于 ECDHE 算法的 TLS 握手流程

核心流程（简化版）：

客户端发起请求（ClientHello）
- 类似 RSA 流程，但支持的加密算法包含 ECDHE 相关套件（如 ECDHE-ECDSA-AES256-GCM-SHA384）。
服务器响应（ServerHello）
- 选择 ECDHE 算法，发送服务器证书（含 ECDSA 公钥或 RSA 公钥，取决于签名算法）、椭圆曲线参数、服务器端生成的椭圆曲线私钥对应的公钥（Server PubKey）。
客户端验证服务器证书
- 验证证书合法性，提取服务器公钥。
客户端生成椭圆曲线密钥对
- 客户端生成临时椭圆曲线密钥对（Client PrivKey 和 Client PubKey），发送 Client PubKey 给服务器。
协商共享密钥（ECDHE 密钥交换）
- 客户端和服务器分别用对方的公钥与自己的私钥计算出 共享秘密（Shared Secret）：
  - 客户端：用 Server PubKey 和 Client PrivKey 计算共享秘密。
  - 服务器：用 Client PubKey 和 Server PrivKey 计算共享秘密。
- 双方得到的共享秘密相同，结合随机数生成 预主密钥 和 主密钥。
生成对称密钥
- 与 RSA 流程类似，基于主密钥生成对称加密密钥。
验证握手完整性
- 流程与 RSA 一致。