http协议主要使用CRLF进行分割。
| 标示 | ASCII | 描述 | 字符 |
|---|---|---|---|
| CR | 13 | Carriage return (回车) | \n |
| LF | 10 | Line feed character(换行) | \r |
| SP | 32 | Horizontal space(空格) | |
| COLON | 58 | COLON(冒号) | : |
请求包,主要包含三部分：请求行(line)，请求头(header)，请求正文(body)
请求行(Line)：主要包含三部分：Method ，URI ，协议/版本。 各部分之间使用空格(SP)分割。整个请求头使用CRLF分割。(比如：POST /1.0.0/_health_check HTTP/1.1 CRLF)
请求头(Header)： 格式为(name ：value)，用于客户端请求的描述信息。header之间以CRLF进行分割。最后一个header会多加一个CRLF。( 比如：Connection: keep-alive CRLF CRLF)
请求正文(body) ：里面主要是Post提交的数据(可支持多种格式，格式在Content-Type定义，长度是在Content-Length里面定义)。
响应包,主要包含三部分：状态行(line),响应头(header),响应正文(body)
状态行(line)：包含三部分：http版本，服务器返回状态码，描述信息。以CRLF进行分割。 ( 比如：HTTP/1.1 200 OK CRLF)
响应头(header) ： 格式为(name ：value)，用于服务器返回的描述信息。header之间以CRLF进行分割。最后一个header会多加一个CRLF (比如：Content-Type: text/html CRLF Content-Encoding:gzip CRLF CRLF)
响应正文(body)：里面主要是返回数据(可支持多种格式，格式在Content-Type定义，长度是在Content-Length里面定义)。
truncked协议
1：主要包含三部分：chunk，last-chunk和trailer。如果分多次发送，则chunk有多份。
2：chunk主要包含大小和数据，大小表示这个这个trunck包的大小，使用16进制标示。其中trunk之间的分隔符为CRLF。
3：通过last-chunk来标识chunk发送完成。 一般读取到last-chunk(内容为0)的时候，代表chunk发送完成。
4：trailer 表示增加header等额外信息，一般情况下header是空。通过CRLF来标识整个chunked数据发送完成。
HTTP协议通常使用Content-Length来标识body的长度，在服务器端，需要先申请对应长度的buffer，然后再赋值。接收数据时，发现header中有Content-Length属性，则读取Content-Length 的值，确定需要读取body的长度。
如果需要一边生产数据一边发送数据，就需要使用”Transfer-Encoding: chunked” 来代替Content-Length，也就是对数据进行分块传输。按照truncked协议分批读取数据。
压缩类型
1：压缩需要客户端，服务器端同时支持。在chrome中，请求默认会加上Accept-Encoding: gzip, deflate，客户端默认开启数据压缩。而tomcat默认关闭压缩，如果开启需要增加配置。
2：在请求时，需要通过header的Accept-Encoding: gzip, deflate 来告诉服务器客户端支持的压缩类型。
3：在返回时，http server会在返回的header中添加Content-Encoding: gzip 来告诉客户端数据的压缩方式。
4：压缩类型主要包含如下几种：
gzip 说明body采用GNU zip编码
compress 说明body采用Unix的文件压缩程序
deflate 说明body是用zlib的格式压缩的
identity 说明没有对实体进行编码。
其中 gzip, compress, 以及deflate编码都是无损压缩算法，不会导致信息损失。 gzip效率最高，使用较为广泛。
http解决粘包拆包
1：请求行的边界是CRLF，如果读取到CRLF，则意味着请求行的信息已经读取完成。
2：Header的边界是CRLF，如果连续读取两个CRLF，则意味着header的信息读取完成。
3：body的长度是有Content-Length 来进行确定。如果没有Content-Length ，则是chunked协议(具体参考前面的trunked协议)。