[[深刻01] 执行上下文](https://juejin.im/post/684490...
[[深刻02] 原型链](https://juejin.im/post/684490...
[[深刻03] 继承](https://juejin.im/post/684490...
[[深刻04] 事件循环](https://juejin.im/post/684490...
[[深刻05] 柯里化偏函数函数记忆](https://juejin.im/post/684490...
[[深刻06] 隐式转换和运算符](https://juejin.im/post/684490...
[[深刻07] 浏览器缓存机制（http缓存机制）](https://juejin.im/post/684490...
[[深刻08] 前端平安](https://juejin.im/post/684490...
[[深刻09] 深浅拷贝](https://juejin.im/post/684490...
[[深刻10] Debounce Throttle](https://juejin.im/post/684490...
[[深刻11] 前端路由](https://juejin.im/post/684490...
[[深刻12] 前端模块化](https://juejin.im/post/684490...
[[深刻13] 观察者模式公布订阅模式双向数据绑定](https://juejin.im/post/684490...
[[深刻14] canvas](https://juejin.im/post/684490...
[[深刻15] webSocket](https://juejin.im/post/684490...
[[深刻16] webpack](https://juejin.im/post/684490...
[[深刻17] http 和 https](https://juejin.im/post/684490...
[[深刻18] CSS-interview](https://juejin.im/post/684490...
[[深刻19] 手写Promise](https://juejin.im/post/684490...
[[深刻20] 手写函数](https://juejin.im/post/684490...

[[react] Hooks](https://juejin.im/post/684490...

[[部署01] Nginx](https://juejin.im/post/684490...
[[部署02] Docker 部署vue我的项目](https://juejin.im/post/684490...
[[部署03] gitlab-CI](https://juejin.im/post/684490...

[[源码-webpack01-前置常识] AST形象语法树](https://juejin.im/post/684490...
[[源码-webpack02-前置常识] Tapable](https://juejin.im/post/684490...
[[源码-webpack03] 手写webpack - compiler简略编译流程](https://juejin.im/post/684490...
[[源码] Redux React-Redux01](https://juejin.im/post/684490...
[[源码] axios ](https://juejin.im/post/684490...
[[源码] vuex ](https://juejin.im/post/684490...
[[源码-vue01] data响应式和初始化渲染 ](https://juejin.im/post/684490...
[[源码-vue02] computed 响应式 - 初始化，拜访，更新过程 ](https://juejin.im/post/684490...

前置常识

一些单词

protocol：协定permanent：永恒的permanently：永恒地temporary：临时的grammar：语法

TCP/IP协定 - 应用层，传输层，网络层，数据链路层

应用层：HTTP FTP TELNET SMTP DNS等协定
传输层：TCP协定 UDP协定
网络层：IP协定 ICMP协定等
数据链路层

( TCP和UDP ) 传输层协定应用 ( IP协定 )网络层协定从一个网络传送数据包到另一个网络

把 ( IP ) 想像成一种 ( 高速公路 )，它容许其它协定在下面行驶并找到到其它电脑的进口。
( TCP和UDP ) 是高速公路上的 ( “卡车” )
卡车携带的 ( 货物 ) 就是像 ( HTTP )，文件传输协定FTP这样的协定

TCP首部图解

总结
- Ack = Seq + 1 ---------------------- 确认号 = 序号 + 1
- 序号Seq ( 简称ISN )
- 确认号Ack
- 标记位：
  - SYN新建一个链接
  - FIN开释一个链接
  - ACK为1时Seq序号才无效

TCP三次握手

三次握手：指的是建设TCP链接时，须要客户端和服务端总的发送的三个包

第一次握手
- 客户端发送一个 ( 标记位SYN=1，序号Seq=x ) 的 ( 连贯包 ) 到服务器
 - SYN=1示意新建链接
 - 客户端状态：由 CLOSED状态 => SYN_SENT状态
第二次握手
- 服务器发送一个 ( 标记位SYN=1,ACK=1,序号Seq=y,确认号Ack=x+1) 的 ( 确认包 ) 给客户端
 - Ack = Seq + 1 ( 确认号 = 序号 + 1 )
 - 服务端状态：由 CLOSED状态 => SYN_RCVD状态
第三次握手
- 客户端发送一个 ( 标记位SYN=0,ACK=1,序号Seq=x+1,确认号Ack=y+1) 的 ( 确认包 ) 给服务器
 - established：是建设的意思
 - 客户端和服务端状态都变成 ESTABLISHED 状态

TCP建设链接 - 为什么须要第三次握手

为什么只有三次握手，能力确认单方的发送和接管能力是否失常，而两次却不能够？？

第一次握手：
- 客户端发送连贯包，服务端收到了
- ( 服务端 ) 就能得出结论：( 客户端的发送能力，服务端的接管能力是失常的 )
第二次握手
- 服务端发送确认包，客服端收到了
- ( 客户端 ) 就能得出结论：( 服务端的接管、发送能力，客户端的接管、发送能力是失常的 )
- 留神：此时服务端并不能确认客户端的接管能力是否失常
第三次握手
- 客户端发送确认包，服务端收到了
- ( 服务端 ) 就能得出结论：( 客户端的接管、发送能力，和服务端的接管、发送能力都是失常的 )
总结为什么须要三次握手：
- 为了实现牢靠数据传输， TCP 协定的通信单方都必须保护一个序列号，标识发送进来的数据包哪些曾经被对方收到
- 三次握手的过程即是通信单方互相告知序列号起始值，并确认对方曾经收到了序列号起始值的必经步骤
- 如果只是两次握手，至少只有连贯发起方的起始序列号能被确认，另一方抉择的序列号则得不到确认，也就是下面每次握手剖析的，如果两次握手，服务端是没法确认客户端的接管能力是失常的
- 避免已生效的连贯申请又传送到服务器端，因此产生谬误

四次挥手

标记位：FIN示意开释一个链接
留神：客户端和服务端都能够被动发动挥手动作
established：建设的意思 ( ESTABLISHED )
过程：( 假如由客户端发动，标记位FIN=1示意开释链接 )
第一次挥手
- 客户端发送一个 ( 标记位FIN=1,序号Seq=u ) 的 ( 开释包 ) 到服务器
- 客户端状态：由 ESTABLISHED状态 => FIN_WAIT1状态
- 表明的是：被动方(客户端)的报文发送完了，然而被动方(客户端)还是能够接管报文
第二次挥手
- 服务器返回一个 ( 标记位ACK=1,确认号Ack=u+1,序号Seq=v ) 的 ( 确认包 ) 到客户端
- 服务端状态：由 ESTABLISHED状态 => COLSE_WAIT状态
第三次次挥手
- 服务器发送一个 ( 标记位FIN=1,ACK=1,确认号Ack=u+1,序号Seq=w ) 的 ( 开释包 ) 到客户端
- 服务端状态：由 COLSEWAIT状态 => LAST_ACK状态
 - 表明的是：被动方(服务端)的报文发送完了，然而被动方(服务端)还是能够接管报文
第四次次挥手
- 客户端送一个 ( 标记位ACK=1，确认号Ack=w+1, 序号Seq=u+1 ) 的 ( 确认包 ) 到服务端
- 客户端状态：由 FIN_WAIT2状态 => TIME_WAIT状态
留神：
- 客户端通常是被动敞开，进入TIME_WAIT状态
- 服务端通常是被动敞开，不会进入TIME_WAIT状态

TIME_WAIT状态 - 2MSL状态

TIME_WAIT状态也称为2MSL期待状态
每个具体TCP实现必须抉择一个报文段最大生存工夫MSL（Maximum Segment Lifetime），它是任何报文段被抛弃前在网络内的最长工夫。

为什么第四次挥手后，客户端要进入TIME_WAIT状态，而不是间接敞开

因为要确保服务器是否收到了Ack确认报文，即在2MSL工夫内没有再收到服务端的FIN报文，证实曾经收到ACK
如果没有收到的话，服务器会从新发 FIN 报文给客户端，客户端再次收到 ACK 报文之后，就晓得之前的 ACK 报文失落了，而后再次发送 ACK 报文。
TIME_WAIT 继续的工夫至多是一个报文的来回工夫。个别会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方胜利就是 ACK 报文，此时处于 CLOSED 状态。

一些重要的HTTP状态码

100 Continue ------------------------- 客户端应持续申请101 Switching Protocols -------------- 切换协定，协定降级200 ok ------------------------------- 申请被失常解决201 created -------------------------- http-post申请的后果，示意 ( 胜利创立一个或多个资源 )202 accepted ------------------------- http-post申请的后果，示意 ( 承受申请，但尚未解决实现 )204 no content ----------------------- 申请解决胜利，但没有资源能够返回206 partial content ------------------ 申请局部资源301 moved permanently ---------------- 永恒重定向，须要变更书签援用302 Found ---------------------------- 长期重定向303 set other ------------------------ 长期重定向，应采纳 GET 办法获取资源304 not modified --------------------- 资源未被批改，协商缓存307 Temporary Redirect --------------- 长期重定向400 bad request ---------------------- 谬误的申请401 unauthorized --------------------- 认证失败 ------------------------- (未受权)403 forbidden ------------------------ 认证胜利，但权限不够 ------------- (权限不够)404 not found ------------------------ 资源未找到405 method not allowed --------------- 申请办法谬误500 Internal Server Error ------------ 服务端谬误502 Bad Gateway ---------------------- 网关谬误503 Service Unavailable -------------- 服务器过载504 Gateway Time Out ----------------- 网关超时

HTTP

HTTP的毛病

通信应用 明文（不加密），内容可能会被 窃听
不验证通信方的 身份，因而有可能遭逢 假装
无奈证实报文的 完整性，所以有可能已遭 篡改

http自身不具备加密性能，报文应用明文流传
为什么设计成不加密：
- TCP/IP 协定族的工作机制，通信内容在所有的通信线路上都有
可能受到窥视。
- 即便曾经过加密解决的通信，也会被窥视到通信内容，这点和未
加密的通信是雷同的。只是说如果通信通过加密，就有可能让人
无奈破2解报文信息的含意，但加密解决后的报文信息自身还是会
被看到的

加密的对象有哪些 - (加密解决避免被窃听)

通信线路的加密 - 平安的通信线路
通信内容的加密 - 内容有被篡改的危险

通信线路的加密

http 通过和 SSL(secure socket layer 安全套接层) 或者和 TLS(transport layer security 平安层传输协定)的组合应用，来加密http的通信内容

通信内容的加密

内容仍有被篡改的危险

HTTP 协定中的申请和响应不会对通信方进行确认。
- 服务器是否就是发送申请中 URI 真正指定的主机
- 返回的响应是否真的返回到理论提出申请的客户端，等相似问题。

不验证通信单方的隐患

无奈确定响应的服务器，就是要申请的指标服务器
无奈确定响应内容是是否真正发送给了申请时的客服端
无奈确定正在通信的对方是否具备拜访权限。如果Web服务器上保留着重要的信息，只想发给特定用户通信的权限。
无奈断定申请是来自何方、出自谁手
即便是无意义的申请也会照单全收。无奈阻止海量申请下的 DoS 攻打（Denial of Service，拒绝服务攻打）
留神：http协定无奈确定通信方，然而SSL能够
- SSL不仅提供加密解决，而且还应用了一种被称为证书的伎俩，
可用于确定方 
- 证书由值得信赖的第三方机构颁发，用以证实服务器和客户端是
理论存在的

完整性指信息的准确度
接管到的内容可能有误

什么是中间人攻打

像这样，申请或响应在传输途中，遭攻击者拦挡并篡改内容的攻打称为中间人攻打
（Man-in-the-Middle attack，MITM）。

应用http协定确认确认报文完整性的办法

MD5 和 SHA-1 等散列值校验的办法
以及用来确认文件的数字签名办法。

HTTP报文 = 报文首部 + 空行 + 报文主体

申请报文首部 = 申请行 + 申请头

响应报文首部 = 响应行 + 响应头

用于http协定交互的信息被称为http报文
申请报文：客户端的报文
响应报文：服务端的报文
http报文：由多行数据形成的字符串文本

HTTPS

HTTPS = HTTP + 加密 + 认证 + 完整性爱护

ssl是独立与http协定的，所以其余应用层的协定也能够应用ssl

HTTPS的加密形式 - 混合加密，即对称加密和非对称加密一起应用

https采纳混合加密
- 在替换密钥环节：应用公开加密 - (非对称加密)
- 之后的建设通信，替换报文阶段：应用共享加密 - (对称加密)
- ( 非对称加密 ) 的处理速度要比 ( 对称加密 ) 慢，所以各有劣势，所以https采纳组合加密

公开密钥加密形式 - 无奈证实公开密钥自身就是货真价实的公开密钥

证实公开密钥正确定的证书

公开密钥加密存在的问题
- 无奈证实公开密钥就是货真价实的公开密钥，因为公开密钥在流传过程中可能被替换
<table bgcolor=orange><tr><td>问题：如何解决公开加密形式的公钥的安全性 ????? </td></tr></table>
<table bgcolor=yellow><tr><td>解决：数字证书机构颁发的 ( 公开密钥证书 )</td></tr></table>

`数字证书认证机构的业务流程`

前置常识：
- 服务器有一对密钥：一个公钥，一个私钥
- 证书颁发机构也有一对密钥：一个公钥，一个私钥，公钥是提前内置在浏览器中的
- 证书颁发机构用 (本人的私钥) 对 ( 服务器的公钥 ) 进行加密，做数字签名，并生成公钥证书
具体流程
- 1. 服务器把本人的 ( 公钥 ) 向证书认证机构申请证书
- 1. 证书颁发机构用本人的 ( 私钥 ) 对服务器的 ( 公钥 ) 进行数字签名，并生成 ( 公钥证书 )
- 1. ( 服务器 ) 向 ( 客服端 ) 发送证书颁发机构颁发的 ( 公钥证书 )
- 1. ( 客服端 ) 收到公钥证书后，利用内置在本人的 ( 证书颁发机构的公钥 ) 解密 (公钥证书中，证实服务器的公钥的真实性 )
  2. 验证通过
    - 阐明服务器的公钥是证书机构颁发的公钥
    - 服务器的公钥值得信赖
- 1. 如果是实在的服务的公钥证书，那么 ( 客户端就会用服务器的公钥加密之后在对称加密才会用到的密钥 ) 并发送给服务器
- 1. 服务器收到 ( 加密后的信息后 ) 用本人的私钥 ( 解密 )，解密后服务端就获取到了 ( 对称加密的密钥了 )
- 1. 接下来，通信双发就能够进行 ( 对称加密通信了 )，即能够建设通信，替换报文了

https的通信过程 - SSL握手过程

名称解释：
- handshake：握手
- certificate：证书
- cipher：明码
- Suite：一套
- cipher suite：明码组件
- spec：规格
- exchange：替换
- ClientKeyExchange
- ChangeCipherSpec：扭转明码规格，即非对称加密替换公共密钥后，应用对称加密通信
SSL握手过程 - 留神联合认证，组合加密一起来了解
(1) ( 客户端 ) 通过发送 ( client hello 报文 ) 开始 SSL 通信
- 报文中蕴含：( SSL版本 )，( 加密组件列表 )
- 加密组件列表cipher suite蕴含：加密算法，密钥长度等
(2) ( 服务端 ) 发送 ( erver Hello 报文 ) 作为应答
- 报文中同样蕴含：( SSL版本 )，( 加密组件列表 )
- ( 服务器 ) 的加密组件内容是从接管到的 ( 客户端 ) 加密组件内 ( 筛选 ) 进去的
(3) ( 服务器 ) 发送 ( certificate ) 加密报文，报文中蕴含 ( 公开密钥证书 )
(4) ( 服务器 ) 发送 ( Server Hello Done ) 报文告诉客户端，最后阶段的 ( SSL握手协商，即第一次SSL握手完结 ) 局部完结
(5) 第一次SSL握手完结后，( 客户端 ) 发送 ( Client Key Exchange ) 报文作为回应
- 报文中蕴含：Pre-Master secret 随机明码串，该报文应用3中的公共密钥证书加密
(6) ( 客户端 ) 持续发送 ( Change Cipher Spec ) 报文
- 该报文会提醒服务器，在此报文之后的通信会采纳 Pre-master secret 密钥加密
(7) ( 客户端 ) 发送 ( Finished ) 报文
- 该报文蕴含连贯至今，全副报文的整体校验值
- 这次握手协商是否胜利，要以服务器是否可能正确解密该报文作为判断规范
(8) ( 服务器 ) 同样发送 ( Change Cipher Spec ) 报文
(9) ( 服务器 ) 同样发送 ( Finished ) 报文
(10) 发送HTTP申请，服务端和客户端的Finished报文交换结束之后，SSL连贯就算建设实现，通信会受到 SSL 爱护
- 从此处开始进行应用层的通信，即发送 HTTP 申请
(11) 响应HTTP申请
(12) 最初由客户端断开连接。断开连接时，发送 close_notify 报文。

url到页面显示过程

DNS域名解析 // 将域名解析成IP地址
建设TCP链接 // 三次握手
客户端发动HTTP申请
服务器解决申请，并返回HTTP报文
浏览器解析渲染页面
断开TCP链接 // 四次挥手

url到页面显示的过程1. DNS域名解析- DNS是 ( domain name system ) 域名零碎的缩写- 将域名解析成ip地址- 一个域名对应一个以上的ip地址- 为什么要将域名解析成ip地址？    - 因 ( 为TCP/IP网络 ) 是通过 ( ip地址 ) 来确定 ( 通信对象 )，不晓得ip就无奈将音讯发送给对方- DNS域名解析的过程：// 递归查问和迭代查问1. ( 浏览器 ) 中查问 DNS 缓存，有则进入建设tcp链接阶段，上面同理2. ( 本机的操作系统 ) 中查问 DNS 缓存3. ( 本机的host ) 文件中查找 DNS 缓存4. ( 路由器 ) 中查问 DNS 缓存5. ( 运营商服务器 ) 中查问 DNS 缓存6. 迭代查问 // 根域名/一级域名/二级域名 ....blog.baidu.com    - .com    - .baidu    - blog    - 还未找到就报错7. DNS域名解析总结：  - 1. 浏览器DNS缓存 => 操作系统DNS缓存 => 本机host文件 => 路由器 => 运营商 => 以上都没有DNS缓存，就递归查问一级/二级/三级域名  - 2. ( 递归查问 ) 和 ( 迭代查问 ) 的区别    - 递归查问: 询问者的角色是变动的，a->b->c->d->c->b->a    - 迭代查问: 询问者的角色始终保持不变，每次都会将询问后果返回给同一个询问者，而后迭代，直到找到想要的后果; a->b->a, a->c->a 2. 建设tcp链接 // 三次握手- 第一次握手    - 客服端发送一个 标记位SYN=1,序号Seq=x的链接包给服务端        - SYN：示意发动一个新链接，( Synchronize Sequence Numbers )        - Seq：序号是随机的- 第二次握手    - 服务端发送一个 标记位SYN=1,ACK=1,确认号Ack=x+1,序号Seq=y的确认包给客户端    - 标记位 ACK 示意响应- 第三次握手    - 客户端发送一个 SYN=0,ACK=1,确认号Ack=y+1,序号Seq=x+1的确认包给服务器    - 为什么须要三次握手        - 之所以要第三次握手，次要是因为防止有效的连贯包延时后又发送到服务器，造成服务器认为又要建设链接的假象，造成谬误                3. 客户端发送http申请4. 服务端解决申请，并返回http响应报文5. 浏览器解析渲染  - 遇见HTML标记，浏览器调用HTML解析器，解析成Token并构建DOM树  - 遇见style/link标记，浏览器调用css解析器，解析成CSSOM树  - 遇见script标记，浏览器调用js解析器，解决js代码（绑定事件，可能会批改DOM tree 和 CSSOM tree）  - 将DOM 和 CSSOM 合并成 render tree  - 依据render tree计算布局（layout布局）  - 将各个节点的色彩绘制到屏幕上（paint渲染）  - 如果paint存在分层，则须要 (composite合成)6. 断开TCP链接 // 四次挥手，( FIN : 示意开释链接 )- 第一次挥手：浏览器发动，通知服务器我申请报文发送完了，你筹备敞开吧- 第二次挥手：服务器发动，通知浏览器我申请报文接管完了，我筹备敞开了，你也筹备吧- 第三次挥手：服务器发动，通知浏览器，我响应报文发送完了，你筹备敞开吧- 第四次挥手：浏览器发动，通知服务器，我响应报文接管完了，我筹备敞开了，你也筹备吧- 先是服务器先敞开，再是浏览器敞开

递归查问和迭代查问的区别

TCP 和 UDP 的区别

TCP面向链接(可靠性高)，UDP无连贯(可靠性低)

HTTP1.0 和 HTTP1.1 的区别

HTTP1.0

无状态：服务器不跟踪不记录申请过的状态
无连贯：浏览器每次申请都要从新建设链接
```
HTTP1.0
```
服务器不跟踪记录申请过的状态
对于无状态的个性能够借助 ( cookie/session ) 机制来做 ( 身份认证 ) 和 ( 状态记录 )
(2) 无连贯
无连贯导致的性能缺点次要有两种：
- 无奈复用链接
  - 每次发送申请，都须要进行tcp链接，即三次握手和四次挥手，使得网络的利用率极低
- 对头阻塞
  - http1.0规定，在前一个申请响应达到之后，下一个申请能力发送，如何前一个申请阻塞，前面的就都会阻塞

HTTP1.1

HTTP1.1解决HTTP1.0的性能缺点

长连贯：新增Connection字段，能够设置 Keep-Alive 使放弃链接一直开
管道化：基于长连贯，管道化能够不等第一个申请响应，持续发送前面的申请，然而响应的程序还是要按申请的程序返回
缓存解决：新增 cache-control 字段
- 留神比照1.0中的expires
- expires：是一个相对工夫点
- cache-control：是一个时间段，并且能够设置除了max-age以外的
  - max-age
  - public 所有服务器都缓存
  - private 只容许局部浏览器缓存资源
  - no-cache 服务器不对资源进行缓存，源服务器当前也将不再对缓存服务器申请中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作
断点续传
- 申请头 ( Range )
  - 指定 ( 第一个字节的地位 ) 和 ( 最初一个字节的地位 )
  - Range:(unit=first byte pos)-[last byte pos]
  - Range: bytes=0-801 //个别申请下载整个文件是bytes=0- 或不必这个头
- 响应头 ( Content-Range )
  - 指定整个实体的一部分插入地位，和整个实体的长度
  - 在服务器向浏览器返回一部分响应，则必须形容 ( 响应笼罩的范畴 ) 和 ( 整个实体的长度 )
  - Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]
  - Content-Range: bytes 0-800/801 //801:文件总大小
```
HTTP1.1
```
HTTP1.1默认放弃长连贯，数据传输实现，放弃tcp链接一直开，持续应用这个通道传输数据
响应头：Connection: Keep-Alive

响应头：Keep-Alive: timeout=5, max=1000

    - timeout：指定了一个闲暇连贯须要放弃关上状态的最小时长（以秒为单位）    - max：在连贯敞开之前，在此连贯能够发送的申请的最大值

(2) 管道化

http1.0
- 申请1 > 响应1 --> 申请2 > 响应2 --> 申请3 > 响应3
http1.1
- 申请1 --> 申请2 --> 申请3 > 响应1 --> 响应2 --> 响应3
尽管管道化一次能够发送多个申请，但响应依然是程序返回，依然无奈解决对头阻塞的问题
(3) 缓存解决
HTTP1.1新增 Cache-Control 字段
- http1.0 => expires => 是一个相对工夫点，用GMT工夫格局
- http1.1 => Cache-Control => 是一个相时时间段，以秒为单位
Cache-control: no-cache,private,max-age=123123
- no-cache：不应用强缓存，应用协商缓存
- max-age: 一个时间段，单位是秒
- public：容许所有服务器缓存该资源
- private：示意该资源仅仅属于发出请求的最终用户，这将禁止两头服务器（如代理服务器）缓存此类资源
```
     对于蕴含用户个人信息的文件，能够设置private
```
Expires 和 Cache-Control 比照
- 如果同时开启，Cache-Control 的优先级高于 Expires
- expires是一个用GMT工夫示意的工夫点，Cach-Control是用秒示意的时间段，都是和浏览器本地工夫做比照
- Cache-Control 比 Expires 更加准确
(4) 断点续传
申请头：Range
响应头：Content-Range
原理
- 在上传/下载资源时，如果资源过大，将其宰割为多个局部，别离上传/下载
- 如果遇到网络故障，能够从曾经上传/下载好的中央持续申请，不必从头开始，提高效率
案例：
- Range: bytes=0-801
- Content-Range: bytes 0-800/801

HTTP2.0

二进制分帧
多路复用：在共享TCP链接的根底上同时发送申请和响应
头部压缩
服务器推送：服务器能够额定的向客户端推送资源，而无需客户端明确的申请

HTTP2.0(1) 二进制分帧- 将所有传输的信息宰割为更小的音讯和帧,并对它们采纳二进制格局的编码(2) 多路复用- 基于二进制分帧- 在同一域名下所有拜访都是从同一个tcp连贯中走，http音讯被合成为独立的帧，乱序发送，服务端依据标识符和首部将音讯从新组装起来

HTTP2.0比照HTTP1.0的毛病
- 连贯无奈复用
- 头部阻塞 ( 对头阻塞 ) head of line blocking

PUT 和 POST 的区别

幂等性
- PUT是幂等的，即间断调用一次或者屡次的成果雷同（无副作用）
- POST是非幂等的
资源
- PUT的URI指向是具体繁多资源 - 更新资源
- POST能够指向资源汇合 - 新增资源
总结
- POST用于新增资源，非幂等，即屡次提交会屡次增加新资源，能够是资源汇合
- PUT用于批改资源，幂等，每次提交都是批改成同样的内容，只争对繁多资源

PUT 和 PATCH 的区别

两者都能够更新资源
PATCH是对资源进行部分更新，这样PATCH就会少提交一个body大小，减小报文大小

二进制分帧

二进制分帧的长处
- http1.0 每次都要从新发送申请
- http1.1 无奈解决对头梗塞
- http2.0 利用 ( 二进制分帧 ) 能够实现 ( 多路复用 )
tcp传输
- tcp层传输是将 ( 上一层协定的数据 ) 宰割成 ( 多个不同序号的报文 ) 来进行传输
- 是 ( 全双工 ) 通信，即 ( 单方须要对传输的报文序号进行确认 )
原理
- http1.0
  - 间接将 ( 字符模式的申请报文 ) 交付给tcp进行传输
  - 在 ( 应用层 ) 必须解析出 ( 申请head ) 和 ( 申请body ) 能力实现通信
- http2.0
  - 将应用层的数据通过 ( 二进制分帧 ) 解决，将 ( 不同的申请拆成不同的stream流)，通过 ( stream的id进行标记 )，( 申请的stream被宰割成多种类型的帧，包含【head帧】和【data数据帧】 )，正是因为stream的id标记和不同类型的帧，才确保了申请和响应的有序重组
  - 二进制分帧是在 ( 二进制帧层 ) 进行解决的，( 重组 ) 也是在二进制帧层进行解决的
总结：
- http2.0引入了二进制帧层，将并发的申请转成不同的stream流，每个stream都具备特定的id，这就保障了申请响应的数据能够二进制帧层进行重组，即便传输过程是无序的

多路复用

2021/06/18 多路复用温习

(1) 帧和流

帧 - frame
- ( 帧 ) 是http2中 ( 数据传输的最小单位 )
- 帧又被分为了两局部：headerFrame 和 dataFrame，即 ( 头部帧 ) 和 ( 数据帧 )
- 帧中蕴含以下字段：type flags length streamIdentifier framePayload
流 - stream
- ( 流 ) 是很http2存在于链接中的一个 ( 虚构通道 )
- 每个流都有一个惟一的id，一个残缺的申请或响应称为一个数据流
- 流的特点
  - 双向性：同一个流内，能够同时发送和接收数据
  - 有序性：流中传递的数据是二进制分帧
  - 并行性：流中的二进制帧都是被并行传输的，无需按程序期待
  - 流的创立和敞开：能够被客户端和服务端单方面创立，也能够被单方面敞开
  - 流的 ID 都是奇数，阐明是由客户端发动的，这是标准规定的
  - 流的 ID 都是偶数，阐明是由服务端发动的

(2) 多路复用总结

传输内容：http2中采纳 ( 二进制分帧传输 )，取代了http1中的 ( 文本传输 )
长处
- http2中代替了http1中的 ( 序列和阻塞 )
- 所有 ( 雷同的域名的申请 ) 都通过 ( 同一个tcp链接并发实现 )，通过对每个申请stream的惟一标识区别出是哪一个申请，并在传输到服务器后进行重组，实现并发无序发送

为什么http1.0不能实现多路复用？

因为http1.0是字符串，即 ( 文本宰割 )
而 -http2.0则是 ( 二进制帧 )

材料

HTTP和HTTPS简介 https://juejin.im/post/684490...
三次握手 https://juejin.im/post/684490...
三次握手四次挥手 https://juejin.im/post/684490...
TCP报文 https://juejin.im/post/684490...
为什么须要三次握手大白话 https://github.com/jawil/blog...
四次挥手 https://juejin.im/post/684490...
URL到页面渲染 https://juejin.im/post/684490...
TCP和UDP：https://juejin.im/post/684490...
HTTP1.0 HTTP1.1 HTTP2.0 https://github.com/Advanced-F...
对于三次握手与四次挥手面试官想考咱们什么？ https://juejin.im/post/684490...

导航