面试

一、前言 因为项目中使用到了 WebSocket ，面试官在深挖项目经验的时候，也难免提到 WebSocket 相关的知识点，通过这篇文章再做一下总结。 二、什么是WebSocket WebSocket 是一种在单个TCP连接上进行全双工通信的协议。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。 在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。 WebSocket本质上一种计算机网络应用层的协议，用来弥补http协议在持久通信能力上的不足。 WebSocket 协议在2008年诞生，2011年成为国际标准。现在最新版本浏览器都已经支持了。 它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。 WebSocket 的其他特点包括： （1）建立在 TCP 协议之上，服务器端的实现比较容易。 （2）与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。 （3）数据格式比较轻量，性能开销小，通信高效。 （4）可以发送文本，也可以发送二进制数据。 （5）没有同源限制，客户端可以与任意服务器通信。 （6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。 ws://example.com:80/some/path 为什么需要 WebSocket？ 我们已经有了 HTTP 协议，为什么还需要另一个协议？它能带来什么好处？ 因为 HTTP 协议有一个缺陷：通信只能由客户端发起，不具备服务器推送能力。 举例来说，我们想了解查询今天的实时数据，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。 这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。我们只能使用“轮询”：每隔一段时候，就发出一个询问，了解服务器有没有新的信息。最典型的场景就是聊天室。轮询的效率低，非常浪费资源（因为必须不停连接，或者 HTTP 连接始终打开）。 在 WebSocket 协议出现以前，创建一个和服务端进双通道通信的 web 应用，需要依赖HTTP协议，进行不停的轮询，这会导致一些问题： 服务端被迫维持来自每个客户端的大量不同的连接 大量的轮询请求会造成高开销，比如会带上多余的header，造成了无用的数据传输。 http协议本身是没有持久通信能力的，但是我们在实际的应用中，是很需要这种能力的，所以，为了解决这些问题，WebSocket协议由此而生，于2011年被IETF定为标准RFC6455，并被RFC7936所补充规范。 并且在HTML5标准中增加了有关WebSocket协议的相关api，所以只要实现了HTML5标准的客户端，就可以与支持WebSocket协议的服务器进行全双工的持久通信了。 WebSocket 与 HTTP 的区别 WebSocket 与 HTTP的关系图： 相同点： 都是一样基于TCP的，都是可靠性传输协议。都是应用层协议。 ...

