HTTP和HTTPS

文章目录

HTTP
- [1. HTTP 协议简介](#1. HTTP 协议简介)
- [2. HTTP 报文格式](#2. HTTP 报文格式)
- - [2.1 抓包工具与 HTTP 报文观察](#2.1 抓包工具与 HTTP 报文观察)
  - - [1. 抓包原理](#1. 抓包原理)
    - [2. 常见抓包工具](#2. 常见抓包工具)
    - [3. 使用 Fiddler 抓包注意事项](#3. 使用 Fiddler 抓包注意事项)
- [3. HTTP 请求与响应的基本格式详解](#3. HTTP 请求与响应的基本格式详解)
- - [一、HTTP 是什么？](#一、HTTP 是什么？)
  - [二、发送 HTTP 请求与接收响应过程](#二、发送 HTTP 请求与接收响应过程)
  - [三、HTTP 请求报文结构](#三、HTTP 请求报文结构)
  - [四、HTTP 响应报文结构](#四、HTTP 响应报文结构)
- [4. URL](#4. URL)
- - [1. URL 与 URI](#1. URL 与 URI)
  - [2. URL 格式结构详解](#2. URL 格式结构详解)
  - [3. 查询字符串（Query String）](#3. 查询字符串（Query String）)
  - [4. URL 编码（url encode）](#4. URL 编码（url encode）)
  - [5. 日常开发注意事项](#5. 日常开发注意事项)
  - [6. 重点关注的 URL 部分](#6. 重点关注的 URL 部分)
- [5. HTTP 的方法（Method）](#5. HTTP 的方法（Method）)
- - [1. 基本概念](#1. 基本概念)
  - [2. GET 方法](#2. GET 方法)
  - [3. POST 方法](#3. POST 方法)
  - [4. GET 和 POST 的区别（经典面试题）](#4. GET 和 POST 的区别（经典面试题）)
  - [5. 浏览器缓存与强制刷新](#5. 浏览器缓存与强制刷新)
  - [6. 访问一个网页的过程](#6. 访问一个网页的过程)
  - [7. POST 请求举例](#7. POST 请求举例)
- [6. 请求报头常见字段](#6. 请求报头常见字段)
- [7. User-Agent（简称 UA）](#7. User-Agent（简称 UA）)
- - [1. 什么是 User-Agent](#1. 什么是 User-Agent)
  - [2. UA 字段示例](#2. UA 字段示例)
  - [3. UA 的常见用途](#3. UA 的常见用途)
  - - 1）判定浏览器和操作系统
    - 2）判断功能支持
    - 3）数据统计与分析
    - [4）区分 PC 和移动端](#4）区分 PC 和移动端)
  - [4. 日常开发中的应用](#4. 日常开发中的应用)
- [8. Referer](#8. Referer)
- - [Referer 的作用](#Referer 的作用)
- [9. Cookie](#9. Cookie)
- - [1. 什么是 Cookie？](#1. 什么是 Cookie？)
  - [2. Cookie 的工作流程](#2. Cookie 的工作流程)
  - [3. Cookie 的特点](#3. Cookie 的特点)
  - [4. Cookie 的典型应用场景](#4. Cookie 的典型应用场景)
  - [5. Cookie 的局限与替代方案](#5. Cookie 的局限与替代方案)
  - [6. 总结](#6. 总结)
- [10. HTTP 状态码](#10. HTTP 状态码)
- - [1. 200 OK](#1. 200 OK)
  - [2. 404 Not Found](#2. 404 Not Found)
  - [3. 403 Forbidden](#3. 403 Forbidden)
  - [4. 405 Method Not Allowed](#4. 405 Method Not Allowed)
  - [5. 500 Internal Server Error](#5. 500 Internal Server Error)
  - [6. 504 Gateway Timeout](#6. 504 Gateway Timeout)
  - [7. 302 Found（重定向）](#7. 302 Found（重定向）)
- [11. 构造HTTP请求的方式](#11. 构造HTTP请求的方式)
**HTTPS**
- - [**一、问题：HTTP 为什么不安全？**](#一、问题：HTTP 为什么不安全？)
  - [**二、解决方案：加密**](#二、解决方案：加密)
  - - [**1. 对称加密 (Symmetric Encryption)**](#1. 对称加密 (Symmetric Encryption))
    - [**2. 非对称加密 (Asymmetric Encryption)**](#2. 非对称加密 (Asymmetric Encryption))
  - [**三、 HTTPS 的完美方案：混合加密**](#三、 HTTPS 的完美方案：混合加密)
  - [**四、新问题：中间人攻击 (Man-in-the-Middle Attack)**](#四、新问题：中间人攻击 (Man-in-the-Middle Attack))
  - [**五、最终解决方案：数字证书 (Digital Certificate) & CA**](#五、最终解决方案：数字证书 (Digital Certificate) & CA)
  - - [**1. 证书是什么？**](#1. 证书是什么？)
    - [**2. 数字签名的工作原理（防篡改核心）**](#2. 数字签名的工作原理（防篡改核心）)
    - [**3. 如何避免中间人攻击？**](#3. 如何避免中间人攻击？)
  - [**六、总结：HTTPS 完整工作流程**](#六、总结：HTTPS 完整工作流程)
  - [**关于 Fiddler/Charles 等抓包工具**](#关于 Fiddler/Charles 等抓包工具)
[**面试题：从输入 URL 到页面展示，发生了什么？**](#面试题：从输入 URL 到页面展示，发生了什么？)
- - **总体概览**
  - [**一、网络原理视角 (核心)**](#一、网络原理视角 (核心))
  - - [**1. URL 解析**](#1. URL 解析)
    - [**2. DNS 解析 (域名 -> IP 地址)**](#2. DNS 解析 (域名 -> IP 地址))
    - [**3. 建立 TCP 连接 (三次握手)**](#3. 建立 TCP 连接 (三次握手))
    - [**4. TLS 握手 (仅 HTTPS)**](#4. TLS 握手 (仅 HTTPS))
    - [**5. 发送 HTTP 请求**](#5. 发送 HTTP 请求)
    - [**6. 服务器处理与返回响应**](#6. 服务器处理与返回响应)
    - [**7. 浏览器接收响应**](#7. 浏览器接收响应)
    - [**8. 关闭连接 (四次挥手)**](#8. 关闭连接 (四次挥手))
  - [**二、服务器后端开发视角**](#二、服务器后端开发视角)
  - - [**1. Web 服务器层 (Nginx)**](#1. Web 服务器层 (Nginx))
    - [**2. 应用服务器层 (Tomcat + Spring)**](#2. 应用服务器层 (Tomcat + Spring))
    - [**3. 定义 API 接口**](#3. 定义 API 接口)
  - [**三、网页前端开发视角**](#三、网页前端开发视角)
  - **总结回答技巧**

HTTP

1. HTTP 协议简介

HTTP（HyperText Transfer Protocol）：应用层协议，主要用于客户端和服务器之间的数据传输。
不仅能传输文本，还能传输图片、音频、视频及其他数据。
最主流版本为 HTTP/1.1，升级到 HTTP/2.0 兼容性成本较高。
典型的一问一答模型：客户端发请求，服务器返回响应。

2. HTTP 报文格式

2.1 抓包工具与 HTTP 报文观察

1. 抓包原理

抓包：指将网卡上的网络数据包捕获并解析、显示出来，便于分析网络通信内容。
抓包程序本质

：是一种代理（Proxy）。
- 正向代理：代理客户端，客户端通过代理访问目标服务器。
- 反向代理：代理服务器，客户端访问代理，代理再转发到真实服务器。
VPN 类软件：也是一种代理，原理类似。

2. 常见抓包工具

工具	说明
Wireshark	可抓取所有网络层数据包（TCP、UDP、IP等），也能解析 HTTP。
Fiddler	专业的 HTTP/HTTPS 抓包工具，支持请求/响应内容分析、修改。
Chrome/Edge 开发者工具	Network 面板可记录和显示浏览器发出的所有 HTTP(S) 请求，但无法看到原始报文数据（如请求的字节流、压缩内容等）。

3. 使用 Fiddler 抓包注意事项

关闭其他代理软件
- Fiddler 本身就是代理，如果电脑有其他代理软件，可能会与 Fiddler 冲突，导致无法正常抓包。
HTTPS 抓包设置
- 现在大部分网站都是 HTTPS 加密，Fiddler 默认无法解析加密内容。
- 需开启 Fiddler 的 HTTPS 抓包功能，安装 Fiddler 提供的"根证书"。
- 弹出安装证书对话框时必须选择"是"，否则无法抓取解密后的 HTTPS 数据。
查看原始报文
- 响应内容通常是压缩过的二进制数据（如 gzip、br 等），需要用 Fiddler 的 Raw 视图查看 HTTP 原始数据。

整理如下，便于快速查阅和理解：

3. HTTP 请求与响应的基本格式详解

一、HTTP 是什么？

HTTP（HyperText Transfer Protocol）是一种基于文本行的协议。
HTTP 报文本质上就是一段字符串，通过 TCP socket 发送和接收。

二、发送 HTTP 请求与接收响应过程

发送请求：就是把一段符合 HTTP 格式的字符串写入 TCP socket。
接收响应：就是从 TCP socket 读取字符串并解析。

三、HTTP 请求报文结构

首行
复制代码
```
GET https://www.nba.com/warriors/ HTTP/1.1
```
- GET：请求方法（method）
- **https://www.nba.com/warriors/**：请求资源的 URL
- HTTP/1.1：协议版本号
请求头（Header）
- 从第二行开始，每一行都是一个键值对，格式为 键: 值，键和值之间用冒号和空格分隔。
- 例：
  http 复制代码
```
Host: www.nba.com
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,...
Cookie: ...
```
空行
- 用于标记请求头的结束。
正文（Body）
- 某些请求（如 POST）会有请求体，GET 通常没有。

四、HTTP 响应报文结构

首行
复制代码
```
HTTP/1.1 200 OK
```
- HTTP/1.1：协议版本号
- 200：状态码
- OK：状态描述

响应头（Header）

每一行也是一个键值对，格式为 键: 值。

例：

http 复制代码

Content-Type: text/html
Content-Encoding: gzip
Set-Cookie: ...
Content-Length: 18979
Date: Fri, 19 Sep 2025 11:44:59 GMT

空行
- 标记响应头的结束。
正文（Body）
- 通常是 HTML、CSS、JS、JSON、图片、音频、字体等内容。

4. URL

1. URL 与 URI

URL （Uniform Resource Locator，统一资源定位符）：用于定位互联网上的某个资源（网页、图片、文件等）。
URI （Uniform Resource Identifier，统一资源标识符）：用于标识某个资源，URL 是 URI 的一种具体实现。

2. URL 格式结构详解

以示例 URL 为例：

复制代码

https://www.mywebsite.com:8080/shop/products?id=100&category=books#reviews

部分	示例值	说明
协议名	`https`	传输协议，常见有 http/https/ftp
域名/IP	`www.mywebsite.com`	服务器主机地址
端口号	`:8080`	访问服务器的具体端口（默认可省略）
路径	`/shop/products`	资源在服务器上的具体位置
查询字符串	`?id=100&category=books`	以键值对形式传递参数
片段标识符	`#reviews`	页面内部锚点，定位到页面某部分

3. 查询字符串（Query String）

以 ? 开头，后面是 key=value 形式的参数，多个参数用 & 连接。
例：?q=golden%20state%20warriors
查询字符串常用来给资源补充说明或传递参数。

4. URL 编码（url encode）

作用：保证 URL 中的特殊字符不会被误解析。
特殊字符（如 :, /, @, ?, &, = 等）在 URL 中有特殊含义，若出现在参数值中，必须进行编码。
编码规则：用 % 加上字符的 ASCII 十六进制表示。例如，空格编码为 %20。
例：golden state warriors → golden%20state%20warriors

5. 日常开发注意事项

大多数开发库 （如 JavaScript 的 encodeURIComponent、Java 的 URLEncoder 等）都自带 URL 编码/解码功能。
一般无需手动处理，只需合理使用相关库方法即可。

6. 重点关注的 URL 部分

域名/IP：定位服务器
端口号：指定服务端口
路径：资源在服务器上的具体位置（与后端代码关系密切）
查询字符串：参数传递（在 Web 框架如 Spring MVC 中经常用到）

5. HTTP 的方法（Method）

1. 基本概念

HTTP 方法（如 GET、POST）描述了"这个 HTTP 请求要对资源做什么操作"。
最常用的两种方法：GET 和 POST。

2. GET 方法

作用：从服务器获取数据（读取资源）。
常见场景 ：
1. 直接在浏览器输入 URL，触发 GET 请求。
2. HTML 页面中的 <img>、<script>、<link>、<a> 等元素自动触发 GET 请求。
3. JS 代码（如 AJAX、fetch）也能主动发起 GET 请求。
数据传递方式：通过 URL 的查询字符串（Query String）传递参数。
特点：
- 数据暴露在 URL 上，明文可见。
- 一般不会有请求体（body）。
- 幂等性强（同样的 GET 多次请求结果一致）。
- 可以被浏览器/代理缓存。

3. POST 方法

作用：向服务器提交数据（新增或修改资源）。
常见场景 ：
1. 登录、注册等提交表单。
2. 上传文件（如更换头像）。
数据传递方式：主要通过请求体（body）传递参数或内容。
特点：
- 数据在 body 中，不会直接暴露在 URL。
- 非幂等性（多次相同 POST 可能产生不同结果）。
- 通常不会被缓存。

4. GET 和 POST 的区别（经典面试题）

区别点	GET	POST
语义	获取（读取）资源	提交（新增/修改）资源
参数传递	通过 URL 查询字符串	通过请求体（body）
数据长度	受 URL 长度限制（一般 2K-8K）	理论上无限制（受服务器配置影响）
安全性	明文可见，敏感信息易泄露	数据在 body，稍好，但同样是明文传输
幂等性	幂等（多次请求结果一样）	非幂等（多次请求结果可能不同）
缓存	可被缓存	通常不会被缓存
典型场景	查询、获取数据	表单提交、文件上传

注意：

HTTP 协议层面，GET 和 POST 没有本质区别，完全可以互换（只要服务器端代码支持）。

实际开发中，主要是语义约定 和使用习惯。

首先, 明确抛出结论, 这两个方法, 其实没有本质区别 (各自替换对方都能用)

在使用习惯上,是有区别的

语义不同. 方法表示的含义

Get 表示从服务器拿数据

Post 表示往服务器提交数据
传递数据的方式不同

GET 传递是数据, 通常是通过 query string 把自定义数据交给服务器

POST 传递数据, 通常通过 body 把自定义数据交给服务器
承接幂等性

GET 如果设计成幂等的, 此时 GET 结果是可以被缓存的

POST 不设计成幂等的, POST 就不应该被缓存

5. 浏览器缓存与强制刷新

浏览器会缓存静态资源（CSS、JS、图片等），提升加载速度，节省带宽。
普通刷新（F5）：命中缓存，部分资源不重新请求。
强制刷新（Ctrl + F5）：忽略缓存，所有资源都重新从服务器获取。

6. 访问一个网页的过程

不是一次 HTTP 请求就能搞定！
一个页面的 HTML 可能会触发数十甚至上百个 GET 请求（CSS、JS、图片、字体等）。
这些资源大多是静态的，浏览器会缓存，减少重复请求。

7. POST 请求举例

登录请求：

http 复制代码

POST https://github.com/session HTTP/1.1
Content-Type: application/x-www-form-urlencoded

login=Zekeriri&password=Eriri320&...

文件上传请求：

http 复制代码

POST https://uploads.github.com/avatars HTTP/1.1
Content-Type: multipart/form-data; boundary=...

------WebKitFormBoundary...
Content-Disposition: form-data; name="file"; filename="1005.png"
Content-Type: image/png

...二进制图片数据...

6. 请求报头常见字段

字段名	作用说明
Host	服务器主机地址和端口（URL 里也体现）
Content-Length	请求体（body）数据长度（字节数）
Content-Type	body 的数据类型（如 text/html、application/json、multipart/form-data 等）

7. User-Agent（简称 UA）

1. 什么是 User-Agent

User-Agent 是 HTTP 请求头中的一个字段，简称 UA。
它会告诉服务器：当前请求来自什么操作系统、什么浏览器、什么版本等详细信息。

2. UA 字段示例

http 复制代码

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 Edg/133.0.0.0

Windows NT 10.0; Win64; x64：操作系统信息（Windows 10，64位）
Chrome/133.0.0.0：浏览器及其版本（Chrome 133）
Edg/133.0.0.0：Edge 浏览器
AppleWebKit/537.36 、Safari/537.36：浏览器内核信息

3. UA 的常见用途

1）判定浏览器和操作系统

服务器可以通过 UA 判断访问者用的是什么浏览器、什么操作系统。
便于做兼容性处理，比如某些老旧浏览器不支持新特性，可以给出提示或降级处理。

2）判断功能支持

判断浏览器是否支持多媒体、HTML5、新的 CSS/JS 特性等。

3）数据统计与分析

网站会收集 UA，用于统计访问量、用户设备分布（PC 端 vs 移动端）、浏览器市场份额等。
这些数据可以帮助产品团队优化和迭代产品，提升用户体验。

4）区分 PC 和移动端

通过 UA 字符串中的关键词（如 Android、iPhone、iPad、Mobile 等）快速判断访问者是用手机还是电脑。

4. 日常开发中的应用

前端适配：根据 UA 判断，自动跳转到手机端或 PC 端页面。
后端日志分析：统计不同设备、浏览器的访问量，辅助决策。
兼容性提示：对不支持的浏览器弹出升级提示。

8. Referer

描述了当前页面,是从哪个页面跳转过来的

Referer 并不一定真的有

示例:

http 复制代码

Referer: https://www.nba.com/warriors/

Referer 是在HTTP请求中,发给服务器的

这个东西是给服务器使用的

Referer 的作用

给服务器使用，帮助服务器了解流量来源。

用于：

统计分析：分析用户是从哪里进入当前页面的，判断推广效果、流量来源渠道等。
防盗链：有些网站会检查 Referer，限制图片、视频等资源只能在指定页面访问。
安全防护：比如防止 CSRF（跨站请求伪造）攻击时，会校验 Referer 是否来自合法页面。

Cookie 是浏览器为网站提供的一种"客户端存储数据"的机制。
本质上是浏览器本地持久化存储的键值对 ，用 ; 分割每组键值对，= 分割键和值。
Cookie 按照域名进行分类，每个域名下可以有多个 Cookie。

首次访问网站
- 浏览器没有 Cookie，向服务器发起请求。
服务器响应
- 响应头中包含 Set-Cookie 字段，把一些键值对写回到浏览器。
浏览器存储 Cookie
- 浏览器收到 Cookie，存储到本地（硬盘），但网页无法直接访问硬盘文件系统，只能通过 Cookie 这种机制。
后续请求
- 再次访问同一域名时，浏览器会自动把对应域名下的 Cookie 附加到请求头，发送给服务器。

安全性：网页无法直接访问你的硬盘，只能通过浏览器接口存储和读取 Cookie。
按域名分类：每个域名有自己的 Cookie，互不干扰。
程序员自定义内容：Cookie 里的键值对内容完全由开发者决定。

用户身份认证（登录状态保持）

HTTP 是无状态协议，每次请求互不关联。
登录后，服务器返回一个 sessionId，用 Set-Cookie 写入浏览器。
后续访问时，浏览器自动带上 Cookie（包含 sessionId）。
服务器用 sessionId 在自己的存储（如 hash 表）里查找用户信息，实现登录状态的保持。

示例：

http 复制代码

Cookie: sessionId=aaabbbcc......

随着技术发展，Cookie 不是唯一的浏览器本地存储机制：
- localStorage：键值对存储，容量更大，不随请求自动发送。
- IndexedDB：结构化数据存储，类似数据库。
会话信息也可以通过其他方式（如 JWT）存储在客户端，安全性更高，支持跨域。

6. 总结

是什么？

Cookie 是浏览器本地持久化存储数据的一种机制，按键值对方式存储，按域名分类。
从哪里来？

服务器响应中的 Set-Cookie 字段。
到哪里去？

后续访问同一服务器时，浏览器自动带上 Cookie。
主要用途？

用户身份认证、登录状态保持、个性化设置等。

整理如下，便于查阅和理解：

10. HTTP 状态码

HTTP 状态码是服务器在响应浏览器请求时返回的数字代码，用于表示请求的处理结果。常见状态码如下：

1. 200 OK

含义：请求成功，服务器已正确返回资源。
场景：正常访问网页、图片等资源。

2. 404 Not Found

含义：请求的资源在服务器上没有找到。
场景：浏览器访问的 URL 路径对应的资源不存在，或被删除。

3. 403 Forbidden

含义：访问被拒绝，没有权限访问该资源。
场景：尝试访问受限页面或文件，服务器拒绝请求。

4. 405 Method Not Allowed

含义：请求的方法（如 GET、POST）不被允许。
场景：比如某接口只允许 GET 请求，但你用 POST 请求，就会返回 405。

5. 500 Internal Server Error

含义：服务器内部错误，无法完成请求。
场景：代码异常、服务器配置错误等。

6. 504 Gateway Timeout

含义：服务器作为网关或代理，在规定时间内未从上游服务器获得响应。
场景：服务器超时，可能是后端服务响应慢或网络问题。

7. 302 Found（重定向）

含义：请求的资源临时被移动到新的 URL。
场景：访问 A 网站自动跳转到 B 网站，比如登录后跳转主页。

11. 构造HTTP请求的方式

HTML form标签
JavaScript ajax
Java Socket API

可以用postman,apifox

HTTPS

一、问题：HTTP 为什么不安全？

明文传输：HTTP 协议中的报文（请求和响应）都是未经加密的文本。就像寄送明信片，途径的所有人都可以看到内容。
信息窃听：黑客或运营商可以在网络传输的各个环节（路由器、网关等）窃听到你的通信内容，包括密码、身份证号等敏感信息。
内容篡改：攻击者可以截获并修改传输中的数据，然后再转发给服务器或客户端（例如，在下载的文件中插入病毒）。
身份冒充：你无法确认与你通信的服务器是不是真正的目标服务器，可能是黑客伪装的。

二、解决方案：加密

HTTPS 的核心就是在 HTTP 和 TCP 层之间加入了一个安全层（SSL/TLS），负责对传输数据进行加密和解密。

1. 对称加密 (Symmetric Encryption)

概念：加密和解密使用同一把密钥。
优点：速度快，效率高，适合加密大量数据。
缺点：密钥分发困难。如何安全地把密钥从客户端传递给服务器？如果在网上明文传输密钥，黑客截获后，后续的加密通信就形同虚设。

2. 非对称加密 (Asymmetric Encryption)

概念：使用一对密钥：公钥 (Public Key) 和 私钥 (Private Key) 。
- 公钥是公开的，任何人都可以获取。
- 私钥是保密的，只有服务器自己持有。
规则：
- 用公钥加密的数据，只能用对应的私钥解密。
- 用私钥加密的数据，只能用对应的公钥解密。（此用途常用于数字签名）
优点：解决了密钥分发问题。客户端可以用服务器公开的公钥加密信息，只有持有私钥的服务器才能解密。
缺点：速度非常慢，比对称加密慢上百倍甚至千倍，不适合加密所有通信内容。

三、 HTTPS 的完美方案：混合加密

HTTPS 结合了两种加密方式的优点，形成了混合加密系统。

使用非对称加密安全地交换"对称密钥"：
- 连接建立时，客户端生成一个随机的对称密钥 （称为 Session Key）。
- 客户端使用服务器的公钥加密这个对称密钥，然后发送给服务器。
- 服务器用自己的私钥解密，得到对称密钥。
- 至此，双方都安全地拥有了同一把对称密钥，且外界无法知晓。
使用对称加密高效地加密"业务数据"：
- 后续所有的通信数据，都使用这把刚刚协商好的对称密钥进行加密和解密。
- 享受了对称加密的高速度。

至此，解决了"加密"和"密钥交换"的问题。但仍然存在一个致命漏洞：中间人攻击。

四、新问题：中间人攻击 (Man-in-the-Middle Attack)

场景：黑客在客户端和服务器之间。
攻击步骤：
1. 客户端向服务器请求公钥。
2. 黑客截获这个请求，将自己的公钥发送给客户端。
3. 客户端误以为这是服务器的公钥，于是用它加密自己的对称密钥。
4. 黑客再次截获，用自己的私钥解密，就拿到了对称密钥。他还可以用服务器的真实公钥重新加密这个对称密钥，再发给服务器。
5. 从此，客户端和服务器之间的所有加密通信，黑客都可以用这把对称密钥解密、窥视甚至篡改。
根源：客户端无法验证收到的公钥到底是不是来自它想要访问的真实服务器。

五、最终解决方案：数字证书 (Digital Certificate) & CA

为了解决身份认证问题，引入了受信任的第三方机构------证书颁发机构 (CA, Certificate Authority)。

1. 证书是什么？

证书就是一个数字文件，里面包含了：

证书持有者的信息（如域名、公司名称）
证书持有者的公钥
签发者（CA）的信息
有效期
...以及其他信息
最重要的：CA 对此证书内容的数字签名

2. 数字签名的工作原理（防篡改核心）

签发过程（CA做的事）：
1. CA 对证书的所有明文信息 进行 Hash 运算 ，得到一个摘要（独一无二的指纹）。
2. CA 使用自己的私钥对这个摘要进行加密，得到的结果就是数字签名。
3. 将数字签名和证书明文信息一起打包成最终的数字证书。
验证过程（客户端浏览器做的事）：
1. 客户端收到证书后，使用同样的 Hash 算法对证书中的明文信息进行计算，得到摘要 A。
2. 客户端使用内置的操作系统/浏览器预装的CA公钥，去解密证书中的数字签名，得到摘要 B。（如果能成功解密，说明此证书由该CA签发）
3. 比较摘要 A 和摘要 B：
  - 如果 A == B ，证明证书内容完整且未被篡改，公钥是可信的。
  - 如果 A != B ，证明证书已被篡改，浏览器会发出安全警告。

3. 如何避免中间人攻击？

黑客无法实施攻击，因为：

他无法篡改证书内容（否则Hash值对不上）。
他无法伪造CA的签名（因为他没有CA的私钥）。
他无法使用自己的证书冒充真实网站（因为客户端浏览器没有预装他的"假CA"的公钥，无法验证通过）。

六、总结：HTTPS 完整工作流程

TCP 三次握手建立连接。
SSL/TLS 握手 ：
- 客户端发送 Client Hello（支持的加密套件等）。
- 服务器回应 Server Hello（选定的加密套件）并发送自己的数字证书。
- 客户端验证证书的合法性（颁发机构、有效期、域名、签名等）。
- 验证通过后，客户端生成随机对称密钥 ，用证书中的服务器公钥加密它，发送给服务器。
- 服务器用私钥解密，得到对称密钥。
安全通信 ：双方使用协商好的对称密钥对所有HTTP通信内容进行加密和解密。
关闭连接。

关于 Fiddler/Charles 等抓包工具

这些工具能抓取HTTPS包，原理就是它们在你的设备上扮演了一个"受信任的"中间人。

你主动安装了它们的根证书，相当于你的电脑信任了它们自己创建的"假CA"。
抓包时，工具会动态生成目标网站的假证书，并用自己的私钥签名。
由于你的电脑信任了它，验证会通过，工具就能解密你的通信内容。
这恰恰证明了HTTPS的安全性：除非用户主动信任某个"恶意CA"，否则中间人攻击无法成功。

好的，这是一道非常经典的面试题，考察的是对计算机系统（尤其是网络、前端、后端）整体知识的理解。下面我将你提供的思路进行扩充和细化，整理成一份结构清晰、内容详实的笔记。

面试题：从输入 URL 到页面展示，发生了什么？

总体概览

整个过程可以大致分为以下几个阶段：

URL 解析：分析网址含义。
DNS 解析：将域名转换为 IP 地址。
建立连接：通过 TCP 三次握手与服务器建立可靠连接。
安全握手：如果是 HTTPS，进行 TLS 握手以建立安全连接。
发送请求：浏览器构造并发送 HTTP 请求。
服务器处理：服务器处理请求并生成响应。
接收响应：浏览器接收服务器返回的 HTTP 响应。
解析渲染：浏览器解析 HTML、CSS，加载资源，执行 JS，最终渲染页面。
连接终止：完成数据传输后，通过四次挥手关闭 TCP 连接。

一、网络原理视角 (核心)

1. URL 解析

浏览器解析你输入的 URL，例如 https://www.example.com/index.html。
提取出协议 (https)、主机名 (www.example.com)、端口 (隐式 443)、路径 (/index.html) 等信息。

2. DNS 解析 (域名 -> IP 地址)

浏览器检查本地缓存（浏览器缓存、操作系统缓存）是否有该域名对应的 IP。
如果没有，则向本地配置的 DNS 服务器（通常由运营商提供）发起查询。
DNS 查询是一个递归过程，可能涉及根域名服务器、顶级域服务器（.com）、权威域名服务器，最终获取到目标域名的 IP 地址。

3. 建立 TCP 连接 (三次握手)

拿到 IP 地址后，浏览器通过操作系统内核的网络协议栈发起 TCP 连接。
三次握手 ：
- 客户端 -> 服务器：发送 SYN 包 (seq=x)。
- 服务器 -> 客户端：发送 SYN-ACK 包 (seq=y, ack=x+1)。
- 客户端 -> 服务器：发送 ACK 包 (seq=x+1, ack=y+1)。
握手成功后，建立了一条可靠的、面向连接的双向通信通道。

4. TLS 握手 (仅 HTTPS)

由于是 HTTPS，在发送 HTTP 数据前，需先进行 TLS 握手以建立安全层。
关键步骤 ：
- 客户端发送 Client Hello（支持的 TLS 版本、加密套件等）。
- 服务器回应 Server Hello（选择的版本和套件）并发送其数字证书。
- 客户端验证证书的合法性（颁发机构、有效期、域名匹配性、数字签名）。
- 验证通过后，客户端生成预主密钥，用服务器公钥加密后发送。
- 双方根据预主密钥生成相同的会话密钥（对称加密密钥）。
此后，所有应用层数据都将使用此会话密钥进行加密传输。

5. 发送 HTTP 请求

安全通道建立后，浏览器开始构造 HTTP 请求报文。
请求行 ：GET /index.html HTTP/1.1
请求头 ：包含大量信息，如：
- Host: www.example.com
- User-Agent (浏览器身份)
- Accept (可接受的响应类型)
- Cookie (携带本地cookie)
- Authorization (认证信息)
请求体：对于 POST 等请求，会包含发送的数据（如表单数据、JSON等）。

6. 服务器处理与返回响应

请求报文通过网络协议栈（IP层处理路由、数据链路层封装成帧）传输到服务器。
服务器网络栈拆包，将 HTTP 请求交给Web服务器软件（如 Nginx）。
Web服务器可能将请求反向代理 或负载均衡到后端的应用服务器（如 Tomcat + Spring）。
应用服务器根据 URL 路径匹配控制器 ，执行业务逻辑（如查询数据库、调用其他服务）。
处理完毕后，生成 HTTP 响应报文。
状态行 ：HTTP/1.1 200 OK
响应头 ：
- Content-Type: text/html (响应体类型)
- Content-Length (响应体长度)
- Set-Cookie (设置Cookie)
响应体：通常是请求的 HTML 文件内容。

7. 浏览器接收响应

浏览器收到响应报文。
首先检查 HTTP 状态码（如 200 成功，304 缓存，404 未找到，500 服务器错误）。
然后根据 Content-Type 决定如何處理响应体。

8. 关闭连接 (四次挥手)

默认 HTTP/1.1 下是 Connection: keep-alive，连接会保持一段时间以供后续请求复用，减少握手开销。
最终数据传输完毕，通过 TCP 四次挥手优雅地关闭连接。

二、服务器后端开发视角

1. Web 服务器层 (Nginx)

反向代理：接收客户端请求，并根据配置转发到内部的一台或多台应用服务器。
负载均衡：使用算法（轮询、权重、IP Hash）将请求分发给不同的应用服务器实例，避免单点过载。
处理静态资源：直接返回 HTML、CSS、JS、图片等文件，减轻应用服务器压力。

2. 应用服务器层 (Tomcat + Spring)

DispatcherServlet ：Spring MVC 的核心，接收所有请求，并根据 URL 映射到对应的 @Controller。
执行业务逻辑 ：
- 服务发现 & RPC调用：在微服务架构中，通过注册中心（Nacos, Eureka）找到其他服务，并通过 RPC（如 Dubbo, Feign）进行调用。
- 数据持久化 ：通过 ORM 框架（MyBatis, JPA）操作数据库（MySQL），执行 CRUD。
- 缓存：查询 Redis 提升性能，减轻数据库压力。
- 消息队列 ：将耗时操作异步化，发送消息到 MQ（RabbitMQ, Kafka）由其他服务处理。
渲染视图：处理完成后，将数据模型填充到模板中（如 Thymeleaf）生成 HTML，或直接返回 JSON/XML 数据（前后端分离架构）。

3. 定义 API 接口

后端负责设计和提供** RESTful API** 接口，明确请求方法（GET/POST）、URL、参数、响应格式（JSON），并与前端工程师协作。

三、网页前端开发视角

站在网页前端开发的角度（前端工程师关注的）

HTTP 请求是怎样在浏览器中构造的

拿到的 HTTP 响应怎样被浏览器解析的

如何对上述过程进一步进行优化......

搭配上一些 Vue 这样的框架~~~

总结回答技巧

总-分-总结构：

总述："这是一个非常复杂的过程，涉及网络、后端、前端等多个层面。我主要从网络原理的角度来描述......"
分述：按照上述流程，清晰地讲出 DNS -> TCP -> TLS -> HTTP -> 响应 -> 解析渲染 这条主线。可以重点突出你最熟悉的点（如 HTTPS 原理、TCP 机制、渲染流程）。
总结："最后，当用户与页面交互时，还可能触发新的 AJAX 请求和局部更新，整个过程大致就是这样。"

文章目录

HTTP

1. HTTP 协议简介

2. HTTP 报文格式

2.1 抓包工具与 HTTP 报文观察

1. 抓包原理

2. 常见抓包工具

3. 使用 Fiddler 抓包注意事项

3. HTTP 请求与响应的基本格式详解

一、HTTP 是什么？

二、发送 HTTP 请求与接收响应过程

三、HTTP 请求报文结构

四、HTTP 响应报文结构

4. URL

1. URL 与 URI

2. URL 格式结构详解

3. 查询字符串（Query String）

4. URL 编码（url encode）

5. 日常开发注意事项

6. 重点关注的 URL 部分

5. HTTP 的方法（Method）

1. 基本概念

2. GET 方法

3. POST 方法

4. GET 和 POST 的区别（经典面试题）

5. 浏览器缓存与强制刷新

6. 访问一个网页的过程

7. POST 请求举例

6. 请求报头常见字段

7. User-Agent（简称 UA）

1. 什么是 User-Agent

2. UA 字段示例

3. UA 的常见用途

1）判定浏览器和操作系统

2）判断功能支持

3）数据统计与分析

4）区分 PC 和移动端

4. 日常开发中的应用

8. Referer

Referer 的作用

9. Cookie

1. 什么是 Cookie？

2. Cookie 的工作流程

3. Cookie 的特点

4. Cookie 的典型应用场景

5. Cookie 的局限与替代方案

6. 总结

10. HTTP 状态码

1. 200 OK

2. 404 Not Found

3. 403 Forbidden

4. 405 Method Not Allowed

5. 500 Internal Server Error

6. 504 Gateway Timeout

7. 302 Found（重定向）

11. 构造HTTP请求的方式

HTTPS

一、 问题：HTTP 为什么不安全？

二、 解决方案：加密

1. 对称加密 (Symmetric Encryption)

2. 非对称加密 (Asymmetric Encryption)

三、 HTTPS 的完美方案：混合加密

四、 新问题：中间人攻击 (Man-in-the-Middle Attack)

五、 最终解决方案：数字证书 (Digital Certificate) & CA

1. 证书是什么？

2. 数字签名的工作原理（防篡改核心）

3. 如何避免中间人攻击？

六、 总结：HTTPS 完整工作流程

关于 Fiddler/Charles 等抓包工具

面试题：从输入 URL 到页面展示，发生了什么？

总体概览

一、 网络原理视角 (核心)

1. URL 解析

2. DNS 解析 (域名 -> IP 地址)

3. 建立 TCP 连接 (三次握手)

4. TLS 握手 (仅 HTTPS)

5. 发送 HTTP 请求

6. 服务器处理与返回响应

7. 浏览器接收响应

一、问题：HTTP 为什么不安全？

二、解决方案：加密

四、新问题：中间人攻击 (Man-in-the-Middle Attack)

五、最终解决方案：数字证书 (Digital Certificate) & CA

六、总结：HTTPS 完整工作流程

一、网络原理视角 (核心)

二、服务器后端开发视角

三、网页前端开发视角