ฉันได้ดูการปรับแต่งพารามิเตอร์ Linux และดูการกำหนดค่าบางอย่างที่ปิด SACK มีใครอธิบายเรื่องนี้ได้บ้าง
นี่จะเป็นการปรับสำหรับเว็บเซิร์ฟเวอร์ที่ไม่ว่าง
ฉันได้ดูการปรับแต่งพารามิเตอร์ Linux และดูการกำหนดค่าบางอย่างที่ปิด SACK มีใครอธิบายเรื่องนี้ได้บ้าง
นี่จะเป็นการปรับสำหรับเว็บเซิร์ฟเวอร์ที่ไม่ว่าง
คำตอบ:
TCP ACK พื้นฐานกล่าวว่า "ฉันได้รับไบต์ทั้งหมดจนถึง X" Selective ACK อนุญาตให้คุณพูดว่า "ฉันได้รับ bytes XY และ VZ"
ตัวอย่างเช่นหากโฮสต์ส่งคุณ 10,000 ไบต์และไบต์ 3000-5000 สูญหายระหว่างทาง ACK จะพูดว่า "ฉันได้รับทุกอย่างมากถึง 3000" ปลายอีกด้านจะต้องส่งไบต์ 3001-10000 อีกครั้ง SACK สามารถพูดว่า "ฉันได้ 1,000-2,999 และ 5001-10000" และโฮสต์ก็จะส่ง 3000-5000
นี่เป็นสิ่งที่ยอดเยี่ยมสำหรับแบนด์วิดท์สูงลิงก์สูญเสีย (หรือมีความล่าช้าสูง) ปัญหาคือมันอาจทำให้เกิดปัญหาประสิทธิภาพการทำงานที่รุนแรงในสถานการณ์ที่เฉพาะเจาะจง TCP ACK ปกติจะทำให้เซิร์ฟเวอร์จัดการกับแบนด์วิธสูง, การสูญเสียการเชื่อมต่อกับถุงมือเด็ก (ส่ง 500 ไบต์, รอ, ส่ง 500 ไบต์, รอเป็นต้น) SACK ช่วยให้สามารถปรับให้เข้ากับความล่าช้าสูงได้เพราะมันรู้ว่าจำนวนแพ็คเก็ตที่หายไปนั้นแท้จริงเพียงใด
นี่คือที่ที่สิ่งเลวร้ายสามารถเกิดขึ้นได้ ผู้โจมตีสามารถบังคับให้เซิร์ฟเวอร์ของคุณเก็บคิวการส่งผ่านข้อมูลจำนวนมากเป็นเวลานานจากนั้นประมวลผลสิ่งที่น่ารังเกียจไปเรื่อย ๆ สิ่งนี้สามารถตรึง CPU, กิน RAM และใช้แบนด์วิดท์มากกว่าที่ควร สรุประบบน้ำหนักเบาสามารถเริ่มต้น DoS กับเซิร์ฟเวอร์ beefier
หากเซิร์ฟเวอร์ของคุณแข็งแกร่งและไม่ได้ให้บริการไฟล์ขนาดใหญ่แสดงว่าคุณมีฉนวนกันความร้อนที่ดี
หากคุณส่วนใหญ่ให้บริการอินทราเน็ตหรือกลุ่มผู้ใช้ที่มีเวลาหน่วงต่ำอื่น ๆ SACK ไม่ได้ซื้ออะไรเลยและสามารถปิดได้ด้วยเหตุผลด้านความปลอดภัยโดยไม่มีประสิทธิภาพลดลง
หากคุณใช้ลิงค์ที่มีแบนด์วิดท์ต่ำ (กล่าวคือ 1Mbps หรือน้อยกว่าซึ่งเป็นกฎง่ายๆ) SACK อาจทำให้เกิดปัญหาในการทำงานปกติโดยทำให้การเชื่อมต่อของคุณอิ่มตัวและควรปิด
ในที่สุดมันก็ขึ้นอยู่กับคุณ พิจารณาสิ่งที่คุณกำลังรับใช้ใครจากอะไรและชั่งน้ำหนักระดับความเสี่ยงของคุณต่อผลการปฏิบัติงานของ SACK
มีภาพรวมที่ดีของ SACK และจุดอ่อนของที่นี่
อีกเหตุผลหนึ่งที่ TCP SACK มักถูกปิดใช้งานคือมีจำนวนอุปกรณ์เครือข่ายที่น่าทึ่งซึ่งไม่สามารถจัดการกับตัวเลือกนี้ได้อย่างถูกต้อง เราเห็นสิ่งนี้ตลอดเวลาด้วยผลิตภัณฑ์ถ่ายโอนไฟล์ความเร็วสูงที่เราจัดหาให้ซึ่งใช้ TCP ปัญหาที่พบบ่อยที่สุดคืออุปกรณ์เกตเวย์ที่ทำสิ่งต่าง ๆ เช่นสุ่มหมายเลขลำดับสำหรับแพ็กเก็ต TCP ที่กำลังส่งผ่านอุปกรณ์จากเครือข่ายภายในไปสู่ภายนอก แต่ไม่ได้ "ยกเลิกการสุ่ม" ตัวเลือก TCP SACK ที่อาจส่งจากระยะไกล ปลาย หากค่า SACK ที่แท้จริงนั้นไม่ได้แปลกลับไปเป็นค่าที่เหมาะสมโดยอุปกรณ์เหล่านี้ดังนั้นเซสชัน TCP จะไม่สมบูรณ์เมื่อเผชิญกับการสูญเสียแพ็กเก็ตเมื่อปลายทางระยะไกลพยายามใช้ SACK เพื่อรับประโยชน์ ACK ที่เลือก
อาจเป็นปัญหาน้อยถ้าคนใช้การบำรุงรักษาซอฟต์แวร์เชิงป้องกันมากขึ้นกับอุปกรณ์นี้ แต่พวกเขามักจะไม่
ฉันสามารถยืนยันได้จากประสบการณ์อันขมขื่นที่ tcp_sack = 1 ทำให้การถ่ายโอนข้อมูลที่ค้างอยู่บน sftp / rsync / scp ฯลฯ มีไฟล์เกินกว่า 12mb เมื่อใช้อุปกรณ์ไฟร์วอลล์ ASA ของ Cisco บางตัว
ทุกครั้งที่มันถูกจนตรอก
เราถ่ายโอนผ่านลิงก์ขนาด 100mbps โดยเฉพาะระหว่างโฮสต์ A และโฮสต์ B ในศูนย์ข้อมูลที่ต่างกันสองแห่งโดยใช้ไฟร์วอลล์ซิสโก้และสวิตช์ฮาร์ดแวร์ที่มี centos
สิ่งนี้สามารถบรรเทาได้บ้างโดยการปรับเปลี่ยนขนาดบัฟเฟอร์ - เช่นฉันไม่สามารถถ่ายโอนไฟล์ 1GB ผ่าน sftp จากโฮสต์ A ไปยังโฮสต์ B เว้นแต่ฉันจะตั้งค่าบัฟเฟอร์ sftp เป็น 2048 แต่ฉันทำได้โดยไม่คำนึงว่าโฮสต์ B ดึงไฟล์จาก A
การทดลองกับไฟล์เดียวกันโดยใช้ rsync และการปรับบัฟเฟอร์ส่ง / รับอนุญาตให้ฉันเพิ่มระดับ yo ประมาณ 70mb ของไฟล์ 1GB ที่ถูกผลักจาก A ถึง B
อย่างไรก็ตามคำตอบที่ดีที่สุดคือการปิดการใช้งาน tcp_sack บนโฮสต์ A เริ่มแรกโดยการตั้งค่า tcp_sack = 0 ในเคอร์เนลแบบทันทีทันใด - แต่ท้ายที่สุด - ฉันเพิ่มมันลงใน /etc/sysctl.conf ของฉัน