เครือข่ายคอมพิวเตอร์คืออะไร
ก่อนจะแบ่งเครือข่ายออกเป็นชั้น (layer) เราควรถอยออกมาหนึ่งก้าว แล้วถามคำถามที่ง่ายกว่านั้นเสียก่อน: เรากำลังพยายามทำให้คอมพิวเตอร์หลายเครื่อง “คุยกัน” ไปเพื่ออะไร และเหตุใดเรื่องที่ดูเหมือนแค่การส่งข้อมูลจึงกลายเป็นระบบที่ซับซ้อนได้ถึงเพียงนี้
1โจทย์ตั้งต้นของทั้งวิชา
คำถามหลักที่ขับเคลื่อนการออกแบบเครือข่ายทั้งหมดคือ: จะสร้างเครือข่ายที่ scalable (ขยายขนาดได้) และรองรับแอปพลิเคชันที่หลากหลายได้อย่างไร? ฟังดูเหมือนคำถามเดียว แต่จริง ๆ ซ่อนโจทย์ไว้สองข้อ: วันนี้ต้องใช้งานได้ และวันพรุ่งนี้ต้องไม่พังเพียงเพราะมีผู้ใช้หรือแอปชนิดใหม่เพิ่มเข้ามา
ถ้าเราต้องการเชื่อมคอมพิวเตอร์เพียงสองเครื่อง เรื่องนี้แทบไม่ใช่ปัญหา ต่อสายให้ถึงกัน ตกลงรูปแบบข้อมูล แล้วส่งไป แต่เมื่อมีสิบเครื่อง เราต้องเริ่มคิดว่าใครเชื่อมกับใคร เมื่อมีหนึ่งล้านเครื่อง เราไม่สามารถลากสายตรงถึงกันทุกคู่ และเมื่อมีหลายพันล้านอุปกรณ์ คำถามไม่ใช่เพียง “ส่งถึงหรือไม่” อีกต่อไป แต่รวมถึงส่งผ่านทางไหน ใช้ทรัพยากรร่วมกับใคร ช้าได้แค่ไหน และเมื่อบางส่วนเสีย ระบบส่วนที่เหลือจะทำอย่างไร
ทั่วไปพอที่จะรองรับสิ่งที่ยังไม่ถูกประดิษฐ์
เครือข่ายคอมพิวเตอร์ต่างจากเครือข่ายโทรศัพท์ดั้งเดิมในจุดสำคัญ เครือข่ายโทรศัพท์ถูกสร้างขึ้นโดยมี “เสียงสนทนา” เป็นโจทย์หลัก จึงสามารถออกแบบทรัพยากรให้เข้ากับเสียงได้โดยตรง แต่ Internet ต้องเป็น general-purpose network มันต้องรองรับ Web, Email, เกม, Video Conference, Streaming, Cloud Computing, IoT ตลอดจนแอปพลิเคชันที่ผู้ออกแบบเครือข่ายในอดีตยังนึกไม่ถึง
นี่คือ paradox แรกของวิชา: เครือข่ายที่ประสบความสำเร็จที่สุด ไม่ใช่เครือข่ายที่รู้จัก application ทุกชนิดดีที่สุด แต่เป็นเครือข่ายที่ไม่ผูกตัวเองกับ application ใดมากเกินไป ความ “ไม่รู้” ของแกนกลางจึงกลายเป็นพื้นที่ให้ความสร้างสรรค์เกิดขึ้นที่ปลายทาง
ผู้ใช้เห็นแอปพลิเคชัน แต่เครือข่ายเห็นการขนส่งข้อมูล
คนส่วนใหญ่รู้จัก Internet ผ่านสิ่งที่ใช้งานอยู่ทุกวัน เช่น World Wide Web, Email, Online Social Network, Streaming Audio/Video, File Sharing และ Instant Messaging เรามองเห็นเป็นหน้าเว็บ เพลง ภาพ หรือบทสนทนา แต่เครือข่ายไม่ได้เข้าใจความหมายเหล่านั้นโดยตรง สิ่งที่มันเห็นคือข้อมูลที่ต้องถูกแบ่ง บรรจุ ระบุปลายทาง และส่งต่อ
แต่ละแอปต้องการบริการไม่เหมือนกัน Email ยอมให้ช้าได้บ้างแต่ไม่อยากให้เนื้อหาขาดหาย การถ่ายทอดสดยอมเสียข้อมูลเล็กน้อยได้ แต่ถ้าภาพมาถึงช้ากว่าความจริงหลายสิบวินาทีก็หมดความหมาย ส่วนการโอนเงินอาจมีข้อมูลเพียงไม่กี่ไบต์ แต่ความถูกต้องสำคัญกว่าความเร็วเสียอีก ดังนั้นคำว่า “เครือข่ายเร็ว” จึงยังไม่ใช่ requirement จนกว่าเราจะถามต่อว่า เร็วสำหรับงานอะไร และแลกกับอะไร
2มุมมองที่ต่างกันของแต่ละฝ่าย
ก่อนออกแบบอะไรก็ตาม ต้องเข้าใจก่อนว่า “เครือข่ายที่ดี” ของแต่ละคนอาจไม่ใช่เครือข่ายแบบเดียวกัน ความขัดแย้งจำนวนมากไม่ได้เกิดจากฝ่ายหนึ่งเข้าใจผิด แต่เกิดจากแต่ละฝ่ายกำลัง optimize คนละ objective
| บทบาท (Role) | คำถามที่อยู่ในใจ | สิ่งที่สนใจ |
|---|---|---|
| Application Programmer | “ฉันขอบริการอะไรจากเครือข่ายได้บ้าง?” | ต้องการรู้ service ที่ application เรียกใช้ได้ เช่น reliable delivery, throughput หรือ delay bound ผู้เขียนโปรแกรมไม่ควรต้องเลือกเส้นทางของ packet เองทุกครั้ง เช่นเดียวกับผู้ส่งจดหมายที่ไม่ต้องขับรถตามซองไปทุกศูนย์ไปรษณีย์ |
| Network Designer | “จะให้คนจำนวนมากใช้ทรัพยากรร่วมกันอย่างคุ้มค่าได้อย่างไร?” | ต้องออกแบบ link, node และกลไกการแชร์ให้ cost-effective หากสร้างถนนส่วนตัวให้จดหมายทุกฉบับ ระบบย่อมเร็วแต่แพงจนใช้จริงไม่ได้ งานออกแบบจึงเป็นการหาสมดุลระหว่าง performance, cost และความซับซ้อน |
| Network Provider | “เมื่อระบบโตและมีบางอย่างเสีย เราจะรู้และจัดการมันอย่างไร?” | สนใจ manageability: ตั้งค่า ตรวจวัด แยกสาเหตุ ซ่อม และขยายระบบได้ การออกแบบที่ทำงานได้ดีใน diagram แต่อธิบายไม่ได้ว่า router ตัวใดเสีย อาจเป็นงานวิจัยที่น่าสนใจ แต่เป็นฝันร้ายของผู้ให้บริการ |
เครือข่ายเดียวกัน แต่คนละความจริง
สมมุติระบบส่งวิดีโอได้ลื่นมาก Application Programmer อาจพอใจ แต่ถ้าต้องจอง bandwidth ไว้เต็มที่ตลอดเวลา Network Designer อาจมองว่าสิ้นเปลือง และถ้าทุกครั้งที่เพิ่ม server ต้องแก้ configuration ด้วยมือหลายสิบจุด Network Provider ก็คงไม่เรียกระบบนี้ว่าดี
นี่ทำให้การออกแบบเครือข่ายไม่ใช่โจทย์ “หาเทคโนโลยีที่ดีที่สุด” แต่เป็นโจทย์หลายวัตถุประสงค์ เราต้องถามเสมอว่า ดีสำหรับใคร ดีใน metric ใด และต้นทุนถูกผลักไปอยู่ที่ส่วนไหน เพราะระบบที่ทำให้ด้านหนึ่งง่ายขึ้น มักส่งความซับซ้อนไปให้อีกด้านรับช่วงต่อ
3เป้าหมายของบทนำทั้ง 8 หน้านี้
บทนำร่วมนี้จะปูพื้นฐาน 8 เรื่องก่อนแยกไปเรียนตามชั้น ไม่ว่าจะเลือกเส้นทาง OSI หรือ TCP/IP ทั้งแปดเรื่องไม่ใช่ศัพท์แปดชุดที่แยกจากกัน แต่เป็นลำดับคำถามที่ค่อย ๆ ประกอบระบบสื่อสารขึ้นมาจากศูนย์:
- เครือข่ายคืออะไร — เรากำลังแก้ปัญหาอะไร และใครเป็นผู้ตัดสินว่าคำตอบนั้นดีพอ
- Connectivity & Switching — เมื่ออุปกรณ์ไม่ได้ต่อสายถึงกันทุกคู่ ข้อมูลจะเดินทางผ่าน node และ link ใด คล้ายการเลือกระหว่างเปิดเส้นทางเฉพาะกับฝากพัสดุให้แต่ละจุดส่งต่อ
- Multiplexing — คนจำนวนมากแชร์ทรัพยากรเดียวกันอย่างไร โดยไม่ต้องสร้างถนนส่วนตัวให้ผู้ใช้ทุกคน
- Communication & Reliability — ถ้าข้อมูลหาย มาซ้ำ หรือมาผิดลำดับ ใครควรตรวจพบและใครควรแก้ไข
- Protocol & Layering — ผู้เกี่ยวข้องแต่ละทอดต้องตกลงกติกาอะไร และเหตุใดการใส่ข้อมูลลงใน “ซองหลายชั้น” จึงช่วยแยกความรับผิดชอบได้
- OSI vs TCP/IP — แบบจำลองสองชุดมองระบบเดียวกันต่างกันอย่างไร แบบหนึ่งช่วยให้คิดเป็นระเบียบ ส่วนอีกแบบสะท้อนโครงสร้างของ Internet ที่ใช้งานจริง
- Performance — คำว่าเร็วประกอบด้วย bandwidth, latency, throughput และ loss ซึ่งอาจให้คำตอบไม่ตรงกัน
- Socket API — จุดที่โลกของ application ยื่นจดหมายให้ระบบเครือข่าย และรับสิ่งที่ปลายทางส่งกลับมา
ทำไมต้องแบ่งเป็นชั้น
เมื่อระบบซับซ้อน เรามีสองทางเลือก ทางแรกคือให้ทุกคนรู้ทุกอย่าง ซึ่งฟังดูรอบคอบแต่ขยายไม่ได้ อีกทางคือแบ่งความรับผิดชอบ แล้วกำหนด interface ระหว่างกันให้ชัดเจน เครือข่ายเลือกทางที่สอง
เวลาส่งจดหมาย เราเขียนเนื้อหาใส่กระดาษแล้วใส่ซอง เจ้าหน้าที่อาจนำซองนั้นใส่ถุงตามเขต ศูนย์กระจายสินค้าอาจนำถุงขึ้นรถหรือเครื่องบิน แต่ละระดับเติมสิ่งที่ตนต้องใช้ โดยไม่แกะและเขียนเนื้อหาของเราใหม่ กระบวนการนี้คล้าย encapsulation: แต่ละ layer เติม header ของตนเองลงไปรอบข้อมูลเดิม
อย่างไรก็ตาม metaphor ทุกอันมีขอบเขต Packet ไม่ใช่จดหมายจริง เพราะอาจถูกแบ่ง ส่งคนละเส้นทาง ส่งซ้ำ หรือถูกทิ้งเมื่อเครือข่ายแออัด การเปรียบเทียบช่วยให้เห็นโครงสร้าง แต่เมื่อ metaphor เริ่มซ่อนพฤติกรรมที่สำคัญ เราต้องกลับมาหา model ทางเทคนิค นี่คือเหตุผลที่เราจะใช้ทั้งภาพเปรียบเทียบและคำจำกัดความควบคู่กัน
4สรุปและก้าวต่อไป
- เครือข่ายไม่ใช่เพียงสายและอุปกรณ์ แต่เป็นระบบที่ทำให้ application แลกเปลี่ยนข้อมูลได้โดยไม่ต้องควบคุมทุกขั้นตอนของการเดินทางเอง
- ความเป็น general-purpose ทำให้ Internet รองรับสิ่งที่ผู้ออกแบบดั้งเดิมไม่ได้คาดการณ์ ความเรียบง่ายบางส่วนของแกนกลางจึงเป็นความสามารถ ไม่ใช่ข้อบกพร่อง
- การส่งข้อมูลคล้ายการใส่จดหมายลงซอง: แต่ละทอดเติมข้อมูลสำหรับหน้าที่ของตน กระนั้น packet อาจหาย ซ้ำ ผิดลำดับ หรือเดินทางคนละเส้นทางได้
- เครือข่ายที่ดีไม่มีนิยามเดียว Programmer มอง service, Designer มอง cost และ resource sharing, Provider มอง manageability
- Layering ทำให้เราแยกความรับผิดชอบและเปลี่ยนกลไกบางส่วนได้โดยไม่ต้องสร้างระบบทั้งหมดใหม่ แต่ทุกการแบ่งย่อมมี overhead และข้อจำกัดตามมา