ns 3 project

% Alfred Tso Chun Fai 20012065g % โครงการ COMP5311: การวิเคราะห์ประสิทธิภาพของ TCP และ UDP

หน้าใหม่

การแนะนำ

แม้แต่สงสัยว่าทำไมเบราว์เซอร์ Chrome จึงให้ความรู้สึกเร็วกว่า Firefox มากเมื่อดูวิดีโอ Youtube ฉันทำและในฐานะนักเรียนที่อยากรู้อยากเห็น ฉันจึงเริ่มใช้งาน Wireshark และบันทึกปริมาณการเข้าชม และสิ่งที่ฉันพบคือสิ่งนี้

ตามวิกิ ¹ QUIC ถูกใช้โดยมากกว่าครึ่งหนึ่งของการเชื่อมต่อทั้งหมดจากเว็บเบราว์เซอร์ Chrome ไปยังเซิร์ฟเวอร์ของ Google

QUIC คืออะไร

QUIC เป็นโปรโตคอลที่มุ่งปรับปรุงเว็บแอปพลิเคชันที่กำลังใช้ TCP ² อยู่ในปัจจุบันโดยการสร้าง UDP แบบมัลติเพล็กซ์จำนวนหนึ่ง และบางตัวเรียกมันว่า "TCP/2" HTTP/3 ที่กำลังจะมาถึง (Internet-Draft ณ เดือนกุมภาพันธ์ 2021) ได้รับการอ้างว่าใช้ QUIC เช่นกัน

เดี๋ยวก่อน ... เรากำลังใช้ UDP เพื่อแทนที่ TCP หรือไม่ เราได้รับแจ้งว่า UDP ไม่น่าเชื่อถือ เหตุใดจึงสามารถมุ่งเป้าไปที่ TCP "ล้าสมัย" ได้ การเปรียบเทียบโปรโตคอลทั้งสอง (TCP และ UDP) นั้นคล้ายคลึงกับการเปรียบเทียบรถไฟกับเครื่องบินมากกว่าโบอิ้งกับแอร์บัส (ทั้ง การขนส่ง ) อย่างไรก็ตาม เรายังคงสามารถเปรียบเทียบสิ่งเหล่านี้กับตัวชี้วัดหลักบางตัวได้เพื่อดูว่า QUIC นี้เลือก UDP เพื่อปรับปรุงอะไร

หน้าใหม่

TCP กับ UDP: กรณีศึกษา

ความเป็นมา: งานที่เกี่ยวข้อง

• หยวน และคณะ (2019) ³ เปรียบเทียบประสิทธิภาพของ TCP และ UDP บน SDN โดยใช้ความล่าช้าของแพ็กเก็ตโดยเฉลี่ยและความน่าจะเป็นที่การสูญเสียแพ็กเก็ต การศึกษาพบว่า TCP มีประสิทธิภาพเหนือกว่า UDP เหนือทั้งสองเมตริก 12-50% และ 25-100% ตามลำดับ โปรดทราบว่าที่นี่ เราไม่ได้ทำการศึกษาใน SDN
• เขาและคณะ (2004) ⁴ ศึกษาผลกระทบของการรวมแพ็คเก็ตและการบัฟเฟอร์ขาเข้าต่อปริมาณงานและความล่าช้าของการกระวนกระวายใจของ TCP และ UDP
• เกมส์และคณะ (2008) ⁵ เสนอโมเดลขอบเขตบนสำหรับปริมาณงาน TCP และ UDP ใน IPv4 และ IPv6 งานวิจัยนี้นำเสนอแบบจำลองสำหรับการคำนวณปริมาณงานทางทฤษฎีสูงสุดของทั้งสองโปรโตคอลให้เป็นอัตราส่วนของจำนวนไบต์ของข้อมูล TCP หรือ UDP ที่จะส่งผ่านนาที จำนวนไบต์ที่จำเป็น รวมถึง IFG, คำนำ, SFD, การห่อหุ้ม Ethernet DIX, ส่วนหัว IP, ส่วนหัว TCP (หรือ UDP) และแพดดิ้ง คูณด้วยแบนด์วิดท์ของลิงก์ โดยถือว่าฟูลดูเพล็กซ์และไม่มีเวลาประมวลผล
• ชาห์รูดิน และคณะ (2016) ⁶ เปรียบเทียบโปรโตคอลการขนส่งต่างๆ รวมถึง TCP และ UDP บนเครือข่าย 4G โดยใช้ตัวชี้วัด 4 ตัว ได้แก่ ปริมาณงาน การสูญเสียแพ็คเก็ต ความล่าช้าตั้งแต่ต้นจนจบ และความกระวนกระวายใจเฉลี่ย

