เหตุใดปริมาณงาน TCP ของฉันจึงมากกว่าปริมาณงาน UDP มาก

ฉันไม่ได้ทำอะไรผิดปกติกับการกำหนดค่าฮาร์ดแวร์หรือเคอร์เนล (การตั้งค่าเริ่มต้นทั้งหมด, การติดตั้งระบบปฏิบัติการใหม่, Linux kernel 3.11 TCP / IP สแต็ค) และฉันเฉลี่ยประมาณ 3.83 ล้านข้อความต่อวินาทีผ่าน TCP ในขณะที่ฉันเฉลี่ยเพียง 0.75 ล้านข้อความต่อวินาทีผ่าน UDP ดูเหมือนว่าจะท้าทายสิ่งที่ฉันคาดหวังของทั้งสองโปรโตคอลอย่างสมบูรณ์

อะไรเป็นสาเหตุที่ทำให้เกิดความแตกต่างอย่างมากและฉันจะวินิจฉัยบน Ubuntu 13.10 ได้อย่างไร

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

สำหรับการทดสอบนี้ฉันมีเซิร์ฟเวอร์ทดสอบสองตัวที่เหมือนกันและเชื่อมต่อโดยตรงผ่านสายเคเบิลครอสโอเวอร์ 10G NICs ที่ใช้ในกรณีนี้คือ Intel X520 พร้อมการกำหนดค่าแบบนอกกล่องและเชื่อมต่อกับสล็อต PCIe 3.0 x8 บนเมนบอร์ดซึ่งสื่อสารกับ CPU ผ่านตัวควบคุม NUMA

นอกเหนือจากการไม่ได้รับข้อมูลโดยละเอียดเกี่ยวกับการตั้งค่าการทดสอบของคุณแล้วปัญหาหลักก็คือคุณใช้ขนาดข้อความ 64 ไบต์ นี่อยู่ไกลจาก MTU ปกติที่ 1500 ไบต์และทำให้ UDP ไม่มีประสิทธิภาพสูง: ในขณะที่ TCP ผสานหลาย ๆ การส่งเข้าไปในแพ็กเก็ตเดียวบนสาย (ยกเว้นถ้าตั้งค่า TCP_NODELAY) เพื่อใช้ลิงค์อย่างมีประสิทธิภาพข้อความ UDP แต่ละอันจะส่งผลให้ แพ็คเก็ตแยกต่างหาก ในตัวเลข: ประมาณ 23 ข้อความของขนาด 64 ไบต์จะถูกรวมเป็น TCP แพ็กเก็ตเดียวของขนาด MTU ในขณะที่มันต้องการ 23 แพ็กเก็ตเดี่ยวสำหรับ UDP สำหรับปริมาณข้อมูลเท่ากัน แต่ละแพ็กเก็ตเหล่านี้หมายถึงค่าใช้จ่ายด้วยการส่งจากโฮสต์ส่งผ่านสายและรับโดยเพียร์ และเท่าที่เห็นในกรณีของคุณประมาณ 80% ของแพ็คเก็ต UDP จะสูญหายเนื่องจากฮาร์ดแวร์ของคุณไม่เร็วพอที่จะรับและส่งแพ็คเก็ตเหล่านี้ทั้งหมด

ดังนั้นสิ่งที่คุณสามารถเรียนรู้จากเกณฑ์มาตรฐานนี้คือ:

• UDP ไม่น่าเชื่อถือ (สูญเสียแพ็กเก็ต 80%)
• UDP ไม่มีประสิทธิภาพหากใช้กับขนาดแพ็คเก็ตที่ต่ำกว่า MTU
• TCP ได้รับการปรับให้สูงที่สุดเพื่อใช้ประโยชน์จากลิงค์ให้ดีที่สุด

สำหรับความคาดหวังของคุณ UDP นั้นน่าจะดีกว่า: คุณเคยสงสัยบ้างไหมว่าทำไมการถ่ายโอนไฟล์สำคัญทั้งหมด (ftp, http, ... ) จึงทำกับโปรโตคอลที่ใช้ TCP? มาตรฐานแสดงเหตุผล

เหตุใดผู้คนจึงใช้ UDP เลย

• ด้วยข้อมูลแบบเรียลไทม์ (เช่น Voice over IP) คุณไม่สนใจข้อความเก่าดังนั้นคุณไม่ต้องการให้ผู้ส่งรวมข้อความเป็นแพ็กเก็ตขนาดใหญ่เพื่อใช้ลิงค์อย่างมีประสิทธิภาพ และคุณค่อนข้างยอมรับว่าแพ็คเก็ตหายไปมากกว่าที่จะมาสายเกินไป
• ด้วยลิงก์แฝงสูง (เช่นเดียวกับดาวเทียม) พฤติกรรมเริ่มต้นของ TCP ไม่เหมาะที่จะใช้งานลิงค์ให้มีประสิทธิภาพ ดังนั้นบางคนจึงเปลี่ยนมาใช้ UDP ในกรณีนี้และใช้เลเยอร์ความน่าเชื่อถือของ TCP อีกครั้งและปรับให้เหมาะสมสำหรับการเชื่อมโยงที่มีความหน่วงสูงในขณะที่คนอื่นปรับแต่งสแต็ก TCP ที่มีอยู่เพื่อใช้ประโยชน์จากการเชื่อมโยง
• ข้อมูล "ทิ้ง": บางครั้งการส่งข้อมูลออกไปนั้นสำคัญกว่าและไม่สนใจว่าแพ็กเก็ตจะสูญหายเช่นในบันทึกข้อความ (syslog)
• การโต้ตอบสั้น ๆ : กับ TCP คุณจำเป็นต้องสร้างการเชื่อมต่อรักษาสถานะซึ่งมีค่าใช้จ่ายเวลาและทรัพยากรที่ลูกค้าและเซิร์ฟเวอร์ สำหรับการโต้ตอบสั้น ๆ (เช่นคำขอสั้นและตอบกลับ) สิ่งนี้อาจมีค่าใช้จ่ายมากเกินไป เพราะ DNS นี้มักจะทำกับ UDP แต่ได้ลองใหม่ที่ด้านบนของ UDP