HTTP on Leanku 的博客

Fiddler 实战：从 HTTP 抓包到接口调试

Tue, 10 Sep 2024 00:00:00 +0000

Fiddler 使用：从 HTTP 抓包到接口调试

在开发 Web、API、移动端应用时，经常会遇到：

前端请求到底发送了什么？
Token 和 Cookie 有没有正确携带？
接口为什么返回 401、403 或 500？
浏览器能访问，程序却访问失败？
如何修改请求参数重新测试？
后端接口还没开发好，前端怎么继续联调？

这类问题可以使用 Fiddler 快速定位。

Fiddler 是一款 HTTP/HTTPS 调试代理工具，可以捕获客户端与服务器之间的网络请求，并查看、修改、重放请求和响应。

目前主要有 Fiddler Classic 和 Fiddler Everywhere。Classic 主要面向 Windows，并已经进入维护阶段；Everywhere 是当前的跨平台版本。

1. Fiddler 是什么？

正常情况下：

浏览器
 ↓
Web Server
 ↓
服务器

启用 Fiddler 后：

浏览器
 ↓
Fiddler
 ↓
Web Server

Fiddler 作为代理，可以看到：

Request
├── URL
├── Method
├── Headers
├── Cookie
└── Body

Response
├── Status Code
├── Headers
└── Body

例如：

一个 HTTP 请求的并发链路：从 Web Server 到 MySQL

Wed, 10 Jul 2024 00:00:00 +0000

一个 HTTP 请求的并发链路：从 Web Server 到 MySQL

前面的文章分别讨论了并发是什么、进程线程协程如何执行请求、IO 多路复用如何管理大量连接，以及如何用 QPS、并发数和响应时间衡量系统。

但这些概念真正进入后端系统之后，会形成一条完整的链路：

Client
 ↓
Web Server / Nginx
 ↓
Application
 ↓
Process / Thread / Coroutine
 ↓
Redis / RPC / MySQL
 ↓
Response
 ↓
Client

真正的高并发问题，通常也不是发生在某一个组件上，而是发生在整个链路的容量不匹配上。

例如：

Web Server 可以接收 10000 个连接，应用可以运行 1000 个协程，但 MySQL 连接池只有 50 个连接。

这并不意味着系统只能处理 50 个 HTTP 请求，但意味着同时进行数据库操作的请求最多受到这 50 个连接的约束。

因此，理解高并发，不能只看 Web Server 或应用服务器，而要沿着一次请求完整地看下去。

1. 一个 HTTP 请求到底经过哪些组件？

假设用户访问：

理解并发：一个 HTTP 请求到后端到底发生了什么？

Mon, 10 Jun 2024 00:00:00 +0000

理解并发：一个 HTTP 请求到后端到底发生了什么？

在开发后端系统时，我们经常会看到这样的描述：

“这个接口支持 1000 并发。”

但“1000 并发”到底意味着什么？

是不是意味着服务器同时启动 1000 个线程？
是不是意味着 CPU 同时执行 1000 个请求？
如果一个请求正在等待 MySQL，CPU 又在做什么？
一个 PHP/Hyperf 服务为什么可以同时处理大量 HTTP 请求？

要真正理解高并发，不能一开始就从 QPS、限流、缓存这些概念入手，而应该先理解一个最基本的问题：

一个 HTTP 请求进入后端以后，到底发生了什么？

1. 先理解什么是并发

并发（Concurrency）描述的是：

多个任务在同一个时间段内处于进行状态，并且它们的执行过程存在交错。

并发和并行（Parallelism）不是同一个概念。

例如：

任务 A：████████
任务 B： ████████

两个任务都在进行，但可能只有一个 CPU 核心。

CPU 可以先执行 A：

A A A A

然后因为 A 正在等待 IO，转而执行 B：

A A → 等待
 ↓
 B B B B

这属于并发。

如果机器有多个 CPU 核心：

WebSocket 详解：实时双向通信是如何实现的？

Sat, 16 Sep 2023 00:00:00 +0000

WebSocket 详解：实时双向通信是如何实现的？

前面几篇分别介绍了 TCP/IP、Socket、HTTP 和 HTTPS。

到这里，一个问题自然出现了：

HTTP 已经可以完成客户端和服务器之间的通信，为什么还需要 WebSocket？

因为传统 HTTP 的基本模型是：

Client
 │
 │ Request
 ▼
Server
 │
 │ Response
 ▼
Client

如果服务器想主动通知客户端，就比较麻烦。

例如：

用户收到新消息
订单状态发生变化
股票价格发生变化
游戏状态发生变化

服务器有数据更新，但客户端没有主动发请求。

传统方案只能不断：

Client → Server：有新消息吗？
Server → Client：没有

Client → Server：有新消息吗？
Server → Client：没有

Client → Server：有新消息吗？
Server → Client：有

这就是轮询。

