它们是：Expires, Pragma: no-cache, Cache-Control , Last-Modified , ETag。
1. Expires:+过期时间
Expires是Web服务器响应消息头字段，在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。不过Expires 是HTTP 1.0的东西，现在默认浏览器均默认使用HTTP 1.1，所以它的作用基本忽略。Expires 的一个缺点就是，返回的到期时间是服务器端的时间，这样存在一个问题，如果客户端的时间与服务器的时间相差很大（比如时钟不同步，或者跨时区），那么误差就很大，所以在HTTP 1.1版开始，被Cache-Control: max-age=秒替代。
过期时间必须是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，缓存会马上过期，HTTP的日期时间必须是格林威治时间（GMT），而不是本地时间。举例：
Expires: Fri, 30 Oct 2009 14:19:41
2. Pragma: no-cache
为了兼容HTTP1.0，可以使用Pragma: no-cache头来告诉浏览器不要缓存内容.许多人相信设置一个 Pragma: no-cache HTTP 协议可以控制缓存是否开启。这其实不是完全正确的。HTTP 协议的详细说明中并没有设置任何有关Pragma的条例，相反，Pragma请求十分有争议。虽然一部分缓存会受到此参数的影响，但大多数一点作用也没有，请使用header头协议代替它！（作用有争议，最好不用）
3. Cache-control:
Cache-control直译成中文就是缓存控制，它的作用就是缓存控制，这个http头的值有几种。
1) max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
2）no-store — 强制缓存在任何情况下都不要保留任何副本
3）no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。
4. Last-Modified/If-Modified-Since：Last-Modified/If-Modified-Since要配合Cache-Control使用。
Last-Modified：标示这个响应资源的最后修改时间。web服务器在响应请求时，告诉浏览器资源的最后修改时间。
If-Modified-Since：当资源过期时（使用Cache-Control标识的max-age），发现资源具有Last-Modified声明，则再次向web服务器请求时带上头 If-Modified-Since，表示请求时间。web服务器收到请求后发现有头If-Modified-Since 则与被请求资源的最后修改时间进行比对。若最后修改时间较新，说明资源又被改动过，则响应整片资源内容（写在响应消息包体内），HTTP 200；若最后修改时间一致，说明资源无新修改，则响应HTTP 304 (无需包体，节省浏览)，告知浏览器继续使用所保存的cache。
5. Etag/If-None-Match：Etag/If-None-Match也要配合Cache-Control使用。
Etag：web服务器响应请求时，告诉浏览器当前资源在服务器的唯一标识（生成规则由服务器决定）。Apache中，ETag的值，默认是对文件的索引节（INode），大小（Size）和最后修改时间（MTime）进行Hash后得到的。
If-None-Match：当资源过期时（使用Cache-Control标识的max-age），发现资源具有Etage声明，则再次向web服务器请求时带上头If-None-Match （Etag的值）。web服务器收到请求后发现有头If-None-Match 则与被请求资源的相应校验串进行比对，决定返回200或304。
ps：Etag与Last-Modified区别：
（1） Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间
（2）有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形；
（3）一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
（4） Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符，能够更加准确的控制缓存。Last-Modified与ETag一起使用时，服务器会优先验证ETag。
1.1浏览器缓存机制
浏览器缓存主要有两类： 缓存协商 和 彻底缓存 ，也有称之为 协商缓存 和 强缓存 。强缓存
强缓存是利用http的返回头中的Expires或者Cache-Control两个字段来控制的，用来表示资源的缓存时间。
Expires
该字段是http1.0时的规范，它的值为一个绝对时间的GMT格式的时间字符串，比如Expires:Mon,18 Oct 2066 23:59:59 GMT。这个时间代表着这个资源的失效时间，在此时间之前，即命中缓存。这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，就会导致缓存混乱。
Cache-Control
Cache-Control是http1.1时出现的header信息，主要是利用该字段的max-age值来进行判断，它是一个相对时间，例如Cache-Control:max-age=3600，代表着资源的有效期是3600秒。cache-control除了该字段外，还有下面几个比较常用的设置值：
- no-cache：不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
- no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
- public：可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。
- private：只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。
Cache-Control与Expires可以在服务端配置同时启用，同时启用的时候Cache-Control优先级高。
协商缓存
协商缓存就是由服务器来确定缓存资源是否可用，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问，这主要涉及到下面两组header字段，这两组搭档都是成对出现的，即第一次请求的响应头带上某个字段（Last-Modified或者Etag），则后续请求则会带上对应的请求字段（If-Modified-Since或者If-None-Match），若响应头没有Last-Modified或者Etag字段，则请求头也不会有对应的字段。
Last-Modify/If-Modify-Since
浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。
当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。
如果命中缓存，则返回304，并且不会返回资源内容，并且不会返回Last-Modify。
ETag/If-None-Match
与Last-Modify/If-Modify-Since不同的是，Etag/If-None-Match返回的是一个校验码。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据浏览器上送的If-None-Match值来判断是否命中缓存。
与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。
2.HTTP请求报文
请求行、请求头、空行、请求体
请求行：请求方法+URL+协议版本
客户端发送一个HTTP请求到服务器的请求报文如下：
- GET：从服务器获取一份文档
- HEAD：只从服务器获取文档的首部
- POST：向服务器发送需要处理的数据，常用于表单提交。
- PUT：将请求的主体部分存储在服务器上，从服务器上向客户发送文档
- TRACE：对可能经过代理服务器传送到服务器上去的报文进行追踪
- OPTIONS：决定可以在服务器上执行哪些方法
- DELETE：从服务器上删除一份文档
GET：当客户端要从服务器中读取某个资源时，使用GET 方法。GET 方法要求服务器将URL 定位的资源放在响应报文的数据部分，回送给客户端，即向服务器请求某个资源。使用GET 方法时，请求参数和对应的值附加在 URL 后面，利用一个问号(“?”)代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。
POST：当客户端给服务器提供信息较多时可以使用POST 方法，POST 方法向服务器提交数据，比如完成表单数据的提交，将数据提交给服务器处理。GET 一般用于获取/查询资源信息，POST 会附带用户数据，一般用于更新资源信息。POST 方法将请求参数封装在HTTP 请求数据中，以名称/值的形式出现，可以传输大量数据;
● User-Agent：产生请求的浏览器类型;标志客户程序
● Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ */* ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型;
● Accept-Language：客户端可接受的自然语言;
● Accept-Encoding：客户端可接受的编码压缩格式;
● Accept-Charset：可接受的应答的字符集;
● Host：请求的主机名，允许多个域名同处一个IP 地址，即虚拟主机;
● connection：连接方式(close 或 keepalive);
● Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie;
（3）空行：通知服务器以下不再有请求的头部信息
（4）主体（请求数据）：相关备注信息状态行：协议版本+状态码+状态码描述
（2）响应首部：首部名 ：（空格）首部值
Location：Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源;
Server：Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。
Content-Length：给出文档长度
Content-type：给出媒体类型
Vary：指示不可缓存的请求头列表;
Connection：连接方式；对于请求来说：close(告诉WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不等待本次连接的后续请求了)。keepalive(告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求);对于响应来说：close(连接已经关闭); keepalive(连接保持着，在等待本次连接的后续请求); Keep-Alive：如果浏览器请求保持连接，则该头部表明希望WEB 服务器保持连接多长时间(秒);例如：Keep-Alive：300;
WWW-Authenticate：WWW-Authenticate响应报头域必须被包含在401 (未授权的)响应消息中，这个报头域和前面讲到的Authorization 请求报头域是相关的，当客户端收到 401 响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了Authorization 报头域的请求;
（3）空行：最后一个响应头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有响应头部。
（4）响应主体：服务器返回给客户端的文本信息;
HTTP协议定义了几个可以用来控制浏览器缓存关键字，它们是：Expires, Pragma: no-cache, Cache-Control , Last-Modified , ETag。
常见的首部：
- 通用首部字段（请求报文与响应报文都会使用的首部字段）
- Date：创建报文时间
- Connection：连接的管理
- Cache-Control：缓存的控制
- Transfer-Encoding：报文主体的传输编码方式
- 请求首部字段（请求报文会使用的首部字段）
- Host：请求资源所在服务器
- Accept：可处理的媒体类型
- Accept-Charset：可接收的字符集
- Accept-Encoding：可接受的内容编码
- Accept-Language：可接受的自然语言
响应首部字段（响应报文会使用的首部字段）
-
- Accept-Ranges：可接受的字节范围
- Location：令客户端重新定向到的URI
- Server：HTTP服务器的安装信息
- 实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
- Allow：资源可支持的HTTP方法
- Content-Type：实体主类的类型
- Content-Encoding：实体主体适用的编码方式
- Content-Language：实体主体的自然语言
- Content-Length：实体主体的的字节数
- Content-Range：实体主体的位置范围，一般用于发出部分请求时使用
4.http状态码
4.1常用的状态码有五大类如下所示：
1xx：表示服务器已接收了客户端请求，客户端可继续发送请求;
2xx：表示服务器已成功接收到请求并进行处理;
3xx：表示服务器要求客户端重定向;
4xx：表示客户端的请求有非法内容;
5xx：表示服务器未能正常处理客户端的请求而出现意外错误，服务器差错;
4.2常见的具体状态码及含义
101：转换协议。服务器将按照其上的头信息变为一个不同的协议。
200：服务器响应正常。
301：永久性定向。该状态码表示请求的资源已被分配了新的URI，以后请求该资源时会一直使用这个新URL。本网页永久性转移到另一个地址。
302：临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。URI将来还有可能发生变化
303：See Other 该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。
304：协商缓存。该资源在上次请求后没有任何修改（通常用于浏览器的缓存机制，使用get请求时注意）
307：临时重定向。
401：访问资源的权限不足。这个很好理解，就是资源存在但是不让你访问。
403：资源禁止访问。如果你的IP列为黑名单了，就会发生这种错误。
404：请求的资源不存在。例如，输入了错误的URL;
408：请求超时。服务器等候请求时发生超时。
414：请求的 URI 过长。请求的 URI（通常为网址）过长，服务器无法处理。
500：服务器内部错误。是常用的服务器错误状态;
503：服务器因暂时超载或临时维护而无法响应;
505：HTTP 版本不受支持。服务器不支持请求中所用的 HTTP 协议版本。
4.3状态码的补充知识
（1）HTTP状态码301、302、303、307区别
301：永久性定向。该状态码表示请求的资源已被分配了新的URI，以后请求该资源时会一直使用这个新URL。本网页永久性转移到另一个地址。
302：临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。URI将来还有可能发生变化
当301、302、303响应状态码返回时，几乎所有浏览器都会把post改成get，并删除请求报文内的主体，之后请求会自动再次发送。
301、302标准是禁止将post方法改变成get方法的，但实际使用时大家都会这么做。
303和302状态码有着相同的功能，但是303明确表示客户端应当采用get方法获取资源，这点与302状态码有区别。
比如，当使用post方法访问CGI程序，其执行后的处理结果为希望客户端能以get方法重定向到另一个uri上去时，返回303状态码。虽然302也可实现相同的功能，但这里使用303状态码是最理想的。
307 Temporary Redirect 。临时重定向。该状态码与302有相同的含义。尽管302标准禁止post变化get，但实际使用时大家不遵守。
307会遵照浏览器标准，不会从post变为get。
（3）304协商缓存
304协商缓存开始吧。这是比较基础的知识。相信我，只要你提起304协商缓存，面试官一定会忍不住问你，什么是协商缓存？
这时就到了你展示一下自己丰富的浏览器缓存知识的时候了。我一般会这么答：浏览器缓存分为强制缓存和协商缓存，优先读取强制缓存。
强缓存是利用http头中的Expires和Cache-Control两个字段来控制的，用来表示资源的缓存时间。而expires是一个GMT格式的绝对时间，是比较旧的标准，cache-control通常是一个具体的时间长度，比较新，优先级也比较高。
而协商缓存包括etag和last-modified，last-modified的设置标准是资源的上次修改时间，而etag是为了应对资源修改时间可能很频繁的情况出现的，是基于资源的内容计算出来的值，因此优先级也较高。
协商缓存与强制缓存的区别在于强制缓存不需要访问服务器，返回结果是200，协商缓存需要访问服务器，命中协商缓存的话，返回结果是304。
5、HTTP get和post区别
5.1.GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头＜request-line＞中），以?分割URL和传输数据，多个参数用&连接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。
POST提交：把提交的数据放置在是HTTP包的包体＜request-body＞中。上文示例中红色字体标明的就是实际的传输数据
因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变
5.2.传输数据的大小：
首先声明,HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。 而在实际开发中存在的限制主要有：
GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
因此对于GET提交时，传输数据就会受到URL长度的限制。
POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
5.3.安全性：
POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了。
6、HTTP/1.0 1.1 2.0之间的区别
6.1 HTTP1.0中请求方法只有三个：GET、POST、HEAD
6.1 链接无法复用，即不支持持久链接：
http 1.0 规定浏览器与服务器保持较短时间的链接，浏览器每次请求都和服务器经过三次握手和慢启动（基本思想是当TCP开始传输数据或发现数据丢失并开始重发时，首先慢慢的对网路实际容量进行试探，避免由于发送了过量的数据而导致阻塞）建立一个TCP链接，服务器完成请求处理后立即断开TCP链接，而且不跟踪每个浏览器的历史请求。
注意：由于http 1.0每次建立TCP链接对性能的影响实在是太大，http1.1实现持久化链接之后，又反向移植到http 1.0上，只是默认是没有开启持久链接的，通过http的header部分的 Connection: KeepAlive 来启用）
6.2 线头阻塞（Head of Line (HOL) Blocking）
请求队列的第一个请求因为服务器正忙（或请求格式问题等其他原因），导致后面的请求被阻塞。
影响一个HTTP网络请求的因素主要有两个：带宽和延迟。
6.2 HTTP1.1 中新增的请求方法：PUT、DELETE、OPTIONS、CONNECT、TRACE
（1）HTTP1.1中使用了持续的TCP连接（长连接）
一个TCP链接可以传送多个http请求和相应，减少了TCP建立链接和关闭链接的消耗。
HTTP1.0中每传输一个文档（HTML或者图片资源）都使用一个单独的TCP连接，也就是说传输一个文档都需要如下步骤：
三次握手建立TCP连接
客户端发送HTTP请求报文
服务器端返回HTTP响应报文
服务器端释放连接
那么HTTP1.1是如何实现TCP持续连接呢？
在HTTP1.1请求头中新加入了一个字段Connection。例如，当一个HTTP请求头中Connection字段值为Keep-Alive时（Connection: Keep-Alive），用来告诉服务器对这个请求返回后客户端与服务器端继续保持TCP连接。如果HTTP请求头中Connection字段值为Close时（Connection: Close），用来告诉服务器对这个请求返回后断开客户端与服务器端继续保持TCP连接。
（2）支持http管道
（3）100-continue响应码（节约带宽）
在HTTP1.1中新加入100响应码，这个状态码用于节约数据传输的带宽的。当请求报文的请求体数据很大时，如果贸然的将这个http请求发送给服务器是不合适的。因为服务器可能不接受这个请求，这样就造成了大量的传输带宽浪费。
在HTTP1.1中加入了100响应码，以应对这种情况。如果客户端想要发送数据量很大的请求时，客户端在发送之前先发送一个只含有请求头的http报文。如果服务器拒绝请求，返回响应码为401的响应报文，这样客户端就不会发送这个大的请求报文。如果服务器允许该请求，会返回响应码为100的响应报文，客户端就可以发送大的请求报文了。
100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用只含header的request试探一下server，看server是否允许接收这个request，再决定要不要发request body。
客户端的request的header中有"Expect: 100-continue"字段，server看到这request后返回响应报文。如果客户端收到100响应码的响应报文，客户端发送完整request。
（4）支持断点续传:
要实现断点续传的功能，通常都需要客户端记录下当前的下载进度，并在需要续传的时候通知服务端本次需要下载的内容片段。
HTTP1.1协议（RFC2616）中定义了断点续传相关的HTTP头 Range和Content-Range字段，一个最简单的断点续传实现大概如下：
1.客户端下载一个1024K的文件，已经下载了其中512K
2. 网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：
Range:bytes=512000-
这个头通知服务端从文件的512K位置开始传输文件
3. 服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：
Content-Range:bytes 512000-/1024000
并且此时服务端返回的HTTP状态码应该是206，而不是200。
但是在实际场景中，会出现一种情况，即在终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题了？显然此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义，比如实现Last-Modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头，可以使用ETag头来放置文件的唯一标识，比如文件的MD5值。
终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段，帮助服务端判别文件变化。
另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据。
（5）Host请求头
HTTP 1.1中加入了“Host”请求头字段（HTTP1.0中没有Host字段）。在HTTP 1.0中每台服务器都绑定一个唯一的IP地址。因此，请求消息中的URL并没有传递主机名(hostname).但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址.
HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request).此外,服务器应该接受以绝对路径标记的资源请求.
HTTP 1.1中的请求头中的Host字段允许在一个服务器上建立多个站点。
6.3. http 2.0
HTTP 2.0把解决性能问题的方案内置在了传输层，通过多路复用来减少延迟，通过压缩 HTTP首部降低开销，同时增加请求优先级和服务器端推送的功能。
（1） 支持多路复用
多路复用允许同时通过单一的 HTTP 2.0 连接发起多重的请求-响应消息，即所有HTTP 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接即可，所有数据流共用同一个连接 ，减少了因http链接多而引起的网络拥塞（在 HTTP1.1 协议中，同一时间，浏览器会针对同一域名下的请求有一定数量限制），解决了慢启动针对突发性和短时性的http链接低效的问题。
（2）将通信的基本单位缩小为帧
即应用层(HTTP)和传输层(TCP or UDP)之间增加一个二进制分帧层，因此在多向请求和响应时，客户端和服务器可以把HTTP消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来，解决了http 1.*的对手阻塞问题。
（3） 首部压缩
目前所有的header请求都是以没有经过压缩的纯文本的形式发送（通常会有600`1000字节），而通常使用的http请求body却很少（10~200字节），和header相比，显得很少，特别是在使用了cookie之后，这样的矛盾就更加突出，因此要减少header的数据。http 2.0支持DEFLATE和HPACK 算法的压缩。
（4） 服务端推送
指客户端请求之前发送数据的机制，在 HTTP 2.0 中，服务器可以对客户端的一个请求发送多个响应。
（5） 请求优先级
HTTP 2.0 使用一个31比特的优先值,0表示最高优先级, 2(31)-1表示最低优先级，服务器端就可以根据优先级，控制资源分配，优先处理和返回最高优先级的请求帧给客户端。
7.Https与Http区别
1、https协议需要申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的SSL加密传输协议。
3、http和https端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由HTTP+SSL协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
http协议比较简单，也是不安全的。端口号是80；三次握手结束之后便可以传输数据，http1.0是短连接，每次都要关闭连接，http 1.0是长连接，超时服务端关闭连接。由于http是明文传输，如果加密也只能在应用层上面加密。
https则是安全的，过程也比http要复杂一些。端口号：443；但简单来说，https只是http+ssl/tls(安全套接字层)而已。加密在ssl层进行，位于应用层与传输层之间，如果一定要归入应用层或者传输层的话，个人感觉应该算是传输层吧。之后再从ssl交给tcp加密后的数据。
https的基本流程
- 与服务端443端口建立TCP连接
- 请求服务端的数字证书
- 验证数字证书(数字签名验证，rsa+hash)
- 双方ssl初始化，进行一次ssl握手提供密钥确认对称对称密钥(rsa加密)
- 报文交付ssl层加密(aes+hash+rsa)
- 交付TCP传输数据
- 关闭ssl
- 关闭TCP
https加密是在ssl层进行的，因此应用层是透明的，在应用层对明文处理没有意义
数字证书
数字证书由CA机构颁发，一般记录了证书颁发机构、对象名称、日期、公钥、哈希算法等
浏览器都会预装有权威CA机构的信息，以便利用数字签名验证CA机构颁发的数字证书，如果证书无法验证，需要让用户手动信任。
8.TCP协议的三次握手和四次挥手
位码即tcp标志位,有6种标示:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
1、客户端通过将一个含有同步序列号的SYN标志位的数据段发送给服务器，请求连接。
2、服务器用一个带有“确认应答的ACK”和含同步序列号SYN标志位的数据段响应给客户端。
3、客户端再回传一个带有ACK标志的数据包，代表握手结束，开始传输实际数据。
8.2 四次挥手:
1 客户端完成数据传输后,将控制位FIN置1发给服务器,提出停止TCP连接的请求
2 服务器收到FIN后对其作出响应,确认这一方向上的TCP连接将关闭,将ACK置1返回给客户端
3 服务器再提出反方向的关闭请求,将FIN置1发送给客户端
4 客户端对服务器的请求进行确认,将ACK置1发送给服务器,双方向的关闭结束.
8.3 为什么不采用两次握手而用三次握手？为什么TCP客户端最后还要发送一次确认呢？
8.4 为什么连接的时候是三次握手，关闭的时候却是四次握手？一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
8.5 为什么最后发出ACK之后需要2MSL时间？
MSL：最大报文生存时间，超过这个时间报文将被丢弃。
TCP的TIME_WAIT需要等待2MSL，当TCP的一端发起主动关闭，三次挥手完成后发送第四次挥手的ACK包后就进入这个状态。
等待2MSL时间主要目的是：为了保证客户端发送的最后一个ACK报文段能够到达服务器。如果最后一个ACK报文段丢失，那么服务器会在超时后将重发第三次握手的FIN包，客户端接收到之后会再发一个ACK应答包，只有在服务器收到确认后才会进入close状态。即连接断开成功。
9. TCP与UDP区别总结：
一、TCP和UDP的概念
TCP（Transmission Control Protocol），传输控制协议。
UDP（User Data Protocol），用户数据报协议。
二、TCP和UDP的异同点
1. TCP和UDP的相同点：
TCP和UDP都是在网络层，都是传输层协议，都能都是保护网络层的传输，双方的通信都需要开放端口。
- TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
- TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保 证可靠交付
- TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的 UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
- 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
- TCP首部开销20字节;UDP的首部开销小，只有8个字节
- TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
10.从输入URL到界面显示经历了哪些过程？1、浏览器地址栏输入url
2、浏览器会先查看浏览器缓存--系统缓存--路由缓存，如有存在缓存，就直接显示。如果没有，接着第三步
3、域名解析（DNS）获取相应的ip
4、浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手
5、握手成功，浏览器向服务器发送http请求，请求数据包
6、服务器请求数据，将数据返回到浏览器
7、浏览器接收响应，读取页面内容，解析html源码，生成DOm树
8、解析css样式、浏览器渲染，js交互
其中，步骤2的具体过程是：
- 浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
- 操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)；
- 路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
- ISP缓存：,Internet服务提供商，若上述均失败，继续向ISP搜索。
浏览器渲染页面的原理
- 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件
- 然后浏览器从head标签开始逐行解析HTML代码，遇到link标签又会向服务器请求加载css文件，不过这个过程是异步的，有多个css文件，会多个同时加载。
- 继续往后如果遇到script标签或者js文件就会立即执行它，而且js文件的加载是同步的。
- 到了body标签就开始渲染页面了，按照从头到尾的顺序依次渲染dom元素，如果遇到img标签会异步向服务器发送请求加载图片文件，执行此过程时浏览器会继续渲染页面，因为加载图片文件是异步的。
- 如果遇到了dom节点的变化，元素尺寸变化，浏览器不得不回头重新渲染这部分代码。
- 不同于css文件，js是阻塞式的加载，当浏览器在执行js代码时，不会做其他的事情。只有js代码执行后，才会继续渲染页面。所以应该把js放到页面的底部。
（3）304协商缓存
304协商缓存开始吧。这是比较基础的知识。相信我，只要你提起304协商缓存，面试官一定会忍不住问你，什么是协商缓存？
这时就到了你展示一下自己丰富的浏览器缓存知识的时候了。我一般会这么答：浏览器缓存分为强制缓存和协商缓存，优先读取强制缓存。
强缓存是利用http头中的Expires和Cache-Control两个字段来控制的，用来表示资源的缓存时间。而expires是一个GMT格式的绝对时间，是比较旧的标准，cache-control通常是一个具体的时间长度，比较新，优先级也比较高。
而协商缓存包括etag和last-modified，last-modified的设置标准是资源的上次修改时间，而etag是为了应对资源修改时间可能很频繁的情况出现的，是基于资源的内容计算出来的值，因此优先级也较高。
协商缓存与强制缓存的区别在于强制缓存不需要访问服务器，返回结果是200，协商缓存需要访问服务器，命中协商缓存的话，返回结果是304。