[深入17] HTTP 和 HTTPS

作者: woow_wu7 | 来源:发表于2021-08-21 22:36 被阅读0次

[深入17] HTTP 和 HTTPS
深入解析http和https那点事
深入Tcp、Udp、http、https
HTTP和HTTPS
HTTP和HTTPS
HTTP和HTTPS
HTTP和HTTPS
http和https
HTTP和HTTPS
http和https

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

[react] Hooks

[部署01] Nginx
[部署02] Docker 部署vue项目
 [部署03] gitlab-CI

[源码-webpack01-前置知识] AST抽象语法树
 [源码-webpack02-前置知识] Tapable
[源码-webpack03] 手写webpack - compiler简单编译流程
 [源码] Redux React-Redux01
[源码] axios
[源码] vuex
[源码-vue01] data响应式和初始化渲染
 [源码-vue02] computed 响应式 - 初始化，访问，更新过程

前置知识

一些单词

protocol：协议
permanent：永久的
permanently：永久地
temporary：暂时的
grammar：语法

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

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

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

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

image

TCP首部图解

image

总结
- 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 状态

image

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状态
  image

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的缺点

通信使用 明文（不加密），内容可能会被 窃听
不验证通信方的 身份，因此有可能遭遇 伪装
无法证明报文的 完整性，所以有可能已遭 篡改

<table bgcolor=orange><tr><td>HTTP是明文传播，可能会遭到窃听</td></tr></table>

http本身不具备加密功能，报文使用明文传播
为什么设计成不加密：
- TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有
  可能遭到窥视。
- 即使已经过加密处理的通信，也会被窥视到通信内容，这点和未
  加密的通信是相同的。只是说如果通信经过加密，就有可能让人
  无法破2解报文信息的含义，但加密处理后的报文信息本身还是会
  被看到的

加密的对象有哪些 - (加密处理防止被窃听)

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

通信线路的加密

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

通信内容的加密

内容仍有被篡改的风险

<table bgcolor=orange><tr><td>HTTP不验证通信双方的身份，可能会遭遇伪装</td></tr></table>

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

不验证通信双方的隐患

无法确定响应的服务器，就是要请求的目标服务器
无法确定响应内容是是否真正发送给了请求时的客服端
无法确定正在通信的对方是否具备访问权限。如果Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
无法判定请求是来自何方、出自谁手
即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）
注意：http协议无法确定通信方，但是SSL可以
- SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，
 可用于确定方 
- 证书由值得信任的第三方机构颁发，用以证明服务器和客户端是
 实际存在的

image

<table bgcolor=orange><tr><td>HTTP无法验证报文的完整性，可能会被篡改</td></tr></table>

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

什么是中间人攻击

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

使用http协议确认确认报文完整性的方法

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

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

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

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

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

image

HTTPS

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

image

ssl是独立与http协议的，所以其他应用层的协议也可以使用ssl

image

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

https采用混合加密
- <table bgcolor=orange><tr><td>在交换密钥环节：使用公开加密 - (非对称加密)</td></tr></table>
- <table bgcolor=yellow><tr><td>之后的建立通信，交换报文阶段：使用共享加密 - (对称加密)</td></tr></table>
- ( 非对称加密 ) 的处理速度要比 ( 对称加密 ) 慢，所以各有优势，所以https采用组合加密

image

公开密钥加密方式 - 无法证明公开密钥本身就是货真价实的公开密钥

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

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

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

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

image

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

image

名称解释：
- 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 : 表示释放链接 )
- 第一次挥手：浏览器发起，告诉服务器我请求报文发送完了，你准备关闭吧
- 第二次挥手：服务器发起，告诉浏览器我请求报文接收完了，我准备关闭了，你也准备吧
- 第三次挥手：服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧
- 第四次挥手：浏览器发起，告诉服务器，我响应报文接收完了，我准备关闭了，你也准备吧
- 先是服务器先关闭，再是浏览器关闭

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

image

TCP 和 UDP 的区别

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

image

HTTP1.0 和 HTTP1.1 的区别

HTTP1.0

无状态：服务器不跟踪不记录请求过的状态
无连接：浏览器每次请求都要重新建立链接

HTTP1.0

(1) 无状态
1. 服务器不跟踪记录请求过的状态
2. 对于无状态的特性可以借助 ( 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

(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消息被分解为独立的帧，乱序发送，服务端根据标识符和首部将消息重新组装起来

image

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则是 ( 二进制帧 )

资料

[深入17] HTTP 和 HTTPS
导航 [深入01] 执行上下文[https://juejin.im/post/684490404605093479...
深入解析http和https那点事
一.协议基础 http基于TCP/IP协议的一种传输协议，如果承载TSL/SSL协议层之上便就成为了https。 ...
深入Tcp、Udp、http、https
下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI（Open System Interconnect）模...
HTTP和HTTPS
1. HTTP和HTTPS的区别超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP...
HTTP和HTTPS
http协议运行在TCP之上，明文传输，客户端和服务端都无法验证对方的身份；Https是身披SSL(Secure ...
HTTP和HTTPS
1、HTTP是什么？ HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TC...
HTTP和HTTPS
超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何...
http和https
HTTP和HTTPS
超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提...
http和https
http和https的概念 HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet...

[深入17] HTTP 和 HTTPS

导航

前置知识

一些单词

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

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

TCP首部图解

TCP三次握手

TCP建立链接 - 为什么需要第三次握手

四次挥手

TIME_WAIT状态 - 2MSL状态

为什么第四次挥手后，客户端要进入TIME_WAIT状态，而不是直接关闭

一些重要的HTTP状态码

HTTP

HTTP的缺点

<table bgcolor=orange><tr><td>HTTP是 明文传播，可能会遭到 窃听</td></tr></table>

加密的对象有哪些 - (加密处理防止被窃听)

通信线路的加密

通信内容的加密

<table bgcolor=orange><tr><td>HTTP不验证通信双方的身份，可能会遭遇伪装</td></tr></table>

不验证通信双方的隐患

<table bgcolor=orange><tr><td>HTTP无法验证报文的完整性，可能会被篡改</td></tr></table>

什么是中间人攻击

使用http协议确认确认报文完整性的方法

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

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

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

HTTPS

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

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

公开密钥加密方式 - 无法证明公开密钥本身就是货真价实的公开密钥

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

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

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

url到页面显示过程

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

TCP 和 UDP 的区别

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

HTTP1.0 和 HTTP1.1 的区别

HTTP1.0

HTTP1.1

HTTP2.0

PUT 和 POST 的区别

PUT 和 PATCH 的区别

二进制分帧

多路复用

(1) 帧和流

(2) 多路复用总结

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

资料

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

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

<table bgcolor=orange><tr><td>HTTP是明文传播，可能会遭到窃听</td></tr></table>

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

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

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