起因
以前一個(gè)小項(xiàng)目的后臺(tái)接口是某PHP的哥們寫的榜苫，然后可能他不知道從哪里看了一篇毒雞湯，說什么大神的成長(zhǎng)之路践磅，都是要對(duì)以前的代碼不停的重構(gòu)单刁，要追求完美，然后認(rèn)真勤奮的把代碼重構(gòu)了一遍府适，重構(gòu)完還興致勃勃的給我發(fā)微信：“爭(zhēng)哥我把代碼重構(gòu)了一遍特順暢特牛逼羔飞，你趕快起個(gè)模塊測(cè)一下￠艽海”
當(dāng)我讀到這條消息的同時(shí)逻淌，客戶那邊候總的電話就打過來了：“搞什么鬼，我這200臺(tái)機(jī)器就快退役了疟暖，忽然今天TM的全都不能用了卡儒，客戶投訴電話都給我打爆了，趕快給我處理一下俐巴」峭”我特么內(nèi)心咯噔一下，肯定是小趙重構(gòu)代碼的鍋欣舵，然后立刻告訴候總擎鸠，我們服務(wù)器遭到黑客攻擊，正在搶修缘圈，這屬于天災(zāi)人禍不可抗力劣光，誰也沒辦法袜蚕。
經(jīng)過各種確認(rèn)，模塊有個(gè)致命BUG绢涡，如果服務(wù)器不停止工作還好牲剃，一旦停止工作，這個(gè)BUG就暴露出來了雄可，再也連不上服務(wù)器凿傅。需要把這分布在好幾個(gè)城市的200多臺(tái)機(jī)器，人工拆卸掉模塊数苫，重新燒錄固件安裝回去狭归。然后我想起姜文的電影《讓子彈飛》中湯師爺?shù)脑挾嗝吹恼_。
這冤鼓文判，乾隆那時(shí)候設(shè)的过椎，這都一百多年了。你要把它砍了戏仓，把鼓露出來疚宇，不定出多大冤吶
這說明了一個(gè)深刻的道理啊，100多年前的陳年老代碼赏殃，馬上就要退役了敷待，千萬一定不要瞎JB折騰，不定出多大BUG吶仁热！
經(jīng)過
在找模塊廠的工程師調(diào)試的時(shí)候榜揖，請(qǐng)求服務(wù)器返回的數(shù)據(jù)又有問題了，數(shù)據(jù)塊前面多了0x33 0x39抗蠢，后面多了0x30举哟，還給我截了圖，讓我去用Wireshark抓包自己看數(shù)據(jù)迅矛。
一開始用postman來測(cè)試妨猩，返回的字符串肉眼看，內(nèi)容是沒問題的秽褒，但是有可能是在編碼過程中自動(dòng)忽略了亂碼信息壶硅，所以我又寫一段程序?qū)ｉT來看返回的數(shù)據(jù)，直接打印URLConnection的InputStream销斟。
public static String sendPost(String url, String param) {
PrintWriter out = null;
BufferedReader in = null;
String result = "";
try {
URL realUrl = new URL(url);
URLConnection conn = realUrl.openConnection();
conn.setRequestProperty("accept", "*/*");
conn.setRequestProperty("connection", "Keep-Alive");
conn.setRequestProperty("user-agent",
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1)");
conn.setDoOutput(true);
conn.setDoInput(true);
out = new PrintWriter(conn.getOutputStream());
out.print(param);
out.flush();
byte[] toString = new byte[1024];
int toStringPos =0;
InputStream ins = conn.getInputStream();
int len =0;
byte[] buffer = new byte[20];
while((len = ins.read(buffer)) != -1) {
byte[] data = new byte[len];
System.arraycopy(buffer, 0, data, 0, len);
System.out.println(SendPack.toHexString(data));
System.arraycopy(buffer, 0, toString, toStringPos, len);
toStringPos = toStringPos+len;
}
System.out.println("====================");
System.out.println(SendPack.toHexString(toString,0,toStringPos));
System.out.println(new String(toString,0,toStringPos));
System.out.println(new String(toString,0,toStringPos).length());
} catch (Exception e) {
e.printStackTrace();
}
finally{
try{
if(out!=null){
out.close();
}
if(in!=null){
in.close();
}
}
catch(IOException ex){
ex.printStackTrace();
}
}
return result;
}
結(jié)果也完全正確,中間省略號(hào)省去數(shù)據(jù)內(nèi)容
[7b,......, 6d]
[71,......, 2c]
[22, 6d, ,......, 7d, 7d]
====================
[7b, ,......, 7d, 7d]
{"code":0,"data":{"m..p":"1.....5","m....t":"...."}}
57
完全正確的內(nèi)容庐椒，為什么單片機(jī)就是無法解析呢，我覺得有點(diǎn)詭異蚂踊，又自己去下載個(gè)Wireshark约谈，這個(gè)工具我用很少，又是折騰半天搞定。
先選擇當(dāng)前正在使用的本地連接窗宇，雙擊，然后會(huì)看到一堆數(shù)據(jù)跳動(dòng)特纤，
在上面的欄里輸入過濾規(guī)則军俊，因?yàn)槲抑婪?wù)器IP，所以我的規(guī)則是：
ip.addr == 192..1.1
然后運(yùn)行上面代碼捧存，看到過濾數(shù)據(jù)包粪躬，選中第3行，這個(gè)是服務(wù)器返回的數(shù)據(jù)
對(duì)第三行點(diǎn)右鍵昔穴，選擇Follow,再選擇TCP Stream镰官。
這時(shí)候默認(rèn)是ASCII編碼展示，點(diǎn)擊右下角選擇Hex Dump吗货∮具耄看到的數(shù)據(jù)果然是前面多了0x33 0x39后面多了0x30，然后看header
HTTP/1.1 200 OK
Date: Mon, 26 Nov 2018 07:33:22 GMT
Server: Apache
X-Powered-By: PHP/5.4.45
Upgrade: h2
Connection: Upgrade, close
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
···
搜索Transfer-Encoding: chunked宙搬，后得知
分塊編碼（Transfer-Encoding: chunked）
1笨腥、Transfer-Encoding，是一個(gè) HTTP 頭部字段（響應(yīng)頭域）勇垛，字面意思是「?jìng)鬏斁幋a」脖母。最新的 HTTP 規(guī)范里，只定義了一種編碼傳輸：分塊編碼(chunked)闲孤。
2谆级、分塊傳輸編碼（Chunked transfer encoding）是超文本傳輸協(xié)議（HTTP）中的一種數(shù)據(jù)傳輸機(jī)制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端的數(shù)據(jù)可以分成多個(gè)部分讼积。分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供肥照。
3、數(shù)據(jù)分解成一系列數(shù)據(jù)塊勤众，并以一個(gè)或多個(gè)塊發(fā)送建峭，這樣服務(wù)器可以發(fā)送數(shù)據(jù)而不需要預(yù)先知道發(fā)送內(nèi)容的總大小。
4决摧、具體方法
a)在頭部加入 Transfer-Encoding: chunked 之后亿蒸，就代表這個(gè)報(bào)文采用了分塊編碼。這時(shí)掌桩，報(bào)文中的實(shí)體需要改為用一系列分塊來傳輸边锁。b)每個(gè)分塊包含十六進(jìn)制的長(zhǎng)度值和數(shù)據(jù)，長(zhǎng)度值獨(dú)占一行波岛，長(zhǎng)度不包括它結(jié)尾的 CRLF(\r\n)茅坛，也不包括分塊數(shù)據(jù)結(jié)尾的 CRLF。
c)最后一個(gè)分塊長(zhǎng)度值必須為 0，對(duì)應(yīng)的分塊數(shù)據(jù)沒有內(nèi)容贡蓖，表示實(shí)體結(jié)束曹鸠。
所以單從數(shù)據(jù)來看，0x33 0x39轉(zhuǎn)ASCII是3和9斥铺，0x30是0彻桃，因?yàn)橛?x0d 0x0a這個(gè)作為分隔符，那么39其實(shí)是連在一起的晾蜘，就是0x39,轉(zhuǎn)換10進(jìn)制表達(dá)就是57,和我們的數(shù)據(jù)塊是對(duì)應(yīng)的邻眷，根據(jù)規(guī)則后面的0是結(jié)束符，所以服務(wù)器并沒有什么問題剔交。但是模塊畢竟是MCU能使用的庫和存儲(chǔ)大小都非常有限肆饶，還是得服務(wù)器解決。
搜索后有的相關(guān)內(nèi)容
1岖常、nginx的Transfer-Encoding: chunked關(guān)閉方法：
chunked_transfer_encoding off;
沒用nginx所以pass驯镊。2、servlet強(qiáng)硬地調(diào)用了OutputStream.flush()竭鞍，web容器是不知道怎么返回Content-Length的焕襟，所以會(huì)用Transfer-Encoding:chunked方式返回困食。
PHP那哥們直接echo出去的摆碉，但是找到了問題的解決思路弛车，返回這個(gè)數(shù)據(jù)的Content-Length是不是就OK了呢，經(jīng)過測(cè)試這個(gè)是可以的滨砍。
header('Content-Length:57');
echo '{......}'
客戶端的請(qǐng)求HTTP的協(xié)議從1.1改為1.0也是可行的往湿，但沒做具體實(shí)驗(yàn)。
在java中還有一種說法是惋戏，返回的數(shù)據(jù)緩存大小設(shè)置的太小领追，設(shè)置緩存大小超過要發(fā)送的數(shù)據(jù)就不會(huì)，但我覺得這樣似乎不妥响逢，所以沒試绒窑，貼出內(nèi)容供以后參考
response.setBufferSize(402800);
