ปี 1973 มีเครือข่ายท้องถิ่นให้เลือกหลายแบบ และเกือบทุกแบบออกแบบมาอย่างมีระเบียบ — มีตัวกลางคอยจัดคิว มีการจองเวลาก่อนส่ง มีการรับประกันว่าข้อมูลจะไม่ชนกัน
Ethernet ทำตรงข้ามทุกข้อ มันปล่อยให้ทุกเครื่องพูดเมื่อไหร่ก็ได้ ยอมรับว่า จะชนกันแน่นอน แล้ววางแผนว่าจะทำอย่างไรหลังชน
สี่สิบกว่าปีต่อมา แบบที่มีระเบียบทั้งหมดตายไปหมดแล้ว ส่วนแบบที่ยอมให้ชนกัน อยู่ในทุกอาคารบนโลก
หน้านี้เล่าว่าทำไม และอธิบายว่าตัวเลข 64, 1500 และ 1536 ที่คนทำงานเครือข่าย เจอทุกวันมาจากไหน
หน้านี้อยู่ชั้นล่างสุดของชุดบทความ ใต้ MAC address ลงไปอีกชั้น เพราะ Ethernet คือสิ่งที่นิยาม MAC ขึ้นมาตั้งแต่แรก
ถ้ายังไม่เคยสังเกต เริ่มตรงนี้
$ ifconfig en0 | grep mtu
... mtu 1500เลข 1500 นี้อยู่บนเครื่องคุณตอนนี้ และมันถูกกำหนดในเอกสารที่เขียนขึ้นก่อน เว็บจะถูกประดิษฐ์ ก่อน Wi-Fi จะมีอยู่ และก่อนที่คนส่วนใหญ่ที่อ่านหน้านี้จะเกิด
ทุกครั้งที่คุณเจอปัญหา MTU ตามที่เขียนไว้ในบทความ ping คุณกำลังเจอผลของการตัดสินใจครั้งหนึ่งเมื่อปี 1980
1971 ที่ฮาวาย — เครือข่ายที่ยอมให้ชนกัน
มหาวิทยาลัยฮาวายมีปัญหาที่แปลกกว่าที่อื่น — วิทยาเขตกระจายอยู่คนละเกาะ การลากสายเชื่อมกันไม่คุ้ม จึงใช้วิทยุแทน
แต่วิทยุมีข้อจำกัดที่สายไม่มี ไม่มีใครสั่งให้ใครเงียบได้ สถานีบนเกาะหนึ่ง ไม่รู้ว่าอีกเกาะกำลังส่งอยู่หรือเปล่า
ALOHAnet จึงเลือกทางที่ดูมักง่ายที่สุด — ส่งไปเลย ถ้าไม่ได้รับการตอบรับ แปลว่าชนกัน ก็รอสุ่มเวลาสักครู่แล้วส่งใหม่
มันทำงานได้จริงที่ความเร็ว 4800 ถึง 9600 บิตต่อวินาที และที่สำคัญกว่านั้นคือ มันพิสูจน์ว่าเครือข่ายที่ไม่มีใครคุมคิวใช้งานได้ ซึ่งเป็นความคิดที่ยังไม่มี ใครกล้าเชื่อในตอนนั้น
Bob Metcalfe ทำวิทยานิพนธ์เกี่ยวกับการวิเคราะห์ปริมาณงานที่ระบบแบบนี้ รองรับได้ เขาจึงเข้าใจทั้งข้อดีและขีดจำกัดของมันดีกว่าใคร
22 พฤษภาคม 1973 — บันทึกที่ตั้งชื่อมัน
Metcalfe ย้ายมาอยู่ที่ Xerox PARC ซึ่งกำลังสร้างคอมพิวเตอร์ส่วนบุคคลชื่อ Alto และมีปัญหาที่ต้องแก้ — จะให้ Alto หลายเครื่องในตึกเดียวกันคุยกัน และใช้เครื่องพิมพ์เลเซอร์ร่วมกันได้อย่างไร
วันที่ 22 พฤษภาคม 1973 เขาพิมพ์บันทึกฉบับหนึ่งด้วยเครื่องพิมพ์ดีด IBM Selectric อธิบายเครือข่ายแบบกระจายเสียงที่จะเชื่อม Alto เข้าด้วยกัน
และในบันทึกนั้นเขาเสนอชื่อ โดยยืมมาจากสิ่งที่นักฟิสิกส์ศตวรรษที่สิบเก้าคิดว่า เป็นตัวกลางที่แสงเดินทางผ่าน — สิ่งที่ชื่อว่า luminiferous ether และถูกพิสูจน์ในภายหลังว่าไม่มีอยู่จริง
...เรียกมันว่า "the ether" กันเถอะ
ชื่อนี้เหมาะกว่าที่เขาตั้งใจด้วยซ้ำ เพราะสิ่งที่ Ethernet ทำคือจำลองอากาศ ที่วิทยุใช้ ให้อยู่ในสายทองแดง ทุกเครื่องบนสายเส้นเดียวได้ยินทุกอย่าง เหมือนสถานีวิทยุบนเกาะได้ยินกันหมด
Metcalfe ชวน David Boggs มาร่วมสร้างต้นแบบ และมันทำงานได้จริงครั้งแรก เมื่อ 11 พฤศจิกายน 1973
ความเร็วที่มาจากสิ่งที่มีอยู่แล้ว
Ethernet ตัวแรกวิ่งที่ 2.94 Mbit/s ซึ่งเป็นตัวเลขที่ดูไม่เป็นเลขกลม จนน่าสงสัย
เหตุผลตรงไปตรงมามาก — สัญญาณนาฬิกาของ Alto คือ 5.88 MHz และพวกเขาหารสอง เอามาใช้เลย ไม่ต้องเพิ่มวงจรอะไร
5.88 MHz ÷ 2 = 2.94 Mbit/sนี่คือลายเซ็นของงานวิศวกรรมที่ดี — ไม่ได้เลือกตัวเลขที่สวยแล้วไปสร้าง ฮาร์ดแวร์ให้ได้ตามนั้น แต่ใช้สิ่งที่มีอยู่ในมือให้คุ้มที่สุด และมันยังเร็ว กว่า ALOHAnet ถึงสามร้อยเท่า
แนวคิดการออกแบบ — ยอมรับความชุลมุนแทนที่จะห้าม
กฎทั้งหมดของ Ethernet ยุคแรกมีห้าข้อ และไม่มีข้อไหนต้องการอุปกรณ์กลาง
- ฟังก่อน มีใครส่งอยู่ก็รอ
- ส่ง ว่างแล้วส่งเลย ไม่ต้องขออนุญาตใคร
- ฟังต่อระหว่างส่ง สัญญาณเพี้ยนแปลว่าชน
- ส่งสัญญาณรบกวนซ้ำ ให้ทุกเครื่องรู้ตรงกันว่าเฟรมนี้เสียแล้ว
- รอแบบสุ่ม แล้วลองใหม่
ข้อที่ห้าคือหัวใจ และรายละเอียดของมันฉลาดกว่าที่ดู — ช่วงเวลาที่สุ่ม เพิ่มเป็นเท่าตัวทุกครั้งที่ชนซ้ำ
ชนครั้งที่ 1 สุ่มจาก 2 ช่วง
ชนครั้งที่ 2 สุ่มจาก 4 ช่วง
ชนครั้งที่ 3 สุ่มจาก 8 ช่วง
... ไปจนถึง 1024 ช่วง
ชนครั้งที่ 16 ยอมแพ้ ทิ้งเฟรมนั้นผลคือยิ่งเครือข่ายแออัด ทุกเครื่องยิ่งถอยห่างกันเองโดยอัตโนมัติ ไม่มีใครสั่ง ไม่มีใครวัด ไม่มีใครต่อรอง แต่ระบบหาจุดสมดุลได้เอง
นี่คือแนวคิดเดียวกับที่ทำให้ Internet Protocol ชนะ — ไม่รับประกันอะไร แลกกับการที่ไม่มีอุปกรณ์ตัวไหนต้องจำสถานะของใคร เครื่องที่พังก็แค่หายไป ที่เหลือทำงานต่อโดยไม่รู้ตัวด้วยซ้ำ
ทำไมเฟรมต่ำสุดต้อง 64 ไบต์
ข้อ 3 ข้างบนซ่อนข้อจำกัดทางฟิสิกส์ไว้ — จะรู้ว่าชนกันได้ ต้องยังส่งไม่จบ
สมมติ A เริ่มส่ง สัญญาณใช้เวลาเดินทางไปถึง B และถ้า B เผลอส่งพอดีตอนที่ สัญญาณของ A ยังไปไม่ถึง สัญญาณจะชนกันแล้ววิ่งกลับมาหา A
ถ้า A ส่งเสร็จไปแล้วก่อนสัญญาณชนจะกลับมาถึง A จะไม่มีวันรู้ว่าเฟรมนั้นเสีย และไม่มีใครส่งซ้ำให้
จึงต้องบังคับว่าเฟรมต้องยาวพอที่จะยังส่งอยู่ตลอดเวลาไป-กลับที่ยาวที่สุด ที่เป็นไปได้
ระยะสูงสุดที่ยอมให้ 2500 เมตร (ห้าช่วง ช่วงละ 500)
ไป-กลับ 5000 เมตร บวกเวลาที่อุปกรณ์ทวนสัญญาณใช้
ตั้งงบไว้ 51.2 ไมโครวินาที
ที่ 10 Mbit/s 51.2 µs = 512 บิต
512 บิต = 64 ไบต์64 ไบต์จึงไม่ใช่ตัวเลขที่ใครเลือกเพราะสวย แต่คือความเร็วแสงในสายทองแดง คูณกับความยาวสายที่ยอมให้ แปลงเป็นจำนวนบิต
ผลข้างเคียงคือเฟรมที่มีข้อมูลน้อยกว่านั้นต้องถูกเติมศูนย์ให้ครบ ส่งข้อมูล หนึ่งไบต์ก็ยังต้องใช้พื้นที่บนสาย 64 ไบต์อยู่ดี
ในเฟรมมีอะไรอยู่บ้าง
preamble 7 ไบต์ 10101010 ซ้ำเจ็ดครั้ง
SFD 1 ไบต์ 10101011
ปลายทาง 6 ไบต์ MAC ของผู้รับ
ต้นทาง 6 ไบต์ MAC ของผู้ส่ง
type/length 2 ไบต์ ดูหัวข้อถัดไป
payload 46–1500 ข้อมูลจริง
FCS 4 ไบต์ รหัสตรวจสอบความถูกต้องpreamble ไม่ได้ถูกนับเป็นส่วนหนึ่งของเฟรม มันคือคลื่นสลับ 1 กับ 0 ที่ส่งนำหน้าไปเพื่อให้ผู้รับปรับจังหวะนาฬิกาให้ตรงกับผู้ส่งได้ก่อน เพราะสายทองแดงไม่มีสัญญาณนาฬิกาแยกมาให้
บิตสุดท้ายของ SFD เปลี่ยนจาก 0 เป็น 1 ซึ่งเป็นสัญญาณว่า "ข้อมูลจริง เริ่มไบต์ถัดไป"
FCS ตรวจทั้งเฟรม ผิดแม้บิตเดียวก็ทิ้งทั้งเฟรม — และไม่มีการส่งซ้ำ ไม่มีการแจ้งใคร เฟรมนั้นหายไปเงียบ ๆ เหมือนที่ IP ทำกับแพ็กเก็ต
1536 — เลขที่แยกสองมาตรฐานออกจากกัน
ปี 1980 กลุ่ม DIX ซึ่งประกอบด้วย DEC, Intel และ Xerox เผยแพร่มาตรฐาน ที่เรียกกันว่า Ethernet Blue Book เมื่อ 30 กันยายน 1980 ที่ความเร็ว 10 Mbit/s
ต่อมา IEEE ทำมาตรฐานของตัวเองชื่อ 802.3 ออกเป็นร่างในปี 1983 และเป็นมาตรฐานจริงในปี 1985
ปัญหาคือสองฉบับใช้ฟิลด์สองไบต์ตำแหน่งเดียวกันคนละความหมาย — DIX ใช้บอกว่า ข้างในเป็นโพรโทคอลอะไร ส่วน IEEE ใช้บอกความยาวของข้อมูล
ทางออกคือใช้ตัวเลขเป็นตัวแยก
ค่า ≤ 1500 = ความยาว รูปแบบ IEEE 802.3
ค่า 1501 – 1535 ไม่มีการนิยาม ห้ามใช้
ค่า ≥ 1536 (0x0600) = EtherType รูปแบบ Ethernet IIและนี่คือเหตุผลที่ payload ใหญ่ได้ไม่เกิน 1500 — ถ้าใหญ่กว่านั้น ตัวเลขความยาวจะไปทับกับช่วงที่สงวนไว้ให้ EtherType แล้วผู้รับจะแยกไม่ออกว่า กำลังอ่านเฟรมแบบไหน
เลข 1500 กับเลข 1536 จึงผูกกันโดยตรง ไม่ใช่เรื่องบังเอิญ
EtherType ที่เจอบ่อย
0x0800 IPv4
0x0806 ARP
0x86dd IPv6
0x8100 มี VLAN tag ต่อท้ายทุกครั้งที่แพ็กเก็ต IP วิ่งผ่านสาย มันเดินทางในเฟรมที่มีเลข 0x0800 อยู่ตรงนี้ — นั่นคือจุดเชื่อมระหว่างบทความนี้กับ Internet Protocol
งบประมาณไบต์ — และราคาของเฟรมเล็ก
ทุกเฟรมมีส่วนเกินคงที่ 38 ไบต์ ไม่ว่าจะส่งข้อมูลมากหรือน้อย
preamble + SFD 8
หัวเฟรม 14 (ปลายทาง 6 + ต้นทาง 6 + type 2)
FCS 4
ช่องว่างก่อนเฟรมถัดไป 12
---
38 ไบต์ ที่ไม่ใช่ข้อมูล เฟรมใหญ่สุด ข้อมูล 1500 จาก 1538 บนสาย = 97.5%
เฟรมเล็กสุด ข้อมูล 46 จาก 84 บนสาย = 54.8%ตัวเลขคู่นี้อธิบายเรื่องที่ทำให้คนงงบ่อยมาก — ลิงก์ 1 Gbit/s ที่วัดได้ จริงแค่ครึ่งเดียว มักไม่ได้เสียหาย แต่กำลังขนทราฟฟิกที่เป็นเฟรมเล็กจำนวนมาก ซึ่งเกือบครึ่งของสายถูกใช้ไปกับส่วนเกิน
และเป็นเหตุผลที่ศูนย์ข้อมูลบางแห่งเปิด jumbo frame ให้ payload ใหญ่กว่า 1500 เพื่อลดสัดส่วนส่วนเกินลงไปอีก
จากสายร่วม สู่สวิตช์ — และการตายของ CSMA/CD
10BASE5 คือรุ่นที่ใช้จริงในยุคแรก สายโคแอกเชียลหนา 9.5 มิลลิเมตร ยาวช่วงละ 500 เมตร และการต่อเครื่องเข้าไปทำโดยเจาะทะลุฉนวนเข้าไปแตะแกนกลาง ด้วยหัวต่อที่คนเรียกกันว่า เขี้ยวแวมไพร์
ทุกเครื่องอยู่บนสายเส้นเดียวกัน จึงอยู่ในเขตชนกันเดียวกันทั้งหมด สายขาดที่จุดเดียวคือทั้งวงล่ม
จากนั้นมาเป็นสายคู่บิดเกลียวกับฮับ ซึ่งดูเหมือนดีขึ้นแต่ยังเป็นเขตชนกัน เดียวกันอยู่ ฮับแค่ทำซ้ำสัญญาณออกทุกพอร์ตเท่านั้น
แล้วสวิตช์ก็มาเปลี่ยนทุกอย่าง ทุกเครื่องมีสายของตัวเอง ส่งและรับพร้อมกันได้ ไม่ต้องแย่งกับใคร
ผลคือ CSMA/CD ไม่มีอะไรให้ทำอีกต่อไป มันยังอยู่ในมาตรฐาน ยังอยู่ในโค้ด ของไดรเวอร์ แต่บนเครือข่ายที่ใช้สวิตช์ทั้งหมดและวิ่งแบบสองทางพร้อมกัน มันไม่เคยทำงานอีกเลย
แต่มรดกของมันยังอยู่ครบ — เฟรมยังต่ำสุด 64 ไบต์ทั้งที่ไม่มีการชนให้ตรวจ แล้ว payload ยังไม่เกิน 1500 และช่องว่างระหว่างเฟรม 12 ไบต์ยังต้องมี ตัวเลขทั้งหมดนี้แก้ปัญหาที่หายไปตั้งแต่ยุคเก้าศูนย์
ตัวอย่างจริงจากงานจริง
กรณีที่ 1 — ลิงก์เต็มทั้งที่ตัวเลขยังไม่ถึง
ระบบเฝ้าระวังบอกว่าลิงก์ 1 Gbit/s ใช้ไปแค่ 400 Mbit/s แต่ผู้ใช้บอกว่าช้า
อ่านอย่างไร ดูจำนวนเฟรมต่อวินาทีควบคู่กับปริมาณข้อมูล ถ้าคิดเฉลี่ยแล้ว ได้ขนาดเฟรมประมาณ 64 ถึง 100 ไบต์ แปลว่าเกือบครึ่งของความจุสายถูกใช้ไปกับ ส่วนเกิน ตัวเลข 400 Mbit/s ที่วัดได้จึงอาจกินความจุจริงไปเกือบหมดแล้ว
สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าทำไมเฟรมถึงเล็ก อาจเป็นทราฟฟิกที่มี ลักษณะแบบนั้นจริง หรืออาจมีอะไรบางอย่างแตกข้อมูลเป็นชิ้นเล็กโดยไม่จำเป็น
กรณีที่ 2 — ตัวนับข้อผิดพลาดที่บอกอะไรได้
switch# show interface Gi1/0/14 | include error|collision
0 input errors, 0 CRC, 0 frame, 0 overrun
127 output errors, 0 collisions, 0 interface resetsอ่านอย่างไร ถ้าเห็นตัวเลข collisions ไม่เป็นศูนย์บนลิงก์ที่ควรวิ่งแบบ สองทางพร้อมกัน นั่นแปลว่ามีฝั่งใดฝั่งหนึ่งตั้งเป็นทางเดียว — ปัญหา duplex mismatch คลาสสิก ซึ่งทำให้ช้าลงมากแต่ไม่ถึงกับใช้ไม่ได้
ส่วน CRC ไม่เป็นศูนย์ชี้ไปที่ชั้นกายภาพ — สาย หัวต่อ หรือโมดูล ตรงกับกรณี ที่ใช้ ping -p ตรวจในบทความ ping
สิ่งที่ยังไม่ได้พิสูจน์ ตัวนับเป็นค่าสะสมตั้งแต่เปิดเครื่อง ต้องล้างแล้ว วัดใหม่จึงจะรู้ว่าปัญหายังเกิดอยู่หรือเป็นของเก่า
กรณีที่ 3 — เฟรมที่ใหญ่เกินและถูกทิ้งเงียบ ๆ
เปิด jumbo frame ที่เซิร์ฟเวอร์สองตัวแล้วบางอย่างพัง
อ่านอย่างไร jumbo frame ทำงานได้ก็ต่อเมื่อทุกอุปกรณ์บนเส้นทางนั้น ตั้งค่าตรงกันหมด สวิตช์ตัวไหนที่ยังตั้ง 1500 อยู่จะทิ้งเฟรมที่ใหญ่กว่านั้น โดยไม่แจ้งใคร เพราะ Ethernet ไม่มีกลไกแจ้งกลับ
อาการที่ได้จึงเหมือน PMTU black hole ในบทความ ping คือการเชื่อมต่อเริ่มได้ปกติแล้วค้างเมื่อส่งข้อมูลก้อนใหญ่
สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าอุปกรณ์ตัวไหนเป็นคอขวด ต้องไล่ดู MTU ของทุกอินเทอร์เฟซบนเส้นทาง
สิ่งที่ Ethernet สอน
Ethernet ชนะเครือข่ายที่ออกแบบมาอย่างมีระเบียบทุกแบบ ด้วยเหตุผลเดียวกับที่ Internet Protocol ชนะ — มันไม่รับประกันอะไร จึงไม่มี อุปกรณ์ตัวไหนต้องจำอะไร
เครือข่ายที่มีตัวกลางจัดคิวทำงานได้ดีกว่าเมื่อทุกอย่างเป็นไปตามแผน แต่พังทั้งระบบเมื่อตัวกลางพัง และขยายยากเพราะต้องอัปเกรดตัวกลางตาม
ส่วนเครือข่ายที่ยอมรับความชุลมุน แค่เพิ่มเครื่องเข้าไปก็ใช้งานได้เลย
และตัวเลข 64, 1500, 1536 ที่ยังอยู่ในเครื่องคุณวันนี้ คือร่องรอยของ สายโคแอกเชียลเส้นหนึ่งยาว 2500 เมตร ที่ไม่มีใครใช้แล้วมาสามสิบปี
อ้างอิง
ประวัติ
- บันทึกของ Robert Metcalfe ลงวันที่ 22 พฤษภาคม 1973 ที่ Xerox PARC ซึ่งเป็นที่มาของชื่อ Ethernet และของประโยคที่เสนอให้เรียกมันว่า the ether
- Ethernet — Wikipedia วันที่ทดสอบครั้งแรก 11 พฤศจิกายน 1973 ที่ 2.94 Mbit/s · Blue Book ของ DIX วันที่ 30 กันยายน 1980 · IEEE 802.3 ร่างปี 1983 มาตรฐานปี 1985 · รายละเอียดของ 10BASE5
- ALOHAnet — Wikipedia ระบบที่ Ethernet ยกความคิดมา
รายละเอียดทางเทคนิค
- Ethernet frame — Wikipedia โครงเฟรม · เส้นแบ่ง 1536 ระหว่าง EtherType กับ Length · ขนาดต่ำสุด 64 ไบต์ ที่มาจาก slot time 512 บิต · ช่องว่างระหว่างเฟรม 96 บิต
- มาตรฐาน IEEE 802.3 ฉบับปัจจุบัน ซึ่งยังคงข้อกำหนดเรื่อง CSMA/CD ไว้ ทั้งที่แทบไม่มีเครือข่ายไหนใช้มันแล้ว
คู่มือ
ifconfigหรือip linkบนเครื่องที่คุณนั่งอยู่ เพื่อดูเลข 1500 ที่ยัง อยู่ตรงนั้นตั้งแต่ปี 1980show interfaceบนสวิตช์ สำหรับตัวนับ CRC และ collision ที่ยังมีความหมาย