最近做新項目累榜，遇到一個問題，
現(xiàn)象是人多了之后富弦，客戶端就有很大概率無法登錄沟娱，或者進(jìn)去之后過一段時間 就斷線了，
客戶端每次說是服務(wù)器給斷線了腕柜。 但是服務(wù)器代碼我確認(rèn)了幾次济似， 除了崩潰是不會主動斷線的
加上客戶端自己的電腦上矫废，一直沒有出現(xiàn)過這個問題，所以他也拖著不查
wireshark客戶端抓包看的是 客戶端一直在重復(fù)的發(fā) ack 碱屁，找 服務(wù)器要包磷脯。。娩脾。
難道內(nèi)網(wǎng)環(huán)境也會丟包赵誓？
我還一度懷疑是 服務(wù)器的erlang delay_send 參數(shù)的問題，關(guān)了之后柿赊，發(fā)現(xiàn)問題還在
服務(wù)器抓包俩功，看的是其實包大小只有3.7k，已經(jīng)發(fā)了碰声，不過是分了兩次發(fā)的(2920 + 786)
好不容易說服客戶端去debug
客戶端debug： 發(fā)現(xiàn)讀的包頭是一個巨大的數(shù)字 诡蜓。。胰挑。他還懷疑是網(wǎng)絡(luò)字節(jié)序的問題蔓罚，
不過erlang的包頭是erlang虛擬機加的，理論上應(yīng)該不會出這種問題瞻颂，而且sgame已經(jīng)驗證好幾年了
無奈豺谈，只能在客戶端收包的地方加斷點debug，發(fā)現(xiàn)客戶端包沒收完贡这，也會每次讀的時候先讀一個包頭大小的長度
懷疑是客戶端沒有做分包的合并邏輯
最后發(fā)現(xiàn)：是客戶端的拼包邏輯有問題（網(wǎng)上拷貝代碼改的）茬末，某些地方是按4個字節(jié)讀的，某些地方是按2個字節(jié)讀的（沒改全）
然后不應(yīng)該讀包頭的地方盖矫，去讀了包頭丽惭，就得到一個巨大的數(shù)字
表現(xiàn)就是客戶端一直問服務(wù)器要數(shù)據(jù)，而服務(wù)器早已經(jīng)發(fā)完了辈双，就互相等待责掏。
最終分析：這個問題只有在服務(wù)器下發(fā)的數(shù)據(jù)分包了，且客戶端某次沒有一次收全整個包體的時候才會出現(xiàn)辐马。
服務(wù)器抓到的包：
