HTTP持久连接

一些影响HTTP时延的机制

延迟确认

为了确保数据的正确传输，TCP协议实现了确认机制。接收端每次成功收到请求后，都会返回一个确认分组，由于确认分组较小，一般这个确认分组会和返回报文放在一起。很多TCP协议栈都实现了一个“延迟确认”的功能，就是把多个确认分组攒起来，过100ms~200ms再发送过去。这样对于HTTP请求就会有个问题：HTTP请求是一个双峰值的请求，一旦响应返回之后，就会有较长时间没有TCP分组返回，于是延迟确认就会找不到搭载分组。最终或将确认信息放到单独的分组中传送，提高了时延。

Nagle算法

因为TCP头本身至少有40字节的首部，如果在一个TCP单元中只携带很少的内容，那么对带宽无疑就是一种浪费了。Nagle算法是将TCP包数据积攒和合并发送的算法。这个算法对于HTTP协议来说却有问题：很可能一个request内容不够塞满一个TCP包，Nagle算法则会一直等待包填充满再发送。这样会造成时延。解决方法就是参数TCP_NODELAY。

HTTP 持久连接（keep-alive）

HTTP keep-alive从HTTP 1.0开始被引入，因为HTTP是无状态的，HTTP又基于TCP协议，TCP协议在建立新连接时，存在三次握手时延、TCP慢启动等问题，新建一个TCP连接的时延会较大，需要复用该连接，于是keep-alive就成了事实标准，最终加入到了HTTP1.0规范中。keep-alive的意思是，在浏览同一站点的页面时，复用这个连接。持久化连接还可以提供管道化请求和响应(就是一下发多次，收多个)的支持。

在HTTP1.1之后，连接默认都是持久的，事务处理后将连接关闭，需要在connction头里声明close。

Apache中KeepAlive参数设置

# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
# 设置开启或关闭持久连接
KeepAlive Off

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
# 最大持久连接请求数
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
# 持久连接超时时间，单位秒
KeepAliveTimeout 15

盲中继（哑代理）

只是简单地将字节从一个连接转发到另一个连接中，不对内容进行任何处理。

Netscape及现代浏览器的解决方法是在connection上写入Proxy-Connection，如果不懂的代理转发了它，服务器端不会建立持久连接，则不会有影响；如果懂的代理，能够支持keep-alive属性，那么会把keep-alive属性写入Connection中。