科普文：websocket全双工协议解读

一、OSI 网络七层模型

第一层：应用层，定义了用于在网络中进行通信和传输数据的接口；

（Http、WebSocket 协议位于该层）

第二层：表示层，定义不同系统中数据的传输格式，编码和解码规范等；

第三层：会话层，管理用户的会话，控制用户间逻辑连接的建立和中断；

第四层：传输层，管理着网络中端到端的数据传输；（Tcp协议位于该层）

第五层：网络层，定义网络设备间如何传输数据；（IP位于该层）

第六层：链路层，将上面的网络层的数据包封装成数据帧，便于物理层传输；

第七层：物理层，这一层主要就是传输这些二进制数据。

二、TCP连接

建立起一个TCP连接需要经过“三次握手”：

• 第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
• 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
• 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求。

SYN攻击就是利用三次握手的第二次握手时进行的，这时候服务器处于SYN_RECV状态，等待客户端进行确认ACK，SYN会伪造不存在的源IP，就会有大量的链接处于等待或重试发送SYN+ACK包，导致该阶段队列持续增长，进而导致后续正常请求被丢弃。

三、HTTP连接

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

1. 在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
2. 在HTTP 1.1中，则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”。

要保持客户端程序的在线状态，需要不断地向服务器发起连接请求，通常情况下即使不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

四、SOCKET连接与HTTP连接

通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

五、SOCKET连接与TCP/IP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

socket则是对TCP/IP协议的封装和应用（程序员层面上）。也可以说，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。

关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：

在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。

平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，才能使用TCP/IP协议。

实际上，Socket跟TCP/IP协议没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以说，Socket的出现 只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了一些最基本的函数接口，比如create、 listen、connect、accept、send、read和write等等。

TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。这个就像操作系统会提供标准的编程接口，比如win32编程接口一样，TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口。

实际上，传输层TCP是基于网络层IP协议的，而应用层HTTP协议又是基于传输层TCP协议的，而Socket本身不算是协议，就像上面所说，它只是提供了一个针对TCP或者UDP编程的接口。

总结：

• HTTP是应用层协议，定义的是传输数据的内容以及格式的规范。
• TCP是底层通讯协议，定义的是数据传输和连接方式的规范。
• Socket可以支持不同的传输层协议（TCP/UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接，Socket是发动机，提供了网络通信的能力

六、什么是单工、半双工、全双工通信？

• 单工：信息只能单向传送；
• 半双工：信息能双向传送但不能同时双向传送；
• 全双工：信息能够同时双向传送。

七、WebSocket与Socket的关系

Socket其实并不是一个协议，而是为了方便使用TCP/UDP而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口，提供一套调用TCP/IP协议的API。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。

WebSocket就像HTTP一样，是一个典型的应用层协议。

总结：

• Socket是传输控制层接口，WebSocket是应用层协议。

八、WebSocket与HTTP的关系

WebSocket是HTML5规范提出的一种协议。HTML5 Web Sockets规范定义了Web Sockets API，支持页面使用Web Socket协议与远程主机进行全双工的通信。它引入了WebSocket接口并且定义了一个全双工的通信通道，通过一个单一的套接字在Web上进行操作。

HTML5 Web Sockets以最小的开销高效地提供了Web连接。相较于经常需要使用推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询（Comet）来说，这就极大的减少了不必要的网络流量与延迟。

相同点：

• 都是一样基于TCP的，都是可靠性传输协议。
• 都是应用层协议。

不同点：

• WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息。HTTP是单向的。
• WebSocket是需要浏览器和服务器握手进行建立连接的。而http是浏览器发起向服务器的连接，服务器预先并不知道这个连接。

联系：

• WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。

为什么要用WebSocket来替代HTTP？

HTTP不断短链接轮询

其实问题的痛点在于，怎么样才能在用户不做任何操作的情况下，网页能收到消息并发生变更。

最常见的解决方案是，网页的前端代码里不断定时发HTTP请求到服务器，服务器收到请求后给客户端响应消息。

这其实时一种伪服务器推的形式。

它其实并不是服务器主动发消息到客户端，而是客户端自己不断偷偷请求服务器，只是用户无感知而已。

用这种方式的场景也有很多，最常见的就是扫码登录。

比如某信公众号平台，登录页面二维码出现之后，前端网页根本不知道用户扫没扫，于是不断去向后端服务器询问，看有没有人扫过这个码。而且是以大概1到2秒的间隔去不断发出请求，这样可以保证用户在扫码后能在1到2s内得到及时的反馈，不至于等太久。

使用HTTP定时轮询

但这样，会有两个比较明显的问题

• 当你打开F12页面时，你会发现满屏的HTTP请求。虽然很小，但这其实也消耗带宽，同时也会增加下游服务器的负担。

• 最坏情况下，用户在扫码后，需要等个1~2s，正好才触发下一次http请求，然后才跳转页面，用户会感到明显的卡顿。

使用起来的体验就是，二维码出现后，手机扫一扫，然后在手机上点个确认，这时候卡顿等个1~2s，页面才跳转。

不断轮询查看是否有扫码

那么问题又来了，有没有更好的解决方案？

有，而且实现起来成本还非常低。

HTTP长连接轮询

我们知道，HTTP请求发出后，一般会给服务器留一定的时间做响应，比如3s，规定时间内没返回，就认为是超时。

如果我们的HTTP请求将超时设置的很大，比如30s，在这30s内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。

这样就减少了HTTP请求的个数，并且由于大部分情况下，用户都会在某个30s的区间内做扫码操作，所以响应也是及时的。

长轮询

比如，某度云网盘就是这么干的。所以你会发现一扫码，手机上点个确认，电脑端网页就秒跳转，体验很好。

以上两种轮询方式也带来了很明显的缺点：

• 首先，客户端需要不断的向服务器发出请求，在消耗较多客户端资源的情况下，服务端并不一定有新的数据下发；
• 其次，HTTP协议请求与回复消息中，需包含较长的头部信息，其中真正有效的数据有可能只占较小的一部分，带来较多的带宽资源消耗。
• 另外，若服务端在同一时间存在连续频繁的数据变化（例如：聊天室场景中），客户端获知数据更新相对较慢（可能存在时间的滞后性）无法保证客户端的用户体验。

长轮询的方式来替代

真一举两得。

像这种发起一个请求，在较长时间内等待服务器响应的机制，就是所谓的长训轮机制。我们常用的消息队列RocketMQ中，消费者去取数据时，也用到了这种方式。

RocketMQ的消费者通过长轮询获取数据

像这种，在用户不感知的情况下，服务器将数据推送给浏览器的技术，就是所谓的服务器推送技术，它还有个毫不沾边的英文名，comet技术，大家听过就好。

上面提到的两种解决方案，本质上，其实还是客户端主动去取数据。

对于像扫码登录这样的简单场景还能用用。

但如果是网页游戏呢，游戏一般会有大量的数据需要从服务器主动推送到客户端。

这就得说下websocket了。

HTTP是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，是半双工通信。

通常，打开某个网页，我们每点击一次网页上的某个选项，前端就会发送一次HTTP请求，网站返回一次HTTP响应。这种由客户端主动请求，服务器响应的方式满足大部分网页的功能场景。但这种情况下，服务器不会主动给客户端发消息。而类似网页游戏这样的场景，是需要客户端和服务器之间互相主动发大量数据的。

因此，我们需要一个基于TCP的新协议，即新的应用层协议WebSocket。

websocket是什么？

WebSocket 是一种用于在单个 TCP 连接上进行全双工通信的网络协议。它使用类似于 HTTP 的握手来建立连接，然后使用单独的持久连接来进行通信。这种方式使得 WebSocket 可以在浏览器和服务器之间进行实时通信，而不需要多次发送 HTTP 请求来获取数据。这意味着连接是持久的，它一直保持打开，直到有一方主动关闭连接。这使得 WebSocket 非常适合用于实时应用程序，因为它不需要不断地建立和关闭连接。

我们知道TCP连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。

而现在使用最广泛的HTTP1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。

也就是说，好好的全双工TCP，被HTTP用成了半双工。

为什么？

这是由于HTTP协议设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应，就够了，根本就没考虑网页游戏这种，客户端和服务器之间都要互相主动发大量数据的场景。

所以为了更好的支持这样的场景，我们需要另外一个基于TCP的新协议。

于是新的应用层协议websocket就被设计出来了。

大家别被这个名字给带偏了。虽然名字带了个socket，但其实socket和websocket之间，就跟雷峰和雷峰塔一样，二者接近毫无关系。

websocket在四层网络协议中的位置

怎么建立websocket连接

WebSocket 连接通常在客户端（例如浏览器）和服务器之间建立。客户端发送一个 HTTP 请求来建立连接，然后服务器返回一个确认消息，表示已建立连接。之后，客户端和服务器可以通过这个连接进行双向通信。客户端可以向服务器发送消息，服务器也可以向客户端发送消息。消息可以是任意的字节数组，并且可以使用任意的格式进行编码。

建立WebSocket连接

WebSocket连接的过程：

1. 客户端发起http请求，经过3次握手后，建立起TCP连接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；
2. 服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据；
3. 客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信。

WebSocket 是一种必不可少的客户端—服务器通信工具，需要充分了解其实用性并避免使用场景才能从其最大潜力中获益。

我们平时刷网页，一般都是在浏览器上刷的，一会刷刷图文，这时候用的是HTTP协议，一会打开网页游戏，这时候就得切换成我们新介绍的websocket协议。

