SSL终端和平衡器

简短的摘要

SSL/TLS终端消除了应用程序中的加密负载，并打开了通往L7路由，WAF，rate-limit，mTLS和金丝雀版本的路径。关键解决方桉：在何处完成TLS （edge/ingress/mesh）、如何平衡（L4 vs L7）、使用哪些密码配置文件、如何更新非中心状态证书以及如何在SLO中保持p95潜伏和错误。

在何处完成TLS

边缘（CDN/Anycast/WAF）：用户的最低潜伏率，全局保护，kesh/bot控制。接下来是re-encrypt到后端。
在ingress L7 （Nginx/Envoy/HAProxy/ALB）：通过URI/标头、 mTLS、JWT验证进行精细路由。
端到端TLS （passthrough L4）：何时需要端到端mTLS到pod/服务（例如严格的合规区）。
服务Mesh （Envoy/Istio/Linkerd）：群集、策略和遥测中的自动mTLS。

练习：更常见的是-边缘终端→ re-encrypt到ingress；PII/付款-服务前的mTLS。

L4 vs L7平衡

L4 （TCP/UDP）：最小延迟、简单健康检查（端口/TSR）, passthrough TLS。适用于TLS上的gRPC，缺少L7-fich。
L7 （HTTP/HTTPS/HTTP3）：通过主机/路由/标题/Cookie、WAF、rate-limits、金丝雀发行版、粘贴会话、retrai/taymout进行路由。

TLS： 版本、密钥、密码

版本： TLS 1。3无处不在，TLS 1。2作为后卫。禁用1。0/1.1.

密钥：ECDSA （P-256）-比RSA更快；可以使用双堆栈（ECDSA+RSA）。
ALPN: `h2` и `http/1.1`;HTTP/3是"h3"（QUIC/UDP）。
OCSP Stapling：包括；HSTS在公共领域。
密钥池：存储在KMS/HSM中；自动扩展（ASME/信任树）。
0-RTT (TLS 1.3）：点启用（GET/偶数），考虑重播风险。

基本密码配置文件（TLS 1。2): `ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305`

TLS性能

Resumption： session tickets/ID-降低手摇成本。
ECDSA+ChaCha20在移动/非AES-NI上提供帮助。
OCSP Stapling+短链减少p95。
HTTP/2/3：多路复用，连接较少→低于p95。
Offload： pin CPU内核在crypto下,包括reuseport, tune socket缓冲区。

安全性

mTLS：需要adminok/API操作员的客户端证书；CRL/OCSP召回。
SNI/ECH：SNI是标准；ECH (Encr.ClientHello）隐藏域（如果支持edge提供程序）。
严格运输安全（HSTS）： prod域,起步时要小心。
hop-ami之间的TLS： re-encrypt到服务,甚至在DC （Zero-Trust）内。
Rate-limit/Grey-wols：在L7上保护api免受机器人/野蛮人的攻击。

可观察性和SLO

SLO（示例）

p95 TLS-handshake ≤ 80-120 ms（全球），p95 TTFB ≤ 200-300 ms。

TLS错误（手动/同行验证）≤ 0。1%.

回访的回程率≥ 70％。

度量标准

`handshake_time`, `tls_version`, `alpn`, `cert_expiry_days`, `ocsp_staple_status`.

L7: `p50/p95/p99`, `5xx`, `429`, `upstream_rq_time`, `retry_budget`.

能力：有源连接器，CPS（每秒连接），RPS。

典型的configi

Nginx (L7 terminate + HTTP/2 + OCSP stapling)

nginx server {
listen 443 ssl http2 reuseport;
server_name api.example.com;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:...:ECDHE-RSA-CHACHA20-POLY1305';
ssl_ecdh_curve X25519:P-256;
ssl_certificate   /etc/ssl/cert.pem;    # полная цепочка ssl_certificate_key /etc/ssl/key.pem;
ssl_stapling on; ssl_stapling_verify on;
ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_pass https://upstream_pool;
}
}

upstream upstream_pool {
zone backends 64k;
server 10.0.1.10:8443 max_fails=3 fail_timeout=10s;
server 10.0.1.11:8443 max_fails=3 fail_timeout=10s;
keepalive 256;
}

HAProxy（L7终端+stickiness+ mTLS到后端）

haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1 mode http http-response set-header Strict-Transport-Security max-age=31536000 default_backend be_api

backend be_api mode http balance roundrobin cookie SRV insert indirect nocache option httpchk GET /healthz server s1 10.0.1.10:8443 check ssl verify required ca-file /etc/haproxy/ca.pem server s2 10.0.1.11:8443 check ssl verify required ca-file /etc/haproxy/ca.pem

