Điểm:0

Tải CPU lớn dưới số lượng lớn kết nối TCP

lá cờ tr

Trong một lượng lớn kết nối TCP, một lõi CPU sẽ luôn đạt tới 100%. Sau khi điều đó xảy ra, toàn bộ VM sẽ bắt đầu bị trễ và sẽ xảy ra tình trạng mất gói rõ ràng.

Có cách nào để giải quyết nó, làm cho các kết nối TCP sử dụng ít CPU hơn hoặc thậm chí giới hạn tốc độ không?

LƯU Ý: Giới hạn tỷ lệ qua iptables sẽ không hoạt động. Đã thử như sau:

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

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

Lưu ý rằng ngay cả khi bỏ cổng với iptables -A INPUT -p tcp --dport 25565 -j DROP sẽ không làm việc.

Trong htop, tôi không thể thấy quá trình nào đang sử dụng CPU, vì vậy tôi cho rằng đó là thứ gì đó với Kernel. Một số nhà cung cấp dịch vụ lưu trữ như OVH đã giải quyết được vấn đề này, nhưng ở nhiều nhà cung cấp khác, điều đó vẫn xảy ra. Những lựa chọn của tôi là gì?

Trân trọng

Doug Smythies avatar
lá cờ gn
Bạn đang gặp phải một cuộc tấn công DDOS (Từ chối dịch vụ phân tán)? Hãy cho chúng tôi thêm một số chi tiết. Bạn đang sử dụng cổng 25565 để làm gì? Một máy chủ minecraft? Các quy tắc kiểm tra iptables của bạn có được áp dụng đúng chỗ đối với các quy tắc khác của bạn để có hiệu quả không? Sử dụng ` sudo iptables -xvnL` để quan sát xem có bao nhiêu gói đã thực hiện đường dẫn thử nghiệm của bạn. Phiên bản Ubuntu nào?
OpenSource avatar
lá cờ tr
Mục đích sử dụng thực sự sẽ là MC Reverse Proxy, tuy nhiên, tại thời điểm thử nghiệm, cổng đã được mở với Ubuntu 20.04 mà không có dịch vụ nào chạy bên dưới nó (mặc dù kết quả là như nhau ngay cả khi nó bị đóng qua IPTables). Quy tắc duy nhất tôi áp dụng tại thời điểm thử nghiệm là: iptables -A INPUT -p tcp --dport 25565 -j DROP. Ngay cả khi cổng đó đã đóng hoàn toàn, số lượng lớn kết nối vẫn khiến VM sử dụng 100% CPU. Điểm chuẩn về cơ bản là cuộc tấn công bot khoảng 20 nghìn CPS vì chúng tôi dự định triển khai proxy ngược trên cổng đó, nghĩa là nó cần xử lý rất nhiều CPS. Tuy nhiên, ngay cả khi không có gì được triển khai
OpenSource avatar
lá cờ tr
Đơn giản là nó sẽ bắt đầu tụt hậu và sử dụng 100% một lõi CPU.
OpenSource avatar
lá cờ tr
https://hastebin.com/soneqonivo.apache
OpenSource avatar
lá cờ tr
Tôi đã sử dụng nó chỉ một lần, như tôi đã thử nghiệm nó trước đây, nhưng tôi hy vọng nó là đủ. Tôi thấy 11040 ACCEPT và 746778220 DROP.
Doug Smythies avatar
lá cờ gn
Các gói là các số liên quan 186/12488841 ACCEPT/DROP. Ứng dụng của bạn là khá cực đoan.
waltinator avatar
lá cờ it
Có dây hay không dây? MTU (`ip l | grep $(ip r | awk '/default/ {print $5}' ) | awk '{print $2, $4, $5}'`) của bạn có quá lớn không? MTU không dây phải là 1492 (tiêu đề PPPOE 8 byte), nếu không, bạn sẽ bị phân mảnh và lắp ráp lại gói, điều này có thể ngốn CPU.
Doug Smythies avatar
lá cờ gn
@waltinator: đây hoàn toàn là các gói SYN với 60 byte mỗi gói. Tôi không nghĩ rằng gói SYN có thể bị phân mảnh.
Điểm:2
lá cờ gn

Tôi không nghĩ rằng vấn đề của bạn nằm ở kernel, tôi cũng không nghĩ rằng nút cổ chai tính toán của bạn có liên quan đến nội dung mạng của bạn, tùy thuộc vào phần cứng của bạn.

