前端知识体系-网络

223 阅读47分钟

网络

网络分层

  • 应用层,应用层为操作系统或网络应用程序提供访问网络服务的接口。
    • 报文(message),一般指完整的信息,传输层实现报文交付,位于应用层的信息分组称为报文
  • 传输层,管理两个节点之间的数据传输。负责可靠传输(确保数据被可靠地传送到目标地址)。
    • 报文段(segment),组成报文的每个分组
  • 网络层,地址管理与路由选择, 在这一层,数据的单位称为数据包(packet)(路由器)。
    • 分组(packet)是网络传输中的二进制格式单元,数据包(datapacket)是TCP/IP通信协议传输中的数据单位
  • 数据链路层,互连设备之间传送和识别数据帧(交换机)。
    • 帧(frame),数据链路层的协议数据单元,为了保证数据的可靠传输,把用户数据封装成帧
  • 物理层,以"0"、 "1"代表电压的高低,数据的单位称为比特(bit)
    • PDU(bit),协议数据单元

v2-4f0d5f94dbc6103b807da5dc1bb23478_720w.webp

HTTP

developer.mozilla.org/zh-CN/docs/…

HTTP1.1

长连接

  • keep-alive: 在http1.0时代,每发送一个http请求都会建立一个tcp连接,发送回响应后,连接就会关闭。而TCP连接的建立需要三次握手,极大的浪费了性能。同时一个连接的发起必须是在前一个连接的响应之后。 在http1.1中允许了长连接,当建立起一个tcp连接之后,多个http访问可以复用这个连接,是通过http请求头中的keep-alive来标识的。
  • 管道化:管道化使得连接请求可以“并行”的发送(并不是真的并行)。比如当我们请求一个index.html的时候,不必等到index.html返回我们就可以继续请求img资源。但是服务端还是按照FIFO来响应的。所以并不是真的并行。

现在的浏览器都允许建立多个TCP连接来进行并行请求。但因为浏览器自身的Max-Connection最大连接数的限制,同一个域名(host)下能够建立的TCP数量是一定的。所以我们可以采用CDN将静态资源文件放在不同域名下来保证请求的速度。

宽带优化

  • range头域:在http1.0中,我们有时会对资源造成一定的浪费。比如有时我们只需要一个对象的一部分,我们却将整个资源都传过来了。在http1.1中,增加了range头域,它允许只请求某个资源的一部分,返回码是206。方便了开发者自由的选择以便于充分的利用宽带。

  • head请求:http1.1支持head请求,也就是只有响应头,没用响应正文。

  • Host头处理:http1.1增加了host请求头字段。在http1.0中认为一个服务器绑定一个唯一的域名,但现在一台服务器上可以有多个虚拟主机,共享一个ip,如果消息头中没用host字段,会报400错误。

缓存处理

