ชั้นสื่อนำส่งและกลไกควบคุมความคับคั่ง

ชั้นสื่อนำส่ง (transport layer) ขยายการส่งข้อมูลจากโฮสต์ถึงโฮสต์ไปสู่การสื่อสารระหว่างกระบวนการ (process-to-process communication) โดยนำเสนอแอปพลิเคชันด้วยสตรีมข้อมูลแบบไบต์ที่เชื่อถือได้ มีลำดับ และมีการควบคุมความคับคั่ง (TCP) หรือดาตาแกรมแบบไร้การเชื่อมต่อที่มีน้ำหนักเบา (UDP) ในขณะที่กลไกควบคุมความคับคั่งจะควบคุมอัตราการส่งข้อมูลเพื่อไม่ให้เครือข่ายที่ใช้ร่วมกันล่มสลาย

Definition

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

Scope

ขอบเขตนี้ครอบคลุมบริการสื่อนำส่งแบบต้นทางถึงปลายทาง: การมัลติเพล็กซ์และการดีมัลติเพล็กซ์ข้อมูลไปยังกระบวนการแอปพลิเคชัน หลักการของการถ่ายโอนข้อมูลที่เชื่อถือได้ผ่านเครือข่ายที่ไม่น่าเชื่อถือ (การรับทราบ, การส่งซ้ำ, หมายเลขลำดับ, หน้าต่างเลื่อน) โปรโตคอลควบคุมการส่งข้อมูลแบบเชื่อมต่อ (Transmission Control Protocol) และโปรโตคอลดาตาแกรมผู้ใช้แบบไร้การเชื่อมต่อ (User Datagram Protocol) รวมถึงทฤษฎีและการปฏิบัติของการควบคุมความคับคั่ง ไม่รวมถึงการกำหนดเส้นทางของแพ็กเก็ตข้ามเครือข่าย (ชั้นเครือข่าย) และโปรโตคอลแอปพลิเคชันที่ใช้บริการสื่อนำส่ง (ชั้นแอปพลิเคชัน)

Sub-topics

• Congestion Control Principles
• Reliable Data Transfer
• Transmission Control Protocol
• UDP and Connectionless Transport

Core questions

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

Key concepts

• การมัลติเพล็กซ์และการดีมัลติเพล็กซ์
• พอร์ตและซ็อกเก็ต
• การถ่ายโอนข้อมูลที่เชื่อถือได้
• หน้าต่างเลื่อน, go-back-N, selective repeat
• การจับมือสามทางของ TCP (TCP three-way handshake)
• การควบคุมการไหล
• การควบคุมความคับคั่ง
• การเพิ่มแบบบวก/การลดแบบคูณ (AIMD)
• การเริ่มต้นช้าและการหลีกเลี่ยงความคับคั่ง
• โปรโตคอลดาตาแกรมผู้ใช้ (UDP)

Key theories

การถ่ายโอนข้อมูลที่เชื่อถือได้ผ่านช่องสัญญาณที่ไม่น่าเชื่อถือ

ความน่าเชื่อถือถูกสร้างขึ้นจากการรับทราบ, ตัวจับเวลาการส่งซ้ำ, หมายเลขลำดับ, และโปรโตคอลหน้าต่างเลื่อน (go-back-N และ selective repeat) ที่ตรวจจับและกู้คืนจากการสูญหาย, การซ้ำซ้อน, และการจัดลำดับใหม่ แม้ว่าเครือข่ายพื้นฐานจะไม่น่าเชื่อถือก็ตาม

การควบคุมความคับคั่งของ TCP

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

การสื่อนำส่งแบบไร้การเชื่อมต่อเทียบกับการสื่อนำส่งแบบเชื่อมต่อ

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

Clinical relevance

พฤติกรรมของชั้นสื่อนำส่งมีผลต่อประสิทธิภาพของแอปพลิเคชันเครือข่ายเกือบทุกชนิด: TCP ใช้ในการส่งข้อมูลเว็บ อีเมล และการถ่ายโอนไฟล์ได้อย่างน่าเชื่อถือ ในขณะที่ UDP รองรับการใช้งานที่มีความหน่วงต่ำ เช่น DNS, เสียงและวิดีโอแบบเรียลไทม์ และเกมจำนวนมาก กลไกควบคุมความคับคั่งเป็นสิ่งที่ทำให้เครือข่ายอินเทอร์เน็ตไม่ล่มสลายภายใต้ภาระงานตั้งแต่ช่วงปลายทศวรรษ 1980 และงานวิจัยที่กำลังดำเนินอยู่เกี่ยวกับอัลกอริทึม เช่น CUBIC และ BBR และโปรโตคอล เช่น QUIC ยังคงปรับสมดุลระหว่างความหน่วง ปริมาณงาน และความเป็นธรรม

History

TCP และ IP เดิมเป็นโปรโตคอลเดียวกันในการออกแบบของ Cerf-Kahn ในปี 1974 และต่อมาได้ถูกแยกออกจากกัน โดย UDP (RFC 768, 1980) ถูกเพิ่มเข้ามาสำหรับแอปพลิเคชันที่ต้องการเพียงบริการดาตาแกรมพื้นฐาน หลังจากเกิดเหตุการณ์ความคับคั่งหลายครั้งบนอินเทอร์เน็ตยุคแรก งานของ Van Jacobson ในปี 1988 ได้นำเสนออัลกอริทึม slow-start และ congestion-avoidance ซึ่งยังคงเป็นรากฐานของการควบคุมความคับคั่งของ TCP และได้รับการปรับปรุงมานานหลายทศวรรษเป็นเวอร์ชันต่างๆ เช่น Reno, CUBIC และ BBR

Debates

การควบคุมความคับคั่งแบบอิงการสูญหายเทียบกับแบบอิงความหน่วงและแบบอิงโมเดล

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

Key figures

• Van Jacobson
• Jon Postel
• Vinton Cerf
• Sally Floyd

Seminal works

• kurose2021
• jacobson1988
• rfc9293

Frequently asked questions

ฉันควรใช้ UDP แทน TCP เมื่อใด?

ใช้ UDP เมื่อความหน่วงต่ำมีความสำคัญมากกว่าการรับประกันการส่งมอบ และคุณสามารถทนต่อหรือจัดการกับการสูญหายได้ด้วยตนเอง — ตัวอย่างเช่น เสียง/วิดีโอแบบเรียลไทม์, การสอบถาม DNS หรือเกม ใช้ TCP เมื่อคุณต้องการการส่งมอบที่เชื่อถือได้ มีลำดับ และมีการควบคุมความคับคั่งในตัว เช่น สำหรับหน้าเว็บ, การถ่ายโอนไฟล์ และอีเมล

การควบคุมความคับคั่งทำอะไรได้บ้าง?

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