全栈必知系列之网络知识篇

时间 2020-05-30

原文原文链接

为了让用户可以拥有更加良好的用户体验，优化页面加载速度成为前端开发过程当中极其重要的一环，而网络资源的传输速度无可厚非成为了优化提速最重要的部分，知道网络传输的各个环节的前因后果才能更好地去优化，所以做为一名合格的前端开发人员仍是有必要了解网络相关的知识。css

HTTP的发展进程

HTTP0.9

HTTP0.9当时主要为了简单的用于网络之间传输HTML超文本内容，因此称为超文本传输协议，实现也相对简单html

流程以下前端

基于TCP协议，客户端根据IP和端口号和服务器创建TCP链接，创建链接过程就是TCP协议的三次握手过程
创建好链接经过GET请求获取index.html
服务器接收请求信息以后，读取对应的 HTML 文件，并将数据以 ASCII 字符流返回给客户端。
HTML文档传输完成，断开链接

HTTP1.0

引入请求头和回应头

因为万维网高速发展，出现了js，css以及邮件等多种形式的文本，单纯的get请求和ASCII字符流没法知足需求，经过请求头和回应头指明文件类型和字符编码以及语言等信息content-encoding content-typeweb

引入状态码

有的请求服务器可能没法处理，或者处理出错，这时候就须要告诉浏览器服务器最终处理该请求的状况，这就引入了状态码。状态码是经过响应行的方式来通知浏览器的算法

提供了Cache机制

为了减轻服务器的压力，在 HTTP/1.0 中提供了Cache 机制，用来缓存已经下载过的数据。数据库

加入用户代理字段

服务器须要统计客户端的基础信息，好比 Windows 和 macOS 的用户数量分别是多少，因此 HTTP/1.0 的请求头中还加入了用户代理的字段。后端

HTTP1.1

改进持久链接以及CDN域名的分片机制

因为请求资源的增多，HTTP1.0的短链接方式没法知足需求，HTTP1.1增长了connection:keep-alive(默认激活，关闭改成close),同一个域名能够创建6个TCP链接(这也是为啥须要配置多个DNS域名的缘由增长TCP链接量)浏览器

下图是1.0和1.1的请求对比缓存

不成熟的HTTP管线化（部分浏览器尝试失败）

持久链接虽然减小了TCP的链接断开次数，可是单个TCP通道请求队列须要每一个请求发送完获得回应才能进行下一个任务的请求，发生队头阻塞,因此将请求批量发送给服务器，但服务器依然须要按顺序依次处理返回安全

提供虚拟主机支持

因为一个服务器上面增设多个虚拟主机，也就是一个IP地址对应多个域名，HTTP1.1头部增长了Host字段

对动态生成的内容完美支持

以前传输内容须要标明内容大小，一次性传输完，随着内容的增大，引入了chunk transfer机制

引入cookie以及安全机制

HTTP2.0

HTTP1.1的问题

HTTP1.1慢启动影响资源首次加载速度

TCP创建链接后，刚开始请求传输速度比较慢而后逐渐的不断提速（主要是为了防止出现网络拥堵）,这样会让页面的首次渲染时间变长

开启多个TCP管道，出现带宽的竞态问题

多个TCP管道一块儿开启一旦出现网速降低，没法识别资源的优先级，出现竞态问题

单个TCP管道队头阻塞

因为管线化不成熟，队头阻塞依然存在

HTTP2.0的更改

多路复用机制

鉴于以上的问题，HTTP2.0引入二进制的分帧层机制来实现多路复用，关于多路复用的实现以下：

单个域名之下仍然只容许创建一个TCP管道，使用一个TCP长链接（整个页面资源下载只须要一次慢启动，并且避免了竞态）
浏览器准备好请求数据（请求行+请求头+请求体），而后分帧层对每一个请求进行分割，将同一个请求的分割块打上相同的ID编号，经过协议栈将全部的分割体发给服务器
服务器端的分帧层根据ID编号进行请求组装
服务器的分帧层将回应数据分割按同一个回应体进行ID分割回应给客户端
客户端拼装回应

能够设置请求的优先级

客户端的分帧层对分割块标上请求的优先级

服务器推送服务器根据请求的资源主动推送其余与该请求资源关联的资源（好比请求html,服务器顺便回应内嵌的js和css资源）
头部压缩请求头压缩，增长传输效率

HTTP3.0

