对于HTTP保持网络连接的解读

一、TCP短连接与长连接的区别

（1）短连接：一般只会在client/server间传递一次读写操作。此方式常用于一点对多点通讯。C/S通信。HTTP就是使用了类似的短连接。目的：减少服务器的压力；减少资源的浪费。

（2）长连接：Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。此种方式常用于P2P通信。例如：数据库的连接用长连接，关于长连接的问题在TCP/IP详解卷一中有详细的介绍, 即TCP的保活功能。

二、心跳包

心跳包概念可以从TCP的保活功能理解，就是在客户端和服务器间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。

比如有些通信软件长时间不使用，要想知道对方的状态是在线还是离线就需要心跳包，可以定时发包收包，这个双方约定即可。

四、http无连接协议

http协议是面向无连接的协议，一次请求，一次操作，然后就结束了，是没有状态的。然后在实际应用中需要保存用户信息的时候，可以采用cookie和session这2种方式，cookie是保存在客户端， session是保存在服务器端的，个人觉得session比较安全。session的实现是服务器在内存中开辟一段内存区域，返回一个索引，即生成一个sessionid，发送到客户端，在客户端下一次发送请求的时候将sessionid键值对以cookie的方式发送即可。服务器可以配置这个时间，比如该SessionID在30分钟内有效。

客户端在登陆成功之后 ，保存SESSIONID。然后每次请求的时间带上这个SESSIONID。缺点是可能会稍微大些网络流量开销而已。

下面是一个测试的例子，抓取到的数据包：

一个结论是：HTTP实现长连接要客户端和服务端都支持长连接。

如果web服务器端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点， web服务器需要在返回给客户端HTTP头信息中发送一个Content-Length（返回信息正文的长度）头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然 后在正式写出内容之前计算它的大小无论客户端浏览器 (Internet Explorer) 还是 Web 服务器具有较低的 KeepAlive 值，它都将是限制因素。例如，如果客户端的超时值是两分钟，而 Web 服务器的超时值是一分钟，则最大超时值是一分钟。

客户端或服务器都可以是限制因素，不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

五、HTTP/1.0和HTTP/1.1的一个区别

Connectin报头有两种选择：

Connection：Closed  HTTP/1.0默认值

Connection:Keep-Alive HTTP/1.1默认值

Closed状态表示执行完请求时，服务器应关闭TCP连接，Keep-Alive状态表示执行完请求时，服务器应保持TCP连接。由于不再需要打开和关闭TCP连接，性能得到明显提高。

六、TCP和HTTP连接的不同应用

TCP的面向连接是传输层的，而HTTP的无状态则是应用层的 
传统TCP应用主要面向专用系统，这种环境中客户端的数目是有限的，意味者服务器最多开几十个服务进程修行了，而客户端与服务器需要连续地交换数据，频繁地连接和断开对两端都难以接受 
HTTP协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端（即浏览器）与服务器之间交换数据的间歇性较大（即传输具有突发性、瞬时性），并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，如果按照上面的方式则需要在服务器端开的进程和句柄数目都是不可接受的，象paranoid945所说的，大部分通道实际上会很空闲、无端占用资源。因此HTTP的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。 

 

附录：摘选自《超文本传输协议-HTTP/1.1（修订版）》

Cnnection

8.1 持久连接（Persistent Connection）。

8.1.1 目的

在没有持久连接之前，为获取每一个 URL指定的资源都必须建立了一个独立的 TCP 连接，这就加重了HTTP服务器的负担，易引起互联网的阻塞。嵌入图片与其它相关数据通常使用户在短时间内对同一服务器进行多次请求。目前针对这些性能问题的分析以及一个原型实现的结果是可以获得的[26][30]。 HTTP/1.1（RFC2068）实现的实践过程和度量展现了一个满意的结果。对其他方法也有了初步探究，如T/TCP [27]。

 HTTP持久连接有着诸多的优点：  

--- 通过建立与关闭较少的TCP连接，不仅节省了路由器与主机（客户端，服务器，代理，网关，隧道或缓存）的 CPU时间，还节省了主机用于 TCP协议控制块（TCP protocol control blocks）的内存。  

--- HTTP请求和响应能在连接上进行管线请求方式。 管线请求方式能允许客户端执行多次请求而不用等待每一个请求的响应（译注：即客户端可以发送请求而不用等待以前的请求的响应到来后再发请求），并且此时只有一个TCP连接被使用，从而提高了效率，减少了时间。  

--- 网络阻塞会被减少，这是由于减少了因 TCP连接产生的包的数量并且也由于允许 TCP有充分的时间去决定网络阻塞的状态。

--- 因为无须在创建TCP连接时的握手上耗费时间，而使后续请求的等待时间减少。

 ---HTTP改进的越来越优雅，因为报告错误不需要关闭tcp连接的代价。 将来的HTTP版本客户端可以乐观的尝试利用一个新特性，但是如果和老服务器通信时错误被报告，那么就要用旧的语义进行重新尝试。 HTTP实现应该实现持久连接。

8.1.2 总体操作

HTTP/1.1 与早期HTTP 版本的一个显著区别在于持久连接是HTTP/1.1的缺省方式。也就是说，除非另有指定，客户端总应当假定服务器会保持持久连接，即便在收到服务器的出错响应时也应如此。 持久连接提供了一种可以由客户端或服务器通知终止TCP连接的机制。利用Connection头域（14。10节）可以产生终止连接信号。一旦出现了终止连接的信号，客户端便不可再向此连接提出任何新请求。

8.1.2.1 协商（Negotiation）

除非请求里Connection头域中包含“close”连接标记（connection-token），HTTP/1.1服务器总可以认为HTTP/1.1 客户端想要维持持久连接（persistent connection）。如果服务器想在发出响应后立即关闭连接，它应当发送一个含“close”的Connection头域。

一个HTTP/1.1客户端可能期望连接一直保持开着，但这必须是基于服务器响应里是否包含一个Connection头域并且此头域里是否包含“close”。如果客户端不想再继续维持连接来发送更多请求，那么它应发送一个值为“close”的Connection头域。  

如果客户端或服务器中的任一方在Connection头域里包含“close”，那么那个请求就成为这个连接的最后一个请求。

客户端和服务器不应认为持久连接是低于 1.1的HTTP版本所拥有的，除非它被显式地指明 。19.6.2节指出了跟HTTP/1.1客户端兼容的更多信息。