arrow_backกลับไปที่บันทึกภาคสนาม
NETWORKING เผยแพร่แล้ว 8 Aug 2026

OSI Model ทีละ Layer ไม่มีเรื่องเหลวไหล

คำแนะนำเชิงปฏิบัติของ OSI model ทั้งเจ็ด layer พร้อมตัวอย่างโปรโตคอลจริง และมุมมองการแก้ไขปัญหาสำหรับแต่ละ layer

คำอธิบายเครือข่ายส่วนใหญ่มองว่า OSI model เหมือนแผนภูมิที่ต้องจดจำเพื่อสอบใบประกาศนียบัตร แล้วลืมไป นั่นเป็นความผิด เมื่อคุณเริ่มแก้ไขปัญหาจริง เจ็ด layer ก็กลายเป็นรายการตรวจสอบทางจิต: นี่คือปัญหาสายไฟ ปัญหา routing หรือ bug ของแอปพลิเคชัน การรู้ว่าคุณกำลังจัดการกับ layer ไหนจะลดเวลาการค้นหาข้อบกพร่องได้อย่างมาก

Layer 1: physical

นี่คือตัวกลางจริง: ทองแดง, เส้นใย, คลื่นวิทยุ ระดับแรงดันไฟฟ้า, ล็อคพิน, ประเภทตัวเชื่อม (RJ45, SFP+) และการมัลติเพล็กซ์สัญญาณอยู่ที่นี่ เมื่อพอร์ต switch แสดง "link down" หรือคุณได้รับการสูญเสีย packet เป็นช่วง ๆ ซึ่งสัมพันธ์กับการใช้เครื่องดูดฝุ่นใกล้เส้นสายไฟ คุณอยู่ในอาณาเขต Layer 1 เครื่องมือเช่น cable tester หรือ ethtool eth0 บน Linux จะแสดงสถานะลิงค์, ความเร็ว และการตั้งค่า duplex ก่อนที่คุณจะเสียเวลาในการดีบัก อะไรก็ตามที่อยู่ในสูงกว่านี้

Layer 2: data link

ที่นี่คุณได้ MAC address, switch, และ frame Ethernet ทำงานที่ layer นี้, เช่นเดียวกับ ARP (ในทางเทคนิคคือสะพานระหว่าง L2 และ L3) VLAN เป็น Layer 2 construct เช่นกัน หากโฮสต์ไม่สามารถเข้าถึงอะไรบน subnet ของตัวเอง แต่ ping ไปยังเครื่องอื่น ๆ ที่เชื่อมต่อโดยตรงได้ดี ให้ตรวจสอบ arp -a หรือ ip neigh สำหรับรายการเก่า และดูการตั้งค่าพอร์ต switch เพื่อหาความไม่ตรงกันของ VLAN ปัญหาคลาสสิก: โฮสต์สองตัวบน VLAN เดียวกัน แต่การตั้งค่า MTU ต่างกันทำให้เกิดอาการแปลก ๆ ที่เกี่ยวข้องกับการแบ่งส่วน

Layer 3: network

IP address, routing, และ ICMP อยู่ที่นี่ นี่คือที่ที่ traceroute และ ping ทำงาน และที่ที่คุณวินิจฉัยว่าแพ็กเก็ตออกจากเครือข่ายท้องถิ่นหรือไม่ Router ทำการตัดสินใจส่งต่อตาม destination IP ที่ layer นี้ เมื่อ ping 8.8.8.8 ทำงาน แต่ ping google.com ไม่ทำงาน นั่นไม่ใช่ปัญหา Layer 3 เลย มันคือ DNS ซึ่งเป็น Layer 7 — ตัวอย่างที่ดีว่าเหตุใดความเป็นระเบียบของ layer จึงมีความสำคัญเมื่อคุณกำลัง缩小ข้อบกพร่อง

Layer 4: transport

TCP และ UDP นี่คือที่ที่พอร์ต, ลำดับ, และความน่าเชื่อถือ (หรือขาดไป) เข้ามา TCP three-way handshake, retransmission timer, และ window scaling อยู่ที่นี่ หาก curl ค้างในการเชื่อมต่อ tcpdump -i eth0 port 443 จะแสดงให้คุณเห็นว่าแพ็กเก็ต SYN ได้รับ SYN-ACK กลับมาหรือไม่ ไม่มีการตอบสนองโดยทั่วไปหมายความว่า firewall กำลังลด traffic เงียบ ๆ แทนที่จะปฏิเสธแบบสุดชัด — ความแตกต่างที่สำคัญเมื่อคุณเขียนรายงานอุบัติเหตุ

Layer 5: session

Layer นี้มีชื่อเสียงที่ไม่ดีเพราะมันบาง ๆ ในทางปฏิบัติ — stack จำนวนมากในโลกจริงทำให้การจัดการ session ยุบตัวลงไปในไม่ว่าจะเป็น transport layer หรือ application layer ประวัติศาสตร์ TLS session resumption และสิ่งต่างๆเหมือน NetBIOS session เป็นตัวอย่างหนังสือเรียน ในสถาปัตยกรรมสมัยใหม่ คุณจะใช้เวลาน้อยกว่าที่นี่มากกว่า layer อื่น ๆ แต่มันยังมีประโยชน์ในแนวคิดเมื่ออธิบายว่าทำไมการเชื่อมต่อที่หลุดออกไปสามารถดำเนินการต่อได้โดยไม่ต้องเจรจาเรื่องใหม่อีกครั้ง

Layer 6: presentation

Encoding, compression, และ encryption formatting ในทางเทคนิคอยู่ที่นี่ — คิดถึง character set, SSL/TLS encryption formatting (เมื่อเทียบกับการจัดตั้ง session เอง) และ data serialization ในทางปฏิบัติ วิศวกรส่วนใหญ่พับสิ่งนี้เข้าไปในทั้ง Layer 5 หรือ Layer 7 เมื่อพวกเขาพูดถึงมัน เพราะขอบเขตไม่ชัดเจน หากคุณกำลัง debug อักขระที่บิดเบี้ยวในเพย์โหลดเทียบกับการ handshake ที่หัก นั่นคือการแยก L6/L7 ของคุณ

Layer 7: application

HTTP, DNS, SMTP, SSH — โปรโตคอลที่คุณเขียนโค้ดจริง ๆ ส่วนใหญ่ของการ debug ในแต่วัน ๆ ของนักพัฒนาเกิดขึ้นที่นี่ โดยตรวจสอบ status code, header และเพย์โหลด เครื่องมือนักพัฒนา browser, Postman และ curl -v ทั้งหมดทำงานที่ layer นี้ มันน่าสะทดสะเทือนที่จะโทษเครือข่ายก่อนเมื่อ API call ล้มเหลว แต่ 500 response หมายความว่าคำขอได้รับผ่านทุก layer ด้านล่างได้ดี — ปัญหาอยู่ในตรรมชาติที่สมบูรณ์ในตรรมชาติของตรรมชาติในตรรมชาติ

เหตุใดจึงต้องกังวลกับโมเดลที่ไม่มีใครนำไปใช้ตรง ๆ

เครือข่ายจริง โดยเฉพาะ TCP/IP ไม่ได้แมปอย่างสมบูรณ์กับ OSI เจ็ด layer — TCP/IP มีสี่ layer ในรูปแบบ reference ของตัวเอง ความไม่ตรงกันนั้นโอเค ค่า OSI ไม่ใช่สเปค implementation มันเป็นคำศัพท์ที่ใช้ร่วมกัน เมื่อเพื่อนร่วมงานพูดว่า "สิ่งนี้ดูเหมือนปัญหา Layer 2" คุณทั้งคู่ทราบทันทีว่าจะตรวจสอบ switch และ VLAN แทนที่จะโต้เถียงเกี่ยวกับ DNS record นั่นคือจุดประสงค์ทั้งหมดในการเรียนรู้อย่างถูกต้องแทนที่จะจดจำเพื่อสอบ

หากคำอธิบาย layer ต่อ layer นี้ติดใจ Korra Studio segment เครือข่ายไปเพิ่มเติมลงในการจับภาพแพ็กเก็ต, แบบฝึก subnetting และการแก้ไขปัญหา firewall rule ที่สร้างขึ้นโดยตรงจากพื้นฐานนี้

เขียนด้วยความช่วยเหลือของ AI ตรวจสอบและเผยแพร่โดย Michal Pilch (CISSP), Korra Studio

พร้อมที่จะไปต่อหรือไม่

นี่คือบันทึกหนึ่งจากฐานความรู้ของ Korra Studio — แพลตฟอร์มจับคู่หัวข้อแต่ละหัวข้อกับการฝึกสอนแบบ 1-to-1

เริ่มใช้งานฟรีarrow_forward