[深入17] HTTP 和 HTTPS

2,869 阅读35分钟

导航

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

HTTP的一些概念

  • HTTP 是 超文本传输协议 ( hyperText Transfer Protocol )
    • ( HT -> hyperText ) ( T -> transfer ) ( P -> Protocol )
    • 单词:hyperText 是超文本的意思
    • 关键词:超文本 + 传输 + 协议
    • 全双工:http协议是一个 ( 双向协议 )
    • 超文本:指的是传输的内容是超文本
      • 含义:
        • 它是文字、图片、视频,超链接,等的混合体
        • 最关键有超链接,能从一个超文本跳转到另外一个超文本
      • HTML:html就是常见的超文本

Content-Type

Content-Type: application/x-www-form-urlencode
- 浏览器的原生Form表单
- 提交的数据按照 key1=v1&key2=v2 的方式进行编码,key和v都进行了URL转码


Content-Type: application/json
- 消息主体是序列化后的 JSON 字符串
- 这种方案,可以方便的提交复杂的结构化数据,特别适合 RESTful 的接口。


Content-Type: multipart/form-data
- 常见的 POST 数据的提交方式
- 我们使用 ( 表单上传文件时 ),必须让 ( form标签 ) 的 ( enctype ) 等于 ( multipart/form-data ) 这个值


Content-Type: text/xml
// Content-Type: text/html
- 是一种使用 HTTP 作为传输协议,XML 作为编码方式的远程调用规范

2022/03/19补充一些 Content-Type 相关知识
---

1. URL 和 URI
- URL:统一资源定位符 ------------ location
- URI:统一资源标识符 ------------ identifier

2. 为什么要进行 URL Encoding 编码
- 因为url中规定url不能包含 ( 汉字和一些其他字符 ),所以需要进行编码

---
3. js 中 encodeURI, encodeURIComponent, decodeURI, decodeURIComponent 的区别?
- 1. encode 和 decode 分别是编码和解码
- 2. encodeURI 和 encodeURIComponent 的编码范围不同 
- 3.
- encodeURI
  - 不会编码 ASCII字母 数字 ~!@#$&*()=:/,;?+'
- encodeURIComponent
  - 不会编码 SCII字母 数字 ~!*()'
- encodeURIComponent的范围比encodeURI的范围大
- 4.
- 应用场景
- encodeURI:------------ 编码整个 URL
- encodeURIComponent ---- 编码URL中的参数部分,即 query部分; 主要用于对url中包含回调地址,对回调地址的处理用encodeURIComponent

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序号才有效 (x)
      • 错误更正2022.03.19 -> 只有标志位ACK=1时,确认序号Ack才有效

TCP/IP协议分层

  • 2022/03/20 复习补充
1
TCP/IP协议一共分为 4 层
- 应用层 ----------- HTTP --------------- 数据
- 传输层 ----------- TCP UDP ------------ 数据 + 端口号
- 网络层 ----------- IP ----------------- 数据 + 端口号 + IP地址 ------------ 设备( 路由器 - 网关 )
- 数据链路层 -------- MAC ---------------- 数据 + 端口号 + IP地址 + MAC地址 -- 设备 ( 交换机 )

- 物理层 ----------------------------------------------------------------- 设备 ( 光纤 )
- 如果还要加一层的话,就是 (物理层),这样就一个有5层 ( 应用层->传输层->网络层->数据链路层->物理层 )


2
ip地址 和 mac地址
- ip地址 -------- 不固定
- mac地址 ------- 固定 -------- 每个网卡都有一个固定的mac地址
- 通过ip地址能找到mac地址,ip -> mac,从而找到具体的设备
- 【 注意:我们真正上网的时,目标的ip的值是不会变的,变的时候mac地址,通过不断的中转mac地址,最终找到目标设备 】
- 【 通过ARP协议将ip地址转成mac地址 】


3
不能通信:----------> 默认 ( 两个不同的网路 ) 是 ( 不能通信的 ) 
如何才能通信:-------> 如果想要在不同网路的两个设备能通信的话,需要 ( 网关 )
哪些设备可以做网关:--> 路由器
路由器:------------> 有两个端口 wan lan
- wan口用来上网
- lan用来做局域网 ( 局域网时,[网络层的路由器]就相当于[数据链路层的交换机]了 ),没有wan口的路由器相当于交换机


4
网络中的协议 - 协议:指的是 约定和规范
应用层协议:HTTP协议 DNS协议 DHCP协议
传输层协议:TCP协议 UDP协议
网络层协议:IP协议 ARP协议
注意:下层为上层提供服务


5
ARP协议:核心价值是将ip地址转成mac地址 - 做广播,缓存表
DHCP协议:动态主机配置协议,自动分配ip


