各位老铁们，大家好，今天由我来为大家分享服务器被流量的解决方法，以及服务器流量突然过高怎么解决的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
一、服务器流量突然过高怎么解决
在使用服务器的过程中，经常会碰到流量异常，时不时的流量很高。遇到这样的情况，可能是以下几点原因：
1.服务器被暴力
2.服务器被攻击DD/CC
遇到这种情况，该如何分析呢？
一、首先，可以先登录服务器里面检查服务器日志，看看是否有IP多次异常登录并显示登录失败的请求，如果显示多次登录失败，说明有人正在尝试暴力登录你的服务器，占用了你过多的带宽资源。解决办法：把异常请求的IP加入到防火墙的黑名单中；端口改成随机5位，尽量复杂些；密码更改复杂些，安全系数高避免被恶意。若已经被暴力了，建议重装下系统。不管怎样，预防大于治疗，提前做好安全防护措施是非常有必要的。
二、其次，检查下服务器的80端口连接数，看看80端口连接数是不是很多，这个要结合用户自己平常对访问流量的一个掌握，一般情况下80连接数几百是正常的，假如上千到万了，很有可能就是被攻击导致的流量异常。那如何查看80连接数呢？如何查看80端口连接数：Windows系统：在运行cmd里面输入此命令：stat-ano|findstr"8080"或者stat-an|find/c":80"Linux系统：stat-nat|grep-i'80'|wc-l
那又有什么解决办法呢。若是被攻击了导致的流量异常，一般情况下服务器商会封掉被攻击的IP，等没有被攻击了，一定时间后会自动解封。这里要判别下是打IP还是打网站，可以把被攻击的IP下的站解析到其他的IP下。若这个换过的IP还是被打，很有可能是网站被攻击，一般情况下都是同行竞争引起的，这个时候建议使用高防类的服务器。若是换了IP，之前的被攻击的IP还是被打，那可能是打IP，可以找服务器商更换IP。这是日常工作总结出来的，欢迎共同交流，一起学习成长哈。
二、服务器流量堵塞如何防御
由于DDoS攻击往往采取合法的数据请求技术，再加上傀儡机器，造成DDoS攻击成为目前最难防御的网络攻击之一。据美国最新的安全损失调查报告，DDoS攻击所造成的经济损失已经跃居第一。传统的网络设备和周边安全技术，例如防火墙和IDSs(Intrusion Detection Systems)，速率限制，接入限制等均无法提供非常有效的针对DDoS攻击的保护，需要一个新的体系结构和技术来抵御复杂的DDoS拒绝服务攻击。
DDoS攻击揭秘
DDoS攻击主要是利用了inter协议和inter基本优点——无偏差地从任何的源头传送数据包到任意目的地。
DDoS攻击分为两种：要么大数据，大流量来压垮网络设备和服务器，要么有意制造大量无法完成的不完全请求来快速耗尽服务器资源。有效防止DDoS攻击的关键困难是无法将攻击包从合法*区分出来：IDS进行的典型“签名”模式匹配起不到有效的作用；许多攻击使用源IP*来逃脱源识别，很难搜寻特定的攻击源头。
有两类最基本的DDoS攻击：
●带宽攻击：这种攻击消耗网络带宽或使用大量数据包淹没一个或多个路由器、服务器和防火墙；带宽攻击的普遍形式是大量表面看合法的TCP、UDP或ICMP数据包被传送到特定目的地；为了使检测更加困难，这种攻击也常常使用源*，并不停地变化。
●应用攻击：利用TCP和HTTP等协议定义的行为来不断占用计算资源以阻止它们处理正常事务和请求。HTTP半开和HTTP错误就是应用攻击的两个典型例子。
DDoS威胁日益致命
DDoS攻击的一个致命趋势是使用复杂的*技术和基本协议，如HTTP，Email等协议，而不是采用可被阻断的非基本协议或高端口协议，非常难识别和防御，通常采用的包过滤或限制速率的措施只是通过停止服务来简单停止攻击任务，但同时合法用户的请求也被拒绝，造成业务的中断或服务质量的下降；DDoS事件的突发*，往往在很短的时间内，大量的DDoS攻击数据就可是网络资源和服务资源消耗殆尽。
现在的DDoS防御手段不够完善
不管哪种DDoS攻击，，当前的技术都不足以很好的抵御。现在流行的DDoS防御手段——例如黑洞技术和路由器过滤，限速等手段，不仅慢，消耗大，而且同时也阻断有效业务。如IDS*监测可以提供一些检测*能但不能缓解DDoS攻击，防火墙提供的保护也受到其技术弱点的限制。其它策略，例如大量部署服务器，冗余设备，保证足够的响应能力来提供攻击防护，代价过于高昂。
黑洞技术
黑洞技术描述了一个服务提供商将指向某一目标企业的包尽量阻截在上游的过程，将改向的包引进“黑洞”并丢弃，以保全运营商的基础网络和其它的客户业务。但是合法数据包和恶意攻击业务一起被丢弃，所以黑洞技术不能算是一种好的解决方案。被攻击者失去了所有的业务服务，攻击者因而获得胜利。
路由器
许多人运用路由器的过滤功能提供对DDoS攻击的防御，但对于现在复杂的DDoS攻击不能提供完善的防御。
路由器只能通过过滤非基本的不需要的协议来停止一些简单的DDoS攻击，例如ping攻击。这需要一个手动的反应措施，并且往往是在攻击致使服务失败之后。另外，现在的DDoS攻击使用互联网必要的有效协议，很难有效的滤除。路由器也能防止无效的或私有的IP空间，但DDoS攻击可以很容易的伪造成有效IP。
基于路由器的DDoS预防策略——在出口侧使用uRPF来停止IP*攻击——这同样不能有效防御现在的DDoS攻击，因为uRPF的基本原理是如果IP不属于应该来自的子网网络阻断出口业务。然而，DDoS攻击能很容易伪造来自同一子网的IP，致使这种解决法案无效。
本质上，对于种类繁多的使用有效协议的*攻击，路由器ACLs是无效的。包括：
● SYN、SYN-ACK、FIN等洪流。
●服务代理。因为一个ACL不能辨别来自于同一源IP或代理的正当SYN和恶意SYN，所以会通过阻断受害者所有来自于某一源IP或代理的用户来尝试停止这一集中*攻击。
● DNS或BGP。当发起这类随机*DNS服务器或BGP路由器攻击时，ACLs——类似于SYN洪流——无法验证哪些是合法的，哪些是*的。
ACLs在防御应用层（客户端）攻击时也是无效的，无论*与否，ACLs理论上能阻断客户端攻击——例如HTTP错误和HTTP半开连接攻击，假如攻击和单独的非*源能被精确的监测——将要求用户对每一受害者配置数百甚至数千ACLs，这其实是无法实际实施的。
防火墙
首先防火墙的位置处于数据路径下游远端，不能为从提供商到企业边缘路由器的访问链路提供足够的保护，从而将那些易受攻击的组件留给了DDoS攻击。此外，因为防火墙总是串联的而成为潜在*能瓶颈，因为可以通过消耗它们的会话处理能力来对它们自身进行DDoS攻击。
其次是反常事件检测缺乏的限制，防火墙首要任务是要控制私有网络的访问。一种实现的方法是通过追踪从内侧向外侧服务发起的会话，然后只接收“不干净”一侧期望源头发来的特定响应。然而，这对于一些开放给公众来接收请求的服务是不起作用的，比如Web、DNS和其它服务，因为*可以使用“被认可的”协议（如HTTP）。
第三种限制，虽然防火墙能检测反常行为，但几乎没有反*能力——其结构仍然是攻击者达到其目的。当一个DDoS攻击被检测到，防火墙能停止与攻击相联系的某一特定数据流，但它们无法逐个包检测，将好的或合法业务从恶意业务中分出，使得它们在事实上对IP*攻击无效。
IDS*监测
IDS解决方案将不得不提供领先的行为或基于反常事务的算法来检测现在的DDoS攻击。但是一些基于反常事务的*能要求有专家进行手动的调整，而且经常误报，并且不能识别特定的攻击流。同时IDS本身也很容易成为DDoS攻击的牺牲者。
作为DDoS防御平台的IDS最大的缺点是它只能检测到攻击，但对于缓和攻击的影响却毫无作为。IDS解决方案也许能托付给路由器和防火墙的过滤器，但正如前面叙述的，这对于缓解DDoS攻击效率很低，即便是用类似于静态过滤串联部署的IDS也做不到。
DDoS攻击的手动响应
作为DDoS防御一部份的手动处理太微小并且太缓慢。受害者对DDoS攻击的典型第一反应是询问最近的上游连接提供者——ISP、宿主提供商或骨干网承载商——尝试识别该消息来源。对于*的情况，尝试识别消息来源是一个长期和冗长的过程，需要许多提供商合作和追踪的过程。即使来源可被识别，但阻断它也意味同时阻断所有业务——好的和坏的。
其他策略
为了忍受DDoS攻击，可能考虑了这样的策略，例如过量供应，就是购买超量带宽或超量的网络设备来处理任何请求。这种方法成本效益比较低，尤其是因为它要求附加冗余接口和设备。不考虑最初的作用，攻击者仅仅通过增加攻击容量就可击败额外的硬件，互联网上上千万台的机器是他们取之不净的攻击容量资源。
有效抵御DDoS攻击
从事于DDoS攻击防御需要一种全新的方法，不仅能检测复杂*和**日益增加的攻击，而且要有效抵御攻击的影响。
完整的DDoS保护围绕四个关键主题建立：
1．要缓解攻击，而不只是检测
2．从恶意业务中精确辨认出好的业务，维持业务继续进行，而不只是检测攻击的存在
3．内含*能和体系结构能对上游进行配置，保护所有易受损点
4．维持可靠*和成本效益可升级*
建立在这些构想上的DDoS防御具有以下保护*质：
通过完整的检测和阻断机制立即响应DDoS攻击，即使在攻击者的身份和轮廓不
断变化的情况下。
与现有的静态路由过滤器或IDS签名相比，能提供更完整的验证*能。
提供基于行为的反常事件识别来检测含有恶意意图的有效包。
识别和阻断个别的*包，保护合法商务交易。
提供能处理大量DDoS攻击但不影响被保护资源的机制。
攻击期间能按需求布署保护，不会引进故障点或增加串联策略的瓶颈点。
内置智能只处理被感染的业务流，确保可靠*最大化和花销比例最小化。
避免依赖网络设备或配置转换。
所有通信使用标准协议，确保互操作*和可靠*最大化。
完整DDoS保护解决技术体系
基于检测、转移、验证和转发的基础上实施一个完整DDoS保护解决方案来提供完全保护，通过下列措施维持业务不间断进行：
1．时实检测DDoS停止服务攻击攻击。
2．转移指向目标设备的数据业务到特定的DDoS攻击防护设备进行处理。
3．从好的数据*分析和过滤出不好的数据包，阻止恶意业务影响*能，同时允许合法业务的处理。
4．转发正常业务来维持商务持续进行。
三、WEB服务器流量超负载问题解决方法
WEB服务器流量超负载问题解决方法
Web应用服务器集群系统，是由一群同时运行同一个web应用的服务器组成的集群系统，在外界看来，就像是一个服务器一样。为了均衡集群服务器的负载，达到优化系统*能的目的，集群服务器将众多的访问请求，分散到系统中的不同节点进行处理。从而实现了更高的有效*和稳定*，而这也正是基于Web的企业应用所必须具备的特*。
一、计算WEB服务器负载量的两种方法
web应用服务器集群系统，是由一群同时运行同一个web应用的服务器组成的集群系统，在外界看来，就像是一个服务器一样。为了均衡集群服务器的负载，达到优化系统*能的目的，集群服务器将众多的访问请求，分散到系统中的不同节点进行处理。从而实现了更高的有效*和稳定*，而这也正是基于Web的企业应用所必须具备的特*。
高可靠*可以看作为系统的一种冗余设定。对于一个特定的请求，如果所申请的服务器不能进行处理的话，那么其他的服务器能不能对之进行有效的处理呢？对于一个高效的系统，如果一个Web服务器失败的话，其他的服务器可以马上取代它的位置，对所申请的请求进行处理，而且这一过程对用户来说，要尽可能的透明，使用户察觉不到！
稳定*决定了应用程序能否支持不断增长的用户请求数量，它是应用程序自身的一种能力。稳定*是影响系统*能的众多因素的一种有效的测量手段，包括机群系统所能支持的同时访问系统的最大用户数目以及处理一个请求所需要的时间。
在现有众多的均衡服务器负载的方法中，广泛研究并使用的是以下两个方法：
DNS负载平衡的方法RR-DNS(Round-Robin Domain Name System)
负载均衡器
以下，我们将就这两种方法进行讨论。
二、DNS轮流排程的优势及缺点
域名服务器（Domain Name Server）中的数据文件将主机名字映射到其IP。当你在浏览器中键入一个URL时（例如：浏览器则将请求发送到DNS，要求其返回相应站点的IP，这被称为DNS查询。当浏览器获得该站点的IP后，便通过该IP连接到所要访问的站点，将页面展现在用户面前。
域名服务器（DNS）通常包含一个单一的IP与该IP所映射的站点的名称的列表。在我们上面所假象的例子中，这个站点的映射IP为203.24.23.3。
为了利用DNS均衡服务器的负载，对于同一个站点来讲，在DNS服务器中同时拥有几个不同的IP。这几个IP代表集群中不同的机器，并在逻辑上映射到同一个站点名。通过我们的例子可以更好的理解这一点，将通过下面的三个IP发布到一个集群中的三台机器上：
203.34.23.3
203.34.23.4
203.34.23.5
在本例中，DNS服务器中包含下面的映射表：
203.34.23.3
203.34.23.4
203.34.23.5
当第一个请求到达DNS服务器时，返回的是第一台机器的IP203.34.23.3；当第二个请求到达时，返回的是第二台机器的IP203.34.23.4，以此类推。当第四个请求到达时，第一台机器的IP将被再次返回，循环调用。
利用上述的DNS Round Robin技术，对于某一个站点的所有请求将被平均的分配到及群中的机器上。因此，在这种技术中，集群中的所有的节点对于网络来说都是可见的。
DNS轮流排程的优势
DNS Round Robin的最大的优点就是易于实现和代价低廉：
代价低，易于建立。为了支持轮流排程，系统管理员只需要在DNS服务器上作一些改动，而且在许多比较新的.版本的DNS服务器上已经增加了这种功能。对于Web应用来说，不需要对代码作任何的修改；事实上，Web应用本身并不会意识到负载均衡配置，即使在它面前。
简单.不需要网络专家来对之进行设定，或在出现问题时对之进行维护。
DNS轮流排程的缺点
这种基于软件的负载均衡方法主要存在两处不足，一是不实时支持服务期间的关联，一是不具有高可靠*。
不支持服务器间的一致*。服务器一致*是负载均衡系统所应具备的一种能力，通过它，系统可以根据会话信息是属于服务器端的，还是底层数据库级别的，继而将用户的请求导向相应的服务器。而DNS轮流排程则不具备这种智能化的特*。它是通过cookie、隐藏域、重写URL三种方法中的一种来进行相似的判断的。当用户通过上述基于文本标志的方法与服务器建立连接之后，其所有的后续访问均是连接到同一个服务器上。问题是，服务器的IP是被浏览器暂时存放在缓存中，一旦记录过期，则需要重新建立连接，那么同一个用户的请求很可能被不同的服务器进行处理，则先前的所有会话信息便会丢失。
不支持高可靠*。设想一个具有N个节点的集群。如果其中的一个节点毁坏，那么所有的访问该节点的请求将不会有所回应，这是任何人都不愿意看到的。比较先进的路由器可以通过每隔一定的时间间隔，对节点检查，如果有毁坏的节点，则将之从列表中去除的方法，解决这个问题。但是，由于在Inter上，ISPs将众多的DNS存放在缓存中，以节省访问时间，因此，DNS的更新就会变得非常缓慢，以至于有的用户可能会访问一些已经不存在的站点，或者一些新的站点得不到访问。所以，尽管DNS轮流排程在一定程度上解决了负载均衡问题，但这种状况的改变并不是十分乐观和有效的。
除了上面介绍的轮流排程方法外，还有三种DNS负载均衡处理分配方法，将这四种方法列出如下：
Round robin(RRS)：将工作平均的分配到服务器(用于实际服务主机*能一致)
Least-connections(LCS)：向较少连接的服务器分配较多的工作(IPVS表存储了所有的活动的连接。用于实际服务主机*能一致。)
Weighted round robin(WRRS)：向较大容量的服务器分配较多的工作。可以根据负载信息动态的向上或向下调整。(用于实际服务主机*能不一致时)
Weighted least-connections(WLC)：考虑它们的容量向较少连接的服务器分配较多的工作。容量通过用户指定的砝码来说明，可以根据装载信息动态的向上或向下调整。(用于实际服务主机*能不一致时)
三：传统负载均衡器的优势及缺点
负载均衡器通过虚拟IP方法，解决了轮流排程所面临的许多问题。使用了负载均衡器集群系统，在外部看来，像是具有一个IP的单一服务器一样，当然，这个IP是虚拟的，它映射了集群中的每一台机器的。所以，在某种程度上，负载均衡器是将整个集群的IP报漏给外部网络。
当请求到达负载均衡器时，它会重写该请求的头文件，并将之指定到集群中的机器上。如果某台机器被从集群中移除了，请求不会别发往已经不存在的服务器上，因为所有的机器表面上都具有同一个IP，即使集群中的某个节点被移除了，该也不会发生变化。而且，inter上缓存的DNS条目也不再是问题了。当返回一个应答时
，客户端看到的只是从负载均衡器上所返回的结果。也就是说，客户端操作的对象是负载均衡器，对于其更后端的操作，对客户端来讲，是完全透明的。
传统负载均衡器的优点
服务器一致*.负载均衡器读取客户端发出的每一个请求中所包含的cookies或url解释。基于所读出的这些信息，负载均衡器就可以重写报头并将请求发往集群中合适的节点上，该节点维护着相应客户端请求的会话信息。在HTTP通信中，负载均衡器可以提供服务器一致*，但并不是通过一个安全的途径（例如：HTTPS）来提供这种服务。当消息被加密后（SSL），负载均衡器就不能读出隐藏在其中的会话信息。
通过故障恢复机制获得高可靠*.故障恢复发生在当集群中某个节点不能处理请求，需将请求重新导向到其他节点时。主要有两种故障恢复：
请求级故障恢复。当集群中的一个节点不能处理请求时（通常是由于down机），请求被发送到其他节点。当然，在导向到其他节点的同时，保存在原节点上的会话信息将会丢失。
透明会话故障恢复。当一个引用失败后，负载均衡器会将之发送到集群中其他的节点上，以完成操作，这一点对用户来说是透明的。由于透明会话故障恢复需要节点具备相应的操作信息，因此为了实现该功能，集群中的所有节点必须具有公共存储区域或通用数据库，存储会话信息数据，以提供每个节点在进行单独进程会话故障恢复时所需要的操作信息。
统计计量。既然所有的Web应用请求都必须经过负载均衡系统，那么系统就可以确定活动会话的数量，在任何实例访问中的活动会话的数目，应答的次数，高峰负载次数，以及在高峰期和低谷期的会话的数目，还有其他更多的。所有的这些统计信息都可以被很好的用来调整整个系统的*能。
传统负载均衡器的缺点
硬件路由的缺点在于费用、复杂*以及单点失败的。由于所有的请求均是通过一个单一的硬件负载均衡器来传递，因此，负载均衡器上的任何故障都将导致整个站点的崩溃。
HTTPS请求的负载均衡
正如上面所提到的，很难在那些来自HTTPS的请求上进行负载均衡和会话信息维护处理。因为，这些请求中的信息已经被加密了。负载均衡器没有能力处理这类请求。不过，这里有两种方法可以解决这一问题：
代理网络服务器
硬件SSL*
代理服务器位于服务器集群之前，首先由它接受所有的请求并对之进行解密，然后将这些处理后的请求根据头信息重新发往相应的节点上，这种方式不需要硬件上的支持，但会增加代理服务器的额外的负担。
硬件SSL*，则是在请求到达负载均衡器之前，先经由它进行解密处理。这种方式比代理服务器的处理速度要快捷一些。但代价也高，而且实现比较复杂。
;