关于前端面试的总结

关于前端面试，关于http+TCP+性能的优化

TCP

要说http就绕不开tcp，TCP协议对应于传输层，而HTTP协议对应于应用层，从本质上来说，二者没有可比性。但是，http是基于tcp协议的。

TCP/IP 协议分层模型

• 物理层将二进制的0和1和电压高低，光的闪灭和电波的强弱信号进行转换
• 链路层代表驱动
• 网络层
  • 使用 IP 协议，IP 协议基于 IP 转发分包数据
  • IP 协议是个不可靠协议，不会重发
  • IP 协议发送失败会使用ICMP 协议通知失败
  • ARP 解析 IP 中的 MAC 地址，MAC 地址由网卡出厂提供
  • IP 还隐含链路层的功能，不管双方底层的链路层是啥，都能通信
• 传输层
  • 通用的 TCP 和 UDP 协议
    • TCP 协议面向有连接，能正确处理丢包，传输顺序错乱的问题，但是为了建立与断开连接，需要至少7次的发包收包，资源浪费
    • UDP 面向无连接，不管对方有没有收到，如果要得到通知，需要通过应用层
• 会话层以上分层
  • TCP/IP 分层中，会话层，表示层，应用层集中在一起
  • 网络管理通过 SNMP 协议

划重点了啊（面试最常问的啊）

TCP三次握手和四次挥手？

被问烂了的问题了，这里不详细讲了，三次握手：

• 客户端–发送带有SYN标志的数据包–一次握手–服务端
• 服务端–发送带有SYN/ACK标志的数据包–二次握手–客户端
• 客户端–发送带有带有ACK标志的数据包–三次握手–服务端

四次挥手：

• 客户端-发送一个FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个FIN，它发回一个ACK，确认序号为收到的序号加1 。和SYN一样，一个FIN将占用一个序号
• 服务器-关闭与客户端的连接，发送一个FIN给客户端
• 客户端-发回ACK报文确认，并将确认序号设置为收到序号加1

HTTP

Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。所以Http连接是一种短连接，是一种无状态的连接。

所谓的无状态，是指浏览器每次向服务器发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。如果是一个连接的话，服务器进程中就能保持住这个连接并且在内存中记住一些信息状态。而每次请求结束后，连接就关闭，相关的内容就释放了，所以记不住任何状态，成为无状态连接。

http传输流

无耻盗图

发送端在层与层间传输数据时，没经过一层都会被加上首部信息，接收端每经过一层都会删除一条首部

HTTP

开玩笑的，这个显然不是重点，但是不排除有人会去问，还是要知道的：超文本传输协议（HyperText Transfer Protocol）

状态码？

状态码就那些，常用的记住就行了：

2XX 成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 206 Partial Content，进行范围请求

3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
• 302 found，临时性重定向，表示资源临时被分配了新的 URL
• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法丁香获取资源
• 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
• 307 temporary redirect，临时重定向，和302含义相同

4XX 客户端错误

• 400 bad request，请求报文存在语法错误
• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
• 403 forbidden，表示对请求资源的访问被服务器拒绝
• 404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误
• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

HTTP协议格式？

HTTP的请求和响应的消息协议是一样的，分为三个部分，起始行、消息头和消息体。这三个部分以CRLF作为分隔符。最后一个消息头有两个CRLF，用来表示消息头部的结束。

HTTP请求的起始行称为请求行，形如GET /index.html HTTP/1.1

HTTP响应的起始行称为状态行，形如200 ok

消息头部有很多键值对组成，多个键值对之间使用CRLF作为分隔符，也可以完全没有键值对。形如Content-Encoding: gzip消息体是一个字符串，字符串的长度是由消息头部的Content-Length键指定的。如果没有Content-Length字段说明没有消息体，譬如GET请求就是没有消息体的，POST请求的消息体一般用来放置表单数据。GET请求的响应返回的页面内容也是放在消息体里面的。我们平时调用API返回的JSON内容都是放在消息体里面的。

HTTP的无状态性？

所谓HTTP协议的无状态性是指服务器的协议层无需为不同的请求之间建立任何相关关系，它特指的是协议层的无状态性。但是这并不代表建立在HTTP协议之上的应用程序就无法维持状态。应用层可以通过会话Session来跟踪用户请求之间的相关性，服务器会为每个会话对象绑定一个唯一的会话ID，浏览器可以将会话ID记录在本地缓存LocalStorage或者Cookie，在后续的请求都带上这个会话ID，服务器就可以为每个请求找到相应的会话状态。

输入url到页面加载都发生了什么事情？（最最常问的来了）

