客户端发送给服务端请求时候，请求头中会声明希望拿到的数据格式，以及其他与数据相关的一些限制，服务端会根据它的请求中的声明，来做针对性的返回。
分类中包含，请求和返回两种。
请求中用Accept来声明，我想要什么数据。Accept:指定我想要的数据类型，Accept-Encoding：代表数据以什么编码的方式来实现传输。Accept-Language:希望获得的语言，用什么语言来展示。User-Agent:用来判定是PC端还是Mac还是移动端等，从而返回不同的信息。
与Accept对应的是服务端返回的内容，对应的字段是Content。Content-Type:对应Accept，从Accept中选取一种数据格式，来说明实际返回的数据格式。Content-Encoding:对应Accept-Encoding，来说明选择哪一种数据格式进行压缩。Content-Language:对应Accept-Language，来说明我是根据你希望的语言进行返回，还是没有根据你要求的语言进行返回。服务端返回没有对应的User-Agent啦，因为User-Agent本来就是由客户端决定我当前用的哪一种刘浏览器，哪一种系统环境当中的，不需要协商。
我们来看下一个例子：这里例子server.js和test.html不再列出，用前面文章中任何一个例子都可以，直接贴出network中的细节，这时我们关注一下Request Headers和Response Headers。
Request Headers中大多都比较好理解，都是声明了客户端可以接受的一些信息，服务器根据这些信息来适配和选择。其中注意Accept和Content-Type是相对应的，其中字段信息叫做MIME Type，同时服务端关于Content-Type字段还可以加上的一个字段：'X-Content-Type-Options':'nosniff'，这是因为老的IE浏览器会主动激进地猜测你返回内容的信息，这样可能会导致一些安全隐患，比如你输入的信息可能会被当作脚本运行，虽然现在的浏览器不会这样，但是加上这个字段确保浏览器不会去猜测和执行用户输入的东西。Accept-Language中的q=0.9表示权重，表明该浏览器更加希望收到英文版本，权重是0.9。User-Agent中展示了一些系统信息、内核、引擎版本等，服务端接受到这个信息，选择是否返回适配这个机型的信息。
下面列出一个例子来说明一下Accept-Encoding和Content-Encoding：
下图是无Content-Encoding 的结果，上面red表示服务端的返回传输时候的大小，它包括response body+response headers等信息，下面blue表示response body的实际大小。
然而，如果我们的静态文件，比如bundle.js很大，如果不经过任何处理，直接经过网络进行传输，是非常慢的。这时候Content-Encoding派上用场，下面标注的红色表示需要修改的地方。引入压缩包，在Content-Encoding声明我用了gzip对文件进行了压缩奥，你浏览器看见了要用对应的方法解压奥，最后返回response.end()中是html经过压缩的内容。现在也不用'utf8'，而是默认用buffer读取文件。
经过压缩后，此时浏览器Size显示如下，content仍然是313B，但是传输大小从458B变成312B。