6
DNS协议
- 英语:Domain Name System 域名系统
- 作用:将 ( 域名 ) 解析成 ( ip ) 地址
- 特点:
  - 1.DNS服务器会缓存 ( 域名和ip的对应关系 ),所以很快
  - 2.并且采用 UDP 方式进行通信,UDP面向无链接,TCP面向连接
- 域名
  - www.baidu.com.cn 
  - 如何判断是几级域名
    - 有几个点就是几级域名,这里有三个点,就是三级域名
  - 查找顺序
    - 解析时,都是 ( 从右向左 ) 的解析域名,( 递归查找 )
    - 递归查找:顶级域名 -> 一级域名 -> 二级域名 -> ...

7
递归和迭代的区别
递归:a->b->c->b->a
迭代:a->b b->a a->c c->a

image.png

image.png

image.png

image.png

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 -------------- 切换协议,协议升级

2023/11/07更新
// 100
// - 1. GET产生一个TCP数据包,POST产生两个TCP数据包
// - 1. POST请求:
//      - POST请求就是分两段,header 和 data,即先发送header数据,返回100状态码后,再继续发送data
//      - 注意: 这两次请求都是post请求,( 不要和post跨域时,两次请求搞混 - 一次是options请求,一次是post请求 )


200 ok ------------------------------- 请求被正常处理
201 created -------------------------- http-post请求的结果,表示 ( 成功创建一个或多个资源 )
202 accepted ------------------------- http-post请求的结果,表示 ( 接受请求,但尚未处理完成 )
204 no content ----------------------- 请求处理成功,但没有资源可以返回,响应报文中不包含报文主体,浏览器显示的页面不发生更新,用于不需要返回资源的请求,比如 DELETE
206 partial content ------------------ 范围请求,请求部分资源,是GET请求,响应报文中包含 Content-Range 指定范围的实体内容

301 moved permanently ---------------- 永久重定向,需要变更书签引用
302 Found ---------------------------- 临时重定向,不需要变更书签引用
303 set other ------------------------ 临时重定向,应采用 GET 方法获取资源
304 not modified --------------------- 资源未被修改,协商缓存 - 返回的报文中不包含报文主体
307 Temporary Redirect --------------- 临时重定向,不需要从 POST 换成 GET

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是 明文传播,可能会遭到 窃听

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

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

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

通信线路的加密

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

通信内容的加密

  • 内容仍有被篡改的风险

HTTP不验证通信双方的身份,可能会遭遇伪装

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

不验证通信双方的隐患

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

HTTP无法验证报文的完整性,可能会被篡改

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

什么是中间人攻击

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

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

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

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

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

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

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

