HTTP1.1和HTTP1.0的高版本，允许使用已有的连接发送不同的请求，这种在连接成功后一直保持开启的连接可称为持久连接（长连接）。长连接一直保持开启状态，直到客户端发起关闭连接的请求。
4.5.1 长连接和并发连接
长连接有时比并发连接更具备优势：
降低建立http连接的资源开销和延迟，原因是不必新增连接；
保持连接状态可调整；
降低潜在的连接数；
劣势：
长连接需要精心维护，否则有可能使应有产生巨大的连接数；
开销大量本地资源；
开销大量远端客户端和服务器端资源；
长连接和并发连接同时使用才能得到更好性能，现在有不少浏览器都使用多个长连接的方式工作。
目前有两种模式：HTTP/1.0+"Keep-alive"，HTTP/1.1"persistent' 两种方式。
4.5.2 HTTP/1.0+"Keep-alive"连接
许多HTTP1.0浏览器和服务器都被升级来支持一种早期实验性长连接Keep-alive模式长连接.这种早期的长连接诟病于一些互通性的设计问题,尽管此问题已经在HTTP1.1做了修正，但仍然有很多客户端使用这种长连接。
一个长连接内的四次请求-响应交互，相比于建立四次连接的时间优势，我想再次不用多少，大家都应该知道。原因是，长连接内的四次交互回避了建立连接的开销。
4.5.3长连接操作
不赞成使用keep-alive属性，并且HTTP1.1说明文档 中已经不再描述此属性。然而，keep-alive握手在浏览器和服务端的应用中还经常被使用，因此HTTP协议的实现者必须做好准备用此属性做互动操作。
客户端要实现HTTP1.0长连接，可以通过报文头中添加Keep-Alive的属性的方式获得。
如果服务器端愿意保持这个连接的长开启状态，它将在响应报文的报文头中添加相同的属性。如果响应报文中没有此属性，那么客户端假设服务器不支持长连接，并且认为服务器在返回消息后就关闭了这个连接。
4.5.4Keep-Alive选项
要注意，keep-alive报文头支持作为保持长连接的请求，但并不意味着肯定可以获取长连接。客户端、服务器端并不需要都同意去建立一个长连接会话。他们可以在任何时间关闭空闲的长连接，并且可以无限制的控制长连接内的交互处理量。
在http报文头中，可以通过多个属性（以逗号分割）控制长连接的行为。
-timeout参数，在服务器端的响应报文中，用以预估此长连接的大概最长会话时间；
-max参数，在服务器端的响应报文中，用以预估长连接存活期大概能处理多少次交互；
-keep-alive头也可以支持一些自定义的http不会做处理的属性，用户系统检查或debug等，语法为name=[value]；
keep-alive头也是完全可以选的，只有当keep-alive参数出现在Connection属性中，才会允许长连接。
例如：
Connection:Keep-Alive
Keep-Alive:max=5,timeout=120
4.5.5Keep-Alive连接的限制和规则
Keep-Alive连接连接中有一些限制和需要明确注意的东西：
-keep-alive不是HTTP1.0默认开启的。客户端必须发送Connection:Keep-Alive请求报文头以激活长连接;
-Connection:Keep-Alive头必须和所有需要持久化交互的信息一起发出;
-在服务器端的响应报文头中如果不再有Connection:Keep-Alive，客户端必须能够识别出来;
-只有当报文体长度可以在不关闭连接的情况下就可以断定，才能保持连接长开启状态，这意味着报文体必须有一个正确的Content-length，多种载体类别，或者被分段编码。发送错误包体长度信息是非常不好的，因为这样交易的结束点就不可能探测的不准确了;
-代理和网关必须加强连接头的规则，在转发或缓存之前，代理和网关必须移除所有Connection header中的域，以及Connection header自身;
-正规的来说，keep-alive连接 不应该在不支持这种Connection header的代理服务器之间建立，以避免和dumb代理之间的交互问题,接下来会进行讲解，实际上keep-alive在实际中并不总是可用的;
-技术角度来讲,任何Connection header域(包括Connection:Keep-Alive)在被HTTP1.0设备接收后，都应该被忽略，因为，他们可能是被其他过时的代理服务器转发过来的。实际情况中，一些客户端和服务器端转变了此规则，当然这要承担来自过时代理服务器转发的风险;
-如果客户端在收到响应报文前，连接就被关闭了，那么他必须做好重复请求的准备，除非重复请求会给客户端带来不良的其他影响。
to be continue ...