事情的起因是正常运行的WEB服务突然大面积的访问异常，导致服务断断续续，一会能使用一会异常。

针对此问题进行排查：

1、检测网络(网络正常)

2、防火墙拦截记录并没有看到什么异常信息

3、C:\Windows\System32\LogFiles\HTTPERR下的日志也没有记录到什么有效信息

4、CMD 80端口监听指令[netstat -ano | find]（也并没有发现什么异常情况）

后面采用 [telnet 80] 远程监听端口发现时好时坏，果断关闭外网，外网关闭之后服务恢复正常运行,此时可以确定80端口出现问题，而且跟外网映射有关系，打开外网映射，祭出抓包工具Wireshark果然发现很多异常的TCP请求：

图一                                                           图二

根据图一图二可以看出

源地址通过80端口发送TCP数据包至WEB服务器，在WEB服务器回传消息时源地址拒收消息导致WEB服务器重复发送，导致WEB服务器消息通道堵塞造成WEB服务不可用状态

SYN Flood攻击详细介绍

一般情况下，TCP 连接的建立需要经过三次握手，即： 
（1） TCP 连接请求的发起者向目标服务器发送 SYN 报文； 
（2） 目标服务器收到 SYN 报文后，建立处于 SYN_RECEIVED 状态的 TCP 半连接，并向发起者回复 SYN ACK 报文，等待发起者的回应； 
（3） 发起者收到 SYN ACK 报文后，回应 ACK 报文，这样 TCP 连接就建立起来了。利用 TCP 连接的建立过程，一些恶意的攻击者可以进行 SYN Flood 攻击。攻击者向服务器发送大量请求建立 TCP 连接的 SYN 报文，而不回应服务器的 SYN ACK 报文，导致服务器上建立了大量的 TCP 半连接。从而达到耗费服务器资源，使服务器无法处理正常业务的目的。

暂时性解决方案(不是专业人士，大大的知识盲区哈哈哈哈哈哈哈)：

通过在防火墙上建立IP拦截策略将154.203.xxx.xxx,154.215.xxx.xxx(示例)加入拦截策略中攻击减少WEB服务恢复可用状态，事情得到暂时性解决

网上找到一个针对SYN Flood的防范方案(待验证)：

TCP Proxy 功能用来防止服务器受到 SYN Flood 攻击。客户端通过 TCP 代理请求与受保护的服务器建立连接时，TCP 代理首先验证客户端的请求是否为 SYN Flood 攻击，验证通过后客户端和服务器之间才能建立 TCP 连接，从而避免服务器受到攻击。 
TCP Proxy 支持两种代理方式：单向代理和双向代理。单向代理方式是指仅对 TCP 连接的正向报文进行处理；双向代理是指对 TCP 连接的正向和反向报文都进行处理。用户可以根据实际的组网情况进行选择