网络基础回顾：TCP/IP协议栈、HTTP/HTTPS协议、WebSocket协议基础
各位同学，咱们今天聊点实在的。做交易所协议分析，网络基础是绕不开的坎。我见过太多人一上来就抓包，结果看到一堆乱码直接懵了。说白了，你连数据怎么包装、怎么传输都不清楚，怎么去拆解它？
这一节，我带大家把TCP/IP、HTTP/HTTPS、WebSocket这三个核心概念捋一遍。嗯，都是老面孔了，但咱们得从交易所协议分析的角度重新审视它们。
1. TCP/IP协议栈：数据是怎么打包的？
先问个问题：你在浏览器里点一下“买入”，这条指令是怎么变成比特流，穿过网线，到达交易所服务器的？
答案就在TCP/IP四层模型里。我个人习惯把它想象成一个“俄罗斯套娃”的过程——每一层都在上一层的数据上套一个自己的头。
| 层级 | 名称 | 核心协议 | 数据单元 |
|---|---|---|---|
| 第4层 | 应用层 | HTTP、WebSocket、FTP | 消息 |
| 第3层 | 传输层 | TCP、UDP | 段 |
| 第2层 | 网络层 | IP、ICMP | 包 |
| 第1层 | 链路层 | 以太网、Wi-Fi | 帧 |
你想想看，交易所的订单数据从你的客户端出发，先被应用层封装成HTTP请求，然后传输层给它加上TCP头（包含源端口和目标端口），网络层再套上IP头（包含源IP和目标IP），最后链路层加上MAC地址，变成一串0和1发出去。
关键点：抓包时你看到的每一层头部，都是逆向分析的线索。比如TCP头的序列号，可以用来判断数据包是否重传——这在分析交易所网络延迟时非常有用。
我在项目中遇到过一个问题：某交易所的行情数据偶尔会“跳变”。后来抓包发现，是TCP重传导致的乱序。嗯，这就是基础不牢的后果。
2. HTTP/HTTPS协议：交易所的“门面”
HTTP是应用层最常用的协议。交易所的REST API，说白了就是HTTP请求的变种。你发一个POST请求到 /api/v1/order，带上你的买卖指令，服务器返回一个JSON告诉你成交结果。
但HTTP有个致命问题——它是明文传输的。你想想看，如果有人在中间截获了你的API密钥，那你的账户就危险了。所以交易所现在都用HTTPS。
HTTPS就是在HTTP外面套了一层TLS/SSL加密。我建议你至少理解这三个概念：
- 证书验证：客户端验证服务器身份，防止中间人攻击
- 对称加密：实际传输数据用的密钥，效率高
- 非对称加密：用来安全地交换对称密钥
避坑指南：我曾经在分析某交易所的HTTPS流量时，发现证书链不完整。后来确认是本地代理软件搞的鬼。所以做协议分析时，一定要确认你的抓包环境没有中间人干扰。
来看一个典型的HTTP请求头，这是交易所REST API的常见格式：
POST /api/v1/order HTTP/1.1
Host: api.exchange.com
Content-Type: application/json
X-MBX-APIKEY: your_api_key_here
Content-Length: 89
{
"symbol": "BTCUSDT",
"side": "BUY",
"type": "LIMIT",
"price": "50000.00",
"quantity": "0.01"
}注意那个 X-MBX-APIKEY 头，这是交易所用来鉴权的。如果你在抓包时看到类似的头部，基本可以确定这是交易所的API流量。
3. WebSocket协议：实时行情的“高速公路”
HTTP有个硬伤——它是“请求-响应”模式。你发一个请求，服务器回一个响应，然后连接就断了。对于实时行情来说，这太慢了。你总不能每秒轮询一次吧？
WebSocket就是为了解决这个问题而生的。它建立一条长连接，服务器可以主动推送数据给你。交易所的深度行情、成交记录，基本都是通过WebSocket推送的。
WebSocket的握手过程很有意思。它先通过HTTP升级协议：
GET /ws/btcusdt HTTP/1.1
Host: stream.exchange.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13服务器返回101状态码，表示协议切换成功。之后，双方就可以在同一个TCP连接上双向通信了。
注意：WebSocket的数据帧格式和HTTP完全不同。它有自己的帧结构，包括opcode、mask、payload length等字段。抓包时如果看到乱码，别慌，那很可能是WebSocket的二进制帧。
我记得有一次，某交易所的WebSocket行情突然断连。我抓包一看，发现是心跳包超时了。交易所要求客户端每30秒发一个ping帧，但客户端的实现有bug，发的是pong帧。嗯，这种细节，不抓包根本发现不了。
4. 三者的关系：一张图说清楚
下面这张图，是我自己画的。它展示了交易所协议栈的完整链路：
从这张图可以看得很清楚：你的程序发出的HTTP或WebSocket请求，经过TCP/IP层层封装，最终变成比特流在网络上传输。交易所服务器收到后，再一层层解包，最终交给订单引擎处理。
抓包分析，就是在“抓包分析区域”这个位置，把经过的数据全部截获下来，然后逆向拆解每一层。说白了，你就是那个“中间人”，只不过你是合法的。
核心总结：
- TCP/IP是骨架，负责数据可靠传输
- HTTP/HTTPS是门面，负责REST API的请求-响应
- WebSocket是高速公路，负责实时行情推送
- 三者缺一不可，共同构成交易所的通信体系
好了，这一节的内容就到这里。记住，基础不牢，地动山摇。下一节我们会真正动手抓包，到时候你就知道今天讲的这些有多重要了。