CDN回源用HTTPS还是HTTP，对服务器压力差多少

CDN回源这件事，很多人一开始会把关注点放在“HTTPS肯定更耗性能”上。这个判断没错，但容易把问题想大。实际使用中发现，回源HTTPS和HTTP的压力差距，主要不在“传输内容加密”本身，而在TLS握手、连接复用、回源频率、文件大小、源站CPU型号这几个变量上。

如果CDN到源站之间长连接保持得好，HTTPS回源的额外压力通常不夸张；如果回源连接频繁创建、短连接多、小文件多、动态接口多，那HTTPS回源对源站CPU和连接处理能力的影响会明显放大。

先把链路拆开看

用户访问HTTPS网站时，链路通常是：用户浏览器 → CDN边缘节点 → 源站。

这里有两段连接：

用户到CDN：一般建议HTTPS，这段由CDN边缘节点负责TLS终止，证书也通常挂在CDN上。

CDN到源站：也就是回源，可以选择HTTP，也可以选择HTTPS。

很多站点开了HTTPS访问，但回源其实是HTTP。用户看到的仍然是HTTPS，因为用户和CDN之间是加密的。区别在于CDN去源站拿数据时，是否也走TLS加密。

所以问题不是“网站要不要HTTPS”，而是“CDN和源站之间要不要HTTPS”。

HTTP回源和HTTPS回源的压力差在哪里

HTTP回源少了TLS握手和加解密过程，源站只处理普通HTTP请求。HTTPS回源则多了证书协商、密钥交换、会话维护、数据加解密。

现代CPU有AES-NI，TLS对称加密的成本已经不算高。真正容易吃CPU的是握手，尤其是连接频繁新建的时候。

可以粗略按下面这个感觉理解：

场景：CDN与源站Keep-Alive正常，连接复用率高，HTTPS回源比HTTP回源多消耗约2%到10%的CPU，很多业务几乎感知不到。

场景：大量小文件、缓存命中率低、回源连接频繁创建，HTTPS回源可能多消耗15%到30%的CPU。

场景：动态API基本不缓存，QPS高，连接复用差，TLS握手很多，HTTPS回源的CPU压力可能比HTTP高30%到50%，极端情况下更高。

场景：大文件下载、视频分发，连接保持时间长，单连接传输数据多，HTTPS额外成本主要是加解密，通常不是瓶颈，瓶颈更可能在带宽、磁盘IO、源站出口。

拿一组接近生产环境的数据看

下面这组不是实验室跑分，是按常见Nginx源站、CDN回源、开启Keep-Alive后的经验区间来估。不同CPU、内核参数、TLS版本、CDN厂商连接池策略都会影响结果。

静态图片站：回源QPS 1000，平均文件80KB，CDN命中率95%。HTTP回源源站CPU约8%到12%，HTTPS回源约9%到14%。差距不大，因为真正打到源站的请求不多。

小文件下载站：回源QPS 3000，平均文件20KB，命中率70%，连接复用一般。HTTP回源CPU约25%到35%，HTTPS回源约35%到50%。这里HTTPS握手和短连接成本开始明显。

动态接口站：回源QPS 5000，接口不缓存，平均响应5KB。HTTP回源CPU约45%到60%，HTTPS回源约65%到85%。如果还有PHP、Java、Go业务逻辑，TLS只是压力的一部分，但会把CPU余量吃得更紧。

大文件分发：回源并发300，单文件100MB以上。HTTP回源CPU约10%到20%，HTTPS回源约12%到25%。差距有，但通常带宽先满。

这里补充一点：如果源站CPU比较老，没有AES-NI，或者虚拟化层性能比较差，HTTPS回源的成本会比上面更难看。现在很多云服务器用EPYC、Xeon新平台，TLS性能已经比以前好很多。

TLS握手为什么会把压力放大

HTTPS不是每个请求都重新做完整握手。正常情况下，CDN回源会维持连接池，多个请求复用同一批连接。这样TLS握手只发生在连接建立阶段，后面就是对称加密传输。

但实际生产里经常遇到这些情况：

源站Nginx的keepalive_timeout设得太短，连接刚建好没多久就断。

CDN节点分布多，每个节点都要和源站建连接，源站看到的连接数比预估高。

回源域名解析到多个源站IP，但负载均衡策略不稳定，连接复用效果差。

源站前面又套了一层SLB或WAF，TLS在多层之间反复终止和重建。

小文件或API请求特别多，每个请求处理时间短，握手成本占比反而变大。

多说一句，很多人压测HTTPS源站时，用ab或者wrk直接打源站，得出“HTTPS压力很大”的结论，但真实CDN回源未必是这样。因为CDN会复用连接，压测工具如果没开连接复用，测出来的更多是TLS握手极限，不是线上回源状态。

延迟差多少

HTTP回源没有TLS握手，连接建立后直接发请求。HTTPS回源要多一个TLS协商过程。

