2024前端面试系列--网络篇

前言

本文是我的前端面试系列的网络篇,汇总整理了网络相关的常见面试题,后续的复习过程中随时会对本文查漏补缺。复习这部分内容的时候,感觉又回到了大学时期的“计算机网络”课堂。
每个题目后面的推荐内容或参考链接,个人认为其阅读价值更高,值得仔细研读。

本文是 网络篇 的内容,其他章节内容更新后可在专栏查看:

  • 2024前端面试系列--Vue 篇

  • 2024前端面试系列-- JS 篇

  • 2024前端面试系列--HTML & CSS篇

  • 2024前端面试系列-- webpack & Git篇

网络相关的常见面试题

什么是 HTTP?

HTTP (HyperText Transfer Protocol),即超文本传输协议,是一种实现网络通信的规范。它定义了客户端和服务器之间交换报文的格式和方式,默认使用的是80端口,其底层使用TCP作为传输层协议,保证了数据传输的可靠性。

特点:

  • 简单快速:客户端向服务器请求服务时,只需传送请求方法和路径。由于HTTP协议简单,使得HTTP服务器的规模小,因而通信速度很快。

  • 灵活:HTTP允许传输任意类型的数据对象。

  • 无连接:限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。

  • 无状态:HTTP协议无法根据之前的状态进行本次的请求处理。

  • 明文:HTTP是以明文的形式传递内容。

HTTP 和 HTTPS 的区别?

HTTPSHTTP协议的安全版本。HTTPS的出现主要是为了解决HTTP明文传输内容导致其不安全的特性。为保证数据加密传输,让HTTP运行安全的SSL/TLS协议上,即 HTTPS = HTTP + SSL/TLS。通过SSL证书来验证服务器的身份,并为浏览器和服务器之间的通信进行加密。

二者的区别:

  • 安全性:HTTP协议的数据传输是明文的,是不安全的;HTTPS 使用了SSL/TLS协议进行加密处理,相对更加安全。

  • 连接方式:二者使用的连接方式不同,HTTP是三次握手,HTTPS是三次握手+数字证书。

  • 默认端口:HTTP的默认端口是80HTTPS的默认端口是443

  • 响应速度:由于HTTPS需要进行加解密过程,因此速度不如HTTP

  • 费用:HTTPS需要使用SSL证书,功能越强大的证书其费用越高;HTTP不需要。

HTTP 1.0 和 1.1 的区别?

  1. 连接:HTTP 1.0默认使用非持久连接,HTTP 1.1则默认使用持久连接。HTTP 1.1通过使用持久连接来使多个HTTP请求复用同一个TCP连接,避免了HTTP 1.0中使用非持久连接造成的每次请求都需要建立连接的时延。

  2. 缓存:HTTP 1.0主要使用header中的If-Modified-SinceExpires 来做为缓存判断的标准;HTTP 1.1则引入了更多的缓存控制策略,例如:EtagIf-Unmodified-SinceIf-MatchIf-None-Match等更多可供选择的缓存头来控制缓存策略。

  3. 资源请求:HTTP 1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能;HTTP 1.1则在请求头引入了range 头域,它允许只请求资源的某个部分,即返回码是 206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。

  4. host:HTTP 1.1引入了host,用来指定服务器的域名。

  5. 方法:HTTP 1.1相较于HTTP 1.0新增了许多方法,如:putdeleteoptions等。

HTTP 状态码有哪些?

状态码第一位数字决定了不同的响应状态:
1xx表示请求已被接受,需要继续处理;
2xx表示请求成功;
3xx表示重定向;
4xx表示客户端错误;
5xx表示服务端错误。

常见的状态码:

  • 101:服务器根据客户端的请求切换协议,主要用于websockethttp2升级

  • 200:请求已成功,请求所希望的数据将随响应一起返回。

  • 201:请求成功并且服务器创建了新的资源。

  • 202:服务器已接受响应请求,但尚未处理。

  • 301:请求的网页已永久移动至新的位置。

  • 302:临时重定向/临时转移。服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。

  • 304:本次获取到的内容是读取缓存中的数据,会每次去服务器校验。

  • 401:请求需要进行身份验证,尚未认证,没有登录网站。

  • 403:禁止访问,服务器拒绝请求。

  • 404:服务器没有找到相应资源。

  • 500:服务器遇到错误,无法完成对请求的处理。

  • 503:服务器无法使用。

