ทำไม Tor รู้สึกช้ากว่า VPN: การคลิกกับการดาวน์โหลด

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

อาการชี้ไปที่ต้นทุนการตั้งค่า ไม่ใช่ความจุ

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

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

ความหน่วงและความจุล้มเหลวคนละแบบ

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

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

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

การกำหนดเส้นทางแบบหัวหอมเพิ่มการกระโดดที่คุณไม่ได้เลือก

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

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

การเปลี่ยนลำดับของห่วงโซ่เปลี่ยนการทดลอง

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

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

การเปรียบเทียบที่ทนการรันครั้งที่สอง

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

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