[深入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:语法

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链接时,需要客户端和服务端总的发送的三个包

  • 第一次握手
    • 客户端发送一个 <font color=red>( 标志位SYN=1,序号Seq=x )</font> 的 ( 连接包 ) 到服务器
      • SYN=1表示新建链接
      • <font color=red>客户端状态:由 CLOSED状态 => SYN_SENT状态</font>
  • 第二次握手
    • 服务器发送一个 <font color=red>( 标志位SYN=1,ACK=1,序号Seq=y,确认号Ack=x+1)</font> 的 ( 确认包 ) 给客户端
      • Ack = Seq + 1 ( 确认号 = 序号 + 1 )
      • <font color=red>服务端状态:由 CLOSED状态 => SYN_RCVD状态</font>
  • 第三次握手
    • 客户端发送一个 <font color=red>( 标志位SYN=0,ACK=1,序号Seq=x+1,确认号Ack=y+1)</font> 的 ( 确认包 ) 给服务器
      • established:是建立的意思
      • <font color=red>客户端和服务端状态都变成 ESTABLISHED 状态</font>

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

为什么只有三次握手,才能确认双方的发送和接收能力是否正常,而两次却不可以??

  • 第一次握手:
    • 客户端发送连接包,服务端收到了
    • ( 服务端 ) 就能得出结论:( 客户端的发送能力,服务端的接收能力是正常的 )
  • 第二次握手
    • 服务端发送确认包,客服端收到了
    • ( 客户端 ) 就能得出结论:( 服务端的接收、发送能力,客户端的接收、发送能力是正常的 )
    • 注意:<font color=red>此时服务端并不能确认客户端的接收能力是否正常</font>
  • 第三次握手
    • 客户端发送确认包,服务端收到了
    • ( 服务端 ) 就能得出结论:( 客户端的接收、发送能力,和服务端的接收、发送能力都是正常的 )
  • 总结为什么需要三次握手
    • 为了实现可靠数据传输, TCP 协议的通信双方都必须维护一个序列号, 标识发送出去的数据包哪些已经被对方收到
    • 三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤
    • <font color=red>如果只是两次握手, 至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认,也就是上面每次握手分析的,如果两次握手,服务端是没法确认客户端的接收能力是正常的</font>
    • 防止已失效的连接请求又传送到服务器端,因而产生错误

四次挥手

  • 标志位:FIN表示释放一个链接
  • 注意:客户端和服务端都可以主动发起挥手动作
  • established:建立的意思 ( <font color=red>ESTABLISHED</font> )
  • 过程:( 假设由客户端发起,<font color=red>标志位FIN=1表示释放链接</font> )
  • 第一次挥手
    • 客户端发送一个 <font color=red>( 标志位FIN=1,序号Seq=u ) </font>的 ( 释放包 ) 到服务器
    • <font color=red>客户端状态:由 ESTABLISHED状态 => FIN_WAIT1状态</font>
    • <font color=blue>表明的是:主动方(客户端)的报文发送完了,但是主动方(客户端)还是可以接收报文</font>
  • 第二次挥手
    • 服务器返回一个 <font color=red>( 标志位ACK=1,确认号Ack=u+1,序号Seq=v ) </font>的 ( 确认包 ) 到客户端
    • <font color=red>服务端状态:由 ESTABLISHED状态 => COLSE_WAIT状态</font>
  • 第三次次挥手
    • 服务器发送一个 <font color=red>( 标志位FIN=1,ACK=1,确认号Ack=u+1,序号Seq=w ) </font>的 ( 释放包 ) 到客户端
    • <font color=red>服务端状态:由 COLSEWAIT状态 => LAST_ACK状态</font>
      • <font color=blue>表明的是:主动方(服务端)的报文发送完了,但是主动方(服务端)还是可以接收报文</font>
  • 第四次次挥手
    • 客户端送一个 <font color=red>( 标志位ACK=1,确认号Ack=w+1, 序号Seq=u+1 ) </font>的 ( 确认包 ) 到服务端
    • <font color=red>客户端状态:由 FIN_WAIT2状态 => TIME_WAIT状态</font>
  • 注意:
    • 客户端通常是主动关闭,进入TIME_WAIT状态
    • 服务端通常是被动关闭,不会进入TIME_WAIT状态

TIME_WAIT状态 – 2MSL状态

  • <font color=red>TIME_WAIT状态也称为2MSL等待状态</font>
  • 每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime),它是任何报文段被丢弃前在网络内的最长时间。

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

  • <font color=red>因为要确保服务器是否收到了Ack确认报文,即在2MSL时间内没有再收到服务端的FIN报文,证明已经收到ACK</font>
  • 如果没有收到的话,服务器会重新发 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的缺点

  • 通信使用<font color=red> 明文</font>(不加密),内容可能会被<font color=red> 窃听</font>
  • 不验证通信方的<font color=red> 身份</font>,因此有可能遭遇<font color=red> 伪装</font>
  • 无法证明报文的<font color=red> 完整性</font>,所以有可能已遭<font color=red> 篡改</font>
  • http本身不具备加密功能,报文使用明文传播
  • 为什么设计成不加密:
    • TCP/IP 协议族的工作机制,通信内容在所有的通信线路上都有

    可能遭到窥视。

    • 即使已经过加密处理的通信,也会被窥视到通信内容,这点和未

    加密的通信是相同的。只是说如果通信经过加密,就有可能让人
    无法破2解报文信息的含义,但加密处理后的报文信息本身还是会
    被看到的

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

  • <font color=red>通信线路的加密 – 安全的通信线路</font>
  • <font color=red>通信内容的加密 – 内容有被篡改的风险</font>

