-
申请相干
-
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