Tôi đã làm thí nghiệm sau:

Máy chủ 1: sử dụng hping3 để tạo các gói SYN với tốc độ 28.870 mỗi giây (xuất phát từ thử nghiệm và được cho là đủ gần với những gì bạn đang làm) tới cổng 25565 trên máy chủ 2. Lệnh được sử dụng:

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

Trong đó "s19" là máy chủ 2 và "u20" có tổng phí và kết quả thực tế là 28.870 gói mỗi giây thay vì 50.000.

Máy chủ 2: có một quy tắc DROP iptables. Turbostat cũng được chạy để quan sát tải điện và CPU. Các lệnh này đã được chạy:

doug@s19:~/tmp$ sudo iptables -xvnL ; ngủ 10 ; sudo iptables -xvnL
Chuỗi INPUT (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn
 2293479 91739160 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 trạng thái tcp MỚI dpt:25565

Chuỗi FORWARD (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn

ĐẦU RA chuỗi (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn
Chuỗi INPUT (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn
 2582175 103287000 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 trạng thái tcp MỚI dpt:25565

Chuỗi FORWARD (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn

ĐẦU RA chuỗi (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn

Vì vậy, 2582175 - 2293479 = 288.696 gói trong 10 giây hoặc 28.870/giây. Lưu ý: Tôi có ít byte trên mỗi gói hơn bạn, ở mức 40, trong khi bạn dường như có 60.

$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
Bận% 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

Mức sử dụng CPU không đáng kể, nhưng sử dụng nhiều hơn khoảng 16 watt so với khi không hoạt động (không hoạt động = 1,5 watt).

Máy tính để bàn 1: Máy qemu/kvm ảo 20.04 chạy với tư cách khách trên máy chủ 2.

Lệnh 1 hping3 của máy chủ trở thành:

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

Và kết quả là:

doug@desk-ff:~$ sudo iptables -xvnL ; ngủ 100; sudo iptables -xvnL
Chuỗi INPUT (chính sách CHẤP NHẬN 117 gói, 9384 byte)
    pkts byte đích prot chọn không tham gia đích nguồn
 2086906 83476240 DROP tcp -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 trạng thái tcp MỚI dpt:25565

Chuỗi FORWARD (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn

ĐẦU RA chuỗi (chính sách CHẤP NHẬN 73 gói, 9116 byte)
    pkts byte đích prot chọn không tham gia đích nguồn
Chuỗi INPUT (chính sách CHẤP NHẬN 144 gói, 12151 byte)
    pkts byte đích prot chọn không tham gia đích nguồn
 4970267 198810680 DROP tcp -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 trạng thái tcp MỚI dpt:25565

Chuỗi FORWARD (chính sách CHẤP NHẬN 0 gói, 0 byte)
    pkts byte đích prot chọn không tham gia đích nguồn

ĐẦU RA chuỗi (chính sách CHẤP NHẬN 77 gói, 9996 byte)
    pkts byte đích prot chọn không tham gia đích nguồn

Vì vậy, 4970267 - 2086906 = 288.361 gói trong 100 giây hoặc 28.834/giây.

và trên máy chủ:

$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
Bận% 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

Tôi có 12 CPU, vì vậy mức sử dụng lớn hơn 100% của 1 CPU. Hoặc qua đầu trang:

hàng đầu - 11:58:16 lên 10 ngày, 18:57, 2 người dùng, tải trung bình: 1,00, 0,99, 0,81
Nhiệm vụ: tổng cộng 239, 1 đang chạy, 238 đang ngủ, 0 đã dừng, 0 zombie
%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 chúng tôi, 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

Vì vậy, vâng, bạn đang làm điều này trong VM dường như tiêu tốn nhiều tài nguyên CPU hơn.Một tùy chọn là không làm điều này trong máy ảo. Hoặc, gán thêm VCPU cho VM. Tôi có thể nhận được tới 118.283 gói mỗi giây (tùy chọn khoảng thời gian "u1" hping3), chỉ tăng một vài phần trăm trong mức sử dụng CPU tổng thể trên máy chủ.

CHỈNH SỬA: Việc sử dụng bộ xử lý máy chủ lưu trữ các gói mỗi giây cho VM khá thú vị với phản hồi loại chức năng bước trong khoảng từ 5000 đến 6000 pps (hãy nhớ rằng 8,33% là 100% của 1 CPU cho máy chủ 12 CPU này):

nhập mô tả hình ảnh ở đây

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.