关于keep-alive的几点疑惑

一、http的keep-alive与tcp的keep-alive

http keep-alive：
在一次tcp连接中可以连续发送多次数据，即可以保持一段时间的tcp连接，在这个保持的通道上有多个request、多个response。而不用每发一次数据就要重新进行三次握手连接，发完一次数据就要立即进行四次挥手释放连接。 这样可以提高性能和吞吐率。

tcp keep-alive：
为了检测tcp的连接状况。经过设定的时间之后，服务器会发出检测包去确认tcp连接是否还在。如果出现了问题就关闭连接。

小结：http的keep-alive和tcp的keep-alive是完全不同的东西。

二、request header中的http keep-alive与tcp连接

在http1.1版本之后都会默认设置connection为keep-alive，如果想要关闭这条设置，需要在头信息中更改connection为close。

但是在实际使用中，http头部有了keep-alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单。这时候虽然http头有connection: keep-alive，但不能说是长连接。所以是否用了长连接，还是得用抓包工具分析tcp流。

小结：正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。但是最终到底有没有实现keep-alive还是得看tcp流的情况。

三、http keep-alive的tcp复用与websocket长连接

http keep-alive：
http keep-alive只是一种为了达到复用tcp连接的“协商”行为，双方并没有建立正真的连接会话，服务端也可以不认可，也可以随时（在任何一次请求完成后）关闭掉。它是指在一次 TCP 连接中完成多个 http请求，但是对每个请求仍然要单独发 header，所以除了真正的数据部分外，服务器和客户端还要大量交换http header，信息交换效率很低，这样建立的“长连接”都是伪长连接。

websocket：
websocket不同，它本身就规定了是正真的、双工的长连接，两边都必须要维持住连接的状态。

小结：http协议决定了浏览器端总是主动发起方，http的服务端总是被动的接受、响应请求。http提供的长连接服务器可以不接受。而websocket协议，在连接之后，客户端、服务端是完全平等的。websocket是真正的长连接。