活动发起人@小虚竹 想对你说:
这是一个以写作博客为目的的创作活动,旨在鼓励大学生博主们挖掘自己的创作潜能,展现自己的写作才华。如果你是一位热爱写作的、想要展现自己创作才华的小伙伴,那么,快来参加吧!我们一起发掘写作的魅力,书写出属于我们的故事。我们诚挚邀请你参加为期14天的创作挑战赛!
提醒:在发布作品前,请将不需要的内容删除。
1.CIA三元组
CIA 三元组是信息安全领域的核心概念,由保密性(机密性)(Confidentiality)、完整性(Integrity)和可用性(Availability)三个核心安全目标构成 ,是广泛应用的信息安全保护框架。具体如下:
- 保密性(Confidentiality):限制对数据的访问,确保只有授权人员能访问关键信息,防止敏感信息被未授权访问和泄露。比如企业财务数据仅限财务部门访问;医疗记录只有医护人员及患者本人有权查看。实现保密性的措施有:
-
- 加密技术:数据传输时用 SSL/TLS 等协议加密,存储时用 AES、RSA 等算法加密,像 HTTPS 加密网站通信 ;端到端加密用于应用通信,如 WhatsApp。
- 访问控制:基于角色(RBAC),如管理员和普通用户权限不同;遵循最小权限原则,只给必要权限;基于属性(ABAC),结合位置、部门等因素控制权限。
- 身份验证:多因素(MFA),如密码加手机验证码;双因素(2FA),如密码加动态验证码;生物识别,如指纹、面部识别。
- 数据脱敏:在测试等场景伪装敏感数据,如部分掩盖身份证号、信用卡号。
- 数据访问日志和监控:记录访问情况并审计,实时监控异常访问。
- 网络安全措施:防火墙、入侵检测 / 防御系统(IDS/IPS)防止外部非法访问;VPN 加密远程连接。
- 物理安全措施:服务器和数据中心设门禁、监控等;用硬件加密设备,如加密硬盘、安全硬件模块(HSM) 。
- 培训与意识教育:给员工开展网络安全培训,制定并执行安全政策。
- 完整性(Integrity):确保数据在存储、使用和传输过程中准确、一致且未被未授权修改或篡改。例如企业网站高管信息要准确;银行交易记录不能被非法篡改。保障完整性的方法包括:
-
- 哈希校验:对数据生成哈希值,传输或存储后对比,判断数据是否被篡改。
- 文件权限管理:设置权限,限定能修改数据的人员。
- 消息认证控制:使用消息认证码(MAC),在数据传输中验证完整性和来源。
- 可用性(Availability):保证系统、企业和应用程序正常运行,授权用户在需要时能及时获取数据。比如电商网站在购物高峰期能正常访问;银行系统保证客户随时办理业务。确保可用性的举措有:
-
- 数据备份:定期备份数据到外部驱动器、云端等,如企业每日备份业务数据。
- 不间断电源(UPS):为关键系统供电,防止电力中断影响。
- 故障转移策略:设计方案应对网络或系统故障、DDoS 攻击等,如服务器集群故障转移。
CIA 三元组概念可追溯到 1975 - 1989 年期间逐步形成并被正式命名,后续随着技术发展,学者提出帕克六元组(增加真实性、实用性、占有) 、IAS - Octave 模型(增加责任、审计等八个安全要求 )等扩展模型。实际应用中,不同组织需根据自身需求平衡三者关系,如军方侧重保密性,电商侧重可用性 。它帮助组织评估安全实践、识别改进点并维护数据和系统安全。
2.HTTPS的实现原理
HTTPS(超文本传输安全协议)是在 HTTP 基础上,利用 SSL/TLS 协议实现加密传输、身份认证等功能,保障网络通信安全。其实现原理如下:
1. 初始握手阶段
- 客户端发起请求:客户端(如浏览器)向服务器发送 HTTPS 请求,请求中包含客户端支持的 SSL/TLS 协议版本、加密算法套件列表(包括对称加密套件列表和非对称加密套件列表 ),以及一个随机数 random1。这个随机数后续会参与密钥生成。
- 服务器响应:服务器收到请求后,从客户端提供的加密算法套件列表中选择合适的对称加密套件和非对称加密套件。然后服务器将选定的加密算法信息、另一个随机数 random2,以及包含服务器公钥的数字证书返回给客户端。数字证书由权威证书颁发机构(CA)签发,包含服务器的身份信息、公钥以及证书有效期等内容。
2. 证书验证阶段
- 客户端验证证书:客户端收到服务器返回的数字证书后,会对证书进行一系列验证。首先检查证书是否过期、证书的颁发机构是否受信任(客户端内置了受信任的根证书列表,通过证书链来验证颁发机构的合法性 )、证书上的域名是否与请求的域名一致等。如果证书验证不通过,客户端会显示安全警告,用户可选择是否继续连接;若验证通过,客户端从证书中提取服务器的公钥。
3. 密钥协商阶段
- 生成 pre - master:客户端在验证证书通过后,利用自身生成的 random1 和服务器返回的 random2,再生成一个新的随机密码串,称为 pre - master(预主密钥)。
- 加密传输 pre - master:客户端使用从证书中提取的服务器公钥,对 pre - master 进行加密,并将加密后的信息发送给服务器。
- 服务器解密获取 master - secret:服务器收到客户端发送的加密信息后,使用自己的私钥进行解密,得到 pre - master。然后服务器根据约定的加密算法,结合 random1、random2 和 pre - master,生成 master - secret(主密钥 )。同时,服务器向客户端发送确认信息。
- 客户端生成 master - secret:客户端收到服务器的确认后,按照与服务器相同的算法,利用 random1、random2 和 pre - master,也生成相同的 master - secret 。至此,客户端和服务器双方都拥有了相同的 master - secret,后续将基于这个主密钥生成用于数据加密解密的对称密钥。
4. 加密通信阶段
- 数据加密传输:客户端和服务器使用 master - secret 生成会话密钥(对称密钥 ),之后双方在通信过程中,使用该会话密钥对传输的数据进行对称加密。同时,为保证数据在传输过程中不被篡改,会使用消息认证码(MAC)等技术对数据进行完整性校验。例如,在发送数据前,根据数据内容和会话密钥计算出一个 MAC 值,随数据一同发送;接收方收到数据后,使用相同的算法和会话密钥重新计算 MAC 值,并与接收到的 MAC 值进行比对,若一致则说明数据完整未被篡改。
HTTPS 通过以上过程,综合运用对称加密的高效性和非对称加密的安全性,实现了安全的网络通信,防止数据在传输过程中被窃取、篡改和伪造。
简单来说,就是五条
1)Client 发送 random1+对称加密套件列表+非对称加密套件列表
2)Server收到信息,选择对称加密套件+非对称加密套件,并和random2+证书(公钥在证书中)一起返回
3)Client验证证书有效性,并用random1+random2生成pre-master,通过服务器公钥加密+浏览器确认,发送给 Server
4)Server 收到 pre-master,
根据约定的加密算法对 random1+random2+pre-master(解密)生成master-secret,然后发送服务器确认
5)Client 收到生成同样的 master-secert,对称加密秘钥传输完毕
3.3389无法连接的情况
3389 端口常用于远程桌面连接
首先3389处于关闭状态 你也无法连接
其次3389处于开启状态一.被防火墙策略所拦截二.端口被修改三.处在内网环境中(需要进行端口转发)四.3389端口超过了最大连接数五.管理员策略(只允许特定的用户ip进行连接)六.网络问题导致机器故障,无法连接七.你输入的用户名密码错误
4.ARP欺骗原理(单向、双向欺骗)
每台主机都有一个 ARP 缓存表,缓存表中记录了P 地址与 MAC 地址的对应关系,而局域网数据传输依靠的是 MAC 地址。在 ARP 缓存表机制存在一个缺陷就是当请求主机收到 ARP应答包后,不会去验证自己是否向对方主机发送过 ARP请求包,就直接把这个返回包中的IP 地址与 MAC 地址的对应关系保存进 ARP缓存表中,如果原有相同 IP对应关系,原有的则会被替换。这样攻击者就有了偷听主机传输的数据的可能。
- 单向欺骗:
-
- 例如,攻击者 C 对主机 A 实施欺骗。C 构造虚假 ARP 应答,将网关 G 的 IP 地址映射到 C 的 MAC 地址,并发送给 A。A 的 ARP 缓存更新后,向 G 发送的数据包会错误流向 C,而 G 的 ARP 缓存未变,仍正常向 A 发送数据包。此时,C 可截获 A 发往 G 的数据,但 A 与 G 的通信不完全中断。
- 双向欺骗:
-
- 攻击者 C 同时欺骗主机 A 和网关 G。一方面向 A 发送伪造应答(G 的 IP → C 的 MAC),另一方面向 G 发送伪造应答(A 的 IP → C 的 MAC)。这样,A 与 G 之间的双向通信数据包都会先流经 C,C 可任意截获、篡改数据,甚至不转发导致通信中断,形成 “中间人攻击”。
想了解更多的 可以去看
详解ARP协议工作流程和ARP欺骗原理,以及ARP欺骗攻击实验_请简述apr协议的基本过程,并说明apr欺骗发生在其哪个阶段-CSDN博客
ARP欺骗攻击原理及其防御_arp欺骗原理和防范措施-CSDN博客
中间人攻击——ARP欺骗的原理、实战及防御 - i春秋 - 博客园
5.ARP欺骗防护
ARP 欺骗利用 ARP 协议缺乏验证机制的漏洞,通过伪造 ARP 报文扰乱网络通信。以下是针对 ARP 欺骗的防护措施:
1. 静态绑定 IP 与 MAC 地址
通过手动绑定目标主机(如网关)的 IP 地址和 MAC 地址,确保 ARP 缓存中映射关系的正确性,防止被伪造报文篡改。
- 在计算机上绑定:
-
- Windows 系统使用
arp -s <IP地址> <MAC地址>
命令(如arp -s 192.168.1.1 00-0a-eb-d5-60-80
),但重启后失效,可通过批处理或netsh
命令(如netsh -c "interface ipv4" add neighbors <idx> "<IP>" "<MAC>"
,需以管理员身份运行)实现永久绑定。 - Linux 系统可编辑
/etc/arp.conf
或使用arp -s <IP> <MAC>
命令(临时生效)。
- Windows 系统使用
- 在路由器 / 交换机上绑定:
启用 ARP 绑定功能,将局域网内计算机的 IP 与 MAC 地址进行静态绑定(如路由器的 ARP 映射表设置),防止 ARP 表被恶意更改。
2. 使用 ARP 防火墙
ARP 防火墙实时监测网络中的 ARP 数据包,识别并拦截包含虚假 IP-MAC 映射的恶意 ARP 报文。例如,360 安全卫士、电脑管家等软件自带 ARP 防护功能,可开启并保持更新,以有效抵御攻击。
3. 配置静态 ARP 缓存
在设备中设置静态 ARP 缓存,使其不受动态 ARP 缓存中虚假报文的影响。即使收到新的 ARP 应答,只要与静态缓存冲突,就不会更新,从而保障通信正常。
4. 定期更新系统与软件
及时更新操作系统、路由器固件及安全软件的补丁,修复已知的 ARP 协议相关漏洞,降低被攻击的风险。
5. 采用加密传输协议
使用 HTTPS、SSL/TLS 等加密协议传输数据,即使攻击者截获数据包,也难以解析内容,防止数据被窃取或篡改。
6. 限制网络访问权限
- VLAN 隔离:通过划分 VLAN,将不同用户或设备隔离在不同网络段,缩小 ARP 欺骗的影响范围。
- 端口绑定:在交换机上绑定端口与设备的 MAC 地址,非绑定设备接入时拒绝其通信,减少攻击者接入网络的机会。
7. 交换机安全配置
- 开启 DHCP Snooping:交换机记录通过 DHCP 分配 IP 的设备的 IP、MAC 和端口信息,生成绑定表。后续检查 ARP 报文是否与表中信息一致,不一致则拦截,防止伪造的 ARP 报文误导网络设备。
- 启用 ARP 反攻击功能:如在交换机输入
arp anti-attack check,user-bind enable
命令,通过检查 ARP 报文与绑定表的一致性来抵御攻击。 - 动态 ARP 检测(DAI):交换机记录电脑的 IP、MAC 和端口连接信息,拦截不符合记录的异常 ARP 报文。
8. 定期检查 ARP 缓存
管理员定期通过 arp -a
(Windows)或 arp -n
(Linux)命令检查设备的 ARP 缓存表,查看是否存在异常的 IP-MAC 映射,及时清除可疑条目。
9. 部署专业安全设备
对于企业级网络,可部署入侵检测系统(IDS)、入侵防御系统(IPS)或专用的 ARP 欺骗防御服务器,通过深度分析网络流量,实时识别和阻断 ARP 欺骗攻击。
通过综合运用以上措施,可有效降低 ARP 欺骗的风险,保障网络通信的安全性和稳定性。
6.syn洪流的原理
SYN 洪流(SYN Flood)是一种常见的拒绝服务(DoS)攻击方式,其核心是利用 TCP 协议三次握手的机制漏洞来耗尽目标服务器资源,具体原理如下:
一、正常 TCP 三次握手流程
- 第一次握手:客户端向服务器发送带有
SYN
标志的数据包(SYN
报文),请求建立连接,其中包含客户端的初始序列号(如seq = a
)。 - 第二次握手:服务器收到
SYN
报文后,回复一个带有SYN
和ACK
标志的数据包(SYN-ACK
报文),表示同意连接,同时确认客户端的序列号(ack = a + 1
),并发送自己的初始序列号(如seq = b
)。 - 第三次握手:客户端收到
SYN-ACK
报文后,回复ACK
报文(ack = b + 1
),完成三次握手,此时 TCP 连接建立成功,双方可进行数据交互。
二、SYN 洪流攻击过程
- 伪造请求:攻击者利用工具或控制僵尸主机,向目标服务器发送海量伪造源 IP 地址(或真实 IP 但不响应)的
SYN
报文,请求建立 TCP 连接。 - 服务器响应:服务器收到
SYN
报文后,正常回复SYN-ACK
报文,但由于源 IP 是伪造的(或攻击者不回应),服务器始终收不到客户端的ACK
报文,导致这些连接处于 “半连接” 状态(仅完成前两次握手)。 - 资源耗尽:服务器为每个半连接分配内存、连接队列等资源,并不断重试发送
SYN-ACK
报文(等待超时,如SYN timeout
时间)。当攻击者发送的SYN
报文数量足够多,服务器资源(如 CPU、内存、连接队列)会被这些半连接占满,无法再处理正常用户的连接请求,最终导致服务瘫痪。
三、攻击关键与影响
- 关键:利用 TCP 协议对未完成连接的资源分配机制,通过海量虚假
SYN
报文占用服务器资源。 - 影响:正常用户的连接请求因服务器资源耗尽而被拒绝,导致服务不可用,如网站无法访问、网络服务中断等。
SYN 洪流攻击通过破坏 TCP 连接的正常建立流程,以低成本消耗服务器高成本资源,是一种典型的资源耗尽型攻击。
简写如下:
伪造大量的源 IP 地址,分别向服务器端发送大量的SYN 包,此时服务器端会返回 SYN/ACK 包,因为源地址是伪造的,所以伪造的IP并不会应答,服务器端没有收到伪造 IP 的回应,会重试3~5次并且等待一个 SYNTime(一般为 30 秒至2 分钟),如果超时则丢弃这个连接。攻击者大量发送这种伪造源地址的SYN 请求,服务器端将会消耗非常多的资源(CPU和内存)来处理这种半连接,同时还要不断地对这些IP 进行 SYN+ACK 重试。最后的结果是服务器无暇理睬正常的连接请求,导致拒绝服务。
想了解更多的 可以去看这个
[黑客入门] TCP SYN洪水 (SYN Flood) 攻击原理与实现-腾讯云开发者社区-腾讯云
7.CC攻击原理
CC 攻击(Challenge Collapsar Attack)原理
一、基本定义
CC 攻击是一种基于应用层(HTTP/HTTPS 协议)的分布式拒绝服务(DDoS)攻击,通过模拟大量合法用户对目标服务器的高频访问,消耗其计算资源(如 CPU、内存、连接数等),最终导致服务器无法响应正常请求,属于资源耗尽型攻击。
二、核心原理
CC 攻击利用 Web 应用的 “动态请求处理机制” 和 “合法请求流程” 发起攻击,具体步骤如下:
1. 正常 Web 请求流程(对比)
- 用户通过浏览器向服务器发送 HTTP 请求(如访问页面、提交表单、查询数据等)。
- 服务器接收请求后,解析参数、访问数据库、执行逻辑处理,生成响应并返回给用户。
- 整个过程依赖服务器的计算资源(CPU、内存、I/O 等),动态请求(如需要数据库查询或复杂逻辑的页面)消耗资源更高。
2. CC 攻击流程
- 攻击准备:攻击者控制大量 “僵尸主机”(Botnet)或利用开放代理、CDN 节点等作为傀儡机,隐藏真实 IP。
- 模拟合法请求:傀儡机向目标服务器发送海量真实有效的 HTTP 请求(如频繁访问动态页面、提交表单、搜索数据等),请求内容看似正常,但频率极高(每秒数百 / 数千次)。
- 资源耗尽:
-
- 服务器为每个请求分配资源(如创建线程 / 进程、解析 HTTP 头、执行数据库查询等),动态请求的处理耗时远高于静态资源(如图片、CSS)。
- 当请求量超过服务器处理能力时,资源(如连接队列、CPU 时间、内存)被耗尽,导致正常用户请求被拒绝(返回 503 错误、超时或无法连接)。
三、攻击特点
- 应用层攻击:
-
- 基于 HTTP 协议,攻击流量混杂在正常流量中,难以通过简单的 IP 封禁或端口过滤识别。
- 可针对特定 URL 或接口(如登录接口、搜索功能)精准打击,利用动态请求消耗高资源的特性放大攻击效果。
- “合法” 伪装:
-
- 攻击包使用真实的 HTTP 头部(如 User-Agent、Cookie),甚至模拟浏览器行为(如 Referer、随机请求间隔),绕过传统防火墙的流量特征检测。
- 分布式执行:
-
- 通过僵尸网络或代理池分散攻击源,避免单一 IP 被封禁,且流量分散后更难识别异常。
- 低流量高消耗:
-
- 无需像网络层 DDoS(如 SYN Flood、UDP Flood)那样发送海量无效流量,仅通过高频合法请求即可压垮服务器,攻击成本低。
四、攻击手段
- 直接攻击:
-
- 僵尸主机直接向目标服务器发送高频 HTTP 请求,通常针对动态页面(如
.php
、.asp
、需要数据库交互的接口)。
- 僵尸主机直接向目标服务器发送高频 HTTP 请求,通常针对动态页面(如
- 代理 / 反射攻击:
-
- 通过开放的 HTTP 代理、公共 Web 服务(如搜索引擎、在线翻译)转发攻击请求,隐藏源 IP 并放大流量(反射攻击)。
- 爬虫模拟:
-
- 模拟搜索引擎爬虫(如 Googlebot、Baiduspider)的行为,发送大量爬取请求,消耗服务器爬虫处理资源。
- 状态保持攻击:
-
- 持续保持与服务器的连接(如长连接、未完成的表单提交),占用连接池资源,导致新请求无法建立连接。
五、核心目标与影响
- 目标:耗尽服务器的应用层处理资源(而非带宽),例如:
-
- CPU 处理高频请求逻辑;
- 内存存储请求上下文和会话数据;
- 数据库连接池被大量无效查询占满。
- 影响:
-
- 服务器响应缓慢或超时,正常用户无法访问;
- 应用程序崩溃或自动重启;
- 连带影响依赖服务(如数据库、缓存)性能,形成级联故障。
六、与其他 DDoS 攻击的区别
攻击类型 | 层级 | 流量特征 | 资源消耗点 | 检测难度 |
SYN Flood | 传输层(TCP) | 海量 SYN 包,半连接 | 服务器 TCP 连接队列 | 中等(可通过 SYN Cookie 防御) |
UDP Flood | 网络层 / 传输层 | 海量随机 UDP 包 | 带宽、CPU 校验 | 较低(流量异常易识别) |
CC 攻击 | 应用层(HTTP) | 合法 HTTP 请求,流量正常 | 应用处理资源(CPU、内存) | 高(需结合行为分析) |
总结
CC 攻击通过 “合法请求滥用” 耗尽目标服务器的应用层资源,是一种针对 Web 应用的高效攻击方式。其核心在于利用动态请求的高处理成本和协议合法性绕过传统防御,需通过应用层流量清洗、行为识别、资源限制等手段进行防御。
8.什么是同源策略
一、基本定义
同源策略是浏览器的核心安全机制,用于限制不同源的文档(或脚本)之间的交互,防止恶意网站通过跨源操作窃取用户数据或执行恶意行为。它是浏览器为保护用户数据安全而内置的 “隔离墙”,确保网页只能访问同源的资源,避免跨源攻击(如 XSS、CSRF 等)。
二、“同源” 的定义
两个 URL 的 ** 协议(Protocol)、域名(Domain)、端口(Port)** 完全一致时,视为 “同源”。例如:
- 同源:
http://example.com:80
与http://example.com:80
- 不同源(满足任意一项不同):
-
- 协议不同:
http://example.com
vshttps://example.com
- 域名不同:
http://example.com
vshttp://www.example.com
(子域名不同) - 端口不同:
http://example.com:80
vshttp://example.com:8080
- 协议不同:
三、同源策略的核心限制
同源策略主要限制以下三种跨源交互行为:
1. DOM 访问限制
- 不允许一个源的脚本读取或修改另一个源的网页内容(如 DOM 节点、Cookie、LocalStorage 等)。
-
- 例:若用户同时打开
http://a.com
和http://b.com
,a.com
的脚本无法获取b.com
的页面元素或数据。
- 例:若用户同时打开
2. 跨源 HTTP 请求限制
- 禁止通过 XMLHttpRequest(XHR)、Fetch 等接口向非同源域名发起 HTTP/HTTPS 请求(除非目标服务器允许跨源)。
-
- 例:
http://a.com
的页面无法直接通过 AJAX 请求http://b.com
的 API 接口。
- 例:
3. Cookie 与身份验证限制
- 浏览器不会自动将某个源的 Cookie 发送到非同源的网站,除非明确配置(如通过 CORS 的
withCredentials
)。
-
- 例:用户在
http://bank.com
登录后,http://malicious.com
的脚本无法读取其 Cookie,也无法利用 Cookie 向银行网站发送请求。
- 例:用户在
四、例外与跨源解决方案
虽然同源策略严格限制跨源交互,但在实际开发中,为了实现合理的跨域需求(如前后端分离、第三方 API 调用),存在以下合法的例外机制:
1. 跨源资源共享(CORS,Cross-Origin Resource Sharing)
- 目标服务器通过返回特定 HTTP 头(如
Access-Control-Allow-Origin
),明确允许指定源的请求访问资源。 - 支持细粒度控制(如允许特定方法、头字段、携带 Cookie 等),是现代浏览器推荐的跨源解决方案。
2. JSONP(JSON with Padding)
- 利用
<script>
标签不受同源策略限制的特性,通过动态插入脚本标签加载非同源数据(回调函数形式)。 - 缺点:仅支持 GET 请求,存在 XSS 风险,已逐渐被 CORS 取代。
3. 文档片段(Document Fragment)
- 当两个页面同源但通过锚点(如
#hash
)切换时,可通过window.postMessage
API 实现有限的跨窗口通信。
4. 代理服务器
- 在同源服务器端转发非同源请求(如后端代理 API),绕过浏览器的跨源限制(本质是服务器端无同源策略)。
五、作用与意义
同源策略是浏览器安全的基石,主要保护以下场景:
- 防止 XSS 攻击:恶意脚本无法跨源窃取用户 Cookie 或 DOM 数据。
- 防止 CSRF 攻击:减少攻击者利用用户身份向同源网站发送非法请求的可能。
- 数据隔离:确保不同源的应用(如银行网站与恶意网站)之间无法直接共享敏感信息。
六、总结
同源策略通过 “协议 + 域名 + 端口” 的严格匹配,在浏览器中构建了一道安全边界,限制跨源资源的随意访问。尽管它可能给开发带来跨域问题,但通过 CORS 等标准解决方案,既能保障安全,又能实现合理的跨源交互需求。理解同源策略是 Web 安全和前端开发的核心基础之一。
9.TCP三次握手的过程以及对应的状态转换
TCP 三次握手的过程及状态转换
一、三次握手的核心目标
TCP 通过三次握手建立可靠连接,确保通信双方同步初始序列号(ISN,Initial Sequence Number),并确认双方的接收和发送能力正常。
二、三次握手详细过程
假设客户端为 A,服务器为 B,步骤如下:
第一次握手(A → B:请求连接)
- 客户端 A 从 CLOSED 状态发起连接,向服务器 B 发送一个 SYN 包(同步标志位)。
-
- 包含:
-
-
- 客户端初始序列号
seq = x
(随机生成,避免被预测)。 - 标志位
SYN = 1
,ACK = 0
(此时无确认号)。
- 客户端初始序列号
-
- 服务器 B 收到后,从 LISTEN 状态转为 SYN_RCVD 状态。
第二次握手(B → A:确认请求并发起连接)
- 服务器 B 向客户端 A 回复 SYN+ACK 包。
-
- 包含:
-
-
- 确认号
ack = x + 1
(确认客户端的 SYN,期望接收下一个字节)。 - 服务器初始序列号
seq = y
(随机生成)。 - 标志位
SYN = 1
,ACK = 1
(同时确认客户端请求并发起自己的同步)。
- 确认号
-
- 客户端 A 收到后,从 SYN_SENT 状态转为 ESTABLISHED 状态(连接建立完成,可发送数据)。
第三次握手(A → B:最终确认)
- 客户端 A 向服务器 B 发送 ACK 包。
-
- 包含:
-
-
- 确认号
ack = y + 1
(确认服务器的 SYN)。 - 序列号
seq = x + 1
(沿用之前的序列号,递增 1)。 - 标志位
ACK = 1
,SYN = 0
(无需再同步)。
- 确认号
-
- 服务器 B 收到后,从 SYN_RCVD 状态转为 ESTABLISHED 状态(双方连接完全建立)。
三、客户端与服务器状态转换表
阶段 | 客户端状态变化 | 服务器状态变化 |
初始状态 | CLOSED | LISTEN |
第一次握手后 | CLOSED → SYN_SENT | LISTEN → SYN_RCVD |
第二次握手后 | SYN_SENT → ESTABLISHED | SYN_RCVD |
第三次握手后 | ESTABLISHED | SYN_RCVD → ESTABLISHED |
四、关键状态含义
- CLOSED:无连接,初始状态。
- LISTEN:服务器等待客户端连接请求。
- SYN_SENT:客户端已发送连接请求,等待服务器确认。
- SYN_RCVD:服务器已收到客户端请求,正在处理(半连接状态)。
- ESTABLISHED:连接完全建立,双方可双向通信。
五、为什么需要三次握手?
- 防止重复连接:若只有两次握手,旧的重复 SYN 包可能被误认为有效请求,导致资源浪费(如 “SYN 洪泛攻击” 利用此漏洞)。
- 双向确认:三次握手确保客户端和服务器都确认对方的发送和接收能力(第二次握手确认客户端→服务器,第三次握手确认服务器→客户端)。
六、常见问题
- 第二次握手后,服务器处于半连接状态(SYN_RCVD):此时服务器已分配资源(如缓冲区),但客户端可能因超时未发送第三次握手,导致资源浪费(需通过超时重传或 SYN Cookie 优化)。
- 三次握手的序列号作用:通过序列号确保数据按序接收,重复数据可被去重,乱序数据可被重组。
通过三次握手,TCP 在不可靠的 IP 层上建立了可靠的端到端连接,是网络通信中可靠性的基石。
10.TCP和UDP协议的区别
TCP(传输控制协议)和 UDP(用户数据报协议)是 TCP/IP 体系中两种核心传输层协议,主要区别体现在连接方式、可靠性、传输效率、应用场景等方面,具体对比如下:
1. 连接方式
- TCP:
-
- 面向连接(Connection-Oriented),通信前需通过 三次握手 建立连接,通信结束后通过 四次挥手 断开连接。
- 确保通信双方存在有效连接后才开始数据传输。
- UDP:
-
- 无连接(Connectionless),无需提前建立连接,直接发送数据报(Datagram)。
- 不管对方是否存在或可达,直接发送,“尽最大努力交付”。
2. 可靠性
- TCP:
-
- 可靠传输,通过以下机制保证数据准确到达:
-
-
- 确认机制:接收方收到数据后返回 ACK 确认,发送方未收到确认则重传。
- 序列号与排序:数据按序列号排序,乱序数据重新组装。
- 错误检测与重传:通过校验和检测错误,丢失或损坏的数据重传。
- 流量控制与拥塞控制:滑动窗口控制发送速率,避免网络拥塞。
-
- UDP:
-
- 不可靠传输,不保证数据到达、不处理重复或乱序、无重传机制。
- 数据是否正确到达由应用层负责(如 DNS、视频流自行处理丢包)。
3. 传输模式
- TCP:
-
- 流式传输(Stream),数据无边界,发送方和接收方以字节流为单位处理数据。
- 例如:发送 “ABC” 和 “DEF” 可能被接收为连续的 “ABCDEF”,需应用层自行拆分包。
- UDP:
-
- 数据报传输(Datagram),每个数据报是独立的单位(最大 65507 字节),有明确边界。
- 发送方发送一个数据报,接收方接收一个完整的数据报,不会合并或拆分。
4. 应用场景
- TCP:
-
- 适用于 对可靠性要求高 的场景,如:
-
-
- 网页浏览(HTTP/HTTPS)、文件传输(FTP)、电子邮件(SMTP/POP3)、远程登录(SSH/Telnet)。
- 需保证数据完整、有序到达,允许一定延迟(如文件下载、数据传输)。
-
- UDP:
-
- 适用于 对实时性要求高、允许少量丢包的场景,如:
-
-
- 视频流(RTSP、RTP)、音频通话(VoIP)、直播(UDP 组播)。
- 轻量型服务(DNS 查询、SNMP 监控、NTP 时间同步),减少协议开销。
- 游戏(实时交互,少量丢包可通过应用层补偿)。
-
5. 头部开销
- TCP:
-
- 固定头部 20 字节,若包含可选项(如窗口扩大、时间戳),最多可达 60 字节。
- 头部字段包括:源 / 目标端口、序列号、确认号、标志位(SYN/ACK/FIN 等)、窗口大小、校验和等。
- UDP:
-
- 固定头部仅 8 字节,字段简单:源 / 目标端口、长度、校验和(可选,非必需)。
- 无额外控制字段,开销小,传输效率高。
6. 传输效率与延迟
- TCP:
-
- 因可靠性机制(确认、重传、流量控制),传输效率较低,延迟较高(尤其网络拥塞时)。
- 适合 “稳定优先” 的场景。
- UDP:
-
- 无额外开销,发送速度快,延迟低(省去连接建立和错误处理时间)。
- 适合 “速度优先” 的场景。
7. 流量与拥塞控制
- TCP:
-
- 内置 滑动窗口(流量控制)和 拥塞控制算法(慢启动、拥塞避免、快速重传、快速恢复),动态调整发送速率,避免网络拥塞。
- UDP:
-
- 无流量控制和拥塞控制,发送方以固定速率发送数据,可能导致网络拥塞(需应用层自行处理)。
8. 连接特性
- TCP:
-
- 点对点连接(1 对 1),不支持多播(Multicast)或广播(Broadcast)。
- UDP:
-
- 支持 单播、多播、广播,可向多个接收方发送数据(如组播视频流)。
总结对比表
特性 | TCP | UDP |
连接方式 | 面向连接(三次握手 / 四次挥手) | 无连接(直接发送数据报) |
可靠性 | 可靠(确认、重传、排序、流量控制) | 不可靠(无确认、不保证到达) |
传输模式 | 流式(无边界) | 数据报(有边界,独立单位) |
应用场景 | 可靠性优先(HTTP、FTP、邮件) | 实时性优先(视频、DNS、游戏) |
头部开销 | 20 字节(固定),最大 60 字节 | 8 字节(固定) |
传输效率 | 低(可靠性机制开销) | 高(无额外开销) |
流量 / 拥塞控制 | 有 | 无 |
多播 / 广播支持 | 不支持 | 支持 |
延迟 | 高(连接建立、重传耗时) | 低(无连接,即发即走) |
核心差异总结
TCP 像 “打电话”,需先接通(建立连接),说话有确认(可靠),但可能有延迟;
UDP 像 “发短信”,无需接通,发了就不管(不可靠),但速度快,适合实时场景。
根据应用需求(可靠性 vs 实时性)选择合适的协议。
11.多线程、多进程区别
基本概念
- 进程(Process)
-
- 操作系统资源分配的基本单位,每个进程拥有独立的内存空间(堆、栈、全局变量等)、文件描述符等资源。
- 进程之间相互隔离,一个进程崩溃不会直接影响其他进程。
- 线程(Thread)
-
- CPU调度的基本单位,属于同一进程的多个线程共享进程的内存和资源(如全局变量、文件句柄)。
- 线程之间缺乏隔离,一个线程崩溃可能导致整个进程终止。
多线程和多进程是实现并发编程的两种重要方式,在操作系统和编程中有着广泛应用,它们的区别主要体现在以下方面:
资源占用
- 多进程:每个进程都有独立的内存空间、系统资源(如文件描述符)和数据段。创建进程时,操作系统会为其分配新的内存块,这意味着多进程占用的系统资源更多。例如,运行多个浏览器进程时,每个进程都有自己独立的内存空间,即使某个进程崩溃,也不会影响其他进程。
- 多线程:线程是轻量级的执行单元,多个线程共享所属进程的内存空间、全局变量、文件句柄等资源。线程只拥有自己独立的栈空间和寄存器,所以创建和销毁线程的开销较小,占用的系统资源也相对较少。
并发性
- 多进程:进程之间的并发是真正的并行,在多核 CPU 系统中,不同进程可以同时在不同的 CPU 核心上运行。例如,在服务器端,多个进程可以同时处理不同用户的请求,提高系统的并发处理能力。
- 多线程:线程的并发可以是并行(多核 CPU)或并发(单核 CPU)。在多核 CPU 上,多个线程可以同时在不同核心上运行;在单核 CPU 上,线程通过时间片轮转的方式实现并发执行。例如,一个图形处理程序中的多个线程可以分别处理图像的不同部分,提高处理效率。
数据共享
- 多进程:由于进程有独立的内存空间,进程间的数据共享比较复杂,需要借助特定的进程间通信(IPC)机制,如管道、消息队列、共享内存、信号量等。例如,在一个分布式系统中,不同进程之间通过网络通信来共享数据。
- 多线程:线程共享所属进程的内存空间,因此数据共享相对容易。线程可以直接访问和修改进程中的全局变量和其他共享数据结构。不过,这也容易引发数据竞争和不一致问题,需要使用同步机制(如互斥锁、信号量、条件变量)来保证线程安全。
通信方式
- 多进程:进程间通信(IPC)方式有多种,如管道、消息队列、共享内存、信号量等。不同的 IPC 方式适用于不同的场景,例如,管道适合在父子进程之间进行简单的数据传输;共享内存适合在多个进程之间进行大量数据的共享。
- 多线程:线程间通信主要通过共享内存实现,即线程可以直接访问和修改进程中的全局变量和其他共享数据结构。此外,线程还可以使用一些同步原语(如互斥锁、信号量、条件变量)来实现线程间的同步和通信。
健壮性
- 多进程:一个进程的崩溃通常不会影响其他进程,因为每个进程都有独立的内存空间和系统资源。因此,多进程的健壮性较高,适合用于对稳定性要求较高的场景,如服务器端程序。
- 多线程:一个线程的崩溃可能会导致整个进程崩溃,因为线程共享所属进程的资源。例如,一个线程出现内存访问错误,可能会导致整个进程崩溃。因此,多线程的健壮性相对较低。
编程复杂度
- 多进程:进程间通信和同步机制相对复杂,需要使用特定的 IPC 方式和同步原语,编程难度较大。例如,使用共享内存进行进程间通信时,需要考虑数据的一致性和并发访问问题。
- 多线程:线程间共享内存,数据共享相对容易,但需要处理好线程安全问题,避免出现数据竞争和不一致问题。因此,多线程编程也需要一定的技巧和经验,但相对多进程编程来说,复杂度稍低。
在实际应用中,需要根据具体的需求和场景来选择使用多进程还是多线程。如果需要处理大量的 CPU 密集型任务,且对稳定性要求较高,可以选择多进程;如果需要处理大量的 I/O 密集型任务,且对资源利用率和响应速度要求较高,可以选择多线程。
12.NTLM原理
NTLM(NT LAN Manager)是微软 Windows 系统中用于实现身份验证的一种协议,主要用于在客户端和服务器之间进行双向身份验证,避免明文密码传输。其核心原理基于挑战 - 响应机制,通过密码哈希值完成认证。以下是 NTLM 的核心原理和工作流程:
一、NTLM 的发展与版本
- NTLMv1:早期版本,安全性较低,易受字典攻击和重放攻击。
- NTLMv2(Windows NT 4.0 SP4 后引入):增强安全性,增加客户端 IP / 端口信息、会话密钥等,防止重放攻击,目前较常用。
二、NTLM 认证的核心流程(以 NTLMv2 为例)
NTLM 认证通常发生在客户端访问服务器资源(如文件共享、Web 服务)时,分为三个阶段,涉及三次消息交互(Type 1、Type 2、Type 3 消息):
1. 客户端发送协商请求(Type 1 Message:Negotiate Message)
- 客户端行为:向服务器发送包含自身支持的 NTLM 版本、加密算法(如 DES、AES)、功能标志(如是否请求会话密钥)等信息的协商包。
- 核心目的:告知服务器 “我想访问资源,请进行认证”,并协商认证参数。
2. 服务器发送挑战(Type 2 Message:Challenge Message)
- 服务器行为:
-
- 生成一个 16 字节的随机数(Challenge 值,又称 “质询”)。
- 若服务器需要验证客户端身份,会将 Challenge 值、服务器域名、服务名(如 HTTP、SMB)等信息返回给客户端。
- 关键作用:服务器通过 Challenge 值确保每次认证的唯一性,防止重放攻击。
3. 客户端生成响应并认证(Type 3 Message:Response Message)
- 客户端行为:
-
- 生成用户哈希:
-
-
- 客户端使用用户输入的密码,生成两种哈希值(仅 NTLMv2):
-
-
-
-
- NTLM Hash:密码的 UTF-16 小端格式经 MD4 哈希后的 16 字节值。
- HMAC-MD5 密钥:基于 NTLM Hash 进一步生成的密钥,用于后续签名。
-
-
-
- 生成响应值(Response):
-
-
- 将 Challenge 值、客户端信息(如 IP、端口)、会话信息等,通过 HMAC-MD5 算法与 HMAC-MD5 密钥结合,生成 16 字节的响应值。
-
-
- 发送响应:将响应值、用户名、域名、客户端挑战等信息打包发送给服务器。
- 服务器验证:
-
- 服务器通过用户账户数据库获取用户的 NTLM Hash。
- 用相同的算法(HMAC-MD5)基于用户 NTLM Hash 和接收到的 Challenge 值生成预期响应,与客户端发送的响应对比。
- 若一致,则认证成功,服务器生成会话密钥(用于后续通信加密);否则失败。
三、NTLM 的核心特性
- 避免明文传输密码:
客户端从不直接发送密码,而是发送密码的哈希值及基于哈希的响应,提升安全性。 - 双向认证(可选):
除客户端认证外,服务器也可向客户端证明自身身份(通过服务器的 Challenge 和响应校验)。 - 会话密钥生成:
认证成功后,客户端和服务器可生成共享的会话密钥,用于加密后续通信数据(如文件传输、命令执行)。 - 跨平台限制:
NTLM 主要用于 Windows 环境,跨平台(如 Linux 服务器)需通过插件(如 Samba)支持。
四、NTLMv1 vs NTLMv2 的关键区别
特性 | NTLMv1 | NTLMv2 |
Challenge 长度 | 8 字节(易被穷举) | 16 字节(安全性更高) |
客户端信息 | 不包含 IP、端口等上下文 | 包含客户端 IP、端口,防止重放攻击 |
哈希算法 | LM Hash(不安全,已废弃)或 NTLM Hash | HMAC-MD5(更安全的密钥派生方式) |
抗重放能力 | 弱(Challenge 可被重用) | 强(结合客户端上下文) |
五、NTLM 的应用场景与安全问题
- 应用场景:
-
- 内网环境中的文件共享(SMB 协议)、远程桌面(RDP)、Web 服务(如 IIS 启用 NTLM 认证)等。
- 当客户端无法使用更安全的 Kerberos 协议时(如跨域、旧系统兼容)。
- 安全风险:
-
- NTLMv1 已过时:易受字典攻击(因 Challenge 短、哈希算法弱),微软已建议禁用。
- 中间人攻击:攻击者可拦截 Challenge 和 Response,伪造身份(NTLMv2 通过客户端上下文缓解此问题)。
- 哈希泄露:若用户哈希被窃取,攻击者可利用 “哈希传递”(Pass-the-Hash)攻击直接认证。
六、总结
NTLM 通过挑战 - 响应机制和密码哈希处理,在不传输明文密码的前提下实现身份认证,是 Windows 环境中重要的 legacy 认证协议。尽管 NTLMv2 提升了安全性,但在现代网络中,更推荐使用 Kerberos 协议(基于票据,安全性更高)。NTLM 目前主要用于兼容性场景,但其部署需注意版本安全(禁用 v1)和网络边界防护(防止哈希泄露)。
简写如下:
Windows认证包括三个部分:本地认证、网络认证、域认证。在本地登录 Windows 的情况下,操作系统会使用用户输入的密码作为凭证去与系统中的密码进行验证,当我们登录系统的时候,系统会自动地读取SAM 文件中的“密码”与我们输入的“密码”进行比对,如果相同证明认证成功。这个 SAM 文件中保留了计算机本地所有用户的凭证信息,可以理解为是一个数据库。Windows本身不保存明文密码,只保留密码的 Hash。在 Windows 中密码Hash 目前称之为 NTLM Hash,其中 NTLM 全称是:“NT LAN Manager”。这个 NTLM 是一种网络认证协议,与 NTLM Hash 的关系就是:NTLM 网络认证协议是以 NTLM Hash 作为根本凭证进行认证的协议。也就是说 NTLM 与 NTLMHash 相互对应。在本地认证的过程中,其实就是将用户输入的密码转换为 NTLMHash与 SAM 中的 NTLM Hash 进行比较。
13.什么是中间人攻击
中间人攻击是一种网络攻击手段,攻击者通过拦截、篡改或窃取通信双方(如客户端与服务器)之间的原始数据,伪装成双方的 “中间人”,使通信双方误以为在直接交互,实则所有数据都经过攻击者中转。这种攻击破坏了通信的机密性、完整性和真实性,可导致敏感信息泄露、数据篡改或身份伪造。
核心原理
攻击者通过以下步骤介入正常通信:
- 拦截通信链路:攻击者插入到通信双方之间(如通过网络嗅探、ARP 欺骗、DNS 劫持等),成为数据传输的中转站。
- 伪装身份:向客户端伪装成服务器,向服务器伪装成客户端,使双方误认为攻击者是合法通信对象。
- 窃取或篡改数据:在转发数据前,攻击者可读取、修改、删除数据,甚至注入恶意内容(如钓鱼链接、恶意软件)。
常见攻击类型
1. ARP 欺骗(ARP 中毒)
- 原理:攻击主机伪造 ARP 响应包,将目标主机的 IP 地址映射到自己的 MAC 地址,导致目标主机的流量流经攻击者。
- 场景:局域网(如 Wi-Fi 热点)中,攻击者可拦截同一网段内设备的通信(如窃取登录凭证、监控流量)。
2. DNS 欺骗
- 原理:攻击者篡改 DNS 解析结果,将用户请求的合法域名(如
www.example.com
)指向恶意服务器的 IP 地址。 - 场景:用户访问伪造的钓鱼网站,输入账号密码时被攻击者窃取。
3. HTTPS 劫持(SSL 剥离)
- 原理:攻击者强制客户端与服务器之间的 HTTPS 连接降级为 HTTP(通过拦截 SSL 握手过程),从而窃取明文数据。
- 漏洞利用:利用客户端未严格验证服务器证书的缺陷,或通过中间人伪造证书。
4. 会话劫持(Session Hijacking)
- 原理:攻击者窃取用户的会话 Cookie 或令牌,冒充用户与服务器交互,获取用户权限(如购物车信息、转账操作)。
攻击过程示例(以 HTTP 通信为例)
- 正常通信:客户端(A)→ 服务器(B)直接交互。
- 攻击介入:
-
- 攻击者(M)拦截 A 的请求,伪装成 B 向 A 发送伪造的公钥(或证书)。
- A 向 “B”(实际是 M)发送加密数据,M 用伪造的公钥解密,读取或修改数据后,再用真实 B 的公钥加密转发给 B。
- B 的响应同理,经 M 中转后回到 A,全程 A 和 B 未察觉异常。
主要危害
- 数据窃取:攻击者获取用户账号、密码、信用卡信息等敏感数据。
- 数据篡改:修改交易金额、订单内容、网页内容(如插入恶意广告或钓鱼链接)。
- 身份伪造:冒充合法用户或服务器,执行非法操作(如转账、文件窃取)。
- 会话劫持:接管用户会话,长期监控或操纵用户行为。
总结
中间人攻击的核心是破坏通信的 “直接性”,攻击者通过技术手段成为通信的中转站,窃取或篡改数据。防范的关键在于加密通信、严格验证身份和修复协议漏洞。在现代网络中,随着 HTTPS 和 TLS 的普及,传统中间人攻击的难度增加,但攻击者仍可能利用配置缺陷(如弱证书验证)或新型漏洞发起攻击,因此需结合技术手段与安全意识综合防护。
14.防御中间人攻击的方案
防范措施
- 使用加密协议:
-
- 强制使用HTTPS(基于 TLS/SSL),验证服务器证书的有效性(防止证书伪造)。
- 避免使用未加密的协议(如 HTTP、FTP、Telnet)传输敏感数据。
- 验证身份与通信完整性:
-
- 通过数字签名、公钥基础设施(PKI)确保通信双方身份真实。
- 使用 HMAC 等技术校验数据完整性,防止篡改。
- 网络安全配置:
-
- 禁用局域网内的 ARP 动态更新,绑定静态 ARP 表(
arp -s IP MAC
)。 - 使用 DNSSEC(DNS 安全扩展)防止 DNS 缓存污染。
- 禁用局域网内的 ARP 动态更新,绑定静态 ARP 表(
- 增强客户端安全性:
-
- 浏览器开启 “严格传输安全”(HSTS),拒绝降级到 HTTP。
- 定期更新系统和软件,修复协议漏洞(如 Heartbleed 漏洞曾被用于 MITM 攻击)。
- 使用 VPN 或代理:
-
- 通过 VPN 建立加密通道,使攻击者无法解析隧道内的数据。
15.描述tcp/udp的区别及优劣,及其发展前景
一、核心差异:设计哲学与机制对比
TCP(传输控制协议)与 UDP(用户数据报协议)是互联网传输层的两大支柱,其设计目标的差异决定了它们的应用场景:
维度 | TCP | UDP |
连接性 | 面向连接(三次握手 / 四次挥手) | 无连接(即发即走) |
可靠性 | 保证数据完整、有序交付(丢包重传、序列号、ACK 确认) | 不保证可靠性(可能丢包、乱序) |
延迟 | 高延迟(需等待确认) | 低延迟(无需握手和确认) |
流量控制 | 滑动窗口、拥塞控制(防止网络过载) | 无流量控制(依赖应用层) |
头部开销 | 20 字节固定头部 + 可选字段(如时间戳、SACK) | 8 字节固定头部 |
协议栈依赖 | 依赖操作系统内核实现(难以自定义) | 可在用户态实现(如 QUIC) |
典型比喻:
- TCP:如同顺丰快递,全程追踪、签收确认,确保包裹完好无损。
- UDP:如同街头传单派发,快速覆盖人群,但可能飘落在地无人接收。
二、优劣对比:场景化选择逻辑
场景需求 | TCP 优势 | UDP 优势 |
文件下载 / 网页浏览 | 确保数据完整性(如 HTTP、FTP) | 不适用(丢包会导致文件损坏) |
视频直播 / 在线游戏 | 延迟高(卡顿明显) | 低延迟(允许少量丢包) |
物联网传感器数据 | 连接开销大(设备资源受限) | 轻量级(适配低功耗设备) |
实时语音通话 | 重传机制导致延迟抖动 | 实时性优先(如 RTP/RTCP 协议) |
金融交易 / 数据库同步 | 强一致性(如 MySQL 复制) | 不适用(数据丢失风险高) |
关键劣势:
- TCP:
-
- 队头阻塞(Head-of-Line Blocking):单个数据包丢失会阻塞整个连接,导致 HTTP/2 性能下降16。
- 握手延迟:三次握手 + TLS 协商需 3 个 RTT,影响移动端快速连接3。
- 资源消耗:每个连接需维护状态(如拥塞窗口),服务器并发压力大。
- UDP:
-
- 不可靠性:需应用层实现重传(如 QUIC 的 ACK 机制)。
- 无拥塞控制:可能引发网络拥塞(如早期视频直播导致网络瘫痪)。
- 安全风险:无加密(需依赖 DTLS 或应用层加密)。
三、发展前景:技术演进与生态竞争
1. TCP 的持续进化
- 协议优化:
-
- BBR 拥塞控制:基于带宽和延迟的主动控制,减少队列积压,提升吞吐量(如 YouTube 视频传输效率提升 30%)11。
- Fast Open:在首次握手携带数据,减少延迟(Windows 11 已支持)5。
- Multipath TCP:多路径传输(如同时使用 Wi-Fi 和 4G),提升可靠性。
- 应用场景:
-
- 传统互联网:HTTP/2、邮件传输、文件同步等对可靠性要求高的场景。
- 云服务:数据库同步(如 MySQL Replication)、容器网络(如 Kubernetes)。
- 挑战:
-
- QUIC 的冲击:HTTP/3 基于 UDP,性能优势明显(如连接建立速度快 3 倍)3。
- 硬件卸载:部分场景转向 RDMA(直接内存访问),绕过 TCP 栈。
2. UDP 的崛起与革新
- 技术突破:
-
- QUIC 协议:Google 开发的 HTTP/3 底层协议,整合 TLS 1.3 加密、多路复用和连接迁移(如 WiFi 切 4G 不掉线)1。
- DTLS:基于 UDP 的安全传输(如 IoT 设备的 MQTT-SN 协议),支持低延迟加密7。
- eBPF 优化:用户态自定义 UDP 处理逻辑(如游戏服务器的反作弊系统)。
- 应用爆发:
-
- 实时通信:视频会议(Zoom)、云游戏(NVIDIA GeForce NOW)。
- 物联网:低功耗传感器(如 Air724UG 模组的 UDP 通信)、车联网(V2X)。
- 5G 与边缘计算:URLLC 场景(如工业自动化)要求 1ms 级延迟14。
- 挑战:
-
- 标准化滞后:QUIC 仍在 IETF 标准化中,兼容性问题待解决。
- 网络中间件支持:防火墙、NAT 对 UDP 的限制(如端口耗尽)。
3. 协议融合与新兴技术
- 混合协议:
-
- SCTP:支持多路径传输和可靠性(如 5G 核心网信令)1。
- DCCP:无连接但带拥塞控制(如实时流媒体)1。
- 量子通信:TCP 的握手机制无法适应量子网络的瞬时连接,UDP 可能成为过渡方案。
- AI 驱动协议:如基于强化学习的动态协议选择(根据网络状况自动切换 TCP/UDP)。
四、未来十年趋势预测
- UDP 主导实时领域:
-
- 5G、元宇宙、AR/VR 等场景将推动 UDP 成为主流(如 8K 直播需 100Mbps 带宽,TCP 延迟无法满足)14。
- 典型案例:TikTok 的直播推流已全面转向 UDP。
- TCP 巩固可靠传输:
-
- 金融、医疗等对数据完整性要求极高的领域仍依赖 TCP。
- 改进方向:结合 BBR 和 eBPF 实现硬件加速(如 SmartNIC 卸载 TCP 处理)。
- QUIC 重塑 Web 生态:
-
- HTTP/3 普及率将超 50%(2025 年 Google 预测),推动 CDN、云服务全面转向 UDP。
- 挑战:现有防火墙规则需适配 QUIC 的加密包头。
- 协议消亡论不成立:
-
- TCP 和 UDP 将长期共存,类似 “邮政系统” 与 “即时通讯” 的互补关系。
- 新兴协议(如 QUIC、SCTP)将作为中间层,而非完全替代。
五、总结:选择策略与技术建议
- 优先 UDP:
-
- 实时性要求高(如游戏、视频)。
- 设备资源受限(如 IoT 传感器)。
- 需自定义传输逻辑(如 P2P 文件共享)。
- 优先 TCP:
-
- 数据完整性至上(如金融交易)。
- 对延迟不敏感(如文件下载)。
- 依赖现有基础设施(如企业 VPN)。
- 未来布局:
-
- 关注 QUIC 的标准化进展(如 IETF RFC 9000)。
- 探索 UDP 在安全领域的应用(如 DTLS+MQTT-SN)。
- 测试 TCP BBR 在高带宽场景的性能(如 Windows 11 手动启用)。
TCP 和 UDP 的竞争本质是 “可靠” 与 “效率” 的永恒博弈。随着技术创新,两者将在各自领域持续优化,而 QUIC 等新协议的崛起则标志着传输层进入 “混合架构” 时代。开发者需根据场景需求灵活选择,并关注协议栈与硬件加速的深度融合。
简写:
TCP-传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前,必须先在双方之间建立一个TCP 连接,之后才能传输数据。
TCP 提供超时重发,丢弃重复数据,检验数据,流量控制等功能,保证数据能从一端传到另一端。(TCP 建立连接 完整性强 速度慢)
UDP-用户数据报协议,是一个简单的面向数据报的运输层协议。UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地。
由于 UDP 在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快(UDP 不建立连接不可靠 速度快)
优劣:当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时TCP 协议是当然的选择。当强调传输性能而不是传输的完整性时,如:音频和多媒体应用,UDP是最好的选择。在数据传输时间很短,以至于此前的连接过程成为整个流量主体的情况下,UDP 也是一个好的选择,如:DNS交换。
16.公司网络安全具体指什么
公司网络安全是指通过技术、管理、流程等手段,保护企业网络系统、数据资产、业务应用免受内部或外部威胁(如攻击、滥用、泄露、破坏等),确保业务连续性、数据完整性和合规性的整体防护体系。其核心目标是 “机密性、完整性、可用性”(CIA 三要素),具体涵盖以下核心领域:
一、基础设施安全:筑牢网络 “地基”
- 网络边界防护
-
- 防火墙(FW):过滤进出流量(如 ACL 规则、NAT 转换),阻止未经授权的访问(如恶意 IP、危险端口)。
- 入侵检测 / 防御系统(IDS/IPS):实时监控异常流量(如端口扫描、DDoS 攻击),主动阻断或预警。
- VPN / 零信任(Zero Trust):加密远程访问通道(如员工通过 VPN 接入内网),基于 “持续验证,永不信任” 原则,最小化权限分配(如仅开放必要业务系统访问)。
- 核心设备安全
-
- 路由器、交换机的访问控制(如 SNMPv3 加密、ACL 限制管理端口)。
- 防止 ARP 欺骗、DHCP 劫持等二层攻击(如静态绑定 MAC 地址)。
- 抗 DDoS 攻击
-
- 部署流量清洗设备(如阿里云 DDoS 防护),识别并过滤海量恶意流量(如 SYN Flood、DNS 放大攻击)。
二、数据安全:保护企业 “血液”
- 数据全生命周期防护
-
- 存储安全:数据库加密(如 TDE 透明数据加密)、文件存储访问控制(如 NAS 权限管理)。
- 传输安全:HTTPS/TLS 加密数据传输(防止中间人攻击)、IPSec 加密内网通信。
- 终端安全:敏感数据脱敏(如员工工资表隐藏部分字段)、U 盘加密(防止数据外带)。
- 访问控制
-
- 权限管理(RBAC):按角色分配权限(如财务人员仅能访问报销系统),避免越权操作。
- 身份认证:多因素认证(MFA,如密码 + 短信验证码 + 硬件令牌),防止账号盗用(如钓鱼攻击窃取密码)。
- 数据备份与恢复
-
- 定期备份关键数据(如数据库每日全量备份 + 增量备份),测试恢复流程(如模拟服务器崩溃后的业务重启)。
三、应用安全:守护业务 “引擎”
- 漏洞管理
-
- 扫描应用漏洞(如 OWASP Top 10,常见 SQL 注入、XSS 攻击),及时修复补丁(如 Java 反序列化漏洞 CVE-2021-21354)。
- 代码审计:在开发阶段检测安全缺陷(如使用 SonarQube 扫描代码逻辑漏洞)。
- 业务逻辑安全
-
- 防止越权访问(如用户 A 通过修改 URL 参数访问用户 B 的订单数据)。
- 接口安全:限制 API 调用频率(防暴力破解)、校验输入参数(防止恶意 payload)。
- 第三方组件安全
-
- 监控开源组件漏洞(如 Log4j2 漏洞导致的远程代码执行),使用依赖检查工具(如 OWASP Dependency-Check)。
四、终端与端点安全:防御 “最后一公里”
- 设备安全
-
- 终端杀毒:部署企业级防病毒软件(如卡巴斯基安全云),实时查杀恶意软件(如勒索病毒 WannaCry)。
- 端点准入(NAC):设备接入网络前检查合规性(如是否安装最新补丁、是否为授权设备),阻止未授权设备入网(如员工私自带入的笔记本电脑)。
- 移动设备管理(MDM)
-
- 远程擦除丢失设备的数据(如员工手机被盗后清除企业应用数据),限制非合规应用安装(如禁止安装盗版软件)。
- 员工行为监控
-
- 审计员工操作日志(如谁何时访问了客户数据),检测异常行为(如凌晨批量下载敏感文件)。
五、人员与管理安全:破解 “最弱一环”
- 安全意识培训
-
- 定期开展钓鱼邮件演练(如模拟伪造 CEO 邮件要求转账,统计员工点击量),培训密码安全(如 8 位以上大小写 + 数字组合,定期更换)。
- 合规与制度
-
- 制定安全政策(如《数据分类分级管理制度》《远程办公安全规范》)。
- 符合法规要求(如中国《网络安全法》、欧盟 GDPR,需向用户明示数据收集目的并获得授权)。
- 应急响应
-
- 制定应急预案(如发生数据泄露时的通报流程、系统恢复步骤),定期演练(如模拟服务器被植入后门后的应急处置)。
六、新兴领域与扩展场景
- 云安全
-
- 公有云(如 AWS、阿里云)的安全组配置、S3 存储桶权限管理,防止 “影子 IT”(员工私自使用未备案的云服务)。
- 工业互联网安全
-
- 保护 OT(运营技术)设备(如工厂 PLC 控制器),防止恶意攻击导致生产中断(如震网病毒攻击伊朗核设施)。
- 物联网(IoT)安全
-
- 智能设备漏洞修复(如摄像头弱密码导致被劫持为肉鸡),通信加密(如 MQTT 协议的 TLS 加密)。
七、典型威胁与防御示例
威胁类型 | 具体案例 | 防御措施 |
内部泄露 | 员工通过邮件发送客户数据到私人邮箱 | DLP 数据防泄漏系统(监控敏感关键词,阻断外发) |
钓鱼攻击 | 伪造公司 OA 系统登录页面骗取账号密码 | 部署反钓鱼网关,启用 MFA 二次认证 |
勒索病毒 | 员工打开恶意附件导致文件被加密并索要比特币 | 定期备份数据,禁用未知来源文件执行权限 |
API 攻击 | 利用未授权 API 获取用户订单信息 | 接口鉴权(如 JWT 令牌)、速率限制(Rate Limit) |
总结:构建 “端 - 网 - 数 - 人” 立体防护体系
公司网络安全不是单一技术的堆砌,而是 “技术 + 管理 + 人员” 的系统化工程:
- 技术层:防火墙、加密、漏洞扫描等工具提供底层支撑;
- 管理层:安全制度、合规要求、应急流程确保体系落地;
- 人员层:安全意识培训减少人为失误,形成全员参与的安全文化。
随着网络攻击复杂化(如 APT 高级持续性威胁),企业需从 “被动防御” 转向 “主动检测”,结合 AI 分析异常行为(如用户画像识别账号盗用),最终实现 “业务安全与效率的平衡”—— 在保护资产的同时,不影响正常办公与创新。
简写:
1)基础网络安全(按网络区域划分)
网络终端安全:防病毒(网络病毒、邮件病毒)、非法入侵、共享资源控制;内部局域网(LAN)安全:内部访问控制(包括接入控制)、网络阻塞(网络风暴)、病毒检测;
外网(Internet)安全:非法入侵、病毒检测、流量控制、外网访问控制。
2)系统安全(系统层次划分)
硬件系统级安全:门禁控制、机房设备监控(视频)、防火监控、电源监控(后备电源)、设备运行监控;
操作系统级安全:系统登录安全、系统资源安全、存储安全、服务安全等应用系统级安全:登录控制、操作权限控制。
3)数据、应用安全(信息对象划分)
本地数据安全:本地文件安全、本地程序安全
服务器数据安全:数据库安全、服务器文件安全、服务器应用系统、服务程序安全
17.如何判断计算机可能已经中马
判断计算机是否感染木马(恶意软件)需要结合系统异常表现、资源占用、网络活动等多方面观察。以下是常见的检测方法和迹象,可帮助用户初步判断:
一、系统性能异常:资源被异常占用
- 卡顿或响应缓慢
-
- 电脑突然变得异常卡顿,打开程序、文件或网页明显延迟,即使无复杂操作,CPU 或内存使用率长期居高不下(任务管理器中查看
Ctrl+Shift+Esc
)。 - 异常进程:任务管理器中出现名称可疑的进程(如随机字符命名、伪装成系统进程如
svchost.exe
但路径非系统目录C:\Windows\System32
),或结束后反复重启。
- 电脑突然变得异常卡顿,打开程序、文件或网页明显延迟,即使无复杂操作,CPU 或内存使用率长期居高不下(任务管理器中查看
-
-
- 右键进程→“打开文件所在位置”,检查文件路径是否为陌生目录(如用户文档、临时文件夹)。
-
- 异常耗电或发热
-
- 笔记本电脑在待机或轻负载时电量消耗异常快,或风扇持续高速运转(可能后台有恶意程序持续运行)。
二、网络连接异常:木马 “外联” 特征
- 不明网络流量
-
- 任务管理器→“性能”→“打开资源监视器”,查看 “网络” 标签,发现无操作时仍有持续的上传 / 下载流量,或连接到陌生 IP 地址、域名(如境外服务器、可疑端口如 4444、8080)。
- 命令行工具检测:
-
-
netstat -ano
:列出所有网络连接,重点关注状态为ESTABLISHED
的外部连接,对照 IP 地址(可通过 IPIP.NET 等查询归属地)。tasklist /svc
:关联进程 ID(PID)与进程名称,定位异常连接对应的程序。
-
- 防火墙或安全软件被禁用
-
- Windows 防火墙突然显示 “未启用”,或第三方杀毒软件无法打开、频繁报错,甚至弹出虚假安全提示(如 “检测到病毒,点击清除” 的钓鱼窗口)。
三、系统设置与文件异常:被恶意篡改
- 启动项或注册表异常
-
- 启动项新增不明程序:
-
-
- 按
Win+R
→输入msconfig
→“启动” 标签,查看是否有非自身安装的程序随系统启动(如 “UpdateManager”“SecurityCenter” 等伪装名称)。 - 或通过任务管理器→“启动” 标签管理。
- 按
-
-
- 注册表被修改:
-
-
- 注册表编辑器(
regedit
)中,检查HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
或HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
下是否有可疑路径(如指向用户目录的 EXE 文件)。
- 注册表编辑器(
-
- 文件或系统功能异常
-
- 出现不明文件或文件夹(如随机命名的
.exe
、.dll
,或隐藏的加密文件)。 - 系统功能失效:如无法打开任务管理器、控制面板、注册表编辑器(被木马禁用),或文件被加密(勒索病毒常见表现)。
- 浏览器异常:主页被篡改、新增恶意插件、频繁弹出广告或跳转至钓鱼网站(可能是浏览器劫持木马)。
- 出现不明文件或文件夹(如随机命名的
四、用户操作异常:权限被窃取或控制
- 账号与数据泄露迹象
-
- 账号密码突然失效(如邮箱、社交平台提示 “密码错误”),或收到异地登录提醒(如微信、支付宝的登录通知)。
- 敏感文件(如文档、照片)被删除、加密,或自动向外部发送(如通过邮件、即时通讯工具)。
- 鼠标 / 键盘被控制
-
- 鼠标指针自动移动、点击,或键盘输入无响应(木马可能在记录按键或远程操控)。
五、专业工具检测:深度扫描与分析
- 杀毒软件全盘扫描
-
- 使用主流杀毒软件(如卡巴斯基、诺顿、Windows Defender)进行全盘扫描(建议在安全模式下扫描,避免木马进程干扰)。
- 若检测到 “Trojan”“Backdoor”“Spyware” 等类型威胁,即为木马。
- 系统文件校验
-
- 对比系统文件哈希值(如使用
CertUtil -hashfile 文件名 MD5
),与微软官方公布的哈希值不一致,可能被篡改。 - 工具辅助:如
Sysinternals
套件中的Process Explorer
(查看进程详细信息)、Autoruns
(管理启动项)。
- 对比系统文件哈希值(如使用
- 日志与监控
-
- 事件查看器:
Win+R
→输入eventvwr.msc
,查看 “系统”“安全” 日志中的异常事件(如账户登录失败、服务异常终止)。 - 网络监控工具:Wireshark 抓取网络包,分析是否有异常的数据传输(如大量加密流量、频繁访问恶意域名)。
- 事件查看器:
六、紧急处理步骤(怀疑中马时)
- 断网隔离:立即断开有线 / 无线网络(防止木马外传数据或接收新指令)。
- 强制结束可疑进程:在任务管理器中结束异常进程(右键→结束任务,若无法结束,尝试安全模式)。
- 全盘扫描与清除:使用杀毒软件彻底查杀,必要时使用离线杀毒工具(如 U 盘启动盘)。
- 修复系统设置:重置浏览器主页、删除异常启动项、恢复被禁用的系统功能(如通过组策略
gpedit.msc
修复)。 - 数据备份与恢复:若文件被加密,在清除木马后,通过未感染的备份恢复数据(切勿向黑客支付赎金)。
日常预防:降低中马风险
- 安装安全软件:开启实时监控,定期更新病毒库。
- 及时补丁更新:系统、软件(如浏览器、Office)的漏洞可能被木马利用(
Win+I
→“更新和安全”)。 - 警惕可疑文件:不点击邮件附件、即时消息中的不明链接,不下载盗版软件(可能捆绑木马)。
- 权限最小化:使用普通账户而非管理员账户登录,限制木马获取系统权限。
总结:多维度综合判断
木马感染通常伴随 “资源异常占用”“网络外联”“系统篡改”“数据异常” 等迹象,需结合任务管理器、网络工具、杀毒软件等多手段检测。若普通用户难以判断,可截图异常进程、网络连接等信息,咨询专业安全人员或使用在线病毒分析平台(如 VirusTotal)扫描可疑文件。预防始终优于清除,保持良好的安全习惯是关键。
简写:
计算机系统运行速度减慢。
计算机系统经常无故发生死机。
计算机系统中的文件长度发生变化
计算机存储的容量异常减少。
系统引导速度减慢。
丢失文件或文件损坏。
计算机屏幕上出现异常显示。
计算机系统的蜂鸣器出现异常声响,
磁盘卷标发生变化。
系统不识别硬盘。
对存储系统异常访问。
键盘输入异常。
文件的日期、时间、属性等发生变化。
文件无法正确读取、复制或打开。
命令执行出现错误。
虚假报警。
换当前盘。有些病毒会将当前盘切换到C盘。
时钟倒转。有些病毒会命名系统时间倒转,逆向计时。
Windows 操作系统无故频繁出现错误。
系统异常重新启动。
一些外部设备工作异常。
异常要求用户输入密码。
Word 或 Excel 提示执行“宏”
18.木马的传播途径主要有哪些
网络途径
1. 恶意网站
- 钓鱼网站:攻击者会创建与正规网站极为相似的钓鱼网站,当用户在这些网站输入账号、密码等敏感信息时,信息就会被窃取。例如,仿冒银行官网,诱导用户登录并输入银行卡信息。
- 恶意脚本注入:一些不良网站会在网页中嵌入恶意脚本,当用户访问这些页面时,脚本会自动在用户的浏览器中执行,从而下载并安装木马。比如,利用浏览器的漏洞,在网页中插入恶意的 JavaScript 代码。
- 包含恶意链接的网页:攻击者会在网页上放置伪装成正常内容的恶意链接,用户一旦点击,就可能下载并运行木马程序。例如,在一些论坛或博客中发布看似吸引人的文章链接,实际指向的是恶意软件下载地址。
2. 电子邮件
- 恶意附件:攻击者会发送带有恶意附件的邮件,这些附件可能是伪装成文档、图片或压缩包的木马程序。当用户打开附件时,木马就会在系统中安装并运行。例如,邮件主题显示为 “重要合同”,附件却是一个带有木马的可执行文件。
- 邮件中的恶意链接:邮件中可能包含指向恶意网站的链接,用户点击链接后,会被引导到恶意网站,进而下载并安装木马。比如,邮件声称是某知名电商的促销活动链接,但实际指向的是恶意站点。
3. 即时通讯工具
- 文件共享:在即时通讯软件中,不法分子可能会发送伪装成正常文件的木马程序,诱导用户接收并打开。例如,在 QQ、微信等软件中发送名为 “精彩视频” 的文件,实际是木马。
- 链接分享:通过即时通讯工具发送恶意链接,诱使用户点击,从而实现木马传播。比如,在聊天中发送看似有趣的新闻链接,实则为恶意网站。
4. 对等网络(P2P)
- 文件下载:在 P2P 网络中,用户可以共享和下载文件。攻击者会上传包含木马的文件,当其他用户下载这些文件时,就会感染木马。例如,在一些 P2P 下载平台上,某些热门电影或软件的下载文件可能被植入了木马。
存储介质途径
1. 移动存储设备
- U 盘和移动硬盘:当 U 盘或移动硬盘感染了木马,再插入其他计算机时,木马就会自动在新的计算机上运行并传播。例如,在公共场合使用他人的 U 盘,或者将自己的 U 盘插入不安全的计算机,都可能导致 U 盘感染木马并传播。
- 光盘:虽然现在光盘使用相对较少,但某些盗版光盘或恶意制作的光盘中可能包含木马程序,用户在使用这些光盘时会感染木马。
软件途径
1. 软件下载
- 盗版软件:一些盗版软件的下载源可能被攻击者植入了木马。用户在下载和安装这些盗版软件时,木马会随之安装到系统中。例如,在非正规网站下载破解版的办公软件,可能会同时下载到木马。
- 免费软件:部分免费软件为了获取经济利益,会捆绑一些恶意软件或木马。用户在安装这些免费软件时,如果没有仔细查看安装选项,就可能在不知不觉中安装了木马。比如,一些看似免费的小游戏软件,可能会捆绑广告软件或木马。
2. 系统漏洞利用
- 攻击者会利用操作系统或应用程序的漏洞,将木马植入到用户的计算机中。例如,微软 Windows 系统曾出现过的 “永恒之蓝” 漏洞,攻击者利用该漏洞可以在未授权的情况下远程执行代码,从而安装木马。
社交途径
1. 社交工程攻击
- 攻击者通过欺骗、诱导等手段,获取用户的信任,然后让用户执行一些操作,从而传播木马。例如,攻击者伪装成技术支持人员,联系用户并指导用户下载和运行某个 “修复程序”,实际上这个程序就是木马。
了解木马的传播途径有助于用户采取相应的防范措施,如不随意点击不明链接、不下载和安装来源不明的软件、定期更新系统和软件补丁等,从而降低感染木马的风险。
简写:
木马主要是依靠邮件、下载等途径进行传播。木马也可以通过各种脚本进行传播:比如,浏览器在执行脚本时存在一些漏洞入侵者可以利用这些漏洞进行木马的传播与种植。当目标主机执行了木马的服务端程序之后,入侵者便可以通过客户端程序与目标主机上的服务端建立连接,进而控制目标主机。
对于通信协议的选择,绝大多数木马使用的是 TCP/IP协议,但也有使用UDP协议的木马。所以,做好木马的检测工作可以及时的发现以及处理木马,降低木马所带来的损失
19.恶意软件的定义
恶意软件(Malware,Malicious Software 的缩写)是指通过未经授权的方式侵入计算机系统、移动设备或网络,旨在实施破坏、窃取信息、滥用资源或进行其他恶意活动的软件程序或代码。其核心特征是未经用户同意且具有明确的恶意目的,通常会对用户的设备、数据或隐私造成损害。
恶意软件的核心要素
- 非授权性:
恶意软件的安装、运行或传播均未经用户明确同意,可能通过欺骗、漏洞利用、捆绑安装等方式潜入系统。 - 恶意目的:
其设计目标包括但不限于:
-
- 窃取信息(如账号密码、银行卡信息、隐私数据);
- 破坏系统(删除文件、格式化硬盘、干扰正常功能);
- 滥用资源(占用算力挖矿、作为僵尸网络节点发动攻击);
- 实施欺诈(如钓鱼、勒索、广告欺诈);
- 监控或控制设备(远程操控摄像头、麦克风,或窃取屏幕内容)。
- 多样化形态:
恶意软件根据功能和行为可分为多种类型,例如:
-
- 病毒(Virus):需依附宿主程序(如文档、可执行文件)传播,自我复制并破坏文件。
- 木马(Trojan):伪装成合法软件,潜伏在系统中窃取信息或远程控制设备。
- 间谍软件(Spyware):监控用户操作、收集数据并发送给攻击者。
- 勒索软件(Ransomware):加密用户文件或系统,以解密为条件勒索赎金。
- 蠕虫(Worm):无需宿主,通过网络漏洞自主传播,消耗系统资源。
- 广告软件(Adware):强制显示广告,可能捆绑其他恶意功能。
- rootkit:隐藏自身及恶意行为,获取系统底层权限。
恶意软件的传播与危害
- 传播途径:
通过网络(如恶意链接、钓鱼邮件、感染性下载)、存储介质(U 盘、移动硬盘)、软件漏洞、社交工程(欺骗用户执行恶意程序)等方式扩散。 - 危害后果:
小到设备卡顿、广告骚扰,大到数据泄露、系统瘫痪、经济损失(如勒索赎金),甚至威胁国家安全(如关键基础设施被攻击)。
总结
恶意软件是网络安全的主要威胁之一,其本质是利用技术手段实现非法目的的软件工具。防范恶意软件需依赖用户安全意识(如不点击不明链接、不安装盗版软件)、系统防护(如杀毒软件、防火墙)和及时更新补丁等多重措施。
简写:
恶意软件-Malicious Software,malware:把未经授权便干扰或破坏计算机系统/网络功能的程序或代码(一组指令)称之为恶意程序。
一组指令:可能是二进制文件,也可能是脚本语言/宏语言等。
20.什么是网页挂马
网页挂马是一种常见的恶意攻击手段,指攻击者通过在合法或恶意网页中植入恶意代码(通常是脚本或链接),当用户访问该网页时,无需主动下载或点击,恶意代码会利用用户浏览器、插件(如 Flash、Java)或操作系统的漏洞,自动在后台下载并执行木马程序,从而感染用户设备。其核心特点是利用网页作为传播载体,实现木马的被动式传播。
网页挂马的技术原理与手段
- 漏洞利用:
-
- 攻击者通过分析用户浏览器、插件或系统的已知漏洞(如 CVE 漏洞),在网页中嵌入针对这些漏洞的攻击代码。例如,利用浏览器的内存溢出漏洞,执行恶意代码下载木马。
- 典型工具:漏洞利用工具包(Exploit Kit),如 Angler、Nuclear 等,可批量扫描并利用多种漏洞。
- 恶意脚本植入:
-
- 通过在网页中插入恶意 JavaScript、VBScript 或 HTML 代码,引导浏览器加载并执行木马文件。常见方式包括:
-
-
- iframe 隐藏嵌入:在网页中嵌入一个不可见的 iframe,指向包含木马下载链接的恶意页面。
- 钓鱼链接伪装:将恶意链接伪装成图片、按钮或正常内容,用户鼠标悬停或点击时触发下载。
- 重定向跳转:通过网页跳转逻辑,将用户从合法页面重定向到恶意下载页面。
-
- 伪装与传播:
-
- 攻击者常选择流量较高的网站(如盗版资源站、论坛、小型博客)挂马,或通过入侵合法网站植入恶意代码(如篡改首页、注入广告位),利用网站的可信度降低用户警惕性。
网页挂马的核心特点
- 无感知感染:用户无需主动操作(如点击下载),访问网页即可能触发攻击,隐蔽性强。
- 跨平台传播:可针对 Windows、macOS、移动设备等不同系统的浏览器漏洞进行攻击。
- 快速扩散:借助高流量网站或热门内容,短时间内感染大量用户。
网页挂马的危害
- 设备感染:下载并安装木马、勒索软件、间谍软件等,导致数据窃取(如账号密码、支付信息)、设备被远程控制(如摄像头、麦克风被窃用)。
- 网络安全威胁:感染设备可能被纳入僵尸网络(Botnet),用于发起 DDoS 攻击、垃圾邮件发送等。
- 网站信誉受损:被挂马的合法网站可能被搜索引擎标记为危险站点,影响用户信任。
防范网页挂马的措施
- 及时修复系统漏洞:定期更新操作系统、浏览器及插件(如 Flash、Java),关闭不再使用的插件。
- 安装安全工具:使用带有网页防护功能的杀毒软件(如卡巴斯基、火绒)、浏览器安全插件(如 NoScript、uBlock Origin),开启浏览器的自动更新和漏洞防护功能(如 Chrome 的安全沙箱)。
- 谨慎访问网站:避免访问盗版资源站、色情网站等风险较高的页面,对陌生网站的安全性保持警惕。
- 增强浏览器设置:禁用或限制运行 ActiveX、Java 等易被利用的插件,开启浏览器的 “安全浏览” 模式(如 Google 安全浏览)。
- 监控网站安全:网站管理员需定期扫描网页代码,部署 Web 应用防火墙(WAF),防止被植入恶意代码。
总结
网页挂马是一种 “以网为饵” 的攻击方式,利用用户对网页的信任和系统漏洞实现木马传播,兼具隐蔽性和破坏性。用户需结合技术防护(更新补丁、安全工具)和安全意识(谨慎访问、警惕风险),才能有效抵御此类攻击。
简写:
网页挂马就是攻击者通过在正常的页面中(通常是网站的主页)插入一段代码。浏览者在打开该页面的时候,这段代码被执行,然后下载并运行某木马的服务器端程序,进而控制浏览者的主机。
挂网马的目的,让访问该网页的主机下载某木马的服务器端程序,进而控制浏览者的主机。
21.网页挂马都有什么类型
一、按攻击技术与漏洞利用方式分类
1. 漏洞利用型挂马
- 技术原理:利用浏览器、插件(如 Flash、Java、PDF 阅读器)或操作系统的已知漏洞(如 CVE 漏洞),通过网页代码触发漏洞执行恶意程序。
- 典型手段:
-
- 使用漏洞利用工具包(Exploit Kit)(如 Angler、Magnitude),集成多种漏洞攻击代码,自动扫描用户环境并选择可利用的漏洞。
- 针对浏览器内存溢出、类型混淆等底层漏洞,直接在网页中嵌入 shellcode(汇编级恶意代码),下载并运行木马。
- 特点:无需用户交互(如点击),访问即感染;依赖未修复的系统漏洞,攻击成功率高。
- 示例:利用 IE 浏览器的 VBScript 引擎漏洞,通过恶意网页直接下载勒索软件。
2. 脚本注入型挂马
- 技术原理:通过植入恶意脚本(如 JavaScript、VBScript),引导浏览器加载或执行恶意文件。
- 细分类型:
-
- iframe 隐藏嵌入:在网页中插入不可见的 iframe,指向恶意下载页面(如
http://恶意域名/木马.exe
),利用浏览器自动加载机制触发下载。 - 重定向跳转:通过
window.location.href
或 302 跳转,将用户从合法页面转向恶意站点(如 “虚假视频播放页” 诱导下载)。 - 钓鱼脚本伪装:将恶意链接伪装成图片、按钮或文本(如 “点击查看原图”“下载高清资源”),用户点击后触发下载。
- iframe 隐藏嵌入:在网页中插入不可见的 iframe,指向恶意下载页面(如
- 特点:部分需要用户交互(如点击),但脚本可隐藏在正常内容中,隐蔽性较强。
3. 跨站脚本(XSS)挂马
- 技术原理:利用 Web 应用的 XSS 漏洞,在页面中注入恶意脚本(如
<script>下载木马</script>
),当用户访问时,脚本在其浏览器中执行。 - 攻击场景:
-
- 攻击者在论坛、留言板等用户可输入内容的区域,植入含木马下载链接的 XSS 代码。
- 脚本可窃取用户 Cookie(会话劫持),或直接下载并运行木马程序。
- 特点:依赖 Web 应用的 XSS 漏洞,攻击目标为网站的访客,传播范围广。
二、按传播载体与目标场景分类
4. 合法网站入侵挂马
- 技术原理:攻击者通过入侵合法网站(如篡改后台、上传恶意文件),在其页面中植入挂马代码(如首页、热门文章页),利用网站流量感染用户。
- 常见目标:
-
- 中小型企业网站(安全性较弱)、教育机构网站、政府网站(利用可信度降低警惕)。
- 盗版资源站、影视网站(用户基数大,易传播)。
- 特点:用户信任度高,感染率高;网站管理员难以及时发现恶意代码(如通过隐藏文件、加密脚本)。
5. 水坑攻击挂马
- 技术原理:针对特定目标群体(如企业员工、政府人员),入侵其常访问的网站并植入挂马代码,等待目标访问时感染。
- 攻击流程:
-
- 分析目标群体的上网习惯,确定高频访问的网站(如行业论坛、内部系统)。
- 入侵这些网站并植入定制化挂马代码(可能结合目标系统的漏洞)。
- 特点:针对性强,攻击目标明确;常结合社会工程学,降低目标警惕性。
6. 广告注入挂马
- 技术原理:通过劫持广告投放系统(如恶意广告网络、破解广告联盟),在正常广告位中插入恶意广告链接,用户点击广告时触发挂马。
- 典型形式:
-
- 恶意广告(Malvertising):表面是正常广告(如促销、热点新闻),实际链接到挂马页面。
- 层叠广告(Overlay Ads):覆盖在网页内容上的透明广告,用户误触即跳转。
- 特点:利用用户对广告的习惯性交互,传播范围广;可绕过部分安全工具的检测(因广告来自合法平台)。
三、按攻击目标与恶意行为分类
7. 下载器型挂马
- 核心目的:通过网页诱导或强制下载 “下载器” 程序,该程序再从远程服务器下载并执行真正的木马(如窃密木马、勒索软件)。
- 技术手段:
-
- 伪装成 “播放器更新”“文件解码器” 等必要程序,诱导用户主动下载。
- 通过漏洞直接后台下载小型下载器(如几 KB 的脚本),再由下载器拉取完整木马。
- 特点:分工明确,降低被安全软件拦截的概率;常与社会工程学结合(如 “文件损坏,需下载修复工具”)。
8. 挖矿脚本挂马
- 核心目的:利用用户浏览器算力,在后台运行加密货币挖矿脚本(如 Monero 挖矿),窃取计算资源。
- 技术实现:
-
- 在网页中嵌入 JavaScript 挖矿代码(如 CoinHive、JSECoin),用户访问时自动运行。
- 部分结合漏洞利用,突破浏览器限制(如突破 CPU 占用阈值),提升挖矿效率。
- 特点:无文件落地(纯内存运行),隐蔽性强;可能导致设备发热、耗电增加、性能下降。
9. 移动端挂马(针对手机 / 平板)
- 攻击对象:移动设备浏览器(如 Chrome Mobile、Safari)或 APP 内浏览器(如微信内置浏览器)。
- 技术特点:
-
- 利用移动系统漏洞(如 Android 的 WebView 漏洞、iOS 的 Safari 内核漏洞)。
- 伪装成 “手机清理工具”“热门游戏下载” 等,诱导用户点击后下载恶意 APK 或安装描述文件(iOS)。
- 典型危害:窃取短信验证码(用于盗号)、静默安装恶意 APP、监听通话等。
四、按挂马代码的隐蔽性分类
10. 显性挂马
- 特征:需要用户主动点击或交互(如下载按钮、弹窗提示),恶意行为较明显(如弹出 “病毒扫描” 虚假窗口)。
- 示例:虚假 Flash 更新提示、伪造的 “系统错误” 弹窗,引导用户下载木马。
11. 隐性挂马
- 特征:完全在后台静默运行,无需用户交互(如通过漏洞自动下载),用户难以察觉。
- 示例:通过 iframe 隐藏加载恶意链接、利用浏览器自动执行的脚本(如 VBScript)直接下载文件。
总结:网页挂马的核心分类逻辑
网页挂马的类型可从技术(漏洞利用 / 脚本注入)、载体(合法网站 / 广告 / 移动端)、目标(通用 / 定向)、行为(下载木马 / 挖矿 / 窃密)等维度划分,其本质是通过网页作为 “桥梁”,将用户导向恶意代码执行。防范时需针对不同类型的特点,结合漏洞修复、浏览器安全设置、可疑内容识别等多重手段,降低感染风险。
22.为什么电子邮件病毒会有危险
一、高效的传播能力与广泛的覆盖性
- 低成本大规模扩散
-
- 病毒可通过邮件客户端的联系人列表、地址簿或自动生成的虚假邮箱列表,以 “群发”“转发” 等形式快速传播,一次攻击即可触达成百上千用户(如 “ILOVEYOU” 病毒 24 小时内感染超 4000 万台设备)。
- 借助邮件服务器的开放性,攻击者可伪造发件人信息(如伪装成银行、政府机构、知名企业),利用用户对 “可信来源” 的信任降低警惕。
- 跨平台与跨设备渗透
-
- 无论用户使用 Windows、macOS、Android 还是 iOS 设备,主流邮件客户端(如 Outlook、Gmail、Foxmail)均可能成为攻击目标,覆盖范围几乎无死角。
- 移动设备的邮件 APP(如手机端 Outlook、系统自带邮箱)因用户常实时查看邮件,感染风险更高。
二、极强的伪装性与社会工程学利用
- 诱饵多样化,欺骗性强
-
- 附件伪装:病毒常藏于文档(.doc/.docx)、表格(.xls/.xlsx)、压缩包(.zip/.rar)、可执行文件(.exe)或脚本文件(.js/.vbs)中,文件名多为 “工资单”“订单详情”“发票.pdf” 等极具诱惑性或紧迫性的内容,诱导用户主动打开。
- 链接陷阱:邮件正文中的超链接可能指向钓鱼网站或挂马页面(如 “点击确认订单”“查看最新通知”),用户点击后跳转至恶意站点,触发下载或漏洞攻击。
- 利用用户心理弱点
-
- 紧急性与恐惧感:如 “账户即将冻结”“检测到异常登录”“系统升级通知”,迫使用户无暇验证真伪即采取行动。
- 利益诱惑:如 “中奖通知”“限时优惠”“免费资源下载”,利用贪婪心理诱导点击。
三、技术层面的漏洞利用与自动化攻击
- 无需用户交互的 “无接触感染”
-
- 早期病毒(如 “Melissa”)需用户主动打开附件,但现代病毒可利用邮件客户端或操作系统的漏洞(如 Outlook 的内存溢出漏洞、Exchange 服务器漏洞),在用户预览邮件时自动执行恶意代码(无需打开附件或点击链接)。
- 例如:通过 HTML 邮件中的恶意代码,加载远程脚本或下载器,直接在后台静默感染。
- 多层级攻击链与持续性威胁
-
- 第一阶段:邮件作为 “敲门砖”,投递携带下载器或漏洞利用工具的附件 / 链接,植入初始恶意程序(如 Agent Tesla 窃密木马)。
- 第二阶段:初始程序进一步窃取用户邮箱登录凭证、会话令牌,或利用邮件客户端权限,以用户名义发送更多病毒邮件,形成 “二次传播”。
- 第三阶段:部分病毒(如勒索病毒)在感染后,通过邮件系统向用户的联系人发送加密文件的勒索通知,扩大心理威慑。
四、严重的破坏性与后续影响
- 直接危害用户资产与数据
-
- 数据窃取:病毒可窃取邮件内容、附件中的敏感信息(如账号密码、财务数据、商业机密),或通过键盘记录、屏幕截图监控用户操作。
- 系统破坏:删除关键文件、格式化磁盘(如 “CIH” 病毒),或植入勒索软件(如 WannaCry)加密用户文件并索要赎金。
- 基础设施与网络安全威胁
-
- 企业级灾难:员工感染邮件病毒后,病毒可能横向渗透企业内网,攻击服务器(如域控制器、数据库),导致业务中断、数据丢失(如 2017 年 Petya 病毒通过企业邮件系统扩散,全球损失超 100 亿美元)。
- 僵尸网络(Botnet)构建:病毒可将用户设备纳入僵尸网络,用于发起 DDoS 攻击、发送垃圾邮件或进行挖矿,消耗设备资源并隐藏真实攻击源。
- 长期信任危机与经济损失
-
- 个人用户可能因邮件病毒导致账号被盗(如邮箱、社交媒体、金融账户),进而引发财产损失;企业则可能因邮件系统被滥用,面临法律风险(如垃圾邮件投诉)、品牌信誉下降。
五、防御难度与隐蔽性
- 绕过安全工具的能力
-
- 病毒附件可能经过加密(如密码保护的 ZIP 文件,提示 “解压密码在邮件正文”),或利用多态性技术(每次传播时改变代码特征),绕过传统杀毒软件的特征库检测。
- 部分病毒通过 “钓鱼邮件 + 网页挂马” 组合攻击,即使附件被邮件网关拦截,链接仍可能引导用户访问恶意站点,形成漏网攻击。
- 清除与恢复成本高
-
- 邮件病毒可能在感染后删除自身痕迹,或修改系统启动项实现持久化驻留,手动清除难度大。
- 勒索病毒加密的文件若没有备份,可能永久无法恢复,尤其对依赖历史数据的企业或个人而言,损失不可逆。
总结:电子邮件病毒危险的本质
电子邮件病毒的危险性源于其 **“社交属性” 与 “技术属性” 的结合 **:利用人类对邮件通信的信任和依赖,通过社会工程学降低防御心理,同时借助技术漏洞实现高效传播与深层破坏。其威胁不仅限于单一设备感染,更可能引发连锁反应(如企业网络瘫痪、数据泄露事件),成为网络安全中最持久且难以根治的风险之一。防范的关键在于提高用户安全意识(如警惕可疑附件和链接)、部署多层级邮件安全网关(过滤恶意内容),以及及时修复系统漏洞(阻断无接触感染路径)。
23.远程访问工具的风险是什么
一、技术层面的固有安全漏洞
- 远程协议自身缺陷
-
- RDP(远程桌面协议)漏洞:历史上多次出现高危漏洞(如 2019 年的 CVE-2019-0708 “永恒黑雨” 漏洞,可远程执行代码),攻击者利用未打补丁的 RDP 服务发起勒索软件攻击(如 WannaCry、NotPetya)。
- 第三方工具漏洞:部分工具存在版本更新不及时问题,例如 TeamViewer 旧版本可能被绕过认证机制,或通过漏洞实现会话劫持(2021 年某高校因 TeamViewer 漏洞导致服务器被植入挖矿程序)。
- 加密与认证机制薄弱
-
- 部分免费版远程工具采用弱加密算法(如 AES-128 而非 AES-256),或未强制启用多因素认证(MFA),攻击者可通过暴力破解密码、中间人攻击(MITM)窃取会话凭证,直接控制目标设备。
二、配置不当引发的暴露风险
- 公网直接暴露与弱密码
-
- 企业或个人将远程服务(如 RDP、VNC)直接暴露在互联网,未通过 VPN 中转或防火墙限制访问 IP,且使用 “123456”“admin” 等弱密码,成为攻击者的首要目标(2023 年某医院因 RDP 弱密码导致全院系统被勒索加密)。
- 部分工具默认开启 “无人值守访问” 功能(如 TeamViewer 的 “安全代码” 长期有效),若设备物理安全失控(如员工离职未注销权限),攻击者可长期潜伏。
- 权限过度开放
-
- 远程工具常赋予用户完全控制权限(如文件读写、系统设置修改),若管理员误将高权限账号泄露,或攻击者通过钓鱼获取权限,可直接窃取敏感数据(如企业财务文件、用户隐私信息)、植入后门或破坏系统。
三、被恶意利用的攻击载体
- 伪装成合法工具的恶意软件
-
- 攻击者通过钓鱼邮件、虚假下载页面传播伪造的远程工具(如 “TeamViewer 破解版”“免费 RDP 客户端”),实际为木马程序(如 AnyDesk 后门病毒),一旦安装即被远程控制,用于数据窃取、挖矿或作为跳板攻击内网。
- 合法工具被滥用
-
- 黑客入侵用户账号后,利用已授权的远程工具横向渗透:例如通过某员工的 TeamViewer 访问其办公电脑,再通过企业内网扫描其他设备,利用远程桌面协议扩散(2022 年某制造业企业因员工账号被盗,导致生产线控制系统被篡改)。
- 会话劫持与监控绕过
-
- 通过网络嗅探、键盘记录等手段获取远程会话凭证,或在用户未察觉时静默连接(如隐蔽的后台进程),实现对设备的长期监控(如窃取用户输入的银行账号、邮件内容)。
四、管理与使用中的疏忽风险
- 日志与审计缺失
-
- 企业未对远程访问行为进行日志记录(如连接时间、操作内容),攻击发生后难以追溯源头。例如,攻击者通过合法工具账号夜间窃取数据,因无操作日志导致长期未被发现。
- 多设备权限混乱
-
- 个人用户在多台设备(如家庭电脑、办公笔记本、手机)使用同一远程工具账号,若其中一台设备感染病毒,攻击者可通过账号关联访问所有设备,形成 “一损俱损” 的链式风险。
- 合规与隐私问题
-
- 部分行业(如医疗、金融)对远程访问有严格合规要求(如 GDPR、等保 2.0),若工具未通过安全认证或数据未加密传输,可能导致合规性违规(如患者病历通过未加密的远程会话泄露)。
五、典型安全事件与影响
- 勒索软件攻击:2021 年美国 Colonial Pipeline 因 RDP 弱密码被攻击,导致东海岸燃油供应中断,最终支付 440 万美元赎金。
- 数据泄露事件:2020 年某律师事务所因员工使用未加密的远程工具传输案件文件,导致客户机密信息被黑客窃取并公开。
- 设备滥用:2023 年某高校实验室服务器被植入挖矿程序,溯源发现攻击者通过破解 TeamViewer 密码,利用设备算力挖掘加密货币。
总结:远程访问工具的核心风险本质
远程访问工具的风险源于其 **“双向可控性” 与 “网络暴露性”:一方面,工具允许外部用户对目标设备进行操作,若权限或认证失控,等同于为攻击者打开 “后门”;另一方面,其依赖的网络传输和软件实现存在技术漏洞,易被针对性攻击。风险防控需结合最小权限原则 **(仅开放必要功能)、动态认证机制(如 MFA)、实时监控审计及定期漏洞修复,避免因工具便利性牺牲安全性。
24.ICMP协议类型简述
ICMP(Internet Control Message Protocol,互联网控制消息协议)是 TCP/IP 协议族的核心协议之一,属于网络层协议,主要用于在 IP 主机、路由器之间传递网络层的控制消息(如网络故障通知、网络状态查询等)。ICMP 消息通过 IP 数据报封装传输,其类型由报文中的类型(Type)字段和代码(Code)字段共同定义。以下是 ICMP 协议的主要类型及分类:
一、ICMP 消息的两大核心类别
ICMP 消息分为两大类:差错报告消息(用于反馈网络传输中的错误或异常)和查询消息(用于主动请求网络信息或诊断网络状态)。
二、差错报告消息(Type 值:3、4、11、12 等)
1. 目标不可达(Type=3)
当 IP 数据报无法到达目标主机或端口时发送,包含多种细分原因(通过 Code 字段区分):
- Code=0:网络不可达(目标网络不存在或路由不可达)。
- Code=1:主机不可达(目标主机不可达,如 IP 不存在或未开机)。
- Code=2:协议不可达(目标主机不支持数据报中的上层协议,如无效的 TCP/UDP 端口)。
- Code=3:端口不可达(目标端口未开放,如访问 Web 服务器的 8080 端口被防火墙阻断)。
- 其他 Code:如需要分片但 DF 标志位被设置(Code=4)、源路由失败(Code=5)等。
2. 源抑制(Type=4)
路由器或主机因拥塞无法处理数据报时,向发送方发送此消息,请求降低传输速率(现已较少使用,被 TCP 的流量控制机制替代)。
3. 超时(Type=11)
数据报在传输中因生存时间(TTL)耗尽而被丢弃时发送:
- Code=0:传输期间 TTL 超时(如路由器转发时 TTL 减为 0,Traceroute 利用此机制追踪路径)。
- Code=1:分片重组超时(接收方未在规定时间内完成分片重组)。
4. 参数问题(Type=12)
数据报头部字段存在错误或歧义时发送:
- Code=0:头部字段错误(如无效的 IP 选项)。
- Code=1:缺少所需选项(如需要记录路由但选项缺失)。
5. 重定向(Type=5)
路由器发现发送方存在更优路由时,向其发送重定向消息,告知下次应使用的下一跳地址(常用于局域网内的路由优化)。
三、查询消息(Type 值:0、8、13、14、17、18 等)
1. 回送请求与应答(Echo Request/Reply,Type=8/0)
- 回送请求(Type=8,Code=0):主动向目标主机发送测试数据包(如 Ping 命令),请求返回响应。
- 回送应答(Type=0,Code=0):目标主机收到回送请求后返回的响应,用于验证网络连通性。
2. 时间戳请求与应答(Timestamp Request/Reply,Type=13/14)
用于测量两台主机之间的时间同步和往返时间(RTT),现已较少使用,被 NTP 等协议替代。
3. 地址掩码请求与应答(Address Mask Request/Reply,Type=17/18)
主机请求获取所在网络的子网掩码(如无 DHCP 时手动获取),应答消息返回子网掩码信息。
4. 路由器 solicitation 与通告(Router Solicitation/Advertisement,Type=10/9)
- 主机主动发送路由器请求(Type=10),请求网络中的路由器发布自身信息。
- 路由器定期广播通告(Type=9),告知可用的路由信息(常用于无状态自动配置)。
四、ICMP 的典型应用场景
- 网络诊断工具:
-
- Ping:基于回送请求 / 应答(Type=8/0),检测主机是否可达及延迟。
- Traceroute(Linux)/Tracert(Windows):利用超时(Type=11)和目标不可达(Type=3)消息,追踪数据报经过的路由节点。
- 错误排查:通过目标不可达、超时等消息定位网络故障(如端口阻塞、路由环路)。
- 路径优化:重定向消息帮助主机选择更优的路由路径。
五、ICMP 的局限性与安全风险
- 非可靠传输:ICMP 消息本身通过 IP 数据报传输,可能丢失或被过滤,诊断结果需结合多次测试。
- 易被滥用:攻击者可能利用 ICMP 发起拒绝服务攻击(如 Ping Flood)、伪造错误消息误导网络配置,或通过禁用 ICMP 规避检测。
- 防火墙策略:企业通常会限制 ICMP 流量(仅允许必要的 Ping 和 Traceroute),以减少攻击面。
总结
ICMP 协议是网络层的 “诊断和反馈系统”,通过差错报告和查询消息实现对网络状态的监控与调试。理解其类型和作用,有助于快速定位网络问题(如连通性故障、路由异常),但也需注意其在安全场景中的潜在风险(如被利用发起攻击)。
25.防火墙的类别及其原理
防火墙是网络安全的核心设备,用于监控和控制网络流量,阻止未经授权的访问。根据技术原理和工作层次,防火墙主要分为以下几类,其核心原理及特点如下:
一、按技术原理分类(核心分类)
1. 包过滤防火墙(Packet Filtering Firewall)
- 工作层次:网络层(OSI 第 3 层)和传输层(第 4 层)。
- 核心原理:
-
- 基于数据包的头部信息(IP 地址、端口号、协议类型(TCP/UDP/ICMP 等))制定规则,对每个独立数据包进行检查,决定是否允许通过。
- 规则通常为 “允许 / 拒绝” 列表,例如:允许源 IP 为 192.168.1.0/24 的设备访问目标端口 80(HTTP)。
- 优点:
-
- 处理速度快(仅检查头部,无需解析应用层内容),资源消耗低。
- 支持大规模网络流量过滤。
- 缺点:
-
- 无法识别应用层协议(如无法区分 HTTP 流量中的合法网页访问和恶意文件下载)。
- 不跟踪连接状态(如允许外部主机主动连接内部端口,即使是未发起的请求)。
- 典型应用:早期路由器内置防火墙、简单网络边界防护。
2. 状态检测防火墙(Stateful Inspection Firewall,动态包过滤)
- 工作层次:网络层、传输层,部分支持应用层(浅度解析)。
- 核心原理:
-
- 维护一个连接状态表(Session Table),跟踪每个网络连接的状态(如 TCP 的三次握手状态、UDP 的临时连接)。
- 仅允许与已建立连接相关的数据包通过(如允许响应包返回,即使目标端口未显式开放)。
- 例如:当内部主机主动访问外部 Web 服务器(发起 TCP SYN 包),防火墙记录该连接状态,允许后续返回的 SYN-ACK 和 ACK 包通过。
- 优点:
-
- 比包过滤更安全(动态允许合法响应流量,阻止未经请求的外部连接)。
- 性能优于应用代理防火墙,支持复杂网络协议(如 FTP 被动模式的动态端口)。
- 缺点:
-
- 对应用层内容解析有限,无法检测加密流量或深层攻击(如恶意 URL、病毒文件)。
- 典型应用:企业级边界防火墙(如 Cisco ASA、华为 USG)。
3. 应用代理防火墙(Application Proxy Firewall,应用层网关)
- 工作层次:应用层(OSI 第 7 层)。
- 核心原理:
-
- 充当内外网的 “中间人”,完全代理应用层连接(如 HTTP、FTP、SMTP)。
- 客户端先连接到防火墙的代理服务,代理服务器再以自己的身份连接目标服务器,反之亦然。
- 深度解析应用层协议内容(如检查 HTTP 请求中的 URL、表单数据,FTP 传输的文件内容),并根据规则过滤。
- 优点:
-
- 提供细粒度的应用层控制(如禁止上传.exe 文件、阻止特定 URL 访问)。
- 隐藏内部网络结构(外部仅可见代理服务器 IP)。
- 缺点:
-
- 性能开销大(每个连接需两次代理,处理速度较慢)。
- 需为每个应用协议单独开发代理模块(如仅支持预定义的 HTTP、FTP 等,无法处理未知协议)。
- 典型应用:企业内部敏感系统防护、传统 Web 代理服务器(如 Squid)。
4. 下一代防火墙(Next-Generation Firewall, NGFW)
- 工作层次:融合网络层、传输层、应用层,支持深度包检测(DPI, Deep Packet Inspection)。
- 核心原理:
-
- 整合状态检测、应用层过滤、入侵检测 / 预防(IDS/IPS)、病毒扫描、URL 过滤等功能。
- 通过 DPI 技术解析应用层协议(如识别微信、P2P 软件、加密的 HTTPS 流量),甚至检测流量中的恶意载荷(如恶意 JavaScript、勒索软件特征)。
- 支持基于用户身份、设备类型、时间策略的细粒度控制(如允许员工在工作时间访问企业邮箱,禁止访问视频网站)。
- 优点:
-
- 全面应对复杂威胁(如应用层攻击、高级恶意软件)。
- 适应多云环境和移动办公场景(支持 SSL VPN、云安全联动)。
- 缺点:
-
- 配置复杂,对硬件性能要求高(需处理大量 DPI 和联动功能)。
- 典型应用:大型企业、数据中心边界防护(如 Palo Alto Networks、Fortinet FortiGate)。
5. Web 应用防火墙(Web Application Firewall, WAF)
- 工作层次:应用层(聚焦 HTTP/HTTPS 协议)。
- 核心原理:
-
- 专门针对 Web 应用攻击(如 SQL 注入、跨站脚本攻击(XSS)、文件包含漏洞等),部署在 Web 服务器前端。
- 通过规则匹配或行为分析,检查 HTTP 请求 / 响应的内容(如 URL 参数、请求头、表单数据)。
- 支持正则表达式匹配(如检测 SQL 注入特征 “SELECT * FROM”)、异常流量检测(如高频访问同一 URL 的爬虫行为)。
- 优点:
-
- 精准防护 Web 应用层漏洞,弥补传统防火墙在 HTTP 细节处理上的不足。
- 支持自定义规则,适应多样化的 Web 攻击场景。
- 缺点:
-
- 仅保护 Web 应用,无法处理其他协议(如 FTP、SMTP)。
- 典型应用:互联网企业 Web 服务防护(如阿里云 WAF、ModSecurity 开源 WAF)。
二、其他分类方式
1. 按部署形态分类
- 硬件防火墙:独立硬件设备(如机架式防火墙),性能强,适合企业级场景。
- 软件防火墙:安装在主机或服务器上的软件(如 Windows 防火墙、Linux iptables),用于个人或主机级防护。
- 云防火墙:基于云计算的防火墙服务(如 AWS WAF、阿里云防火墙),支持弹性扩展和多云环境。
2. 按结构分类
- 主机防火墙(个人防火墙):部署在单个主机上,保护本地系统(如 Windows Defender 防火墙)。
- 网络防火墙:部署在网络边界(如企业出口、数据中心入口),保护整个网络。
3. 按特殊功能分类
- NAT 防火墙:结合网络地址转换(NAT),隐藏内部 IP 地址,实现端口映射(如家用路由器的 NAT 功能)。
- 负载均衡防火墙:在过滤流量的同时实现负载均衡,提升高并发场景下的性能。
三、核心技术对比
类型 | 工作层次 | 检测深度 | 性能 | 应用场景 |
包过滤防火墙 | 网络层 / 传输层 | 仅头部信息 | 高 | 简单流量过滤 |
状态检测防火墙 | 网络层 / 传输层 | 连接状态 | 中高 | 企业边界基础防护 |
应用代理防火墙 | 应用层 | 协议内容 | 低 | 敏感应用代理 |
下一代防火墙 | 全层次 | 深度包检测 | 中 | 复杂威胁防护 |
Web 应用防火墙 | 应用层(HTTP) | Web 内容细节 | 中 | Web 服务专属防护 |
四、总结
防火墙通过分层过滤和协议解析实现安全控制:
- 网络层 / 传输层:快速过滤非法 IP、端口或无状态连接(包过滤、状态检测)。
- 应用层:深度解析协议内容,阻止针对特定应用的攻击(代理防火墙、NGFW、WAF)。
选择防火墙时需根据场景需求平衡安全性和性能:企业边界适合 NGFW,Web 服务需部署 WAF,个人主机可用软件防火墙。随着攻击技术复杂化,防火墙正从单一功能向集成化、智能化(如 AI 驱动威胁检测)发展。
26.HTTP响应状态简述
HTTP 响应状态码(HTTP Status Code)是服务器向客户端返回的三位数代码,用于表示请求的处理结果。根据状态码的首位数字,可分为 5 大类,每类代表不同的响应性质。以下是核心分类及常见状态码的简述:
一、状态码分类(首位数字定义类别)
类别 | 分类 | 含义 |
1xx | 信息性状态码 | 服务器已收到请求,正在处理,客户端需继续操作(如等待进一步响应)。 |
2xx | 成功状态码 | 请求已成功处理,客户端获得预期结果。 |
3xx | 重定向状态码 | 请求需进一步操作以完成,通常涉及资源位置变更(需客户端重新发起请求)。 |
4xx | 客户端错误码 | 客户端请求存在错误,服务器无法处理(如无效语法、权限不足)。 |
5xx | 服务器错误码 | 服务器内部处理请求时发生错误,与客户端无关(需服务器端排查问题)。 |
二、详细分类及常见状态码
1. 1xx 信息性状态码(Informational)
- 100 Continue:客户端请求的初始部分已接收,服务器同意继续处理(常用于分块传输或大文件上传)。
- 101 Switching Protocols:服务器接受客户端切换协议的请求(如从 HTTP 切换到 WebSocket)。
- 103 Early Hints(HTTP/2+):服务器提前返回资源提示(如 HTML 头部的 Link 预加载),优化加载性能。
2. 2xx 成功状态码(Successful)
- 200 OK:请求成功,返回目标资源(最常见的成功响应)。
- 201 Created:请求成功且创建了新资源(如 POST 创建用户时返回)。
- 204 No Content:请求成功但无返回内容(常用于删除操作或无需返回数据的 API)。
- 206 Partial Content:客户端请求部分资源(如 Range 头指定字节范围),服务器返回对应片段(支持断点续传)。
3. 3xx 重定向状态码(Redirection)
- 301 Moved Permanently:资源永久移动,后续请求应使用新 URL(搜索引擎会更新链接)。
- 302 Found(或 307 Temporary Redirect):资源临时移动,客户端需使用原 URL 重新请求(避免缓存旧链接)。
- 303 See Other:请求的响应是另一个 URL,需客户端用 GET 方法访问新 URL(常用于表单提交后跳转)。
- 304 Not Modified:客户端缓存的资源未修改,无需重新下载(服务器返回此状态码以减少流量)。
4. 4xx 客户端错误码(Client Error)
- 400 Bad Request:客户端请求语法错误(如错误的 URL 参数、无效 JSON 格式)。
- 401 Unauthorized:请求需身份验证(未提供或凭证无效,常伴随
WWW-Authenticate
头)。 - 403 Forbidden:服务器拒绝请求(即使身份验证通过,也无访问权限,如权限不足、IP 被封禁)。
- 404 Not Found:请求的资源不存在(URL 错误或资源已被删除)。
- 405 Method Not Allowed:请求方法(如 GET/POST)不被目标资源支持(如 API 仅允许 POST 但收到 GET)。
- 429 Too Many Requests:客户端请求频率过高,触发速率限制(服务器返回重试时间
Retry-After
头)。
5. 5xx 服务器错误码(Server Error)
- 500 Internal Server Error:服务器内部错误(最通用的服务器端故障,需管理员排查日志)。
- 502 Bad Gateway:服务器作为网关 / 代理时,从上游服务器收到无效响应(如后端服务崩溃)。
- 503 Service Unavailable:服务器暂时无法处理请求(可能因过载或维护,常伴随
Retry-After
头)。 - 504 Gateway Timeout:网关 / 代理等待上游服务器响应超时(后端服务处理过慢或连接中断)。
三、特殊状态码(非标准但常见)
- 418 I'm a Teapot(RFC 2324):玩笑状态码,模拟茶壶拒绝泡茶(常用于测试或彩蛋)。
- 451 Unavailable For Legal Reasons(RFC 7725):因法律原因无法提供资源(如内容被屏蔽)。
四、状态码的作用
- 客户端处理:根据状态码调整行为(如重定向时自动跳转,401 时提示登录)。
- 调试与监控:通过状态码统计错误类型(如 4xx 高频可能是客户端问题,5xx 需服务器优化)。
- SEO 影响:301 永久重定向利于搜索引擎更新链接,404 需合理处理以避免影响网站排名。
总结
HTTP 状态码是客户端与服务器沟通的 “语言”,通过首位数字快速定位问题类别(客户端错、服务器错、重定向等),后两位提供具体原因。掌握常见状态码(如 200、301、404、500)可高效排查 Web 应用问题,优化用户体验和系统稳定性。
27.cookie和session的区别
Cookie 和 Session 是 Web 开发中用于跟踪用户会话的两种常用技术,二者在存储位置、机制、安全性等方面有显著区别,以下是具体对比:
一、核心区别对比
特性 | Cookie | Session |
存储位置 | 存储在客户端浏览器(浏览器内存或硬盘)。 | 存储在服务器端(内存、文件、数据库或缓存中)。 |
数据载体 | 数据随 HTTP 请求和响应在客户端与服务器之间传输(每次请求都会携带)。 | 服务器通过 Session ID 识别用户,Session ID 通常通过 Cookie 或 URL 传递,实际数据存于服务器。 |
存储容量 | 单个 Cookie 大小限制通常为 4KB,且浏览器对单个域名的 Cookie 数量有限制(一般 20-50 个)。 | 无固定大小限制,但过多 Session 会占用服务器资源(需考虑内存或存储性能)。 |
安全性 | 较低:数据可被客户端查看、篡改,易受 XSS、CSRF 攻击(但可通过 、 等属性增强安全性)。 | 较高:数据存于服务器,客户端仅持有 Session ID(需确保 ID 传输安全,防止会话劫持)。 |
有效期 | 可设置 过期时间(持久化 Cookie,存于硬盘)或临时 Cookie(浏览器关闭后失效)。 | 默认会话级有效(浏览器关闭后失效),也可设置过期时间(通过 等配置)。 |
跨域支持 | 受 同源策略限制(仅同域名、同端口、同协议可共享),支持子域名共享(需配置 )。 | 依赖 Session ID 的传递方式:若通过 Cookie 传递,则同样受同源策略限制;若通过 URL 重写,可跨域但不安全。 |
典型应用场景 | 存储非敏感用户信息(如记住密码、语言偏好、购物车临时数据)、跟踪用户行为。 | 存储敏感会话数据(如用户登录状态、权限信息、复杂会话逻辑数据)。 |
二、工作原理对比
1. Cookie 的工作流程
- 服务器生成 Cookie:首次响应时,服务器通过
Set-Cookie
头向浏览器发送 Cookie(包含键值对、有效期、域名等信息)。 - 浏览器存储 Cookie:浏览器将 Cookie 存储在本地(内存或硬盘)。
- 自动携带 Cookie:后续每次请求该域名时,浏览器会将对应 Cookie 附加到请求头中(如
Cookie: key=value
),服务器解析后识别用户。
2. Session 的工作流程
- 服务器创建 Session:用户首次访问时,服务器生成唯一的 Session ID,并在服务器端存储该用户的会话数据(如
$_SESSION
数组)。 - 传递 Session ID:服务器通过
Set-Cookie: PHPSESSID=xxx
(以 PHP 为例)将 Session ID 存入 Cookie,或通过 URL 重写(如url?session_id=xxx
)传递给客户端。 - 识别用户会话:客户端后续请求时,携带 Session ID,服务器根据 ID 查找对应的 Session 数据,实现状态保持。
三、优缺点对比
Cookie 的优缺点
- 优点:
-
- 无需服务器存储资源,减轻服务器压力。
- 跨浏览器会话(持久化 Cookie 可长期存储)。
- 简单易用,浏览器自动处理传递。
- 缺点:
-
- 数据暴露在客户端,存在安全风险。
- 容量有限,不适合存储大量数据。
- 每次请求都携带,增加网络流量。
Session 的优缺点
- 优点:
-
- 数据安全(敏感信息存于服务器)。
- 容量大,适合存储复杂会话数据。
- 支持会话级临时数据(如登录状态、购物车实时计算)。
- 缺点:
-
- 占用服务器资源(尤其是高并发场景下内存开销大)。
- 依赖 Cookie 或 URL 传递 Session ID,若客户端禁用 Cookie 则需 URL 重写(不安全)。
- 分布式架构中需共享 Session(如通过 Redis、数据库集群),增加复杂度。
四、适用场景选择
- 优先使用 Cookie:
-
- 存储非敏感、轻量的用户偏好(如主题设置、语言选择)。
- 实现 “记住密码” 功能(需加密存储 token)。
- 跨页面共享简单数据(如购物车商品 ID,不涉及复杂计算)。
- 优先使用 Session:
-
- 存储用户登录状态、权限信息(如用户 ID、角色)。
- 临时存储需要计算或验证的数据(如表单提交前的临时数据、购物车总价计算)。
- 防止敏感数据泄露(避免在客户端暴露用户隐私或认证信息)。
五、安全增强措施
Cookie 安全配置
HttpOnly
:禁止 JavaScript 访问 Cookie,防止 XSS 攻击。Secure
:仅在 HTTPS 连接下传输 Cookie,防止中间人攻击。SameSite
:设置Strict
或Lax
,防止 CSRF 攻击(限制跨站请求携带 Cookie)。- 加密存储:对 Cookie 中的敏感数据(如 token)进行加密处理。
Session 安全措施
- 定期销毁过期 Session:通过配置
session.gc_maxlifetime
避免僵尸 Session 占用资源。 - 强 Session ID 生成:使用足够长度的随机字符串,防止暴力破解。
- 分布式 Session 共享:使用 Redis、Memcached 等缓存工具,确保集群环境下 Session 一致性。
- 会话固定攻击防护:用户登录后重新生成 Session ID(如登录时废弃旧 ID,生成新 ID)。
总结
Cookie 和 Session 各有优劣,实际应用中常结合使用:
- Cookie 用于存储轻量、非敏感的客户端状态,减少服务器压力。
- Session 用于管理敏感的服务器端会话数据,确保安全性和数据完整性。
理解两者的区别和适用场景,能帮助开发者在性能、安全和用户体验之间找到平衡,构建更健壮的 Web 应用。
28.ARP协议工作原理
一、ARP 协议的作用
ARP(Address Resolution Protocol)是 TCP/IP 协议族中的一个重要协议,主要用于将 IP 地址解析为对应的 MAC 地址(物理地址)。在局域网中,数据链路层(如以太网)通过 MAC 地址标识设备,而网络层通过 IP 地址路由数据。当主机需要向另一台主机发送数据时,必须先知道对方的 MAC 地址,ARP 协议即负责这一解析过程。
二、核心工作流程
假设主机 A(IP: 192.168.1.1,MAC: AA-AA-AA-AA-AA)需要向主机 B(IP: 192.168.1.2,MAC 未知)发送数据,ARP 协议的工作步骤如下:
1. 检查 ARP 缓存(本地映射表)
- 主机 A 首先查询本地的ARP 缓存表,查看是否有 IP 地址 192.168.1.2 对应的 MAC 地址。
- 若存在缓存记录,则直接使用该 MAC 地址封装数据帧,无需进一步操作;
- 若缓存中无记录,则进入下一步。
2. 发送 ARP 请求广播(Broadcast)
- 主机 A 构造一个ARP 请求报文,包含以下关键信息:
-
- 发送方 IP:192.168.1.1
- 发送方 MAC:AA-AA-AA-AA-AA
- 目标 IP:192.168.1.2(待解析的 IP)
- 目标 MAC:全 0(未知,用 0 填充)
- 该报文以广播形式发送到局域网(所有主机都会收到),数据链路层的广播地址为 FF-FF-FF-FF-FF-FF。
3. 接收方响应(单播 Unicast)
- 局域网内所有主机收到 ARP 请求后,检查目标 IP 是否为自己的 IP:
-
- 非目标主机:忽略该请求,不做响应;
- 目标主机 B:发现目标 IP 是自己的 IP,记录发送方 A 的 IP 和 MAC 地址(更新自己的 ARP 缓存),并构造ARP 响应报文,包含:
-
-
- 发送方 IP:192.168.1.2(自己的 IP)
- 发送方 MAC:BB-BB-BB-BB-BB(自己的 MAC)
- 目标 IP:192.168.1.1(主机 A 的 IP)
- 目标 MAC:AA-AA-AA-AA-AA(主机 A 的 MAC)
-
- 响应报文以单播形式直接发送给主机 A(通过主机 A 的 MAC 地址定位)。
4. 更新 ARP 缓存
- 主机 A 收到响应后,将主机 B 的 IP-MAC 映射关系写入本地 ARP 缓存,后续发送给 B 的数据帧即可直接使用该 MAC 地址封装。
5. ARP 缓存的老化机制
- 为避免缓存过时,ARP 条目有生存时间(TTL)(通常几分钟),过期后自动删除,下次通信时重新解析。
三、ARP 协议的核心特点
- 广播请求,单播响应:
-
- 请求阶段通过广播泛洪寻找目标主机,确保同一网络内所有设备都能接收到;
- 响应阶段仅目标主机回复,避免网络拥塞。
- 仅作用于本地网络:
-
- ARP 协议仅在同一局域网(子网)内有效,跨网段通信需通过路由器(路由器会隔离广播域,且每个接口有独立的 MAC 地址)。
- 两种操作类型:
-
- 正向 ARP:已知 IP 地址,解析 MAC 地址(最常用场景);
- 反向 ARP(RARP):已知 MAC 地址,解析 IP 地址(已很少使用,被 DHCP 取代)。
四、ARP 的应用场景与潜在问题
- 典型场景:
-
- 主机首次通信时解析目标 MAC 地址;
- 网络设备(如路由器、交换机)维护 IP-MAC 映射表。
- 安全风险:
-
- ARP 欺骗(ARP 攻击):恶意主机伪造 ARP 响应,篡改他人 ARP 缓存,导致数据流向错误地址(如中间人攻击);
- ARP 泛洪:大量伪造的 ARP 请求导致网络拥塞或设备缓存溢出。
五、总结
ARP 协议是连接 IP 地址(网络层)和 MAC 地址(数据链路层)的桥梁,通过广播请求 - 单播响应 - 缓存机制高效实现地址解析。其设计依赖局域网的广播特性,但也因此存在安全隐患(如 ARP 欺骗)。在实际网络中,需结合 ARP 缓存过滤、静态绑定等手段提升安全性。
29.GET和POST的区别
1. 定义与用途
- GET:
-
- 请求获取资源,用于从服务器获取数据(如查询、获取页面内容)。
- 本质是 “读取” 操作,不会修改服务器端数据(理想情况下应保持幂等性)。
- POST:
-
- 提交数据给服务器,用于向服务器提交新资源(如表单提交、上传文件、创建数据)。
- 本质是 “写入” 操作,会修改服务器端数据(通常是非幂等的,多次提交可能产生不同结果)。
2. 参数传递方式
- GET:
-
- 参数通过 URL 明文拼接(格式:
?key1=value1&key2=value2
),直接附加在请求路径后。 - 示例:
https://api.example.com/search?keyword=apple&page=2
。
- 参数通过 URL 明文拼接(格式:
- POST:
-
- 参数通过 请求体(Request Body) 传递,不暴露在 URL 中。
- 需指定
Content-Type
头(如application/x-www-form-urlencoded
、application/json
等)。
3. 参数可见性与安全性
- GET:
-
- 参数完全可见于 URL,会被浏览器历史记录、服务器日志、代理服务器缓存记录,安全性较低(不适合传递敏感数据,如密码)。
- 例:用户收藏包含 GET 参数的 URL 时,参数会被保留。
- POST:
-
- 参数在请求体中,URL 中不显示,相对隐蔽,但 仅在 HTTPS 加密时才真正安全(否则仍可通过抓包获取)。
- 适合提交敏感数据(如登录信息、支付信息)。
4. 幂等性与副作用
- 幂等性:多次调用对资源的影响相同。
-
- GET:具有幂等性(多次请求同一资源,结果不变)。
- POST:不保证幂等性(每次提交可能创建新资源,如重复提交表单会生成多条数据)。
- 副作用:
-
- GET 应无副作用(仅读取数据);
- POST 会产生副作用(如创建、更新数据)。
5. 长度限制
- GET:
-
- 受限于 URL 长度限制(不同浏览器 / 服务器限制不同,通常为 2048 字节左右)。
- 原因:浏览器需处理完整 URL,过长可能导致解析错误。
- POST:
-
- 理论上无固定长度限制,由服务器配置决定(可支持大文件上传,如文件表单)。
6. 缓存与浏览器行为
- GET:
-
- 请求可被浏览器、代理服务器缓存(除非显式禁用),适合频繁读取的场景。
- 可被书签收藏,重新加载时浏览器直接重复请求(不会提示重新提交)。
- POST:
-
- 不会被缓存(需显式设置缓存头),且重新加载时浏览器会提示 “是否重新提交数据”(避免重复操作)。
- 无法直接收藏为书签(需额外处理参数)。
7. 典型应用场景
- GET:
-
- 搜索查询(如商品搜索)、获取页面数据、静态资源请求(图片、API 数据)。
- POST:
-
- 登录 / 注册(提交用户信息)、提交表单(如评论、订单)、上传文件、创建 / 更新资源(如发布文章)。
8. 其他细节
- 请求格式:
-
- GET 请求没有请求体(即使添加,服务器也可能忽略);
- POST 必须有请求体(携带参数)。
- HTTP 方法语义:
-
- 遵循 RESTful 设计时,GET 对应 “读取”(
GET /users/1
),POST 对应 “创建”(POST /users
)。
- 遵循 RESTful 设计时,GET 对应 “读取”(
总结对比表
特性 | GET | POST |
用途 | 请求资源(读取) | 提交数据(写入) |
参数位置 | URL 明文拼接 | 请求体(Body) |
可见性 | 高(URL 可见) | 低(Body 不可见,需加密保障安全) |
幂等性 | 是 | 否 |
长度限制 | 受限(URL 长度) | 无固定限制(服务器决定) |
缓存支持 | 支持 | 不支持(需显式设置) |
副作用 | 无(理想情况) | 有(修改服务器数据) |
典型场景 | 数据查询、静态资源获取 | 表单提交、数据创建 / 更新、文件上传 |
注意事项
- 安全性误区:POST 并非绝对安全,其安全性依赖 HTTPS(加密传输),而非参数位置;
- REST 规范:应遵循 HTTP 方法的语义(如用 GET 读取、POST 创建、PUT 更新、DELETE 删除),而非仅通过 URL 路径区分。
通过合理选择 GET 或 POST,可以优化接口设计,提升安全性和用户体验。
30.HTTPS和HTTP的区别
HTTPS(Hypertext Transfer Protocol Secure)是 HTTP 的安全版本,通过加密和认证机制保障数据传输的安全性。以下是两者的核心区别:
1. 安全性与数据传输
特性 | HTTP | HTTPS |
传输方式 | 明文传输(数据未加密),易被监听、篡改或窃取。 | 通过 SSL/TLS 协议 加密传输,数据经过加密处理,防止中间人攻击。 |
加密机制 | 无加密。 | 采用 对称加密(如 AES,快速但密钥需保密)和 非对称加密(如 RSA,安全但速度慢)结合: |
身份验证 | 无服务器身份验证,无法确认对方是否为真实服务器。 | 通过 数字证书(由 CA 机构颁发)验证服务器身份,防止假冒站点(如钓鱼网站)。 |
2. 协议端口与 URL
- HTTP:
-
- 默认端口为 80。
- URL 以
http://
开头,浏览器地址栏无安全标识(如锁形图标)。
- HTTPS:
-
- 默认端口为 443。
- URL 以
https://
开头,浏览器地址栏显示 锁形图标,并标注 “安全”(如 Chrome 显示 “安全”),点击可查看证书详情。
3. 连接过程与步骤
- HTTP 连接流程:
-
- 客户端发起 TCP 连接(三次握手)。
- 直接发送请求并接收响应,无额外安全层。
- HTTPS 连接流程(多了 TLS 握手阶段):
-
- 客户端发起 TCP 连接。
- TLS 握手(建立安全通道):
-
-
- 客户端与服务器协商加密算法和版本(如 TLS 1.3)。
- 服务器向客户端发送数字证书,客户端验证证书有效性(如过期时间、CA 签名)。
- 客户端生成随机对称密钥,用服务器公钥加密后发送给服务器(服务器用私钥解密)。
-
-
- 后续数据通过对称密钥加密传输,确保完整性和机密性。
4. 数字证书与信任机制
- HTTP:无需证书,无法验证服务器身份。
- HTTPS:
-
- 必须向 CA(证书颁发机构,如 Let's Encrypt、Symantec)申请 SSL/TLS 证书,证书包含服务器公钥、域名、有效期等信息。
- 客户端通过内置的 CA 根证书链验证服务器证书的合法性,确保通信对象是目标服务器而非中间人。
5. 性能与资源消耗
- HTTP:
-
- 无加密开销,响应速度快,资源消耗低。
- HTTPS:
-
- 由于 TLS 握手和加密计算,会增加 延迟(约 100-500ms)和 CPU / 内存消耗。
- 但现代优化(如会话重用、TLS 1.3 简化握手流程)和硬件加速(如 AES-NI)已大幅降低性能影响。
6. 搜索引擎与浏览器策略
- HTTP:
-
- 谷歌等浏览器会标记 HTTP 页面为 “不安全”(尤其在输入框场景),可能影响用户信任。
- 搜索引擎(如 Google)可能降低 HTTP 网站的排名(因安全性不足)。
- HTTPS:
-
- 浏览器默认信任并优先加载 HTTPS 资源,地址栏显示安全标识。
- Google 将 HTTPS 作为 SEO 排名因素之一,鼓励网站迁移至 HTTPS(提升搜索权重)。
7. 应用场景
- HTTP:
-
- 适用于无需保护数据的场景,如公开静态页面(博客、新闻)、内部测试环境。
- 缺点:不适合传输敏感信息(如登录密码、支付数据),易被中间人攻击。
- HTTPS:
-
- 强制用于涉及用户隐私或敏感操作的场景,如金融网站(银行、支付)、电商平台、登录 / 注册页面。
- 现代 Web 趋势:即使无敏感数据,也推荐使用 HTTPS(如 GitHub Pages、博客),以提升安全性和用户信任。
8. 成本与部署
- HTTP:
-
- 无需证书,部署简单,成本低。
- HTTPS:
-
- 需要购买或申请证书(部分免费,如 Let's Encrypt)。
- 需配置服务器支持 HTTPS(如 Nginx 开启 SSL 模块),定期更新证书(避免过期)。
总结:核心区别对比
维度 | HTTP | HTTPS |
安全性 | 明文传输,不安全 | 加密传输,防篡改、窃听、身份伪造 |
端口 | 80 | 443 |
加密 | 无 | SSL/TLS 协议(对称 + 非对称加密) |
证书 | 不需要 | 需要 CA 证书(验证服务器身份) |
浏览器标识 | 无安全标识 | 显示锁形图标和 “安全” 状态 |
性能 | 快,低消耗 | 稍慢,需 TLS 握手和加密计算 |
SEO 影响 | 无优势,可能被标记为 “不安全” | 有优势,谷歌优先收录和排名 |
适用场景 | 公开、非敏感数据传输 | 敏感数据(登录、支付)、用户信任场景 |
为什么 HTTPS 更安全?
HTTPS 通过 机密性(数据加密)、完整性(哈希校验防止篡改)、认证性(证书验证服务器身份)三大机制,解决了 HTTP 的核心安全缺陷,是现代 Web 安全的基石。即使部署成本和性能有轻微影响,其安全性优势也使其成为绝大多数网站的首选。
31.OSI的七层模型都有哪些
OSI(Open System Interconnection)七层模型是国际标准化组织(ISO)制定的网络通信体系结构,用于规范不同系统之间的互联与通信。七层模型从 ** 顶层(用户端)到底层(物理硬件)** 依次为:
1. 应用层(Application Layer)
- 功能:直接为用户应用程序提供服务(如文件传输、邮件、远程登录等),是用户与网络的接口。
- 常见协议 / 技术:HTTP、HTTPS、FTP、SMTP、POP3、DNS、Telnet、SSH 等。
- 作用:处理应用逻辑,例如浏览器访问网页、邮件客户端收发邮件。
2. 表示层(Presentation Layer)
- 功能:负责数据格式的转换、加密 / 解密、压缩 / 解压缩,确保不同系统间数据的兼容性。
- 核心任务:
-
- 数据格式转换(如 JSON/XML 与二进制的转换);
- 数据加密(如 SSL/TLS 加密)、解密;
- 数据压缩(如 ZIP 压缩)、解压缩。
- 示例:图片格式(JPEG/PNG)转换、加密传输前的信息处理。
3. 会话层(Session Layer)
- 功能:管理设备之间的通信会话,包括会话的建立、维护和终止。
- 核心任务:
-
- 建立会话连接(如客户端与服务器的会话 ID 绑定);
- 会话同步(支持断点续传,如文件传输中断后从断点恢复);
- 会话终止(正常关闭或异常中断处理)。
- 示例:数据库连接(如 MySQL 的会话管理)、远程桌面连接(RDP 会话)。
4. 传输层(Transport Layer)
- 功能:提供端到端的可靠或不可靠数据传输,确保数据正确到达目标设备。
- 核心任务:
-
- 分割与重组数据(将上层数据分成合适大小的 “段” Segment);
- 流量控制(避免发送方过载接收方);
- 错误检测与恢复(可靠传输时重传丢失的数据)。
- 常见协议:
-
- TCP(传输控制协议,可靠连接,如网页访问);
- UDP(用户数据报协议,无连接,高效但不可靠,如视频流、DNS)。
5. 网络层(Network Layer)
- 功能:负责网络间的逻辑寻址和路由选择,实现不同网络(如跨网段、跨地区)的数据传输。
- 核心任务:
-
- 逻辑地址(IP 地址)的分配与管理;
- 路由选择(通过路由表决定数据传输路径);
- 分组转发(将数据封装为 “包” Packet,如 IP 数据包)。
- 常见协议:IP、ICMP(错误报告)、ARP(IP 到 MAC 地址转换)、RIP/OSPF(路由协议)。
6. 数据链路层(Data Link Layer)
- 功能:在相邻节点(同一链路)之间传输数据,确保数据帧的可靠传输。
- 核心任务:
-
- 物理地址(MAC 地址)的寻址;
- 数据封装为 “帧”(Frame),添加帧头(源 / 目标 MAC)和帧尾(校验码);
- 错误检测(如 CRC 校验)和纠正(部分场景);
- 流量控制(如停止等待协议)。
- 子层:
-
- LLC(逻辑链路控制子层):处理上层协议的逻辑接口;
- MAC(介质访问控制子层):管理物理层的接入(如 Ethernet 争用、WiFi 的 CSMA/CA)。
- 常见技术:Ethernet(以太网)、Wi-Fi、PPP(拨号上网)、VLAN(虚拟局域网)。
7. 物理层(Physical Layer)
- 功能:定义物理设备与传输介质的电气、机械、功能和规程特性,实现比特流(0/1)的传输。
- 核心任务:
-
- 传输介质(电缆、光纤、无线信号)的选择;
- 比特流的编码与解码(如电压高低表示 1/0);
- 物理接口标准(如 RJ45 接口、光纤接口、蓝牙信号)。
- 关键参数:传输速率(bps)、信号调制方式、带宽、物理拓扑(总线型、星型等)。
记忆口诀与层次对比
- 七层顺序记忆:
应表会传网数物(应用层、表示层、会话层、传输层、网络层、数据链路层、物理层)。 - 每层数据单元:
-
- 应用层:数据(Data)
- 表示层:数据(Data)
- 会话层:数据(Data)
- 传输层:段(Segment)
- 网络层:包(Packet)
- 数据链路层:帧(Frame)
- 物理层:比特流(Bit)
OSI 模型的作用
- 标准化:各层功能独立,便于不同厂商设备互连;
- 故障排查:分层定位问题(如网络层故障可能导致跨网段通信失败);
- 协议设计:为网络协议开发提供框架(如 TCP 对应传输层,IP 对应网络层)。
虽然实际应用中更常用简化的 TCP/IP 四层模型(应用层、传输层、网络层、网络接口层),但 OSI 七层模型是理解网络原理的基础。
32.http长连接和短连接的区别
HTTP 长连接(持久连接)和短连接是两种处理客户端与服务器之间 TCP 连接的方式,主要区别在于连接是否在多次请求中复用。以下是具体对比:
1. 连接建立与关闭方式
短连接(Short Connection)
- 工作原理:
每次 HTTP 请求都单独建立一条 TCP 连接,请求完成后立即关闭连接(经历 TCP 三次握手建立连接,四次挥手关闭连接)。 - 典型流程:plaintext
客户端 → 三次握手 → 发送请求 → 服务器响应 → 四次挥手关闭连接
- 协议支持:
-
- HTTP/1.0 默认使用短连接,需显式设置
Connection: close
(实际默认行为也是关闭)。 - 每次请求都需重新建立和销毁连接。
- HTTP/1.0 默认使用短连接,需显式设置
长连接(Persistent Connection/Keep-Alive)
- 工作原理:
一次 TCP 连接建立后,允许多个 HTTP 请求复用该连接,连接在一段时间内保持打开,直到双方决定关闭(或超时)。 - 典型流程:plaintext
客户端 → 三次握手 → 发送请求1 → 服务器响应1 → 发送请求2 → 服务器响应2 → …(一段时间后)四次挥手关闭连接
- 协议支持:
-
- HTTP/1.1 默认启用长连接,通过
Connection: keep-alive
头字段控制(无需显式声明,默认值为keep-alive
)。 - 可通过
Keep-Alive: timeout=xxx, max=xxx
设定连接超时时间和最大请求数(非必需)。
- HTTP/1.1 默认启用长连接,通过
2. 核心区别对比
特性 | 短连接 | 长连接 |
连接复用 | 不复用,每次请求独立建立 / 关闭连接 | 复用,一次连接处理多次请求 |
TCP 握手开销 | 高(每次请求都有三次握手 + 四次挥手) | 低(仅首次请求有握手,后续请求无额外开销) |
网络效率 | 低(频繁创建 / 销毁连接,浪费资源) | 高(减少握手耗时,提升吞吐量) |
服务器资源占用 | 低(连接关闭后释放资源) | 高(需维护空闲连接,可能占用更多内存 / 句柄) |
适用场景 | 单次请求、低并发场景(如简单静态网页浏览) | 高并发、频繁请求场景(如 API 接口、单页应用) |
连接管理 | 无需维护连接状态 | 需处理连接超时(如设置心跳机制或超时时间) |
3. 优缺点对比
短连接的优点:
- 资源释放快:请求结束后立即关闭连接,服务器无需长期维护空闲连接,适合短时间、低频率的请求。
- 实现简单:无需处理连接复用和超时管理,逻辑简单。
短连接的缺点:
- 效率低:频繁的 TCP 握手增加延迟,尤其在高并发时性能下降明显。
- 网络开销大:每次请求都需重新建立连接,浪费带宽和 CPU 资源。
长连接的优点:
- 性能提升:减少握手开销,适合多次交互的场景(如 AJAX 频繁请求、微服务间调用)。
- 降低延迟:避免重复建立连接的耗时,尤其在网络延迟较高时优势显著。
长连接的缺点:
- 资源占用高:服务器需维护大量空闲连接,可能导致端口或内存耗尽(需配置连接池、超时机制)。
- 连接维护复杂:需处理连接超时(如通过
Keep-Alive
头设置超时时间)、心跳机制(检测连接是否存活)。
4. 实际应用与配置
短连接的应用场景:
- 单次请求的场景:如简单的文件下载、静态页面访问(较少使用,因 HTTP/1.1 默认长连接)。
- 对服务器资源敏感的场景:若请求频率极低,长连接的空闲维护成本可能高于握手开销。
长连接的应用场景:
- 高并发 API 接口:如 RESTful 服务、前后端分离项目(频繁的 JSON 数据交互)。
- 单页应用(SPA):页面切换时通过 AJAX 异步请求数据,复用同一连接。
- 微服务架构:服务间调用频繁,长连接减少网络开销。
关键 HTTP 头字段:
Connection: close
:显式关闭连接(短连接)。Connection: keep-alive
:保持连接(长连接,HTTP/1.1 默认)。Keep-Alive: timeout=5, max=100
:设置连接超时 5 秒,最多处理 100 个请求(非必需,不同服务器实现可能不同)。
5. 补充:HTTP/2 与长连接
- HTTP/2 强制长连接:无论
Connection
头如何设置,HTTP/2 连接始终保持打开,且支持多路复用(同一连接并发处理多个请求,避免队头阻塞)。 - HTTPS 与长连接:HTTPS(基于 TLS/SSL)同样支持长连接,且由于 TLS 握手开销更高,长连接的优势更明显(减少 TLS 握手次数)。
总结
- 短连接:适用于单次、低频率请求,简单但效率低。
- 长连接:适用于高频、高并发场景,高效但需管理连接资源。
现代 Web 开发中,HTTP/1.1 长连接是主流,而 HTTP/2 在此基础上进一步优化了连接复用机制,成为性能更佳的选择。
33.什么是SSL,SSL是怎莫工作保证安全的
什么是 SSL?
SSL(Secure Sockets Layer,安全套接层) 是一种为网络通信提供安全及数据完整性的协议,用于在客户端(如浏览器)和服务器之间建立加密连接,确保传输的数据不被窃取、篡改或伪造。其后续版本称为 TLS(Transport Layer Security),目前 SSL/TLS 常被混用,TLS 是更现代、安全的标准(如 TLS 1.2、TLS 1.3),但习惯上仍统称为 SSL。
SSL 如何保证安全?核心工作原理
SSL 通过 加密通信、身份验证、数据完整性校验 三大机制保障安全,具体工作流程分为 “SSL 握手” 和 “数据传输” 两个阶段:
一、SSL 握手阶段:建立安全连接
- 客户端发起请求(ClientHello)
-
- 客户端向服务器发送请求,包含支持的 SSL 版本、加密算法列表(如 TLS 1.3)、随机数(用于生成密钥)等信息。
- 服务器响应(ServerHello)
-
- 服务器选择双方都支持的 SSL 版本和加密算法,返回自身的 数字证书(包含服务器公钥),并生成另一个随机数(与客户端的随机数共同生成会话密钥)。
- 客户端验证服务器身份
-
- 客户端检查服务器证书的有效性:
-
-
- 证书是否由受信任的 CA(证书颁发机构) 签发(如 Symantec、Let’s Encrypt)。
- 证书是否过期、域名是否与当前访问的域名匹配。
-
-
- 若验证通过,客户端提取服务器公钥。
- 生成会话密钥(预主密钥交换)
-
- 客户端生成一个 预主密钥(Pre-Master Secret),用服务器公钥加密后发送给服务器。
- 客户端和服务器通过预主密钥及之前的两个随机数,生成相同的 会话密钥(对称密钥),用于后续数据加密(对称加密效率更高)。
- 服务器确认握手完成
-
- 服务器用私钥解密预主密钥,生成会话密钥,并向客户端发送 “握手完成” 消息。
二、数据传输阶段:加密与完整性保护
- 对称加密传输数据
-
- 双方使用会话密钥对传输的数据进行 对称加密(如 AES 算法),加密后的信息即使被截获,没有密钥也无法解密。
- 数据完整性校验
-
- 通过 哈希函数(如 SHA-256)对数据生成摘要,再用会话密钥生成 消息认证码(MAC),随数据一起传输。
- 接收方重新计算哈希值并与 MAC 对比,确保数据未被篡改。
- 身份验证(仅服务器端,可选客户端验证)
-
- 通常服务器需向客户端证明身份(通过数字证书),客户端身份验证(如双向 SSL)较少见,仅在高安全场景(如企业内部系统)使用。
三、核心安全机制解析
- 非对称加密与对称加密结合
-
- 非对称加密(如 RSA、ECC):用于握手阶段交换预主密钥,确保密钥传输安全(公钥加密,私钥解密),但计算开销大。
- 对称加密:用于实际数据传输,效率高,适合大量数据加密(双方共享会话密钥)。
- 数字证书与 CA 信任链
-
- 服务器数字证书包含公钥、域名、有效期、CA 签名等信息,CA 作为第三方机构确保公钥确实属于该服务器,防止中间人伪造身份(如钓鱼网站)。
- 防止中间人攻击
-
- 握手过程中,客户端验证服务器证书的合法性,确保通信双方是真实的(而非中间人冒充),且数据在传输中被加密,中间人无法窃取或篡改。
四、SSL/TLS 的应用场景
- HTTPS:在 HTTP 基础上叠加 SSL/TLS,实现网页数据加密(如用户登录、支付信息传输)。
- 邮件协议:如 SMTPS、IMAPS,加密邮件传输。
- VPN:通过 SSL/TLS 建立安全通道,远程访问企业内部网络。
- API 接口:保护数据在客户端与服务器 API 之间的传输安全。
总结
SSL 通过 握手阶段的身份验证和密钥协商,以及 传输阶段的加密与完整性校验,确保网络通信的 机密性、完整性和身份真实性。其核心是利用非对称加密建立安全通道,再通过对称加密高效传输数据,同时借助 CA 证书体系防止身份伪造,是现代互联网安全的基石。