HTTPS

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

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

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

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

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

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

  • 公开密钥加密存在的问题

    • 无法证明公开密钥就是货真价实的公开密钥, 因为公开密钥在传播过程中可能被替换
  • 问题:如何解决公开加密方式的公钥的安全性 ?????

  • 解决:数字证书机构颁发的 ( 公开密钥证书 )

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

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

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

  • 名称解释:

    • handshake:握手
    • certificate:证书
    • cipher:密码
    • Suite:一套
    • cipher suite:密码组件
    • spec:规格
    • exchange:交换
    • ClientKeyExchange
    • ChangeCipherSpec:改变密码规格,即非对称加密交换公共密钥后,使用对称加密通信
  • SSL握手过程 - 注意结合认证,组合加密一起来理解

  • (1) ( 客户端 ) 通过发送 ( client hello 报文 ) 开始 SSL 通信

    • 报文中包含:( SSL版本 ),( 加密组件列表 )
    • 加密组件列表cipher suite包含:加密算法,密钥长度等
  • (2) ( 服务端 ) 发送 ( server 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到页面显示过程

  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

(1) 无状态
1. 服务器不跟踪记录请求过的状态
2. 对于无状态的特性可以借助 ( cookie/session ) 机制来做 ( 身份认证 ) 和 ( 状态记录 )

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

HTTP1.1

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

  • 2021/10/13 更新优化
  • 长连接:新增Connection字段,可以设置 Keep-Alive 使保持链接不断开
    • 新增 Connection 字段
      • 可以设置 Keep-Alive 使保持链接不断开
      • Connection: Keep-Alive
      • Connection 是一个通用头,即既可以做请求头,又可以做相应头
    • 新增 Keep-Alive 字段
      • 注意 Keep-Alive属性生效需要先设置 Connection:Keep-Alive
      • Keep-Alive: timeout
        • -> 指定了一个空闲连接需要保持打开状态的最小时长(以秒为单位)
      • Keep-Alive: max
        • -> 在连接关闭之前,在此连接可以发送的请求的最大值 -> 最大链接数
    • developer.mozilla.org/zh-CN/docs/…
      长链接:
      - 主要有两个头字段 ( Connectoin ) 和 ( Keep-Alive )
      - 表示数据传输完成,TCP保持链接不断开,继续使用该通道传输数据
      --------
      响应行和响应头 
      -------
      HTTP/1.1 200 OK
      Connection: Keep-Alive
      Keep-Alive: timeout=5, max=1000
      
  • 管道化:基于长连接,管道化可以不等第一个请求响应,继续发送后面的请求,但是响应的顺序还是要按请求的顺序返回
  • 缓存处理:新增 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消息被分解为独立的帧,乱序发送,服务端根据标识符和首部将消息重新组装起来
- 比如:一个页面有三个http请求,在HTTP1.0时需要发三次http请求,而HTTP2.0只需要发送一次HTTP请求,将之前的三次分层不同的stream,乱序发送

(3) 头部压缩
- 将http中的头部中的key:value的纯文本,在两端做了一个映射表,发送的时候只需要记录key就可以了



  • HTTP2.0对比HTTP1.0的缺点
    • 连接无法复用
    • 头部阻塞 ( 对头阻塞 ) head of line blocking

GET 和 POST 的区别

  • GET 安全幂等,获取资源
  • POST 不安全不幂等,新建资源/更新资源
  • 详细区别,见下文更新 -> Question2 GET 和 POST 的详细区别?

PUT 和 POST 的区别

  • 幂等性
    • PUT是幂等的,即 连续调用一次或者多次的效果相同(无副作用)
    • POST是非幂等的
  • 资源
    • PUT的URI指向是具体单一资源 - 更新资源
    • POST可以指向资源集合 - 新增资源
  • 总结
    • POST用于新增资源,非幂等,即多次提交会多次添加新资源,可以是资源集合
    • PUT用于修改资源,幂等,每次提交都是修改成同样的内容,只争对单一资源

HTTP3.0

  • QUIC 协议
    • HTTP3.0 的核心是 QUIC (读音 quick - quick 是快的意思) 协议,由 Google 在 2015 年提出
    • QUIC 基于( UDP 协议 ),又取了 TCP 中的精华,实现了即快又可靠的协议
  • 解决 HTTP2.0 以下问题
    • 1.队头阻塞问题
      • 队头阻塞原因: 指的是 ( 一个数据包影响了一堆数据包,它不来大家都走不了 )
      • 队头阻塞发生在那些地方: 可能存在于 ( HTTP 应用层 ) 或 ( TCP 传输层 )
        • HTTP1.1
          • HTTP 层和 TCP 层两层 都会队头阻塞
        • HTTP2.0
          • HTTP 层的队头阻塞:
            • 解决了 HTTP 层的队头阻塞,但是 TCP 层仍然会队头阻塞
          • TCP 层的队头阻塞:
            • 无法解决
            • 因为 TCP 协议在收到数据包之后,这部分数据可能是乱序到达的,但是 TCP 必须将所有数据收集排序整合后给上层使用,如果其中某个包丢失了,就必须等待重传,从而出现某个丢包数据阻塞整个连接的数据使用
        • HTTP3.0
          • QUIC 协议是基于 UDP 协议实现的,在一条链接上可以有多个流,流与流之间是互不影响的,当一个流出现丢包影响范围非常小,从而解决队头阻塞问题
    • 2.RTT 建链
      • 减少链接时长和优化链接性能
      • 问题
        • 问题: 什么是 RTT ?
        • 回答: 衡量网络建链的常用指标是 RTT ( Round-Trip Time ),也就是 ( 数据包一来一回的时间消耗 )
      • RTT 耗时对比
        • HTTPS -------- 2-3 个 RTT
        • HTTP3.0 ------ ( 1RTT 进行密钥交换 ),( 建立链接后的非首次链接,只需 0 个 RTT )
    • 3.解决 HTTP2.0 在移动互联网领域表现不佳(弱网环境)
      • HTTP2.0 TCP
        • 切换网络会重连: TCP 当我们从 4G 环境切换到 wifi 环境时,手机的 IP 地址就会发生变化,这时必须创建新的 TCP 连接才能继续传输数据
      • HTTP3.0 QUIC
        • 切换网络不会重连: 基于 QUIC 协议之下,我们在日常 wifi 和 4G 切换时,或者不同基站之间切换都不会重连,从而提高业务层的体验

PUT 和 PATCH 的区别

  • 两者都可以 更新资源
  • PATCH是对资源进行局部更新,这样PATCH就会少提交一个body大小,减小报文大小

二进制分帧

  • 二进制分帧的优点
    • http1.0 无连接,每次都要重新建立连接,队头阻塞
    • http1.1 长连接,不用每次都重新建立连接,无法解决对头堵塞
    • http2.0 利用 ( 二进制分帧 - 将数据转成二进制 ) 可以实现 ( 多路复用 )
  • tcp传输
    • tcp层传输是将 ( 上一层协议的数据 ) 分割成 ( 多个不同序号的报文 ) 来进行传输
    • 是 ( 全双工 ) 通信,即 ( 双方需要对传输的报文序号进行确认 )
  • 原理
    • http1.0
      • 直接将 ( 字符 - 形式的请求报文 ) 交付给tcp进行传输
      • 在 ( 应用层 ) 必须解析出 ( 请求head ) 和 ( 请求body ) 才能完成通信
    • http2.0
      • 将 ( 应用层 ) 的数据经过 ( 二进制分帧 ) 处理,即将 ( 纯文本字符 转成 二进制帧)
      • 将 ( 并发的多个不同的http请求 ) 拆成 ( 不同的stream流 ),通过 ( stream的id进行标记 ),合并成 ( 一个http请求 )
      • 请求的 ( stream流 ) 被分割成 ( 多种类型的帧 ),包括 【head帧】和【data数据帧】
      • 正是因为stream的id标记不同类型的帧,才确保了请求和响应的有序重组
      • stream_ID表示的是
        • 这个帧属于哪个流
        • 接收方把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则是 ( 二进制帧 )

Question1 HTTP有哪些方法?

  • HTTP1.0 定义了三种方法:GET,POST,HEAD
  • HTTP1.1 定义了五种方法:PUT,PATCH,DELETE,OPTIONS,CONNECT
    • OPTIONS
      • 用于获取目的资源所支持的 ( 请求方法 )
      • 返回报文的 ( 报文首部 - 响应头 ) 中包含 ( Allow ) 字段,值是所支持的请求方法
      • 响应头 Allow: GET,POST
    • CONNECT
      • 该方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)
      • HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

