前端面试准备指南八之网络安全篇

一、网络分层架构（七/四层协议）

1.1 分层模型概述

业内普遍的分层方式有两种：OSI七层模型和TCP/IP四层模型。

模型	分层	记忆口诀
OSI七层模型	物理层、数据链路层、网络层、传输层、会话层、表示层、应用层	物、数、网、传、会、表、应
TCP/IP四层模型	网络接口层、网络层、传输层、应用层	链、网、传、应

对应关系：

• TCP/IP 的网络接口层 ≈ OSI 的物理层 + 数据链路层
• TCP/IP 的应用层 ≈ OSI 的会话层 + 表示层 + 应用层

1.2 各层详解

1.2.1 物理层

主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输，到达目的地后再转化为1、0，也就是我们常说的数模转换与模数转换）。这一层的数据叫做比特。

1.2.2 数据链路层

定义了如何让格式化数据以帧为单位进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。如：串口通信中使用到的115200、8、N、1

1.2.3 网络层

在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加，而网络层正是管理这种连接的层。

1.2.4 传输层

定义了一些传输数据的协议和端口号（WWW端口80等），如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议，与TCP特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种方式传输的）。 主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组。常常把这一层数据叫做段。

1.2.5 会话层

通过传输层(端口号：传输端口接收端口)建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名）。

1.2.6 表示层

可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机使用扩展二一十进制交换码(EBCDIC)，而另一台则使用美国信息交换标准码（ASCII）来表示相同的字符。如有必要，表示层会通过使用一种通格式来实现多种数据格式之间的转换。

1.2.7 应用层

是最靠近用户的OSI层。这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务。

二、TCP UDP 区别

区别	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

三、HTTP 和 HTTPS 区别

特性	HTTP	HTTPS
URL 开头	http://	https://
安全性	不安全	安全（加密传输）
标准端口	80	443
工作层级	应用层	应用层（TLS/SSL 在传输层）
数据加密	不加密	TLS/SSL 加密
证书要求	无需证书	需要 CA 机构颁发的 SSL/TLS 证书
性能	较快	略慢（需加密解密）

四、HTTP 请求方法

方法	描述	是否安全	是否幂等
GET	请求指定资源，用于查询	是	是
POST	提交数据到服务器，用于创建或更新	否	否
HEAD	同GET，但只返回响应头，不返回响应体	是	是
PUT	更新指定资源（全量更新）	否	是
DELETE	删除指定资源	否	是
OPTIONS	询问服务器支持哪些方法	是	是
PATCH	部分更新指定资源	否	否

安全方法：不会改变服务器状态的方法（GET、HEAD、OPTIONS）
幂等方法：多次请求产生相同效果的方法（GET、HEAD、PUT、DELETE、OPTIONS）

五、GET 和 POST 区别

特性	GET	POST
浏览器后退/刷新	不会再次请求	会再次提交请求
缓存	浏览器主动缓存	需手动设置缓存
历史记录	参数保留在历史记录	参数不保留
长度限制	URL 长度有限制（浏览器限制）	无限制
参数位置	URL 查询字符串	请求体（Request Body）
安全性	参数暴露在地址栏，相对不安全	参数在请求体中，相对安全
主要用途	查询/获取资源	创建/更新资源
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data
幂等性	是	否
TCP 数据包	通常一个（请求头+数据一起发送）	通常一个（现代浏览器优化后）

注意：”POST 产生两个 TCP 数据包”的说法不准确，现代浏览器通常会合并请求头和请求体一起发送。

六、TCP 三次握手

三次握手的目的：确保双方都具备发送和接收数据的能力。

1. 第一次握手：客户端发送 SYN（同步）报文到服务端，客户端进入 SYN_SENT 状态
2. 第二次握手：服务端收到 SYN 后，回复 SYN + ACK（同步+确认）报文，服务端进入 SYN_RCVD 状态
3. 第三次握手：客户端收到 SYN + ACK 后，发送 ACK（确认）报文，客户端进入 ESTABLISHED 状态；服务端收到 ACK 后也进入 ESTABLISHED 状态，连接建立完成

状态转换：

客户端：CLOSED → SYN_SENT → ESTABLISHED
服务端：CLOSED → LISTEN → SYN_RCVD → ESTABLISHED

七、TCP 四次挥手

四次挥手的目的：关闭 TCP 连接，确保双方数据都已传输完毕。

刚开始双方都处于 ESTABLISHED 状态，假设客户端先发起关闭请求：

