1）通知功能：

保持一個長連接，當(dāng)服務(wù)端游新的消息，能夠?qū)崟r的推送到使用方。像知乎的點贊通知、評論等，都可以使用WebSocket通信。

某些使用H5的客戶端，為了簡化開發(fā)，也會使用WebSocket進行消息的通知，由于它是實時推送的，會有更好的用戶體驗。

2）數(shù)據(jù)收集：

一些次優(yōu)級別的數(shù)據(jù)，比如行為日志、trace、異常執(zhí)棧收集等，都可以開辟專門的WebSocket通道進行傳輸。這能夠增加信息的集中度，并能及時的針對用戶的行為進行合適的配置推送。由于大多數(shù)瀏覽器內(nèi)核都支持，它將使客戶端APM編程模型變得簡單。

3）加密 && 認(rèn)證：

雖然使用Fiddler、Charles等能夠抓到很多WebSocket包。但如果同時開啟SSL，傳輸加密后的二進制數(shù)據(jù)，會大幅增加破解的成本，會安全的多。

4）反向控制鉤子：

這個...由于是雙工長連接，服務(wù)端完全可以推送一些鉤子命令，甚至直接是代碼，在客戶端進行執(zhí)行。比如截個屏，錄個音，種個小馬。用戶只要通過了授權(quán)申請，剩下的就隨你發(fā)揮了。

所以就一個梗：支付寶偷偷調(diào)用你的相機給你拍照

下面我們就來了解websocket協(xié)議：

HTTP是單工的還是雙工的還是半雙工的

先來區(qū)分三者的含義

1.單工：數(shù)據(jù)傳輸只允許在一個方向上的傳輸，只能一方來發(fā)送數(shù)據(jù)，另一方來接收數(shù)據(jù)并發(fā)送。例如：對講機

2.半雙工：數(shù)據(jù)傳輸允許兩個方向上的傳輸，但是同一時間內(nèi)，只可以有一方發(fā)送或接受消息。例如：打電話

3.全雙工：同時可進行雙向傳輸。例如：websocket

http協(xié)議是什么工作模式呢

分版本，版本不同，工作模式不同

1.http1.0：單工。因為是短連接，客戶端發(fā)起請求之后，服務(wù)端處理完請求并收到客戶端的響應(yīng)后即斷開連接。

2.http1.1：半雙工。默認(rèn)開啟長連接keep-alive，開啟一個連接可發(fā)送多個請求。

3.http2.0：全雙工，允許服務(wù)端主動向客戶端發(fā)送數(shù)據(jù)。

TCP三次握手四次揮手

WebSocket：WebSocket和HTTP什么關(guān)系？

WebSocket和http一樣，都是處于OSI模型中的最高層：應(yīng)用層。

WebSocket借助http協(xié)議進行握手，三次握手成功后，就會變身為TCP通道，從此與http不再相見。

WebSocket是一種在單個TCP連接上進行全雙工通信的協(xié)議。在WebSocket API中，瀏覽器和服務(wù)器只需要完成一次握手（不是指建立TCP連接的那個三次握手，是指在建立TCP連接后傳輸一次握手?jǐn)?shù)據(jù)），兩者之間就直接可以創(chuàng)建持久性的連接，并進行雙向數(shù)據(jù)傳輸。

WebSocket：WebSocket協(xié)議只能瀏覽器發(fā)起么？

不是。目前此協(xié)議的受眾的也不僅僅是web開發(fā)者。

WebSocket只是一種協(xié)議，它和http協(xié)議一樣，使用類似okhttp的組件，可以在任何地方進行調(diào)用，甚至可以借助WebSocket實現(xiàn)RPC框架。

WebSocket：WebSocket和長輪詢有什么區(qū)別？

長輪詢就是客戶端發(fā)送一個請求，服務(wù)端將一直在這個連接上等待（當(dāng)然有一個超長的超時時間），直到有數(shù)據(jù)才返回，它依然是一個一問一答的模式。比如著名的comted。WebSocket在握手成功后，就是全雙工的TCP通道，數(shù)據(jù)可以主動從服務(wù)端發(fā)送到客戶端，處于鏈接兩端的應(yīng)用沒有任何區(qū)別。WebSocket創(chuàng)建的連接和Http的長連接是不一樣的。由于Http長連接底層依然是Http協(xié)議，所以它還是一問一答，只是Hold住了一條命長點的連接而已。長輪詢和Http長連接是阻塞的I/O，但WebSocket可以是非阻塞的（具體是多路復(fù)用）

