BFE

BFE #

baidu/bfe Github stars

Baidu Front End 百度统一前端

统一的百度七层(HTTP)流量接入平台

BFE 之前的百度前端接入架构 #

流量从 BGW 接入之后直接到达了产品线的前端服务器, 这些服务器种类繁多,几乎包涵了现在流行的各种 webserver,比如 nginx,apache,lighttpd 等, 不同的服务器经过后端不同业务逻辑的处理之后打印日志内容并且将响应发送给用户。

开发成本高 #

如果前端多个产品线需要实现一个通用功能,比如防攻击或者 IP 地域识别,需要开发不同的 webserver 模块,虽然每个模块的功能一样,但实现方式完全不同,所以存在一定的重复开发和人力资源浪费。

维护成本高 #

不同的产品线和模块都需要一定的人力来维护。前端接入服务器类型多样,实现和原理各异,出现问题的概率大,Nginx, apache 等服务器比较稳定,高效,但是如果产品线出现强烈的个性化业务需求或者严重 BUG,开源社区很难提供及时有效的技术支持。

数据和策略共享的成本高 #

产品线间维护不同的前端接入模块,策略和经验很难做到有效的分享。

技术积累难 #

由于产品线间沟通和分享的成本大,很多经验和成果并没有得到有效的积累。


BFE 架构 #

BFE 是一个七层接入系统。 它的最基本工作就是接收用户数据,解析 HTTP 请求,对内容进行过滤和分析之后再转发给后端产品线。

BFE 最基本的工作就是从 BGW/BVS 接入流量并将流量转发给产品线的前端 webserver 或者其他接入模块,最后接收后端 server 的内容并回复给外部用户。

反向代理服务器 #

BFE 本质上是一个反向代理服务器,每天承接百度数百亿的流量,高峰期的集群 QPS 有一百多万。 在如此大的流量压力环境中,服务器的处理性能至关重要。 BFE 采用现在业界流行的多进程全异步非阻塞事件驱动模型, 但由于业务功能繁多,产品线策略及规则复杂,任何一个开源的代理服务器比如 nginx, squid, varnish 的性能都很难满足需求。 BFE 本身也需要不断优化,降低系统资源开销,提升处理性能。

能够在任意阶段处理用户请求 #

从接收用户请求的时候起,BFE 就能对数据进行完全的解析和过滤,能够在读取、解析、连接、写后端等的任一阶段对数据进行修改、增加、删除、丢弃等操作。

分流策略非常高效 #

NGINX 和大部分通用的网络服务器在多个正则规则复杂策略组合下的分流效率比较低,BFE 通过反解正则规则嵌套分流策略实现了时间复杂度为 O(1) 的分流。

BFE 提供统一缓存 #

BFE 提供统一缓存,用户请求可以不经过后端处理由 BFE 直接返回。

BFE 提供灵活的缓存策略,对于 css 及不宜存放 CDN 的静态资源,BFE 缓存。

提升超长距离的数据传输效率和响应时间 #

BFE 和 BFE 级联后可以启用 tcp fast open 及任意时间的长连接,提升超长距离的数据传输效率和响应时间。


防攻击系统 #

产品线各自为战的防攻击很被动,

  1. 各个产品线需要重复去做防御
  2. 同一个防御策略,不同的接入服务器和架构需要不同的代码和逻辑实现
  3. 公司的防攻击策略很多都是直接从产品线日志进行挖掘的,不同的服务器日志有不同的格式,众多产品线有各自的部署机房,日志传输延时大并且计算成本高,导致部分防攻击策略时延很大,无法有效实时防止外部攻击。

BFE 防攻击系统的优点: #

  1. 全局性防御

    BFE 接入目标是百度全部流量,一个策略在 BFE 生效,就可以为百度全部产品线提供保护。

  2. 时效性

    BFE 实时接收和分析流量,只要符合攻击特征,实时封禁攻击请求。相比 UBS 的离线日志统计和挖掘,BFE 的防攻击检测和生效延时能做到秒级。

  3. 支持复杂策略

    BFE 接收用户请求时需要对全部内容进行分析过滤,应用层的常见攻击都能实施有效防御。 此外,BFE 的统一防攻击系统 BDS 还在进行实时的全局攻击特征计算,对于同时符合多种封禁规则的外部请求实行封禁。

百度防攻击系统(BDS) #

BDS 是百度接入端全局防攻击系统,负责对接入端流量进行全局、旁路、常态的特征分析和防御处理。 主要由三个子系统组成:

  • 旁路特征发送子系统(BDS Sender)
  • 特征检测子系统(BDS Detector)
  • 攻击防御子系统(BDS Defender)


流量调度及均衡系统 #

内网流量调度及均衡系统(GSLB) #

GSLB(global service load balance)即内网流量调度系统, 主要针对百度 IDC 内部的流量进行调度。

它的主要目标是感知内网流量和产品线容量变化并自动地均衡调度流量。

GSLB 要解决的主要问题描述如下:

  1. BFE 应该优先将流量转发给离其最近(延时最短)的 Service Cluster
  2. BFE Cluster 向下游多个 Service Cluster 的流量转发:
    • 需要对每个下游的 Service Cluster 给出一个权重
    • 这个权重是 gslb 的控制系统需要计算给出的

