Score:0

โหลด CPU จำนวนมากภายใต้การเชื่อมต่อ TCP จำนวนมาก

ธง tr

ภายใต้การเชื่อมต่อ TCP จำนวนมาก CPU หนึ่งคอร์จะสูงถึง 100% เสมอ หลังจากนั้น VM ทั้งหมดจะเริ่มล้าหลังและจะมีการสูญเสียแพ็กเก็ตอย่างเห็นได้ชัด

มีวิธีแก้ไขหรือไม่ ทำให้การเชื่อมต่อ TCP ใช้ CPU น้อยลง หรือแม้แต่จำกัดอัตราหรือไม่

หมายเหตุ: การจำกัดอัตราผ่าน iptables จะไม่ทำงาน พยายามต่อไปนี้:

iptables -A INPUT -i eth0 -m state --state NEW -p tcp -m limit --limit 30/minute --dport 25565 -j ACCEPT

iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 25565 -j DROP

โปรดทราบว่าแม้แต่การทิ้งพอร์ตด้วย iptables -A อินพุต -p tcp --dport 25565 -j DROP จะไม่ทำงาน.

ภายใต้ htop ฉันไม่เห็นว่ากระบวนการใดกำลังใช้ CPU ดังนั้นฉันคิดว่าเป็นบางอย่างกับเคอร์เนล ผู้ให้บริการโฮสติ้งบางรายเช่น OVH ได้แก้ไขปัญหานี้แล้ว แต่ภายใต้ผู้ให้บริการรายอื่น ๆ ก็เกิดขึ้น ตัวเลือกของฉันคืออะไร?

ขอแสดงความนับถืออย่างสูง

Doug Smythies avatar
gn flag
คุณกำลังประสบกับการโจมตี DDOS (Distributed Denial Of Service) หรือไม่? ให้รายละเอียดเพิ่มเติมแก่เรา คุณใช้พอร์ต 25565 เพื่ออะไร เซิฟเวอร์มายคราฟ? กฎการทดสอบ iptables ของคุณถูกนำไปใช้ในจุดที่ถูกต้องตามกฎอื่น ๆ ของคุณเพื่อให้มีประสิทธิภาพหรือไม่? ใช้ ` sudo iptables -xvnL` เพื่อสังเกตจำนวนแพ็กเก็ตที่ใช้เส้นทางทดสอบของคุณ อูบุนตูรุ่นใด
OpenSource avatar
tr flag
จุดประสงค์การใช้งานน่าจะเป็น MC Reverse Proxy อย่างไรก็ตาม ในขณะที่ทำการทดสอบ พอร์ตนั้นเปิดด้วย Ubuntu 20.04 โดยไม่มีบริการใดทำงานภายใต้พอร์ตนี้ (แม้ว่าผลลัพธ์จะเหมือนกันแม้ว่าจะปิดผ่าน IPTables ก็ตาม) กฎข้อเดียวที่ฉันใช้ในขณะที่ทำการทดสอบคือ: iptables -A อินพุต -p tcp --dport 25565 -j DROP แม้จะปิดพอร์ตนั้นอย่างสมบูรณ์ แต่การเชื่อมต่อจำนวนมากทำให้ VM ใช้ CPU 100% เกณฑ์มาตรฐานโดยทั่วไปเกี่ยวกับการโจมตีบอท CPS 20k เนื่องจากเราวางแผนที่จะปรับใช้พร็อกซีย้อนกลับบนพอร์ตนั้น หมายความว่าจำเป็นต้องจัดการกับ CPS จำนวนมาก อย่างไรก็ตาม แม้จะไม่ได้ใช้งานอะไร
OpenSource avatar
tr flag
มันจะเริ่มล้าหลังและใช้ 100% ของคอร์ CPU หนึ่งคอร์
OpenSource avatar
tr flag
https://hastebin.com/soneqonivo.apache
OpenSource avatar
tr flag
ฉันเคยใช้มันเพียงครั้งเดียวเท่าที่ฉันทดสอบมาก่อน แต่ฉันหวังว่ามันจะเพียงพอ ฉันเห็น 11040 ACCEPT และ 746778220 DROP
Doug Smythies avatar
gn flag
แพ็คเก็ตคือหมายเลขที่เกี่ยวข้อง 186/12488841 ACCEPT/DROP แอปพลิเคชันของคุณค่อนข้างมาก
waltinator avatar
it flag
มีสายหรือไร้สาย? MTU ของคุณ (`ip l | grep $(ip r | awk '/default/ {print $5}' ) | awk '{print $2, $4, $5}'`) ใหญ่เกินไปหรือไม่ MTU ไร้สายควรเป็น 1492 (ส่วนหัว PPPOE 8 ไบต์) มิฉะนั้นคุณจะได้รับการแยกส่วนแพ็กเก็ตและประกอบใหม่ ซึ่งอาจกิน CPU
Doug Smythies avatar
gn flag
@waltinator : เหล่านี้เป็นแพ็กเก็ต SYN ทั้งหมดที่ละ 60 ไบต์ ฉันไม่คิดว่าการแยกส่วนเป็นไปได้สำหรับแพ็กเก็ต SYN
Score:2
ธง gn