1. 概念 正向代理是一个位于客户端和目标服务器之间的代理服务器(中间服务器)。为了从原始服务器取得内容，客户端向代理服务器发送一个请求，并且指定目标服务器，之后代理向目标服务器转交并且将获得的内容返回给客户端。正向代理的情况下客户端必须要进行一些特别的设置才能使用。 反向代理正好相反。对于客户端来说，反向代理就好像目标服务器。并且客户端不需要进行任何设置。客户端向反向代理发送请求，接着反向代理判断请求走向何处，并将请求转交给客户端，使得这些内容就好似他自己一样，一次客户端并不会感知到反向代理后面的服务，也因此不需要客户端做任何设置，只需要把反向代理服务器当成真正的服务器就好了。 2. 区别 正向代理需要你主动设置代理服务器ip或者域名进行访问，由设置的服务器ip或者域名去获取访问内容并返回；而反向代理不需要你做任何设置，直接访问服务器真实ip或者域名，但是服务器内部会自动根据访问内容进行跳转及内容返回，你不知道它最终访问的是哪些机器。 正向代理是代理客户端，为客户端收发请求，使真实客户端对服务器不可见；而反向代理是代理服务器端，为服务器收发请求，使真实服务器对客户端不可见。 从上面的描述也能看得出来正向代理和反向代理最关键的两点区别： 是否指定目标服务器 客户端是否要做设置 下面用一张图来表示两者的差异： 正向代理与反向代理 正向代理中，proxy和client同属一个LAN，对server透明； 反向代理中，proxy和server同属一个LAN，对client透明。 实际上proxy在两种代理中做的事都是代为收发请求和响应，不过从结构上来看正好左右互换了下，所以把前者那种代理方式叫做正向代理，后者叫做反向代理。 从用途上来区分： 正向代理：正向代理用途是为了在防火墙内的局域网提供访问internet的途径。另外还可以使用缓冲特性减少网络使用率 反向代理：反向代理的用途是将防火墙后面的服务器提供给internet用户访问。同时还可以完成诸如负载均衡等功能 从安全性来讲： 正向代理：正向代理允许客户端通过它访问任意网站并且隐蔽客户端自身，因此你必须采取安全措施来确保仅为经过授权的客户端提供服务 反向代理：对外是透明的，访问者并不知道自己访问的是代理。对访问者而言，他以为访问的就是原始服务器 3. 使用场景 正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。正向代理还可以使用缓冲特性减少网络使用率。反向代理的典型用途是将 防火墙后面的服务器提供给Internet用户访问。反向代理还可以为后端的多台服务器提供负载平衡，或为后端较慢的服务器提供缓冲服务。 3.1 正向代理 从上面的介绍也就可以猜出来正向代理的至少一个功能（俗称翻墙），也即： 用户A无法访问facebook，但是能访问服务器B，而服务器B可以访问facebook。于是用户A访问服务器B，通过服务器B去访问facebook，，服务器B收到请求后，去访问facebook，facebook把响应信息返回给服务器B，服务器B再把响应信息返回给A。这样，通过代理服务器B，就实现了翻墙。 3.2 反向代理 从上面的介绍也可以猜出来反向代理的至少一个功能（比如负载均衡），也即： 假设用户A访问 **www.somesite.com/something.html**，但 www.somesite.com 上并不存在something.html页面，于是接收用户请求的该服务器就偷偷从另外一台服务器上取回来，然后返回给用户，而用户并不知道something.html页面究竟位于哪台机器上。 反向代理的作用就比较多了，这里简单列举一下： 保护和隐藏原始资源服务器 加密和SSL加速 负载均衡 缓存静态内容 压缩 减速上传 安全 外网发布 下面做两个简单介绍 保护和隐藏原始资源服务器 代理作用 用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答，从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。 负载均衡 负载均衡 当反向代理服务器不止一个的时候，我们甚至可以把它们做成集群，当更多的用户访问资源服务器B的时候，让不同的代理服务器Z（x）去应答不同的用户，然后发送不同用户需要的资源。 3.3 透明代理 透明代理比较类似正向代理的功能，差别在于客户端根本不知道代理的存在，它改编你的request，并会传送真实IP（使用场景就是公司限制网络的访问）。 比如为了工作效率或者安全，A公司屏蔽了QQ软件的使用。A公司的员工接上了网络，但发现无法使用qq。这就是透明代理捣的鬼。公司在内网和外网的中间插入一个透明代理，这个代理会根据规则抓取请求内容，遇到qq的请求我就把这个请求给屏蔽掉，这样就完成了透明屏蔽。当然了，如果你明白原理，就可以自己搞个正向代理来绕过公司的屏蔽。 Nginx作为时下最流行的HTTP服务器之一，同时它是一个反向代理服务器，提到反向代理服务器，有同学可能觉得这个概念很模糊，如果说到代理，他可能明白，但是再引出一个正向代理，估计懵了，笔者将尝试用浅显易懂的比方把这两个概念解释清楚。 正向代理 A同学在大众创业、万众创新的大时代背景下开启他的创业之路，目前他遇到的最大的一个问题就是启动资金，于是他决定去找马云爸爸借钱，可想而知，最后碰一鼻子灰回来了，情急之下，他想到一个办法，找关系开后门，经过一番消息打探，原来A同学的大学老师王老师是马云的同学，于是A同学找到王老师，托王老师帮忙去马云那借500万过来，当然最后事成了。不过马云并不知道这钱是A同学借的，马云是借给王老师的，最后由王老师转交给A同学。这里的王老师在这个过程中扮演了一个非常关键的角色，就是代理，也可以说是正向代理，王老师代替A同学办这件事，这个过程中，真正借钱的人是谁，马云是不知道的，这点非常关键。 我们常说的代理也就是只正向代理，正向代理的过程，它隐藏了真实的请求客户端，服务端不知道真实的客户端是谁，客户端请求的服务都被代理服务器代替来请求，知名的科学上网工具shadowsocks 扮演的就是典型的正向代理角色。在天朝用浏览器访问 www.google.com 时，被残忍的拒绝了，于是你可以在国外搭建一台代理服务器，让代理帮我去请求google.com，代理把请求返回的相应结构再返回给我。 _ 反向代理 大家都有过这样的经历，拨打10086客服电话，可能一个地区的10086客服有几个或者几十个，你永远都不需要关心在电话那头的是哪一个，叫什么，男的，还是女的，漂亮的还是帅气的，你都不关心，你关心的是你的问题能不能得到专业的解答，你只需要拨通了10086的总机号码，电话那头总会有人会回答你，只是有时慢有时快而已。那么这里的10086总机号码就是我们说的反向代理。客户不知道真正提供服务人的是谁。 反向代理隐藏了真实的服务端，当我们请求 www.baidu.com 的时候，就像拨打10086一样，背后可能有成千上万台服务器为我们服务，但具体是哪一台，你不知道，也不需要知道，你只需要知道反向代理服务器是谁就好了，www.baidu.com 就是我们的反向代理服务器，反向代理服务器会帮我们把请求转发到真实的服务器那里去。Nginx就是性能非常好的反向代理服务器，用来做负载均衡。 ...

