1、什么是Keep-Alive模式？

我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成 之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

http 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；http 1.1中默认启用Keep-Alive，如果加入"Connection: close "，才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。

2、启用Keep-Alive的优点

从上面的分析来看，启用Keep-Alive模式肯定更高效，性能更高。因为避免了建立/释放连接的开销。

3、客户端/服务器如何判断数据大小

Http协议的请求报文和回复报文都有header和body，body就是你要获取的资源，例如一个html页面，一个jpeg图片，而header是用来做某些约定的。例如客户端与服务端商定一些传输格式，客户端先获取头部，得知一些格式信息，然后才开始读取body。

http遵循什么协议。客户端： Accept-Encoding:gzip （给我压缩一下，我用的是流量，先下载下来我再慢慢解压吧）

服务端1：Content-Encoding:null(没有Content-Encoding头。 我不给压缩，CPU没空，你爱要不要）

服务端2：Content-Encoding:gzip (给你节省流量，压缩一下）

客户端：Connection: keep-alive (大哥，咱好不容易建了个TCP连接，下次接着用）

服务端1: Connection: keep-alive （都不容易，接着用）

服务端2: Connection: close (谁跟你接着用，我们这个TCP是一次性的，下次再找我还得重新连)

http协议有哪些？http协议没有三次握手，一般客户端向服务端请求资源时，以服务端为准。还有一些header并没有协商的过程，而是服务端直接告诉客户端按什么来。例如上述的Content-Length，是服务端告诉客户端body的大小有多大。但是！服务端并不一定能准确的提前告诉你body有多大。服务端要先写header，再写body，如果要在header里把body大小写进去，就得提前知道body大小。如果这个body是动态生成的，服务端先生成完，再开始写header，这样需要很多额外的开销，所以header里不一定有content-length。

那客户端怎么知道body的大小呢？服务器有三种方式告诉你。

1.服务器已经知道资源大小，通过content-length这个header告诉你。

Content-Length:1076(body的大小是1076B，你读取1076B就可以完成任务了）
Transfer-Encoding: null

2.服务器没法提前知道资源的大小，或者不愿意花费资源提前计算资源大小，就会把http回复报文中加一个header叫Transfer-Encoding:chunked，就是分块传输的意思。每一块都使用固定的格式，前边是块的大小，后面是数据，然后最后一块大小是0。这样客户端解析的时候就需要注意去掉一些无用的字段。

Content-Length:null
Transfer-Encoding:chunked (接下来的body我要一块一块的传，每一块开始是这一块的大小，等我传到大小为0的块时，就没了）

3.服务器不知道资源的大小，同时也不支持chunked的传输模式，那么就既没有content-length头，也没有transfer-encoding头，这种情况下必须使用短连接，以连接结束来标示数据传输结束，传输结束就能知道大小了。这时候服务器返回的header里Connection一定是close。

Content-Length:nullTransfer-Encoding:nullConnection:close(我不知道大小，我也用不了chunked，啥时候我关了tcp连接，就说明传输结束了）

总结

一个好的http客户端，必须充分实现协议，不然就可能出问题，浏览器对于服务端可能产生的各种情况都很好的做了处理，但是自己实现http协议的解析时一定得注意考虑多种情况。