山月在年前的大厂面试

今天药忘吃喽~ 2022-10-26 12:43 93阅读 0赞

年前面试据说是一年中最好通过面试的时候，这个时候面试的人少，加之岗位急，供需关系决定比以往更容易拿一个不错的工资。

趁着这几天结束了几月的旅行，在家没事，恰好有充分的时间，面了几家大厂。最终也有几家拿了 Offer，再接再厉，最近有面试的同学也可以与我交流。

总结题目如下(链接在左下角原文打开)

## 01 如何实现一个元素的水平垂直居中 ##

> 在 Issue 或者我的网站中交流与讨论: 01 如何实现一个元素的水平垂直居中

提供一个较少提过的方法，使用 `grid`，它是做二维布局的，但是只有一个子元素时，一维布局与二维布局就一样了。结合 `justify-content`/`justify-items` 和 `align-content/align-items` 就有四种方案

效果可以见 codepen

.container {
      display: grid;
      justify-content: center;
      align-content: center;
    }

.container {
      display: grid;
      justify-content: center;
      align-items: center;
    }

.container {
      display: grid;
      justify-items: center;
      align-content: center;
    }

.container {
      display: grid;
      justify-items: center;
      align-items: center;
    }

## 02 css 如何实现左侧固定300px，右侧自适应的布局 ##

> 在 Issue 或者我的网站中交流与讨论: 02 css 如何实现左侧固定300px，右侧自适应的布局

使用 `flex` 布局，左侧 `300px`，右侧 `flex-grow: 1`。`pug` 代码及 `css` 代码示例如下

.container
      .left
      .main

.container {
      display: flex;
    }
    
    .left {
      flex-basis: 300px;
    }
    
    .main {
      flex-grow: 1;
    }

此处看起来比较圆满了，其实还有一个缺陷: **如果 .main 区域过大挤压 .left 区域怎么办**，此时还需要加一个禁止挤压

.left {
      flex-basis: 300px;
      flex-shrink: 0;
    }

### 总结 ###

使用 `flex` 进行如下布局

.container
      .left
      .main

.container {
      display: flex;
    }
    
    .left {
      flex-basis: 300px;
      flex-shrink: 0;
    }
    
    .main {
      flex-grow: 1;
    }

## 03 http 状态码 502 和 504 有什么区别 ##

> 在 Issue 或者我的网站中交流与讨论: 03 http 状态码 502 和 504 有什么区别

这两种异常状态码都与网关 Gateway 有关，首先明确两个概念

*  Proxy (Gateway)，反向代理层或者网关层。在公司级应用中一般使用 Nginx 扮演这个角色
 *  Application (upstream serrver)，应用层服务，作为 Proxy 层的上游服务。在公司中一般为各种语言编写的服务器应用，如 Go/Java/Python/PHP/Node 等

此时关于 502 与 504 的区别就很显而易见

*  `502 Bad Gateway`。一般表现为你自己写的应用层服务(Java/Go/PHP)挂了，网关层无法接收到响应
 *  `504 Gateway Timeout`。一般表现为应用层服务 (upstream) 超时，如查库操作耗时十分钟，超过了 Nginx 配置的超时时间

## 04 如何使用 react hooks 实现 useFetch 请求数据 ##

> 更多描述: 比如设计成 \`useFetch\` 这种形式，它的 API 应该如何设计

> 在 Issue 或者我的网站中交流与讨论: 04 如何使用 react hooks 实现 useFetch 请求数据

可以参考 How to fetch data with React Hooks?

## 05 react 如何使用 render prop component 请求数据 ##

> 在 Issue 或者我的网站中交流与讨论: 05 react 如何使用 render prop component 请求数据

参考: https://www.robinwieruch.de/react-fetching-data\#how-to-fetch-data-in-render-props

## 06 什么是 virtual DOM，它的引入带了什么好处 ##

> 在 Issue 或者我的网站中交流与讨论: 06 什么是 virtual DOM，它的引入带了什么好处

数据与UI的进一步分离，这样也更有利于 SSR

## 07 http 服务中静态文件的 Last-Modified 是根据什么生成的 ##

> 在 Issue 或者我的网站中交流与讨论: 07 http 服务中静态文件的 Last-Modified 是根据什么生成的

一般会选文件的 `mtime`，表示文件内容的修改时间

`nginx` 也是这样处理的，源码见: ngx\_http\_static\_module.c

r->headers_out.status = NGX_HTTP_OK;
        r->headers_out.content_length_n = of.size;
        r->headers_out.last_modified_time = of.mtime;

关于为什么使用 `mtime` 而非 `ctime`，可以参考 \#116

## 08 localhost:3000 与 localhost:5000 的 cookie 信息是否共享 ##

> 在 Issue 或者我的网站中交流与讨论: 08 localhost:3000 与 localhost:5000 的 cookie 信息是否共享

共享

## 09 http 响应头中如果 content-type 为 application/octet-stream，则代表什么意思 ##

> 在 Issue 或者我的网站中交流与讨论: 09 http 响应头中如果 content-type 为 application/octet-stream，则代表什么意思

代表二进制流，一般用以下载文件

## 10 http 响应头中的 Date 与 Last-Modified 有什么不同，网站部署时需要注意什么 ##

> 在 Issue 或者我的网站中交流与讨论: 10 http 响应头中的 Date 与 Last-Modified 有什么不同，网站部署时需要注意什么

*  `Date`: 报文在源服务器的产生时间，由此可查看报文已缓存了多久时间
 *  `Last-Modified`: 源服务器上资源的上次修改时间

`LM-Factor` 与它俩有关。

简而言之，一个静态资源没有设置 `Cache-Control` 时会以这两个响应头来设置强制缓存时间：`(Date - LastModified) * n`，而非直接进行协商缓存。在涉及到 CDN 时，表现更为明显，体现在更新代码部署后，界面没有更新。

## 11 http 1.1 中的 keep-alive 有什么作用 ##

> 在 Issue 或者我的网站中交流与讨论: 11 http 1.1 中的 keep-alive 有什么作用

在 `http 1.1` 中，在响应头中设置 `keep-alive` 可以在一个 TCP 连接上发送多个 http 请求

1.  避免了重开 TCP 连接的开销
2.  避免了刷新时重新建立 SSL 连接的开销
3.  避免了QPS过大时，服务器的连接数过大

在服务器端使用响应头开启 `keep-alive`

Connection: Keep-Alive
    Keep-Alive: timeout=5, max=1000

## 12 如果使用 SSR，可以在 created/componentWillMount 中访问 localStorage 吗 ##

> 在 Issue 或者我的网站中交流与讨论: 12 如果使用 SSR，可以在 created/componentWillMount 中访问 localStorage 吗

不可以，created/componentWillMount 时，还未挂载，代码仍然在服务器中执行，此时没有浏览器环境，因此此时访问 localStorage 将会报错

## 13 CSP 是干什么用的了 ##

> 在 Issue 或者我的网站中交流与讨论: 13 CSP 是干什么用的了

`CSP` **只允许加载指定的脚本及样式**，**最大限度地防止 `XSS` 攻击**，是解决 XSS 的最优解。CSP 的设置根据加载页面时 http 的响应头 `Content Security Policy` 在服务器端控制。

1.  外部脚本可以通过指定域名来限制：**`Content-Security-Policy: script-src 'self'`**，`self` 代表只加载当前域名
2.  如果网站必须加载内联脚本 (inline script) ，则可以提供一个 `nonce` 才能执行脚本，攻击者则无法注入脚本进行攻击。**`Content-Security-Policy: script-src 'nonce-xxxxxxxxxxxxxxxxxx'`**

通过 `devtools -> network` 可见 github 的 CSP 配置如下：

Content-Security-Policy: default-src 'none'; 
      base-uri 'self'; 
      block-all-mixed-content;
      connect-src 'self' uploads.github.com www.githubstatus.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com cdn.optimizely.com logx.optimizely.com/v1/events wss://alive.github.com; 
      font-src github.githubassets.com; 
      form-action 'self' github.com gist.github.com; 
      frame-ancestors 'none'; 
      frame-src render.githubusercontent.com; 
      img-src 'self' data: github.githubassets.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; 
      manifest-src 'self'; 
      media-src 'none'; 
      script-src github.githubassets.com; 
      style-src 'unsafe-inline' github.githubassets.com; 
      worker-src github.com/socket-worker.js gist.github.com/socket-worker.js

### 相关链接 ###

*  Content Security Policy 入门教程 - 阮一峰
 *  Content Security Policy - w3

## 14 简述下 css specificity ##

> 在 Issue 或者我的网站中交流与讨论: 14 简述下 css specificity

`css specificity` 即 css 中关于选择器的权重，以下三种类型的选择器依次下降

1.  `id` 选择器，如 `#app`
2.  `class`、`attribute` 与 `pseudo-classes` 选择器，如 `.header`、`[type="radio"]` 与 `:hover`
3.  `type` 标签选择器和伪元素选择器，如 `h1`、`p` 和 `::before`

其中通配符选择器 `*`，组合选择器 `+ ~ >`，否定伪类选择器 `:not()` 对优先级无影响

另有内联样式 `<div class="foo" style="color: red;"></div>` 及 `!important`(最高) 具有更高的权重

> `:not` 的优先级影响 - codepen 可以看出 `:not` 对选择器的优先级无任何影响

## 15 position: sticky 如何工作，适用于哪些场景 ##

> 在 Issue 或者我的网站中交流与讨论: 15 position: sticky 如何工作，适用于哪些场景

`position: sticky` 可理解为 `relative` 与 `fixed` 的结合体

## 16 什么情况下会发送 OPTIONS 请求 ##

> 在 Issue 或者我的网站中交流与讨论: 16 什么情况下会发送 OPTIONS 请求

**当一个请求跨域且不是简单请求时就会发送 `OPTIONS` 请求**

满足以下条件就是一个简单请求:

1.  `Method`: 请求的方法是 `GET`、`POST` 及 `HEAD`
2.  `Header`: 请求头是 `Content-Type`、`Accept-Language`、`Content-Language` 等
3.  `Content-Type`: 请求类型是 `application/x-www-form-urlencoded`、`multipart/form-data` 或 `text/plain`

而在项目中常见的 `Content-Type: application/json` 及 `Authorization: <token>` 为典型的**非简单请求**，在发送请求时往往会带上 `Options`

> 更详细内容请参考 CORS - MDN

## 17 简述下 TLS 握手过程 ##

> 在 Issue 或者我的网站中交流与讨论: 17 简述下 TLS 握手过程

TLS 握手的详细过程可参考下图：

![format_png][] TLS handshake

> 以上图片来自 high-performance-browser

从 `wireshark` 抓包，也可以看到握手的详细流程，建议抓包加强理解，以下是抓包 `https://q.shanyue.tech` 时的握手流程

通过 `curl -vvv --head` 来查看握手信息:

$ curl -vvv --head  https://q.shanyue.tech
    *   Trying 111.6.180.235...
    * TCP_NODELAY set
    * Connected to q.shanyue.tech (111.6.180.235) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: /etc/ssl/cert.pem
      CApath: none
    * TLSv1.2 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: CN=q.shanyue.tech
    *  start date: Dec  2 00:00:00 2019 GMT
    *  expire date: Dec  1 12:00:00 2020 GMT
    *  subjectAltName: host "q.shanyue.tech" matched cert's "q.shanyue.tech"
    *  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Encryption Everywhere DV TLS CA - G1
    *  SSL certificate verify ok.
    * Using HTTP2, server supports multi-use
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x7f95ba80dc00)

### 握手过程 ###

在 TLS 1.2 中，握手协议过程需要耗费两个 RTT，过程如下

1.  \[OUT\] Client Hello，客户端选出自身支持的 TLS 版本号、`cipher suites`、一个随机数、SessionId 传送给服务器端 (有可能可服用 Session)
2.  \[IN\] Server Hello，服务器端选出双方都支持的 TLS 版本，`cipher suite` 、一个随机数、SeesionId 给客户端
3.  \[IN\] Certificate，服务器端给客户端发送证书，用以身份验证及提供公钥
4.  \[IN\] Server Key Exchange，服务器端给客户端发送秘钥交换算法的一些参数
5.  \[IN\] Server Finished
6.  \[OUT\] Client Key Exchange，客户端给服务器端发送秘钥交换算法的一些参数，计算出预备主密钥 (pre master key)，作为随机数传递给服务器端 (这个随机数是安全的)。双方根据三个随机数生成对称加密中的秘钥
7.  \[OUT\] Change Cipher Spec，告知对方以后的消息将要使用TLS记录层协议进行加密
8.  \[OUT\] Finished，发送第一条加密的消息并完整性验证
9.  \[IN\] Change Cipher Spec，告知以后的消息将要使用TLS记录层协议进行加密
10. \[IN\] Finished，发送第一条加密的消息并完整性验证

### 相关链接 ###

*  https握手流程详解
 *  Chapter 4. Transport Layer Security (TLS)

## 18 TLS1.3 相比 TLS1.2 有何不同 ##

> 在 Issue 或者我的网站中交流与讨论: 18 TLS1.3 相比 TLS1.2 有何不同

以下摘自 RFC 5246: TLS 1.2

Client                                               Server
    
          ClientHello                  -------->
                                                          ServerHello
                                                         Certificate*
                                                   ServerKeyExchange*
                                                  CertificateRequest*
                                       <--------      ServerHelloDone
          Certificate*
          ClientKeyExchange
          CertificateVerify*
          [ChangeCipherSpec]
          Finished                     -------->
                                                   [ChangeCipherSpec]
                                       <--------             Finished
          Application Data             <------->     Application Data
    
                 Figure 1.  Message flow for a full handshake
    
       * Indicates optional or situation-dependent messages that are not
       always sent.

以下摘自 RFC 8446: TLS 1.3

Client                                           Server
    
    Key  ^ ClientHello
    Exch | + key_share*
         | + signature_algorithms*
         | + psk_key_exchange_modes*
         v + pre_shared_key*       -------->
                                                      ServerHello  ^ Key
                                                     + key_share*  | Exch
                                                + pre_shared_key*  v
                                            {EncryptedExtensions}  ^  Server
                                            {CertificateRequest*}  v  Params
                                                   {Certificate*}  ^
                                             {CertificateVerify*}  | Auth
                                                       {Finished}  v
                                   <--------  [Application Data*]
         ^ {Certificate*}
    Auth | {CertificateVerify*}
         v {Finished}              -------->
           [Application Data]      <------->  [Application Data]
    
                  +  Indicates noteworthy extensions sent in the
                     previously noted message.
    
                  *  Indicates optional or situation-dependent
                     messages/extensions that are not always sent.
    
                  {} Indicates messages protected using keys
                     derived from a [sender]_handshake_traffic_secret.
    
                  [] Indicates messages protected using keys
                     derived from [sender]_application_traffic_secret_N.
    
                   Figure 1: Message Flow for Full TLS Handshake

1.  握手时间从以前的 2RTT 缩短到 1RTT，通过 `Pre shared-key` 减少了单独的 ServerKeyExchange 与 ClientKeyExchange 消耗的一个 RTT
2.  0-RTT Resumption

## 19 你使用过哪些前端性能分析工具 ##

> 在 Issue 或者我的网站中交流与讨论: 19 你使用过哪些前端性能分析工具

最常见且实用的性能工具有两个：

1.  `lighthouse`: 可在 chrome devtools 直接使用，根据个人设备及网络对目标网站进行分析，并提供各种建议
2.  `webpagetest`: 分布式的性能分析工具，可在全球多个区域的服务器资源为你的网站进行分析，并生成相应的报告

## 20 如何找到当前页面出现次数最多的HTML标签 ##

> 在 Issue 或者我的网站中交流与讨论: 20 如何找到当前页面出现次数最多的HTML标签

这是一道前端基础与编程功底具备的面试题：

*  如果你前端基础强会了解 `document.querySelector(*)` 能够列出页面内所有标签
 *  如果你编程能力强能够用递归快速实现同等的效果

有三种 API 可以列出页面所有标签：

1.  `document.querySelector('*')`，标准规范实现
2.  `$$('*')`，devtools 实现
3.  `document.all`，非标准规范实现

> document.querySelectorAll('*')
    < NodeList(593) [html, head, meta, meta, meta, meta, meta, meta, meta, title, link#favicon, link, link#MainCss, link#mobile-style, link, link, link, script, script, script, script, script, script, script, link, script, link, link, script, input#_w_brink, body, a, div#home, div#header, div#blogTitle, a#lnkBlogLogo, img#blogLogo, h1, a#Header1_HeaderTitle.headermaintitle.HeaderMainTitle, h2, div#navigator, ul#navList, li, a#blog_nav_sitehome.menu, li, a#blog_nav_myhome.menu, li, a#blog_nav_newpost.menu, li, a#blog_nav_contact.menu, li, a#blog_nav_rss.menu, li, a#blog_nav_admin.menu, div.blogStats, span#stats_post_count, span#stats_article_count, span#stats-comment_count, div#main, div#mainContent, div.forFlow, div#post_detail, div#topics, div.post, h1.postTitle, a#cb_post_title_url.postTitle2.vertical-middle, span, div.clear, div.postBody, div#cnblogs_post_body.blogpost-body, p, p, strong, p, p, p, strong, div.cnblogs_code, pre, span, span, span, span, span, p, span, strong, pre, strong, span, strong, br, br, br, div.cnblogs_code, pre, span, span, p, p, …]
    [0 … 99]
    [100 … 199]
    [200 … 299]
    [300 … 399]
    [400 … 499]
    [500 … 592]
    __proto__: NodeList

使用 `document.querySelectorAll` 实现如下

const maxBy = (list, keyBy) => list.reduce((x, y) => keyBy(x) > keyBy(y) ? x : y)
    
    function getFrequentTag () {
      const tags = [...document.querySelectorAll('*')].map(x => x.tagName).reduce((o, tag) => { 
        o[tag] = o[tag] ? o[tag] + 1 : 1;
        return o
      }, {})
      return maxBy(Object.entries(tags), tag => tag[1])
    }

使用 `element.children` 递归迭代如下 (最终结果多一个 document)

function getAllTags(el = document) {
      const children = Array.from(el.children).reduce((x, y) => [...x, ...getAllTags(y)], [])
      return children
    }
    
    // 或者通过 flatMap 实现
    function getAllTags(el = document) {
      const children = Array.prototype.flatMap.call(el.children, x => getAllTags(x))
      return [el, ...children]
    }

## 21 在 nginx 中如何配置负载均衡 ##

> 在 Issue 或者我的网站中交流与讨论: 21 在 nginx 中如何配置负载均衡

通过 `proxy_pass` 与 `upstream` 即可实现最为简单的负载均衡。如下配置会对流量均匀地导向 `172.168.0.1`，`172.168.0.2` 与 `172.168.0.3` 三个服务器

http {
      upstream backend {
          server 172.168.0.1;
          server 172.168.0.2;
          server 172.168.0.3;
      }
    
      server {
          listen 80;
          location / {
              proxy_pass http://backend;
          }
      }
    }

关于负载均衡的策略大致有以下四种种

1.  round\_robin，轮询
2.  weighted\_round\_robin，加权轮询
3.  ip\_hash
4.  least\_conn

### Round\_Robin ###

轮询，`nginx` 默认的负载均衡策略就是轮询，假设负载三台服务器节点为 A、B、C，则每次流量的负载结果为 ABCABC

### Weighted\_Round\_Robin ###

加权轮询，根据关键字 weight 配置权重，如下则平均没来四次请求，会有八次打在 A，会有一次打在 B，一次打在 C

upstream backend {
      server 172.168.0.1 weight=8;
      server 172.168.0.2 weight=1;
      server 172.168.0.3 weight=1;
    }

### IP\_hash ###

对每次的 IP 地址进行 Hash，进而选择合适的节点，如此，每次用户的流量请求将会打在固定的服务器上，利于缓存，也更利于 AB 测试等。

upstream backend {
      server 172.168.0.1;
      server 172.168.0.2;
      server 172.168.0.3;
      ip_hash;
    }

### Least Connection ###

选择连接数最少的服务器节点优先负载

upstream backend {
      server 172.168.0.1;
      server 172.168.0.2;
      server 172.168.0.3;
      least_conn;
    }

说到最后，**这些负载均衡策略对于应用开发者至关重要，而基础开发者更看重如何实现这些策略**，如这四种负载算法如何实现？请参考以后的文章

\- END -

### 最后 ###

如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：

1.  点个「**在看**」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -\_-）
2.  欢迎加我微信「huab119」拉你进技术群，长期交流学习...
3.  关注公众号「**前端劝退师**」，持续为你推送精选好文，也可以加我为好友，随时聊骚。

![format_png 1][]

![format_png 2][]

点个在看支持我吧，转发就更好了

[format_png]: /images/20221024/9c6f446e34f442079d8605735d1a5365.png
[format_png 1]: /images/20221024/adb1d9661c0543b0bf044e6c8ec4c320.png
[format_png 2]: /images/20221024/47c81789149b4dbda1c441f4d15b8756.png