TCP 的三次握手和四次挥手?

三次握手🤝:

  1. 第一次握手:客户端给服务器发送一个SYN报文。

  2. 第二次握手:服务器收到SYN报文后,应答一个ACK报文,同时发出自己的SYN报文,即应答了一个SYN + ACK报文。

  3. 第三握手:客户端收到SYN + ACK报文后,回应一个ACk报文。服务器收到ACK报文之后,三次握手完毕。

四次挥手🙋:

  1. 第一次挥手:客户端认为没有数据需要继续发送,于是向服务器发送一个FIN报文,申请断开客户端到服务器端的连接,报文中同时会指定一个序列号seq(等于已传送数据的最后一个字节的序号加1)。此时,客户端进入FIN_WAIT_1状态。

  2. 第二次挥手:服务器接收到FIN报文后,向客户端发送一个确认报文ACK,表示已经接收到了客户端释放连接的请求,以后不会再接收客户端发送过来的数据。同时会把客户端报文中的序列号seq加1,作为ACK报文中的序列号值。此时,服务端处于CLOSE_WAIT状态。客户端接收到报文之后,进入FIN_WAIT_2状态,等待服务器发送连接释放报文(由于TCP连接是全双工的,此时客户端到服务区器的连接已释放,但是服务器仍可以发送数据给客户端)。

  3. 第三次挥手:服务器端发送完所有的数据,会向客户端发送一个FIN报文,申请断开服务器端到客户端的连接。此时,服务器进入LAST_ACK 状态。

  4. 第四次挥手:客户端接收到FIN报文之后,向服务器发送一个ACK报文作为应答,且把服务器报文中的序列号值加1作为ACK报文的序列号值。此时,客户端就进入TIME_WAIT状态。需要注意的是,该阶段会持续一段时间,以确保服务器收到了该ACK报文。这个时间是 2 * MSL(最长报文段时间),如果在这个时间内,没有收到服务器的重发请求,时间过后,客户端就进入CLOSED状态;如果收到了服务器的重发请求就需要重新发送确认报文。服务器只要一收到ACK报文,就会立即进入CLOSED状态。

改成两次握手可以不?

简答:
这个问题的本质是,信道不可靠,但是通信双方需要就某个问题达成一致。三次通信是理论上的最小值。(你品,细品 ^_^)

详细的说:
三次握手可以理解为了客户端和服务器互相确认对方的发送和接收能力。如果是两次握手,可以确定服务器的发送和接收能力,但只能确定客户端的发送能力,无法确认其接收能力。另外,如果是两次握手的话,可能会因为网络阻塞等原因会发送多个请求报文,延时到达的请求又会与服务器建立连接,浪费服务器的资源。

GET 和 POST 的区别?

  1. 参数位置:GET请求的参数是放在 url 中,POST请求放在请求体 body 中。

  2. 参数长度:GET请求在 url 中传递的参数有长度限制(主要是因为浏览器对 url 长度有限制),POST则没有。

  3. 参数的数据类型:GET只接受ASCII字符,而POST没有限制。

  4. 安全:POSTGET安全,因为数据在地址栏上不可见。但是从传输角度考虑,二者都是不安全的,因为HTTP是明文传输。

  5. 幂等性:GET是一个幂等的请求;POST不是。(幂等,指同⼀个请求⽅法执⾏多次和仅执⾏⼀次的效果完全相同)

  6. 缓存:GET请求会被浏览器主动cache,而POST不会,除非手动设置。

