前言：
tcp四次挥手过程中，谁主动断开，谁有time_wait，被动断开一方会有close_wait
- time_wait:保持端口占用2mls~4min,避免对方还有一些tcp片发往这个端口，新链接受影响。time_wait的缺点：占用内存
- close_wait:被动关闭一方接受到fin信号后马上回复ack表示收到fin信号，同时进入close_wait 状态，等待未传输完成的data继续传输完毕，close_wait状态结束，发送fin信号。即close_wait的目的是等待未传输完成的data继续传输完毕。
http 1.0与1.1
http1.0 默认是短连接，client端主动发起，server端服务完毕后，将连接关毕，client端也借此判断数据发送完毕。所以http1.0时代，服务端容易有较多的time_wait。
- 如果http 1.0协议，client希望使用长连接，需要在header中设置connection:keep-alive
http1.1默认是长连接
- 如果client不希望使用长连接，需要在header中设置connection:close
- 如果server不希望使用长连接，也需要在reponse中设置connection:close
http header中keep-alive参数用于设置客户端希望服务端保持连接的秒数
长连接的问题
keep-alive模式带来的问题：此时服务端不关闭连接，客户端如何知道消息内容是否发送完毕（bfe曾经因为对http1.0没有主动关闭连接，导致一些老旧php上的的socket http包因为等待服务端关闭连接判断消息发送完毕而超时）
keep-alive模式下，通过两种方式
- 服务端reqponse设置content-length参数：告知内容大小，客户端收到指定内容长度后即可关闭连接。客户端发送post时也会采用这种方式，如若content-length大于实际发生的值会超时，小于则服务端会响应400。这种模式有缺陷，动态页面服务器也不知道内容大小，只有等内容全准备完毕后才知道，若等到此时发送，效率太低了。
- transfer-encoding:chunked模式：此模式下简单说是规定一直特殊的响应data格式，此种格式中会包含body结束的标志。客户端收到此标志即知道数据发送完毕，可以组装解密数据了。
content-length,transfer-encoding,content-encoding
- transfer-encoding:传输编码，针对传输过程来的，传输完解码才拿到对象。用于在网络传输国财中保证数据安全成功的传输。在http1.1里，如果有transfer-encoding，则必须是chunked，此时不能有content-lengh参数，即使有也会忽略。transfer-encoding相冲突，因为transfer-encoding会通过额外的处理方式来改变数据的组织方式，就会改变实际的数据长度，如果客户端仍按照原content-length来处理的话，则不会接收到完整的数据。
- content-encoding: 内容编码和accept-encoding对应。比如gzip，对于文本有较好的压缩效果。
附两篇很好的文章
1.介绍http:https://www.byvoid.com/zhs/blog/http-keep-alive-header
2.content-length:http://www.tuicool.com/articles/FJ7rye
3.http协议官方文档：http://greenbytes.de/tech/webdav/rfc7230.html#header.content-length
4.http://liupan2668.blog.163.com/blog/static/12038513120140129504967/