ระยะทางกายภาพส่งผลต่อความเร็วในการดาวน์โหลดหรือไม่

22

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

tcp latency bandwidth

— Navid
แหล่งที่มา

2

คุณสามารถยืนยันด้วยตัวคุณเองได้เล็กน้อย Ping เซิร์ฟเวอร์เพื่อรับค่าเวลาแฝง จากนั้น 2Mbps * Latency == หน้าต่าง คุณสามารถยืนยันขนาดหน้าต่างจริงด้วย wireshark แต่สมมติว่าคุณไม่มีการปรับขนาดหน้าต่างจากนั้นเป็น 64kB / 2Mbps = 256ms ดังนั้นฉันคาดการณ์ว่าเซิร์ฟเวอร์ของคุณจะอยู่ห่างจาก 256ms

— ytti

2

@ytti อธิบายทางอ้อม BDP (แบนด์วิดท์ผลิตภัณฑ์ล่าช้า) ซึ่งแปลโดยประมาณว่าเป็นเครือข่ายยาว (ล่าช้า), ไขมัน (แบนด์วิดท์) ยากที่จะรักษาเต็มและไม่กินอะไรจากปริมาณงานที่มีศักยภาพของคุณ ดูen.wikipedia.org/wiki/Bandwidth-delay_product

— Generalnetworkerror

2

@ytti, Windows Vista และต่อมามีการปรับขนาดหน้าต่างตามค่าเริ่มต้น ... เราจำเป็นต้องรู้ว่า OS Navid ใช้อะไรในการทดสอบ

— Mike Pennington

ตามsupport.microsoft.com/kb/934430 การปรับขนาด (ตัวประกอบ 8) นี้เป็นค่าเริ่มต้นใน Vista แต่ไม่ใช่สำหรับ HTTP เท่านั้น ฉันไม่ใช่ผู้ใช้ Window ด้วยตัวเองดังนั้นจึงไม่สามารถตรวจสอบได้

— ytti

2

@ytti ฉันไม่แน่ใจว่ามีความเกี่ยวข้อง ฉันเรียกใช้ Vista และฉันกำลังดูการเชื่อมต่อ HTTP ของฉันไปยังหน้าสนับสนุนนั้นและ TCP SYN พูดว่า: "Window Scale: 2 (คูณด้วยปัจจัย 4)"

— Mike Pennington

23

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

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

การปรับขนาดหน้าต่าง TCP
การปรับบัฟเฟอร์โฮสต์

ความแตกต่างในผลลัพธ์ที่คุณเห็นอาจได้รับผลกระทบจาก:

การสูญเสียแพ็คเก็ต
การถ่ายโอน TCP แบบขนาน

การปรับขนาดหน้าต่าง TCP: เอฟเฟกต์การหน่วงเวลาแบนด์วิดท์

ดังที่เพื่อนของคุณได้กล่าวถึงการใช้งาน TCP แบบเก่าได้รับผลกระทบจากข้อ จำกัด ที่กำหนดโดยขนาดหน้าต่างรับ 16 บิตดั้งเดิมในส่วนหัว TCP (อ้างอิงRFC 793: ส่วน 3.1 ); RWIN ควบคุมจำนวนข้อมูลที่ไม่ได้รับการยอมรับที่สามารถรอในซ็อกเก็ต TCP เดียว ค่า RWIN แบบ 16 บิต จำกัด เส้นทางอินเทอร์เน็ตที่ จำกัด ด้วยผลิตภัณฑ์ที่มีความล่าช้าในแบนด์วิดท์สูง (และการเชื่อมต่ออินเทอร์เน็ตความเร็วสูงจำนวนมากในปัจจุบันจะถูก จำกัด โดยค่า 16 บิต)

สำหรับค่า RTT ที่สูงจะเป็นประโยชน์หากมี RWIN ขนาดใหญ่มาก ตัวอย่างเช่นหากเส้นทาง RTT ของคุณจากมาเลเซียไปยังสหรัฐอเมริกาอยู่ที่ประมาณ 200ms TCP RWIN ดั้งเดิมจะ จำกัด ให้คุณอยู่ที่ 2.6Mbps

ปริมาณงาน_{สูงสุด} = Rcv_Win / RTT

* ปริมาณงาน_{สูงสุด} = 65535 * 8 / 0.200 *

ปริมาณงาน_{สูงสุด} = 2.6Mbps

RFC 1323กำหนด "ตัวเลือก TCP" บางอย่างเพื่อเอาชนะข้อ จำกัด เหล่านี้ หนึ่งในตัวเลือก TCP เหล่านั้นคือ "window scaling" มันแนะนำตัวประกอบสเกลซึ่งคูณค่า RWIN ดั้งเดิมเพื่อรับค่าหน้าต่างรับแบบเต็ม ใช้ตัวเลือกการปรับขนาดหน้าต่างให้ RWIN สูงสุด 1073725440 ไบต์ ใช้การคำนวณเดียวกัน:

ปริมาณงาน_{สูงสุด} = Rcv_Win / RTT

* ปริมาณงาน_{สูงสุด} = 1073725440 * 8 / 0.200 *

ปริมาณงาน_{สูงสุด} = 42.96Gbps

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

การสูญเสียแพ็คเก็ต

