计算机网络 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: 27
  
  username=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: 10
  
  Hello 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 握手是客户端与服务器建立安全连接的关键步骤，主要目的是：

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

基于 RSA 算法的 TLS 握手流程

核心流程（简化版）：

1. 客户端发起请求（ClientHello）

   • 客户端发送支持的 TLS 版本、加密算法列表（如 RSA 相关套件）、随机数（Client Random）等信息。

2. 服务器响应（ServerHello）

   • 服务器选择 TLS 版本、加密算法（如 RSA）、随机数（Server Random），并发送服务器证书（含 RSA 公钥）。

3. 客户端验证服务器证书

   • 客户端通过信任的 CA 验证服务器证书的合法性，提取服务器公钥。

4. 客户端生成预主密钥（Pre-Master Secret）

   • 客户端生成一个随机数作为预主密钥，用服务器公钥加密后发送给服务器（RSA 加密过程）。

5. 服务器解密预主密钥

   • 服务器用私钥解密获取预主密钥，结合双方随机数（Client Random 和 Server Random）生成 主密钥（Master Secret）。

6. 生成对称密钥

   • 客户端和服务器分别根据主密钥生成用于加密通信的对称密钥（如 AES 密钥）。

7. 验证握手完整性

   • 双方发送握手结束消息，使用新生成的密钥对消息进行加密和校验，确保握手过程未被篡改。

基于 ECDHE 算法的 TLS 握手流程

核心流程（简化版）：

1. 客户端发起请求（ClientHello）

   • 类似 RSA 流程，但支持的加密算法包含 ECDHE 相关套件（如 ECDHE-ECDSA-AES256-GCM-SHA384）。

2. 服务器响应（ServerHello）

   • 选择 ECDHE 算法，发送服务器证书（含 ECDSA 公钥或 RSA 公钥，取决于签名算法）、椭圆曲线参数、服务器端生成的椭圆曲线私钥对应的公钥（Server PubKey）。

3. 客户端验证服务器证书

   • 验证证书合法性，提取服务器公钥。

4. 客户端生成椭圆曲线密钥对

   • 客户端生成临时椭圆曲线密钥对（Client PrivKey 和 Client PubKey），发送 Client PubKey 给服务器。

5. 协商共享密钥（ECDHE 密钥交换）

   • 客户端和服务器分别用对方的公钥与自己的私钥计算出 共享秘密（Shared Secret）：
     • 客户端：用 Server PubKey 和 Client PrivKey 计算共享秘密。
     • 服务器：用 Client PubKey 和 Server PrivKey 计算共享秘密。
   • 双方得到的共享秘密相同，结合随机数生成 预主密钥 和 主密钥。

6. 生成对称密钥

   • 与 RSA 流程类似，基于主密钥生成对称加密密钥。

7. 验证握手完整性

   • 流程与 RSA 一致。