文章目录
Accept
请求头用来告知客户端可以处理的内容类型，这种内容类型用MIME类型来表示。借助内容协商机制, 服务器可以从诸多备选项中选择一项进行应用，并使用 Content-Type 应答头通知客户端它的选择。浏览器会基于请求的上下文来为这个请求头设置合适的值，比如获取一个CSS层叠样式表时值与获取图片、视频或脚本文件时的值是不同的。
语法
Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*
Accept-Encoding
- Accept-Encoding 会将客户端能够理解的内容编码方式——通常是某种压缩算法——进行通知。通过内容协商的方式，服务端会选择一个客户端提议的方式，使用并在响应报文首部 Content-Encoding 中通知客户端该选择。
- 即使客户端和服务器都支持相同的压缩算法，在 identity 指令可以被接受的情况下，服务器也可以选择对响应主体不进行压缩。导致这种情况出现的两种常见的情形是：
- 要发送的数据已经经过压缩，再次进行压缩不会导致被传输的数据量更小。一些图像格式的文件会存在这种情况；
- 服务器超载，无法承受压缩需求导致的计算开销。通常，如果服务器使用超过80%的计算能力，微软建议不要压缩。
语法
#表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。
Accept-Encoding: gzip
#采用 Lempel-Ziv-Welch (LZW) 压缩算法。
Accept-Encoding: compress
#采用 zlib 结构和 deflate 压缩算法。
Accept-Encoding: deflate
#表示采用 Brotli 算法的编码方式。
Accept-Encoding: br
#用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。
Accept-Encoding: identity
# 匹配其他任意未在该首部字段中列出的编码方式。
Accept-Encoding: *
#值代表优先顺序，用相对质量价值 表示，又称为权重。
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
Accept-Language
- 请求头允许客户端声明它可以理解的自然语言，以及优先选择的区域方言。借助内容协商机制，服务器可以从诸多备选项中选择一项进行应用， 并使用Content-Language 应答头通知客户端它的选择。浏览器会基于其用户界面语言来为这个请求头设置合适的值，即便是用户可以进行修改，但是这种情况极少发生 。
- 当服务器无法通过其他方式来确定应当使用的语言时——例如某一特定的URL，这是用户明确指定的——这个请求头可以用作提示。建议服务器端永远不要覆盖明确指定的信息。 Accept-Language消息头的内容通常不在用户的掌控之中（例如在国外旅行时到提供网络服务的场所上网）；另外用户可能会想要浏览非本地用户界面语言的页面。
Connection
- connection 决定当前的事务完成后，是否会关闭网络连接。如果该值是“keep-alive”，网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成。
- 除去标准的逐段传输（hop-by-hop）头（Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization and Proxy-Authenticate），任何逐段传输头都需要在 Connection 头中列出，这样才能让第一个代理知道必须处理它们且不转发这些头。标准的逐段传输头也可以列出（常见的例子是 Keep-Alive，但这不是必须的）。
Content-Length
一个实体消息首部，用来指明发送给接收方的消息主体的大小，即用十进制数字表示的八位元组的数目。
Host
- Host请求头指明了服务器的域名，以及服务器监听的TCP端口号。如果没有给定端口号，会自动使用被请求服务的默认端口（比如请求一个HTTP的URL会自动使用80端口）。
- HTTP/1.1 的所有请求报文中必须包含一个Host头字段。如果一个 HTTP/1.1 请求缺少 Host 头字段或者设置了超过一个的 Host 头字段，一个400（Bad Request）状态码会被返回。
Referer
Referer首部包含了当前请求页面的来源页面的地址。
User-Agent
客户端标识。User-Agent 首部包含了一个特征字符串，用来让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号。
语法：
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.25 Safari/537.36 Core/1.70.3867.400 QQBrowser/10.7.4315.400
X-Real-IP
是一个自定义头部字段。X-Real-IP 通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP，这个设备可能是其他代理，也可能是真正的请求端。需要注意的是，X-Real-IP 目前并不属于任何标准，代理和 Web 应用之间可以约定用任何自定义头来传递这个信息。
X-Forwarded-For
Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。
语法
X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。
如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，那么按照 XFF 标准，服务端最终会收到以下信息：
X-Forwarded-For: IP0, IP1, IP2
Proxy3 直连服务器，它会给 XFF 追加 IP2，表示它是在帮 Proxy2 转发请求。列表中并没有 IP3，IP3 可以在服务端通过 Remote Address 字段获得。我们知道 HTTP 连接基于 TCP 连接，HTTP 协议中没有 IP 的概念，Remote Address 来自 TCP 连接，表示与服务端建立 TCP 连接的设备 IP，在这个例子里就是 IP3。
Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。不同语言获取 Remote Address 的方式不一样，例如 php 是 $_SERVER[“REMOTE_ADDR”]，Node.js 是 req.connection.remoteAddress，但原理都一样。
Cookie
也常用复数形式Cookies,这是网站为了辨别用户进行会话跟踪而存储在用户本地的数据。它的主要功能是维持当前访问会话。例如，我们输入用户名和密码成功登录某个网站后，服务器会用会话保存登录状态信息，后面我们每次刷新或请求该站点的其他网页时，会发现都是登录状态，这就是cookie的功劳。Cookies里有信息标识了我们所对应的服务器的会话，每次浏览器在请求页面时，都会在请求头中加上Cookies并将其发送给服务器，服务器通过Cookies识别出是我们自己，并查出当前状态是登录状态，所以返回结果就是登录之后才能看到的网页内容。
Cache-Control
no-cache表示不使用缓存。
Sec-Fetch-*
Sec-Fetch开头的请求头都属于Fetch Metadata Request Headers，于2019年发布的新草案，目前处于Editor’s Draft阶段，支持度还不是很高，还需要注意的是，这些请求头都是Forbidden header，也就是不能被篡改的，是浏览器自动加上的请求头，这样也保证了数据的准确性，还需要注意的是如果资源是本地缓存加载，那么就不会添加这些请求头了.
Sec-Fetch-Dest
- **含义：**表示请求的目的地，即如何使用获取的数据；
- 取值范围：
report document frame iframe object embed audio font image paintworkletscript
Sec-Fetch-Mode
- **含义：**该请求头表明了一个请求的模式；
- 取值范围：
cors：跨域请求；
no-cors：限制请求只能使用请求方法(get/post/put)和请求头(accept/accept-language/content-language/content-type)；
same-origin：如果使用此模式向另外一个源发送请求，显而易见，结果会是一个错误。你可以设置该模式以确保请求总是向当前的源发起的；
navigate：表示这是一个浏览器的页面切换请求(request)。 navigate请求仅在浏览器切换页面时创建，该请求应该返回HTML；
websocket：建立websocket连接；
说明：
cors表示跨域请求，且要求后端需要设置cors响应头；no-cors并不是代表请求不跨域，而是服务端不设置cors响应头，什么情况下会是这种模式呢，图片/脚本/样式表这些请求是容许跨域且不用设置跨域响应头的，而no-cors也是默认的模式；same-origin表示同源请求，这就限制了不能跨域，前面说的cors和no-cors是容许跨域的，只是要求服务端的设置不同而已，熟悉fetch接口的同学对mode属性应该不陌生，其实跟这里的含义是一样的，只是fetch的mode大家可以手动设置，而Sec-Fetch-Mode不能干预而已；
Sec-Fetch-Site
- 含义：表示一个请求发起者的来源与目标资源来源之间的关系；
- 取值范围：
cross-site：跨域请求；
same-origin：发起和目标站点源完全一致；
same-site：有几种判定情况，详见说明；
none：如果用户直接触发页面导航，例如在浏览器地址栏中输入地址，点击书签跳转等，就会设置none；
Sec-Fetch-User
-
**含义：**取值是一个Boolean类型的值，true(?1)表示导航请求由用户激活触发(鼠标点击/键盘)，false(?0)表示导航请求由用户激活以外的原因触发；
-
取值范围：
?0 ?1 -
**说明：**请求头只会在导航请求情况下携带，导航请求包括document , embed , frame , iframe , or object ；
Upgrade-Insecure-Requests
取值范围：
1
表示能读懂服务器发过来的上面这条信息，并且在以后发请求的时候不用http而用https