四层与七层流量防护的适用业务比较，关键不在“哪一层更高级”，而在攻击发生的位置和业务需要识别的内容。四层防护主要应对网络连接与传输层流量冲击；七层防护则检查 HTTP、HTTPS 请求及其应用特征。若入口可能同时遭遇大流量冲击和恶意请求，通常要分层部署，而不是只选一种。
两种防护分别能看见什么
四层：先处理连接与流量
四层防护关注源地址、端口、连接状态、流量速率等信息，常见作用是过滤异常连接、限制连接速率，并在流量到达应用服务器前进行清洗或转发。它适合应对带宽或连接资源受到挤压的情况，也适用于不使用 HTTP 的业务，例如部分游戏通信、邮件传输或自定义协议服务。
它的优势是离业务内容较远，能在请求进入应用之前处理流量，适用协议较广；不足是通常看不到具体页面、查询参数或用户操作，难以判断一条格式正常的请求是不是在滥用某项功能。四层防护也不能替代上游网络的承载能力：若入口链路已经拥塞，仍需由具备相应清洗能力的网络侧协同处理。
七层：辨认请求意图与应用行为
七层防护能够依据 HTTP 方法、URL 路径、请求头和请求频率等特征制定规则。针对登录接口反复尝试、搜索接口被高频调用，或某个商品查询功能遭自动化滥用，可结合 WAF、身份验证和限速规则处理。七层的长处是规则贴近业务，能对不同接口采取不同策略；代价是需要理解应用流量，规则配置、证书处理及误拦截排查也更复杂。
加密流量要进行七层检查，通常需要在受控入口终止 TLS 加密，再检查请求内容；具体能力取决于部署方式和服务配置。七层策略能识别应用层请求，却不意味着它能单独消化任意规模的网络流量冲击。
按业务风险选，不按名称猜
| 业务特征 | 优先考虑 | 主要原因与注意点 |
|---|---|---|
| 提供 HTTP 网站、公开查询或在线交易 | 七层为主，视入口风险叠加四层 | 可按登录、搜索、下单等路径区分规则；需要观察正常请求，避免误拦真实用户。 |
| 运行游戏通信、邮件或其他非 HTTP 服务 | 四层为主 | 防护重点是连接和流量特征；七层 HTTP 规则通常无法直接理解这类协议。 |
| 既有网站和 API，也有网络层流量风险 | 四层与七层协同 | 四层先做连接过滤，七层再处理应用请求；策略需分别核对，避免只保护网站而遗漏其他端口。 |
因此，四层与七层流量防护的适用业务比较应落实到协议、入口和风险上。API 即使没有网页界面，只要通过 HTTP 提供服务，也可能需要七层规则；反过来，网站部署了七层防护，也不代表其他非 HTTP 端口已受到保护。
落地前的检查步骤
- 列清入口：记录对外域名、端口、协议和对应服务，区分 HTTP 网站、API 与非 HTTP 服务。
- 确认主要风险：判断更担心链路流量、连接耗尽，还是登录、查询等应用功能被滥用；有多种风险时分别安排防护。
- 先观察再拦截：对七层规则先使用记录或告警模式，核对正常请求路径、调用频率和自动化客户端，再逐步启用阻断。
- 验证覆盖范围：从外部测试应保护的域名、端口和功能，并确认告警、日志、回滚及故障联系人可用。规则变更后复查正常访问。
常见问题
只部署七层防护够不够？
若业务只有 HTTP 服务且主要风险是应用请求滥用，七层可能是重点；若存在明显的连接或网络流量风险，还应评估四层及上游清洗能力。
四层防护能挡住恶意登录吗？
通常不能仅靠四层判断登录请求是否恶意。它可以限制连接或速率，但针对账号、接口和请求行为的控制更适合由七层策略及应用自身的认证措施承担。
两种防护一定要一起买或部署吗？
不一定。按协议和风险选取即可；只有当业务同时需要连接层过滤与应用层识别，或入口包含不同类型服务时，组合部署才更有针对性。
最后怎么做决定？
先列出每项业务的协议和端口，再判断风险发生在连接层还是请求层。四层与七层流量防护的适用业务比较得出的结论应对应具体入口：非 HTTP 服务优先评估四层，网站和 API 重点评估七层，两类风险并存时采用分层方案。