你点开一个网页，浏览器干的协议第一件事不是渲染页面，而是协议向服务器发一串纯文本。这串文本就是协议HTTP协议在干活。它不神秘，协议本质就是协议客户端和服务器之间约定好的“说话方式”——你说什么格式，我回什么格式，协议彼此别猜。协议

拿我昨天调试的协议一个小工具举例。用curl -v https://example.com，协议终端里哗啦啦滚出一堆东西。协议最前面的协议GET / HTTP/1.1就是请求行。后面跟着Host: example.com、协议User-Agent: curl/8.4.0，协议这些叫请求头。协议服务器收到后，返回HTTP/1.1 200 OK，再附上Content-Type: text/html和一堆HTML。整个过程像寄信：信封上写清楚地址（Host）、寄件人（User-Agent），信纸里装内容。HTTP就是规定信封怎么写、回信怎么贴邮票的那套规矩。

但别以为它只管网页。现在很多手机App的后台接口、物联网设备上报数据，底层也是HTTP。我见过一个智能灯泡，调亮度居然发的是POST /api/brightness，body里塞JSON。这协议太通用了，通用到有时候显得笨重——每次请求都要带一堆头，连接用完就关，早期版本连个复用都没有。

说到版本，HTTP/1.0和1.1差别就很大。1.0默认短连接，每发一个请求就得重新握手。1.1引入了Keep-Alive，一个TCP连接上能跑多个请求。但1.1有个坑：队头阻塞。前一个请求没回来，后面的就得干等。所以后来有了HTTP/2，把请求拆成帧，多路复用。我实测过，同一张网页加载30张小图，HTTP/1.1开了6个连接，HTTP/2只开1个，时间少了三分之一。不过HTTP/2的头部压缩和二进制分帧，对普通开发者来说基本无感，浏览器和服务器自己搞定。

HTTP/3更激进，直接不用TCP了，改走QUIC（基于UDP）。为什么？因为TCP的重传机制在丢包时会把后续所有数据卡住，QUIC能独立处理每个流。这就像高速公路，TCP是单车道，前面撞车后面全堵；QUIC是多车道，各走各的。但QUIC部署麻烦，很多老防火墙直接封UDP，所以现在还没完全普及。

状态码是HTTP里最直观的部分。200成功，404找不到，500服务器炸了。但有些码容易混淆。301永久重定向，302临时重定向——做SEO的人特别在意这个，因为301会把权重传给新地址，302不会。我见过一个电商网站改版，运营图省事全用302，结果搜索引擎半年没更新索引，流量掉了一大截。还有304，表示“你本地缓存还能用”，这个码能省不少带宽。浏览器发请求时带个If-Modified-Since，服务器一看文件没变，回个304，body都不带。

方法也不止GET和POST。PUT用来上传资源，DELETE用来删，PATCH做局部更新。但很多公司偷懒，全用POST，连查询都用POST。理由是“防止URL里带参数被日志记录”。这其实违背了HTTP语义——GET应该是幂等的，POST不是。幂等的意思是，同一个请求发一次和发十次，服务器状态不变。GET、PUT、DELETE都该幂等，POST不该。但现实里，你发十次POST删订单，可能真删十次。所以设计接口时得想清楚。

HTTP本身不加密。你发出去的密码、cookie，在公网上就是明文。所以有了HTTPS，其实就是HTTP套了层TLS。TLS握手那几步——ClientHello、ServerHello、证书验证、密钥交换——比HTTP本身复杂多了。但浏览器地址栏那个小锁图标，背后就是这套东西在跑。我抓过包，HTTPS的请求内容全是乱码，HTTP的请求内容一眼就能看穿。所以现在Chrome对HTTP站点直接标“不安全”，没得商量。

最后说个细节：HTTP是无状态的。服务器不记得你上次来过。所以有了Cookie和Session。Cookie是服务器塞给浏览器的一小段文本，浏览器每次请求自动带上。Session是服务器自己存的，只给浏览器一个Session ID。但Session ID要是被偷了，别人就能冒充你。所以现在流行Token，比如JWT，把状态签在客户端，服务器不存。这又引出跨域、CORS一堆事。你看，一个简单的“说话方式”，衍生出多少麻烦和智慧。

说到底，HTTP就是互联网的普通话。不标准，但大家都得说。