Transport Layer

1UDP vs TCP

2TCP: Header, Handshake, Sliding Window

TCP sliding window ทำ 3 อย่างพร้อมกัน: reliability, ordering, flow control — SequenceNum 32-bit ต้องไม่ wrap ภายใน MSL=120 วินาที

3Congestion Control: AIMD

Fast Retransmit: duplicate ACK 3 ครั้ง → retransmit ทันที ไม่ต้องรอ timeout เต็มรอบ — RTO คำนวณจาก Jacobson/Karels algorithm ที่นับทั้ง EstimatedRTT และ Deviation

4RTP/RTCP สำหรับสื่อ Real-Time

RTP วิ่งบน UDP — ให้ sequence number (จัดลำดับ/ตรวจ loss) และ timestamp (synchronize หลายแหล่ง) RTCP รายงานคุณภาพผ่าน Sender/Receiver Report

5Socket API

# TCP Client/Server (Python) — โครงสร้างย่อ
# Server: bind() → listen() → accept() → recv()/send()
# Client: connect() → send()/recv()

# UDP: ไม่มี connection — ต้องระบุ address ทุกครั้งด้วย sendto()/recvfrom()

Code เต็มพร้อมคำอธิบายทีละบรรทัด (UDP และ TCP) → ดูเต็มที่หน้า OSI Transport Layer

ชื่อชั้นเหมือนกัน แต่ OSI เริ่มจากบริการ ส่วน TCP/IP เริ่มจาก Protocol ที่มีอยู่จริง

OSI อธิบายว่า Transport ควรให้บริการ process-to-process และอาจมีบริการหลายระดับ ส่วน TCP/IP มีตัวเลือกหลักที่เรียบง่ายกว่า คือ UDP กับ TCP Application ต้องเลือกเองว่าจะรับบริการแบบ datagram ที่เบา หรือ byte stream ที่เชื่อถือได้ การเลือกนี้ไม่ใช่ระดับคุณภาพของ protocol เดียว แต่เป็นคนละ abstraction

UDP ไม่ได้ “ทำอะไรเลย”

UDP เพิ่ม source port, destination port, length และ checksum เหนือ IP ทำให้หลาย process ใช้เครือข่ายบน host เดียวกันได้และรักษาขอบเขตของ message ไว้ หาก application ส่ง datagram หนึ่งก้อน ผู้รับรับเป็นก้อน ไม่ใช่ byte stream ต่อเนื่อง แต่ UDP ไม่รับประกันการถึง ลำดับ การส่งซ้ำ หรือ congestion control

TCP เป็น Byte Stream ไม่ใช่ Message Protocol

การเรียก send() สองครั้งฝั่งส่งไม่ได้รับประกันว่าฝั่งรับจะได้ recv() สองครั้งในขนาดเดียวกัน TCP อาจรวมข้อมูลหรือแบ่งออกตาม buffer และสภาพเครือข่าย Protocol ระดับ application ต้องบอกขอบเขตด้วย delimiter, length prefix, fixed length หรือโครงสร้างอื่น หากลืมเรื่องนี้ โปรแกรมอาจทำงานดีบนเครื่องเดียวแล้วพังเมื่อเจอ network จริง

End-to-End Reliability ต่างจาก Link Reliability

Link Layer อาจส่ง frame ซ้ำบน Wi-Fi หนึ่งช่วง แต่ยังมี router, queue และ link อื่นตลอดทาง TCP จึงตรวจ sequence และ acknowledgement จากปลายทางจริง หลัก end-to-end บอกว่า คุณสมบัติบางอย่างจะยืนยันได้สมบูรณ์ก็ต่อเมื่อปลายทางตรวจเอง แม้กลไกชั้นล่างช่วยเพิ่มประสิทธิภาพได้

Flow Control กับ Congestion Control มองคนละคอขวด

Flow control ป้องกันไม่ให้ sender ส่งเร็วเกิน buffer ของ receiver ส่วน congestion control ป้องกันไม่ให้ส่งเร็วเกินความสามารถของเครือข่ายระหว่างทาง Receiver อาจมีหน่วยความจำเหลือมาก แต่ router กลางกำลังแน่น หรือเครือข่ายอาจว่างแต่ application ปลายทางอ่านไม่ทัน ทั้งสองจึงต้องมีตัวแปรและสัญญาณคนละชุด

TCP Congestion Control เป็นกลไกของ Internet จริง ไม่ใช่ข้อกำหนดทั่วไปของ OSI

OSI ระบุหน้าที่เป็นแบบจำลอง แต่ slow start, congestion avoidance, fast retransmit และการตีความ loss เป็นสัญญาณ congestion เติบโตจากประสบการณ์ของ TCP บน Internet Algorithm เปลี่ยนตามเวลาได้ เช่น Reno, CUBIC หรือ BBR อาจประเมินเครือข่ายต่างกัน แม้ยังให้ application เห็น TCP socket คล้ายเดิม

