波仔
🕸️ 第三章 为Web提供支持的技术
📄 一句话概括

同样是【代理】，正向代理站在客户端这边替它出头，反向代理站在服务器前面替它挡枪——看它站在谁旁边，就知道它在干什么。

📝 本节和前面几节的关系

3-2 到 3-5 讲的都是【怎么把请求送到】。这一节讲的是半路上多出来的那个角色：请求不直接到服务器，而是先经过一台代理。它是现代网站里最常见的一层，也是性能与安全的主要着力点。

一、先分清方向

【代理】这个词本身不含方向。关键在于它站在谁旁边、替谁办事。

正向代理站在客户端这边：用户配置它，它替用户去访问外面的网站。网站看到的只是代理的地址，看不到后面是谁。公司统一上网出口、以及各种【换个出口访问】的工具，都属于这一类。

反向代理站在服务器前面：网站自己架设它，它替服务器接待所有来客。用户以为自己是在直接访问网站，其实中间隔了一层。CDN、云 WAF、网关，全都是反向代理的不同叫法。

二、反向代理一次解决三件事

更快：把内容缓存在离用户更近的地方，命中缓存就不用回源。

更稳：一台服务器扛不住就摆一排，由代理把请求分下去；某一台挂了，代理把流量转给其它机器。

更安全：真实服务器的地址藏在后面，攻击流量先撞在代理身上；常见的恶意请求在代理层就被拦掉了。

正因为一次解决三件事，它才成了现代网站的标配——哪怕是个小站，套一层也几乎不花钱。

三、动手 Demo：采用率与缓存账

先看采用率，数字比形容词有说服力得多。

total = 10000000
hit = 0.85
print("总请求", format(total, ","), "次，缓存命中率", hit)
print("回源", format(int(total * (1 - hit)), ","), "次")
print("省下", format(int(total * hit), ","), "次回源，相当于源头少扛 %.0f%%" % (hit * 100))
print("前 1000 个站挂 CDN 的比例：75.4%；前 100 万个站：52%")

实跑输出：

--------------------------------------------------------------------
D6  代理：正向代理替客户端出头，反向代理替服务器挡枪
--------------------------------------------------------------------

  都叫代理，方向却正好相反。看清楚【它站在谁那边】，就分得清了。

  比什么        正向代理                          反向代理
  ------------------------------------------------------------------------------------
  代表谁        代表客户端去访问外面              代表服务器接待外面
  谁配置它      用户在浏览器里设                  网站自己架在源头前面
  对方看见谁    网站只看见代理的地址              用户以为在直接访问网站
  典型用途      翻墙、统一出口、缓存加速          负载均衡、缓存、防护攻击
  常见场合      公司统一上网出口                  CDN、云 WAF、网关

  为什么反向代理这么常见？因为它一次性解决了三件事：更快、更稳、更安全。

    · 29.6% 的网站前面有一层反向代理
    · 在这 29.6% 里，84.6% 用的是同一家
    · 访问量最大的 1,000 个站，75.4% 都挂了 CDN
    · 访问量最大的 100 万个站，52% 挂了 CDN

  算一笔缓存账。1000 万次请求，缓存命中率 85%：

    · 真正回到源头服务器的只有 1,500,000 次
    · 源头少扛了 85% 的活，用户还更快拿到内容
    · 这层挡在前面，攻击流量也先撞在它身上

第一组数字：29.6% 的网站前面有一层反向代理，而在这 29.6% 里，84.6% 用的是同一家。这种集中度意味着：一家出问题，波及面是【全网级别】。

流量越大的站越依赖它：访问量最大的 1,000 个站有 75.4% 挂了 CDN，前 100 万个站是 52%。这是明显的规模效应——小站靠它省钱，大站靠它活命。

第二组数字是缓存账：1000 万次请求、85% 命中率，真正回到源头服务器的只有 150 万次。这不只是省带宽，更是让源站在流量高峰时不必跟着一起喘。

四、它带来的新问题

代理不是免费的午餐。第一，它多了一跳：缓存没命中时，请求反而要比直连多走一段路。所以代理的价值取决于命中率，命中率低的时候它就是纯成本。

第二，它让排查变复杂。出问题时你得先分清：是代理的问题、还是源站的问题？缓存没刷新、回源失败、超时设置太短，都会表现成【网站打不开】。

第三，它改变了【谁能看到谁】。对源站来说，来访地址变成了代理的地址，真实用户 IP 要靠额外的头来传递。这也牵出了信任边界的问题：这些头由代理填，如果被伪造，后面的判断就全错了。

30 秒实验

  1. 打开开发者工具 Network 面板，点开一条请求看响应头，找找有没有 cf-cache-status、x-cache、age 这类字段——有的话，说明你正在经过代理。
  2. 把同一个页面刷新两次，对比两次请求的耗时和响应头，看第二次是不是明显更快、缓存状态是不是变成了命中。
  3. 在命令行运行 nslookup www.cloudflare.com，看返回的地址有几个——多地址通常是代理或负载均衡在做分发。

常见误区

  1. 错误：正向代理和反向代理只是叫法不同。——纠正：方向完全相反。正向代理代表客户端去访问外面，反向代理代表服务器接待外面。判断方法是看它替谁办事，而不是看它叫什么名字。
  2. 错误：代理只是大站才需要的东西。——纠正：小站用它的收益往往更大。免费套餐就能拿到缓存、HTTPS 证书和基本防护，对没有专职运维的站点来说，这一层几乎等于把基础设施外包了。
  3. 错误：套了代理，源站就绝对安全了。——纠正：它只是把你藏起来，不是把你锁起来。源站地址一旦被找到，绕过代理直接打一样能打。所以正确做法是让源站只接受来自代理的流量，而不是指望外面找不到它。
  4. 错误：把用户真实 IP 交给源站的头是可信任的。——纠正：要分来源。这些头是由代理填写的，只有来自你自己信任的那一层代理时才可信；直连进来的请求也能带上同样的头，照着它做权限判断就会被绕过。
自测三问（点开对答案） 1. 怎么一眼分清正向代理和反向代理？ —— **看它替谁办事**。正向代理由用户配置、替用户去访问外面，网站只看见代理的地址；反向代理由网站自己架设、替服务器接待来客，用户以为在直连。**一句话：一个替客户端出头，一个替服务器挡枪。** 2. 反向代理一次解决了哪三件事？ —— **更快**（就近缓存）、**更稳**（分发与容错）、**更安全**（隐藏源站、拦截攻击）。三件事同时成立，所以它才会成为现代网站的标配。 3. 为什么说代理的价值取决于命中率？ —— 因为**它多了一跳**。缓存命中时省掉整段回源，收益很大；没命中时请求反而要多走一段路，**这时它就是纯成本**。所以配置代理的核心，是让缓存尽量命中——**而不是简单地【加上一层就完事】**。

相关笔记