佳宸学习和分享笔记的地方

0%

网络基础 复习

网络基础

UDP

UDP 协议是面向无连接的,正式传递数据之前不需要先连接起双方(不可靠性)。不会对数据报文进行任何拆分和拼接操作(高效)。

UDP支持一对多,多对多,多对一的方式。

TCP

TCP 建立连接断开连接都需要先需要进行握手。

建立连接3次握手

img

断开连接四次握手

img

http

get post 区别

  • Get 请求能缓存,Post 不能
  • Post 相对 Get 安全一点,因为Get 请求都包含在 URL 里(当然你想写到 body 里也是可以的),且会被浏览器保存历史纪录。Post 不会,但是在抓包的情况下都是一样的。
  • URL有长度限制,会影响 Get 请求,但是这个长度限制是浏览器规定的,不是 RFC 规定的
  • Post 支持更多的编码类型且不对数据类型限制

常见状态码

2XX 成功

  • !!200 OK,表示从客户端发来的请求在服务器端被正确处理

  • 204 No content,表示请求成功,但响应报文不含实体的主体部分(请求成功但是没有资源返回)

  • 205 Reset Content,表示请求成功,但响应报文不含实体的主体部分,但是与 204 响应不同在于要求请求方重置内容

  • 206 Partial Content,进行范围请求

    图片摘取自HTTP图解

3XX 重定向

  • !!301 moved permanently,永久性重定向,表示资源已被分配了新的 URL

    图片摘取自HTTP图解

  • !!302 found,临时性重定向,表示资源临时被分配了新的 URL

    图片摘取自HTTP图解

  • 303 see other,表示资源存在着另一个 URL,应使用 GET 方法获取资源

    图片摘取自HTTP图解

  • !!304 not modified,表示服务器允许访问资源,但因发生请求未满足条件的情况(304 虽 然被划分在 3XX 类别中,但是和重定向没有关系。)

    图片摘取自HTTP图解

  • 307 temporary redirect,临时重定向,和302含义类似,尽管 302 标准禁止 POST 变换成 GET,但实际使用时大家并不遵守。

    307 会遵照浏览器标准,不会从 POST 变成 GET。但是,对于处理响应时的行为,每种浏览器有可能出现不同的情况

4XX 客户端错误

  • !!400 bad request,请求报文存在语法错误

    图片摘取自HTTP图解

  • !!401 unauthorized,表示发送的请求需要有通过 HTTP 认证的认证信息

    图片摘取自HTTP图解

  • !!403 forbidden,表示对请求资源的访问被服务器拒绝

  • !!404 not found,表示在服务器上没有找到请求的资源

  • 405 Method Not Allowed, 客户端请求的方法虽然能被服务器识别,但是服务器禁止使用该方法(GET 和 HEAD 方法,服务器应该总是允许客户端进行访问)

    客户端可以通过 OPTIONS 方法来查看服务器允许的访问方法, 如下

    1
    2
    > Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
    >

5XX 服务器错误

  • !!500 internal sever error,表示服务器端在执行请求时发生了错误

    图片摘取自HTTP图解

  • 501 Not Implemented,表示服务器不支持当前请求所需要的某个功能

  • 502 Bad Gateway,表明扮演网关或代理角色的服务器,从上游服务器中接收到的响应是无效的。(通常不是客户端能够修复的,而是需要由途径的 Web 服务器或者代理服务器对其进行修复)

  • !!503 service unavailable,表明服务器暂时处于超负载或正在停机维护,无法处理请求

图片摘取自HTTP图解

https

HTTPS 还是通过了 HTTP 来传输信息,但是信息通过 TLS 协议进行了加密。

对称加密:对称加密就是两边拥有相同的秘钥,两边都知道如何将密文加密解密。

非对称加密:有公钥私钥之分,公钥所有人都可以知道,可以将数据用公钥加密,但是将数据解密必须使用私钥解密,私钥只有分发公钥的一方才知道。

流程:首先服务端公钥公布出去,那么客户端也就知道公钥了。接下来客户端创建一个秘钥,然后通过公钥加密并发送给服务端服务端接收到密文以后通过私钥解密出正确的秘钥,这时候两端就都知道秘钥是什么了。

