CDN回源用HTTPS和HTTP，对源站压力差多少

CDN接入后，用户请求先到边缘节点，边缘节点再去源站取数据。这里有一个容易被忽略的配置：CDN到源站这段，也就是回源链路，用HTTP还是HTTPS。

很多站点前端已经开了HTTPS，浏览器到CDN是HTTPS，但CDN回源仍然用HTTP。这样配置能跑，也省事，但安全性和链路一致性会差一些。反过来，如果CDN回源也改成HTTPS，源站就要处理TLS握手、证书、加解密，这部分确实会增加CPU开销。

实际使用中发现，HTTPS回源对源站性能的影响，不能只看“HTTPS比HTTP慢”这句话。真正影响大小的，是回源请求量、连接复用、响应体大小、TLS参数、源站CPU，以及CDN厂商的回源策略。

先看结论范围：大多数业务影响没有想象中夸张

在现代CPU支持AES-NI、Nginx/OpenResty配置正常、CDN开启回源KeepAlive的情况下，HTTPS回源相比HTTP回源，源站CPU通常增加5%到20%左右。这个区间在 Web 业务里比较常见。

如果是大量短连接、小包动态请求，比如每秒几千次回源，每个响应只有几KB，而且CDN没有很好复用连接，CPU涨幅可能到30%甚至更高。反过来，如果是图片、视频、安装包这类大文件回源，加密开销摊到传输过程中，差距往往很小，瓶颈更多在带宽、磁盘IO、源站上行。

HTTPS回源多出来的开销主要在TLS握手

HTTPS不是简单地把HTTP包套一层壳。CDN节点回源时，要和源站建立TLS连接，里面包括证书交换、密钥协商、加密算法确认等动作。这个过程最吃CPU的是非对称加密阶段，比如ECDHE、RSA签名验证这些。

连接建立完成后，后续数据传输主要使用对称加密，比如AES-GCM、ChaCha20-Poly1305。现代CPU对AES支持很好，单纯传输阶段的加密成本没有那么可怕。

所以这里有个很实战的判断：如果HTTPS回源慢，先看新建TLS连接数，而不是只看回源QPS。

例如回源QPS是1000，如果CDN和源站之间有KeepAlive，可能只有几十个长连接在复用，TLS握手开销很低。反过来，回源QPS也是1000，但每个请求都新建连接，那源站CPU会明显上去，Nginx的worker也会更忙。

一个压测口径下的参考数据

以下数据不是所有机器都一样，但可以帮助判断量级。测试口径按常见Nginx源站、8C CPU、OpenSSL 1.1.1+、开启AES-NI、响应体10KB、动态接口模拟。

这里最关键的差异不是HTTP和HTTPS本身，而是KeepAlive有没有生效。HTTPS短连接回源，会把TLS握手成本放大很多倍。

CDN命中率会改变这个问题的严重程度

很多人估算HTTPS回源压力时，会直接拿全站访问量算，这是不准的。源站只承接CDN未命中的请求、动态请求、刷新预热后的回源请求，以及一些绕过缓存的请求。

比如网站公网访问QPS是50000，CDN缓存命中率是96%，那么真正回源QPS大约是2000。这个时候HTTPS回源即便让源站CPU增加15%，也未必是问题。

如果是动态站点，CDN只做加速不缓存，用户请求几乎全部回源，那HTTPS回源的开销就要认真算。尤其是登录、下单、支付、API网关这类接口，本身数据库和应用层已经比较重，再叠加TLS短连接，很容易让源站CPU曲线变得难看。

HTTP回源省性能，但安全边界要想清楚

HTTP回源的好处很直接：源站不用处理TLS，CPU省一点，配置简单，证书不用在源站维护。对于内网专线、同云厂商内网回源、源站和CDN节点之间链路可信的场景，HTTP回源确实很常见。

但如果CDN回源走公网，HTTP就有明显风险。用户到CDN是HTTPS，只能保证用户到边缘节点这一段安全；CDN到源站如果是HTTP，中间链路仍然是明文。Cookie、Authorization Header、业务参数、源站返回内容，都可能暴露在回源链路上。

这里补充一点，有些人觉得“源站IP没公开就安全”。实际情况没这么理想。源站IP可能从DNS历史记录、邮件头、业务回调、证书透明日志、旁路扫描里被发现。HTTP回源一旦暴露源站链路，风险不是只有被窃听，还包括被篡改。

HTTPS回源还有一个价值：链路行为更一致

线上排障时，HTTP回源和HTTPS访问混用，经常会遇到一些奇怪问题。