• 输入地址
• 浏览器查找域名的 IP 地址这一步包括 DNS 具体的查找过程，包括：浏览器缓存->系统缓存->路由器缓存...
• 浏览器向 web 服务器发送一个 HTTP 请求
• 服务器的永久重定向响应（从 http://example.com 到 http://www.example.com）
• 浏览器跟踪重定向地址
• 服务器处理请求
• 服务器返回一个 HTTP 响应
• 浏览器显示 HTML
• 浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS等等）
• . 浏览器发送异步请求

性能优化

  

性能不仅仅是一个技术问题：它很重要，而且当把它引入到工作流时，设计决策必须根据其性能影响来决定。 我们必须不断的测量、监视和改进性能，而且 Web 日益复杂的情况带来了新的挑战，使得性能指标难以被跟踪，因为性能指标将因设备、浏览器、协议、网络类型和延迟（CDN、运营商、缓存、代理、防火墙、负载平衡器和服务器都在其中发挥作用）而有很大差异。

一、准备：规划和指标

01 建立性能文化

只要团队之间没有协作，高性能就无法长期维持。研究用户反馈中常见的抱怨，看看提高性能是否可以帮助缓解其中一些问题。用真实数据来建立适合自己的案例和模型。在设计过程中就开始规划加载顺序和权衡。

02 选择正确的性能指标

并非每个指标都同等重要。研究最重要的度量标准：一般而言，它与您开始渲染最重要像素的速度以及提供输入响应的速度有关。根据客户的感受确定页面加载的优先级。可交互时间、页面大标题元素的渲染时间、首次有效绘制时间（FMP）、速度指数（Speed Index）一般都很重要。

03 比你的竞争对手快至少 20%

收集代表您受众的设备上的数据。在数据来源上，真实设备比模拟数据更好。选择一台 Moto G4、中端三星设备或者 Nexus 5X 等性能良好的中端设备。或者，也可以通过在电脑上，通过设置网络限速（例如：150ms RTT，1.5Mbps 下载，0.7Mbps 上传）和 CPU 限速（5 倍慢速）以模拟移动体验。最后在常规 3G、4G 和 Wi-Fi 之间切换。收集数据、设置电子表格、将指标提高 20% 并设置目标（即，“性能预算”）。

04 把这张检查表分享给你的同事

确保团队中的每个成员都熟悉该清单。每一个决策都涉及性能问题，前端开发人员的积极参与将使您的项目受益匪浅。将你的性能预算映射到设计决策上。

二、制定现实的目标

05 100 毫秒的响应时间 + 每秒60帧

每帧动画应在少于 16 毫秒（理想情况下为 10 毫秒）内完成，从而达到每秒 60 帧（1 秒 ÷ 60 = 16.6毫秒）。保持乐观，明智地利用空闲时间。对于像动画这样的高压点，只要能，就不要做任何其它事情。预计输入延迟时间（Estimated Input Latency）应低于 50 毫秒。

06 速度指数（SpeedIndex）小于 1250，可交互时间（Time-To-Interactive）在 3G 上小于 5 秒

目标是在 1 秒内（在高速网络下）完成首次绘制（FMP），速度指数（SpeedIndex）低于 1250 毫秒。考虑速度基线是一台有着 3G 网络的，价格为 200 美元左右的 Android 手机（译注：国产千元机水平），那么可以以 400 毫秒 RTT 和 400kb/s 的传输速度进行网络模拟，以达成可交互时间（Time-To-Interactive）小于 5 秒，第二次打开的速度低于 2 秒。尽你所能地降低这些指标。

07 核心块 = 15kb，关键文件 < 170 kb

HTML 的前 14~15kb 是最关键的核心块（chunk），也是整个文件中唯一可以在第一个 RTT 内被下载的部分。要实现上述目标，请设定关键文件的最大尺寸“预算”。170kb gzip 后的文件（原始文件尺寸 0.8~1mb），在普通手机上可能需要 1 秒才能解析和编译完成。

三、定义环境

08 选择并设置你的构建工具

不要太注意所谓的“酷”。只要您能够快速获得结果，而且在维护构建过程上没有问题就很好了。

09 渐进增强

首先设计和构建核心功能，然后再在此基础上为功能强大的浏览器的高级功能增强效果，从而创建弹性的体验。如果您的网站在性能差、网络差的机器上还能运行得比较快，那在性能好、网络棒的机器上只会运行得更快。

10 设定硬性的性能基准

用 JavaScript 实现交互效果的成本相当高昂。170kb 的尺寸预算已经包含了核心的 HTML / CSS / JavaScript、路由、状态管理、工具函数、框架还有产品逻辑，因此，请彻底检查我们选择的框架的网络传输成本、解析 / 编译时间和其运行时的时间成本。

