据我所知，CDN意味着将您的静态文件实际caching在距离用户较近的多个区域中。 但是，我注意到一些网站，当他们的服务器请求一个页面时，他们从他们的cdn获取资产文件，处理它们（压缩，缩小等），将结果caching到他们的服务器上，然后将它们发送到用户请求页面。
这对我来说没有太大的意义。 不会处理您的服务器上的文件消除了使用cdn的收益？ 这是一种正常的做事方式，还是我不了解整个资产pipe理概念？
拥有CDN过程的文件使开发人员的生活更轻松。 另外，根据网站的情况，开发者可能不知道最好的压缩/缩放技术，所以把它留给主持CDN的人并不是一件坏事。
出于好奇，你是怎么注意到这种行为的？ 看来如果做得对，最终用户是无法察觉的。
一些网站在从服务器请求页面时，从他们的cdn中获取资源文件，处理它们（压缩，缩小等），将结果caching到服务器上，然后发送给请求页面的用户。
好吧，假设您在自己的服务器上拥有www.company.com ，并且您还拥有另一家公司提供的CDN服务。 您的意思是将数据从CDN上的存储中提取出来，然后传输到运行www.company.com的服务器园区，然后从那里向最终用户提供数据？
如果这就是你的意思，这是没有意义的，而且似乎是一个错误。 对于某些forms的“云文件存储”，例如Amazon S3，这可能是有意义的。 但是，Amazon S3并不是一个CDN，它是一个高度可扩展的文件存储，并不像CDN那样分发给世界各地的POP。 （如果您想在亚马逊系列产品中使用CDN，那么您需要Amazon CloudFront。）
也许你的意思是相反，你在自己的服务器上有www.company.com ，并且把资源服务器放到你的CDN上。 您的CDN然后缩小和HTTP压缩它们，并将它们压缩到最终用户？ 这很正常，但这只是一个更容易configuration的问题。 有些人/公司似乎没有尽力configuration自己的networking服务器，所以他们要求CDN来处理这个问题。 （其中BTW只是一个部分解决scheme，因为只有'静态'CSS和JS等才能得到最佳服务–HTML通常不会通过CDN。）
据我所知，CDN意味着将您的静态文件实际caching在距离用户较近的多个区域中。
对，那是正确的。 在这种情况下，“更紧密”是“networking延迟更less”的缩写。