Transport Layer

1คุณสมบัติที่คาดหวังจาก Transport Protocol

Transport Layer ไม่ได้มีหน้าที่ทำให้ทุกการสื่อสารเชื่อถือได้เหมือนกัน แต่เปิดบริการหลายแบบให้ application เลือก TCP เพิ่ม byte stream ที่มีลำดับและการส่งซ้ำ ส่วน UDP รักษาขอบเขต datagram และเพิ่ม port กับ checksum โดยไม่สร้าง connection หรือ retransmission ให้ การออกแบบจึงเริ่มจากถามว่า application ต้องการคุณสมบัติใด ไม่ใช่เริ่มจากตัดสินว่า protocol หนึ่ง “ดีกว่า” อีก protocol หนึ่ง

Multiplexing และ Demultiplexing

ฝั่งส่งมีหลาย process เขียนข้อมูลลง socket Transport Layer จึง multiplex ข้อมูลเหล่านั้นลงสู่ Network Layer พร้อมข้อมูลกำกับ ฝั่งรับอ่าน destination port และบริบทของ connection เพื่อ demultiplex ไปยัง socket ที่ถูกต้อง UDP socket มักจับคู่ด้วย local address/port ส่วน TCP connection แยกด้วย tuple ที่รวม source address, source port, destination address และ destination port ทำให้ server port เดียวรับ client หลายรายพร้อมกันได้

2Simple Demultiplexer (UDP)

UDP รักษาขอบเขต message: การส่ง datagram สองครั้งทำให้ฝั่งรับเห็น datagram แยกกันหากทั้งสองมาถึง ต่างจาก TCP ที่รวมเป็น byte stream แต่ datagram อาจหาย มาไม่เรียง หรือซ้ำได้ และถ้าใหญ่เกิน path MTU อาจถูก fragment หรือส่งไม่ผ่านตาม IP version และ policy

ระบบปฏิบัติการมี receive buffer ให้ socket หาก application อ่านไม่ทัน buffer อาจเต็มและ kernel ทิ้ง datagram พฤติกรรมการรายงานขึ้นกับ OS และ API ผู้ส่งมักไม่รู้ว่าฝั่งรับทิ้งจาก buffer เต็ม การเรียก sendto() สำเร็จจึงบอกเพียงว่าระบบรับข้อมูลไปจัดการ ไม่ได้ยืนยันว่า process ปลายทางอ่านแล้ว

เมื่อใด UDP เหมาะกว่า

• คำขอและคำตอบสั้น โดย application retry และจับคู่ transaction ได้ เช่น DNS แบบทั่วไป
• สื่อ real-time ที่ข้อมูลเก่าหมดประโยชน์ก่อน retransmission มาถึง และยอมซ่อมหรือปกปิด loss เอง
• Multicast ซึ่ง TCP แบบ connection ต่อคู่ไม่ตอบโจทย์
• Protocol ใหม่ที่ต้องการควบคุม reliability และ congestion ใน user space เช่น QUIC ซึ่งวางบน UDP แต่ไม่ได้แปลว่า QUIC ไม่มี reliability

3Reliable Byte Stream (TCP)

TCP ให้บริการ: Reliable, Connection-oriented, Byte-stream service

Reliable ในที่นี้หมายถึง TCP พยายามส่ง byte ที่ application เขียนให้ถึงอีกฝั่งตามลำดับและไม่ส่ง duplicate byte ให้ application ภายใต้ connection ที่ยังทำงาน แต่ไม่ได้รับประกัน deadline และไม่สามารถกู้ข้อมูลได้ถ้า connection ขาดจน retry ไม่สำเร็จ Application ยังต้องรับมือ error, timeout และกรณีที่ไม่รู้ว่าฝั่งตรงข้ามทำงานระดับ application เสร็จหรือยัง

Sequence Number นับ Byte ไม่ได้นับ Segment

TCP segment ที่มี Sequence Number 1,000 และ payload 500 byte ครอบคลุม byte 1,000–1,499 ACK 1,500 โดยทั่วไปหมายถึงได้รับ byte ก่อนหน้า 1,500 ครบและกำลังรอ byte 1,500 ACK เป็น cumulative จึงยืนยันช่วงต่อเนื่อง ไม่ได้หมายถึง “ได้รับ segment หมายเลข 1,500”