Question2 GET 和 POST 的详细区别?

  • 作用不同
    • GET获取资源
    • POST添加资源/更新资源
  • 数据传输
    • GET通过URL传输数据,POST通过body传输数据
    • 其实也没规定GET不能通过body传输数据,所以 GET和POST都能通过body传输数据
  • 幂等 和 安全性
    • GET幂等,安全
    • POST 非幂等,非安全
  • 缓存
    • GET能被浏览器和代理服务器缓存
    • POST不能被浏览器和代理服务器缓存
  • 书签
    • GET能添加为书签
    • POST不能能添加为书签
  • 数据类型
    • GET只允许 ASCII 字符
    • POST无限制
  • TCP数据包个数
    • GET产生一个TCP数据包, POST产生两个TCP数据包

    • GET,浏览器会把 ( header 和 data ) 一并发送出去,服务器响应200(返回数据)

    • POST,浏览器( 先发送header ),服务器响应100 continue,浏览器 ( 再发送data ),服务器响应200 ok(返回数据)

Question3 TRACE 方法

  • 让 ( 最终的服务器 ) 原样放回发送的内容
  • TRACE 请求会在目的服务器端发起一个 环回 诊断,行程最后一站的服务器会弹回一条 TRACE 响应,并在响应主体中携带它收到的原始请求报文。
  • 这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上,原始报文是否,以及如何被毁坏或修改过
  • 主要作用意义

常见的加密算法

加密算法总体上分为:( 可逆加密 ) 和 ( 不可逆加密 )

1. 可逆加密
- MD5,SHA
- SHA 是安全散列算法
- 由于这些加密都是不可逆的,因此比较常用的场景就是用户密码加密,其验证过程就是通过比较两个加密后的字符串是否一样来确认身份的


2. MD5加密的特点
- 压缩性:无论数据的长度是多少,MD5加密计算出来的值 ( 长度相同 )
- 容易计算性:由 原数据 容易计算出 MD5的值
- 抗修改性:即便只修改一个字符,计算出来的MD5值也差异巨大
- 抗碰撞性:知道数据和`MD5`值,很小概率找到相同`MD5`值相同的原数据

扩展 - 有哪些常见的请求头和响应头

  • 缓存相关
    • 强缓存: ( 请求头 Expires Cache-Control )
    • 协商缓存: ( 响应头 Last-Modified Etag ) ( 请求头 If-Modified-Since If-None-Match)
  • cors 相关
    • 简单请求
      • 请求头
        • Accept Accept-Language Content-Language Last-Event-Id
        • Content-Type: application/x-www-form-urlencoded
        • Content-Type: multipart/form-data
        • Content-Type: text/plain
        • Origin
      • 响应头
        • Access-Control-Allow-Origin
        • Access-Control-Allow-Credentials
        • Access-Control-Expose-Headers
    • 非简单请求
      • 响应头
        • Access-Control-Allow-Methods
        • Access-Control-Allow-Headers
  • HTTP1.1 相关
    • 长链接: 响应头 Connection Keep-Alive
    • 缓存: Cache-Control
    • 断点续传: ( 请求头 Range ) ( 响应头 Content-Range )
  • CSRF 攻击
    • referer

资料

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