時隔N年，第二次在csdn發帖，不足之處，謝謝指正
由于筆者公司是做物聯網這一塊的，用到了tcp協議傳遞訊息，筆者主要是負責tcp client這一塊的開發，基本上邏輯很簡單，連上服務器，發送認證，等待回傳，如果成功、發送心跳、處理心跳回傳，接受服務端的下發控制指令； 如果認證失敗，超時后繼續重連服務器，發送認證... 基本沒有任何問題。如果說是客戶端某些情況下無法重連服務器，那是客戶端的bug。
就是服務端每次更新重啟之后，大量客戶端開始發送登錄認證，就導致服務端出問題，表現現象如下：
1、有的客戶端已經認證發送了，服務器也回傳認證成功了，之后心跳都正常，服務端有時候顯示設備還是離線，有時候顯示在線，但是此時客戶端不能收到任何服務器的控制訊息，我說是服務端的問題，他說是我客戶端的問題，根本扯不清
2、另外有這種情況，客戶端拔掉電源，之后服務器重啟，服務器顯示設備還是在線，按理說，tcp服務重啟之后，之前記錄的所有的tcp會話id都沒有意義了，所以一般不用持久化存盤的對吧，都是保存在記憶體里面的吧，我不清楚為什么他們用的持久化存盤
另外，不清楚那些諸如騰訊公司的qq、微信，包括認證，狀態存盤等等都是怎么tcp和服務器進行通訊的，先說說我們目前的設計問題點：
1、tcp訊息傳輸限制在65535，因為他們設計的包頭就兩個位元組，用的Netty分隔符解碼器DelimiterBasedFrameDecoder，我個人覺得這樣拆包效率太低，是不是應該考慮LengthFieldBasedFrameDecoder分包機制效率最高
2、tcp包運載效率太低，即使心跳包實際傳輸內容為空的情況下，還會產生62位元組的資料包，因為他們要求每個tcp包都要把認證資訊附帶上，不清楚為什么這么做
3、按理說tcp只有第一次連接時候需要認證，之后只要當前tcp連接不斷開，tcp會話id并不會發生變化，認證身份也不會發生變化，不需要每條訊息都驗證吧，個人覺得每次都校驗資料包無故浪費大量服務器運算資源，也可能導致服務器在每次重啟后瞬間根本處理不過來
4、他們所有tcp包資料做了xor運算，得到一個值，接收方每次都要計算一遍，但是不能實作加密，資料在公網上處于裸奔狀態，另外tcp通訊已經實作可靠傳輸，個人覺得純屬多余
5、是不是應該考慮TLS加密，包括證書的認證，管理等等？
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/83804.html
標籤：Java EE