3. HTTP协议与网络请求
HTTP协议，说白了就是客户端和服务器之间沟通的「通用语言」。我刚开始做数据采集那会儿，总觉得这玩意儿太基础，不就是发个请求收个响应嘛。直到有一次线上采集任务频繁超时，排查了半天才发现是请求头里少了个关键的 User-Agent，被服务器当成了爬虫直接拒绝。嗯，从那以后我再也不敢小看HTTP协议了。
咱们做数据采集与事件联动，天天都在跟HTTP打交道。你想想看，无论是从API拉数据，还是把采集到的事件推送到下游系统，本质上都是在组装HTTP请求、解析HTTP响应。所以这一章，咱们把HTTP协议的核心知识点彻底捋一遍。
核心认知：HTTP是应用层协议，它定义了客户端如何向服务器请求资源，服务器如何返回响应。数据采集的本质，就是构造合法的HTTP请求，并正确解析HTTP响应。
3.1 HTTP协议基础
HTTP（HyperText Transfer Protocol）是一种无状态的、基于请求-响应模式的协议。无状态是什么意思？就是服务器默认不记得你上一次请求干了什么。每次请求都是独立的，像两个陌生人第一次见面。
我个人习惯把HTTP通信比作「寄快递」：
- 客户端：寄件人，发起请求
- 服务器：收件人，处理请求并返回结果
- 请求报文：快递单，写明要什么资源
- 响应报文：回执单，告诉结果如何
一个完整的HTTP请求报文包含四部分：请求行、请求头、空行、请求体。响应报文也类似：状态行、响应头、空行、响应体。
// 请求报文示例
POST /api/collect/data HTTP/1.1
Host: data-collect.example.com
Content-Type: application/json
User-Agent: DataCollector/1.0
Authorization: Bearer xxxxxx
{"sensor_id": "S001", "temperature": 25.6}
// 响应报文示例
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 15 Jan 2024 10:30:00 GMT
{"status": "success", "data_id": "202401151030001"}小技巧：调试HTTP请求时，我习惯先用 curl -v 命令，它能打印出完整的请求和响应报文，比任何图形化工具都直观。
3.2 请求方法：GET/POST/PUT/DELETE
HTTP定义了多种请求方法，每种方法代表一种操作意图。做数据采集时，最常用的就是GET和POST，PUT和DELETE在事件联动场景中也会用到。
| 方法 | 语义 | 数据采集场景 | 是否携带请求体 |
|---|---|---|---|
| GET | 获取资源 | 拉取数据、查询状态 | 否 |
| POST | 创建资源 | 上报采集数据、触发事件 | 是 |
| PUT | 更新资源 | 更新采集配置、修改联动规则 | 是 |
| DELETE | 删除资源 | 取消采集任务、移除联动规则 | 通常无 |
GET请求：参数拼在URL里，比如 ?page=1&size=100。我在项目中遇到过一个问题——采集的数据量太大，URL长度超过了浏览器和服务器的限制，导致请求被截断。后来我改用POST来传参，或者把参数放在请求头里。
POST请求：数据放在请求体里，没有长度限制。这是数据采集最常用的方法。上报传感器数据、提交日志、触发告警，基本都是POST。
PUT请求：幂等的，意思是多次执行结果一样。比如更新采集器的配置，不管发多少次，最终配置都是一样的。
DELETE请求：删除资源。我曾经踩过一个坑——调用DELETE接口后，以为资源被删了，结果发现服务器只是标记了「已删除」，数据还在。所以做事件联动时，一定要确认删除操作的语义。
注意：GET请求的参数会暴露在URL中，不要用来传输敏感信息（如密码、Token）。另外，GET请求有长度限制（通常4KB-8KB），大数据量采集请用POST。
3.3 请求头与响应头
请求头和响应头，是HTTP协议里最容易被忽视但又最关键的部分。我见过太多采集任务失败，就是因为请求头没配对。
常见的请求头：
Host：目标服务器域名或IP，必须要有User-Agent：客户端标识，很多服务器会校验这个Content-Type：请求体的格式，比如application/jsonAuthorization：认证信息，Bearer Token或Basic AuthAccept：客户端期望的响应格式Cookie：会话标识，用于维持登录状态
常见的响应头：
Content-Type：响应体的格式Content-Length：响应体大小（字节）Set-Cookie：服务器要求客户端保存的CookieCache-Control：缓存策略Retry-After：限流时告诉客户端多久后重试
避坑指南：我曾经在采集某个第三方API时，一直返回403。排查了半天，发现是 User-Agent 太奇怪了（默认的Python requests库的标识），被对方防火墙拦截了。改成 Mozilla/5.0 后立刻正常。嗯，有时候装成浏览器反而更顺利。
3.4 状态码详解
状态码是服务器给客户端的「回执」，告诉你这次请求的结果。做数据采集和事件联动，必须熟记这些状态码的含义。
| 状态码 | 含义 | 采集场景说明 |
|---|---|---|
| 200 | OK，请求成功 | 数据正常返回，可以解析响应体 |
| 201 | Created，创建成功 | 数据上报成功，通常POST请求返回 |
| 204 | No Content，无内容 | 删除成功，响应体为空 |
| 301/302 | 重定向 | 请求的URL变了，需要跟进新地址 |
| 400 | Bad Request，请求格式错误 | 检查请求参数、请求体格式 |
| 401 | Unauthorized，未认证 | Token过期或无效，需要重新获取 |
| 403 | Forbidden，禁止访问 | 权限不足，检查认证信息 |
| 404 | Not Found，资源不存在 | URL写错了，或者资源已被删除 |
| 429 | Too Many Requests，请求过多 | 被限流了，需要等待 Retry-After 指定的时间 |
| 500 | Internal Server Error，服务器内部错误 | 服务器出问题了，稍后重试 |
| 502/503 | 网关错误/服务不可用 | 上游服务挂了，需要降级处理 |
重要：做数据采集时，不要只处理200。必须对429（限流）、401（认证过期）、502（服务不可用）做专门的逻辑处理。我曾经因为没处理429，导致采集程序被对方封了IP，整个采集任务停了2小时。
3.5 HTTPS与安全
HTTPS = HTTP + SSL/TLS。说白了就是在HTTP外面套了一层加密协议。做数据采集和事件联动，尤其是涉及敏感数据（用户信息、设备密钥、业务数据）时，必须使用HTTPS。
为什么需要HTTPS？
- 加密传输：防止数据在传输过程中被窃听
- 身份验证：确认你连接的是真正的服务器，不是假冒的
- 数据完整性：防止数据被篡改
证书验证流程：
- 客户端请求服务器
- 服务器返回SSL证书（包含公钥）
- 客户端验证证书是否由可信CA签发
- 验证通过后，生成对称加密密钥，用公钥加密后发给服务器
- 双方用对称密钥加密通信
个人经验：在开发环境测试时，经常遇到自签名证书导致SSL验证失败。我建议开发环境可以设置 verify=False 跳过验证，但生产环境绝对不要这么做。生产环境一定要配置正确的CA证书链。
数据采集中的HTTPS注意事项：
- 采集目标如果是HTTPS，必须验证证书有效性
- 如果采集的是内部服务，可以使用双向TLS认证（mTLS）
- 事件联动推送时，回调URL尽量使用HTTPS，防止回调数据泄露
- 证书过期会导致采集失败，建议监控证书有效期
一句话总结：HTTP是数据采集的「语言」，HTTPS是数据采集的「保险箱」。语言不通干不了活，保险箱不牢出了事兜不住。
3.6 HTTP请求与响应流程（SVG）
下面这张图，把一次完整的HTTP请求-响应流程串起来了。从客户端发起请求，到服务器返回响应，每一步都对应着咱们刚才讲的知识点。
这张图把整个流程分成了8步。从客户端构建请求报文开始，到最终提取数据结束。你想想看，任何一个环节出问题，采集任务都可能失败。比如请求头少了认证信息（401），或者服务器处理超时（504），都会导致采集异常。