HTTP权威指南-连接部分

http://my.oschina.net/flashsword/blog/80036

最近买了一本《Http权威指南》，读了之后收获不少。把每章的读书心得都记下来，免得忘记，同时也可以分享一下。

HTTP keep-alive

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

官方文档 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

在HTTP1.1之后，连接默认都是持久的，除非在connction头里声明close。(待确认，RFC确实是这样写的，但是事实标准需要测试)

盲中继和哑代理

作为一个HTTP代理，盲中继就是不管HTTP报文内容是什么，都进行转发。但是转发Connection头时，如果带有keep-alive属性，那么代理并不会理解keep-alive的意思，在进行完一次事务(request-response)后，代理会将连接关闭。而此时，客户端和服务端都以为持久化连接已经建立了，还在傻傻的等着继续的发送，这个代理就“哑”了。

Netscape的解决方法是在头上写入Proxy-Connection，如果不懂的代理转发了它，则不会有影响；如果懂的代理，能够支持keep-alive属性，那么会把Proxy-Connection属性写入Connection中。这一属性目前仍在使用，使用Chrome测试了几个HTTP请求，request头中的字段都是Proxy-Connection: keep-alive，而response头中的字段都是Connection: keep-alive。其实可以想到，服务端返回response的时候，很可能也是返回的Proxy-Connection: keep-alive，而经过了某个代理的转换后，客户端拿到的就是Connection: keep-alive了。

一些影响HTTP时延的机制

延迟确认

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

Nagle算法

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