先說一下網絡的層級：由下往上分為 物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層
1、TCP和UDP
TCP：是面向連接的一種傳輸控制協議。屬於傳輸層協議。TCP連接之后，客戶端和服務器可以互相發送和接收消息，在客戶端或者服務器沒有主動斷開之前，連接一直存在屬於長連接。
優點：安全、傳輸數據無大小限制、准確可靠，先發先至
缺點：效率低，不能做離線任務、連接有耗時
UDP：是面向非連接的用戶數據報協議。屬於傳輸層協議。所謂的無連接就是在傳輸數據之前不需要交換信息，沒有握手建立連接的過程，只需要直接將對應的數據發送到指定的地址和端口就行。
例：我不管你要不要，我就一直發給你。就好比QQ消息一樣，當你離線的時候仍然可以收到消息
優點：可以傳輸大文件，速度快，效率高
缺點：不安全，容易丟包（數據）、先發未必先至
補充：
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連接的請求，斷開過程需要經過“四次握手”
因為當A給B發送消息時，只有B同意了才能傳輸。由此可以看出HTTP協議是基於TCP的。因為當你在向后台請求數據的時候，后台必須同意，你才可以請求，否則都是白扯
2、HTTP
HTTP是基於TCP協議的應用的超文本傳輸協議，屬於應用層的協議。請求時需建立TCP連接，請求結束后斷開連接，完成一次請求/響應操作。
HTTP協議永遠都是客戶端發起請求，服務器回送響應，這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，服務器將消息推送給客戶端。
HTTP協議是一個無狀態的協議，同一個客戶端的這次請求和上次請求是沒有對應關系。
優點：基於應用級的接口使用方便
缺點：(1)傳輸速度慢，數據包大。(2)如實現實時交互，服務器性能壓力大。(3)數據傳輸安全性差
注意：服務器不會主動給客戶端發送數據。
3、Socket
Socket是對TCP/IP協議的封裝，Socket本身並不是協議，而是一個調用接口（API）
Socket連接需要一對套接字，一個運行於客戶端，另一個運行於服務端！之間的連接分為三個步驟：服務器監聽，客戶端請求，連接確認。
（1）服務器監聽：是服務端套接字並不定位具體的客戶端套接字，而是處於等待連接的狀態，實時監控網絡狀態。
（2）客戶端請求：是由客戶端的套接字提出連接請求，要連接的目標是服務端的套接字。所以客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字的地址和端口號，然后就向服務器端套接字提出連接請求。
（3）連接確認：是指當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求，它就響應客戶端套接字的請求，建立一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，連接就建立好了。而服務器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求。
4、WebSocket
雖然叫WebSocket，但它與Socket沒有任何關系。就好比：Java與JavaScript，雷鋒與雷峰塔，印度與印度尼西亞，黑客與博客的關系，兩者沒有任何關系！
WebSocket也是一種協議，並且也是基於TCP協議的。可以理解為WebSocket是HTTP的優化，但WebSocket不僅僅在Web應用程序上得到支持。
WebSocket雖然是Html5的產物，但也不僅僅局限於瀏覽器的應用程序，許多語言都提供了WebSocket的支持，比如C，C++，Python等
在WebSocket概念出來之前，如果頁面要不停地顯示最新的價格，那么必須不停地刷新頁面，或者用一段js代碼每隔幾秒鍾發消息詢問服務器數據。
而使用WebSocket技術之后，當服務器有了新的數據，會主動通知瀏覽器。 如當服務端有新的比特幣價格之后，瀏覽器立馬接收到消息。
webSocket優點：
1. 節約帶寬。不停地輪詢服務端數據這種方式，使用的是http協議，head信息很大，有效數據占比低， 而使用WebSocket方式，頭信息很小，有效數據占比高。
2. 無浪費。 輪詢方式有可能輪詢10次，才碰到服務端數據更新，那么前9次都白輪詢了，因為沒有拿到變化的數據。 而WebSocket是由服務器主動回發，來的都是新數據。
3. 實時性，考慮到服務器壓力，使用輪詢方式不可能很短的時間間隔，否則服務器壓力太多，所以輪詢時間間隔都比較長，好幾秒，設置十幾秒。 而WebSocket是由服務器主動推送過來，實時性是最高的。
Websocket的作用
在講Websocket之前，我就順帶着講下 long poll 和 ajax輪詢 的原理。
ajax輪詢
首先是 ajax輪詢 ，ajax輪詢 的原理非常簡單，讓瀏覽器隔個幾秒就發送一次請求，詢問服務器是否有新信息。
場景再現：
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：沒有。。（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務端：你好煩啊，沒有啊。。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：好啦好啦，有啦給你。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務端：。。。。。沒。。。。沒。。。沒有（Response） ---- loop
long poll
long poll 其實原理跟 ajax輪詢 差不多，都是采用輪詢的方式，不過采取的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起連接后，如果沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完之后，客戶端再次建立連接，周而復始。
場景再現
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）
服務端：額。。 等待到有消息的時候。。來 給你（Response）
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop
從上面可以看出其實這兩種方式，都是在不斷地建立HTTP連接，然后等待服務端處理，可以體現HTTP協議的另外一個特點，被動性。
何為被動性呢，其實就是，服務端不能主動聯系客戶端，只能有客戶端發起。
簡單地說就是，服務器是一個很懶的冰箱（這是個梗）（不會、不能主動發起連接），但是上司有命令，如果有客戶來，不管多么累都要好好接待。
說完這個，我們再來說一說上面的缺陷（原諒我廢話這么多吧OAQ）
從上面很容易看出來，不管怎么樣，上面這兩種都是非常消耗資源的。
ajax輪詢 需要服務器有很快的處理速度和資源。（速度）
long poll 需要有很高的並發，也就是說同時接待客戶的能力。（場地大小）
所以ajax輪詢 和long poll 都有可能發生這種情況。
客戶端：啦啦啦啦，有新信息么？
服務端：月線正忙，請稍后再試（503 Server Unavailable）
客戶端：。。。。好吧，啦啦啦，有新信息么？
服務端：月線正忙，請稍后再試（503 Server Unavailable）
--------------------------
言歸正傳，我們來說Websocket吧
通過上面這個例子，我們可以看出，這兩種方式都不是最好的方式，需要很多資源。
一種需要更快的速度，一種需要更多的'電話'。這兩種都會導致'電話'的需求越來越高。
哦對了，忘記說了HTTP還是一個無狀態協議。（感謝評論區的各位指出OAQ）
通俗的說就是，服務器因為每天要接待太多客戶了，是個健忘鬼，你一掛電話，他就把你的東西全忘光了，把你的東西全丟掉了。你第二次還得再告訴服務器一遍。
所以在這種情況下出現了，Websocket出現了。
他解決了HTTP的這幾個難題。
首先，被動性，當服務器完成協議升級后（HTTP->Websocket），服務端就可以主動推送信息給客戶端啦。
所以上面的情景可以做如下修改。
客戶端：啦啦啦，我要建立Websocket協議，需要的服務：chat，Websocket協議版本：17（HTTP Request）
服務端：ok，確認，已升級為Websocket協議（HTTP Protocols Switched）
客戶端：麻煩你有信息的時候推送給我噢。。
服務端：ok，有的時候會告訴你的。
服務端：balabalabalabala
服務端：balabalabalabala
服務端：哈哈哈哈哈啊哈哈哈哈
服務端：笑死我了哈哈哈哈哈哈哈
就變成了這樣，只需要經過一次HTTP請求，就可以做到源源不斷的信息傳送了。（在程序設計中，這種設計叫做回調，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你）
這樣的協議解決了上面同步有延遲，而且還非常消耗資源的這種情況。
那么為什么他會解決服務器上消耗資源的問題呢？
其實我們所用的程序是要經過兩層代理的，即HTTP協議在Nginx等服務器的解析下，然后再傳送給相應的Handler（PHP等）來處理。
簡單地說，我們有一個非常快速的接線員（Nginx），他負責把問題轉交給相應的客服（Handler）。
本身接線員基本上速度是足夠的，但是每次都卡在客服（Handler）了，老有客服處理速度太慢。，導致客服不夠。
Websocket就解決了這樣一個難題，建立后，可以直接跟接線員建立持久連接，有信息的時候客服想辦法通知接線員，然后接線員在統一轉交給客戶。
這樣就可以解決客服處理速度過慢的問題了。
雖然接線員很快速，但是每次都要聽這么一堆，效率也會有所下降的，同時還得不斷把這些信息轉交給客服，不但浪費客服的處理時間，而且還會在網路傳輸中消耗過多的流量/時間。
但是Websocket只需要一次HTTP握手，所以說整個通訊過程是建立在一次連接/狀態中，也就避免了HTTP的非狀態性，服務端會一直知道你的信息，直到你關閉請求，這樣就解決了接線員要反復解析HTTP協議，還要查看identity info的信息。
同時由客戶主動詢問，轉換為服務器（推送）有信息的時候就發送（當然客戶端還是等主動發送信息過來的。。），沒有信息的時候就交給接線員（Nginx），不需要占用本身速度就慢的客服（Handler）了。