11 圣战止于智者：Angular, React 还是 Ember

并不是每个项目都需要框架。但是如果你的项目需要框架，那么最好选择使用一个支持服务器端渲染（SSR）的框架。在使用框架之前，请确保在移动设备上以服务器端渲染和客户端渲染两种模式来评估框架的启动时间。了解您将依赖的框架的具体细节。了解 PRPL 模式和 App Shell 模型。

12 你会使用 AMP 或者 Instant Articles 吗

（译注：AMP 为 Google 的开源项目，意在以组件化的形式以提升移动设备对网站的访问速度；Instant Articles 是 Facebook 的协议，意在通过渲染页面的精简版本以提升页面在 Facebook App 内的打开速度。在国内，MIP 是和 AMP 类似的解决方案。）

没有它们，你也可以获得良好的性能。但是 AMP 提供了一个可靠的性能框架，有免费的 CDN ，而 Instant Articles 将提高你在 Facebook 上的知名度和性能。你也可以构建一个渐进式 AMP（译注：Progressive Web AMP，PWA 和 AMP 的结合体）。

13 选择合适的 CDN

您可以将部分内容“外包”给静态站点生成器，然后将其推送到 CDN，并从CDN 提供静态版本，从而避免数据库请求（即 JAMStack）。当然，这取决于您拥有的动态数据量。仔细检查 CDN 是否为您执行了内容压缩和转换、智能 HTTP/2 和边缘端包含（ESI, edge-side includes）。

四、优化构建

14 合理安排优先级

把你所有的静态资源（JavaScript，图片，字体，第三方脚本，尺寸大的模块）列成一个表，然后把它们按优先级分成三组：基本核心功能（老浏览器也能浏览的核心内容）、增强体验效果（为现代浏览器设计的强大功能和丰富体验）、附加功能（不一定需要并且可以惰性加载的资源，比如字体、轮播脚本、视频播放器、分享按钮等）。

15 使用“符合标准”技术

（译注：“符合标准”技术（cutting-the-mustard technique）是 BBC News 开发者博客提出的，一种基于浏览器特性来检测其支持程度，并以此选择要加载哪些功能的技术。）

对老旧的浏览器，仅输出核心功能代码；对现代浏览器输出增强的功能代码。严格按标准加载静态资源：直接加载核心代码，在 DOMContentLoaded 事件中加载增强代码，并在 load 事件中加载剩下的代码。注意：廉价的 Android 手机虽然很符合标准，但这些手机的内存和 CPU 性能有限。因此，您可能需要使用读取设备内存大小的 JavaScript API 来检测设备性能，只有不支持的时候才按“符合标准”技术来。

16 减少 JavaScript 体积

由于解析 JavaScript 很耗时，所以请尽可能的减少 JavaScript 的体积。在构建 SPA 时，您可能需要用一定时间初始化应用程序之后，才能开始渲染页面。寻找可以加快初始渲染事件的模块和技术（在低端移动设备上，这可以轻松将速度提高 2-5 倍）。彻底检查每一个 JavaScript 依赖，以找出谁在消耗初始化的宝贵时间。

17 使用微优化和渐进式启动

使用服务器端渲染来获得快速的首次有效绘制时间（FMP），但也在页面里输出一些最小功能的 JavaScript 来保持交互时间（TTI）接近首次有效绘制时间（FMP）。然后，如果有需要或者有多余的时间，才开始启动应用程序的非必要部分。在加载时显示一个骨架屏幕，而不是“加载中”动画。

18 使用摇树和代码分割

使用摇树（Tree Shaking）技术和代码分割（Code Splitting）技术以减少代码体积。

摇树（Tree Shaking）技术是一种通过丢弃未使用的代码以在构建过程清理代码的方法。代码分割（Code Splitting）技术将您的代码拆分为按需加载的“chunks（块）”。作用域提升（Scope Hoisting）技术使得链式的依赖能被无缝地转换成行内函数。通过 WebPack 将上述技术用于您的代码。使用 AOT 编译器（译注：例如 Closure Compiler）将一些客户端计算移到服务端。

19 异步加载 JavaScript

作为开发者，我们必须显式地使用 defer 和 async 属性来告诉浏览器不要等待脚本下载、开始渲染页面。如果你不需要关注 IE 9 及以下版本的浏览器，那么使用 defer 更好；否则，使用 async 更好。使用静态的分享按钮、静态链接交互式地图而不是使用第三方库。

20 HTTP 缓存头是否设置好了

