21届秋招前端面经 -- 兴业数金

JS事件流

事件流描述的是从页面中接收事件的顺序。
事件发生时会在元素节点之间按照特定的顺序传播,这个传播过程即 DOM 事件流。
比如我们给一个div 注册了点击事件:

DOM 事件流分为3个阶段:

  1. 捕获阶段
  2. 当前目标阶段
  3. 冒泡阶段
  4. [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6E6KeKJ0-1603002965026)(9AF089E85BBD406591CFAF4C27772DF5)]
  • 事件冒泡: IE 最早提出,事件开始时由最具体的元素接收,然后逐级向上传播到到 DOM 最顶层节点的过程。

  • 事件捕获: 网景最早提出,由 DOM 最顶层节点开始,然后逐级向下传播到到最具体的元素接收的过程。

同步和异步

同步

​ 所有的操作都做完,才返回给用户。这样用户在线等待的时间太长,给用户一种卡死了的感觉(就是系统迁移中,点击了迁移,界面就不动了,但是程序还在执行,卡死了的感觉)。这种情况下,用户不能关闭界面,如果关闭了,即迁移程序就中断了。

​ 同步,是所有的操作都做完,才返回给用户结果。即写完数据库之后,再响应用户,用户体验不好。

异步
将用户请求放入消息队列,并反馈给用户,系统迁移程序已经启动,你可以关闭浏览器了。然后程序再慢慢地去写入数据库去。这就是异步。但是用户没有卡死的感觉,会告诉你,你的请求系统已经响应了。你可以关闭界面了。

​ 异步,不用等所有操作都做完,就相应用户请求。即先响应用户请求,然后慢慢去写数据库,用户体验较好。

ES6 let var const

  1. 使用 var 声明的变量,其作用域为该语句所在的函数内,且存在变量提升现象。
  2. 使用 let 声明的变量,其作用域为该语句所在的代码块内,不存在变量提升。
  3. 使用 const 声明的是常量,在后面出现的代码中不能再修改该常量的值。
    const实际上保证的,并不是变量的值不得改动,而是变量指向的那个内存地址所保存的数据不得改动。对于简单类型的数据(数值、字符串、布尔值),值就保存在变量指向的那个内存地址,因此等同于常量。但对于复合类型的数据(主要是对象和数组),变量指向的内存地址,保存的只是一个指向实际数据的指针,const只能保证这个指针是固定的(即总是指向另一个固定的地址),至于它指向的数据结构是不是可变的,就完全不能控制了。如果真的想将对象冻结,应该使用Object.freeze方法。

Http工作过程

HTTP通信机制是在一次完整的 HTTP 通信过程中,客户端与服务器之间将完成下列7个步骤:

  1. 建立 TCP 连接
    在HTTP工作开始之前,客户端首先要通过网络与服务器建立连接,该连接是通过 TCP 来完成的,该协议与 IP 协议共同构建 Internet,即著名的 TCP/IP 协议族,因此 Internet 又被称作是 TCP/IP 网络。HTTP 是比 TCP 更高层次的应用层协议,根据规则,只有低层协议建立之后,才能进行高层协议的连接,因此,首先要建立 TCP 连接,一般 TCP 连接的端口号是80;
  2. 客户端向服务器发送请求命令
    一旦建立了TCP连接,客户端就会向服务器发送请求命令;
    例如:GET/sample/hello.jsp HTTP/1.1
  3. 客户端发送请求头信息
    客户端发送其请求命令之后,还要以头信息的形式向服务器发送一些别的信息,之后客户端发送了一空白行来通知服务器,它已经结束了该头信息的发送;
  4. 服务器应答
    客户端向服务器发出请求后,服务器会客户端返回响应;
    例如: HTTP/1.1 200 OK
    响应的第一部分是协议的版本号和响应状态码
  5. 服务器返回响应头信息
    正如客户端会随同请求发送关于自身的信息一样,服务器也会随同响应向用户发送关于它自己的数据及被请求的文档;
  6. 服务器向客户端发送数据
    服务器向客户端发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以 Content-Type 响应头信息所描述的格式发送用户所请求的实际数据;
  7. 服务器关闭 TCP 连接
    一般情况下,一旦服务器向客户端返回了请求数据,它就要关闭 TCP 连接,然后如果客户端或者服务器在其头信息加入了这行代码 Connection:keep-alive ,TCP 连接在发送后将仍然保持打开状态,于是,客户端可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。