http1.1引入了更多的缓存处理策略。 在HTTP1.0中主要使用header里的Last-Modified,Expires来做为缓存判断的标准,HTTP1.1引入了Entity tag,Last-Modified, Cache-Control等更多可供选择的缓存头来控制缓存策略。

  • ETag:Etag 是URL的Entity Tag,用于标示URL对象是否改变,控制更加准确。Etag由服务器端生成,客户端通过If-Match或者说If-None-Match这个条件判断请求来验证资源是否修改。
  • If-Match:客户端If-Match的值若与服务端的ETag一致,才会执行请求。
  • If-None-Match:与If-Match相反,对比不一致才会执行请求。
  • If-Range:服务器若指定的If-Range字段值和请求资源的ETag值一致时,则作为范围请求处理(range头指定),否则返回全部资源。
  • Cache-Control(强缓存
    • max-age xxx秒后失效,设置缓存存储的最大周期
    • no-store 不使用任何缓存(强制缓存和协商缓存)
    • no-cache 或 max-age=0, must-revalidate 使用协商缓存,验证资源有效性后可以使用缓存
  • Pragma: 请求标头,Pragma:no-cache 的行为与 Cache-Control: no-cache 相同,但请仅将其用于向后兼容 HTTP/1.0 客户端。
  • Expired(HTTP/1.0 )(强缓存):设置以分钟为单位的绝对过期时间,资源过期后需要和WEB服务器验证其有效性后,才能用来响应客户请求。Cache-Control的优先级高于Expires
  • Last-Modified(HTTP/1.0 ):WEB服务器认为对象的最后修改时间,比如文件的最后修改时间,动态页面的最后产生时间等等。
  • If-Modified-Since(HTTP/1.0 ):如果请求的资源在该头部指定的时间之后修改了,才执行请求的动作,否则返回代码304,告诉浏览器该对象没有修改。
  • If-Unmodified-Since(HTTP/1.0 ):如果请求的资源在该头部指定的时间之后没修改过,才执行请求的动作(比如返回对象)。

2020082518212325.png

Last-Modify 和 If-Modify-Since

浏览器访问一个资源时,服务器响应浏览器的请求,会在Header中加入Last-Modify,Last-modify是一个时间标识该资源的最后修改时间。

当浏览器再次请求该资源时,发送的请求头中会包含If-Modify-Since,该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后,根据资源的最后修改时间判断是否命中缓存。

Last-Modified的缺点

  • Last-Modified最后修改只能精确到秒级,
  • 如果某些文件会被定期生成,当有时内容并没有任何变化,但Last-Modified却改变了,导致文件没法使用有效的缓存。
  • 有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致等情形。
ETag 和 If-None-Match

ETag对于每一个资源都能生成一个唯一的值,资源变化时ETag也会发生变化。Last-Modified与ETag是可以一起使用的,服务器会优先验证ETag,一致的情况下,才会继续比对Last-Modified。ETag的出现解决了Last-Modify遇到的一些问题:

与Last-Modify/If-Modify-Since不同的是,Etag/If-None-Match返回的是一个校验码(ETag: entity tag)。ETag可以保证每一个资源是唯一的,资源变化都会导致ETag变化。ETag值的变更则说明资源状态已经被修改。服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。

segmentfault.com/a/119000001…

TCP

TCP( Transmission control protocol )即传输控制协议

  • 面向连接
  • 可靠的
  • 提供端到端字节流

TCP 报文结构

tcp1.png

TCP 连接建立和关闭

tcppng.png

三次握手

在 TCP/IP 协议中,TCP 协议提供可靠的连接服务,连接是通过三次握手进行初始化的。

(1)第一次握手:Client 将同步标志位 SYN 设置为 1,随机生成一个序列号 x,并将数据包发送给 Server。此时 Client 进入 SYN_SENT 状态,等待 Server 确认。 (2)第二次握手:Server 接收到数据包之后,由 SYN=1 得知这是 Client 请求建立连接。Server 将同步标志位 SYN 设置为 1,将确认标志位 ACK 设置为 1,ack = x+1,随机生成一个序列号 y,并将数据包发送给 Client 确认请求。此时 Server 进入 SYN_RCVD 状态。(半连接列队) (3)第三次握手:Client 接收到数据包后,确认 ack 是否为 x+1,如果是则将确认标志位 ACK 设置为 1,ack=y+1,发送给 Server。此时 Client 状态为 ESTABLISHED。Server 接收到数据包之后检查 ack 是否为 y+1,如果是则成功建立连接,Serve 状态进入 ESTABLISHED,完成三次握手。(全连接列队)

ISN:即 Initial Sequence Number(初始序列号),在三次握手的过程当中,双方会用过 SYN 报文来交换彼此的 ISN。 ISN 并不是一个固定的值,而是每 4 ms 加一,溢出则回到 0,这个算法使得猜测 ISN 变得很困难。那为什么要这么做? 如果 ISN 被攻击者预测到,要知道源 IP 和源端口号都是很容易伪造的,当攻击者猜测 ISN 之后,直接伪造一个 RST 后,就可以强制连接关闭的,这是非常危险的。 而动态增长的 ISN 大大提高了猜测 ISN 的难度。

四次挥手 (1)第一次挥手:Client 向 Server 发送 FIN 标志,用于关闭 Client 到 Server 的数据传送,并发送序列号 a,进入 FIN_WAIT_1 状态。这表示 Client 告诉 Server 我已经没有数据要发给你了。 (2)第二次挥手:Server 接收到 FIN 标志后,发送一个 ack=a+1,告知 Client 它已经接收到了关闭请求,进入 CLOSE_WAIT 状态。Clinet 接收到回应后进入 FIN_WAIT_2 状态。 (3)第三次挥手:Server 发送 FIN 标志,用于关闭 Server 到 Client 的数据传送,并发出序列号 b,进入 LAST_ACK 状态。这表示 Server 告诉 Client 我也没有数据要发送给你了。 (4)第四次挥手:Client 接收到 FIN 标志后,发送一个 ack=b+1,告知 Server 它已经接收到请求关闭,进入 TIME_WAIT 状态。Server 接收到回应进入 CLOSED 状态。等待 2MSL 后,Client 依然没有收到其他回复,则也进入 CLOSED。

为什么要进行第三次握手? 主要原因:防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误,消耗网络资源

第一次握手: 客户端向服务器端发送报文 证明客户端的发送能力正常 第二次握手:服务器端接收到报文并向客户端发送报文 证明服务器端的接收能力、发送能力正常 第三次握手:客户端向服务器发送报文 证明客户端的接收能力正常

如果失效的请求报文发送到服务端,但此时服务器端误认为客户端又发送了一次连接请求,两次握手建立好连接,此时客户端忽略服务器端发来的确认,也不发送数据,造成不必要的错误和网络资源的浪费。

可靠通信(Reliable Communication)

在一个TCP连接上的数据流可以可靠的顺序地投递到目的地。 传输通过系列号(sequence numbers)和确认(acknowledements)来确保可靠。当TCP传输一个包含数据的分片的时候,他将该数据分片的拷贝放在重传队列中,然后开始一个定时器,当数据的确认收到的时候,该分片拷贝从队列中删除,如果在定时到达之前没有收到确认,分片被重传。

MSS

  • 在建立 TCP 连接的同时,也可以确定发送数据包的单位,我们也可以称其为“最大消息长度”(MSS)。最理想的情况是,最大消息长度正好是 IP 中不会被分片处理的最大数据长度。
  • TCP 在传送大量数据时,是以 MSS 的大小将数据进行分割发送。进行重发时也是以 MSS 为单位。

利用窗口控制提高速度

  • TCP 以1个段为单位,每发送一个段进行一次确认应答的处理。这样的传输方式有一个缺点,就是包的往返时间越长通信性能就越低。
  • 为解决这个问题,TCP 引入了窗口这个概念。确认应答不再是以每个分段,而是以更大的单位进行确认,转发时间将会被大幅地缩短。也就是说,发送端主机,在发送了一个段以后不必要一直等待确认应答,而是继续发送。- 窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。上图中窗口大小为4个段。这个机制实现了使用大量的缓冲区,通过对多个段同时进行确认应答的功能。

参考:

RFC: blog.csdn.net/m0_46500807…

blog.csdn.net/m0_56649557…

CORS、简单请求、复杂请求

参考:

cloud.tencent.com/developer/a…

HTTP2

HTTP/2 可以通过同一个 TCP 连接发送多个逻辑数据流,带来更好的拥塞控制、更充分的带宽利用、更长久的 TCP 连接,链路能更容易实现全速传输。标头压缩技术也减少了带宽的用量。另外,HTTP/2 使用的连接聚合(connection coalescing)和“去分片”(desharding)技术还可以进一步缩减连接数。 HTTP/2 解决了 HTTP 的队头拥塞(head of line blocking)问题:客户端必须等待一个请求完成才能发送下一个请求。

多路复用

  • HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧,单个连接可以承受任意数量的双向数据流。 => 并行多个请求响应。
  • 同一域名下,只需要建立一个连接。 => 减少握手等待时间,以及多个 tcp 竞争带宽。
  • 数据流以消息的形式发送,消息由一个或多个帧组成;帧可以乱序发送,根据帧头部的流标识重新组装。 => 可以设置一个 31 bit 的优先级,有了这个优先值,客户端和服务器就可以在处理不同的流时采取不同的策略,以最优的方式发送流、消息和帧。

二进制分帧

在二进制分帧层中, HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用格式的编码 ,其中 HTTP1.x 的首部信息会被封装到 HEADER frame,而相应的 Request Body 则封装到 DATA frame 里面。

通过二进制分帧,HTTP/2 可以让所用数据流共用一个 TCP 连接,从而减少网络拥塞。

首部压缩

在 HTTP/1.1 中,header 字段未被压缩。HTTP2 使用 HPACK 方法压缩 HTTP 头部,减少带宽消耗。

服务端推送

服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应。

HTTP2升级

从HTTP/1.1升级到h2c,其实是和HTTP/1.1升级到WebSocket协议是一样的,步骤如下 1.客户端传一个头部
Connection: Upgrade,HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: 438997893ab379
2.客户端回一个101响应码
HTTP/1.1 101 SwitchingProtocals
Connection: Upgrade
Upgrade: h2c
3.客户端再发送一个Magic帧,Magic帧的固定格式 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n 055.

zhuanlan.zhihu.com/p/405149337

HTTP3

QUIC 协议:

  • 基于UDP的传输层协议
  • 可靠性
    • 虽然UDP不提供可靠的传输,但QUIC在基于UDP之时增加了一层带来可靠性的层。它提供了数据包重传、拥塞控制、调整传输节奏(pacing)以及其他一些TCP中存在的特性。
  • 数据流,QUIC在同一物理连接上可以有多个独立的逻辑数据流。这些数据流并行在同一个连接上传输,不影响其他流。
  • 有序交付,QUIC的单个数据流可以保证有序交付,但多个数据流之间可能乱序
  • 快速握手,QUIC提供0-RTT和1-RTT的连接建立,这意味着QUIC在最佳情况下不需要任何的额外往返时间便可建立新连接。其中更快的0-RTT仅在两个主机之间建立过连接且缓存了该连接的“秘密”(secret)时可以使用。

TCP队头阻塞

采用HTTP/2时,浏览器一般会在单个TCP连接中创建并行的几十个乃至上百个传输。

如果HTTP/2连接双方的网络中有一个数据包丢失,或者任何一方的网络出现中断,整个TCP连接就会暂停,丢失的数据包需要被重新传输。因为TCP是一个按序传输的链条,因此如果其中一个点丢失了,链路上之后的内容就都需要等待。

独立的数据流避免阻塞问题

使用QUIC时,两端间仍然建立一个连接,该连接也经过协商使得数据得到安全且可靠的传输。

但是,当我们在这个连接上建立两个不同的数据流时,它们互相独立。也就是说,如果一个数据流丢包了,只有那个数据流必须停下来,等待重传。

http3-explained:http3-explained.haxx.se/zh/why-quic

HTTPS

SSL 协议的握手过程:

  • 第一步,客户端给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

  • 第二步,服务器确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

  • 第三步,客户端确认数字证书有效,若证书失效,则会给访问者一个警示,由其决定是否继续连接;若有效则生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给服务器;

  • 第四步,服务器使用自己的私钥,获取客户端发来的随机数(即 Premaster secret)。

  • 第五步,客户端和服务器根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。

参考图解 SSL/TLS 协议

证书

数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件,它是由权威机构—CA 机构,又称为证书授权(CertificateAuthority)中心发行的。 CA 机构,又称为证书授证(CertificateAuthority)中心,作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。CA 中心为每个使用公开密钥的用户发放一个数字证书,数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA 机构的数字签名使得攻击者不能伪造和篡改证书。

CA 证书颁发过程

用户首先产生自己的密钥对,并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后,将执行一些必要的步骤,以确信请求确实由用户发送而来,然后,认证中心将发给用户一个数字证书,该证书内包含用户的个人信息和他的公钥信息,同时还附有认证中心的签名信息。

验证证书的内容

  • 验证证书有效期(起止时间)
  • 验证证书域名(与浏览器地址栏中域名是否匹配)
  • 验证证书吊销状态(CRL+OCSP).
  • 验证证书颁发机构, 如果颁发机构是中间证书, 在验证中间证书的有效期/颁发机构/吊销状态. 一直验证到最后一层证书, 如果最后一层证书是在操作系统或浏览器内置, 那么就是可信的, 否则就是自签名。 以上验证步骤, 需要全部通过. 否则就会显示警告.

客户端如何验证证书的合法性

  1. 首先浏览器读取证书中的证书所有者、有效期等信息进行校验,校验证书的网站域名是否与证书颁发的域名一致,校验证书是否在有效期内
  2. 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA,与服务器发来的证书中的颁发者CA比对,用于校验证书是否为合法机构颁发
    • 如果找不到,浏览器就会报错,说明服务器发来的证书是不可信任的。
    • 如果找到,那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布 版本时,会事先在内部植入常用认证机关的公开密钥),然后对服务器发来的证书里面的签名进行解密
  3. 浏览器使用相同的hash算法计算出服务器发来的证书的hash值,将这个计算的hash值与证书中签名做对比
  4. 对比结果一致,则证明服务器发来的证书合法,没有被冒充

参考:

www.ruanyifeng.com/blog/2014/0…

zhuanlan.zhihu.com/p/25587986

中间人攻击

过程原理:

1.本地请求被劫持(如 DNS 劫持等),所有请求均发送到中间人的服务器

2.中间人服务器返回中间人自己的证书

3.客户端创建随机数,通过中间人证书的公钥对随机数加密后传送给中间人,然后凭随机数构造对称加密对传输内容进行加密传输

4.中间人因为拥有客户端的随机数,可以通过对称加密算法进行内容解密

5.中间人以客户端的请求内容再向正规网站发起请求

6.因为中间人与服务器的通信过程是合法的,正规网站通过建立的安全通道返回加密后的数据

7.中间人凭借与正规网站建立的对称加密算法对内容进行解密

8.中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输

9.客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证,所以客户端虽然发起的是 HTTPS 请求,但客户端完全不知道自己的网络已被拦截,传输内容被中间人全部窃取。

参考: jichengw.com/htmlcssn/64…

DNS

DNS(Domain Name System,域名系统)是一种把域名称解析为对应的 IP 地址的服务。在 UNIX 和 Linux 操作系统中的 DNS 服务通常称为 BIND(Berkeley Internet Name Domain Service,伯克利因特网名称域服务)。

整个互联网是一个 DNS 名称空间,DNS 名称空间是一个树形结构,最顶端称为互联网的“根域”,以一个小圆点(.)表示,接下来是顶级域,再接下来是二级域、三级域,依此类推。其中,顶级域名和二级域名必须是由对应的互联网域名管理机构颁布的。

  • 顶级域名:是根域名下的第一级域名,包括三类,即国家地区类、通用类、新增的通用类,如 cn(中国)、us(美国)、jp(日本)等
  • 二级域名:是指顶级域名下的域名,分为两类:在国际顶级域名下,它是指域名注册人的网上名称,例如 ibm、microsoft 等,这是可供用户申请的;在国家或地区顶级域名下,它表示注册企业类别的符号,如 com、edu、gov、net 等,这些是不能直接供用户申请注册的。
  • 三级域名:可以由用户自己申请注册的,可以采用字母(AZ、az、大小写组合等)、数字(0~9)和连接符(-)等,各级域名之间用小圆点(.)连接。

DNS 域名服务器

即担当 DNS 域名解析任务并配置了 DNS 服务的服务器。为了有效地管理整个互联网的 DNS 域名解析工作,DNS 系统开发者设计了一个与分层的 DNS 域名结构类似的层次化 DNS 域名服务器结构,把所有 DNS 域名称服务器自高到低分成 4 个级别:根域名服务器、顶级域名服务器、权威域名服务器和本地域名服务器。它们都是由互联网域名管理机构或下级的 ISP(互联网服务供应商) 负责配置建立的。

根域名服务器

负责对互联网上所有“顶级名称服务器”进行管理,有全部的顶级名称服务器的 IP 地址和域名映射。是域名解析的入口。

全球共有 13 套,这 13 台主根名称服务器主机名分别为字母 A-M,即完整 DNS 名称为 a.rootserver.net~m.rootserver.net。

顶级域名服务器

各顶级域名自己的名称服务器,负责它们各自所管理的二级域名解析。

权威域名服务器

针对 DNS 区域提供名称解析服务而专门建立的名称服务器,可为用户提供最权威的 DNS 域名解析。 该域下二级、三级甚至更多级的域名都在这里解析。

每一级域一个服务器,如果域名的层次过多,那么就要往返查询好多次,效率也不高。所以 DNS(Domain Name System)只分了三级域名服务器其,把二、三、四、五甚至更多级的域名都合并在一个服务器解析了,叫做权威域名服务器。

本地域名服务器

本地域名服务器是移动、联通等 ISP(因特网服务提供商)提供的,一般在每个城市都有一个。某台机器访问了某个域名,解析之后会把结果缓存下来,其他机器访问这个域名就不用再次解析了。

这里所说的“本地名称服务器”不是指用户局域网中的名称服务器,而是用户端操作系统所配置的、由本地 ISP 提供的名称服务器。它是离用户最近的互联网名称服务器。用户发出的 DNS 域名解析请求,首先到达的就是本地名称服务器。

如果本地名称服务器解析不了用户所请求的域名,那么这个本地名称服务器就会直接向所配置的根名称服务器发出解析请求,由根名称服务器告知它该向哪个顶级名称服务器查询。如果顶级名称服务器还不能解析,则顶级名称服务器会向本地名称服务器告知要向哪个权威名称服务器发出请求,然后本地名称服务器继续向对应权威名称服务器请求解析。如果权威名称服务器还不能解析的话,则这次 DNS 域名解析请求失败。

DNS 解析

递归查询 (Recursive query)

递归查询一般发生在客户端请求 DNS Server。客户端发出一个域名解析的请求,DNS Server 必须返回对应的 IP 地址,或者返回找不到的错误。

迭代查询 (Iterative query)

迭代查询一般发生在 DNS Server 之间,当 Client 发出域名解析的请求后,DNS Server 需要给予最佳答案,这个最佳答案可能是"距离最近"的顶级域名服务器,也能是权威域名服务器。无论如何,Client 需要对返回结果再次发起请求,知道获得最终结果。 域名服务器之间的查询使用迭代查询方式,以免根域名服务器的压力过大

当然,每次查询还是比较耗时的,查询完之后要把结果缓存下来,并且设置一个过期时间,域名解析记录在 DNS 服务器上的缓存时间叫做 TTL(Time-To-Live)。

DNS 解析基本流程

20201130171101884.png

  1. 客户端向本机配置的本地域名服务器发出 DNS 域名查询请求。
  2. 本地域名服务器收到请求后,先查询本地的缓存,如果有该域名的记录项,则本地域名服务器直接把查询的结果返回给客户端;如果本地缓存中没有该域名的记录,则本地域名服务器再以 DNS 客户端的角色发送与前面一样的 DNS 域名查询请求给根域名服务器。
  3. 根域名服务器收到 DNS 请求后,把顶级域名所对应的顶域名称服务器地址返回给本地域名服务器。
  4. 本地域名服务器根据根域名服务器返回的顶级域名服务器地址,向对应的顶级域名服务器发送与前面一样的 DNS 域名查询请求。
  5. 对应的顶级域名服务器在收到 DNS 查询请求后,也是先查询自己的缓存,如果有所请求的 DNS 域名的记录项,则先把对应的记录项返回给本地域名服务器,然后再由本地域名服务器返回给 DNS 客户端,否则向本地域名服务器返回所请求的 DNS 域名中的二级域名所对应的二域名称服务器地址。
  6. 然后,本地域名服务器继续按照前面介绍的方法一次次地向三级、四级域名服务器查询,直到最终的对应域名所在区域的权威域名服务器返回最终的记录给本地域名服务器,再由本地域名服务器返回给 DNS 客户,同时本地域名服务器会缓存本次查询得到的记录项。

参考:

zhuanlan.zhihu.com/p/351059293

DNS 报文结构

6-1911111G20QV (1).png

  • 事务 ID:DNS 报文的 ID 标识。对于请求报文和其对应的应答报文,该字段的值是相同的。通过它可以区分 DNS 应答报文是对哪个请求进行响应的。
  • 标志:DNS 报文中的标志字段。
  • 问题计数:DNS 查询请求的数目。
  • 回答资源记录数:DNS 响应的数目。
  • 权威名称服务器计数:权威名称服务器的数目。
  • 附加资源记录数:额外的记录数目(权威名称服务器对应 IP 地址的数目)。
  • 问题部分,指是报文格式中查询问题区域(Queries)部分。该部分是用来显示 DNS 查询请求的问题,通常只有一个问题。该部分包含正在进行的查询信息,包含查询名(被查询主机名字)、查询类型、查询类。
  • 资源记录部分,指 DNS 报文格式中的最后三个字段,包括回答问题区域字段、权威名称服务器区域字段、附加信息区域字段。

DNS 劫持

DNS 劫持又称域名劫持,是通过劫持技术修改域名注册信息,修改 DNS 解析,劫持修改域名解析结果。使访问域名的用户不能够准确达到目标站点,而进入指定站点。

例如:

  1. 用户计算机感染病毒,该病毒在操作系统中 HOSTS 文件中添加了虚假的 DNS 解析记录,因为系统本地的 DNS 解析记录高于 DNS 服务器,操作系统在访问域名的时候都会先行检测本地 DNS 解析记录,然后在访问 DNS 服务器。

  2. 用户试图访问的网站被攻击这击破,并在网站中植入路由 DNS 劫持代码,当用户访问网站,浏览器就是自动执行路由 DNS 劫持代码,用户路由器如果存在漏洞就会中招,导致用户上网流量被假 DNS 服务器劫持,出现广告,各种奇怪现象。

  3. 当用户打开浏览器主页的时候,却出现 ISP 提供的定向页面,广告页面等内容页面

  4. 用户在浏览器中输入了错误的域名,导致 DNS 查询不存在的记录。以前遇到这种情况,浏览器通常会返回一个错误提示。而最近,这种情况下用户会看到 ISP 设置的域名纠错系统提示。,广告页面等内容页面。

  5. 用户想通过该网址访问 A 网站结果却指向了 B 网站。

如何防范 DNS 劫持:

第一:使用安全稳定可靠的 DNS 服务器,并且及时升级,更新补丁,加固服务器。

第二:保护好域名注册的账号信息。增加域名账号密码的复杂性。

第三:注意本地计算机系统的安全性,使用杀毒软件安全防范。、

DNS服务器的实现

mp.weixin.qq.com/s?__biz=Mzg…

CDN

CDN(Content Delivery Network)是指内容分发网络,也称为内容传送网络。由于CDN是为加快网络访问速度而被优化的网络覆盖层,。其主要作用范围是用于前端的静态资源加速。CDN的优点:

  • 访问速度(离得最近的资源返回)
  • 减轻源站(服务器)的负载压力
  • 跨运营商,可以保证不同网络中的用户都能得到良好的访问质量
  • 集群抗攻击性:主要是降低各种D.D.o.S攻击对网站的影响 CDN的运作流程

阿里云CDN解析流程

20200825182252914.png

  • 当终端用户(北京)向www.a.com 下的某资源发起请求时,首先向LDNS(本地DNS)发起域名解析请求。
  • LDNS检查缓存中是否有www.a.com 的IP地址记录。如果有,则直接返回给终端用户;如果没有,则向授权DNS查询。
  • 当授权DNS解析www.a.com 时,返回域名CNAME www.a.tbcdn.com 对应IP地址(CNAME 别名,指向另外一个域名)。
  • 域名解析请求发送至阿里云DNS调度系统,并为请求分配最佳节点IP地址
  • LDNS获取DNS返回的解析IP地址。
  • 用户获取解析IP地址。
  • 用户向获取的IP地址发起对该资源的访问请求。
  • 如果该IP地址对应的节点已缓存该资源,则会将数据直接返回给用户,请求结束。
  • 如果该IP地址对应的节点未缓存该资源,则节点向源站发起对该资源的请求。获取资源后将资源缓存至节点并返回给用户,请求结束。
缓存命中率

对于一个缓存而言,有一点很重要,就是你的缓存到底有没有用,衡量这个东西的就是缓存命中率。

资源预热

缓存设计中,预热是很重要的环节,在最初刚开始启动 CDN 的时候,CDN 上并没有缓存数据,此刻大量的请求全部打向源站,肯定会把源站打挂,预热就是事先缓存好热门数据,这样在业务上线时,CDN 上已经有所需的数据了。

原文链接:blog.csdn.net/Shaoyouiqng…

如何找到离用户最近的 CDN 节点 ?

找到离用户最近的 CDN 节点是由 CDN 的全局负载均衡器( Global Sever Load Balance,GSLB 负责的。

GSLB 就会为用户选择一台合适的 CDN 节点提供服务,选择的依据主要有以下几点:

  • 看用户的 IP 地址,查表得知地理位置,找相对最近的 CDN 节点;
  • 看用户所在的运营商网络,找相同网络的 CDN 节点;
  • 看用户请求 URL,判断哪一台服务器上有用户所请求的资源;
  • 查询 CDN 节点的负载情况,找负载较轻的节点;

GSLB 会基于以上的条件进行综合分析后,找出一台最合适的 CDN 节点,并返回该 CDN 节点的 IP 地址给本地 DNS 服务器,然后本地 DNS 服务器缓存该 IP 地址,并将 IP 返回给客户端,客户端去访问这个 CDN 节点,下载资源。

HTTP 劫持

HTTP 劫持:你 DNS 解析的域名的 IP 地址不变。在和网站交互过程中的劫持了你的请求。在网站发给你信息前就给你返回了请求。

HTTP 劫持很好判断,当年正常访问一个无广告的页面时,页面上出现广告弹窗,很可能就是运营商劫持了 HTTP。

原理:

  1. 标识 HTTP 连接。在天上飞的很多连接中,有许多种协议,第一步做的就是在 TCP 连接中,找出应用层采用了 HTTP 协议的连接,进行标识
  2. 篡改 HTTP 响应体,可以通过网关来获取数据包进行内容的篡改
  3. 抢先回包,将篡改后的数据包抢先正常站点返回的数据包先到达用户侧,这样后面正常的数据包在到达之后会被直接丢弃

如何防范 HTTP 劫持:

  1. 事前加密 HTTPS

很大一部分 HTTP 劫持,主要的原因就是在传输数据时都是明文的,使用了 HTTPS 后,会在 HTTP 协议之上加上 TLS 进行保护,使得传输的数据进行加密,但是使用 HTTPS,一定要注意规范,必须要全站使用 HTTPS,否则只要有一个地方没有使用 HTTPS,明文传输就很有可能会被 HTTP 劫持了。

  1. 事中加密 拆分 HTTP 请求数据包

在 HTTP 劫持的步骤中,第一步是标记 TCP 连接,因此只要躲过了标识,那么后续的运营商篡改就不会存在了,有一种方式就是拆分 HTTP 请求

拆分数据包就是把 HTTP 请求的数据包拆分成多个,运营商的旁路设备由于没有完整的 TCP/IP 协议栈,所以就不会被标志,而目标 web 服务器是有完整的 TCP/IP 协议栈,能接收到的数据包拼成完整的 HTTP 请求,不影响服务

  1. 事后屏蔽 通过浏览器 Api,根据若干规则去匹配 DOM 中的节点,对匹配到的节点作拦截和隐藏

CSP(内容安全策略),DOM 事件监听等。

CSP 是浏览器附加的一层安全层,用于对抗跨站脚本与数据注入,运营商植入内容性质与数据注入类似,因此,可以用 CSP 对抗运营商劫持。通过在 HTTP 响应头或 meta 标签设置好规则,支持拦截和上报劫持信息的功能。

DOM 事件监听主要是监听 DOMNodeInserted、DOMContentLoaded、DOMAttrModified 等事件,可以在前端 DOM 结构发生变化时触发回调,这时补充一些检测逻辑,即可判断是不是业务的正常 UI 逻辑,如果不是,即可认为是来自劫持

Websocket

Websocket使用TCP链接来进行双向数据传输,支持在 TCP 上层引入 TLS 层, 以建立加密数据传输通道, 即 WebSocket over TLS。 在 WebSocket 协议中, 帧 (frame) 是通信双方数据传输的基本单元, 与其它网络协议相同, frame 由 Header 和 Payload 两部分构成。

WebSocket 握手

WebSocket 握手采用 HTTP Upgrade 机制, 客户端可以发送如下所示的结构发起握手:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

服务端若支持 WebSocket 协议, 并同意握手, 可以返回如下所示的结构:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
  • Upgrade:upgrade是HTTP1.1中用于定义转换协议的header域。它表示,如果服务器支持的话,客户端希望使用现有的「网络层」已经建立好的这个「连接(此处是TCP连接)」,切换到另外一个「应用层」(此处是WebSocket)协议
  • Connection:必须设置 Upgrade,表示客户端希望连接升级;
  • Sec-WebSocket-Key , 必传, 由客户端随机生成的 16 字节值, 然后做 base64 编码, 客户端需要保证该值是足够随机
  • Sec-WebSocket-Protocol , 可选, 客户端发起握手的时候可以在头部设置该字段, 该字段的值是一系列客户端希望在于服务端交互时使用的子协议 (subprotocol)
  • Origin:作安全使用,防止跨站攻击,浏览器一般会使用这个来标识原始域
  • Sec-WebSocket-Accept , 必传,通过客户端的Sec-WebSocket-Key计算并检验服务端对 WebSocket 协议的支持性
  • Sec-WebSocket-Version, 必传, 服务端从客户端传递的支持的 WebSocket 协议版本中选择其中一个, 若客户端传递的所有 WebSocket 协议版本对服务端来说都不支持, 则服务端应立即终止握手, 并返回 HTTP 426 状态码

WebSocket 数据帧 (frame)

WebSocket 以 frame 为单位传输数据, frame 是客户端和服务端数据传输的最小单元, 当一条消息过长时, 通信方可以将该消息拆分成多个 frame 发送, 接收方收到以后重新拼接、解码从而还原出完整的消息, 在 WebSocket 中, frame 有多种类型, frame 的类型由 frame 头部的 Opcode 字段指示:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+
  • FIN, 长度为 1 比特, 该标志位用于指示当前的 frame 是消息的最后一个分段, 因为 WebSocket 支持将长消息切分为若干个 frame 发送, 切分以后, 除了最后一个 frame, 前面的 frame 的 FIN 字段都为 0, 最后一个 frame 的 FIN 字段为 1, 当然, 若消息没有分段, 那么一个 frame 便包含了完成的消息, 此时其 FIN 字段值为 1

  • RSV 1 ~ 3, 这三个字段为保留字段, 只有在 WebSocket 扩展时用, 若不启用扩展, 则该三个字段应置为 1, 若接收方收到 RSV 1 ~ 3 不全为 0 的 frame, 并且双方没有协商使用 WebSocket 协议扩展, 则接收方应立即终止 WebSocket 连接

  • Opcode, 长度为 4 比特, 该字段将指示 frame 的类型, RFC 6455 定义的 Opcode 共有如下几种:\

    • 0x0, 代表当前是一个 continuation frame
    • 0x1, 代表当前是一个 text frame
    • 0x2, 代表当前是一个 binary frame
    • 0x3 ~ 7, 目前保留, 以后将用作更多的非控制类 frame
    • 0x8, 代表当前是一个 connection close, 用于关闭 WebSocket 连接
    • 0x9, 代表当前是一个 ping frame (将在下面讨论)
    • 0xA, 代表当前是一个 pong frame (将在下面讨论)
    • 0xB ~ F, 目前保留, 以后将用作更多的控制类 frame
  • Payload Len, 以字节为单位指示 frame Payload 的长度, 该字段的长度可变

  • Payload, 该字段的长度是任意的, 该字段即为 frame 的数据部分

  • Mask, 长度为 1 比特, 该字段是一个标志位, 用于指示 frame 的数据 (Payload) 是否使用掩码掩盖, RFC 6455 规定当且仅当由客户端向服务端发送的 frame

  • Masking-key, 该字段为可选字段, 当 Mask 标志位为 1 时, 代表这是一个掩码覆盖的 frame

消息分片

发送的一条消息过长或者消息是实时产生并不能预测具体的长度时, 客户端可将消息进行分片, 构成一个 frame 后便可以发往服务端, 分片的另一个考虑是为了复用底层的 TCP 连接, 当客户端有多份相互独立的数据需要发送时, 消息分片可以实现在一条 TCP 链路上的复用, 多份数据可以并发地发往服务端, 如果读者了解过 HTTP/2 [RFC 7540] 便可以知道这里也是 HTTP/2 的做法 消息分片主要利用 frame Header 的 FIN 和 Opcode 字段来实现:

  • 一个未分片的消息包含一个设置了FIN字段(标记为1)的单独的帧和一个除0以外的操作码。
  • 一个分片的消息包含一个未设置的FIN字段(标记为0)的单独的帧和一个除0以外的操作码,然后跟着0个或者多个未设置FIN字段的帧和操作码为0的帧,然后以一个设置了FIN字段以及操作码为0的帧结束。一个分片的消息内容按帧顺序组合后的payload字段,是等价于一个单独的更大的消息payload字段中包含的值
  • 控制帧(见5.5节)可能被插入到分片消息的中间。控制帧不能被分片。
  • 消息片段必须在发送端按照顺序发送给接收端。
  • 除非在扩展中定义了这种嵌套的逻辑,否则一条消息分的片不能与另一条消息分的片嵌套传输。
  • 终端必须有能力来处理在分片的消息中的控制帧。
  • 发送端可能会创建任意大小的非控制消息片段。
  • 客户端和服务端必须同时支持分片和不分片消息。

 WebSocket 挥手

控制帧的操作码值是0x8。 关闭帧可能包含内容(body)(帧的“应用数据”部分)来表明连接关闭的原因。 WebSocket 的连接关闭分为 CLOSING 和 CLOSED 两个阶段, 当发送完 Close frame 或接收到对方发来的 Close frame 后, WebSocket 连接便从 OPEN 状态转变为 CLOSING 状态, 此时可以称挥手已启动, 通信方接收到 Close frame 后应立即向对方发回 Close frame, 并关闭底层 TCP 连接, 此时 WebSocket 连接处于 CLOSED 状态

参考:juejin.cn/post/684490…

WEB安全

XSS

XSS是跨站脚本攻击(Cross Site Scripting),不写为CSS是为了避免和层叠样式表(Cascading Style Sheets)的缩写混淆,所以将跨站脚本攻击写为XSS。攻击者可以通过向Web页面里面插入script代码,当用户浏览这个页面时,就会运行被插入的script代码,达到攻击者的目的。XSS的危害一般是泄露用户的登录信息cookie,攻击者可以通过cookie绕过登录步骤直接进入站点。XSS的分类分为反射型和存储型。反射型就是临时通过url访问网站,网站服务端将恶意代码从url中取出,拼接在HTML中返回给浏览器,用户就会执行恶意代码。存储型就是将恶意代码以留言的形式保存在服务器数据库,任何访问网站的人都会受到攻击。预防XSS攻击的方案基本是对数据进行严格的输出编码,比如HTML元素的编码,JavaScript编码,css编码,url编码等等。

XSS的危害

  • 获取cookie:网站中的登录一般都是用cookie作为某个用户的身份证明,这是服务器端返回的一串字符。如果cookie被攻击者拿到,那么就可以绕过密码登录。当空间、论坛如果可以被插入script代码,那么进入空间或者论坛的人的账号就可以轻易被攻击者获取。
  • 恶意跳转:直接在页面中插入window.location.href进行跳转

XSS的分类

  • DOM型:取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞
  • 反射型XSS(非持久型XSS):通过URL参数直接注入
  • 存储型XSS(持久型XSS):存储到数据库后读取时注入 XSS的预防
  •  浏览器的防御和“X-XSS-Protection”有关,默认值为1,即默认打开XSS防御,可以防御反射型的XSS,不过作用有限,只能防御注入到HTML的节点内容或属性的XSS,例如URL参数中包含script标签。不建议只依赖此防御手段。
  •    防御HTML节点内容,通过转义<为&lt以及>为&gt来实现防御HTML节点内容。
  •    预防HTML属性,通过转义"->&quto来实现防御,一般不转义空格,但是这要求属性必须带引号
  •    预防JavaScript代码,通过将数据进行JSON序列化。
    • 防御富文本是比较复杂的工程,因为富文本可以包含HTML和script,这些难以预测与防御,建议是通过白名单的方式来过滤允许的HTML标签和标签的属性来进行防御,大概的实现方式是:
    •  将HTML代码段转成树级结构的数据
    •  遍历树的每一个节点,过滤节点的类型和属性,或进行特殊处理
    •  处理完成后,将树级结构转化成HTML代码
  •    开启浏览器XSS防御:Http Only cookie,禁止 JavaScript 读取某些敏感 Cookie,攻击者完成XSS注入后也无法窃取此 Cookie;sameSite strict;

CSRF

CSRF 攻击思想:
1、浏览并登录信任网站A
2、登录成功后在浏览器产生信息存储(举例:cookie)
3、用户在没有登出淘宝的情况下,访问危险网站B
4、危险网站B中存在恶意代码,代码为发送一个恶意请求
5、携带刚刚在浏览器产生的信息进行恶意请求
6、网站A验证请求为合法请求(区分不出是否是该用户发送) 7、达到了恶意目标

防御方法:

  • HTTP 协议中使用 Referer 属性来确定请求来源进行过滤(禁止外域)

  • 请求地址添加 token ,使黑客无法伪造用户请求

  • HTTP 头自定义属性验证(类似上一条)

  • 显示验证方式:添加验证码、密码等

HSTS(HTTP Strict Transport Security)

HSTS:通知浏览器此网站禁止使用 HTTP 方式加载,浏览器应该自动把所有尝试使用 HTTP 的请求自动替换为 HTTPS 进行请求。

HTTP劫持

  • 302劫持。用户正常的请求能够请求到CDN节点,但是正常请求返回200OK,通信链路修改HTTP响应头为302,并插入location字段,导致用户强制跳转到非法节点响应。

  • 内容劫持。用户正常的请求能够请求到CDN节点,但是正常请求返回200OK,经过http请求被标示,并通过旁路设备改写HTTP响应内容(例如HTML插入iframe),抢先回包策略,响应给用户。

防HTTP劫持:全站业务使用HTTPS方案

CDN 劫持

当我们访问某个资源时会去附近的CDN节点上进行访问,如果这个资源存在则使用CDN上的这个资源,这个过程是HTTPS加密的,所以不存在劫持;可是当我们的资源发生了变化,或者是CDN上没有这个资源,那么就会去源节点上去寻找这个资源,并且拉取到这个CDN上,这个过程就是回源,回源的这个过程是HTTP的,所以这个过程存在风险,资源在这个过程中有被篡改或者替换的可能。

script 标签新增了integrity属性,子资源完整性(SRI)是允许浏览器检查其获得的资源(例如从 CDN 获得的)是否被篡改的一项安全特性。它通过验证获取文件的哈希值是否和你提供的哈希值一样来判断资源是否被篡改。

使用 SRI:

通过使用 webpack 的 html-webpack-plugin 和 webpack-subresource-integrity 可以生成包含 integrity 属性 script 标签。

CDN防劫持方案。1)全链路HTTPS 2)对内容的MD5验证 3)回源直接IP回源,减少回源链路DNS劫持。4)中间链路私有协议SDN传输。

developer.mozilla.org/zh-CN/docs/…

zhuanlan.zhihu.com/p/69491352

cloud.tencent.com/developer/a…

加密算法

对称加密

加密和解密使用相同密钥的加密算法。对称加密算法的优点在于加解密的高速度和使用长密钥时的难破解性。

对称加密算法用来对敏感数据等信息进行加密,常用的算法包括:

  • DES(Data Encryption Standard):数据加密标准,速度较快,适用于加密大量数据的场合。

  • 3DES(Triple DES):是基于DES,对一块数据用三个不同的密钥进行三次加密,强度更高。

  • AES(Advanced Encryption Standard):高级加密标准,是下一代的加密算法标准,速度快,安全级别高;

非对称加密

指加密和解密使用不同密钥的加密算法,也称为公私钥加密。 非对称加密的缺点是加解密速度要远远慢于对称加密,在某些极端情况下,甚至能比非对称加密慢上1000倍。

  • RSA:由 RSA 公司发明,是一个支持变长密钥的公共密钥算法,需要加密的文件块的长度也是可变的;

  • DSA(Digital Signature Algorithm):数字签名算法,是一种标准的 DSS(数字签名标准);

  • ECC(Elliptic Curves Cryptography):椭圆曲线密码编码学。

    • ECC和RSA相比,在许多方面都有对绝对的优势,主要体现在以下方面:

    • 抗攻击性强。相同的密钥长度,其抗攻击性要强很多倍。

    • 计算量小,处理速度快。ECC总的速度比RSA、DSA要快得多。

  • SM2 国密标准的椭圆曲线加密算法

Hash算法

Hash算法特别的地方在于它是一种单向算法,用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值,却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

散列算法

散列是信息的提炼,通常其长度要比信息小得多,且为一个固定长度。加密性强的散列一定是不可逆的,这就意味着通过散列结果,无法推出任何部分的原始信息。任何输入信息的变化,哪怕仅一位,都将导致散列结果的明显变化,这称之为雪崩效应。散列还应该是防冲突的,即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。

单向散列函数一般用于产生消息摘要,密钥加密等,常见的有:

  • MD5(Message Digest Algorithm 5):是RSA数据安全公司开发的一种单向散列算法,非可逆,相同的明文产生相同的密文。

  • SHA(Secure Hash Algorithm):可以对任意长度的数据运算生成一个160位的数值;

SHA-1与MD5的比较

因为二者均由MD4导出,SHA-1和MD5彼此很相似。相应的,他们的强度和其他特性也是相似,但还有以下几点不同:

  • 对强行供给的安全性:最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术,产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作,而对SHA-1则是2160数量级的操作。这样,SHA-1对强行攻击有更大的强度。

  • 对密码分析的安全性:由于MD5的设计,易受密码分析的攻击,SHA-1显得不易受这样的攻击。

  • 速度:在相同的硬件上,SHA-1的运行速度比MD5慢。

数字签名的流程

发送者:

  1. 发送者对消息计算摘要值。
  2. 发送者用私钥对摘要值进行签名得到签名值。
  3. 发送者将原始消息和签名值一同发给接收者。 接收者:
  4. 接收者接收到消息后,拆分出消息和消息签名值A。
  5. 接收者使用公钥对消息进行运算得到摘要值B。
  6. 接收者对摘要值B和签名值A进行比较,如果相同表示签名验证成功,否则就是验证失败。

zhuanlan.zhihu.com/p/272888661