比如源站应用根据协议生成跳转地址，用户访问https://www.example.com，CDN回源却用http://origin，应用没正确识别X-Forwarded-Proto，结果返回http链接，浏览器出现Mixed Content。再比如后端强制HTTPS跳转，CDN用HTTP回源，被301到HTTPS，CDN又重新请求，链路变复杂。

HTTPS回源能减少这类协议不一致问题。尤其是业务里有OAuth、支付回调、WebSocket、HSTS、Secure Cookie时，回源也使用HTTPS会更稳。

连接复用是HTTPS回源性能的关键

实际调优时，别一上来就换CPU、扩机器。先确认CDN到源站是否复用连接。

CDN控制台里通常会有“回源长连接”“Origin KeepAlive”“回源HTTP/2”之类配置。源站Nginx也要配合，比如keepalive_timeout不能太短，worker_connections不能太小，系统的somaxconn、nf_conntrack、端口范围也要够。

Nginx源站常见配置思路如下：

keepalive_timeout 60s 到 75s 比较常见；如果回源节点集中，可以适当拉长，但不要无限大，避免连接堆积。

ssl_session_cache 要开启，ssl_session_timeout 可以设置到10m或更长，让TLS Session Resumption生效。

优先用TLS 1.3。TLS 1.3握手更少，恢复连接更快，对短连接场景帮助明显。

证书尽量使用ECDSA或RSA 2048。RSA 4096安全性更高，但握手CPU更重，普通Web业务没必要为了回源链路上RSA 4096。

一个容易踩的坑：CDN回源Host和证书不匹配

HTTPS回源时，CDN会校验证书域名。源站证书如果只签了www.example.com，但CDN回源Host写成origin.example.com，就可能出现证书校验失败。

有些CDN允许关闭证书校验，但不推荐长期这么做。关闭校验后，HTTPS只剩加密，身份认证弱了很多。更合理的做法是给源站配置匹配的证书，或者在CDN里正确设置SNI和回源Host。

小包动态请求，HTTPS回源影响最明显

小包动态请求有个特点：响应体小，业务处理时间短，连接和握手成本占比高。

举个实际口径：一个接口响应体只有2KB，应用处理耗时5ms，HTTP回源时Nginx转发和连接处理占用很低；改成HTTPS回源后，如果连接复用不好，TLS握手可能比业务处理还显眼。CPU曲线会从应用进程转移一部分到Nginx/OpenSSL。

这种场景下，优化优先级一般是：回源KeepAlive、TLS Session Resumption、TLS 1.3、减少不必要回源、接口缓存、合并请求。不是简单地把HTTPS关掉。

大文件回源，别把问题误判成HTTPS

图片、视频、压缩包这类大文件，HTTPS加密当然有开销，但大多数时候更先撞到的是带宽和磁盘。

比如源站上行只有40Mbps，CDN回源拉一个500MB文件，HTTP和HTTPS差距不会是主要矛盾。源站网卡、磁盘读取、TCP拥塞、跨境链路质量，都会比TLS更影响速度。

如果业务是下载站、素材站、游戏补丁分发，源站选择比纠结HTTP/HTTPS更重要。需要大带宽或精品线路时，可以看129云的香港大宽带-A型，500Mbps峰值、500GB流量，适合做海外访问或跨境分发源站；如果是需要回国质量，美国精品网-E型走CMIN2，适合对国内访问稳定性要求高的业务。采购前可以直接打客服热线400-9177118问线路和带宽细节，别只看标称峰值。

源站被攻击时，HTTPS回源会放大握手压力

DDoS和CC攻击场景要单独看。攻击如果打到CDN边缘，CDN能挡住大部分请求，源站压力不一定增加。但如果攻击绕过CDN直接打源站HTTPS端口，TLS握手会成为放大器。

HTTP被打，主要消耗连接、带宽、应用资源；HTTPS被打，攻击者只要不断发起握手，就能让源站CPU消耗得更快。尤其是没有限速、没有源站防火墙、没有只允许CDN回源IP访问的机器，很容易被拖死。

实战里源站应该做两件事：只放行CDN回源IP，源站真实IP不要暴露；如果业务本身容易被打，源站用高防机器或高防IP承接。比如游戏、活动页、金融营销页这类流量波动大、攻击概率高的业务，可以看129云宁波高防-E型，100Gbps防御，16C 16G配置，适合放在CDN后面做源站或业务入口。

HTTPS回源延迟增加多少

延迟要分新连接和复用连接。

