บทเรียนเรื่อง Computer Networks และ Network Computing ตั้งแต่หลักการพื้นฐานไปจนถึงการเขียนโปรแกรมและออกแบบบริการบนเครือข่าย เนื้อหาชุดเดียวกันนี้จัดไว้หลายเส้นทาง เพราะคนเราไม่ได้เข้าใจเรื่องยากจากจุดเริ่มต้นเดียวกัน
ทำ Pretest / Posttest · 13 หัวข้อ →ตอนเริ่มจัดเนื้อหาชุดนี้ ผมมีคำถามอยู่ข้อหนึ่งว่า ทำไมผู้เรียนบางคนเข้าใจเรื่องเครือข่ายได้ดีเมื่อเริ่มจากสัญญาณและสายสื่อสาร ขณะที่อีกกลุ่มหนึ่งกลับเห็นภาพทันทีเมื่อเริ่มจากเว็บ แอป หรือบริการที่เขาใช้อยู่ทุกวัน ทั้งสองกลุ่มไม่ได้มีใครเก่งกว่ากัน เขาเพียงมีความรู้เดิมและวิธีตั้งคำถามต่างกัน ถ้าเราบังคับให้ทุกคนเริ่มจากหน้าเดียวกัน เดินด้วยความเร็วเดียวกัน และมองเครือข่ายด้วยแว่นอันเดียวกัน คนจำนวนหนึ่งจะต้องจำคำศัพท์อยู่นานกว่าจะรู้ว่าสิ่งที่จำไปนั้นเอาไว้ตอบคำถามอะไร
ผมจึงไม่อยากให้เว็บไซต์นี้เป็นเพียงสารบัญที่เรียงบทที่ 1 ถึงบทสุดท้าย แต่ตั้งใจให้เป็นแผนที่การเรียนรู้ ผู้เรียนควรเห็นก่อนว่าแต่ละเส้นทางพาไปทางไหน ระหว่างทางเราจะตอบคำถามอะไร และเมื่อใดควรย้อนกลับมาเชื่อมความรู้เข้าหากัน การแยกเส้นทางไม่ได้แปลว่าเนื้อหาคนละชุด และไม่ได้แบ่งว่าเด็กสาขาไหน “ควร” รู้มากหรือน้อยกว่าสาขาอื่น สิ่งที่ต่างกันคือจุดเริ่มต้นและลำดับในการประกอบภาพเท่านั้น
อีกภาพหนึ่งคืออาคารหลังใหญ่ วิศวกรที่สนใจโครงสร้างอาจเริ่มดูฐานราก สายไฟ และท่อก่อนจะขึ้นไปถึงห้องทำงาน นักพัฒนาซอฟต์แวร์อาจเดินเข้าทางประตูหน้า เห็นว่าคนในอาคารทำงานอะไร แล้วค่อยถามว่าลิฟต์ ไฟฟ้า และระบบน้ำสนับสนุนงานนั้นอย่างไร ผู้ดูแลระบบอาจเริ่มจากคำถามว่า ถ้าลิฟต์เสีย ไฟตก หรือคนเข้าพร้อมกันจำนวนมาก อาคารจะยังให้บริการได้หรือไม่ ทุกคนศึกษาอาคารเดียวกัน เพียงเริ่มจากปัญหาที่คุ้นเคยต่างกัน
คำใหม่จะมีความหมายเมื่อมันไปเกาะกับประสบการณ์เดิม ผู้เรียนจึงเลือกเริ่มจากสัญญาณ แอปพลิเคชัน อินเทอร์เน็ตที่ใช้งานจริง หรือปัญหาในระบบก็ได้
ผมอยากให้ถามก่อนว่า “ปัญหาคืออะไร” แล้วจึงดูว่า protocol, layer หรือ pattern ใดเกิดขึ้นมาเพื่อแก้ปัญหานั้น
โมเดลช่วยให้เราแยกเรื่องซับซ้อนออกเป็นส่วน ๆ ส่วน socket, HTTP, Docker และ microservice ช่วยให้เห็นผลของแนวคิดเหล่านั้นในโค้ดและการใช้งานจริง
การมีหลายเส้นทางจึงไม่ใช่การลดความยากของเนื้อหา แต่เป็นการจัดลำดับความยากให้เหมาะกับคำถามของผู้เรียน เราไม่ได้ตัดรายละเอียดทิ้ง เพียงเลื่อนเวลาที่จะพบรายละเอียดบางอย่าง เมื่อเรียนไปสักระยะ ทุกคนควรข้ามไปดูเส้นทางอื่นด้วย เพราะการมองเรื่องเดิมจากอีกด้านมักทำให้สิ่งที่เคยจำกลายเป็นสิ่งที่เข้าใจ
ถ้าเพิ่งเรียนเครือข่ายเป็นครั้งแรก ผมแนะนำให้อ่านบทนำร่วมทั้ง 8 หน้าเสียก่อน บทนำทำหน้าที่เหมือนการกางแผนที่บนโต๊ะ เราจะยังไม่รู้จักถนนทุกเส้น แต่ควรรู้ว่าเมืองนี้มีบ้าน มีถนน มีทางแยก มีที่อยู่ และมีข้อจำกัดเรื่องเวลาและความจุ จากนั้นจึงเลือกเส้นทางหลักหนึ่งเส้นเพื่อเดินอย่างต่อเนื่อง เมื่อพบคำที่ไม่คุ้น ให้จดคำถามไว้ก่อน ไม่จำเป็นต้องหยุดค้นทุกคำจนเสียภาพรวม
| วิธีเรียน | เหมาะกับสถานการณ์ | ทำอย่างไร |
|---|---|---|
| เรียนตามลำดับ | เพิ่งเริ่มและต้องการโครงสร้างที่ชัด | อ่านบทนำ 1–8 แล้วเลือก Bottom-Up, Top-Down หรือ TCP/IP หนึ่งเส้น พยายามอธิบายความเชื่อมโยงกับหน้าก่อนทุกครั้ง |
| เรียนจากปัญหา | มีงานหรือ lab ที่ต้องทำอยู่แล้ว | เริ่มจากปัญหา เช่น ส่งข้อความไม่ครบ ตอบช้า หรือเรียกบริการไม่ได้ แล้วเปิดหัวข้อที่เกี่ยวข้อง จากนั้นย้อนดูชั้นล่างและชั้นบนที่มีผลต่อปัญหา |
| เรียนแบบเปรียบเทียบ | อ่านมารอบหนึ่งแล้วแต่แนวคิดยังปนกัน | เปิดเรื่องเดียวกันจากสองแผนที่ เช่นเทียบ OSI กับ TCP/IP หรือเทียบคำอธิบายเชิง protocol กับโค้ด socket แล้วเขียนด้วยคำของตัวเองว่าส่วนไหนตรงกันและส่วนไหนเป็นเพียงแบบจำลอง |
ถ้าตอบได้เพียงคำจำกัดความ แต่ยังเล่าเหตุการณ์ตั้งแต่โปรแกรมฝั่งหนึ่งส่งข้อมูลไปถึงอีกฝั่งไม่ได้ แปลว่ายังมีช่องว่างอยู่ ช่องว่างนั้นไม่ใช่ความล้มเหลว แต่เป็นป้ายบอกว่าเราควรข้ามไปดูหน้าใดต่อ
เริ่มจาก Physical Layer ไล่ขึ้นไปทีละชั้นจนถึง Application ตามโครงสร้างจริงของสัญญาณ/ฮาร์ดแวร์/โปรโตคอล เหมาะกับสายที่เน้นวงจร สัญญาณ และระบบเครือข่ายระดับล่าง
เริ่มเส้นทาง Bottom-Up (OSI) →เริ่มจาก Application Layer แล้วไล่ลงไปดูว่าแต่ละชั้นล่างสนับสนุนแอปพลิเคชันอย่างไร เหมาะกับสายที่เน้นซอฟต์แวร์ ระบบ และการออกแบบโปรโตคอลระดับสูง
เริ่มเส้นทาง Top-Down →เริ่มจาก TCP/IP stack เพื่อเห็นโครงสร้างที่อินเทอร์เน็ตใช้งานจริง จากนั้นเทียบกลับไปศึกษา OSI ให้ครบทั้ง 7 Layer แล้วจึงต่อด้วย congestion, QoS, security และ internetworking
เริ่มเส้นทาง TCP/IP →Bottom-Up เริ่มจากคำถามว่า ก่อนคอมพิวเตอร์สองเครื่องจะคุยกันได้ เราต้องทำให้บิตเดินทางผ่านสื่อได้อย่างไร เมื่อบิตเดินทางได้แล้วจึงค่อยรวมเป็น frame ส่งในเครือข่ายใกล้ตัว หาเส้นทางข้ามเครือข่าย แยกข้อมูลให้ถูกโปรแกรม และสุดท้ายให้บริการแก่ผู้ใช้ ข้อดีคือเห็นชัดว่าแต่ละชั้นสร้างความสามารถใหม่บนข้อจำกัดของชั้นล่างอย่างไร เหมือนสร้างบ้านจากฐานรากขึ้นไป เมื่อถึงหลังคาเราจะรู้ว่าน้ำหนักทั้งหมดถูกส่งผ่านส่วนใดบ้าง
Top-Down เริ่มจากสิ่งที่ผู้ใช้และโปรแกรมต้องการ เช่น เปิดเว็บ ค้นชื่อเครื่อง ส่งไฟล์ หรือประชุมออนไลน์ แล้วถามย้อนลงไปว่า ถ้าจะให้บริการนี้เกิดขึ้น เราต้องมีช่องทางสื่อสารแบบใด ต้องระบุปลายทางอย่างไร และสุดท้ายข้อมูลกลายเป็นสัญญาณได้อย่างไร ข้อดีคือคำศัพท์ชั้นล่างไม่ลอยอยู่โดด ๆ ทุกคำมีแอปพลิเคชันคอยบอกว่าเรียนไปเพื่ออะไร เหมือนเริ่มออกแบบบ้านจากกิจกรรมของคนในบ้าน แล้วค่อยลงรายละเอียดว่าฐานรากและระบบสาธารณูปโภคต้องรองรับอะไร
TCP/IP เริ่มจากโครงสร้างที่อินเทอร์เน็ตใช้เป็นหลัก เหมาะกับสาย IT ที่อยากเห็นภาพของระบบซึ่งใช้งานจริงก่อน แล้วจึงนำโครงสร้าง 4 ชั้นนี้ไปเทียบกับ OSI ให้ครบทั้ง 7 Layer ลำดับที่ต่างกันไม่ได้แปลว่าเรียนเนื้อหาน้อยลง เพียงเริ่มจากแผนที่ที่กระชับกว่า ก่อนขยายให้เห็นหน้าที่ซึ่ง OSI แยกไว้ละเอียดกว่าเดิม
หัวข้อขั้นสูงและ Network Computing เป็นขั้นถัดจากพื้นฐาน ไม่ใช่ทางลัดที่ข้ามพื้นฐาน เมื่อเข้าใจ TCP/IP และเห็นความสัมพันธ์กับ OSI ครบแล้ว จึงค่อยศึกษาสิ่งที่เกิดเมื่อระบบถูกใช้งานจริง ผู้ใช้มากขึ้นทำให้เกิด congestion เครื่องบางตัวล่มทำให้เกิด partial failure การ retry โดยไม่ระวังทำให้งานซ้ำ และบริการจำนวนมากทำให้การตามหาสาเหตุยากขึ้น เส้นทางนี้เหมือนออกจากห้องเรียนไปยืนในห้องควบคุม เราต้องใช้ทั้งความรู้เรื่องเครือข่าย โค้ด การติดตั้งระบบ และการสังเกตอาการร่วมกัน
ปูพื้นฐานที่ใช้ร่วมกันทุกเส้นทาง: เครือข่ายคืออะไร, การสวิตช์, การแชร์ทรัพยากร, รูปแบบการสื่อสาร, protocol/layering, เปรียบเทียบ OSI กับ TCP/IP, performance, และ Socket API — จบหน้าที่ 8 แล้วจึงเลือกว่าจะศึกษา OSI แบบ Bottom-Up, OSI แบบ Top-Down หรือเริ่มจาก TCP/IP แล้วเทียบกลับไปให้ครบทั้ง 7 Layer ก่อนต่อด้วยหัวข้อขั้นสูง
บทนำไม่ได้มีไว้แค่ท่องคำศัพท์ก่อนเข้าบทจริง แต่ใช้สร้างชุดคำถามร่วมกัน หน้าแรกเริ่มจากความหมายของเครือข่ายและเหตุผลที่เครื่องหลายเครื่องต้องเชื่อมถึงกัน หน้าที่สองพูดถึง connectivity และ switching ว่าเมื่อมีปลายทางมากกว่าสองแห่ง เราจะจัดทางเชื่อมอย่างไรโดยไม่ต้องลากสายตรงหากันทุกคู่ หน้าที่สามอธิบาย multiplexing หรือการแบ่งใช้ทรัพยากรร่วมกัน เพราะช่องสื่อสารหนึ่งเส้นมักต้องรองรับผู้ใช้หลายคน
หน้าที่สี่ขยับจากการ “ส่งได้” ไปสู่การ “สื่อสารให้เข้าใจตรงกัน” รวมทั้งคำถามเรื่องข้อมูลสูญหาย ผิดลำดับ หรือมาถึงไม่ทันเวลา หน้าที่ห้าแนะนำ protocol และ layering ซึ่งเป็นภาษาหลักของวิชานี้ หน้าที่หกวาง OSI และ TCP/IP เคียงกันเพื่อให้รู้ว่าแบบจำลองไม่ใช่ตัวเครือข่ายเอง หน้าที่เจ็ดพูดเรื่อง performance เพื่อแยก bandwidth, throughput, latency และ delay ออกจากกัน ส่วนหน้าที่แปดนำแนวคิดลงมาสู่ Socket API จุดที่โปรแกรมเริ่มแตะบริการของระบบเครือข่าย
ชื่อ protocol มีจำนวนมากและเปลี่ยนไปตามเทคโนโลยี แต่คำถามหลักของเครือข่ายกลับวนอยู่ไม่กี่เรื่อง หากรู้ว่ากำลังตอบคำถามใด เราจะวางรายละเอียดใหม่ลงในภาพเดิมได้ง่ายกว่าการจำรายการชื่อยาว ๆ
| คำถาม | ตัวอย่างกลไก | ภาพเปรียบเทียบ |
|---|---|---|
| ข้อมูลถูกแทนอย่างไร | encoding, framing, serialization, compression | ก่อนส่งของ เราต้องตกลงว่าของชิ้นไหนนับเป็นหนึ่งกล่อง ป้ายและสัญลักษณ์บนกล่องอ่านอย่างไร |
| ส่งไปหาใครและทางไหน | MAC address, IP address, DNS, routing | ชื่อคน ที่อยู่บ้าน และเส้นทางของรถส่งของเป็นคนละเรื่องกัน แม้ทั้งหมดช่วยให้ของถึงผู้รับ |
| รู้ได้อย่างไรว่าถึงครบ | checksum, ACK, sequence number, retransmission | เลขพัสดุบอกลำดับ ใบรับของบอกว่าถึง และการส่งใหม่ช่วยเมื่อของหาย แต่ส่งใหม่โดยไม่คิดอาจทำให้ได้ของซ้ำ |
| แบ่งใช้ทางร่วมกันอย่างไร | multiplexing, switching, queueing, congestion control | ถนนเส้นเดียวรองรับรถหลายคันได้ แต่ถ้าทุกคันเข้าพร้อมกัน ถนนกว้างเพียงใดก็อาจติด |
| โปรแกรมตกลงกันว่าอะไร | HTTP, DNS, API contract, message schema | มีโทรศัพท์ไม่ได้แปลว่าคุยรู้เรื่อง ผู้พูดต้องใช้ภาษาและแบบสนทนาที่อีกฝ่ายเข้าใจด้วย |
| เมื่อบางส่วนเสียจะทำอย่างไร | timeout, retry, idempotency, circuit breaker, health check | ปลายสายเงียบอาจแปลว่าไม่ได้ยิน กำลังคิด หรือหลุดไปแล้ว ผู้โทรไม่รู้แน่ชัดจากความเงียบเพียงอย่างเดียว |
เมื่อเจอเทคโนโลยีใหม่ ลองอย่าเพิ่งถามว่า “ต้องจำคำสั่งอะไร” ให้ถามก่อนว่าเทคโนโลยีนั้นแก้หนึ่งในคำถามข้างบนอย่างไร แลกอะไรกับอะไร และสมมุติว่าองค์ประกอบใดเชื่อถือได้ การตั้งคำถามแบบนี้ทำให้ความรู้ใช้ต่อได้ แม้เครื่องมือและชื่อผลิตภัณฑ์จะเปลี่ยนไป
เรียนละเอียดทีละชั้นตามโมเดล 7 ชั้น จาก Physical ขึ้นไปถึง Application เหมาะกับ CE และใครก็ตามที่ต้องการความเข้าใจลึกครบทุกมิติ (เนื้อหาเวอร์ชันเต็ม)
เนื้อหาเดียวกับ OSI ทั้ง 7 หน้า แต่เรียงลำดับการเรียนจาก Application ไล่ลงมาถึง Physical เหมาะกับ CS ที่อยากเห็นภาพแอปพลิเคชันก่อนแล้วค่อยลงรายละเอียดชั้นล่าง
เรียนตามโมเดลที่ Internet ใช้จริง 4 ชั้นเพื่อให้เห็นภาพรวมได้เร็ว แล้วใช้ลิงก์ในแต่ละหน้าเทียบกลับไปยัง OSI ที่เกี่ยวข้องจนครบทั้ง 7 Layer เส้นทางนี้เหมาะเป็นจุดเริ่มต้นของสาย IT และใช้ได้กับทุกสาขา
ต่อยอดหลังเข้าใจ TCP/IP และหน้าที่ของ OSI ครบทั้ง 7 Layer แล้ว ครอบคลุมปัญหาบริเวณ Transport, Network และเรื่องที่เกี่ยวข้องข้ามหลายชั้น เหมาะกับ IT โดยตรง และเป็นความรู้ต่อยอดสำหรับ CE/CS เช่นกัน
เวลาเรียน OSI เรามักวาดชั้นเป็นกล่องเจ็ดใบซ้อนกัน ภาพนี้มีประโยชน์มาก เพราะช่วยแยกความรับผิดชอบและทำให้สนทนากันได้ตรงเรื่อง แต่ต้องระวังไม่ให้ภาพกล่องกลายเป็นความเข้าใจว่าระบบจริงต้องมีโปรแกรมเจ็ดชิ้นวางซ้อนกันอย่างเรียบร้อยเสมอ การแบ่งชั้นเป็นแบบจำลองสำหรับคิด ออกแบบ และอธิบาย ส่วนการนำไปสร้างจริงอาจรวมบางหน้าที่ไว้ด้วยกัน กระจายหน้าที่หนึ่งไปหลายส่วน หรือให้ hardware, operating system, library และ application แบ่งกันทำ
ตัวอย่างเช่น การเข้ารหัสข้อมูลอาจเกิดใน application library, TLS library หรืออุปกรณ์เฉพาะ การรักษาสถานะของการสนทนาอาจอยู่ใน cookie, token, database หรือโค้ดของบริการ การบอกว่า TCP/IP ไม่มี Session และ Presentation layer แยกต่างหากจึงไม่ได้แปลว่างานทั้งสองอย่างหายไป และไม่ควรสรุปง่าย ๆ ว่าถูกยุบเข้า Application ทั้งหมด งานเหล่านั้นยังอยู่ เพียงตำแหน่งและผู้รับผิดชอบขึ้นกับ protocol และสถาปัตยกรรมที่เลือกใช้
แต่การแบ่งชั้นก็มีค่าใช้จ่าย แต่ละชั้นเพิ่ม header มีการคัดลอกหรือประมวลผลข้อมูล และบางครั้งข้อมูลที่ชั้นหนึ่งรู้กลับส่งต่อไปใช้อีกชั้นได้ไม่สะดวก ระบบสมัยใหม่จึงมีแนวคิด cross-layer optimization อยู่ด้วย สิ่งสำคัญไม่ใช่การยึดกล่องให้แน่นที่สุด แต่คือรู้ว่าเมื่อข้ามขอบเขตของชั้น เรากำลังแลกความเรียบง่ายกับอะไร
Resource allocation, Fair Queuing, TCP AIMD/Slow Start/Fast Retransmit, DECbit, RED, IntServ/RSVP, DiffServ — ต่อยอดจาก Transport Layer
อ่านหัวข้อนี้ →Cryptographic building blocks, PKI, Diffie-Hellman, PGP/SSH/TLS/IPsec, 802.11i, Firewall — ครอบคลุมหลาย Layer
อ่านหัวข้อนี้ →BGP-4 interdomain routing, IPv6, Internet Multicast (DVMR/RPB/PIM), Mobile IP — ต่อยอดจาก Network Layer
อ่านหัวข้อนี้ →ห้องทดลองหกหน้าเชื่อมกันจากข้อความ HTTP ไปสู่การค้นชื่อ การส่ง Email การสร้าง Secure Channel การส่ง Request ผ่าน Gateway และการกระจายข้อมูลแบบ Peer-to-Peer ทุกหน้าจำลองทีละ Message หรือ Hop จึงเห็นทั้งเส้นทางปกติและ Failure semantics ได้จากหลักฐาน
ประกอบ HTTP/1.1 request/response ตรวจ CRLF, header, body, status และ UTF-8 bytes
เปิด Lab →ติดตาม Cache, Recursive Resolver, Root, TLD และ Authoritative พร้อม TTL และ NXDOMAIN
เปิด Lab →ห้า Lab ย่อย: Journey, SMTP dialogue, MIME, SPF/DKIM/DMARC และ IMAP/POP3
เปิด Lab →เดิน TLS 1.3 ตรวจ Certificate chain, SNI, ALPN, Expiry, Name mismatch และ Trust
เปิด Lab →ทดลอง Routing, Health, Deadline และหาที่มาของ 200, 502, 503 และ 504
เปิด Lab →ทดลอง Piece, Rarest-first, Choking, Peer-wire message, Hash integrity และ Seeder ที่ออกก่อน
เปิด Lab →ส่วน OSI และ TCP/IP ช่วยอธิบายว่าข้อมูลเดินทางผ่านเครือข่ายอย่างไร ส่วน Network Computing ขยับคำถามไปอีกขั้นว่า เราจะเขียนโปรแกรมสองฝั่งให้สื่อสารกันอย่างถูกต้อง และจะดูแลบริการนั้นอย่างไรเมื่อมีผู้ใช้จริง เครื่องจริง และความผิดพลาดจริง เนื้อหาจึงเริ่มจาก Socket API แล้วค่อยไปถึง network service, failure, deployment, observability, microservice pattern และปิดท้ายด้วยแล็ปเครื่องมือเครือข่ายสำหรับตรวจสอบระบบจากหลักฐานจริง
โมดูลนี้ไม่ใช่เพียงวิชาเขียนเว็บ และไม่ใช่การสอน Docker หรือ framework ใด framework หนึ่ง เป้าหมายคือให้ผู้เรียนมองเห็นรอยต่อระหว่าง protocol กับโค้ด ระหว่างโค้ดกับระบบปฏิบัติการ และระหว่างบริการหนึ่งตัวกับระบบทั้งชุด เหมาะทำเป็น lab หลังมีพื้นฐาน Transport Layer และ Application Layer หรือใช้เป็นประตูเข้าเรื่องเครือข่ายสำหรับผู้ที่มีพื้นฐานการเขียนโปรแกรมอยู่แล้ว
Socket API, client-server model, bind/listen/accept/connect, TCP เป็น byte stream ไม่ใช่ message, message framing, JSON serialization, concurrent server, timeout — lab: key-value server (SET/GET/DELETE)
อ่านหัวข้อนี้ →HTTP request/response, API contract, REST, method/status code, stateless service, authentication เบื้องต้น, REST vs RPC, WebSocket/message queue — lab: สองบริการที่เป็นทั้ง server และ client
อ่านหัวข้อนี้ →Partial failure, timeout vs connection refused, retry/idempotency, exponential backoff, health check, correlation ID, Docker networking, load balancing — lab: Docker Compose จำลอง failure จริง
อ่านหัวข้อนี้ →8 กลุ่ม pattern (decomposition, communication, data management, resilience, consistency/messaging, deployment, observability, migration) พร้อม anti-pattern ที่ควรรู้คู่กัน เช่น Distributed Monolith, Retry Storm
อ่านหัวข้อนี้ →ฝึกวินิจฉัยปัญหาอย่างเป็นลำดับด้วย ipconfig/ip, ping, ARP, routing table, tracert/traceroute, DNS, netstat/ss, curl, TLS, tcpdump, Wireshark และ iperf3 พร้อมสถานการณ์ให้แยกว่าอาการเกิดที่เครื่องเรา ชื่อโดเมน เส้นทาง transport หรือบริการปลายทาง
เปิดแล็ปนี้ →ช่วงที่ 1: Network Programming เริ่มจาก socket เพราะเป็นจุดที่โปรแกรมขอใช้บริการเครือข่ายจากระบบปฏิบัติการ ผู้เรียนจะเห็นว่า server ต้อง bind, listen และ accept ส่วน client ต้อง connect แต่หัวใจไม่ได้อยู่ที่จำลำดับคำสั่งเท่านั้น หัวใจคือเข้าใจว่า TCP ส่งเป็นสายธารของ byte ไม่ได้รักษาขอบเขต message ให้เรา การเรียก send() หนึ่งครั้งจึงไม่ได้รับประกันว่าอีกฝั่งจะ recv() ได้ครบเป็นก้อนเดียว เราต้องออกแบบ framing เช่นกำหนดความยาว ใช้ตัวคั่น หรือใช้รูปแบบข้อมูลที่อ่านต่อเนื่องได้
ช่วงที่ 2: Network Services เมื่อส่ง byte ได้ เราต้องตกลงความหมายของข้อความต่อ HTTP, REST และ RPC จึงไม่ใช่เรื่องตกแต่ง URL แต่เป็นการออกแบบสัญญาระหว่างสองฝ่าย ต้องระบุว่าคำขอหน้าตาอย่างไร คำตอบมีสถานะอะไร ข้อมูลผิดรูปจะจัดการอย่างไร และการเรียกซ้ำปลอดภัยหรือไม่ API contract ที่ดีเหมือนแบบฟอร์มราชการที่ทั้งผู้ยื่นและเจ้าหน้าที่อ่านตรงกัน ถ้าแบบฟอร์มเปลี่ยนโดยไม่แจ้ง อีกฝ่ายอาจยังส่งข้อมูลถึงอาคารถูก แต่บริการทำงานต่อไม่ได้
ช่วงที่ 3: Failure, Deployment และ Observation ในโปรแกรมเครื่องเดียว ความผิดพลาดมักปรากฏตรงหน้า แต่ในระบบเครือข่าย ฝั่งหนึ่งอาจทำงานสำเร็จแล้วแต่คำตอบหาย ฝั่งเรียกจึงไม่รู้ว่าควรลองใหม่หรือหยุด การ timeout ไม่ได้บอกว่าอีกฝั่ง “ไม่ได้ทำ” เพียงบอกว่าเราไม่ได้รับคำตอบภายในเวลาที่กำหนด นี่คือ partial failure ซึ่งเป็นรากของปัญหาจำนวนมากในระบบกระจาย
เมื่อบริการมีหลายตัว เราจึงต้องมี log, metric และ trace ที่เชื่อมเหตุการณ์ข้ามเครื่องได้ Correlation ID คล้ายเลขติดตามพัสดุ ต่อให้พัสดุผ่านคลังหลายแห่ง เราควรตามเรื่องเดียวกันได้โดยไม่ต้องเดาจากเวลาเพียงอย่างเดียว Docker และ load balancer เข้ามาในบทนี้เพราะตำแหน่งที่โปรแกรมรัน ชื่อที่ใช้เรียก และเส้นทางที่คำขอผ่านมีผลต่อพฤติกรรม ไม่ใช่เพราะการใส่ container ทำให้ระบบกลายเป็น microservice โดยอัตโนมัติ
ช่วงที่ 4: Microservice Patterns จึงค่อยถามเรื่องการแบ่งระบบ การสื่อสาร การดูแลข้อมูล ความทนทาน การติดตั้ง การสังเกต และการย้ายจากระบบเดิม Pattern ไม่ใช่สูตรสำเร็จ แต่เป็นชื่อของปัญหาที่เกิดซ้ำพร้อมทางเลือกและผลข้างเคียง การรู้ชื่อ pattern โดยไม่รู้แรงกดดันที่ทำให้ต้องใช้ เปรียบได้กับพกกล่องเครื่องมือเต็มรถแต่ใช้ค้อนกับทุกอย่าง
ช่วงที่ 5: Networking Tools Lab นำความรู้ทั้งหมดกลับมาทดลองกับเครื่องและเครือข่ายจริง ผู้เรียนจะไม่ได้จำเพียงว่า ping, traceroute หรือ netstat ใช้อย่างไร แต่ต้องเริ่มจากคำถามว่าเรากำลังตรวจอะไร และผลที่เห็นยืนยันได้มากน้อยเพียงใด เช่น ping ไม่ตอบอาจหมายถึงปลายทางปิด ICMP ไม่ได้แปลว่าเว็บล่มเสมอ ส่วนการต่อ TCP สำเร็จก็ยังไม่ได้ยืนยันว่า HTTP หรือ application ทำงานถูกต้อง แล็ปนี้จึงทำหน้าที่เหมือนห้องตรวจโรคของระบบเครือข่าย—อาการหนึ่งอย่างต้องอาศัยหลักฐานหลายชิ้นก่อนสรุปสาเหตุ
| กลุ่มปัญหา | ตัวอย่าง pattern | คำถามที่ต้องตอบก่อนใช้ |
|---|---|---|
| การแบ่งบริการ | Decompose by Business Capability, Subdomain | ขอบเขตงานและข้อมูลเป็นของใคร การเปลี่ยนส่วนหนึ่งทำได้โดยไม่ลากทุกทีมมาประชุมหรือไม่ |
| การสื่อสาร | API Gateway, Backend for Frontend, Messaging | ต้องตอบทันทีหรือรอได้ ใครเป็นผู้เริ่ม การพึ่งพากันแน่นเพียงใด และเมื่อปลายทางล่มจะเกิดอะไร |
| การจัดการข้อมูล | Database per Service, Saga, CQRS | ข้อมูลใดต้องสอดคล้องทันที ข้อมูลใดยอมให้ตามกันภายหลังได้ และจะแก้เหตุการณ์ที่ทำไปครึ่งทางอย่างไร |
| ความทนทาน | Timeout, Retry, Circuit Breaker, Bulkhead | งานเรียกซ้ำได้ปลอดภัยหรือไม่ การลองใหม่เพิ่มภาระให้ระบบที่กำลังล้มหรือเปล่า และควรจำกัดความเสียหายตรงไหน |
| การสังเกตระบบ | Centralized Logging, Metrics, Distributed Tracing | เมื่อผู้ใช้บอกว่า “ช้า” เราจะเชื่อมคำขอเดียวกันข้ามหลายบริการ และแยกสาเหตุจากอาการได้อย่างไร |
| การย้ายระบบ | Strangler Fig, Anti-Corruption Layer | จะทยอยเปลี่ยนส่วนใดก่อน รักษาสัญญาเดิมอย่างไร และมีทางถอยเมื่อของใหม่ยังไม่พร้อมหรือไม่ |
ควรเรียน anti-pattern คู่กันด้วย Distributed Monolith คือระบบที่แยก deployment ออกหลายตัวแต่ยังต้องเปลี่ยนและปล่อยพร้อมกัน ส่วน Retry Storm เกิดเมื่อหลาย client ลองใหม่พร้อมกันจนระบบที่กำลังอ่อนแรงรับภาระหนักกว่าเดิม การเห็นด้านเสียช่วยเตือนว่า pattern ทุกตัวมีบริบท ไม่มีสถาปัตยกรรมใดดีเพราะชื่อของมันเพียงอย่างเดียว
ชุดนี้จัดเนื้อหาใหม่ตามเส้นทางของข้อมูล ตั้งแต่การสื่อสารระหว่างปลายทาง ชั้นเชื่อมโยงข้อมูล การหาเส้นทาง ชั้นขนส่ง และบริการระดับแอปพลิเคชัน ยังถือเป็นฉบับทดลองใช้ เนื้อหา ลำดับ และตัวอย่างอาจได้รับการแก้ไขหลังการสอน
ความเข้าใจเรื่องเครือข่ายมักเห็นได้จากการอธิบายเหตุและผล มากกว่าการจำชื่อ ผู้เรียนควรแยกได้ว่า bandwidth สูงไม่รับประกันว่า response จะเร็ว อธิบายได้ว่าทำไม TCP connection สำเร็จแต่ application ยังตอบผิด และรู้ว่า ping ไม่ผ่านไม่ได้พิสูจน์ว่าเครื่องปลายทางล่มเสมอ เพราะ firewall หรือนโยบายของระบบอาจไม่ตอบ ICMP ก็ได้ เมื่อเจออาการหนึ่งจึงไม่รีบกระโดดไปหาสาเหตุเดียว แต่สร้างสมมุติฐานหลายข้อแล้วหาหลักฐานมาคัดออก
การทดลองเล็ก ๆ ช่วยได้มาก ลองเขียน client และ server แล้วตั้งใจแบ่ง message เป็นหลายส่วน ลองหน่วงเวลา ปิดบริการกลางทาง ส่งคำขอเดิมซ้ำ หรือจำกัดจำนวน connection จากนั้นสังเกตว่าโค้ดตอบสนองอย่างไร การทดลองเหล่านี้เหมือนการซ้อมดับเพลิง เราไม่ได้ทำเพื่อให้ไฟไหม้ แต่ทำเพื่อให้รู้ว่าความเชื่อของเราตรงกับพฤติกรรมจริงหรือไม่ และเพื่อให้ตัดสินใจได้ดีขึ้นเมื่อเหตุการณ์เกิดขึ้นในระบบที่มีผู้ใช้
สุดท้าย ลองสอนเรื่องหนึ่งให้เพื่อนฟังโดยไม่เปิดสไลด์ ถ้าใช้คำเปรียบเทียบได้ พร้อมบอกได้ว่าคำเปรียบเทียบนั้นเหมือนและไม่เหมือนระบบจริงตรงไหน แปลว่าเราไม่ได้จำเพียงผิวหน้า ตัวอย่างเช่น จดหมายช่วยอธิบาย address และ encapsulation แต่ไม่ควรทำให้เข้าใจว่า packet ทุกชิ้นต้องเดินทางเส้นเดียวหรือมาถึงตามลำดับ การรู้ขอบเขตของ metaphor สำคัญพอ ๆ กับการใช้ metaphor เพราะแบบเปรียบเทียบมีหน้าที่เปิดประตูความเข้าใจ ไม่ใช่แทนรายละเอียดทั้งหมด
ถ้ายังไม่เคยเรียนเรื่องเครือข่าย ให้เริ่มจากบทนำ 8 หน้า จากนั้นเลือก Bottom-Up หรือ Top-Down ตามชนิดของคำถามที่ทำให้เราอยากเรียน ถ้าเคยเรียนมาแล้วแต่ภาพรวมยังแยกส่วน ให้ใช้เส้นทาง TCP/IP เป็นแกน แล้วเปิดหน้า OSI ที่เกี่ยวข้องเพื่อเติมรายละเอียด ถ้าสามารถอธิบาย TCP, IP, DNS และ HTTP ได้แล้ว ให้ลงมือทำ Network Programming เพราะโค้ดจะเปิดเผยช่องว่างที่คำจำกัดความซ่อนไว้
อย่าใช้จำนวนหน้าที่อ่านจบเป็นตัววัดเพียงอย่างเดียว ลองวาดเหตุการณ์หนึ่งเรื่อง เช่นผู้ใช้พิมพ์ชื่อเว็บไซต์แล้วเห็นหน้าเว็บ อธิบายตั้งแต่ DNS, การเลือกเส้นทาง, การเปิด connection, การแลก HTTP message ไปจนถึงสิ่งที่เกิดเมื่อ packet หาย จากนั้นลองเล่าเหตุการณ์เดิมในมุมของโปรแกรม ในมุมของระบบปฏิบัติการ และในมุมของผู้ดูแลระบบ ถ้าเล่าได้ต่อเนื่องและรู้ว่าจุดใดเป็นสิ่งที่โมเดลสมมุติ จุดใดเป็นสิ่งที่ protocol รับประกัน และจุดใดเป็นหน้าที่ของ application แปลว่าเราเริ่มมีแบบจำลองในหัวที่ใช้งานได้แล้ว
เป้าหมายปลายทางไม่ใช่การท่อง OSI ได้ครบเจ็ดชั้น และไม่ใช่การสร้าง microservice ให้ได้จำนวนมาก เป้าหมายคือเมื่อระบบสื่อสารผิดปกติ เราสามารถตั้งคำถามเป็นลำดับ เลือกหลักฐานที่ควรดู อธิบายข้อแลกเปลี่ยนของวิธีแก้ และออกแบบให้ความผิดพลาดไม่ลุกลามเกินจำเป็น ถ้าทำได้ ความรู้เรื่องเครือข่ายจะไม่ใช่บทที่เรียนจบแล้วจบไป แต่จะเป็นเครื่องมือคิดที่ใช้กับระบบแทบทุกชนิดที่เราสร้างต่อจากนี้