http相关

1.http头信息

HTTP Request Header 请求头

Header解释示例
Accept指定客户端能够接收的内容类型Accept: text/plain, text/html
Accept-Charset浏览器可以接受的字符编码集。Accept-Charset: iso-8859-5
Accept-Encoding指定浏览器可以支持的web服务器返回内容压缩编码类型。Accept-Encoding: compress, gzip
Accept-Language浏览器可接受的语言Accept-Language: en,zh
Accept-Ranges可以请求网页实体的一个或者多个子范围字段Accept-Ranges: bytes
AuthorizationHTTP授权的授权证书Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control指定请求和响应遵循的缓存机制Cache-Control: no-cache
Connection表示是否需要持久连接。（HTTP 1.1默认进行持久连接）Connection: close
CookieHTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。Cookie: $Version=1; Skin=new;
Content-Length请求的内容长度Content-Length: 348
Content-Type请求的与实体对应的MIME信息Content-Type: application/x-www-form-urlencoded
Date请求发送的日期和时间Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect请求的特定的服务器行为Expect: 100-continue
From发出请求的用户的EmailFrom: user@email.com
Host指定请求的服务器的域名和端口号Host: www.zcmhi.com
If-Match只有请求内容与实体相匹配才有效If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为EtagIf-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since只在实体在指定时间之后未被修改才请求成功If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards限制信息通过代理和网关传送的时间Max-Forwards: 10
Pragma用来包含实现特定的指令Pragma: no-cache
Proxy-Authorization连接到代理的授权证书Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range只请求实体的一部分，指定范围Range: bytes=500-999
Referer先前网页的地址，当前请求网页紧随其后,即来路Referer: http://www.zcmhi.com/archives/71.html
TE客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息TE: trailers,deflate;q=0.5
Upgrade向服务器指定某种传输协议以便服务器进行转换（如果支持）Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-AgentUser-Agent的内容包含发出请求的用户信息User-Agent: Mozilla/5.0 (Linux; X11)
Via通知中间网关或代理服务器地址，通信协议Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning关于消息实体的警告信息Warn: 199 Miscellaneous warning

HTTP Responses Header 响应头

Header解释示例
Accept-Ranges表明服务器是否支持指定范围请求及哪种类型的分段请求Accept-Ranges: bytes
Age从原始服务器到代理缓存形成的估算时间（以秒计，非负）Age: 12
Allow对某网络资源的有效的请求行为，不允许则返回405Allow: GET, HEAD
Cache-Control告诉所有的缓存机制是否可以缓存及哪种类型Cache-Control: no-cache
Content-Encodingweb服务器支持的返回内容压缩编码类型。Content-Encoding: gzip
Content-Language响应体的语言Content-Language: en,zh
Content-Length响应体的长度Content-Length: 348
Content-Location请求资源可替代的备用的另一地址Content-Location: /index.htm
Content-MD5返回资源的MD5校验值Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range在整个返回体中本部分的字节位置Content-Range: bytes 21010-47021/47022
Content-Type返回内容的MIME类型Content-Type: text/html; charset=utf-8
Date原始服务器消息发出的时间Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag请求变量的实体标签的当前值ETag: “737060cd8c284d8af7ad3082f209582d”
Expires响应过期的日期和时间Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified请求资源的最后修改时间Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location用来重定向接收方到非请求URL的位置来完成请求或标识新的资源Location: http://www.zcmhi.com/archives/94.html
Pragma包括实现特定的指令，它可应用到响应链上的任何接收方Pragma: no-cache
Proxy-Authenticate它指出认证方案和可应用到代理的该URL上的参数Proxy-Authenticate: Basic
refresh应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）

Refresh: 5; url=

http://www.zcmhi.com/archives/94.html

Retry-After如果实体暂时不可取，通知客户端在指定时间之后再次尝试Retry-After: 120
Serverweb服务器软件名称Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie设置Http CookieSet-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer指出头域在分块传输编码的尾部存在Trailer: Max-Forwards
Transfer-Encoding文件传输编码Transfer-Encoding:chunked
Vary告诉下游代理是使用缓存响应还是从原始服务器请求Vary: *
Via告知代理客户端响应是通过哪里发送的Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning警告实体可能存在的问题Warning: 199 Miscellaneous warning
WWW-Authenticate表明客户端请求实体应该使用的授权方案

2.tcp协议丢包

1. 数据分片：发送端对数据进行分片，接受端要对数据进行重组，由TCP确定分片的大小并控制分片和重组