HTTP协议报文

​ http协议报文包括请求报文和响应报文。

一个HTTP请求报文由四个部分组成:请求行、请求头部、空行、请求数据。
在这里插入图片描述

​ 1.请求行:由请求方法字段、URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔。

​ 2.请求头部:HTTP客户程序(例如浏览器),向服务器发送请求的时候必须指明请求类型(一般是GET或者 POST)。

​ 3.空行:它的作用是通过一个空行,告诉服务器请求头部到此为止。

​ 4.请求数据:若方法字段是GET,则此项为空,没有数据;若方法字段是POST,则通常来说此处放置的就是要提交的数据。

  • HTTP请求报文
    • GET:通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。

    • HEAD:与 GET 方法的行为很类似,但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下,对资源的首部进行检查。使用 HEAD,可以:在不获取资源的情况下了解资源的情况(比如,判断其类型);

      • 通过查看响应中的状态码,看看某个对象是否存在;
      • 通过查看首部,测试资源是否被修改了。
    • PUT:与 GET 从服务器读取文档相反,PUT 方法会向服务器写入文档。PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档,或者,如果那个 URL 已经存在的话,就用这个主体来替代它。因为 PUT 允许用户对内容进行修改,所以很多 Web 服务器都要求在执行 PUT 之前,用密码登录。

      • 和POST方法一样,PUT方法也改变了资源的状态,所以是 非安全 的。但是有一点和POST不同,它是 幂等 的,这是为什么呢?想想setter函数吧,重复调用,只要参数是一样的,表述就是不变的。
    • POST:起初是用来向服务器输入数据的。实际上,通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器,然后由服务器将其发送到它要去的地方(比如,送到一个服务器网关程序中,然后由这个程序对其进行处理)。

      注: POST 用于向服务器发送数据。PUT 用于向服务器上的资源(例如文件)中存储数据。

    • TRACE:客户端发起一个请求时,这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在 最终将请求发送给服务器时,看看它变成了什么样子。

      • TRACE 请求会在目的服务器端发起一个 环回 诊断。行程最后一站的服务器会弹回一条 TRACE 响应,并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上,原始报文是否,以及如何被毁坏或修改过。
      • TRACE 方法主要用于诊断;也就是说,用于验证请求是否如愿穿过了请求 / 响应链。它也是一种很好的工具,可以用来查看代理和其他应用程序对用户请求所产生效果。
      • 缺点:它假定中间应用程序对各种不同类型请求(不同的方法——GET、HEAD、POST 等)的处理是相同的。 很多 HTTP 应用程序会根据方法的不同做出不同的事情——比如,代理可能会将 POST 请求直接发送给服务器,而将 GET 请求发送给另一个 HTTP 应用程序(比如 Web 缓存)。TRACE 并不提供区分这些方法的机制。通常,中间应用程序会自行决定对 TRACE 请求的处理方式。
      • TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本。
      • 当 TRACE 请求到达目的服务器时,16 整条请求报文都会被封装在一条 HTTP 响应的主体中回送给发送端。当 TRACE 响应到达时,客户端可以检查服务器收到的确切报文,以及它所经过的代理列表(在 Via 首部)。TRACE 响应的 Content-Typemessage/http,状态为 200 OK
    • Via:首部字段列出了与报文途经的每个中间节点(代理或网关)有关的信息。报文每经过一个节点,都必须将这个中间节点添加到 Via 列表的末尾。

      • 代理也可以用 Via: 首部来检测网络中的路由循环。代理应该在发送一条请求之前, 在 Via 首部插入一个与其自身有关的独特字符串,并在输入的请求中查找这个字符串,以检测网络中是否存在路由循环。
      • Via 首部字段包含一个由逗号分隔的 路标(waypoint)。每个路标都表示一个独立的 代理服务器或网关,且包含与那个中间节点的协议和地址有关的信息。下面是一个 带有两个路标的 Via 首部实例:
      Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.net
      
      • Via 首部的正规语法如下所示
      Via = "Via" ":" 1#( waypoint )
      waypoint = ( received-protocol received-by [ comment ] ) 
      received-protocol = [ protocol-name "/" ] protocol-version 
      received-by = ( host [ ":" port ] ) | pseudonym
      

      注意:

      每个 Via 路标中最多包含 4 个组件:一个可选的协议名(默认为 HTTP)、一 个必选的协议版本、一个必选的节点名和一个可选的描述性注释。

    • OPTIONS:OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法,或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作)。

    • Allow首部:Allow 实体首部字段列出了请求 URI 标识的资源所支持的方法列表,如果请求 URI为 * 的话,列出的就是整个服务器所支持的方法列表。例如:

      Allow: GET, HEAD, PUT
      
      • 可以将 Allow 首部作为请求首部,建议在新的资源上支持某些方法。并不要求服务 器支持这些方法,但应该在相应的响应中包含一个 Allow 首部,列出它实际支持的方法。因为客户端可能已经通过其他途径与原始服务器进行了交流,所以即使代理无法理解指定的所有方法,也不能对 Allow 首部字段进行修改。
    • DELETE:请服务器删除请求 URL 所指定的资源。 但是,客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务 器在不通知客户端的情况下撤销请求。

      • 和POST方法一样,DELETE方法也改变了资源的状态,所以是非安全的。但是有一点和POST不同,它是幂等的,也就是说,就算是服务器在前一个请求中已经删除了资源,它也必须返回200。这就意味着,我们在实现服务端的该方法是,需要跟踪已经删除的资源,否则就会返回404的。
    • CONNECT:是HTTP/1.1协议预留的,能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。

    • PATCH:出现较晚,它在2010年被定义。PATCH请求与PUT请求类似,同样用于资源的更新。二者有以下两点不同:

      • 但PATCH一般用于资源的部分更新,而PUT一般用于资源的整体更新。
      • 当资源不存在时,PATCH会创建一个新的资源,而PUT只会对已在资源进行更新。
  • 常见的HTTP报文头属性
    • Accpet:告诉服务端,客户端接收什么类型的响应
    • Referer:表示这是请求是从哪个URL进来的,比如想在网上购物,但是不知道选择哪家电商平台,你就去问度娘,说哪家电商的东西便宜啊,然后一堆东西弹出在你面前,第一给就是某宝,,当你从这里进入某宝的时候,这个请求报文的Referer就是www.baidu.com
    • Cache-Control:对缓存进行控制,如一个请求希望响应的内容在客户端缓存一年,或不被缓可以通过这个报文头设置
    • Accept-Encoding:这个属性是用来告诉服务器能接受什么编码格式,包括字符编码,压缩形式(一般都是压缩形式),例如:Accept-Encoding:gzip, deflate(这两种都是压缩格式)
    • Host:指定要请求的资源所在的主机和端口
    • User-Agent 作用:告诉服务器,客户端使用的操作系统、浏览器版本和名称