Segment boundary เปลี่ยนได้ระหว่าง retransmission ผู้ส่งอาจส่ง byte เดิมด้วยขนาด segment ต่างจากรอบแรก Receiver จัดข้อมูลด้วย sequence space ของ byte จึงประกอบ stream ได้โดยไม่ต้องรักษารูปร่าง segment เดิม SYN และ FIN ใช้พื้นที่หนึ่งตำแหน่งใน sequence space แม้ไม่บรรทุก application byte ซึ่งอธิบายว่าทำไม handshake ACK เป็น x+1

Flow control ปกป้อง receive buffer ของ endpoint ผ่าน advertised receive window หรือ rwnd ส่วน congestion control จำกัดข้อมูลตามสภาพเครือข่ายผ่าน congestion window หรือ cwnd ผู้ส่งส่งข้อมูลที่ยังไม่ ACK ได้โดยประมาณไม่เกิน min(rwnd, cwnd) และยังถูกจำกัดด้วยข้อมูลที่ application มี, sender buffer และ implementation อื่นด้วย

TCP checksum ตรวจ segment ร่วมกับ pseudo-header ที่รวม address และ protocol เพื่อช่วยจับการส่งผิดปลายทาง Header ยังมี Data Offset, window, checksum, urgent pointer และ options เช่น MSS, Window Scale, SACK Permitted และ Timestamps ขนาด header จึงไม่คงที่ 20 byte เสมอ

PSH และ URG มักถูกอธิบายกว้างเกินจริง PSH ไม่ได้สร้าง message boundary หรือรับประกันว่า application จะถูกปลุก “ทันที” แบบ deadline ส่วน urgent mechanism มี semantics ที่ใช้งานและตีความต่างกันในประวัติศาสตร์และไม่ใช่กลไก priority ทั่วไป Application สมัยใหม่ควรพึ่ง protocol framing และ API semantics ที่ชัดกว่า

Handshake ทำสามเรื่องพร้อมกัน: ยืนยันว่าเส้นทางสื่อสารสองทิศพอใช้งาน แลก initial sequence numbers และเจรจา options บางส่วน SYN flood ใช้ประโยชน์จากช่วงที่ server เก็บ half-open state โดยส่ง SYN จำนวนมากแต่ไม่จบ handshake กลไก SYN cookies หรือ backlog management ลดผลกระทบ แต่มีข้อแลกเปลี่ยนและรายละเอียดตาม implementation

TIME_WAIT ช่วยให้ ACK สุดท้ายถูกส่งซ้ำได้หาก FIN กลับมา และให้ segment เก่าหมดอายุก่อน tuple เดิมถูกนำกลับมาใช้ ระยะเวลาขึ้นกับ implementation และการกำหนด MSL ไม่ควรจำว่า MSL บน Internet เท่ากับ 120 วินาทีเป็นกฎสากลทุกระบบ นอกจากนี้การปิดด้วย RST ต่างจาก FIN เพราะยกเลิก connection ทันทีและอาจทำให้ข้อมูลที่ยังค้างสูญหาย

Half-Close และเหตุผลที่ EOF ไม่ใช่ข้อความว่างธรรมดา

เมื่อ recv() คืนศูนย์ byte บน TCP โดยไม่มี error โดยทั่วไปหมายถึง peer ปิดทิศส่งอย่างเป็นระเบียบ ไม่ได้หมายถึง “ยังไม่มีข้อมูล” Socket แบบ blocking จะรอ ส่วน nonblocking API ใช้สถานะหรือ error code แยกกรณี การเข้าใจ EOF ช่วยให้ server ไม่วนอ่านศูนย์ byteตลอดไป

Sliding Window ของ TCP — ทำหน้าที่ 3 อย่างพร้อมกัน

Triggering Transmission, Silly Window Syndrome, Nagle

