从输入URL地址,到看到页面,中间都经历了啥？

不是張國荣
180 阅读9分钟

1.URL解析:解析出URL中各部分的规则,然后按照规则向服务器发送请求

  • 传输协议: http/https/ftp...
    • http超文本传输协议:除了传输文本之外,还可以传输图片、音视频等富文本媒体资源
    • https:http+ssl(证书加密协议) ||Tsl证书(比ssl更加安全) 具备ssl证书加密的http传输,所以更安全,一般用于涉及支付类的网站
    • ftp文件传输协议:一般用于开发者把写好的代码部署到服务器上[例如:FileZilla...]、或者公司内部的ftp资源共享服务器
  • 域名[ip地址]:目的就是找到对应的服务器(每一台服务器都有一个唯一的外网IP地址)
    • 域名的目的就是让用户好记一些,直接记外网IP地址就不是人干的事
  • 端口号:用来区分一台服务器上的不同服务(不同项目)的 取值范围0~65535之间
    • 默认端口号
      • http协议 -> 80
      • https协议 -> 443
      • ftp协议 -> 21 URL地址编码的问题:地址(含传参的信息)中出现中文等特殊符号，这样在传输中可能出现乱码，此时我们事先进行编码
  • encodeURL/decodeURL 针对于整个URL地址中的"中文及部分特殊符号(不含有url地址的符号)"进行编码
  • encodeComponent/decodeComponent:针对于"URL地址的问号传参信息" 进行编码 它不仅可以把中文进行编码，类似于 "://?&"这种特殊符号也可以编码...
  • escape/unescape:也可以对中文和部分特殊符号进行编码,适用于客户端的不同页面之间,很多服务器的语言不支持 这个API,所以不适合客户端和服务器之间的通信！！

=================================================

2.缓存检查[优化项]

  • 针对第二次以及以后的访问进行优化
  • 资源文件的缓存检查(HTML、CSS、JS、图片、音视频等) => 半自动 都是服务器端设置缓存的规则,客户端浏览器自动配合处理,无需前端写代码
    • 强缓存 cache-Control、Expires cache-Control优先级大于Expires
      • 不论是从服务器获取还是从服务器获取,HTTP状态码都是200
      • 如何保证即使本地有缓存,但是如果服务器资源更新了,也会获取最新的资源？ @1 HTML坚决不能做强缓存,因为它是一个页面渲染的入口 每一次访问,html都是从服务器获取最新的 @2 服务器代码一旦被更改,就会生成一个全新的文件(文件名是新的),并且在html中导入新的文件 @3 再次访问页面,拿到最新的html,渲染后遇到新的文件请求,就不在从本地缓存中查找(本地没有缓存过),从服务器获取 ----> 除了页面之外,所有资源都要设置强缓存
    • 协商缓存
      • 协商缓存是在强缓存失效或者未设置时的一个辅助操作
      • 整体流程,不论本地是否有缓存,都要项服务器发送器请求(把之前存储的last-Modified基于if-Modified-Since、Etag基于if-None-Match;通过请求头传递给服务器),
        • 问问服务器当前资源是否更新了？
        • 服务端没有更新:返回304状态码,客户端获取到304后,从本地缓存中获取信息渲染
        • 服务器没有更新:返回200状态码,返回客户端最新的信息,以及在响应头中返回的 Last-Modified(资源最后一次更新的时间)
          • /Etag(资源最后一次更新的标识),客户端渲染的同时把信息和标识存储起来 -------->真实项目中,html页面设置协商缓存,其余页面不论是否设置强缓存,协商缓存也做一份
  • 数据信息的缓存检查(AJAX数据请求) => 手动
    • 依托于本地存储的机制,对于不经常更新的数据,手动设置缓存,以此来减少客户端和服务端的通信频率！！ 本地存储方案:把信息存储在客户端本地的 application
      • cookie document.cookie
        • 持久存储,但是需要设置过期时间 [页面刷新或者关闭不影响]
        • 同源最多存储4kb
        • 存储稳定性cookie不稳定,清除浏览器的历史记录或者使用安全卫士清理垃圾 可能会清除cookie
          • 浏览器的隐私模式或者无痕模式是不允许设置cookie
        • cookie和浏览器之间有"猫腻",客户端只要有cookie信息,不论服务器是否需要,都会默认把其基于请求头
          • cookie字段传递给服务器(跨域请求除外);这样有利弊,弊处在于:cookie如果比较多,每次和服务器通信,都要携带大量cookie信息,浪费性能
      • localStorage localStorage:setItem/getItem/removeItem
        • 持久化存储:只要浏览器不卸载,不手动清除,信息就会消失
        • 存储大小:同源最多存储5mb
        • 稳定性:localStorage的存储不会受模式的限制,也不会被随意清除...所以稳定性很好
      • sessionStorage 语法和localStorage类似
        • 会话存储:页面刷新信息还在,但是页面一旦关闭,存储的信息就会消失
      • 全局变量:把信息存储在虚拟内存中,页面刷新就消失了 3.DNS解析:根据域名获取服务器和外网IP地址

