การคำนวณขีดจำกัดปริมาณข้อมูลของ TCP
ประสิทธิภาพที่แท้จริงของการส่งข้อมูลผ่านโปรโตคอล TCP บนเครือข่ายไม่ได้ขึ้นอยู่กับความเร็วของสายสัญญาณเพียงอย่างเดียว แต่ถูกกำหนดด้วยปัจจัยร่วมสามประการ ได้แก่ อัตราลิงก์ หน้าต่างรับข้อมูล และอัตราการสูญหายของแพ็กเก็ต เครื่องคำนวณนี้จะหาขีดจำกัดสูงสุดของการไหลของ TCP เดี่ยวในสภาวะคงตัว โดยการเปรียบเทียบขีดจำกัดทั้งสามด้านนี้ และระบุว่าปัจจัยใดคือคอขวดที่แท้จริงที่ทำให้ความเร็วในการส่งข้อมูลลดลง
การคำนวณประสิทธิภาพนี้อ้างอิงตามสูตรหลัก:
throughput = min(อัตราความเร็ว × ประสิทธิภาพ, หน้าต่างรับข้อมูล ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = อัตราความเร็ว × RTT
ทุกค่าที่คุณกรอกจะถูกคำนวณในเบราว์เซอร์นี้ — ไม่มีข้อมูลใดถูกส่งออกไปภายนอก
ปัจจัยนำเข้าและข้อจำกัดของระบบ
เพื่อวิเคราะห์ประสิทธิภาพของเส้นทางเครือข่าย เครื่องคำนวณต้องการข้อมูลนำเข้าดังต่อไปนี้:
- อัตราลิงก์: ความเร็วของโฮปที่ช้าที่สุดบนเส้นทาง ซึ่งต้องมีค่ามากกว่าศูนย์
- เวลาเดินทางไป-กลับ (RTT): เวลาปิงไปยังปลายทางที่เป็นค่าสูงสุดภายใต้ภาระงาน โดยต้องมีค่ามากกว่าศูนย์
- ขนาดข้อมูล: ขนาดของไฟล์หรือชุดข้อมูลที่ต้องการเคลื่อนย้าย ซึ่งต้องมีค่ามากกว่าศูนย์
- หน้าต่างรับข้อมูล: ขนาดบัฟเฟอร์ของผู้รับ มีค่ามากกว่าศูนย์ และไม่เกิน 1,073,725,440 ไบต์ หากว่างไว้จะถือว่าไม่มีการจำกัดขนาดหน้าต่าง
- MSS (ไบต์): ขนาดข้อมูลผู้ใช้ต่อแพ็กเก็ต ต้องเป็นจำนวนเต็มระหว่าง 1 ถึง 65,495 ไบต์ หากว่างไว้ระบบจะละเว้นส่วนหัวโปรโตคอลและการสูญหาย
- แพ็กเก็ตสูญหาย (%): อัตราการสูญหายเฉลี่ยของแพ็กเก็ต ต้องมีค่าระหว่าง 0 ถึง 100 เปอร์เซ็นต์
- ตำแหน่งทศนิยมที่แสดง: กำหนดความละเอียดของทศนิยมในผลลัพธ์
อินเตอร์เฟสมีปุ่ม โหลดตัวอย่าง เพื่อใส่ค่าตัวอย่าง และปุ่ม ล้างข้อมูล เพื่อเริ่มกรอกค่าใหม่
ขีดจำกัดทางสถาปัตยกรรมและการปรับขนาดหน้าต่าง TCP
ในการส่งข้อมูลผ่านเครือข่ายที่มีความหน่วงสูง ขนาดของหน้าต่างรับข้อมูล (TCP Receive Window) เป็นสิ่งสำคัญอย่างยิ่ง:
- ความจำเป็นในการปรับขนาด: หน้าต่างรับข้อมูลแบบดั้งเดิมของ TCP มีขีดจำกัดสูงสุดแบบไม่ปรับขนาดอยู่ที่ 65,535 ไบต์ หากผลคูณแบนด์วิดท์และเวลาหน่วง (BDP) ของเส้นทางสูงกว่าค่านี้ ระบบจะแสดงข้อความเตือน เพื่อแจ้งว่าต้องเจรจาการปรับขนาดหน้าต่าง TCP (RFC 7323)
- ขีดจำกัดสูงสุดของโปรโตคอล: ขีดจำกัดสูงสุดที่ TCP สามารถเจรจาได้ผ่าน RFC 7323 คือ 1,073,725,440 ไบต์ หากหน้าต่างที่ต้องใช้เกินค่านี้ ระบบจะแสดงข้อความเตือน เนื่องจากไม่สามารถส่งข้อมูลได้เร็วกว่าขีดจำกัดนี้บนเส้นทางดังกล่าว
- คำแนะนำในการปรับปรุง: หากการเพิ่มขนาดหน้าต่างรับข้อมูลสามารถช่วยเพิ่มประสิทธิภาพได้ ระบบจะแสดงข้อความ เพื่อระบุขนาดหน้าต่างที่เหมาะสม
แบบจำลองการสูญหายและประสิทธิภาพโปรโตคอล
การคำนวณประสิทธิภาพของระบบเครือข่ายในเครื่องมือนี้ใช้หลักเกณฑ์ทางเทคนิคดังนี้:
- ประสิทธิภาพของโปรโตคอล: คิดจากขนาด MSS เทียบกับขนาดเฟรมรวมส่วนหัว โดยคิดส่วนหัวโปรโตคอลมาตรฐาน Ethernet เพิ่ม 78 ไบต์ต่อแพ็กเก็ต (ส่วนหัว TCP/IP 40 ไบต์ และส่วนหัวบนสายส่ง 38 ไบต์)
- แบบจำลอง Mathis: ใช้คำนวณขีดจำกัดปริมาณข้อมูลจากอัตราการสูญหายของแพ็กเก็ต โดยแบบจำลองนี้จะเชื่อถือได้เฉพาะเมื่ออัตราการสูญหายต่ำกว่าประมาณ 1% เท่านั้น หากค่าที่กรอกสูงกว่า 1% ระบบจะแสดงข้อความเตือน เพื่อแจ้งให้ทราบว่าขีดจำกัดจากการสูญหายนี้เป็นค่าที่มองโลกในแง่ดีเกินไป
- หน่วยวัด: ระบบใช้หน่วยฐานสิบในการคำนวณ (เช่น 1 kbit = 1,000 บิต, 1 MB = 1,000,000 ไบต์) ซึ่งอาจแตกต่างจากหน่วยฐานสอง (1024) ที่ตัวจัดการไฟล์ทั่วไปใช้งาน
ข้อความแสดงข้อผิดพลาดของระบบ
หากข้อมูลที่กรอกไม่ถูกต้อง ระบบจะแสดงข้อความแจ้งเตือนดังนี้:
- กรณีค่าที่กรอกไม่ใช่ตัวเลข:
"‹field›: “‹token›” ไม่ใช่ตัวเลข" - กรณีอัตราลิงก์ไม่ถูกต้อง:
"อัตราลิงก์ต้องมีค่ามากกว่าศูนย์" - กรณีเวลาเดินทางไป-กลับไม่ถูกต้อง:
"เวลาเดินทางไป-กลับต้องมีค่ามากกว่าศูนย์" - กรณีขนาดข้อมูลไม่ถูกต้อง:
"ขนาดข้อมูลต้องมีค่ามากกว่าศูนย์" - กรณีหน้าต่างรับข้อมูลไม่ถูกต้อง:
"หน้าต่างรับข้อมูลต้องมีค่ามากกว่าศูนย์" - กรณีหน้าต่างรับข้อมูลเกินขีดจำกัด RFC 7323:
"TCP ไม่สามารถเจรจาต่อรองหน้าต่างที่สูงกว่า 1,073,725,440 ไบต์ได้ (การปรับขนาดหน้าต่างตาม RFC 7323)" - กรณี MSS อยู่นอกขอบเขต:
"MSS ต้องเป็นจำนวนเต็มของไบต์ระหว่าง 1 ถึง 65,495" - กรณีอัตราสูญหายอยู่นอกขอบเขต:
"อัตราการสูญหายต้องอยู่ระหว่าง 0 ถึง 100 เปอร์เซ็นต์" - กรณีค่าคำนวณเกินขีดจำกัดระบบ:
"ค่าหรือผลลัพธ์ระหว่างทางเกินช่วงตัวเลขที่รองรับ"
คำถามที่พบบ่อย (FAQ)
ถาม: ทำไมการถ่ายโอนข้อมูลของฉันถึงช้ากว่าอัตราลิงก์ที่ฉันจ่ายเงินซื้อ? ตอบ: การไหลของ TCP เดี่ยวต้องเผชิญกับขีดจำกัดอิสระสามด้าน และด้านที่ต่ำที่สุดจะเป็นตัวกำหนด ประสิทธิภาพที่สูญเสียไปจากโปรโตคอลจะลดทอนตัวลิงก์เองลงประมาณ 5% — เฟรม Ethernet มาตรฐานจะนำส่งข้อมูลผู้ใช้ 1,460 ไบต์จากทั้งหมด 1,538 ไบต์บนสายส่ง หน้าต่างรับข้อมูลจะจำกัดปริมาณข้อมูลที่ส่งผ่านได้ไว้ที่ หน้าต่าง ÷ RTT ดังนั้นหน้าต่างขนาดดั้งเดิม 65,535 ไบต์จะจำกัดเส้นทางที่มี RTT 50 ms ไว้ที่ประมาณ 10.5 Mbit/s ไม่ว่าลิงก์จะเร็วแค่ไหนก็ตาม และการสูญหายจะจำกัดไว้ที่ (MSS ÷ RTT) ÷ √การสูญหาย ผลลัพธ์ด้านบนจะระบุว่าขีดจำกัดใดที่เป็นตัวจำกัดตัวเลขของคุณ
ถาม: Bandwidth-Delay Product คืออะไร และทำไมมันถึงกำหนดขนาดของหน้าต่าง? ตอบ: BDP — อัตราลิงก์ × เวลาเดินทางไป-กลับ — คือปริมาณข้อมูลที่อยู่ระหว่างการส่งในขณะใดขณะหนึ่ง TCP สามารถมีหน้าต่างที่ยังไม่ได้รับการตอบรับค้างอยู่ได้มากที่สุดเพียงหนึ่งหน้าต่าง ดังนั้นหน้าต่างที่เล็กกว่า BDP จะทำให้ท่อส่งข้อมูลว่างเปล่าบางส่วน: ที่ความเร็ว 100 Mbit/s พร้อม RTT 50 ms ท่อส่งข้อมูลจะรองรับได้ 625 kB และหน้าต่างขนาด 65,535 ไบต์จะเติมเต็มได้ไม่ถึงหนึ่งในสิบของท่อด้วยซ้ำ นั่นคือเหตุผลที่เส้นทางที่เร็วและยาวต้องการการปรับขนาดหน้าต่าง TCP (RFC 7323) ซึ่งจะเพิ่มขีดจำกัดสูงสุดที่เจรจาได้จาก 65,535 ไบต์เป็นประมาณ 1 GB
ถาม: การสูญหายของแพ็กเก็ตจำกัดปริมาณข้อมูลที่ส่งผ่านได้ของ TCP อย่างไร? ตอบ: TCP จะจัดการกับการสูญหายเสมือนเป็นความหนาแน่นของเครือข่าย และจะลดอัตราการส่งลงครึ่งหนึ่งในทุกๆ เหตุการณ์ที่เกิดการสูญหาย ดังนั้นแม้อัตราการสูญหายเพียงเล็กน้อยก็ส่งผลอย่างมากต่อเส้นทางที่รวดเร็ว แบบจำลองของ Mathis ประมาณการขีดจำกัดไว้ที่ (MSS ÷ RTT) ÷ √p — ที่การสูญหาย 0.01% บนเส้นทาง 50 ms พร้อม MSS ขนาด 1,460 ไบต์ จะได้ความเร็วประมาณ 23 Mbit/s โดยไม่คำนึงถึงความเร็วของลิงก์ แบบจำลองนี้สมมติว่าเหตุการณ์การสูญหายเกิดขึ้นอย่างกระจายตัวสม่ำเสมอและเป็นอิสระต่อกัน ซึ่งจะสอดคล้องกับความเป็นจริงได้ดีเมื่อการสูญหายต่ำกว่าประมาณ 1% และสำหรับกรณีการสูญหายแบบเป็นกลุ่ม (bursty) แบบจำลองนี้จะให้ผลลัพธ์ที่มองโลกในแง่ดีเกินไป
ถาม: เมกะไบต์ในที่นี้เหมือนกับในตัวจัดการไฟล์ของฉันหรือไม่? ตอบ: ไม่เชิง หน้าเว็บนี้ใช้หน่วยฐานสิบตามหลักการทำงานของระบบเครือข่าย: 1 kbit = 1,000 บิต และ 1 MB = 1,000,000 ไบต์ ตัวจัดการไฟล์ส่วนใหญ่จะนับในหน่วยฐาน 1024 ซึ่งมักจะระบุป้ายกำกับผิดเป็น MB — ไฟล์ขนาด "100 MB" ในนั้นมักจะเป็น 100 MiB ≈ 104.86 MB ในฐานสิบ ดังนั้นจึงใช้เวลาในการเคลื่อนย้ายนานกว่าที่ตัวเลขฐานสิบระบุไว้ประมาณ 5% ให้กรอก 104.86 MB ที่นี่เพื่อให้ตรงกันพอดี