2. HTTP协议基础：请求-响应模型、RESTful API、长连接与短连接、HTTP/1.1 vs HTTP/2
聊物联网协议，绕不开HTTP。很多人觉得HTTP太“重”，不适合物联网。这话对，也不对。
我个人的习惯是：先搞清楚HTTP到底能干什么，再判断它适不适合你的场景。别一上来就否定它，也别盲目崇拜它。
2.1 请求-响应模型：最朴素的对话方式
HTTP的核心，说白了就是“你问我答”。客户端发一个请求，服务器给一个响应。就这么简单。
举个例子：你的手机（客户端）想查天气，它发一个请求给服务器：“今天北京天气怎么样？”服务器查完数据库，回一句：“晴，25度。”这就是一次完整的HTTP通信。
关键点：HTTP是无状态的。服务器不会记住你上一次问了什么。每次请求都是独立的。
我在项目中遇到过一个问题：设备上报数据时，服务器处理完就忘了。下次设备再问“上次的数据处理了吗？”服务器一脸懵。嗯，这就是无状态带来的麻烦。解决办法？要么让设备自己带上下文，要么用Session或Token来维持状态。
一个典型的HTTP请求长这样：
POST /api/v1/sensor/data HTTP/1.1
Host: iot.example.com
Content-Type: application/json
Authorization: Bearer xxxxxx
{
"device_id": "sensor_01",
"temperature": 25.6,
"humidity": 60.2
}服务器响应：
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "success",
"message": "数据已接收"
}你看，一来一回，清清楚楚。但这里有个问题：如果设备数量很多，每个设备都频繁地“问一句、答一句”，服务器压力会很大。这就是为什么HTTP在物联网中常被诟病的原因之一。
2.2 RESTful API：让HTTP更有章法
光有请求和响应还不够。你得告诉别人：什么资源该用什么方式操作。RESTful API就是干这个的。
我建议你记住一个原则：用名词表示资源，用HTTP方法表示操作。
| HTTP方法 | 操作 | 示例 |
|---|---|---|
| GET | 查询资源 | GET /devices/123 |
| POST | 创建资源 | POST /devices |
| PUT | 更新资源（全量） | PUT /devices/123 |
| PATCH | 更新资源（部分） | PATCH /devices/123/temperature |
| DELETE | 删除资源 | DELETE /devices/123 |
举个例子：你想查询某个传感器的当前温度。用RESTful风格，就是：
GET /sensors/temp_01/readings/latest HTTP/1.1
Host: iot.example.com服务器返回：
HTTP/1.1 200 OK
Content-Type: application/json
{
"sensor_id": "temp_01",
"value": 25.6,
"unit": "celsius",
"timestamp": "2025-01-15T10:30:00Z"
}我的经验：在物联网中，RESTful API最适合管理面的操作，比如设备注册、配置下发、固件升级。对于数据面（高频数据上报），RESTful API就显得力不从心了。你想想看，一个传感器每秒上报一次数据，每次都走HTTP请求，那开销得多大？
2.3 长连接与短连接：别让连接成为瓶颈
HTTP早期版本（HTTP/1.0）默认是短连接。每次请求都要新建一个TCP连接，请求完就断开。这在网页浏览时代问题不大，但在物联网场景下，问题就来了。
短连接的痛点：
- 每次请求都要三次握手、四次挥手
- 大量设备频繁连接、断开，服务器资源消耗巨大
- 延迟高，不适合实时性要求高的场景
我曾经在一个项目中，用HTTP短连接管理5000个设备。结果呢？服务器CPU飙升，连接数爆表，最后不得不紧急切换到长连接方案。那次教训挺深刻的。
长连接（Keep-Alive）就聪明多了。它在HTTP/1.1中成为默认行为。多个请求复用同一个TCP连接，减少了握手开销。
关键区别：
- 短连接：一次请求一个连接，用完即弃
- 长连接：多个请求共享一个连接，保持一段时间
但长连接也不是万能的。你想想看，如果设备数量达到十万级，每个设备都维持一个长连接，服务器的内存和文件描述符会很快耗尽。这时候就需要考虑连接池、负载均衡等技术了。
2.4 HTTP/1.1 vs HTTP/2：老将与新秀
HTTP/1.1用了二十多年，稳定可靠。但它的设计初衷是网页浏览，不是物联网。HTTP/2的出现，解决了一些痛点。
| 特性 | HTTP/1.1 | HTTP/2 |
|---|---|---|
| 连接复用 | 支持（Keep-Alive） | 多路复用（一个连接并发多个请求） |
| 头部压缩 | 不支持 | HPACK压缩，减少开销 |
| 二进制协议 | 文本协议 | 二进制分帧，解析更快 |
| 服务器推送 | 不支持 | 服务器可主动推送资源 |
| 队头阻塞 | 有（一个请求阻塞，后续排队） | 无（多路复用解决） |
HTTP/1.1的队头阻塞问题：说白了就是，如果第一个请求处理慢了，后面的请求都得等着。这在物联网场景下很要命。比如你同时查询100个传感器的数据，第一个传感器响应慢了，后面99个都得排队。
HTTP/2的多路复用：一个连接上可以同时发送多个请求，互不干扰。响应也可以乱序返回，谁先准备好谁先回。这大大提升了并发效率。
注意：HTTP/2虽然好，但它在物联网中的普及度还不高。原因有几个：
- 很多嵌入式设备的内存和算力有限，跑HTTP/2的协议栈有压力
- HTTP/2依赖TLS加密，增加了握手开销
- 部分老旧设备不支持HTTP/2
我个人建议：新项目可以考虑HTTP/2，但老项目迁移要慎重。
2.5 小结：HTTP在物联网中的定位
说了这么多，HTTP到底适不适合物联网？我的看法是：
- 适合：设备管理、配置下发、固件升级、低频数据查询
- 不适合：高频数据上报、实时控制、低功耗场景
你想想看，一个智能灯泡，你每天开关几次，用HTTP完全没问题。但一个温度传感器，每秒上报一次数据，用HTTP就太浪费了。这时候，MQTT或CoAP会是更好的选择。
嗯，下一章我们就来聊聊MQTT。那个协议，才是物联网数据面的主力选手。