OSI Layer 3 of 7

Network Layer

พา packet ข้ามลิงก์และเครือข่ายหลายช่วงไปยังปลายทาง ด้วย addressing, forwarding และ routing โดยมี IP เป็นแกนกลางของ Internet

🔗
เทียบเท่าใน TCP/IP: Internet Layerอ่านฉบับกระชับ →

1บทบาทของ Network Layer ใน OSI

หน้าที่ตาม OSI
รับ packet จาก Transport Layer แล้วพาข้ามเครือข่ายหลายช่วงไปยังปลายทาง Network Layer จัดการ logical addressing, forwarding และ routing พร้อมเชื่อมลิงก์ที่ใช้เทคโนโลยีต่างกันให้ทำงานเป็น internetwork เดียวกัน

Data Link Layer ตอบคำถามว่า “บนลิงก์นี้จะส่ง frame ให้ node ถัดไปอย่างไร” ส่วน Network Layer ขยายขอบเขตเป็น “ถ้าปลายทางไม่ได้อยู่บนลิงก์นี้ packet ควรผ่าน router ตัวใดต่อ” Router ไม่จำเป็นต้องรู้รายละเอียดเส้นทางทั้งหมดของ packet ตั้งแต่ต้นจนจบในทุกกรณี มันเพียงอ่าน destination address ใช้ forwarding table เลือก next hop แล้วส่งต่อทีละช่วง

IP Address เหมือนที่อยู่ ส่วน MAC Address เหมือนป้ายส่งของช่วงปัจจุบัน

จดหมายมีที่อยู่บ้านปลายทางซึ่งยังคงเดิมระหว่างเดินทาง แต่รถที่ขนจดหมายเปลี่ยนทุกศูนย์ ใบงานของรถคันหนึ่งระบุเพียงว่าจะส่งให้ศูนย์ถัดไปตรงไหน IP address คล้ายที่อยู่ปลายทางระดับเครือข่าย ส่วน MAC address คล้ายข้อมูลส่งมอบบนลิงก์ปัจจุบัน

เมื่อ packet ผ่าน router Ethernet frame เดิมถูกแกะออก Router สร้าง frame ใหม่สำหรับ outgoing link โดย destination MAC มักเป็นของ next hop ไม่ใช่ host ปลายทางไกลออกไป การเรียก address ทั้งสองอย่างว่า “ที่อยู่เครื่อง” เหมือนกันจึงซ่อนขอบเขตที่สำคัญที่สุดไว้

สามคำที่ต้องแยกให้ชัด

คำหน้าที่ช่วงเวลาที่ทำงาน
Addressingตั้งชื่อหรือตำแหน่งเชิงโครงสร้างให้ interface หรือปลายทางทำให้ router เปรียบเทียบ destination กับ prefix ได้
Routingเรียนรู้หรือคำนวณว่าเครือข่ายใดควรเข้าถึงผ่านทางไหนControl plane สร้างข้อมูลเส้นทางจาก static config หรือ routing protocol
Forwardingใช้ตารางที่มีอยู่ตัดสิน packet แต่ละใบแล้วส่งออก interfaceData plane ทำซ้ำด้วยความเร็วสูงสำหรับ traffic จริง

Routing เปรียบเหมือนฝ่ายวางแผนเส้นทางที่อัปเดตแผนที่เมื่อถนนเปลี่ยน ส่วน forwarding คือพนักงานหน้าด่านที่อ่านป้ายของรถแต่ละคันแล้วชี้ช่องทางออก การคำนวณแผนที่อาจใช้เวลามากกว่า แต่การตัดสิน packet ต้องเร็วและเกิดขึ้นตลอดเวลา

Network Layer ไม่ได้ทำให้การส่งเชื่อถือได้โดยอัตโนมัติ
IP สามารถพา packet ข้ามหลายเครือข่ายได้ แต่บริการพื้นฐานเป็น best effort Packet อาจหาย ถูกทิ้งเมื่อ TTL หมด มาช้า หรือมาไม่เรียง การสร้างความน่าเชื่อถือ end-to-end เป็นหน้าที่ของ Transport protocol หรือ application ตามบริการที่เลือก

2Switching & Forwarding: Datagram vs Virtual Circuit

Datagram (Connectionless)

แนวคิดหลัก
ทุก packet บรรจุที่อยู่ปลายทางแบบสมบูรณ์ — switch ดูข้อมูลนี้เทียบกับ forwarding table เพื่อตัดสินใจ ส่งได้ทันทีไม่ต้อง setup, แต่ละ packet ตัดสินใจอิสระ (อาจเดินคนละเส้นทางกัน) ทนต่อ failure ได้ดี

คำว่า connectionless หมายถึงเครือข่ายไม่ต้องสร้าง per-flow connection state ตลอดเส้นทางก่อนส่ง packet แรก แต่ไม่ได้แปลว่าระบบไม่มี state เลย Router ยังมี forwarding table, neighbor state, queue และข้อมูลจาก routing protocols ส่วน application อาจใช้ TCP connection อยู่ด้านบนได้ Connectionless ของ IP กับ connection-oriented ของ TCP จึงอยู่คนละขอบเขตและอยู่ร่วมกันได้

แต่ละ datagram มี destination address พอให้ router ตัดสินใจแยกจาก packet อื่น ถ้า routing table เปลี่ยนกลางทาง packet ชุดเดียวกันอาจเดินคนละเส้น ทำให้ลำดับที่มาถึงเปลี่ยนได้ ความยืดหยุ่นนี้ช่วยให้เครือข่ายปรับเส้นทางเมื่อ topology เปลี่ยน แต่คำว่า “ทน failure” ไม่ใช่คำรับประกัน ถ้าไม่มีเส้นทางสำรองหรือ control plane ยัง converge ไม่ทัน packet ก็ยังหายได้

Virtual Circuit (Connection-Oriented)

VC Table Entry — 4 field
VCI (ระบุ connection เฉพาะที่ link นี้ — ไม่ใช่ global identifier มีความหมายแค่บน link เดียว), incoming/outgoing interface, outgoing VCI (อาจไม่เท่ากับ incoming)
ตัวอย่าง Walkthrough: A→S1→S2→S3→B
VCI: A→S1=5, S1→S2=11, S2→S3=7, S3→B=4 — packet วิ่งผ่านแต่ละ switch จะถูกเปลี่ยน VCI ในทุก hop ตามตาราง จนถึง B ด้วย VCI=4 ซึ่ง B รู้ว่ามาจาก A

VCI เป็น label ที่มีความหมายเฉพาะบนลิงก์หรือ interface หนึ่ง คู่ค่า incoming interface + incoming VCI จึงใช้ค้นหา outgoing interface + outgoing VCI การให้แต่ละช่วงเลือก label ของตนเองทำให้ header สั้นและจัดสรรค่าได้อิสระ แต่ switch ต้องเก็บ state ของ circuit และขั้น setup ต้องติดตั้ง state ให้ครบก่อน data เดินทาง

Datagram กับ Virtual Circuit — จดหมายกับสายพานที่จองไว้

Datagram คล้ายจดหมายแต่ละซองมีที่อยู่เต็ม ศูนย์คัดแยกอ่านแล้วเลือกทางใหม่ทุกครั้ง จดหมายสองฉบับถึงคนเดียวกันอาจผ่านคนละศูนย์ ส่วน virtual circuit คล้ายตั้งสายพานและหมายเลขงานไว้ล่วงหน้า เมื่อกล่องมาถึงแต่ละจุด พนักงานดู label สั้น ๆ แล้วรู้ทันทีว่าต้องเปลี่ยน label และส่งช่องไหน

แบบแรกกระจายการตัดสินใจไปกับ packet และไม่ต้อง setup แบบหลังยอมสร้าง state ก่อนเพื่อให้ forwarding และการจองทรัพยากรตาม circuit ทำได้ง่ายขึ้น ไม่มีแบบใดชนะทุกมิติ สิ่งที่ได้จากความยืดหยุ่นมักแลกกับ header หรือความยากในการรับประกัน ส่วนสิ่งที่ได้จาก state มักแลกกับการ setup และการกู้คืนเมื่อ state ขาด

