Go C连接(keep-alive/websocket) D连接 C轮询 D轮询

直接说结论:
长连接:TCP连接一直不断开的连接
keep-alive能实现长连接。
  1.但是有时间限制,最多时间长一些而已 2.需要服务端也支持keep-alive,因为TCP连接的断开是双向的,不是客户端说我要保持连接就行

keep-alive实现的长连接和websocket的长连接不同:
  keep-alive是HTTP协议层面的长连接,不能主动推消息,主要是进行连接复用的
  websocket是websocket协议的长连接,只要不断开,连接一直都在,而且服务端可以主动推消息
keep-alive和websocket应用场景
  • keep-alive用于需要发了HTTP请求后,需要连接复用的场景:
  1.   打开一个页面时,该页面链接了n个图片或n个js脚本或n个css等,并且这些东西都在一台server上;
  2.   需要用户频繁的在网站中转悠,这点点那点点;
  3.   keep-alive不能用在短时间内高并发的场景
  • websocket用于连接不多的场景或者需要服务端推送的场景,因为是长连接,所以服务器能提供的连接数是有限的。
HTTP长轮询:服务器收到请求后如果有数据, 立刻响应请求; 如果没有数据就会 hold 一段时间,这段时间内如果有数据立刻响应请求; 如果时间到了还没有数据, 则响应 http 请求;浏览器受到 http 响应后立在发送一个同样http 请求查询是否有数据;
(长轮询个人理解:“服务端hold住请求”如何实现?是不是有个死循环在一直监测,有数据变化就返回。)
HTTP短轮询:服务器收到请求不管是否有数据都直接响应 http 请求; 浏览器受到 http 响应隔一段时间在发送同样的http 请求查询是否有数据;

长轮询短轮询使用场景:
  • 长轮询多用于web聊天场景,实时性高,还有一个web微信登录扫码的场景也是用的长轮询,手机一扫二维码,网页就显示用户头像
    • 短轮询多用于实时性不高的场景。(celery查询状态就是短轮询,要注意结合keep-alive使用)



HTTP协议的核心: 先有请求,才有响应。有了请求,就要建TCP连接。
所以造就了服务端没办法主动推消息,因为找不到发给谁。

在http早期每个http请求都要求打开一个tpc socket连接,并且使用一次之后就断开这个tcp连接。 使用keep-alive可以在一次TCP连接中可以持续发送多份数据而不会断开连接。
Httpd守护进程,提供了keep-alive timeout时间设置参数。

这个keepalive_timout意味着:一个http请求产生的tcp连接在传送完最后一个响应后,还需要hold住keepalive_timeout秒后,才关闭这个socket连接

设置:Keep-Alive: timeout=5, max=100 // 第一次HTTP请求5秒后自动断开TCP连接,5s内HTTP请求超过100次,断开TCP连接。


keepalive由客户端发HTTP请求(建立TCP连接)时进行设置

HTTP的keep-alive 跟 TCP的keep-alive是两个不同的东西
HTTP的keep-alive说的是我这次请求的TCP连接要保持多长时间不关闭。
TCP的keep-alive是监测我TCP连接保持的这段时间内,双方是不是通的,不通就关闭TCP连接。

设置了keep-alive(http请求头)就是长连接(socket)了吗?

长连接是什么? 长连接是socket建立后一直不关闭,叫长连接。

短连接是什么?短连接是socket建立,通讯一次后,关闭socket。

所以,长连接和短连接在于client和server采取的socket关闭策略。服务器是资源提供者,所以服务器的连接关闭策略就很重要了

所以,问题变成:

设置了keep-alive(http请求头)服务端socket就不关闭了吗?

显然需要请求和服务器双方都设置keep-alive才行。  可以在不同的服务器软件中设定这个时间,nginx,或Apache的keep-alive时间

设置了keep-alive(http请求头),高并发场景服务端设置keep-alive合适吗?

如果同时有大量请求,服务端socket短时间得不到释放,肯定崩溃

双方都支持keep-alive了,用在哪些场景?

  1. 打开一个页面时,该页面链接了n个图片或n个js脚本或n个css等,并且这些东西都在一台server上;
  2. 需要用户频繁的在网站中转悠,这点点那点点;

keep-alive能实现长连接(有时间限制的长连接),但是这个连接除了拿来复用之外没别的用处。和websocket的长连接有什么区别呢

这是协议层面的区别。http 协议规定了 http 连接是一个一来(request)一回(response)的过程。一个请求获得一个响应后必须断掉。而且只有先有请求才会有响应。拿 http1.1 keep-alive 来说,即使底层 tcp 连接没有断,服务端无缘无故给浏览器发一个 http 响应,浏览器是不收的,他找不到收的人啊,因为这个响应没有对应的请求。你看 ajax 必须先发请求才会有一个 onsuccess 回调来响应这个请求。这个 onsuccess 的回调会在你 ajax 不发送的情况下被调用到吗?

而 WebSocket 协议不同,他通过握手之后规定说你连接给我保持着,别断咯。所以浏览器服务器在这种情况下可以相互的发送消息。浏览器端 new 一个 WebSocket 之后注册 onmessage 回调,那么这个 onmessage 可以被反复调用,只要服务器端有消息过来。而不会说是 new 一个 WebSocket onmessage 只会被调用一次,下次还得再 new 一个 websocket。

上面说到 http 连接,tcp 连接,websockt 连接到底啥区别。其实这是新人最容易搞不懂的地方。接下来我就要胡诌了,为啥说胡诌,因为我只是看了个皮毛,然后按我自己的理解说下区别。网络5层分层(自下而上):

物理层
数据链路层
网络层
传输层
应用层
http,websocket都是应用层协议,他们规定的是数据怎么封装,而他们传输的通道是下层提供的。就是说无论是 http 请求,还是 WebSocket 请求,他们用的连接都是传输层提供的,即 tcp 连接(传输层还有 udp 连接)。只是说 http1.0 协议规定,你一个请求获得一个响应后,你要把连接关掉。所以你用 http 协议发送的请求是无法做到一直连着的(如果服务器一直不返回也可以保持相当一段时间,但是也会有超时而被断掉)。而 WebSocket 协议规定说等握手完成后我们的连接不能断哈。虽然 WebSocket 握手用的是 http 请求,但是请求头和响应头里面都有特殊字段,当浏览器或者服务端收到后会做相应的协议转换。所以 http 请求被 hold 住不返回的长连接和 WebSocket 的连接是有本质区别的。

原文地址:https://www.cnblogs.com/staff/p/13252182.html