HTTP 长连接

上周再做一个easyproxy的小项目，实现代码反向代理的工作，具体就是在tcp层对各个请求（只要遵循建立在tcp层之上的协议即可）进行解析，然后分发各个具体服务上。

这中间遇到的一个问题就是HTTP中的长连接问题，重新去看了下具体的http协议，发现之前对这块知识还是存在盲点。

这篇文章可以算是自己的学习笔记， 很多内容更是直接使用我看到和觉得讲得不错的资料，希望对大家也有所帮助。

基础知识

 1. 名称

 维基百科中的介绍：

“HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair.”

讲这个，是因为我觉得“长连接”这个称呼并不是非常准确，用“持久连接”，而“Long Connection”这种直接翻译词就更不用再用了。但毕竟这个名字已经沿用这么久了，我们也就继续用这个名

2. 原理

在HTTP协议中长连接中同一个TCP连接来发送和接收多个HTTP请求/应答，而不是为每一个新的请求/应答打开新的连接的方法。

下图是网上一张很形象讲解普通连接和长连接区别的图

从图中，我们就能清晰地看到，两者区别就是长连接会“复用”原先建立TCP连接

3. 实现

在 HTTP 1.0 中

没有官方的 keepalive 的操作。通常是在现有协议上添加一个指数。如果浏览器支持 keep-alive，它会在请求的包头中添加：

Connection: Keep-Alive

然后当服务器收到请求，作出回应的时候，它也添加一个头在响应中：

Connection: Keep-Alive

这样做，连接就不会中断，而是保持连接。当客户端发送另一个请求时，它会使用同一个连接。这一直继续到客户端或服务器端认为会话已经结束，其中一方中断连接。

比如我用chrome访问博客园首页

request header：

 

response header：

在 HTTP 1.1 中 

所有的连接默认都是持续连接，除非特殊声明不支持。

所以现在各个浏览器的高版本基本都是支持长连接。

 

4. 优势

• 较少的CPU和内存的使用（由于同时打开的连接的减少了）
• 允许请求和应答的HTTP pipelining
• 降低网络阻塞 （TCP连接减少了）
• 减少了后续请求的延迟（无需再进行握手）
• 报告错误无需关闭TCP连接

 其实它一切的优势就在于复用了原先建立的TCP连接，减少重新建立TCP连接的消耗

5. 劣势

• 空闲的连接需要过段时间后才能被断开，可能影响整体性能（比如那些单次访问次数多的web 服务）

 

6. 浏览器 

 现在的高版本浏览器都是默认支持长连接的，而它们维护长连接的方式就是用“超时管理”。

 在一段时间内没有请求和相应时，就自动将连接断掉。

 

 

参考文章：

维基百科介绍：英文

Persistent HTTP Connections in RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1