HTTP2.0虽然采用多路复用机制解决大多数问题，可是和HTTP1.1同样，TCP管道传输途中也会出现丢包问题（丢包就必须等待从新发包）,形成队头阻塞，这样2.0的单个TCP长链接丢包率太高的状况下（高于2%）还不如1.1的6个管道传输效率，而且2.0的TCP创建链接三次握手以及HTTPS的TSL链接也会耗费较多时间

因为TCP协议的僵化以及底层包括中间设备的僵化，没法再进行修改，因而3.0基于UDP协议开发了QUIC协议

实现了相似 TCP 的流量控制、传输可靠性的功能。
集成了 TLS 加密功能。
实现了 HTTP/2 中的多路复用功能。和 TCP 不一样，QUIC 实现了在同一物理链接上能够有多个独立的逻辑数据流（以下图）。实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。

实现了快速握手功能。

HTTPS

HTTPS在HTTP基础上增长了安全层(SSL安全套接层/TSL传输层安全)

安全层的两个主要职责：对发起HTTP请求的数据进行加密操做和对接收到的HTTP内容进行解密操做

对称加密

对称加密是指加密和解密都使用的是相同的密钥

速度快但秘钥传递过程容易被中间人劫持

非对称加密

非对称加密算法有 A、B 两把密钥，若是你用 A 密钥来加密，那么只能使用 B 密钥来解密；反过来，若是你要 B 密钥来加密，那么只能用 A 密钥来解密

第一个是非对称加密的效率过低
第二个是没法保证服务器发送给浏览器的数据安全,服务器发送给客户端的数据只能用私钥加密，公钥每一个人都有，因此中间人可解密服务端到客户端的数据

混合加密

在传输数据阶段依然使用对称加密，可是对称加密的密钥咱们采用非对称加密来传输

虽然混合加密比较安全，但咱们没法知道数据是否被篡改，服务端没法知道加密是不是对应客户端的随机数，客户端也没法知道获取的必定是服务端给的公钥

CA认证

服务器生成公钥A+私钥A,将公钥A和信息(公司、网站等)发送给CA机构认证
CA用经过线上线下渠道确认该公司信息，审核经过而后对信息进行hash加密，生成 信息摘要,而后用本身的私钥B对信息摘要加密生成 数字签名，将 数字签名和 信息装在一块儿组成 数字证书发给服务器
服务器将数字证书发给客户端
- 首先浏览器读取证书中的证书全部者、有效期等信息进行一一校验
- 浏览器开始查找操做系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
- 若是找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。若是找到，那么浏览器就会从操做系统中取出颁发者CA 的公钥，而后对服务器发来的证书里面的签名进行解密
- 浏览器使用相同的hash算法根据证书内容计算出信息摘要，将这个计算的值与证书解密的值作对比
- 对比结果一致，则证实服务器发来的证书合法，没有被冒充。此时浏览器就能够读取证书中的公钥，用于后续加密了
客户端用CA的私钥B解密获得消息摘要，并对原始信息采用一样hash算法作比较，确认公钥未被篡改
客户端生成随机数字采用公钥加密随机数，发给客户端
客户端解密获取随机数，创建对称加密信息传输通道

cookie

为啥会产生cookie?

因为HTTP1.X是一个无状态协议，也就是客户端同一个请求发送屡次，服务端并不能识别是否是同一个客户端发送，为了解决无状态状况，出现了cookie

cookie设置流程

客户端请求服务端 -> 服务端回应头部set-cookie -> 客户端收到并保存到本地 -> 客户端请求携带头部字段cookie

cookie属性

属性	解释
expires	有效期，以客户端为准
max-Age	正数s，负数s马上删除，0为会话cookie即关闭浏览器就是消失
Domin	cookie送达的主机名
Path	携带cookie的资源路径
Secure	标记为Secure只会https发送
HttpOnly	标记为HttpOnly前端没法经过document.cookie获取，避免xss攻击
SameSite	Chrome80新加入的属性

cookie做用

会话状态管理（如用户登陆状态、购物车、游戏分数或其它须要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

SameSite

好比当前网页www.renrendai.com为一方请求，请求后端必然根据设置的domin和path会携带对应的cookie,可是好比经过www.baidu.com等三方网站点击跳转到www.renrendai.com的请求会根据SameSite的设定一方请求是否携带cookie；

所谓同站(一方)就是顶级域名和二级域名相同 eg: a.taobao.com 和 b.taobao.com 顶级域名为.com, 二级域名为taobao, 也就是前面截去.后面截去顶级域名，中间部分为二级域名 a.a.xx.cn二级域名为a.xx

