HTTP

从输入URL地址，到看到页面，中间都经历了什么？

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

• 传输协议：http/https/ftp...
  

  • http超文本传输协议：除了传输文本之外，还可以传输图片,音频等富媒体资源
  • https：https+ssl 具备ssl证书加密的http传输，所以更安全，一般用于涉及支付类的网站
  • ftp文件传输协议：一般用于开发者把写好的代码部署到服务器上（例如：FireZilla）；或者公司内部的FTP资源共享服务器
  • 域名：IP地址：目的就是找到对应的服务器（每一台服务器都一样一个对应的唯一的外网IP地址）
  • 端口号：用来区分同一台服务器上的不同服务（不同项目）范围：0-65535
    • 默认端口号：用户自己不写，浏览器会自己加的
  • http协议：80；HTTPS协议：443；ftp协议：21；
  • 路径
  • ?传参
  • 哈希值

• URL编码问题：地址（含传参的数据）中出现中文等特殊符号，这样在传输中可能会出现乱码，此时我们需要事先进行编码

  • encodeURL/decodeURL针对整个URL地址中的特殊部分符号（不含URL地址的符号）和中文进行编码解码

  • encodeURLComponent/decodeURLComponenta针对URL的问号传参信息进行编码，它不仅可以把中文进行编码，类似于“；//&"也可以进行编码

  • escape/unescape也可以对中文和特事故符号进行编码，但是适用于客户端的不同页面之间，大部分后端语言中美哟有这个API，所以不适用于客户端和服务器之间的通信

    2.缓存检查（优化项）

• 优化项 针对第二次及其以后的访问进行优化

• 资源文件的缓存检查（HTML CSS JS 图片 音频等）=>半自动

  • 都是服务器设置缓存的规则，客户端和浏览器自动配合处理，无需前端写代码
  • 强缓存
    • Cache-Control，Expires
    • 不论是从服务器获取，还是从缓存中获取，HTTP状态码都是200，真是项目中，一般都是强缓存
    • 如何保证即便本地有缓存，但是如果服务器资源更新了，也会获取最新资源
      • html页面坚决不能做强缓存，因为他是一个页面渲染的入口
      • 每一次访问html都会从服务器获取最新资源
      • 在此访问页面，拿到的是最新的html页面，渲染后遇到新的问价请求，就不再本地缓存中查找了（本地没 缓存过），就从服务器获取
      • 真实项目中，除了html页面外，其余资源一般都需要设置强缓存