TCP/IP提供了通过 IP地址 来连接到设备的功能，但对用户来讲，记住某台设备的IP地址是相当困难的，因此专门设计了一种字符串形式的主机命名机制，这些主机名与IP地址相对应。在IP地址与主机名之间需要有一种转换和查询机制，提供这种机制的系统就是域名系统DNS（Domain Name System）。 为什么要有DNS？ 互联网中，一台计算机与其他计算机通信时，通过 IP地址 唯一的标志自己。此时的IP地址就类似于我们日常生活中的电话号码。但是，这种纯数字的标识是比较难记忆的，而且数量也比较庞大。例如，每个IPv4地址是一个32位长的二进制数字，或者采用点分十进制展示成192.168.1.1这种格式，有接近43亿个的IPv4地址。DNS的作用就是将人类可读的名称转换为机器识别的IP地址，供计算机相互连接。DNS的工作原理和电话簿相似，都是管理名称和数字之间的映射关系。就像我们日常打电话，一般使用人名查找，很少直接输入电话号码一样。当我们上网打开某个网页、视频时，也很少直接使用IP地址，而是在浏览器里输入的URL地址，例如：https://www.huawei.com，这其实使用的就是计算机的名字，一般称为域名。 域名的构成 最初设备的域名由字符序列组成、所有设备的域名组成一个未分级的域名结构。未分级的域名结构存在命名冲突、管理维护复杂的缺点。因此，TCP/IP把DNS的域名设计成了分级的树状结构。每个申请加入Internet的国家都要向NIC注册一个顶级域名，顶级域采用组织模式和地理模式的划分模式，如cn代表中国、us代表美国等。 常见的顶级域名如下表所示。NIC将顶级域的管理权分派给由其指定的管理机构，由这些管理机构再对被授权管理的域继续进行划分，从而形成了二级域。负责划分二级域的管理机构可以授权其下属的管理结构，由它们继续划分域。由此下去，便形成了层次型的Internet域名体系结构。 顶级Internet域名 含义 com 商业组织 edu 教育机构 gov 政府机构 mil 军事部门 net 主要网络支持中心 int 国际组织 org 其他组织 国家代码 国家（按照地理模式划分） 从语法上讲，每一个域名都是有标号序列组成，而各标号之间用点（小数点）隔开。以www.huawei.com域名为例，从右到左依次是： com：顶级域名。代表商业组织。 huawei：二级域名，归属于某个公司自己的域名。 www：三级域名，表明某个公司提供的是什么服务，www代表普通网页。 DNS服务器、DNS客户端和DNS中继 网络中与DNS相关的设备角色包括DNS服务器、DNS客户端和DNS中继。 DNS服务器 DNS服务器是将域名指向对应IP地址的服务器。DNS服务器中保存了一张域名和与之相对应的IP地址的表，以解析消息的域名。 由于互联网连通的是全球资源，单一的域名服务器不足以支撑全部的地址转换操作，因此全球有多套域名服务器相互配合使用。 域名是分层结构，域名DNS服务器也是对应的层级结构。通过根域名服务器，依次请求顶级域名服务器和权威域名服务器，最终获取对应IP地址，并将该结果保存在本地域名服务器，以待下次DNS请求使用。当用户再次对同一域名发起访问时，可以直接从本地域名服务器获得结果，无需再次发起全球递归查询。 表1-2 DNS服务器的分类 分类 作用 根DNS服务器 根DNS服务器是最高层次的域名服务器，它知道所有顶级服务器的域名和IP地址，当本地域名服务器无法对域名进行解析时，首先对根域名服务器发起请求。 顶级域名服务器 顶级域名服务器负责管理该服务器下的所有二级域名，当收到DNS查询请求时，就会给权威域名服务器相应的回答。 权威域名服务器 负责某一个区域的域名服务器。当一个顶级域名服务器还不能给出最后查询回答时，就会告知下一步应当请求的权威域名服务器。 本地域名服务器 当一个主机发出DNS查询请求时，这个查询请求报文就发送给本地域名服务器。每一个互联网服务提供者ISP都可以拥有一个本地域名服务器。当本地域名服务器无法给出应答时，就会请求最高级的根域名服务器。 DNS客户端 DNS客户端的作用是接收用户程序（User Program）的DNS请求，并对其作出回应。作为DNS客户端的设备上一般具备以下能力： 启动DNS解析 要使用DNS客户端功能，需要在设备上打开DNS解析的开关。 指定服务器的IP地址 要进行DNS域名解析，需要在设备上指定DNS服务器的IP地址。这样才能把查询请求发动到正确的DNS服务器上进行解析。 指定DNS域后缀搜索列表 DNS客户端所访问的一些服务器或主机的域名后缀往往都是相同的。用户可以预先设置一些域名后缀，在域名解析的时候，用户只需要输入域名的部分字段，系统会自动将输入域名加上不同的后缀进行解析。例如，用户想查询域名“huawei.com”，那么可以在后缀列表中配置com，然后输入“huawei”，系统会自动将输入域名与后缀连接成“huawei.com”进行查询。 DNS中继 当DNS服务器的IP地址发生变化时，用户网络中每个DNS客户端上的配置都需要改变，这样工作量极大并且容易出错。此时，可以通过部署DNS中继解决该问题。DNS客户端上配置DNS中继的IP地址，DNS服务器的IP地址在DNS中继上配置。之后，DNS客户端会将DNS请求报文直接发送给DNS中继，由DNS中继将收到的DNS请求报文转发至DNS服务器。由此，当DNS服务器的IP地址发生变化时，仅需改变DNS中继上的配置即可，简化了网络管理。 DNS中继的工作原理 DNS客户端将DNS请求报文发送给DNS中继，即请求报文的目的地址为DNS中继的IP地址。 DNS中继收到请求报文后，将报文转发给DNS服务器，通过DNS服务器进行域名解析。 DNS域名解析过程 通过域名获取对应IP地址的过程称为域名解析。DNS域名解析分为以下两种方式： 静态域名解析 静态域名解析是通过静态域名解析表进行的，即手动建立域名和IP地址之间的对应关系表，该表的作用可以将一些常用的域名放入表中。当DNS客户端需要域名所对应的IP地址时，即到静态域名解析表中去查找指定的域名，从而获得所对应的IP地址，提高域名解析的效率 动态域名解析 动态域名解析需要专用的域名解析服务器（DNS服务器）运行域名解析服务器程序，提供从域名到IP地址的映射关系，负责接收客户提出的域名解析请求。 为提高查询速度，在解析域名时，首先采用静态域名解析的方法，如果静态解析不成功，再采用动态域名解析的方法。 ...