异步请求（不会改变当前页面，也不会打开新页面），好比经过 <script>、<link>、<img>、<iframe> 等标签发起的请求，还有经过各类发送 HTTP 请求的 DOM API（XHR，fetch，sendBeacon）发起的请求。
同步请求（可能改变当前页面，也可能打开新页面），好比经过对 <a> 的点击，对 <form> 的提交，还有改变 location.href，调用 window.open() 等方式产生的请求。

SameSite三个值

strict全部三方的连接都不会携带cookie，好比你当前淘宝处于登陆态，可是从百度跳转到淘宝的页面却没有登陆态，于是没法发起csrf攻击
lax只有同步且是get请求才可携带cookie
none全部三方的请求都会携带cookie

Token

token解决的问题

彻底由应用端管理，避开了同源策略
token能够避免csrf攻击
能够多服务器之间共享

如何解决token过时问题

token发送给服务端，服务端缓存过时时间，每次请求都查看过时时间，若是过时则直接推迟过时时间
前端将token发送给服务端，服务端发现token过时提示前端，前端调用后端的refresh刷新过时时间

token组成

JWT格式：Header.Payload.Signature

Header = {
 alg: "HS256", // 签名算法  typ: "JWT" // 令牌类型 } Payload = { // 内容提  sub: '123123',  name: 'Jone',  admin: true, }  Signature = Hash256(`${base64(header)}.${base64(patload)}.${secret}`) 复制代码

分离认证服务

网络安全

聊聊大前端网络安全那些事

TCP/IP

TCP/IP 协议其实是一系列网络通讯协议的统称，其中最核心的两个协议是TCP和IP，其余的还有 UDP、ICMP、ARP 等等，共同构成了一个复杂但有层次的协议栈。

IP协议(Internet Protocol) 主要目的是解决寻址和路由问题，以及如何在两点间传送数据包，采用IP地址来定位互联网的每一台计算机(IPV4/IPV6)

TCP协议(Transmission Control Protocol) 它位于 IP 协议之上，基于 IP 协议提供可靠的、字节流形式的通讯，是 HTTP 协议得以实现的基础。保证数据的完整性和不丢失

HTTP 是一个"传输协议"，但它不关心寻址、路由、数据完整性等传输细节，而要求这些工做都由下层来处理。由于互联网上最流行的是 TCP/IP 协议，而它恰好知足 HTTP 的要求，因此互联网上的 HTTP 协议就运行在了 TCP/IP 上，HTTP 也就能够更准确地称为“HTTP over TCP/IP”。

分层

TCP/IP协议总共有四层，以下

应用层决定了向用户提供应用服务时通讯的活动。 TCP/IP协议族内预存了各种通用的应用服务。好比，FTP（File Transfer Protocol，文件传输协议）和DNS（Domain Name System，域名系统）服务就是其中两类。HTTP协议也处于该层。
传输层对上层应用层，提供处于网络链接中的两台计算机之间的数据传输。在传输层有两个性质不一样的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。传输层对上层应用层，提供处于网络链接中的两台计算机之间的数据传输。在传输层有两个性质不一样的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。
网络层（又名网络互连层）网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了经过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间经过多台计算机或网络设备进行传输时，网络层所起的做用就是在众多的选项内选择一条传输路线。
链路层（又名数据链路层，网络接口层）用来处理链接网络的硬件部分。包括控制操做系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括链接器等一切传输媒介）。硬件上的范畴均在链路层的做用范围以内

七层协议

工做原理

应用层根据请求信息生成请求报文（请求行+请求头+请求体）
在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。
网络层增长通讯的Mac地址，搜索对方的地址，一边中转一边传送
接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的HTTP请求。
发送端在层与层之间传输数据时，每通过一层时一定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每通过一层时会把对应的首部消去。

TCP三次握手和四次挥手

发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端再回传一个带ACK标志的数据包，表明“握手”结束。若在握手过程当中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

DNS

全称 Domain Name System ,即域名系统。在 TCP/IP 协议中使用 IP 地址来标识计算机，数字形式的地址对于计算机来讲是方便了，但对于人类来讲却既难以记忆又难以输入。因此出现了域名

DNS结构

根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的 IP 地址；
顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，好比 com 顶级域名服务器能够返回 apple.com 域名服务器的 IP 地址；
权威域名服务器（Authoritative DNS Server）：管理本身域名下主机的 IP 地址，好比 apple.com 权威域名服务器能够返回 www.apple.com 的 IP 地址。
本地域名服务器 (Local DNS Server)，不少大公司和网络运营商创建本身的DNS服务器

DNS查询过程

iOS设备请直接跳到第三步骤

首先搜索浏览器自身的DNS缓存,若是存在，则域名解析到此完成。
若是浏览器自身的缓存里面没有找到对应的条目，那么会尝试读取操做系统的hosts文件看是否存在对应的映射关系,若是存在，则域名解析到此完成。
若是本地Host文件中没有那么操做系统会把这个域名发送给这里设置的LocalDNS，也就是本地区的域名服务器。这个DNS一般都提供给你本地互联网接入的一个DNS解析服务。这个专门的域名解析服务器性能都会很好，它们通常都会缓存域名解析结果，固然缓存时间是受域名的失效时间控制的，通常缓存空间不是影响域名失效的主要因素。
若是本地DNS服务器还没找到的话,它就会向根服务器发出请求,进行递归查询。
根域名服务器返回给本地域名服务器一个所查询的域的主域名服务器（gTLD Server）地址。gTLD是国际顶级域名服务器，如.com，.cn、.org等。全球只有13台左右。
本地域名服务器（Local DNS Server）再向上一步返回的gTLD服务器发送请求。
接受请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server一般就是你注册的域名服务器，例如你在某个域名服务提供商申请的域名，那么这个域名解析任务就由这个域名提供商的服务器来完成
Name Server域名服务器会查询存储的域名和IP的映射关系表，正常状况下都根据域名获得目标IP记录，连同一个TTL值返回给DNS Server域名服务器。
返回该域名对应的IP和TTL值，Local DNS Server会缓存这个域名和IP的对应关系，缓存的时间由TTL值控制。
返回该域名对应的IP和TTL值，Local DNS Server会缓存这个域名和IP的对应关系，缓存的时间由TTL值控制。

CDN

CDN，全称Content Delivery Network，根本的做用是将网站的内容发布到最接近用户的网络“边缘”，使用户能够就近取得所需的内容，提升用户访问网站的响应速度。他-有别于镜像，它比镜像更智能，能够这样作一个比喻：CDN=镜像（Mirror） + 缓存（cache） + 总体负载均衡（GSLB），于是，CDN能够明显提升Internet中信息流动的效率。目前CDN都以缓存网站中的静态数据为主，如CSS、JS、图片和静态网页等数据。用户在从主站服务器请求到动态内容后再从CDN上下载这些静态数据，从而加速网页数据内容的下载速度，如淘宝有90%以上的数据都是由CDN来提供的。这里引用一个网上比较形象的例子：A家的网速 100M的，但他只用了10M的速度，B家的网速是10M的，可是他须要15M的速度才行。怎么办呢。 C是一家CDN服务商，在A家有个节点（就像A是一个赞助商同样）B在C家买了CDN加速服务。当B的速度不够的时候，CDN加速就会选择有节余的节点来帮B，提升B的速度。这样B的速度就能达到或超过15M ，皆大欢喜。A没浪费，B速度有了，C赚了钱。当C的节点在全国都有，很是多的时候。那么你用C家的CDN加速服务，你就会大步流星了。

CDN工做流程

一个用户访问某个静态文件（如CSS），这个静态文件的域名假如是www.baidu.com，而这个域名最终会被指向CDN全局中CDN负载均衡服务器，再由这个负载均衡服务器来最终分配是哪一个地方的访问用户，返回给离这个访问用户最近的CDN节点。以后用户就直接去这个CDN节点访问这个静态文件了，若是这个节点中请求的文件不存在，就会再回到源站去获取这个文件，而后再返回给用户。

代理

代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。代理服务器的基本行为就是接收客户端发送的请求后转发给其余服务器。代理不改变请求URI，会直接发送给前方持有资源的目标服务器。持有资源实体的服务器被称为源服务器。从源服务器返回的响应通过代理服务器后再传给客户端。

代理服务器种类

匿名代理：彻底“隐匿”了被代理的机器，外界看到的只是代理服务器；
透明代理：顾名思义，它在传输过程当中是“透明开放”的，外界既知道代理，也知道客户端；
正向代理：靠近客户端，表明客户端向服务器发送请求；
反向代理：靠近服务器端，表明服务器响应客户端的请求；

代理能够作的事情

负载均衡：把访问请求均匀分散到多台机器，实现访问集群化；
内容缓存：暂存上下行的数据，减轻后端的压力；
安全防御：隐匿 IP, 使用 WAF 等工具抵御网络攻击，保护被代理的机器；
数据处理：提供压缩、加密等额外的功能。

网关

网关是转发其余服务器通讯数据的服务器，接收从客户端发送来的请求时，它就像本身拥有资源的源服务器同样对请求进行处理。有时客户端可能都不会察觉，本身的通讯目标是一个网关。网关的工做机制和代理十分类似。而网关能使通讯线路上的服务器提供非HTTP协议服务。利用网关能提升通讯的安全性，由于能够在客户端与网关之间的通讯线路上加密以确保链接的安全。好比，网关能够链接数据库，使用SQL语句查询数据。另外，在Web购物网站上进行信用卡结算时，网关能够和信用卡结算系统联动。

隧道

隧道是在相隔甚远的客户端和服务器二者之间进行中转，并保持双方通讯链接的应用程序。隧道可按要求创建起一条与其余服务器的通讯线路，届时使用SSL等加密手段进行通讯。隧道的目的是确保客户端能与服务器进行安全的通讯。隧道自己不会去解析HTTP请求。也就是说，请求保持原样中转给以后的服务器。隧道会在通讯双方断开链接时结束。

HTTP请求方式

常见状态码

1××：提示信息，表示目前是协议处理的中间状态，还须要后续的操做；
2××：成功，报文已经收到并被正确处理；
3××：重定向，资源位置发生变更，须要客户端从新发送请求；
4××：客户端错误，请求报文有误，服务器没法处理；
5××：服务器错误，服务器在处理请求时内部发生了错误。

状态码	含义
200 OK	表示从客户端发来的请求在服务器端被正常处理了。
220 No Content	该状态码表明服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。
206 Partial Content	该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。
301 Moved Permanently	永久性重定向。该状态码表示请求的资源已被分配了新的URI，之后应使用资源如今所指的URI。也就是说，若是已经把资源对应的URI保存为书签了，这时应该按Location首部字段提示的URI从新保存。
302 Found	临时性重定向。该状态码表示请求的资源已被分配了新的URI，但愿用户（本次）能使用新的URI访问。和301 状态码类似，但302状态码表明的资源不是被永久移动，只是临时性质的。换句话说，已移动的资源对应的URI未来还有可能发生改变。好比，用户把URI保存成书签，但不会像301状态码出现时那样去更新书签，而是仍旧保留返回302状态码的页面对应的URI。
304 Not Modified	该状态码表示客户端发送附带条件的请求[插图]时，服务器端容许请求访问资源，但因发生请求未知足条件的状况后，直接返回304 Not Modified（服务器端资源未改变，可直接使用客户端未过时的缓存）。304状态码返回时，不包含任何响应的主体部分。304虽然被划分在3XX类别中，可是和重定向没有关系
400 Bad Request	该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像200 OK同样对待该状态码。
401 Unauthorized	该状态码表示发送的请求须要有经过HTTP认证（BASIC认证、DIGEST认证）的认证信息。另外若以前已进行过1次请求，则表示用户认证失败。返回含有401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部用以质询（challenge）用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。
403 Forbidden	该状态码代表对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但若是想做说明的话，能够在实体的主体部分对缘由进行描述，这样就能让用户看到了。
404 Not Found	该状态码代表服务器上没法找到请求的资源。除此以外，也能够在服务器端拒绝请求且不想说明理由时使用。
500 Internal Server Error	该状态码代表服务器端在执行请求时发生了错误。也有多是Web应用存在的bug或某些临时的故障。
503 Service Unavailable	该状态码代表服务器暂时处于超负载或正在进行停机维护，如今没法处理请求。若是事先得知解除以上情况须要的时间，最好写入Retry-After首部字段再返回给客户端。

首部字段

首部字段名	说明
通用首部字段
Cache-Control	控制缓存的行为
Connection	逐跳首部、链接的管理
Date	建立报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其余协议
Via	代理服务器的相关信息
Warning	错误通知
请求首部字段
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（天然语言）
Authorization	Web认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag)
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与lf-Match相反）
If-Range	资源未更新时发送实体Byte的范围请求
If-Unmodified-Since	比较资源的更新时间（与lf-Modified-Since相反
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中URI的原始获取方
TE	传输编码的优先级
User-Agent	HTTP客户端程序的信息
响应首部字段
Accept-Ranges	是否接受字节范围请求
Age	推算资源建立通过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息
实体首部字段
Allow	资源可支持的HTTP方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的天然语言
Content-Length	实体主体的大小（单位：字节）
Content-Location	替代对应资源的URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过时的日期时间
Last-Modified	资源的最后修改日期时间

浏览器缓存

缓存优势

减小冗余的数据传输
减小服务器的负担，大大提高了网站的性能
加快了客户端加载网页的速度