刨根问底HTTP和WebSocket协议

消息体长度的确定有一下几个规则，它们顺序执行：

1. 所有不应该返回内容的Response消息都不应该带有任何的消息体，消息会在第一个空行就被认为是终止了。
2. 如果消息头含有Transfer-Encoding，且它的值不是identity，那么消息体的长度会使用chunked方式解码来确定，直到连接终止。
3. 如果消息头中有Content-Length，那么它就代表了entity-length和transfer-length。如果同时含有Transfer-Encoding，则entity-length和transfer-length可能不会相等，那么Content-Length会被忽略。
4. 如果消息的媒体类型是multipart/byteranges，并且transfer-length也没有指定，那么传输长度由这个媒体自己定义。通常是收发双发定义好了格式， HTTP1.1客户端请求里如果出现Range头域并且带有多个字节范围（byte-range）指示符，这就意味着客户端能解析multipart/byteranges响应。
5. 如果是Response消息，也可以由服务器来断开连接，作为消息体结束。

从消息体中得到实体主体，它的类型由两个header来定义，Content-Type和Content-Encoding（通常用来做压缩）。如果有实体主体，则必须有Content-Type,如果没有，接收方就需要猜测，猜不出来就是用application/octet-stream。

HTTP连接

HTTP1.1的连接默认使用持续连接（persistent connection），持续连接指的是，有时是客户端会需要在短时间内向服务端请求大量的相关的资源，如果不是持续连接，那么每个资源都要建立一个新的连接，HTTP底层使用的是TCP，那么每次都要使用三次握手建立TCP连接，将造成极大的资源浪费。

持续连接可以带来很多的好处：

1. 使用更少的TCP连接，对通信各方的压力更小。
2. 可以使用管道（pipeline）来传输信息，这样请求方不需要等待结果就可以发送下一条信息，对于单个的TCP的使用更充分。
3. 流量更小
4. 顺序请求的延时更小。
5. 不需要重新建立TCP连接就可以传送error，关闭连接等信息。

HTTP1.1的服务器使用TCP的流量控制来控制HTTP的流量，HTTP1.1的客户端在收到服务器连接中发过来的error信息，就要马上关闭此链接。关于HTTP连接还有很多细节，之后再详述。

WebSocket

只从RFC发布的时间看来，WebSocket要晚近很多，HTTP 1.1是1999年，WebSocket则是12年之后了。WebSocket协议的开篇就说，本协议的目的是为了解决基于浏览器的程序需要拉取资源时必须发起多个HTTP请求和长时间的轮训的问题……而创建的。

待续

本来是打算在一篇文章里把HTTP和WebSocket两个协议的大致细节理出来，然后进行对比。可是写着写着就发现篇幅可能会比较长，读起来就不那么友好了，那么刚好就再写第二篇吧。第二篇里会将WebSocket的大致情况描述一下，然后和HTTP适用的场景进行对比。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!