HTTP响应报文也由三部分组成:响应行、响应头、响应体
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-44vMSzcx-1603002965033)(5E1C55C3DA0A42B7B51A2A5AB625F271)]

​ 1.响应行:一般由协议版本、状态码及其描述组成

​ 2.响应头:用于描述服务器的基本信息,以及数据的描述,服务器通过这些数据的描述信息,可以通知客户端如何处理等一会儿它回送的数据。

​ 3.响应体:就是响应的消息体,如果是纯数据就是返回纯数据,如果请求的是HTML页面,那么返回的就是HTML代码,如果是JS就是JS代码,如此之类。

  • 响应码:

    • 1XX:临时响应,由于 HTTP/1.0 协议中没有定义任何 1xx状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送 1xx 响应。
    • 2XX:代表请求已成功被服务器接收、理解、并接受。
    • 3XX:这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的 Location 域中指明。
    • 4XX:这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。
    • 5XX:这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。
  • 常见响应码:

    • 200 OK 表示成功
    • 303 重定向,把你重定向到其他页面
    • 304 资源并未修改,可以直接使用本地的缓存
    • 404 找不到页面(页面被删除或其他)
    • 500 服务端错误
  • 常见HTTP响应报文属性

    • Cache-Control:响应输出到客户端后,服务端通过该属性告诉客户端该怎么控制响应内容的缓存
      • 可缓存性:

        • public (HTTP 返回的时候在Heaher 中设置Cache-Control 的值为‘public’。它代表,这个HTTP 请求它返回的内容所经过的任何路径中,包括中间的一些HTTP 代理服务器以及发出请求的客户端浏览器,都可以进行对返回内容的缓存操作)
        • private (发起请求的浏览器才能使用返回数据的缓存)
        • no-cache (可以在本地或者proxy服务器进行缓存,每次发起请求都要去服务器验证,服务器返回可以使用缓存,才可以真正使用本地缓存,任何节点都不能直接使用缓存)
      • 到期(缓存的有效期)

        • max-age= (最常用)
        • s-maxage=(只有在代理服务器才会生效,且代理服务器会优先使用s-maxage)
        • max-stale= (它是发起请求方,主动去带着的header;在max-age过期后,但还在max-stale的有效期内,还可以使用过期的缓存,不需要去原服务器请求新的内容)
      • 重新验证(不常用)

        • must-revalidate (它的意思是:当我们设置了 max-age ,过期后,我们必须去原服务端发送请求,重新获取数据,验证是否缓存过期,而不能直接去使用本地的缓存)
        • proxy-revalidate (与must-revalidate 相似,proxy-revalidate 是用在缓存服务器中,如果缓存服务器中的数据过期的话,需要去原服务器发送请求…)
    • ETag:表示你请求资源的版本,如果该资源发生啦变化,那么这个属性也会跟着变
    • Location:在重定向中或者创建新资源时使用
    • Set-Cookie:服务端可以设置客户端的cookie

