http报文头解析

一、http请求格式：

http请求格式主要分为四部分：公共头部、请求头、返回头。

（1）公共头部(General)：

公共头部包括：请求网址、请求方法（POST/GET/DELETE/PUT/HEAD）、请求资源的URL路径、请求状态码、请求的远程地址、HTTP版本。

• Request URL:http://news.sina.com.cn/gov/zt/xjpbdj/
• Request Method:GET
• Status Code:304 Not Modified
• Remote Address:218.30.108.226:80
• Referrer Policy:no-referrer-when-downgrade

表1 公共头（General）

Request URL请求的域名Remote Address请求的远程地址Request Method请求方法Status Code请求状态码Referrer Policy浏览器该如何发送 Referrer

（2）请求头（Request Headers）：

• Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
• Accept-Encoding:gzip, deflate, sdch
• Accept-Language:zh-CN,zh;q=0.8
• Cache-Control:max-age=0
• Connection:keep-alive
• Cookie:U_TRS1=0000008e.fe762dc5.58e61204.7f2d69f5; UOR=www.baidu.com,blog.sina.com.cn,; SINAGLOBAL=124.127.130.142_1491472900.954556; vjuids=29d825d6a.15b42b66c3b.0.428ddd0a135ef; vjlast=1491472903.1491472903.30; SGUID=1491875229376_85527180; SUB=_2AkMvqeUtf8NxqwJRmP4Ry2nrboh3ygHEieKZ9RT2JRMyHRl-yD9kqnQ-tRApD93ATOxyVE1r2-mUydO2U1uf_w..; SUBP=0033WrSXqPxfM72-Ws9jqgMF55529P9D9W50BiypURwAWhf-KfmzxaAk; Apache=124.127.130.142_1492743682.829278; ULV=1492745238560:7:7:3:124.127.130.142_1492743682.829278:1492478486711; directAd=true; lxlrttp=1492689981
• Host: news.sina.com.cn
• If-Modified-Since:Fri, 21 Apr 2017 02:48:39 GMT
• Referer: http://www.sina.com.cn/
• User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

表2 请求头（Request Headers）

Accept表示浏览器支持的MIME类型Accept-Encoding:浏览器支持的压缩类型Accept-Language:浏览器支持的语言类型，并且优先支持靠前的语言类型Connection:当浏览器与服务器通信时，对于长连接如何进行处理：close/keep-aliveCookie:向服务器返回Cookie，这些cookie是之前服务器发给浏览器的Host:请求的服务器URLReferer:该页面的来源URLUser-Agent:用户客户端的一些必要信息

（3）返回头（Response Healders）:

• Cache-Control:max-age=60
• Date:Fri, 21 Apr 2017 03:30:59 GMT
• Expires:Fri, 21 Apr 2017 03:31:59 GMT
• Last-Modified:Fri, 21 Apr 2017 02:48:39 GMT
• Server:nginx
• X-Cache:MISS from ja180-186.sina.com.cn
• Content-Disposition:inline;filename=ClAcW1jcZ5WAD4RqAAD4v89Ln1U184.jpg
• Content-Type:image/jpg;charset=UTF-8
• Transfer-Encoding:chunked

表3 返回头（Response Headers）

Cache-Control:告诉浏览器或者其他客户，什么环境下可以安全地缓存文档Connection:当浏览器与服务器通信时，对于长连接如何进行处理：close/keep-aliveContent-Encoding内容编码：数据在传输过程中所使用的压缩编码方式Content-Type 数据的类型Date:数据从服务器发送的时间Expires:应该在什么时间认为文档已经过期，从而不在缓存它Last-Modified:此文件在服务器端最后被修改的时间Server:服务器名字。Servlet一般不设置这个值，而是有Web服务器自己设置Transfer-Encoding传输编码：数据传输的方式

二、部分字段说明

1.Accept-Encoding 和 Content-Encoding:

[1]. 浏览器支持的内容编码列表：Accept-Encoding

[2]. 传输内容编码：Content-Encoding 内容编码，即整个数据信息是在数据器端经过怎样的编码处理，然后客户端会以怎么的编码来反向处理，以得到原始的内容。这里的内容编码主要是指压缩编码，即服务器端压缩，客户端解压缩。 可以参考的值为：gzip,compress,deflate和identity。

Accept-Encoding 和 Content-Encoding 是 HTTP 中用来对「采用何种编码格式传输正文」进行协定的一对头部字段。

它的工作原理是这样：浏览器发送请求时，通过 Accept-Encoding 带上自己支持的内容编码格式列表；服务端从中挑选一种用来对正文进行编码，并通过 Content-Encoding 响应头指明选定的格式；浏览器拿到响应正文后，依据 Content-Encoding 进行解压。当然，服务端也可以返回未压缩的正文，但这种情况不允许返回 Content-Encoding。这个过程就是 HTTP 的内容编码机制。

内容编码目的是优化传输内容大小，通俗地讲就是进行压缩。一般经过 gzip 压缩过的文本响应，只有原始大小的 1/4。对于文本类响应是否开启了内容压缩，是我们做性能优化时首先要检查的重要项目；而对于 JPG / PNG 这类本身已经高度压缩过的二进制文件，不推荐开启内容压缩，效果微乎其微还浪费 CPU。

2.Accept