นี่คือความต่างระหว่าง service interface กับ internal algorithm โปรแกรมยังเรียก send() เหมือนเดิม แต่ระบบข้างในอาจเปลี่ยนวิธีควบคุมอัตราส่งได้ การซ่อนรายละเอียดช่วยให้พัฒนา protocol โดยไม่ต้องแก้ application ทุกตัว

QUIC ทำให้เส้นแบ่ง Transport กับ Application ไม่เรียบร้อยอีกครั้ง

QUIC ทำงานบน UDP แต่สร้าง connection, reliability, congestion control, stream และ TLS 1.3 ขึ้นมาเอง โดยทั่วไปนำไปใช้กับ HTTP/3 ข้อดีคือพัฒนาใน user space ได้เร็วและลดปัญหา stream หนึ่งรออีก stream แบบ TCP บางกรณี แต่ในแผนภาพสี่ชั้น เราอาจถามว่า QUIC อยู่ Transport หรือ Application คำตอบขึ้นกับว่าเรากำลังจัดตามหน้าที่หรือตามตำแหน่งที่สร้างระบบจริง

Socket เป็น Programming Interface ไม่ใช่ Protocol บนสาย

Socket API เป็นวิธีที่โปรแกรมขอใช้ TCP หรือ UDP จากระบบปฏิบัติการ คำสั่ง bind(), connect() และ accept() ไม่ได้ถูกส่งเป็น packet ชื่อเดียวกันไปบนเครือข่าย เครื่องอีกฝั่งเห็น TCP segment หรือ UDP datagram ไม่ได้เห็น function call ใน source code

Port ระบุ Process Endpoint แต่ไม่ใช่ตัวตนถาวรของบริการเสมอไป

Server มักผูก well-known port ส่วน client ใช้ ephemeral port ที่ระบบเลือก Connection ของ TCP จึงแยกได้ด้วยข้อมูลต้นทางและปลายทางร่วมกัน ไม่ใช่ดู destination port เพียงตัวเดียว Load balancer, proxy และ NAT ยังอาจเปลี่ยน endpoint ที่เห็นระหว่างทาง ทำให้ “IP + port ของ server” ไม่จำเป็นต้องตรงกับ process ปลายทางจริงเพียงเครื่องเดียว

การเปิด Connection ไม่ได้แปลว่ามีสายเสมือนถูกจองไว้

TCP connection คือ state ที่ endpoint สองฝั่งเก็บร่วมกัน เช่น sequence number, window และ timer Router กลางทั่วไปไม่ต้องเก็บ TCP connection ทุกเส้นและไม่ได้จอง bandwidth ไว้ให้ 3-way handshake จึงยืนยันความพร้อมและเริ่มต้น state ของปลายทาง ไม่ได้โทรไปสั่ง router ทุกตัวให้กันช่องทางเฉพาะ

เหตุใดต้องใช้ 3-Way Handshake

สองฝั่งต้องยืนยันว่าเส้นทางสื่อสารใช้ได้ทั้งไปและกลับ พร้อมแลก initial sequence number เพื่อแยก byte ใหม่ออกจาก segment เก่าที่อาจค้างในเครือข่าย หากมีเพียงสองข้อความ ฝั่งหนึ่งอาจยังไม่รู้ว่า acknowledgement ของตนกลับถึงอีกฝ่ายแล้ว ขั้นที่สามจึงปิดวงของการยืนยัน

Checksum, Reliability และ Security ไม่ใช่สิ่งเดียวกัน

Checksum ช่วยตรวจความเสียหายที่เกิดโดยไม่ตั้งใจระหว่างส่ง TCP ใช้ acknowledgement และ retransmission ทำให้ byte stream ครบตามลำดับ แต่ทั้งสองอย่างไม่ได้ยืนยันว่าคู่สื่อสารเป็นใครหรือป้องกันผู้โจมตีแก้ข้อมูลอย่างมีเจตนา งานนั้นต้องใช้กลไก cryptographic เช่น TLS การมี reliable connection จึงไม่เท่ากับมี secure connection

Transport เลือกเวลาให้ Application ไม่ได้ทุกเรื่อง

TCP รับรองลำดับ ทำให้ byte หลังส่วนที่หายอาจต้องรอแม้มาถึงแล้ว สำหรับไฟล์นี่เป็นพฤติกรรมที่ต้องการ แต่สื่อ real-time อาจยอมทิ้งเสียงช่วงเก่าแล้วเล่นช่วงใหม่ต่อ Application จึงเลือก UDP, RTP หรือ QUIC stream/datagram ตาม deadline ของข้อมูล ไม่ใช่เลือกจากคำสั้น ๆ ว่า “TCP ดี UDP เร็ว”

6สรุปและขั้นตอนถัดไป