输入url到页面渲染的过程--前世

一曲肝肠寸断
240 阅读6分钟

从输入 url 到页面渲染发生了什么？

  1. 客户端发起 DNS 解析，得到服务端的 IP 地址
  2. TCP 的三次握手建立连接
  3. 发起 HTTP 请求，进行数据传输
  4. 浏览器获取到 html，css，js 这种资源
  5. TCP 的四次挥手，释放连接
  6. 浏览器会将HTML 解析成 DOM 树，CSS解析成CSSOM 树，在合成render 树
  7. 拿着 render 树去调用浏览器的 GUI 绘图功能，绘制出页面 （回流重绘）

UDP

UDP 和 TCP 的区别是什么？

  1. UDP 协议是面向无连接的，也就是说不需要在正式传递数据之前先建立双方的连接。
  2. UDP 只是数据报文的搬运工，不保证有序且不丢失的传递到对端
  3. UDP 没有任何控制流量的算法

UDP的特点

  • 面向无连接

    不需要在发送数据之前进行三次握手，想发数据就可以发送，不会对数据报文进行任何的拆分和拼接。

    发送端（数据）-> 应用层 -> 传输层 （UDP协议只会给数据增加一个UDP头标识）-> 网络层 接收端 -> 网络层（得到数据） -> 传输层（UDP去除报文头） -> 应用层

  • 不可靠性

    体现在无连接，想发就发

    接收到什么数据就传递什么数据，不会备份数据，也不会关心对方是否已经正确的接收到了数据

    没有拥塞控制，一直以恒定的速度发送数据，网络条件不好的时候，可能会造成数据包丢失

  • 高效

    UDP的头部开销小，只有8字节，而TCP有至少20个字节

  • 应用场景

    直播、视频通话、实时性游戏（王者荣耀、和平精英......）

TCP

TCP特点

  1. 传输之前需要建立连接
  2. 通过各种算法保证数据的有序且可靠传输
  3. 有拥塞控制

TCP头部字段包含哪些：

1. Sequence number： 序号，保证了数据都是有限的，接收端可以通过序号顺序拼接报文
2. Ackonwledgement number： 该序号表示接收端期望接收的下一字节的编号是多少，同时也表示上一个数据已经接收到了
3. window size： 窗口大小，表示还能接收多少字节数据，用于流量控制
4. 标识符： 
    · URG=1： 表示当前的数据包是紧急数据，那么该数据包一定位于当前传输的数据包的最前面
    · ACK=1： 表示确定当前数据有效
    · PSH=1： 表示接收端应该立即把当前的数据包交给应用层，而不是等到缓存区存满再提交
    · RST=1： 表示当前的TCP连接出现了严重问题，可能需要重新请求报文
    · SYN=1： 当SYN=1，ACK=0，表示当前报文段是一个请求报文，当SYN=1，ACK=1，表示当前报文是一个同意建立连接的应答报文
    · FIN=1： 表示当前报文段是一个释放链接的请求

三次握手

  1. 客户端向服务端发送连接请求报文，该报文段中包含自身的数据通讯初始序号，请求发送之后，客户端便进入 SYN-SENT 状态
  2. 服务端接收到连接请求报文后，如果同意连接，则会发送一个应答，该应答中包含自身的数据通讯初识序号，发送完后便进入到 SYN-RECEIVED 状态
  3. 客户端接收到连接应答后，还要向服务端发送一个确认接收到应答的报文，客户端便进入到 ESTABLISHED 状态，服务端接收到此应答后也进入到 ESTABLISHED 状态

为什么 TCP 建立连接需要三次握手，明明两次就可以建立连接？

假设客户端发送连接请求A，但是因为网络原因造成了超时这时 TCP 会启动超时重传机制，重新发一个连接请求B，此时请求B顺利到达服务端，服务端应答完成建立连接，然后接收数据完成后断开连接。假设这时请求A在两端关闭之后又抵达了服务端，那么此时服务端会认为客户端又需要建立连接，从此应答该请求进入SYN-RECEIVED状态，但是客户端其实是CLOSED状态，那么服务端就会一直等待，造成资源浪费。

四次挥手

  1. 客户端向服务端发送连接释放请求
  2. 服务端接收到连接释放请求后，会告诉应用层要释放TCP连接，然后应答该连接释放请求，服务端进入CLOSED_WAIT状态，此时服务端不再接收客户端发的数据了，但是此时服务端任然可以向客户端发数据
  3. 如果服务端还没有发完数据，会继续发送，完毕后会向客户端发送释放请求，自己便进入LAST_ACK状态
  4. 客户端接收到释放请求后，向服务端发送应答确认，此时客户端进入TIME_WAIT状态，该状态会持续 2MSL （报文在网络中生存的最大时间）时间，若该时间段内没有服务端的请求，就会进入到CLOSED状态。服务端接受到应答后也会进入CLOSED 状态。

为什么客户端要进入 TIME_WAIT状态，等待2MSTL 时间才进入CLOSED状态？

为了保证服务端能收到客户端的确认应答，如果客户端直接进入CLOSED状态，最后的确认应答万一因为网络问题没有送达，那么会造成服务端不能正常关闭。

http

  1. 请求行
  2. 首部（ header 请求头、响应头）
  3. 实体

首部

  • 通用首部

Cache-contrgol 控制缓存的行为

Date 创建报文的时间

Pragma 报文指令

Via 代理服务器的相关信息

Transfer- 传输编码方式

Connection 浏览器想要优先使用的连接类型

  • 请求的首部 Access 能正确接受的媒体类型

Access-Charset 能正确接受的字符集

Access-Encoding 能正确接受的编码格式

Host 服务器的域名

Accept-Language 能正确接受的语言

User-Agent 客户端信息

  • 响应的首部 Accept-Ranges 是否支持某种类型

Age 资源在代理缓存中存在的时间

Etag 资源标识 Location 客户端需要重定向去到某个url

实体

  • 实体首部

    Allow 资源的正常请求方式

    Expires 内容过期时间

    Content-Type 内容媒体类型

    Last_modified 内容最后的修改时间

状态码

TLS协议

https还是通过http协议来传输通信的，但是信息通过TLS协议进行了加密

TLS有两种加密方式：

  1. 对称加密：客户端和服务端两边拥有相同的密钥，两边都知道如何将密文加密和解密 缺点：通过网络传输密钥不安全

  2. 非对称加密：有公钥和私钥之分，公钥可以让所有人知道，用于数据加密，但是要解密数据必须使用私钥，私钥只有分发公钥的一方才知道 流程：假如A是服务端，B是客户端

  3. A创建公钥和私钥，将公钥发布出去让B知道

  4. B创建一个密钥，然后通过公钥加密这个密钥，并发送给A

  5. A通过私钥解密这个密钥

  6. 两端就都知道这个密钥了

avatar
文章
阅读
粉丝