新建HTTPS回源连接时，TLS握手会多出1到2个RTT。TLS 1.2通常更明显，TLS 1.3会好一些。如果CDN节点到源站RTT是20ms，新连接可能多几十毫秒；如果跨境回源RTT是150ms，新连接多出来的感知就很明显。

连接复用后，单次请求延迟差距很小，通常在1ms到几ms级别，更多取决于源站处理能力和网络质量。

所以跨境回源一定要重视长连接。跨境链路上每新建一次TLS连接，代价都比内地同区域大很多。BGP、CN2、GIA、CMIN2这类线路质量，会直接影响回源稳定性。

源站CPU怎么估算

粗略估算可以按两个维度看：回源QPS和TLS新建连接数。

如果回源QPS 2000，但TLS新建连接每秒只有20到50个，HTTPS回源的额外CPU通常不高。8C到16C的源站，只要应用本身不重，一般能扛。

如果回源QPS 2000，TLS新建连接也接近2000，那就很危险。即使每个请求很小，CPU也会被握手打满。这个时候扩容一台机器可能能缓解，但配置问题不改，流量再涨还会出事。

可以在源站观察这些指标：Nginx active connections、握手失败数、CPU sys/user占比、OpenSSL相关消耗、TIME_WAIT数量、443端口新建连接速率、CDN回源状态码分布。

如果看到CPU user升高明显，Nginx worker吃CPU，443新建连接速率很高，基本就能判断HTTPS握手参与了压力增长。

HTTP/2回源不一定总是更快

有些CDN支持HTTP/2回源。HTTP/2的多路复用可以减少连接数量，对HTTPS回源有帮助。但实际使用中也见过HTTP/2回源导致源站排障变复杂，尤其是老版本Nginx、应用网关、gRPC混用时。

普通Web静态资源，HTTP/1.1 KeepAlive已经够用。大量小请求、接口聚合、gRPC业务，可以考虑HTTP/2回源。关键还是压测，不要看到HTTP/2就直接打开全站。

哪些场景适合HTTP回源

源站和CDN在同一个云厂商内网，回源走内网地址，链路不出公网，HTTP回源可以接受。

纯静态资源，没有敏感Header，没有Cookie，没有用户私密数据，并且源站访问控制做得好，HTTP回源也常见。

临时迁移、证书还没准备好、业务需要快速接入CDN时，可以先用HTTP回源跑起来，但后面要安排切到HTTPS。这个过程别拖太久，很多安全问题都是临时配置变成长期配置。

哪些场景更应该HTTPS回源

登录态业务、管理后台、支付、订单、用户中心、API接口，建议HTTPS回源。这里传的不只是页面，还有Cookie、Token、手机号、订单号、内部接口参数。

跨境回源、跨运营商公网回源，也建议HTTPS。公网链路越长，中间不可控因素越多。

对合规有要求的业务，比如金融、医疗、企业SaaS，HTTPS回源基本是常规配置，不要为了省一点CPU让链路中间变成明文。

线上切换HTTPS回源时怎么做更稳

先在源站配置证书，确保证书链完整。用openssl s_client或curl验证SNI、Host、证书有效期、协议版本。

再在CDN里开一个测试域名或灰度回源规则，不要直接全量切主域名。观察源站CPU、443连接数、5xx、回源耗时。小流量跑半小时到几小时，基本能看出趋势。

然后打开回源KeepAlive，确认CDN没有对每个请求都新建连接。有些CDN控制台默认值比较保守，需要手动调。

切换后保留HTTP监听一段时间，用来处理回滚或兼容旧配置，但源站防火墙要限制来源，只允许CDN回源IP访问。不要让公网用户直接访问源站HTTP端口。

实际选择时可以按这个口径判断

如果CDN命中率高、源站回源少，HTTPS回源带来的性能影响通常很小，优先选HTTPS。

如果动态请求多，回源QPS高，先确认CDN长连接和TLS恢复能力，再决定源站规格。不要只按HTTP压测数据买机器。

如果源站上行带宽小、跨境链路差，大文件业务的主要问题不是HTTPS，而是线路和带宽。可以根据访问地区选更合适的BGP、CN2、GIA、CMIN2线路。

如果业务容易被DDoS或CC攻击，HTTPS回源本身不是问题，源站暴露才是问题。源站只允许CDN回源IP访问，高防、WAF、限速、连接数控制要一起配。

压测时别只压首页。要压真实回源路径，包括缓存MISS、动态API、登录态接口、大文件、刷新预热后的源站承载。HTTP和HTTPS各跑一轮，看CPU、连接数、延迟、5xx，再决定是否需要扩容或调CDN回源参数。