【导语】
本期为大家介绍的是SYN Flood攻击的基本原理。
【SYN Flood】
我们先来看一个片段，感受一下生活场景中发生的那些SYN Flood攻击。Jack因为之前在工作中得到了Alice的很多帮助，所以Jack准备请Alice吃顿晚饭以示感激，于是他们之间发生了如下对话：
Jack：”嗨，晚上有空么，我们一起吃晚饭吧“ (客户端向服务器发送SYN报文，请求建立连接)
Alice：”真的吗?“ (服务器回应SYN ACK报文，确认连接请求)
Jack：”当然是真的，位子都订好了!“ (客户端回应ACK报文，确认建立连接)
最后Alice如期赴约，两人共进晚餐······ (TCP连接建立，传输后续数据报文)
其实一个正常的TCP连接也是经过这三个会话之后建立起来的，其中服务器会在第二次握手中分配数据空间来记录这个连接的信息，并且会维护半开连接条目来等待客户端的确认报文。但是如果迟迟等不到客户端的确认报文，服务器所做的这些动作无疑都是在浪费资源的。我们回到刚才的场景，如果在Jack约Alice之前，Dick对Alice搞恶作剧，那结局可能就不太一样了：
Dick：”嗨，Alice，晚上一起吃晚饭吧“ (客户端向服务器发送SYN报文，请求建立连接)
Alice：”真的吗?” (服务器回应SYN ACK报文，确认连接请求)
······
······
······”
半天过去了，Dick还是杳无音讯。而在这半天里面，Alice一直在边准备边等待Dick的回复，而Jack的邀请也因为这件事情而被Alice拒绝了，一直到了晚上，Alice才对Dick失去了信心，不再等待了。
其实这个就是SYN Flood攻击的基本原理了，Dick的恶作剧导致Alice把时间都花在了准备和等待上，结果是既被Dick欺骗了，也影响了Alice正常的约会邀请。那么被攻击的服务器也是一样，在收到连接建立请求之后会傻傻地等待客户端的ACK确认报文，并为建立连接做好准备。一个无用的连接倒是不会消耗服务器太大的性能，但是如果攻击者发送了海量的恶意SYN报文，那么服务器的资源将会被严重消耗，影响正常服务。
迪普科技异常流量清洗解决方案采用Probe、Guard和UMC三个组件，使用SYN Proxy、SYN Cookie、SYN Reset等技术，通过判断用户的合法性，在源头上阻止了SYN Flood攻击，从而有效地保障了用户业务系统的正常稳定运行。