如何解决跨域问题?

  • JSONP:Jsonp(JSON with Padding) 是 json 的一种"使用模式",可以让网页从别的域名(网站)那获取资料,即跨域读取数据。ajax 请求受同源策略影响,不允许进行跨域请求,而 script 标签 src 属性中的链接却可以访问跨域的 js 脚本,利用这个特性,服务端不再返回 JSON 格式的数据,而是返回一段调用某个函数的 js 代码,在 src 中进行了调用,这样实现了跨域。

  • CORS:CORS(Cross-origin resource sharing)跨域资源共享,服务器设置对 CORS 的支持。其原理是,服务器设置 Access-Control-Allow-Origin HTTP响应头之后,浏览器将会允许跨域请求。实现CORS通信的关键是服务器。只要服务器实现了CORS接口,就可以跨源通信。

  • proxy代理:最常用多方式。通俗点说就是客户端浏览器发起一个请求会存在跨域问题,但是服务端向另一个服务端发起请求并无跨域,因为跨域问题归根结底源于同源策略,而同源策略只存在于浏览器。那么我们是不是可以通过 Nginx 配置一个代理服务器,反向代理访问跨域的接口,并且我们还可以修改 Cookie 中 domain 信息,方便当前域 Cookie 写入。

正向代理和反向代理?

正向代理隐藏了真实的请求客户端,服务端不知道真实的客户端是谁,客户端请求的服务都被代理服务器代替来请求。

反向代理隐藏了真实的服务端,当发送一个请求时,其背后可能有很多台服务器为我们服务,但具体是哪一台,我们不知道,也不需要知道,我们只需要知道反向代理服务器是谁就好了,反向代理服务器会帮我们把请求转发到真实的服务器那里去。反向代理器一般用来实现负载平衡。

DNS 协议?

  1. 概念:
    DNS(Domain Namse System),域名系统,是进行域名和其相应IP地址进行转换的服务器。可以将DNS理解为一个翻译官,负责把域名转换为相应的IP地址。DNS协议运行在UDP协议之上,使用53号端口。

  2. 域名:
    域名是一个具有层次的结构,如下:

    主机名.次级域名.顶级域名.根域名
    
    host.sld.tld.root
    
    

    需要注意的是,根域名.root对于所有域名都是一样的,所以平时是省略的。

    根据域名的层级结构,管理不同层级域名的服务器,可以分为根域名服务器顶级域名服务器权限域名服务器。除此之外,还有电脑默认的本地域名服务器

  3. 查询方式:
    DNS查询方式分为递归查询迭代查询两种。所谓递归查询,就是A向B请求,如果B不知道所请求的内容,则B将继续向上请求,直到获得所需的内容,然后将内容返回给A。迭代查询,就是A向B请求,如果B不知道,则B会告诉A如何获得该内容,让A继续去请求。

  4. 域名缓存:
    域名服务器会缓存域名和IP之间的映射。分为两种缓存方式:
    浏览器缓存:浏览器在获取网站域名的地址后会对其进行缓存,减少网络请求的损耗。
    操作系统缓存:操作系统的缓存其实是用户自己配置的 hosts 文件。

  5. 完整解析过程:

  • 首先搜索浏览器的 DNS 缓存,缓存中维护一张域名与 IP 地址的对应表

  • 若没有命中,则继续搜索操作系统的 DNS 缓存

  • 若仍然没有命中,则操作系统将域名发送至本地域名服务器,本地域名服务器查询自己的 DNS 缓存,查找成功则返回结果

  • 若本地域名服务器的 DNS 缓存没有命中,则本地域名服务器向上级域名服务器进行查询,通过以下方式进行迭代查询
    • 首先本地域名服务器向根域名服务器发起请求,根域名服务器返回顶级域名服务器的地址

    • 本地域名服务器拿到这个顶级域名服务器的地址后,向其发起请求,获取权限域名服务器的地址

    • 本地域名服务器根据权限域名服务器的地址向其发起请求,最终得到该域名对应的 IP 地址

  • 本地域名服务器将得到的 IP 地址返回给操作系统,同时自己将 IP 地址缓存起来

  • 操作系统将 IP 地址返回给浏览器,同时自己也将 IP 地址缓存起来

  • 至此,浏览器就得到了域名对应的 IP 地址,并将 IP 地址缓存起来

从输入URL到看到页面的过程,发生了什么?

  1. url解析:首先会判断输入的是一个合法 url还是关键词,并根据输入的内容进行相应的操作。

  2. 查找缓存:浏览器会判断所请求的资源是否在浏览器缓存中,以及是否失效。如果没有失效就直接使用;如果没有缓存或失效了,就继续下一步。

  3. DNS解析:此时需要获取url中域名对应的IP地址。浏览器会依次查看浏览器缓存操作系统缓存中是否有ip地址,如果缓存中没有就会向本地域名服务器发起请求,获取ip地址。本地域名服务器也会先检查缓存,有则直接返回;如果也没有,则采用迭代查询方式,向上级域名服务器查询。先向根域名服务器发起请求,获取顶级域名服务器的地址;再向顶级域名服务器发起请求以获取权限域名服务器地址;然后向权限域名服务器发起请求并得到url中域名对应的IP地址。

  4. 建立TCP连接:根据ip地址,三次握手与服务器建立TCP连接。

  5. 发起请求:浏览器向服务器发起HTTP请求。

  6. 响应请求:服务器响应HTTP请求,将相应的HTML文件返回给浏览器。

  7. 关闭TCP连接四次挥手关闭TCP连接。

  8. 渲染页面:浏览器解析HTML内容,并开始渲染。浏览器渲染过程[11]如下:
    • 构建DOM树:词法分析然后解析成DOM树,DOM树是由DOM元素及属性节点组成,树的根是document对象。

    • 构建CSS规则树:生成CSS 规则树。

    • 构建渲染树:将DOM树和CSS规则树结合,构建出渲染树。

    • 布局:计算每个节点的位置。

    • 绘制:使用浏览器的UI接口进行绘制。

即时通讯的实现方式?

主要有四种方式,它们分别是轮询长轮询(comet)长连接(SSE)WebSocket。它们大体可以分为两类,一种是在HTTP基础上实现的,包括短轮询、comet和SSE;另一种不是在HTTP基础上实现是,即WebSocket。

  1. 轮询
    短轮询的基本思路就是浏览器每隔一段时间向浏览器发送http请求,服务器在收到请求后,不论是否有数据更新,都直接进行响应。这种方式实现的即时通信,本质上还是浏览器发送请求,服务器接受请求的一个过程,通过让客户端不断的进行请求,使得客户端能够模拟实时地收到服务器端的数据的变化。
    优点:比较简单,易于理解,实现起来没有什么技术难点。
    缺点:由于需要不断的建立http连接,严重浪费了服务器端和客户端的资源。

  2. 长轮询
    当服务器收到客户端发来的请求后,服务器端不会直接进行响应,而是先将这个请求挂起,然后判断服务器端数据是否有更新。如果有更新,则进行响应;如果一直没有数据,则到达一定的时间限制(服务器端设置)才返回。
    优点:长轮询和短轮询比起来,明显减少了很多不必要的http请求次数,相比之下节约了资源。
    缺点:连接挂起也会导致资源的浪费。

  3. 长连接
    SSE是HTML 5新增的功能,全称为Server-Sent Events。它可以允许服务推送数据到客户端。SSE在本质上就与之前的长轮询、短轮询不同,虽然都是基于http协议的,但是轮询需要客户端先发送请求。而SSE最大的特点就是不需要客户端发送请求,可以实现只要服务器端数据有更新,就可以马上发送到客户端。 优点:不需要建立或保持大量的客户端发往服务器端的请求,节约了很多资源,提升应用性能;实现非常简单,并且不需要依赖其他插件。

  4. WebSocket
    WebSocket是HTML 5定义的一个新协议,与传统的http协议不同,该协议可以实现服务器与客户端之间全双工通信。简单来说,首先需要在客户端和服务器端建立起一个连接,这部分需要http。连接一旦建立,客户端和服务器端就处于平等的地位,可以相互发送数据,不存在请求和响应的区别。
    优点:实现了双向通信。
    缺点:服务器端的逻辑非常复杂。

最后

如果你现在正在找工作,可以私信“web”进群领取前端面试小册、简历优化修改、大厂内推以及更多阿里、字节大厂面试真题合集,和p8大佬一起交流。

  • 27
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Web面试那些事儿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值