TCP ตัดสินใจส่ง segment เมื่อ: (1) buffer ครบ MSS (2) application สั่ง push (3) timer หมดเวลา

if (available data ≥ MSS) และ (window ≥ MSS): ส่งทันที
else:
    if มี unACKed data ค้างอยู่: buffer รอไว้
    else: ส่งทันที

Silly Window Syndrome มีด้าน receiver ด้วย หาก receiver เปิด window ทีละน้อย ผู้ส่งอาจส่งชิ้นเล็กถี่ แนวทางอย่าง Clark's solution รอจนมีพื้นที่เพียงพอก่อน advertise window เพิ่ม Nagle แก้ tinygram ที่ sender ส่วนหนึ่ง แต่ไม่ได้เป็นคำตอบเดียวของ SWS ทั้งระบบ

Adaptive Retransmission (RTO)

Timeout สั้นเกินไปทำให้ retransmit ทั้งที่ packet เพียงมาช้า เพิ่มภาระให้เครือข่าย ส่วน timeout ยาวเกินไปทำให้ recovery ช้า TCP จึงประมาณ RTT จาก sample และเผื่อความผันผวน RTO ยังมีค่าต่ำสุด/สูงสุดและ exponential backoff ตาม implementation เพื่อไม่ให้ลองใหม่ถี่เมื่อเครือข่ายกำลังมีปัญหา

Karn's algorithm ไม่ใช้ RTT sample จาก segment ที่ retransmit เพราะ ACK ที่กลับมาบอกไม่ได้ว่ายืนยันสำเนาแรกหรือสำเนาใหม่ หากเอาค่าคลุมเครือไปอัปเดต estimator อาจเรียน RTT ผิด ส่วน timestamp option ช่วยแยก sample ได้ดีขึ้นในหลายกรณี แต่รายละเอียดขึ้นกับ stack

Slow Start, Congestion Avoidance, Loss Recovery

คำอธิบายนี้เป็นภาพของ TCP Reno เชิงตำราและใช้หน่วย MSS ในการอธิบาย ปัจจุบัน initial congestion window มักมากกว่า 1 MSS และระบบอาจใช้ CUBIC, BBR หรือ algorithm อื่น พฤติกรรมหลัง loss, ECN และ recovery จึงไม่เหมือนสูตร Reno ทุกประการ ควรเรียน Reno เพื่อเข้าใจ feedback loop แล้วแยกจาก implementation ที่เครื่องกำลังใช้

Duplicate ACK สามครั้งเป็น heuristic ว่ายังมี packet หลังช่องว่างเดินทางถึง receiver จึงน่าจะมี segment หนึ่งหาย แต่ packet reordering ก็สร้าง duplicate ACK ได้ SACK option ให้ receiver รายงานช่วงข้อมูลที่ได้รับแล้ว ช่วยให้ sender รู้ช่องว่างหลายช่วงและ retransmit เจาะจงกว่าการพึ่ง cumulative ACK อย่างเดียว

Congestion Control ไม่เท่ากับ Flow Control

Receiver อาจ advertise window หลาย megabyte แต่ cwnd เล็กเพราะเครือข่ายเพิ่งมี loss ผู้ส่งต้องเคารพค่าที่เล็กกว่า ในทางกลับกัน network อาจโล่งและ cwnd ใหญ่ แต่ application ปลายทางอ่านช้าจน rwnd เหลือศูนย์ TCP ใช้ persist mechanism probe เพื่อหลีกเลี่ยง deadlock หาก window update หาย

4RTP / RTCP — โปรโตคอลสำหรับสื่อ Real-Time

RTCP รายงานคุณภาพผ่าน Sender/Receiver Report เช่น packet count, loss, highest sequence, interarrival jitter และ timing information Jitter estimator ของ RTP สะท้อนความแปรผันของ transit time ระหว่าง packet ต่อเนื่อง ไม่ใช่ delay เฉลี่ย และ receiver ยังต้องเลือกขนาด jitter buffer แลกระหว่างการเล่นราบรื่นกับ latency

5QUIC — Transport สมัยใหม่ที่สร้างใน User Space

