（1）从应用层上来看，攻击者每次攻击时，与8300端口都有建立最多两、三百个tcp连接。
（2）从防火墙监控来看，攻击的流量非常微小，以至于防火墙的流量报警都未触发。
（3）每次攻击产生时，原先的玩家的tcp连接并未断开（应用程序未抛出TCP连接断开的异常），但服务端的再也接收不到来自客户端的任何消息。服务端进程的CPU飙到100%，而内存使用未发现异常。
（4）而且服务端也从未接收到来自攻击者的tcp连接的任何消息。
（5）我们对tcp半连接进行了监控，排除了基于tcp的半连接攻击。
（6）重启服务端程序后，一切恢复正常。
我们的动作以及思考：
（1）最开始，我们以为是服务端程序出现问题，导致CPU 100%，后来通过详细检查程序代码，并使用文本日志定时记录程序每个线程的状态（每5秒钟一次），排除了这一可能性。也就是说，在攻击的过程中，服务端内的各个线程的运行都是正常的。（后来，我们进一步确认了这一点 -- 我们在游戏服务器前加了一个简单的tcp代理服务器，游戏服务器不再对外暴露，所有客户端都与代理服务器连接，由代理服务器在游戏服务器和客户端之间转发所有的数据，结果代理服务器被攻击，代理服务器的代理程序进程的cpu达到100%（也是重启代理程序即恢复正常），而游戏服务器进程一直正常）。
（2）排除程序的问题后，我们开始怀疑攻击者攻击的是TCP/IP协议栈（也许是根据TCP/IP的一些漏洞进行攻击），而导致操作系统在处理底层的TCP/IP数据报时，陷入忙碌的状态，而导致CPU 100%，而当底层陷入忙碌的时候，来自客户端的正常消息就来不及接收或者来不及提交到应用层（即我们的服务端程序）了。
我们还未确定，攻击的方式究竟是什么？以前我们碰到的大多是流量攻击，而针对这种低带宽的攻击或TCP/IP漏洞攻击，没有任何经验。不知哪位大侠碰到过类似的情况，能够指点一二，感激不尽了，呵呵
附：我在网上找到了一些可能与我们的攻击有关系的TCP/IP攻击相关的资料，与大家共享一下：
（1）TCP协议堵塞窗口算法攻击技术 ： http://sec.chinabyte.com/207/8816207.shtml
（2）TCP RST攻击 ：http://baike.baidu.com/view/1044719.htm
（3）低速率拒绝服务攻击原理 ： http://blog.chinaunix.com/u/12592/showart_2058363.html
（4）TCP漏洞可导致致命DoS攻击 ：http://sec.chinabyte.com/279/8339279.shtml
（5）泪滴攻击 ： http://baike.soso.com/v4492311.htm
（6）Land攻击 ： http://baike.soso.com/v4194619.htm?pid=baike.box
喜欢 
顶
难过
囧
围观
无聊