ประเภท VCคำอธิบาย
PVC (Permanent)Administrator ตั้งค่าเอง อายุยาว
SVC (Switched)โฮสต์ส่ง signalling (setup message) เพื่อสร้างเองแบบ dynamic
ข้อดีของ VCข้อเสียของ VC
Header เล็กลง, รู้ล่วงหน้าว่ามีเส้นทางจริง, จองทรัพยากร/QoS ได้ล่วงหน้าต้องรอ RTT setup ก่อนส่งข้อมูล
link/switch ล่ม → ต้องสร้าง connection ใหม่ทั้งหมด

ATM (Asynchronous Transfer Mode) เป็นเครือข่ายแบบ VC เต็มรูปแบบ — หน่วยข้อมูลเรียก cell: header 5 byte + payload 48 byte (ขนาดคงที่ทำให้ switch ด้วย hardware ง่ายและขนานกันได้) มี 2 รูปแบบ header: UNI (host↔switch) และ NNI (switch↔switch)

ATM เป็นตัวอย่างเชิงประวัติที่ดีของการออกแบบด้วย fixed-size cell ขนาดเล็ก ช่วยจำกัดเวลาที่ cell หนึ่งขวาง traffic อื่นและเอื้อต่อ hardware switching แต่ payload 48 byte ทำให้ overhead สูงสำหรับข้อมูลก้อนใหญ่ และ application ต้องผ่าน ATM Adaptation Layer เพื่อแบ่งและประกอบข้อมูลกลับ ปัจจุบัน Internet ใช้ IP datagram เป็นหลัก แต่แนวคิด label switching และ traffic engineering ยังปรากฏในเทคโนโลยีอย่าง MPLS ซึ่งอยู่ระหว่างโลกของ IP forwarding กับ virtual-circuit-like forwarding

Routing Table กับ Forwarding Table ไม่จำเป็นต้องเป็นตารางเดียวกัน

Routing Information Base (RIB) เก็บเส้นทางที่ control plane เรียนรู้และเลือก ส่วน Forwarding Information Base (FIB) เป็นโครงสร้างที่เตรียมไว้ให้ data plane ค้นหาเร็ว เส้นทางหลายรายการใน RIB อาจแข่งขันกันก่อนเหลือ best route ที่ติดตั้งใน FIB และ FIB อาจใช้โครงสร้าง hardware เช่น TCAM เพื่อทำ longest-prefix lookup ด้วยความเร็วสูง การใช้คำว่า routing table แบบกว้าง ๆ พอได้ในบทนำ แต่เมื่อวิเคราะห์ระบบจริงควรแยกแหล่งความรู้กับสิ่งที่กำลังใช้ส่ง packet

3Routing: Distance Vector (Bellman-Ford)

แนวคิดหลัก
แต่ละ router เก็บค่าระยะทางไปยัง destination ที่รู้จัก พร้อม next hop แล้วแลกเปลี่ยน distance vector กับเพื่อนบ้านโดยตรงเป็นระยะหรือเมื่อมีการเปลี่ยนแปลงตาม protocol Router ไม่ต้องรู้ topology ทั้งหมด แต่คำนวณจากสิ่งที่เพื่อนบ้านบอกและ cost ของลิงก์ที่ไปหาเพื่อนบ้านนั้น
Bellman–Ford Relation
Dₓ(y) = minᵥ { c(x,v) + Dᵥ(y) }
ระยะจาก x ไป y = ค่าน้อยสุดของ (cost จาก x ไปเพื่อนบ้าน v + ระยะที่ v บอกว่าไป y)

ความเรียบง่ายของ Distance Vector อยู่ตรงที่ router รู้เพียงว่าเพื่อนบ้านแต่ละคนเสนอระยะเท่าไร ไม่ต้องเก็บแผนที่ทั้งเครือข่าย แต่ความไม่รู้ topology ก็เป็นต้นเหตุของปัญหา Router อาจเชื่อข้อมูลที่ท้ายที่สุดย้อนกลับมาจากตัวเองโดยไม่รู้ว่าเส้นทางนั้นเป็นวงรอบ

ถามทางจากเพื่อนบ้าน โดยไม่มีใครถือแผนที่ทั้งเมือง

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

ข่าวดีแพร่เร็วเพราะเส้นทางที่สั้นลงถูกเลือกทันที ส่วนข่าวร้ายต้องค่อย ๆ พิสูจน์ว่าทางเลือกที่เพื่อนเสนอไม่ได้วนกลับมา จึงเกิดคำว่า good news travels fast, bad news travels slowly

ตัวอย่าง Count-to-Infinity
Link A-E ล่ม แต่ B,C ยังโฆษณาไป E เป็น 2 hop (อ้อมผ่านกันเอง) → B สรุปว่าตัวเองไป E ได้ 3 hop → A สรุป 4 hop → C สรุป 5 hop → วนซ้ำจนถึงค่า "infinity"
วิธีแก้หลักการ
กำหนด Infinity ให้เล็กเช่น hop สูงสุดไม่เกิน 16
Split Horizonไม่ส่งเส้นทางที่เรียนมาจาก neighbor กลับไปหา neighbor นั้น
Split Horizon + Poison Reverseส่งกลับไปแต่ระบุ cost เป็น ∞ อย่างชัดเจน
ข้อจำกัด
Split horizon แก้ loop ระหว่างคู่ node 2 ตัวได้ดี แต่ไม่แก้ loop ที่เกิดจาก node 3 ตัวขึ้นไปทั้งหมด

Triggered update ช่วยให้ router ส่งข่าวการเปลี่ยนแปลงทันทีแทนรอรอบ periodic update ส่วน hold-down timer หรือแนวทางอื่นพยายามลดการรับข่าวที่ไม่น่าเชื่อถือในช่วง topology ยังไม่นิ่ง อย่างไรก็ตาม เทคนิคเหล่านี้ลดบางอาการ ไม่ได้เปลี่ยน Distance Vector ให้รู้ topology ทั้งหมด

RIP เป็นตัวอย่าง Distance Vector ที่ใช้ hop count และกำหนด 16 เป็น unreachable การเลือก infinity เล็กทำให้ count-to-infinity จบเร็วขึ้น แต่จำกัดเส้นผ่านศูนย์กลางเครือข่าย และ hop count มองทุกลิงก์เท่ากัน ต่อให้ลิงก์หนึ่งช้าและอีกลิงก์เร็ว เส้นทางที่ hop น้อยกว่าอาจยังถูกเลือก นี่แสดงว่า routing ไม่ได้หา “ทางดีที่สุด” จนกว่าเราจะนิยาม metric ก่อน

Convergence คือช่วงที่ Router กลับมาเห็นภาพสอดคล้องกัน

หลัง link ล่ม routing information ไม่เปลี่ยนพร้อมกันทั้งเครือข่าย ช่วง convergence router บางตัวรู้ข่าวแล้ว บางตัวยังใช้เส้นทางเก่า จึงเกิด packet loss, loop หรือเส้นทางอ้อมชั่วคราวได้ ความเร็ว convergence ขึ้นกับการตรวจพบ failure, timer, propagation ของ update, computation และการติดตั้ง FIB ไม่ใช่ routing algorithm เพียงบรรทัดเดียว

เส้นทางสั้นที่สุดยังไม่จำเป็นต้องดีที่สุด
Cost อาจแทน hop, delay, bandwidth, policy หรือค่าที่ administrator กำหนด Algorithm ทำเพียงหาค่าต่ำสุดตาม metric ที่ได้รับ ถ้า metric ไม่สะท้อนเป้าหมาย ผลลัพธ์อาจถูกทางคณิตศาสตร์แต่ผิดความต้องการของระบบ ปัญหาจึงอยู่ก่อน algorithm หนึ่งขั้นเสมอ: เรากำลัง optimize อะไร

4Internetworking และ IP Protocol

IP Service Model
Connectionless และ best effort — เครือข่ายพยายามส่ง datagram แต่ไม่รับประกันว่าจะถึง ถึงครั้งเดียว เรียงลำดับ หรือถึงภายในเวลาใด IP มี hierarchical addressing สำหรับ routing แต่ในโลกจริงยังมี private address, NAT, anycast และ address ที่ผูกกับ interface จึงไม่ควรเหมารวมว่า host ทุกตัวมี public address ไม่ซ้ำหนึ่งค่าตลอดเวลา