QUIC ทำงานบน UDP เพื่อให้พัฒนาและ deploy transport logic ใน user space ได้เร็วกว่าแก้ TCP ใน kernel และ middlebox ทั่วโลก แต่ QUIC สร้าง reliability, congestion control, flow control และ connection management ของตนเอง พร้อมผสาน TLS 1.3 การอยู่บน UDP จึงไม่ได้ทำให้ QUIC เป็น unreliable protocol

TCP มี byte stream เดียว หาก packet ของ stream ขาด byte ต่อไปทั้งหมดต้องรอลำดับ แม้ application มีหลาย logical request HTTP/2 multiplex หลาย stream บน TCP แต่ packet loss ยังทำให้ transport stream ทั้ง connection รอ QUIC มี stream หลายชุดและ loss ของ stream หนึ่งไม่จำเป็นต้องบล็อก delivery ของ stream อื่นในระดับเดียวกัน แม้ congestion control ยังร่วมทรัพยากร connection

QUIC ใช้ Connection ID ช่วยให้ connection อยู่ต่อเมื่อ IP address หรือ port เปลี่ยน เช่นย้ายจาก Wi‑Fi ไป cellular ภายใต้นโยบายและการตรวจ path แต่ mobility ไม่ได้ไร้ความเสี่ยงหรือสำเร็จทุกกรณี Server และ network ยังต้องรองรับ การเปลี่ยน path อาจเปลี่ยน RTT/MTU และต้อง validate address เพื่อป้องกัน amplification

6Socket API: ประตูสู่ Transport Layer

Transport service ที่แอปพลิเคชันเรียกผ่าน socket ต้องการต่างกันตามชนิดแอป:

ตารางเป็นภาพรวม ไม่ใช่กฎตายตัว Web สมัยใหม่อาจมี latency requirement สูงและใช้ QUIC ส่วน file transfer อาจยอม resume แทนเริ่มใหม่ Real-time media บางข้อมูล เช่น control message สำคัญกว่าภาพบาง frame Application จึงควรแยกชนิดข้อมูลและ deadline ไม่ตัดสิน protocol จากชื่อหมวดเพียงอย่างเดียว

UDP Socket

# Python UDP Client
clientSocket = socket(AF_INET, SOCK_DGRAM)
clientSocket.sendto(message,(serverName, serverPort))
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)

# Python UDP Server
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('', serverPort))
while 1:
    message, clientAddress = serverSocket.recvfrom(2048)
    serverSocket.sendto(message.upper(), clientAddress)

TCP Socket

# Python TCP Client
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)

# Python TCP Server
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind(('',serverPort)); serverSocket.listen(1)
while 1:
    connectionSocket, addr = serverSocket.accept()
    sentence = connectionSocket.recv(1024)
    connectionSocket.send(sentence.upper())
    connectionSocket.close()

ตัวอย่างเป็น pseudocode แบบ Python รุ่นเก่าเพื่อเน้นลำดับ API ใน Python 3 ข้อมูลที่ส่งผ่าน socket เป็น bytes จึงต้อง encode/decode ตาม format ที่ตกลง และ send() อาจส่งได้เพียงบางส่วนของ buffer ควรใช้ sendall() หรือวนจัดการจำนวน byte ที่ส่งจริง ส่วน recv(1024) หมายถึงรับได้ไม่เกิน 1,024 byte ไม่ได้สัญญาว่าจะได้ครบหนึ่ง message

TCP Server มี Listening Socket กับ Connected Socket คนละหน้าที่

listen() เปลี่ยน socket ให้รับ connection request ส่วน accept() คืน connected socket ใหม่สำหรับ client หนึ่งราย Listening socket เดิมยังอยู่เพื่อรับ client ถัดไป Server จึงมี local port เดียวแต่ connection หลายชุดแยกด้วย tuple การปิด connected socket ไม่ควรปิด listening socket เว้นแต่จะหยุดบริการ

Server ตัวอย่างรับทีละ client ถ้า client หนึ่งช้าจะบล็อกคนอื่น ระบบจริงใช้ thread, process, event loop หรือ asynchronous I/O พร้อมจำกัด concurrency และ timeout การทำ concurrent server ไม่ได้เพิ่ม capacity แบบไม่จำกัด เพราะ file descriptor, memory, CPU และ downstream service ยังเป็นทรัพยากรที่ต้องควบคุม

