这两天在例行服务器的检查时发现有一个ip地址的连接数有近2000个，且一直呈FIN_WAIT2状态，在对系统日志及相关内容进行检查后并无发现异常，好在我们服务器已经做过相关的调优，这些连接并无大碍，重新检查服务器相关内核参数之后顺便查了一下关于ddos的相关文档，下面是关于windows系统和Linux/Unix系统内核的调整，一起贴上来，以便自己日后查看，希望能方便有此需要的朋友们
每次vi的时候总是想不起来一些指令，为了方便记忆，也为了方便大家，找了一个完整版指令集贴上来
vi指令說明(完整版)
.vi 的操作模式
==============
vi 提供兩種操作模式：輸入模式(insert mode)和指令模式(command mode)
。當使用者進入 vi 後，即處在指令模式下，此刻鍵入之任何字元皆被視為
指令。在此模式下可進行刪除、修改等動作。若要輸入資料，則需進入輸入
模式。
.輸入模式
=========
如何進入輸入模式
a (append) 由游標之後加入資料。
A 由該行之末加入資料。
i (insert) 由游標之前加入資料。
I 由該行之首加入資料。
o (open) 新增一行於該行之下供輸入資料之用。
O 新增一行於該行之上供輸入資料之用。
如何離開輸入模式
《ESC》 結束輸入模式。
vi指令說明(完整版)
.vi 的操作模式
==============
vi 提供兩種操作模式：輸入模式(insert mode)和指令模式(command mode)
。當使用者進入 vi 後，即處在指令模式下，此刻鍵入之任何字元皆被視為
指令。在此模式下可進行刪除、修改等動作。若要輸入資料，則需進入輸入
模式。
.輸入模式
=========
如何進入輸入模式
a (append) 由游標之後加入資料。
A 由該行之末加入資料。
i (insert) 由游標之前加入資料。
I 由該行之首加入資料。
o (open) 新增一行於該行之下供輸入資料之用。
O 新增一行於該行之上供輸入資料之用。
如何離開輸入模式
《ESC》 結束輸入模式。
1．引言
本质上讲，网络负载平衡是分布式作业调度系统的一种实现。平衡器作为网络请求分配的控制者，要根据集群节点的当前处理能力，采用集中或分布策略对网络服务请求进行调配，并且在每个服务请求的生命周期里监控各个节点的有效状态。一般的说，平衡器对请求的调度具备以下的特征：
网络服务请求必须是可管理的
请求的分配对用户是透明的
最好能够提供异构系统的支持
能够依据集群节点的资源情况进行动态分配和调整
负载平衡器在集群的各个服务节点中分配工作负载或网络流量。可以静态预先设置或根据当前的网络状态来决定负载分发到哪个特定的节点，节点在集群内部可以互相连接，但它们必须与平衡器直接或间接相连。
网络平衡器可以认为是网络层次上的作业调度系统，大多数网络负载平衡器能够在网络的相应层次上实现单一系统映像，整个集群能够体现为一个单一的IP地址被用户访问，而具体服务的节点对用户而言是透明的。这里，平衡器可静态或动态配置，用一种或多种算法决定哪个节点获得下一个网络服务请求。
本质上讲，网络负载平衡是分布式作业调度系统的一种实现。平衡器作为网络请求分配的控制者，要根据集群节点的当前处理能力，采用集中或分布策略对网络服务请求进行调配，并且在每个服务请求的生命周期里监控各个节点的有效状态。一般的说，平衡器对请求的调度具备以下的特征：
网络服务请求必须是可管理的
请求的分配对用户是透明的
最好能够提供异构系统的支持
能够依据集群节点的资源情况进行动态分配和调整
负载平衡器在集群的各个服务节点中分配工作负载或网络流量。可以静态预先设置或根据当前的网络状态来决定负载分发到哪个特定的节点，节点在集群内部可以互相连接，但它们必须与平衡器直接或间接相连。
网络平衡器可以认为是网络层次上的作业调度系统，大多数网络负载平衡器能够在网络的相应层次上实现单一系统映像，整个集群能够体现为一个单一的IP地址被用户访问，而具体服务的节点对用户而言是透明的。这里，平衡器可静态或动态配置，用一种或多种算法决定哪个节点获得下一个网络服务请求。
五. 容量计划
容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。
这里先对提及的容量计划作一个简要的定义：容量计划是指评估硬件、操作系统和网络带宽，确定应用服务的服务范围，寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不仅包括Tomcat，也包括与Tomcat结合使用的任何第三方web服务器软件。
如果在购买软硬件或部署系统前你对容量计划一无所知，不知道现有的软硬件环境能够支撑多少的访问量，甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行变更可能为时已晚。此时只能增加硬件投入，增加硬盘容量甚至购买更好的服务器。如果事先做了容量计划那么就不会搞的如此焦头烂额了。
我们这里只介绍与Tomcat相关的内容。
首先为了确定Tomcat使用机器的容量计划，你应该从一下列表项目种着手研究和计划：
容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。
这里先对提及的容量计划作一个简要的定义：容量计划是指评估硬件、操作系统和网络带宽，确定应用服务的服务范围，寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不仅包括Tomcat，也包括与Tomcat结合使用的任何第三方web服务器软件。
如果在购买软硬件或部署系统前你对容量计划一无所知，不知道现有的软硬件环境能够支撑多少的访问量，甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行变更可能为时已晚。此时只能增加硬件投入，增加硬盘容量甚至购买更好的服务器。如果事先做了容量计划那么就不会搞的如此焦头烂额了。
我们这里只介绍与Tomcat相关的内容。
首先为了确定Tomcat使用机器的容量计划，你应该从一下列表项目种着手研究和计划：
