要理解HTTP长连接和websocket长连接的区别，首先要理解一下什么是HTTP的长连接和短连接。

一、HTTP的长连接和短连接区别

首先需要消除一个误解：HTTP协议是基于请求/响应模式的，因此客户端请求后只要服务端给了响应，本次HTTP请求就结束了，没有长连接这一说。那么自然也就没有短连接这一说了。

所谓的HTTP分为长连接和短连接，其实本质上是说的TCP连接。TCP连接是一个双向的通道，它是可以保持一段时间不关闭的，因此TCP连接才有真正的长连接和短连接这一说。

HTTP协议是应用层的协议，而TCP才是真正的传输层协议，只有负责传输的这一层才需要建立连接。

1、短连接

过程：连接->传输数据->关闭连接 
短链接就是浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。 比如HTTP1.0。
具体就是 浏览器client发起并建立TCP连接 -> client发送HttpRequest报文 -> server接收到报文->server handle并发送HttpResponse报文给前端,发送完毕之后立即调用socket.close方法->client接收response报文->client最终会收到server端断开TCP连接的信号->client 端断开TCP连接，具体就是调用close方法。 
也就是说，短连接是指SOCKET连接后，发送接收完数据后马上断开连接。 因为连接后接收了数据就断开了，所以每次数据接受处理不会有联系。 这也是HTTP协议无状态的原因之一。

2、长连接

过程：连接->传输数据->保持连接 -> 传输数据-> ………..->一方关闭连接

长连接指建立SOCKET连接后不管是否使用都保持TCP连接。

HTTP1.1默认是长连接，也就是默认Connection的值就是keep-alive，本次请求响应结束后，TCP连接将仍然保持打开状态，所以浏览器可以继续通过相同的连接发送请求，节省了很多TCP连接建立和断开的消耗，还节约了带宽。

长连接并不是永久连接的。如果一段时间内（具体的时间可以在header当中进行设置，也就是所谓的超时时间），这个连接没有HTTP请求发出的话，那么这个长连接就会被断掉。这一点其实很容易理解，否则的话，TCP连接将会越来越多，直到把服务器的TCP连接数量撑爆为止。

二、HTTP长连接和WebSocket长连接的区别

HTTP1.1中，Connection默认为Keep-alive参数，官方的说法是可以用这个来作为长连接。那么问题来了，既然HTTP1.1支持长连接，为什么还要搞出一个WebSocket呢？

1、HTTP1.1

Keep-alive的确可以实现长连接，但是这个长连接是有问题的，本质上依然是客户端主动发起-服务端应答的模式，是没法做到服务端主动发送通知给客户端的。也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是一个request只能有一个response。而且这个response也是被动的，不能主动发起。开启了Keep-alive，可以看出依然是一问一答的模式，只是省略了每次的关闭和打开操作。

2、WebSocket

WebSocket是可以互相主动发起的。相对于传统 HTTP 每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket 是类似 TCP 长连接的通讯模式，一旦 WebSocket 连接建立后，后续数据都以帧序列的形式传输。在客户端断开 WebSocket 连接或 Server 端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

WebSocket API 是 HTML5 标准的一部分， 但这并不代表 WebSocket 一定要用在 HTML 中，或者只能在基于浏览器的应用程序中使用。
在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一个握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。WebSocket同HTTP一样也是应用层的协议，但是它是一种双向通信协议，是建立在TCP之上的。

WebSocket的流程大概是以下几步：

1、浏览器、服务器建立TCP连接，三次握手。这是通信的基础，传输控制层，若失败后续都不执行。
2、TCP连接成功后，浏览器通过HTTP协议向服务器传送WebSocket支持的版本号等信息。（开始前的HTTP握手）服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据。
3、连接成功后，双方通过TCP通道进行数据传输，不需要HTTP协议。
也就是说WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。

WebSocket 客户端连接报文

GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: 
http://localhost
:8080
Sec-WebSocket-Version: 13

客户端发起的 WebSocket 连接报文类似传统 HTTP 报文，”Upgrade：websocket”参数值表明这是 WebSocket 类型请求，“Sec-WebSocket-Key”是 WebSocket 客户端发送的一个 base64 编码的密文，要求服务端必须返回一个对应加密的“Sec-WebSocket-Accept”应答，否则客户端会抛出“Error during WebSocket handshake”错误，并关闭连接。

服务端收到报文后返回的数据格式类似：
WebSocket 服务端响应报文：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=

“Sec-WebSocket-Accept”的值是服务端采用与客户端一致的密钥计算出来后返回客户端的,“HTTP/1.1 101 Switching Protocols”表示服务端接受 WebSocket 协议的客户端连接，经过这样的请求-响应处理后，客户端服务端的 WebSocket 连接握手成功, 后续就可以进行 TCP 通讯了。

 

参考：

https://www.jianshu.com/p/3fc3646fad80

https://www.cnblogs.com/zzz-knight/p/12694198.html

https://www.jianshu.com/p/86a550a521c5