1. 第一次挥手：客户端发送 FIN（结束）报文，客户端进入 FIN_WAIT1 状态
2. 第二次挥手：服务端收到 FIN 后，发送 ACK（确认）报文，服务端进入 CLOSE_WAIT 状态；客户端收到 ACK 后进入 FIN_WAIT2 状态
3. 第三次挥手：服务端准备好关闭时，发送 FIN 报文，服务端进入 LAST_ACK 状态
4. 第四次挥手：客户端收到 FIN 后，发送 ACK 报文，客户端进入 TIME_WAIT 状态；服务端收到 ACK 后进入 CLOSED 状态；客户端等待 2MSL（最大报文段生存时间）后进入 CLOSED 状态

状态转换：

客户端：ESTABLISHED → FIN_WAIT1 → FIN_WAIT2 → TIME_WAIT → CLOSED
服务端：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

TIME_WAIT 作用：

• 确保最后一个 ACK 能被服务端收到
• 等待网络中残留的报文过期

八、HTTP1.0、1.1、2.0、3.0的区别

8.1 HTTP 1.1 相比 1.0

• 支持持久连接
• 支持断点续传
• 支持 Host 头
• 支持管道化请求

8.2 HTTP 2.0 相比 1.1

• 采用二进制格式
• 支持多路复用
• 支持头部压缩
• 支持服务器推送

8.3 HTTP 3.0 相比 2.0

• 基于 QUIC 协议（基于 UDP）
• 更快的连接建立（0-RTT 或 1-RTT）
• 更好的拥塞控制
• 连接迁移（支持网络切换）
• 更可靠的传输（解决队头阻塞问题）

九、HTTP 状态码

9.1 状态码分类

1xx    Informational（信息状态码）     接受请求正在处理
2xx    Success（成功状态码）            请求正常处理完毕
3xx    Redirection（重定向状态码）         需要附加操作已完成请求
4xx    Client Error（客户端错误状态码）    服务器无法处理请求
5xx    Server Error（服务器错误状态码）    服务器处理请求出错

9.2 2xx 成功

• 200 OK：请求成功，服务器返回请求的资源
• 201 Created：请求成功并创建了新资源
• 202 Accepted：请求已接受，但尚未处理完成
• 204 No Content：请求成功，但没有返回内容

9.3 3xx 重定向

• 301 Moved Permanently：永久重定向，资源已移动到新位置
• 302 Found：临时重定向，资源暂时移动到新位置
• 303 See Other：重定向到另一个资源
• 304 Not Modified：资源未修改，使用缓存
• 307 Temporary Redirect：临时重定向，保持请求方法不变

9.4 4xx 客户端错误

• 400 Bad Request：请求参数错误或格式不正确
• 401 Unauthorized：未授权，需要身份验证
• 403 Forbidden：服务器拒绝访问
• 404 Not Found：资源未找到
• 405 Method Not Allowed：请求方法不允许
• 406 Not Acceptable：服务器无法返回请求的内容类型
• 408 Request Timeout：请求超时
• 429 Too Many Requests：请求过于频繁，超出限制

9.5 5xx 服务器错误

• 500 Internal Server Error：服务器内部错误
• 501 Not Implemented：服务器不支持请求的功能
• 502 Bad Gateway：网关错误，上游服务器响应无效
• 503 Service Unavailable：服务不可用，通常是临时的
• 504 Gateway Timeout：网关超时，上游服务器未及时响应
• 505 HTTP Version Not Supported：不支持请求的HTTP版本

十、XSS、CSRF、DDoS攻击原理及避免方式

10.1 XSS攻击

10.1.1 XSS定义

XSS（Cross-Site Scripting，跨站脚本攻击）是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当被攻击者登录网站时就会执行这些恶意代码，这些脚本可以读取 cookie、session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等。

10.1.2 XSS避免方式

1. 输入验证：对所有用户输入进行严格验证和过滤
2. 输出编码：
   • url 参数使用 encodeURIComponent 方法转义
   • 对 HTML 内容使用 innerHTML 时要谨慎，优先使用 textContent
   • 使用特殊字符转义，如 & → &、< → <、> → >
3. 内容安全策略（CSP）：设置 Content-Security-Policy 头部，限制脚本来源
4. 使用现代框架：React、Vue 等框架默认会对输入进行转义
5. HttpOnly Cookie：设置 HttpOnly 属性，防止 JavaScript 读取 cookie

10.2 CSRF攻击

10.2.1 CSRF定义

CSRF（Cross-site Request Forgery，跨站请求伪造）：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

