แล็ป Network Programming — จาก TCP/UDP สู่โปรแกรมจริง

1Socket คือจุดเชื่อมระหว่าง Application กับ Transport Layer

ในเชิงระบบปฏิบัติการ socket คือ file descriptor ชนิดหนึ่ง — เขียน/อ่านผ่าน socket คล้ายเขียน/อ่านไฟล์ แต่ข้อมูลวิ่งผ่านเครือข่ายแทนที่จะเขียนลงดิสก์ การระบุ socket หนึ่งตัวให้ไม่ซ้ำกับตัวอื่นในเครื่องใช้ 5-tuple:

พารามิเตอร์หลักตอนสร้าง socket: address family (AF_INET = IPv4, AF_INET6 = IPv6) และ socket type (SOCK_STREAM = TCP, SOCK_DGRAM = UDP) — สองค่านี้กำหนดว่า socket ที่ได้จะมีพฤติกรรมแบบ connection-oriented/reliable หรือ connectionless/best-effort

2Client–Server Model

เกือบทุกแอปพลิเคชันเครือข่ายตั้งอยู่บน asymmetry ระหว่างสองบทบาท:

3TCP Socket Lifecycle

ฝั่ง server และ client เดินผ่านลำดับ syscall ที่ต่างกัน:

socket() → bind() → listen() → accept() → recv()/send() (วน) → close()

socket() → connect() → send()/recv() (วน) → close()

# echo_server.py
import socket

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("0.0.0.0", 9000))
srv.listen(5)                      # backlog = 5
print("listening on :9000")

while True:
    conn, addr = srv.accept()      # บล็อกจนมี client ใหม่
    print("connected:", addr)
    while True:
        data = conn.recv(4096)
        if not data:                # b"" = client ปิด connection แล้ว
            break
        conn.sendall(data)          # echo กลับ
    conn.close()

# echo_client.py
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("127.0.0.1", 9000))
s.sendall(b"hello server")
print(s.recv(4096))
s.close()

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

สาเหตุ: TCP stack อาจรวม (coalesce) ข้อมูลจากหลาย send() เข้า segment เดียว หรือแบ่ง (fragment) ข้อมูลจาก send() เดียวออกเป็นหลาย segment ตาม MSS/MTU/สภาพเครือข่าย — ทั้งหมดนี้เกิดโปร่งใสโดยที่ application ไม่รู้และควบคุมไม่ได้

5Message Framing — ใครเป็นคนกำหนดขอบเขตข้อความ

เพราะ TCP ไม่ทำให้ ตัว application-layer protocol ที่เราออกแบบเองต้องกำหนดขอบเขต message เอง เรียกว่า framing — มี 3 เทคนิคหลัก:

def recv_line(sock, buf=b""):
    """อ่านจาก socket จนกว่าจะเจอ \\n ครบหนึ่งบรรทัด คืน (line, buf_ที่เหลือ)"""
    while b"\n" not in buf:
        chunk = sock.recv(4096)
        if not chunk:
            raise ConnectionError("peer closed before line completed")
        buf += chunk
    line, _, rest = buf.partition(b"\n")
    return line, rest

import struct

def recv_exact(sock, n):
    """อ่านให้ได้ครบ n byte เป๊ะ ไม่งั้น error"""
    data = b""
    while len(data) < n:
        chunk = sock.recv(n - len(data))
        if not chunk:
            raise ConnectionError("peer closed mid-message")
        data += chunk
    return data

def recv_framed(sock):
    header = recv_exact(sock, 4)              # 4-byte length prefix
    (length,) = struct.unpack("!I", header)
    return recv_exact(sock, length)

def send_framed(sock, payload: bytes):
    sock.sendall(struct.pack("!I", len(payload)) + payload)

6Serialization ด้วย JSON

Framing แก้ปัญหา "message เริ่ม/จบตรงไหน" ส่วน serialization แก้ปัญหาคนละชั้น: "โครงสร้างข้อมูลในโปรแกรม (dict, object, list) แปลงเป็นลำดับ byte ที่ส่งผ่านเครือข่ายได้อย่างไร แล้วแปลงกลับอย่างไร" — Presentation Layer พูดถึงแนวคิดนี้ในเชิงทฤษฎี (XDR, ASN.1) ส่วนในทางปฏิบัติปัจจุบัน JSON เป็นตัวเลือกที่นิยมที่สุดเพราะอ่านง่าย มีไลบรารีรองรับแทบทุกภาษา

import json

def send_json_line(sock, obj: dict):
    line = json.dumps(obj) + "\n"
    sock.sendall(line.encode("utf-8"))

def recv_json_line(sock, buf=b""):
    line, buf = recv_line(sock, buf)           # ใช้ recv_line จากหัวข้อก่อน
    return json.loads(line.decode("utf-8")), buf

7Blocking I/O และ Concurrent Server