ssl握手过程

  1. 首先,客户端 访问 服务端 。这时候客户端 会生成一个随机数1,把随机数1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务端。
  2. 服务器 收到这些信息后,然后确认一下双方的加密算法,然后服务端也生成一个随机数 2 ,并将随机数 2 和 CA 颁发给自己的证书一同返回给客户端 A 。
  3. 客户端 得到 CA 证书后,会去校验该 CA 证书的有效性,校验通过后,客户端生成一个随机数 3 ,然后用证书中的公钥加密随机数 3 并传输给服务端 。
  4. 服务端 得到加密后的随机数 3,然后利用私钥进行解密,得到真正的随机数3。
  5. 最后,客户端 和 服务端 都有随机数1、随机数2、随机数3,然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密,一般用的都是 AES 算法。
  6. 客户端 通知 服务端 ,指明后面的通讯用对话密钥来完成,同时通知 服务端 握手过程结束。
  7. 服务端 通知 客户端 ,指明后面的通讯用对话密钥来完成,同时通知客户端 握手过程结束。
  8. SSL 的握手部分结束,SSL 安全通道的数据通讯开始,客户端 和服务端 开始使用相同的对话密钥进行数据通讯。

http2

在 HTTP/2 中引入了多路复用的技术(就是在一个 TCP 连接中可以存在多条流,对端可以通过帧中的标识知道属于哪个请求)。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题,可以避免 HTTP 旧版本中的队头阻塞问题,更容易实现全速传输。

代表着最小的数据单位,每个帧会标识出该帧属于哪个流,也就是多个帧组成的数据流。

在之前的 HTTP 版本中,我们是通过文本的方式传输数据。在 HTTP/2 中所有传输的数据都会被分割,并采用二进制格式编码

在 HTTP /2 中,使用了 HPACK 压缩格式对传输的 header 进行编码,减少了 header 的大小。并在两端维护了索引表,用于记录出现过的 header ,后面在传输过程中就可以传输已经记录过的 header 的键名,对端收到数据后就可以通过键名找到对应的值

因为 HTTP/2 使用了多路复用,一般来说同一域名下只需要使用一个 TCP 连接。出现丢包的情况下,整个 TCP 都要开始等待重传,也就导致了后面的所有数据都被阻塞了,导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。

QUIC

QUIC 虽然基于 UDP,但是在原本的基础上新增了很多功能,比如多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等等功能

多路复用

虽然 HTTP/2 支持了多路复用,但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能,并且传输的单个数据流可以保证有序交付且不会影响其他的数据流,这样的技术就解决了之前 TCP 存在的问题。

并且 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的,这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接,不管你网络环境如何变化,只要 ID 不变,就能迅速重连上。

纠错机制

假如说这次我要发送三个包,那么协议会算出这三个包的异或值并单独发出一个校验包,也就是总共发出了四个包。

当出现其中的非校验包丢包的情况时,可以通过另外三个包计算出丢失的数据包的内容。

0-RTT

通过使用类似 TCP 快速打开的技术,缓存当前会话的上下文,在下次恢复会话的时候,只需要将之前的缓存传递给服务端验证通过就可以进行传输了。

输入 URL 到页面渲染的整个流程

dns查询

  1. 操作系统会首先在本地缓存中查询 IP
  2. 没有的话会去系统配置的 DNS 服务器中查询
  3. 如果这时候还没得话,会直接去 DNS 根服务器查询,这一步查询会找出负责 com 这个一级域名的服务器
  4. 然后去该服务器查询 google 这个二级域名
  5. 接下来三级域名的查询其实是我们配置的,你可以给 www 这个域名配置一个 IP,然后还可以给别的三级域名配置一个 IP

接下来是 TCP 握手,应用层会下发数据给传输层,这里 TCP 协议会指明两端的端口号,然后下发给网络层。网络层中的 IP 协议会确定 IP 地址,并且指示了数据传输中如何跳转路由器。然后包会再被封装到数据链路层的数据帧结构中,最后就是物理层面的传输了。

TLS 的握手情况以及两种加密方式:http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

数据在进入服务端之前,可能还会先经过负责负载均衡的服务器,它的作用就是将请求合理的分发到多台服务器上。这时假设服务端会响应一个 HTML 文件。

首先浏览器会判断状态码是什么,如果是 200 那就继续解析,如果 400 或 500 的话就会报错,如果 300 的话会进行重定向,这里会有个重定向计数器,避免过多次的重定向,超过次数也会报错。

浏览器开始解析文件,如果是 gzip 格式的话会先解压一下,然后通过文件的编码格式知道该如何去解码文件。

文件解码成功后会正式开始渲染流程,先会根据 HTML 构建 DOM 树,有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话,会判断是否存在 async 或者 defer ,前者会并行进行下载并执行 JS,后者会先下载文件,然后等待 HTML 解析完成后顺序执行。

如果以上都没有,就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件,这里如果使用 HTTP/2 协议的话会极大的提高多图的下载效率。

CSSOM 树和 DOM 树构建完成后会开始生成 Render 树,这一步就是确定页面元素的布局、样式等等诸多方面的东西

在生成 Render 树的过程中,浏览器就开始调用 GPU 绘制,合成图层,将内容显示在屏幕上了。