• 协商缓存

  • 协商缓存就是在强缓存失效（没设置或者过期）后的一个辅助操作
  • 不论本地是否有缓存，都要向服务器发送请，问问服务器当前资源是否更新
    • 服务器没更新：返回304状态码，客户在获取304后，从本地缓存中获取信息渲染
    • 服务器更新：返回200状态码，返回给客户最新的信息，以及在响应头中返回两个字段（Last-Modified（资源最后更新的时间）/ETag(时间最后一次更新的标识））；客户端渲染的同时把信息和标识储存起来

• 真实项目中，html页面设置协商缓存，其余的资源不论是否设置强缓存，协商也做一份

• 数据信息的缓存检查（AJAX数据请求），需要手动处理

• 依托于本地储存机制，对于不经常更新的数据，手动设置缓存，以此来减少客户端和服务器之间的通信频率

• 本地储存：把信息可以储存在客户端本地

  • cookie：document.cookie
    • 持久储存，但是需要设置过期时间，页面刷新或者页面关闭不影响，同源存储最多4Kb，一个字母是1b，存储稳定性方面，cookie不稳定，清除浏览器的历史记录，或者使用安全卫士清除垃圾，可能会清除cookie，浏览器的无痕浏览或者隐私模式下是禁止设置cookie的
  • localStorage.setltem/getltem/removeltem/clear...
    • 持久化储存：只要浏览器不卸载，不手动清除，信息会一直存着，即使刷新或者关闭页面
    • 同源最多存储5Mb
    • 稳定性：不会受模式的限制，也不会被随意清除，稳定性相对较好
    • localStorage和服务器没有关系，除非手动传输
  • sessionStorage：语法和locaStorage类似

    • 会话储存：页面刷新信息还在，但是页面一旦关闭，储存的消息会消失

    • cookie和服务器之间有猫腻：客户端只要有cookie信息，不论服务器是否需要，都会默认把基于请求头cookie传给服务器（跨域除外），这样有利有弊；弊端在于，cookie如果比较多，每次和服务器通信，都要携带大量的cookie信息，浪费性能。

  • 全局变量（vuex/redux）：把信息存储在虚拟内存中，页面刷新就消失了，存储周期短

  3.DNS解析：根据域名获取服务器的外网IP地址

• 去DNS服务器上，基于域名，找到服务器的外网ip。因为只有这样，后续才可以基于外网ip找到服务器

  • 在部署项目的时候会做域名解析，把域名和服务器外网ip的记录放在DNS服务器上

• 每一次DNS解析大概是20-120毫秒之间，如何优化

  • 理论上一个项目只有一个域名

  • 把所有的资源和后台程序等，都部署到相同的服务器的相同服务下

    • 这样做虽然虽然提高了域名的解析速度，但是真是项目不这样，因为所有资源都在一起，服务器压力太大

  • 真实项目部署的时候一般都是分服务器部署，所以涉及更多的域名解析

  • DNS Prefetch：DNS解析：浏览器的异步性，预先解析DNS，并且把记录缓存，后续需要这个域名的时候直接从缓存拿就行

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

• TCP：稳定可靠的传输协议（三次握手）

• UDP：（用于直播）快速的传输协议不需要三次握手，直接传输即可，但是不一定稳定

  5.HTTP传输

  • HTTP请求（request）请求报文
  • HTTP响应（reoponse）响应报文
  • HTTP事物：re
  • quest+response
  • 报文
    • 起始行
      • 请求起始行：请求方式，请求地址，HTTP版本
      • 响应起始行：HTTP版本 HTTP状态码 状态码描述
    • 首部（头）
      • 请求头：Repuest Headers：cintent-type connection host origin referer user-agent cookie if-modified-since if-none-match authorzation token x-token
      • 响应头：Response Headers:Data cache-control expires last-modified etag set-cookie
    • 主体
      • 请求主体：Payload 客户端一般只有在Post请求下，才会基于请求主体把信息传递给服务器
      • 响应主体：REsponse 服务器返给客户端的信息，一般都在响应体中
    • 善于使用NEXTWork观测，所有前后端交互的信息
  • 常用HTTP状态码
    • 200成功
    • 206断点续传
    • 301永久转移一般用在域名迁移
    • 302临时转移
    • 304协商缓存，服务器资源没更新，客户端从缓存中获取即可
    • 307临时重定向一般用于服务器的负载均衡
    • 400请求参数错误
    • 401无权限访问
    • 403请求出现问题，不告诉原因
    • 404请求地址错误
    • 405请求方式错误
    • 408请求超时
    • 以4开头的一般都是客户端存在的问题
    • 500未知的服务器错误
    • 503服务器超负荷
    • 以5开头的一般都是服务器的问题

  6.TCP的四次挥手：断开后和服务器之间的传输通道

  • 把建立好的通道关闭：在客户端把信息传递给服务器的同时，客户端发起了第一次挥手...当服务器把信息返回给客户端的时候，客户端需要再次告诉服务器，东西已经收到，我这边开始关闭，你也关闭吧
  • Connection:keep-alive 长连接机制（服务器端可以设置传输通道关闭的条件，例如：多少个请求后关掉，或者多久后关掉） 如果不设置长连接机制，则每次请求都要“三握四挥”，很浪费时间和性能！设置长连接机制后，可以保证一段时间内，建立的通道不会被关闭
  • HHTP/1.1版本及以后，默认就是Connection：keep-alive

  7：浏览器渲染解析

  DOM TREE
        CSSOM  TREE
        RENDER  TREE
        Layout
        分层
        Painting