什麼是WebSockets！？

到目前為止，我們已經深入到實時世界，因為許多應用程式使用實時資料。 現在正是以技術立場解釋所有導致這一點的事件的時候了。 所以，這裡......

目前，應用程式正在從利用資料庫中的陳舊資料或在實際事件之後的實時體驗中事件觸發後即時建立的資料轉變。 我們在實時應用程式中首先想到的是 WebSockets 。 但是，儘管很多人不斷在技術圈中圍繞這個術語，但實際上似乎存在與其意義和工作相關的巨大誤解。

讓我們破解行話並瞭解正在發生的事情！

HTTP - >長輪詢 - > WebSockets

回到當天，HTTP的無狀態請求 - 響應機制非常適合當天的用例，讓任何兩個節點透過網際網路進行通訊。 由於它都是無狀態的，即使連線斷開，您也可以輕鬆地從那一點恢復通訊。

然而，隨著應用程式轉向實時實現，即確保在現實世界中建立共享資料時的最小延遲，傳統的請求 - 響應週期被證明是一個巨大的開銷。 為什麼？ 高頻請求 - 響應週期導致更多延遲，因為每個週期都需要每次都建立新連線。

從邏輯上講，下一步是為相同數量的資料流最小化這些週期的方法。 解？ 長輪詢！

透過長輪詢，底層TCP套接字連線可以持續一段時間，即連線可以保持開啟狀態比平時更長。 這不僅使伺服器有機會整理多個資料以在單個響應中發回，而不是在單個響應中傳送，而且，它幾乎完全消除了由於缺少資料而返回空響應的情況。現在伺服器只要有實際回饋的資料就可以返回響應。

但是，即使長輪詢技術也涉及連線建立和頻繁的請求 - 響應週期，類似於傳統的HTTP，當然，這會導致更多的延遲。

對於大多數實時應用程式而言，資料的速度（最接近最接近的毫秒數）絕對至關重要，因此上述兩種選項均未被證明是有用的。

然後怎樣呢？

自從我透過提及WebSockets開始撰寫文章以來，你顯然會猜到我得到了什麼。

因此，與HTTP不同，WebSockets是一種透過TCP工作的有狀態通訊協議。

通訊最初是作為HTTP握手開始的，但如果兩個通訊方同意繼續透過WebSockets，則連線只是提升，從而產生全雙工，持久連線。 這意味著連線在應用程式執行時的整個持續時間內保持開啟狀態。 這為伺服器提供了一種啟動任何通訊並將資料傳送到預訂客戶端的方法，因此他們不必繼續傳送詢問新資料可用性的請求。

實際應用程式實際上發生了很多事情，而不是我在本文中簡單總結的內容。