Best effort ไม่ได้แปลว่า router ทำงานแบบขอไปที Router ยังตรวจ header เลือก longest prefix ลด TTL จัด queue และพยายามส่งตามทรัพยากรที่มี ความหมายคือ service contract ไม่รับประกันผลลัพธ์ หาก queue เต็ม packet อาจถูกทิ้ง หากเส้นทางเปลี่ยน packet อาจมาผิดลำดับ และหากต้องการ reliability ต้องสร้างเพิ่มที่ชั้นบน

Best Effort เหมือนการส่งไปรษณีย์ธรรมดา
ระบบรับซองและพยายามส่งตามที่อยู่ แต่ไม่ได้จองรถเฉพาะ ไม่กำหนดเวลาถึง และไม่ได้โทรยืนยันทุกจุด ผู้ส่งอาจเพิ่มบริการลงทะเบียนหรือให้ผู้รับตอบกลับเอง เปรียบเหมือน TCP สร้าง reliability บน IP แต่ถ้า application เลือก UDP ก็ยอมรับบริการที่เบากว่าและจัดการสิ่งจำเป็นเอง
Field ใน IP Headerความหมาย
TTL (8 bit)นับ hop, ลดทุก hop, ถึง 0 ทิ้ง (กัน loop)
Protocol (8 bit)demux key (TCP=6, UDP=17)
Checksumครอบคลุมเฉพาะ header
Ident/Flags/Offsetใช้ในกระบวนการ fragmentation

อ่าน IPv4 Header ให้เป็นเหตุการณ์

Version บอกว่าจะตีความ header แบบ IPv4, IHL บอกความยาว header, Total Length บอกขนาด datagram, DSCP/ECN ใช้กับการจัดชั้นบริการและสัญญาณ congestion, TTL จำกัดอายุเชิง hop, Protocol บอก payload ชั้นบน และ Source/Destination Address ใช้ระบุปลายทางเชิง IP Field เหล่านี้ไม่ได้อยู่เพื่อให้ท่องตำแหน่ง แต่แต่ละตัวแก้ปัญหาในกระบวนการ forwarding หรือ demultiplexing

TTL ใน IPv4 มีชื่อมาจากเวลา แต่ router ใช้งานโดยลดอย่างน้อยหนึ่งต่อ hop ในทางปฏิบัติ ถ้าค่ากลายเป็นศูนย์ router ทิ้ง packet และโดยทั่วไปส่ง ICMP Time Exceeded กลับไป Traceroute ใช้พฤติกรรมนี้โดยตั้ง TTL เพิ่มทีละค่าเพื่อให้ router ตามทางตอบกลับ แต่ firewall, rate limit หรือ policy อาจทำให้บาง hop ไม่ตอบ จึงไม่ควรตีความเครื่องหมายดอกจันว่า router หายไปแน่นอน

IPv4 header checksum ครอบคลุมเฉพาะ header และต้องคำนวณใหม่เมื่อ TTL เปลี่ยน ส่วน TCP/UDP checksum มีขอบเขตอีกแบบและอาจครอบคลุม pseudo-header ด้วย การมี checksum หลายชั้นดูซ้ำซ้อน แต่แต่ละชั้นป้องกันขอบเขตและมีเงื่อนไขต่างกัน IPv6 ตัด header checksum ออกจาก base header เพื่อลดงาน forwarding และอาศัย error detection ที่ชั้นอื่นร่วมกับกลไกของ transport

IP Fragmentation
แต่ละลิงก์มี MTU ต่างกัน เช่น Ethernet ทั่วไปมักมี IP MTU 1,500 byte ใน IPv4 router อาจแบ่ง datagram เมื่อ outgoing MTU เล็กกว่าและไม่ได้ตั้ง DF ส่วนการประกอบกลับเกิดที่ host ปลายทางเท่านั้น สำหรับ IPv6 router ระหว่างทางไม่ทำ fragmentation และ IP ไม่มีกลไกกู้ fragment ที่หายด้วยตัวเอง

คำอธิบายนี้ใช้กับ IPv4 เมื่ออนุญาตให้ fragment หากตั้ง Don't Fragment (DF) แล้ว packet ใหญ่เกิน outgoing MTU router จะทิ้งและควรส่ง ICMP Fragmentation Needed กลับต้นทาง สำหรับ IPv6 router ระหว่างทางไม่ทำ fragmentation ต้นทางต้องใช้ Path MTU Discovery และ Fragment extension header เมื่อจำเป็น

Fragments ใช้ Identification เดียวกัน พร้อม Fragment Offset และ More Fragments flag เพื่อให้ปลายทางประกอบกลับ Offset นับเป็นหน่วย 8 byte จึงทำให้ fragment ที่ไม่ใช่ชิ้นสุดท้ายต้องมี payload สอดคล้องกับหน่วยดังกล่าว ถ้า fragment ชิ้นเดียวหาย datagram ทั้งก้อนไม่สมบูรณ์ และ transport อาจต้องส่งข้อมูลต้นฉบับใหม่ จึงควรหลีกเลี่ยง fragmentation เมื่อทำได้

ตัวอย่าง IPv4 Fragmentation

Datagram มี payload 4,000 byte และ IPv4 header 20 byte ต้องผ่านลิงก์ MTU 1,500 byte แต่ละ fragment บรรจุ payload ได้ไม่เกิน 1,480 byte ซึ่งหาร 8 ลงตัว

  • Fragment 1: payload 1,480, offset 0, MF=1
  • Fragment 2: payload 1,480, offset 185, MF=1
  • Fragment 3: payload 1,040, offset 370, MF=0

ทุก fragment มี header ของตนเอง จึงเพิ่ม overhead และแต่ละชิ้นถูก route แยกกันได้ การคำนวณต้องระวังว่า MTU รวม IP header ไม่ใช่พื้นที่ payload ล้วน

MTU Black Hole
ถ้าต้นทางส่ง packet ที่ตั้ง DF และใหญ่เกินทางผ่าน แต่ ICMP Fragmentation Needed ถูก firewall ทิ้ง ต้นทางอาจไม่รู้ว่าต้องลดขนาด ผลคือ packet เล็กผ่าน แต่ข้อมูลก้อนใหญ่ค้าง อาการดูเหมือน application แปลก ๆ ทั้งที่รากอยู่ตรงรอยต่อระหว่าง MTU กับการปิดกั้น control message
Forwarding Algorithm
if (NetworkNum ปลายทาง = NetworkNum ของ interface ใดของฉัน) then
    ส่งตรงถึงปลายทาง
else if (อยู่ใน forwarding table) then
    ส่งไปยัง NextHop router
else
    ส่งไปยัง default router

อัลกอริทึมข้างต้นเป็นภาพเริ่มต้น แต่ implementation จริงรวม connected routes ไว้ใน forwarding table และใช้ longest prefix match กับทุกกรณี รวมถึง default route 0.0.0.0/0 หากไม่มี prefix ใดตรงและไม่มี default route router จะทิ้ง packet และอาจส่ง ICMP Destination Unreachable ตามเงื่อนไข

Next Hop คือปลายทางของ Frame ช่วงนี้ ไม่ใช่ปลายทางสุดท้ายของ Packet

หลังเลือก outgoing interface และ next-hop IP แล้ว router ต้องหา link-layer address ของ next hop เช่นใช้ ARP สำหรับ IPv4 บน Ethernet จากนั้นสร้าง frame ใหม่ Destination IP ใน packet ยังเป็นปลายทางสุดท้าย แต่ destination MAC ใน frame เป็น next hop บน LAN นั้น ถ้า destination อยู่ directly connected next hop ก็คือ destination เอง

Longest Prefix Match — เลือกป้ายที่บอกทางได้เฉพาะเจาะจงที่สุด

ป้ายหนึ่งเขียนว่า “ภาคเหนือไปทางซ้าย” อีกป้ายเขียนว่า “เชียงใหม่ไปทางขวา” รถไปเชียงใหม่ตรงกับทั้งสองป้าย แต่ควรเลือกป้ายที่เจาะจงกว่า Prefix /24 จึงชนะ /16 เมื่อ destination ตรงทั้งคู่ ส่วน default route /0 เหมือนป้าย “ที่อื่นไปทางนี้” ใช้เมื่อไม่มีป้ายเฉพาะกว่า

CIDR — Classless Inter-Domain Routing

