前端2-浏览器HTTP

caizy
84 阅读9分钟

  • 二、浏览器HTTP\

    • ✔2.1 浏览器输入URL发生了什么\

      • URL解析（判断合法性，然后解析URL结构）\
      • DNS 解析\
      • TCP 连接（三次握手建立TCP 连接）\
      • HTTP 请求（开始通信）\
      • 响应请求\
      • 页面渲染\

    • ✔DNS解析\

      • 过程：\

        • 先检查浏览器缓存和主机本地文件里有没有记录，有则返回\
        • 1.发送解析请求（浏览器=>解析器DNS客户端）\
        • 2.发送解析请求（解析器=>本地DNS服务器）本地DNS服务器查看自己的缓存，有则返回\
        • \
        • 3.查询根（。）（本地DNS服务器=>根域名服务器）\
          1. com服务器地址（根域名服务器=>本地DNS服务器）\
        • \
        • 5.咨询com（本地DNS服务器=>com域名服务器）\
          1. baidu.com网站服务器地址（com域名服务器=>本地DNS服务器）\
        • \
        • \
        • 9.IP（本地DNS服务器=>解析器）\
        • 10.IP（解析器DNS客户端=>浏览器）\
      • 本地DNS服务器和解析器DNS客户端之间是递归传输\
      • 本地DNS服务器和各种域名服务器之间是迭代传输\

    • ✔三次握手 四次挥手\

      • 1.三次握手概念：\

        • 三次握手在其建立TCP连接的时候\
        • 第一次握手：客户端向服务器发起的，用来申请建立连接（报文当中的SYN标志会标记为1，所以也叫做SYN包）\
        • 第二次握手：服务器回复客户端的，用来确认并接收连接请求（报文当中的SYN位和ACK位都会标记为1，所以也叫做SYN-ACK报文）\
        • 第三次握手：客户端向服务器发起的，用来确认服务器的回复消息（报文当中的ACK标志会标记为1，所以也叫做ACK包）\

      • 2.四次挥手概念：\

        • TCP协议完成数据发送后会断开连接，经历四个挥手\
        • 第一次挥手：客户端向服务器，申请断开连接（FIN标志位会标记为1，所以叫做FIN包）\
        • 第二次挥手：服务器回复客户端，用来确认客户端的上一个断开连接请求的（ACK报文）\
        • 第三次挥手：服务器发送给客户端，用来告知客户端 服务器的数据发送完毕 需要断开连接（FIN标志位会标记为1，是FIN包）\
        • 第四次挥手：客户端回复服务器，用来确认服务器的上一个断开连接的请求（ACK报文）\

      • 为什么需要三次握手？\

        • 因为TCP/IP不可靠，为了在不可靠建立起一种可靠传输，必须要有握手确认机制。\

      • 为什么是三次？\

        • 因为TCP是全双工协议，需要通信双方同时通信。最少需要三次双向确认\

    • ✔2.2浏览器如何渲染页面的？\

      • 细节：\

        • 1.请求服务器得到HTML文件，构建DOM\
        • 2.遇到link标签，请求服务器得到CSS文件，构建CSSOM\
        • 3.请求JS，返回JS，运行JS\
        • 4.构建渲染树，布局和绘制\

      • 总结：\

        • 1.构建DOM\
        • 2.构建CSSOM\
        • 3.构建渲染树，布局和绘制\
      • 重点：必须等到CSSOM构建完成了才能执行JS文件\

    • ✔2.3 回流 重绘\

      • 回流（reflow）\

        • 渲染树中的一部分(或全部)因为元素的规模尺寸，布局，隐藏等改变而需要重新构建DOM树\
        • 引起Dom树结构变化，改变页面布局\

      • 重绘（repaint）\

        • 渲染树中的一些元素需要更新属性，而这些属性只是影响元素的外观，风格，而不会影响布局。比如颜色\
        • 不会引起Dom树变化及页面布局变化，只重新渲染页面样式\
      • 两者区别：回流必将引起重绘，而重绘不一定会引起回流。比如：只有颜色改变的时候就只会发生重绘而不会引起回流\

    • ✔2.4 HTTP的 强制缓存 和 协商缓存\

      • HTTP强制缓存：\

        • 不会向服务器发送请求，直接从缓存中读取资源，请求返回状态码为 200\
        • 强制缓存时，服务端会在 Response Headers 中的 cache-control 对缓存时间、缓存方式等进行定义\
        • 技术核心是如何知道当前时间是否超过过期时间\

      • HTTP协商缓存：\

        • 向服务器发送请求，服务器会根据这个请求的 Request Headers 的一些参数(etag 和 last-modified)来判断是否命中协商缓存，如果命中，则返回 304 状态码, 并带上新的 Request Headers 通知浏览器从缓存中读取资源\
        • 协商缓存主要表现在 Response Headers 中的 etag 和 last-modified\

      • 二者区别：\

        • 状态码200与304\
        • 强缓存不发送请求到服务器\
        • 协商缓存发送请求到服务器，通过服务器来告知缓存是否可用\

    • ✔2.5 cookies、localStorage、sessionStorage\

      • 大小：4kb、10mb、5mb\
      • 兼容：H4/H5、H5、H5\
      • 访问：任何窗口、任何窗口、同一窗口\
      • 有效期：手动设置、无、到窗口关闭\
      • 存储位置：浏览器和服务器、浏览器、浏览器\
      • 与请求一起发送：是、否、否\
      • 语法：复杂、简易、简易\

    • ✔2.6 session、cookie、token\

      • session\

        • session是诞生并保存在服务器的\
        • 由服务器主导一切\

      • cookie\

        • 而cookie则是一种数据载体，把session放在cookie中送到客户端那边\
        • cookie跟随着每个HTTP请求发送出去\

      • token\

        • token是诞生在服务器，但保存在浏览器这边的\
        • 由客户端主导一切\
        • 可以放在cookie或者storage里，持有token就像持有“令牌”一样可以允许访问服务器\

    • ✔2.7 fetch vs axios\

      • 两者区别：\

        • fetch是低层次的API，浏览器原生支持的；其缺点是需要封装\
        • axios是一个封装好的框架\

      • fetch：\

        • 优点：\

          • 浏览器级别原生支持的api\
          • 原生支持promise API\
          • 语法简洁，符合 ES 标准规范\
          • 由whatwg组织提出，现在已经是w3c规范\

        • 缺点：\

          • 1.不支持文件上传进度监测\
          • 2.默认不带cookie\
          • 3.不支持请求终止\
          • 4.使用不完美，需要封装\

      • axios：\

        • 1.支持浏览器与nodejs前后端发送请求\
        • 2.支持promise语法\
        • 3.支持自动解析json\
        • 4.支持中断请求\
        • 5.支持拦截请求\
        • 6.支持进度条检测\
        • 7.支持客户端防止CSRF\
      • fetch概念：fetch是用来取代传统的AJAX的。 它的优点很多，包括链式调用的语法、返回promise等。\

      • 什么是fetch？\

        • fetch api是基于promise的设计，它是为了取代传统xhr的不合理的写法而生的。\
      • fetch方法的返回是一个Promise类型的对象\
      • ajax请求写起来非常混乱，但使用fetch链式调用后使用箭头函数更简洁\

    • ✔2.8 浏览器多页签通讯实现\

      • websocket协议\

        • webSoket用来实现双向通信，客户端和服务端实时通信。\

        • webSoket优点和缺点：\

          • 优点：对于前端来说，使用简单，功能灵活，如果部署了webSocket服务器，可以实现实时通信。\
          • 缺点：需要服务端技术的支持，如果websocket数据量比较大的话，会严重消耗服务器的资源。\

      • localstorage、cookie\

        • localstorage是浏览器多个标签共用的存储空间，所以可以用来实现多标签之间的通信\

      • SharedWorker(HTML5新特性)\

        • SharedWorker可以被多个window共同使用，但必须保证这些标签页都是同源的(相同的协议，主机和端口号)\

    • ✔2.9 前端安全相关-XSS和CSRF\

      • 跨站脚本攻击（XSS）恶意Script代码\

        • 恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页面时，嵌入其中的Script代码会被执行，从而达到恶意攻击用户的目的。\
        • 存储型XSS\
        • 反射型XSS\
        • DOM型XSS\

      • 跨站请求伪造（CSRF）在用户不知情的情况下携带Cookie信息\

        • 用户未退出网站A之前，同一个浏览器中又打开一个TAB页访问了黑客的网站B\
        • 网站B收到用户请求后，返回一些攻击代码（调用网站A的接口）\
        • 浏览器接收到攻击代码后，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道请求其实是网站B发起的，所以执行了网站B的恶意代码。\

    • ✔2.10跨域问题\

      • 不同源的资源进行交互，就需要跨域技术\

      • 为什么在script标签引用别的源不会有跨域问题？\

        • 因为在设计script标签时，就允许在别的源请求脚本\

      • JSONP概念：\

        • jsonp的核心原理就是目标页面回调本地页面的方法,并带入参数\
        • jsonp是为跨域而生的\
        • 我们可以使用script来帮助我们跨域\

      • CORS概念：\

        • CORS的核心简单来说就是设置头部Access-Control-Allow-Origin\
        • 比JSONP简单多了，不过要注意兼容问题\

    • ✔2.11 HTTP响应\

      • 1XX：信息性状态码、接收的请求正在处理\
      • 2XX：成功状态码、请求正常处理完毕\
      • 3XX：重定向状态码、需要进行附加操作已完成请求\
      • 4XX：客户端错误状态码、服务器无法处理请求\
      • 5XX：服务器错误状态码、服务器处理请求出错\

    • ✔2.12 http（http1.x 和http2.x）和https\

      • http是应用层协议。\

      • http1.x 和http2.x\

        • HTTP 1.x是文本协议\
        • HTTP 2.0是二进制协议\
      • HTTP协议以明文方式发送内容，不提供任何方式的数据加密\
      • HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议\

      • 两者区别：\

        • 1.https协议需要到CA申请证书\
        • 2.http是超文本传输协议，信息是明文传输；https则是具有安全性的ssl/tls加密传输协议。\

    • 非对称加密和对称加密（web3.0）\

      • 非对称加密：一堆密钥由公钥和私钥组成，私钥公钥可以相互加密解密\

        • 优点：速度快\
        • 缺点：不安全\

      • 对称加密：双方使用同一个密匙，既可以加密又可以加密\

        • 优点：安全\
        • 缺点：速度慢\

      • 二者区别：\

        • 对称加密的效率要高得多。但密缺陷在密钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。在实际中会将两者混合使用\
    • 完整的非对称加密过程\
avatar
文章
阅读
粉丝