做了不少物聯網通訊上的模組，也看過了各種各樣的協議解析，也學習了不少開源軟體的網路互動方式，不談那些http和其他一些封裝好的處理方法，總認為tcp丟包或者包錯了，那就會導致解析模組很容易卡住，比如長度位錯了，你還要一直找協議頭，始終找不到，
群裡大佬都說tcp丟包和錯包不用考慮，那是硬體問題或系統問題，不要考慮。。。
查了下資料tcp層有可能丟包，比如型號衰減或者網路阻塞等情況，但是這些情況與應用層無關，並且tcp有重傳機制和其他安全性機制保證應用層意義上的包的連續性和完整性，所以從應用層協議的角度來看tcp層是不會丟包的。這個是我個人理解，現在公司的應用場景都是小範圍的傳輸，確實沒有丟包這種事情。但是做服務端，那種長距離傳輸我也不知道是什麼樣子，反正在短距離傳輸，不用考慮這個了。可能有理解錯的地方，希望大家提點指出。
糟糕的應用層通訊協議設計
去年和今年分別參與了兩個公司的專案，這兩個專案都涉及到了通訊方面的程式設計，或者是以太網路通訊，或者是串列埠通訊。凡是通訊就必須要有通訊協議，個人認為協議的設計是個非常嚴肅的工作，需要理解業務需求和掌握基本的協議設計知識。但是從這兩個專案來看，其協議的設計可以說是 糟糕到了極點。下面就其糟糕的設計之...
親歷的幾個糟糕的應用層通訊協議設計
去年和今年分別參與了兩個公司的專案，這兩個專案都涉及到了通訊方面的程式設計，或者是以太網路通訊，或者是串列埠通訊。凡是通訊就必須要有通訊協議，個人認為協議的設計是個非常嚴肅的工作，需要理解業務需求和掌握基本的協議設計知識。但是從這兩個專案來看，其協議的設計可以說是糟糕到了極點。下面就其糟糕的設計之處...
STM32開發 UART應用層通訊協議分析
拿到乙份uart的通訊協議，上手來操作之前先做一下分析。先看一下它的幀格式說明 1 幀頭標誌head 不論是命令幀還是響應幀，幀頭標誌都是0x92。2 協議版本 協議版本號 4bit 目前值為1 加密方式 4bit 0表示採取 資料不加密 校驗和 方式。所以，當前此欄位完整值為0x10 3 控制欄位...