2. 到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认

3. 超时重发：发送方在发送分片时设置超时定时器，如果在定时器超时之后没有收到相应的确认，重发分片数据

4. 滑动窗口：TCP连接的每一方的接受缓冲空间大小固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出

5. 失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层;

6. 重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据;

7. 数据校验：TCP将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验或有差错，TCP将丢弃这个分片，并不确认收到此报文段导致对端超时并重发

3.HTTP协议

http1 协议

问题和缺陷

1.HTTP/1.0 每进行一次 HTTP 通信，都需要经历建立 TCP 连接、传输 HTTP 数据和断开 TCP 连接三个阶段；

2.在 HTTP/1.0 中，每个域名绑定了一个唯一的 IP 地址，因此一个服务器只能支持一个域名；

3.设计 HTTP/1.0 时，需要在响应头中设置完整的数据大小，如Content-Length: 901，这样浏览器就可以根据设置的数据大小来接收数据。不过随着服务器端的技术发展，很多页面的内容都是动态生成的，因此在传输数据之前并不知道最终的数据大小，这就导致了浏览器不知道何时会接收完所有的文件数据。

http1.1协议解决方案和缺陷

针对http1的解决方案

1.HTTP/1.1 中增加了持久连接的方法，它的特点是在一个 TCP 连接上可以传输多个 HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该 TCP 连接会一直保持。目前浏览器中对于同一个域名，默认允许同时建立 6 个 TCP 持久连接。减少握手挥手；

2.一台物理主机上绑定多个虚拟主机，每个虚拟主机都有自己的单独的域名，这些单独的域名都公用同一个 IP 地址。因此，HTTP/1.1 的请求头中增加了 Host 字段，用来表示当前的域名地址，这样服务器就可以根据不同的 Host 值做不同的处理。

3.HTTP/1.1 通过引入 Chunk transfer 机制来解决这个问题，服务器会将数据分割成若干个任意大小的数据块，每个数据块发送时会附上该个数据块的长度，最后使用一个零长度的块作为发送数据完成的标志。这样就提供了对动态内容的支持。

http1.1的缺陷

队头阻塞：持久连接虽然能减少 TCP 的建立和断开次数，但是它需要等待前面的请求返回之后，才能进行下一次请求。如果 TCP 通道中的某个请求因为某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是著名的队头阻塞的问题。

HTTP/1.1对带宽的利用率却并不理想：

第一个原因，TCP 的慢启动。刚开始 TCP 协议会采用一个非常慢的速度去发送数据，然后慢慢加快发送数据的速度，直到发送数据的速度达到一个理想状态，我们把这个过程称为慢启动。

      慢启动概念：发送端和接收端在连接建立之初，谁也不知道可用带宽是多少，因此需要一个估算机制，然后还要根据网络中不断变化的条件而动态改变速度。

         （1）最初让拥塞窗口按照指数级增长，这样可以提高发送数据吞吐量；

         （2）当拥塞窗口大小到达慢启动门限后，该成线性增长，目的是减少拥塞窗口的增长速度；

        （3）当发送端检测的网络拥塞时，立即把拥塞窗口减小为1，把慢启动门限调整为出现拥塞时拥塞窗口的一半目的是可以减少向网络中注入的数据量。

        （4） 重新开始指数级增长和线性增长。

第二个原因，同时开启了多条 TCP 连接，那么这些连接会竞争固定的带宽。

     TCP 连接之间又不能协商让哪些关键资源优先下载，这样就有可能影响那些关键资源的下载速度了。

第三个原因，HTTP/1.1 队头阻塞的问题。

     使用持久连接时，虽然能公用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。

HTTP2协议

一个域名只使用一个 TCP 长连接和消除队头阻塞问题。

这样整个页面资源的下载过程只需要一次慢启动，同时也避免了多个 TCP 连接竞争带宽所带来的问题。

就是队头阻塞的问题，等待请求完成后才能去请求下一个资源，这种方式无疑是最慢的，所以 HTTP/2 需要实现资源的并行请求，也就是任何时候都可以将请求发送给服务器，而并不需要等待其他请求的完成。

多路复用：通过引入二进制分帧层，数据会被转换为一个个带有请求 ID 编号的帧，通过协议栈将这些帧发送给服务器。接收到所有帧之后，会将所有相同 ID 的帧合并为一条完整的请求信息。

 可以设置请求的优先级：HTTP/2 提供了请求优先级，可以在发送请求时，标上该请求的优先级，这样服务器接收到请求之后，会优先处理优先级高的请求。

