前端实习八股整理-计算机网络

一、怎么处理跨域问题

1.设置CORS响应头（服务器端配置）
2.代理服务器Proxy（开发环境（Vue/React）、生产环境Nginx反向代理）
3.JSONP（仅限GET请求，写在script里）

二、HTTP状态码

1xx（信息性状态码）
表示请求已接收需要继续处理。
100 Continue 客户端应继续发送请求。
101 Switching Protocols 服务器同意切换协议。
102 Processing 服务器正在处理请求但未完成。
2xx（成功状态码）
200 OK 请求成功，返回数据（GET请求）
201 Created 请求成功并创建了新资源（POST请求）
202 Accepted 请求已接收，但尚未处理完成（异步任务）
204 No Content 请求成功，无返回内容（如DELETE请求）
206 Partial Content 部分内容（用于分块下载或断点续传）
3xx（重定向状态码）
301 Moved Permanently 资源永久重定向（浏览器缓存新地址）
302 Found 资源临时重定向（比如未登录）
304 Not Modified 资源未修改
4xx（客户端/前端错误状态码）
400 Bad Request 请求语法错误（如JSON格式错误）
401 Unauthorized 未授权（需要身份认证）
403 Forbidden 服务器拒绝访问（无权限）
404 Not Found 请求的资源不存在（检查url是否输错）
405 Method Not Allowed 请求方法不对（如POST了只能GET的接口）
408 Request Timeout 请求超时
429 Too Many Request 请求过于频繁（限流）
5xx（服务器/后端错误状态码）
500 Internal Server Error 服务器内部错误（如代码异常）
502 Bad Gateway 网关或代理服务器收到无效响应
503 Service Unavailable 服务不可用（如服务器维护）
504 Gateway Timeout 网关超时（代理服务器未及时响应）

三、HTTP中几种常用的请求方法

1.GET：从服务器中获取资源（幂等的）

• 把请求参数和附带的数据包含到请求URL中，即URL后面的？之后，参数用&连接。因此，GET方法会在浏览器的历史记录中留下明文记录。
• 访问简单、效率较高、可以被缓存，但请求参数长度通常有限制（约2048字符），而且数据传输不安全，不适合传输敏感数据
• 适用场景：数据查询、资源获取等
  2.POST：向服务器提交数据，用于创建新资源或触发某些操作（不是幂等的）
• 把请求参数和附带的数据放在请求体中，并在请求头中指定请求体的类型（最常用的表单提交格式【GET方法只能用这种】：application/x-www-form-urlencoded、文件上传专用格式：multipart/form-data、现代 API 常用格式：application/json、纯文本格式：text/plain、XML 数据格式：application/xml）
• 可以传输大量数据，且更安全、隐蔽（数据不会留在URL历史中）。但由于涉及请求体，请求的格式和规范比较复杂，相对GET耗时间、效率低。
• 适用场景：将数据存储到服务器、上传文件、提交表单等
  3.PUT：用于更新服务器上的资源（幂等的）
  4.PATCH：用于更新部分服务器上的资源（不是幂等的）
  5.DELETE：用于删除服务器上的资源（幂等的）
  6.HEAD：与GET类似，但只获取请求头，不返回响应体。
  7.OPTIONS：获取服务器支持的HTTP方法。（用于跨域请求的预检）
  8.CONNECT：要求与代理服务器通信时简历隧道，用隧道进行TCP通信。
  9.TRACE：回显服务器收到的请求，主要用于测试或诊断。

四、TCP中的滑动窗口有什么用？

滑动窗口机制：是 TCP 中用于流量控制和拥塞控制的重要机制。
流量控制：确保接收方不会因为数据量过大而无法处理。
拥塞控制：避免网络拥塞，确保网络资源的有效利用。
动态调整：根据网络状况和接收方的能力动态调整窗口大小，提高传输效率和网络稳定性

五、简述OSI七层模型

OSI（开放系统互联）模型是一个用于理解和实现网络协议的七层概念框架。每一层都有特定的功能，并与其直接上下的层进行通信。
1.物理层(Physical Layer)：这是OSI模型的最低层，负责设备之间的物理连接，包括通过物理介质传输原始比特流。它涉及硬件组件，如电缆、交换机和网络接口卡。
2.数据链路层(Data Link Layer)：负责节点到节点的数据传输以及错误检测和纠正，确保数据在物理链路上的可靠传输。它分为两个子层：媒体访问控制（MAC）层和逻辑链路控制（LLC）层。
3.网络层(Network Layer)：负责数据的路由、转发和寻址，确定数据到达目的地的最佳物理路径。像IP（互联网协议）这样的协议在这一层运行。
4.传输层(Transport Layer)：为应用程序提供端到端的通信服务，负责错误恢复、流量控制和确保完整的数据传输。像TCP（传输控制协议）和UDP（用户数据报协议）这样的协议在这一层运行。
5.会话层(Session Layer)：管理应用程序之间的会话，建立、维护和终止应用程序之间的连接，负责会话的检查点和恢复。
6.表示层(Presentation Layer)：负责数据的翻译、加密和压缩，确保数据以可用的格式呈现给应用层，充当网络和应用之间的翻译器。
7.应用层(Application Layer)：这是OSI模型的最高层，直接为终端用户应用程序提供网络服务，负责电子邮件、文件传输和网页浏览等网络服务。像HTTP、FTP和SMTP这样的协议在这一层运行。

六、TCP和UDP的区别？

UDP（User Datagram Protocol，用户数据报协议）
无连接协议：UDP 是一种无连接协议，发送数据前不需要建立连接。
不提供错误恢复：UDP 不提供错误恢复机制，如果数据包丢失，不会进行重传。
传输速度快：由于没有错误检查和连接建立的过程，UDP 传输速度更快，延迟更低。
应用场景：适用于对速度要求高且允许偶尔数据丢失的应用，如直播流媒体、在线游戏和语音通话（VoIP）。
TCP（Transmission Control Protocol，传输控制协议）
面向连接协议：TCP 在发送数据前需要建立连接，确保通信的可靠性。
提供错误恢复：TCP 提供错误检查，确保数据按顺序且无误地传输。
传输速度较慢：由于需要建立连接和进行错误检查，TCP 的传输速度相对较慢。
应用场景：适用于对数据完整性和顺序有严格要求的应用，如网页浏览、电子邮件和文件传输。

七、WebSocket和它的生命周期

WebSocket 是一种网络通信协议，提供了在单个 TCP 连接上进行全双工通信的能力。它允许客户端和服务器之间进行实时、双向的数据传输，而无需像传统的 HTTP 请求那样频繁地建立和关闭连接。WebSocket 在 Web 开发中广泛用于实现实时功能，如聊天应用、在线游戏、实时通知等。

WebSocket 的生命周期
WebSocket 的生命周期包括以下几个主要阶段：创建、连接、通信、关闭。

1.创建 WebSocket 连接
客户端通过 new WebSocket(url) 创建一个 WebSocket 实例，其中 url 是 WebSocket 服务器的地址，通常以 ws://（非加密）或 wss://（加密）开头。

const socket = new WebSocket('ws://example.com/socket');

2.连接阶段
创建 WebSocket 实例后，客户端会尝试与服务器建立连接。在连接过程中，WebSocket 实例会触发以下事件：
· onopen：连接成功建立时触发。
· onerror：连接过程中发生错误时触发。
· onclose：连接关闭时触发。

socket.onopen = function (event) {
  console.log('WebSocket connection established');
};

socket.onerror = function (error) {
  console.error('WebSocket error:', error);
};

socket.onclose = function (event) {
  console.log('WebSocket connection closed', event);
};

3.通信阶段
一旦连接成功建立，客户端和服务器就可以通过 send 方法发送数据，并通过 onmessage 事件接收数据。
· 发送数据

socket.send('Hello, server!');

· 接收数据

socket.onmessage = function (event) {
  console.log('Message from server:', event.data);
};

WebSocket 支持发送和接收多种类型的数据，包括文本（字符串）、二进制数据（Blob、ArrayBuffer）等。
4.关闭连接
客户端或服务器都可以主动关闭 WebSocket 连接。关闭连接时，可以调用 close 方法，并可选地传递状态码和原因。

socket.close(1000, 'Normal closure');

