WebSocket是什么原理？为什么可以实现持久连接？

　　首先需要明白：基于TCP的应用层协议，只要设计者愿意，都是可以实现持久连接的。
　　你问的方式，大概是在和HTTP做比较。HTTP
　　http协议是请求应答式的文本协议，协议设计就是ClientServer模式，出发点是服务端为客户端提供资源。http服务端只能监听和响应来自客户端的请求，http客户端只能发起请求接受响应，这个是HTTP协议本身的设计，双向通信不在设计的考虑之内。
　　关于Http协议，额外说点：
　　HTTP1。00。9
　　不支持keepalive，要完成一次HTTP请求，需要建立一个新的TCP连接，然后发送http请求，待接收响应后关闭连接。
　　HTTP1。1
　　默认使用keepalive，一次HTTP请求完成后不会关闭TCP连接，会继续为下一个HTTP请求服务（可以类比数据库连接池和线程池的设计），减小建立和关闭TCP连接的开销（三次握手四次挥手）。当然闲置超时后也会关闭。并非楼下所说的把多个HTTP请求合并为一个。
　　HTTP协议的设计无法实现对TCP通道的分用和复用。因为HTTP协议没有请求的唯一标记（仅仅是URL是不行的，原因大家想）用来从同一TCP通道分离不同的HTTP消息，所以一个完整的HTTP请求在发送请求到响应回来之间是独占一个TCP通道的！是不是觉得HTTP对TCP的利用率太低了？而关于pipeline模式，不管在服务端还是客户端排队，HTTP响应依然要通过进入服务端队列的顺序返回，这样才能和客户端HTTP请求队列用顺序做对应！所以pipeline模式某个请求被服务端因为某些原因阻塞了的情况下，后续请求都会阻塞，会引起很大的问题，实际上很少用。
　　浏览器或者一般HTTP客户端组件为某一个服务器端点（域名端口）保留46条活跃TCP连接。你可以F12观察浏览器，看看同时是几个请求阻塞了就知道你的浏览器设置的多少。比较大的门户网站，比如京东，首页请求非常多，但是大量都需要排队等TCP空闲。限制客户端的连接数量的出发点主要是性能，否则会占用服务器太多Socket资源（考虑socket预留的读写缓冲区，windows的内核对象或者linux的文件句柄）或者变相地造成DoS攻击。
　　Tips：HTTP客户端组件一般会提供诸如ConnectionLimit的选项让你控制最大TCP连接数。如果你是桌面客户端，或者请求远程服务，不宜设置过大。如果你是内部服务之间调用，可以根据需求合理设置以增加并发性能。
　　HTTP2。0
　　针对以上的问题（主要是性能）做了很多改进，这个也会提高很多人在后端不同服务器之间做通信时选择HTTP（我在HTTP2。0出来之前就是自己设计RPC方案）。详细的HTTP2。0的东西，这里不展开了，详细参考官方文档。
　　HTTP相关知识推荐《HTTP权威指南》以及相关的RFC文档，尽量少去看博客上面支离破碎的小知识，体系化的认知结构对你帮助更大。
　　WebSocket
　　WebSocket的出现，就是为了解决http协议不支持双向通信的缺口。所以WebSocket的握手协议就是使用的HTTP消息来Upgrade。
　　现代的Web场景，服务端推送的需求非常大，这个发展过程中使用的Ajax轮询，Comet等都只是临时解决方案，从设计上看，只为满足需求，一点都不优雅。
　　Html5规范将WebSocket纳入后，得到了现代几乎所有浏览器的支持，当然IE（10才支持）仍然是一个巨坑，在乎用户覆盖面的产品依然要通过浏览器是否支持ws来做出降级处理（轮询、长连接）。
　　websocket协议实现独占一条tcp通道，它负责从tcp流确定消息边界，解析出每个独立的消息包。可进行全双工的双向通信。题主所谓的WebSocket可以实现持久连接，只是的一个服务端WebSocket会话和对应的客户端WebSocket会话在使用一个固定的保持连接的TCP通信而已。一般需要将服务端WebSocket会话和某位用户关联起来（客户单连接后，可以再单独发送凭证验证），实现给某个用户推送消息，只需根据关联找到对应的WebSocket会话调用发送API即可。应用
　　使用单独实现websocket协议的服务客户端组件，可以更加轻松地实现自定义协议：在websocket的二进制或者文本消息体内或者直接使用websocket的自协议定义机制封装自己定义的协议。
　　推荐大家如果有些需要自建IM服务器，推送服务器的场合尝试先用WebSocket来实现。负载高（协议头消耗小），协议简洁，几乎所有客户端（减少了大量的工作）都有对应的开源项目可用，同时还是唯一可以在浏览器上用的双向通信协议（flash和silverlight等插件方式除外）。
　　如果你要用websocket实现请求应答式的子协议，要点是你要设计唯一的请求标志，响应也将请求标志带回来，然后你就可以从客户端的请求队列中查找响应对应的请求将响应交给上层处理！
　　特别注意：
　　关于webcket持久连接，本质上是下层tcp连接的保持，核心问题同样是如何保活。需要考虑Nat失效（基站最突出，一般有效期只有3分钟）或者其它网络原因导致大量半连接存在。解决方案就是合理的心跳时间，一般我设置为2分50秒的样子。其它
　　不论是否从事网络编程，都应该花时间学习下TCPIP协议簇方面的知识，着重理解分层原理，各层的功能和为上层提供了哪些功能。就像这个问题，如果不对TCP有所了解，回答的内容就没多大意义了。阅读一个你比较熟悉的语言的的一种协议（比如http）实现项目的源码，帮助应该很大。
　　和网络IO密切相关的就是线程，要设计高可用的TCP服务器，必须要熟悉多线程。网络IO和多线程是我认为最重要的两个核心知识点。
　　关于协议的设计，你可以多学习其他优秀的基于TCP实现的应用层协议，简单的就有Redis的通信协议，里面有阻塞式的消费者队列，那个就需要一条单独的tcp通道。协议设计是很有意思的一件事情，就是mysql和mongodb的通信协议我也不会放过，去看看，会给自己设计协议带来不少的参考价值。
　　如果时间允许，有标准的协议最好看看RFC文档，现在Chrome的翻译已经很好了，如果英文不太好，问题也不大。关于TCPIP相关的书籍
　　《计算机网络：自顶向下方法》和谢希仁的《计算机网络》都是不错的入门书籍。
　　《TCPIP详解》是经典，虽然出版已久，内容是没过时的。
　　网络应用脱离不了操作系统，所以可以再看看操作系统关于网络IO这一块的设计。
　　实际开发更多和Socket以及多线程打交道，Windows下面可以看看《Windows核心编程》。
　　其它的就是开源项目：Nginx，netty等大量优秀的项目都在等你。
　　还是要感谢大家对我写的东西有那么一点感兴趣，能对大家有所帮助就更好了。
　　解释WebSocket为什么可以实现持久连接，还是先介绍一些什么是WebSocket，以及它产生的原因是什么。
　　是什么WebSocket？
　　WebSocket是一个协议。
　　协议就是王八的屁股规定，你可以不遵守，但是别人都遵守你不遵守，你就跟别人玩不到一块去。
　　WebSocket协议在2008年诞生，2011年成为了国际标准，现在绝大部分浏览器都已经支持了。
　　产生的原因
　　其实原因是为了弥补HTTP协议的不足，因为HTTP协议只能由客户端发起请求，并且一个Request要对应一个Response（长链接也是如此）。
　　举个例子：
　　我之前做过一个小项目，只有一个页面，展示的是各个分公司当天的业绩，就是挣了多少钱。后台服务是Java，数据库是Mysql，有一张汇总表，内容大概是北京100万，上海80万这样的。
　　流程很简单，HTML页面发起请求到Java，Java访问数据库查询数据，再返回给HTML展示。但是Mysql中的汇总表的数据，是不定期更新的，可能10分钟，可能20分钟。
　　最简单的做法：HTML中用JS设置一个定时轮询（Polling），每隔几秒去发起一次请求，获取最新的数据，如果数据没有变化，页面也保持变化；缺点很明显，前端发起的很多请求都是无效的（因为数据没有变化）。
　　WebSocket的通信原理
　　而WebSocket，是要在客户端和服务器之间，建立一个通道，建立一个【真的长链接】。
　　WebSocket是要借助于HTTP，完成一部分工作。我在找到一个WebSocket在线测试的网站，打开之后查看请求和响应（具体网站连接也看下面图片中的信息）。
　　可以看出来协议里面多了两行：
　　Upgrade：websocket
　　Connection：Upgrade
　　这个就是关键内容了，通过请求告诉服务器：看清楚咯，请求要用WebSocket协议。
　　服务器会回答：好的，那我就切换到WebSocket协议啦。
　　到了这时候，HTTP完成它所有工作，客户端和服务器已经建立好了一个通道，下面就按照WebSocket协议进行了，服务端也就可以主动推送信息给客户端（双向），并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接，故此WebSocket也就实现了持久连接。
　　希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
　　很高兴能够看到和回答这个问题！WebSocket是什么原理？
　　WebSocket通过常见的HTTP协议进行数据连接，一般走的是TCP通道，WebSocket是一个允许单TCP连接之间全双工通信的协议。在WebSocketAPI中，浏览器和服务器只需要一次远程连接，而不是三次远程连接连接到TCP服务器，这样就可以直接持久连接和双向数据传输。WebSocket的特点
　　WebSocket协议是基于TCP的一种新的网络协议。它实现了浏览器与服务器全双工（fullduplex）通信允许服务器主动发送信息给客户端。缺陷：HTTP的通信只能由客户端发起建立在TCP协议之上WebSocket特点性能开销小通信高效客户端可以与任意服务器通信协议标识符wswss持久化网络通信协议
　　通常情况下，浏览器向服务器发送一个请求，工作完成后再向客户端返回一个消息。如果需要主动向浏览器提供数据，可以使用Web套接字。在向对方发送消息之前，先在服务器上维护一个Web套接字连接，然后在前端维护一个，再维护Web套接字。
　　Websocket使用ws或wss协议，对应http或https。在WebSocket远程连接成功后，这是一个全双工的TCP通道，在这个通道上可以无差别的从工作日结束后向客户端发送数据。WebSocket创建的绑定与长HTTP绑定不同。由于长期的地下室还是HTP协议，他还是提出了一个问题，但只是长期保持联系。为什么可以实现持久连接？
　　WebSocket协议是由HTML5标准定义的，它最初是为浏览器设计的，避免了相似性的限制。因为浏览器可以和任何工作端进行通信，现代的浏览器大多支持WebSocket。虽然WebSocket最初定义为HTML5，但它同样适用于移动终端。虽然可以通过Socket直接与终端连接，但使用WebSocket可以有效防止一些防火墙的窃听。
　　WebSocket建立了一个连接，我们称之为持久连接，每个连接都是服务器的一个资源。但是，如果服务器长时间没有消息通信，就会倾向于关闭连接。其实，WebSocket的任务就是及时向桌面端发送空白消息，保证连接不会自动断开。很多网站采用技术实现推送技术。当浏览器向服务器发送HTTTP请求时，在一定的时间间隔内（如1秒）进行轮询，然后服务器将最新的数据返回给客户端的浏览器。这种传统的模式有明显的缺点，那就是浏览器需要不断地访问服务器，但HTTTP请求中会包含一个较长的头，在这个头中，真正有效的数据只能占据一小部分，这似乎造成了很多资源（如带宽）的浪费。
　　第一次连接到Web套接字时，使用普通的HTTP与服务器通信，与Web套接字交换消息。一旦建立了Web套接字连接，所有的消息都可以通过这个通道发送。同时，客户端和服务器会继续使用乒乓球保持心跳，防止非正常断线。将网站的刷新逻辑移植到支持的浏览器上很容易，只需要找一些webssocket接口使用双webssocket属性即可。因为协议是完全双向的，服务器可以随时主动向客户端发送数据。与HTTP请求相比，接收客户请求的响应所需的延迟要少得多。即使与彗星等长时间的轮询相比，也可以在短时间内更频繁地传输数据。
　　答案写到这里，我想您应该明白了WebSocket的原理，也知道了WebSocket可以实现持久连接的原因。WebSocket是基于web的一项新技术，它克服了以往HTTP协议下访问速度较慢容易断开连接，网站假死的现象。未来WebSocket技术将全面普及，提高我们的上网体验！
　　以上便是我的一些见解和回答，可能不能如您所愿，但我真心希望能够对您有所帮助！不清楚的地方您还可以关注我的头条号每日精彩科技我将竭尽所知帮助您！
　　码字不易，感觉写的还行的话，还请点个赞哦！
　　WebSocket是一种不同于HTTP的协议，重要的是它完美弥补了http协议在某些场合下的重大不足。
　　接下来，我来简单介绍下websocket与http的区别。
　　httphttps请求是目前最广泛使用的网络通信协议，但是它们有一个非常大局限性，那就是请求只能由agent发起，server只能被动的等待请求，而且一次请求就是一个response和request对应。虽然在HTTP1。1中进行了改进，增加了keepalive，出现了长连接这样的概念，但是仍然是一个request对应一个response，这在request中携带大量header信息，而response中没什么有用信息的时候，无疑是对通信资源的浪费。
　　也许你觉得这么说有点抽象，那么我们举个例子来说明，我们在浏览器上用QQ聊天，如果浏览器作为agent使用的是http协议与server端通信，那么它需要定时去访问server（轮询），问它，喜欢的女神有没有回复我的信息啊。可是女神可能去洗澡了，手机没带进浴室，于是browser这个agent就不停的发一个大脑袋的request去server，每次拿回来的却都是干瘪瘪的response。这时候，如果你一边看电影一边等女神的回复，那么结果可能就是电影很卡，女神也没有消息。
　　这个时候WebSocket协议就出现了。如果使用的是websocket协议，在登陆了网页版QQ之后，这个浏览器就会作为agent向server发起请求，建立一个连接，在这个连接建立期间，是可以进行双工通信的，就是说agent可以主动把消息发送给server，server也能在收到女神回复后，第一时间把消息传递到你的屏幕上，减少了无意义的轮询消耗，同时也保证了等女神回复期间电影不卡，不会无聊。甚至也可以简单的理解，只需要经过一次HTTP请求的连接建立，就可以进行源源不断的信息传送了。
　　说到实现长连接，说白了，websocket的设计者在最初就是没想过像http协议那样谨慎小气，建立了连接说完一句话就跑。否则任何基于TCP的应用协议，都是可以进行长连接通信的。
　　也许正是当初http的如此设计，才给了WebSocket如今的用武之地。
　　以上是我的浅见，欢迎各位在下方评论区与我沟通交流。
　　我是苏苏思量，来自BAT的Java开发工程师，每日分享科技类见闻，欢迎关注我，与我共同进步。
　　首先我们看一下websocket的出现背景，我们知道http系列协议是建立在tcp上的，理论上，他是可以可以双向通信的。但是http1。1之前，服务器没有实现推送的功能。每次都是客户端请求，服务器响应。下面看一下http协议关于请求处理的发展。http1。0的时候，一个http请求的生命周期是客户端发起请求，服务器响应，断开连接。但是我们知道tcp协议的缺点就是，三次握手需要时间，再加上慢开始等特性，每一个http请求都这样的话，效率就很低。http1。1的时候，默认开启了长连接（客户端请求中设置了keepalive头），服务器处理一个请求后，不会立刻关闭连接，而是会等待一定的时间。如果没有请求才关闭连接。这样浏览器不仅可以在一个tcp连接中，不断地发送请求（服务器也会限制一个连接上可以处理的请求阈值），甚至可以一次发很多个请求。这就是http1。1的管道化（pipeline）技术。但是他也有个问题，因为对于基于http协议的客户端来说，虽然他可以发很多请求出去，但是当一个请求对于的回包回来时，他却无法分辨是属于哪个请求的。所以回包只能按请求顺序返回，这就引来了另一个问题线头阻塞（HeadofLinkBlocking）。并且http1。1虽然支持长连接，但是他不支持服务端推送（push）的能力。如果服务器有数据要给客户端，也只能等着客户端来取（pull）。来到了http2。0，不仅实现了服务器推送，还使用了帧（iframe），流（stream）等技术解决了线头阻塞的问题，http2。0在一个tcp连接中，可以同时发送多个http请求，每个请求是一个流，一个流可以分成很多帧，有了标记号，服务器可以随便发送回包，客户端收到后，根据标记，重新组装就可以。
　　以上是http协议的关于请求的一些发展，而websocket就服务端推送提供了另外一种解决方案。他本质上是在tcp协议上封装的另一种应用层协议（websocket协议）。因为他是基于tcp的，所以服务端推送自然不是什么难题。但是在实现上，他并不是直接连接一个tcp连接，然后在上面传输基于websocket协议的数据包。他涉及到一个协议升级（交换）的过程。我们看看这个过程。
　　1客户端发送协议升级的请求。在http请求加上下面的http头
　　2服务器如果支持websocket协议的话，会返回101状态码表示同意协议升级，并且支持各种配置（如果服务器不支持某些功能或版本，或告诉客户端，客户端可以再次发送协议升级的请求）。服务会返回形如下面的http头（可以参考websocket协议）。
　　3这样就完成了协议的升级，后续的数据通信，就是基于tcp连接之上，使用websocket协议封装的数据包。
　　下面我们通过wireshark来了解这个过程。首先我们启动一个服务器（ip：192。168。8。226）。
　　我们可以直接在浏览器控制台进行测试
　　这时候，我们看看wireshark的包。
　　首先看前面三条记录，这是tcp三次握手的数据包。这个我们都了解了，就不展示。接着看第四条记录。展开后如下。
　　我们看到建立tcp连接后，浏览器发了一个http请求，并带上了几个websocket的数据包。接着看下面的一条。
　　服务返回了同意升级协议或者说交换协议。从服务器代码中我们看到，在建立连接的时候我们给浏览器推送了一个getit的字符串。继续看上面的记录。
　　这就是服务器给浏览器推送的基于websocket协议的数据包。具体每个字段什么意思，参考websocket协议就可以。继续往下看一条记录是针对服务器推送的数据包的一个tcp的ack。最后我们可以顺便看看最后三条写着keepalive的记录。这就是之前文章里讲到的tcp层的keepalive。因为我们一直没有数据传输，所以tcp层会间歇性地发送探测包。我们可以看看探测包的结构。
　　有一个字节的探测数据。如果这时候我们发送一个数据包给服务器，又是怎样的呢。
　　白色背景的三条数据，分别是浏览器发送给服务器的数据，服务器推送回来的数据。tcp的ack。我们发现，服务器给浏览器推送的时候，浏览器会发送ack，但是浏览器给服务器发送的时候，服务器貌似没有返回ack。下面我们看看为什么。首先我们看浏览器发出的包。
　　再看看服务器给浏览器推送的数据包。
　　我们发现服务器（tcp）推送消息的时候把ack也带上了。而不是发送两个tcp包。这就是tcp的机制。tcp不会对每个包都发ack，他会累积确认（发ack），以减少网络的包，但是他也需要保证尽快地回复ack，否则就会导致客户端触发超时重传。tcp什么时候发送确认呢？比如需要发送数据的时候，或者超过一定时间没有收到数据包，或者累积的确认数量达到阈值等。既然研究了tcp，我们不妨多研究点，我们看一下，如果这时候关闭服务器会怎样。
　　服务器会发送一个重置包给浏览器，告诉他需要断开连接。继续，如果是浏览器自己调用close去关闭连接会怎样。
　　我们看到websocket首先会发送一个FIN包给服务器，然后服务器也会返回一个FIN包，然后才开始真正的四次挥手过程。并且四次挥手的第一个fin包是服务器发的。
　　我们再来看看安全版本的websocket。我们启动一个https服务器。
　　然后在浏览器控制台执行。
　　然后来看看wireshark。
　　首先建立tcp连接，然后建立tls连接。后续的数据通信就可以基于加密来进行了。不再重复。后续分析tls协议的时候再分析。
　　经过一系列的分析，我们对websocket协议应该有了更多的了解，最后再说一个关于websocket的点。我们发现如果在websocket连接上，一直不通信的话，websocket连接所维持的时间是依赖tcp实现的。因为我们发现tcp层会一直发送探测包。达到阈值之后，连接就会被断开。所以我们想维持websocket连接的话，需要自己去发送心跳包，比如ping，pong。
　　总结：本文分析了websocket的基本原理，但不涉及协议的内容，如需了解协议的内容，可以参考rfc文档。
　　先说为什么WebSocket可以实现持久连接。这个前面已经有人回答了：WebSocket是基于TCP的，TCP本身就支持长连接。
　　那么问题就变成了，为什么早期的HTTP不支持长连接？以及HTTP1。1开始默认支持长连接了，为什么还要WebSocket？
　　为什么早期的HTTP不支持长连接？
　　个人认为有几个方面的原因：
　　网络环境：早期网络，带宽不高，速度也不咋的，长连接浪费资源交互方式：早期的网页以浏览为主，交互性不强，可能页面展示出来后，阅读需要花较长的时间，保持长连接意义不大。Web2。0开始，交互性越来越强，页面展示后，可能还会有各种交互。底层IO实现：epoll是2003年，在linux的2。6版本的内核中加入的。在此之前的select和poll都有一个问题，都是通过遍历文件描述符来获取已经就绪的socket的，随着连接数的增加，性能会越来越低。
　　HTTP1。1开始默认支持长连接了，为什么还要WebSocket？
　　要回答这个问题，需要先来看HTTP的设计目的是什么。可以参考RoyThomasFielding博士的博士论文《ArchitecturalStylesandtheDesignofNetworkbasedSoftwareArchitectures》，也就是传说中的REST，这是HTTP的设计指导原则。
　　Roy博士认为一个良好设计的Web应用应该这样运转：一个由网页组成的网络（一个虚拟状态机），用户通过选择链接在应用中前进（状态迁移），导致下一个页面（应用的下一个状态的表述）被转移给用户，并且呈现给他们，以便他们来使用。
　　可以看出普通Web应用是个标准的CS架构，且通过Client来操作Server的状态变迁！Server只对Client的请求做出响应，而不会主动的响应Client。
　　也就是说HTTP是单向的！但实际场景中还是有Server向Client推送消息的情况，所以就有了类似ajax轮询，Comet这样的方式。但实际还是需要Client主动发送请求，Server响应，只是响应的时机不同。
　　WebSocket就是为了解决这个问题的。怎么解决的呢？定义了一套新的协议！只不过以HTTP做了个嫁衣。
　　WebSocket原理
　　最后来说说WebSocket是如何实现的！
　　协议传输方式其实都是大同小异，可以回想一下编写Socket的代码逻辑：
　　建立连接Client组装请求协议消息发送Server接收协议消息，进行解析处理然后再组装响应协议消息，发送回去
　　Server端直接向Client推送消息的流程也是类似的。区别就是Client与Server是一对多的关系。也就是说Server端有多个连接。
　　那要Server端能够推送消息给指定Client端，无非就是Server端需要维护这个连接池。你可以把这个连接池想象成一个key，value键值对。key是ClientId，key是Connection。只需要根据ClientId找到对应的Connection，实际发送方式和Client是一样的。
　　WebSocket有一个比较特别的地方就是，它是通过HTTP来建立连接的：
　　Client首先通过HTTP发送一个GET请求来告诉Server，我们能通过WebSocket来进行通信吗？Server答复101，表示好的然后Client和Server就开始使用WebSocket开始通信了
　　这个流程是不是似曾相识：
　　你在fb上撩到个外国妹子，你问道：CanyouspeakChinese？
　　对方回答：Yes
　　然后你们就开始用中文撩了～大妹子，你哪人啊？东北的这么巧，俺也是。。。。。。
　　对于Web项目开发，往往需要前端和后端进行数据通信交互，在以前如果前端要和后端通信往往是通过Ajax这种异步方式，但这样就存在一些弊端，比如说实时性要求高的项目（如在线聊天室）就不好使用Ajax这种方式，而应该使用服务器推技术。
　　在WebSocket出来之前，实现服务器推基本上都是野路子，不够优雅，而WebSocket一经推出，就可以便捷实现长连接了。WebSocket是一种新的协议
　　WebSocket是一种借鉴了HTTP协议的新协议，随着HTML5一起推出了WebSocketAPI（WebSocket不属于HTML5，HTML5中所谓的WebSocket其实是指WebSocketAPI）。WebSocket和HTTP没有必然联系，不能单纯的把WebSocket理解成HTTP协议的升级，不过WebSocket为了兼容现有的浏览器握手规范，借鉴了HTTP协议规范！不过WebSocket协议解决了HTTP协议的被动性，可以实现长连接。
　　WebSocket为什么可以持久化连接？
　　WebSocket协议实现了浏览器与服务器的全双工通信，它通过已建立的TCP连接来传输数据，WebSocket协议的特点是：
　　WebSocket协议名为ws，它有对应的安全连接协议名为wss；
　　先像TCP一样建立连接，WebSocket基于TCP协议；
　　客户端和服务端握手过程中，客户端会发送一个包含Upgrade：请求头的HTTP请求，告诉服务器建立一个WebSocket连接；
　　服务端收到请求后，会将协议转换为WebSocket协议，且在协议转换过程中该连接没有中断；
　　当第一个HTTPRequest请求建立TCP连接之后，以后的数据交换就不需要再次发送HTTPRequest了，因此这个连接也就变成了长连接；
　　不同URI可复用同一个WebSocket连接。以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！
　　http请求响应模式是一夜情，websocket请求响应模式是小三，tcp请求响应模式是夫妻关系。
　　一句话就可以说清楚的问题，饶了这么大的一个圈子。因为websocket的本质还是基于tcp的，tcp是老爹，既然tcp可以全双工，那么websocket当然可以实现。http不支持是因为协议本身规定是只能响应一次，第二次服务器不认识客户端了就像一夜情。如何解决这个问题？原理就是让服务器保留客户端的身份信息，你不需要再一次告诉服务器，我是谁，我是你的情人，可以再上车。
　　Websocket是应用层第七层上的一个应用层协议，它必须依赖HTTP协议进行一次握手，握手成功后，数据就直接从TCP通道传输，与HTTP无关。
　　Websocket的数据传输是frame形式传输的，它将一条消息分为几个frame，按照先后顺序传输，大数据的传输可以分片传输，不用考虑到数据大小导致的长度标志位不足够的情况，和http的chunk一样，可以边生成数据边传递消息，即提高传输效率。
　　有个心跳检测超时的话服务端会自动断开