วงจรอินเทอร์เน็ตทั่วมหาสมุทรแปซิฟิกค่อนข้างหนาแน่นในบางครั้ง ครอบครัวของฉันบางคนอาศัยอยู่ในไต้หวันและเราพบปัญหาเป็นประจำเมื่อเราใช้ Google Talk กับพวกเขา ฉันมักจะเห็นการสูญเสียแพ็คเก็ตมากกว่า 0.5% เมื่อฉัน ping สาย DSL ของพวกเขาจากสหรัฐอเมริกา หากคุณเห็นอะไรเช่นการสูญเสีย 0.5% ไปยังเซิร์ฟเวอร์ "ช้าลง" จะง่ายมากที่จะ จำกัด ปริมาณงานบนซ็อกเก็ต TCP เดียว

สตรีม TCP แบบขนาน

FYI บางเว็บไซต์ทดสอบความเร็วใช้กระแส TCP ขนานไปกับการเพิ่ม throughput ; สิ่งนี้อาจส่งผลต่อผลลัพธ์ที่คุณเห็นเนื่องจากสตรีม TCP แบบขนานเพิ่มปริมาณงานอย่างมากในกรณีที่คุณสูญเสียแพ็กเก็ตในเส้นทาง ฉันได้เห็นลำธาร TCP แบบขนานสี่กระแสเต็มอิ่มที่เคเบิลโมเด็ม 5Mbps ซึ่งรับความเสียหายจากการสูญเสียแพ็กเก็ตคงที่ 1% โดยปกติการสูญเสีย 1% จะทำให้ปริมาณงานของสตรีม TCP เดี่ยวลดลง

วัสดุโบนัส: การปรับแต่งบัฟเฟอร์โฮสต์

ระบบปฏิบัติการรุ่นเก่าหลายแห่งมีซ็อกเก็ตที่มีบัฟเฟอร์ จำกัด ด้วยระบบปฏิบัติการรุ่นเก่า (เช่น Windows 2000) มันไม่สำคัญว่า TCP จะอนุญาตให้มีข้อมูลจำนวนมากบนเครื่องหรือไม่ ... บัฟเฟอร์ซ็อกเก็ตไม่ได้ถูกปรับแต่งเพื่อใช้ประโยชน์จาก RWIN ขนาดใหญ่ มีจำนวนมากของการวิจัยที่จะทำคือการเปิดใช้งานที่มีประสิทธิภาพสูงในการถ่ายโอน TCP ระบบปฏิบัติการที่ทันสมัย (สำหรับคำตอบนี้เราสามารถเรียก Windows Vista และต่อมา "ทันสมัย") รวมถึงกลไกการจัดสรรบัฟเฟอร์ที่ดีขึ้นในการใช้ซ็อกเก็ตบัฟเฟอร์

— ไมค์เพนนิงตัน
แหล่งที่มา

4

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

— Chris Down

เราเตอร์คืออุปกรณ์ L3 การปรับสเกลหน้าต่าง TCP เป็นกระบวนการ L4 เราเตอร์ส่งต่อแพ็คเก็ตหรือไม่และยกเว้นการใช้กลไก QoS ไม่มีความแตกต่างระหว่าง TCP, UDP หรือโปรโตคอลอื่น ๆ แน่นอนว่าเราเตอร์จะมีผลต่อการเจรจา MSS เริ่มต้น (.. หรือถ้าพวกมันดรอป ICMP ไม่สามารถเข้าถึงได้) แต่อัลกอริทึมของหน้าต่างบานเลื่อนเป็นหน้าที่ของสแต็คในระบบปลายทางอย่างหมดจด

— rnxrx

2

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

— ytti

3

คำตอบสั้น ๆ : ใช่ระยะทางมีผลต่อแบนด์วิดท์สตรีมเดี่ยว

อินเทอร์เน็ตมีการพัฒนาวิธีการ จำกัด ผลกระทบนั้น ... ล่าช้า ACK, ปรับขนาดหน้าต่าง, โปรโตคอลอื่น ๆ :-) แต่ฟิสิกส์ยังคงชนะในที่สุด ในกรณีนี้มีแนวโน้มที่จะเกิดความแออัดของเครือข่ายมากกว่าการกระโดดหลายครั้ง - ใช้แพ็คเก็ตที่ถูกส่งเพียงครั้งเดียวเพื่อฆ่าสตรีม TCP

— Ricky Beam
แหล่งที่มา

1

ในขณะที่มีคำตอบที่ยอดเยี่ยมนี้แล้วฉันต้องการเพิ่ม: ไม่ความเร็วไม่จำเป็นต้องได้รับผลกระทบจากระยะทางและใช่บ่อยครั้งความเร็วที่ได้รับผลกระทบจากระยะทางมีทั้งจริง

ทำไมถึงเป็นอย่างนั้น?

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

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

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

— Zac67
แหล่งที่มา

-1

ตามที่Andrew Martinคำตอบคือใช่

— โจนาธาน
แหล่งที่มา

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

— Teun Vink

เพื่อนมันไม่ได้เป็นเพียงคำตอบที่เชื่อมโยงมันเป็นภาพที่มีสถิติ

— โจนาธาน

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

— Teun Vink

ฉันไม่รู้ว่าทำไมมันยากสำหรับคุณ แต่แกน X และ Y มีป้ายกำกับ "ความเร็วในการดาวน์โหลดโดยเฉลี่ยเป็น Mbps"

— Jonathan