2025前端最新面试题-网络篇

1. 当代欣赏器为何要禁用第三方 cookie

• 为了用户的安全 (安全和隐私是欣赏器永恒的话题)
  
• 第三方 cookie 会记载用户的行为和数据, 方便做广告
  
• 有些欣赏器默认禁止, Chrome 增加了 SameSite (谷歌有广告)
  

cookie 可以实现不同域共享吗
同一主域名下的子域名，cookie 可以共享
2. 实现心跳检验 - 用于断线重连

1. function Heartbeaet() {
2.     let timer = 0
3.     function fn() {
4.         console.log('hello')
5.         timer = setTimeout(fn, 1000) // “心跳” 经量避免使用 setInterval
6.     }
7.     timer = setTimeout(fn, 1000)
8.    
9.     return () => {
10.         console.log('销毁成功')
11.         clearTimeout(timer) // 组件销毁
12.     }
13. }

复制代码

3. https 与 http 的区别

• http：明文传输，信息不安全。用的是80端口, 应用层，速度比较快，由于没有证书校验步调
  
• https：有 SSL 证书，信息安全。用的443端口, 传输层，比较慢，有证书校验步调
  

4. 常见的HTTP协议哀求头有哪些？

常见的 HTTP 哀求头有：

• Accept: 接收的数据范例
  
• Accept-Language: 接收的语言
  
• Accept-Encoding: 客户端的编码方式, 通常指压缩方式
  
• Connection: 长毗连还是短链接
  
• Host: 客户端的主机和端口号
  
• Referer: 哀求来源网站
  
• Cache-Control: 缓存设置（重点）
  
• Cookie: 存储用户信息
  
• Origin: 表明来这哪个站点
  

5. 常见的HTTP协议相应头有哪些？

常见 HTTP 相应头有

• Cache-Control：对应哀求中 Cache-control
  
• Content-Type: text/html; charset=UTF-8, 诉客户端，资源文件的范例，还有字符编码，客户端通过 utf-8 对资源进行解码，然后对资源进行 html 解析
  
• Content-Encoding: 告诉客户端, 服务端发送的资源采用的什么样的压缩方式 gzip、deflate
  
• Date: 服务端发送资源时的服务器时间
  
• Server: 服务器和相对应的版本
  
• Connection: 长毗连还是短链接
  

6. HTTP 1.0 与 HTTP 2.0 的区别？

HTTP 1.0：

• 欣赏器与服务器只保持短暂的毗连，欣赏器的每次哀求都需要与服务器创建一个TCP毗连
  

HTTP 1.1：

• 引入了持久毗连，即TCP毗连默认不关闭，可以被多个哀求复用
  
• 在同一个TCP毗连里面，客户端可以同时发送多个哀求
  
• 固然答应复用TCP毗连，但是同一个TCP毗连里面，全部的数据通讯是按次序进行的，服务器只有处理完一个哀求，才会接着处理下一个哀求。假如前面的处理特别慢，背面就会有许多哀求列队等着
  
• 新增了一些哀求方法
  
• 新增了一些哀求头和相应头
  

HTTP 2.0：

• 采用二进制格式而非文本格式
  
• 完全多路复用，而非有序并阻塞的、只需一个毗连即可实现并行
  
• 使用报头压缩，降低开销
  
• 服务器推送
  

7. HTTP 状态码有哪些?

种别原因短语1XXInformational（信息性状态码）接受的哀求正在处理2XXSuccess（成功状态码）哀求正常处理完毕3XXRedirection（重定向状态码）需要进行附加操作以完成哀求4XXClient Error（客户端错误状态码）服务器无法处理哀求5XXServer Error（服务器错误状态码）服务器处理哀求出错 8. get 和 post 两种传参的区别?

安全性角度 (可不说, 等面试官问)

