2025年最新总结安全基础(面试题)
活动发起人@小虚竹 想对你说:
这是一个以写作博客为目的的创作活动,旨在鼓励大学生博主们挖掘自己的创作潜能,展现自己的写作才华。如果你是一位热爱写作的、想要展现自己创作才华的小伙伴,那么,快来参加吧!我们一起发掘写作的魅力,书写出属于我们的故事。我们诚挚邀请你参加为期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:
-
- 因可靠性机制(确认、重传、流量控