Web 服务缓存 ⼤致可以分为：数据库缓存、服务器端缓存（代理服务器缓存、CDN 服务器缓存）、浏览器缓存。

浏览器缓存 也包含很多内容： HTTP 缓存、indexDB、cookie、localstorage 等等。 这⾥只讨论 HTTP 缓存相关内容 。 浏览器缓存主要是 HTTP 协议定义的缓存机制。

HTTP缓存: (优化⻚⾯加载的效率, 如果没有缓存策略, 每次重新加载⻚⾯, 会⾮常慢!)

浏览器缓存, HTTP缓存分类

浏览器缓存分为 强缓存 和 协商缓存。浏览器加载⼀个⻚⾯的简单流程如下：

1.浏览器先根据这个资源的 http头信息 来 判断是否命中强缓存。 如果命中则直接加载在缓存中的资源，并不会将请求发送到服务器。（强缓存）

2.如果未命中强缓存，则浏览器会将资源加载请求发送到服务器。 服务器来判断浏览器本地缓存是否失效。 若可以使⽤，则服务器并不会返回资源信息，浏览器继续从缓存加载资源。（协商缓存）

3.如果未命中协商缓存，则服务器会将完整的资源返回给浏览器，浏览器加载新资源，并更新缓存。（新的请求）

强缓存 (验证缓存是否过期)

(进⾏判断缓存是否有效, 就是判断资源是否过期, 如果未过期, 直接⽤缓存) 强缓存命中强缓存时，浏览器并不会将请求发送给服务器。

在Chrome的开发者⼯具中看到http的返回码是200，但是在Size列会显示为(from cache)。

强缓存是利⽤http的返回的响应头中的Expires或者Cache-Control (优先级更⾼) 两个字段来控制的，⽤来表示资源 的缓存时间。

Expires: 指定⼀个具体时间(如上图), 到了这个时间了, 缓存过期了, 在时间内, 都是有效的, 可以直接读

Cache-Control : 指定⼀个过期时间 (如上图), 这个资源你加载到后, 可以⽤ 15552000s

协商缓存 (强缓存未命中-发送请求进⾏协商)

看看过期时间, ⻝品没过期, 直接吃 (直接读缓存, 不发请求) 命中强缓存!

⻝品过期时间过了, 能不能吃呢? 问问专家(服务器), 专家瞅了⼀眼, 还能吃, 不会死⼈, 重新标了个过期时间(有科学 依据) (响应304, 不返回内容) , 可以⽤ (协商缓存)

如果问过专家(服务器), 专家瞅了⼀眼, 呀真不能⽤了, 原来的不要了, 我重新给你发⼀个 (响应200, 并返回内容) 协商缓存 若未命中强缓存(强缓存过期了)，则浏览器会将请求发送⾄服务器。

服务器根据http头信息中的 Last-Modify/If-Modify-Since 或 Etag/If-None-Match 来判断是否命中协商缓 存。 如果命中，则http返回码为304 (你本地之前加载的资源是有效的)，浏览器从缓存中加载资源。

整体请求缓存流程

浏览器第⼀次请求

浏览器第二次请求

在地址栏输⼊地址到⻚⾯加载出来中间发⽣了什么？浏览器的渲染原 理 (这个和在地址栏输⼊地址到⻚⾯加载出来中间发⽣了什么？是同⼀个问 题) 浏览器拿到资源到⻚⾯加载完成 之间还有哪些过程?

当我们在web浏览器的地址栏中输⼊： www.baidu.com ，具体发⽣了什么？

1.对 www.baidu.com 这个⽹址进⾏DNS域名解析，得到对应的IP地址

2.根据这个IP，找到对应的服务器，发起TCP的三次握⼿

3.建⽴TCP连接后, 发起HTTP请求

4.服务器响应HTTP请求，浏览器得到html代码

5.浏览器解析html代码，并请求html代码中的资源（如js、css、图⽚等）（先得到html代码，才能去找这些资 源）

6.浏览器对⻚⾯进⾏渲染呈现给⽤户

7.服务过程完毕, 关闭TCP连接, 四次挥⼿

因为post请求, 是⾮幂等的,从302中, 细化出了 303 和 307

简⽽⾔之: 301 302 307 都是重定向 304 协商缓存

http的keep-alive是什么?

作⽤：使客户端到服务器端的连接持续有效(⻓连接)，当出现对服务器的后继请求时， Keep-Alive功能避免了建⽴或者重新建⽴连接。

早期 HTTP/1.0 在每次请求的时候，都要创建⼀个新的连接，⽽创建连接的过程需要消耗资源和时间,

为了减少资源消耗、缩短响应时间，就需要复⽤已有连接.

在后来的 HTTP/1.0 以及 HTTP/1.1 中引⼊了复⽤连接的机制，也就是在请求头中加⼊Connection: keep-alive，

