http长连接、长轮询的理解

昨天翻了翻《HTTP权威指南》，看到HTTP连接管理这节，书中讲到了HTTP事务，突然发现事务一词在好多场合都用到了，事务简单来说就是一连串的事情，要么都做，要么都不做，中间出了问题，整个过程都失败，对于HTTP事务就是域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源--> 浏览器对页面进行渲染呈现给用户(因为都是这样说的，所以直接从百度复制粘贴过来)。

然后讲到了串行事务和并行连接，后者是用多线程机制实现，然后讲到管道化连接，其实就是流水线，用队列机制实现，最让我印象深刻的就是Connection:keep-alive这个首部，以前看过，但总是记不住，所以昨天为了搞清楚一看就是看到凌晨3点。这个首部在HTTP1.0+中支持，默认未激活，除非客户端显式地发送这个首部，服务器知道后再决定用不用持久连接，如果服务器返回了一样的Connection:keep-alive，客户端就认为服务器开了持久连接，如果没有，客户端收到响应数据后就会关闭连接，如果想一直保持，那客户端还得每次都带上这个首部。

话说到这里，突然发现跟标题也没啥关系啊，别急，现在重点来了，以前觉得http长连接和长轮询要保持住连接应该要用这个首部，然而很显然我是错的，这个首部和长连接，长轮询没关系，这个首部只是为了减少通讯双方建立连接的开销，本质上还是一问(request)一答(response)，而且Connection: keep-alive只是是双方约定长连接、还是收完一次数据后立刻关闭套接字，简单的说就是HTTP协议的Connection: keep-alive和长连接，长轮询都是基于socket写代码写出来的，没谁一定要用谁。

再说长连接和长轮询，这两个是为了实现服务器push实现的机制，前面说到了，http是一问一答模式，客户端不发请求服务器就永远也不会响应，但是在实时通信和消息推送这样的场景完全不合理啊，服务器必须一有数据就要发给我，这样才是实时，为了解决这个问题，所以有很多服务器push技术。

长轮询不是一个真正的push技术，传统的轮询是前端ajax轮询，每隔一段时间发一个请求，服务器响应后马上关掉连接，但是这种方式明显有很大的开销，所以才有了长轮询，就是响应时间变长了，浏览器（客户端）发送一个请求，服务器hold住连接（就是循环加睡觉，可以到网上找找简单的实现代码），等有消息的时候才返回，当然浏览器的这个连接在这个过程中可以阻塞也可以异步非阻塞，ajax是异步的，等等，你说了这么多我还是不知道为什么长轮询可以当push技术用，和传统的有什么区别，这里说一下，长轮询技术要求服务器一旦发送了响应，客户端必须马上再发一个请求，这就变成了服务器是主动方，所以才说是一种伪push技术

长连接看网上的说法是在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。其实我也没看懂，毕竟没有真的实现过。

现在流行的push技术是websocket，这是一种基于HTTP协议的新协议，实现了全双工通信，websocket中不再有主动方和被动方，都是对等方，客户端和服务器可以随时互相发送数据。

瞎说一大堆，其实就是策略与机制的问题，不同应用场景利用socket的一整套api实现不同功能，但都是双方规定好才能奏效。还有一点经过本人亲身体验，纠结名词其实都是基础不行，所以想真正搞懂这些，赶快去补补基础吧，《TCP／IP详解》、《Unix网络编程：卷一》走起，多看多练！