HTTP

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 前面的文章分别讨论了并发是什么、进程线程协程如何执行请求、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 请求到底经过哪些组件？ 假设用户访问： GET /api/orders/10001 一个典型后端系统可能经过： ┌──────────┐ │ Client │ └────┬─────┘ │ HTTP ▼ ┌──────────────┐ │ Nginx / Web │ │ Server │ └──────┬───────┘ │ ▼ ┌──────────────────┐ │ Application │ │ Hyperf / Java....

理解并发：一个 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 核心： CPU Core 1：A A A A CPU Core 2：B B B B 两个任务可以在同一时刻真正执行，这才是并行。...

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 的双向通信协议，协议由连接建立握手和数据帧传输两部分组成。 1. WebSocket 到底是什么？ WebSocket 是一个应用层通信协议。 它建立在 TCP 之上：...

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。...