Ajax

Ajax(异步 JavaScript 和 XML),是指一种创建交互式、快速动态网页应用的网页开发技术,无需重新加载整个网页的情况下,能够更新部分网页的技术。

通过在后台与服务器进行少量数据交换,Ajax 可以使网页实现异步更新。这意味着可以在不重新加载整个网页的情况下,对网页的某部分进行更新。

WebSocket的实现和应用

(1)什么是WebSocket?

WebSocket是HTML5中的协议,支持持久连续,http协议不支持持久性连接。Http1.0和HTTP1.1都不支持持久性的链接,HTTP1.1中的keep-alive,将多个http请求合并为1个

(2)WebSocket是什么样的协议,具体有什么优点?

HTTP的生命周期通过Request来界定,也就是Request一个Response,那么在Http1.0协议中,这次Http请求就结束了。在Http1.1中进行了改进,是的有一个connection:Keep-alive,也就是说,在一个Http连接中,可以发送多个Request,接收多个Response。但是必须记住,在Http中一个Request只能对应有一个Response,而且这个Response是被动的,不能主动发起。

WebSocket是基于Http协议的,或者说借用了Http协议来完成一部分握手,在握手阶段与Http是相同的。我们来看一个websocket握手协议的实现,基本是2个属性,upgrade,connection。

基本请求如下:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

多了下面2个属性:

Upgrade:webSocket
Connection:Upgrade

告诉服务器发送的是websocket

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

猜你喜欢

转载自blog.csdn.net/Guoxuxinwen/article/details/109144776