UDP socket สามารถเรียก connect() ได้เช่นกัน แต่ไม่ได้สร้าง handshake แบบ TCP มันกำหนด default peer และช่วยกรอง/รายงาน error ผ่าน API บางส่วน จึงควรพูดว่า UDP ไม่มี transport connection state แบบ TCP มากกว่าจะบอกว่า UDP “connect ไม่ได้” โดยเด็ดขาด

7Partial Failure, Timeout และ Idempotency

ระบบเครือข่ายมีความกำกวมที่โปรแกรมเครื่องเดียวพบไม่บ่อย Client ส่ง request แล้ว connection ขาดก่อนเห็น response เราไม่รู้ว่า request ไม่ถึง, server กำลังทำ, ทำเสร็จแต่ response หาย หรือทำเสร็จแล้ว server ล่ม การ timeout บอกเพียงว่าไม่มีผลลัพธ์ในเวลาที่รอ ไม่ได้บอกว่างานไม่เกิด

Retry ต้องมี Budget และ Backoff

Retry ช่วยจาก transient failure แต่ถ้า client จำนวนมากลองใหม่ทันทีเมื่อ server ช้า ภาระจะเพิ่มจนระบบฟื้นยาก เกิด retry storm Exponential backoff กระจายเวลาลองใหม่และ jitter ลดการตื่นพร้อมกัน แต่ต้องจำกัดจำนวนครั้ง/เวลารวม และพิจารณา deadline ของผู้ใช้ด้วย

8การวิเคราะห์ปัญหา Transport Layer

อาการ “ต่อไม่ได้” ควรถูกแยกเป็น DNS/IP path, connection establishment, TLS/application และ server capacity ถ้า SYN ออกแต่ไม่มี SYN-ACK อาจเป็น route, firewall, server ไม่ฟัง หรือ response กลับคนละทาง ถ้าได้ RST มักมี node ตอบปฏิเสธอย่างชัดเจน เช่นไม่มี listener หรือ policy ส่ง reset ส่วน timeout คือความเงียบที่มีหลายคำอธิบาย

ss/netstat ช่วยดู socket state และ queue, packet capture ช่วยเห็น flags, sequence, ACK และ timing, application log ช่วยตอบว่าข้อมูลถูกอ่านและประมวลผลหรือไม่ ต้องใช้ร่วมกัน เพราะ packet capture เห็น ACK ระดับ kernel แต่ไม่เห็นว่า application ทำงานสำเร็จ

TIME_WAIT, CLOSE_WAIT และความหมายที่ต่างกัน

TIME_WAIT จำนวนมากอาจเป็นผลปกติของ endpoint ที่ active close connection บ่อย ไม่ใช่ memory leak โดยอัตโนมัติ ส่วน CLOSE_WAIT หมายถึง local application ได้รับ FIN แล้วแต่ยังไม่ปิด socket หากสะสมมากมักชี้ว่าโปรแกรมไม่จัดการ close หลัง peer ปิด การแก้ด้วยการลด timeout โดยไม่เข้าใจ state อาจซ่อนอาการและเสี่ยง segment เก่าปะปน

9ความปลอดภัยและขอบเขตของ Transport

TCP และ UDP checksum ตรวจความเสียหายจากการส่ง ไม่ใช่ cryptographic integrity ผู้โจมตีสามารถแก้ payload แล้วคำนวณ checksum ใหม่ได้ TLS จึงสร้าง confidentiality, authentication และ integrity เหนือ transport ตาม configuration แต่ TLS ไม่ซ่อน IP address และ traffic timing ทั้งหมด และไม่แก้ denial-of-service ทุกชนิด

