关于javascript:深入17-HTTP-和-HTTPS

[[深刻 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：语法

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

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

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

三次握手：指的是建设 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 协定的通信单方都必须保护一个序列号，标识发送进来的数据包哪些曾经被对方收到
- 三次握手的过程即是通信单方互相告知序列号起始值，并确认对方曾经收到了序列号起始值的必经步骤
- 如果只是两次握手，至少只有连贯发起方的起始序列号能被确认，另一方抉择的序列号则得不到确认，也就是下面每次握手剖析的，如果两次握手，服务端是没法确认客户端的接管能力是失常的 
- 避免已生效的连贯申请又传送到服务器端，因此产生谬误

标记位：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 期待状态
每个具体 TCP 实现必须抉择一个报文段最大生存工夫 MSL（Maximum Segment Lifetime），它是任何报文段被抛弃前在网络内的最长工夫。

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

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 自身不具备加密性能，报文应用明文流传
为什么设计成不加密：
- 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）。

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

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

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

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. 接下来，通信双发就能够进行 (对称加密通信了)，即能够建设通信，替换报文了

名称解释：
- 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 报文。

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 无连贯(可靠性低)

无状态：服务器不跟踪不记录申请过的状态
无连贯：浏览器每次申请都要从新建设链接
```
HTTP1.0
```
服务器不跟踪记录申请过的状态
对于无状态的个性能够借助 (cookie/session) 机制来做 (身份认证) 和 (状态记录)

(2) 无连贯
无连贯导致的性能缺点次要有两种：
- 无奈复用链接
  - 每次发送申请，都须要进行 tcp 链接，即三次握手和四次挥手，使得网络的利用率极低
- 对头阻塞
  - http1.0 规定，在前一个申请响应达到之后，下一个申请能力发送，如何前一个申请阻塞，前面的就都会阻塞

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

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

HTTP2.0

(1) 二进制分帧
- 将所有传输的信息宰割为更小的音讯和帧, 并对它们采纳二进制格局的编码

(2) 多路复用
- 基于二进制分帧
- 在同一域名下所有拜访都是从同一个 tcp 连贯中走，http 音讯被合成为独立的帧，乱序发送，服务端依据标识符和首部将音讯从新组装起来

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

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

两者都能够更新资源
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 多路复用温习

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

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

因为 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…

关于javascript:深入17-HTTP-和-HTTPS

导航

前置常识

一些单词

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

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

TCP 首部图解

TCP 三次握手

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

四次挥手

TIME_WAIT 状态 – 2MSL 状态

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

一些重要的 HTTP 状态码

HTTP

HTTP 的毛病

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

通信线路的加密

通信内容的加密

不验证通信单方的隐患

什么是中间人攻打

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

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

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

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

HTTPS

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

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

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

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

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

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

url 到页面显示过程

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

TCP 和 UDP 的区别

HTTP1.0 和 HTTP1.1 的区别

HTTP1.0

HTTP1.1

HTTP2.0

PUT 和 POST 的区别

PUT 和 PATCH 的区别

二进制分帧

多路复用

(1) 帧和流

(2) 多路复用总结

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

材料

Just My Socks（注册教程 内含优惠码）

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

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

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

Just My Socks（注册教程内含优惠码）