Echo server ในหัวข้อ 3 มีข้อจำกัดใหญ่: accept() และ recv() เป็น blocking call — ขณะ server กำลังคุยกับ client รายหนึ่ง (ติดอยู่ใน loop recv()/send()) จะไม่กลับไปเรียก accept() รับ client รายใหม่ได้เลย client รายที่สองต้องรอจนรายแรกตัดการเชื่อมต่อ

import socket, threading

def handle_client(conn, addr):
    print("connected:", addr)
    try:
        buf = b""
        while True:
            line, buf = recv_line(conn, buf)
            conn.sendall(b"echo: " + line + b"\n")
    except ConnectionError:
        pass
    finally:
        conn.close()
        print("disconnected:", addr)

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("0.0.0.0", 9000))
srv.listen(50)

while True:
    conn, addr = srv.accept()
    t = threading.Thread(target=handle_client, args=(conn, addr), daemon=True)
    t.start()

8Timeout และการปิด Connection

sock.settimeout(5.0)          # ให้เวลารอสูงสุด 5 วินาที
try:
    data = sock.recv(4096)
except socket.timeout:
    print("no response within 5s — treat as failure")

Half-close: TCP รองรับการปิดทีละทิศทาง — sock.shutdown(socket.SHUT_WR) บอกอีกฝ่ายว่า "เราจะไม่ส่งอะไรเพิ่มแล้ว" แต่ยังอ่านข้อมูลที่อีกฝ่ายส่งมาต่อได้ ต่างจาก close() ที่ปิดทั้งสองทิศทางทันที มีประโยชน์เมื่อต้องส่ง request เสร็จแล้วรอ response ยาวๆ

9Lab: ออกแบบ Protocol สำหรับ Key–Value Server

รวมทุกหัวข้อข้างต้นเข้าด้วยกัน — ออกแบบ protocol ข้อความบรรทัดเดียว (delimiter-based framing ด้วย \n) สำหรับ key-value store อย่างง่าย:

> SET course NetworkComputing
< OK
> GET course
< VALUE NetworkComputing
> DELETE course
< OK
> GET course
< NOT_FOUND

import socket, threading

store = {}
lock = threading.Lock()

def handle(conn, addr):
    buf = b""
    try:
        while True:
            line, buf = recv_line(conn, buf)
            parts = line.decode("utf-8", errors="replace").split(" ", 2)
            cmd = parts[0].upper() if parts else ""

            if cmd == "SET" and len(parts) == 3:
                with lock:
                    store[parts[1]] = parts[2]
                resp = "OK"
            elif cmd == "GET" and len(parts) == 2:
                with lock:
                    val = store.get(parts[1])
                resp = f"VALUE {val}" if val is not None else "NOT_FOUND"
            elif cmd == "DELETE" and len(parts) == 2:
                with lock:
                    existed = store.pop(parts[1], None) is not None
                resp = "OK" if existed else "NOT_FOUND"
            else:
                resp = "ERROR unknown or malformed command"

            conn.sendall((resp + "\n").encode("utf-8"))
    except ConnectionError:
        pass
    finally:
        conn.close()

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("0.0.0.0", 9000))
srv.listen(50)
print("key-value server on :9000")
while True:
    conn, addr = srv.accept()
    threading.Thread(target=handle, args=(conn, addr), daemon=True).start()

10แผนการทดลอง: ทำให้เห็นสิ่งที่ Socket ซ่อนไว้

เตรียมเครื่องมือและสมุดบันทึก

1. ใช้ Python 3 สอง terminal โดย terminal แรกเป็น server และอีก terminal เป็น client ถ้ามีสองเครื่องในวง LAN เดียวกันให้ทดลองข้ามเครื่องหลังจาก localhost สำเร็จ
2. ทุกครั้งให้บันทึกคำสั่ง เวลา IP/port ข้อความที่ส่ง ผลที่ได้ และข้อสรุป อย่าเก็บเฉพาะภาพหน้าจอ เพราะภาพบอกว่าเกิดอะไรขึ้นแต่ยังไม่บอกเหตุผล
3. เพิ่ม log ก่อนและหลัง accept(), connect(), recv() และ sendall() พร้อมเวลาและ address เพื่อให้เรียงเหตุการณ์ย้อนหลังได้
4. ถ้าใช้ Wireshark ให้กรอง tcp.port == 9000 ถ้าใช้ tcpdump ให้ใช้ tcpdump -i any -nn tcp port 9000 แล้วเปรียบเทียบ packet กับ log ของโปรแกรม

การทดลองที่ 1 — แยก listening socket ออกจาก connected socket

เริ่ม server ก่อน client และดูว่าโปรแกรมหยุดรอที่บรรทัดใด จากนั้นเชื่อม client สองตัวพร้อมกัน พิมพ์ค่า getsockname() และ getpeername() ของ socket ที่ได้จาก accept() แล้วเติมตารางต่อไปนี้

การทดลองที่ 2 — พิสูจน์ว่า TCP ไม่มีขอบเขตข้อความ

1. ให้ client เรียก sendall(b"ONE"), sendall(b"TWO"), sendall(b"THREE") ติดกัน ส่วน server เรียก recv(4) ซ้ำและพิมพ์ repr(data)
2. ทำซ้ำโดยหน่วงระหว่างการส่ง 0.5 วินาที แล้วทำซ้ำอีกครั้งด้วย payload ยาว 100 KB ห้ามสรุปจากการทดลอง localhost เพียงรอบเดียว
3. อธิบายว่าจำนวนครั้งที่ sendall() ไม่จำเป็นต้องเท่ากับจำนวนครั้งที่ recv() และเหตุใดการเขียน json.loads(sock.recv(4096)) จึงเป็นระเบิดเวลาของโปรแกรมจริง

# ตัวช่วยทำให้การแบ่งชิ้นมองเห็นง่ายขึ้น
while True:
    block = conn.recv(4)
    if block == b"":
        break
    print(len(block), repr(block))

การทดลองที่ 3 — เปรียบเทียบ newline framing กับ length prefix

สร้าง protocol สองรุ่น รุ่น A จบข้อความด้วย \n รุ่น B นำหน้าด้วยความยาว 4 byte แบบ network byte order ทดลองส่งภาษาไทย ช่องว่าง newline ใน value และ binary data แล้วตอบว่าแต่ละแบบเหมาะกับงานใด

# length prefix: ซองจดหมายเขียนหน้าซองว่าของข้างในยาวกี่ byte
import struct
payload = "สวัสดี network".encode("utf-8")
sock.sendall(struct.pack("!I", len(payload)) + payload)

def recv_exact(sock, n):
    chunks = []
    while n:
        part = sock.recv(n)
        if part == b"":
            raise ConnectionError("peer closed before message completed")
        chunks.append(part); n -= len(part)
    return b"".join(chunks)

Metaphor ของ framing คือการเอาจดหมายใส่ซอง TCP เป็นรถไปรษณีย์ที่อาจขนหลายซองในเที่ยวเดียว แต่ถ้าเราเทกระดาษทุกแผ่นลงรถโดยไม่ใช้ซอง ผู้รับย่อมไม่รู้ว่ากระดาษหน้าใดเป็นของจดหมายฉบับไหน newline คือรอยคั่นระหว่างซอง ส่วน length prefix คือเลขจำนวนแผ่นที่เขียนไว้หน้าซอง

การทดลองที่ 4 — Protocol ที่อ่านได้ไม่เท่ากับ Protocol ที่แข็งแรง

1. ใช้ Key–Value Server เดิมทดสอบคำสั่งปกติ แล้วทดสอบคำสั่งว่าง command ไม่รู้จัก UTF-8 ผิดรูปแบบ key ยาวมาก และ client ที่ส่งครึ่งคำสั่งแล้วหยุด
2. กำหนดขนาดข้อความสูงสุด เช่น 64 KiB ถ้า buffer เกินให้ตอบ error แล้วปิด connection เพื่อป้องกัน client ที่ค่อย ๆ ส่งข้อมูลจนกินหน่วยความจำ
3. เปลี่ยน response เป็น JSON ที่มี status, data, error และ request_id ให้ client แยกความผิดพลาดของ protocol ออกจากความผิดพลาดของระบบได้
4. เขียน protocol contract หนึ่งหน้า ระบุ encoding, framing, command, response, error, maximum size และพฤติกรรมเมื่อ connection ปิดกลางข้อความ

การทดลองที่ 5 — หลาย Client, Race Condition และ Backpressure

เปิด client 20 ตัวพร้อมกัน ให้ทุกตัวเพิ่มค่า counter 1,000 ครั้ง เริ่มจาก server ที่ไม่มี lock แล้วใส่ lock เปรียบเทียบผลสุดท้าย เวลา และจำนวน thread จากนั้นให้ client ตัวหนึ่งเชื่อมต่อแต่ไม่ส่งข้อมูล เพื่อดูว่ามันยึด thread ไว้อย่างไร

การทดลองที่ 6 — การปิดแบบสุภาพ การหลุด และ Half-close

1. ปิด client ด้วย close() แล้วจดว่า server เห็น recv() คืน b"" เมื่อใด
2. บังคับหยุด process และตัดเครือข่ายชั่วคราว เปรียบเทียบว่าฝั่ง server รู้ทันทีหรือรู้เมื่อส่งครั้งถัดไป/timeout เท่านั้น
3. ใช้ shutdown(SHUT_WR) หลังส่ง request ยาว ฝั่ง server อ่านจน EOF แล้วส่งผลกลับ แสดงให้เห็นว่า TCP ปิดทิศทางส่งได้โดยยังเปิดทิศทางรับ
4. เพิ่ม cleanup ใน finally และทดสอบว่า file descriptor ไม่เพิ่มค้างหลังเชื่อมต่อซ้ำ 100 รอบ

ชิ้นงานที่ส่ง

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

เป้าหมายของหัวข้อนี้ไม่ใช่แค่ "เขียน socket ได้" — แต่คือการเจอปัญหาเหล่านี้ด้วยตัวเองระหว่างทดสอบ: