极客时间对于推广渠道会有返利优惠,比如山月在极客时间买了一门课,再把课程分享给好友购买,这时极客时间会向山月返利20元左右。
而我现在做了一个返利平台,你可以在上边通过山月的链接购买课程,此时极客时间会向我返利。为了共同学习,而你可以添加我的微信 (shanyue94),我将把极客时间给我的返利发一个红包全部返给你

# 2021 年初山月的大厂面试经验总结

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

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

总结题目如下

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

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

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

效果可以见 codepen (opens new window)

.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 (opens new window) 或者我的网站 (opens new window)中交流与讨论: 02 css 如何实现左侧固定300px,右侧自适应的布局 (opens new window)

使用 flex 布局,左侧 300px,右侧 flex-grow: 1pug 代码及 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 (opens new window) 或者我的网站 (opens new window)中交流与讨论: 03 http 状态码 502 和 504 有什么区别 (opens new window)

这两种异常状态码都与网关 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 (opens new window) 或者我的网站 (opens new window)中交流与讨论: 04 如何使用 react hooks 实现 useFetch 请求数据 (opens new window)

可以参考 How to fetch data with React Hooks? (opens new window)

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 05 react 如何使用 render prop component 请求数据 (opens new window)

参考: https://www.robinwieruch.de/react-fetching-data#how-to-fetch-data-in-render-props (opens new window)

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 06 什么是 virtual DOM,它的引入带了什么好处 (opens new window)

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

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

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

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

nginx 也是这样处理的,源码见: ngx_http_static_module.c (opens new window)

    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 (opens new window)

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 08 localhost:3000 与 localhost:5000 的 cookie 信息是否共享 (opens new window)

共享

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

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

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

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 10 http 响应头中的 Date 与 Last-Modified 有什么不同,网站部署时需要注意什么 (opens new window)

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

LM-Factor 与它俩有关。

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

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 11 http 1.1 中的 keep-alive 有什么作用 (opens new window)

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 (opens new window) 或者我的网站 (opens new window)中交流与讨论: 12 如果使用 SSR,可以在 created/componentWillMount 中访问 localStorage 吗 (opens new window)

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

# 13 CSP 是干什么用的了

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 13 CSP 是干什么用的了 (opens new window)

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

# 相关链接

# 14 简述下 css specificity

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 14 简述下 css specificity (opens new window)

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

  1. id 选择器,如 #app
  2. classattributepseudo-classes 选择器,如 .header[type="radio"]:hover
  3. type 标签选择器和伪元素选择器,如 h1p::before

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

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

:not 的优先级影响 - codepen (opens new window) 可以看出 :not 对选择器的优先级无任何影响

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 15 position: sticky 如何工作,适用于哪些场景 (opens new window)

position: sticky 可理解为 relativefixed 的结合体

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 16 什么情况下会发送 OPTIONS 请求 (opens new window)

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

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

  1. Method: 请求的方法是 GETPOSTHEAD
  2. Header: 请求头是 Content-TypeAccept-LanguageContent-Language
  3. Content-Type: 请求类型是 application/x-www-form-urlencodedmultipart/form-datatext/plain

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

更详细内容请参考 CORS - MDN (opens new window)

# 17 简述下 TLS 握手过程

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 17 简述下 TLS 握手过程 (opens new window)

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

TLS handshake

以上图片来自 high-performance-browser (opens new window)

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,发送第一条加密的消息并完整性验证

# 相关链接

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

Issue (opens new window) 或者我的网站 (opens new window)中交流与讨论: 18 TLS1.3 相比 TLS1.2 有何不同 (opens new window)

以下摘自 RFC 5246: TLS 1.2 (opens new window)

      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 (opens new window)

       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 (opens new window) 或者我的网站 (opens new window)中交流与讨论: 19 你使用过哪些前端性能分析工具 (opens new window)

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

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

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

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

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

  • 如果你前端基础强会了解 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,]
[099]
[100199]
[200299]
[300399]
[400499]
[500592]
__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 (opens new window) 或者我的网站 (opens new window)中交流与讨论: 21 在 nginx 中如何配置负载均衡 (opens new window)

通过 proxy_passupstream 即可实现最为简单的负载均衡。如下配置会对流量均匀地导向 172.168.0.1172.168.0.2172.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;
}

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

关于山月

我的项目:
我的微信:shanyue94,欢迎交流
Last Updated: 5/14/2021, 1:48:53 PM