重新检查你是否正确的设置了 Expires, Cache-Control, Max-Age 等 HTTP 缓存控制响应头。通常而言，一个资源要么只被缓存很短的时间（比如经常修改的资源），要么永久缓存（比如不会被更改的那种资源）。使用专为带哈希指纹的静态文件设计的响应头 Cache-Control: imuutable 以避免浏览器重新请求文件。

五、静态资源优化

21 是否使用了 Brotli 或 Zopfli 压缩

Brotli 是一种新的无损压缩格式。现在，所有的现代浏览器都支持它。它比 Gzip 和 Deflate 压缩率更高，压缩非常慢，但是解压速度很快。使用最高压缩比的 Brotli+Gzip 预压缩静态文件，并使用 1~4 级的 Brotli 实时压缩动态内容。也顺便检查一下 CDN 是否支持 Brotli。或者，你也可以试试在不常变化的资源上使用 Zopfli —— 它将数据用 Deflate、Gzip 和 Zlib 格式压缩，并且被设计为一次压缩、多次下载。

22 图片是否被正确优化

尽可能使用通过 srcset、sizes 和 <picture> 元素实现的响应式图片。使用 WebP 格式的图片；这可通过 <picutre> 标签配合 JPEG fallback，或者通过 Accept 请求头来实现。对于核心图片，使用渐进式的 JPEG 并用高斯滤镜模糊掉不重要的部分。

23 Web Font 是否被正确优化

您使用的 Web Font 很可能包含未真正被使用的执行和额外的特性。制作字体的子集（译注：仅包含部分文字的字体，如 fontmin 等方案）。优先使用 WOFF2 并使用 WOFF 作为后备。立即使用后备字体显示文字、异步加载字体（例如，使用 loadCSS），然后再切换字体。同时也考虑本地操作系统中已经安装了的字体。不要忘记在 CSS 中写 font-display: optional；如果你无法从您的服务器加载字体，请记得使用 Font Load Events。

六、分发优化

24 快速推送核心 CSS

将所有首屏渲染所需要的 CSS 放在一起，然后方法在 <head> 标签中。考虑有选择的内联的方法。或者，使用 HTTP/2 服务端推送；但这样你可能需要构建一个可感知缓存的 HTTP/2 服务端推送机制。

25 使用 babel-preset-env 以仅转译 ES2015+ 特性

由于 ES2015 已被广泛支持了，您可以考虑使用 babel-preset-env 以仅转译现代浏览器不支持的 ES2015+ 特性。然后你可以编译两份，一份是 ES6 ，另一份是 ES5。使用 <script type="module"> 使得有 ESM 支持的浏览器加载新文件，剩下的老的浏览器可以使用 <script nomodule> 来加载老的文件。

26 提升渲染性能

使用 CSS 包含（CSS Containment）隔离渲染十分耗时的组件。请保证在滑动页面或者元素动画的时候，页面不会卡顿，而且你的页面能持续以 60fps 的速度渲染。如果那不可能，那么至少也要把 fps 控制在 15~60 之间。使用 CSS 的 will-change 属性通知浏览器哪个元素将会变化。

27 使用 Intersection Observer 懒加载大型脚本

Intersection Observer API 提供了异步监听目标元素与祖先元素或顶层文档视口交点中的更改的能力。浏览器支持？Chrome, Firefox, Edge 和三星浏览器都支持了。WebKit 还在开发。浏览器不支持？懒加载一个 polyfill。

28 是否优化了渲染体验

不要低估感知性能的作用。在加载静态文件时，尽量始终领先用户一步，这样在后台发生很多事情时，会感觉体验上很快。例如，要让用户持续关注你的页面，请使用骨架屏幕而不是一些加载中的动画。

29 预热连接以加快分发速度

使用骨架屏幕，然后懒加载所有的大型组件，比如字体、JavaScript、轮播图、视频和 iframe 等。使用资源提示（Resource Hints），如 dns-prefetch、preconnect、prefetch 和 preload来节省时间。

七、HTTP/2

30 为 HTTP/2 做准备

HTTP/2 支持很好，而且提供了不小的性能提升。缺点是，您必须迁移到 HTTPS；根据您不支持 HTTP/2 的用户群大小，你可能需要为 HTTP/1.1 和 HTTP/2 的用户返回不同版本的代码，这就要求您调整您的编译工具。

31 正确地部署 HTTP/2

您需要在打包模块和并行加载许多小模块之间找到一个良好的平衡。将整个界面分解为许多小模块；然后分组、压缩和打包。整个网站分为大约 6 到 10 个包应该是一个不错的折衷方案（对于传统浏览器来说也不错）。通过实验和数据监测来为您的网站找到正确的平衡。

