OSI 七层模型（Open Systems Interconnection）
国际标准化组织制定的网络通信分层标准，把网络功能从低到高分成 7 层，每层只负责一部分工作，方便不同设备兼容通信。
- 物理层（Physical Layer）
单位：比特（bit）
作用：负责硬件层面传输，只关心 0 和 1 的电信号、光信号传输。
典型设备：网线、光纤、集线器、网卡接口
- 数据链路层（Data Link Layer）
单位：帧（Frame）
作用：把比特组成帧，做差错检测、MAC 地址寻址，控制相邻节点间传输。
典型设备：交换机、网卡
协议：以太网、PPP、ARP
- 网络层（Network Layer）
单位：数据包（Packet）
作用：路由选择、IP 寻址，决定数据包从源到目的走哪条路径。
典型设备：路由器
协议：IP、ICMP、OSPF、 BGP
- 传输层（Transport Layer）
单位：数据段（Segment）
作用：负责端到端可靠传输，控制流量、差错重传、端口寻址。
核心协议：
TCP：可靠、面向连接
UDP：不可靠、速度快
- 会话层（Session Layer）
作用：建立、管理、断开应用之间的会话，保证通信不混乱。
功能：会话同步、断点续传控制
- 表示层（Presentation Layer）
作用：负责数据格式转换、加密解密、压缩解压，让双方能看懂对方数据。
例子：图片编码、SSL/TLS 加密、文本编码
- 应用层（Application Layer）
作用：直接为用户应用程序提供服务，是用户能接触到的一层。
典型协议：HTTP/HTTPS、FTP、DNS、SMTP、POP3
快速记忆口诀
物 数 网 传 会 表 应（物理 → 数据链路 → 网络 → 传输 → 会话 → 表示 → 应用）
TCP/IP 四层模型
也叫互联网协议套件模型，是实际互联网真正在用的模型，比 OSI 更简洁实用。
四层结构（从下到上）
网络接口层（Network Interface Layer）
网际层（Internet Layer）
传输层（Transport Layer）
应用层（Application Layer）
每层作用
- 网络接口层
负责与物理硬件打交道
处理帧、MAC 地址、网卡、网线、交换机等
对应 OSI 的：物理层 + 数据链路层
- 网际层
负责IP 寻址、路由选择
核心协议：IP、ICMP、ARP
对应 OSI 的：网络层
- 传输层
负责端到端数据传输
核心协议：TCP、UDP
对应 OSI 的：传输层
- 应用层
直接给应用程序提供服务
协议：HTTP、HTTPS、FTP、DNS、SMTP 等
对应 OSI 的：会话层 + 表示层 + 应用层
| OSI 七层模型 | TCP/IP 四层模型 |
|---|---|
| 7 应用层 | 4 应用层 |
| 6 表示层 | ↑ 合并到应用层 |
| 5 会话层 | ↑ 合并到应用层 |
| 4 传输层 | 3 传输层 |
| 3 网络层 | 2 网际层 |
| 2 数据链路层 | 1 网络接口层 |
| 1 物理层 | ↑ 合并到网络接口层 |
一句话速记
OSI：物数网传会表应
TCP/IP：网接 → 网际 → 传输 → 应用
中间两层一一对应，上下各合并三层。
IP 地址、MAC 地址 超清晰总结
一、什么是 MAC 地址？
MAC 地址（Media Access Control 地址）
也叫：物理地址、硬件地址
长度：48 位二进制 ，通常写成 16 进制例：
00:1A:2B:3C:4D:5E特点：出厂就烧在网卡里，全球唯一，一般不能改
MAC 地址作用
标识同一局域网内的设备
用于交换机寻址：在同一个内网里找具体设备
只在本地链路有效，出了路由器就没用
二、什么是 IP 地址？
IP 地址（Internet Protocol 地址）
逻辑地址，用来在整个互联网定位一台主机
常见：
IPv4：
192.168.1.100（32 位）IPv6：更长，解决地址不够用
IP 地址作用
标识网络中的主机位置
用于路由器跨网络寻址：从一个网传到另一个网
可以动态变化（DHCP 自动分配）
| 对比项 | MAC 地址 | IP 地址 |
|---|---|---|
| 全称 | Media Access Control | Internet Protocol |
| 别称 | 物理地址、硬件地址 | 逻辑地址、网络地址 |
| 长度 | 48 位（6 字节） | 32 位（IPv4）/128 位（IPv6） |
| 位置 | 网卡硬件中 | 系统网络配置中 |
| 是否可改 | 基本固定，可伪装但不建议 | 可动态分配、手动修改 |
| 作用范围 | 同一局域网内 | 整个互联网 |
| 工作层次 | 数据链路层（OSI 第 2 层） | 网络层（OSI 第 3 层） |
| 负责设备 | 交换机 | 路由器 |
| 通俗比喻 | 设备身份证号（终身不变） | 设备家庭住址（可搬家换地址） |
四、一句话理解它们的关系
MAC 地址：标识 "你是谁"
IP 地址：标识 "你在哪"
数据传输时：先通过 IP 地址找到目标网络 ，再通过 MAC 地址找到目标设备。
端口 & 端口号
- 什么是端口？
可以把一台电脑 想象成一栋大楼：
IP 地址 = 大楼地址（找到这栋楼）
端口号 = 房间号（找到具体房间 / 程序）
端口 就是设备上用于区分不同应用程序 的 "通道编号"。一台电脑只有一个 IP，但可以同时跑很多程序（QQ、浏览器、游戏、网盘......），靠端口号区分数据该发给谁。
- 端口号是什么？
是一个 16 位数字
范围：0 ~ 65535
写在 IP 后面，用冒号分隔例：
192.168.1.100:80
- 为什么需要端口号？
一句话：只有 IP 只能找到电脑，有了端口才能找到具体程序。
详细原因：
一台主机同时运行多个网络程序（浏览器、微信、游戏等）
数据包到达电脑后，系统不知道该交给哪个软件
通过端口号，操作系统就能精准分发数据
实现一个 IP 同时支持多个网络服务
常见默认端口（必背）
80：HTTP 网页
443：HTTPS 加密网页
21：FTP 文件传输
22：SSH 远程登录
25：SMTP 发邮件
53：DNS 域名解析
3389：Windows 远程桌面
端口分类
**知名端口（0~1023）**系统固定分配给常用服务，一般程序不能随便用
**注册端口（1024~49151）**给普通应用程序使用
**动态 / 私有端口（49152~65535）**客户端临时使用，连接断开就回收
一句话总结
IP 地址：找到哪台设备
端口号：找到设备上哪个程序
没有端口，电脑收到数据也不知道该给浏览器还是 QQ。
常见协议默认端口
- HTTP：80
- HTTPS：443
- FTP：21
- SSH：22
- MySQL：3306
- Redis：6379
- DNS：53
- Tomcat：8080
- PostgreSQL：5432
- SQL Server：1433
- MongoDB：27017
什么是局域网、广域网、网关、子网掩码
- 局域网（LAN）
全称：Local Area Network
范围：小范围网络（家里、公司、学校、机房）
特点：
距离近、速度快、延迟低
一般用交换机连接
IP 通常是内网 IP（如 192.168.x.x、10.x.x.x）
例子：家里几台手机电脑连同一个 Wi-Fi
- 广域网（WAN）
全称：Wide Area Network
范围：跨地域的大范围网络
特点：
距离远、速度相对慢
靠路由器、运营商线路连接
例子：互联网、跨城市的公司专线
一句话区分：局域网 = 小圈子内部网 广域网 = 大网络 / 互联网
- 网关（Gateway）
通俗理解：内网通往外网的 "大门"
作用：让局域网设备能访问外部网络数据包要出内网，必须经过网关
通常就是：路由器的 IP 例如：
192.168.1.1一句话：网关就是内网的 "出口管理员"
- 子网掩码（Subnet Mask）
作用：判断两个 IP 是不是在同一个局域网里
格式和 IP 一样，如
255.255.255.0机器通过 IP & 子网掩码 计算出网络号
网络号相同 → 同一局域网，直接通信
网络号不同 → 不在同一网，必须走网关
最常见：
255.255.255.0（家用 / 小型公司）一句话：子网掩码用来划分 "哪些 IP 是自己人"
快速总结（必背）
局域网：小范围内部网
广域网：大范围外部网 / 互联网
网关：内网访问外网的出口
子网掩码：判断两个 IP 是否在同一局域网
DNS 域名系统
- 什么是 DNS？
DNS = Domain Name System，域名系统 。作用就是：把域名翻译成 IP 地址。
人记域名：
baidu.com机器只认 IP：
110.242.68.66DNS 就是中间的 "翻译官"
DNS 作用
域名 → IP 地址转换（正向解析）
让用户不用记复杂 IP，只记好记的域名
实现负载均衡、智能解析（就近访问）
DNS 查询过程（递归 + 迭代，面试 / 考试必考）
你在浏览器输入
www.baidu.com，流程如下：
浏览器查本地缓存之前访问过，直接用缓存 IP。
查操作系统缓存（hosts 文件） Windows：
C:\Windows\System32\drivers\etc\hosts请求本地 DNS 服务器（运营商 DNS，如 114.114.114.114）本地 DNS 先查自己缓存，有就直接返回。
**本地 DNS 去问根域名服务器（Root）**根服务器说：我不知道，但我知道 ** 顶级域服务器（.com）** 在哪。
问 .com 顶级域服务器 .com 服务器说：我不知道，但我知道百度的权威 DNS在哪。
问百度权威 DNS 服务器 权威 DNS 直接返回：
www.baidu.com对应的 IP。本地 DNS 把结果返回给你的电脑同时缓存下来，下次直接用。
浏览器拿着 IP 去访问目标服务器
一句话速记
DNS = 域名翻译官 查询流程：浏览器 → 系统 → 本地 DNS → 根 DNS → 顶级 DNS → 权威 DNS → 拿到 IP
常用公共 DNS
114.114.114.114
8.8.8.8（谷歌）
223.5.5.5 / 223.6.6.6（阿里）
1.1.1.1（Cloudflare）
HTTP 是什么
HTTP = HyperText Transfer Protocol（超文本传输协议）
互联网上网页传输最常用的协议
用于浏览器和服务器之间通信，请求文字、图片、视频等资源
特点：无连接、无状态、明文传输
- 属于哪一层
在 OSI 七层模型 ：第 7 层 应用层
在 TCP/IP 四层模型 ：应用层
- 简单补充（常考点）
对应端口：80
HTTPS = HTTP + TLS/SSL 加密，端口 443
基于 TCP 可靠传输
HTTP 1.0 / 1.1 / 2.0 / 3.0 区别
HTTP 从 1.0 到 3.0 的核心演进，是解决连接效率、队头阻塞、传输性能 三大问题的过程。下面用表格 + 要点讲清区别，面试 / 考试直接背。
| 特性 | HTTP/1.0 (1996) | HTTP/1.1 (1999) | HTTP/2 (2015) | HTTP/3 (2022) |
|---|---|---|---|---|
| 底层协议 | TCP | TCP | TCP | UDP + QUIC |
| 连接机制 | 短连接（每请求新建 TCP） | 持久连接（Keep‑Alive，默认） | 多路复用（单 TCP） | 多路复用（QUIC，无队头阻塞） |
| 传输格式 | 纯文本 | 纯文本 | 二进制分帧 | 二进制分帧 |
| 头部压缩 | ❌ 无 | ❌ 无 | ✅ HPACK | ✅ QPACK |
| 队头阻塞 | ✅ 严重 | ✅ 存在（管道化仍阻塞） | ❌ 应用层解决，但TCP 层仍有 | ❌ 彻底解决（流独立） |
| 服务器推送 | ❌ | ❌ | ✅ 支持 | ✅ 支持 |
| 加密 | 无 | 可选（HTTPS） | 可选（HTTPS） | 强制 TLS 1.3 |
| 核心痛点 | 连接开销大 | 队头阻塞、头部冗余 | TCP 层队头阻塞 | 无（终极方案） |
二、各版本详细区别
- HTTP/1.0
连接 ：短连接，每发一个请求就新建一次 TCP 连接（三次握手 + 四次挥手），开销极大。
特点：
引入请求头、响应头、状态码、Content‑Type。
支持 GET/POST/HEAD 方法。
无持久连接、无头部压缩、无并发优化。
问题：加载一个网页要建 N 次连接，速度极慢。
- HTTP/1.1（里程碑，至今主流）
核心改进：
持久连接（Keep‑Alive）：默认开启，一个 TCP 连接可发多个请求，大幅减少握手开销。
管道化（Pipeline） ：可连续发多个请求，但响应必须按序返回 → 仍有队头阻塞。
Host 头：支持一台服务器部署多个网站（虚拟主机）。
缓存增强：Cache‑Control、ETag、If‑None‑Match 等。
分块传输：Transfer‑Encoding: chunked，支持大文件流式传输。
新增方法：PUT/DELETE/OPTIONS/PATCH 等。
遗留问题：
队头阻塞：一个请求慢，后面全堵。
头部无压缩，Cookie/User‑Agent 重复传输，浪费带宽。
浏览器同域名最多开 6--8 个连接，并发有限。
- HTTP/2（性能飞跃）
核心突破：
二进制分帧：把报文拆成二进制 "帧"，解析更快、更紧凑。
多路复用（Multiplexing） ：单 TCP 连接并行传输多个请求 / 响应 ，帧可乱序，按流 ID 重组 → 解决应用层队头阻塞。
HPACK 头部压缩：静态表 + 动态表 + 哈夫曼编码，头部体积减少 50%--80%。
服务器推送（Server Push）：服务器可主动推送资源（如 HTML → 自动推 CSS/JS）。
流优先级：可设置请求优先级（如先加载关键资源）。
遗留问题：
- 底层还是 TCP → TCP 层队头阻塞依然存在（一个包丢了，整个连接等待重传）。
- HTTP/3（终极方案）
底层革命 ：抛弃 TCP，改用 QUIC 协议（基于 UDP）。
核心优势：
彻底解决队头阻塞 ：QUIC 实现流级独立，一个流丢包不影响其他流。
0‑RTT 握手：首次连接后，后续可 0 延迟建立连接。
更快的连接迁移：Wi‑Fi/4G 切换不中断连接。
QPACK 头部压缩：适配 QUIC 多路复用的头部压缩。
强制 TLS 1.3：更安全、更快的加密。
现状：Chrome、Firefox、Cloudflare 已支持，正在普及。
三、一句话总结演进
1.0 → 1.1 ：从短连接 到长连接，解决连接开销。
1.1 → 2 ：从文本 + 串行 到二进制 + 多路复用，解决应用层队头阻塞。
2 → 3 ：从TCP 到QUIC（UDP） ，彻底解决TCP 层队头阻塞，速度与稳定性拉满。
HTTP 请求方法有哪些？GET 和 POST 区别
一、HTTP 常见请求方法
GET：查询、获取资源
POST：提交数据、创建资源
PUT：修改 / 更新资源（整体替换）
PATCH：局部更新资源
DELETE：删除资源
HEAD：只获取响应头，不返回 body
OPTIONS：查询服务器支持哪些方法（跨域预检用）
TRACE：追踪请求路径（一般禁用）
CONNECT：建立隧道（代理用）
二、GET 和 POST 核心区别（面试必背）
- 作用不同
GET ：用于查询、获取数据，不修改服务器
POST ：用于提交、新增、修改数据，会产生副作用
- 参数位置
GET ：参数放在URL里，可见
POST：参数放在 ** 请求体（body）** 里，相对隐蔽
- 数据大小
GET：受 URL 长度限制，一般几 KB
POST：理论无限制，适合传大量数据 / 文件
- 安全性
GET ：明文可见，不安全，不能传敏感信息
POST：相对安全，但不加密，仍需 HTTPS
- 缓存
GET ：会被浏览器缓存
POST：默认不缓存
- 历史记录 / 书签
GET：会保留在历史记录，可收藏为书签
POST：不会
- 幂等性
GET ：幂等（多次请求结果一样）
POST ：非幂等（多次提交可能重复创建）
- 编码类型
GET ：只支持 URL 编码
POST：支持 form-data、json、文件等多种类型
极简背诵版
GET：查数据，URL 传参，长度有限，可缓存，不安全，幂等
POST：交数据，Body 传参，无大小限制，不缓存，相对安全，非幂等
HTTP 状态码分类：1xx、2xx、3xx、4xx、5xx 分别代表什么
一、五大类含义
1xx：信息性状态码 服务器收到请求，继续处理
2xx：成功状态码 请求正常处理完成
3xx：重定向状态码 需要进一步操作，跳转其他地址
4xx：客户端错误 客户端发的请求有问题，服务器无法处理
5xx：服务器错误 请求没问题，但服务器自己挂了 / 出错了
二、每类常见状态码（必背）
1xx 信息类
- 100 Continue：继续发送请求
2xx 成功
200 OK：请求成功（最常见）
201 Created：创建成功（如新建用户）
204 No Content：成功，但无返回内容
3xx 重定向
301 Moved Permanently：永久重定向
302 Found：临时重定向
304 Not Modified：资源未修改，使用缓存（非常高频）
4xx 客户端错误
400 Bad Request：请求参数错误
401 Unauthorized：未登录 / 未授权
403 Forbidden：拒绝访问（有权限也不让进）
404 Not Found：资源不存在
405 Method Not Allowed：请求方法不支持
429 Too Many Requests：请求太频繁
5xx 服务器错误
500 Internal Server Error：服务器内部错误
502 Bad Gateway：网关错误
503 Service Unavailable：服务不可用 / 超载
504 Gateway Timeout：网关超时
一句话速记
1xx：等一等
2xx：成了
3xx：走这边
4xx：你错了
5xx：我炸了
常见 HTTP 状态码含义
200 OK请求成功，正常返回数据。
301 Moved Permanently 永久重定向，旧地址废弃，推荐用新地址。
302 Found 临时重定向，只是暂时跳转，以后还可能变。
304 Not Modified 资源未修改，直接用本地缓存，不用重新下载。
400 Bad Request请求参数错误、格式不对，服务器看不懂。
401 Unauthorized 未登录、token 无效，需要身份验证。
403 Forbidden 服务器拒绝访问，权限不足。
404 Not Found资源不存在，页面 / 接口找不到。
500 Internal Server Error服务器代码报错、异常，后台挂了。
502 Bad Gateway网关错误，服务器作为网关 / 代理收到无效响应。
HTTPS 是什么？加密原理
- HTTPS 是什么
HTTPS = HTTP + SSL/TLS 加密
安全版的 HTTP
默认端口：443
作用：保证传输过程加密、防窃听、防篡改、防冒充
- 加密原理（面试必背）
HTTPS 用的是对称加密 + 非对称加密 结合的方式，也叫混合加密。
① 对称加密
加密解密用同一把密钥
速度快
问题：密钥在网络传输时容易被窃听
② 非对称加密
有公钥 + 私钥一对：
公钥：公开给所有人
私钥：自己保存，绝不外传
公钥加密 → 只能私钥解密
私钥加密 → 只能公钥解密
优点：安全
缺点：速度慢
HTTPS 完整握手流程（极简版）
客户端发起请求，支持的 TLS 版本、加密套件
服务器返回数字证书（包含服务器公钥）
客户端验证证书真伪（由 CA 机构颁发）
客户端生成一个随机对称密钥
用服务器公钥加密这个对称密钥，发给服务器
服务器用私钥解密，得到对称密钥
之后双方都用这个对称密钥加密传输数据
一句话总结：用非对称加密安全交换对称密钥，再用对称加密高速传输数据。
- 额外作用
身份验证：证书确保你访问的是真实服务器
数据完整性：防止内容被篡改
防中间人攻击
HTTP 与 HTTPS 核心区别
安全性
HTTP：明文传输，数据易被窃听、篡改、劫持
HTTPS：加密传输，防窃听、防篡改、防冒充
协议与端口
HTTP ：超文本传输协议，端口 80
HTTPS ：HTTP + TLS/SSL，端口 443
加密方式
HTTP：无加密
HTTPS：对称加密 + 非对称加密混合加密
是否需要证书
HTTP：不需要证书
HTTPS ：需要 CA 颁发的数字证书
性能
HTTP：开销小、速度快
HTTPS：握手加密有开销，稍慢一点
搜索引擎与浏览器
HTTP：浏览器标 "不安全"，SEO 排名低
HTTPS：标安全锁，搜索引擎更友好
一句话速记
HTTP 明文 80 不安全，HTTPS 加密 443 更安全，需要证书。
HTTPS 握手过程简单描述
这里给你一段最简单、面试直接背的 HTTPS 握手过程，不绕弯子：
客户端说：我要建立 HTTPS 连接，把支持的加密方式发给服务器。
服务器回应：选一种加密方式，并把 ** 数字证书（含公钥）** 发给客户端。
客户端验证证书是否合法有效。
客户端生成一个随机对称密钥 ，用服务器的公钥加密后发过去。
服务器用自己的私钥解密，拿到对称密钥。
之后双方都用这个对称密钥加密通信，握手完成。
超简一句话版
客户端验证证书 → 生成对称密钥 → 用公钥加密传给服务器 → 双方用对称密钥加密传输。
Cookie 和 Session 核心区别
- 简单一句话
Cookie：数据存在客户端（浏览器）
Session：数据存在服务器，客户端只存一个 SessionID
- 详细对比
Cookie
存储位置：浏览器
容量：很小，一般 4KB 左右
生命周期：可设置过期时间，关闭浏览器不一定消失
安全性：低，明文可见，能被篡改、伪造
传输：每次请求都会自动带上 Cookie
用途：记住用户名、主题、广告追踪、购物车等
Session
存储位置：服务器（内存 / 数据库 / 缓存）
容量：几乎无限制
生命周期：默认随会话结束（关闭浏览器或超时失效）
安全性：高，数据在服务器，客户端只有 ID
传输：只传一个 SessionID（通常放在 Cookie 里）
用途：登录状态、用户信息、权限等敏感数据
- 核心区别总结表
| 对比项 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端浏览器 | 服务器端 |
| 安全性 | 较低，可查看修改 | 较高，数据不暴露 |
| 存储大小 | 小（≤4KB） | 大 |
| 服务器压力 | 无压力 | 占用服务器资源 |
| 生命周期 | 可长期保存 | 临时会话，超时销毁 |
| 支持禁用 | 可被浏览器禁用 | 依赖 Cookie 传递 SessionID |
它们怎么配合工作？（登录流程）
用户登录成功
服务器创建 Session，保存用户信息
服务器把 SessionID 通过 Cookie 发给浏览器
浏览器之后每次请求自动带上这个 Cookie
服务器根据 SessionID 找到对应的 Session，识别用户
超简背诵版
Cookie 存在客户端，小、不安全、可持久
Session 存在服务端，大、安全、临时
Session 通常靠 Cookie 传递 SessionID 工作
Token 是什么？与 Session 区别
- Token 是什么
Token = 令牌
是一串加密字符串（如 JWT），相当于服务器给用户发的 "通行证"
登录成功后，服务器生成并签发 Token，返回给客户端
客户端自己保存（localStorage / Cookie）
后续请求时主动带上，服务器验证通过就放行
- Token 与 Session 核心区别
| 对比项 | Session | Token |
|---|---|---|
| 存储位置 | 信息存在服务器 | 信息加密存在客户端 |
| 状态 | 有状态：服务器要存会话 | 无状态：服务器不存会话 |
| 扩展性 | 差，集群需同步 Session | 好，分布式 / 微服务天然适用 |
| 跨域 / 跨端 | 麻烦，依赖 Cookie | 方便，APP / 小程序 / 跨域都能用 |
| 安全性 | 依赖 SessionID，易被劫持 | 可加密、过期、签名，防篡改 |
| 压力 | 占服务器内存 / 缓存 | 几乎不占服务器存储 |
- 一句话总结
Session：服务器记着你是谁，你只带个编号
Token：服务器不记你，通行证里自己带着身份信息，验签就行
- 最简单记忆
Session：有状态，服务器存，集群麻烦
Token：无状态，客户端存，分布式友好
浏览器输入 URL → 页面显示 全过程
- 解析 URL
判断是域名还是 IP
补全协议（默认 HTTP/HTTPS）
拆分出：协议、域名、端口、路径、参数
DNS 域名解析（域名 → IP）
查浏览器缓存
查系统 hosts
查本地 DNS 服务器
依次请求：根 DNS → 顶级域 DNS → 权威 DNS
得到目标服务器 IP
建立传输层连接
如果是 HTTP ：建立 TCP 连接（三次握手）
如果是 HTTPS ：先 TCP 握手，再进行 TLS 握手，建立加密通道
- 浏览器发送 HTTP 请求
构造请求行、请求头、请求体
发送 GET/POST 等请求到服务器 IP
- 服务器处理请求并返回响应
服务器接收请求
处理业务逻辑、查询数据库
返回 HTTP 响应（状态码、响应头、HTML 等内容）
- 关闭连接（可选）
HTTP/1.1 默认 Keep-Alive，不断开
否则进行 TCP 四次挥手
浏览器解析渲染页面（核心）
解析 HTML ，生成 DOM 树
解析 CSS ，生成 CSSOM 树
结合 DOM + CSSOM 生成 渲染树（Render Tree）
布局（Layout/Reflow）：计算元素位置大小
绘制（Paint）：填充像素、颜色、图片
合成（Composite）：将多层合成显示
加载额外资源
遇到 CSS、JS、图片、字体等继续发起请求
JS 执行可能阻塞渲染
图片异步加载，加载完成后重新绘制
- 页面最终展示给用户
超简背诵版（考场 / 面试口述版）
解析 URL
DNS 解析域名成 IP
TCP 三次握手建立连接
HTTPS 则进行 TLS 握手
浏览器发 HTTP 请求
服务器处理并返回响应
浏览器解析 HTML → DOM 树
解析 CSS → CSSOM 树
生成渲染树 → 布局 → 绘制 → 合成
加载静态资源，最终显示页面
TCP 和 UDP 区别 + 适用场景
一、TCP 与 UDP 核心区别
| 对比项 | TCP 传输控制协议 | UDP 用户数据报协议 |
|---|---|---|
| 连接性 | 面向连接（必须先建立连接） | 无连接（发完拉倒） |
| 可靠性 | 可靠传输，不丢包、不乱序 | 不可靠，可能丢包、乱序 |
| 重传机制 | 有，丢包自动重传 | 无 |
| 流量 / 拥塞控制 | 有 | 无 |
| 传输效率 | 慢，开销大 | 快，开销极小 |
| 数据形式 | 字节流 | 数据报 |
| 双工性 | 全双工 | 支持一对一、一对多、多对多 |
二、简单一句话理解
TCP ：像打电话，先拨号接通，再说内容，保证你听得清清楚楚。
UDP ：像寄平信 / 广播，直接发出去，不管对方收没收到、顺序对不对。
三、适用场景
TCP 适用：要求可靠、不能丢数据
HTTP/HTTPS（网页）
FTP（文件传输）
SMTP/POP3（邮件）
MySQL、Redis（数据库连接）
文件下载、登录支付
UDP 适用：要求快、允许少量丢包
直播、点播
网络游戏
视频通话（微信 / QQ 视频）
DNS 域名解析
在线语音聊天
四、超简背诵版
TCP：面向连接、可靠、慢、适合对数据完整性要求高的场景。
UDP：无连接、不可靠、快、适合实时性要求高的场景。
TCP 三次握手
一、三次握手过程（通俗 + 专业版）
目的：建立可靠的 TCP 连接
第一次握手（客户端 → 服务器）
客户端发送：SYN 包
含义："我想连接你，我的初始序列号是 x。"
第二次握手（服务器 → 客户端）
服务器回复：SYN + ACK 包
含义："收到了，我同意连接。我的初始序列号是 y，并且确认收到你的 x（ACK=x+1）。"
第三次握手（客户端 → 服务器）
客户端发送：ACK 包
含义："收到你的确认，我已准备好，确认收到你的 y（ACK=y+1）。"
之后连接正式建立，开始传输数据。
二、为什么必须是三次？不能两次、不能四次？
核心目的只有一个：
确保双方的【发送能力】和【接收能力】都正常。
一步步看：
第一次握手 服务器知道：→ 客户端能发 → 自己能收
第二次握手 客户端知道：→ 自己能发、能收→ 服务器能发、能收但服务器还不确定客户端能不能收
第三次握手 服务器终于知道：→ 客户端能收→ 双方收发都没问题
总结为什么要三次
两次 ：只能确认客户端没问题，服务器不知道客户端能不能收，不可靠。
四次：多余，浪费资源。
三次 ：刚好能同时确认客户端、服务器双方收发都正常，是最小可靠次数。
超简背诵版
客户端发 SYN → 服务端
服务端回 SYN+ACK → 客户端
客户端发 ACK → 服务端连接建立。
为什么三次？ 确保客户端和服务器双方的发送、接收能力都正常，最少可靠次数。
TCP 四次挥手
一、作用
用于可靠关闭 TCP 连接，保证双方数据都传输完毕再断开。
二、四次挥手过程（通俗版）
第一次挥手：客户端 → 服务器（FIN 包）
客户端说：我发完数据了，请求关闭连接。
客户端进入 FIN_WAIT_1 状态。
第二次挥手：服务器 → 客户端（ACK 包）
服务器说：收到你的关闭请求，我知道了。
服务器进入 CLOSE_WAIT ，客户端进入 FIN_WAIT_2。
此时：客户端不能发，但服务器还能发剩余数据。
第三次挥手：服务器 → 客户端（FIN 包）
服务器说：我也发完了，现在可以正式关闭。
服务器进入 LAST_ACK。
第四次挥手：客户端 → 服务器（ACK 包）
客户端说：收到，同意关闭。
客户端进入 TIME_WAIT，等待 2MSL 后彻底关闭。
服务器收到后直接关闭。
三、为什么需要四次挥手？
一句话核心：TCP 是全双工通信，双方要各自关闭 "发送通道"，各发一次 FIN + ACK。
展开说：
TCP 连接双方都能独立收发数据
客户端先关自己的发送端（第一次 FIN）
服务器回复 ACK 确认（第二次 ACK）
但服务器可能还有数据要发，不能马上关
等服务器发完，再主动关闭它的发送端（第三次 FIN）
客户端最后回复 ACK（第四次 ACK）
所以必须四次：
客户端：FIN → ACK
服务器：ACK → FIN
不像三次握手可以把 SYN 和 ACK 合并成一次，挥手时不能合并，因为服务器不一定立刻关闭。
四、超简背诵版
客户端发 FIN，请求关闭
服务器回 ACK，收到请求
服务器发 FIN，也准备关闭
客户端回 ACK，连接关闭
为什么四次？ 因为 TCP 是全双工 ，双方要各自独立关闭发送通道，不能合并。
TIME_WAIT 是什么？为什么要等 2MSL
- TIME_WAIT 是什么？
出现在四次挥手的主动关闭方（通常是客户端）
发送完最后一个 ACK 后，不会立刻关闭，而是进入 TIME_WAIT 状态
等待时间：2MSL
- 什么是 MSL？
MSL = Maximum Segment Lifetime
报文最大生存时间（一个数据包在网络上最多能活多久）
超过这个时间，数据包会被路由器丢弃
不同系统一般设为 30s / 60s / 120s
所以 2MSL 就是：数据包一来一回最长可能需要的时间
- 为什么要等 2MSL？（两个核心原因）
① 防止最后一个 ACK 丢失，导致对方无法正常关闭
如果客户端发完 ACK 立刻关闭
万一 ACK 在网络中丢了
服务器收不到 ACK，会以为 FIN 丢了，重发 FIN
客户端已经关闭，会回复 RST，导致服务器报错
等待 2MSL 可以确保：即使最后一个 ACK 丢了，服务器重发的 FIN 也能在 2MSL 内回来，客户端可以再次 ACK。
② 让本次连接的所有 "残留数据包" 在网络中自然消失
网络中可能还有延迟到达的旧数据包
如果不等它们消失，立刻用相同端口建立新连接
旧包可能被新连接错误接收，导致数据混乱
2MSL 能保证：本次连接的所有报文都已消失在网络中，不会干扰下一次连接。
极简背诵版
TIME_WAIT ：主动关闭连接后，等待 2MSL 的状态
为什么等 2MSL
确保最后一个 ACK 不丢失，让对方正常关闭
让网络中旧数据包全部过期消失，避免影响新连接
粘包、拆包 超清晰讲解
一、什么是粘包、拆包？
基于 TCP 是流式协议（像水流一样连续），没有消息边界，所以会出现：
- 粘包
发送方发了两条独立消息：
消息A、消息B接收方一次性收到：
消息A+消息B连在一起→ 这就是粘包
- 拆包
发送方发了一条完整消息：
消息A接收方分成两次收到：
消息A的一部分+消息A剩下的部分→ 这就是拆包二、为什么会发生？
TCP 是流式协议，不保留消息边界，只保证字节有序可靠
发送缓冲区累积数据，一次性发出去 → 粘包
发送数据超过 MSS/MTU，被分片发送 → 拆包
Nagle 算法（合并小包发送）也会导致粘包
三、怎么解决？（三种经典方案）
核心思路：给数据加上 "边界"，让接收方能分清一条消息从哪开始、到哪结束
- 固定消息长度（不常用）
每条消息固定长度，不足补空格
缺点：不灵活，浪费带宽
- 固定包头 + 包体长度（最常用）
包头固定 4 字节，表示包体长度
接收流程：
先读包头，拿到长度 N
再精确读取 N 字节包体
优点：高效、通用，几乎所有项目都用这个
- 特殊分隔符分隔
每条消息末尾加特殊符号：
\n、\r\n等接收方读到分隔符就认为一条消息结束
优点：简单
缺点：内容里不能出现分隔符，需转义
极简背诵版
粘包：多条消息拼成一条收到
拆包：一条消息分成多次收到
原因：TCP 是流式协议，无消息边界
解决：
固定长度
消息头 + 长度 + 消息体（主流）
特殊分隔符
TCP 可靠传输机制
- 确认应答（ACK）
每收到一段数据，接收方就返回一个 ACK 确认号
告诉发送方："我收到了，下次从这里发"
保证数据不丢失、不乱序
- 超时重传
发送方发完数据启动定时器
若超时未收到 ACK ，认为丢包，重新发送
保证即使丢包也能恢复
- 滑动窗口
不用每发一段就等 ACK，一次性连续发多段
窗口大小表示可发送但未确认的数据量
提升传输效率，同时保持可靠
- 流量控制
作用：防止发送方发太快，把接收方撑爆
接收方在 ACK 中告诉对方自己的接收窗口大小（rwnd）
发送方根据窗口调整发送速度
- 拥塞控制
作用：防止网络拥堵、雪崩
发送方维护 拥塞窗口 cwnd，根据网络状况调整
包含四个阶段：
慢启动（指数增长）
拥塞避免（线性增长）
快重传（连续 3 个重复 ACK 立即重传）
快恢复（丢包后不从头开始）
一句话总结
TCP 通过 ACK 确认、超时重传 保证不丢不乱；通过 滑动窗口 提高效率；通过 流量控制 保护接收方；通过 拥塞控制 保护整个网络。
TCP 拥塞控制 4 个阶段
- 慢启动（Slow Start）
刚连接时，拥塞窗口 cwnd 很小
每收到一个 ACK，cwnd 指数增长（1→2→4→8...）
快速试探网络能承受多大流量
- 拥塞避免（Congestion Avoidance）
达到慢启动门限 ssthresh 后，进入此阶段
cwnd 不再暴增，改为线性增长（加 1）
平稳提升速度，避免突然拥塞
- 快重传（Fast Retransmit）
收到 连续 3 个重复 ACK ，判定为丢包
不等定时器超时，立刻重传丢失的包
减少等待时间，提高效率
- 快恢复（Fast Recovery）
快重传后，不进入慢启动
把门限 ssthresh 设为当前 cwnd 的一半
cwnd 设为新门限，直接进入拥塞避免
不用从头开始，恢复更快
一句话口诀
慢启动暴增，拥塞避免缓增； 快重传立即补发，快恢复不从头来。
半连接队列 & 全连接队列
- 半连接队列（SYN Queue）
存放状态 ：服务端收到客户端 SYN ，回复 SYN+ACK 后，连接处于 SYN_RCVD
作用 ：存储还没完成三次握手的连接
什么时候移出 ：收到客户端最后一次 ACK，完成三次握手，移入全连接队列
一句话：还没握完手的连接，在半连接队列等着。
- 全连接队列（Accept Queue）
存放状态 ：已经完成三次握手，建立好的 TCP 连接
作用 ：等待应用程序调用
accept()取走连接什么时候移出 ：应用层
accept()处理连接后移出一句话：已经握完手、可以正式用的连接，在全连接队列等着被处理。
超简总结
半连接队列 ：三次握手进行中（SYN_RCVD）
全连接队列 ：三次握手已完成（ESTABLISHED），等待应用处理
对应的攻击：
- 半连接队列被占满 → SYN Flood 攻击
SYN 洪水攻击原理
- 攻击原理
攻击者伪造大量不存在的 IP ，向服务器不停发送 SYN 包（第一次握手）。
服务器收到后：
回复 SYN+ACK（第二次握手）
把这个半开连接放入半连接队列（SYN 队列）
等待客户端的 ACK，并重试超时重发
但攻击者根本不会回复 ACK，这些连接就一直占着半连接队列，直到超时。
- 最终结果
半连接队列很快被占满 ，正常用户的 SYN 进不来，服务器无法建立新连接 → 服务不可用。
一句话总结
攻击者大量发送伪造 SYN 包，不回 ACK，占满半连接队列，让服务器无法处理正常连接。
IP 协议作用
IP 协议属于网络层协议，核心就两件事：
寻址 给每个主机分配 IP 地址，确定数据要发给谁、从哪发来。
路由选择 根据目标 IP，选择路径，让数据包能穿过多个路由器，从源主机传到目标主机。
一句话总结
IP 协议负责寻址和路由，让数据包能在网络中找到目的地，但不保证可靠、不保证顺序。
补充：
无连接：发数据包不需要先建立连接
不可靠：可能丢包、乱序，可靠性靠上层 TCP 实现
IPv4 与 IPv6 核心区别
- 地址长度与数量
IPv4 ：32 位，约 42 亿 个地址，早已不够用
IPv6：128 位，地址数量近乎无限，彻底解决地址短缺
- 地址表示
IPv4 ：点分十进制，如
192.168.1.1IPv6 ：冒分十六进制，如
2001:db8::1
- 路由与性能
IPv4：路由表大，转发效率低
IPv6：路由层次更优，转发更快
- 安全性
IPv4：无内置安全，需额外加密
IPv6 ：原生支持 IPSec，更安全
- 自动配置
IPv4：需 DHCP 或手动配置
IPv6：支持无状态自动配置，即插即用
- 组播与移动性
- IPv6 比 IPv4 支持更好，适合物联网、移动设备
一句话速记
IPv4 地址少、32 位、不安全；IPv6 地址无限、128 位、原生安全、自动配置。
ARP 协议
- 作用
根据目标 IP 地址，获取对应的 MAC 地址，实现局域网内通信。
工作过程
主机 A 想和主机 B 通信，知道主机 B 的 IP，但不知道 MAC。
主机 A 在局域网内发送 ARP 请求广播："谁的 IP 是 ×××，请把 MAC 告诉我！"
同一局域网内所有主机都收到，只有主机 B 响应。
主机 B 发送 ARP 应答单播，把自己的 MAC 发给主机 A。
主机 A 收到后，将 IP 与 MAC 的映射存入 ARP 缓存，后续直接使用。
一句话总结
ARP：IP → MAC 地址解析，先广播问，再单播回，缓存起来。
RARP、ICMP、IGMP
- RARP 协议（反向地址解析协议）
作用 ：与 ARP 相反，根据 MAC 地址 → 获取 IP 地址
场景：无盘工作站启动，不知道自己 IP，只知道网卡 MAC
现在基本被 DHCP 取代
- ICMP 协议（互联网控制报文协议）
作用 ：网络层的 "差错检测 + 网络诊断"
用来传递网络异常信息（不可达、超时、重定向等）
典型应用：
ping 命令（检测网络通不通）
traceroute（追踪路由路径）
- IGMP 协议（网际组管理协议）
作用 ：实现 IP 组播（多播）
主机和路由器之间用，告诉路由器："我要加入 / 退出某个组播组"
场景：直播、视频会议、IPTV 等一对多传输
一句话速记
ARP：IP → MAC
RARP：MAC → IP
ICMP：网络报错、ping 用
IGMP：组播管理，一对多
Ping 命令使用协议 & 工作原理
- 使用协议
ICMP 协议（互联网控制报文协议）
工作原理
源主机向目标主机发送 ICMP 回显请求报文（Echo Request）
目标主机收到后，回复 ICMP 回显应答报文（Echo Reply）
如果源主机收到应答，说明网络连通；超时或收不到则说明不通 / 丢包。
简单一句话
Ping 就是发送 ICMP 请求，等对方 ICMP 回复，用来测试网络是否通、延迟多少。
静态路由 vs 动态路由
- 静态路由
由管理员手动配置路由条目
不会自动适应网络变化
优点：简单、稳定、不占带宽、安全
缺点：网络拓扑变了要手动改，不适合大型网络
适用：小型网络、固定拓扑网络
- 动态路由
路由器之间自动学习、交换路由信息，自动生成路由表
网络故障或拓扑变化时自动调整
优点：自适应、扩展性好、适合大型网络
缺点：占用带宽、配置复杂、安全性稍差
常见协议：RIP、OSPF、IS-IS、BGP
一句话总结
静态路由：手动配、不变、简单； 动态路由：自动学、自适应、适合大型网络。
什么是子网划分
把一个大网络，拆分成多个更小的子网，分别管理。
目的：
减少广播风暴，提高网络效率
节约 IP 地址，避免浪费
方便网络管理与安全隔离
原理：借位，把主机位 拿出一部分当子网位使用。
- CIDR 是什么？
CIDR = 无类别域间路由（Classless Inter-Domain Routing）
废除传统 A/B/C 类地址限制，用 前缀长度 表示子网掩码
表示形式：
IP地址/前缀位数例：192.168.1.0/24
/24等价于子网掩码：255.255.255.0作用：
更灵活地分配 IP，减少地址浪费
简化路由表，支持路由聚合
一句话总结
子网划分：把大网切小网，更高效安全。
CIDR ：用
/数字表示子网掩码，灵活分配 IP。
NAT 是什么、作用、优缺点
- NAT 是什么
网络地址转换（Network Address Translation） 路由器把内网私有 IP 与外网公网 IP 互相转换，实现内网设备访问互联网。
- 作用
缓解 IPv4 公网地址不足，多个内网设备共用一个公网 IP
隐藏内网拓扑，提高内网安全性
节省公网 IP 资源，降低成本
- 优点
节约公网 IPv4 地址
保护内网主机，外部无法直接访问
内网 IP 可自由规划，方便管理
- 缺点
某些 P2P、视频通话、游戏等端对端应用无法直接穿透
增加转发延迟
不支持端到端加密（IPSec 等受影响）
不利于服务器对外提供服务
一句话速记
NAT 实现内外网地址转换，节约公网 IP、隐藏内网；但影响 P2P，有转发损耗。
数据链路层作用
组帧 ：将网络层的 IP 数据包封装成帧，添加帧头帧尾，划分数据边界。
物理寻址 ：使用 MAC 地址 标识设备，实现局域网内节点通信。
差错检测 ：通过 CRC 等机制检测传输错误，保证帧正确。
流量控制：协调收发速率，防止接收方来不及处理。
访问控制：协调多个设备共享信道（如 CSMA/CD）。
一句话总结：在相邻节点间可靠传输帧，用 MAC 寻址，负责差错检测与信道控制。
MAC 地址
MAC 地址 是网卡的物理地址 / 硬件地址，全球唯一，用来标识网络设备。
特点
长度：48 位（6 字节）
表示：
XX:XX:XX:XX:XX:XX十六进制前 24 位：厂商编号（OUI）
后 24 位：设备序列号
工作在数据链路层
出厂固化在网卡，一般不可更改
作用
在局域网内实现设备之间的寻址与通信（IP 是逻辑地址，MAC 是物理身份）。
一句话速记：MAC 是网卡硬件地址，全球唯一，用于局域网寻址。
以太网帧结构
按顺序记：
前导码 + 帧开始定界符同步时钟，告诉接收方 "帧要来了"。
目的 MAC 地址（6 字节）接收设备的硬件地址。
源 MAC 地址（6 字节）发送设备的硬件地址。
类型 / 长度（2 字节）标识上层协议：
0x0800→ IPv4
0x0806→ ARP数据字段（46～1500 字节）IP 数据包，不足 46 字节要填充。
FCS 帧校验序列（4 字节）CRC 校验，用于检测传输错误。
极简记忆版
前导码 → 目的 MAC → 源 MAC → 类型 → 数据 → FCS
冲突域 vs 广播域
- 冲突域（Collision Domain）
范围：同一域内设备同时发送数据会产生冲突
特点：共享带宽，冲突会降低效率
设备影响：
集线器（Hub） 所有端口在同一个冲突域
交换机、路由器 每个端口是独立冲突域
一句话：会发生数据碰撞的范围 = 冲突域
- 广播域（Broadcast Domain）
范围：广播帧（广播包）能传到的所有设备范围
特点：广播会被域内所有设备接收
设备影响：
交换机 所有端口在同一个广播域
路由器 每个接口是独立广播域（隔离广播）
一句话：广播包能到达的范围 = 广播域
核心区别总结
冲突域 ：解决冲突，交换机可隔离
广播域 ：解决广播风暴，只有路由器能隔离
记忆口诀：冲突域交换机隔，广播域路由器隔。
交换机 vs 路由器
- 工作层次
交换机 ：工作在数据链路层（二层）
路由器 ：工作在网络层（三层）
- 寻址依据
交换机 ：基于 MAC 地址 转发
路由器 ：基于 IP 地址 转发
- 主要作用
交换机 ：连接局域网内设备，扩展接口，同一网段通信
路由器 ：连接不同网络，实现跨网段通信、寻址、选路
- 冲突域 / 广播域
交换机 ：隔离冲突域，不隔离广播域
路由器 ：隔离冲突域 + 广播域
- 其他功能
交换机：简单转发，无 NAT、无路由选择
路由器：路由选择、NAT、防火墙、DHCP 等
一句话记忆
交换机用 MAC 连内网，路由器用 IP 连外网；交换机隔冲突，路由器隔广播。
集线器、交换机、路由器分别工作在哪一层
集线器（Hub） ：物理层（第一层）
交换机（Switch） ：数据链路层（第二层）
路由器（Router） ：网络层（第三层）
一句话速记：集线一、交换二、路由三。
浏览器输入 URL 到页面显示全过程
按真实网络流程一步步走，条理清晰，直接背诵：
- 解析 URL
判断协议：
http/https/ftp域名：
www.xxx.com端口、路径、参数等
检查是否为非法地址、是否需要跳转
- 浏览器缓存查找
先查浏览器自身缓存（之前访问过的 DNS）
没有 → 查系统 hosts 文件
没有 → 发起 DNS 请求
DNS 域名解析（域名 → IP）
浏览器向本地 DNS 服务器发送查询请求
本地 DNS 查自己缓存，没有就向上级查
查根 DNS 服务器 → 顶级域名服务器（.com）
最终查到目标权威 DNS ，得到对应服务器 IP
DNS 结果返回给浏览器
封装 HTTP/HTTPS 请求
构造请求行、请求头、请求体
如果是 HTTPS：
发起 TLS 握手
协商加密套件、交换密钥、验证证书
建立加密通道
操作系统协议栈封装
应用层：HTTP/HTTPS 报文
传输层：加上 TCP 头（源端口、目标端口）
网络层：加上 IP 头（源 IP、目标 IP）
数据链路层：加上 MAC 头（源 MAC、网关 MAC）
物理层：转为比特流传输
建立 TCP 连接（三次握手）
浏览器 → 服务器：SYN
服务器 → 浏览器：SYN+ACK
浏览器 → 服务器：ACK连接建立，开始传输数据。
数据在网络中传输
数据包经过交换机、路由器、网关
路由器根据目标 IP 进行路由选择
经过多层转发到达目标服务器
- 服务器处理请求
服务器端口（80/443）接收请求
Nginx/Apache 转发请求到后端服务
后端处理业务、查询数据库
生成响应数据（HTML/CSS/JS/JSON）
- 服务器返回响应
状态码：200/301/302/404/500 等
响应头 + 响应体
沿原网络路径返回客户端
TCP 断开连接（四次挥手）
浏览器 → 服务器：FIN
服务器 → 浏览器：ACK
服务器 → 浏览器：FIN
浏览器 → 服务器：ACK连接关闭
浏览器解析渲染页面
解析 HTML → 生成 DOM 树
解析 CSS → 生成 CSSOM 树
合并为 渲染树（Render Tree）
布局（Layout）：计算位置大小
绘制（Paint）：像素绘制
加载 JS、图片、字体等资源
页面最终展示
极简流程口诀
URL 解析 → 查缓存 → DNS 查 IP → HTTPS 握手 → TCP 三次握手 → 发包路由转发 → 服务器处理 → 响应返回 → TCP 四次挥手 → 浏览器渲染显示
HTTPS 建立连接完整流程
- 客户端 → 服务端：Client Hello
支持的 TLS 版本
客户端随机数 Random_C
支持的加密套件列表（Cipher Suite）
会话 ID（用于会话复用）
- 服务端 → 客户端：Server Hello
选定 TLS 版本
服务端随机数 Random_S
选定一个加密套件
会话 ID
- 服务端 → 客户端：发送证书
发送服务器数字证书（包含公钥、域名、颁发机构等）
客户端会验证证书合法性（有效期、域名、CA 签名）
4.（可选）Server Key Exchange
- 如使用 DHE/ECDHE 算法，会发送密钥交换参数
- 服务端 → 客户端：Server Hello Done
- 表示服务端握手消息结束，等待客户端回复
- 客户端验证证书
验证证书是否被信任 CA 签发
检查域名、有效期、是否吊销
验证通过则取出服务器公钥
- 客户端 → 服务端：Client Key Exchange
生成预主密钥 Pre-Master Secret
用服务器公钥加密后发送给服务端
- 双方生成会话密钥
客户端与服务端各自通过：
Random_C
Random_S
Pre-Master Secret
使用相同算法算出：
主密钥 Master Secret
最终生成对称加密密钥（用于后续数据加密）
- 客户端 → 服务端：Change Cipher Spec
- 通知服务端：后续消息将加密传输
- 客户端 → 服务端：Encrypted Handshake Message
- 发送加密的握手结束消息，验证加密通道是否正常
- 服务端 → 客户端：Change Cipher Spec
- 通知客户端：我也开始加密
- 服务端 → 客户端：Encrypted Handshake Message
- 握手完成，开始正式传输 HTTP 数据
极简总结（背诵版）
双方 Hello 交换随机数、加密套件
服务器发证书，客户端验证书取公钥
客户端加密发送预主密钥
双方算出相同对称密钥
切换加密模式，开始安全传输
一句话：HTTPS = TCP 三次握手 + TLS 握手，用非对称加密交换密钥，对称加密传输数据。
TCP 如何保证可靠传输
TCP 依靠以下核心机制实现可靠、有序、无重复、无丢失的数据传输：
- 面向连接
传输前必须通过三次握手建立连接
传输后通过四次挥手正常断开
确保双方状态同步，才开始传输数据
- 序列号 + 确认应答（ACK）
每个字节数据都有唯一序列号（Seq）
接收方收到后返回确认号（ACK），表示收到哪一段数据
发送方知道数据已被正确接收
- 超时重传
发送方发出数据后启动定时器
若超时未收到 ACK ，认为数据丢失，自动重传
- 流量控制（滑动窗口）
接收方在 ACK 中告知自己接收窗口大小
发送方根据窗口控制发送速率
防止发送过快导致接收方处理不过来
- 拥塞控制
网络拥堵时降低发送速率，避免大量丢包
包含：慢启动、拥塞避免、快重传、快恢复
- 差错校验
每个报文段有校验和
接收方检测到错误直接丢弃，等待重传
- 去重与排序
依靠序列号对数据重新排序
重复的报文段直接丢弃，保证数据唯一
- 面向字节流
- 数据以字节流形式传输，边界清晰，不丢失不混乱
极简背诵版
TCP 靠：连接建立、序列号 + ACK、超时重传、滑动窗口、拥塞控制、校验和、排序去重，保证可靠传输。
拥塞控制 vs 流量控制
- 流量控制（Flow Control）
解决问题 ：发送方发太快，接收方处理不过来
作用范围 ：端到端（只在发送方和接收方之间）
实现方式 ：接收方在 ACK 中告诉发送方自己的窗口大小（rwnd）
核心目的：不让接收方溢出
一句话：你收不收得完？我慢点发。
- 拥塞控制（Congestion Control）
解决问题 ：网络本身拥堵，路由器扛不住，大量丢包
作用范围 ：整个网络（关注链路、路由器状况）
实现方式：发送方通过丢包、延迟等感知网络状况，用 ** 拥塞窗口（cwnd）** 控制速率
核心目的：不让网络崩溃
一句话：网络堵不堵？我慢点发。
核心区别总结
流量控制 ：点对点，防止接收方溢出
拥塞控制 ：全局，防止网络拥堵
共同配合：发送窗口 = min (rwnd, cwnd)
极简口诀
流量控制管接收方，拥塞控制管整个网。
大量 TIME_WAIT / CLOSE_WAIT 原因
一、大量 TIME_WAIT
- 出现在谁身上？
主动关闭连接的一方（通常是客户端、Nginx、Tomcat）
- 产生原因
主动调用
close()发送 FIN，收到对方 FIN 并 ACK 后进入持续时间：2MSL（一般 30s~2min）
本质：防止最后一个 ACK 丢包，让旧报文在网络中自然消失
- 为什么会大量出现？
短连接并发极高（大量 HTTP 请求、频繁新建 + 关闭连接）
服务端主动断开连接（如 Nginx 后端回收连接）
单机并发连接数巨大，关闭后堆积
- 危害
- 占用大量端口、内存，导致无法新建连接
- 解决
开启
tcp_tw_reuse、tcp_timestamps调小
tcp_fin_timeout改用长连接（HTTP keep-alive）
二、大量 CLOSE_WAIT
- 出现在谁身上？
被动关闭方（收到对方 FIN，但自己没调用 close）
- 产生原因
对方已经关闭连接（发了 FIN）
本方应用程序没有及时关闭 socket
代码问题：没读到 EOF、死循环、线程阻塞、逻辑漏写 close
一句话：对方走了，你还拿着连接不放手。
- 典型场景
后端服务业务逻辑阻塞
线程池满，无法处理关闭
代码 bug：读完数据忘记
close()Tomcat/Nginx 后端应用没正确处理连接关闭
- 危害
占用文件描述符（fd），最终导致 "too many open files" 无法建立新连接
- 解决
查代码：确保异常 / 读完后一定
close()检查线程池、超时设置
抓包 / 看日志定位哪里没关闭连接
一句话区分
TIME_WAIT 多 = 正常但并发太高
CLOSE_WAIT 多 = 代码 / 应用没关连接，基本是 bug
DDoS 攻击
- 定义
DDoS = 分布式拒绝服务攻击 攻击者控制大量傀儡机（肉鸡） ，同时向目标服务器发送海量请求，耗尽服务器资源，导致正常用户无法访问。
- 核心原理
利用分布式节点发起攻击，流量巨大，难以防御
目标：占满带宽、CPU、内存、连接数，使服务瘫痪
- 常见类型
流量型：占满带宽（UDP 洪水、ICMP 洪水）
协议型：耗尽连接资源（SYN 洪水）
应用层：模拟正常请求耗尽服务（HTTP 洪水、CC 攻击）
- 与 DoS 的区别
DoS：单台机器攻击，流量小
DDoS：多台机器协同攻击，流量极大，难防御
一句话总结
控制大量机器同时发起请求，耗尽服务器资源，让服务瘫痪无法响应正常用户
HTTP 长连接 vs 短连接
- 短连接（HTTP/1.0 默认）
流程：请求 → 建立 TCP 连接 → 传输 → 立即关闭
每发起一个 HTTP 请求，就新建一次 TCP 三次握手、四次挥手
特点：
连接用完就关
开销大、延迟高
高并发下容易产生大量 TIME_WAIT
- 长连接（HTTP/1.1 默认，Keep-Alive）
流程：建立一次 TCP 连接 → 连续传输多个 HTTP 请求 / 响应 → 超时再关闭
通过请求头
Connection: keep-alive实现特点：
复用 TCP 连接
减少握手挥手开销，延迟更低
减轻服务器压力
- 核心区别
短连接：一请求一连接，开销大
长连接：多请求复用一个连接，高效
- 适用场景
短连接：并发极低、一次性请求
长连接：高并发、Web 网站、API 接口、移动端请求
一句话速记
短连接：一次请求一次 TCP；长连接：多次请求复用一个 TCP。
跨域、原因、解决方案
- 什么是跨域？
浏览器出于安全，限制一个源的 JS 去访问另一个源 的资源，只要协议、域名、端口任意一个不同，就是跨域。
- 为什么会跨域？
浏览器 ** 同源策略（Same-Origin Policy）** 限制：
防止恶意网站窃取 Cookie、 localStorage、发送伪造请求
只限制 AJAX/fetch ，不限制
<script>、<img>、<link>等标签
- 如何解决跨域？（最常用）
① CORS（后端配置，最标准）
服务端设置响应头：
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers② 代理服务器（开发最常用）
Webpack DevServer proxy
Nginx 反向代理原理：浏览器请求同域代理 → 代理转发跨域请求，浏览器不限制后端之间请求。
③ JSONP（老方案，仅支持 GET）
利用
<script src>不受跨域限制，后端返回函数调用。④ Nginx 配置跨域
通过 Nginx 统一入口，转发不同服务，让浏览器看起来是同源。
⑤ postMessage
iframe / 多窗口之间跨域通信。
极简背诵版
跨域 = 协议 / 域名 / 端口不一致，受浏览器同源策略限制。 解决：CORS、代理、JSONP、Nginx、postMessage。