หน้าใหม่

คำจำกัดความของปัญหา

การเปรียบเทียบโปรโตคอลชั้นการขนส่งไม่ใช่เรื่องง่าย เนื่องจากมีปัจจัยหลายประการที่อาจส่งผลต่อผลลัพธ์:

การนำไปปฏิบัติที่แตกต่างกัน

พารามิเตอร์บางตัวภายในโปรโตคอล (เช่น TCP) เหลืออยู่ในการใช้งาน (ซึ่งก่อให้เกิดลายนิ้วมือ TCP/IP ทำให้ผู้ไม่ประสงค์ดีสามารถระบุ OS ของโฮสต์ได้ เหนือสิ่งอื่นใด) ซึ่งหมายความว่าความแตกต่างเหล่านี้อาจส่งผลกระทบเล็กน้อยต่อ การวัดประสิทธิภาพ

โทโพโลยีเครือข่าย

เส้นทางที่แพ็กเก็ตใช้โดยตรงจะส่งผลต่อผลลัพธ์อย่างแน่นอน ดังนั้นเราเตอร์ทันที ลิงก์คอขวดที่อยู่ระหว่างนั้น และการรับส่งข้อมูลอื่นๆ อาจส่งผลต่อผลลัพธ์เช่นกัน

แบนด์วิธของลิงก์ที่เกี่ยวข้อง

ตามที่กล่าวไว้ข้างต้น เรามักจะไม่แน่ใจเกี่ยวกับแบนด์วิธของลิงก์ทันทีเหล่านั้น หรือเพียงแค่ลิงก์ระหว่างไคลเอนต์และเซิร์ฟเวอร์ บทความฉบับหนึ่งที่กล่าวถึงได้ตั้งสมมติฐานว่าลิงก์จะไม่มีการชนกัน

ฮาร์ดแวร์

เราพบว่าบัฟเฟอร์อาจส่งผลกระทบต่อประสิทธิภาพของโปรโตคอลเหล่านี้ และไม่เพียงแต่ด้านซอฟต์แวร์เท่านั้นที่เกี่ยวข้อง ส่วนฮาร์ดแวร์ก็มีความสำคัญเช่นกัน และบ่อยครั้งเราไม่สามารถควบคุมรายละเอียดระดับล่างเหล่านี้ได้

แอปพลิเคชันที่ใช้ส่งแพ็กเก็ตเหล่านี้

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

วัตถุประสงค์

จากการพิจารณาทั้งหมดนี้ เราจะใช้โทโพโลยีเครือข่ายแบบธรรมดาที่มีการตั้งค่าที่ใกล้เคียงกับความเป็นจริงมากที่สุด ในกรณีที่รายละเอียดพื้นฐานเช่นขนาดคิวบัฟเฟอร์หรือโปรโตคอลเราจะใช้เหมือนกันสำหรับทั้งสองโปรโตคอล ด้วยเหตุนี้ เราจะเปรียบเทียบ TCP และ UDP บน IPv4 ในโฮสต์แบบหนึ่งต่อหนึ่งแบบใช้สายโดยใช้ทรูพุต ความล่าช้าโดยเฉลี่ย และความกระวนกระวายใจโดยเฉลี่ยเป็นตัวบ่งชี้ประสิทธิภาพของเรา

เราจะส่งแพ็กเก็ต 10, 100 และ range(1e4, 1e5, 1e4) แต่ละแพ็กเก็ตมี 1472 ไบต์ในแอปพลิเคชัน UDP และจำนวนไบต์ที่เทียบเท่าในแอปพลิเคชัน TCP เพื่อสังเกตโฟลว์ของทั้งแอปพลิเคชัน TCP และ UDP

