พื้นฐานเครือข่าย เว็บเทคโนโลยี และระบบกระจายศูนย์ (Web Fundamentals, Networking & Distributed Systems)

ทฤษฎีและกลไกการทำงาน (How it works): Networking คือการเชื่อมต่ออุปกรณ์หลายเครื่องเข้าด้วยกันเพื่อให้สื่อสารข้อมูลกันได้ โดยมี Protocol เป็นภาษากลาง บนโลกของ Web มีความแตกต่างสำคัญระหว่าง Internet (โครงสร้างพื้นฐานเปรียบเหมือนระบบถนน) และ Web (บริการขนส่งที่วิ่งอยู่บนถนนโดยใช้ URL, DNS, HTTP, Browser และ Server)

อุปกรณ์ทุกเครื่องต้องมีที่อยู่คือ IP Address แบ่งเป็น Private IP (ใช้ภายใน เช่น 192.168.1.10) และ Public IP (ใช้ติดต่อบน Internet) โดยมี 2 รูปแบบหลักคือ IPv4 (32-bit เช่น 142.250.199.78) และ IPv6 (128-bit เช่น 2001:db8::1) เนื่องจากมนุษย์จำตัวเลขได้ยาก จึงมีระบบ Domain Name System (DNS) ทำหน้าที่เป็นสมุดรายชื่อแปลง Domain Name เป็น IP Address โดยมี DNS Records ที่สำคัญ ได้แก่:
- A Record: ชี้ Domain ไปยัง IPv4
- AAAA Record: ชี้ Domain ไปยัง IPv6
- CNAME Record: กำหนดชื่อแทน (Alias) ไปยัง Domain อื่น
- MX Record: ระบุ Mail Server
- TXT Record: บันทึกข้อมูลข้อความ เช่น การยืนยันตัวตน Domain/SPF
- NS Record: ระบุ Name Server ผู้ดูแล Domain

# Python script to resolve domain name DNS records and inspect IP addresses
import socket

def resolve_domain_info(domain):
    print(f"=== Resolving DNS Info for: {domain} ===")
    try:
        # Resolve IPv4 Address (A Record)
        ipv4 = socket.gethostbyname(domain)
        print(f"[A Record] IPv4 Address: {ipv4}")
        
        # Resolve all addresses info (including IPv6 AAAA)
        addr_info = socket.getaddrinfo(domain, None)
        for info in addr_info:
            family = "IPv6" if info[0] == socket.AF_INET6 else "IPv4"
            print(f"[{family}] Socket Addr: {info[4][0]}")
    except socket.gaierror as e:
        print(f"DNS Resolution Failed: {e}")

resolve_domain_info("google.com")
                    

Use Case ในชีวิตจริง (Real-world Scenario): เมื่อบริษัททำการย้ายคลังข้อมูลหรือ API Gateway ไปยัง Cloud Provider ใหม่ วิศวกรข้อมูลต้องทำการอัปเดต A Record หรือ CNAME ใน DNS Server เพื่อชี้ไปยัง IP / Endpoint ใหม่ของระบบคลาวด์

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): เมื่อเปลี่ยน DNS Record แล้ว เว็บไซต์หรือ API ปลายทางอาจยังไม่เปลี่ยนทันทีเนื่องจากข้อมูลเดิมยังค้างอยู่ใน Cache ของ DNS Resolvers และ Browser ตามค่า TTL (Time To Live) แก้ไขโดยการลดค่า TTL ลงล่วงหน้า (เช่น เหลือ 300 วินาที) ก่อนทำการย้าย Server จริง เพื่อให้การอัปเดตกระจายตัวอย่างรวดเร็ว

ทฤษฎีและกลไกการทำงาน (How it works): การสื่อสารข้ามเครือข่ายอาศัยชุดโปรโตคอล TCP/IP โดย IP ทำหน้าที่ระบุที่อยู่ปลายทาง และ TCP ทำหน้าที่รับประกันว่าข้อมูลถูกส่งไปครบถ้วน ถูกลำดับ และเชื่อถือได้ ผ่านกระบวนการ TCP 3-Way Handshake (SYN -> SYN-ACK -> ACK) เหมาะกับงานที่ห้ามเสียข้อมูล เช่น HTTP, API, Database (PostgreSQL, MySQL), SSH และ Email

ในทางตรงกันข้าม UDP (User Datagram Protocol) ตัดขั้นตอนการยืนยันและการสร้าง Connection ออกเพื่อแลกกับความรวดเร็วสูงสุด เหมาะกับงานที่ไวต่อเวลา เช่น Video Streaming, Voice Calls, Telemetry Log Ingestion

Port เปรียบเสมือนหมายเลขห้องภายในอาคาร (IP Address คือที่อยู่อาคาร) เพื่อให้ Server เครื่องเดียวเปิดให้บริการหลายระบบพร้อมกันได้ เช่น Port 80 (HTTP), 443 (HTTPS), 22 (SSH), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis)

# Simple TCP vs UDP Socket Listener in Python

import socket
import threading

def start_tcp_server():
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.bind(('127.0.0.1', 8080))
    server.listen(5)
    print("[TCP Server] Listening on 127.0.0.1:8080 (Reliable)...")
    while True:
        conn, addr = server.accept()
        data = conn.recv(1024)
        conn.sendall(b"HTTP/1.1 200 OK\r\nContent-Length: 13\r\n\r\nHello via TCP")
        conn.close()

# TCP ensures zero packet loss via ACK confirmation
threading.Thread(target=start_tcp_server, daemon=True).start()
                    

Use Case ในชีวิตจริง (Real-world Scenario): ท่อส่งข้อมูล ETL/ELT ที่เชื่อมต่อกับ Database (เช่น PostgreSQL Port 5432) จะใช้ TCP เพื่อการันตีว่าแถวข้อมูลทุกเรคคอร์ดเดินทางไปถึงครบถ้วน ส่วนระบบสตรีมมิ่งเซนเซอร์ IoT จะใช้ UDP ส่งค่าอุณหภูมิความถี่สูงเพื่อความรวดเร็ว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเผลอเปิด Port ฐานข้อมูล (เช่น 5432 หรือ 3306) ออกสู่ Public Internet โดยไม่ตั้งค่า Firewall/Security Group ทำให้โดนแฮกเกอร์โจมตี brute-force ได้ แก้ไขโดยการตั้งค่า Firewall ให้ปิด Port สำคัญทั้งหมด และอนุญาต (Whitelist) เฉพาะ IP ของ Private Subnet หรือผ่าน VPN เท่านั้น

ทฤษฎีและกลไกการทำงาน (How it works): โครงสร้างของ URL เช่น https://api.example.com:443/products?page=2#reviews ประกอบด้วย Protocol (https), Subdomain (api), Domain (example.com), Port (443), Path (/products), Query String (?page=2) และ Fragment (#reviews)

HTTP (Hypertext Transfer Protocol) ทำงานแบบ Client-Server โดย Client ส่ง Request และ Server ตอบ Response กลับมา HTTP Methods ใช้บอกเจตนาในการกระทำ:
- GET: อ่าน/ดึงข้อมูล (Idempotent)
- POST: สร้างข้อมูลใหม่
- PUT: แทนที่ข้อมูลเดิมทั้งรายการ (Idempotent)
- PATCH: แก้ไขข้อมูลบางส่วน
- DELETE: ลบข้อมูล (Idempotent)

HTTP Status Codes บ่งบอกผลลัพธ์การประมวลผล:
- 1xx: Informational (กำลังดำเนินการ)
- 2xx: Success (200 OK, 201 Created)
- 3xx: Redirection (301 Moved Permanently, 302 Found)
- 4xx: Client Error (400 Bad Request, 401 Unauthorized [ยังไม่ได้ยืนยันตัวตน], 403 Forbidden [ไม่มีสิทธิ์], 404 Not Found, 429 Too Many Requests)
- 5xx: Server Error (500 Internal Server Error, 502 Bad Gateway [Proxy ติดต่อ App ไม่ได้], 503 Service Unavailable)

# Inspecting HTTP Request & Response Status Codes in Python
import urllib.request
import urllib.error

url = "https://httpbin.org/status/404"

try:
    response = urllib.request.urlopen(url)
    print(f"Status Code: {response.getcode()} - {response.reason}")
except urllib.error.HTTPError as e:
    print(f"HTTP Error Intercepted: Code {e.code} ({e.reason})")
    if e.code == 404:
        print("Debugging Tip: Check if the API Endpoint Path or Resource ID exists.")
    elif e.code == 502:
        print("Debugging Tip: Check if backend application service/container is running behind Reverse Proxy.")
                    

Use Case ในชีวิตจริง (Real-world Scenario): การทำระบบ Data Pipeline ดึงข้อมูลจาก External REST API ต้องตรวจสอบ HTTP Status Code อย่างถี่ถ้วน หากได้ 429 ให้ทำ Exponential Backoff Retry หากได้ 401 ให้ทำ Re-authentication Refresh Token และหากได้ 502/503 ให้แจ้งเตือนวิศวกร On-call

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): Anti-pattern ที่พบบ่อยคือการออกแบบ API ให้คืนค่า HTTP Status Code 200 OK เสมอ แล้วใส่ {"error": "Unauthorized"} ไว้ใน JSON Body ทำให้ระบบเฝ้าระวัง (Monitoring) ไม่สามารถดักจับ Error ได้ถูกต้อง แก้ไขโดยใช้ HTTP Status Code มาตรฐาน (401, 403, 500) ให้ตรงตามความหมายเสมอ

ทฤษฎีและกลไกการทำงาน (How it works): HTTP ปกติส่งข้อมูลแบบ Plaintext ทำให้เสี่ยงต่อการดักอ่าน HTTPS คือ HTTP ที่ทำงานอยู่บนโปรโตคอลความปลอดภัย TLS (Transport Layer Security) โดยทำหน้าที่: 1. เข้ารหัสข้อมูล (Encryption): ป้องกันการดักอ่านระหว่างทาง (Eavesdropping)
2. ตรวจสอบตัวตน (Authentication): ยืนยันว่า Server เป็นตัวจริงผ่าน Digital Certificate จาก Certificate Authority (CA)
3. รักษาความสมบูรณ์ข้อมูล (Integrity): ป้องกันข้อมูลถูกแก้ไขระหว่างทาง

อย่างไรก็ตาม HTTPS ป้องกันเฉพาะการรับส่งข้อมูลผ่าน Network แต่ไม่ได้ป้องกันช่องโหว่ระดับ Application Developer จึงต้องระวังช่องโหว่สำคัญ เช่น:
- SQL Injection: โดนฉีดคำสั่ง SQL ปลอมแปลงผ่าน Input
- XSS (Cross-Site Scripting): โดนฝัง สคริปต์ Malicious JS บนหน้าเว็บ
- CORS (Cross-Origin Resource Sharing): กลไกของ Browser ที่บล็อกไม่ให้สคริปต์จาก Origin หนึ่งยิงขอข้อมูลจากอีก Origin หนึ่ง เว้นแต่ Server ปลายทางจะอนุญาตผ่าน Header Access-Control-Allow-Origin

# Setting CORS Headers in Axum (Rust Backend)
use tower_http::cors::{CorsLayer, Any};
use axum::http::Method;

pub fn create_cors_layer() -> CorsLayer {
    CorsLayer::new()
        // Allow specific origin or methods safely
        .allow_methods([Method::GET, Method::POST, Method::OPTIONS])
        .allow_headers(Any)
        .allow_origin(Any) // On production, replace Any with specific domain e.g. https://pipecraft.dev
}
                    

Use Case ในชีวิตจริง (Real-world Scenario): เว็บแอปพลิเคชันที่มีระบบ Login, ชำระเงิน หรือรับส่งข้อมูลส่วนบุคคล (PDPA/GDPR) บังคับใช้ HTTPS 100% พร้อมเปิดใช้งาน HSTS (HTTP Strict Transport Security) เพื่อบังคับให้ Browser เชื่อมต่อด้วย HTTPS เท่านั้น

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การตั้งค่า Access-Control-Allow-Origin: * ร่วมกับ allow_credentials(true) บน Production API เปิดช่องโหว่ให้เว็บอันตรายแอบยิง API แทนผู้ใช้ได้ แก้ไขโดยระบุชื่อ Domain ที่อนุญาตเฉพาะเจาะจงเท่านั้น

ทฤษฎีและกลไกการทำงาน (How it works): เนื่องจาก HTTP เป็น Stateless Protocol (แต่ละ Request ไม่จำ Request ก่อนหน้า) ระบบ Login จึงต้องใช้นวัตกรรมจัดการสถานะ:
- Cookie: ข้อมูลขนาดเล็กที่ Server ส่งให้ Browser เก็บไว้ และ Browser จะแนบไปกับ Request ถัดไปโดยอัตโนมัติ
- Session: เก็บข้อมูลสถานะผู้ใช้ไว้บน Server (เช่น ใน RAM/Redis) แล้วส่งเพียง Session ID เก็บใน Cookie ของ Browser
- Token (เช่น JWT - JSON Web Token): ข้อมูลยืนยันตัวตนที่ถูกเซ็นสัญญาดิจิทัล (Digitally Signed) Client จะส่งแนบไปใน Header เช่น Authorization: Bearer <token> โดย Server ไม่ต้องเก็บสถานะไว้ใน Database (Stateless Auth)

# Example of Secure Cookie vs Authorization Header structure

# 1. Secure Cookie Flags (Response Header)
Set-Cookie: session_id=xyz123; Path=/; Secure; HttpOnly; SameSite=Strict; Max-Age=3600

# Explanation:
# - HttpOnly: Prevents JavaScript (XSS) from reading the cookie
# - Secure: Transmitted ONLY over HTTPS
# - SameSite=Strict: Prevents Cross-Site Request Forgery (CSRF)

# 2. JWT Bearer Token (Request Header)
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบ Microservices และ Data API นิยมใช้ JWT Bearer Token ในการยืนยันตัวตนข้ามบริการ เพราะ API Gateway สามารถส่ง Token ให้บริการย่อยถอดรหัสตรวจสอบสิทธิ์ได้ทันทีโดยไม่ต้องคิวรีฐานข้อมูลกลางซ้ำๆ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเก็บ Sensitive Token ไว้ใน localStorage หรือ sessionStorage เสี่ยงต่อการโดนแฮกเกอร์ขโมยผ่านช่องโหว่ XSS แก้ไขโดยเก็บ Refresh Token ไว้ใน Cookie ที่ตั้งค่า HttpOnly, Secure และ SameSite=Strict เสมอ