WebSocket 的目标就是解决这类问题：

Client ⇄ Server

建立连接之后，双方都可以主动发送数据。

RFC 6455 将 WebSocket 定义为一种基于 TCP 的双向通信协议，协议由连接建立握手和数据帧传输两部分组成。

HTTP 详解：一次请求背后发生了什么？

Tue, 01 Aug 2023 00:00:00 +0000

HTTP 详解：一次请求背后发生了什么？

在 Web 开发中，HTTP 几乎无处不在。

浏览器访问一个页面，前端调用一个 API，PHP、Java、Go 服务之间进行 RPC，下载文件，提交表单，这些场景背后都可能使用 HTTP。

但很多开发者真正理解的 HTTP 只是：

GET /users
POST /login
200 OK
Content-Type: application/json

如果继续往下追问：

浏览器输入一个 URL 后，到底发生了什么？

就会涉及 DNS、TCP、TLS、HTTP、连接复用、请求报文、响应报文、缓存等多个环节。

理解这些内容之后，很多常见问题都会变得容易：

为什么第一次请求比较慢？
为什么 HTTP/1.1 需要 Keep-Alive？
HTTP/2 为什么能够同时处理多个请求？
Cookie 和 Session 到底是什么关系？
304 是什么意思？
为什么 API 经常返回 401、403、404、409？
HTTPS 到底保护了什么？
HTTP 和 Socket、TCP 又是什么关系？

本文从一次实际请求开始，把这些概念串起来。

1. HTTP 到底是什么？

HTTP（Hypertext Transfer Protocol，超文本传输协议）是一个应用层的请求/响应协议。

它的核心模型非常简单：

Client
 │
 │ HTTP Request
 ▼
Server
 │
 │ HTTP Response
 ▼
Client

客户端发送 Request，服务端返回 Response。

HTTP 详解：一次请求背后发生了什么？

Tue, 01 Aug 2023 00:00:00 +0000

HTTP 详解：一次请求背后发生了什么？

在 Web 开发中，HTTP 几乎无处不在。

浏览器访问一个页面，前端调用一个 API，PHP、Java、Go 服务之间进行 RPC，下载文件，提交表单，这些场景背后都可能使用 HTTP。

但很多开发者真正理解的 HTTP 只是：

GET /users
POST /login
200 OK
Content-Type: application/json

如果继续往下追问：

浏览器输入一个 URL 后，到底发生了什么？

就会涉及 DNS、TCP、TLS、HTTP、连接复用、请求报文、响应报文、缓存等多个环节。

理解这些内容之后，很多常见问题都会变得容易：

为什么第一次请求比较慢？
为什么 HTTP/1.1 需要 Keep-Alive？
HTTP/2 为什么能够同时处理多个请求？
Cookie 和 Session 到底是什么关系？
304 是什么意思？
为什么 API 经常返回 401、403、404、409？
HTTPS 到底保护了什么？
HTTP 和 Socket、TCP 又是什么关系？

本文从一次实际请求开始，把这些概念串起来。

1. HTTP 到底是什么？

HTTP（Hypertext Transfer Protocol，超文本传输协议）是一个应用层的请求/响应协议。

它的核心模型非常简单：

Client
 │
 │ HTTP Request
 ▼
Server
 │
 │ HTTP Response
 ▼
Client

客户端发送 Request，服务端返回 Response。

HTTP 详解：一次请求背后发生了什么？

Tue, 01 Aug 2023 00:00:00 +0000

HTTP 详解：一次请求背后发生了什么？

在 Web 开发中，HTTP 几乎无处不在。

浏览器访问一个页面，前端调用一个 API，PHP、Java、Go 服务之间进行 RPC，下载文件，提交表单，这些场景背后都可能使用 HTTP。

但很多开发者真正理解的 HTTP 只是：

GET /users
POST /login
200 OK
Content-Type: application/json

如果继续往下追问：

浏览器输入一个 URL 后，到底发生了什么？

就会涉及 DNS、TCP、TLS、HTTP、连接复用、请求报文、响应报文、缓存等多个环节。

理解这些内容之后，很多常见问题都会变得容易：

为什么第一次请求比较慢？
为什么 HTTP/1.1 需要 Keep-Alive？
HTTP/2 为什么能够同时处理多个请求？
Cookie 和 Session 到底是什么关系？
304 是什么意思？
为什么 API 经常返回 401、403、404、409？
HTTPS 到底保护了什么？
HTTP 和 Socket、TCP 又是什么关系？

本文从一次实际请求开始，把这些概念串起来。

1. HTTP 到底是什么？

HTTP（Hypertext Transfer Protocol，超文本传输协议）是一个应用层的请求/响应协议。

它的核心模型非常简单：

Client
 │
 │ HTTP Request
 ▼
Server
 │
 │ HTTP Response
 ▼
Client

客户端发送 Request，服务端返回 Response。