WebSocket：如何創(chuàng)建一個WebSocket連接？

WebSocket的連接創(chuàng)建是借助Http協(xié)議進行的。這樣設(shè)計主要是考慮兼容性，在瀏覽器中就可以很方便的發(fā)起請求，看起來比較具有迷惑性。

下圖是一個典型的由瀏覽器發(fā)起的ws請求，可以看到和http請求長的是非常相似的。

但是，它只是請求階段長得像而已：

請求的地址: 一般是：ws://***，或者是使用了SSL/TLS加密的安全協(xié)議wss:，用來標(biāo)識是WebSocket請求。

1）首先，通過Http頭里面的Upgrade域，請求進行協(xié)議轉(zhuǎn)換。如果服務(wù)端支持的話，就可以切換到WebSocket協(xié)議。簡單點講：連接已經(jīng)在那了，通過握手切換成ws協(xié)議，就是切換了連接的一個狀態(tài)而已。

2）Connection域可以認(rèn)為是與Upgrade域配對的頭信息。像Nginx等代理服務(wù)器，是要先處理Connection，然后再發(fā)起協(xié)議轉(zhuǎn)換的。

3）Sec-WebSocket-Key 是隨機的字符串，服務(wù)器端會用這些數(shù)據(jù)來構(gòu)造出一個 SHA-1 的信息摘要。如此操作，可以盡量避免普通 HTTP 請求被誤認(rèn)為 WebSocket 協(xié)議。

其他的，像Sec-WebSocket*字樣的頭信息，表明了客戶端支持的子協(xié)議以及其他信息。像loT中很流行的mqtt，就可以作為WebSocket的子協(xié)議。

Python服務(wù)器端開發(fā)

pip install python-socketio

使用協(xié)程的方式運行 (推薦)

  import eventlet
  eventlet.monkey_patch()

  import socketio
  import eventlet.wsgi

  sio = socketio.Server(async_mode='eventlet')  # 指明在evenlet模式下
  App = socketio.Middleware(sio)
  eventlet.wsgi.server(eventlet.listen(('', 8000)), app)

1）事件處理方法

編寫事件處理方法，可以接收指定的事件消息數(shù)據(jù)，并在處理方法中對消息數(shù)據(jù)進行處理。

@sio.on('connect')
def on_connect(sid, environ):
    """
    與客戶端建立好連接后被執(zhí)行
    :param sid: string sid是socketio為當(dāng)前連接客戶端生成的識別id
    :param environ: dict 在連接握手時客戶端發(fā)送的握手?jǐn)?shù)據(jù)(HTTP報文解析之后的字典)
    """
    pass
?
@sio.on('disconnect')
def on_disconnect(sid):
    """
    與客戶端斷開連接后被執(zhí)行
    :param sid: string sid是斷開連接的客戶端id
    """
    pass
?
# 以字符串的形式表示一個自定義事件，事件的定義由前后端約定
@sio.on('my custom event')  
def my_custom_event(sid, data):
    """
    自定義事件消息的處理方法
    :param sid: string sid是發(fā)送此事件消息的客戶端id
    :param data: data是客戶端發(fā)送的消息數(shù)據(jù)
    """
    pass

注意

connect 為特殊事件，當(dāng)客戶端連接后自動執(zhí)行
disconnect 為特殊事件，當(dāng)客戶端斷開連接后自動執(zhí)行
connect、disconnect與自定義事件處理方法的函數(shù)傳入?yún)?shù)不同

2）發(fā)送事件消息