为了兼容这些使用场景。浏览器在TCP三次握手建立连接之后，都统一使用HTTP协议先进行一次通信。

• 如果此时是普通的HTTP请求，那后续双方就还是老样子继续用普通HTTP协议进行交互，这点没啥疑问。

• 如果这时候是想建立websocket连接，就会在HTTP请求里带上一些特殊的header头。

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n

这些header头的意思是，浏览器想升级协议（Connection: Upgrade），并且想升级成websocket协议（Upgrade: websocket）。

同时带上一段随机生成的base64码（Sec-WebSocket-Key），发给服务器。

如果服务器正好支持升级成websocket协议。就会走websocket握手流程，同时根据客户端生成的base64码，用某个公开的算法变成另一段字符串，放在HTTP响应的 Sec-WebSocket-Accept 头里，同时带上101状态码，发回给浏览器。

HTTP/1.1 101 Switching Protocols\r\n
Sec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n

http状态码=200（正常响应）的情况，大家见得多了。101确实不常见，它其实是指协议切换。

base64转为新的字符串

之后，浏览器也用同样的公开算法将base64码转成另一段字符串，如果这段字符串跟服务器传回来的字符串一致，那验证通过。

对比客户端和服务端生成的字符串

就这样经历了一来一回两次HTTP握手，websocket就建立完成了，后续双方就可以使用webscoket的数据格式进行通信了。

建立websocket连接.drawio

websocket抓包

我们可以用wireshark抓个包，实际看下数据包的情况。

客户端请求升级为websocket

上面这张图，注意画了红框的第2445行报文，是websocket的第一次握手，意思是发起了一次带有特殊Header的HTTP请求。

服务器同意升级为websocket协议

上面这个图里画了红框的4714行报文，就是服务器在得到第一次握手后，响应的第二次握手，可以看到这也是个HTTP类型的报文，返回的状态码是101。同时可以看到返回的报文header中也带有各种websocket相关的信息，比如Sec-WebSocket-Accept。

两次HTTP请求之后正式使用websocket通信

上面这张图就是全貌了，从截图上的注释可以看出，websocket和HTTP一样都是基于TCP的协议。经历了三次TCP握手之后，利用HTTP协议升级为websocket协议。

你在网上可能会看到一种说法："websocket是基于HTTP的新协议"，其实这并不对，因为websocket只有在建立连接时才用到了HTTP，升级完成之后就跟HTTP没有任何关系了。

这就好像你喜欢的女生通过你要到了你大学室友的微信，然后他们自己就聊起来了。你能说这个女生是通过你去跟你室友沟通的吗？不能。你跟HTTP一样，都只是个工具人。

这就有点"借壳生蛋"的那意思。

HTTP和websocket的关系

websocket的消息格式

上面提到在完成协议升级之后，两端就会用webscoket的数据格式进行通信。

数据包在websocket中被叫做帧。

我们来看下它的数据格式长什么样子。

websocket报文格式

这里面字段很多，但我们只需要关注下面这几个。

opcode字段：这个是用来标志这是个什么类型的数据帧。比如。

• 等于1时是指text类型（string）的数据包

• 等于2是二进制数据类型（[]byte）的数据包

• 等于8是关闭连接的信号

payload字段：存放的是我们真正想要传输的数据的长度，单位是字节。比如你要发送的数据是字符串"111"，那它的长度就是3。

另外，可以看到，我们存放payload长度的字段有好几个，我们既可以用最前面的7bit, 也可以用后面的7+16bit或7+64bit。

那么问题就来了。

我们知道，在数据层面，大家都是01二进制流。我怎么知道什么情况下应该读7bit，什么情况下应该读7+16bit呢？

websocket会用最开始的7bit做标志位。不管接下来的数据有多大，都先读最先的7个bit，根据它的取值决定还要不要再读个16bit或64bit。

• 如果最开始的7bit的值是 0~125，那么它就表示了 payload 全部长度，只读最开始的7个bit就完事了。

payload长度在0到125之间

• 如果是126（0x7E）。那它表示payload的长度范围在 126~65535 之间，接下来还需要再读16bit。这16bit会包含payload的真实长度。

payload长度在126到65535之间

• 如果是127（0x7F）。那它表示payload的长度范围>=65536，接下来还需要再读64bit。这64bit会包含payload的长度。这能放2的64次方byte的数据，换算一下好多个TB，肯定够用了。

payload长度大于等于65536的情况

payload data字段：这里存放的就是真正要传输的数据，在知道了上面的payload长度后，就可以根据这个值去截取对应的数据。

大家有没有发现一个小细节，websocket的数据格式也是  数据头（内含payload长度） + payload data 的形式。

