一、 项目背景
一个物联网项目，公司要求降低硬件成本，真可谓穷公司练技术，硬件资源有限制，最终技术选型使用单片机，因资源受限，硬件sdk中没有现成的http可使用，因此，最终嵌软同学直接在TCP socket基础上，构造了Http请求头，仿造http与物联网平台进行交互。
因此，有意思的事情发生了，嵌软同学仿造http的过程如下：
1、初始化tcp client，然后构造http请求，通过tcp send发送http请求，接着recv等待对端的返回；
2、收到recv报文之后，读取整个response报文，然后转化为string，从string中匹配content-length字段，从而获取response的body体大小。
看似一切正常，而且嵌软同学之前也这么做过，为啥这次就不行了那，一切都是chunk（这里就不解释啥是chunk了，不知的同学自行百度吧）搞的鬼，有的时候server会使用chunk方式进行数据返回，chunk模式下，是可以不存在content-length字段的（严格上来说是没有content-length），因此这种情况下，按照上面的流程就跑不通了。
二、content-length和chunk是如何工作的？
这里百度了一些文章，说是chunk和gzip有关，但是百思不得其解，没有缕出来两者的关联关系，实验了一些demo，请求和返回头里都含有gzip的压缩方式，但是content-lenght字段还是存在，所以，索性认为没有必然联系。
再继续百度了下，说是chunk和keep-alive相关，看到这我想是因为http1.1支持了连接服用，因此才支持了chunk，但是并不是说一旦开启了keep-alive所有交互都是chunk模式，事实自己也写了个小demo试了下，确实如此。
继续百度之旅，最后看到chunk和flush函数有关，正常我们server端在返回数据的时候，是使用write函数，而write函数并不是直接给用户返回数据，而是先降数据写回缓冲区，直到连接close之前，会先将缓冲区的数据buffer发送过去，然后close连接。而flash函数则是手动将缓冲区的数据发送到客户端，然后server端可以继续将数据写到缓冲区，然后再调用flush函数，而还是之前的那一个连接（我想这也是之前百度到的一些文章说chunk和keepalive有关的原因吧），这样收到的传输方式就是chunk的方式。而我们调用write函数，然后等到hander结束，close连接之前发送数据这个流程，也就是我们说的非chunk方式吧（除buff中数据超过buff大小的情况）。
三、demo验证
这里采用golang代码进行了过程验证。
1、使用gin router写了一个简单的请求，如下：
r :=gin.Default()
r.GET("/ping", func(c *gin.Context) {
c.JSON(200, gin.H{
"message":"pong",
})
})
r.Run()
请求结果如下所示：
2、修改flush发送数据方式，如下：
r :=gin.Default()
r.GET("/ping", func(c *gin.Context) {
w := c.Writer
flusher, ok := w.(http.Flusher)
if !ok {
panic("expected http.ResponseWriter to be an http.Flusher")
}
fmt.Fprintf(w,string("hello chunk!"))
flusher.Flush()
})
r.Run()
结果如下图：
四、总结
1、通过理论+实验来看，chunk和keepalive有关系，chunk是基于keekalive基础实现的，但是他们俩者之间并不是必然的关系。
2、server端如果不想采取chunk方式回复数据，以免有些客户端对chunk支持性不好，通过server端可以对传输方式进行控制，比如通过避免使用flush函数回复数据的方式。
3、至于其他语言例如java如何控制传输方式，后面我们再完善补充，多谢。
