计算机网络自顶向下方法7——应用层 HTTP概述及其连接方式
HTTP协议深度解析（一）：概述与连接管理
本文深入解析HTTP协议的基本原理，重点探讨持续连接与非持续连接的工作机制与性能影响。
一、HTTP概述：Web的通信基石
1. HTTP是什么？
超文本传输协议是Web应用层协议，它是Web的核心。
客户端-服务器模型：浏览器(客户端)向Web服务器请求资源，服务器响应资源
无状态协议：服务器不保存任何客户端的状态信息
使用TCP传输：默认端口80，提供可靠的数据传输
请求-响应模式：总是由客户端发起请求，服务器返回响应
2. HTTP报文流
浏览器进程 Web服务器进程| ||---HTTP请求报文----->|| ||<---HTTP响应报文-----|| |关键理解：HTTP报文是在HTTP客户端和服务器进程之间交换的数据，而TCP连接是在客户端和服务器主机的传输层之间建立的。
二、非持续连接：HTTP/1.0的默认方式
1. 工作原理
在非持续连接中，每个请求/响应对都通过一个单独的TCP连接发送。
获取包含3个图片的网页流程：
时间轴： 1. 客户端 → SYN → 服务器 2. 客户端 ← SYN+ACK ← 服务器 3. 客户端 → ACK+HTTP请求(HTML) → 服务器 4. 客户端 ← HTTP响应(HTML) ← 服务器 5. 客户端 × 关闭TCP连接 × 服务器6. 客户端 → SYN → 服务器 7. 客户端 ← SYN+ACK ← 服务器 8. 客户端 → ACK+HTTP请求(图片1) → 服务器 9. 客户端 ← HTTP响应(图片1) ← 服务器 10. 客户端 × 关闭TCP连接 × 服务器...（为每个图片重复6-10步骤）
2. RTT的精确分析
TCP三次握手与HTTP请求的时序应该是：
时间线： 0ms 客户端 → SYN → 服务器 100ms 客户端 ← SYN+ACK ← 服务器 (1个RTT) 100ms 客户端 → ACK+HTTP请求 → 服务器 (捎带确认) 200ms 客户端 ← HTTP响应 ← 服务器 (2个RTT完成)
关键理解：
第1个RTT：用于SYN和SYN+ACK（握手的前两次）
第2个RTT：ACK捎带HTTP请求，服务器返回HTTP响应
总共需要2个RTT来获取一个对象
3. 精确的RTT计算
假设：
RTT = 100ms
HTML文件传输时间 = 50ms
每个图片传输时间 = 30ms
TCP连接建立 = 2个RTT（包括请求和响应）
TCP连接关闭时间忽略
获取HTML页面：
连接建立 + 请求响应 = 2个RTT = 200ms
加上HTML传输时间 = 200ms + 50ms = 250ms
获取每个图片：
每个图片都需要新的TCP连接 = 2个RTT = 200ms
加上图片传输时间 = 200ms + 30ms = 230ms
总时间 = 250ms + 3×230ms = 940ms
三、持续连接：HTTP/1.1的改进
1. 工作原理
在持续连接中，服务器在发送响应后保持TCP连接打开，后续对相同服务器的请求和响应可以通过相同的连接进行。
获取包含3个图片的网页流程：
时间轴： 1. 客户端 → SYN → 服务器 2. 客户端 ← SYN+ACK ← 服务器 3. 客户端 → ACK+HTTP请求(HTML) → 服务器 4. 客户端 ← HTTP响应(HTML) ← 服务器 (2个RTT完成HTML)5. 客户端 → HTTP请求(图片1) → 服务器 6. 客户端 ← HTTP响应(图片1) ← 服务器 (1个RTT)7. 客户端 → HTTP请求(图片2) → 服务器 8. 客户端 ← HTTP响应(图片2) ← 服务器 (1个RTT)9. 客户端 → HTTP请求(图片3) → 服务器 10. 客户端 ← HTTP响应(图片3) ← 服务器 (1个RTT)
2. 精确的RTT计算
总时间：
HTML页面：2个RTT + 传输时间 = 200ms + 50ms = 250ms
3个图片：3个RTT + 传输时间 = 3×100ms + 3×30ms = 300ms + 90ms = 390ms
总计 = 250ms + 390ms = 640ms
性能提升：(940-640)/940 ≈ 31.9%
四、技术细节深度解析
1. TCP三次握手与HTTP请求的时序优化
关键机制：捎带确认
客户端在第三次握手的ACK报文段中携带第一个HTTP请求
这避免了额外的RTT，使得第一个请求能在2个RTT内完成
2. 持续连接的实现机制
// HTTP/1.1默认就是持续连接，如需关闭要显式声明 Connection: close// 控制持久连接参数 Keep-Alive: timeout=5, max=1000
3. 管道化技术的限制
虽然HTTP/1.1支持管道化，但由于队头阻塞问题，实际使用有限：
如果请求1处理慢，请求2、3的响应会被阻塞
这导致现代浏览器通常禁用管道化
五、从理论到实践的演进
HTTP/1.1的实际优化策略：
域名分片：将资源分布到不同域名，绕过6个连接的限制
资源合并：将多个小文件合并减少请求数
预连接：浏览器预先建立到重要域名的TCP连接
HTTP/2的根本性改进：
多路复用：彻底解决队头阻塞，单个连接上并行传输
头部压缩：HPACK算法消除冗余头部
服务器推送：服务器主动推送关键资源
总结
精确的RTT分析应该是：
非持续连接：每个对象需要2个RTT
持续连接：第一个对象2个RTT，后续对象每个1个RTT
持续连接通过复用TCP连接，显著减少了建立连接的RTT开销，这是HTTP/1.1相比HTTP/1.0的核心性能改进。