服务器推送：HTTP/2 还可以直接将数据提前推送到浏览器。用户请求一个 HTML 页面之后，服务器知道该 HTML 页面会引用几个重要的 JavaScript 文件和 CSS 文件，那么在接收到 HTML 请求之后，附带将要使用的 CSS 文件和 JavaScript 文件一并发送给浏览器，

头部压缩：解决巨大的 HTTP 头部 //使用专门的 HPACK 算法，每次请求和响应只发送差异头部，一般可以达到 50%~90% 的高压缩率。通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。

HTTP2的缺陷：

1.TCP 的队头阻塞

TCP 连接看成是两台计算机之前的一个虚拟管道，计算机的一端将要传输的数据按照顺序放入管道，最终数据会以相同的顺序出现在管道的另外一头。如果在数据传输的过程中，有一个数据因为网络故障或者其他原因而丢包了，那么整个 TCP 的连接就会处于暂停状态，需要等待丢失的数据包被重新传输过来。

使用 HTTP/1.1 时，浏览器为每个域名开启了 6 个 TCP 连接，如果其中的 1 个 TCP 连接发生了队头阻塞，那么其他的 5 个连接依然可以继续传输数据。所以随着丢包率的增加，HTTP/2 的传输效率也会越来越差。有测试数据表明，当系统达到了 2% 的丢包率时，HTTP/1.1 的传输效率反而比 HTTP/2 表现得更好。

2. TCP 建立连接的延时

1.在建立 TCP 连接的时候，需要和服务器进行三次握手来确认连接成功，也就是说需要在消耗完 1.5 个 RTT 之后才能进行数据传输。

2.如果使用 HTTPS 的话，还需要使用 TLS 协议进行安全传输，而使用 TLS 也需要一个握手过程，这样就需要有两个握手延迟过程。大致是需要 1～2 个 RTT

HTTP3特点

QUIC 协议

1.连接迁移： tcp连接基于四元组（ip，源端口，目的ip，目的端口），切换网络时；至少有一个要素发生变化，导致连接变化；QUIC 连接不以四元组作为标识，而是使用64位随机数connectionID 只要ID没有变化，连接依然可以维持

2.快速握手使用DH秘钥交换算法，1个RTT就可以交换秘钥；现在计算机也没有办法破解秘钥；

3.队头阻塞/多路复用功能：QUIC 协议实现了类似http2多路复用的功能；http2基于tcp协议，存在丢包阻塞tcp连接的情形；quic是基于udp，udp的数据包在接收端没有处理顺序，不存在队头阻塞的情形；

4.QUIC实现了流量控制、传输可靠性 

    流量控制：stream还没传输数据时，接收窗口就是最大接受窗口。随着接收方接收到数据，窗口不断缩小；

            接收方每次收到数据包，可以在发送 ACK 报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口（Receive Window，缩写：rwnd）。

            发送方收到接收窗口 rwnd 之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口 rwnd 的大小为 0 时，发送方就会停止发送数据，防止出现大量丢包情况的发生。

流量控制的意思是让发送方不要发送太快，要让接收方来得及接收，不然会导致数据溢出而丢失，TCP 的流量控制主要通过滑动窗口来实现的。可以看出，拥塞控制主要是控制发送方的发送策略，但没有考虑到接收方的接收能力，流量控制是对这部分能力的补齐。

   拥塞控制： QUIC重新实现了cubic算法进行拥塞控制，tcp修改拥塞控制在系统层面进行；QUIC修改拥塞控制只需要在应用层，并且根据不同网络环境、用户来动态选择拥塞控制算法

   前向纠错：使用前向纠错技术增加协议的容错性。如果中间有数据包丢失，可以根据剩余的包推算出丢失的包的数据；这样就大大增加了协议的容错性；

  单调递增的packetNumber： packetNumber严格递增，这样，如果packetN 丢失，重传的packetN就不会是N而是比N大的数。这样发送方收到消息就能方便知道ACK对应的是原始请求还是重传请求

   TCP将发送方的传输序列号与接收方的传送序列号进行了合并，这将导致同样的数据将携带 同样的序列号，因此导致了“重传歧义（retransmission ambiguity）”的问题。

   重传歧义会导致：如果算成原始请求的响应，但实际上是重传请求的响应，会导致采样 RTT 变大。如果算成重传请求的响应，但实际上是原始请求的响应，又很容易导致采样 RTT 过小。

(RTT

  • 设长了，重发就慢，丢了老半天才重发，没有效率，性能差；
  • 设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

)

    QUIC的数据包序列号时严格递增的，这样的设计极大的简化了QUIC中的丢包检测机制。

缺陷：

第一，从目前的情况来看，服务器和浏览器端都没有对 HTTP/3 提供比较完整的支持。Chrome 虽然在数年前就开始支持 Google 版本的 QUIC，但是这个版本的 QUIC 和官方的 QUIC 存在着非常大的差异。

第二，部署 HTTP/3 也存在着非常大的问题。因为系统内核对 UDP 的优化远远没有达到 TCP 的优化程度，这也是阻碍 QUIC 的一个重要原因。

第三，中间设备僵化的问题。这些设备对 UDP 的优化程度远远低于 TCP，据统计使用 QUIC 协议时，大约有 3%～7% 的丢包率。

4.完整的tcp协议

一个完整的 TCP 连接的生命周期包括了“建立连接”“传输数据”和“断开连接”三个阶段。

建立连接  断开连接

SYN，ACK，FIN存放在TCP的标志位，一共有6个字符，这里就介绍这三个：

SYN：代表请求创建连接，所以在三次握手中前两次要SYN=1，表示这两次用于建立连接，至于第三次什么用，在疑问三里解答。

FIN：表示请求关闭连接，在四次分手时，我们发现FIN发了两遍。这是因为TCP的连接是双向的，所以一次FIN只能关闭一个方向。

ACK：代表确认接受，从上面可以发现，不管是三次握手还是四次分手，在回应的时候都会加上ACK=1，表示消息接收到了，并且在建立连接以后的发送数据时，都需加上ACK=1,来表示数据接收成功。

seq:序列号，什么意思呢？当发送一个数据时，数据是被拆成多个数据包来发送，序列号就是对每个数据包进行编号，这样接受方才能对数据包进行再次拼接。

初始序列号是随机生成的，这样不一样的数据拆包解包就不会连接错了。（例如：两个数据都被拆成1，2，3和一个数据是1，2，3一个是101，102，103，很明显后者不会连接错误）

ack:这个代表下一个数据包的编号，这也就是为什么第二请求时，ack是seq+1，

在创建连接时，

1.客户端首先要SYN=1,表示要创建连接，

2.服务端接收到后，要告诉客户端：我接受到了！所以加个ACK=1，就变成了ACK=1,SYN=1

3.理论上这时就创建连接成功了，但是要防止一个意外（见疑问三），所以客户端要再发一个消息给服务端确认一下，这时只需要ACK=1就行了。

三次握手完成

在四次分手时，

1.首先客户端请求关闭客户端到服务端方向的连接，这时客户端就要发送一个FIN=1，表示要关闭一个方向的连接（见上面四次分手的图）

2.服务端接收到后是需要确认一下的，所以返回了一个ACK=1

3.这时只关闭了一个方向，另一个方向也需要关闭，所以服务端也向客户端发了一个FIN=1 ACK=1

4.客户端接收到后发送ACK=1，表示接受成功

四次分手完成！

疑问三，为什么需要三次握手

下面解释明明两次就可以建立连接的为什么还要加第三次的确认。

如果发送两次就可以建立连接话，那么只要客户端发送一个连接请求，服务端接收到并发送了确认，就会建立一个连接。

可能出现的问题：如果一个连接请求在网络中跑的慢，超时了，这时客户端会从发请求，但是这个跑的慢的请求最后还是跑到了，然后服务端就接收了两个连接请求，然后全部回应就会创建两个连接，浪费资源！

如果加了第三次客户端确认，客户端在接受到一个服务端连接确认请求后，后面再接收到的连接确认请求就可以抛弃不管了。

疑问四，为什么需要四次分手

TCP是双向的，所以需要在两个方向分别关闭，每个方向的关闭又需要请求和确认，所以一共就4次。

传输数据阶段。

在该阶段，接收端需要对每个数据包进行确认操作，也就是接收端在接收到数据包之后，需要发送确认数据包给发送端。所以当发送端发送了一个数据包之后，在规定时间内没有接收到接收端反馈的确认消息，则判断为数据包丢失，并触发发送端的重发机制。同样，一个大的文件在传输过程中会被拆分成很多小的数据包，这些数据包到达接收端后，接收端会按照 TCP 头中的序号为其排序，从而保证组成完整的数据。

5.一次完整的请求

1. 构建请求

首先，浏览器构建请求行信息

GET /index.html HTTP1.1

 2. 查找缓存

