对于JAVA调TUXEDO服务，有三种方法：一是通过JNI，二是通过WTC，三是通过JOLT！这三种方式各有优劣，简单的描述为：
JNI
优--无需购买License；发布TUXEDO服务无需做额外限制；无需借助于任何J2EE容器
劣--JNI影响系统移植；防止过度JNI带来性能问题
WTC（WEBLOGIC为TUXEDO定制）
优--因定制，存在一套和TUXEDO API相对应的JAVA API；发布TUXEDO服务无需做额外限制；双向调用
劣--需要购买License；依赖于WEBLOGIC容器，不能移植到其它J2EE容器（如WEBSPHERE，JBOSS）
JOLT
优--可用于但不依赖于J2EE容器（如WEBLOGICWEBSPHERE，JBOSS）；提供的API用WTC类似但不同；
劣--需要购买License；发布TUXEDO服务有些额外的要求；不提供集成的 WebLogic Server-Tuxedo 事务的机制
由此可知，第一，在受限于License经济压力或无法要求UXEDO服务方发布服务的情况下，我们可以选择JNI方式调TUXEDO服务；
第二，当需要一般 Java 客户端或其他 Web 服务器应用程序且 WebLogic Server 不是解决方案的一部分时，用户应使用 Jolt（而不使用 WTC）作为解决方案。
对于jolt方式调TUXEDO服务，3个必须的JAR包：jolt.jar、joltjse.jar、joltwls.jar，下面信息也许对您有帮助：
[转贴]不涉及wls的jolt客户端实现
1、如果不使用wls，同样可以使用jolt提供的pool功能，而这又分为两种：一种是基于web容器的servlet jolt
pool，另一种则是普通java客户端的jolt
pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，后者则未提供。
2、如果不使用jolt产品自带的pool，也可以自己实现。套路为：创建Jolt Session >
基于此session构建JoltRemoteService对象并发起tuxedo调用 >释放jolt
session。这里有个要点就是在使用session前需要用session.isAlive()来判断当前session是否可用，因为JSL的-T
参数及防火墙对idle连接的干扰都可能导致已有的session是无效的。
3、创建JoltRemoteSession时一定记得为三个超时属性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）进行
显式的设置。idle超时和tuxedo的JSL
-T属性对应，该设置将保证session.isAlive()返回正确的布尔值。RECV超时则控制client端自发起call至收到tuxedo
return这一过程的预期时常。
5、tuxedo侧在ubb里为相应的service配置了SVCTIMEOUT，所以service执行超时后会收到SIGKILL而被终止，这样一
来，客户端的call会收到TPESVCERR错，对应的异常为bea.jolt.ServiceException。客户端需要对此异常进行处理，此
外，客户端捕获此异常的时间点应当和ulog中该server被kill的时间点对应。
6、在客户端，时不时会发现由于达到RECVTIMEOUT而导致的客户端接收超时。客户的疑问是：当前RECVTIMEOUT设置为25s，而ubb中
相应SVCTIMEOUT设置为10s且scanunit为默认的10s，所以理论上不应发生25s的客户端RECVTIMEOUT超时。庹达人提出了一
种怀疑，即client端请求抵达tuxedo侧时，server出现排队情况，请求未被及时处理，这个排队时长决定了20s以外的时间差。对于此，建议
客户使用MSSQ，并监控pq的情况。
使用XMLink和Jolt实现IBM WebSphere与BEA Tuxedo的互连 第一部分
使用XMLink和Jolt实现IBM WebSphere与BEA Tuxedo的互连 第二部分
下面，我们重点关注下WTC，WebLogic Tuxedo Connector (WTC) 提供了 WebLogic Server 应用程序与
Tuxedo 服务之间的互操作性。WTC 允许 WebLogic Server 客户端调用 Tuxedo 服务，Tuxedo 客户端调用
WebLogic Server Enterprise Java Bean (EJB) 来响应服务请求，两者之间的简单关联关系如下图：
关于WTC的配置原则和最佳实践可参考下面的链接：
配置准则
最佳实践
为方便记，摘录过来：
配置准则
在配置 WebLogic Tuxedo Connector 时请使用以下准则：
最佳实践
以下部分提供了使用 WTC 时的最佳实践：
请参阅“WebLogic Tuxedo Connector 编程人员指南”中的应用程序错误管理。
请参阅“WebLogic Tuxedo Connector 管理指南”中的系统级调试设置。
将 Security 的值设置为 DM_PW。请参阅“WebLogic
Tuxedo Connector 管理指南”中的远程访问点的身份验证。
启用链接级加密并将 min-encrypt-bits 参数设置为
40，将 max-encrypt-bits 设置为 128。请参阅“WebLogic Tuxedo Connector 管理指南”中的链接级加密。
在 WebLogic Server 群集的所有节点上配置 WTC 实例。
每个群集节点中的每个 WTC 实例都必须具有相同的配置。
请参阅“WebLogic Tuxedo Connector 管理指南”中的如何管理群集环境中的
WebLogic Tuxedo Connector。
在配置连接策略时，请使用 ON_STARTUP 和 INCOMING_ONLY。
ON_STARTUP 和 INCOMING_ONLY 总是成对出现。例如，如果使用 ON_STARTUP 配置了
WTC 远程访问点，则必须将远程访问点的 Tuxedo 域配置的 DM_TDOMAIN 部分配置为 INCOMING_ONLY。在此情况下，WTC
总是充当会话发起方。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置访问点之间的连接。
避免使用连接策略 ON_DEMAND。首选连接策略是 ON_STARTUP 和 INCOMING_ONLY。这样会减少因路由ON_DEMAND 的语义而引起的服务请求失败。请参阅“WebLogic
Tuxedo Connector 管理指南”中的配置访问点之间的连接。
在设计应用程序时，请考虑使用以下 WTC 功能：链接级故障转移、服务级故障转移和负载平衡。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置故障转移和故障回复。
请考虑使用 WebLogic Server 群集提供额外的负载平衡和故障转移。要在 WebLogic Server 群集中使用 WTC，请执行下列操作：
如果 WTC 到 Tuxedo 的连接使用了 Internet，则要使用以下安全设置：
应用程序逻辑应该提供机制来管理和解释应用程序中的错误条件。
避免在 TypedFML32 缓冲区内使用嵌入的 TypedFML32 缓冲区。请参阅“WebLogic
Tuxedo Connector 编程人员指南”中的将 FML 用于 WebLogic Tuxedo
Connector。
如果应用程序处理重负载，请考虑配置更多的远程 Tuxedo 访问点并让 WTC 平衡访问点之间的工作负载。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置故障转移和故障回复。
在使用事务应用程序时，尽量让同一事务中涉及的远程服务能够从同一远程访问点访问。请参阅“WebLogic Tuxedo Connector 编程人员指南”中的 WebLogic
Tuxedo Connector JATMI 事务。
从网关调度服务时，可用的客户端线程数可能会限制运行的并发服务数。没有任何 WebLogic Tuxedo Connector 特性可以增加可用线程的数量。在调用服务时请使用合理的线程模型。请参阅“配置
WebLogic Server 环境”中的线程管理和使用工作管理器优化调度的工作。
WebLogic Server 9.2 及更高版本提供了改进的路由算法，这增强了事务性能。具体说就是，当 2 阶段提交 (2PC) 事务中具有不止一项 Tuxedo 服务请求时，性能就会相应提高。如果应用程序仅向
Tuxedo 域执行单个服务请求，则可以通过设置以下 WebLogic Server 命令行参数来禁用此功能：
通过在缓冲区中使用最大数量的对象来调用构造方法 TypedFML32。即使是很难预测最大数量，提供合理的数量也可以提高性能。可以通过将字段的数量乘以
1.33 得到近似的最大数量。
注意：
注意，此性能提示不应用于 TypedFML 缓冲区类型。
例如：
如果在 TypedFML32 缓冲区类型中有 50 个字段，那么最大数量就是
63。调用构造方法 TypedFML32(63, 50) 比 TypedFML32() 执行得更好。
如果在 TypedFML32 缓冲区类型中有 50 个字段，并且每个字段最多可以有
10 个事件，则调用构造方法 TypedFML32(625, 50) 将会有比 TypedFML32() 更好的性能。
当配置 Tuxedo 应用程序（这些应用程序可以作为与 WTC 客户端互操作的服务器）时，请考虑平行问题，这一点可以通过在不同 Tuxedo 计算机上仔细配置不同服务器来实现。
要知道在 Tuxedo 应用程序中可能会存在数据库访问死锁现象。可以通过认真配置 Tuxedo 应用程序来避免死锁现象。
如果正在使用 WTC 负载平衡或服务级故障转移，BEA 建议不要禁用 WTC 事务关系。
针对负载平衡出站请求，为导入服务配置使用不同密钥的多个条目。导入服务将使用复合密钥来确定每个记录的唯一性。复合密钥的构成：服务名称 + 本地访问点 + 远程访问点列表中的主要路由。
下面是一个如何为 service1 在 TDomainSession(WDOM1,TUXDOM1) 和TDomainSession(WDOM1,TUXDOM2) 之间正确配置负载平衡请求的示例：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM2
TOLOWER2
下面是一个错误配置负载平衡请求的示例。下面的配置会导致 service1 具有相同的复合密钥：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM1
TOLOWER
在建立连接/会话前更改该会话/连接配置（本地 AP、远程 AP、密码和资源）：
接受更改并在新的会话/连接中实现这些更改。
在建立连接/会话后更改该会话/连接配置（本地 AP、远程 AP、密码和资源）：
接受更改，但是要到连接断开并重新连接后，才在现有的连接/会话中实现这些更改。请参阅“管理控制台联机帮助”中的定位
WTC 服务。
更改导入和导出服务配置：
接受更改并在下一个入站或出站请求中实现这些更改。BEA 建议不要使用此做法，因为这会让正在进行的请求处于未知状态。
更改 tBridge 配置：
对已部署的 WTC 服务进行任何更改都会导致异常。在进行任何 tBridge 配置更改前都必须先取消对 WTC 服务的定位。在取消定位和进行配置更改后，必须定位 WTC 服务以便实现更改。
在配置中可以有多种 WTC 服务。
只能将一种 WTC 服务定位到服务器实例。
WTC 不支持连接缓冲池。WTC 通过单个物理连接多路传输请求。
配置更改可按照如下方式实现：
一、为何要DDOS?
随着Internet互联网络带宽的增加和多种DDOS黑客工具的不断发布，DDOS拒绝服务攻击的实施越来越容易，DDOS攻击事件正在成上升趋势。出于商业竞争、打击报复和网络敲诈等多种因素，导致很多IDC托管机房、商业站点、游戏服务器、聊天网络等网络服务商长期以来一直被DDOS攻击所困扰，随之而来的是客户投诉、同虚拟主机用户受牵连、法律纠纷、商业损失等一系列问题，因此，解决DDOS攻击问题成为网络服务商必须考虑的头等大事。
2
二、什么是DDOS?
DDOS是英文Distributed Denial of Service的缩写，意即“分布式拒绝服务”，那么什么又是拒绝服务(Denial of Service)呢?可以这么理解，凡是能导致合法用户不能够访问正常网络服务的行为都算是拒绝服务攻击。也就是说拒绝服务攻击的目的非常明确，就是要阻止合法用户对正常网络资源的访问，从而达成攻击者不可告人的目的。虽然同样是拒绝服务攻击，但是DDOS和DOS还是有所不同，DDOS的攻击策略侧重于通过很多“僵尸主机”(被攻击者入侵过或可间接利用的主机)向受害主机发送大量看似合法的网络包，从而造成网络阻塞或服务器资源耗尽而导致拒绝服务，分布式拒绝服务攻击一旦被实施，攻击网络包就会犹如洪水般涌向受害主机，从而把合法用户的网络包淹没，导致合法用户无法正常访问服务器的网络资源，因此，拒绝服务攻击又被称之为“洪水式攻击”，常见的DDOS攻击手段有SYN Flood、ACK Flood、UDP Flood、ICMP Flood、TCP Flood、Connections Flood、Script Flood、Proxy Flood等而DOS则侧重于通过对主机特定漏洞的利用攻击导致网络栈失效、系统崩溃、主机死机而无法提供正常的网络服务功能，从而造成拒绝服务，常见的DOS攻击手段有TearDrop、Land、Jolt、IGMP Nuker、Boink、Smurf、Bonk、OOB等。就这两种拒绝服务攻击而言，危害较大的主要是DDOS攻击，原因是很难防范，至于DOS攻击，通过给主机服务器打补丁或安装防火墙软件就可以很好地防范，后文会详细介绍怎么对付DDOS攻击。
3
三、被DDOS了吗?
DDOS的表现形式主要有两种，一种为流量攻击，主要是针对网络带宽的攻击，即大量攻击包导致网络带宽被阻塞，合法网络包被虚假的攻击包淹没而无法到达主机另一种为资源耗尽攻击，主要是针对服务器主机的攻击，即通过大量攻击包导致主机的内存被耗尽或CPU被内核及应用程序占完而造成无法提供网络服务。
如何判断网站是否遭受了流量攻击呢?可通过Ping命令来测试，若发现Ping超时或丢包严重(假定平时是正常的)，则可能遭受了流量攻击，此时若发现和你的主机接在同一交换机上的服务器也访问不了了，基本可以确定是遭受了流量攻击。当然，这样测试的前提是你到服务器主机之间的ICMP协议没有被路由器和防火墙等设备屏蔽，否则可采取Telnet主机服务器的网络服务端口来测试，效果是一样的。不过有一点可以肯定，假如平时Ping你的主机服务器和接在同一交换机上的主机服务器都是正常的，突然都Ping不通了或者是严重丢包，那么假如可以排除网络故障因素的话则肯定是遭受了流量攻击，再一个流量攻击的典型现象是，一旦遭受流量攻击，会发现用远程终端连接网站服务器会失败。
相对于流量攻击而言，资源耗尽攻击要容易判断一些，假如平时Ping网站主机和访问网站都是正常的，发现突然网站访问非常缓慢或无法访问了，而Ping还可以Ping通，则很可能遭受了资源耗尽攻击，此时若在服务器上用Netstat -na命令观察到有大量的SYN_RECEIVED、TIME_WAIT、FIN_WAIT_1等状态存在，而ESTABLISHED很少，则可判定肯定是遭受了资源耗尽攻击。还有一种属于资源耗尽攻击的现象是，Ping自己的网站主机Ping不通或者是丢包严重，而Ping与自己的主机在同一交换机上的服务器则正常，造成这种原因是网站主机遭受攻击后导致系统内核或某些应用程序CPU利用率达到100%无法回应Ping命令，其实带宽还是有的，否则就Ping不通接在同一交换机上的主机了。
4
当前主要有三种流行的DDOS攻击：
1、SYN/ACK Flood攻击：这种攻击方法是经典最有效的DDOS方法，可通杀各种系统的网络服务，主要是通过向受害主机发送大量伪造源IP和源端口的SYN或ACK包，导致主机的缓存资源被耗尽或忙于发送回应包而造成拒绝服务，由于源都是伪造的故追踪起来比较困难，缺点是实施起来有一定难度，需要高带宽的僵尸主机支持。少量的这种攻击会导致主机服务器无法访问，但却可以Ping的通，在服务器上用Netstat -na命令会观察到存在大量的SYN_RECEIVED状态，大量的这种攻击会导致Ping失败、TCP/IP栈失效，并会出现系统凝固现象，即不响应键盘和鼠标。普通防火墙大多无法抵御此种攻击。
2、TCP全连接攻击：这种攻击是为了绕过常规防火墙的检查而设计的，一般情况下，常规防火墙大多具备过滤TearDrop、Land等DOS攻击的能力，但对于正常的TCP连接是放过的，殊不知很多网络服务程序(如：IIS、Apache等Web服务器)能接受的TCP连接数是有限的，一旦有大量的TCP连接，即便是正常的，也会导致网站访问非常缓慢甚至无法访问，TCP全连接攻击就是通过许多僵尸主机不断地与受害服务器建立大量的TCP连接，直到服务器的内存等资源被耗尽而被拖跨，从而造成拒绝服务，这种攻击的特点是可绕过一般防火墙的防护而达到攻击目的，缺点是需要找很多僵尸主机，并且由于僵尸主机的IP是暴露的，因此容易被追踪。
3、刷Script脚本攻击：这种攻击主要是针对存在ASP、JSP、PHP、CGI等脚本程序，并调用MSSQLServer、MySQLServer、Oracle等数据库的网站系统而设计的，特征是和服务器建立正常的TCP连接，并不断的向脚本程序提交查询、列表等大量耗费数据库资源的调用，典型的以小博大的攻击方法。一般来说，提交一个GET或POST指令对客户端的耗费和带宽的占用是几乎可以忽略的，而服务器为处理此请求却可能要从上万条记录中去查出某个记录，这种处理过程对资源的耗费是很大的，常见的数据库服务器很少能支持数百个查询指令同时执行，而这对于客户端来说却是轻而易举的，因此攻击者只需通过Proxy代理向主机服务器大量递交查询指令，只需数分钟就会把服务器资源消耗掉而导致拒绝服务，常见的现象就是网站慢如蜗牛、ASP程序失效、PHP连接数据库失败、数据库主程序占用CPU偏高。这种攻击的特点是可以完全绕过普通的防火墙防护，轻松找一些Proxy代理就可实施攻击，缺点是对付只有静态页面的网站效果会大打折扣，并且有些Proxy会暴露攻击者的IP地址。
5
四、怎么抵御DDOS?
对付DDOS是一个系统工程，想仅仅依靠某种系统或产品防住DDOS是不现实的，可以肯定的是，完全杜绝DDOS目前是不可能的，但通过适当的措施抵御90%的DDOS攻击是可以做到的，基于攻击和防御都有成本开销的缘故，若通过适当的办法增强了抵御DDOS的能力，也就意味着加大了攻击者的攻击成本，那么绝大多数攻击者将无法继续下去而放弃，也就相当于成功的抵御了DDOS攻击。以下几点是防御DDOS攻击几点：
1、采用高性能的网络设备
首先要保证网络设备不能成为瓶颈，因此选择路由器、交换机、硬件防火墙等设备的时候要尽量选用知名度高、口碑好的产品。再就是假如和网络提供商有特殊关系或协议的话就更好了，当大量攻击发生的时候请他们在网络接点处做一下流量限制来对抗某些种类的DDOS攻击是非常有效的。
2、尽量避免NAT的使用
无论是路由器还是硬件防护墙设备要尽量避免采用网络地址转换NAT的使用，因为采用此技术会较大降低网络通信能力，其实原因很简单，因为NAT需要对地址来回转换，转换过程中需要对网络包的校验和进行计算，因此浪费了很多CPU的时间，但有些时候必须使用NAT，那就没有好办法了。
3、充足的网络带宽保证
网络带宽直接决定了能抗受攻击的能力，假若仅仅有10M带宽的话，无论采取什么措施都很难对抗现在的SYNFlood攻击，当前至少要选择100M的共享带宽，最好的当然是挂在1000M的主干上了。但需要注意的是，主机上的网卡是1000M的并不意味着它的网络带宽就是千兆的，若把它接在100M的交换机上，它的实际带宽不会超过100M，再就是接在100M的带宽上也不等于就有了百兆的带宽，因为网络服务商很可能会在交换机上限制实际带宽为10M，这点一定要搞清楚。
4、升级主机服务器硬件
在有网络带宽保证的前提下，请尽量提升硬件配置，要有效对抗每秒10万个SYN攻击包，服务器的配置至少应该为：P4 2.4G/DDR512M/SCSI-HD，起关键作用的主要是CPU和内存，若有志强双CPU的话就用它吧，内存一定要选择DDR的高速内存，硬盘要尽量选择SCSI的，别只贪IDE价格不贵量还足的便宜，否则会付出高昂的性能代价，再就是网卡一定要选用3COM或Intel等名牌的，若是Realtek的还是用在自己的PC上吧。
5、把网站做成静态页面
大量事实证明，把网站尽可能做成静态页面，不仅能大大提高抗攻击能力，而且还给黑客入侵带来不少麻烦，至少到现在为止关于HTML的溢出还没出现，看看吧!新浪、搜狐、网易等门户网站主要都是静态页面，若你非需要动态脚本调用，那就把它弄到另外一台单独主机去，免的遭受攻击时连累主服务器，当然，适当放一些不做数据库调用脚本还是可以的，此外，最好在需要调用数据库的脚本中拒绝使用代理的访问，因为经验表明使用代理访问你网站的80%属于恶意行为。
6、增强操作系统的TCP/IP栈
Win2000和Win2003作为服务器操作系统，本身就具备一定的抵抗DDOS攻击的能力，只是默认状态下没有开启而已，若开启的话可抵挡约10000个SYN攻击包，若没有开启则仅能抵御数百个，具体怎么开启，自己去看微软的文章吧!《强化 TCP/IP 堆栈安全》。
也许有的人会问，那我用的是Linux和FreeBSD怎么办?很简单，按照这篇文章去做吧!《SYN Cookies》。
7、安装专业抗DDOS防火墙
8、其他防御措施
拒绝服务攻击即攻击者想办法让目标机器停止提供服务或资源访问。这些资源包括磁盘空间、内存、进程甚至网络带宽，从而阻止正常用户的访问。其实对网络带宽进行的消耗性攻击只是拒绝服务攻击的一小部分，只要能够对目标造成麻烦，使某些服务被暂停甚至主机死机，都属于拒绝服务攻击。拒绝服务攻击问题也一直得不到合理的解决，究其原因是因为这是由于网络协议本身的安全缺陷造成的，从而拒绝服务攻击也成为了攻击者的终极手法。攻击者进行拒绝服务攻击，实际上让服务器实现两种效果：一是迫使服务器的缓冲区满，不接收新的请求；二是使用IP欺骗，迫使服务器把合法用户的连接复位，影响合法用户的连接。
DDOS（分布式拒绝服务）：凡是能导致合法用户不能够访问正常网络服务的行为都算是拒绝服务攻击。 也就是说拒绝服务攻击的目的非常明确，就是要阻止合法用户对正常网络资源的访问，从而达成攻击者不可告人的目的。虽然同样是拒绝服务攻击，但是DDOS 和DOS 还是有所不同，DDOS的攻击策略侧重于通过很多“僵尸主机”（被攻击者入侵过或可间接利用的主机）向受害主机发送大量看似合法的网络包， 从而造成网络阻塞或服务器资源耗尽而导致拒绝服务， 分布式拒绝服务攻击一旦被实施， 攻击网络包就会犹如洪水般涌向受害主机， 从而把合法用户的网络包淹没， 导致合法用户无法正常访问服务器的网络资源， 因此， 拒绝服务攻击又被称之为 “洪水式攻击” ，常见的 DDOS 攻击手段有 SYN Flood、ACK Flood、UDP Flood、ICMP Flood、TCP Flood、Connections Flood、Script Flood、Proxy Flood 等；而 DOS 则侧重于通过对主机特定漏洞的利用攻击导致网络栈失效、系统崩溃、 主机死机而无法提供正常的网络服务功能， 从而造成拒绝服务， 常见的 DOS 攻击手段有 T earDrop、 Land、 Jolt、 IGMP Nuker、 Boink、 Smurf、 Bonk、OOB 等。就这两种拒绝服务攻击而言，危害较大的主要是 DDOS 攻击，原因是很难防范，至于 DOS 攻击，通过给主机服务器打补丁或安装防火墙软件就可以很好地防范DDOS 的表现形式主要有两种，一种为流量攻击，主要是针对网络带宽的攻击，即大量攻击包导致网络带宽被阻塞， 合法网络包被虚假的攻击包淹没而无法到达主机； 另一种为资源耗尽攻击，主要是针对服务器主机的攻击，即通过大量攻击包导致主机的内存被耗尽或CPU 被内核及应用程序占完，造成的无法提供网络服务。
如何判断网站是否遭受了流量攻击可通过 Ping 命令来测试，若发现 Ping 超时或丢包严重(假定平时是正常的)，则可能遭受了流量攻击，此时若发现和你的主机接在同一交换机上的服务器也访问不了， 基本可以确定是遭受了流量攻击。 当然， 这样测试的前提是你到服务器主机之间的 ICMP 协议没有被路由器和防火墙等设备屏蔽， 否则可采取 T elnet 主机服务器的网络服务端口来测试，效果是一样的。不过有一点可以肯定，假如平时 Ping 你的主机服务器和接在同一交换机上的主机服务器都是正常的，突然都 Ping 不通了或者是严重丢包，那么假如可以排除网络故障因素的话则肯定是遭受了流量攻击，再一个流量攻击的典型现象是，一旦遭受流量攻击，会发现用远程终端连接网站服务器会失败。相对于流量攻击而言， 资源耗尽攻击要容易判断一些， 假如平时 Ping 网站主机和访问网站都是正常的，发现突然网站访问非常缓慢或无法访问了，而 Ping 还可以 Ping 通，则很可能遭受了资源耗尽攻击 ，此时若在服务器上用Nistat -na命令观察到有大量的SYN_RECEIVED、TIME_W AIT、FIN_W AIT_1 等状态存在，而EST BLISHED 很少，则可判定肯定是遭受了资源耗尽攻击。还有一种属于资源耗尽攻击的现象是，Ping 自己的网站主机 Ping 不通或者是丢包严重，而 Ping 与自己的主机在同一交换机上的服务器则正常，造成这种原因是网站主机遭受攻击后导致系统内核或某些应用程序 CPU 利用率达到 100%无法回应 Ping 命令，其实带宽还是有的，否则就 Ping 不通接在同一交换机上的主机了。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）