先說一下網路的層級：由下往上分為 物理層、資料鏈路層、網路層、傳輸層、會話層、表示層和應用層

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的作用
在講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就解決了這樣一個難題，建立後，可以直接跟接線員建立持久連線，有資訊的時候客服想辦法通知接線員，然後接線員在統一轉交給客戶。
這樣就可以解決客服處理速度過慢的問題了。