ปัญหา Efficiency (ตัวอย่างคำนวณ)
2 โฮสต์ใน class C → efficiency = 2/255 ≈ 0.78% / 256 โฮสต์ใน class B → 256/65535 ≈ 0.39% — ถ้าแจก 16×class C แทน class B เดียว: storage efficiency = 16×255/65536 ≈ 6.2% (แต่ routing table ใหญ่กว่ามาก)

ตัวอย่าง classful ด้านบนสะท้อนปัญหาในอดีต แต่จำนวน host ที่ใช้งานได้ตามกฎ subnet ทั่วไปมักหัก network และ broadcast address จึงไม่ควรใช้ 255 หรือ 65,535 เป็นจำนวน usable hosts โดยไม่บอกสมมุติฐาน ประเด็นหลักคือ class A/B/C บังคับขนาดก้าวใหญ่เกินไป ทำให้ผู้ต้องการ address ระหว่างขนาดได้รับบล็อกใหญ่เกินจำเป็น และการแจกหลาย class C แก้ waste บางส่วนแต่ทำให้ routing table โต

หลักการ CIDR
แจก address เป็นบล็อกต่อเนื่อง แล้ว aggregate เป็น 1 entry เช่น 192.4.16–192.4.31 → 20-bit prefix เดียว 192.4.16/20 — เมื่อ prefix ทับซ้อนกัน ใช้กฎ longest prefix match

Prefix length /n หมายถึง n บิตแรกเป็นส่วนที่ใช้จับคู่เครือข่าย ที่เหลือเป็นพื้นที่ address ภายในบล็อก บล็อก /24 มี 2⁸ = 256 addresses ส่วน /20 มี 2¹² = 4,096 addresses การหาขอบเขตทำได้ด้วย bitwise AND ระหว่าง IP address กับ subnet mask

ตัวอย่าง Subnet และ Host Range

192.168.10.77/26 มี mask 255.255.255.192 ขนาดบล็อกใน octet สุดท้ายเท่ากับ 64 ช่วงที่ครอบ 77 คือ 64–127

  • Network address: 192.168.10.64
  • Broadcast address: 192.168.10.127
  • Usable host ตาม subnet IPv4 ทั่วไป: .65–.126 รวม 62 ค่า

กฎการหักสอง address มีข้อยกเว้น เช่น point-to-point /31 ตามมาตรฐานที่เกี่ยวข้อง และ host route /32 จึงควรรู้ทั้งกฎทั่วไปและบริบท ไม่เปลี่ยนกฎจำให้กลายเป็นกฎธรรมชาติ

Aggregation ช่วยได้เมื่อ Address ถูกจัดสรรให้ต่อเนื่อง

ISP สามารถประกาศ prefix ใหญ่หนึ่งรายการแทน prefix ย่อยจำนวนมาก หากบล็อกของลูกค้าอยู่ต่อเนื่องและใช้เส้นทางร่วมกัน แต่ถ้าองค์กร multihoming หรือย้าย provider แล้วยังต้องประกาศ prefix เฉพาะ เส้นทางเจาะจงอาจทำให้ aggregation แตก Longest prefix match ทำให้ route เฉพาะชนะ aggregate ได้ ซึ่งยืดหยุ่นแต่เพิ่มขนาด global routing table

CIDR แก้สองเรื่องที่เชื่อมกัน แต่ไม่ใช่เรื่องเดียวกัน
Variable-length prefix ช่วยจัดสรร address ใกล้กับขนาดที่ต้องใช้ ส่วน route aggregation ช่วยรวมหลาย prefix เป็นประกาศเดียว ทั้งสองอาศัย prefix แต่การแบ่ง subnet ละเอียดขึ้นอาจกลับเพิ่มจำนวน route ภายในระบบได้ ประหยัด address กับลดตารางจึงต้องออกแบบร่วมกัน ไม่ได้ดีขึ้นพร้อมกันทุกครั้ง
โปรโตคอลเสริมหน้าที่
ARPหา link-layer address ของ IPv4 next hop บน local link โดย request มักเป็น broadcast และ reply มักเป็น unicast ไม่ใช่ระบบแปลสองทางทั่วไป
DHCPแจก address และค่าตั้งเครือข่าย เช่น prefix, default gateway และ DNS server; relay ช่วยข้าม subnet ไปหา server
ICMPส่ง control/error information เช่น destination unreachable, time exceeded และ echo request/reply แต่มีข้อห้ามและ policy ว่าเมื่อใดไม่ควรส่ง error ซ้อน

ARP ทำงานเฉพาะขอบเขต Local Link

Host ไม่ broadcast ARP ข้าม router เพราะ broadcast ระดับ Ethernet ถูกจำกัดใน LAN ถ้าปลายทางอยู่นอก prefix host ARP หา default gateway แล้วส่ง frame ให้ gateway Proxy ARP เป็นกรณีพิเศษที่อุปกรณ์ตอบแทน address อื่น แต่ไม่ควรใช้เป็นภาพพื้นฐานว่า ARP เดินข้าม network ได้

ARP cache ลดการ broadcast ซ้ำแต่ข้อมูลหมดอายุได้ และ ARP ไม่มี authentication ดั้งเดิม ผู้โจมตีจึงอาจส่งข้อมูลปลอมเพื่อเปลี่ยน mapping กลไกอย่าง Dynamic ARP Inspection อาศัยข้อมูลที่เชื่อถือได้จากระบบอื่นช่วยตรวจ แต่การรักษาความปลอดภัยไม่ได้เกิดจาก ARP เอง

DHCP ไม่ได้มีหน้าที่แจก IP เพียงค่าเดียว

Client ที่ยังไม่มี address ใช้ข้อความ discovery และ request เพื่อขอ lease พร้อม option ต่าง ๆ การสื่อสารระยะแรกใช้ broadcast เพราะ client ยังไม่รู้ server และยังตั้ง network ไม่ครบ DHCP relay รับ broadcast ใน subnet แล้วส่งต่อแบบ unicast ไป server พร้อมข้อมูลว่าคำขอมาจากเครือข่ายใด Server จึงเลือก pool ได้ถูกต้อง

Lease ทำให้ address ถูกนำกลับมาใช้และเปลี่ยนได้ ตัวตนของเครื่องจึงไม่ควรถูกผูกกับ IPv4 address แบบถาวร Log ที่ต้องติดตามเหตุการณ์ควรเก็บเวลา lease, client identifier และข้อมูลอื่นประกอบ มิฉะนั้นคำว่า “IP นี้คือเครื่องใคร” อาจตอบผิดเมื่อถามคนละเวลา

ICMP เป็นส่วนช่วยให้ IP อธิบายสิ่งที่เกิดขึ้น

ICMP ไม่ได้ทำให้ IP reliable แต่ช่วยรายงานเงื่อนไขบางอย่าง เช่นไม่มี route, port unreachable, TTL หมด หรือ packet ใหญ่เกิน MTU ข้อความ ICMP เองก็ส่งผ่าน IP และอาจหายได้ รวมทั้งถูก rate-limit หรือ firewall กรอง การไม่ได้ ICMP กลับมาจึงไม่พิสูจน์ว่าไม่มีปัญหา

Router ที่พบ IPv4 header checksum ผิดโดยทั่วไปทิ้ง packet โดยไม่ส่ง ICMP error เพราะ source address ใน header ที่เสียอาจไม่น่าเชื่อถือ และกติกา ICMP ยังหลีกเลี่ยงการส่ง error ตอบ ICMP error บางประเภท, broadcast/multicast บางกรณี หรือ fragment ที่ไม่ใช่ชิ้นแรก เพื่อไม่ให้ error สร้าง error ต่อเป็นลูกโซ่

ICMP เหมือนจดหมายตีกลับ ไม่ใช่ระบบติดตามแบบรับประกัน
ที่ทำการไปรษณีย์อาจส่งซองกลับมาว่าไม่มีที่อยู่นี้หรือเส้นทางใช้ไม่ได้ แต่ซองแจ้งเตือนเองก็อาจหาย และบางกรณีไปรษณีย์เลือกไม่ตอบเพื่อไม่สร้างภาระเพิ่ม Ping จึงเป็นเครื่องมือหนึ่ง ไม่ใช่ผู้พิพากษาว่าเครื่อง “เป็น” หรือ “ตาย”

