rperf
v0.1.8
rperf เป็นทางเลือก iperf แบบ Rust ที่พัฒนาโดย 3D-P โดยมีเป้าหมายเพื่อหลีกเลี่ยงปัญหาด้านความน่าเชื่อถือและความสอดคล้องที่พบใน iperf3 ในขณะเดียวกันก็ให้ข้อมูลตัวชี้วัดที่สมบูรณ์ยิ่งขึ้น โดยมุ่งเน้นไปที่การดำเนินงานในสภาพแวดล้อมที่ทนต่อการสูญเสียและคล้ายกับ IoT มากขึ้น แม้ว่าจะสามารถนำมาใช้แทน iperf แบบเกือบจะดรอปอินได้ และอาจมีประโยชน์ในการทำเช่นนั้น แต่การมุ่งเน้นไปที่การรวบรวมข้อมูลเป็นระยะในความสามารถในการตรวจสอบในเครือข่ายแบบปิด หมายความว่ามันไม่เหมาะสำหรับทุกโดเมน iperf นั้นสามารถให้บริการได้
rperf เป็นการใช้งานอิสระ โดยอ้างอิงอัลกอริธึมของ iperf3 และ zapwireless เพื่อประเมินความถูกต้องและรับการแก้ไขที่เหมาะสม แต่ไม่มีการคัดลอกโค้ดจากทั้งสองอย่าง
โดยเฉพาะอย่างยิ่ง ปัญหาที่สำคัญที่สุดที่ได้รับการจัดการจาก iperf3 มีดังนี้:
เซิร์ฟเวอร์ที่กำหนดรองรับหลายไคลเอนต์พร้อมกัน
การใช้ RFC 1889 ของ rperf สำหรับการสตรีมการคำนวณ jitter เริ่มต้นโดยสมมติว่าเดลต้าระหว่างแพ็กเก็ตที่หนึ่งและที่สองในลำดับและช่องว่างในลำดับจะกระตุ้นให้เกิดการรีเซ็ตการนับ เมื่อเปรียบเทียบกันแล้ว iperf3 เริ่มต้นด้วย 0 ซึ่งสร้างค่าที่ต่ำเกินจริง และในกรณีของช่องว่าง มันจะดำเนินต่อไปอย่างไร้เดียงสา ซึ่งสร้างค่าที่สูงเกินจริง
แพ็กเก็ตที่ซ้ำกันจะถูกพิจารณาในการแลกเปลี่ยน UDP และแพ็กเก็ตที่ไม่อยู่ในลำดับจะถูกนับเป็นเหตุการณ์อิสระ
การรับส่งข้อมูลทั้งหมดสามารถปล่อยออกมาตามสัดส่วนในช่วงเวลาย่อยวินาทีปกติ ช่วยให้สามารถกำหนดค่าที่สะท้อนถึงการส่งข้อมูลจริงและอัลกอริธึมการส่งได้แม่นยำยิ่งขึ้น
การกำหนดค่าสตรีมและผลลัพธ์จะได้รับการแลกเปลี่ยนผ่านการเชื่อมต่อเฉพาะ และเส้นทางข้อมูลทุกเส้นทางได้กำหนดความหมายการหมดเวลา ความสมบูรณ์ และความล้มเหลวไว้อย่างชัดเจน ดังนั้นการดำเนินการจะไม่หยุดทำงานอย่างไม่มีกำหนดที่ด้านใดด้านหนึ่งของการทดสอบเมื่อแพ็กเก็ตคีย์สูญหาย
เอาต์พุต JSON ของ rperf มีโครงสร้างถูกกฎหมาย ไม่มีสตริงที่ไม่ได้ใส่เครื่องหมายคำพูด คีย์ที่ซ้ำกัน หรือเครื่องหมายจุลภาคห้อย ซึ่งทั้งหมดนี้จำเป็นต้องมีการประมวลผลล่วงหน้าก่อนที่จะใช้งาน หรือทำให้เกิดข้อผิดพลาดที่ไม่คาดคิด
ตรงกันข้ามกับ zapwireless มีการปรับปรุงต่อไปนี้:
rperf ใช้สถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์แบบคลาสสิก ดังนั้นจึงไม่จำเป็นต้องรักษากระบวนการทำงานบนอุปกรณ์ที่รอคำขอดำเนินการทดสอบ
มีการคำนวณความกระวนกระวายใจ
รองรับ IPv6
การสตรีมหลายรายการอาจทำงานแบบขนานซึ่งเป็นส่วนหนึ่งของการทดสอบ
มีตัวเลือก omit เพื่อละทิ้งเวลาเพิ่ม TCP ออกจากผลลัพธ์
เอาต์พุตมีอยู่ใน JSON เพื่อการเก็บเกี่ยวทางไกลที่ง่ายขึ้น
rperf ควรสร้างและทำงานบนแพลตฟอร์มหลักๆ ทั้งหมด แม้ว่าการพัฒนาและการใช้งานจะเน้นไปที่ระบบที่ใช้ Linux ก็ตาม ดังนั้นนั่นคือจุดที่มันจะมีคุณสมบัติครบถ้วนที่สุด
เรายินดีรับคำขอดึงเพื่อใช้งานคุณลักษณะที่เทียบเท่ากับระบบอื่นๆ
ทุกอย่างระบุไว้ในผลลัพธ์ของ --help และผู้ใช้ส่วนใหญ่ที่คุ้นเคยกับเครื่องมือที่คล้ายกันควรรู้สึกสบายใจทันที
rperf ทำงานเหมือนกับ iperf3 มาก แบ่งปันแนวคิดมากมาย และแม้แต่แฟล็กบรรทัดคำสั่ง สิ่งสำคัญประการหนึ่งที่แตกต่างคือไคลเอ็นต์ขับเคลื่อนกระบวนการกำหนดค่าทั้งหมด ในขณะที่เซิร์ฟเวอร์ปฏิบัติตามอย่างเต็มความสามารถและให้ผลลัพธ์ที่ต่อเนื่อง ซึ่งหมายความว่าเซิร์ฟเวอร์จะไม่นำเสนอผลการทดสอบโดยตรงผ่านอินเทอร์เฟซ และยังสามารถเรียกใช้การทดสอบ TCP และ UDP กับอินสแตนซ์เดียวกัน ซึ่งอาจดำเนินการโดยไคลเอนต์หลายตัวพร้อมกัน
ในโหมดการทำงานปกติ ไคลเอนต์จะอัพโหลดข้อมูลไปยังเซิร์ฟเวอร์ เมื่อตั้งค่าสถานะ reverse ลูกค้าจะได้รับข้อมูล
ต่างจาก iperf3 ตรงที่ rperf ไม่ได้ใช้ช่วงพอร์ตที่สงวนไว้ตามค่าเริ่มต้น ด้วยเหตุนี้จึงสามารถรองรับไคลเอนต์จำนวนเท่าใดก็ได้ในแบบคู่ขนานโดยไม่มีการแย่งชิงทรัพยากรกับพอร์ตที่ต่อเนื่องกันจำนวนเล็กน้อยเท่านั้น ตามความสามารถที่ตั้งใจไว้ สิ่งนี้ไม่น่าจะเป็นปัญหา แต่เมื่อเกี่ยวข้องกับไฟร์วอลล์ที่ไม่ได้รับอนุญาตและการตั้งค่า NAT ตัวเลือก --tcp[6]-port-pool และ --udp[6]-port-pool อาจเป็นได้ ใช้เพื่อจัดสรรพอร์ตที่ไม่ต่อเนื่องกันให้กับชุดที่จะใช้รับทราฟฟิก
นอกจากนี้ยังไม่มีแนวคิดในการทดสอบปริมาณงานที่เกี่ยวข้องกับปริมาณข้อมูลคงที่ แต่มุ่งเน้นไปที่การวัดปริมาณงานในช่วงเวลาที่ทราบโดยประมาณเท่านั้น
สิ่งที่เกี่ยวข้องอีกอย่างคือ หากเซิร์ฟเวอร์ทำงานในโหมด IPv6 และโฮสต์รองรับการแมป IPv4 ในการกำหนดค่าแบบสแต็กคู่ ทั้งไคลเอนต์ IPv4 และ IPv6 ก็สามารถเชื่อมต่อกับอินสแตนซ์เดียวกันได้
rperf ใช้ สินค้า กระบวนการทั่วไปจะเป็นเพียงแค่ cargo build --release
cargo-deb ยังได้รับการสนับสนุนและจะสร้างแพ็คเกจ Debian ที่ใช้งานได้ซึ่งติดตั้งบริการ rperf systemd ที่ปิดใช้งานโดยค่าเริ่มต้น เมื่อเริ่มต้น มันจะทำงานเป็น nobody:nogroup โดยถือว่ารองรับ IPv6 เป็นค่าเริ่มต้น
เช่นเดียวกับผลิตภัณฑ์รุ่นเดียวกัน แนวคิดหลักของ rperf คือการส่งกระแสข้อมูล TCP หรือ UDP ไปยังเป้าหมาย IP ด้วยความเร็วเป้าหมายที่จัดเตรียมไว้ล่วงหน้า จำนวนข้อมูลที่ได้รับจริงจะถูกสังเกตและใช้เพื่อวัดความจุของลิงก์เครือข่าย
ภายในโดเมนเหล่านั้น ข้อมูลเพิ่มเติมเกี่ยวกับคุณภาพของการแลกเปลี่ยนจะถูกรวบรวมและทำให้พร้อมสำหรับการตรวจสอบ
ในทางสถาปัตยกรรม rperf มีไคลเอนต์สร้างการเชื่อมต่อ TCP ไปยังเซิร์ฟเวอร์ หลังจากนั้นไคลเอนต์จะส่งรายละเอียดเกี่ยวกับการทดสอบที่จะดำเนินการและเซิร์ฟเวอร์มีหน้าที่รับผิดชอบ โดยรายงานผลการสังเกตไปยังไคลเอนต์ในระหว่างกระบวนการทดสอบทั้งหมด
ไคลเอนต์อาจขอให้ใช้สตรีมแบบขนานหลายรายการสำหรับการทดสอบ ซึ่งได้รับการอำนวยความสะดวกโดยการสร้างการเชื่อมต่อ TCP หรือซ็อกเก็ต UDP หลายช่องด้วยเธรดเฉพาะของตนเองที่ด้านใดด้านหนึ่ง ซึ่งอาจปักหมุดเพิ่มเติมไว้ที่คอร์ CPU แบบลอจิคัลตัวเดียวเพื่อลดผลกระทบของเพจ - ข้อผิดพลาดในการแลกเปลี่ยนข้อมูล
ความสัมพันธ์ระหว่างไคลเอ็นต์-เซิร์ฟเวอร์ถือเป็นส่วนสำคัญของการออกแบบนี้ ตรงกันข้ามกับ iperf3 ซึ่งมีลักษณะเหมือนเพื่อนมากกว่า และ zapwireless โดยที่ผู้เข้าร่วมแต่ละคนจะรัน daemon ของตัวเองและกระบวนการที่สามจะจัดการการสื่อสาร
โดยเฉพาะอย่างยิ่ง การรวบรวมข้อมูล การคำนวณ และการแสดงผลทั้งหมดเกิดขึ้นที่ฝั่งไคลเอ็นต์ โดยเซิร์ฟเวอร์จะส่งคืนสิ่งที่สังเกตได้ สิ่งนี้สามารถนำไปสู่การเบี่ยงเบนในการบันทึก โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับเวลา (ช่วงเวลาของเซิร์ฟเวอร์ที่นานกว่าค่าไคลเอนต์ที่เกี่ยวข้องนั้นไม่ใช่เรื่องแปลกเลย) สมมติว่าการเชื่อมต่อไม่สูญหาย อย่างไรก็ตาม ผลรวมของข้อมูลที่สังเกตได้จะตรงกันในทุกโหมดการทำงาน
เซิร์ฟเวอร์ใช้เธรดสามชั้น: หนึ่งชั้นสำหรับเธรดหลัก หนึ่งชั้นสำหรับแต่ละไคลเอนต์ที่ให้บริการ และอีกชั้นหนึ่งสำหรับแต่ละสตรีมที่สื่อสารกับไคลเอนต์ บนฝั่งไคลเอ็นต์ เธรดหลักใช้เพื่อสื่อสารกับเซิร์ฟเวอร์ และสร้างเธรดเพิ่มเติมสำหรับแต่ละสตรีมที่สื่อสารกับเซิร์ฟเวอร์
เมื่อเซิร์ฟเวอร์ได้รับการร้องขอจากไคลเอนต์ เซิร์ฟเวอร์จะสร้างเธรดที่จัดการคำขอเฉพาะของไคลเอนต์นั้น ภายใน แต่ละสตรีมสำหรับการทดสอบจะสร้างตัวจัดการที่เหมือนตัววนซ้ำทั้งสองด้าน ทั้งไคลเอนต์และเซิร์ฟเวอร์เรียกใช้ตัววนซ้ำ-อะนาล็อกเหล่านี้ต่อกันแบบอะซิงโครนัสจนกว่าช่วงการทดสอบจะสิ้นสุดลง ณ จุดที่ผู้ส่งระบุว่าเสร็จสิ้นภายในสตรีม
ในการจัดการความเป็นไปได้ของการตัดการเชื่อมต่อในระดับสตรีมได้อย่างน่าเชื่อถือ กลไก Keepalive ในสตรีมไคลเอ็นต์-เซิร์ฟเวอร์ ซึ่งผลการทดสอบจะถูกส่งจากเซิร์ฟเวอร์ในช่วงเวลาปกติ จะยุติการเชื่อมต่อที่ค้างอยู่หลังจากไม่มีการใช้งานไม่กี่วินาที
กลไก TCP และ UDP ของระบบปฏิบัติการโฮสต์ใช้สำหรับการรับส่งข้อมูลจริงทั้งหมดที่แลกเปลี่ยน โดยมีการเปิดเผยพารามิเตอร์การปรับแต่งบางส่วน แนวทางนี้ได้รับเลือกเหนือการใช้งานพื้นที่ผู้ใช้ที่ด้านบนของเลเยอร์ 2 หรือเลเยอร์ 3 เนื่องจากวิธีนี้แสดงถึงวิธีการทำงานของแอปพลิเคชันในโลกแห่งความเป็นจริงได้แม่นยำที่สุด
ค่า "การประทับเวลา" ที่มองเห็นได้ในข้อมูลช่วงเวลาที่ทำให้เป็นอนุกรมของ JSON นั้นขึ้นอยู่กับโฮสต์ ดังนั้น เว้นแต่ว่าสภาพแวดล้อมของคุณจะมีความแม่นยำของนาฬิการะบบที่สูงมาก การประทับเวลาการส่งควรเปรียบเทียบกับการประทับเวลาการส่งอื่นๆ เท่านั้น และเช่นเดียวกันสำหรับการประทับเวลาการรับ โดยทั่วไป ข้อมูลนี้ไม่มีประโยชน์นอกเหนือจากการตรวจสอบความถูกต้อง
ในระหว่างแต่ละช่วงการแลกเปลี่ยน มีการพยายามส่งไบต์ length ในแต่ละครั้ง จนกว่าจำนวนที่เขียนไปยังสตรีมจะตรงตามหรือเกินเป้าหมายแบนด์วิดธ์ ซึ่ง ณ จุดนี้ผู้ส่งจะเงียบไปจนกระทั่งเริ่มช่วงเวลาถัดไป ข้อมูลที่ส่งภายในช่วงเวลาควรมีการกระจายอย่างสม่ำเสมอในช่วงเวลานั้น
ดัชนีสตรีมเริ่มต้นที่ 0 ไม่ใช่ 1 สิ่งนี้อาจไม่ทำให้ใครแปลกใจ แต่การเห็น "สตรีม 0" ในรายงานไม่ได้ทำให้เกิดข้อกังวล
rperf จัดจำหน่ายโดย Evtech Solutions, Ltd., dba 3D-P ภายใต้ GNU GPL เวอร์ชัน 3 ซึ่งอาจพบข้อความได้ใน COPYING
รายละเอียดการประพันธ์ ข้อมูลเฉพาะด้านลิขสิทธิ์ และบันทึกความสามารถในการถ่ายโอนมีอยู่ในซอร์สโค้ด