Envoy（来自客户+金丝雀的L7终端+mTLS）

yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress route_config:
virtual_hosts:
- name: api domains: ["api.example.com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- name: api-stable weight: 95
- name: api-canary weight: 5 http_filters:
- name: envoy.filters.http.router transport_socket:
name: envoy.transport_sockets.tls typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext common_tls_context:
tls_certificates:
- certificate_chain: { filename: "/etc/tls/cert.pem" }
private_key:   { filename: "/etc/tls/key.pem" }
validation_context:       # mTLS (опционально)
trusted_ca: { filename: "/etc/tls/ca.pem" }
require_client_certificate: true

AWS ALB/NLB（概念）

ALB (L7 terminate): HTTPS listener 443 (TLS 1.2/1.3), target group HTTPs:8443, health-check `/healthz`, stickiness (cookie).

NLB（L4 passthrough）：TLS listener 443，TCP健康检查，端到端SNI到pod。

CloudFront/Cloudflare： TLS边缘+WAF+博特管理；origin — HTTPS only.

无市区证书更新

ACME（Let's Encrypt/私人 CA）具有自动升级和热重新启动（Nginx "reload"，Envoy SDS）。
迁移时双证书（ECDSA+RSA）。
链控制：检查中间CA；轮换后的OCSP稳定。
Alerts： 'cert_expiry_days <21'和'ocsp_status!=good'。

健康检查和路由

L4: TCP connect, TLS handshake.

L7：HTTP 200/JSON标记版本，gRPC健康。
策略：failover, weighted, latency, consistent-hash （cookie/IP） for sticky。
Retrai/Taymauts：稳定性和重复查询之间的平衡（相等！）。

Kubernetes模式

Ingress控制器（Nginx/Envoy/HAProxy）：ingress终端，DNS记录的"ExternalDNS"，ACME的"证书管理器"。
网关API：带有金丝雀的声明性TLSRoute/HTTPRoute。
服务Mesh：自动mTLS pod↔pod，"PeerAuthentication"/"DestinationRule"级别的策略。

安全支票单

[] TLS 1.3包括在内；1.0/1.1个关闭。

现代密码；ECDSA在支持允许的地方。
OCSP stapling，完整的链，HSTS。
海军上将/互连的mTLS；重温客户服务。
边缘的极限/机器人过滤器；slowloris/oversized头保护。
Re-encrypt到后端（Zero-Trust）。
KMS/HSM中的秘密/密钥；发行轮换和审计。

可观察性和Alerta

Метрики: TLS handshakes/sec, failure rate, session resumption rate, OCSP, p95/99, open conns, CPS, RPS.

Logs：SNI/ALPN/TLS版本，cipher，客户端证书（适用于mTLS），上游代码，后期中断。
Alerts："5xx/525"的增长，恢复的下降，"cert_expiry_days"，"ocsp_failed"，超过p95，尖峰为"429"。

典型的错误

在没有保护的情况下终止边缘和HTTP平原。
CA链条过长→ p95手摇上升。
在客户端/浏览器上没有OCSP →锁定。
不考虑故障转移的sticky会话→降级节点上的"凹陷"。
0-RTT包括更改请求→重新提交风险。
在旋转时没有热转发硫磺→秒空。

iGaming/fintech的细节

高峰（锦标赛/比赛）：加热TLS会议（预连接），短链，高比例的恢复，HTTP/2/3前线。
支付网关/PSP： mTLS,严格的ciphers/version, pinned CA, 单独的域名/ALB有严格的规则。
Antifrod/bot过滤器：通过IP/ASN/device-fingerprint进行L7-rate-limit，在单独的域上使用金丝雀灰狼（挑战/帽子）。
监管：HSTS,可审计的TLS参数日志,版本报告,召回事件客户服务。

迷你花花公子

通过L7平衡器发布金丝雀

1.添加5％重量的"api-canary"集群；2）注意p95/错误；3) 5→25→50→100%;4）降解时自动转动。

证书紧急轮换

1.下载新的证书/密钥；2）"reload"不降低连接符（SDS/热替换）；3）OCSP验证；4）dashboard p95手推车。

包括HTTP/3

1.打开UDP/443；2）添加ALPN "h3"；3）单独的QUIC 失效/RTT度量；4）按客户比例划分的A/B。

结果

高效SSL终端是现代的TLS配置文件，正确的完成位置，智能的L7路由，可观察性和严格的安全性（mTLS，HSTS，re-encrypt）。在IaC中记录所有内容，自动轮换，测量p95/错误，并使用金丝雀-因此前线将超过峰值，并且可以预测地快速和安全。