測試過程：（每次測試只取第一次流程的記錄）
i.webshop不變化，拉取最新backend-ms代碼部署
1.打開webshop
2.打開simulator app
3.執行所有api
ii.最新的backend-ms不變化，拉取最新的webshop代碼部署
1.打開webshop，
2.打開simulator app，
3.執行所有api
疑惑點：這里列出我發現的有點奇怪的地方，也許對找到原因會有所幫助。
日志中backend-ms與webshop的每次通信，require，response都是只有一次記錄，

（截圖來自log_latestBackend_with_oldFrontend）
但是backend-ms和simulator的通信，request和response的記錄都不止一次，比如confirmRequest的request有三個，第二次比第一次添加了clientAddress，第三次和第二次內容重復
這里是不是因為在wsServer在對請求的處理過程中有多個log語句？

（截圖來自log_latestBackend_with_oldFrontend）
然后還有下面這張截圖，FieldUpdate時間的response有4個response，而且每個的clientSocketID都不一樣，但是我當時只開了一個網頁，對應的是第四個（最后一條）response的clientSocketID.而在日志開頭，也只有一條webshop的接入的記錄。下面這張截圖來自第二次測試，第一冊測試也有相同的問情況，但是只有2個response，截圖附在更下面。

（截圖來自log_latestBackend_with_latestFrontend）
同樣是只開了一個webshop，該webshop對應的clientSocketID對應第二條（最后一條）response。

（截圖來自log_latestBackend_with_oldFrontend）
我們在分析日志之前，應該盡可能排除所有的干擾因素，這樣做出的判斷才準確。

分析日志之前，應該先停掉server，把日志文件清空。

確保啟動的server只有你一個人的web shop使用到。這個可以通過我之前在微信上的描述，即修改server配置文件里的監聽端口，啟動一組新的server，這些server監聽的端口和Oliver他們正常測試使用的server的監聽端口互不相同。這樣大家可以并行工作，互不干擾。

每個web shop實例給WebSocket服務器發送請求時，附上自己的unique ID(human readable), WebSocket server接到請求后打印出這個unique id，這樣服務器就知道到底是哪一個具體的Web Shop實例發起的請求了。
要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的通过服务器端日志分析WebSocket的server和client交互的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。