欢迎光临网防CDN首页! 您好, 新人有礼

网防CDN

新闻公告

解决云中的反向代理问题

发布时间:2018-04-16 09:01
cdn加速

最近的一项研究表明反向代理技术正在Web应用程序中得到进一步的采用。自2016年初以来使用反向代理服务的网站数量从5.5%稳步增长到8.3%,采用率增长了51%。这种架构设计是当今CDN和网络安全服务的核心。反向代理的许多好处包括:
 
通过Web应用程序防火墙(WAF)增强安全性:
 
在需要开发新的故障排除方法的可见性方面存在不足。在本文中介绍反向代理服务在解决生产环境故障时能够引入的局限性,并快速识别出可见度有限的意外问题。扰流器警报它被称为XRAY。
 
反向代理体系结构的复杂性:
 
反向代理是一个中间服务器它处理来自最终用户的请求,就好像它是源服务器一样并从源端请求资源跟最终用户一样。该平台创建了用户和原点之间的完美区别,因此两者不会互相讲话。这种设计模式的挑战我们可以确定七个关键领域:
 
A.失去窗帘后面的可见性
 
从最终用户的角度来看就像RUM(真实用户监控)工具一样,可视性停在应用程序边缘。这些工具和方法无法理解边缘与原点之间的行为或性能。例如当在使用反向代理或CDN的网站中识别到性能下降时它可能主要是由两个因素造成的。它可能是应用程序问题例如服务器负载增加,或者它可能与Internet路由有关的连接问题。这两者非常不同需要完全不同的方法来处理。
 
B.非确定性缓存
 
添加反向代理时如Varnish,NGINX或HA代理通常是通过减少延迟提高最终用户体验,以及
通过减少原点的计算负担来提高基础设施利用率。但是通过静态内容缓存您实际上会在Web和应用程序服务器堆栈外添加应用程序的扩展。这意味着由于用于控制的缓存逻辑,许多请求甚至不会到达原点。
 
C.安全政策和规则
 
如果像WAF这样的反向代理是流入您网站的流量的内联检查机制的一部分,则某些请求将在安全层被阻止。对网站安全层的行为的可见性是重要的。
 
D.监视日志
 
所有处理层(包括原始端和反向代理)都可以生成日志,但是将系统置于可以从多个系统收集和分析日志的位置上。
 
E.关联请求
 
一旦SIEM系统就绪并且数据以可靠的方式进行流式传输,几乎不可能提取任何有意义的跨系统信息,因为每个日志都是数据的一部分。需要一种方法来关联每个反向代理和源自身上的不同日志。否则这些是多个不同且并行的数据集。
 
F. CDN和地理乘数
 
为了增加混合的复杂性,想象你没有一个反向代理,延迟是100、1,000或10,000。现在想象这个网络遍布全球数十个不同的地点。它们中的每一个都根据DNS GeoIP决策,互联网BGP通告传输提供者之间的对等关系,缓存行为和安全策略独立处理请求。如果您使用的是像网防CDN这样的内容交付网络情况就是如此。
 
G.最终用户
 
还有一个关键因素我们没有解决。当涉及到您的网站最终用户时大量问题的根本原因就在您那里。例如特定的本地ISP可能配置了错误的Internet路由导致用户流量无缘无故地跨越海洋和大陆,从而降低了您感知的网站性能。当使用全球CDN网络时每个客户端可能会在不同的PoP中打不同的反向代理。这些代理中的每一个都可以基于预设的缓存状态和策略以不同的方式作出反应。如果没有能力区分不同的客户并从特定的客户角度获得洞察力,我们处于未知领域无法有效地排除故障。
 
完整解决方案的特点:
 
让我们设想一个理想的故障排除框架。这些是我们期望得到完整解决方案的七个特征:
 
A.所需的粒度:解决方案应提供每个请求的可见性。聚合对于识别趋势非常有用,但在涉及特定请求的故障排除时基于实例的粒度是强制性的。
 
B.需要的处理数据:每层应该提供足够的信息来推导每个请求的处理结果。例如如果由于应用程序传送规则(如添加新标题)而导致特定请求被操纵或由于安全规则而被阻止,则该信息应可用于分析。
 
C.原始日志:该解决方案应该以标准SIEM格式导出或流式化日志以便将其轻松导入到现有的日志分析工具中。
 
D.关联的公共密钥ID:每个请求应该有一个持久性请求标识可用于唯一标识它。该密钥必须在请求第一次接触代理时设置。
 
E. ID共享机制:请求标识应该在请求从边缘到原点所经过的所有跳转中传递。这是因为在原点上生成的日志包含相同的ID用于数据关联和事件分析。
 
F.按需最终用户请求数据:解决方案应在特定时间提供特定最终用户的数据。例如现在在特定路由机制下的特定国家/地区的用户从哪个资源获取缓存。
 
G.地理维度:所有通过来自所有PoP所有代理的数据的所有请求以及来自任何相关最终用户的数据应该可用于需要时的分析和故障排除。
 
网防cdn专业提供国内外高防cdn加速服务
 
本文链接:http://www.f8i.com/news/470.html