状态码是一个数字，表示关闭连接的原因。常见的状态码包括：
1000：正常关闭。
1001：正在离开。
1002：协议错误。
1003：不可接受的数据类型。
1006：连接异常关闭。
1007：数据不符合 UTF-8 编码。
1008：违反策略。
1009：消息太大。
1010：需要扩展。
1011：内部服务器错误。
1012：服务重启。
1013：尝试重新连接。
1014：不可恢复的错误。
1015：TLS 手shake失败。
1016：不可恢复的错误。

八、400一定是前端错误吗，500一定是后端错误吗，怎么排查？

1.400 Bad Request（客户端错误）
官方定义
客户端发送的请求存在语法或参数错误，服务器无法处理。
典型场景
· 前端提交的 JSON 数据格式错误（如缺少必填字段、类型不匹配）。
· URL 参数不符合后端校验规则（如 id=abc 但后端期望数字）。
· 请求头缺失或错误（如未携带 Content-Type: application/json）。
例外情况
· 后端校验逻辑不合理：
例如，前端传 age=150，后端认为“年龄不能 > 120”直接返回 400，但该逻辑应属业务错误（更推荐 422 Unprocessable Entity）。
· 接口文档不清晰：
前端按文档传参，但后端实际要求不同，导致 400（本质是前后端协作问题）。
2. 500 Internal Server Error（服务端错误）
官方定义
服务器内部处理请求时发生未预期的错误。
典型场景
· 后端代码抛出未捕获的异常（如数据库查询失败、空指针异常）。
· 第三方服务（如支付接口）突然不可用。
· 服务器配置错误（如内存溢出、文件权限问题）。
例外情况
· 前端触发后端异常：
例如，前端传 page=-1，后端未校验导致数组越界崩溃（应归责于后端防御性编程不足）。
· 网络代理层问题：
Nginx 转发请求时超时或崩溃，返回 500（实际是基础设施问题）。

状态码 主要责任方 例外情况
400 前端（80%） 后端校验逻辑不合理
500 后端（90%） 前端触发未处理的边缘 case

九、HTTP请求的组成，常用的请求头

1.请求行（Request Line）
包含三个部分：
请求方法（如 GET、POST 等）
请求目标（通常是 URL 路径）
HTTP 版本（如 HTTP/1.1 或 HTTP/2）

GET /api/data HTTP/1.1

2.请求头（Request Headers）
包含客户端发送的附加信息，用于控制请求行为或传递元数据。常用的请求头包括：
请求头 说明
Host 指定服务器域名（HTTP/1.1 必需）
User-Agent 客户端标识（浏览器或应用信息）
Accept 客户端可接受的响应内容类型（如 text/html）
Accept-Language 客户端偏好的语言（如 en-US）
Accept-Encoding 客户端支持的压缩方式（如 gzip）
Content-Type 请求体的媒体类型（如 application/json）
Content-Length 请求体的字节长度
Authorization 身份验证凭证（如 Bearer token）
Cookie 发送服务器的 Cookie 数据
Referer 当前请求的来源页面 URL
Cache-Control 缓存策略（如 no-cache）
Connection 控制连接行为（如 keep-alive）
3. 请求体（Request Body）
用于 POST、PUT 等方法发送数据（如表单、JSON 等）。
GET 请求通常没有请求体，数据通过 URL 查询参数传递。

HTTP请求示例

POST /api/login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Content-Type: application/json
Content-Length: 52
Accept: application/json

{"username": "user123", "password": "pass456"}

4.响应头

content-encoding: br 告诉浏览器压缩方式是br
content-type: text/html; charset=utf-8 告诉浏览器以这种方式，编码加载
cache-control: 告诉浏览器缓存策略
expires: 告诉浏览器缓存过期时间
set-cookie: 告诉浏览器设置 cookie
access-control-allow-origin: * 告诉浏览器允许跨域

十、http、https和WebSocket的区别

HTTP 、HTTPS和 WebSocket 都是基于 TCP 的应用层协议，但它们在通信模式、性能、用途等方面有显著不同：

