Socket API — จุดเชื่อมระหว่างแอปกับเครือข่าย

1Socket คืออะไร

Application ไม่ได้สร้าง TCP segment หรือ IP packet ด้วยตนเองทุกครั้ง โดยทั่วไปมันขอให้ระบบปฏิบัติการจัดการผ่าน Socket API ซึ่งทำหน้าที่เป็น interface ระหว่าง process กับบริการสื่อสารที่ระบบมีให้

Socket เป็นทั้งแนวคิดและทรัพยากรของระบบปฏิบัติการ

ในโปรแกรมแบบ Unix-like การเรียก socket() คืนค่า file descriptor ซึ่งเป็นหมายเลขที่ process ใช้อ้างถึง socket object ที่ kernel ดูแลอยู่ ข้างใน object นี้มี state, buffer, protocol information และข้อมูล address ที่เกี่ยวข้อง ตัวเลข descriptor ไม่ใช่ port และไม่ใช่หมายเลข connection บนเครือข่าย เป็นเพียง handle ภายใน process

Process สองตัวอาจมี descriptor หมายเลข 3 เหมือนกันได้ เพราะแต่ละ process มีตาราง descriptor ของตนเอง เช่นเดียวกับห้อง 3 ในคนละอาคารไม่ใช่ห้องเดียวกัน การดูตัวเลขเพียงค่าเดียวโดยไม่ดูขอบเขตจึงตีความไม่ได้

Address Family, Socket Type และ Protocol

ใน API ดั้งเดิมจะพบทั้งชื่อ AF_* และ PF_* โดยทั่วไปโปรแกรมใช้ AF_INET หรือ AF_INET6 เป็น address family ส่วนการใช้ AF_INET + SOCK_STREAM + protocol 0 มักเลือก TCP ตามค่าเริ่มต้นของระบบ

AF_UNIX หรือ AF_LOCAL ใช้ Unix-domain socket สำหรับ inter-process communication ภายในเครื่อง ไม่ใช่ Unix pipe แม้ทั้งคู่ช่วยให้ process สื่อสารกันได้ ส่วน packet socket เช่น AF_PACKET เป็นความสามารถเฉพาะบางระบบอย่าง Linux ใช้เข้าถึง frame ระดับ link และต้องมีสิทธิ์เหมาะสม จึงไม่ใช่เส้นทางปกติของ application ทั่วไป

IP Address บอกเครื่อง ส่วน Port ช่วยบอก Process หรือ Service

IP address ช่วยพาข้อมูลไปยัง host หรือ interface ตามขอบเขตของ network routing ส่วน port number ช่วยให้ Transport Layer ส่งข้อมูลต่อไปยัง socket ของ process ที่เหมาะสมบน host นั้น จึงอาจมอง address กับ port เป็น “ที่อยู่สองระดับ”

Connection หนึ่งชุดถูกแยกจาก connection อื่นอย่างไร

TCP connection มักระบุได้ด้วยข้อมูล 4 ค่า ได้แก่ source IP, source port, destination IP และ destination port หากรวม transport protocol เข้าไปด้วย มักพูดถึง 5-tuple ข้อมูลชุดนี้ทำให้ server ใช้ local port เดียวรับ client จำนวนมากได้ โดยแต่ละ connection ยังแยกจากกัน

Client มักปล่อยให้ระบบปฏิบัติการเลือก ephemeral port ชั่วคราวให้ ส่วน server เลือก port ที่ผู้ใช้หรือระบบค้นพบได้ Port 0–1023 เป็น well-known range ตามธรรมเนียมและข้อกำหนดของระบบ แต่ server ของเราใช้ registered หรือ dynamic/private port อื่นก็ได้ หาก client รู้ว่าจะติดต่อที่ใด

วงจรชีวิตของ socket ไม่ได้มีเพียงสี่คำสั่ง

ลำดับ operation ขึ้นกับชนิด socket และบทบาท TCP server, TCP client และ UDP endpoint ใช้ขั้นตอนไม่เหมือนกัน การสรุปเป็น create → attach → send/receive → close ช่วยเห็นภาพกว้าง แต่ยังไม่พอสำหรับเขียนโปรแกรมจริง

2TCP Client-Server Flow (ภาพรวม)