在真正发起网络请求之前，浏览器会先在浏览器缓存中查询是否有要请求的文件。其中，浏览器缓存是一种在本地保存资源副本，以供下次请求时直接使用的技术。

3. 准备 IP 地址和端口

你会发现在第一步浏览器会请求 DNS 返回域名对应的 IP。当然浏览器还提供了 DNS 数据缓存服务，

4. 等待 TCP 队列

答案依然是“不行”。Chrome 有个机制，同一个域名同时最多只能建立 6 个 TCP 连接，如果在同一个域名下同时有 10 个请求发生，那么其中 4 个请求会进入排队等待状态，直至进行中的请求完成。当然，如果当前请求数量少于 6，会直接进入下一步，建立 TCP 连接。

5. 建立 TCP 连接

6. 发送 HTTP 请求

首先浏览器会向服务器发送请求行，它包括了请求方法、请求 URI（Uniform Resource Identifier）和 HTTP 版本协议。

在浏览器发送请求行命令之后，还要以请求头形式发送其他一些信息，把浏览器的一些基础信息告诉服务器。比如包含了浏览器所使用的操作系统、浏览器内核等信息，以及当前请求的域名信息、浏览器端的 Cookie 信息，等等。

服务器端处理 HTTP 请求流程

1. 返回响应行

首先服务器会返回响应行，包括协议版本和状态码。

2.响应头

服务器也会随同响应向浏览器发送响应头。响应头包含了服务器自身的一些信息，比如服务器生成返回数据的时间、返回的数据类型（JSON、HTML、流媒体等类型），以及服务器要在客户端保存的 Cookie 等信息。

3.响应体

发送完响应头后，服务器就可以继续发送响应体的数据，通常，响应体就包含了 HTML 的实际内容。

如果响应行返回的是301，响应头中包含重定向url；再次发送请求；

6.登录状态是如何保持的？

下面我们再一起看下登录状态是如何保持的。用户打开登录页面，在登录框里填入用户名和密码，点击确定按钮。点击按钮会触发页面脚本生成用户登录信息，然后调用 POST 方法提交用户登录信息给服务器。

服务器接收到浏览器提交的信息之后，查询后台，验证用户登录信息是否正确，如果正确的话，会生成一段表示用户身份的字符串，并把该字符串写到响应头的 Set-Cookie 字段里，如下所示，然后把响应头发送给浏览器。

Set-Cookie: UID=3431uad;

浏览器在接收到服务器的响应头后，开始解析响应头，如果遇到响应头里含有 Set-Cookie 字段的情况，浏览器就会把这个字段信息保存到本地。比如把UID=3431uad保持到本地。当用户再次访问时，浏览器会发起 HTTP 请求，但在发起请求之前，浏览器会读取之前保存的 Cookie 数据，并把数据写进请求头里的 Cookie 字段里（如下所示），然后浏览器再将请求头发送给服务器。

7.为什么很多站点第二次打开速度会很快

DNS 缓存和页面资源缓存这两块数据是会被浏览器缓存的。

有两种：强缓存和协商缓存

强缓存是指，服务器的响应头设置expires或者Cache-Control，区别就在于 Expires 是http1.0的产物，Cache-Control是http1.1的产物，两者同时存在的话，Cache-Control优先级高于Expires；在某些不支持HTTP1.1的环境下，Expires就会发挥用处。

协商缓存：

上一次加载资源时，服务器返回的响应头，是对该资源的唯一标识，当资源变化时，Etag也会变化，当浏览器再次请求该资源时，请求头会在If-None-Match中带上Etag标识，服务器接受到If-None-Match的值后，会拿来跟该资源文件的Etag值做比较，如果相同，则表示资源文件没有发生改变，命中协商缓存。

还有一种是Last-Modified和If-Modified-Since：最后修改时间，但是如果一秒钟修改多次，可能会造成不准确，因此ETAG优先级要高，但是etag性能上要差一点，因为要通过算法计算出一个hash值，而Last-Modified只是记录一下时间；

浏览器缓存过程

浏览器第一次加载资源，服务器返回200，浏览器将资源文件从服务器上请求下载下来，并把response header及该请求的返回时间一并缓存；
    下一次加载资源时，先比较当前时间和上一次返回200时的时间差，如果没有超过cache-control设置的max-age，则没有过期，命中强缓存，不发请求直接从本地缓存读取该文件（如果浏览器不支持HTTP1.1，则用expires判断是否过期）；如果时间过期，则向服务器发送header带有If-None-Match和If-Modified-Since的请求；
    服务器收到请求后，优先根据Etag的值判断被请求的文件有没有做修改，Etag值一致则没有修改，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回200；
    如果服务器收到的请求没有Etag值，则将If-Modified-Since和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回200；