5Link State Routing และ Dijkstra's Algorithm

ต่างจาก Distance Vector อย่างไร
Router แต่ละตัวค้นหาเพื่อนบ้านและ cost ของลิงก์ที่ตนต่อโดยตรง แล้ว flood link-state information ให้ router อื่นในขอบเขต routing เดียวกัน ทุกตัวจึงสร้าง link-state database ที่ควรสอดคล้องกันและคำนวณ shortest-path tree ของตนเอง ไม่ได้ส่ง forwarding table ทั้งชุดให้ทุกคนโดยตรง

Link State ยอมจ่ายค่าเก็บ topology และคำนวณมากขึ้น เพื่อให้แต่ละ router เห็นแผนที่แทนการเชื่อคำบอกระยะจากเพื่อนบ้านเพียงอย่างเดียว Reliable flooding ต้องจัดการ duplicate, ลำดับข้อมูล และอายุของประกาศ Sequence number ช่วยแยกข้อมูลใหม่จากเก่า ส่วน age/TTL ช่วยให้ state ที่เจ้าของหายไปไม่ค้างตลอดกาล

Distance Vector บอกระยะ ส่วน Link State แจกชิ้นส่วนแผนที่
แบบแรกเพื่อนบอกว่า “ผ่านฉันไปมหาวิทยาลัย 5 กิโลเมตร” เราไม่เห็นว่าทางข้างในผ่านอะไร แบบหลังทุกแยกประกาศว่าตนต่อกับถนนใดและมี cost เท่าไร เมื่อทุกคนได้ประกาศครบจึงประกอบเป็นแผนที่และคำนวณทางเอง ข้อมูลมากขึ้น แต่ตรวจเหตุผลของเส้นทางได้ชัดกว่า
Dijkstra's Algorithm (non-negative weight)
N' = {s}; D(v) = c(s,v) สำหรับทุก v
เลือก w ∉ N' ที่ D(w) ต่ำสุด; เพิ่ม w ลง N'; แล้ว D(v)=min(D(v), D(w)+c(w,v))

Dijkstra ใช้ได้เมื่อ edge weight ไม่เป็นลบ ซึ่งสอดคล้องกับ metric routing ทั่วไป หลังคำนวณ shortest-path tree จากตนเองเป็น root Router แปลงเส้นทางไปแต่ละ prefix เป็น next hop และติดตั้งใน RIB/FIB การมี topology เหมือนกันไม่ได้แปลว่าทุก router มี shortest-path tree เหมือนกัน เพราะแต่ละตัวใช้ตนเองเป็นจุดเริ่ม

เดิน Dijkstra โดยไม่กระโดดขั้น
  1. ตั้งระยะของ source เป็น 0 และ node อื่นเป็น ∞ ยกเว้นเพื่อนบ้านที่มี direct cost
  2. เลือก node ชั่วคราวที่ระยะต่ำสุดเป็นค่าถาวรถัดไป
  3. Relax edge จาก node นั้น ถ้าทางผ่านมันสั้นกว่าค่าเดิมให้อัปเดต distance และ predecessor
  4. ทำซ้ำจนได้ destination ที่ต้องการหรือทุก node ที่เข้าถึงได้ถูกเลือก

ข้อผิดพลาดที่พบบ่อยคืออัปเดตจาก node ที่ยังไม่ได้ถูกเลือกเป็นค่าต่ำสุด หรือเลือกจากค่า edge โดยตรงแทน cumulative cost ตารางทุกแถวควรบอกทั้งระยะปัจจุบันและ predecessor เพื่อย้อนสร้าง path ได้

OSPF เป็น Interior Gateway Protocol แบบ link state ภายใน Autonomous System ใช้ Link-State Advertisement หลายชนิดและแบ่งเครือข่ายเป็น area เพื่อลดขอบเขต flooding และ computation Area 0 เป็น backbone สำหรับการเชื่อม area ตามสถาปัตยกรรม OSPF ส่วนการแลกเส้นทางระหว่าง AS เป็นอีกขอบเขตและมักใช้ BGP ซึ่งตัดสินด้วย policy มากกว่าหา shortest path แบบ Dijkstra เพียงอย่างเดียว

Equal-Cost Multi-Path และเหตุผลที่เส้นทางอาจมีมากกว่าหนึ่ง

ถ้ามีหลาย next hop ที่ cost เท่ากัน router อาจติดตั้ง Equal-Cost Multi-Path (ECMP) แล้วกระจาย flow ตาม hash เพื่อใช้หลายลิงก์ การแบ่งต่อ packet อาจทำให้ packet ใน flow เดียวมาผิดลำดับ ระบบจึงมักรักษา flow เดียวไว้บน next hop เดิมตราบเท่าที่ topology ไม่เปลี่ยน Hash ที่ไม่สมดุลยังทำให้บางลิงก์แน่นแม้ capacity รวมเหลืออยู่ จึงต้องแยก “มีหลายทาง” ออกจาก “แบ่งโหลดได้พอดี”

Shortest Path ไม่ได้แปลว่า Traffic จะไม่ติด
Dijkstra ใช้ static metric ณ เวลาหนึ่ง เส้นทาง cost ต่ำสุดอาจดึง flow จำนวนมากมารวมกันจน queue สูง การเปลี่ยน metric ตาม congestion เร็วเกินไปกลับทำให้เส้นทางแกว่งได้ Routing stability กับ load adaptation จึงเป็นข้อแลกเปลี่ยน ไม่ใช่แค่เพิ่มสูตรวัด traffic แล้วทุกอย่างจะดีขึ้น

6IPv6 และ NAT — สองคำตอบต่อข้อจำกัดของ IPv4 ที่ต่างกัน

IPv6 ขยาย Address Space และปรับโครงสร้าง Header

IPv6 ใช้ address 128 บิต เขียนเป็นกลุ่ม hexadecimal แปดกลุ่มและย่อเลขศูนย์ตามกติกาได้ การมี address มากขึ้นไม่ใช่ประโยชน์เดียว Base header ถูกทำให้มีรูปแบบคงที่ 40 byte ตัด header checksum ออก ย้ายข้อมูลเสริมไป extension headers และให้ router ระหว่างทางไม่ fragment packet การออกแบบพยายามทำให้ forwarding path เรียบง่ายขึ้น แม้ระบบทั้งหมดจะยังซับซ้อนจาก extension และ policy

แนวคิดIPv4IPv6
Address length32 บิต128 บิต
Broadcastมี broadcast addressไม่มี broadcast ใช้ multicast ตามหน้าที่
Neighbor resolutionARPNeighbor Discovery ผ่าน ICMPv6
FragmentationRouter อาจ fragment เมื่อ DF ไม่ถูกตั้งRouter ไม่ fragment ต้นทางจัดการตาม Path MTU
Header checksumมีใน IPv4 headerไม่มีใน IPv6 base header

IPv6 address มีหลาย scope เช่น link-local, global unicast, multicast และ loopback Link-local ถูกสร้างบน interface และใช้สื่อสารในลิงก์เดียว รวมถึงงานของ Neighbor Discovery และ routing protocol บางส่วน การมี IPv6 address หลายค่าบน interface เดียวเป็นเรื่องปกติ จึงไม่ควรถามหา “IP ของเครื่อง” เหมือนต้องมีคำตอบเดียว

IPv6 ไม่ใช่เพียงบ้านเลขที่ยาวขึ้น
ถ้าเมืองขยายจากหมื่นหลังเป็นจำนวนมหาศาล เราไม่ได้แค่เพิ่มหลักให้บ้านเลขที่ แต่ต้องคิดวิธีประกาศเขต หาเพื่อนบ้าน และจัดเอกสารส่งต่อใหม่ IPv6 จึงเปลี่ยนทั้ง address space และกระบวนการรอบข้างบางส่วน การเอา IPv4 address ไปเติมศูนย์ให้ยาวขึ้นไม่ใช่การ migrate

NAT ช่วยประหยัด Public IPv4 แต่เปลี่ยน End-to-End Model

Network Address Translation แก้ไข address และมักแก้ port เมื่อ packet ผ่านขอบเขต ทำให้ host private หลายตัวใช้งาน public IPv4 ร่วมกันได้ PAT/NAPT เก็บ mapping ระหว่าง tuple ฝั่งในกับ tuple ฝั่งนอก Return traffic ต้องตรงกับ state หรือ rule จึงย้อนกลับถูกเครื่อง