TCP เป็น connection-oriented byte stream ฝั่ง server เตรียมจุดรับ connection ส่วน client เริ่มเชื่อมต่อ เมื่อ handshake สำเร็จทั้งสองฝั่งจึงส่ง byte ผ่าน connection ได้ แต่ socket ที่ใช้รอรับกับ socket ที่ใช้คุยกับ client แต่ละรายเป็นคนละ object

Listening Socket กับ Connected Socket

Server เริ่มจาก listening socket หนึ่งตัว เมื่อ accept() สำเร็จ ระบบคืน connected socket อีกตัวสำหรับคุยกับ client รายนั้น Server จึงมี socket สองบทบาทพร้อมกัน: ตัวหนึ่งรับแขกใหม่ อีกหลายตัวดูแลแขกที่เข้ามาแล้ว

Blocking ไม่ได้แปลว่าโปรแกรมทั้งระบบต้องหยุด

ใน blocking mode คำสั่งอย่าง accept() หรือ recv() อาจรอจนมีเหตุการณ์ที่ต้องการ แต่สิ่งที่หยุดคือ thread ที่เรียก operation นั้น ไม่จำเป็นต้องเป็น process ทั้งหมด Server สามารถใช้หลาย thread, หลาย process, event loop หรือ asynchronous I/O เพื่อดูแลหลาย connection พร้อมกัน

แต่ละแนวทางมีต้นทุนต่างกัน Thread-per-connection เข้าใจง่ายแต่ใช้ทรัพยากรเพิ่มเมื่อ connection จำนวนมาก Event-driven model รองรับ connection ได้มากโดยใช้ thread น้อย แต่ state ของแต่ละ connection และ error path ซับซ้อนขึ้น ไม่มี concurrency model ที่ดีที่สุดโดยไม่ดู workload

connect() สำเร็จรับรองถึงระดับใด

TCP connect สำเร็จหมายถึง transport connection ถูกสร้างกับ endpoint ปลายทางตาม protocol ไม่ได้หมายความว่า application ปลายทาง authenticate ผู้ใช้แล้ว ทำ transaction เสร็จแล้ว หรือแม้แต่พร้อมตอบ request ที่เรากำลังจะส่ง Server process อาจ accept connection แล้วแต่ติดคิวงานภายในอีกนาน

ในทางกลับกัน connect ล้มเหลวอาจให้หลักฐานต่างกัน เช่น connection refused ชี้ว่าปลายทางตอบกลับแต่ไม่มี service รับตามเงื่อนไขนั้น ขณะที่ timeout อาจเกิดจาก packet ถูกกรอง เส้นทางขาด หรือปลายทางเงียบ การแปล error code ต้องดูขอบเขต ไม่ควรสรุปว่า “server ล่ม” จากอาการเดียว

3send(), recv() และสิ่งที่ Programmer มักเข้าใจเกินจริง

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

TCP รักษาลำดับ byte แต่ไม่รักษาขอบเขตของแต่ละ send() สมมุติ sender ส่ง “ABC” แล้วส่ง “DEF” receiver อาจอ่านได้ “ABCDEF” ครั้งเดียว หรืออ่าน “AB”, “CD”, “EF” หลายครั้งก็ได้ ตราบใดที่ลำดับ byte ยังถูกต้อง

ดังนั้น application protocol ต้องกำหนด message framing เอง เช่น:

send() อาจส่งได้ไม่ครบตามที่ขอ

ค่า return ของ send() หรือ write() บอกจำนวน byte ที่ API รับไปในครั้งนั้น โดยเฉพาะ non-blocking socket หรือเมื่อ buffer มีพื้นที่จำกัด อาจรับได้น้อยกว่าขนาดที่ application ขอ Programmer จึงต้องวนส่งส่วนที่เหลือและจัดการ error อย่างถูกต้อง

แม้ส่งเข้า kernel buffer ได้ครบ ก็ยังไม่ได้รับรองว่า byte ถึง application ปลายทาง TCP จะพยายามส่งตาม state ของ connection แต่หากเครื่องหยุดทำงานหลังจากนั้นหรือ connection เกิดปัญหา ผลลัพธ์ระดับ application ยังอาจไม่สำเร็จ

recv() อาจได้ข้อมูลน้อยกว่าหนึ่ง Message

recv() คืน byte ที่พร้อมอ่านในขณะนั้น สูงสุดตามขนาด buffer ที่ application ให้ มันไม่จำเป็นต้องรอให้ “message ของเรา” ครบ เพราะ TCP ไม่รู้ขอบเขตดังกล่าว Application ต้องสะสมข้อมูลจน parser บอกว่าได้ frame ครบ

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

Buffer ช่วยแยกจังหวะ แต่ไม่ได้มีขนาดไม่จำกัด

Send buffer ช่วยให้ application วางข้อมูลไว้แล้วกลับไปทำงานต่อ ขณะที่ kernel ค่อยส่งตามเครือข่าย Receive buffer เก็บข้อมูลที่มาถึงไว้จน application อ่าน ความเร็วของ application กับ network จึงไม่ต้องตรงกันทุกขณะ

แต่หาก sender สร้างข้อมูลเร็วกว่าที่ network ระบายออก buffer จะเต็มและ send() อาจ block, รับข้อมูลบางส่วน หรือรายงานให้ลองใหม่ หาก receiver อ่านช้า receive window อาจลดลงและ flow control ทำให้ sender ช้าตาม Buffer ดูดซับความต่างระยะสั้นได้ แต่ไม่สามารถแก้ความไม่สมดุลถาวร

Timeout เป็นนโยบายของผู้รอ ไม่ใช่หลักฐานว่าอีกฝั่งไม่ได้ทำงาน

เมื่อ operation timeout เรารู้เพียงว่าไม่เห็นผลที่ต้องการภายในเวลาที่กำหนด Request อาจไม่ถึง server, server อาจทำอยู่, response อาจหาย หรือระบบอาจเพียงช้ากว่าค่าที่เราตั้ง หาก retry operation ที่มีผลข้างเคียงโดยไม่มี idempotency อาจทำงานซ้ำ

การออกแบบจึงต้องแยก connect timeout, read timeout, write timeout และ deadline ของงานทั้งหมด เพราะแต่ละค่าป้องกันการรอคนละช่วง Deadline แบบ end-to-end ช่วยไม่ให้การ retry หลายรอบรวมกันยาวเกินเวลาที่ผู้ใช้ยอมรับ

close() กับ shutdown() และการปิดเพียงครึ่งทาง

close() ปล่อย descriptor ของ process เมื่อไม่มี reference ที่เกี่ยวข้องเหลือ ระบบจึงดำเนินการปิด socket ตาม semantics ของ protocol ส่วน shutdown() ใช้ปิดทิศทางการอ่านหรือเขียนบางด้านโดยไม่จำเป็นต้องปล่อย descriptor ทันที

TCP เป็น full-duplex จึงสามารถเกิด half-close ได้ เช่น client ส่ง request เสร็จแล้วปิดทิศทางเขียนเพื่อบอกว่าไม่มีข้อมูลเพิ่ม แต่ยังอ่าน response จาก server ต่อ การเข้าใจว่าปิดหนึ่งทิศไม่เท่ากับทำลายทุกอย่างทันทีช่วยออกแบบ protocol ที่ใช้ end-of-stream เป็นสัญญาณได้

4UDP Socket — ไม่มี Connection แต่ไม่ได้แปลว่าไม่มีกติกา

UDP ให้บริการแบบ datagram และรักษาขอบเขต message แต่ไม่สร้าง connection และไม่รับรอง delivery, ordering หรือ duplicate suppression ให้ Application จึงได้ overhead และ state ที่น้อยลง พร้อมรับผิดชอบคุณสมบัติที่ต้องการเพิ่มเติมเอง

UDP socket สามารถเรียก connect() ได้ แต่ไม่ได้สร้าง handshake หรือ reliability แบบ TCP โดยทั่วไปเป็นการบันทึก default peer ใน kernel และช่วยกรองหรือส่ง datagram โดยไม่ต้องระบุ address ทุกครั้ง คำว่า connected UDP จึงมีความหมายต่างจาก connected TCP

หนึ่ง recvfrom อ่านหนึ่ง Datagram แต่ Buffer อาจเล็กเกินไป

UDP รักษาขอบเขต datagram ต่างจาก TCP stream หาก sender ส่ง datagram สองก้อน receiver จะไม่เห็นเป็น byte stream ก้อนเดียว อย่างไรก็ตาม หาก receive buffer ที่ application ให้เล็กกว่า datagram ข้อมูลส่วนเกินอาจถูกตัดทิ้งตาม API และไม่สามารถเรียกอ่าน “ส่วนที่เหลือ” เหมือน stream ได้โดยอัตโนมัติ

Datagram ขนาดใหญ่ยังอาจนำไปสู่ IP fragmentation หรือไม่เหมาะกับ path MTU ซึ่งเพิ่มความเสี่ยงต่อ loss Application protocol จึงควรเลือกขนาด message และกลไกแบ่งข้อมูลอย่างระมัดระวัง ไม่ใช่เพียงเห็นว่า UDP รับได้หนึ่ง message แล้วส่งก้อนใหญ่เท่าไรก็ได้

5จาก Socket เดียว ไปสู่ Server ที่รับหลาย Client

Sequential Server เข้าใจง่าย แต่ Client คนเดียวอาจขวางทุกคน

Server แบบง่ายอาจ accept client หนึ่งราย รับ request ประมวลผล ส่ง response แล้วจึงกลับไปรับรายต่อไป หาก client แรกส่งข้อมูลช้า หรือเชื่อมแล้วไม่ส่งอะไร client อื่นทั้งหมดต้องรอ แม้ CPU และ network ยังว่างอยู่

Thread, Process, Event Loop และ Async I/O

Concurrency ไม่ได้ทำให้ CPU เร็วขึ้นเอง แต่มันเปิดให้ server ใช้เวลาที่งานหนึ่งกำลังรอ I/O ไปดูแลงานอื่น การเลือก model ต้องดูจำนวน connection ระยะเวลารอ ปริมาณ CPU ต่อ request และความง่ายในการรักษา state ให้ถูกต้อง

Backpressure: เมื่อปลายทางช้ากว่า เราจะทำอย่างไร

หาก server สร้าง response เร็วกว่าที่ client รับได้ send buffer จะค่อย ๆ เต็ม ระบบต้องชะลอ producer, เก็บคิวเพิ่ม จำกัดปริมาณงาน หรือยกเลิก connection บางส่วน หากรับทุกอย่างโดยไม่มีขอบเขต หน่วยความจำจะกลายเป็น buffer สุดท้ายและล่มทั้ง process

Backpressure คือการส่งสัญญาณย้อนกลับว่าฝั่งถัดไปรับงานไม่ทัน แนวคิดนี้ปรากฏตั้งแต่ TCP flow control ไปจนถึง message queue และ microservices Socket programming ทำให้เราเห็นปัญหานี้ในรูปพื้นฐานที่สุด

6ข้อผิดพลาดที่ควรตรวจให้พบตั้งแต่ห้องปฏิบัติการ

ตรวจ Return Value และ Error ทุกครั้ง

System call อาจล้มเหลว ถูก interrupt หรือทำงานได้เพียงบางส่วน โปรแกรมที่ทดสอบบนเครื่องเดียวอาจดูปกติ แต่พังเมื่อเจอ network delay, client disconnect หรือ resource limit การตรวจ return value ไม่ใช่งานตกแต่งหลังเขียนเสร็จ แต่เป็นส่วนหนึ่งของ semantics ของ API

นอกจาก error จาก network ยังมีข้อจำกัดของระบบ เช่น descriptor หมด memory ไม่พอ address ถูกใช้อยู่ หรือ permission ไม่เหมาะสม Network program จึงล้มเหลวได้แม้สาย network ไม่ได้มีปัญหาเลย

7สรุปบทนำร่วมและขั้นตอนถัดไป

จากบทนำ ไปสู่การลงมือสร้าง Network Application

หลังจากนี้ผู้เรียนควรได้ทดลองเขียน TCP client/server ที่รองรับ partial read, framing และ timeout จากนั้นจึงเปรียบเทียบกับ UDP ทดลองจำลอง delay, disconnect และ message ซ้ำ เพื่อให้เห็นว่าแนวคิดในบท Reliability และ Performance ปรากฏใน code อย่างไร

เมื่อผ่านจุดนี้ Socket API จะไม่ใช่เพียงรายชื่อ function แต่เป็นรอยต่อที่ทุกแนวคิดก่อนหน้ามาพบกัน: address จาก Network Layer, port และ stream จาก Transport Layer, protocol จาก Application Layer และ failure ที่อาจเกิดได้ตลอดเส้นทาง