OSI Reference Model vs TCP/IP Model

1OSI Reference Model — 7 Layers

OSI เป็น reference model ที่แบ่งหน้าที่ของระบบสื่อสารออกเป็น 7 ชั้นอย่างเป็นระเบียบ จุดแข็งของมันคือช่วยให้เราเรียกชื่อปัญหาและบอกขอบเขตความรับผิดชอบได้ละเอียด แม้ protocol ที่ใช้งานจริงอาจไม่ได้แยกตัวตรงตามทั้ง 7 กล่องทุกกรณี

Reference model คือแผนที่ ไม่ใช่ตัวเครือข่าย

คำว่า reference model หมายถึงกรอบอ้างอิงสำหรับจัดความคิดและแบ่งหน้าที่ ไม่ใช่โปรแกรมหรือ protocol ตัวหนึ่งที่ติดตั้งแล้ว Internet จะทำงานขึ้นมาได้ OSI บอกว่า “ควรมองงานสื่อสารเป็นส่วนใดบ้าง” ส่วน protocol จริงบอกว่า “แต่ละส่วนแลกข้อมูลด้วยกติกาใด”

การแยกสองเรื่องนี้สำคัญ เพราะนักศึกษามักพูดว่า “เราใช้ OSI” ทั้งที่สิ่งที่ใช้งานจริงอาจเป็น Ethernet, IP, TCP และ HTTP เราใช้ OSI เป็นภาษาสำหรับอธิบายและวิเคราะห์ protocol เหล่านั้นมากกว่าใช้เป็น protocol stack ชุดเดียวตรง ๆ

เจ็ดชั้นของ OSI และคำถามที่แต่ละชั้นตอบ

ชื่อหน่วยข้อมูลในตารางเป็นคำที่ใช้กันทั่วไป ไม่ใช่กฎว่าทุก protocol ต้องเรียกเหมือนกันทั้งหมด ตัวอย่างเช่น UDP ใช้คำว่า datagram ขณะที่ TCP ใช้ segment การเข้าใจว่าแต่ละชั้นเติมและอ่านข้อมูลควบคุมใดสำคัญกว่าการจำชื่อ PDU แบบไม่ดูบริบท

อุปกรณ์แต่ละชนิดไม่ได้ประมวลผลครบทุกชั้นเท่ากัน

การบอกว่า “สามชั้นล่างทำงานบนทุก node” ง่ายเกินไป อุปกรณ์แต่ละแบบอ่านข้อมูลเท่าที่หน้าที่ของมันต้องใช้:

ตารางนี้เป็นภาพทั่วไป ไม่ใช่ข้อห้ามตายตัว Switch บางตัวทำ routing ได้ และ router บางตัวตรวจ application data เพื่อใช้นโยบาย security โลกจริงไม่ได้ขออนุญาตแผนภาพ OSI ก่อนเพิ่ม feature ใหม่เสมอครับ

2TCP/IP Reference Model — 4 Layers

TCP/IP ไม่ได้เริ่มจากการวาดโมเดลให้สมบูรณ์แล้วค่อยสร้าง protocol ตามทุกช่อง แต่พัฒนาจากสถาปัตยกรรมและชุด protocol ที่ต้องทำให้เครือข่ายต่างชนิดสื่อสารกันได้จริง โมเดลจึงสะท้อนสิ่งที่ใช้งานบน Internet มากกว่าการแยกหน้าที่ให้ละเอียดเท่า OSI

TCP/IP Model กับ TCP/IP Protocol Suite ไม่ใช่สิ่งเดียวกันเสียทีเดียว

TCP/IP model เป็นกรอบที่ใช้จัดกลุ่มหน้าที่เป็นชั้น ส่วน TCP/IP protocol suite คือชุด protocol จริง เช่น IP, TCP, UDP, ICMP, DNS และ HTTP มาตรฐาน Internet จำนวนมากพัฒนาผ่านกระบวนการของ IETF แต่ไม่ควรสรุปว่า IETF เป็นผู้วาด reference model 4 ชั้นขึ้นมาในลักษณะเดียวกับ OSI ของ ISO

จำนวนชั้นของ TCP/IP เองอาจพบทั้งแบบ 4 ชั้นและ 5 ชั้นในตำรา แบบ 4 ชั้นรวม physical ไว้กับ link ขณะที่แบบ 5 ชั้นแยก physical ออกมา การต่างกันหนึ่งชั้นไม่ได้หมายความว่าฝ่ายหนึ่งไม่รู้จริง แต่หมายถึงเลือกความละเอียดของแผนที่คนละระดับ

ARP เป็นตัวอย่างที่แสดงว่าการจับ protocol ใส่กล่องเดียวอาจไม่ลงตัว มันช่วยเชื่อม IP address กับ link-layer address ใน IPv4 จึงมักถูกวางไว้บริเวณรอยต่อระหว่าง Internet กับ Link Layer มากกว่าจะตอบได้เพียงคำเดียวว่า “อยู่ชั้นไหนแน่นอน”

TCP/IP มีความยืดหยุ่น แต่ไม่ได้แปลว่าไม่มีโครงสร้าง

บาง application หรือระบบสามารถใช้ raw IP หรือ protocol อื่นที่ไม่ผ่าน TCP/UDP แบบปกติได้ จึงไม่ควรใช้คำว่า “ทุก application ต้องผ่าน transport ตัวใดตัวหนึ่งเสมอ” อย่างไรก็ตาม application ทั่วไปยังใช้บริการ transport และ operating system ผ่าน socket API การมีข้อยกเว้นไม่ได้ทำให้แนวคิด layering หมดความหมาย

สิ่งที่ต่างคือ TCP/IP มักถูกอธิบายจาก protocol และการทำงานจริง จึงยอมรับความไม่เรียบร้อยของขอบเขตมากกว่า ในขณะที่ OSI เหมาะกับการแยกหน้าที่เพื่อการเรียนและการวิเคราะห์ ทั้งสองมุมช่วยกันมากกว่าหักล้างกัน

แผนภาพการจับคู่ชั้น (Layer Mapping)

การจับคู่ชั้นเป็นการเทียบหน้าที่ ไม่ใช่สมการหนึ่งต่อหนึ่ง

แผนภาพด้านบนมีประโยชน์สำหรับเริ่มต้น แต่คำว่า “TCP/IP Application เท่ากับ OSI 5+6+7” เป็นการย่อ ไม่ใช่สมการทางคณิตศาสตร์ หน้าที่ด้าน session, presentation และ application อาจกระจายอยู่ในหลาย library หรือ protocol และบางเทคโนโลยี เช่น TLS, QUIC, VPN หรือ proxy ก็ข้ามเส้นแบ่งที่สะอาดในตำรา

ดังนั้นเวลาเทียบโมเดล ควรถามว่า “หน้าที่นี้ถูกทำที่ใดในระบบจริง” แทนการถามเพียงว่า “อยู่ชั้นหมายเลขอะไร” หมายเลขช่วยหาตำแหน่ง แต่หน้าที่ช่วยอธิบายพฤติกรรม

3Internet Architecture: รูปทรงนาฬิกาทราย (Hourglass)

พลังของ Internet ไม่ได้มาจากการกำหนดทุกอย่างให้เหมือนกันตั้งแต่ application จนถึงสายสัญญาณ แต่มาจากการกำหนดจุดร่วมที่แคบพอให้เทคโนโลยีจำนวนมากมาเชื่อมต่อกันได้

สถาปัตยกรรม Internet มีลักษณะสำคัญดังนี้:

1. Application ด้านบนหลากหลาย — Web, Email, Streaming, IoT และระบบที่ยังไม่ถูกสร้างสามารถใช้โครงสร้างพื้นฐานร่วมกัน
2. มี IP เป็นเอวแคบ — ทุกฝ่ายตกลงใช้ datagram และ addressing ของ IP เป็นภาษากลางสำหรับส่งข้ามเครือข่าย
3. เทคโนโลยีด้านล่างหลากหลาย — Ethernet, Wi-Fi, fiber, cellular และ link ชนิดอื่นรองรับ IP ได้โดยไม่ต้องเข้าใจ application ทุกชนิด
4. เน้น specification และการทำงานร่วมกันจริง — วัฒนธรรม Internet ให้ความสำคัญกับเอกสารมาตรฐาน การทดลองใช้ และ interoperability ไม่ใช่เพียงแบบจำลองบนกระดาษ

ความเรียบง่ายตรงกลางเปิดพื้นที่ให้ความหลากหลายสองด้าน

หาก IP กำหนดรายละเอียดเฉพาะของทุก application เทคโนโลยีใหม่ด้านบนจะเกิดยาก เพราะต้องขอให้ส่วนกลางรู้จักมันก่อน หาก IP ผูกกับสื่อชนิดเดียว เครือข่ายใหม่ด้านล่างก็เข้าร่วมไม่ได้ง่าย Narrow waist จึงลดข้อตกลงร่วมให้เหลือเท่าที่จำเป็น

แต่ความเรียบง่ายมีต้นทุน IP แบบพื้นฐานให้บริการ best effort ไม่รับประกันว่า packet จะถึง เรียงลำดับ หรือมาทันเวลา ชั้นบนจึงต้องเติม reliability, security และ application semantics เองตามความต้องการ สิ่งที่ทำให้ Internet ยืดหยุ่น จึงเป็นสิ่งเดียวกับที่ผลักความรับผิดชอบบางส่วนไปยังปลายทาง

End-to-End Principle: งานบางอย่างควรให้ปลายทางตัดสิน

แนวคิดสำคัญของ Internet คือฟังก์ชันบางอย่างจะทำให้ถูกต้องครบถ้วนได้เมื่ออยู่ที่ปลายทาง เช่น การตรวจว่าไฟล์ทั้งชุดตรงกับต้นฉบับ แม้ link ทุกช่วงตรวจ error แล้ว ปลายทางยังควรตรวจผลรวมอีกครั้ง เพราะความผิดพลาดอาจเกิดในส่วนอื่นของเส้นทางได้

หลักนี้ไม่ได้บอกว่า network ภายในห้ามช่วยอะไร Link Layer อาจ retransmit และ router อาจจัด queue เพื่อคุณภาพบริการได้ แต่การช่วยด้านในไม่ควรถูกตีความว่าแทนการตรวจสอบ end-to-end ได้ทุกกรณี หน้าที่จึงอาจมีทั้งกลไกช่วยใกล้จุดเกิดเหตุและกลไกรับรองที่ปลายทาง

4Encapsulation — กลไกที่ทำงานเหมือนกันในทั้งสองโมเดล

แม้ OSI กับ TCP/IP แบ่งชั้นไม่เท่ากัน หลักการส่งข้อมูลลงผ่าน stack และเติมข้อมูลควบคุมของแต่ละชั้นยังเป็นภาพร่วมที่ใช้ทำความเข้าใจทั้งสองโมเดลได้

เมื่อข้อมูลถูกส่งจากชั้นบนลงล่าง แต่ละชั้นเติม header และบาง protocol อาจเติม trailer เพื่อห่อหุ้มข้อมูลจากชั้นบนไว้เป็น payload:

End host กับ router จัดการ encapsulation ไม่เหมือนกัน

ฝั่งรับที่เป็น end host ตรวจข้อมูลจากล่างขึ้นบน แต่ละชั้นอ่าน header ของตนและส่ง payload ให้ชั้นถัดไปจนถึง application กระบวนการนี้เรียกว่า decapsulation

Router ระหว่างทางรับ frame จาก link ขาเข้าและถอดกรอบของ link นั้นออกเพื่อเข้าถึง IP packet จากนั้นตรวจ IP header เลือกขาออก ปรับ field บางส่วนตาม protocol แล้วนำ packet ไปใส่ frame ใหม่ของ link ขาออก Router ไม่ได้ถอด transport และ application header เพื่อส่งให้ application ของตนในกรณี forwarding ปกติ และไม่ได้ “ถอด network header ทิ้ง” เหมือนปลายทางสุดท้าย

Overhead ไม่ได้สูญเปล่า หากมันทำหน้าที่ที่จำเป็น

Header ทำให้จำนวน byte ที่ส่งมากกว่า application data จริง จึงเป็น overhead ในด้านความจุ แต่ข้อมูลเหล่านี้ใช้ระบุ port, address, ลำดับ, ชนิด protocol หรือความถูกต้องของ frame หากตัด header ทุกอย่างทิ้ง เราอาจส่ง payload ได้มากขึ้นต่อ frame แต่ไม่มีใครรู้ว่าควรส่งให้ใครหรือประกอบกลับอย่างไร

โจทย์ที่เหมาะสมจึงไม่ใช่ “ทำอย่างไรให้ไม่มี overhead” แต่คือ “ข้อมูลควบคุมใดจำเป็น และควรมีมากเพียงใดเมื่อเทียบกับ payload” สำหรับ packet เล็ก header อาจกินสัดส่วนสูงมาก ขณะที่ไฟล์ขนาดใหญ่ถูกแบ่งเป็นหลาย packet แล้วต้นทุนกระจายออกไป

5ใช้โมเดลเพื่อวิเคราะห์ปัญหา ไม่ใช่เพียงท่องจำ

คุณค่าของ reference model ไม่ได้อยู่ที่ช่วยตอบว่า Ethernet อยู่ชั้น 2 หรือ TCP อยู่ชั้น 4 เท่านั้น แต่อยู่ที่ช่วยแยกขอบเขตของปัญหา ตั้งสมมุติฐาน และเลือกหลักฐานที่ควรตรวจต่อ

เริ่มจากอาการ แล้วค่อยหาว่ากลไกใดเกี่ยวข้อง

เมื่อผู้ใช้บอกว่า “เปิดเว็บไม่ได้” เราไม่ควรรีบตอบว่าเป็นปัญหา Network Layer เพราะคำว่า “เปิดเว็บ” ครอบตั้งแต่ Wi-Fi, IP, DNS, TCP/TLS ไปจนถึง HTTP และ server ของเว็บไซต์ โมเดลช่วยให้เราไล่คำถามเป็นช่วง ๆ แทนการเดาสุ่มจากชื่ออาการ

ตารางนี้ไม่ใช่สูตรว่าต้องตรวจจากล่างขึ้นบนเสมอ หากผู้ใช้เปิดด้วย IP ได้แต่เปิดด้วยชื่อไม่ได้ เราอาจเริ่มที่ DNS ทันที หากหลาย service บน server เดียวกันล่มพร้อมกัน เราอาจเริ่มจาก host หรือ network path สิ่งสำคัญคือใช้ชั้นเป็นกรอบจัดสมมุติฐาน ไม่ใช่ขั้นตอนพิธีกรรมที่ห้ามข้าม

Layer เดียวกันอาจมีทั้งปัญหา configuration, capacity และ failure

แม้ระบุชั้นได้แล้ว เรายังต้องแยกชนิดของปัญหา เช่น IP ติดต่อไม่ได้อาจเกิดจาก address ตั้งผิด ไม่มี route, firewall ปฏิเสธ, link ด้านล่างเสีย หรือเครือข่ายแออัดจน timeout การพูดว่า “ปัญหาอยู่ L3” จึงเป็นเพียงการบีบขอบเขต ไม่ใช่คำวินิจฉัยสุดท้าย

ในทางกลับกัน ปัญหาหนึ่งอาจแสดงผลหลายชั้นพร้อมกัน DNS ช้าทำให้ Web page ช้า TCP retransmission ทำให้ HTTP response ช้า และ CPU ของ server เต็มทำให้ client เห็น timeout แบบเดียวกับ packet loss การวิเคราะห์จึงต้องเชื่อมข้อมูลหลายระดับกลับเป็นเหตุการณ์เดียวกัน

อย่าถามเพียงว่าอยู่ชั้นไหน ให้ถามว่าใครตัดสินใจจากข้อมูลอะไร

คำถาม “อุปกรณ์นี้อยู่ layer ไหน” มีประโยชน์ในระดับเริ่มต้น แต่คำถามที่แม่นกว่าคือ อุปกรณ์อ่าน header ใด ใช้ field ใดตัดสินใจ เปลี่ยนข้อมูลส่วนใด และการตัดสินใจมีขอบเขตแค่หนึ่ง link หรือถึงปลายทาง

ตัวอย่างเช่น Layer-2 switch ใช้ MAC address ส่ง frame ภายใน LAN, router ใช้ IP prefix เลือก next hop, transport demultiplexing ใช้ port ส่งข้อมูลให้ process และ reverse proxy อาจอ่าน HTTP host หรือ path เพื่อเลือก backend ทั้งหมดทำหน้าที่ “ส่งต่อ” คล้ายกัน แต่ใช้ข้อมูลและขอบเขตคนละระดับ

6เลือกเส้นทางของคุณ

ยังเหลือบทนำร่วมอีก 2 เรื่องคือ Performance และ Socket API ก่อนแยกไปศึกษาแต่ละเส้นทางโดยละเอียด หากต้องการเห็นภาพครบก่อน แนะนำให้อ่านต่ออีกสองหน้า แต่หากมีพื้นฐานอยู่แล้วก็เลือกเส้นทางจากจุดนี้ได้:

แต่ละเส้นทางตอบคำถามคนละแบบ

เส้นทางเหล่านี้ไม่ได้พาไปคนละวิชา แต่พาไปดูระบบเดียวกันจากคนละจุดเริ่มต้น ผู้เรียนอาจเริ่มจากเส้นทางที่ถนัด แล้วกลับมาอ่านอีกเส้นทางเพื่อเติมมุมที่หายไปได้

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

สองบทสุดท้ายของบทนำร่วม

หลังจากรู้ว่าแต่ละชั้นทำอะไร คำถามต่อไปคือทำได้ดีเพียงใด บท Performance จะอธิบาย bandwidth, throughput, latency, delay, jitter และ loss ซึ่งทำให้คำว่า “เครือข่ายเร็ว” แตกออกเป็นตัวชี้วัดที่ตรวจสอบได้

จากนั้น Socket API จะเชื่อมแบบจำลองกลับเข้าสู่การเขียนโปรแกรม แสดงจุดที่ application ขอใช้ Transport Service จริง ทั้งสองบทจะทำให้ภาพจาก protocol stack ลงมาถึงประสบการณ์ของ programmer และผู้ใช้