mysql字體模糊查詢，WebSocket是什么原理？

首先我們看一下websocket的出現背景，我們知道http系列協議是建立在tcp上的，理論上，他是可以可以雙向通信的。但是http1.1之前，服務器沒有實現推送的功能。每次都是客戶端請求，服務器響應。下面看一下http協議關于請求處理的發展。

http1.0的時候，一個http請求的生命周期是客戶端發起請求，服務器響應，斷開連接。但是我們知道tcp協議的缺點就是，三次握手需要時間，再加上慢開始等特性，每一個http請求都這樣的話，效率就很低。http1.1的時候，默認開啟了長連接（客戶端請求中設置了keep-alive頭），服務器處理一個請求后，不會立刻關閉連接，而是會等待一定的時間。如果沒有請求才關閉連接。這樣瀏覽器不僅可以在一個tcp連接中，不斷地發送請求（服務器也會限制一個連接上可以處理的請求閾值），甚至可以一次發很多個請求。這就是http1.1的管道化（pipeline）技術。但是他也有個問題，因為對于基于http協議的客戶端來說，雖然他可以發很多請求出去，但是當一個請求對于的回包回來時，他卻無法分辨是屬于哪個請求的。所以回包只能按請求順序返回，這就引來了另一個問題-線頭阻塞(Head-of-Link Blocking)。并且http1.1雖然支持長連接，但是他不支持服務端推送（push）的能力。如果服務器有數據要給客戶端，也只能等著客戶端來取（pull）。來到了http2.0，不僅實現了服務器推送，還使用了幀（iframe），流（stream）等技術解決了線頭阻塞的問題，http2.0在一個tcp連接中，可以同時發送多個http請求，每個請求是一個流，一個流可以分成很多幀，有了標記號，服務器可以隨便發送回包，客戶端收到后，根據標記，重新組裝就可以。以上是http協議的關于請求的一些發展，而websocket就服務端推送提供了另外一種解決方案。他本質上是在tcp協議上封裝的另一種應用層協議（websocket協議）。因為他是基于tcp的，所以服務端推送自然不是什么難題。但是在實現上，他并不是直接連接一個tcp連接，然后在上面傳輸基于websocket協議的數據包。他涉及到一個協議升級（交換）的過程。我們看看這個過程。1 客戶端發送協議升級的請求。在http請求加上下面的http頭

2 服務器如果支持websocket協議的話，會返回101狀態碼表示同意協議升級，并且支持各種配置（如果服務器不支持某些功能或版本，或告訴客戶端，客戶端可以再次發送協議升級的請求）。服務會返回形如下面的http頭（可以參考websocket協議)。

3 這樣就完成了協議的升級，后續的數據通信，就是基于tcp連接之上，使用websocket協議封裝的數據包。

下面我們通過wireshark來了解這個過程。首先我們啟動一個服務器（ip：192.168.8.226）。

我們可以直接在瀏覽器控制臺進行測試

這時候，我們看看wireshark的包。

首先看前面三條記錄，這是tcp三次握手的數據包。這個我們都了解了，就不展示。接著看第四條記錄。展開后如下。

我們看到建立tcp連接后，瀏覽器發了一個http請求，并帶上了幾個websocket的數據包。接著看下面的一條。

服務返回了同意升級協議或者說交換協議。從服務器代碼中我們看到，在建立連接的時候我們給瀏覽器推送了一個get it的字符串。繼續看上面的記錄。

這就是服務器給瀏覽器推送的基于websocket協議的數據包。具體每個字段什么意思，參考websocket協議就可以。繼續往下看一條記錄是針對服務器推送的數據包的一個tcp的ack。最后我們可以順便看看最后三條寫著keep-alive的記錄。這就是之前文章里講到的tcp層的keep-alive。因為我們一直沒有數據傳輸，所以tcp層會間歇性地發送探測包。我們可以看看探測包的結構。

有一個字節的探測數據。如果這時候我們發送一個數據包給服務器，又是怎樣的呢。

白色背景的三條數據，分別是瀏覽器發送給服務器的數據，服務器推送回來的數據。tcp的ack。我們發現，服務器給瀏覽器推送的時候，瀏覽器會發送ack，但是瀏覽器給服務器發送的時候，服務器貌似沒有返回ack。下面我們看看為什么。首先我們看瀏覽器發出的包。

再看看服務器給瀏覽器推送的數據包。

我們發現服務器（tcp）推送消息的時候把ack也帶上了。而不是發送兩個tcp包。這就是tcp的機制。tcp不會對每個包都發ack，他會累積確認（發ack），以減少網絡的包，但是他也需要保證盡快地回復ack，否則就會導致客戶端觸發超時重傳。tcp什么時候發送確認呢？比如需要發送數據的時候，或者超過一定時間沒有收到數據包，或者累積的確認數量達到閾值等。既然研究了tcp，我們不妨多研究點，我們看一下，如果這時候關閉服務器會怎樣。

服務器會發送一個重置包給瀏覽器，告訴他需要斷開連接。繼續，如果是瀏覽器自己調用close去關閉連接會怎樣。

我們看到websocket首先會發送一個FIN包給服務器，然后服務器也會返回一個FIN包，然后才開始真正的四次揮手過程。并且四次揮手的第一個fin包是服務器發的。

我們再來看看安全版本的websocket。我們啟動一個https服務器。

然后在瀏覽器控制臺執行。

然后來看看wireshark。

首先建立tcp連接，然后建立tls連接。后續的數據通信就可以基于加密來進行了。不再重復。后續分析tls協議的時候再分析。

經過一系列的分析，我們對websocket協議應該有了更多的了解，最后再說一個關于websocket的點。我們發現如果在websocket連接上，一直不通信的話，websocket連接所維持的時間是依賴tcp實現的。因為我們發現tcp層會一直發送探測包。達到閾值之后，連接就會被斷開。所以我們想維持websocket連接的話，需要自己去發送心跳包，比如ping，pong。

總結：本文分析了websocket的基本原理，但不涉及協議的內容，如需了解協議的內容，可以參考rfc文檔。