以此告诉对⽅这个请求响应完成后不要关闭连接，下⼀次还⽤这个请求的连接进⾏后续交流。

协议规定，如果想要保持连接，则需要在请求头中加上 Connection: keep-alive

keep-alive 的优点

(复⽤连接) 较少的 CPU 和内存的占⽤（因为要打开的连接数变少了, 复⽤了连接） 减少了后续请求的延迟（⽆需再进⾏握⼿） ...

缺点: 因为在处理的暂停期间，本来可以释放的资源仍旧被占⽤。请求已经都结束了, 但是还⼀直连接着也不合适

解决：Keep-Alive: timeout=5, max=100

timeout：过期时间5秒（对应httpd.conf⾥的参数是：KeepAliveTimeout），

max是最多⼀百次请求，强制断掉连接。

就是在timeout时间内⼜有新的连接过来，同时max会⾃动减1，直到为0，强制断掉

什么是DNS 解析

DNS解析（域名解析服务器） 将 域名 转换成 ip地址 (⼀个域名和ip的映射关系, 具体登记在哪⾥, 看我们如何申请关联的!)

假定请求的是 www.baidu.com

a）⾸先会搜索浏览器⾃身的DNS缓存（缓存时间⽐较短，⼤概只有1分钟，且只能容纳1000条缓存）

b）如果浏览器⾃身的缓存⾥⾯没有找到，那么浏览器会搜索系统⾃身的DNS缓存

c）如果还没有找到，那么尝试从 hosts ⽂件⾥⾯去找 (⼀个系统电脑的⽂件, 可以编辑, 可以存 域名 和 ip 的对应关系)

d）在前⾯三个过程都没获取到的情况下，就递归地去域名服务器去查找(就近查找)，具体过程如下 DNS优化两个⽅⾯：DNS缓存、DNS负载均衡 (准备多台dns服务器, 进⾏dns解析)

TCP 三次握⼿理解 (双⽅确认)

TCP是⼀个端到端的 可靠 ⾯相连接的协议，

HTTP基于传输层TCP协议不⽤担⼼数据传输的各种问题（当发⽣错误时，可以重传）

根据这个IP，找到对应的服务器，发起TCP的三次握⼿ (tcp 三次握⼿四次挥⼿)

为什么要3次握⼿

我们假定第⼀次发送的请求, 因为⽹络延迟很慢才到达服务端， 然后客户端以为这服务器居然不理睬我，然后默默的关闭的等待连接的请求，⾛开了（好⽐追⼥神）；

但事实呢？⼥神（服务器）是因为各种各样的原因，很晚才看到，然后说我接受你了, 同意你的要求咱们两结婚 吧！

但是，A早已经远⾛⾼⻜，这个请求A完全不会收到（在第⼆次握⼿，服务端打开连接，等待客户端的响应）， 那么⼥⽣呢，以为对⽅收到了，就会⼀直等待，这样B的资源就会被浪费的（创建连接的时候，空间浪费以及端⼝消耗）；

⽽三次握⼿, 就不会发⽣，服务端同意连接了，但是A缺⼀直没有下⼀步的动作，导致资源浪费

关闭TCP连接四次挥⼿的理解 (客⽓挽留)

⽬标: 关闭连接(四次挥⼿)

不能直接⼀次性断开连接(双⽅知晓), 万⼀还有什么数据没有传完, 造成数据的丢失,

这和有礼貌的好友道别⼀样：（a：客户端 b:服务端）

1、⼀开始A想要回家离开，但是呢？怕B还有事情要交代，那么呢？只好先向B打招呼，我要⾛了，请求停⽌交谈 (请求断开连接) (此时，a到B的连接没有断开，依旧可以进⾏通信）；

2、同意A的请求，说好的，但是我这⾥可能还有⼀些话（数据）没说完。我检查看看, 你等等, 等我说完你再⾛。

3、B确实没啥要补充的了，就告知你我可以撤了

4、A说好的，知道了，88；（B得知A⾛开了，关闭了⾃⼰的连接 )

完整的⼀次 http 请求流程才算结束

计量单位

• 1bit（位） ：1bit
• 1Byte (字节)：1Byte =8bit
• 1KB=1024Byte=1*2的10次幂Byte
• 1M=1024KB =1*2的20次幂Byte
• 1G=1024MB
• 1T=1024GB

5层参考模型

• 应用层 ：支持各种网络应用： FTP、SMTP、HTTP
• 传输层：进程的数据传输 TCP、UDP
• 网络层：源主机到目的主机的数据分组路由与转发 IP、ICMP、OSPF协议
• 数据链路层：把网络层传下来的数据包组装成帧 Ethrnet，PPP
• 物理层 :比特传输