特性	HTTP	HTTPS	WebSocket
协议类型	无状态请求-响应协议（半双工）	加密的 HTTP（HTTP + SSL/TLS）	全双工实时通信协议
安全性	明文传输，不安全	加密传输，防止窃听和篡改	可基于 HTTPS（wss://）加密
连接方式	短连接（每次请求后断开）	短连接（同 HTTP）	长连接（建立后持续通信）
通信模式	客户端发起请求，服务器响应	同 HTTP	双向通信（服务器可主动推送数据）
适用场景	网页浏览、API 调用	安全登录、支付、敏感数据传输	实时聊天、股票行情、在线游戏等
默认端口	80	443	80（ws://）、443（wss://）
协议头	http://	https://	ws://（明文）、wss://（加密）

十一、http各版本差异对比

1. HTTP/0.9（1991年）
   特点：
   只有 GET 方法，无请求头/响应头。
   响应仅为纯文本（无图片、样式等）。
   问题：功能极度简陋，无法满足复杂需求。
2. HTTP/1.0（1996年，RFC 1945）
   核心改进：
   引入 请求头/响应头（如 Content-Type、User-Agent）。
   支持 GET、POST、HEAD 方法。
   新增状态码（如 200 OK、404 Not Found）。
   支持多类型数据（如图片、CSS）。
   局限性：
   短连接：每个请求需重新建立TCP连接（高延迟）。
   无主机头（Host），无法支持虚拟主机。
3. HTTP/1.1（1997年，RFC 2616）
   核心改进：
   持久连接（Keep-Alive）：默认复用TCP连接（减少握手开销）。
   管道化（Pipelining）：允许连续发送多个请求（但响应必须按顺序返回，易队头阻塞）。
   强制 Host 头：支持虚拟主机（单IP多域名）。
   新增方法：PUT、DELETE、OPTIONS。
   缓存控制（Cache-Control、ETag）。
   局限性：
   队头阻塞（Head-of-Line Blocking）：前一个请求未完成会阻塞后续请求。
   头部冗余：每次请求携带完整头部（如Cookie未压缩）。
4. HTTP/2（2015年，RFC 7540）
   核心改进：
   二进制分帧：将请求/响应分解为二进制帧（替代文本格式，解析更高效）。这些帧可以交错发送，接收方可以根据帧头信息重新组装消息。
   多路复用（Multiplexing）：同一连接上并行传输多个请求/响应（彻底解决队头阻塞）。
   头部压缩（HPACK）：减少重复头部字段（如Cookie、User-Agent）。
   服务器推送（Server Push）：主动推送资源（如CSS/JS）到客户端缓存。
   流是 HTTP/2 中的一个独立的、双向的字节流，可以承载一个或多个消息。每个流都有一个唯一的标识符，用于区分同一连接上的不同流。
   示例：
   一个TCP连接上同时传输HTML、CSS、JS请求。
   局限性：
   仍基于TCP协议，受TCP拥塞控制影响（如丢包重传延迟）。
5. HTTP/3（2022年，RFC 9114）
   核心改进：
   基于QUIC协议：替代TCP，运行在UDP之上，解决TCP队头阻塞。
   0-RTT连接：首次访问即可缓存会话信息，减少握手延迟。
   改进的多路复用：单个流阻塞不影响其他流。
   更强的加密：QUIC默认使用TLS 1.3。
   优势场景：
   高延迟网络（如移动端）、频繁切换网络（WiFi/4G）。
   示例：
   视频会议、实时游戏等低延迟应用。
   
   如何选择HTTP版本？
   兼容性优先：
   所有环境支持 HTTP/1.1（最广泛兼容）。
   性能优先：
   现代浏览器/服务器启用 HTTP/2（需HTTPS）。
   极致低延迟：
   使用 HTTP/3（需服务端和客户端支持，如 Chrome/CDN 服务商）。

十二、传输格式从文本到二进制帧的优势是什么？

一、文本格式（HTTP/1.x）的局限性

1. 解析复杂度高
   文本协议：需按字符解析（如换行符分割头部/正文），易出错且效率低。
   示例：解析以下请求需逐行处理：

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

2. 冗余数据传输
   重复头部：每个请求携带完整头部（如 Cookie、User-Agent），未压缩。
   无复用能力：相同请求需重复发送相同字段（如 Host: example.com）。
