问题背景：
在workerman官方社区有网友提出了这么一个问题，大体意思是在一次HTTP请求中服务端返回的body体中"多了一些看似奇怪的字符"，
问题原因：
"多了一些看似奇怪的字符"，既然我用引号引起来了，说明这些字符并不奇怪，为什么？因为这是HTTP协议的规范，具体就是用到了HTTP协议的分块传输编码技术：Transfer-Encoding: chunked
chunked分块技术：
服务端将响应内容 body 体分成若干个 chunk 块来分别传输的，表现为一边计算一边传输。
使用场景：
1、通常情况下，当我们请求一个静态资源比如图片的时候，服务端是能准确提供该图片的大小的，这时候服务端会在响应头中增加一个头字段：Content-Length来告知客户端需要接收多少数据，此时服务端响应的内容是整体一次性发送给客户端的，这没什么毛病。
2、然很多时候，当我们请求的内容是动态内容的话，这个时候服务端就无法预先得知动态内容的大小，怎么办？Transfer-Encoding: chunked 分块传输编码技术正是为此而生，这时服务端会在响应头中增加一个头字段：Transfer-Encoding: chunked，即切割成一块一块的数据块分段发送给客户端；另外注意有了这个字段，就用不到Content-Length字段了。
chunked格式：
Chunked-Body = 1-chunk-block
+ 2-chunk-block
+ 3-chunk-block
+ .............
+ .............
+ N-chunk-block
= last-chunk-block
+ trailer
+ CRLF
chunk-block = chunk-size CRLF
+ chunk-data CRLF
名词解释：
(1)其中 1-chunk-block、2-chunk-block、.....、N-chunk-block 分别代表若干个chunk块，此时 chunk-size = strlen(chunk-data)，chunk-data = 非空的数据内容。
(2)其中last-chunk-block 代表最后一个chunk块，只不过此时 chunk-size = 0, chunk-data = 空。
(3)其中trailer是附加在尾部的额外头域，主要包含一些元数据，通常可以直接忽略。
(4)其中chunk-size 代表紧随其后的chunk-data数据的大小，单位为字节，特别注意是以16进制表示的。
(5)其中chunk-data 代表具体数据内容。
实战截图：