去DNS服务器上,基于域名,找到服务器的外网IP,因为只有这样,后续才可以基于外网IP找到服务器 + 在部署项目的时候,我们自己会做域名解析：把域名和服务器外网IP的记录房子啊DNS服务器上 每一次DNS解析的时间大概在20~120ms之间 如何优化？ + 真实项目部署的时候,一般都是分服务器部署,所以涉及更多的域名解析 + DNS Prefatch:DNSt预解析[浏览器的异步性,预先解析DNS,并且把记录缓存,后续用到这个域名,直接从本地拿出来使用即可]

4.TCP的三次握手:建立客户端和服务端的稳定的数据传输通道

  • TC稳定可靠的传输协议[经历三次握手]

  • UDP:快速的传输协议[不需要三次握手 直接传输即可 但是不一定稳定]

  • 三次握手，客户端先向服务端发起一个SYN包，进入SYN_SENT状态，服务端收到SYN后，给客户端返回一个ACK+SYN包，表示已收到SYN，并进入SYN_RECEIVE状态，最后客户端再向服务端发送一个ACK包表示确认，双方进入establish状态。

  • 之所以是三次握手而不是两次，是因为如果只有两次，在服务端收到SYN后，向客户端返回一个ACK确认就进入establish状态，万一这个请求中间遇到网络情况而没有传给客户端，客户端一直是等待状态，后面服务端发送的信息客户端也接受不到了。

5.HTTP传输

  • http请求报文:客户端发送给服务端的东西
  • http响应报文:服务端返回给客户端的东西
  • http事物:request + response
  • 报文
    • 起始行
      • 请求起始行：请求方式 请求地址 http版本
      • 响应起始行:HTTP版本 HTTP状态码 状态码描述
    • 首部(头)
      • 请求头 Request
      • 响应头
    • 主体
      • 请求主体 Payload 客户端一般只有在POST系列请求下，才会基于请求主体把信息传递给服务器
      • 响应主体: Response 服务器返回给客户端的信息 一般都在响应主体中 -----------擅于使用NetWork观测 所有前后端交互的信息 常见HTTP状态码
    • 200 ok 成功
    • 206 Partial Content 断点续传
    • 301 Moved Permanently 永久转移[一般用在域名搬迁]
    • 302 Move Temporarily 临时转移
    • 304 Not Modified 协商缓存 服务器资源没有更新 客户端从缓存获取即可
    • 307 Temporary Redirect 临时重定向 [一般用于服务器的负载均衡]
    以4开头一般都是客户端的问题
    • 400 Bad Request 请求参数错误
    • 401 Unauthorized 无权限访问
    • 403 Forbidden 请求出现问题 但是就不告诉你为啥
    • 404 Not Found 请求地址错误
    • 405 Method Not Allowed 请求方式不被允许
    • 408 Request Timeout 请求超时
    以5开头一般都是服务器的问题
    • 500 Internal Server Error 未知的服务器错误
    • 503 Service Unavailable 服务器超负荷 6.TCP的四次握手:断开客户端和服务端之间的传输通道

目的:把建立好的传输通道关闭 在客户端把信息传递给服务器的时候 客户端就主动发起了第一次挥手 当服务器把信息返回给客户端的时候，客户端需要再次告知服务器 东西已经收到，我这边关闭通道，你也关闭吧。 Connection:keep-alive 常连接机制 [服务器端可以设置传输通道关闭的条件 例如:多少个请求后关闭 或者多久关闭] 如果不设置长连接 则每一次请求都要"三握四挥" 很浪费性能和时间！设置长连接后 可以保证在一段时间内,建立的通道不会被关闭 其余请求直接基于这个通道实现数据传输即可 加快传输的速度！！ HTTP/1.1版本及以后,默认就是Connection:keep-alive

  • 四次挥手，首先客户端向服务端发送一个FIN包，进入FIN_WAIT1状态，服务端收到后，向客户端发送ACK确认包，进入CLOSE_WAIT状态，然后客户端收到ACK包后进入FIN_WAIT2状态，然后服务端再把自己剩余没传完的数据发送给客户端，发送完毕后在发送一个FIN+ACK包，进入LAST_ACK（最后确认）状态，客户端收到FIN+ACK包后，再向服务端发送ACK包，在等待两个周期后在关闭连接

  • 之所以等待两个周期是因为最后客户端发送的ACK包可能会丢失，如果不等待2个周期的话，服务端在没收收到ACK包之前，会不停的重复发送FIN包而不关闭，所以得等待两个周期

7.浏览器渲染解析

  • DOM TREE
  • CSSOM TREE
  • RENSER TREE
  • LAYOUT
  • 分层
  • Painting
avatar
文章
阅读
粉丝