NAT ชะลอการขาดแคลน IPv4 และซ่อนโครงสร้าง address ภายในบางส่วน แต่ไม่ใช่ firewall โดยตัวมันเอง และทำให้ inbound connection, peer-to-peer, protocol ที่ฝัง address ใน payload, IPsec บางโหมด และ troubleshooting ซับซ้อนขึ้น Application ใช้ STUN, TURN, ICE, port forwarding หรือ relay เพื่อเดินผ่านข้อจำกัดตามกรณี

Private ไม่ได้แปลว่าปลอดภัย และ Public ไม่ได้แปลว่าเปิดทุกอย่าง
Private address บอกว่าไม่ถูก route บน public Internet ตามข้อตกลง ไม่ได้ authenticate ผู้ใช้หรือเข้ารหัสข้อมูล ส่วน public address อาจอยู่หลัง firewall ที่ปิดทุก inbound flow ความปลอดภัยขึ้นกับ policy และ control ที่ใช้งาน ไม่ใช่ชนิด address เพียงคำเดียว

7Routing ใน Ad Hoc Network

Ad hoc network ไม่มีโครงสร้างพื้นฐานคงที่ โหนดอาจเป็นทั้งปลายทางและตัวส่งต่อ ลิงก์เกิดหรือหายตามการเคลื่อนที่ กำลังสัญญาณ และพลังงานที่เหลือ Routing protocol จึงต้องแลกความสดของเส้นทางกับ overhead ถ้าอัปเดตทั้งเครือข่ายตลอดเวลา route จะสดแต่กิน bandwidth และแบตเตอรี่ ถ้ารอจนต้องใช้ค่อยค้นหา packet แรกต้องรอ route discovery

Reactive routing เช่นแนวคิดใน AODV ใช้ Route Request กระจายออกไปเมื่อยังไม่มีเส้นทาง โหนดบันทึก reverse path และปลายทางหรือโหนดที่มีข้อมูลเหมาะสมส่ง Route Reply กลับ ส่วน Route Error แจ้งเมื่อทางขาด Proactive routing พยายามรักษาตารางล่วงหน้า จึงส่งได้เร็วเมื่อมีข้อมูลแต่จ่าย overhead แม้เส้นทางไม่ได้ใช้งาน ยังมี hybrid approach ที่ผสมตามขอบเขต

ขบวนคนเดินป่าที่สมาชิกเคลื่อนตลอดเวลา
ถ้าทุกคนรายงานตำแหน่งให้ทุกคนทุกวินาที แผนที่สดแต่แบตเตอรี่หมดเร็ว ถ้าจะถามทางเฉพาะตอนต้องส่งของ ข่าวแรกต้องตะโกนหากันก่อน Ad hoc routing ไม่ได้เพียงหา shortest path แต่ต้องคิดว่าค่าใช้จ่ายของการรักษาแผนที่คุ้มกับ traffic จริงหรือไม่

Route metric อาจรวม hop count, link quality, expected transmission count, energy หรือความเสถียร เส้นที่สั้นแต่หลุดบ่อยอาจแพงกว่าเส้นอ้อมที่เชื่อถือได้ Mobility ยังทำให้ route ที่คำนวณเสร็จอาจหมดอายุก่อนใช้ ดังนั้น convergence ใน ad hoc network ไม่ใช่เหตุการณ์เฉพาะตอนอุปกรณ์เสีย แต่เป็นสภาวะปกติของ topology ที่เปลี่ยนอยู่ตลอด

8Routing ระหว่างองค์กร: เมื่อ Policy สำคัญกว่าระยะสั้นที่สุด

Distance Vector และ Link State ช่วยสร้างภาพ routing ภายในองค์กรหรือ Autonomous System แต่ Internet เชื่อมเครือข่ายที่มีเจ้าของต่างกัน แต่ละฝ่ายมีต้นทุน สัญญาทางธุรกิจ ความปลอดภัย และนโยบายของตน เส้นทางที่สั้นที่สุดเชิง hop จึงอาจไม่ใช่เส้นทางที่องค์กรยอมใช้ การ routing ระหว่าง AS ใช้ BGP ซึ่งเป็น path-vector protocol และเลือก route จาก attribute กับ policy หลายขั้น ไม่ได้ใช้ Dijkstra บนแผนที่ Internet ทั้งโลก

ถนนที่ใกล้ที่สุดอาจผ่านประเทศที่เราไม่มีสิทธิ์ผ่าน
แผนที่บอกว่าทางหนึ่งสั้นกว่า แต่บริษัทขนส่งอาจไม่มีสัญญาใช้ด่านนั้น หรือการส่งผ่านคู่แข่งมีต้นทุนสูงกว่า Routing ระหว่างองค์กรจึงไม่ใช่โจทย์เรขาคณิตล้วน ๆ Policy สามารถชนะระยะทาง เพราะเครือข่ายไม่ได้มีเจ้าของคนเดียว

Autonomous System และ BGP Route

Autonomous System คือกลุ่มเครือข่ายภายใต้นโยบาย routing ร่วมกันและมี Autonomous System Number BGP speaker แลก prefix reachability พร้อม path attribute เช่น AS_PATH, NEXT_HOP, LOCAL_PREF และ MED แต่ละองค์กร import route แล้วใช้นโยบายปรับหรือกรอง จากนั้น export เฉพาะสิ่งที่ยอมประกาศให้เพื่อนบ้าน

Attribute/แนวคิดช่วยตอบคำถามอะไร
AS_PATHประกาศนี้ผ่าน AS ใดมา ใช้ช่วยป้องกัน loop และเป็นส่วนหนึ่งของ route selection
LOCAL_PREFภายใน AS ต้องการให้ออกทางไหน ค่าสูงกว่ามักถูกชอบตามกระบวนการทั่วไป
MEDเสนอให้อีก AS เลือกจุดเข้าทางใดภายใต้เงื่อนไขการเปรียบเทียบของ BGP
Communitiesติดป้าย route เพื่อให้นโยบายกลุ่มหนึ่งจัดการได้สะดวก
Longest Prefix Matchหลัง route ถูกเลือกและติดตั้งแล้ว data plane ยังเลือก prefix ที่เจาะจงที่สุดสำหรับ packet

คำว่า best path ใน BGP จึงหมายถึงเส้นทางที่ชนะตาม decision process และ policy ไม่ใช่หลักฐานว่า delay ต่ำสุดหรือ bandwidth สูงสุด ผู้ดูแลอาจเลือก provider ราคาถูกสำหรับ outbound traffic แต่ inbound traffic ถูกควบคุมได้ทางอ้อมผ่านสิ่งที่ประกาศและ attribute ที่อีกฝ่ายอาจเคารพหรือไม่ก็ได้ Routing ไปกับ routing กลับจึงไม่จำเป็นต้องสมมาตร

Route Advertisement คือคำกล่าวอ้างที่ต้องตรวจสอบ

ถ้า AS ประกาศ prefix ผิด ไม่ว่าจะจากการตั้งค่าพลาดหรือเจตนา traffic อาจถูกดึงไปผิดทาง เกิด route leak หรือ prefix hijack ได้ กลไกอย่าง prefix filtering, max-prefix, RPKI Route Origin Validation และการติดตาม announcement ช่วยลดความเสี่ยง แต่ไม่ได้ทำให้ทุก policy ถูกต้องโดยอัตโนมัติ

RPKI ROA ช่วยบอกว่า AS ใดได้รับอนุญาตให้ originate prefix ตามข้อมูลที่ลงทะเบียนไว้ แต่ไม่ได้ยืนยัน AS_PATH ทั้งเส้นในรูปพื้นฐาน การเห็น route เป็น RPKI-valid จึงตอบเรื่อง origin authorization ไม่ใช่ใบรับรองว่าเส้นทางทั้งหมดปลอดภัยหรือดีที่สุด ความปลอดภัยของ routing ต้องแยก claim แต่ละระดับออกจากกัน

Routing Protocol คำนวณจากข้อมูลที่ได้รับ
Algorithm อาจทำงานถูกต้องทุกบรรทัด แต่ถ้า input เป็น route ที่ประกาศผิด ผลลัพธ์ก็พา traffic ผิดทางได้ ความถูกต้องของ computation กับความน่าเชื่อถือของข้อมูลเป็นคนละเรื่อง เหมือนเครื่องคิดเลขตอบเลขได้ตรง แต่ไม่รู้ว่าตัวเลขตั้งต้นมาจากใคร