32 你为 Save-Data 头节约数据流量了吗

Save-Data 请求提示头可以让我们为关心流量费用和性能的用户提供个性化的响应。例如，你可以把所有高清的图片都改成低清的，不用 Web Font 和华丽的动效，关掉视频自动播放和服务器推送，甚至修改你的应用界面。

34 确保服务器上的安全性是无懈可击的

再次检查安全标头是否设置正确，消除已知漏洞，并检查 SSL 证书。确保所有外部插件和跟踪脚本都是通过 HTTPS 加载的、没有 XSS，并且 HSTS 响应头和内容安全策略（CSP）响应头都已正确设置。

35 你的服务器和 CDN 都支持 HTTP/2 吗

不同的服务器和 CDN 可能对 HTTP/2 有不同的支持。使用 Is TLS Fast Yet? 来检查你的设置，或者直接看看你的服务器性能如何，支持的特性情况怎么样。

36 是否启用了 OCSP Stapling

在服务器上启用 OCSP Stapling 有助于提升 TLS 握手速度。OCSP 协议可以让浏览器无需下载并检索证书信息，从而减少握手时间。

37 你使用 IPv6 了吗

研究标明，IPv6 的邻居发现（NDP）和路由优化可以使网站快 10% ~ 15%。升级到支持 IPv6 的 DNS 以为未来做好准备。只需确保双栈网络能正常工作——这使得 IPv6 和 IPv4 能同时运行。毕竟，IPv6 不是向后兼容的。

38 HPACK 压缩启用了吗

如果你使用了 HTTP/2，再次检查你的服务器是否实现了 HPACK 压缩。HPACK 压缩可以压缩 HTTP 响应头，以减少不必要的开支。由于 HTTP/2 服务器现在都很新，他们可能不能完全支持包括 HPACK 压缩在内的所有标准。H2spec 是一个非常好的用于检测标准支持程度的工具。

39 你使用了 Service Worker 来缓存或者提供离线内容吗

网络再怎么优化，也不会比本地缓存更快。如果你的网站使用了 HTTPS，那么你可以把静态资源放在 Service Worker 的缓存中，而不用请求网络。

八、测试和监控

40 监控混合内容警告

如果您最近从 HTTP 迁移到了 HTTPS，请确保使用类似 Report-URI.io 之类的服务监控了严格的或被动的混合内容报警。你也可以用 Mixed Content Scan 来扫描你的 HTTPS 站点上是否有非 HTTPS 的混合内容。

41 使用 DevTools 的开发工作流是优化过的吗

选择一个调试工具，并试着点击每一个按钮。请确保您理解如何分析渲染性能、控制台输出、调试 JavaScript 和编辑 CSS 样式。

42 是否在代理浏览器和老式浏览器上测试过了

在 Chrome 和 Firefox 上测试是不够的。请看看你的网站在代理浏览器和老式浏览器（包括 UC 浏览器和 Opera Mini 等。译者注：此处的代理浏览器即指国内浏览器中常见的云加速功能）上是什么样子。统计你受众国家的网络平均速度，避免出现重大意外。使用网络节流并模拟高 DPI 设备。虽然 BrowserStack 很好，但也得在真机上测试。

43 是否设置了持续的监控

良好的性能指标是被动和主动监控工具的组合。拥有 WebPagetest 的私有实例和使用 Lighthouse 确实有利于快速测试，但也需要使用诸如 Calibre、speedscurve 等 RUM 工具建立持续的监控体系。设置您自己的用户计时打点以监控特定的业务速度指标。

九、速战速决

此列表相当全面，完成所有优化可能需要相当长的时间。如果你只有一个小时的时间，但又想获得显著的提升，你应该怎么做？我们挑出了 10 个最容易实现的方法。显然，在开始之前和完成之后，请统计结果，包括 3G 和有线连接上的开始渲染时间和速度指数（SpeedIndex）。

1. 统计真实的用户体验，设置可接受的目标。一个好的目标大致是：FMP < 1s，速度指数 < 1250，TTI 在 3G 网络上 < 5s 、二次访问 < 2s。优化开始渲染时间和 TTI。
2. 为你的主模板准备核心 CSS，并放在 <head> 标签里（你的预算是 14KB）。对于 CSS/JS，请保证核心文件尺寸最大为 170kb （gzip 后的尺寸；压缩前 0.8~1Mb）
3. 延迟或懒加载尽可能多的脚本，不管是你自己的还是第三方的——特别是分享按钮、视频播放器和其它的复杂模块。
4. 增加资源提示，包括 dns-lookup, preconnect, prefetch 和 preload。
5. 为 Web Font 创建子集，并异步加载（或者干脆别用）。
6. 优化图片。考虑在关键的页面（比如落地页）上用 WebP 格式。
7. 检查 HTTP 缓存头和安全头是否正确设置了。
8. 在服务器上启用 Brotli 或者 Zopfli 压缩。如果不支持，别忘了开 gzip。
9. 如果有 HTTP/2，启用 HPACK 压缩并上报混合内容警告。如果使用了 LTS，那么请打开 OCSP 装订。
10. 如果可能，将静态资源（包括字体、样式、脚本和图片等）尽可能多地在 service worker 里缓存起来。

  

