共计 7753 个字符，预计需要花费 20 分钟才能阅读完成。
申请相干
get post
- Get 办法的含意是申请从服务器获取资源，这个资源能够是动态的文本、页面、图片视频等。
- Post 向 URI 指定的资源提交数据，数据就放在报文的 body 里。
- GET 办法就是平安且幂等的, POST 都不是
平安和幂等的概念：
- 在 HTTP 协定里，所谓的「平安」是指申请办法不会「毁坏」服务器上的资源。
- 所谓的「幂等」，意思是屡次执行雷同的操作，后果都是「雷同」的。
罕用端口号
200
- 「204 No Content」也是常见的胜利状态码，与 200 OK 基本相同，但响应头没有 body 数据。
- 「206 Partial Content」是利用于 HTTP 分块下载或断点续传，示意响应返回的 body 数据并不是资源的全副，而是其中的一部分，也是服务器解决胜利的状态。
300
- 301 Moved Permanently」示意永恒重定向，阐明申请的资源曾经不存在了，需改用新的 URL 再次拜访。
- 302 Found」示意长期重定向，阐明申请的资源还在，但临时须要用另一个 URL 来拜访。
- 301 和 302 都会在响应头里应用字段 Location，指明后续要跳转的 URL，浏览器会主动重定向新的 URL。
- 304 Not Modified」不具备跳转的含意，示意资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存管制。
400
- 「403 Forbidden」示意服务器禁止拜访资源，并不是客户端的申请出错。
500
- 500 Internal Server Error」与 400 类型，是个抽象通用的错误码，服务器产生了什么谬误，咱们并不知道。
- 「501 Not Implemented」示意客户端申请的性能还不反对，相似“行将停业，敬请期待”的意思。
- 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，示意服务器本身工作失常，拜访后端服务器产生了谬误。
- 「503 Service Unavailable」示意服务器以后很忙，临时无奈响应服务器，相似“网络服务正忙，请稍后重试”的意思。
缓存
缓存类型
- 200 form memory cache : 不拜访服务器，个别曾经加载过该资源且缓存在了内存当中，间接从内存中读取缓存。浏览器敞开后，数据将不存在（资源被开释掉了），再次关上雷同的页面时，不会呈现 from memory cache。
- 200 from disk cache：不拜访服务器，曾经在之前的某个工夫加载过该资源，间接从硬盘中读取缓存，敞开浏览器后，数据仍然存在，此资源不会随着该页面的敞开而开释掉下次关上依然会是 from disk cache。
- 优先拜访 memory cache, 其次是 disk cache，最初是申请网络资源
强 / 协商缓存 协定
强缓存 expires / cache-control: max-age=600
- Expires：过期工夫，如果设置了工夫，则浏览器会在设置的工夫内间接读取缓存，不再申请
Cache-Control：当值设为 max-age=300 时，则代表在这个申请正确返回工夫（浏览器也会记录下来）的 5 分钟内再次加载资源，就会命中强缓存。
- private 无表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）public 可省略表明响应能够被任何对象（包含：发送申请的客户端，代理服务器，等等）缓存 no-cache 可省略缓存前必须确认其有效性 no-store 无不缓存申请或响应的任何内容 max-age=[s]必须响应的最大值
- （1）max-age：用来设置资源（representations）能够被缓存多长时间，单位为秒；
- （2）s-maxage：和 max-age 是一样的，不过它只针对代理服务器缓存而言；
- （3）public：可省略 批示响应可被任何缓存区缓存；响应能够被任何对象（包含：发送申请的客户端，代理服务器，等等）缓存
- （4）private：无参数，只能针对个人用户，而不能被代理服务器缓存；
- （5）no-cache：可省略 强制客户端间接向服务器发送申请, 也就是说每次申请都必须向服务器发送。服务器接管到 申请，而后判断资源是否变更，是则返回新内容，否则返回 304，未变更。这个很容易让人产生误解，使人误以为是响应不被缓存。实际上 Cache-Control: no-cache 是会被缓存的，只不过每次在向客户端（浏览器）提供响应数据时，缓存都要向服务器评估缓存响应的有效性。
- （6）no-store：无参数，禁止所有缓存（这个才是响应不被缓存的意思）。
协商缓存
last-modify + if-modify-since http1.0
- Last-Modified：浏览器向服务器发送资源最初的批改工夫
- If-Modified-Since：
- 当资源过期时（浏览器判断 Cache-Control 标识的 max-age 过期），发现响应头具备 Last-Modified 申明，则再次向服务器申请时带上头 if-modified-since，示意申请工夫。服务器收到申请后发现有 if-modified-since 则与被申请资源的最初批改工夫进行比照（Last-Modified）, 若最初批改工夫较新（大），阐明资源又被改过，则返回最新资源，HTTP 200 OK; 若最初批改工夫较旧（小），阐明资源无新批改，响应 HTTP 304 走缓存。
ETag + if-not-match HTTP 1.1
- Etag 是属于 HTTP 1.1 属性，它是由服务器（Apache 或者其余工具）生成返回给前端，用来帮忙服务器管制 Web 端的缓存验证。Apache 中，ETag 的值，默认是对文件的索引节（INode），大小（Size）和最初批改工夫（MTime）进行 Hash 后失去的。
- if-not-match 当资源过期时，浏览器发现响应头里有 Etag, 则再次像服务器申请时带上申请头 if-none-match(值是 Etag 的值)。服务器收到申请进行比对，决定返回 200 或 304
- 不缓存 Pragma: no-cache / catch-control: no-store
缓存优先级
- 程序的话是先判断 http1.0 的【Pragma: no-cache】再，Cache-Control 再 Expires，再【ETag，最初 Last-Modified，都满足就 304，有一项不满足就 200。】
强缓存
- expires 更多是为了反对 http/1.0 的上古浏览器的响应头，是一个具体的工夫点，可能客户端与服务器工夫不统一，或者网络提早导致工夫不精确
- cache-control: max-age 是一个秒数，两者同时呈现以 max-age 为准
协商缓存
- 个别分布式环境下（比方 CDN）很少应用 ETag，因为 ETag 依赖 Web Server 的哈希算法，不同 Web Server、不同版本、不同的配置，都会导致同样的文件 ETag 可能是不相等的。当然了，如果你能限度上述信息都一样，也能够应用 ETag，并不相对。
- Last-Modified 工夫精度是秒的问题，如果 1s 内批改了，Last-Modified 不会更改，eTag 是应用了摘要算法，能够及时刷新
不同行为引起的缓存
在 URI 输出栏中输出而后回车 / 通过书签拜访
- 浏览器发现该资源曾经缓存了而且没有过期（通过 Expires 头部或者 Cache-Control 头部），没有跟服务器确认，而是间接应用了浏览器缓存的内容。其中响应内容和之前的响应内容截然不同，例如其中的 Date 工夫是上一次响应的工夫。所以咱们也能看到该资源的 Size 为 from cache
F5/ 点击工具栏中的刷新按钮 / 右键菜单从新加载
- F5 会让浏览器无论如何都发一个 HTTP Request 给 Server，即便先前的响应中有 Expires 头部
Ctl+F5
- Ctrl+F5 要的是彻底的从 Server 拿一份新的资源过去，所以不光要发送 HTTP request 给 Server，而且这个申请外面连 If-Modified-Since/If-None-Match 都没有，这样就逼着 Server 不能返回 304，而是把整个资源原原本本地返回一份，这样，Ctrl+F5 引发的传输工夫变长了，天然网页 Refresh 的也慢一些。咱们能够看到该操作返回了 200，并刷新了相干的缓存管制工夫。
- 为了保障拿到的是从 Server 上最新的，Ctrl+F5 不只是去掉了 If-Modified-Since/If-None-Match，还须要增加一些 HTTP Headers。依照 HTTP/1.1 协定，Cache 不光只是存在 Browser 终端，从 Browser 到 Server 之间的两头节点 (比方 Proxy) 也可能表演 Cache 的作用，为了避免取得的只是这些两头节点的 Cache，须要通知他们，别用本人的 Cache 搪塞我，往 Upstream 的节点要一个最新的 copy 吧。
- 在 Chrome 51 中会蕴含两个头部信息，作用就是让两头的 Cache 对这个申请生效，这样返回的相对是陈腐的资源。Cache-Control: no-cache Pragma: no-cache
跨域问题
原理
- 协定 | 站点域名 | 端口号 有一个不一样就是跨域
体现
- 服务端跨域申请的资源无奈共享
解决方案
- jsonP
- iFrame 嵌套
- postMessage
- Cros
并发问题
并发
古代浏览器在与服务器建设了一个 TCP 连贯后是否会在一个 HTTP 申请实现后断开？什么状况下会断开？
HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接
- 尽管规范中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了反对。
- HTTP/1.1 就把 Connection 头写进规范，并且默认开启长久连贯，除非申请中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连贯
- 一个 TCP 连贯是能够发送多个 HTTP 申请的。
一个 TCP 连贯中 HTTP 申请发送能够一起发送么（比方一起发三个申请，再三个响应一起接管）？
- HTTP/1.1 存在一个问题，单个 TCP 连贯在同一时刻只能解决一个申请，任意两个 HTTP 申请从开始到完结的工夫在同一个 TCP 连贯里不能重叠。
HTTP/1.1 标准中规定了 Pipelining
- 一个反对长久连贯的客户端能够在一个连贯中发送多个申请（不须要期待任意申请的响应）。收到申请的服务器必须依照申请收到的程序发送响应。
- 然而这个性能在浏览器中默认是敞开的。因为 HTTP/1.1 是个文本协定，同时返回的内容也并不能辨别对应于哪个发送的申请，所以程序必须维持统一
- 古代浏览器默认是不开启 HTTP Pipelining
问题
- 一些代理服务器不能正确的解决 HTTP Pipelining。
- 正确的流水线实现是简单的。
- Head-of-line Blocking 连贯头阻塞
优化
- 维持和服务器曾经建设的 TCP 连贯，在同一连贯上程序解决多个申请。
- 和服务器建设多个 TCP 连贯。
HTTP2 提供了 Multiplexing 多路传输个性
- 能够在一个 TCP 连贯中同时实现多个 HTTP 申请
为什么有的时候刷新页面不须要从新建设 SSL 连贯？
- TCP 连贯有的时候会被浏览器和服务端维持一段时间。TCP 不须要从新建设，SSL 天然也会用之前的。
浏览器对同一 Host 建设 TCP 连贯到数量有没有限度？
- Chrome 最多容许对同一个 Host 建设六个 TCP 连贯
如果图片都是 HTTPS 连贯并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器磋商能不能用 HTTP2
- 能的话就应用 Multiplexing 性能在这个连贯上进行多路传输
用不了 HTTP2 或 https
- 浏览器就会在一个 HOST 上建设多个 TCP 连贯，连贯数量的最大限度取决于浏览器设置
- 这些连贯会在闲暇的时候被浏览器用来发送新的申请
- 如果所有的连贯都正在发送申请呢？那其余的申请就只能等等了。
协定 http/s
tcp-ip + ssl/tls 握手过程
- TCP/ IP 三次握手
- ssl 非对称加密 + 对称加密 + CA 证书
- UDP
http 演进
http0.9
- 只容许客户端发送 GET 这一种申请，且不反对申请头
- 只反对一种内容，即纯文本，反对 html 但 无奈插入图片
http1.0
- 申请与响应反对头域
- 响应对象以一个响应状态行开始
- 响应对象不只限于超文本
- 开始反对客户端通过 POST 办法向 Web 服务器提交数据，反对 GET、HEAD、POST 办法
- 反对长连贯（但默认还是应用短连贯），缓存机制，以及身份认证
http 1.1
增长新个性：
默认为长连贯
- HTTP 1.1 反对长连贯（PersistentConnection）和申请的流水线（Pipelining）解决，在一个 TCP 连贯上能够传送多个 HTTP 申请和响应，缩小了建设和敞开连贯的耗费和提早，在 HTTP1.1 中默认开启 Connection：keep-alive，肯定水平上补救了 HTTP1.0 每次申请都要创立连贯的毛病。
提供了范畴申请性能(宽带优化)
- HTTP1.0 中，存在一些节约带宽的景象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，并且不反对断点续传性能，HTTP1.1 则在申请头引入了 range 头域，它容许只申请资源的某个局部，即返回码是 206（Partial Content），这样就不便了开发者自在的抉择以便于充分利用带宽和连贯。这是反对文件断点续传的根底。
提供了虚拟主机的性能(HOST 域)
- 在 HTTP1.0 中认为每台服务器都绑定一个惟一的 IP 地址，因而，申请音讯中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的倒退，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的申请音讯和响应音讯都应反对 Host 头域，且申请音讯中如果没有 Host 头域会报告一个谬误（400 Bad Request）。
多了一些缓存解决字段
- HTTP/1.1 在 1.0 的根底上退出了一些 cache 的新个性，引入了实体标签，个别被称为 e -tags，新增更为弱小的 Cache-Control 头。
谬误告诉的治理
- 在 HTTP1.1 中新增了 24 个谬误状态响应码，如 409（Conflict）示意申请的资源与资源的以后状态发生冲突；410（Gone）示意服务器上的某个资源被永久性的删除。
问题：
- 高提早 — 队头阻塞(Head-Of-Line Blocking)
- 无状态个性 — 妨碍交互：协定对于连贯状态没有记忆能力，服务器并不知道它与上一条申请有何关联，换句话说就是掉登录态
- 明文传输 — 不安全性：传输内容没有加密，中途可能被篡改和劫持。
- 不反对服务端推送
改良计划：
针对队头阻塞：
- 1. 将同一页面的资源扩散到不同域名下，晋升连贯下限。尽管能专用一个 TCP 管道，然而在一个管道中同一时刻只能解决一个申请，在以后的申请没有完结之前，其余的申请只能处于阻塞状态。
- 2. 缩小申请数量
- 3. 内联一些资源：css、base64 图片等
- 4. 合并小文件缩小资源数
http2
增长新个性
二进制分帧传输：HTTP 2.0 的所有帧都采纳二进制编码
- 帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连贯中能够存在多个流
- 帧：客户端与服务器通过替换帧来通信，帧是基于这个新协定通信的最小单位。
- 音讯：是指逻辑上的 HTTP 音讯，比方申请、响应等，由一或多个帧组成。
- 流：流是连贯中的一个虚构信道，能够承载双向的音讯；每个流都有一个惟一的整数标识符（1、2 … N）；
多路复用 — 解决队头阻塞
- 多路复用容许同时通过繁多的 HTTP/2.0 连贯发动多重的申请 - 响应音讯。有了新的分帧机制后，HTTP/2.0 不再依赖多个 TCP 连贯去解决更多并发的申请。每个数据流都拆分成很多互不依赖的帧，而这些帧能够交织（乱序发送），还能够分优先级。最初再在另一端依据每个帧首部的流标识符把它们重新组合起来。HTTP 2.0 连贯都是长久化的，而且客户端与服务器之间也只须要一个连贯（每个域名一个连贯）即可。
头部压缩 — 解决微小的 HTTP 头部
- HTTP/1.1 的首部带有大量信息，而且每次都要反复发送。HTTP/2.0 要求通信单方各自缓存一份首部字段表，从而防止了反复传输。
- 申请优先级 — 先获取重要数据: 浏览器能够在发现资源时立刻分派申请，指定每个流的优先级，让服务器决定最优的响应秩序。这样申请就不用排队了，既节俭了工夫，也最大限度地利用了每个连贯。
- 服务端推送 — 填补空缺：申请 index.html 能够把首次依赖的 js、css 间接返回，办法是在 nginx 上配置一下就行
- 进步安全性
问题：
- TCP 以及 TCP+TLS 建设连贯的延时：TCP 连贯须要和服务器进行三次握手，即耗费完 1.5 个 RTT（Round-Trip Time，往返时延）
TCP 的队头阻塞并没有彻底解决：
- TCP 为了保障牢靠传输，有一个“超时重传”机制，失落的包必须期待重传确认。
- HTTP2 呈现丢包时，整个 TCP 都要期待重传，那么就会阻塞该 TCP 连贯中的所有申请。
- 多路复用导致服务器压力回升
- 多路复用容易 Timeout
http3 Google 基于 UDP 协定的 QUIC 协定
增长新个性
- 改良的拥塞管制、牢靠传输
- 疾速握手
- 集成了 TLS 1.3 加密
- 多路复用
- 连贯迁徙
问题：
NAT
- 在一些 NAT 网络环境下（如某些校园网），UDP 协定会被路由器等两头网络设备禁止，这时客户端会间接降级，抉择 HTTPS 等备选通道，保障失常业务申请。
边界问题
A、B 机器失常连贯后，B 机器忽然重启，问 A 此时处于 TCP 什么状态
- https://github.com/Advanced-Frontend/Daily-Interview-Question/issues/21
一个 TCP 连贯能够发多少个 HTTP 申请
- https://maimai.cn/article/detail?fid=1565594485&efid=2XGge6_3eNs_d2tiQsBWRw&use_rn=1
参考链接
- 【手动加精】硬核！30 张图解 HTTP 常见的面试题 https://www.cnblogs.com/xiaolincoding/p/12442435.html
- HTTP 的倒退和演变 https://www.cnblogs.com/xiaolincoding/p/12442435.html
- 一个 TCP 连贯能够发多少个 HTTP 申请 https://maimai.cn/article/detail?fid=1565594485&efid=2XGge6_3eNs_d2tiQsBWRw&use_rn=1
- 浏览器 HTTP 缓存机制 https://juejin.cn/post/6844903554587574285
- 强制缓存和协商缓存 https://juejin.cn/post/6844903838768431118
- 缓存优先级 https://segmentfault.com/q/1010000022541364
- http 差别 https://zhuanlan.zhihu.com/p/102561034
- HTTP 0.9 HTTP 1.0 HTTP 1.1 HTTP 2.0 区别 https://www.cnblogs.com/wupeixuan/p/8642100.html
- HTTP 缓存管制小结 https://imweb.io/topic/5795dcb6fb312541492eda8c
正文完