通常来说, post 比 get 更安全, 由于 post 哀求参数是放在 body 里面的嘛, 但是 post body 中的数据也可以从开发者工具中看到, 以是也不能说安全吧
而且 get post 也都可以在 body 中放数据的, 只是由于欣赏器限定, get 才无法放在 body 中, 我本身就试过使用 postman 在 get 的 body 中传数据, 后台服务也是可以收到的
数据量角度 (可不说, 等面试官问)

常见的 get 和 post 区别还有GET传输的数据比较少，post 传输数据多；在 HTTP 规范中并没有 URL 的长度和传输的数据巨细进行限定，但是在实际开发时，由于欣赏器和服务器均对 URL 的长度进行了限定，因此体现出了 GET传输数据少的缺点
而对于 post 哀求，由于数据放在哀求体中，固然理论上不会受到限定，但是实际开发中各个服务器也会对POST的数据巨细进行一定的限定；比如 nginx 默认上传图片的巨细是 2mb
因此不管GET还是POST，数据传输巨细都会有限定，只是POST的传输巨细相对于GET来说比较大
从缓存角度

get 会缓存, 我们发送一个 get 哀求, 背面相同的哀求会 304 进行缓存下来
而 post 不会, 由于 post 哀求大多用于数据提交, 需要数据到达服务器才进行操作
从幂等性角度

一样平常情况下
get 哀求无论哀求多少次也不会有副作用, 也可以说是不会对资源产生影响, 因此我们说 get 哀求具有幂等性
post 不止会去修改数据, 大概说是去影响资源变革, 以是我们说 post 有明显的 非幂等性
固然, 这是规范的说法, 由于 get 也是可以去修改资源, post 也是可以去查询资源
从 TCP 的角度

get 哀求会产生一个 TCP 数据包, get 哀求发送 header 和 data 给服务端, 服务端返回一个 200, 哀求成功
post 哀求会产生两个 TCP 数据包, post 哀求发送 header 给服务端, 服务端返回 100, 告诉客户端我已经准备接收数据, post 在发送一个 data 给服务端, 服务端返回 200, 哀求成功 (固然啦这是只有特殊的欣赏器才会这样, 一样平常欣赏器不会这样)
如何答复面试官问的 GET 和 POST 区别这道送死题
9. Request Headers 与 Response Headers

• 哀求(客户端->服务端[request])
  

• GET(哀求的方式) /newcoder/hello.html(哀求的目的资源) HTTP/1.1(哀求采用的协媾和版本号)
  
• Accept: /(客户端能接收的资源范例)
  
• Accept-Language: en-us(客户端接收的语言范例)
  
• Connection: Keep-Alive(维护客户端和服务端的毗连关系)
  
• Host: localhost:8080(毗连的目的主机和端口号)
  
• Referer: http://localhost/links.asp(告诉服务器我来自于哪里)
  
• User-Agent: Mozilla/4.0(客户端版本号的名字)
  
• Accept-Encoding: gzip, deflate(客户端能接收的压缩数据的范例)
  
• If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT(缓存时间)
  
• Cookie(客户端暂存服务端的信息)
  
• Date: Tue, 11 Jul 2000 18:23:51 GMT(客户端哀求服务端的时间)
  

• 相应(服务端->客户端[response])
  

• HTTP/1.1(相应采用的协媾和版本号) 200(状态码) OK(描述信息)
  
• Location: http://www.baidu.com(服务端需要客户端访问的页面路径)
  
• Server: apache tomcat(服务端的Web服务端名)
  
• Content-Encoding: gzip(服务端能够发送压缩编码范例)
  
• Content-Length: 80(服务端发送的压缩数据的长度)
  
• Content-Language: zh-cn(服务端发送的语言范例)
  
• Content-Type: text/html; charset=GB2312(服务端发送的范例及采用的编码方式)
  
• Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT(服务端对该资源末了修改的时间)
  
• Refresh: 1;url=http://www.it315.org(服务端要求客户端1秒钟后，革新，然后访问指定的页面路径)
  
