จะปรับปรุงความทนทานต่อ TCP ต่อการส่งมอบนอกคำสั่งซื้อใน Linux balance-rr bonds และ/หรือ FreeBSD roundrobin laggs ได้อย่างไร

ฉันมี 3 เซิร์ฟเวอร์เครือข่าย kwise กำหนดค่าดังนี้

• ก คือ DELL R710 ใช้ Linux 5.13.19-1-pve Proxmox VE 7.1 และมี 4 NICs ทำงานร่วมกันใน สมดุล-RR พันธบัตรโหมด.
• ข คือ DELL R610 ใช้ Linux 5.13.19-1-pve Proxmox VE 7.1 และมี 4 NICs ทำงานร่วมกันใน สมดุล-RR พันธบัตรโหมด.
• ค DELL R710 กำลังทำงานอยู่ FreeBSD 12.2-RELEASE-p1 กับ ล่าช้ากว่า 8 NICs ใน วงเวียน (นี่คือ TrueNAS distro).

NIC ทั้งหมดคือ 1 GBps

เมื่อฉันวิ่ง ไอเพอร์เอฟ3 ระหว่างเบลดของลีนุกซ์ ฉันสูงสุดที่ประมาณ 3 GBps และหน้าต่างขึ้นไปโดยเฉลี่ยประมาณ 300 KiB อย่างไรก็ตาม ระหว่างเบลด TrueNAS (FreeBSD) และเบลด Linux สตรีม TCP จะสูงสุดที่ 1.20 Gbps และปิดหน้าต่างที่ค่าเฉลี่ย ~60 KiB ถ้าฉันเรียกใช้สตรีมคู่ขนาน (เช่น ไอเพอร์เอฟ3 ...-P 8) ฉันสามารถอิ่มตัวพันธบัตร ในทางกลับกัน อย่างที่คาดไว้ จำนวนการส่งซ้ำนั้นค่อนข้างสูงในทั้งสองกรณี ดังนั้น คำถามของฉันคือ

1. เหตุใด FreeBSD จึงไม่ถึงทรูพุตที่เท่ากัน หากคาดว่าทั้งคู่กำลังเข้าใกล้ปัญหาในลักษณะเดียวกัน (อาจเป็นที่ที่ฉันผิด)
2. มีตัวเลือกการปรับแต่งหรือการรวมกันของตัวเลือกเพื่อทำให้สแต็ก TCP ทนต่อการไม่อยู่ในลำดับมากขึ้นโดยไม่เรียกใช้การส่งสัญญาณซ้ำทันทีหรือไม่ (ฉันไม่ค่อยคุ้นเคยกับ 3-ACK reTX, พื้นฐานของการควบคุมความแออัดของ TCP และอื่นๆ)

ฉันจะรวมการปรับแต่งและตัวเลือกที่ฉันใช้ระหว่างการทดสอบไว้ที่นี่

• ifaces ทั้งหมดถูกกำหนดให้ใช้จัมโบ้เฟรม (MTU 9000)
• กล่อง Linux ได้รับการปรับแต่งดังนี้

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.ipv4.tcp_mem = 1638400 1638400 1638400
net.ipv4.tcp_rmem = 10240 87380 16777216
net.ipv4.tcp_rmem = 10240 87380 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_reordering=127
net.ipv4.tcp_max_reordering = 1,000
net.core.netdev_max_backlog = 10,000
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_congestion_control = รีโน

• กล่อง FreeBSD (TrueNAS Core ~= FreeNAS) ปรับจูนดังนี้

kern.ipc.maxsockbuf=614400000
kern.ipc.somaxconn=1024
net.route.netisr_maxqlen=8192
net.inet.ip.intr_queue_maxlen=8192
net.inet.tcp.mssdflt=8948
net.inet.tcp.reass.maxqueuelen=1000
net.inet.tcp.recvbuf_inc=65536
net.inet.tcp.sendbuf_inc=65536
net.inet.tcp.sendbuf_max=307200000
net.inet.tcp.recvbuf_max=307200000
net.inet.tcp.recvspace=65228
net.inet.tcp.sendspace=65228
net.inet.tcp.minmss=536
net.inet.tcp.abc_l_var=52
net.inet.tcp.initcwnd_segments=52 # เริ่มเร็ว
net.inet.udp.recvspace=1048576
net.inet.udp.sendspace=1048576

คุณสามารถลองใช้จัมโบ้เฟรมได้หากเครือข่ายของคุณรองรับ มันไม่ได้ลบปัญหาหลักของการทริกเกอร์การส่งสัญญาณซ้ำของ TCP ที่ไม่ได้อยู่ในลำดับอย่างไรก็ตาม เนื่องจากอีเทอร์เน็ตเฟรมใหญ่ขึ้น 6 เท่า จำนวนแพ็กเก็ตจึงลดลง ซึ่งจะลดจำนวนเหตุการณ์ที่ไม่เป็นไปตามลำดับ

มิฉะนั้น คุณควรตรวจสอบกรณีการใช้งานของคุณ คุณต้องการการเชื่อมต่อ TCP เดียวเพื่อรับปริมาณงานทั้งหมดหรือไม่ หากมีการเชื่อมต่อ TCP ที่ใช้งานอยู่หลายรายการระหว่างอุปกรณ์ คุณควรใช้ TCP รู้จักโหลดบาลานซ์