ปริมาณงาน

$$ ปริมาณงาน = frac{จำนวนแพ็กเก็ตที่ได้รับ (RxPackets)}{ เวลาที่ได้รับครั้งล่าสุด - เวลาที่ได้รับครั้งแรก} $$

ความล่าช้าโดยเฉลี่ย

$$ ความล่าช้าโดยเฉลี่ย = frac{ความล่าช้าตั้งแต่ต้นทางถึงปลายทางรวมทั้งหมดForRxPackets}{RxPackets} $$

ความกระวนกระวายใจโดยเฉลี่ย

JitterSum มีผลรวมของค่าการหน่วงเวลาตั้งแต่ต้นทางถึงปลายทาง (รูปแบบความล่าช้า) ทั้งหมดสำหรับแพ็กเก็ตที่ได้รับทั้งหมดของโฟลว์ ที่นี่เรากำหนด ความกระวนกระวายใจ ของแพ็กเก็ตเป็นรูปแบบการหน่วงเวลาซึ่งสัมพันธ์กับแพ็กเก็ตสุดท้ายของสตรีม กล่าวคือ $$Jitterleft{P_Nright} = left|ความล่าช้าซ้าย{P_Nright} - ความล่าช้าleft{P_{N-1}right}right|$$ คำจำกัดความนี้เป็นไปตาม Type-P-One-way-ipdv ตามที่กำหนดใน IETF RFC 3393

$$ ความกระวนกระวายใจเฉลี่ย = frac{JitterSum}{RxPackets} $$

หน้าใหม่

การออกแบบ/ระเบียบวิธี

การจำลองหรือห้องปฏิบัติการจริง

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

เครื่องมือ: NS-3

ns-3 เป็นโปรแกรมจำลองเครือข่ายแบบโอเพ่นซอร์สและแยกเหตุการณ์ที่ใช้เพื่อการวิจัยหรือการศึกษาเป็นหลักที่เขียนด้วยภาษา C ++ ตัวจำลองนั้นมีเอกสารที่ครอบคลุมทางออนไลน์

ns-3: พื้นฐาน

เพื่อจุดประสงค์ปัจจุบันของเรา เราเพียงต้องเข้าใจนามธรรมหลักของ ns-3 เท่านั้น

{ ความกว้าง=75% }

แอปพลิเคชัน

ก็เหมือนกับกระบวนการในคอมพิวเตอร์ของเรา คือใช้ "ซ็อกเก็ต" เพื่อส่งข้อมูลไปยังชั้นล่าง เราจะติดตั้ง BulkSendApplication ที่วางจำหน่ายทั่วไปใน ns-3 โดยใช้ซ็อกเก็ต TCP และ UDPClient และ UDPServer สำหรับการส่งแพ็กเก็ต UDP และ FlowMonitor สำหรับทั้งสองกรณีเพื่อตรวจสอบแพ็กเก็ต

UDP : ตัวเลือกช่วงเวลาการส่ง

เราจะส่งแพ็กเก็ตในช่วงเวลา 2 ไมโครวินาทีซึ่งเป็นความล่าช้าของช่องสัญญาณพื้นฐานที่ระบุด้านล่าง

UDP: ตัวเลือก MaxPacketSize

ในที่นี้หมายถึงเพย์โหลด เนื่องจาก MTU คือ 1500 โดยปกติแล้วเราจึงต้องการใช้ 1500 Bytes อย่างไรก็ตาม ส่วนหัว IP และส่วนหัว UDP ต้องใช้ 20 + 8 ไบต์ ดังนั้นเราจึงควรใช้ 1472 แทน ⁵ สิ่งนี้ได้รับการยืนยันในการจำลอง การใช้แพ็กเก็ตขนาด 1,500 ไบต์อาจส่งผลเสียต่อประสิทธิภาพการรับส่งข้อมูล

TCP: BulkSendApplication