工作原理简述如下:

调度模块根据流量采集模块采集到的实时流量数据和容量管理模块提供的容量数据实时计算出权重并将权重数据下发给 BFE, BFE 根据权重数据分配流量,实现快速的流量切换和负载均衡。

外网流量调度及均衡系统 (GTC) #

GTC(global service control)主要针对外网流量调度。

由于网络运营商、带宽资源、网络质量等的限制,即使同一个用户访问同一个百度服务的不同 VIP,也会带来不同的访问延时。

GTC 要解决的主要问题是:

对每个用户群,选择唯一的 vip,希望总延迟较小。


流量分析及展现 #

流量分析 #

BFE 拥有各个产品线访问日志,目前整个集群的天访问日志量有 30 多 T。包括最基本的 URI、HTTP 状态码、用户 IP、cookie、响应时间等, BFE 通过这些日志能挖掘出哪些价值?流量分析主要在以下几个方面开展工作:

  • 异常检测

    本文提到的异常定义为不同于正常或者预期行为的数据模式。异常检测的研究成果目前已经应用于金融业的信用欺诈检测,网络入侵检测,医疗疾病预测等。 BFE 的异常检测主要分析访问日志中出现的各种特征数据,判断并拦截异常请求。比如可以根据用户 IP 和 COOKIE 的历史访问纪录判断该 IP 是否正常用户。

  • 带宽及资源优化

    主要是针对各产品线流量的占用带宽、响应时间和页面特征优化带宽接入。尽量减少跨 IDC 流量和外网带宽资源。

  • 服务质量监控

    服务质量的变化都会反映在访问日志里,响应时间上升,建立连接和重试时间增多都是服务质量下降的具体表现。BFE 希望能通过日志分析数据监控和提前预警产品线服务质量的变化。

流量展现 #

BFE 希望能够实时、准确地展现全百度各条产品线的流量概况,包括总流量趋势、响应时间、状态码变化、地域统计等。 但是在大流量大压力环境下,保证日志传输,数据计算的实时性、稳定性也是个非常有挑战的难题。


其他 #

BGW #

BVS #

UBS 日志 #

911 防攻击系统 #

公司最主要的防攻击系统就是 911

911 运行在内核态并且主要针对四层攻击

不支持长时间的流量清洗 #

因为长时间内核态运行很容易产生稳定性问题。

不支持应用层协议的复杂防御 #

911 主要定位于四层防攻击,如果对七层协议进行分析和策略组合防御,性能消耗非常大。 所以无法防御很多常见的 HTTP 攻击,比如恶意 header(重定向攻击cookie 攻击), XSS 攻击sql 注入等。


BFE 未来工作(by 2014-02) #

BFE 的未来工作依然围绕四个核心模块进行:

  • 高性能网络服务器技术
  • 防攻击
  • 流量调度及均衡
  • 流量分析及展现

高性能网络服务器技术 #

优化网络协议 #

BFE 需要研究和应用业界最先进和成熟的网络优化协议,最主要的就是 TCP 和 HTTP。BFE 目前应用了 tcp fast open 技术,能有效减少 TCP 建立连接三次握手带来的延迟,在第一个 syn 包发出时就能开始传输数据。

BFE 目前只支持 HTTP1.0\1.1 协议,HTTP1.1 1999 年发布之后几乎没有很大更新。随着因特网的发展,HTTP1.1 协议的一些缺陷也遭受越来越多的诟病,比如网络连接的复用少,头部冗余数据等。做为下一代 HTTP 协议的 HTTP2.0(主要基于 SPDY 协议)草案正在讨论,预计于 2014 年提交 IETF。BFE 目前也在研究 HTTP2.0 协议内容及在 BFE 上的实现方式。

优化并发连接处理模型 #

BFE 采用异步事件驱动实现高并发。但事件驱动的性能到底有多高?是否有新的模型支持实现百万甚至千万级的并发?这是业界广泛讨论和思考的问题。

但事件模型也有很多缺陷,比如事件状态机的处理很复杂,事件不好管理,超时管理消耗资源等。BFE 需要考虑改进事件模型或者采用新的模型实现更高的并发。

分流策略及计算优化 #

BFE 分流策略非常复杂,一条简单的请求往往要通过几十个规则的过滤才能到达产品线后端,怎样降低时间复杂度?减少规则计算?随着接入产品线越来越多,规则越来越复杂,BFE 需要通过优化分流策略来提升处理性能。

防攻击技术 #

防攻击系统管理、查询平台化、接口化。 #

包括配置修改、策略修改及查询、防攻击数据查询等需求,全部实现接口化。

WAF 研究 #

WafWeb Application Firewall,是通过执行一系列针对 HTTP/HTTPS 的安全策略来专门为 Web 应用提供保护的系统。

性能优化 #
复杂防攻击策略定制。 #

流量调度及均衡 #

加强流量调度结果的可视化

在外网调度中支持更多的调度策略(比如:增加对带宽成本的考虑)

在内网调度中,增加对更复杂内网环境的考虑(目前只考虑下游服务机群的故障)

流量分析 #

流量分析争取在异常检测和服务质量监控取方面取得突破。