HTTP协议详解：从基础到Python服务器实现

1. HTTP协议基础认知

HTTP（HyperText Transfer Protocol）作为Web通信的基石协议，本质上是一种无状态的请求-响应协议。我在第一次接触HTTP时，最困惑的就是这个"无状态"特性——服务器不会记住之前的请求，每个请求都是独立的。这就像去银行柜台办理业务，柜员每次都会要求你重新出示身份证，哪怕你一分钟前刚给他看过。

协议的基本交互流程可以概括为：

1. 客户端建立TCP连接（通常是80端口）
2. 发送ASCII文本格式的请求报文
3. 等待服务器返回响应报文
4. 关闭连接（HTTP/1.0）或保持连接复用（HTTP/1.1+）

关键点：HTTP/1.1默认启用持久连接（Connection: keep-alive），这是与早期版本的重要区别。我在实际抓包分析时发现，现代浏览器对单个域名通常会建立6个并行的TCP连接来提高吞吐量。

2. 协议报文结构解析

2.1 请求报文解剖

一个典型的GET请求如下：

code复制GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

• 起始行包含：方法(GET) + URI(/index.html) + 版本(HTTP/1.1)
• 头部字段每行一个键值对，以冒号分隔
• 空行表示头部结束
• 可选的消息体（GET通常没有）

我在调试API时经常遇到的坑是Host头字段——当使用IP直接访问时，必须正确设置Host头，否则服务器可能返回400错误。这就像寄信不写收件人地址，邮局自然无法投递。

2.2 响应报文示例

服务器响应示例：

code复制HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

• 状态行包含：版本 + 状态码(200) + 原因短语(OK)
• 头部字段格式与请求相同
• 空行后是响应正文

注意：Content-Length必须准确对应body字节数。我曾遇到过一个故障案例：Nginx配置错误导致Content-Length计算错误，结果客户端一直等待接收剩余数据，最终超时。