一、什么是跨域？ 1.什么是同源策略及其限制内容？ 同源策略是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSRF等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。 同源策略限制内容有： Cookie、LocalStorage、IndexedDB 等存储性内容 DOM 节点 AJAX 请求发送后，结果被浏览器拦截了 但是有三个标签是允许跨域加载资源： <img src=XXX> <link href=XXX> <script src=XXX> 2.常见跨域场景 当协议、子域名、主域名、端口号中任意一个不相同时，都算作不同域。不同域之间相互请求资源，就算作“跨域”。常见跨域场景如下图所示： 特别说明两点： 第一：如果是协议和端口造成的跨域问题“前台”是无能为力的。 第二：在跨域问题上，仅仅是通过“URL的首部”来识别而不会根据域名对应的IP地址是否相同来判断。“URL的首部”可以理解为“协议, 域名和端口必须匹配”。 这里你或许有个疑问：请求跨域了，那么请求到底发出去没有？ 跨域并不是请求发不出去，请求能发出去，服务端能收到请求并正常返回结果，只是结果被浏览器拦截了。你可能会疑问明明通过表单的方式可以发起跨域请求，为什么 Ajax 就不会?因为归根结底，跨域是为了阻止用户读取到另一个域名下的内容，Ajax 可以获取响应，浏览器认为这不安全，所以拦截了响应。但是表单并不会获取新的内容，所以可以发起跨域请求。同时也说明了跨域并不能完全阻止 CSRF，因为请求毕竟是发出去了。 二、跨域解决方案 1.jsonp 1) JSONP原理 利用 <script> 标签没有跨域限制的漏洞，网页可以得到从其他来源动态产生的 JSON 数据。JSONP请求一定需要对方的服务器做支持才可以。 2) JSONP和AJAX对比 JSONP和AJAX相同，都是客户端向服务器端发送请求，从服务器端获取数据的方式。但AJAX属于同源策略，JSONP属于非同源策略（跨域请求） 3) JSONP优缺点 JSONP优点是简单兼容性好，可用于解决主流浏览器的跨域数据访问的问题。缺点是仅支持get方法具有局限性,不安全可能会遭受XSS攻击。 4) JSONP的实现流程 声明一个回调函数，其函数名(如show)当做参数值，要传递给跨域请求数据的服务器，函数形参为要获取目标数据(服务器返回的data)。 创建一个<script>标签，把那个跨域的API数据接口地址，赋值给script的src,还要在这个地址中向服务器传递该函数名（可以通过问号传参:?callback=show）。 服务器接收到请求后，需要进行特殊的处理：把传递进来的函数名和它需要给你的数据拼接成一个字符串,例如：传递进去的函数名是show，它准备好的数据是show('我不爱你')。 最后服务器把准备的数据通过HTTP协议返回给客户端，客户端再调用执行之前声明的回调函数（show），对返回的数据进行操作。 在开发中可能会遇到多个 JSONP 请求的回调函数名是相同的，这时候就需要自己封装一个 JSONP函数。 // index.html function jsonp({ url, params, callback }) { return new Promise((resolve, reject) => { let script = document.createElement('script') window[callback] = function(data) { resolve(data) document.body.removeChild(script) } params = { ...params, callback } // wd=b&callback=show let arrs = [] for (let key in params) { arrs.push(`${key}=${params[key]}`) } script.src = `${url}?${arrs.join('&')}` document.body.appendChild(script) }) } jsonp({ url: 'http://localhost:3000/say', params: { wd: 'Iloveyou' }, callback: 'show' }).then(data => { console.log(data) }) 上面这段代码相当于向http://localhost:3000/say?wd=Iloveyou&callback=show这个地址请求数据，然后后台返回show('我不爱你')，最后会运行show()这个函数，打印出’我不爱你' ...

Cookie 和 Session HTTP 协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。 Session 是什么 客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个对象便是 Session 对象，存储结构为 ConcurrentHashMap。Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。 Session 如何判断是否是同一会话 服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），同时生成一个 sessionId ，并通过响应头的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客户端发送要求设置 Cookie 的响应； 客户端收到响应后，在本机客户端设置了一个 JSESSIONID=XXXXXXX 的 Cookie 信息，该 Cookie 的过期时间为浏览器会话结束； 接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ）， 然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。 Session 的缺点 Session 机制有个缺点，比如 A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。 Cookies 是什么 HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie，它是服务器发送到 Web 浏览器的一小块数据。服务器发送到浏览器的 Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器。通常，它用于判断两个请求是否来自于同一个浏览器，例如用户保持登录状态。 ...

