概要

本文主要讲解目前用于提高HTTP连接的常用手法（内容是对HTTP权威指南的总结）。要解决如何提高HTTP效率的问题我们首先要理解什么是HTTP连接，他的连接过程是怎样的，只有了解整个过程，才能找到产生效率慢的根本原因。

什么是HTTP连接

众所周知，现在的网络模型大抵是四层，从上层到下层依次是应用层，传输层，网络层，数据链路层。而我们的HTTP应用位于应用层，是基于传输层和网络层的，也就是说HTTP是建立在TCP/IP协议之上的，一个请求从上到下开始构建的时候，TCP会将数据切割，而IP会进行分组，然后再将其发送出去，所以HTTP连接的效率有一大部分取决于TCP/IP的效率。

HTTP连接过程

请求报文分装好后（由TCP/IP处理）首先会和服务器进行三次握手，握手成功后才会建立一个HTTP连接，握手这个过程就是客户端和服务端的一问一答，最后再由客户端最终确认开始连接 ，这样才算是真正的建立了HTTP连接。在一个事务结束后，通常这个连接就中断了，如果要进行另一个事务就要重新进行握手连接。这个过程往往复复，就是HTTP连接了。

影响连接效率的因素

TCP三次握手时延

每次HTTP连接的时候（实质也是TCP的连接），会如上所述进行三次握手，那如果我们要进行多个事务连接，就要进行多个事务开始前的TCP三次握手，如果我明知道要和同一个服务端进行多个事务处理的话，就没必要每次事务都要进行握手了，也就是说，只进行一次握手，然后处理多个事务，不也是很好的吗。

HTTP慢启动拥塞时延

影响HTTP连接效率除了因TCP连接特性所需要的多次握手外，还有TCP的慢启动拥塞控制，在一个连接刚连接成功的时候，并不能一次性把数据全部发完，如果数据比较大的话，一次发完会瞬间消耗网络资源，造成网络拥堵，就像堵车一样，简直是灾难。所以为了有效控制数据的爆发，会有一个流量窗口（阀门），控制着每次可传输数据的大小，由小到大，慢慢提速。这个过程就称作TCP连接的自我调谐。
因此这里自然就会造成一个问题：如果多次握手完后建立了多个连接，这些连接一开始就会很慢，因此这些连接尚未调谐，阀门尚未打开。为何我不能用最先开始建立了的连接呢（因为建立时间早，该连接早已调谐）而要自己重新建立连接呢。

TCP报文发送端傻窗综合征

在请求报文从应用层向下逐层包装并发送的过程中，原始的请求数据会在各层中按照该层的规则进行打包封装，最终发送出去。所以即便你数据很小如1kb，最终发送出去的请求也会变大如41kb。因此，如果我每次发送的数据很小很小，占最终包大小的比例超小，如这里1/41，那很明显这就照成了流量的浪费。“明明我可以把这些小数据放在一个组进行发送的，我为毛还要多次封装多次打包多次发送，我是傻X吗？？”因此该现象也被称作发送端傻窗综合征。、

HTTP事务处理

很明显，在一条请求报文发送出去之后，服务端都要进行处理（如查询，删除之类的业务操作）因此在发送出去到接受到相应报文的这段空闲时间，便是服务端的HTTP事务处理时间。如果我们有多个事务，还要等一个结束后再进行下一个事务，倘若这些事务有所关联（如，我这次的事务要用到上一个事务的结果）那还能理解，但问题是那些毫无关联的事务还要等待上一个事务的结束，这未免也太浪费大家的时间了。

效率提高的方法

针对上述问题，有Nagle算法，长连接，管道连接，并行连接等方法。

Nagle算法

实质上解决TCP报文发送端傻窗综合征，简单来说该方法就是以某种规则来缓存那些小型数据（原始请求数据和最终大小比例极小的数据），然后塞在同一个报文中再发送出去的一种解决方法，但问题是，如果这些缓存起来最终塞进同一个报文的数据后仍然比例很小，那就有问题了。该算法会一直缓存等待新的数据，直到缓存的全部数据符合某种规则（足够大）的时候才发送出去，那万一依旧很小是不是就挂起不发报文了。。然后就让服务器白等，直到超时挂断...

长连接

就是客户端和服务端通过报文的头部设置，维持一条较长的连接（一段时间或完成一定数量的事务后才断开，而不是完成一个事务断一次），也就是复用一条连接，那就比较好的解决了TCP握手时延和傻窗综合征了，因为不用重新建立连接和调谐了。但如果用不好会造成客户端和服务端的相互等待。

并行连接

顾名思义，多个事务并发进行，建立多个连接让他们的TCP握手时延和傻窗综合征产生的时延时间重叠，就像煮个鸡蛋要5分钟，那煮十个鸡蛋依旧只要五分钟一样。但如果事务过多，不加以控制会迅速建立大量连接，会消耗服务器的资源。如果网络宽带不足，不足的速度会分配到N个连接上，每个连接都会显得很慢...

管道化连接

在一个长连接中维持一个事务列表，然后在长连接中连续请求，也就是不等一个事务结束就去开始另一个事务，其实就是长连接中的并行处理。客户端这边只要维持一个缓存把每一个事务的结果存起来，最后处理就好了。但因为这管道化连接是可以自由关闭的。如果对服务端的输入连接被关闭了，就会饭返回一个严重的错误报文给客户端，然后操作系统会收到这个错误报文，根据指示删除所有的缓存...也就是说如果你之前成功结束的事务储存起来的结果..都没了..oh shit那我岂不是要再来一遍...

长连接所带来的问题

在HTTP1.0中，要建立长连接就必须在每个报文的头部带有connection:keep-alive字段，这样客户端和服务端才能建立长连接。而在HTTP1.1中长连接是默认开启的，只有报文里指定关闭时，才会关闭。
但问题是现在的网络结构越来越复杂，不再是单纯的客户端和服务端临近，而是两者之间隔着若干个HTTP网络组件，如各种代理等。如果这些代理不能识别这个头部，单纯的将带有connection头部的报文转发，这样就会产生问题：服务端不知道中间隔着代理，以为是客户端直接发送而来，于是和临近的客户端（代理）建立厂连接并发送带有connection头部的报文给客户端。客户端收到connection的报文，同样也不知道中间隔着代理，于是客户端与临建的服务端（代理）建立连接。然而转发的代理已经完成了一个是事务，关闭了对客户端和服务端的端口拒绝转发任何报文，这样客户端和服务端就造成了白白的等待直到超时，两者都把代理当做了彼此。这种问题就是哑代理盲转发所带来的问题

哑代理解决方法

一般作为一个代理都应该识别出来connection字段，并把该字段去掉处理后再进行转发，这样就能避免上述出现的问题。