WebSocket的消息能排隊

Question

我們有一個服務器，使用龍捲風寫，它比的WebSockets發送異步消息給客戶端。在這種情況下，Mac上的Chrome中運行的JavaScript應用程序。當客戶端強制掛斷，在這種情況下，通過將客戶睡覺，服務器仍然認爲它是將消息發送到客戶端。另外，當客戶從睡眠中喚醒時，消息會突然傳送。

這些消息排隊/緩衝的機制是什麼？誰是負責的人？他們爲什麼仍然交付？誰正在重新連接套接字？我的直覺是，儘管websockets不像HTTP這樣的請求/響應，但它們仍然需要ACK數據包，因爲它們是建立在TCP上的。這是否是爲了使協議在移動時代的臨時丟失更有力？

Answer 1

瀏覽器可以在單獨的線程中處理websocket客戶端消息，而不會被睡眠阻塞。

即使您的自定義應用程序的線程未處於活動狀態，但當您強制其進入睡眠狀態（如sleep（100））時，TCP連接在此情況下仍未關閉。套接字句柄仍由OS內核管理，並且TCP服務器仍然發送消息，直到它到達TCP客戶端的接收窗口溢出。即使在此之後在服務器端的應用程序仍然可以成功提交新的消息，這是在TCP級緩存在服務器端，直到TCP傳出緩衝區溢出是。當傳出緩衝區已滿時，應用程序應在發送請求時收到錯誤代碼，如「不再有空間」。我沒有嘗試過自己，但它應該像這樣。

嘗試關閉客戶端（終止進程），您將看到完全不同的圖片 - 服務器將通知斷開連接。

這兩種情況下，斷開和溢出，都很難在服務器端處理高可靠性場景。斷開的情況下可以被轉化成溢出的情況下（當客戶端被重新連接的WebSocket服務器可以緩衝消息到用戶空間中的一些限制）。但是，沒有簡單的方法來可靠地處理髮送緩衝區限制的溢出。我只看到一個解決方案 - 傳播溢出錯誤回到事件，這引起了該消息，已因溢出丟棄的鼻祖。