HTTP 基础 HTTP 超文本传输协议 ，应用层协议。主要用于 Web 上传输超媒体文本的底层协议，经常在浏览器和服务器之间传递数据。通信就是以纯文本的形式进行。 HTTP 是无状态 无状态是 HTTP 协议对客户端请求状态没有进行存储，比如每次请求都需要重新登录 HTTP 是无连接 无连接主要是限制每次连接只处理一个请求。每次请求都是客户发起请求，服务端响应请求，然后就断开连接。这期间就是通过三次握手建立连接，四次挥手断开连接。每次请求即便是多次请求并请求同一个资源，服务端都无法判断是否是相同请求，都需要重新响应请求。 所以，为了解决客户端和服务端保持会话连接，通过 cookie 和 session 来记录 http 状态。 HTTP 的其他特点是简单快速，只需传送方法和路径就可以向服务端进行请求；还有支持传输任意类型的数据对象。 HTTPS 基础 https 是 http 的“升级”版本： HTTPS = HTTP+ SSL/TLS SSL 是安全层，TLS 是传输层安全，是SSL 的继承。使用SSL或TLS 可确保传输数据的安全性。 使用 HTTP 可能看到传输数据是： “这是明文信息” 使用 HTTPS 可能看到： “283hd9saj9cdsncihquhs99ndso” HTTPS 传输的不再是文本，而是二进制流，使得传输更高效，且加密处理更加安全。 HTTPS 的工作流程 1、客户端请求 HTTPS 请求并连接到服务器的 443 端口，此过程和请求 HTTP 请求一样，进行三次握手； 2、服务端向客户端发送数字证书，其中包含公钥、证书颁发者、到期日期 现比较流行的加解密码对，即公钥和私钥。公钥用于加密，私钥用于解密。所以服务端会保留私钥，然后发送公钥给客户端。 3、客户端收到证书，会验证证书的有效性。验证通过后会生成一个随机的 pre-master key。再将密钥通过接收到的公钥加密然后发送给服务端 4、服务端接收后使用私钥进行解密得到 pre-master key 5、获得 pre-master key 后，服务器和客户端可以使用主密钥进行通信。 ...