• Content-Disposition: attachment filename=aaa.zip(服务端要求客户端以下载文件的方式打开该文件)
  
• Transfer-Encoding: chunked(分块传递数据到客户端）
  
• Set-Cookie:SS=Q0=5Lb_nQ;path=/search(服务端发送到客户端的暂存数据)
  
• Expires: -1//3种(服务端禁止客户端缓存页面数据)
  
• Cache-Control: no-(服务端禁止客户端缓存页面数据)
  
• Pragma: no-(服务端禁止客户端缓存页面数据)
  
• Connection: close(1.0)/(1.1)Keep-Alive(维护客户端和服务端的毗连关系)
  
• Date: Tue, 11 Jul 2000 18:23:51 GMT(服务端相应客户端的时间)
  

​
   在服务器相应客户端的时候，带上 Access-Control-Allow-Origin 头信息，解决跨域的一种方法
  10. 常见 HTTP 哀求有哪些？他们的区别是什么?

• get 哀求, 常用于获取数据、查询资源
  
• post 哀求, 常用来提交数据, 上传文件等
  
• head 哀求, 类似于 get 哀求, 只不过返回实体, 用于获取/查询资源信息
  
• delete 哀求, 用于哀求服务器删除数据
  
• put 哀求, 从客户端向服务端传送的数据, 从而改变数据
  

11. 常见状态码?

种别原因短语1XXInformational（信息性状态码）接受的哀求正在处理2XXSuccess（成功状态码）哀求正常处理完毕3XXRedirection（重定向状态码）需要进行附加操作以完成哀求4XXClient Error（客户端错误状态码）服务器无法处理哀求5XXServer Error（服务器错误状态码）服务器处理哀求出错 状态码状态码英文名称中文描述200OK哀求成功, 一样平常用于 GET 与 POST 哀求204No Content无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保欣赏器继续显示当前文档206Partial Content是对资源某一部分的哀求，服务器成功处理了部分 GET 哀求，相应报文中包含由 Content-Range 指定范围的实体内容。301Moved Permanently永世性重定向。哀求的资源已被永世的移动到 新URL，返回信息会包罗新的URL，欣赏器会主动定向到 新URL。以后任何新的哀求都应使用新的URL取代302Found临时性重定向。与301类似。但资源只是临时被移动。客户端应继续使用原有URL303See Other查看其它地址。与302类似。使用GET哀求查看304Not Modified未修改。所哀求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端盼望只返回在指定日期之后修改的资源307Temporary Redirect临时重定向。与302类似。使用GET哀求重定向，会按照欣赏器标准，不会从POST酿成GET。400Bad Request客户端哀求报文中存在语法错误，服务器无法理解。欣赏器会像200 OK一样对待该状态吗401Unauthorized哀求要求用户的身份认证，通过HTTP认证（BASIC认证，DIGEST认证）的认证信息，若之前已进行过一次哀求，则表示用户认证失败403Forbidden服务器理解哀求客户端的哀求，但是拒绝实行此哀求404Not Found服务器无法根据客户端的哀求找到资源（网页）。通过此代码，网站设计人员可设置"您所哀求的资源无法找到"的个性页面。也可以在服务器拒绝哀求且不想说明理由时使用500Internal Server Error服务器内部错误，无法完成哀求，也大概是web应用存在bug或某些临时故障501Not Implemented服务器不支持哀求的功能，无法完成哀求503Service Unavailable由于超载或系统维护，服务器暂时的无法处理客户端的哀求。延时的长度可包含在服务器的Retry-After头信息中 12. 跨域

一样平常跨域问题前端是怎么解决的？调试的时候

• 使用跨域欣赏器
  
• proxy 代理
  

13. 请描述 TCP 三次握手 和 四次挥手

HTTP 传输过程

• 先创建毗连（确保两边都有收发消息的能力）
  
• 再传输内容（如发送一个 get 哀求）
  
• 网络毗连是 TCP 协议，传输内容是 HTTP 协议
  

三次握手过程 - 创建毗连

• Client发包，Server 接收。Server: 有 Client 要找我
  
• Server 发包，Client 接收。Client: Server 已经收到消息了
  
• Client 发包，Server 接收。Server：Client 要准备发送了
  

四次挥手的过程 - 关闭毗连

• Client 发包，Server 接收。Server：Client 已哀求竣事
  
• Server 发包，Client 接收。Client：Server 已收到，我等候它关闭
  
• Server 发包，Client 接收。Client：Server 此时可以关闭毗连了（其他要发送的数据已经发送完成了）
  
• Client 发包，Server 接收。Server：可以关闭了（然后关闭毗连）
  

14. HTTP 跨域哀求时为何发送 options 哀求 ❌

跨域哀求

• 欣赏器同源计谋
  
• 同源计谋一样平常限定 Ajax 网络哀求，不能跨域哀求 server
  
• 不会限定 <link> <img> <script> <iframe> 加载第三方资源
  

跨域解决办法

• JSONP
  
• CORS 设置答应跨域 (服务端)
  

1. <!-- JSONP 原理
2. script 里面是没有跨域限制的，所以 <script src="https://www.bbb.com/api/getData"></script>
3. 执行后，会返回一个字符串 ‘onSuccess({ errno: 0, data: { /* 数据内容 */ }})’
4. 而 script 会将字符串当成 js 进行执行，而这个 我们又定义了 onSuccess 这个方法，那么就能拿到数据了 -->
5. <script>
6.         window.onSuccess = function (data) {
7.         console.log(data)
8.     }
9.     // CORS 配置允许跨域 (服务端)
10.     response.setHeader("Access-Control-Allow-Origin", "http://localhost:8011")
11.     response.setHeader("Access-Control-Allow-Headers", "X-Requested-With")
12.     response.setHeader("Access-Control-Allow-Headers", "PUT,POST,GET,DELETE,OPTIONS")
13.     response.setHeader("Access-Control-Allow-Credentials", "true") // 允许跨域接收 cookie
14. </script>
15. <script src="https://www.bbb.com/api/getData"></script>

复制代码

“多余” 的 options 哀求

• options 哀求，是跨域哀求之前的预检查
  
• 欣赏器自行发起的，无需我们干预
  
• 不会影响实际的功能
  

15. session 和 JWT 区别？

session 优点

• 原理简单，易于学习
  
• 用户信息存储在服务端，可快速封禁某个用户
  

session 缺点

• 占用服务端内存，硬件成功高
  
• 多历程，多服务器时，不好同步 — 需使用第三方缓存，如 redis
  
• 默认有跨域限定
  

JWT 优点

• 不占用服务端内存
  
• 多历程、多服务 不受影响
  

JWT 缺点

• 用户信息存储在客户端，无法快速封禁某个用户（可以通过创建黑名单，来封禁用户，代价是斲丧内存）
  
• 万一服务端密钥被走漏，则用户信息全部丢失
  
• token 体积一样平常大于 cookie, 会增加哀求的数据量
  

对比

• 如有严格管理用户信息的需求 (保密、快速封禁) 推荐 Session
  
• 如没有特殊要求，则使用 JWT (如创业初期的网站)
  

16. 如何实现 SSO 单点登录

基于 cookie

• cookie 默认不可跨域共享，但有些情况下可设置为共享
  
• 主域名相同，如 www.baidu.com image.baidu.com (www、image 为二级域名，baidu.com 为主域名)
  
• 设置 cookie domain 为主域名，即可共享 cookie
  

SSO

• 主域名完全不同，则 cookie 无法共享
  
• 可使用 SSO 技术方案
  

第三方登录（ OAuth 2.0 ）

• 如 微信登录
  
  
  
  

   扩展
  

• 主域名相同，则可共享 cookie
  
• 主域名不同，则需使用 SSO (单点登录)
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。