9Queue, Congestion และสิ่งที่เกิดขึ้นระหว่าง Forwarding

ภาพพื้นฐานมักวาด router รับ packet แล้วส่งออกทันที แต่ถ้า packet เข้าหลาย interface พร้อมกันและต้องออก interface เดียวกัน อัตราขาเข้ารวมอาจสูงกว่า link rate ขาออก Packet จึงต้องรอใน queue เมื่อ buffer เต็ม router ต้องทิ้งบาง packet นี่คือจุดที่ Network Layer เชื่อมกับ performance และ congestion control

Router เหมือนด่านรวมถนนหลายเลน
รถจากถนนสามสายมุ่งออกสะพานเลนเดียว ต่อให้เจ้าหน้าที่อ่านป้ายและเลือกทางได้ถูก รถก็ยังต่อคิว ปัญหาไม่ได้เกิดจากไม่รู้เส้นทาง แต่เกิดจากความต้องการใช้ทางออกมากกว่าความจุ การเพิ่มป้ายจึงไม่แก้รถติด ต้องจัด queue, เพิ่ม capacity, กระจายเส้นทาง หรือให้ต้นทางลดอัตรา

Buffer ช่วยรับความผันผวน แต่สร้าง Delay ได้

Buffer ดูดซับ traffic burst ชั่วคราว ทำให้ packet ไม่ถูกทิ้งทันที แต่ buffer ใหญ่มากไม่ได้ดีเสมอ เมื่อ queue สะสม packet จำนวนมาก latency พุ่งและ flow ที่ต้องการ feedback รอช้าลง ปรากฏการณ์ bufferbloat ทำให้เครือข่ายมี throughput ดูสูงแต่ interactive application หน่วงมาก การออกแบบจึงต้องสมดุลระหว่าง loss กับ queueing delay

กลไกบทบาทข้อแลกเปลี่ยน
Tail Dropรับจน queue เต็มแล้วทิ้ง packet ใหม่ง่าย แต่อาจทำให้หลาย flow ลดพร้อมกันและ queue ค้างเต็ม
AQMส่งสัญญาณหรือทิ้งก่อน buffer เต็มตามภาวะ queueลด latency และเตือน congestion เร็วขึ้น แต่ต้องตั้งและเลือก algorithm เหมาะสม
ECNMark packet แทนทิ้งเมื่ออุปกรณ์และ endpoint รองรับรักษาข้อมูลไว้แต่ต้องมีการตอบสนองจาก transport และนโยบายเครือข่าย
Schedulingเลือก packet ใดออกก่อน เช่น priority หรือ fair queueingช่วยแยกบริการ แต่ priority ที่ไม่จำกัดอาจทำให้ traffic อื่นอด

DSCP ใน IP header ใช้ทำเครื่องหมาย traffic class แต่เครื่องหมายเป็นเพียงคำขอหรือนโยบายที่ network domain ตีความ Router แต่ละขอบเขตอาจ remark, ignore หรือ map ไป queue ต่างกัน การใส่ DSCP สูงไม่ได้สร้าง bandwidth และไม่ควรถูก application ทุกตัวประกาศตัวเองว่าสำคัญที่สุด มิฉะนั้น priority queue จะกลายเป็น queue ธรรมดาที่มีความมั่นใจสูงขึ้นเท่านั้น

Load Balancing และ Packet Ordering

Router ที่มี ECMP หลายทางมัก hash จาก source/destination address, protocol และ port เพื่อรักษา flow เดียวบน path เดิม ถ้ากระจายต่อ packet ผ่าน path ที่ latency ต่างกัน packet อาจมาผิดลำดับและกระทบ transport แต่ per-flow hashing อาจเกิด elephant flow ตัวเดียวกินลิงก์หนึ่งเต็ม ขณะที่อีกลิงก์ว่าง การปรับสมดุลจึงมี granularity และข้อมูลไม่สมบูรณ์เป็นข้อจำกัด

Packet Loss ไม่ได้แปลว่าสายเสียเสมอไป
CRC error ชี้ไปที่ปัญหาลิงก์ได้ แต่ packet drop อาจเกิดจาก queue เต็ม, TTL หมด, ACL, route missing, MTU หรือ policy การเห็นคำว่า loss โดยไม่ดู counter และตำแหน่งที่หายยังไม่พอจะเลือกวิธีแก้

10วิธีวิเคราะห์ปัญหา Network Layer อย่างเป็นลำดับ

การแก้ปัญหาที่ดีไม่เริ่มจากสุ่ม ping ทุก address แล้วหวังว่าคำตอบจะเล่าเรื่องทั้งหมด เราควรสร้างเส้นทางที่คาดไว้ก่อนว่า source จะเลือก next hop ใด Router แต่ละตัวมี route อะไร และ return traffic จะกลับทางไหน จากนั้นเก็บหลักฐานทีละขอบเขต

  1. ตรวจ local configuration — address, prefix length, default gateway และ interface state ถูกต้องหรือไม่ Prefix ผิดหนึ่งบิตอาจทำให้ host คิดว่าปลายทางไกลอยู่ local แล้ว ARP หาอย่างไร้คำตอบ
  2. ตรวจ neighbor resolution — ARP หรือ IPv6 Neighbor Discovery หา link-layer address ของ next hop ได้หรือไม่ ถ้าไม่ได้ ปัญหายังไม่ควรกระโดดไปโทษ routing ทั้ง Internet
  3. ตรวจ route lookup — destination ตรง prefix ใด longest prefix ชี้ outgoing interface และ next hop ใด มี policy routing หรือ VRF เปลี่ยนตารางหรือไม่
  4. ตรวจ forwarding path — TTL ลดตามคาดหรือไม่ ACL/firewall, NAT, MTU และ queue ที่แต่ละ hop ทำอะไรกับ packet
  5. ตรวจ return path — ปลายทางรู้ทางกลับหรือไม่ Stateful firewall เห็น flow ครบสองทิศหรือเปล่า Asymmetric routing อาจทำให้ขาไปผ่านแต่ขากลับถูกทิ้ง
  6. ตรวจ application หลัง network path — เมื่อ IP reachability มีหลักฐานแล้ว ค่อยแยก transport port, service และ application response ไม่ใช้ ping สำเร็จเป็นหลักฐานว่าเว็บต้องทำงาน
กรณีศึกษา: Ping Gateway ได้ แต่เข้า Internet ไม่ได้

การ ping gateway สำเร็จพิสูจน์เพียง local link, neighbor resolution และ IP path ระหว่าง host กับ gateway บางส่วน ขั้นต่อไปต้องดูว่า gateway มี default route หรือไม่ NAT ถูกใช้และมี state หรือไม่ DNS resolution ทำงานหรือเปล่า upstream filter traffic หรือไม่ และ return route กลับ public address อยู่ตรงไหน

ถ้า ping public IP ได้แต่เปิดชื่อเว็บไม่ได้ หลักฐานชี้ไปทาง DNS มากขึ้น ถ้า DNS ตอบและ TCP connect ได้แต่หน้าเว็บผิด ปัญหาอยู่สูงขึ้น การแบ่งสมมุติฐานตามหลักฐานช่วยลดการแก้ config แบบสุ่ม ซึ่งมักสร้างปัญหาใหม่ให้ร่วมทีมกับปัญหาเดิม

เครื่องมือแต่ละตัวเห็นคนละมุม

