用Python代码透视HTTP连接：持续与非持续连接的实战对比

当翻开谢希仁教授的《计算机网络》教材时，许多同学会在"持续连接"与"非持续连接"的概念前陷入困惑。抽象的文字描述和公式计算往往难以形成直观理解，而实际上，通过简单的Python代码实验，我们就能让这些概念变得触手可及。

1. 实验环境搭建

在开始之前，我们需要准备一个本地测试环境。这个环境将模拟Web服务器响应不同HTTP连接方式的行为。我们将使用Python的Flask框架来创建这个微型服务器。

from flask import Flask, Response
import time

app = Flask(__name__)

@app.route('/image/<int:num>')
def get_image(num):
    time.sleep(0.1)  # 模拟网络延迟
    return Response(f"Image {num} data", mimetype='text/plain')

if __name__ == '__main__':
    app.run(threaded=True)

这个简单的服务器定义了10个端点（/image/1到/image/10），每个端点模拟返回一个小图片，并人为添加了100毫秒的延迟来模拟真实网络环境。

关键工具准备：

• Python 3.6+
• requests库（ pip install requests ）
• Flask框架（ pip install flask ）

2. 非持续连接模拟实现

非持续连接（HTTP/1.0默认方式）的特点是每个请求都需要建立新的TCP连接，请求完成后立即断开。我们先用最直观的方式实现串行请求：

import requests
import time

def non_persistent_sequential(url, num_requests):
    start = time.time()
    for i in range(1, num_requests + 1):
        response = requests.get(f"{url}/image/{i}")
        print(f"Received: {response.text}")
    return time.time() - start

base_url = "http://localhost:5000"
time_taken = non_persistent_sequential(base_url, 3)
print(f"Sequential non-persistent took {time_taken:.2f} seconds")

执行这段代码，你会发现总耗时大约是请求数量的线性倍数。这是因为：

1. 每个请求都需要完成TCP三次握手
2. 每个请求独立传输HTTP头部
3. 服务器需要为每个请求分配新的资源

提示：在实际测试中，你会发现时间并非严格的0.3秒，这是因为TCP连接的建立和关闭也需要时间，这个开销在真实网络中更为明显。

3. 并行TCP连接实现

现代浏览器通常会为同一个域名打开多个TCP连接（通常是6个）来并行下载资源。我们可以用Python的线程池来模拟这种行为：

from concurrent.futures import ThreadPoolExecutor

def parallel_non_persistent(url, num_requests, max_workers=3):
    start = time.time()
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        futures = [executor.submit(requests.get, f"{url}/image/{i}") 
                  for i in range(1, num_requests + 1)]
        for future in futures:
            print(f"Received: {future.result().text}")
    return time.time() - start

time_taken = parallel_non_persistent(base_url, 3)
print(f"Parallel non-persistent took {time_taken:.2f} seconds")

这种方式的性能提升显而易见，但也存在明显缺点：

• 每个连接仍然需要独立的TCP握手过程
• 服务器需要维护多个连接状态
• 浏览器通常限制每个域名的最大并行连接数

4. HTTP/1.1持续连接实现

HTTP/1.1引入了持续连接（默认启用）和流水线机制，允许在同一个TCP连接上发送多个请求。requests库的Session对象会自动处理连接复用：

def persistent_pipelined(url, num_requests):
    start = time.time()
    with requests.Session() as session:
        for i in range(1, num_requests + 1):
            response = session.get(f"{url}/image/{i}")
            print(f"Received: {response.text}")
    return time.time() - start

time_taken = persistent_pipelined(base_url, 3)
print(f"Persistent pipelined took {time_taken:.2f} seconds")

三种方式性能对比表：

从表中可以看出，持续连接在减少TCP握手开销的同时，避免了并行连接的资源消耗，是一种平衡的方案。

5. 深入理解连接管理

通过上述实验，我们可以更直观地理解教材中的几个关键概念：

1. RTT(往返时间)的影响 ：每次TCP握手都需要至少1个RTT，持续连接大大减少了这部分开销

2. 队头阻塞问题 ：即使使用持续连接，HTTP/1.1的请求仍需按顺序处理，这也是HTTP/2引入多路复用的原因

3. 连接开销对比 ：

   • 非持续连接：高延迟，高服务器负载
   • 并行非持续：降低延迟，但增加服务器负担
   • 持续连接：平衡方案，但存在队头阻塞

# 更精确的计时器实现
class RequestTimer:
    def __init__(self, url):
        self.url = url
        self.timings = []
    
    def make_request(self, i):
        start = time.time()
        response = requests.get(f"{self.url}/image/{i}")
        elapsed = time.time() - start
        self.timings.append(elapsed)
        return response

这个增强版的计时器可以帮助我们更精确地测量每个请求的实际耗时，从而更细致地分析不同连接策略的性能特征。