群發(fā)sio.emit('my event', {'data': 'foobar'})
給指定用戶發(fā)送sio.emit('my event', {'data': 'foobar'}, room=user_sid)
給一組用戶發(fā)送SocketIO提供了房間（room）來為客戶端分組sio.enter_room(sid, room_name)將連接的客戶端添加到一個room @sio.on('chat')
def begin_chat(sid):
sio.enter_room(sid, 'chat_users')注意：當(dāng)客戶端連接后，socketio會自動將客戶端添加到以此客戶端sid為名的room中sio.leave_room(sid, room_name)將客戶端從一個room中移除 @sio.on('exit_chat')
def exit_chat(sid):
sio.leave_room(sid, 'chat_users')sio.rooms(sid)查詢sid客戶端所在的所有房間給一組用戶發(fā)送消息的示例@sio.on('my message')
def message(sid, data):
sio.emit('my reply', data, room='chat_users')也可在群組發(fā)消息時跳過指定客戶端@sio.on('my message')
def message(sid, data):
sio.emit('my reply', data, room='chat_users', skip_sid=sid)
使用send發(fā)送message事件消息對于'message'事件，可以使用send方法 sio.send({'data': 'foobar'})
sio.send({'data': 'foobar'}, room=user_sid)

3）Python客戶端

import socketio
?
sio = socketio.Client()
?
@sio.on('connect')
def on_connect():
    pass
?
@sio.on('event')
def on_event(data):
    pass
?
sio.connect('http://10.211.55.7:8000')
sio.wait()

WebSocket：如何使用Nginx做WebSocket的負(fù)載均衡？

nginx官網(wǎng)已經(jīng)給出了例子。主要是Upgrade和Connection頭的設(shè)置。

Nginx的中的配置如下：

map $http_upgrade $connection_upgrade {

default upgrade;

''close;

}

location /chat/{

proxy_pass http://backend;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;

}

需要注意的是，nginx做負(fù)載均衡，不需要配置ip_hash等參數(shù)，nginx天然支持。由于ip_hash僅使用ip地址的前三個數(shù)字做hash，還有可能造成服務(wù)端的不均衡。

特別注意：

在IM聊天系統(tǒng)場景下，Nginx提供給WebSocket的這種所謂的“負(fù)載均衡”，只能解決傳統(tǒng)分布系統(tǒng)中的SLB服務(wù)器要做的事。

通俗地說，Nginx只能幫助完成引導(dǎo)WebSocket客戶連接到哪一個WebSocket服務(wù)端實例，在IM集群情況下，如果兩個用戶處于不同的WebSocket實例下時，它們之間的跨實例通信，Nginx是沒有辦法實現(xiàn)的，這一塊的邏輯還是得IM開發(fā)者自已來實現(xiàn)。

總而言之，Nginx提供給WebSocket的所謂“負(fù)載均衡”，并不是IM開發(fā)者認(rèn)為的那種全功能集群！

一、什么是長連接

HTTP1.1規(guī)定了默認(rèn)保持長連接（HTTP persistent connection ，也有翻譯為持久連接），數(shù)據(jù)傳輸完成了保持TCP連接不斷開（不發(fā)RST包、不四次握手），等待在同域名下繼續(xù)用這個通道傳輸數(shù)據(jù)；相反的就是短連接。

1. HTTP協(xié)議與TCP/IP協(xié)議的關(guān)系

HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接。HTTP屬于應(yīng)用層協(xié)議，在傳輸層使用TCP協(xié)議，在網(wǎng)絡(luò)層使用IP協(xié)議。 IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問題，TCP協(xié)議主要解決如何在IP層之上可靠地傳遞數(shù)據(jù)包，使得網(wǎng)絡(luò)上接收端收到發(fā)送端所發(fā)出的所有包，并且順序與發(fā)送順序一致。TCP協(xié)議是可靠的、面向連接的。

在HTTP/1.0中默認(rèn)使用短連接。也就是說，客戶端和服務(wù)器每進行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問的某個html或其他類型的Web頁中包含有其他的Web資源（如JAVAScript文件、圖像文件、css文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。

**而從HTTP/1.1起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應(yīng)頭加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，客戶端再次訪問這個服務(wù)器時，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。實現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。

**HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接。

**2.1. TCP連接