之前写的《既然有HTTP协议，为什么还要有RPC》提到过，TCP协议本身就是全双工，但直接使用纯裸TCP去传输数据，会有粘包的"问题"。为了解决这个问题，上层协议一般会用消息头+消息体的格式去重新包装要发的数据。

而消息头里一般含有消息体的长度，通过这个长度可以去截取真正的消息体。

HTTP协议和大部分RPC协议，以及我们今天介绍的websocket协议，都是这样设计的。

消息边界长度标志

 websocket最大优势

websocket可以做到服务端主动将消息推送给客户端

websocket其余特点

1. 握手阶段采用http协议

2. 数据格式轻量，性能开销小，客户端与服务端进行数据交换时，服务端到客户端的数据包头只有2-10字节，客户端到服务器需要加上另外4字节的掩码。

http每次都要携带完整头部

3. 更好的二进制支持，可以发送文本和二进制数据

4. 没有同源限制，客户端可以与任意服务器进行通信

5. 协议标识符是WS（如果加密，则是WSS），请求的地址就是后端支持WebSocket的API

websocket的使用场景

websocket完美继承了TCP协议的全双工能力，并且还贴心的提供了解决粘包的方案。它适用于需要服务器和客户端（浏览器）频繁交互的大部分场景。比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。

回到文章开头的问题，在使用websocket协议的网页游戏里，怪物移动以及攻击玩家的行为是服务器逻辑产生的，对玩家产生的伤害等数据，都需要由服务器主动发送给客户端，客户端获得数据后展示对应的效果。

websocket的使用场景

websocket与服务端实时通信的方法

1. AJAX轮询

2. Long Polling长轮询

（注意：以上俩种缺点：开销大，被动性，并发高的时候服务器压力很大）

3. WebSocket通信

连接过程

客户端发起HTTP握手，告诉服务端进行WebSocket协议通讯，并告知WebSocket协议版本，服务端确定协议版本，升级为WebSocket协议。

之后如果有数据需要推送，会主动推送给客户端。

 WebSocket API

客户端若想与支持WebSocket的服务器通信，可以使用WebSocket构造函数返回WebSocket对象

​

const test = new WebSocket("ws://localhost:8080/websocket");

1. WebSocket.onopen： 连接成功后的回调

2. WebSocket.onclose： 连接关闭后的回调

3. WebSocket.onerror： 连接失败后的回调

4. WebSocket.onmessage： 客户端接收到服务端数据的回调

5. webSocket.bufferedAmount： 未发送至服务器的二进制字节数

6. WebSocket.binaryType： 使用二进制的数据类型连接

7. WebSocket.protocol ： 服务器选择的下属协议

8. WebSocket.url ： WebSocket 的绝对路径

9. WebSocket.readyState： 当前连接状态，对应的四个常量

       WebSocket.CONNECTING: 0

       WebSocket.OPEN: 1

       WebSocket.CLOSING: 2

       WebSocket.CLOSED: 3

10. WebSocket.close() 关闭当前连接

11. WebSocket.send(data) 向服务器发送数据

​

WebSocket 与 HTTP 的选择

WebSocket 是一种框架双向协议。与此相反，HTTP 是一种单向协议，作用于 TCP 协议之上。由于WebSocket协议能够支持不间断的数据传输，因此主要用于实时应用程序开发。HTTP 是无状态的，用于开发RESTful和 SOAP 应用程序。SOAP 仍然可以使用 HTTP 来实现，但是 REST 被广泛传播和使用。

在 WebSocket 中，通信发生在两端，这使其成为更快的协议。在 HTTP 中，连接是在一端建立的，这使得它比 WebSocket 有点慢。WebSocket 使用统一的 TCP 连接，需要一方终止连接。在它发生之前，连接保持活动状态。HTTP 需要为单独的请求建立不同的连接。请求完成后，连接会自动断开。

HTTP 长轮询

现今对网络数据安全性也存在更多需求，WebSocket 连接使用的是标准的 TCP 连接，因此它可以在任何支持 TCP 的网络上使用。它使用的是 ws:// 和 wss:// 协议前缀，这些前缀可以与任何域名或 IP 地址结合使用。

WebSocket 连接是可以加密的，可以使用 TLS（Transport Layer Security，传输层安全）协议来保护数据的安全。这种加密连接使用的是 wss:// 协议前缀，与不加密的连接使用的 ws:// 协议前缀相区别。除此之外，WebSocket 还支持安全握手协议（Secure Handshake Protocol），这使得它可以在浏览器和服务器之间进行加密通信。总的来说，WebSocket 具有较高的安全性，可以保护数据的安全。

另外，需要注意的是，WebSocket不是基于HTTP的新协议，因为WebSocket只有在建立连接时才用到了HTTP，升级完成之后就跟HTTP不再有任何关系。

总结

• TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。

• 在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。

• 对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。

• websocket和socket几乎没有任何关系，只是叫法相似。

• 正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。