起因

以前一個(gè)小項(xiàng)目的后臺(tái)接口是某PHP的哥們寫(xiě)的，然后可能他不知道從哪里看了一篇毒雞湯，說(shuō)什么大神的成長(zhǎng)之路，都是要對(duì)以前的代碼不停的重構(gòu)，要追求完美，然后認(rèn)真勤奮的把代碼重構(gòu)了一遍，重構(gòu)完還興致勃勃的給我發(fā)微信：“爭(zhēng)哥我把代碼重構(gòu)了一遍特順暢特牛逼，你趕快起個(gè)模塊測(cè)一下?！?/p>

當(dāng)我讀到這條消息的同時(shí)，客戶(hù)那邊候總的電話(huà)就打過(guò)來(lái)了：“搞什么鬼，我這200臺(tái)機(jī)器就快退役了，忽然今天TM的全都不能用了，客戶(hù)投訴電話(huà)都給我打爆了，趕快給我處理一下?！蔽姨孛磧?nèi)心咯噔一下，肯定是小趙重構(gòu)代碼的鍋，然后立刻告訴候總，我們服務(wù)器遭到黑客攻擊，正在搶修，這屬于天災(zāi)人禍不可抗力，誰(shuí)也沒(méi)辦法。

經(jīng)過(guò)各種確認(rèn)，模塊有個(gè)致命BUG，如果服務(wù)器不停止工作還好，一旦停止工作，這個(gè)BUG就暴露出來(lái)了，再也連不上服務(wù)器。需要把這分布在好幾個(gè)城市的200多臺(tái)機(jī)器，人工拆卸掉模塊，重新燒錄固件安裝回去。然后我想起姜文的電影《讓子彈飛》中湯師爺?shù)脑?huà)多么的正確。

這冤鼓，乾隆那時(shí)候設(shè)的，這都一百多年了。你要把它砍了，把鼓露出來(lái)，不定出多大冤吶

QQ圖片20181126170141.png

這說(shuō)明了一個(gè)深刻的道理啊，100多年前的陳年老代碼，馬上就要退役了，千萬(wàn)一定不要瞎JB折騰，不定出多大BUG吶！

經(jīng)過(guò)

在找模塊廠的工程師調(diào)試的時(shí)候，請(qǐng)求服務(wù)器返回的數(shù)據(jù)又有問(wèn)題了，數(shù)據(jù)塊前面多了0x33 0x39，后面多了0x30，還給我截了圖，讓我去用Wireshark抓包自己看數(shù)據(jù)。

image.png

一開(kāi)始用postman來(lái)測(cè)試，返回的字符串肉眼看，內(nèi)容是沒(méi)問(wèn)題的，但是有可能是在編碼過(guò)程中自動(dòng)忽略了亂碼信息，所以我又寫(xiě)一段程序?qū)ｉT(mén)來(lái)看返回的數(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ī)就是無(wú)法解析呢，我覺(jué)得有點(diǎn)詭異，又自己去下載個(gè)Wireshark，這個(gè)工具我用很少，又是折騰半天搞定。
先選擇當(dāng)前正在使用的本地連接，雙擊，然后會(huì)看到一堆數(shù)據(jù)跳動(dòng)，
在上面的欄里輸入過(guò)濾規(guī)則，因?yàn)槲抑婪?wù)器IP，所以我的規(guī)則是：

ip.addr == 192..1.1

然后運(yùn)行上面代碼，看到過(guò)濾數(shù)據(jù)包，選中第3行，這個(gè)是服務(wù)器返回的數(shù)據(jù)

image.png

對(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)頁(yè)服務(wù)器發(fā)送給客戶(hù)端的數(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í)體需要改為用一系列分塊來(lái)傳輸。

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ù)沒(méi)有內(nèi)容，表示實(shí)體結(jié)束。

所以單從數(shù)據(jù)來(lái)看，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ù)器并沒(méi)有什么問(wèn)題。但是模塊畢竟是MCU能使用的庫(kù)和存儲(chǔ)大小都非常有限，還是得服務(wù)器解決。

搜索后有的相關(guān)內(nèi)容

1、nginx的Transfer-Encoding: chunked關(guān)閉方法：
chunked_transfer_encoding off;
沒(méi)用nginx所以pass。

2、servlet強(qiáng)硬地調(diào)用了OutputStream.flush()，web容器是不知道怎么返回Content-Length的，所以會(huì)用Transfer-Encoding:chunked方式返回。
PHP那哥們直接echo出去的，但是找到了問(wèn)題的解決思路，返回這個(gè)數(shù)據(jù)的Content-Length是不是就OK了呢，經(jīng)過(guò)測(cè)試這個(gè)是可以的。

header('Content-Length:57');
echo '{......}'

客戶(hù)端的請(qǐng)求HTTP的協(xié)議從1.1改為1.0也是可行的，但沒(méi)做具體實(shí)驗(yàn)。

在java中還有一種說(shuō)法是，返回的數(shù)據(jù)緩存大小設(shè)置的太小，設(shè)置緩存大小超過(guò)要發(fā)送的數(shù)據(jù)就不會(huì)，但我覺(jué)得這樣似乎不妥，所以沒(méi)試，貼出內(nèi)容供以后參考

response.setBufferSize(402800);