起因
以前一个小项目的后台接口是某PHP的哥们写的，然后可能他不知道从哪里看了一篇毒鸡汤，说什么大神的成长之路，都是要对以前的代码不停的重构，要追求完美，然后认真勤奋的把代码重构了一遍，重构完还兴致勃勃的给我发微信：“争哥我把代码重构了一遍特顺畅特牛逼，你赶快起个模块测一下。”
当我读到这条消息的同时，客户那边候总的电话就打过来了：“搞什么鬼，我这200台机器就快退役了，忽然今天TM的全都不能用了，客户投诉电话都给我打爆了，赶快给我处理一下。”我特么内心咯噔一下，肯定是小赵重构代码的锅，然后立刻告诉候总，我们服务器遭到黑客攻击，正在抢修，这属于天灾人祸不可抗力，谁也没办法。
经过各种确认，模块有个致命BUG，如果服务器不停止工作还好，一旦停止工作，这个BUG就暴露出来了，再也连不上服务器。需要把这分布在好几个城市的200多台机器，人工拆卸掉模块，重新烧录固件安装回去。然后我想起姜文的电影《让子弹飞》中汤师爷的话多么的正确。
这冤鼓，乾隆那时候设的，这都一百多年了。你要把它砍了，把鼓露出来，不定出多大冤呐
这说明了一个深刻的道理啊，100多年前的陈年老代码，马上就要退役了，千万一定不要瞎JB折腾，不定出多大BUG呐！
经过
在找模块厂的工程师调试的时候，请求服务器返回的数据又有问题了，数据块前面多了0x33 0x39，后面多了0x30，还给我截了图，让我去用Wireshark抓包自己看数据。
一开始用postman来测试，返回的字符串肉眼看，内容是没问题的，但是有可能是在编码过程中自动忽略了乱码信息，所以我又写一段程序专门来看返回的数据，直接打印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;
}
结果也完全正确,中间省略号省去数据内容
[7b,......, 6d]
[71,......, 2c]
[22, 6d, ,......, 7d, 7d]
====================
[7b, ,......, 7d, 7d]
{"code":0,"data":{"m..p":"1.....5","m....t":"...."}}
57
完全正确的内容，为什么单片机就是无法解析呢，我觉得有点诡异，又自己去下载个Wireshark，这个工具我用很少，又是折腾半天搞定。
先选择当前正在使用的本地连接，双击，然后会看到一堆数据跳动，
在上面的栏里输入过滤规则，因为我知道服务器IP，所以我的规则是：
ip.addr == 192..1.1
然后运行上面代码，看到过滤数据包，选中第3行，这个是服务器返回的数据
对第三行点右键，选择Follow,再选择TCP Stream。
这时候默认是ASCII编码展示，点击右下角选择Hex Dump。看到的数据果然是前面多了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，是一个 HTTP 头部字段（响应头域），字面意思是「传输编码」。最新的 HTTP 规范里，只定义了一种编码传输：分块编码(chunked)。
2、分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网页服务器发送给客户端的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。
3、数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。
4、具体方法
a)在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。b)每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF(\r\n)，也不包括分块数据结尾的 CRLF。
c)最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。
所以单从数据来看，0x33 0x39转ASCII是3和9，0x30是0，因为有0x0d 0x0a这个作为分隔符，那么39其实是连在一起的，就是0x39,转换10进制表达就是57,和我们的数据块是对应的，根据规则后面的0是结束符，所以服务器并没有什么问题。但是模块毕竟是MCU能使用的库和存储大小都非常有限，还是得服务器解决。
搜索后有的相关内容
1、nginx的Transfer-Encoding: chunked关闭方法：
chunked_transfer_encoding off;
没用nginx所以pass。2、servlet强硬地调用了OutputStream.flush()，web容器是不知道怎么返回Content-Length的，所以会用Transfer-Encoding:chunked方式返回。
PHP那哥们直接echo出去的，但是找到了问题的解决思路，返回这个数据的Content-Length是不是就OK了呢，经过测试这个是可以的。
header('Content-Length:57');
echo '{......}'
客户端的请求HTTP的协议从1.1改为1.0也是可行的，但没做具体实验。
在java中还有一种说法是，返回的数据缓存大小设置的太小，设置缓存大小超过要发送的数据就不会，但我觉得这样似乎不妥，所以没试，贴出内容供以后参考
response.setBufferSize(402800);