一、HTTP 状态码概述 1. 概念 当我们在浏览器输入URL并按下Enter键时，浏览器就会向站点的服务器发送一个HTTP请求，服务器接收并处理请求，然后将相关资源和HTTP标头一起返回。可以在浏览器的Network中查看 HTTP 的请求状态码： 维基百科中对HTTP状态码的解释： HTTP状态码（HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码被分为五类，状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的，但是可以提供任何可读取的替代方案。 除非另有说明，状态码是HTTP/1.1标准（RFC 7231）的一部分。 HTTP 状态代码是从 Web 服务器发送的 3 位代码（如 200 OK 或 404 Not Found），用于让我们和搜索引擎知道请求中是否存在任何错误或服务器尝试处理请求时是否存在任何问题。 2. 分类 应用通常就是客户端向服务器发出请求，服务器做出响应。状态码就是让我们知道 HTTP 请求是成功、失败还是其他。HTTP状态码通常分为五类： 类别 定义 描述 1xx Informational(信息性状态码) 接受的请求正在处理 2xx Success(成功状态码) 请求正常处理完毕 3xx Redirection(重定向状态码) 需要进行附加操作来完成请求 4xx Client Error (客户端错误状态码) 服务器无法处理请求 5xx Server Error(服务器错误状态码) 服务器处理请求出错 3. 重要性 HTTP 状态代码对于诊断应用问题很重要，例如网络服务器是否无法正常工作且无法提供页面等。快速发现这些问题对于开发人员和搜索引擎提供良好的体验非常重要。那为什么 HTTP 状态代码和错误对搜索引擎优化 (SEO) 很重要呢？ ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 面试时间： 60分钟 本轮共 16 道题。答案默认折叠，便于先自行作答。 1. 前端和后端有什么区别？ 题目要点 职责分工不同，前端关注用户体验，后端关注业务逻辑，但需要密切协作完成产品开发。 参考答案 前端和后端在职责、技术栈、关注点等方面都有明显区别。前端主要负责用户界面和交互体验，使用HTML、CSS、JavaScript等技术，关注的是如何让用户更好地使用产品。后端则负责业务逻辑处理、数据存储、系统架构等，使用Java、Python、Node.js等语言，关注的是系统的稳定性、安全性和性能。 工作内容上，前端需要将设计稿转化为可交互的页面，处理用户输入、数据展示、页面跳转等；后端需要设计数据库结构、编写API接口、处理业务逻辑、确保数据安全等。思维方式也不同，前端更多从用户角度思考问题，注重体验和视觉效果；后端更多从系统角度思考，注重逻辑严谨性和数据一致性。 但两者并不是完全独立的，现代Web开发中前后端需要密切协作，通过API接口进行数据交互，共同完成产品功能。随着技术发展，界限也在模糊，比如Node.js让前端开发者也能做后端开发。 2. 如果现在有一个需要前后端协作的功能开发需求，你认为前端和后端在沟通和配合上最重要的是什么？ 题目要点 API接口设计一致性、数据格式规范、清晰的沟通方式、完善的联调流程是协作的关键。 参考答案 最重要的是在项目开始前就API接口的设计达成一致。这包括接口的URL设计、请求方法、参数格式、返回数据结构、错误处理方式等。清晰的接口文档能够避免后续很多沟通成本和返工问题。 其次是建立统一的数据格式规范。比如时间格式、状态码定义、分页参数等，这些看似细节的问题如果不提前约定，会在开发过程中产生很多摩擦。还要约定好错误处理机制，什么情况下返回什么状态码，错误信息的格式等。 沟通方式也很重要。建议使用统一的协作工具，如Postman分享API文档，或者使用Swagger等工具生成接口文档。定期的技术评审会议也必不可少，确保双方对需求理解一致。 最后是要建立联调测试的流程。前端可以先用Mock数据开发，后端接口完成后再进行联调，这样能够并行开发，提高效率。 3. 项目是怎么接到的？ 题目要点 通过课程项目、实验室项目、实习项目和个人项目等多种渠道积累开发经验。 参考答案 主要通过几个渠道获得项目经验。首先是课程项目，在Web开发、软件工程等课程中，老师会布置一些实际的开发任务，比如开发一个在线学习平台、图书管理系统等。这些项目虽然规模不大，但涵盖了完整的开发流程。 实验室项目是另一个重要来源。导师的研究项目中经常需要开发一些数据展示、实验管理的Web系统，会让研究生参与开发。这类项目更贴近实际应用，需求也更复杂一些。 还有就是实习期间参与的公司项目。虽然作为实习生主要是辅助开发，但能够接触到真实的商业项目，了解完整的产品开发流程。 另外也会主动寻找一些开源项目参与贡献，或者自己发起一些小项目来练习新技术。比如看到一个有趣的API，就会想着用它开发一个小应用来练手。 4. 讲一个你觉得最有成就感的项目 题目要点 科研数据可视化平台，解决了性能优化和数据适配的技术挑战，最终被多个实验室采用。 参考答案 最有成就感的是在实验室开发的一个科研数据可视化平台。这个项目是为了帮助实验室的研究人员更好地分析和展示实验数据。 项目的挑战在于需要处理大量的科研数据，并且要支持多种图表类型的动态切换。数据量大的时候页面会卡顿，用户体验很差。通过学习和实践，使用了虚拟滚动技术处理大列表，用Web Workers在后台处理数据计算，用Canvas替代DOM渲染复杂图表，最终解决了性能问题。 另一个难点是不同研究方向的数据格式差异很大，需要设计一个灵活的数据适配层。通过抽象出通用的数据模型，并提供配置化的字段映射功能，让系统能够适应不同的数据格式。 最终这个平台不仅在我们实验室使用，还被其他几个实验室采用，帮助研究人员提高了数据分析效率。看到自己开发的系统真正解决了实际问题，并且得到用户认可，这种成就感是最大的收获。 5. 前端怎么样才是一种好的体验？ 题目要点 性能优化、交互反馈改进、错误处理优化、移动端适配、基于反馈的持续改进。 参考答案 好的前端体验应该是用户感知不到技术存在的体验。首先是性能方面，页面加载要快，交互要流畅，用户不应该感受到明显的等待时间。这需要做好资源优化、懒加载、缓存策略等。 界面设计要直观易懂，用户能够快速找到需要的功能，操作流程要符合用户习惯。响应式设计也很重要，在不同设备上都能提供良好的体验。 交互反馈要及时准确。用户的每个操作都应该有明确的反馈，比如按钮点击效果、加载状态提示、操作结果通知等。错误处理要友好，当出现问题时，要给用户清晰的错误信息和解决建议。 可访问性也是好体验的重要组成部分。要考虑到不同能力用户的需求，比如键盘导航、屏幕阅读器支持等。 最后是要保持一致性，整个应用的交互模式、视觉风格、信息架构都要保持统一，让用户形成稳定的使用预期。 6. 平时怎么学习前端的？ 题目要点 系统性学习、实践项目、阅读源码、关注社区、记录总结、保持好奇心。 参考答案 学习前端主要通过几个渠道。首先是系统性学习，通过在线课程平台如慕课网、极客时间等学习完整的技术体系。看技术书籍也很重要，比如《JavaScript高级程序设计》、《CSS权威指南》等经典书籍能够建立扎实的基础。 实践是最重要的学习方式。会跟着教程做一些小项目，然后尝试改进和扩展功能。GitHub上有很多优秀的开源项目，通过阅读源码能够学到很多最佳实践。 技术社区是获取最新信息的重要渠道。经常浏览掘金、思否、MDN等网站，关注前端技术的发展趋势。参加一些技术分享会和线上讲座，能够了解行业动态和实际应用经验。 建立了自己的学习笔记系统，将学到的知识点整理成文档，定期回顾和总结。还会写一些技术博客，通过输出来加深理解。 保持好奇心很重要，看到新技术会主动去了解和尝试。比如最近学习了WebAssembly、微前端等新技术，虽然可能暂时用不到，但能够拓宽技术视野。 7. 最近了解到的新技术讲一下 题目要点 WebAssembly提供高性能计算能力，微前端解决大型应用架构问题，新CSS特性增强布局能力。 ...

