第3章 数据安全设计和负载均衡设计

本课程对应[日]宫田宽士《图解服务器端网络架构》，曾薇薇译、乌尼日其其格审校，人民邮电出版社/图灵教育，2015年4月第1版第1次印刷，376页、478千字、16开，ISBN 9787115388179；原书ISBN 9784797373516。图灵官方资料标明467张图表，官方试读PDF包含CIP、版次页和完整目录。首版正式结构为第0章加第1至5章，共171个目录节点；课程不会用2024年第2版、云原生、Service Mesh或现代API网关替换原书内容。

从一条可证伪的通信流开始

先预测：只开一个宽泛端口或只看负载均衡VIP可达，会遗漏动态端口、SSL处理、DNS TCP/UDP差异、健康检查与回程NAT状态。把预测写成“需求、正常路径、状态/表项、单故障路径、告警与恢复”五列，再接线、配置或测试。若结果与预测不同，先修正设计模型，不要把现场补丁当作架构成立。

本章的主问题是：从TCP/UDP与端口进入防火墙、目的NAT和健康检查，再用HTTP、SSL、FTP、DNS理解应用通信并完成纵深防御与负载均衡设计。每个箭头要注明源/目的、接口、VLAN、地址、协议端口和设备责任；每个冗余结论要说明丢失哪个故障域、剩余容量和状态如何接管。

验收不变量是：每条允许流和负载均衡虚拟服务都写明五元组、连接状态、地址转换、应用协议、健康判据、返回路径与最小权限。单次ping成功、设备状态为up或拓扑图看似对称，都不能单独证明业务双向通信、容量、故障切换和恢复成立。

核心词汇与首版边界

五元组、状态检测、目的NAT、健康检查、纵深防御

这些词汇固定在2015年首版语境。第2版新增或更新的技术、云上托管网络、容器网络和Service Mesh可以另行比较，但不改变本页目录分母。

核心机制深读

传输层把进程与连接状态带入设计

端口区分同一主机上的服务进程，TCP用握手、序列、确认、窗口和结束维护可靠连接，UDP不维护连接。MTU限制IP包，MSS限制TCP数据部分；错误的MTU/MSS会造成分片或黑洞。

动手试：先写预期拓扑、通信流、接口/状态表变化和告警，再执行一次正常验证与一次单故障验证。若结果不同，修正设计规则而不是只改现场配置。

防火墙规则从通信矩阵产生

包过滤逐包匹配地址、端口和协议；状态检测还确认报文属于合法连接。规则应从源区到目的区列最小允许流、方向、理由和责任人，并在末尾拒绝未声明通信。

负载均衡是地址转换加服务状态

客户端访问VIP，负载均衡器选择后端并做目的NAT，必要时也改写源地址保证回程。健康检查必须验证业务所需层次；只连通TCP端口可能无法发现应用已经返回错误。

应用协议会改变端口与状态设计

HTTP/1.1持久连接影响并发状态；SSL增加握手、证书和加密负载；FTP控制连接会协商主动或被动数据端口；DNS通常UDP查询但区域传输使用TCP。防火墙和LB不能只背默认端口。

安全与均衡设计都要最小化

先整理真正必要的业务、管理和监控流，再分层过滤并关闭默认服务。负载均衡只启用有明确需求的会话保持、SSL卸载、内容切换等功能，记录容量代价和故障降级行为。

原书目录核对清单

本页承担39个目录或复习节点，正文、图解、实验和题目必须能反向定位每一项：

• 3.1 传输层的技术
• 3.1.1 通过端口号划分服务器进程
• 3.1.1.1 传输层使用TCP和UDP两种协议
• 3.1.1.2 TCP的工作原理比较复杂
• 3.1.1.3 MTU和MSS的差异在于对象层不同
• 3.1.2 用防火墙守卫系统
• 3.1.2.1 基于连接进行控制
• 3.1.2.2 状态检测和包过滤之间的区别
• 3.1.2.3 防火墙在不断进步
• 3.1.3 通过负载均衡器分散服务器的负荷
• 3.1.3.1 目的NAT是服务器负载均衡技术的基础
• 3.1.3.2 通过健康检查监控服务器的状态
• 3.1.3.3 熟练掌握可选功能
• 3.2 从会话层到应用层的技术
• 3.2.1 HTTP支撑着互联网
• 3.2.1.1 HTTP/1.0和HTTP/1.1的TCP连接用法大相径庭
• 3.2.1.2 HTTP因请求和响应而得以成立
• 3.2.2 用SSL保护数据
• 3.2.2.1 防止窃听、篡改和冒充
• 3.2.2.2 通过SSL可以给各种各样的应用程序协议加密
• 3.2.2.3 SSL使用混合加密方式进行加密
• 3.2.2.4 消息摘要是消息的概要
• 3.2.2.5 SSL中执行着大量的处理
• 3.2.2.6 用客户端证书对客户端进行认证
• 3.2.3 用FTP传输文件
• 3.2.3.1 主动模式使用特定的端口
• 3.2.3.2 被动模式改变使用的端口
• 3.2.3.3 FTP就应该当作FTP去处理
• 3.2.4 用DNS解析名称
• 3.2.4.1 用UDP进行名称解析
• 3.2.4.2 用TCP进行区域传输
• 3.3 数据安全设计与负载均衡设计
• 3.3.1 数据安全设计
• 3.3.1.1 整理出真正需要的通信
• 3.3.1.2 通过多级防御提高安全系数
• 3.3.1.3 默认启动的服务应控制在最小范围内
• 3.3.2 负载均衡设计
• 3.3.2.1 要高效地均衡负载
• 3.3.2.2 启用哪些可选功能

可复现实验

src zone/IP:port -> firewall state -> VIP:port -> DNAT -> real server:port -> return state

health: TCP connect != HTTP 200 != application transaction
choose the shallowest check that still proves service readiness

FTP active: server:20 -> client negotiated port
FTP passive: client -> server negotiated high port
DNS query: UDP/53; zone transfer: TCP/53

独立证据门

第3章 数据安全设计和负载均衡设计 的最小证据包包含：首版节点、需求编号、物理/逻辑拓扑、端口/VLAN/IP/路由/NAT/策略表、正反向通信流、容量与单故障、监控日志、恢复步骤、偏差、责任人与复核人。

练习

本章回顾

“第3章 数据安全设计和负载均衡设计”的核心是从TCP/UDP与端口进入防火墙、目的NAT和健康检查，再用HTTP、SSL、FTP、DNS理解应用通信并完成纵深防御与负载均衡设计。真正掌握不是背设备名，而是把需求、责任层、通信流、状态、容量、故障、监控和恢复连成可施工且可证伪的闭环。

← 上一页：第2章 逻辑设计 · 下一页：第4章 高可用性设计 →

原版目录概念补充核对

以下条目补齐官方目录中容易被示例主线掩盖的概念。它们不重复罗列目录，而是明确每项概念的机制、适用边界和验收证据。

3.1.1 通过端口号划分服务器进程：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.1 通过端口号划分服务器进程属于可施工的物理约束，介质、距离、速率/双工、连接器、端口容量、供电与散热要按完整链路核对。验证时把两端规格和余量写入端口表，再用错误计数、光功率或负载测试确认最弱一段仍满足峰值与单故障条件。

3.1.1.1 传输层使用TCP和UDP两种协议：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.1.1 传输层使用TCP和UDP两种协议需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.1.1.2 TCP的工作原理比较复杂：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.1.2 TCP的工作原理比较复杂需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.1.1.3 MTU和MSS的差异在于对象层不同：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.1.3 MTU和MSS的差异在于对象层不同需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.1.2 用防火墙守卫系统：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.2 用防火墙守卫系统同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.1.2.1 基于连接进行控制：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.2.1 基于连接进行控制属于可施工的物理约束，介质、距离、速率/双工、连接器、端口容量、供电与散热要按完整链路核对。验证时把两端规格和余量写入端口表，再用错误计数、光功率或负载测试确认最弱一段仍满足峰值与单故障条件。

3.1.2.2 状态检测和包过滤之间的区别：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.2.2 状态检测和包过滤之间的区别需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.1.2.3 防火墙在不断进步：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.2.3 防火墙在不断进步同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.1.3 通过负载均衡器分散服务器的负荷：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.3 通过负载均衡器分散服务器的负荷同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.1.3.1 目的NAT是服务器负载均衡技术的基础：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.3.1 目的NAT是服务器负载均衡技术的基础决定报文在二层广播域、三层前缀和地址转换之间如何选择路径。应同时记录正反向路由、ARP/邻居状态、策略与转换表，再从两个方向发起测试，避免单向可达掩盖返回路径或地址重叠问题。

3.1.3.2 通过健康检查监控服务器的状态：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.3.2 通过健康检查监控服务器的状态把运行状态转化为可诊断、可恢复的操作证据。指标、日志、配置版本、告警阈值和责任人要关联同一设备与时间线；通过制造一个已知故障验证告警能定位根因，恢复步骤能把配置和服务带回基线。

3.1.3.3 熟练掌握可选功能：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.1.3.3 熟练掌握可选功能需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2 从会话层到应用层的技术：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2 从会话层到应用层的技术同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.2.1 HTTP支撑着互联网：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.1 HTTP支撑着互联网需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.1.1 HTTP/1.0和HTTP/1.1的TCP连接用法大相径庭：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.1.1 HTTP/1.0和HTTP/1.1的TCP连接用法大相径庭属于可施工的物理约束，介质、距离、速率/双工、连接器、端口容量、供电与散热要按完整链路核对。验证时把两端规格和余量写入端口表，再用错误计数、光功率或负载测试确认最弱一段仍满足峰值与单故障条件。

3.2.1.2 HTTP因请求和响应而得以成立：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.1.2 HTTP因请求和响应而得以成立需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.2 用SSL保护数据：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2 用SSL保护数据同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.2.2.1 防止窃听、篡改和冒充：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2.1 防止窃听、篡改和冒充需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.2.2 通过SSL可以给各种各样的应用程序协议加密：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2.2 通过SSL可以给各种各样的应用程序协议加密同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.2.2.3 SSL使用混合加密方式进行加密：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2.3 SSL使用混合加密方式进行加密同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.2.2.4 消息摘要是消息的概要：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2.4 消息摘要是消息的概要需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.2.5 SSL中执行着大量的处理：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2.5 SSL中执行着大量的处理同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.2.2.6 用客户端证书对客户端进行认证：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.2.6 用客户端证书对客户端进行认证同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.2.3 用FTP传输文件：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.3 用FTP传输文件需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.3.1 主动模式使用特定的端口：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.3.1 主动模式使用特定的端口属于可施工的物理约束，介质、距离、速率/双工、连接器、端口容量、供电与散热要按完整链路核对。验证时把两端规格和余量写入端口表，再用错误计数、光功率或负载测试确认最弱一段仍满足峰值与单故障条件。

3.2.3.2 被动模式改变使用的端口：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.3.2 被动模式改变使用的端口属于可施工的物理约束，介质、距离、速率/双工、连接器、端口容量、供电与散热要按完整链路核对。验证时把两端规格和余量写入端口表，再用错误计数、光功率或负载测试确认最弱一段仍满足峰值与单故障条件。

3.2.3.3 FTP就应该当作FTP去处理：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.3.3 FTP就应该当作FTP去处理需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.4 用DNS解析名称：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.4 用DNS解析名称决定报文在二层广播域、三层前缀和地址转换之间如何选择路径。应同时记录正反向路由、ARP/邻居状态、策略与转换表，再从两个方向发起测试，避免单向可达掩盖返回路径或地址重叠问题。

3.2.4.1 用UDP进行名称解析：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.4.1 用UDP进行名称解析需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.2.4.2 用TCP进行区域传输：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.2.4.2 用TCP进行区域传输需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.3 数据安全设计与负载均衡设计：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3 数据安全设计与负载均衡设计同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.3.1 数据安全设计：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.1 数据安全设计同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.3.1.1 整理出真正需要的通信：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.1.1 整理出真正需要的通信需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.3.1.2 通过多级防御提高安全系数：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.1.2 通过多级防御提高安全系数同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.3.1.3 默认启动的服务应控制在最小范围内：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.1.3 默认启动的服务应控制在最小范围内需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。

3.3.2 负载均衡设计：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.2 负载均衡设计同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.3.2.1 要高效地均衡负载：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.2.1 要高效地均衡负载同时影响允许哪些流量以及请求如何分配，规则顺序、会话保持、健康检查和返回路径必须形成闭环。用允许、拒绝、节点摘除和会话续接四类样本核对策略命中、后端选择、连接表与客户端结果。

3.3.2.2 启用哪些可选功能：机制、边界与证据

第3章 数据安全设计和负载均衡设计中的3.3.2.2 启用哪些可选功能需要落到明确的流量路径、责任设备和状态表，而不能停留在设备名称。画出正常与单故障路径，固定输入后只改变一个链路、表项或容量条件，再以双向抓包、设备状态、告警和恢复结果核对设计。