通信线路的加密

  • <font color=red>http</font> 通过和 <font color=red>SSL(secure socket layer 安全套接层)</font> 或者和 <font color=red>TLS(transport layer security 安全层传输协议)</font>的组合使用,来加密http的通信内容

通信内容的加密

  • 内容仍有被篡改的风险
  • HTTP 协议中的请求和响应不会对通信方进行确认。
    • 服务器是否就是发送请求中 URI 真正指定的主机
    • 返回的响应是否真的返回到实际提出请求的客户端,等类似问题。

不验证通信双方的隐患

  • 无法确定响应的服务器,就是要请求的目标服务器
  • 无法确定响应内容是是否真正发送给了请求时的客服端
  • 无法确定正在通信的对方是否具备访问权限。如果Web服务器上保存着重要的信息,只想发给特定用户通信的权限。
  • 无法判定请求是来自何方、出自谁手
  • 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击(Denial of Service,拒绝服务攻击)
  • 注意:<font color=red>http协议无法确定通信方,但是SSL可以</font>
    • <font color=red>SSL不仅提供加密处理,而且还使用了一种被称为证书的手段,

    可用于确定方 </font>

    • 证书由值得信任的第三方机构颁发,用以证明服务器和客户端是

    实际存在的

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

什么是中间人攻击

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

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

  • <font color=red>MD5 和 SHA-1 等散列值校验的方法</font>
  • <font color=red>以及用来确认文件的数字签名方法。</font>

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

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

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

  • 用于http协议交互的信息被称为http报文
  • 请求报文:客户端的报文
  • 响应报文:服务端的报文
  • <font color=red> http报文:由多行数据构成的字符串文本 </font>

HTTPS

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

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

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

  • https采用混合加密
    • 在交换密钥环节:使用公开加密 – (非对称加密)
    • 之后的建立通信,交换报文阶段:使用共享加密 – (对称加密)
    • <font color=red> ( 非对称加密 ) 的处理速度要比 ( 对称加密 ) 慢,所以各有优势,所以https采用组合加密</font>

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

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

  • 公开密钥加密存在的问题
    • <font color=red>无法证明公开密钥就是货真价实的公开密钥, 因为公开密钥在传播过程中可能被替换 </font>
  • <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:改变密码规格,即非对称加密交换公共密钥后,使用对称加密通信
  • <font color=blue size=6>SSL握手过程 – 注意结合认证,组合加密一起来理解</font>
  • (1) ( <font color=red>客户端</font> ) 通过发送 ( <font color=red>client hello 报文</font> ) 开始 SSL 通信
    • 报文中包含:( SSL版本 ),( 加密组件列表 )
    • 加密组件列表cipher suite包含:加密算法,密钥长度等
  • (2) ( <font color=red>服务端</font> ) 发送 ( <font color=red>erver Hello 报文</font> ) 作为应答
    • 报文中同样包含:( SSL版本 ),( 加密组件列表 )
    • ( 服务器 ) 的加密组件内容是从接收到的 ( 客户端 ) 加密组件内 ( 筛选 ) 出来的
  • (3) ( <font color=red>服务器</font> ) 发送 ( <font color=red>certificate</font> ) 加密报文,报文中包含 ( <font color=red>公开密钥证书</font> )
  • (4) ( <font color=red>服务器</font> ) 发送 ( <font color=red>Server Hello Done</font> ) 报文通知客户端,最初阶段的 ( <font color=red>SSL握手协商,即第一次SSL握手结束</font> ) 部分结束
  • (5) 第一次SSL握手结束后,( <font color=red>客户端</font> ) 发送 ( <font color=red>Client Key Exchange</font> ) 报文作为回应
    • <font color=blue>报文中包含:Pre-Master secret 随机密码串,该报文使用3中的公共密钥证书加密</font>
  • (6) ( <font color=red>客户端</font> ) 继续发送 ( <font color=red>Change Cipher Spec</font> ) 报文
    • <font color=blue>该报文会提示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密</font>
  • (7) ( <font color=red>客户端</font> ) 发送 ( <font color=red>Finished</font> ) 报文
    • <font color=blue>该报文包含连接至今,全部报文的整体校验值</font>
    • <font color=blue>这次握手协商是否成功,要以服务器是否能够正确解密该报文作为判断标准</font>
  • (8) ( <font color=red>服务器</font> ) 同样发送 ( <font color=red>Change Cipher Spec</font> ) 报文
  • (9) ( <font color=red>服务器</font> ) 同样发送 ( <font color=red>Finished</font> ) 报文
  • (10) 发送HTTP请求,服务端和客户端的Finished报文交换完毕之后,SSL连接就算建立完成,通信会受到 SSL 保护
    • 从此处开始进行应用层的通信,即发送 HTTP 请求
  • (11) 响应HTTP请求
  • (12) 最后由客户端断开连接。断开连接时,发送 close_notify 报文。

url到页面显示过程

  1. DNS域名解析 // 将域名解析成IP地址
  2. 建立TCP链接 // 三次握手
  3. 客户端发起HTTP请求
  4. 服务器处理请求,并返回HTTP报文
  5. 浏览器解析渲染页面
  6. 断开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…

未经允许不得转载:集众思SEO » [深入17] HTTP 和 HTTPS

赞 (0) 打赏

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