2014年5月，颇负盛名的搜狐视频，背负了一起著名的DDoS攻击事件。
当时，日本CDN服务商Incapsula声称，自己的一位客户的服务器遭遇了搜狐视频发起的DDoS攻击，期间总共有超过2万的网民通过搜狐视频向这位客户发起超过2000万次的HTTP Get请求。然而如此知名的网站，怎么会甘冒不韪，公然向别人发起攻击呢？原来，搜狐视频是在未知的情况下被黑客利用，成为了攻击的源头。
有句话叫“趁虚而入”，搜狐视频网站上恰好就有这么一个漏洞给了黑客“打劫”的机会。通过这个漏洞，黑客注册一个搜狐视频账户，在头像中注入恶意代码（JavaScript），然后用这个账户在视频的评论区发布大量的评论。你看，每条评论都带有用户头像，头像中带有恶意代码，这样，每条评论都附带着恶意代码。当任何用户访问这个视频页面的时候，都会触发恶意代码，实际上控制了搜狐视频用户的浏览器。
那么这段恶意代码干了什么呢？简单说，这段代码就是在用户不知情的情况下，定时向受害者发起HTTP访问请求。这个定时器，是1秒。
也就是说，当搜狐视频用户观看视频时，他的浏览器会每秒向受害者发起一次请求。如果用户观看30分钟视频，那么就会向受害者发起1800次请求。大家可能会觉得，这也没有多少呀，但是，搜狐视频这样的大型视频网站，同时在线观看热门视频的用户都是成千上万级别的，黑客在多个热门视频下发布海量评论，轻松获得无数“肉鸡”。众人拾柴火焰高，如果星火燎原到千家万户同时持续地向受害者发送请求，攻击效果就可想而知了。
HTTP协议，HyperText Transfer Protocol，超文本传输协议。我们先来简单回顾下HTTP协议的基本原理。
HTTP协议最基本的交互流程如下。
完成TCP三次握手后，客户端向服务器发起HTTP请求。正常情况下，服务器回应200 OK，在应答中添加应答长度，然后开始传输数据。
HTTP协议还有一种重定向的交互流程，如下。
完成TCP三次握手后，客户端向服务器发起HTTP请求。如果客户端请求的这个URL是过期的，那么服务器就会回应客户端302重定向报文，并携带新的URL地址。然后客户端再重新向新的URL地址发起请求，服务器回应200 OK，并开始传输数据。
HTTP攻击一般分为GET FLOOD和POST FLOOD攻击
HTTP GET Flood攻击的原理很简单，攻击者利用攻击工具或者操纵僵尸主机，向目标服务器发起大量的HTTP GET报文，请求服务器上涉及数据库操作的URI或其它消耗系统资源的URI，造成服务器资源耗尽，无法响应正常请求。
防御HTTP GET Flood攻击的常用手段是源认证，这种防御方式适用于客户端为浏览器的场景，因为浏览器支持完整的HTTP协议栈，可以正常回应抗DDOS设备发出的探测报文。源认证包括两种方式，最基本的方式是302重定向认证。
302重定向认证
302重定向认证的原理是抗DDOS设备代替服务器向客户端响应302状态码（针对GET请求方法的重定向），告知客户端需要重定向到新的URL，以此来验证客户端的真实性。真实客户端的浏览器可以自动完成重定向过程，通过认证；而虚假源或者一般的攻击工具没有实现完整的HTTP协议栈，不支持自动重定向，无法通过认证。
1、当连续一段时间内去往目标Web服务器的HTTP GET请求报文超过告警阈值后，抗DDOS设备启动源认证机制。源认证机制启动后，抗DDOS设备将会代替服务器与客户端建立TCP三次握手。
2、抗DDOS设备拦截HTTP请求，代替Web服务器回应302状态码，将客户端的访问重定向到一个新的URI。
3、如果这个源是虚假源，或者不支持完整HTTP协议栈的攻击工具，不会向新的URI发起请求。
4、如果这个源是真实客户端，则会向新的URI发起请求。Anti-DDoS系统收到请求后，将该客户端的源IP地址加入白名单。然后抗DDOS设备会再次回应302状态码，将客户端的访问重定向到一开始访问的URI。
5、后续这个客户端发出的HTTP请求报文命中白名单直接通过。
我们结合一组抓包信息来看一下交互报文的具体情况。
1、抗DDOS设备代替Web服务器与客户端建立TCP三次握手，然后客户端发起访问请求。
(author https://www.cnblogs.com/Shepherdzhao/)
2、抗DDOS设备代替Web服务器回应302状态码，希望客户端访问一个新的URI地址“http://156.*.*.*/?dbiekfcjekngdjec”，然后双方关闭连接。
3、真实客户端会再次与抗DDOS设备建立TCP三次握手，并向新的URI“http://156.*.*.*/?dbiekfcjekngdjec”发起请求。
4、抗DDOS设备收到请求后，判定该客户端为真实客户端，将其IP地址加入白名单。同时抗DDOS设备会再次回应302状态码，将客户端的访问重定向到一开始访问的URI，然后双方关闭连接。后面该客户端发出的HTTP请求报文就可以命中白名单直接通过了。
除了302状态码重定向方式，还有一种META Refresh重定向方式。META Refresh方式是通过修改HTML页面来实现重定向，具有局限性；而302状态码方式是利用HTTP协议规范来实现重定向，适用性更好。所以302状态码方式是目前使用比较广泛的重定向方式。
另外还有一种情况，网络中存在HTTP代理服务器时，只要代理服务器IP地址通过源认证加入白名单，僵尸主机就可以利用代理服务器IP地址绕开源认证，导致防御失效。针对这种情况，抗DDOS设备提供了代理检测功能。开启该功能后，抗DDOS设备会检测HTTP请求是不是通过代理服务器发出的。如果是，抗DDOS设备会从HTTP报文中获取请求者的实际IP地址进行源认证，通过认证后才加入白名单。
302重定向认证利用HTTP响应报文中的302状态码来实现对客户端的源认证功能，但是如果攻击工具实现了完整的HTTP协议栈，或者像搜狐视频攻击事件中攻击源都是真实的浏览器这种情况，会导致302重定向认证方式失效。此时，可以使用源认证中的增强方式，即验证码认证。
验证码认证
验证码认证的原理是抗DDOS设备要求客户端输入验证码，以此来判断请求是否由真实的用户发起，而不是由攻击工具或僵尸主机发起。因为攻击工具或僵尸主机无法自动响应随机变化的验证码，所以能够有效的防御攻击。
1、当连续一段时间内去往目标Web服务器的HTTP GET请求报文超过告警阈值后，抗DDOS设备启动源认证机制。源认证机制启动后，抗DDOS设备将会代替服务器与客户端建立TCP三次握手。
2、抗DDOS设备拦截HTTP请求，向客户端返回验证码页面，要求客户端输入验证码。
3、如果这个源是攻击工具或僵尸主机，不会输入验证码。
4、如果这个源是真实客户端，则会输入验证码并通过认证，抗DDOS设备将该客户端的源IP地址加入白名单。然后抗DDOS设备会请客户端继续访问一开始的URI。
5、后续这个客户端发出的HTTP请求报文命中白名单直接通过。
下面给出了抗DDOS设备向客户端返回的验证码页面的报文，以及对应的实际页面：
验证码认证方式与302认证方式相比，防御效果更好，但是由于需要人机交互输入验证码，用户体验稍差一些。在实际使用验证码认证方式时，可以增加源IP统计的环节，即抗DDOS设备先基于目的IP进行统计，当去往某个目的IP的HTTP请求超过阈值时，启动基于源IP的统计。当来自某个源的HTTP请求也超过阈值时，才启动验证码认证机制。这样就会精确控制需要进行验证码认证的源IP范围，避免大范围的源IP都要输入验证码。
302重定向认证和验证码认证这两种源认证方式是防御HTTP GET Flood攻击的有效手段，但是源认证方式也存在一定的局限，比如机顶盒视频点播、特定移动网络等场景中，无法对客户端使用源认证方式。为此，有的抗D设备还支持URI动态指纹学习和URI行为监测防御方式，作为源认证方式的补充，满足不同场景的需求。
URI动态指纹学习
URI动态指纹学习方式适用于攻击源访问的URI比较固定的情况，因为要形成攻击效果，攻击者一般都会以容易消耗系统资源的URI作为攻击目标。一个攻击源会发出多个针对该URI的请求，最终呈现为该源对特定的URI发送大量的请求报文。
基于这个原理，抗D设备对客户端所访问的URI进行指纹学习，找到攻击目标URI指纹。在一定的周期内，当同一个源发出的包含同一指纹的请求超过设置的阈值时，就将该源加入黑名单。
URI行为监测
URI行为监测防御方式要先设置需要重点监测的URI，可以将消耗资源多、容易受到攻击的URI加入到“重点监测URI”列表中。URI行为监测防御方式通过判断两个比例是否超过阈值来确定攻击源。
首先，在特定时间内对某个目的服务器的所有访问中，对重点监测URI的访问数与总访问数的比例超过设置的阈值时，抗D设备启动针对源的URI检测。当这个源对某个重点检测URI的访问数与总访问数的比例超过设置的阈值时，就将该源加入黑名单。
攻击者利用攻击工具或者操纵僵尸主机，向目标服务器发起大量的HTTP POST报文，消耗服务器资源，使服务器无法响应正常请求，这就是HTTP POST Flood攻击。
防御HTTP POST Flood攻击与防御GET Flood攻击类似，常用手段也是源认证，包括重定向认证和验证码认证。
重定向认证
抗D设备代替服务器向客户端响应307状态码（针对POST请求方法的重定向），同时向客户端的浏览器注入Cookie，客户端再次发起请求时会在HTTP报头上附加Cookie信息，抗D设备通过验证Cookie信息的真实性来验证客户端。
1、当连续一段时间内去往目标Web服务器的HTTP POST请求报文超过告警阈值后，抗D设备启动源认证机制。源认证机制启动后，抗D设备将会代替服务器与客户端建立TCP三次握手。
2、抗D设备拦截HTTP请求，代替Web服务器回应307状态码，并在响应头部附加上由客户端IP生成的Cookie。
3、如果这个源是虚假源，或者不支持完整HTTP协议栈的攻击工具，不会重新发起请求。
4、如果这个源是真实客户端，抗D设备生成的Cookie会写入到浏览器中，并且客户端会重新发起请求，请求头部就会带有该Cookie信息。抗D设备收到请求后，验证Cookie是否正确，如果正确则将该客户端的源IP地址加入白名单。然后抗D设备会回应408状态码，表示请求超时，使客户端重新发起访问。
5、后续这个客户端发出的HTTP请求报文命中白名单直接通过。
我们结合一组抓包信息来看一下交互报文的具体情况。
1、抗D设备代替Web服务器与客户端建立TCP三次握手，然后客户端发起访问请求。
2、抗D设备代替Web服务器回应307状态码，同时在响应头部附加上由客户端IP生成的Cookie，然后双方关闭连接。
3、真实客户端会再次与抗D设备建立TCP三次握手，并且会重新发起请求，请求头部就会带有Cookie信息。
4、抗D设备收到请求后，通过验证Cookie来判定该客户端为真实客户端，将其IP地址加入白名单。然后抗D设备会回应408状态码，表示请求超时，使客户端重新发起访问。
上面介绍的307重定向认证方式能够很好地防御HTTP POST Flood攻击，但是这种方式也具有一定的局限性。其一，依赖于客户端浏览器的Cookie的机制，受安全级别限制。如果客户端的浏览器安全级别较高而无法写入Cookie，会导致认证不通过；其二，第一阶段重定向结束后，需要客户端再次手动执行提交等操作，才能重新发起POST请求。
同HTTP GET Flood的防御方式相似，HTTP POST Flood的源认证防御也支持增强方式，即验证码认证。
验证码认证
此处的验证码认证与HTTP GET Flood中的验证码机制相同，抗D设备要求客户端输入验证码，以此来判断请求是否由真实的用户发起。其弊端也是需要人机交互输入验证码，用户体验稍差一些。具体的工作原理请参考HTTP GET Flood攻击与防御部分中的介绍，此处不再赘述。
URI动态指纹学习和URI行为监测
防御HTTP POST Flood攻击时，也可以使用URI动态指纹学习和URI行为监测防御方式，作为源认证方式的补充，满足不同场景的需求。其防御原理我们在上面的HTTP GET Flood攻击与防御部分中已经介绍过，在此也不赘述了。
HTTP慢速攻击是利用HTTP协议的正常交互机制，先与目标服务器建立一个连接，然后长时间保持该连接不释放。如果攻击者持续与目标服务器建立这样的连接，就会使目标服务器上的可用资源耗尽，无法提供正常服务。
HTTP慢速攻击主要包括针对HTTP请求报文头部结束符的Slow Headers攻击，以及针对POST请求报文数据长度的Slow POST攻击。
Slow Headers
HTTP请求头部的后面会存在一个空行（结束符），其中包括回车符和换行符，告知服务器请求头部结束，后面不再有请求头。如果服务器没有收到这个空行则会一直保持连接。
Slow Headers攻击正是利用这一点，攻击者使用GET或POST请求方法与目标服务器建立连接，然后持续发送不包含结束符的HTTP头部报文，目标服务器会一直等待请求头部中的结束符而导致连接始终被占用。如果攻击者控制大量的僵尸主机向目标服务器发起这种攻击，将会导致服务器资源耗尽，无法正常提供服务。
如下图所示，正常的HTTP报文中请求头部的后面会有结束符0x0d0a（\r\n的十六进制表示方式），而攻击报文中不包含结束符，并且攻击者会持续发送不包含结束符的HTTP头部报文，维持连接状态，消耗目标服务器的资源。
Slow Headers攻击行为的特征比较明显，解决方案防御Slow Headers攻击，会对HTTP报文进行检查。如果发现某个源发出的连续多个HTTP GET/POST请求报文的报文头中都没有结束符“\r\n”，则认为发生Slow Headers攻击，将该源IP地址加入黑名单。
Slow POST
Slow POST攻击利用的是POST请求方法，攻击者向目标服务器发送POST请求报文提交数据，数据的长度设置为一个很大的数值，但是在随后的数据发送中，每次只发送很小的报文，这样就是导致目标服务器一直等待攻击者发送数据。如果攻击者控制大量的僵尸主机向目标服务器发起这种攻击，将会导致服务器资源耗尽，无法正常提供服务。
如下图所示，Slow POST攻击报文中，POST请求头部的Content-Length关键字的值设置为8192，表示数据长度为8192字节，但是攻击者后续每次只发送1个字节的报文，导致连接一直被占用，消耗了服务器的资源。
防御Slow POST攻击时，防御方法也是对HTTP报文进行检查。如果发现某个源发出的连续多个HTTP POST请求报文的长度设置的很大，但是实际报文的数据部分长度都很小，则认为发生Slow POST攻击，将该源IP地址加入黑名单。