8.从输入URL到页面展示，这中间发生了什么？

  • 首先，浏览器进程接收到用户输入的 URL 请求，浏览器进程便将该 URL 转发给网络进程。
  • 然后，在网络进程中发起真正的 URL 请求。

         dns解析；以获取请求域名的服务器 IP 地址。

             

                DNS查询

              1.浏览器自身的DNS缓存

               2.搜索操作系统自身的DNS缓存

               3.读取hosts文件，看是否有该域名对应的IP地址

               4.浏览器向本地配置的DNS 服务器发起域名解析请求，DNS服务器先查找自身缓存，再向根服务器发出请求，进行递归查询（DNS 服务器先问根域名服务器.com 域名服务器的 IP 地址，然后再问.baidu 域名服务器，依次类推）

如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

  • 接着网络进程接收到了响应头数据，便解析响应头数据，并将数据转发给浏览器进程。浏览器进程接收到网络进程的响应头数据之后，发送“提交导航 (CommitNavigation)”消息到渲染进程；
  • 渲染进程接收到“提交导航”的消息之后，便开始准备接收 HTML 数据，接收数据的方式是直接和网络进程建立数据管道；
  • 最后渲染进程会向浏览器进程“确认提交”，这是告诉浏览器进程：“已经准备好接受和解析页面数据了”。浏览器进程接收到渲染进程“提交文档”的消息之后，便开始移除之前旧的文档，然后更新浏览器进程中的页面状态。
  • 渲染进程将 HTML 内容转换为能够读懂的 DOM 树结构。
  • 渲染引擎将 CSS 样式表转化为浏览器可以理解的 styleSheets，计算出 DOM 节点的样式。
  • 创建布局树。根据计算好的信息绘制页面

9.常用的HTTP方法有哪些？

GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
    POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
    PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
    HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
    DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
    OPTIONS：查询相应URI支持的HTTP方法。

10.http和https有什么区别

http是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

1、HTTPS协议需要到证书颁发机构(Certificate Authority，简称CA)申请证书，一般免费证书很少，需要交费。

2、HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。

3、HTTP和HTTPS使用的是完全不同的连接方式，使用的端口也不一样,前者是80,后者是443。

4、HTTP的连接很简单,是无状态的。

5、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全。

从上面可看出，HTTPS和HTTP协议相比提供了

· 数据完整性：内容传输经过完整性校验

· 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥

· 身份认证：第三方无法伪造服务端(客户端)身份

其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

11.HTTP状态码

403，资源禁止访问，和你的IP有关系

401，权限不足

304 没有修改

301 永久重定向

302 临时重定向

303 使用get方式重定向到另一个uri

206 只对资源的某一部分进行请求

12、HTTP 的安全风险

1、隐私泄露

由于 HTTP 本身是明文传输，用户和服务端之间的传输内容都能被中间者查看。也就是说 你在网上搜索、购物、访问的网点、点击的页面等信息，都可以被「中间人」获取。

2、页面劫持

隐私泄露的风险比较隐蔽，用户基本感知不到。但另外一类劫持的影响就非常明显非常直接了——页面劫持，也就是直接篡改用户的浏览页面。

HTTP劫持分类

根据劫持路径分类：DNS 劫持、客户端劫持、链路劫持。


 

13.HTTPS的缺点

1、速度慢

(1)、网络耗时

由于协议的规定，必须要进行的网络传输。比如 SSL 完全握手，302 跳转等。HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电。

(2)、计算耗时

无论是客户端还是服务端，都需要进行对称加解密，协议解析，私钥计算，证书校验等计算，增加大量的计算时间。

3、成本较高

(1)、服务器成本

HTTPS 的私钥计算会导致服务端性能的急剧下降，甚至不到 HTTP 协议的十分之一，也就是说，如果 HTTP 的性能是 10000cps，HTTPS 的性能可能只有几百 cps，会增加数倍甚至数十倍的服务器成本。

(2)、证书成本

根据证书个数及证书类型，一年可能需要花费几百到几百万不等的证书成本。

(3)、开发和运维成本

HTTPS 协议比较复杂，包括协议的配置，证书的更新，过期监控，客户端的兼容等一系列问题都需要具备专业背景的技术人员跟进处理。