计算机网络基础
子网划分怎么算
1.核心公式：子网数 = 2^子网位，每个子网主机数 = 2^ 主机位 – 2（减网络地址和广播地址
2.比如 192.168.1.0/24 要分成 4 个子网，需借 2 位子网位（2^2=4），子网掩码变 255.255.255.192
滑动窗口机制是什么
滑动窗口的本质是：允许发送方 “一次发一批数据（不用等每一个的 ACK）”，等收到部分确认后，再 “滑动” 窗口发新的一批，既保证可靠性，又提升效率。
滑动窗口的 2 个核心功能：流量控制 + 拥塞控制
流量控制：防止接收方 “撑死”（接收方主导）
安全关联：如果某 IP 的 TCP 窗口 “忽大忽小，异常波动”（比如一秒内从 100 降到 1，又突然升到 200），可能是恶意流量（比如 DDoS 攻击中的 “脉冲式发包”）—— 用 Wireshark 抓包分析时，这种窗口异常能帮助识别恶意流量。
TCP 三次握手、四次挥手的过程
三次握手（建立连接）：
① 客户端发 SYN（同步）；
② 服务器回 SYN+ACK（同步 + 确认）；
③ 客户端发 ACK（确认），连接建立。
四次挥手（断开连接）：
① 客户端发 FIN（结束）；
② 服务器回 ACK；
③ 服务器发 FIN；
④ 客户端回 ACK，断开。
HTTP 和 HTTPS 的区别
① 端口：HTTP 用 80，HTTPS 用 443；
② 加密：HTTP 明文（抓包能看到内容），HTTPS 加了 TLS/SSL 层（数据加密，防篡改、防窃听）；
③ 证书：HTTPS 需要 CA 证书（验证服务器身份，防钓鱼）；
④ 安全场景：做 “互联网发布前安全检测” 时，会检查是否强制 HTTPS，避免敏感数据泄露。
VLAN 的作用是什么
① 定义：虚拟局域网，把一个物理网络分成多个逻辑网络；
② 作用：同一 VLAN 内的设备能通信，不同 VLAN 不能直接通（需路由器），减少广播风暴，同时实现 “网络隔离”（比如把财务 VLAN 和办公 VLAN 分开，防办公网入侵财务网）。
SSL/TLS
SSL（安全套接层） 和 TLS（传输层安全） 都是用于在互联网上建立加密通信通道的加密协议。它们确保在两个系统（浏览器和一个网站服务器）之间传递的数据是私密和完整的。TLS 是 SSL 的更新、更安全的版本，我们现在普遍使用的都是 TLS。
在没有 SSL/TLS 的情况下，在互联网上发送的数据（如密码、信用卡号、聊天信息）都是以明文形式传输的。这就像寄出一张明信片，任何经手的人都能看到上面的内容。SSL/TLS 相当于给这封信加上了一个只有收件人才能打开的坚固的保险箱，确保了数据的：
加密：隐私性，防止窃听。
认证：确认您正在与正确的服务器通信，而不是一个假冒的网站
完整性：确保数据在传输过程中未被篡改
工作原理简析（以访问 HTTPS 网站为例）
安全通信：握手完成后，双方使用这个会话密钥对所有后续的通信进行加密和解密。浏览器地址栏看到一个锁的图标，表示连接是安全的。
“握手”：当浏览器连接到使用 HTTPS 的网站时，它会启动一个“TLS 握手”。
交换凭证：服务器向浏览器发送其 SSL/TLS 证书，该证书由一个受信任的第三方（证书颁发机构，CA）签发，证明了服务器的身份。
密钥协商：浏览器验证证书有效后，双方会通过一种复杂的算法协商出一个唯一的会话密钥。这个过程中，即使有人监听了整个协商过程，也无法计算出这个密钥。
核心关系总结：
所有版本的 SSL 都已被发现存在严重安全漏洞，在现代安全实践中已被彻底废弃。 现在使用和谈论的，本质上都是 TLS。
继承关系：TLS 直接建立在 SSL 3.0 的基础之上，可以看作是 SSL 的官方升级版。
不兼容：虽然一脉相承，但 TLS 1.0 与 SSL 3.0 不能直接互通。
目前人们常说SSL是因为历史惯性和品牌认知，许多产品和服务，如“SSL证书”、“SSL VPN”，在命名时就固定下来了，即使它们现在主要服务于 TLS。
数字签名
数字签名是一串基于密码学计算出来的数据串，它主要用于验证真实性、完整性、不可否认性。
签名的核心过程（基于非对称加密）：数字签名的实现依赖于非对称加密（也称为公钥加密）。在这种体系下，每个参与者拥有一对密钥：
公钥：公开给所有人。用于验证签名。
私钥：绝对保密，只有自己拥有。用于签名。
发送方生成签名
发送方将原始消息和数字签名一起发送给接收方。有时也会附带发送自己的数字证书（其中包含了发送方的公钥和身份信息）。将会有以下步骤：
1.计算哈希值:发送方将需要签名的原始消息通过一个哈希函数（如 SHA-256）进行处理。输出得到一段固定长度的、独一无二的字符串，称为 “消息摘要” 或 “哈希值”。【注意：哈希是单向的，无法从摘要反推原始消息；任何对消息的微小改动都会产生一个完全不同的哈希值。】
2.用私钥加密摘要：发送方使用自己的私钥，对第一步生成的消息摘要进行加密。加密后得到的数据，就是 “数字签名”。
3.发送：发送方将原始消息和数字签名一起发送给接收方。有时也会附带发送自己的数字证书（其中包含了发送方的公钥和身份信息）
接收方验证签名
1.计算原始消息的哈希值：接收方首先使用与发送方相同的哈希函数，对接收到的原始消息单独计算一次哈希值，得到 “消息摘要 A”。
2.用公钥解密签名：接收方使用发送方公开发布的公钥，对接收到的数字签名进行解密。如果解密成功，就能得到一串数据，我们称之为 “消息摘要 B”。解密成功本身在理论上就证明了签名是由对应的私钥创建的。
3.对比验证：接收方将自己计算出的 “消息摘要 A” 与解密签名得到的 “消息摘要 B” 进行比对。如果两者完全一致：正确验证；如果不一致，意味着要么消息被篡改了，要么签名是伪造的。验证失败。
实际应用场景：
电子邮件签名：使用S/MIME或PGP对邮件进行签名，让收件人确信邮件确实来自你且未被篡改。
软件更新：开发者对软件包进行签名，用户系统在安装前验证签名，确保下载的不是被恶意篡改过的版本。
HTTPS 网站：服务器向浏览器出示其数字证书，浏览器验证证书的签名（由证书颁发机构CA签发），以确认你访问的是真正的官网，而不是钓鱼网站。
区块链与加密货币：当你发起一笔比特币交易时，你需要用你的私钥对交易进行签名，以证明你拥有这些币的支配权。
关于数字签名在应用场景中的引申问题
Q：网站交互过程中，对流量进行分析，有单次加密，怎么能从中获取有效明文？
My A：单次加密的原理就是不可逆的，不会分析。
AI A：
“从密码学理论上讲，一个实现良好的单次加密过程确实是不可逆的，无法通过数学计算直接从密文得到明文。但是，在实际的网络攻防中，我们并不总是需要去正面破解加密算法。突破口可以存在于多个层面：
密钥层面：通过社会工程学、弱口令攻击或侧信道攻击来获取加密密钥。
实现层面：利用加密模式的使用错误（如ECB:相同的明文块会产生相同的密文块）或协议漏洞（如Padding Oracle:攻击者虽然不能解密，但可以篡改密文。接收方解密后得到的是乱码，但可能会通过错误信息暴露出部分明文信息）来推断出明文信息。
元数据层面：分析未加密的通信部分（如TLS握手、SNI字段）以及数据包的尺寸和时序，来获取大量有价值的情报。
系统层面：这是最有效的方式——直接攻陷客户端或服务器，在数据加密前或解密后获取明文，例如通过恶意软件或成功的中间人攻击。
因此，结论可以说：虽然无法‘解密’，但通过利用加密系统周边环节的脆弱性，完全有可能获取到有效的明文信息或与之等效的敏感信息。
XSS和CSRF的区别
跨站脚本攻击（XSS）：XSS 的核心在于 “信任用户输入”。攻击者利用网站对用户输入过滤不严的漏洞，将恶意脚本代码“注入”到网页中，当其他用户浏览该网页时，嵌入的恶意脚本就会被执行。
一个典型的反射型 XSS 攻击流程如下：
1.构造恶意链接：攻击者发现一个搜索框存在 XSS 漏洞，输入 keyword 后，页面会显示 “你搜索的关键词是：keyword”。
2.注入脚本：攻击者将 keyword 替换成一段恶意 JavaScript 代码，例如：<script>alert('XSS')</script>。
3.诱骗点击：攻击者将这个包含恶意代码的 URL 通过邮件、短信、论坛等方式发送给受害者。
4.执行脚本：受害者点击了这个链接，浏览器访问了漏洞网站，并将恶意代码作为参数发送。服务器返回的页面中包含了这个恶意脚本，受害者的浏览器便执行了它。
XSS 主要类型：
反射型 XSS：恶意脚本来自当前 HTTP 请求（如 URL 参数）。
存储型 XSS：恶意脚本被永久地存储在服务器的数据库、评论区、留言板等。任何访问该页面的用户都会中招，危害更大。
DOM 型 XSS：漏洞存在于前端 JavaScript 代码中，不经过服务器。客户端的脚本修改了页面的 DOM 结构，导致恶意代码执行。
防御措施：
1.设置 HttpOnly Cookie：防止恶意脚本通过 document.cookie 窃取用户的会话 Cookie。
2.对用户输入进行转义和过滤：将 <, >, &, ", ' 等危险字符转换为 HTML 实体（如 < 变为 <）。
3.使用 CSP（内容安全策略）：告诉浏览器只允许加载指定来源的脚本、样式等资源，从根本上杜绝内联脚本的执行。
跨站请求伪造（CSRF）：CSRF 的核心在于 “利用用户已登录的身份认证”。攻击者诱骗用户在当前已登录的 Web 应用程序上执行非本意的操作。一个典型的 CSRF 攻击流程如下：
1.用户登录：用户登录了 bank.com，服务器返回了一个会话 Cookie 保存在用户的浏览器中。
2.构造恶意请求：攻击者构造了一个向 bank.com/transfer?to=hacker&amount=1000 发起请求的页面（可以放在任何网站，如 evil.com）。
3.诱骗访问：攻击者诱骗已经登录了 bank.com 的用户访问 evil.com。
4.自动发送请求：evil.com 的页面中包含一个自动提交的表单或一个 <img src="..."> 标签，其目标就是那个转账 URL。
5.携带凭证：用户的浏览器在访问 bank.com/transfer... 时，会自动带上之前在 bank.com 的登录 Cookie。
6.服务器执行：服务器收到带有合法 Cookie 的请求，认为这是用户的正常操作，于是执行了转账。
防御措施：
使用 SameSite Cookie：将 Cookie 设置为 SameSite=Strict 或 SameSite=Lax，可以阻止第三方网站在跨站请求中携带 Cookie，从根本上解决 CSRF 问题（现代浏览器支持得很好）。
使用 CSRF Token：服务器生成一个随机的、不可预测的 Token，藏在表单或请求头中。提交请求时，服务器验证这个 Token 是否合法。因为 evil.com 无法获取到这个 Token（受同源策略限制），所以它的伪造请求会失败。
验证 Referer/Origin 头部：检查请求来源的域名是否在白名单内。但可靠性稍差。
对称加密和非对称加密的应用场景及原因
对称加密应用场景：
1.大数据量加密，例如文件加密、磁盘加密（如BitLocker, FileVault）、数据库加密。
原因：对称加密算法（如AES）计算速度非常快，比非对称加密快成百上千倍。对于加密整个硬盘、大型文件或数据库字段这种海量数据操作，效率是首要考虑因素。
2.HTTPS/TLS 连接中的会话加密
原因：这是最经典的应用之一。在HTTPS建立连接的初期，会使用非对称加密来安全地协商一个临时的、随机的“会话密钥”。一旦双方拥有了这个共享的会话密钥，后续所有的数据传输都使用对称加密（如AES）。
深入思考：因为网页浏览涉及大量数据的实时传输（图片、视频、文本），必须使用高效的对称加密才能保证速度和用户体验。非对称加密只用于最开始的“握手”阶段，以解决密钥分发问题。
3.消息认证码（MAC）
原因：用于确保数据的完整性和真实性。发送方和接收方共享一个密钥，用它来生成和验证一个关于消息的“标签”。任何对消息的篡改都会导致验证失败
公钥加密应用场景：由于速度慢，它通常只用于加密密钥或非常短的数据（如密码），而不是整个邮件内容。
1.密钥交换（如TLS握手）
客户端获取服务器的公钥，并用它来加密一个随机生成的“会话密钥”，然后发送给服务器。只有拥有对应私钥的服务器才能解密出这个会话密钥。这样，双方就安全地共享了一个对称密钥，后续就可以改用高效的对称加密了。
2.数字签名
场景：软件发布、代码签名、电子合同、SSL证书。
原因：用于验证消息的来源（认证） 和完整性。发送方用自已的私钥对数据进行签名，接收方用发送方的公钥来验证签名。
3.非对称加密小数据（本身）
场景：加密用于登录网站的密码、加密电子邮件（如PGP）。
原因：当需要将少量机密信息发送给某个实体，且无法提前共享密钥时，非对称加密是唯一选择。发送方直接用接收方的公钥加密数据，只有接收方的私钥能解密。
完美结合：
HTTPS (TLS)：后续所有的HTTP通信，都使用这个会话密钥进行快速的对称加密和解密。
非对称加密（握手）：浏览器向服务器请求其公钥（包含在SSL证书中）；浏览器验证证书的真实性；浏览器生成一个随机的会话密钥；浏览器用服务器的公钥加密这个会话密钥，并发送给服务器。
对称加密接管（通信）：服务器用自己的私钥解密，得到会话密钥。
现在，浏览器和服务器都拥有了相同的会话密钥。
什么是HTTPS
HTTPS=HTTP+TLS；TLS 是一种协议，而 HTTPS 是一种使用该协议的方式
TLS（Transport Layer Security，传输层安全协议）：它是一个加密协议。它的设计目标是在两个通信应用程序（例如，你的浏览器和一个网站服务器）之间提供保密性和数据完整性。通过加密，它确保在网络上传输的数据不会被窃听和篡改。它工作在网络的“传输层”之上、“应用层”之下，为上层协议（如 HTTP）提供一个安全的通道。TLS 的前身是著名的 SSL（Secure Sockets Layer）。由于 SSL 存在安全漏洞，现在已经完全被 TLS 取代。但在日常交流中，人们仍然习惯用“SSL”来指代这类安全技术（例如，我们仍然说“SSL证书”）。
HTTPS（HyperText Transfer Protocol Secure，安全超文本传输协议）：它就是HTTP 的安全版本。当 HTTP 协议想要进行安全通信时，它不会自己去实现一套复杂的加密算法，而是直接使用 TLS 协议来建立连接。在开始传输任何实际的 HTTP 数据（比如网页内容）之前，客户端（浏览器）和服务器会先进行一个复杂的“握手”过程。这个“握手”过程就是TLS 握手，在这个过程中，双方会：协商使用哪个版本的 TLS（如 TLS 1.2, TLS 1.3）；验证服务器的身份（通过 SSL/TLS 证书）；生成共享的会话密钥，用于后续的对称加密。