“ตัวสร้างทราฟฟิกนี้จะส่งข้อมูลเร็วที่สุดเท่าที่จะเป็นไปได้จนถึง MaxBytes หรือจนกว่าแอปพลิเคชันจะหยุดทำงาน (หาก MaxBytes เป็นศูนย์) เมื่อบัฟเฟอร์การส่งเลเยอร์ด้านล่างเต็ม มันจะรอจนกว่าพื้นที่ว่างจะว่างเพื่อส่งข้อมูลเพิ่มเติม โดยพื้นฐานแล้วจะรักษา การไหลของข้อมูลอย่างต่อเนื่อง"

เราตั้งค่า MaxBytes เป็นจำนวนไบต์ทั้งหมด (PacketCount * PacketSize) ของ UDP เพื่อเปรียบเทียบประสิทธิภาพ และ SendSize นั้นไม่สำคัญสำหรับการทดลองบางอย่าง

สแต็กโปรโตคอล

เรียกอีกอย่างว่า InternetStackHelper ซึ่งโดยปกติจะรวม UDP, TCP Sockets, IPv4 และสำหรับจุดประสงค์ปัจจุบันของเรา TrafficControlLayer ซึ่งรวมถึงคิวและเมื่อเต็มมันจะแจ้งให้ชั้นบนทราบ

เน็ตดีไวซ์

สิ่งนี้สอดคล้องกับทั้งฮาร์ดแวร์ (การ์ดอินเทอร์เฟซเครือข่าย, NIC) และไดรเวอร์ซอฟต์แวร์ของพวกเขา และยังรวมคิวสำหรับแพ็กเก็ตด้วย จึงมีการเข้าคิวสองระดับใน ns-3

โหนด

เป็นโฮสต์ปลายทางที่เราสามารถติดตั้งได้ Application , InternetStack และ NetDevice คล้ายกับคอมพิวเตอร์ของเรา เราจะสร้าง Node สองอันและเชื่อมต่อเข้ากับสายอีเธอร์เน็ต

ช่อง

ให้ช่องทางการสื่อสารไปยัง Node และเราจะใช้ช่องทาง CSMA (เช่น Ethernet) รายละเอียดที่สำคัญที่นี่คือตัวเลือกของคุณลักษณะเหล่านี้สำหรับการปรับแต่ง: MTU, DataRate และ Delay เราจะใช้ MTU มาตรฐาน (ไม่มีเฟรมจัมโบ้ บางครั้งใช้ได้กับเครือข่ายเฉพาะ) กิกะบิต และดีเลย์ 2 ไมโครวินาที สาเหตุของเวลา 2 ไมโครวินาทีคือแสงเดินทางได้ 600 เมตร เมื่อเทียบกับการศึกษาอื่นๆ ที่ใช้ความล่าช้า 0

หน้าใหม่

ผลลัพธ์

ผลลัพธ์มีดังนี้:

ปริมาณงาน

เราสังเกตว่าปริมาณงานสำหรับ UDP สำหรับ 14720, 147200 ไบต์ที่ส่งเกิน 1000Mbps (แบนด์วิดท์ของเราคือ 1Gbps) จากนั้นเราดูที่การสูญหายของแพ็กเก็ต

เราจะเห็นได้ว่าใน 147,200 Bytes 97 จาก 100 แพ็กเก็ตหายไป พูดได้อย่างปลอดภัยว่าเราควรทิ้ง 2 รายการนี้และตรวจสอบเพิ่มเติม

เรายังเห็นได้ว่าปริมาณงาน TCP เพิ่มขึ้นทีละน้อยและแบนราบที่ประมาณ 400Mbps

ความล่าช้าโดยเฉลี่ย

เนื่องจากขาดการควบคุมการรับส่งข้อมูล แพ็กเก็ต UDP จึงสามารถ "ติด" ในคิวของชั้นล่างได้ ผลลัพธ์อาจเนื่องมาจากแพ็กเก็ตการส่งที่รวดเร็วตลอดเวลาของเราทำให้เกิดความแออัด จำเป็นต้องมีการตรวจสอบเพิ่มเติม เช่น การลดบัฟเฟอร์เพื่อดูว่าความล่าช้าเพิ่มขึ้นจริงหรือไม่

TCP

