《Web发布技术》作者：田中祥平
——HTTP缓存
——反向代理
——活用CDN技术
让所有的网站系统都拥有最好的性能！
从基础到实践，全面讲解使用HTTP进行「Web发布」。
打造坚实的Web系统，CDN技术的导入只是开始。
高速化/负载策略/系统基础架构/HTTP缓存/HTTP消息头优化/内容优化/反向代理入门/CDN导入及有效设定/Varnish加速器/自建CDN/缓存设定及战略/动态内容缓存/防止缓存带来的故障/降低系统成本/高效抗压的大规模服务
前言
1.1 本书的受众及目的
本书是讲解以HTTP进行Web发布及其优化的入门书籍。本着使新手前端・后端都能很好理解，从零开始说明。
「发布」这个词，字面意思广泛，应该会有不明所以的读者。本书中的「发布」，主要是指Web（使用HTTP协议为主）下，把内容*1从服务端传输到客户端。本书中，“最佳发布”定义为高速、稳定、安全地进行发布。“发布技术”是指实现Web发布所使用的各种方法。“发布系统”是指使用与发布相关的反向代理（Proxy）*2、CDN*3等构筑的系统集合。
发布的稳定性和速度直接影响用户体验，对于网站所有者及主机服务商来说，这是绝对不能轻视的地方。
发布技术贯穿于服务器和客户端之间，并非单一知识所成。要从把握系统整体，优化程序设定，基础架构的组建，缓存等上下功夫。如有需要还需导入CDN等外部服务。
尽管讲了这么多，现阶段想必是一头雾水吧。其实不用把发布想的太复杂，只需考虑如何靠它上线我们的Web。比如当我们架起简单的网站或者博客的时候，大多数情况都是把它们放置在托管主机中。
服务器和因特网相连，人们使用电脑・智能手机等客户端通过互联网来访问网站。
*1 本书中，把服务器本地文件定义为内容资源，将服务器上后端代码所生成的动态网页等和内容资源相结合的产物定义为“内容”。当单独使用“资源”一词时，它指的是CPU和存储等资源。
*2 代理服务器的一种。本书基本以“Proxy”记载。架设在Apache等Web服务器/应用服务器的前端（与客户端交互）。收集用户请求，转发至Web服务器/应用服务器。其主要功能为整理客户端请求，缓存应用服务器响应内容等。详细将在第四章讲解。
*3 Content Delivery Network（内容分发网络）的简称。是一种加强Web内容发布的稳定，提高访问速度的一种服务。Akamai公司的Fastly作为其代表。
HTTP消息头 – 设定和发布
出现问题时，恐怕大家首先想到的对策便是导入CDN及服务器扩容吧。
不过，对于不少网站来说基本没有效果。这时候，就需要认识到问题在此之前。
・没完全理解Web标准，错误的设置导致本地缓存不能正常工作
・明显超出需求的缩略图大小*1
・…
我见过很多这样的事例。不过在着手导入CDN及大改架构之前，能够改善的地方非常多。扎实地分析缺陷逐一补足，才能治本，才能使系统更高效、稳定、降低成本。
在本章，将解说如何在不进行大规模架构变更的情况下，可进行的系统效率优化。
进行Web发布的系统构造各式各样，但是大都有一个共通点，数据的传输总量左右着企业的利润。比如，以AWS为首的云服务，就包含以传输量为计价单位的服务*2。不对流量加以控制，将产生巨额账单。
以下公式计算传输量（总传输量）
（总传输量 = 请求数 x 平均内容大小）
本章中，以下列两点为中心，讲解如何缩减总传输量。
・对标准HTTP消息头进行设定，本地缓存…
*1 笔者还曾遇到过8K分辨率（7680×4320）大小的缩略图。
*2 还有根据请求数计费的服务。
压力对策 – 缓存
上一章，我们使保存在客户端的本地缓存正常工作了。如此简单就能应对访问压力了吗？
来看一看现实中能够发生的例子。比如，突然某一服务在SNS里成为话题，用户量激增。第二章我们粗略讲过，本地缓存仅仅只能在对应的客户端中再利用。所以，只有在客户端访问站点过后本地缓存才生效。
上面提到的用户激增，预示着并没有本地缓存的新用户所带来的服务请求增加。固然，随着用户的增长，新增访问也会增加，直接导致系统的负载升高。目前为止，一直是以客户端本地缓存为中心作讲解，单单靠本地缓存，似乎不足以应对单纯的用户数量增长。
下图为导入了Proxy和CDN的网路缓存。
图4.1 本地缓存与网路缓存生效节点的不同
已进行过请求的客户端
→ 不发生新请求，直接使用本地缓存Private/Shared
未进行请求的新客户端
→ CDN/Proxy服务器接收请求，返回已有的Shared缓存
→ 服务主体静默
如图所示，新客户端发出请求，客户端与服务端中间的CDN或Proxy接收请求。如果拥有缓存的话，直接回应请求。就算没有缓存，向后端服务器…
活用CDN服务
“想要面向全世界用户进行发布”，“想要进行数据传输量非常大的发布” 如此条件，对于运营Web的你来说，都是必然会面对的。随着网站的发展，访问量的增加，现有架构已无力承受压力，想必你也想做点什么改变现状吧。
这时候能为你所用的，便是无数次提及到的CDN（内容分发网络）。
图6.1 靠近用户端的是CDN的边缘节点
CDN的最显眼优势，更快、更稳定的进行发布。
由于CDN拥有世界上高质量的网络线路，大量的边缘节点（靠近用户端的服务器），使得能够在地理上以靠近用户端的位置，提供高速，稳定的Web发布。
善用CDN服务，能从全球各地的边缘节点，向全世界用户提供高速的访问。同时还拥有超大容量的带宽，从容应对大流量访问。
但是，仅仅导入CDN服务并不能自动就缓解发布压力。由于有各种各样的使用方法和注意点，本章将详细说明。
自建CDN（DIY-CDN）
在第6.1.2章，介绍了自建CDN（DIY-CDN）、本地部署（自建CDN的一部分）与外部CDN组合进行服务的事例。
采用自建CDN的公司中，具有代表性的便是Netflix*1。其核心业务依赖发布，并且时常伴随着巨大的传输量。因此自建CDN在成本和自主性上要优于导入外部CDN服务。
即使没有Netflix那样大规模的发布，也有其他符合采用自建CDN的模式。比如“预算不足以使用外部CDN”，“想要降低资金成本”，“考虑组建混合架构”，这些你早就想到的。
本章就这些模式，以及有关经济自建CDN的重点进行讲解。
7.1 为何要自建CDN
自建CDN可以分为3大类
1.超大规模服务。
对巨量数据传输、高度自主性的需求，自建的话有着明显的成本优势（如Netflix）
2.低预算。
没有充裕资金导入外部CDN
3.混合架构
外部CDN与本地部署相结合的混合架构，具有优势。
— 为静态内容减载，使用外部CDN
— 流量固定，低成本的本地部署满足需求。超出本地负载上限的流量，使用外部CDN处理。（如DMM公司等*2）
— 保证内容的一致性，采用本地部署与外部CDN相结合的多段构成。
有“由于内容性质无法使用CDN”等，少部分例外情况，暂不讲解。上述3类中，对大多数读者来说，实际能够…
*1 使用自建的称为“Netflix OpenConnect”的服务。
*2 另外，Apple公司也拥有CDN，采用混合架构。