10.2.2 CSRF避免方式

1. 使用 CSRF Token：
   • 服务端给用户生成一个 token，加密后传递给用户
   • 用户在提交请求时，需要携带这个 token
   • 服务端验证 token 是否正确
2. 验证码：重要操作添加验证码，增加攻击难度
3. 检查 Referer 头：验证请求来源是否合法
4. SameSite Cookie：设置 SameSite 属性，限制跨站 cookie 发送
5. 双重提交 Cookie：将 CSRF token 同时放在 cookie 和请求体中
6. 使用 POST 请求：对于修改操作，避免使用 GET 请求

10.3 DDoS攻击

10.3.1 DDoS定义

DDoS（Distributed Denial of Service，分布式拒绝服务攻击）：攻击者控制大量僵尸主机（肉鸡），向目标服务器发送海量请求，导致服务器资源耗尽，无法正常处理合法请求，从而导致服务不可用。

与DoS的区别：DoS（Denial of Service）是单点攻击，DDoS是分布式攻击，威力更大。

10.3.2 DDoS避免方式

1. 流量限制：限制单 IP 请求频率
2. CDN 防护：使用 CDN 分散流量
3. WAF 防护：配置 Web 应用防火墙
4. 服务器集群：使用多台服务器分担负载
5. 流量清洗：识别并过滤恶意流量
6. 优化代码：减少服务器处理时间，提高并发能力

十一、同源策略

11.1 同源策略定义

同源策略是浏览器的安全机制，限制一个域下的 JavaScript 脚本未经允许不能访问另一个域下的资源。

同源策略是对 JS 脚本的一种限制，并不是对浏览器的限制，像 img、script 脚本请求不会有跨域限制。

同源判断标准（三个都相同才是同源）：

• 协议：http://、https://
• 域名：www.example.com、api.example.com
• 端口：80、443、3000

示例：

页面URL	请求目标	是否同源	原因
http://www.example.com	http://www.example.com/api	是	协议、域名、端口都相同
http://www.example.com	https://www.example.com/api	否	协议不同
http://www.example.com	http://api.example.com	否	子域名不同
http://www.example.com:8080	http://www.example.com:3000	否	端口不同

不受同源策略限制的资源：

• <img>、<script>、<link>、<iframe> 等标签的资源加载
• 表单提交（POST 请求）

受同源策略限制的操作：

• XMLHttpRequest 和 fetch 请求
• 读取非同源页面的 DOM
• 访问非同源的 Cookie、LocalStorage

十二、前后端通信方式

方式	类型	特点	适用场景
Ajax	短连接，单向	通过 XMLHttpRequest 或 fetch() 发起请求，服务器响应后连接断开	常规数据请求、表单提交
WebSocket	长连接，双向	建立持久连接，服务器可主动推送数据	实时聊天、实时通知、在线游戏
Server-Sent Events (SSE)	长连接，单向（服务端→客户端）	服务器主动向客户端推送事件	实时日志、股票行情、新闻推送
Form 表单	短连接，单向	传统表单提交，会刷新页面	简单表单提交、文件上传
GraphQL	短连接，单向	按需获取数据，减少请求次数	API 数据查询

对比：

• Ajax：请求-响应模式，适合常规数据交互
• WebSocket：全双工通信，适合实时场景
• SSE：服务器单向推送，实现简单，兼容性好
• GraphQL：灵活查询，减少冗余数据

十三、跨域通信的几种方式

方案	原理	优点	缺点	适用场景
JSONP	利用 <script> 标签无跨域限制	兼容性好（支持IE）	仅支持 GET 请求，存在XSS风险	旧项目兼容、简单数据获取
CORS	设置 HTTP 响应头 Access-Control-Allow-Origin	支持所有 HTTP 方法，安全可靠	需要服务端配置	现代项目首选
postMessage	HTML5 API，跨窗口/iframe通信	支持双向通信	需要双方页面配合	多窗口/iframe通信
WebSocket	建立持久连接，不受同源限制	双向实时通信	协议复杂度较高	实时通信场景
Node 中间件代理	前端请求代理服务器，代理转发到目标服务器	灵活可控	需要额外服务器资源	开发环境调试
Nginx 反向代理	配置 Nginx 转发请求	性能好，稳定可靠	需要运维配置	生产环境常用

日常工作中最常用的跨域方案：

1. 开发环境：Node 中间件代理（如 webpack-dev-server）
2. 生产环境：CORS + Nginx 反向代理