1.请简单描述http协议的请求报文和响应报文的组成格式？

HTTP请求报文

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。

英文：

＜request-line＞

＜headers＞

＜blank line＞

＜request-body＞

1.请求头

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

2.请求头部

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

User-Agent：产生请求的浏览器类型。

Accept：客户端可识别的内容类型列表。

Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

3.空行

最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

4.请求数据

请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

HTTP报文

HTTP响应也由三个部分组成，分别是：状态行、消息报头、响应正文。

如下所示，HTTP响应的格式与请求的格式十分类似：

英文：

＜status-line＞

＜headers＞

＜blank line＞

＜response-body＞

正如你所见，在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。

状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。

• 1xx：指示信息--表示请求已接收，继续处理。
• 2xx：成功--表示请求已被成功接收、理解、接受。
• 3xx：重定向--要完成请求必须进行更进一步的操作。
• 4xx：客户端错误--请求有语法错误或请求无法实现。
• 5xx：服务器端错误--服务器未能实现合法的请求。

常见状态代码、状态描述的说明如下。

• 200 OK：客户端请求成功。
• 400 Bad Request：客户端请求有语法错误，不能被服务器所理解。
• 401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。
• 403 Forbidden：服务器收到请求，但是拒绝提供服务。
• 404 Not Found：请求资源不存在，举个例子：输入了错误的URL。
• 500 Internal Server  Error：服务器发生不可预期的错误。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）。

详情可以参考该博客

2.用三种方式实现块框的垂直剧中效果，假设框的高度根据内容自适应

注意兼容性，autoprefixer可以处理前缀的兼容而已,对于不支持transform和flex的浏览器，如果要兼容该部分浏览器，请选择其他方式（笔者做的大多是移动端，以下三种，除安卓4.3以下原生内核不支持外，并外见兼容性的bug,flex在X5内核，ios低版本内核中有些兼容性(如flex-wrap),需注意）。

第一种：flex

父元素设置以下属性
display:flex;
flex-direction:row //web 默认的值，rn默认column
align-items:center

第二种：absolute

父元素设置
position:relative
本元素
position:absolute;
top:50%;
transform:translateY(-50%);

第三种：利用display:table-cell属性

display:table-cell;
vertical-alian:middle;

。。。还有很多

3.http中的状态码302代表的是什么意思

302重定向表示临时性转移(Temporarily Moved )，当一个网页URL需要短期变化时使用。

顺便提一嘴301

301重定向/跳转一般，表示本网页永久性转移到另一个地址。

301是永久性转移(Permanently Moved),SEO常用的招式，会把旧页面的PR等信息转移到新页面

301重定向与302重定向的区别

301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

302重定向是临时的重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。

4.cookie是什么，和session有什么区别

1，session 在服务器端，cookie 在客户端（浏览器）

2，session 默认被存在在服务器的一个文件里（不是内存）

3，session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览

器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 

session_id）

4，session 可以放在 文件、数据库、或内存中都可以。

5，用户验证这种场合一般会用 session

因此，维持一个会话的核心就是客户端的唯一标识，即 session id

5.有那些dom接口可以获取一个元素的尺寸（宽度和高度）

假设该元素id为box

1.第一种通过内联样式（注意：css声明中没有设置hieght和width的话是获取不到的,而且也不会根据box-sizing的值而返回不同盒子模型的宽高

    var box = document.getElementById('box');
    var w = box.style.width;
    var h = box.style.height;

2.通过计算元素的大小（但是在ie情况下有一个问题，那就没写widht和height的css就返回auto，getComputedStyle在IE下如果设置了宽高为em这种单位,返回来的值依然是em,而不会是px）;

    var style = window.getComputedStyle ? window.getComputedStyle(box,null) : null || box.currentStyle;
    var w = style.width;
    var h = style.height;

3.offsetHeight和offsetHeight