　　例子中的Accept字段是这样子的：Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8。意思是：浏览器支持的MIME类型分别是text/html、application/xhtml+xml、application/xml和*/*，优先顺序是它们从左到右的排列顺序。

　　Accept表示浏览器支持的 MIME 类型；

　　MIME的英文全称是 Multipurpose Internet Mail Extensions（多功能 Internet 邮件扩充服务），它是一种多用途网际邮件扩充协议，在1992年最早应用于电子邮件系统，但后来也应用到浏览器。

　　text/html,application/xhtml+xml,application/xml 都是 MIME 类型，也可以称为媒体类型和内容类型，斜杠前面的是 type（类型），斜杠后面的是 subtype（子类型）；type 指定大的范围，subtype 是 type 中范围更明确的类型，即大类中的小类。

　　Text：用于标准化地表示的文本信息，文本消息可以是多种字符集和或者多种格式的；

　　text/html表示 html 文档；

　　Application：用于传输应用程序数据或者二进制数据；

　　application/xhtml+xml表示 xhtml 文档；

　　application/xml表示 xml 文档。

3. 传输内容格式：Content-Type内容格式，即接收的数据最终是以何种的形式显示在浏览器中，可以是一个图片，还是一段文本，或者是一段html。内容格式额外支持可选参数,charset，即实际内容的字符集。通过字符集，客户端可以对数据进行解编码，以最终显示可以看得懂的文字（而不是一段byte[]或者是乱码)。

4.持久连接：Persistent Connection

Persistent Connection（持久连接，通俗说法长连接）。我们知道 HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性，为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。为此，HTTP 协议引入了相应的机制。

HTTP/1.0 的持久连接机制是后来才引入的，通过 Connection: keep-alive 这个头部来实现，服务端和客户端都可以使用它告诉对方在发送完数据之后不需要断开 TCP 连接，以备后用。HTTP/1.1 则规定所有连接都必须是持久的，除非显式地在头部加上 Connection: close。所以实际上，HTTP/1.1 中 Connection 这个头部字段已经没有 keep-alive 这个取值了，但由于历史原因，很多 Web Server 和浏览器，还是保留着给 HTTP/1.1 长连接发送 Connection: keep-alive 的习惯。

浏览器重用已经打开的空闲持久连接，可以避开缓慢的三次握手，还可以避免遇上 TCP 慢启动的拥塞适应阶段，听起来十分美妙。

5.实体长度：Content-Length

表示实体长度，并通过头部告诉对方。

浏览器可以通过 Content-Length 的长度信息，判断出响应实体已结束。那如果 Content-Length 和实体实际长度不一致会怎样？有兴趣的同学可以自己试试，通常如果 Content-Length 比实际长度短，会造成内容被截断；如果比实体内容长，会造成 pending。

由于 Content-Length 字段必须真实反映实体长度，但实际应用中，有些时候实体长度并没那么好获得，例如实体来自于网络文件，或者由动态语言生成。这时候要想准确获取长度，只能开一个足够大的 buffer，等内容全部生成好再计算。但这样做一方面需要更大的内存开销，另一方面也会让客户端等更久。

我们在做 WEB 性能优化时，有一个重要的指标叫 TTFB（Time To First Byte），它代表的是从客户端发出请求到收到响应的第一个字节所花费的时间。大部分浏览器自带的 Network 面板都可以看到这个指标，越短的 TTFB 意味着用户可以越早看到页面内容，体验越好。可想而知，服务端为了计算响应实体长度而缓存所有内容，跟更短的 TTFB 理念背道而驰。但在 HTTP 报文中，实体一定要在头部之后，顺序不能颠倒，为此我们需要一个新的机制：不依赖头部的长度信息，也能知道实体的边界。

6.传输编码Transfer-Encoding: chunked（分块编码）

可以是分段传输，也可以是不分段，直接使用原数据进行传输。 有效的值为：chunked和 identity

Transfer-Encoding 正是用来解决上面这个问题的（TTFB）。历史上 Transfer-Encoding 可以有多种取值，为此还引入了一个名为 TE 的头部用来协商采用何种传输编码。但是最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。

分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF（\r\n），也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。按照这个格式改造下之前的代码：

require('net').createServer(function(sock) { sock.on('data',function(data) { sock.write('HTTP/1.1 200 OK\r\n'); sock.write('Transfer-Encoding: chunked\r\n'); sock.write('\r\n'); sock.write('b\r\n'); sock.write('01234567890\r\n'); sock.write('5\r\n'); sock.write('12345\r\n'); sock.write('0\r\n'); sock.write('\r\n'); });}).listen(9090,'127.0.0.1');

上面这个例子中，我在响应头中表明接下来的实体会采用分块编码，然后输出了 11 字节的分块，接着又输出了 5 字节的分块，最后用一个 0 长度的分块表明数据已经传完了。用浏览器访问这个服务，可以得到正确结果。可以看到，通过这种简单的分块策略，很好的解决了前面提出的问题。

 Content-Encoding 和 Transfer-Encoding 二者经常会结合来用，其实就是针对 Transfer-Encoding 的分块再进行 Content-Encoding。

7. User-Agent

　　User-Agent的值是：用户使用的客户端的一些必要信息，比如操作系统、浏览器及版本、浏览器渲染引擎等。

8.Cache-Control

　　Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会影响到另一个消息处理过程中的缓存处理过程。

　　请求时的缓存指令包括：no-cache, no-store, max-age, max-stale, min-fresh, only-if-cached。

　　响应消息中的指令包括：public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age。

　　各个指令的含义：

　　Public：指示响应可被任何缓存区缓存。 

　　Private：指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当前用户的部分响应消息，此响应消息对于其他用户的请求无效。 

　　no-cache：指示请求或响应消息不能缓存 

　　no-store：用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。 

　　max-age：指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。 

　　min-fresh：指示客户机可以接收响应时间小于当前时间加上指定时间的响应。 

　　max-stale：指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。