Port scanning ใช้พฤติกรรม SYN, RST หรือ ICMP อนุมานว่าบริการใดเปิด Firewall อาจ drop ให้ timeout หรือ reject ด้วย response ผลลัพธ์จึงบอกสิ่งที่ scanner มองเห็นจากจุดนั้น ไม่ใช่รายการ process ที่เครื่องมีทั้งหมด การเปิด port ก็ไม่ได้แปลว่ามีช่องโหว่ แต่เพิ่ม attack surface ที่ต้องอัปเดตและกำหนดสิทธิ์

TCP reset injection และ sequence prediction เป็นเหตุผลที่ initial sequence number ต้องคาดเดายากพอใน threat model แม้ TLS ปกป้อง application data ได้ดีกว่า Transport security ต้องมองทั้ง endpoint authentication, key management, protocol version และ implementation ไม่ยกภาระทั้งหมดให้คำว่า connection-oriented

10ออกแบบ Protocol บน TCP ให้ไม่พังตรงขอบเขต Message

ข้อผิดพลาดที่พบซ้ำใน lab คือ client ส่ง JSON หนึ่งครั้ง แล้ว server เรียก recv(1024) หนึ่งครั้งและสมมุติว่าได้ JSON ครบ วิธีนี้อาจทำงานบนเครื่องเดียวกันในข้อความสั้น ๆ จนดูเหมือนถูก แต่ TCP มีสิทธิ์แบ่งข้อมูลเป็นหลาย segment รวมหลาย write ใน buffer เดียว หรือให้ recv() คืนเท่าที่มีตอนนั้น การทดสอบที่เครือข่ายเร็วและโหลดต่ำเพียงซ่อน bug ไว้ให้ไปเปิดตัวใน production

วิธีสร้าง Message Framing ที่ใช้บ่อย

ป้องกัน Slow Client และข้อความที่ประกาศความยาวเกินจริง

ผู้โจมตีอาจส่ง header ช้ามากหรือประกาศ payload หลาย gigabyte แล้วไม่ส่งต่อ หาก server จอง memory ทันทีหรือเก็บ connection ไม่จำกัดจะเกิด denial of service ต้องมี maximum message size, read timeout, idle timeout, connection limit และการจัดสรร buffer แบบระวัง แต่ timeout สั้นเกินไปอาจตัดผู้ใช้เครือข่ายช้า จึงต้องเลือกจาก workload และวัดผล

11Connection Reuse, Pooling และต้นทุนที่ซ่อนอยู่

การเปิด TCP connection ใหม่มี handshake และอาจมี TLS handshake, authentication และ warm-up ของ congestion window การ reuse connection ลด latency และ CPU แต่ connection ที่เปิดค้างใช้ file descriptor, memory, state ใน load balancer/NAT และอาจชี้ไป backend ที่ไม่เหมาะแล้ว Connection pooling จึงต้องกำหนดขนาด อายุ idle, max lifetime และวิธีตรวจ connection ที่ถูกปิดจากอีกฝั่ง

Keepalive มีหลายความหมาย

TCP keepalive เป็นกลไก OS ตรวจ peer ที่เงียบตาม timer ซึ่งมักมีค่าเริ่มต้นยาวและปรับได้ HTTP keep-alive หมายถึง reuse connection สำหรับหลาย request ส่วน application heartbeat เป็นข้อความตาม protocol เพื่อบอก health หรือ lease ทั้งสามอย่างไม่เหมือนกัน การเปิด TCP keepalive ไม่ได้แทน application heartbeat ที่ต้องตรวจว่า service loop ยังตอบได้

Connection ที่ขาดแบบเงียบอาจไม่ถูกตรวจจนมีการส่งข้อมูล เพราะ TCP ไม่มีข้อความลอยมาแจ้งทันทีว่า router กลางทางหาย Application ที่ต้องรู้สถานะเร็วต้องมี deadline/heartbeat แต่ heartbeat ถี่เกินไปเพิ่ม traffic และอาจประกาศ failure จาก network pause ชั่วคราว จึงควรผูกกับ recovery objective ที่ต้องการ

Head-of-Line Blocking

