IP แบบคงที่ใน GCP เทียบกับความเร็ว VPN: สามตัวแปร หนึ่งการทดสอบ

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

ที่อยู่ที่จองไว้ให้อะไรจริง ๆ

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

เหล่านั้นเป็นเหตุผลดีที่จะจองสักอัน ไม่มีข้อใดเป็นเหตุผลด้านทรูพุต

รักษาชั้น ที่อยู่ และการขนส่งเป็นสามตัวแปร

Google Cloud ยังขายชั้นบริการเครือข่าย Premium และ Standard และทั้งสองใช้เส้นทางต่างกันสู่อินเทอร์เน็ตด้วยความพร้อมของฟีเจอร์ที่ต่างกัน การกำหนดที่อยู่แบบคงที่เป็นมุมฉากกับทั้งสอง ดังนั้นจงถือว่าคงที่และ Premium เป็นข้อเท็จจริงที่ไม่เกี่ยวข้องกันเกี่ยวกับ VM ไม่ใช่คำพ้อง บันทึกชั้นจริง ภูมิภาค และการเชื่อมต่อหรือสิ่งที่แนบใด ๆ ที่เกี่ยวข้อง เพราะสิ่งเหล่านี้อธิบายเส้นทางในแบบที่ป้ายที่อยู่จะไม่มีวันทำได้

สามตัวแปร สามการทดลองแยกกัน ไม่อย่างนั้นผลลัพธ์ก็คือเรื่องเล่า ไม่ใช่การวัด

ออกแบบการทดสอบที่ตอบคำถามเดียว

ตรึง VM ที่อยู่ ตำแหน่งไคลเอนต์ ปลายทาง และภาระงานไว้ให้คงที่ขณะเปรียบเทียบโปรไฟล์ UDP และ TCP ที่อนุมัติแล้ว ต้องมีทั้งตัวรับฟังฝั่งเซิร์ฟเวอร์ต่อการขนส่งแต่ละแบบและกฎไฟร์วอลล์ที่เข้าคู่กัน การแก้คีย์เวิร์ดในไคลเอนต์แล้วปล่อยตัวรับฟังไว้ไม่เปลี่ยนทดสอบแค่ความอดทนของคุณ ใช้การถ่ายโอนที่ทำซ้ำได้และบันทึกทิศทาง ระยะเวลา สตรีมเดี่ยวเทียบแบบขนาน และหน่วย เพราะ MB/s กับ Mb/s ต่างกันแปดเท่า

เฝ้าดู CPU ของ VM ด้วย เพราะอินสแตนซ์เล็กอิ่มตัวจากการเข้ารหัสหรืองาน softirq นานก่อนที่เครือข่ายจะอิ่มตัว และเพดานนั้นจะดูเหมือนขีดจำกัดของผู้ให้บริการทุกประการ

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

ทำไม UDP กับ TCP จึงต่างกันในเชิงกลไก

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

ดังนั้นการทดสอบ TCP ที่เร็วกว่าจึงพิสูจน์ว่า TCP เร็วกว่าในวันนั้นบนเส้นทางนั้น และไม่มีอะไรที่ทั่วไปกว่านั้น

เขียนผลลัพธ์ให้ทนต่อการตรวจทาน

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

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