3. 队头阻塞（Head-of-Line Blocking）
   顺序处理：请求/响应必须按顺序完成，前一个请求延迟会阻塞后续请求。
   二、二进制分帧（HTTP/2/3）的核心优势
4. 高效解析
   二进制编码：帧（Frame）有固定格式（类型、长度、标志等），直接按字节解析，速度更快。
   示例：HTTP/2 的帧结构：

+-----------------------------------------------+
| Length (24) | Type (8) | Flags (8) | Stream ID (31) |
|                   Payload (Length)                  |
+-----------------------------------------------+

2. 多路复用（Multiplexing）
   并行传输：通过 流（Stream） 在同一连接上并发传输多个请求/响应，彻底解决队头阻塞。
   对比：
   HTTP/1.1：6个TCP连接并行（浏览器限制）仍可能阻塞。
   HTTP/2：单连接上数百个流并行。
3. 头部压缩（HPACK/QPACK）
   静态/动态表：复用高频头部字段（如 :method: GET），压缩率高达 90%。
   示例：第二次请求的 User-Agent 可能仅用 1 字节表示。
4. 更精细的流量控制
   帧级优先级：可指定流的优先级（如 CSS 优先于图片）。
   流量窗口：基于帧的滑动窗口控制，避免单一流占满带宽。
5. 更好的扩展性
   自定义帧类型：支持新增帧类型（如 HTTP/2 的 PUSH_PROMISE 帧用于服务器推送）。

十三、介绍下HTTP3使用的QUIC

一、QUIC 的核心优势

1. 基于 UDP，绕过 TCP 限制
   问题：TCP 需要三次握手（1.5 RTT）且存在队头阻塞（HOL Blocking）。
   解决：QUIC 直接在 UDP 上实现可靠传输，避免操作系统对 TCP 的硬性依赖，更灵活。
2. 极快的连接建立（0-RTT/1-RTT）
   0-RTT：首次连接后，再次访问可跳过握手，直接发送数据（类似 TLS 1.3 的 0-RTT）。
   1-RTT：首次连接仅需 1 次往返（TCP + TLS 需 2-3 次）。
3. 彻底解决队头阻塞
   HTTP/2 的遗留问题：虽然 HTTP/2 在应用层解决了队头阻塞，但 TCP 层仍会因单个丢包阻塞所有流。
   QUIC 的方案：每个流（Stream）独立传输，丢包只影响当前流。
4. 内置加密（TLS 1.3）
   默认加密：QUIC 将 TLS 1.3 作为协议的一部分，无法明文传输。
   前向安全：即使长期密钥泄露，历史会话也无法解密。
5. 连接迁移
   网络切换无感：当设备从 WiFi 切换到 4G 时，QUIC 连接无需重建（TCP 需重新握手）。

二、QUIC 的工作原理

1. 连接建立流程
   首次连接（1-RTT）：
   客户端发送 Initial 包（包含 TLS 1.3 的 ClientHello）。
   服务端回复 Initial 包（含 ServerHello）和 Handshake 包。
   客户端完成握手，开始传输数据。
   再次连接（0-RTT）：
   客户端直接发送加密数据（需缓存会话密钥）。
2. 多路复用与流控制
   流（Stream）：一个连接内可并行多个独立流，每个流承载不同请求。
   流量控制：基于流的滑动窗口，避免单一流占满带宽。
3. 丢包恢复
   快速重传：通过包编号（Packet Number）和确认机制（ACK）快速检测丢包。
   无阻塞恢复：丢包仅重传丢失的流，不影响其他流。

三、QUIC 与 TCP/HTTP 的对比

四、QUIC 的应用场景
高延迟网络（如移动端、卫星通信）：0-RTT 特性显著减少加载时间。
实时应用（视频会议、在线游戏）：多路复用和低延迟提升体验。
频繁切换网络（WiFi/4G 切换）：连接迁移避免中断。
大规模内容分发（CDN）：快速握手和高效传输节省服务器资源。

五、QUIC 的挑战
网络中间件干扰：某些防火墙/NAT 设备会阻止 UDP 或限制 QUIC 流量。
CPU 开销：UDP 的可靠传输需在用户态实现，比 TCP 内核实现更耗 CPU。
兼容性：旧设备/操作系统可能不支持（需回退到 TCP）。