← 已是第一轮 · 返回本次面经 · 第 2 轮 → 本轮概述： 比较简单，主要考察一些前端基础知识。 本轮共 21 道题。答案默认折叠，便于先自行作答。 1. 请你简单介绍一下自己，你研究生期间学了哪些课程？ 题目要点 计算机专业研究生，系统学习了相关理论课程，对前端技术有浓厚兴趣并有实践经验。 参考答案 本科学习计算机科学与技术专业，研究生阶段继续深入学习相关领域知识。研究生期间的核心课程包括高级数据结构与算法分析、分布式系统、软件架构设计、人工智能原理、计算机图形学、高级数据库系统等。同时选修了前端开发相关的课程，如Web技术与应用、用户界面设计等。在学习过程中，对前端技术产生了浓厚兴趣，通过自学掌握了React、Vue等主流框架，并在多个课程项目中实践应用。研究方向偏向Web技术和用户体验，毕业论文也是围绕前端性能优化展开的研究。 2. 在之前参与的项目里，你主要担任什么职责，都负责了哪些模块的开发呀？ 题目要点 主要通过课程项目、实验室项目和实习积累经验，担任前端开发角色，涉及多种常见功能模块。 参考答案 主要参与过学校的课程项目、实验室项目以及一段实习经历。在课程项目中，通常担任前端开发的主要负责人，负责整体页面架构设计和核心功能实现。具体开发过在线学习平台的用户界面、数据可视化展示模块、以及实时聊天功能。在实验室项目中，参与开发了一个科研数据管理系统，主要负责数据录入界面、图表展示组件和用户权限管理前端部分。实习期间，在导师指导下参与了公司内部管理系统的开发，负责表单处理、文件上传和基础的增删改查功能。虽然项目规模不算很大，但通过这些实践对前端开发的完整流程有了较好的理解。 3. HTML5 相较于之前的版本有哪些新特性？ 题目要点 语义化标签、原生多媒体支持、Canvas绘图、增强表单、Web存储、丰富的API等新特性。 参考答案 HTML5相比之前版本引入了很多重要特性。语义化标签是最显著的改进，新增了header、nav、main、article、section、aside、footer等标签，让页面结构更清晰，也有利于SEO优化。多媒体支持方面，audio和video标签可以直接嵌入音视频内容，不再依赖Flash等插件。Canvas元素提供了强大的2D绘图能力，可以用JavaScript动态绘制图形和动画。表单功能得到增强，新增了email、url、date、range等输入类型，以及内置的表单验证功能。Web存储API包括localStorage和sessionStorage，提供了比cookie更好的本地存储方案。还有地理位置API、拖拽API、Web Workers等，为Web应用提供了更丰富的功能支持。 4. 浏览器缓存这块，你是怎么理解的？ 题目要点 性能优化机制，通过HTTP头部控制，能减少网络请求但需要合理配置避免更新问题。 参考答案 浏览器缓存是Web性能优化的重要机制，通过在本地存储已请求的资源来减少网络请求，提升页面加载速度。在学习过程中了解到，缓存主要通过HTTP协议的相关头部来控制。当浏览器首次请求资源时，服务器会返回资源内容以及缓存相关的响应头，浏览器根据这些头部信息决定是否缓存资源以及缓存多长时间。再次请求相同资源时，浏览器会先检查本地缓存，如果缓存有效就直接使用，否则向服务器发起请求。这个机制在减少服务器负载、节省带宽、提升用户体验方面都有重要作用。在实际项目中也遇到过缓存导致的问题，比如更新代码后用户看不到最新内容。 5. 浏览器缓存主要有哪些类型？ 题目要点 HTTP缓存（强缓存、协商缓存）、内存缓存、磁盘缓存、Service Worker缓存等多层次缓存机制。 参考答案 浏览器缓存可以分为几个层次。HTTP缓存是最主要的类型，包括强缓存和协商缓存两种机制。强缓存通过Cache-Control和Expires头部设置过期时间，在有效期内直接使用本地缓存。协商缓存则通过ETag和Last-Modified与服务器确认资源是否有更新。除了HTTP缓存，还有内存缓存和磁盘缓存的区别，内存缓存速度快但容量小，磁盘缓存容量大但速度相对较慢。Service Worker缓存是比较新的技术，可以通过编程方式控制缓存策略，支持离线应用。另外还有DNS缓存、CDN缓存等，虽然不在浏览器内部，但也是整个缓存体系的组成部分。 6. 你有没有遇到过因为浏览器缓存带来的问题？比如，用户没有获取到最新的资源这种情况，你是怎么解决的？ 题目要点 通过版本号、时间戳、文件hash等方式解决缓存更新问题，构建工具可以自动化处理。 参考答案 在做课程项目和实习期间确实遇到过这类问题。最典型的情况是修改了CSS或JavaScript文件后，浏览器仍然加载旧版本的文件，导致页面显示异常或功能不正常。刚开始遇到这种问题时比较困惑，后来学习了解到是缓存机制导致的。解决方法主要有几种：最简单的是在开发阶段使用浏览器的强制刷新功能，或者在开发者工具中禁用缓存。对于生产环境，学会了在文件名后添加版本号或时间戳参数来强制更新，比如style.css?v=1.0.1。后来了解到webpack等构建工具可以自动为文件生成hash值，这样文件内容改变时文件名也会改变，从而绕过缓存。这个问题让我深刻理解了缓存机制的重要性和复杂性。 7. 说说 sessionStorage 和 localStorage 的区别 题目要点 主要区别在生命周期和作用域，sessionStorage会话级，localStorage持久化且可跨页面共享。 参考答案 这两个都是HTML5提供的Web存储API，在项目中都有使用过。 最主要的区别是生命周期不同：sessionStorage只在当前浏览器标签页的会话期间有效，关闭标签页后数据就会被清除；而localStorage的数据会持久保存在用户设备上，除非主动删除或者达到存储限制。 作用域方面也不同，sessionStorage的数据只能在当前标签页内访问，不同标签页之间是隔离的；localStorage则可以在同一域名下的所有页面间共享数据。 在实际使用中，sessionStorage适合存储临时的会话相关数据，比如表单的临时保存；localStorage更适合存储用户偏好设置、购物车内容等需要跨会话保持的信息。 8. 除了它们的存储大小区别外，还有哪些不同？ 题目要点 事件机制、安全特性、使用场景和数据共享能力等方面存在差异。 参考答案 除了生命周期差异，还有一些其他区别。数据共享机制上，localStorage支持storage事件，当其他页面修改localStorage数据时，当前页面可以监听到这个变化，这在多标签页应用中很有用；而sessionStorage不支持这种跨页面的事件通知。安全性方面，sessionStorage由于其会话特性，数据泄露的风险相对较小。在浏览器兼容性上，两者的支持程度基本一致，都是HTML5的特性。使用场景也有明显区别：sessionStorage常用于单页面应用的状态管理、表单数据的临时保存等；localStorage则用于用户设置、主题偏好、离线数据缓存等需要持久化的场景。在移动端开发中，还需要考虑存储空间限制和清理策略。 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮共 3 道题。答案默认折叠，便于先自行作答。 1. 如何理解业务与技术的关系，如何将业务需求转化为技术方案 题目要点 解释业务与技术的相互依赖和促进关系 梳理需求理解到方案设计的完整流程 强调沟通、验证和持续优化的重要性 结合案例体现实际落地思路 警示脱节风险，体现系统思考 参考答案 考察点 ● 理解业务与技术的相辅相成关系 ● 掌握业务需求分析和技术方案设计流程 ● 能将抽象业务目标拆解为具体技术实现路径 ● 体现跨部门沟通和协作能力 参考答案 一、业务与技术的关系理解 相辅相成：业务是技术的驱动力，技术是业务落地的支撑。 业务需求为核心：技术方案应围绕业务目标服务，解决实际问题，促进业务增长。 技术赋能业务创新：通过技术提升效率、优化体验、开拓新业务模式。 动态迭代：业务变化带来技术调整，技术创新反哺业务拓展，形成良性循环。 二、将业务需求转化为技术方案的步骤 1. 需求理解与梳理 深入沟通，明确业务背景、目标及关键痛点。 梳理业务流程，明确输入输出及核心功能点。 识别非功能性需求，如性能、安全、可扩展性。 2. 方案调研与评估 研究现有技术栈及解决方案的适用性。 评估技术选型的可行性、成本、风险与团队能力。 结合业务优先级确定技术方案核心方向。 3. 技术方案设计 架构设计：整体技术架构、模块划分、接口设计。 技术细节：选用框架、数据库设计、接口协议、安全机制等。 性能与安全：设计性能优化点和安全防护方案。 4. 方案验证与沟通 原型或PoC验证方案可行性。 向业务团队和相关部门说明方案，获取反馈和支持。 根据反馈调整方案，确保与业务需求匹配。 5. 实施与持续优化 制定详细的开发计划和质量保障措施。 迭代交付，及时根据业务变化调整技术方案。 建立监控和反馈机制，确保方案持续满足业务目标。 三、实际案例示范 针对用户增长业务需求，设计可扩展的用户行为分析系统。 技术团队结合业务需求选用微服务架构，支持快速迭代和多渠道接入。 通过技术方案提升数据处理效率，助力业务决策精准化。 四、常见误区与面试陷阱 ❌ 技术方案脱离业务需求，造成资源浪费和低效。 ❌ 业务需求不明确，导致方案反复修改或失焦。 ❌ 缺少跨团队沟通，信息孤岛影响方案落地。 ❌ 忽视非功能性需求，如安全和性能，影响用户体验。 五、总结观点 业务和技术密不可分，技术方案的设计必须紧扣业务目标，基于深入理解的业务需求进行科学规划和实施。通过有效沟通与验证，确保技术方案既满足当前业务，又具备扩展能力，实现技术对业务的最大赋能。 ...