เวลาทำงานของเซิร์ฟเวอร์ VPN: ตัวเลขนั้นไม่ได้บอกอะไรคุณ

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

ตัวเลขวัดอะไร

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

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

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

กระบวนการอาจทำงานอยู่ขณะที่เส้นทางล่ม

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

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

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

ความสดใหม่: รายงานเก่ากว่าความพยายามของคุณ

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

ช่องว่างนั้นทำงานในทิศทางตรงกันข้ามด้วย โหนดที่ถูกรายงานว่าล่มอาจฟื้นตัวภายในไม่กี่นาทีหลังสร้างรายงาน ดังนั้นการลองใหม่ทันทีกับโหนดอื่นจึงไม่ใช่ทางเลือกที่ดีกว่าเสมอ

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

จะทดสอบอะไรแทน

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

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

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

อ่านรายการโหนดสาธารณะโดยไม่ถูกทำให้เข้าใจผิด

เวลาทำงานไม่ได้นำข้อมูลเกี่ยวกับสิ่งที่ผู้คนมักต้องการจาก VPN มาเลย คือความถูกต้องของใบรับรอง ใครดำเนินการทางออก นโยบาย DNS ใดที่ใช้ และผู้ให้บริการเก็บบันทึกการเชื่อมต่อหรือไม่ สิ่งเหล่านี้เป็นการกล่าวอ้างแยกกันที่ต้องมีหลักฐานแยกกัน และตัวนับยาวไม่ใช่หลักฐานของสิ่งใดเลย โหนดอาจเสถียรเป็นเดือนและยังเป็นทางเลือกที่ไม่ดีสำหรับข้อกำหนดความเป็นส่วนตัว

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

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