如果服务器传过来的数据量过大,怎么处理

如果服务器传过来的数据量过大,怎么处理,第1张

说白了就是服务器的承受能力。 第一,确认服务器硬件是否足够支持当前的流量。

普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大,那么必须首先配置一台更高性能的专用服务器才能解决问题,否则怎么优化都不可能彻底解决性能问题。

第二,优化数据库访问。

服务器的负载过大,一个重要的原因是CPU负荷过大,降低服务器CPU的负荷,才能够有效打破瓶颈。而使用静态页面可以使得CPU的负荷最小化。前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站,静态化往往不能满足某些功能。

缓存技术就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用这些文件,而不必再访问数据库,WordPress和Z-Blog都大量使用这种缓存技术。我自己也写过一个Z-Blog的计数器插件,也是基于这样的原理。

如果确实无法避免对数据库的访问,那么可以尝试优化数据库的查询SQL.避免使用Select *from这样的语句,每次查询只返回自己需要的结果,避免短时间内的大量SQL查询。

第三,禁止外部的盗链

外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对于自身的图片或者文件盗链,好在目前可以简单地通过refer来控制盗链,Apache自己就可以通过配置来禁止盗链,IIS也有一些第三方的ISAPI可以实现同样的功能。当然,伪造refer也可以通过代码来实现盗链,不过目前蓄意伪造refer盗链的还不多,可以先不去考虑,或者使用非技术手段来解决,比如在图片上增加水印。

第四,控制大文件的下载。

大文件的下载会占用很大的流量,并且对于非SCSI硬盘来说,大量文件下载会消耗CPU,使得网站响应能力下降。因此,尽量不要提供超过2M的大文件下载,如果需要提供,建议将大文件放在另外一台服务器上。目前有不少免费的Web2.0网站提供图片分享和文件分享功能,因此可以尽量将图片和文件上传到这些分享网站。

你的程序关掉了和别人发不发包有个什么关系呢?如果是DDOS攻击,方式有很多,比方说分片攻击,网卡收到分片攻击的报文是要处理的,你不能说这个包有问题网卡就不处理,网卡处理就会消耗资源,消耗带宽,这只是简简单单的一个比方。你自己描述了一大堆,实际上是根本就没有找到问题,带宽大,你要抓包看到低是什么流量,要在交换机上看,路由器上看,在防火墙上过滤,光盯着应用层看有什么用呢,网络层,数据链路层都不管了?

不是木马,是设置问题,下面是流量的控制方法一、Linux 流量控制过程分二种:1、队列控制 即 QOS, 瓶颈处的发送队列的规则控制,常见的有 SFQ PRIO2、流量控制 即带宽控制 , 队列的排队整形, 一般为 TBF HTB二、Linux 流量控制算法分二种:1、无类算法 用于树叶级无分支的队列,例如:SFQ2、分类算法 用于多分支的队列,例如:PRIO TBF HTB三、具体实现: 1. 在网卡上建立 以SFQ算法的限流#tc qdisc add dev eth0 root handle 1: sfq SFQ 参数有 perturb( 重新调整算法间隔 ) quantum 基本上不需要手工调整 : handle 1: 规定算法编号 .. 可以不用设置由系统指定 ..#tc qdisc sh dev eth0 显示算法#tc qd del dev eth0 root 删除 注 : 默认 eht0 支持 TOS 2. 在网卡建立以 TBF算法的限流 #tc qd add dev eth1 root handle 1: tbf rate 256kbit burst 10000 latency 50ms 速率 256kbit 突发传输 10k 最大延迟 50ms #tc -s qd sh dev eth1 统计#tc qd del dev eth1 root 删除3. 在网卡建立 PRIO #tc qdisc add dev eth0 root handle 1: prio # 此命令立即创建了类 : 1:1, 1:2, 1:3 ( 缺省三个子类 ) #tc qdisc add dev eth0 parent 1:1 handle 10: sfq #tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 注 : 此为 TBF 限速的另一写法 , 前文有讲解 . #tc qdisc add dev eth0 parent 1:3 handle 30: sfq4. WEB 服务器的流量控制为 5Mbps,SMTP 流量控制在 3Mbps 上 . 而且二者一共不得超过 6Mbps, 互相之间允许借用带宽 #tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell 8 #tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded 这部分按惯例设置了根为 1:0, 并且绑定了类 1:1. 也就是说整个带宽不能超过 6Mbps. #tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 #tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 建立了 2 个类 . 注意我们如何根据带宽来调整 weight 参数的 . 两个类都没有配置成"bounded", 但它们都连 接到了类 1:1 上 , 而 1:1 设置了"bounded". 所以两个类的总带宽不会超过 6Mbps. 别忘了 , 同一个 CBQ 下面的子 类的主号码都必须与 CBQ 自己的号码相一致 ! #tc qdisc add dev eth0 parent 1:3 handle 30: sfq #tc qdisc add dev eth0 parent 1:4 handle 40: sfq 缺省情况下 , 两个类都有一个 FIFO 队列规定 . 但是我们把它换成 SFQ 队列 , 以保证每个数据流都公平对待 . #tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 80 0xffff flowid 1:3 #tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 25 0xffff flowid 1:46. 过滤器过滤示例 #tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match ip dport 22 0xffff flowid 10:1 在 10: 节点添加一个过滤规则 , 优先权 1: 凡是去往 22 口 ( 精确匹配 ) 的 IP 数据包 , 发送到频道 10:1.. #tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match ip sport 80 0xffff flowid 10:1 在 10: 节点添加一个过滤规则 , 优先权 1: 凡是来自 80 口 ( 精确匹配 ) 的 IP 数据包 , 发送到频道 10:1.. #tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 在 eth0 上的 10: 节点添加一个过滤规则 , 它的优先权是 2: 凡是上二句未匹配的 IP 数据包 , 发送到频道 10:2.. #tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip dst 4.3.2.1/32 flowid 10:1 去往 4.3.2.1 的包发送到频道 10:1 其它参数同上例 #tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 1.2.3.4/32 flowid 10:1 来自 1.2.3.4 的包发到频道 10:1 #tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 凡上二句未匹配的包送往 10:2 #tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32 match ip sport 80 0xffff flowid 10:1 可连续使用 match, 匹配来自 1.2.3.4 的 80 口的数据包


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/117902.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-03-13
下一篇2023-03-13

发表评论

登录后才能评论

评论列表(0条)

    保存