场景应用：常见的HTTP协议请求头有哪些？

标准答案：

​ 常见的HTTP请求头有：Accept，接收的数据类型。Accept-Language，接收的语言。Accept-Encoding，客户端的编码方式。Connection，长连接还是短链接。Host，客户端的主机和端口号。Referer，请求来源网站。User-Agent，客户端的系统和浏览器的信息。Cache-Control，缓存设置（重点）。Cookie，存储用户信息。Range，获取的数据部分。

扩展学习：

​ 常见的HTTP请求头有：

Accept：

Accept：text/html浏览器可以接受服务器回发的类型为 text/html。
Accept：*/*代表浏览器可以处理所有类型（一般浏览器发给服务器都是发这个）。
Accept-Encoding：gzip、deflate。浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）。

Accept-Language：

浏览器申明自己接收的语言。

Connection：

Connection：keep-alive。当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。
Connection：close。代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭，当客户端再次发送Request，需要重新建立TCP连接。

Host：

请求报文头部主要用于指定被请求资源的Internet主机和端口号，发送请求时，这个字段是必需的。

Referer：

当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。

User-Agent：

告诉HTTP服务器， 客户端使用的操作系统和浏览器的名称和版本。

Cache-Control：

Cache-Control：默认为private，响应只能够作为私有的缓存，不能再用户间共享。
Cache-Control：public。响应会被缓存，并且在多用户间共享。正常情况，如果要求HTTP认证，响应会自动设置为private。
Cache-Control：must-revalidate。响应在特定条件下会被重用，以满足接下来的请求，但是它必须到服务器端去验证它是不是仍然是最新的。
Cache-Control：no-cache。响应不会被缓存，而是实时向服务器端请求资源。
Cache-Control：max-age。设置缓存最大的有效时间，但是这个参数定义的是时间大小，而不是确定的时间点。单位是秒。
Cache-Control：no-store在任何条件下，响应都不会被缓存，并且不会被写入到客户端的磁盘里，这也是基于安全考虑的某些敏感的响应才会使用这个。

Cookie：

用来存储一些用户信息以便让服务器辨别用户身份的（大多数需要登录的网站上面会比较常见），比如cookie会存储一些用户的用户名和密码，当用户登录后就会在客户端产生一个cookie来存储相关信息，这样浏览器通过读取cookie的信息去服务器上验证并通过后会判定你是合法用户，从而允许查看相应网页。当然cookie里面的数据不仅仅是上述范围，还有很多信息可以存储是cookie里面，比如sessionid等。

Range：

bytes=0-5。指定第一个字节的位置和最后一个字节的位置。用于告诉服务器自己想取对象的哪部分。

延伸阅读：

​Connection字段中的keep-alive可以简单理解为一种状态保持或重用机制，比如当一条连接建立后，我们不想它立刻被关闭，如果实现了keep-alive机制，就可以通过它来实现连接的保持。

keep-alive在HTTP 1.0版本默认是关闭的，但在HTTP1.1是默认开启的；操作系统里TCP的keep-alive默认也是关闭，但一般应用都会修改设置来开启。因此网上TCP流量中基于keep-alive的是主流。那TCP为什么要用keep-alive呢？TCP的三次握手和四次挥手中的关闭机制看起来简单明了，但实际衍生出了各种问题，有的时候确实不希望中断空闲的TCP连接，因为建立一次TCP连接需要经过一到两次的网络交互，且由于TCP的slow-start机制，新的TCP连接开始数据传输速度是比较慢的，理想上希望通过连接池模式，保持一部分空闲连接，当需要传输数据时，可以从连接池中直接拿一个空闲的TCP连接来全速使用，这样对性能有很大提升为了支持这种情况，于是TCP实现了keep-alive机制。