當(dāng)網(wǎng)絡(luò)通信時采用TCP協(xié)議時，在真正的讀寫操作之前，客戶端與服務(wù)器端之間必須建立一個連接，當(dāng)讀寫操作完成后，雙方不再需要這個連接時可以釋放這個連接。連接的建立依靠“三次握手”，而釋放則需要“四次握手”，所以每個連接的建立都是需要資源消耗和時間消耗的。

**2.2. TCP短連接

模擬一下TCP短連接的情況：client向server發(fā)起連接請求，server接到請求，然后雙方建立連接。client向server發(fā)送消息，server回應(yīng)client，然后一次請求就完成了。這時候雙方任意都可以發(fā)起close操作，不過一般都是client先發(fā)起close操作。上述可知，短連接一般只會在 client/server間傳遞一次請求操作。

短連接的優(yōu)點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。

2.3. TCP長連接

我們再模擬一下長連接的情況：client向server發(fā)起連接，server接受client連接，雙方建立連接，client與server完成一次請求后，它們之間的連接并不會主動關(guān)閉，后續(xù)的讀寫操作會繼續(xù)使用這個連接。

TCP的保活功能主要為服務(wù)器應(yīng)用提供。如果客戶端已經(jīng)消失而連接未斷開，則會使得服務(wù)器上保留一個半開放的連接，而服務(wù)器又在等待來自客戶端的數(shù)據(jù)，此時服務(wù)器將永遠等待客戶端的數(shù)據(jù)。保活功能就是試圖在服務(wù)端器端檢測到這種半開放的連接。

如果一個給定的連接在兩小時內(nèi)沒有任何動作，服務(wù)器就向客戶發(fā)送一個探測報文段，根據(jù)客戶端主機響應(yīng)探測4個客戶端狀態(tài)：

客戶主機依然正常運行，且服務(wù)器可達。此時客戶的TCP響應(yīng)正常，服務(wù)器將保活定時器復(fù)位。

客戶主機已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動。上述情況下客戶端都不能響應(yīng)TCP。服務(wù)端將無法收到客戶端對探測的響應(yīng)。服務(wù)器總共發(fā)送10個這樣的探測，每個間隔75秒。若服務(wù)器沒有收到任何一個響應(yīng)，它就認(rèn)為客戶端已經(jīng)關(guān)閉并終止連接。

客戶端崩潰并已經(jīng)重新啟動。服務(wù)器將收到一個對其保活探測的響應(yīng)，這個響應(yīng)是一個復(fù)位，使得服務(wù)器終止這個連接。

客戶機正常運行，但是服務(wù)器不可達。這種情況與第二種狀態(tài)類似。

長連接和短連接的優(yōu)點和缺點

由上可以看出，長連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費，節(jié)約時間。對于頻繁請求資源的客戶端適合使用長連接。在長連接的應(yīng)用場景下，client端一般不會主動關(guān)閉連接，當(dāng)client與server之間的連接一直不關(guān)閉，隨著客戶端連接越來越多，server會保持過多連接。這時候server端需要采取一些策略，如關(guān)閉一些長時間沒有請求發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損；如果條件允許則可以限制每個客戶端的最大長連接數(shù)，這樣可以完全避免惡意的客戶端拖垮整體后端服務(wù)。

短連接對于服務(wù)器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關(guān)閉操作上浪費較多時間和帶寬。

長連接和短連接的產(chǎn)生在于client和server采取的關(guān)閉策略。不同的應(yīng)用場景適合采用不同的策略。

由上可以看出，長連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費，節(jié)約時間。對于頻繁請求資源的客戶來說，較適用長連接。不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，屬于比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應(yīng)用場景下，client端一般不會主動關(guān)閉它們之間的連接，Client與server之間的連接如果一直不關(guān)閉的話，會存在一個問題，隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數(shù)，這樣可以完全避免某個蛋疼的客戶端連累后端服務(wù)。

短連接對于服務(wù)器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關(guān)閉操作上浪費時間和帶寬。

長連接和短連接的產(chǎn)生在于client和server采取的關(guān)閉策略，具體的應(yīng)用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。

長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創(chuàng)建也是對資源的浪費。

而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因為長連接對于服務(wù)端來說會耗費一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好。