ความล่าช้าโดยเฉลี่ยลดลงหลังจาก "ถึงจุดสูงสุด" แล้วค่อย ๆ เพิ่มขึ้นอีกครั้ง อาจเกิดจากการ cwnd เพื่อหลีกเลี่ยงความแออัด จำเป็นต้องมีการตรวจสอบเพิ่มเติม เนื่องจากเราจำเป็นต้องยืนยันว่าอัลกอริทึมสำหรับการควบคุมความแออัดสร้างรูปแบบดังกล่าวจริง ๆ เนื่องจากมีทางเลือกมากมายใน ns-3 (Veno, ลูกบาศก์... ฯลฯ)

ความกระวนกระวายใจโดยเฉลี่ย

ความกระวนกระวายใจโดยเฉลี่ยคาดว่าจะลดลงเมื่อระบบ "เสถียร" และความแปรผันของความล่าช้าจะน้อยลง

TCP jitter ใหญ่กว่า UDP

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

หน้าใหม่

การอภิปราย

ทำไมไม่เปรียบเทียบแพ็กเก็ตที่สูญหาย?

BulkSendApplication ทำให้แน่ใจว่าเมื่อบัฟเฟอร์การส่งเลเยอร์ด้านล่างเต็มแล้ว ระบบจะรอ ดังนั้นที่เดียวที่เราสามารถทิ้งแพ็กเก็ตได้คือในช่องที่เราจะต้องแนะนำข้อผิดพลาด

UDPClient ไม่มีการควบคุมการรับส่งข้อมูลดังกล่าว ดังนั้นเราจึงสามารถสังเกตการสูญหายของแพ็กเก็ตได้

แล้วอะไรคือเหตุผลที่ QUIC เลือก UDP จากการศึกษาของเราที่นี่

อาจเป็นเพียงแค่ปริมาณงาน (ปริมาณงานที่มากขึ้น) และความกระวนกระวายใจ (การเปลี่ยนแปลงของความล่าช้าน้อยลง) ความล่าช้าโดยเฉลี่ยที่มากขึ้นมีสาเหตุหลักมาจากการขาดการควบคุมการรับส่งข้อมูล ซึ่ง QUIC มีเป้าหมายที่จะย้าย "อัลกอริธึมการควบคุมความแออัดไปยังพื้นที่ผู้ใช้ … แทนที่จะเป็นพื้นที่เคอร์เนล" ¹

รหัส

https://github.com/alfredtso/ns-3-project

หน้าใหม่

อ้างอิง

ทรัพยากรการฝึกอบรม ns-3

ร่าง HTTP/3

เชิงอรรถ

1. ควิก ↩ ↩ ²

2. QUIC GoogleDoc ↩

3. Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin, การสร้างแบบจำลองประสิทธิภาพและการวิเคราะห์การไหลของ TCP และ UDP บนเครือข่ายที่กำหนดโดยซอฟต์แวร์, วารสารเครือข่ายและแอปพลิเคชันคอมพิวเตอร์, เล่มที่ 130, 2019, หน้า 76-88, ISSN 1084-8045 ↩

4. Jingyi He, S.-H.Gary Chan, ประสิทธิภาพ TCP และ UDP สำหรับอินเทอร์เน็ตผ่านเครือข่ายสวิตช์แพ็กเก็ตออปติคัล, เครือข่ายคอมพิวเตอร์, เล่มที่ 45, ฉบับที่ 4, 2004, หน้า 505-521, ISSN 1389-1286 ↩

5. Eric Gamess, Rina Surós, โมเดลขอบเขตบนสำหรับปริมาณงาน TCP และ UDP ใน IPv4 และ IPv6, วารสารแอปพลิเคชันเครือข่ายและคอมพิวเตอร์, เล่มที่ 31, ฉบับที่ 4, 2008, หน้า 585-602, ISSN 1084-8045 ↩ ↩ ²

6. Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, ประสิทธิภาพการจำลองของโปรโตคอล TCP, SCTP, DCCP และ UDP บนเครือข่าย 4G, วิทยาศาสตร์คอมพิวเตอร์ Procedia, เล่มที่ 111, 2017, หน้า 2-7, ISSN 1877-0509 ↩