TLS 1.2完整握手通常多1到2个RTT，TLS 1.3完整握手通常多1个RTT，会话复用可以进一步降低。问题是，CDN到源站如果跨境，RTT本来就高。

比如CDN节点在中国大陆，源站在香港，RTT可能在20ms到50ms。HTTPS回源如果没有复用连接，首个请求可能多出20ms到100ms。

如果源站在美国西海岸，RTT可能在130ms到180ms。TLS握手没复用时，首包时间会更明显。跨境业务里，HTTPS回源带来的延迟问题，有时比CPU问题更容易被用户感知。

但只要CDN和源站之间Keep-Alive稳定，后续请求不会每次都付这个握手延迟。线上看到的平均延迟差距可能只有几毫秒到十几毫秒。

安全角度不能只看CPU

HTTP回源性能更轻，但CDN到源站之间是明文。如果CDN和源站在同一个内网、同一家云厂商专线、或者通过私有网络回源，HTTP问题不大。

如果CDN到源站走公网，尤其是跨境公网，HTTP回源会暴露请求路径、Header、Cookie、URL参数、接口返回内容。对于登录态、支付、后台接口、用户资料这类业务，不建议HTTP回源。

有些站点会说“源站只允许CDN IP访问，所以HTTP回源也安全”。IP白名单确实能减少绕过CDN直打源站的问题，但它解决的是访问控制，不解决链路明文传输。

实际使用中，比较常见的做法是：静态资源HTTP回源，动态业务HTTPS回源。图片、CSS、JS、下载文件不带敏感信息，HTTP回源可以省一点源站压力；API、后台、账号系统、订单系统走HTTPS回源。

CDN缓存命中率比回源协议更关键

很多源站压力大，不是因为HTTPS回源，而是CDN命中率太低。

比如一个图片站，日访问量很高，但缓存命中率99%，源站压力可能很轻。反过来，一个动态站点，CDN只是做转发，命中率10%以下，那HTTP回源也扛不住太多请求。

看回源压力时，建议盯这几个指标：回源QPS、回源带宽、回源连接数、源站CPU、TLS握手次数、5xx比例、CDN命中率。

如果只看源站CPU，很容易误判。CPU涨了可能是TLS，也可能是PHP-FPM打满、数据库慢查询、磁盘IO、日志写入、Nginx worker连接数不足。

Nginx源站上要注意的配置

HTTPS回源时，Nginx这边证书链不要配错。证书链不完整，部分CDN节点可能回源失败，表现为偶发502或525。

ssl_protocols建议保留TLSv1.2和TLSv1.3，不要再开TLSv1.0、TLSv1.1。

ssl_session_cache要开，减少重复握手成本。比如 shared:SSL:50m 这种量级，具体看连接规模。

keepalive_timeout不要太短。CDN回源场景里，30秒到120秒比较常见。太短会增加握手，太长会占连接资源，需要结合并发调。

worker_processes、worker_connections、ulimit也要配够。HTTPS回源连接数上来后，连接数限制比CPU先出问题也很常见。

如果源站前面有SLB，确认SLB到后端是HTTP还是HTTPS。有些架构是CDN HTTPS回源到SLB，SLB再HTTP到业务机；也有CDN到SLB HTTP，SLB内网HTTPS到业务机。链路怎么加密，要按实际安全边界设计。

什么情况下可以用HTTP回源

静态资源为主，内容不敏感，URL里不带token、cookie、用户隐私。

源站和CDN之间有内网、专线、同区域私有链路。

源站CPU余量不大，短期内需要减轻TLS压力。

CDN厂商支持严格的回源IP白名单，源站防火墙只放行CDN节点。

下载、图片、视频切片这类业务，用HTTP回源很常见。尤其是大带宽场景，源站更应该把资源留给磁盘IO和出口带宽，不一定非要把每一段回源流量都加密。

什么情况下建议HTTPS回源

登录、注册、支付、订单、用户中心、管理后台、API接口。

请求里有Cookie、Authorization、Token、手机号、邮箱、地址等信息。

源站在海外或跨运营商公网回源，链路不可控。

合规要求明确要求全链路加密。

业务经常被抓包、劫持、篡改，或者对数据完整性要求比较高。

这里不要只盯性能。HTTPS回源多花一点CPU，但能减少中间链路被观察和篡改的风险。对企业业务来说，这部分成本通常是值得的。

海外源站和回源线路的影响

跨境CDN回源时，协议只是问题的一部分。线路质量、BGP路由、CN2、CMI、CU回国质量，对回源稳定性影响很大。

比如源站放香港，面向中国大陆用户，CDN回源走CN2+CMI+CU这类优化线路，延迟和丢包会比普通国际线路稳定很多。HTTPS回源多出来的握手延迟，在低RTT线路上也更容易被摊薄。

如果你也在找这种适合做源站、回源节点、海外业务承载的服务器，可以看看129云。像香港综合-D型，16C、16G DDR4 ECC、110G SSD、20Mbps峰值，线路是CN2+CMI+CU，适合对回国访问质量比较敏感的业务；如果是美国方向的大带宽业务，美国精品网-E型有16C、16G、100Mbps峰值，三网精品线路，适合做海外源站或下载类业务。需要确认线路、带宽、防御和回源架构，可以直接打客服热线400-9177118。

源站压力不够时，协议选择会被放大

有些4C4G的小机器，跑Nginx、PHP、MySQL都在一台上，再开HTTPS回源，CPU一高就开始抖。不是HTTPS本身有多可怕，而是机器本来没有余量。

如果业务已经接近CPU 70%到80%，HTTPS回源再多吃10%到20%，线上就会出现排队、慢请求、502。这个时候把回源改成HTTP，确实可能立刻缓解。

但这只是把TLS成本拿掉了，业务处理压力还在。更稳的处理方式是把静态资源缓存好，把数据库拆出去，业务服务扩容，源站只允许CDN回源访问。

马来西亚、新加坡、香港这类区域做东南亚业务时，也要看用户分布。如果业务主要在马来西亚，马来西亚-B型这种4C、4G、30Mbps峰值、三网优化的机器可以做中小型源站；如果中国大陆访问占比高，香港优化线路通常更合适。

压测时要按CDN回源方式测

压测HTTP和HTTPS差距时，不要只用短连接压测。

更接近真实CDN回源的压测方式应该包含Keep-Alive、固定连接池、不同文件大小、真实缓存命中率估算。

比如压测小文件，可以分两轮：一轮模拟短连接，看TLS握手极限；一轮开启Keep-Alive，看连接复用后的吞吐。两组数据差别会很大。

wrk压测时可以关注Latency、Req/Sec、Transfer/sec，同时看源站CPU sys/user占比。如果HTTPS回源时user CPU明显上升，多半是加解密和握手；如果sys CPU高，可能是连接、内核网络栈、文件句柄、TLS库调用带来的开销。

线上更直接的办法是看Nginx日志和stub_status，结合CDN控制台的回源请求数、回源状态码、回源耗时。切协议前后对比半小时到一天，数据会比猜测靠谱。

实际配置上更常见的组合

全站静态资源：用户到CDN走HTTPS，CDN到源站走HTTP，源站限制CDN IP访问。

企业官网：页面和静态资源可以HTTP回源，表单、登录、后台HTTPS回源。

电商和会员系统：全链路HTTPS，源站扩CPU或优化TLS连接复用。

游戏更新包、客户端下载：HTTP回源较多，重点放在缓存命中率、带宽、DDoS防护、源站限速。

API网关：HTTPS回源更稳妥，配合长连接、HTTP/2、连接池、限流和熔断。

一个容易忽略的问题：源站被绕过

不管HTTP回源还是HTTPS回源，源站都不应该裸奔在公网被随便访问。

源站IP一旦泄露，攻击流量可以绕过CDN直接打源站。DDoS场景下，CDN前面看起来没事，源站已经被打挂。

源站防火墙要只放行CDN回源IP段，SSH、数据库、管理端口不要对公网开放。需要远程管理时，走VPN、堡垒机或固定办公IP白名单。

如果业务本身容易被攻击，源站要考虑高防服务器或高防IP。回源协议解决不了DDoS，HTTPS还会让握手型攻击更消耗CPU。高防、限速、连接数限制、WAF规则要一起看。

回源HTTPS的压力怎么降

开启TLS 1.3，减少握手往返。

开启session cache和session ticket，让会话复用生效。

调大CDN回源Keep-Alive时间，减少连接反复创建。

源站Nginx开启合理的worker数量和连接数。

把静态资源缓存时间拉长，减少回源请求。

动态接口能缓存的做短缓存，比如1秒、3秒、10秒，对高并发接口很有用。

证书链配置完整，避免CDN节点反复握手失败。

源站CPU选择新一点的平台，AES-NI对HTTPS吞吐影响很明显。

实际选择时可以这样判断

如果源站和CDN之间是公网，并且业务有登录态、接口数据、用户信息，优先HTTPS回源，然后通过Keep-Alive和TLS优化降低压力。

如果是纯静态资源、下载、图片分发，源站只允许CDN IP访问，HTTP回源可以减少CPU消耗，配置也简单。

如果现在源站CPU已经很紧，切HTTPS回源前要压测。特别是4C、8C的小规格机器，动态请求多的时候，HTTPS回源可能把余量吃掉。

如果机器是16C以上、新平台CPU、CDN连接复用正常，HTTPS回源带来的压力通常可控。真正需要重点优化的，往往是缓存命中率、源站带宽、业务慢接口和数据库。

线上切换时不要一次全量改。可以先选一个回源域名、一个业务路径或一个CDN区域灰度，观察源站CPU、连接数、回源耗时、5xx，再扩大范围。