TCP ต้องส่ง byte ให้ application ตามลำดับ ถ้า segment หนึ่งหาย byte หลังจากนั้นที่มาถึงแล้วต้องรอช่องว่าง แม้เป็นข้อมูลคนละ logical request บน connection เดียว HTTP/2 multiplex ลดการรอระดับ application framing แต่ยังอยู่บน TCP stream เดียว QUIC แยก stream จึงลด transport head-of-line blocking ข้าม streamได้ อย่างไรก็ตาม packet loss ยังลด congestion window และกระทบ capacity รวม

12Performance ของ Transport: BDP, Window Scale และ Application Backpressure

ลิงก์ bandwidth สูงและ RTT ยาวต้องมีข้อมูลค้างระหว่างทางมากพอจึงใช้ capacity เต็ม Bandwidth-delay product ประมาณจาก bandwidth × RTT เช่น 1 Gb/s กับ RTT 100 ms มี BDP 100 Mb หรือ 12.5 MB ถ้า effective window เพียง 64 KB throughput จะติดที่ window/RTT แม้ลิงก์ว่างมาก

TCP Window Scale option ขยาย receive window เกิน field 16 บิตและต้องเจรจาตอน SYN ส่วน congestion window ต้องเติบโตตาม algorithm ด้วย การเพิ่ม socket buffer อย่างเดียวจึงไม่รับประกัน throughput ถ้า loss สูง, application เขียนไม่ทัน, cwnd เล็ก หรือ path มี bottleneck ต่ำกว่า

Backpressure ต้องเดินจากปลายทางกลับถึงต้นทาง

TCP flow control หยุด sender เมื่อ receive buffer เต็ม แต่ถ้า application server อ่านเข้าหน่วยความจำเร็วแล้วโยนงานเข้า queue ภายในไม่จำกัด TCP จะเห็น receiver ว่าง ขณะที่ระบบจริงกำลังสะสมงาน Backpressure ที่ดีต้องเชื่อม queue ของ application, worker, database และ upstream ไม่ใช่หยุดที่ socket buffer

Async framework ทำให้รับ connection จำนวนมากได้ แต่ไม่ได้ทำให้ CPU/database ทำงานพร้อมกันไม่จำกัด หากอ่าน request ทุกตัวเข้ามาแล้วสร้าง task โดยไม่จำกัด ระบบอาจใช้ memory จนล้ม Semaphore, bounded queue, admission control และ response อย่าง overload เป็นส่วนต่อของ flow control ในระดับ service

Timeout ควรแยกตามช่วง ไม่ใช้ตัวเลขเดียวครอบทุกอย่าง

โปรแกรมหนึ่ง request มีได้ทั้ง DNS timeout, connect timeout, TLS handshake timeout, time-to-first-byte, read timeout และ deadline รวม ถ้าใช้ read timeout 30 วินาทีอย่างเดียว DNS อาจค้างเกือบทั้งหมดจนไม่เหลือเวลาให้ server ทำงาน ในทางกลับกัน deadline รวมที่ไม่มี timeout ย่อยอาจทำให้เราไม่รู้ว่าค้างขั้นใด

การเลือก timeout ควรดู latency distribution และผลของ false timeout ไม่ใช้ค่าเฉลี่ยเพียงอย่างเดียว Tail latency ทำให้ request บางส่วนช้ากว่าปกติ การตั้งต่ำเกิน percentile ที่ระบบให้ได้จะสร้าง retry จาก request ที่เกือบสำเร็จ และ retry เหล่านั้นผลักระบบให้ช้าลงอีก นี่เป็น feedback loop ที่เริ่มจากตัวเลข timeout ตัวเดียวได้

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

ขั้นตอนถัดไปในเส้นทาง OSI คือ Session Layer ซึ่งถามเรื่องการรักษาบริบทของการสนทนา การแบ่งช่วง และการกลับมาทำงานต่อ แต่ใน TCP/IP stack หน้าที่เหล่านี้มักอยู่ใน application protocol, library หรือ service state ไม่ได้มี Session protocol กลางหนึ่งตัวคั่นอยู่เหนือ TCP ทุกครั้ง การเรียนชั้นถัดไปจึงควรมองเป็นชุดความรับผิดชอบ ไม่ใช่ตามหา header ชื่อ Session ในทุก packet