เครื่องมือ/ข้อมูลช่วยตอบสิ่งที่ยังตอบไม่ได้ลำพัง
ip addr, ipconfigAddress และ interface config บนเครื่องไม่ได้ยืนยันว่า gateway หรือเส้นทางไกลทำงาน
ip route, routing tableRoute ที่เครื่องหรือ router จะใช้มี route ไม่ได้แปลว่า next hop เข้าถึงได้หรือ return path ถูก
ARP/neighbor tableMapping ของ next hop บน local linkไม่ใช่รายชื่อทุก host ทั่วเครือข่าย
pingICMP echo round trip เมื่อทุกฝ่ายยอมตอบไม่ตอบอาจเกิดจาก policy; ตอบได้ไม่ยืนยัน transport/application
tracerouteบาง hop ที่ตอบต่อ TTL/hop-limit probesเส้นทางกลับอาจต่าง และ hop ที่เงียบยัง forward traffic ได้
Packet capturePacket ที่ผ่านจุดจับและถูกส่งขึ้นมาให้เห็นไม่เห็นสิ่งที่ถูก drop ก่อนจุดจับหรือ offload ซ่อนไว้เสมอ
Troubleshooting เหมือนตามพัสดุจากรอยประทับแต่ละศูนย์
ถ้ารู้ว่าพัสดุถึงศูนย์ B แต่ไม่ถึง C เราลดพื้นที่ค้นหาเหลือช่วง B–C แต่ถ้าดูเพียงว่าผู้รับยังไม่ได้ของแล้วประกาศว่ารถคันแรกเสีย เรากำลังกระโดดข้ามหลักฐาน Network tools คือรอยประทับคนละแบบ ต้องอ่านร่วมกันและรู้ด้วยว่าศูนย์บางแห่งไม่ประทับตราแม้ส่งต่อปกติ

11ความปลอดภัยที่ Network Layer มองเห็น และสิ่งที่มองไม่เห็น

Router และ firewall ระดับเครือข่ายมองเห็น source/destination address, protocol, interface และบางครั้ง transport port หรือ connection state จึงใช้ ACL, route filtering, anti-spoofing และ segmentation จำกัด traffic ได้ แต่ IP address ไม่ใช่ตัวตนที่พิสูจน์แล้ว Source address ปลอมได้ในหลายบริบท และ NAT mapping ไม่บอกผู้ใช้จริงโดยไม่ผูกกับ log และเวลา

Source Validation และ Spoofing

Ingress filtering ตรวจว่า packet ที่เข้าจาก interface หนึ่งมี source prefix สมเหตุสมผลหรือไม่ ช่วยลดการปลอม source สำหรับ reflection/amplification attack Unicast Reverse Path Forwarding อาจตรวจเส้นทางย้อนกลับ แต่ strict mode มีปัญหากับ asymmetric routing จึงต้องเลือกโหมดตาม topology การควบคุมที่ดีต้องรู้สมมุติฐานของเส้นทาง ไม่ใช่เปิด feature เพราะชื่อฟังดูปลอดภัย

IPsec ปกป้อง Packet แต่ไม่ได้แก้ทุกปัญหาของเครือข่าย

IPsec ใช้ Authentication Header หรือ Encapsulating Security Payload ตามโหมดและนโยบาย เพื่อให้ integrity, authentication และ confidentiality บางส่วน Transport mode ปกป้อง payload ของ IP packet เดิมเป็นหลัก ส่วน tunnel mode ห่อ packet เดิมใน packet ใหม่และใช้สร้าง VPN ได้ แต่ IPsec ไม่ทำให้ route ที่ผิดกลับถูก ไม่เพิ่ม availability และ endpoint ที่ได้รับสิทธิ์ยังส่งข้อมูลอันตรายระดับ application ได้

Encryption ยังเหลือ metadata บางอย่าง เช่น outer source/destination, ขนาดและเวลาให้เครือข่ายเห็นตามโหมด Traffic analysis จึงอาจอนุมานรูปแบบได้แม้อ่าน payload ไม่ได้ คำว่า encrypted ควรระบุว่าปกป้องข้อมูลส่วนใด จากผู้สังเกตตำแหน่งใด และ key อยู่กับใคร

Addressing, Reachability และ Trust เป็นสามเรื่อง
รู้ address ไม่ได้แปลว่าไปถึง ไปถึงไม่ได้แปลว่าได้รับอนุญาต และได้รับ packet ไม่ได้แปลว่าควรเชื่อข้อมูลข้างใน Network Layer จัดการสองเรื่องแรกบางส่วน ส่วน trust ต้องพึ่ง authentication, cryptography และ policy ที่ข้ามหลายชั้น

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

  • Network Layer พา packet ข้ามหลายลิงก์ โดยแยก addressing, routing ใน control plane และ forwarding ใน data plane
  • Datagram ตัดสิน packet แยกกัน ส่วน Virtual Circuit ตั้ง state และเปลี่ยน local VCI ในแต่ละช่วง ไม่มีแบบใดดีที่สุดทุกเป้าหมาย
  • Distance Vector เรียนระยะจากเพื่อนบ้านและเสี่ยง count-to-infinity ส่วน Link State flood ชิ้นส่วน topology แล้วคำนวณ Dijkstra ภายในขอบเขต
  • IP ให้บริการ connectionless แบบ best effort ไม่รับประกันการถึง ลำดับ เวลา หรือการไม่ซ้ำ คุณสมบัติ end-to-end ต้องสร้างเพิ่มที่ชั้นบน
  • IPv4 router fragment ได้เมื่อเงื่อนไขอนุญาตและปลายทาง reassemble; IPv6 router ไม่ fragment และพึ่ง Path MTU Discovery
  • CIDR ใช้ prefix ยาวแปรผันและ longest prefix match ช่วยทั้งการจัดสรรกับ aggregation แต่สองเป้าหมายไม่ได้ดีขึ้นพร้อมกันเสมอ
  • ARP หา MAC ของ IPv4 next hop บน local link, DHCP แจก configuration และ ICMP รายงาน control/error บางชนิดโดยไม่รับประกันว่าจะถึง
  • OSPF ใช้ link state ภายใน AS ส่วน BGP เลือกเส้นทางระหว่าง AS ด้วย attribute และ policy ไม่ใช่ shortest path ล้วน
  • IPv6 เพิ่ม address space และปรับ header/neighbor discovery ส่วน NAT ประหยัด public IPv4 แต่เพิ่ม state และลดความตรงของ end-to-end connectivity
  • Queue, MTU, ACL, NAT, asymmetric return path และ routing convergence ล้วนทำให้ packet หายหรือช้าได้ ต้องใช้หลักฐานแยกสาเหตุ
คำถามซ้อมสอบ
  1. อธิบายว่าทำไม VCI จึงไม่ใช่ global identifier
  2. อธิบายปัญหา count-to-infinity และเปรียบเทียบ split horizon กับ poison reverse
  3. คำนวณ address assignment efficiency เมื่อกำหนดจำนวนโฮสต์และ class ที่ขอ
  4. เดิน Dijkstra's algorithm จากกราฟตัวอย่างที่กำหนด cost แต่ละ edge
  5. ทำ longest prefix match จาก forwarding table ที่มี default route และ prefix ซ้อนกันหลายระดับ
  6. แบ่ง IPv4 datagram ตาม MTU โดยคำนวณ payload, offset และ MF ของแต่ละ fragment
  7. อธิบายว่าทำไม route ขาไปกับขากลับอาจไม่เหมือนกัน และส่งผลต่อ stateful firewall อย่างไร
  8. ไล่ troubleshooting จาก local address, neighbor, route, forwarding ไปถึง return path โดยบอกหลักฐานที่ต้องเก็บแต่ละขั้น

ขั้นตอนถัดไปคือ Transport Layer ซึ่งรับช่วงจากบริการ best effort ของ IP แล้วเพิ่มการสื่อสารระหว่าง process ด้วย port, multiplexing และบริการแบบ TCP หรือ UDP TCP จะนำ sequence number, acknowledgment, window และ retransmission มาสร้าง byte stream ที่เชื่อถือได้แบบ end-to-end ขณะที่ UDP รักษารูปแบบ datagram ที่เบากว่าและปล่อยให้ application เลือกสิ่งที่จะเพิ่มเอง

Network Layer พาไปถึงอาคาร ส่วน Transport Layer พาไปถึงห้อง
IP address ช่วยพา packet ไปยัง host หรือ interface ที่เป็นปลายทาง แต่เครื่องหนึ่งมีหลาย process รอข้อมูลอยู่ Transport port จึงบอกว่าควรส่งต่อให้บริการใด และ protocol แต่ละแบบตกลงว่าจะรับประกันอะไร การไปถึงอาคารถูกหลังยังไม่เท่ากับส่งเอกสารถูกคน—แต่ถ้ารถยังหาอาคารไม่เจอ ต่อให้เขียนชื่อผู้รับละเอียดเพียงใดก็ไม่มีประโยชน์