4.getBoundingClientRect（IE67的left、top会少2px,并且没有width、height属性，需兼容该部分浏览器的，那就不得不选择放弃了）DOMRect 对象包含了一组用于描述边框的只读属性——left、top、right和bottom，单位为像素。除了 width 和 height 外的属性都是相对于视口的左上角位置而言的

6.请描述dom事件的流程，即从触发到结束的整个过程

事件流包括三个阶段:事件捕获阶段、处于目标阶段和事件冒泡阶段。首先发生的是事件捕获，

为截获事件提供了机会。然后是实际的目标接收到事件。最后一个阶段是冒泡阶段，可以在这

个阶段对事件做出响应。 单击<div>元素会按照如下图：

DOM 事件流中，实际的目标(<div>元素)在捕获阶段不会接收到事件。这意味着在捕获阶段， 

12事件从 document 到<html>再到<body>后就停止了。下一个阶段是“处于目标”阶段，于是

事件在<div>上发生，并在事件处理(后面将会讨论这个概念)中被看成冒泡阶段的一部分。然

后，冒泡阶段发生，事件又传播回文档。 

多数支持 DOM 事件流的浏览器都实现了一种特定的行为;即使“DOM2 级事件”规范明确要求

捕获阶段不会涉及事件目标，但 IE9、Safari、Chrome、Firefox 和 Opera 9.5 及更高版本都

会在捕获阶段触发事件对象上的事件。结果，就是有两个机会在目标对象上面操作事件。 

以上是高程的内容。

7.请描述utf-8和unicode的区别

• Unicode 是「字符集」
• UTF-8 是「编码规则」

Unicode是一套复杂的字符编码标准，简单来说就是将人类使用的每个所谓字符与一个非负整数对应，并且保证不同的字符对应的整数一定不同。UTF-8是这个整数的编码方式，用1到4字节来表达一个整数。

关系：UTF-8是Unicode的实现方式之一，它规定了字符如何在计算机中存储、传输等。

8.讲一讲你在日常web开发中加载和交互体验上常用的优化策略

1. 减少HTTP请求数

这条策略基本上所有前端人都知道，而且也是最重要最有效的。都说要减少HTTP请求，那请求多了到底会怎么样呢？首先，每个请求都是有成本的，既包 含时间成本也包含资源成本。一个完整的请求都需要经过DNS寻址、与服务器建立连接、发送数据、等待服务器响应、接收数据这样一个“漫长”而复杂的过程。 时间成本就是用户需要看到或者“感受”到这个资源是必须要等待这个过程结束的，资源上由于每个请求都需要携带数据，因此每个请求都需要占用带宽。

另外，由于浏览器进行并发请求的请求数是有上限的，因此请求数多了以后，浏览器需要分批进行请求，因此会增加用户的等待时间，会给 用户造成站点速度慢这样一个印象，即使可能用户能看到的第一屏的资源都已经请求完了，但是浏览器的进度条会一直存在。减少HTTP请求数的主要途径包括：

(1). 从设计实现层面简化页面

如果你的页面像百度首页一样简单，那么接下来的规则基本上都用不着了。保持页面简洁、减少资源的使用时最直接的。如果不是这样，你的页面需要华丽的皮肤，则继续阅读下面的内容。

(2). 合理设置HTTP缓存

缓存的力量是强大的，恰当的缓存设置可以大大的减少HTTP请求。以有啊首页为例，当浏览器没有缓存的时候访问一共会发出78个请求，共600多K 数据（如图1.1），而当第二次访问即浏览器已缓存之后访问则仅有10个请求，共20多K数据（如图1.2）。（这里需要说明的是，如果直接F5刷新页面 的话效果是不一样的，这种情况下请求数还是一样，不过被缓存资源的请求服务器是304响应，只有Header没有Body，可以节省带宽）

怎样才算合理设置？原则很简单，能缓存越多越好，能缓存越久越好。例如，很少变化的图片资源可以直接通过HTTP Header中的Expires设置一个很长的过期头；变化不频繁而又可能会变的资源可以使用Last-Modifed来做请求验证。尽可能的让资源能够 在缓存中待得更久。

(3). 资源合并与压缩

如果可以的话，尽可能的将外部的脚本、样式进行合并，多个合为一个。另外，CSS、Javascript、Image都可以用相应的工具进行压缩，压缩后往往能省下不少空间。

(4). CSS Sprites

合并CSS图片，减少请求数的又一个好办法。

(5). Inline Images

使用data: URL scheme的方式将图片嵌入到页面或CSS中，如果不考虑资源管理上的问题的话，不失为一个好办法。如果是嵌入页面的话换来的是增大了页面的体积，而且无法利用浏览器缓存。使用在CSS中的图片则更为理想一些。

(6). Lazy Load Images

这条策略实际上并不一定能减少HTTP请求数，但是却能在某些条件下或者页面刚加载时减少HTTP请求数。对于图片而言，在页面刚加载的时候可以只 加载第一屏，当用户继续往后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。有啊首页曾经的做法 是在加载的时候把第一屏之后的图片地址缓存在Textarea标签中，待用户往下滚屏的时候才“惰性”加载。

2. 将外部脚本置底

前文有谈到，浏览器是可以并发请求的，这一特点使得其能够更快的加载资源，然而外链脚本在加载时却会阻塞其他资源，例如在脚本加载完成之前，它后面 的图片、样式以及其他脚本都处于阻塞状态，直到脚本加载完成后才会开始加载。如果将脚本放在比较靠前的位置，则会影响整个页面的加载速度从而影响用户体 验。解决这一问题的方法有很多，而最简单可依赖的方法就是将脚本尽可能的往后挪，减少对并发下载的 影响。

3. 异步执行inline脚本

inline脚本对性能的影响与外部脚本相比，是有过之而无不及。首页，与外部脚本一样，inline脚本在执行的时候一样会阻塞并发请求，除此之 外，由于浏览器在页面处理方面是单线程的，当inline脚本在页面渲染之前执行时，页面的渲染工作则会被推迟。简而言之，inline脚本在执行的时 候，页面处于空白状态。鉴于以上两点原因，建议将执行时间较长的inline脚本异步执行，异步的方式有很多种，例如使用script元素的defer属 性（存在兼容性问题和其他一些问题，例如不能使用document.write）、使用setTimeout，此外，在HTML5中引入了Web Workers的机制，恰恰可以解决此类问题。

4. Lazy Load Javascript

随着Javascript框架的流行，越来越多的站点也使用起了框架。不过，一个框架往往包括了很多的功能实现，这些功能并不是每一个页面都需要 的，如果下载了不需要的脚本则算得上是一种资源浪费-既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种，一种是为那些流量特别大的页面专门定制 一个专用的mini版框架，另一种则是Lazy Load。YUI则使用了第二种方式，在YUI的实现中，最初只加载核心模块，其他模块可以等到需要使用的时候才加载。

5. 将CSS放在HEAD中

如果将CSS放在其他地方比如BODY中，则浏览器有可能还未下载和解析到CSS就已经开始渲染页面了，这就导致页面由无CSS状态跳转到CSS状 态，用户体验比较糟糕。除此之外，有些浏览器会在CSS下载完成后才开始渲染页面，如果CSS放在靠下的位置则会导致浏览器将渲染时间推迟。

6. 减少不必要的HTTP跳转

对于以目录形式访问的HTTP链接，很多人都会忽略链接最后是否带’/'，假如你的服务器对此是区别对待的话，那么你也需要注意，这其中很可能隐藏了301跳转，增加了多余请求。具体参见下图，其中第一个链接是以无’/'结尾的方式访问的，于是服务器有了一次跳转。

7. 避免重复的资源请求

这种情况主要是由于疏忽或页面由多个模块拼接而成，然后每个模块中请求了同样的资源时，会导致资源的重复请求。出现的几率不大，但是还是要注意排查。

。。。

9.什么是CSRF攻击，如何预防

CSRF全程 Cross Site Request Forgery, 跨站域请求伪造.CSRF是一种夹持用户在已经登陆的web应用程序上执行非本意的操作的攻击方式。相比于XSS，CSRF是利用了系统对页面浏览器的信任，XSS则利用了系统对用户的信任。

防御CSRF攻击：

目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。

（1）验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。

这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。

即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。

（2）在请求地址中添加 token 并验证

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

（3）在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。

然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

10.script标签到defer和async属性有什么作用和区别

async属性，表示后续文档的加载和渲染与js脚本的加载和执行是并行进行的，即异步执行。

defer属性，加载后续文档的过程和js脚本的加载(此时仅加载不执行)是并行进行的(异步)，js脚本的执行需要等到文档所有元素解析完成之后，DOMContentLoaded事件触发执行之前。

区别

　　1.defer和async在网络加载过程是一致的，都是异步执行的；

　　2.两者的区别在于脚本加载完成之后何时执行，defer更符合大多数场景对应用脚本加载和执行的要求；

　　3.如果存在多个有defer属性的脚本，那么它们是按照加载顺序执行脚本的；而对于async，它的加载和执行是紧紧挨着的，无论声明顺序如何，只要加载完成就立刻执行，它对于应用脚本用处不大，因为它完全不考虑依赖。

转自链接：https://juejin.im/post/5ad4094e6fb9a028d7011069