ฉันไม่คิดว่าปัญหาของคุณอยู่ที่เคอร์เนล และไม่คิดว่าคอขวดในคอมพิวเตอร์ของคุณเกี่ยวข้องกับเครือข่ายของคุณ ขึ้นอยู่กับฮาร์ดแวร์ของคุณ

ฉันทำการทดลองต่อไปนี้:

คอมพิวเตอร์เซิร์ฟเวอร์ 1: ใช้ hping3 เพื่อสร้างแพ็คเก็ต SYN ในอัตรา 28,870 ต่อวินาที (ได้มาจากการทดลอง และคิดว่าใกล้เคียงกับสิ่งที่คุณกำลังทำอยู่) ไปยังพอร์ต 25565 บนคอมพิวเตอร์เซิร์ฟเวอร์ 2 คำสั่งที่ใช้:

$ sudo /usr/sbin/hping3 -p 25565 --syn --interval u20 s19

โดยที่ "s19" คือคอมพิวเตอร์เซิร์ฟเวอร์ 2 และ "u20" มีค่าโสหุ้ยและผลลัพธ์จริงคือ 28,870 แพ็กเก็ตต่อวินาทีแทนที่จะเป็น 50,000

คอมพิวเตอร์เซิร์ฟเวอร์ 2: มีกฎ DROP ของ iptables หนึ่งข้อ Turbostat ถูกเรียกใช้เพื่อสังเกตพลังงานและโหลด CPU มีการเรียกใช้คำสั่งเหล่านี้:

doug@s19:~/tmp$ sudo iptables -xvnL ; นอน 10 ; sudo iptables -xvnL
Chain INPUT (นโยบายยอมรับ 0 แพ็กเก็ต, 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
 2293479 91739160 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 สถานะ NEW tcp dpt:25565

เชน FORWARD (นโยบายยอมรับ 0 แพ็กเก็ต 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

Chain OUTPUT (นโยบายยอมรับ 0 แพ็คเก็ต, 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
Chain INPUT (นโยบายยอมรับ 0 แพ็กเก็ต, 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
 2582175 103287000 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 สถานะ NEW tcp dpt:25565

เชน FORWARD (นโยบายยอมรับ 0 แพ็กเก็ต 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

Chain OUTPUT (นโยบายยอมรับ 0 แพ็คเก็ต, 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

ดังนั้น 2582175 - 2293479 = 288,696 แพ็กเก็ตใน 10 วินาที หรือ 28,870/วินาที หมายเหตุ: ฉันมีไบต์ต่อแพ็กเก็ตน้อยกว่าคุณที่ 40 ในขณะที่ดูเหมือนคุณมี 60

$ sudo turbostat --สรุป --เงียบ --แสดง Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
ไม่ว่าง% Bzy_MHz IRQ PkgTmp PkgWatt CorWatt GFXWatt RAMWatt
0.61 4800 196262 38 17.91 17.25 0.00 0.89
0.61 4800 196844 38 17.95 17.29 0.00 0.89
0.60 4800 197409 39 18.01 17.35 0.00 0.89

การใช้งาน CPU เล็กน้อย แต่ใช้วัตต์มากกว่า 16 วัตต์ที่ไม่ได้ใช้งาน (ไม่ได้ใช้งาน = 1.5 วัตต์)

คอมพิวเตอร์ตั้งโต๊ะ 1: เครื่อง 20.04 เสมือน qemu/kvm ที่ทำงานในฐานะแขกบนคอมพิวเตอร์เซิร์ฟเวอร์ 2.

คำสั่ง hping3 ของคอมพิวเตอร์เซิร์ฟเวอร์ 1 กลายเป็น:

$ sudo /usr/sbin/hping3 -p 25565 --syn --interval u20 192.168.111.19

และผลลัพธ์คือ:

doug@desk-ff:~$ sudo iptables -xvnL ; นอน 100 ; sudo iptables -xvnL
Chain INPUT (นโยบายยอมรับ 117 แพ็คเก็ต, 9384 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
 2086906 83476240 DROP tcp -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 สถานะใหม่ tcp dpt:25565

เชน FORWARD (นโยบายยอมรับ 0 แพ็กเก็ต 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

Chain OUTPUT (นโยบายยอมรับ 73 แพ็คเก็ต, 9116 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
Chain INPUT (นโยบายยอมรับ 144 แพ็คเก็ต, 12151 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
 4970267 198810680 DROP tcp -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 สถานะใหม่ tcp dpt:25565

เชน FORWARD (นโยบายยอมรับ 0 แพ็กเก็ต 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

Chain OUTPUT (นโยบายยอมรับ 77 แพ็คเก็ต, 9996 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

ดังนั้น 4970267 - 2086906 = 288,361 แพ็กเก็ตใน 100 วินาที หรือ 28,834/วินาที

และบนคอมพิวเตอร์โฮสต์:

$ sudo turbostat --สรุป --เงียบ --แสดง Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
ไม่ว่าง% Bzy_MHz IRQ PkgTmp PkgWatt CorWatt GFXWatt RAMWatt
9.61 4800 207685 58 31.19 30.53 0.00 0.89
9.64 4800 211088 58 31.14 30.48 0.00 0.89
9.44 4800 202499 59 30.72 30.07 0.00 0.89

ฉันมี 12 CPU ดังนั้นการใช้งานจึงมากกว่า 100% ของ 1 CPU หรือผ่านทางด้านบน:

บน - 11:58:16 อัพ 10 วัน 18:57 ผู้ใช้ 2 คน โหลดเฉลี่ย: 1.00, 0.99, 0.81
งาน: ทั้งหมด 239, 1 วิ่ง, 238 นอน, 0 หยุด, 0 ซอมบี้
%Cpu0 : 0.3 us, 0.0 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu7 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu8 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu9 : 0.0 us, 3.1 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st
%Cpu10 : 8.3 us, 90.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
%Cpu11 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st

ใช่ว่าคุณกำลังทำสิ่งนี้ใน VM ดูเหมือนว่าจะใช้ทรัพยากร CPU มากขึ้นทางเลือกหนึ่งคืออย่าทำสิ่งนี้ใน VM หรือกำหนด VCPUs ให้กับ VM มากขึ้น ฉันสามารถรับได้ถึง 118,283 แพ็กเก็ตต่อวินาที (ตัวเลือกช่วงเวลา "u1" hping3) โดยเพิ่มการใช้งาน CPU โดยรวมบนโฮสต์เพียงสองสามเปอร์เซ็นต์

แก้ไข: การใช้งานโปรเซสเซอร์โฮสต์ข้อแพ็กเก็ตต่อวินาทีไปยัง VM ค่อนข้างน่าสนใจด้วยการตอบสนองประเภทฟังก์ชันขั้นตอนระหว่าง 5,000 ถึง 6,000 pps (จำได้ว่า 8.33% คือ 100% ของ 1 CPU สำหรับโฮสต์ CPU 12 ตัวนี้):

ป้อนคำอธิบายรูปภาพที่นี่

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา