192 บทที่ 24. IPV6
24.3.1 หมายเลขของอินเตอร์เฟส (Interface Identifiers)
เพื่อสนับสนุนการทำงานของ Auto-configuration ที่ได้กล่าวไปแล้ว ในแอดเดรสแบบยูนิคาสท์ของ IPv6 ยกเว้นที่
ขึ้นต้นด้วย 000 (::/3) จะใช้ 64 บิตของหมายเลขของอินเตอร์เฟส (interface indentifier) เพื่อกำหนดส่วนของ 64
บิตหลังของ IPv6 address ซึ่งหมายเลขของอินเตอร์เฟส (interface identifier) นี้จะได้มาจาก MAC address ของ
อุปกรณ์นั้นๆ โดย MAC address จะประกอบด้วย 24 บิตของ Organizationally Unique Identifier (OUI) หรือก็
คือหมายเลขของบริษัทที่ถูกจัดการโดย Institute of Electrical and Electronics Engineers (IEEE) และ 24 หรือ
40 บิต กำหนดโดยบริษัทนั้นๆ แม้ว่า โดยทั่วไปเราจะอ้างถึง 24 บิต แต่โดยจริงแล้วใช้ได้เพียง 22 บิต เท่านั้น อีก 2
บิตจะใช้เพื่อแสดงว่า MAC address หรือ EUI-64 ซํ้ากับใครหรือไม่ (บิต Universal/Local ) รวมทั้งระบุถึง MAC
address ที่กำหนดเป็นแบบแอดเดรสแบบมัลติคาสท์หรือเป็นแอดเดรสแบบยูนิคาสท์ปกติ
แม้ว่าในกรณีที่ไม่มีหมายเลขของอุปกรณ์หรือแอดเดรสถูกกำหนดเองโดยผู้ใช้ หลักการของหมายเลขของ
อินเตอร์เฟส (interface identifier) ยังคงสามารถที่จะใช้ได้ ในกรณีนี้ บิต Universal/Local จะถูกกำหนดให้เป็น 1
book)
เพื่อแจ้งให้ทราบว่าแอดเดรสไม่สามารถใช้ได้ทั่วไป อย่างไรก็ตามเพื่อหลีกเลี่ยงความยุ่งยากในการตั้งค่าแอดเดรสบิต
Univeral/Local จะถูกกลับบิต เมื่อ IPv6 address ถูกกำหนดโดย routing prefix และหมายเลขระบุอินเตอร์เฟส
(interface identifier) การที่บิต Universal/Local ถูกกลับบิตบน EUI-64 จะเรียกว่า modified EUI64 รูปที่
24.2 แสดงความสัมพันธ์ระหว่าง OUI, MAC address, EUI-64 และ modified EUI-64
(partial
only
KKU
รูปที่ 24.2: ความสัมพันธ์ระหว่าง OUI, MAC address, EUI-64, และ modified EUI-64
ตัวอย่าง 24.1 พิจารณา MAC address 00:0A:95:F5:E9:6E ประกอบไปด้วย OUI 000A95 ซึ่งเป็นของบริษัท
APPLE เพื่อให้ 48 บิตของ MAC address เป็นค่า EUI-64 สามารถทำได้โดยการแทรกค่า FFFE ระหว่าง OUI และ
ค่าที่กำหนดขึ้นโดยบริษัทผู้ผลิต ทำให้เราได้ค่าของ 64 บิตคือ 00:0A:95:FF:FE:F5:E9:6E จากนั้นกลับบิตที่ 6 และ
เพิ่ม 64 บิตด้านหน้าเช่น 1001:0DB9:0031:0001::/64 จะทำให้เราได้แอดเดรส 1001:0DB9:0031:0001:020A:
95FF:FEF5:E96E
24.3.2 รูปแบบทั่วไปของแอดเดรส IPv6
จากการที่แอดเดรสของ IPv6 มีขนาดเพิ่มขึ้นจาก 32 บิตเป็น 128 บิต การออกแบบของโพรโตคอลเลือกที่จะ
กำหนดการเขียนให้อยู่ในรูปของจำนวนเต็มขนาด 16 บิตและแยกด้วยเครื่องหมาย colon (:) และจำนวนเต็มดัง
กล่าวจะถูกแทนด้วยเลขฐาน 16 เช่น FFDC:1521:7654:3210:FDCD:BA98:7654:3210
แม้ว่าการใช้เลขฐาน 16 แทนค่อนข้างเหมาะสม ตรงไปตรงมาในระบบดิจิทัล แต่ยากในการจำและใช้งาน
สำหรับผู้ใช้ พูดง่ายๆคือไม่เป็นมิตรกับผู้ใช้ ทำให้ต้องอ้างอิงเป็นชื่อจะทำให้ง่ายกว่า แต่อย่างไรก็ตามในฐานะผู้ดูแล
ระบบ หลีกเลี่ยงไม่ได้ที่จะต้องทำงานในลักษณะที่เป็นเลขฐาน 16 ซึ่งอาจแก้ไขโดยการบันทึกชื่อต่างๆไว้ในแฟ้มหรือ
24.4. ประเภทของแอดเดรสแบบยูนิคาสท์ 193
ฐานข้อมูล ดังนั้นเพื่อทำให้ง่ายเข้า จึงได้มีการกำหนดชื่อแบบย่อขึ้น อย่างน้อยในช่วงต้น 128 บิตจะไม่ใช่ทั้งหมด
เลขส่วนใหญ่น่าจะยังเป็น 0 (ศูนย์) อยู่ เช่น 8010:0000:0000:0000:0008:0800:200A:1235
ดังนั้น ในช่วงแรกเราสามารถทำได้โดยการไม่เขียนเลข 0 ที่อยู่ด้านหน้าในแต่ละเลขฐาน 16 เช่นการเขียนเป็น
0 แทนการเขียน 0000 หรือ 8 แทน 0008 และ 800 แทน 0800 และอีกวิธีหนึ่งคือการใช้เครื่องหมาย colon 2 ตัว
ติดกัน (::) เพื่อแทน 16 บิตของ 0 ที่ต่อเนื่องกัน เช่นการแทนเลขที่แล้วด้วย 1080::8:800:200A:1235
การทำงานของการแทนด้วยเลขค่อนข้างง่าย คือหากมีเครื่องหมาย colon อยู่ด้านหน้าด้านซ้ายมือมีความเป็น
ไปได้ที่จะต้องมี เลข 16 บิตอยู่ด้านหน้า หากมีอยู่ด้านขาวจะมีเลข 0 อยู่ เช่น
FEDC:BA98::7654:3210 แทน FEDC:BA98:0:0:0:0:7654:3210
::FEDC:BA98:7654:3210 แทน 0:0:0:0:FEDC:BA98:7654:3210
FEDC:BA98:7654:3210:: แทน FEDC:BA98:7654:3210:0:0:0:0
การแทนด้วย :: สามารถใช้ได้ครั้งเดียวในแอดเดรสหนึ่งๆ เช่น 0:0:0:AABB:1236:0:0:0 สามารถที่จะย่อเป็น
::AABB:1236:0:0:0 หรือ 0:0:0:AABB:1236:: แต่ไม่สามารถที่จะย่อเป็น ::AABB:1236::
book)
นอกจากนี้ แอดเดรสบางแอดเดรสมีบิตอยู่ด้านหน้าถึง 96 บิต เช่นการเขียนแอดเดรสของ IPv4 ดังนั้นเพื่อหลีก
เลี่ยงความผิดพลาดที่อาจเกิดขึ้นได้ ในการแทนเลข IPv4 ด้วยเลขฐาน 16 ของ IPv6 ทำให้การออกแบบของ IPv6
อนุญาตให้ใช้ในลักษณะที่เป็นแบบจุดของ IPv4 ได้ เช่น แทนที่จะเขียน 0:0:0:0:0:0:A00:1 เราสามารถเขียนให้อยู่
ในรูปของ ::10.0.0.1 ได้
(partial
เพื่อให้คล้องจองกับ IPv4 กำหนดหมายเลขของ IPv6 ใช้เครื่องหมาย slash (/) เพื่อใช้กับ routing protocol
เช่นการใช้FEDC:BA98:7600::/40จะแทนค่าของเลขฐานสองของ1111111011011100101110101001100001
110110 ซึ่งนอกจากนี้เรายังสามารถที่ใช้ร่วมกับรูปแบบของเครื่องหมาย colon สองตัวร่วมอีกด้วย (::) เช่น IPv6
ที่ FEDC:BA98:0000:0076:0000:1234:5678:9ABC ในการที่จะระบุถึง 64 บิตแรก เพื่อระบุเน็ตเวิร์คที่หมายเลขนี้
อยู่สามารถทำได้ถึง 4 วิธีคือ
only
1. FEDC:BA98:0000:0076:0000:1234:5678:9ABC/64
KKU
2. FEDC:BA98::76:0:1234:5678:9ABC/64
3. FEDC:BA98:0:76::1234:5678:9ABC/64
4. FEDC:BA98:0:76::/64
โดยทั่วไปแล้ววิธีที่ 4 เป็นที่นิยมสุด ในการระบุหมายเลขของเน็ตเวิร์คแต่หากจำเป็นต้องการระบุถึงหมายเลขของ
โฮสต์ด้วยจะใช้วิธีที่ 1 อย่างไรก็ตามเมื่อย่อแล้วสิ่งหนึ่งที่ต้องระวังถึง หากเราเขียนเป็น FEDC:BA98::0076/64 ซึ่งดู
เหมือนว่าจะไม่มีความผิดพลาดใดๆ แต่จะเป็นการหมายถึง FEDC:BA98:0000:0000/64 แทน ซึ่งมิใช่ที่ต้องการ
24.4 ประเภทของแอดเดรสแบบยูนิคาสท์
ใน IPv6 ได้กำหนดแอดเดรสแบบยูนิคาสท์ดังนี้
• Global unicast เดิมหมายถึงแอดเดรสแบบร่วมแอดเดรสยูนิคาสท์ (aggregation) แบบนี้จะไม่มีซํ้าใน
อินเทอร์เน็ต ทำให้สามารถส่งผ่านได้โดยตรง เสมือนหมายเลขจริงในแอดเดรสของ IPv4 การทำงานโดยใช้
แอดเดรสแบบร่วมทำให้สามารถลดเร้าติ้งเทเบิลในอินเทอร์เน็ตลง โดยแบ่งแอดเดรสออกตามรูปที่ 24.3
โดยที่
194 บทที่ 24. IPV6
– 48 บิตแรกเป็นเลขที่ใช้สำหรับ Service Provider โดยที่ 3 บิตแรกจะเป็น 001 ทำให้ glabal unicast
address อยู่ในช่วงตั้งแต่ 2000:: ถึง 3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
– 16 บิต เป็นหมายเลขที่ผู้ดูแลระบบสามารถใช้ เพื่อแบ่งซับเน็ตภายใน ทำให้สามารถมีได้ถึง 2 16
ซับเน็ต
– 64 บิตใช้เพื่อกำหนดส่วนของ Interface ID สามารถบรรจุ 48 บิต MAC address ได้
0 48 63
001 global routing prefix Subnet ID
Interface ID
รูปที่ 24.3: รูปแบบของ Global Address
book)
• Link local unicast แอดเดรสนี้เป็นแอดเดรสสำหรับ link ซึ่งแอดเดรสนี้จะถูกกำหนดขึ้นเพื่อใช้ในการ
ทำงานที่เกี่ยวข้องกับ auto-configuration, neighbor discovery หรือ กรณีที่ไม่พบเร้าเตอร์ แพกเกตที่
ถูกกำหนดในแอดเดรสนี้จะไม่ถูกส่งออกไปยัง link อื่นๆ ในกรณีนี้แอดเดรสจะขึ้นต้นด้วย FE80::/10 รูปที่
24.4 แสดงแอดเดรสแบบ Link local unicast
0 10 (partial 63
1111111010 0
only Interface ID
รูปที่ 24.4: รูปแบบของ Link Local Address
KKU
24.4.1 ประเภทของแอดเดรสแบบยูนิคาสท์อื่นๆ
เพื่อให้ครอบคลุมการกำหนดแอดเดรสของ IPv6 ได้มีการกำหนดหมายเลขพิเศษอื่นๆดังนี้
• Unispecified address : แอดเดรส 0:0:0:0:0:0:0:0 หรือ (::) แอดเดรสนี้จะถูกกำหนดเป็นแอดเดรส
ต้นทางของโนดที่ยังไม่มีแอดเดรสของตนเอง ก่อนที่จะเรียนรู้แอดเดรสของตน เสมือนแอดเดรส 0.0.0.0 ใน
แอดเดรส IPv4
• Loopback address : แอดเดรส 0:0:0:0:0:0:0:1 เป็น loopback แอดเดรส เพื่อส่งแพกเกต IPv6 กลับ
หาตนเอง เสมือนการใช้ 127.0.0.1 ในแอดเดรส IPv4
• Encoded NSAP addresses : เป็นการกำหนดขึ้นเพื่อใช้กับเครือข่ายแบบ OSI CLNP และแนวทางใน
การกำหนด NSAP ไปเป็น NSAP
• IPv4compatible address: แอดเดรส (::<IPv4 address>) ใช้ในกรณีที่โฮสต์ของ IPv6 ต้องการ tunnel
ผ่านเน็ตเวิร์ค ของ IPv4 โดยที่ IP address ของ IPv4-compatible address จะกำหนดให้ 96 บิตแรกเป็น
ศูนย์ทั้งหมด ตามด้วยแอดเดรสของ IPv4 32 บิต เช่น แอดเดรส 01.02.03.04 จะได้เป็น ::0102:0304
24.4. ประเภทของแอดเดรสแบบยูนิคาสท์ 195
• IPv4mapped address: แอดเดรส (::FFFF:<IPv4 address>) ใช้ในกรณีที่โฮสต์ของ IPv6 ต้องการ
สื่อสารกับโฮสต์ที่เป็น IPv4 โดยการใช้งานของ dual stack และ header translation เช่นโนดของ
IPv6 ต้องการส่งไปหาโฮสต์ IP address 01.02.03.04 จะใช้หมายเลขของปลายทางภาครับเป็น ::FFFF:
0102:0304
ตารางที่ 24.2 แสดง IPv6 address แบบต่างๆ
Address Type Binary prefix IPv6 notation
Unspecified 00...0 ::/128
Loopback 00...1 ::1/128
Multicast 11111111 FF00::/8
Link-local unicast 1111111010 FE80::/10
Global unicast everythig lese
book)
ตารางที่ 24.2: IPv6 แอดเดรสแบบยูนิคาสท์
24.4.2 Anycast Address
(partial
แอดเดรสแบบ anycast นี้ เป็นแอดเดรสที่กำหนดขึ้นเพื่อใช้ในการอ้างถึงหลายอินเตอร์เฟซพร้อมกัน โดยทั่วไปอาจ
อ้างถึงอินเตอร์เฟซที่อยู่คนละเร้าเตอร์กัน หากมีแพกเกตที่ส่งมายังแอดเดรส anycast นี้ แพกเกตนั้นจะถูกส่งไปหา
อินเตอร์เฟซที่อยู่ใกล้ที่สุด โดยขึ้นอยู่กับโพรโตคอลที่ใช้ ซึ่งแอดเดรสแบบ anycast นี้จะกำหนดขึ้นเพื่อใช้อ้างถึงเร้า
เตอร์เท่านั้น ไม่ใช้กับโฮสต์ และไม่สามารถที่จะเป็นแอดเดรสของต้นทางได้
only
เนื่องจากแอดเดรสของ anycast นี้เป็นแอดเดรสแบบยูนิคาสท์ ดังนั้นหากกำหนดแอดเดรส anycast นี้ จะ
ต้องกำหนดบนอินเตอร์เฟซของเร้าเตอร์โดยตรง การทำเช่นนี้เนื่องจากไม่สามารถแยกความแตกต่างกับแอดเดรส
ยูนิคาสท์อื่น รูปที่ 24.5 แสดงรูปแบบของแอดเดรสนี้
KKU 1111110111...111 Subnet pad (64-n bits) Anycast ID
Subnet prefix (n bit)
รูปที่ 24.5: รูปแบบของแอดเดรสแบบ Anycast
24.4.3 แอดเดรสแบบมัลติคาสท์
แอดเดรสแบบมัลติคาสท์ใน IPv6 ถือว่ามีความสำคัญอย่างมาก เนื่องจากมีการนำมาใช้ในหลายกรณี และใน IPv6
ไม่มีการใช้งานของบรอดคาสท์แล้ว การใช้งานของมัลติคาสท์เพื่อใช้ในการสร้าง multicast group และจะต้องไม่ใช้
เป็นแอดเดรสของภาคส่งต้นทาง หรือการใช้ในเฮดเดอร์ของเร้าเตอร์
การออกแบบของแอดเดรสแบบมัลติคาสท์ของ IPv6 อาศัยประสบการณ์จากการใช้งานของ Dartnet และ
MBone ตั้งแต่ปี 1988 และ 1992 ตามลำดับ โดยที่รูปแบบแอดเดรสแบบมัลติคาสท์ของ IPv6 แสดงในรูปที่ 24.6
การกำหนดแอดเดรสของมัลติคาสท์จะเริ่มต้นด้วย 11111111 ตามด้วย Flag ขนาด 4 บิต ดังแสดงในรูปที่
24.7 บิต T เพื่อแทน Transient (ชั่วคราว) หมายถึงเป็นหมายเลขของ multicast group แบบชั่วคราว หรือหาก
0 จะเป็นแบบ well-known address ในกรณี well-known address นี้จะถูกกำหนดโดย Internet Assigned
196 บทที่ 24. IPV6
0 7 11 15 63
11111111 Flags Scope
112-bit field
รูปที่ 24.6: รูปแบบของ Multicast Address
Number Authority (IANA) บิต P เพื่อระบุว่าเป็น unicast-prefix-base IPv6 multicast address [RFC3306]
บิต R แสดงถึงว่าเป็น rendezvous point (RP) address [RFC3956]
0 R P T
book)
รูปที่ 24.7: ค่าของ Flag ในแอดเดรสของมัลติคาสท์
ในส่วนของ Scope จะมีค่าตั้งแต่ 0 จนกระทั่งถึง 0xF ซึ่งเป็นการบอกถึงว่าแพกเกตแบบมัลติคาสท์นี้ควร
จะถูกส่งไปถึงที่ใด เช่นเราอาจต้องการส่ง Videoconference ไปในบริเวณเราเท่านั้น ไม่ควรจะถูกส่งออกไปยัง
อินเทอร์เน็ต ค่าของ Scope ถูกกำหนดในตารางที่ 24.3 การใช้งานของ Scope นี้สามารถทำได้เช่นกันใน IPv4
Scope Definition
0 (partial reserved
1 node-local
2
link-local
only 5 organization-local
site-local
8
E
global
reserved
F
KKU 3,4,6,7, 9-D unassigned
ตารางที่ 24.3: ค่าของ Scope
โดยการกำหนดค่าของ TTL แต่การใช้งานของ Scope ของ IPv6 ทำให้ดีกว่า อย่างไรก็ตามการใช้งานเพื่อให้อยู่ใน
ขอบเขตที่ต้องการ เช่นการทำ site local และ organization local เร้าเตอร์จะต้องทราบถึง link ใดอยู่ในที่ตั้ง
(site) หรือหน่วยงานที่ใช้
• แอดเดรสแบบมัลติคาสท์ที่กำหนดไว้แล้วและมีการใช้งานบ่อยครั้ง แสดงในตารางที่ 24.4
จุดประสงค์ IPv6 Address
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 local โนด (จำกัดที่โนด) FF01:0:0:0:0:0:0:1
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 link-local โนด FF02:0:0:0:0:0:0:1
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 node-local เร้าเตอร์ FF01:0:0:0:0:0:0:2
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 link-local เร้าเตอร์ FF02:0:0:0:0:0:0:2
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 site-local เร้าเตอร์ FF05:0:0:0:0:0:0:2
ตารางที่ 24.4: แอดเดรสแบบมัลติคาสท์ที่ใช้บ่อย
• Well-known แอดเดรสแบบมัลติคาสท์ที่กำหนดสำหรับโพรโตคอลเพื่อเร้าติ้ง แสดงในตารางที่ 24.5
24.5. สรุป 197
จุดประสงค์ IPv6 Address
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 link-local RIP เร้าเตอร์ FF02:0:0:0:0:0:0:9
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 link-local OSPF เร้าเตอร์ FF02:0:0:0:0:0:0:5
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 link-local OSPF DR เร้าเตอร์ FF02:0:0:0:0:0:0:6
แอดเดรสแบบมัลติคาสท์สำหรับทุก IPv6 link-local PIM เร้าเตอร์ FF02:0:0:0:0:0:0:D
ตารางที่ 24.5: Well-known แอดเดรสแบบมัลติคาสท์
• แอดเดรสแบบมัลติคาสท์ที่ถูกกันไว้ (reserved) ได้แก่ FF0X:0:0:0:0:0:0:0 โดย X เป็น 0 - F
24.5 สรุป
จากการที่ปัจจจุบันมีความต้องการในการใช้เน็ตเวิร์คอย่างมาก ทำให้มีความจำเป็นในการกำหนดหมายเลข IP ชุด
ใหม่เพื่อให้เพียงพอกับความต้องการ IPv6 เป็น IP address ชุดใหม่ที่ถูกกำหนดขึ้น
book) เพื่อรองรับการขยายตัวที่เกิด
ขึ้น เนื่องจากเป็นการกำหนดใหม่ IPv6 ได้แก้ไขปัญหาต่างๆที่เคยเกิดกับ IPv4 เพื่อให้เป็นไปทิศทางที่ดีขึ้น ตั้งแต่
รูปแบบของ IPv6 การใช้เฮดเดอร์ส่วนต่อขยายได้ (Entension header) ทำให้ลดการประมวลผลที่ไม่จำเป็นลง
อย่างไรก็ตาม เนื่องจากยังมีเร้าเตอร์จำนวนมากที่ไม่รองรับการทำงานของ IPv6 ในบทนี้ยังกล่าวถึงการทำงานร่วม
(partial
กันของทั้งสองโพรโตคอล โดยความแตกต่างสำคัญของโพรโตคอล IPv4 และ IPv6 สามารถสรุปได้ในตารางที่ 24.6
IPv6
IPv4
ขนาดของแอดเดรส 32 บิต 128 บิต
Flow Labels ไม่มี มี
only
Checksum ในเฮดเดอร์ มี ไม่มี
ข้อมูลการ Fragmentation ทุกดาต้าแกรม เป็นตัวเลือก
ตารางที่ 24.6: ความแตกต่างหลักของ IPv4 และ IPv6
KKU
24.6 คำถามท้ายบท
1. สถานะของ IPv4 และ IPv6 ในปัจจุบันเป็นอย่างไร?
2. แอดเดรสใน IPv6 แบ่งเป็นกี่ประเภทอะไรบ้าง?
3. การกำหนดแอดเดรสใน IPv6 มีการอ้างถึงการใช้ MAC address ในการกำหนด มีลักษณะเป็นอย่างไร?
4. อะไรคือการทำ Autoconfiguration?
5. Neighbor Discovery มีประโยชน์อย่างไรใน IPv6?
6. แนวทางการทำงานร่วมกันระหว่าง IPv4 และ IPv6 มีวิธีใดบ้าง อย่างไร?
7. จากตารางที่ 24.6 ผลของการเปลี่ยนแปลงหลักดังกล่าวทั้ง 4 ข้อทำให้มีข้อดีอย่างไร?
book)
(partial
only
KKU
บทที่ 25
เฮดเดอร์ส่วนต่อขยาย (Extension Headers)
จากประสบการณ์ของ IPv4 ทำให้การออกแบบ IPv6 เผื่อส่วนที่เรียกว่า Extension Headers หรือ เฮดเดอร์ส่วน
book) Source Routing เพื่อส่งแพก
ต่อขยาย เพื่อรองรับแพกเกตที่ต้องจัดการเป็นกรณีพิเศษ เช่น บางแพกเกตอาจทำ
เกตหรือ ในกรณีที่ต้องการการจัดการพิเศษสำหรับภาครับบางกรณี ดังนั้น IPv6 จึงออกแบบให้สามารถแทรกเฮดเด
อร์ส่วนต่อขยาย ระหว่างเฮดเดอร์ของ IP และ ส่วนบรรจุข้อมูล (Payload) แต่ละเฮดเดอร์จะกำหนดโดยประเภท
ของเฮดเดอร์ ตามด้วยเฮดเดอร์นั้น หรือ ส่วนบรรจุข้อมูลหากเป็นส่วนเฮดเดอร์ส่วนต่อขยายสุดท้าย
รูปที่ 25.1 แสดงตัวอย่างของเฮดเดอร์ส่วนต่อขยายของ IPv6
(partial ในแพกเกตแรกจะเป็นกรณีที่แพกเกตไม่มีส่วน
เฮดเดอร์ส่วนต่อขยายใดๆ แพกเกตที่สองแสดงถึงกรณีที่มีการเพิ่มเติมของ Routing Header เป็นเฮดเดอร์ส่วนต่อ
ขยายสุดท้ายเป็นกรณีของเฮดเดอร์ส่วนต่อขยายที่ประกอบด้วย Routing Header และ Fragment Header
only
KKU
รูปที่ 25.1: เฮดเดอร์ Extension ของ IPv6
สังเกตว่าในรูปที่ 25.1 ปกติเฮดเดอร์ของ IPv6 หากไม่มีการกำหนดเฮดเดอร์ส่วนต่อขยายใดๆ ค่า Next = TCP
จะถูกกำหนดไว้ แต่หากมีส่วนเฮดเดอร์ส่วนต่อขยาย ส่วนนี้จะถูกเลื่อนออกไปอยู่ส่วนสุดท้าย ค่าของเฮดเดอร์ส่วน
ต่อขยายที่สำคัญดังแสดงในตารางที่ 25.1
25.0.1 เฮดเดอร์เพื่อเร้าติ้ง (Routing Header)
กรณีของเฮดเดอร์ Routing Extension จะคล้ายกับการทำงานของ source routing เฮดเดอร์จะประกอบ IP
Address ของโนดที่ส่งผ่าน ใน IPv4 กำหนดการทำ Source routing ในสองลักษณะคือ Loose Source และ
Strict Source routing ในแบบแรกจะเป็นการกำหนดเร้าเตอร์ที่แพกเกตจะถูกส่งผ่านเพื่อไปยังภาครับ แต่ในกรณี
นี้เส้นทางอาจเปลี่ยนแปลงได้ วิธีที่สองกำหนดเร้าเตอร์ที่ต้องผ่าน โดยไม่สามารถหลีกเลี่ยงได้ ใน IPv6 Routing
Header ได้ถูกกำหนดใน RFC 2460 รูปแบบของเฮดเดอร์แสดงในรูปที่ 25.2
• Next Header : บอกถึงประเภทของเฮดเดอร์ที่ตามมาใน Routing header (43)
199
200 บทที่ 25. เฮดเดอร์ส่วนต่อขยาย (EXTENSION HEADERS)
Next Header Type Value Notes
Hop-by-hop options 0
Routing 43
Fragment 44
Encrypted Security payload 50
Authentication 51
Destination Options 60
No Next Header 59 กรณีที่ไม่มีเฮดเดอร์ใดๆตามมา
ตารางที่ 25.1: ค่าต่างๆที่ใช้ในฟิลด์ของ IPv6 Next Header
Next Header Hdr Ext. Len Routing Type Segments left
Reserved
IPv6 Address (1) book)
IPv6 Address (2)
(partial
. . .
IPv6 Address (N)
only
รูปที่ 25.2: Routing Extension Header
• Header Extension Lenght: ความยาวของ extension header
KKU
• Routing Type: ปัจจุบันที่ได้รับการกำหนดแน่นอนแล้วคือ Source routing (Type = 0) และ Nimrod
network architecture (Type = 1)
• Segments Left: ใช้เพื่อระบุจำนวนโนดที่จะต้องผ่านเพื่อไปยังภาครับ หากมีค่าเป็น 0 แสดงว่าแพกเกตนั้น
ถึงภาครับแล้ว
25.0.2 เฮดเดอร์เพื่อแบ่งข้อมูล (Fragment Header)
จากที่ได้กล่าวไปแล้ว เนื่องจากศักยภาพของเน็ตเวิร์คในการรองรับขนาดของแพกเกตที่ไม่เท่ากัน การส่งผ่านจาก
เน็ตเวิร์คหนึ่งไปยังอีกเน็ตเวิร์คหนึ่ง ใน IPv4 เร้าเตอร์ต้องแบ่งเป็นแพกเกตให้มีขนาดเล็กลง เพื่อให้สามารถส่งผ่าน
แพกเกตนั้นได้ นอกจากมีการกำหนดบิต don't fragment เป็นลอจิก 1 เท่านั้น เพื่อไม่ให้แบ่งแพกเกต ดังนั้น เพื่อ
ลดภาระของเน็ตเวิร์ค ใน IPv6 จะไม่รองรับการแบ่งแพกเกต หากแพกเกตที่ส่งมีขนาดใหญ่เกินกว่าฮอปถัดไปจะ
สามารถรองรับได้ แพกเกตจะถูกกำจัดทิ้งไป และเมสเสจของ ICMP จะถูกส่งกลับไปยังต้นทาง เพื่อให้ต้นทางแบ่ง
แพกเกตที่จะส่งนั้นก่อน ตัวอย่างที่เห็นได้ชัดคือ การส่งผ่านแพกเกตของ IPv6 ไปยังอีเทอร์เน็ต ซึ่งสามารถรองรับได้
เพียง 1500 ไบต์เท่านั้น หากมีขนาดของแพกเกตที่สูงกว่านั้น จำเป็นจะต้องแบ่งออกเป็นส่วนๆ โดยที่ในแต่ละส่วน
จะถูกส่งต่ออย่างอิสระ ไม่จำเป็นต้องไปในเส้นทางเดียวกัน ดังนั้นในส่วนของ fragment header จะต้องมีข้อมูล
เพียงพอที่จะทำให้ภาครับสามารถประกอบเฟรมกลับมาได้ ดังแสดงในรูปที่ 25.3
201
Next Header = 44 Reserved Fragment offset (13 บิต) Res M
Reserved
รูปที่ 25.3: เฮดเดอร์ของ IPv6 ในการทำ Fragment (Fragment Header )
• Next Header: ใช้ในการระบุโพรโตคอลเฮดเดอร์ที่ตามมา
• Reserved: ใส่เป็น 0 สำหรับการส่ง ไม่ทำอะไรเมื่อได้รับ
• Fragment Offset: ฟิลด์ขนาด 13 บิตทำงานคล้ายกับของ IPv4 ในการใช้ระบุตำแหน่งของ fragment
book)
• Res: สำรองใส่เป็น 0 สำหรับการส่ง ไม่ทำอะไรเมื่อได้รับ
• M flag: ทำนองเดียวกันกับ IPv4 เมื่อ M = 1 คือมี fragment ถัดไป หาก M = 0 เป็น fragment สุดท้าย
(partial
• Identification: ฟิลด์ขนาด 32 บิตเพื่อใช้ระบุแพกเกตหากเป็นแพกเกตเดียวกันจะมีเลขเดียวกัน เพื่อให้
ภาครับสามารถทราบในการประกอบแพกเกตกับดังเดิม และกำจัดทิ้งหากเป็นแพกเกตที่ได้รับแล้ว
โดยทั่วไปแพกเกตของ IPv6 ประกอบด้วยสองส่วนคือ ส่วนที่ไม่สามารถแบ่งได้ เรียกว่า Unfragmentable
Part เช่น เฮดเดอร์ของ IPv6 และเฮดเดอร์ส่วนต่อขยายต่างๆ ที่จำเป็นในการทำงานที่โนดต่างๆระหว่างสื่อสาร
และส่วนที่สามารถแบ่งได้ Fragmentable Part ส่วนที่เหลือทั้งหมด เช่น เฮดเดอร์ส่วนต่อขยายที่สามารถประมวล
ผลที่ปลายทาง โดยไม่มีผลต่อการทำงานและส่วนข้อมูลของเลเยอร์ถัดไป รูปที่ 25.4 แสดงรูปแบบของแพกเกตที่ถูก
แบ่งออก 3 fragment ย่อย only
KKU
รูปที่ 25.4: แพกเกตที่เกิดการแบ่งออกเป็นส่วนๆ
25.0.3 เฮดเดอร์เพื่อความปลอดภัย (Security Header)
การทำงานของ IPv6 สนับสนุนการรักษาความปลอดภัยสองประเภท คือ Authentication Header (AH) และ
Encrypted Security Payload (ESP) การทำงานของ AH จะใช้เพื่อตรวจสอบว่าแพกเกตที่ส่งไม่ได้ถูกปรับเปลี่ยน
202 บทที่ 25. เฮดเดอร์ส่วนต่อขยาย (EXTENSION HEADERS)
IPv6 header (next header = 51)
Next Header Length Reserved
Security parameter index
Sequence number field
Authentication data (variable length
Payload, eg. TCP in clear text
book)
รูปที่ 25.5: Security Header โดยใช้ Authentication header
IPv6 header (next header = 50)
(partial
Security parameter index
Encryption parameters and encrypted payload as specified by the
only
chosen algorithm
KKU
รูปที่ 25.6: Security Header โดยใช้ Encrypted Security Payload
ระหว่างการสื่อสาร การใช้ AH จะไม่ได้มีผลกับส่วนส่วนบรรจุข้อมูล (payload) ในขณะที่ ESP สนับสนุนการทำการ
พิสูจน์ทราบตัวตน (authentication) และการเข้ารหัสส่วนบรรจุข้อมูล ทำให้ไม่สามารถแก้ไขได้ระหว่างส่ง
รูปแบบของ authenticated header ค่อนข้างง่าย เริ่มจากเฮดเดอร์ขนาด 64 บิตของ เฮดเดอร์ถัดไป ความ
ยาวของเฮดเดอร์ขนาด 32 บิต และอีกที่สำรองไว้อีก 16 บิตให้เป็น 0 ทั้งหมด ถัดไปเป็น 32 บิตของ ของ
Security Paramenter Index ที่เกี่ยวข้อง ตามด้วย authentication data ที่ถูกเข้ารหัสแบบ 32 บิต การทำงาน
ของ encrypted security payload เริ่มต้นด้วย 32 บิตของ Security Paramenter Index ตามด้วยข้อมูลที่ถูก
encrypted ซึ่งกรณีนี้ขึ้นอยู่กับอัลกอริทึมที่ใช้ การทำงานของ Security header จะได้กล่าวในรายละเอียดต่อไป
ใน หัวข้อ 34.5.3 เรื่องความปลอดภัยใน Network Layer
25.0.4 เฮดเดอร์เพื่อข้อมูลเพิ่มเติมของโนดปลายทาง (Destination Options Header)
การใช้งานเฮดเดอร์ของ Destination Options เพื่อส่งข้อมูลเพิ่มเติมให้กับโนดปลายในการประมวลผลเท่านั้น ไม่
เกี่ยวข้องกับการทำงานของโนดระหว่างทาง ซึ่งกำหนดให้ค่าของฟิลด์ Next Header เป็น 60 รูปที่ 25.7 แสดงรูป
แบบของ Destination Option
203
Next Header = 60 Hdr Ext Len Reserved
Option
รูปที่ 25.7: Destination Option header
25.0.5 Hop-by-Hop Options
การทำงานของเฮดเดอร์เพื่อข้อมูลเพิ่มเติมของโนดปลายทาง (destination option header) เป็นการทำงานปกติ
book)
ของส่วนเฮดเดอร์ส่วนต่อขยาย (extension header) ซึ่งจะประมวลผลเมื่อแพกเกตถึงปลายทาง เป็นไปตามข้อ
กำหนดของ IPv6 ที่ไม่ต้องการให้มีการประมวลผลที่ไม่จำเป็นระหว่างการส่งผ่าน อย่างไรก็ตามในการจัดการบาง
ประเภทต้องการที่ข้อมูลเพื่อส่งไปให้เร้าเตอร์ต่างๆ ซึ่งถือว่าเป็นจุดประสงค์ของ hop-by-hop options ซึ่งจะระบุ
โดยเป็นเฮดเดอร์ type 0 และ null ในเฮดเดอร์ ถัดไปในเฮดเดอร์ของ IPv6 ซึ่งจำเป็นต้องประมวลผล แม้ว่า
(partial
แอดเดรสปลายทางจะไม่ใช้โนดที่อยู่ภายใน
รูปแบบของ hop-by-hop options จะเหมือนกับของ destiation options การทำงานของ hop-by-hop
options จะเข้ารหัสเช่นเดียวกันกับ destination options หนึ่งในตัวเลือก (option) คือส่วนบรรจุข้อมูลแบบจัม
โบ (jumbo payload) ที่ค่า type = 194 ซึ่งใช้ในการส่งแพกเกตที่มีขนาดใหญ่ ที่ไม่สามารถที่จะเข้ารหัสแบบ 16
บิตได้ หากมีการใช้ option นี้ ฟิลด์ Length ของ IPv6 จะถูกกำหนดให้เป็นลอจิก 0 ภาครับปลายทางจะตรวจสอบ
only
จากส่วนบรรจุข้อมูลเพื่อหาความยาวของแพกเกต การใช้งานของส่วนบรรจุข้อมูลแบบจัมโบ (jumbo payload)
ไม่ควรจะใช้หากความยาวมีค่าน้อยกว่า 65,535 ไบต์ หรือหากมีการแบ่งข้อมูล (fragment)
KKU
25.0.6 ไม่มีเฮดเดอร์อื่นๆตามมา (No Next Header)
หากไม่มีเฮดเดอร์ใดๆตามมา ค่าของ Value จะเท่ากับ 59
25.0.7 การลำดับเฮดเดอร์ส่วนต่อขยาย
IPv6 ได้กำหนดลำดับของการประมวลผลของเฮดเดอร์ตามลำดับดังนี้
1. IPv6
2. Hop-by-hop options
3. Destination options (1)
4. Routing
5. Fragment
6. Authentication
7. Destination Options (2)
204 บทที่ 25. เฮดเดอร์ส่วนต่อขยาย (EXTENSION HEADERS)
8. Upper-layer (for exmaple, TCP หรือ UDP)
แต่ละเฮดเดอร์สามารถที่จะมีหรือไม่มีก็ได้ ไม่จำเป็นต้องใส่ hop-by-hop ถ้าหากไม่มีการใช้งานจริง ซึ่งส่วน
ของการ fragment อาจไม่เกิดขึ้นหากขนาดของข้อมูลเล็กกว่าขนาดของ MTU บนเส้นทางที่จะส่ง ลำดับที่จัดให้
เป็นเพื่อการแนะนำในการพัฒนา จะเห็นว่าส่วนของ destination option จะถูกบรรจุไว้สองส่วน หากเราต้องการ
ให้ส่วนนี้ถูกให้ทุกโนดประมวลเช่นในการทำ tunnelling เราจะใส่ในส่วนนี้ก่อนส่วนของเร้าติงเฮดเดอร์ ในทางตรง
ข้ามหากต้องการส่งผ่านไปยังปลายทาง เราจะแทรกไว้ก่อนเฮดเดอร์ของเลเยอร์
book)
(partial
only
KKU
บทที่ 26
โปรโตคอลสำคัญของ IPv6
book)
26.1 Internet Control Message Protocol สำหรับ IPv6
Internet Control Message Protocol (ICMP) ถูกใช้งานสำหรับการแจ้งกรณีเกิดความผิดพลาด การตรวจสอบ
ระบบเครือข่าย และอื่นๆที่ได้กล่าวไปแล้วใน 19.3 การใช้งานใน IPv6 เรียกว่า ICMPv6 โดยการนำไปใช้กับ IPv6
นี้ บางฟังก์ชันที่ไม่ได้ใช้งานได้ถูกยกเลิกไป และขยายฟังก์ชันการทำงานให้ครอบคลุมฟังก์ชันอื่นๆเพิ่มขึ้น เช่น ARP
และ IGMP รวมถึงการทำงานเพิ่มเติมที่ไม่มีการก่อน ทำให้ ICMPv6 ที่เกิดขึ้นไม่สามารถที่จะใช้ร่วมกับ ICMP เดิม
ได้ การกำหนด ICMPv6 ให้ type เป็น 58 (partial
0 7 15 31
only ICMP body
Type Length Checksum
KKU รูปที่ 26.1: เฮดเดอร์ของ ICMPv6
• Type: แสดงถึงประเภทของเมสเสจ
• Code: แสดงถึงรายละเอียดเพิ่มเติมของ type ของ ICMP Message
• Checksum: เนื่องจากใน IPv6 ไม่มีฟิลด์ของการ checksum นี้ ทำให้ต้องมีการเพิ่มส่วนนี้ เพื่อป้องกัน
ความผิดพลาดที่อาจเกิดขั้นในส่วนของ ICMP message และส่วนของ pseudo header โดยที่ pseudo
header ประกอบไปด้วย IP Address ของภาคส่งและภาครับ ความยาวของส่วนบรรจุข้อมูล (payload)
และส่วนของเฮดเดอร์ถัดไป ดังแสดงในรูปที่ 26.2 ซึ่ง pseudo header ไม่ได้ส่งไปจริง แต่ใช้ในการคำนวณ
เท่านั้นและจะถูกกำจัดทิ้งไป
• ICMP body: ข้อมูลของ ICMP
ICMPv6ได้แบ่งICMPMessageออกเป็นสองกลุ่มได้แก่กลุ่มของการแจ้งความผิดพลาด(ICMPErrorMessage)
และกลุ่มของข้อมูลอื่นๆ (ICMP Information Message)
205
206 บทที่ 26. โปรโตคอลสำคัญของ IPV6
Source Address
Pseudoheader
Destination Address
Payload Length
book)
0x000000 Next: 58
Type Length Checksum
(partial
ICMP body
รูปที่ 26.2: Pseudo header ของ ICMPv6
only
ICMPv6 Error Message
KKU Type Code รายละเอียด
ค่าของ Type ของ error message มีค่าตั้งแต่ 0 - 127 ตารางที่ 26.1 เป็นตัวอย่างค่าที่กำหนดขึ้น
Destination unreachable 1 0 No Route to Destination
1
Communication with Destination
Administratively Prohibited
3 Address Unreachable
4 Port Unreachable
Packet too big 2 0 size MTU > Link
Time exceeded 3 0 (Hop Limit Exceeded in Transit
Parameter problem (problem with 4 0 Erroneous Header
the field of the IPv6 header or Field Encountered
extended headers)
1 Unrecognized Next
Header Type Encountered
2 Unrecognized IPv6 Option Encountered
Option Encountered
ตารางที่ 26.1: ICMPv6 Error Message
26.1. INTERNET CONTROL MESSAGE PROTOCOL สำหรับ IPV6 207
ICMP Informational Messages
ค่าของ Type ของ Informational message มีค่าตั้งแต่ 128- 255 ตารางที่ 26.2 เป็นตัวอย่างค่าที่กำหนดขึ้น
Type ส่งจาก รายละเอียด
Echo request 128 โฮสต์ ใช้ในการทำงานของ ping6
Echo reply 129 เร้าเตอร์ ใช้ในการตอบกลับจาก ping
Router solicitation (RS) 133 โฮสต์ trigger a router advertisement
Router advertisement (RA) 134 เร้าเตอร์ สำหรับโฮสต์ทำ stateless autoconfiguration
Neighbor solicitation (NS) 135 โฮสต์, เร้าเตอร์ ใช้ในการค้นหา MAC ของ neighbor
Router advertisement (RA) 136 โฮสต์, เร้าเตอร์ ตอบกลับจาก neighbor solicitation
Redirect 137 เร้าเตอร์ แจ้งโฮสต์ให้ใช้ฮอปถัดไปอื่นเพื่อไปยังปลายทาง
ตารางที่ 26.2: ICMPv6 Information Message
book)
26.1.1 Neighbor Discovery
(partial
Neighbor Discovery (ND) เป็นฟังก์ชันหนึ่งที่สำคัญใน ICMP การทำงานของ ND ทำให้สามารถจะระบุถึงโฮสต์
หรือเร้าเตอร์ที่อยู่ในซับเน็ตหรือ Link เดียวกัน เพื่อให้ทราบถึง MAC Address (ใน IPv6 จะใช้คำว่า link address)
ที่ของโฮสต์หรือ เร้าเตอร์ที่จะส่งไป การทำงานของ ND เสมือนการทำงานของ ARP บนอีเทอร์เน็ตใน IPv4
ใน IPv6 แต่ละโนดจะ join ไปยัง solicited node multicast group โดยมีเลข IP address ประกอบด้วย 104
บิต ff02:0:0:0:0:1:ff00::/104 ตามด้วย 24 บิตของยูนิคาสท์หรือ anycast เมื่อโนดต้องการค้นหา link address
only
ของโนดอื่นที่อยู่บน link เดียวกัน โนดจะส่ง neighbor solicitation ไปยัง solicited node รวมทั้งแทรก MAC
address ของตนด้วย ทำให้ neighbor ทราบว่าจะส่งกลับไปที่ใด
การทำงานของ ND ทำให้โฮสต์ทราบถึงเลขชุดหน้าของ IP address โดยที่เร้าเตอร์จะส่งข้อมูลของเลขชุดหน้า
KKU
ไปยัง link ที่เชื่อมต่อโดยตรง ทำให้โฮสต์ที่อยู่ใน link สามารถทราบถึงแอดเดรสใดอยู่บน link และ link ใดสามารถ
ที่สามารถเข้าถึงได้โดยผ่านเร้าเตอร์
นอกจากนี้ การทำงานของ ND ยังช่วยให้สามารถตรวจสอบว่าโนด neighbor ยังอยู่ในระบบหรือไม่ (Neighbor
Unreachability Detection) โดยโนดอาศัย ND โพรโตคอลเพื่อสอบถามไปยัง neighbor หากไม่มีการตอบกลับ
แสดงว่ามีปัญหาเกิดขึ้นกับโนดนั้นๆ ระบบจะยกเลิก MAC address ของ neighbor นั้น และเข้าสู่ขบวนการส่งมัลติ
คาสท์เพื่อทำ neighbor discovery
การทำงานของ ND จะใช้แพกเกตของ ICMPv6 ประกอบด้วยแพกเกตต่างๆได้แก่ Router Solicitation,
RouterAdvertisement, Neigbor Solicitation, NeighborAdvertisement และ Redirectดังแสดงรายละเอียด
ในตาราง 26.2
26.1.2 Statless Address Autoconfiguration
การใช้งานเร้าเตอร์และโฮสต์บนอินเตอร์เฟซหนึ่งๆของ IPv6 จะต้องกำหนด link-local adddress เสมอ โดยทั่วไป
แล้ว link-local address จะได้มาจากการ MAC Address ของอินเตอร์เฟซ เพื่อป้องกันการซํ้ากันของหมายเลข
ที่กำหนด การตรวจสอบหมายเลขของ IP Address จะใช้ อัลกอริทึมที่เรียกว่า Duplicate Address Detection
(DAD) ทั้งนี้การทำงานของ DAD จะทำทุกครั้งของการกำหนดแอดเดรส โดยอาศัยโพรโตคอลของ ND
จากนั้นเมื่อได้ link-local address การกำหนด global IPv6 address สามารถทำได้โดยการทำงานของ
statless address autoconfiguration ทำให้โฮสต์สามารถกำหนดแอดเดรสได้เอง โดยไม่จำเป็นต้องอาศัยผู้ดูแล
208 บทที่ 26. โปรโตคอลสำคัญของ IPV6
ระบบเข้าช่วยเหลือ หรือเซิร์ฟเวอร์เพิ่มเติมในระบบนอกเหนือจากเร้าเตอร์ การกำหนดแอดเดรสนี้ โฮสต์อาศัยเลข
ชุดหน้าที่ได้รับจาก Router Advertisement ในการกำหนด global address แม้ว่าการกำหนดแอดเดรสนี้จะ
ต้องการเร้าเตอร์ในการช่วยเหลือ แต่ยังถือว่า stateless เนื่องจากเร้าเตอร์ไม่จำเป็นมีข้อมูลใดว่าโฮสต์จะกำหนด
หมายเลขใด
การทำงานของ IPv6 จะรองรับการทำงานของ address autoconfiguration แต่ IPv6 ยังคงรองรับการทำงาน
ของ DHCPv6 โดยการใช้งานของ DHCPv6 เพื่อให้ผู้ดูแลระบบสามารถควบคุมการกำหนดแอดเดรสได้ ในขณะที่
การใช้งานของ stateless autoconfiguration ไม่สนใจว่าจะใช้หมายเลขใดในการสื่อสารตราบเท่าที่ IP Address
นั้นไม่ซํ้าและสามารถสื่อสารได้ ซึ่งจากที่กล่าวมาแล้วการตรวจสอบว่าซํ้าหรือไม่ เป็นหน้าที่ของ DAD ไม่ว่าแอดเดรส
นั้นจะได้มาจากการทำงานของ DHCPv6 หรือ stateless autoconfiguration
26.2 จาก IPv4 ไปสู่ IPv6
book)
แม้ว่า IPv6 จะได้รับการพัฒนาขึ้น และดูเหมือนว่า IPv6 สามารถรองรับการทำงานพื้นฐานตามกำหนดเป็นที่
เรียบร้อยแล้ว คำถามจึงเกิดขึ้นว่าเมื่อใดเราจึงจะเริ่มใช้งาน IPv6 อย่างจริงจัง เป็นไปได้หรือไม่ที่เราจะเปลี่ยน
ทั้งหมดเป็น IPv6 ทันที ในเชิงปฎิบัติแล้ว เป็นไปได้ยากมาก เนื่องจากทั่วโลกยังมีเร้าเตอร์อีกจำนวนมากที่ไม่สามารถ
รองรับ IPv6 ได้ ทำให้เราต้องหาแนวทางในการทำให้ IPv4 และ IPv6 สามารถทำงานได้อย่างพร้อมกัน จนกระทั่ง
ระบบส่วนใหญ่เป็น IPv6 ด้วยเหตุผลดังกล่าวทำให้ IETF นำเสนอแนวทางในการใช้ร่วมกัน 3 วิธี ได้แก่ Dual stack,
Tunneling และ Header Translation (partial
26.2.1 Dual Stack
only
วิธีแรกที่สามารถทำได้คือการให้ทุกโฮสต์สามารถทำงานได้ทั้งสองระบบ เพื่อรอจนกระทั่งการทำงานทั้งหมดเป็น
IPv6 หรือเรียกว่าการทำงานแบบ dual stack หมายถึงการทำงานทั้ง IPv4 และ IPv6 ไปพร้อมกัน ดังแสดงในรูป
KKU
ที่ 26.3
รูปที่ 26.3: IPv6 dual stack
หลักการของ dual-stack ไม่ถือว่าเป็นวิธีการที่ใหม่ ในอดีตได้มีการใช้งานของ dual-stack ใน LAN กับ
Novell's Netware มาแล้ว ในการงานของร่วมระหว่าง IPv4 และ IPv6 การที่จะส่งโดยใช้เวอร์ชันใด พิจารณาจาก
การตรวจสอบไปยัง DNS หากพบว่า DNS ตอบกลับด้วย IPv4 Address ภาคส่งจะส่งโดยแพกเกตของ IPv4 ใน
ทำนองเดียวกัน หาก DNS ตอบกลับเป็น IPv6 Address ภาคส่งจะส่งด้วยแพกเกตของ IPv6
26.2. จาก IPV4 ไปสู่ IPV6 209
26.2.2 Tunneling
หาก IPv6 ต้องการที่จะสื่อสารผ่าน IPv4 ในที่ติดตั้งไว้แล้ว เช่นการสื่อสารระหว่างโฮสต์ดังแสดงในรูปที่ 26.4 การ
ทำ Tunneling เป็นวิธีที่ค่อนข้างง่าย โดยแพกเกตของ IPv6 จะถือเป็น payload ในดาต้าแกรมของ IPv4 หรือก็คือ
การใส่เฮดเดอร์ของ IPv4 ให้กับแพกเกต IPv6 โดยฟิลด์โพรโตคอลใน IPv4 จะมีค่าเท่ากับ 41 (Protocol = 41) การ
ทำงานดังกล่าวเรียกว่า automatic tunneling สามารถทำงานโดยไม่จำเป็นต้องติดตั้งข้อมูลเพิ่มเติม แต่หมายเลข
ของ IPv6 address ต้องเป็นแบบ IPv4 compatible address เท่านั้น
book)
(partial
รูปที่ 26.4: IPv6 automatic tunneling
only
หากแอดเดรสของโฮสต์ไม่ใช่IPv4-compatibleaddressระบบมีความจำเป็นต้องใช้การทำงานแบบconfigured
tunneling ซึ่งต้องมีกำหนดหมายเลขของ IPv4-mapped address ที่ต้นทางและปลายทางของจุดที่ทำ tunnel
รูปที่ 26.5 แสดงตัวอย่างการทำ configured tunneling ระหว่างเร้าเตอร์ไปเร้าเตอร์ (เร้าเตอร์-เร้าเตอร์) โดยมีจุด
KKU
ต้นและจุดปลายในที่นี้คือ เร้าเตอร์ X และเร้าเตอร์ Y ตามลำดับ ดังนั้น สังเกตว่าเฮดเดอร์ของ IPv4 จะกำหนดให้
แอดเดรสของภาคส่งเป็น เร้าเตอร์ X ในขณะที่ปลายทางเป็น เร้าเตอร์ Y การ tunneling แบบอื่นๆที่อาจเกิดขึ้น
ได้แก่ เร้าเตอร์-โฮสต์, โฮสต์-โฮสต์ และโฮสต์-เร้าเตอร์ tunneling
รูปที่ 26.5: IPv6 configured tunneling
210 บทที่ 26. โปรโตคอลสำคัญของ IPV6
26.2.3 Header Translation
อีกหนึ่งวิธีคือการทำ Header Translation หรือการแปลงจาก IPv6 เป็น IPv4 หรือในทางกลับกันเช่น การทำงาน
ของ Header Translation เป็นการใช้ IPv4-mapped address โดยที่เฮดเดอร์ของ IPv6 address จะถูกแทนที่
ด้วยเฮดเดอร์ของ IPv4 address ของภาครับ รูปที่ 26.6 แสดงการทำงานดังกล่าว สังเกตว่าเฮดเดอร์ของ IPv6 จะ
เปลี่ยนเป็นเฮดเดอร์ของ IPv4 ในกรณีนี้
book)
(partial
รูปที่ 26.6: IPv6 header translation
26.3 เร้าติ้งโพรโตคอลบน IPv6
only
เนื่องจากขนาดของ IP address ที่เพิ่มขึ้นใน IPv6 ทำให้มีความจำเป็นในการแก้ไขรูปแบบของโพรโตคอลที่เกี่ยวข้อง
ดังนั้น เมื่อกล่าวถึงเร้าติ้งโพรโตคอล เราคงหลีกเลี่ยงไมได้ที่จะกล่าวถึงสองโพรโตคอลที่สำคัญคือ RIP และ OSPF
KKU
โพรโตคอล RIPng เป็นเวอร์ชันของ RIP ใน IPv6 โดยที่ ng ย่อมาจาก next generation การทำงานของ RIPng
จะใช้จำนวนฮอปเป็น metric เหมือนใน RIPv2 รวมไปถึงการทำงานเชิงเวลาต่างๆ ข้อแตกต่างที่สำคัญของ RIPng
และ RIPv2 ได้แก่ การแก้ไขรูปแบบของแพกเกตให้มีขนาดที่ใหญ่ขึ้นเพื่อรองรับ IPv6 address และการใช้ความ
ปลอดภัยจาก IPv6 โดยตรง แทนที่จะใช้การทำการพิสูจน์ทราบตัวตน (authentication) เหมือน RIPv2 ตารางที่
26.3 เปรียบเทียบการทำงานพื้นฐาน RIP เวอร์ชันต่างๆ
RIPv1 RIPv2 RIPng
แอดเดรส IPv4 IPv4 IPv6
metric ฮอป ฮอป ฮอป
การแลกเปลี่ยนข้อมูล บรอดคาสท์ บรอดคาสท์ มัลติคาสท์
อัลกอริทึมที่ใช้ Bellman Ford Bellman Ford Bellman Ford
VLSM/CIDR ไม่ได้ ได้ v6-based
ตารางที่ 26.3: เปรียบเทียบการทำงานพื้นฐาน RIP เวอร์ชันต่างๆ
โพรโตคอล OSPF สำหรับ IPv6 หรือ OSPFv3 มีการเปลี่ยนแปลงจากเดิมน้อยมาก การทำงานของ OSPFv3
จะใช้ link local IPv6 address และ multicast address นอกจากนี้ link-state database ของทั้ง IPv4 และ
IPv6 จะเป็นอิสระต่อกัน เร้าเตอร์สามารถทำงานทั้งสองโพรโตคอลพร้อมกันได้
บทที่ 27
Transport Layer
book) Albert Einstein
If the facts don't fit the theory,
change the facts.
(partial
หากเราเปรียบเทียบการทำงานของเน็ตเวิร์คเสมือนการส่งจดหมายจากต้นทางไปยังปลายทาง โดยไม่สนใจ
ว่าการส่งนั้นเกิดขึ้นได้อย่างไร ถือเป็นหน้าที่ของไปรษณีย์ที่ให้บริการ การทำงานของเร้าเตอร์จะ เสมือนสำนักงาน
ไปรษณีย์พร้อมด้วยเจ้าหน้าที่ไปรษณีย์ เพื่อรับผิดชอบในการคัดกรองจดหมายเพื่อไปถึงปลายทางให้เร็ว และ
ประหยัดแรงงานมากที่สุด ในส่วนของ Transport Layer จะเทียบได้กับผู้ตรวจสอบความครบถ้วนของการส่ง
แต่ละครั้ง ซึ่งหากพบว่ามีการส่งที่ไม่ครบถ้วน อาจมีการกำกับให้มีการส่งใหม่ เพื่อให้ผู้รับบริการพอใจมากที่สุด
only
การทำงานของ Transport Layer เป็นการจัดการระหว่างต้นทางกับปลายทาง หรือเรียกว่าแบบ End-to-End
ดังแสดงในรูปที่ 27.1 โดยแต่ละโนดจะประกอบด้วยโปรเซสที่ทำงานอยู่ภายใน เพื่อความคุมการส่งข้อมูลที่เกิดใน
เน็ตเวิร์คเป็นไปอย่างถูกต้อง รวมไปถึงลดความคับคั่งที่อาจเกิดขึ้น หรือแม้แต่การส่งข้อมูลจากต้นทางไปยังปลาย
KKU
ทางซํ้าอีกครั้ง แม้ว่าการเชื่อมต่อระหว่างโนดต้นทางไปและปลายทาง อาจมีการสื่อสารผ่านเน็ตเวิร์คที่แตกต่าง เช่น
อีเทอร์เน็ต WLAN หรือ Asynchronous Transfer Mode (ATM) ทั้งหมดเพื่อเชื่อมต่อการสื่อสารเท่านั้น แต่มิได้
รวมถึงการตรวจสอบและแก้ไขเหตุการณ์ที่อาจเกิดขึ้นระหว่างที่ส่งข้อมูล เช่น การตรวจสอบว่ามีการส่งข้อมูลที่เกิน
ความสามารถของเน็ตเวิร์ค ทำให้พบว่ามีการสูญหายของข้อมูล เป็นต้น
รูปที่ 27.1: การสื่อสารของเลเยอร์ Transport
เพื่อรองรับความไม่แน่นอนของการส่งข้อมูล Transport Layer ถูกใช้เพื่อแก้ปัญหาดังกล่าว โดยประกอบ
211
212 บทที่ 27. TRANSPORT LAYER
ด้วยสองโพรโตคอลที่สำคัญได้แก่ User Datagram Protocol (UDP) เพื่อให้การส่งข้อมูลไปถึงโปรเซสที่ต้องการ
อย่างถูกต้อง แม้ว่าจะไปถึงอย่างไม่เป็นลำดับหรือมีบางส่วนตกหล่นไปบ้างก็ตาม ในขณะที่อีกหนึ่งโพรโตคอลคือ
Transport Control Protocol (TCP) จะคำนึงถึงการตรวจสอบความผิดพลาดที่อาจเกิดขึ้น เช่น การส่งไม่เป็นตาม
ลำดับ ข้อมูลบางส่วนขาดหาย รวมไปถึงการแก้ไขให้ถูกต้องครบถ้วน โดยรายละเอียดจะได้กล่าวถึงในหัวข้อถัดไป
27.1 พอร์ต (Ports)
การทำงานของ Transport Layer จะใช้พอร์ตแอดเดรสเพื่อระบุถึงโพรโตคอลที่ใช้ในการสื่อสาร เพื่อใช้ในการอ้าง
ถึงโปรแกรม หรือแอพพลิเคชันที่ใช้ในการสื่อสาร ซึ่งแต่ละแอพพลิเคชันจะมีหมายเลขพอร์ตเฉพาะตัวขนาด 16 บิต
ซึ่งเลขนี้จะถูกบรรจุในทั้งเฮดเดอร์ของ UDP และ TCP เพื่อเป็นการกำหนดว่า ต้องการเชื่อมต่อกับโพรโตคอลใด
(พอร์ตปลายทาง) และมาจากโพรโตคอลใด (พอร์ตต้นทาง) องค์กร IANA กำหนดการใช้งานของพอร์ตออกเป็นสาม
ช่วงดังนี้ book)
(partial
only
KKU
รูปที่ 27.2: การทำงานของพอร์ตกับโปรแกรมต่างๆ
• ช่วงพอร์ตหมายเลข 0 ถึง 1023 เรียกว่า WellKnown ports ถูกกำหนดและควบคุมโดย IANA เพื่อใช้ใน
แอพพลิเคชันพื้นฐานต่างๆในอินเทอร์เน็ตเช่น พอร์ต 20 และ 21 สำหรับ File Transfer Protocol (FTP)
และ พอร์ต 80 สำหรับ Hypertext Transfer Protocol (HTTP) เป็นต้น
• ช่วงพอร์ตหมายเลข 1024 ถึง 49,151 เรียกว่า Registered ports ไม่ถูกกำหนดหรือควบคุมโดย IANA แต่
สามารถลงทะเบียนกับ IANA เพื่อป้องกันการใช้ซํ้าได้ เช่นพอร์ต 3306 สำหรับ MySql เซิร์ฟเวอร์
• ช่วงพอร์ตหมายเลข 49,152 ถึง 65,535 หรือส่วน Dynamics ports สามารถใช้งานได้อย่างอิสระจากผู้ที่
ต้องการพัฒนาเน็ตเวิร์คแอพพลิเคชันขึ้นใช้
27.2. USER DATAGRAM PROTOCOL (UDP) 213
27.2 User Datagram Protocol (UDP)
UDP เป็นโพรโตคอลที่ถูกพัฒนาขึ้นเพื่อสนับสนุนการเชื่อมต่อระหว่างโปรเซส UDP เป็นโพรโตคอลแบบ ไม่ต้องมี
การสร้างเส้นทางล่วงหน้าเพื่อส่งข้อมูล(connectionless)ไม่มีการตอบกลับเพื่อยืนยันว่าได้รับข้อมูลแล้ว(unreliable
protocol) และไม่มีการจัดลำดับข้อมูลที่ได้รับ หรือกล่าวได้ว่า UDP ไม่ได้เพิ่มเติมฟังก์ชันที่ต่างจากการทำงานของ
IP
UDP ถูกพัฒนาขึ้นสำหรับการส่งข้อมูลในบางแอพพลิเคชันที่สามารถยอมรับในการสูญหายของข้อมูลบาง
ส่วนได้ ตัวอย่างเช่นในแอพพลิเคชันลักษณะที่เป็นมัลติมีเดียต่างๆ โดยที่ไม่ได้เพิ่มเติมความน่าเชื่อถือในการส่ง
ข้อมูล ( reliability) การความคุมการส่งข้อมูลระหว่างภาครับและภาคส่ง (flow-control) หรือ การแก้ไขความ
ผิดพลาด (error recovery) ให้กับ Network Layer เลย ดังนั้น หน้าที่หลักของ UDP เพื่อเป็น multiplexer และ
demultiplexer รับส่งของข้อมูลที่เป็นดาต้าแกรม และใช้พอร์ตเพื่ออ้างอิงถึงแอพพลิเคชันของดาต้าแกรม ตัวอย่าง
book)
ของแอพพลิเคชันที่ทำงานบน UDP ที่ใช้แพร่หลาย และพอร์ตที่ใช้ดังแสดงในตารางที่ 27.1
พอร์ต โพรโตคอล รายละเอียด
7 Echo Echoes a received datagram back to sender
9 Discard Discards any datagram that is received
11 Users Active Users
13 Daytime Returns the date and
(partial the time
17 Quote Returns a quote of the day
19 Chargen Returns a string of characters
53 Nameserver Domain Name Server
67 BOOTPs Server port to download bootstrap information
68 BOOTPc Client port to download bootstrap information
69 TFTP Trivial
111 RPC Remote Procedure Call
123 NTP only File Transfer Protocol
Network Time Protocol
KKU ตารางที่ 27.1: UDP Well-known port
161 SNMP Simple Network Management Protocol
162 SNMP Simple Network Management Protocol (trap)
อย่างไรก็ตาม จากการที่ขนาดของ UDP ดาต้าแกรม มีขนาดเล็ก ทำให้ UDP มีประสิทธิภาพการส่งข้อมูลที่ดี
และ ไม่เกิดเวลาหน่วงเนื่องจากการสร้างการเชื่อมต่อระหว่างต้นทางและปลายทาง แต่ถือเป็นความรับผิดชอบของ
แอพพลิเคชันที่ทำหน้าที่ในการตรวจสอบความผิดพลาด หรือความน่าเชื่อถือของการสื่อสารหากต้องการ
27.2.1 รูปแบบของ UDP (UDP Format)
• Source Port: พอร์ตที่ถูกใช้โดยโพรโตคอลซึ่งทำงานโดยโฮสต์ต้นทางที่ส่งข้อมูล มีขนาด 16 บิต เพื่อให้โนด
ปลายทางใช้ในการตอบกลับ
• Destination Port: พอร์ตที่ถูกใช้โดยโพรโตคอลซึ่งทำงานโดยโฮสต์ปลายทางที่ส่งข้อมูล มีขนาด 16 บิต
• Length: จำนวนไบต์ของดาต้าแกรมที่ส่ง รวมเฮดเดอร์มีขนาด 16 บิต ทำให้สามารถส่งข้อมูลได้สูงสุด
65,535 ไบต์
214 บทที่ 27. TRANSPORT LAYER
0 15 31
Source Port Destination Port
Length Checksum
Data
รูปที่ 27.3: UDP Datagram format
• Checksum: 16 บิต One's complement ของผลรวมของ pseudo-IP header, UDP header และข้อมูล
ของ UDP ประกอบไปด้วย IP Address ของต้นทางและปลายทาง โพรโตคอลและความยาวของ UDP ดัง
แสดงการคำนวณรูปที่ 27.4
0 15 31
Source IP Address
Destination IP Address book) Pseudoheader
All 0s 8-bit protocol 16-bit UDP total length
Destination Port
Source Port (partial Header
Length Checksum
only
ข้อมูลเป็นทวีคูณ 16 บิต
KKU รูปที่ 27.4: Pseudo-IP แอดเดรสของ UDP
27.3 Transport Control Protocol (TCP)
การทำงานของ TCP แตกต่างจาก UDP โดยสิ้นเชิง การทำงานของ TCP จะมีการสร้างเส้นทางก่อนการส่ง
ข้อมูล (connection-oriented) โดยการใช้ขบวนการที่เรียกว่า Threeway Handshaking และการใช้ Sequence
number เพื่อจัดลำดับข้อมูล รวมถึงการตรวจสอบข้อมูลที่ส่งถึงผู้รับหรือไม่ และส่งข้อมูลออกไปใหม่ หากได้รับไม่
ครบถ้วน แตกต่างจาก UDP ที่ไม่มีการสร้างเส้นทางก่อนการสื่อสารข้อมูล ตัวอย่างของแอพพลิเคชันที่ทำงานบน
TCP ที่ใช้แพร่หลาย และพอร์ตที่ใช้แสดงในตารางที่ 27.2
ทำไมต้องใช้ UDP? จากการที่เราได้กล่าวถึงแล้วในการทำงานของ UDP ไม่ได้สนับสนุนการเรียงลำดับข้อมูล
การจัดการกับการสูญหายของข้อมูล จึงอาจมีข้อสงสัยว่าแล้วเหตุใดจึงใช้ UDP อีก ซึ่งดูเหมือนว่า TCP จะมีข้อดี
กว่าหลายด้าน คำตอบจึงอยู่ที่ความง่ายในการส่งข้อมูล เนื่องจากใน UDP เราไม่จำเป็นต้องสร้างการเชื่อมต่อก่อน
27.3. TRANSPORT CONTROL PROTOCOL (TCP) 215
พอร์ต โพรโตคอล รายละเอียด
7 Echo Echoes a received datagram back to sender
9 Discard Discards any datagram that is received
11 Users Active Users
13 Daytime Returns the date and the time
17 Quote Returns a quote of the day
19 Chargen Returns a string of characters
20 FTP, Data File Transfer Protocol (data connection)
21 FTP, Control File Transfer Protocol (control connection)
23 TELNET Terminal Network
25 SMTP Simple Mail Transfer Protocol
53 DNS Domain Name Server
67 BOOTP Bootstrap Protocol
79 Finger Finger
book)
80 HTTP Hypertext Transfer Protocol
111 RPC Remote Procedure Call
ตารางที่ 27.2: TCP Well-known port
(partial
เหมือนใน TCP ดังนั้นหากแอพพลิเคชันที่ต้องการจะส่งข้อมูล สามารถที่จะส่งออกไปได้ทันที ทำให้สามารถลดเวลา
หน่วงที่จะเกิดขึ้น ซึ่งถือว่าเป็นปัจจัยสำคัญของการเลือกใช้ UDP
only
27.3.1 การใช้บริการของ TCP
จากการที่การทำงานของ TCP แตกต่างจาก UDP เราสามารถที่จะกล่าวได้ว่า หน้าที่สำคัญของ TCP ในการ
สนับสนุนแอพพลิเคชันที่ใช้งานในด้านต่างๆ ได้แก่
KKU หากมองจากแอพพลิเคชัน TCP จะส่งข้อมูลต่อเนื่องเป็นไบต์ไปบนเครือข่าย
• Stream data transfer
โดยที่แอพพลิเคชันไม่มีความจำเป็นในการที่จะแบ่งข้อมูลออกเป็นส่วนๆ หรือเป็นดาต้าแกรม TCP จะรวม
ไบต์ของข้อมูลเป็น TCP เซกเมนต์ก่อนส่งต่อไปยังเลเยอร์ถัดไป (Network Layer) เพื่อไปยังปลายทางที่
ต้องการ การทำงานของ TCP สามารถตัดสินใจว่าจะแยกข้อมูลอย่างไร เพื่อจะทำให้ข้อมูลส่งได้อย่างสะดวก
• Reliability TCP จะกำหนดหมายเลขเรียกว่า Sequence number ให้กับทุกไบต์ที่ส่ง และจะรอรับ ACK
ตอบกลับจากภาครับ ถ้าหากไม่ได้รับ ACK ในเวลาที่กำหนด TCP จะทำการส่งเซกเมนต์นั้นใหม่ ส่วนภาค
รับจะใช้หมายเลขนี้ในการจัดเรียงข้อมูล และกำจัดเซกเมนต์ที่ซํ้าหากเกิดขึ้น
• Flow control นอกจากภาครับจะส่ง ACK กลับเพื่อแสดงถึงเซกเมนต์ที่ได้รับแล้ว ยังแสดงถึงจำนวนไบต์
ที่ตนเองสามารถรับได้ในรอบถัดไป เพื่อไม่ให้มีจำนวนเซกเมนต์ที่มากเกินความสามารถในการจัดเก็บใน
บัฟเฟอร์ของตนเอง (overflow) และประมวลผล
• Multiplexing การใช้พอร์ตคล้ายกับที่เกิดขึ้นกับ UDP
• Logical connections การทำงานของ TCP จะทำงานในลักษณะที่เรียกว่า stateful หรือเป็นการรักษา
สถานะของการทำงาน เช่น ขนาดของ windows ที่ส่ง (window sizes) ลำดับการส่งข้อมูลหรือ sequence
number เป็นต้น เพื่อให้การสื่อสารเป็นไปอย่างมีเสถียรภาพ ภาครับสามารถประมวลผลได้ทันกับข้อมูลที่
ได้รับ และหลีกเลี่ยงการที่จะทำให้เกิดความคับคั่งบนเน็ตเวิร์คขึ้น
216 บทที่ 27. TRANSPORT LAYER
27.3.2 รูปแบบเซกเมนต์ของ TCP (TCP Segment Format)
จากการที่การทำงานของ TCP เป็นแบบ stateful ดังที่ได้กล่าวไปแล้ว ทำให้นอกเหนือจากหมายเลขของพอร์ตที่
จำเป็นต้องมีคล้ายกับการทำงานของ UDP เฮดเดอร์ของ TCP ยังมีส่วนต่างๆเพิ่มมา ดังแสดงในรูปที่ 27.5 ทั้งหมด
มีขนาด 20 ไบต์ไม่รวมส่วนของ option ที่อาจเกิดขึ้น
0 15 31
Source port Destination port
Sequence number
Acknowledgment number
book)
HLEN Reserved U A P R S F Window size
Checksum Urgent pointer
Options and Padding
(partial
รูปที่ 27.5: รูปแบบเซกเมนต์ของ TCP
• Source Port: พอร์ตต้นทางของการส่งข้อมูล
only
• Destination Port: พอร์ตปลายทางของการส่งข้อมูล
• Sequence Number: หมายเลขของข้อมูลในการส่งของเซกเมนต์นี้ ถ้าหาก SYN บิตถูกเซ็ต Sequence
KKU
number ที่ n จะเป็นหมายเลขแรก และข้อมูลจะเป็นหมายเลขที่ n+1
• Acknowledgement Number: ถ้า ACK บิตถูกเซ็ต จะเป็นการบอกถึง sequence number ถัดไปที่จะ
รับข้อมูล
• HLEN (Header Length) : เป็นเลขฐาน 32 เพื่อบอกแอพพลิเคชันถึงข้อมูลเริ่มต้น การใช้ฟิลด์นี้ใน TCP
เพื่อกรณีมีการใช้ Option ฟิลด์ในเฮดเดอร์ของ TCP ในกรณีทั่วไปมีค่าเป็น 5
• Reserved: หกบิตจองไว้ใช้ในอนาคต เป็นศูนย์ (0)
• Control Field: มีขนาด 6 บิต ตั้งแต่ U ถึง F เพื่อแสดงสถานะการทำงาน ดังรายละเอียดในตารางที่ 27.3
URG (Urgent Pointer is Valid) เพื่อให้พิจารณา Urgent pointer ด้วย
ACK (Acknowledgment is valid) เพื่อให้พิจารณาฟิลด์ของ ACK ด้วย
PSH (Request for push) เพื่อใช้ในการทำ PUSH ฟังก์ชัน
RST (Reset the connection) เพื่อรีเซ็ตการเชื่อมต่อ
SYN (Synchronize sequence numbers) เมื่อมีการตกลงหมายเลขของ Sequence Number
FIN (Terminate the connection) เพื่อแสดงถึงสิ้นสุดการเชื่อมต่อ
ตารางที่ 27.3: ตารางแสดงความหมายของ TCP Control Field
27.3. TRANSPORT CONTROL PROTOCOL (TCP) 217
• Window Size: ใช้กับเซกเมนต์ของ ACK เพื่อระบุจำนวนของข้อมูลที่สามารถรับได้เป็นไบต์ในเลขฐาน 16
เพื่อช่วยในการทำ flow control บน TCP
• Checksum: ใช้ในการตรวจสอบความผิดพลาดที่อาจเกิดในส่วนของข้อมูล
• Urgent Point: เพื่อใช้งานกับบิต U หรือ URG หากบิตนี้ถูกกำหนดให้เป็น 1 จะมีความหมายสองประการ
คือ หนึ่งภาคส่งต้องการที่จะส่งข้อมูลที่เร่งด่วน (Urgent) สองระบุถึงจุดสิ้นสุดของข้อมูล Urgent
• Options หากไม่มีการใช้งานฟิลด์ Options นี้ สิ่งที่ตามมาจะเป็นข้อมูลที่ต้องการส่ง แต่หากมีการใช้ฟิลด์
Options จะทำให้ค่าของ HLEN มากกว่า 5 ซึ่งการใช้งานฟิลด์ Options จะไม่ขอกล่าวถึงในที่นี้
27.3.3 Three-way Handshaking
การทำงานของ TCP เป็นแบบ connection-oriented ทำให้ก่อนที่จะส่งข้อมูลระหว่างโนด TCP ต้องสร้างการ
book)
เชื่อมต่อขึ้นก่อน เรียกว่า TCP Threeway Handshake โดยที่ภาคส่งจะเริ่มส่ง SYN เซกเมนต์ (SYN = 1) พร้อม
ทั้ง Sequence number ที่ภาคส่งกำหนดขึ้น เรียกว่า Initial Sequence Numbers (ISN) เพื่อให้ภาครับรับทราบ
ถึงการเริ่มสร้างการเชื่อมต่อระหว่างกัน จากนั้นภาครับจะตอบกลับด้วย ACK เซกเมนต์ (ACK = 1) พร้อมทั้ง ISN
ของตน ก่อนที่ภาคส่งจะส่ง ACK เซกเมนต์อีกครั้งก่อนการสื่อสารจริงจะเกิดขึ้น นอกเหนือจาก ISN แล้ว ทั้งสอง
สามารถกำหนดค่าของ option อื่นเพิ่มเติมได้เช่นกัน
1 (partial 2
only 3
KKU รูปที่ 27.6: การเชื่อมต่อแบบ Three-way handshaking
รูปที่ 27.7 แสดงเซกเมนต์ของ TCP จากไคลเอนต์ (ตำแหน่ง 1 ) สมมติให้ต้นทางใช้พอร์ตหมายเลข 3456
และร้องขอไปยังปลายทางที่พอร์ตหมายเลข 21 ซึ่งเป็น Well-Known port ของ FTP กำหนดให้ TCP เซกเมนต์ที่
ส่งมี Sequence number เริ่มต้นเป็น 1000 ทำให้หากเซกเมนต์นี้สูญหาย TCP จะส่งออกไปใหม่โดยใช้หมายเลขนี้
ดังเดิม
เนื่องจากเซกเมนต์นี้เป็นการร้องขอการเชื่อมต่อระหว่างต้นทางและปลายทาง ทำให้ส่วนของ ACK ไม่มีความ
หมายใดๆ ในส่วนของ HLEN ในที่นี้มีค่าเท่ากับ 5 หมายถึงไม่มีการกำหนด Options ใดๆ และฟิลด์ Reserve มีค่า
เป็น 0 เพื่อแสดงว่าไม่มีการใช้งาน ในส่วนของบิต Control มีส่วนของบิต SYN เท่านั้นที่ถูกกำหนดให้เป็น 1 นอก
นั้นมีค่าเป็น 0 ทำให้ Urgent Pointer ไม่มีความหมายใดๆ นอกจากนี้ในเซกเมนต์นี้ ฟิลด์ Window size ไม่มีความ
หมายใดๆเช่นกัน ในส่วนของฟิลด์ Checksum จะบันทึกค่าที่คำนวณได้ เพื่อให้ภาครับใช้ตรวจสอบความถูกต้อง
ของข้อมูลที่ได้รับ
จากนั้นเมื่อภาครับได้รับการร้องขอนี้ ดังแสดงรูปที่ 27.6 เซกเมนต์ที่เซิร์ฟเวอร์ตอบ ACK กับมายังไคลเอนต์
สามารถแสดงในรูปที่ 27.8
รูปที่ 27.8 แสดงที่ตำแหน่ง 2 จะเห็นว่าหมายเลขพอร์ตต้นทางและปลายทางจะสลับที่กัน เซิร์ฟเวอร์กำหนด
Sequence number ของตนเองเป็น 3000 พร้อมตอบกับด้วย ACK หมายเลข 1001 (เนื่องจาก SYN จะใช้ 1 ไบต์)
218 บทที่ 27. TRANSPORT LAYER
Source port = 3456 Destination port = 21
Sequence number: 1000
Acknowledgment number
5 0 0 0 0 0 1 0 Window size
Checksum Urgent pointer
รูปที่ 27.7: เฮดเดอร์เซกเมนต์ของ TCP ที่ตำแหน่ง 1
Source port = 21 Destination port = 3456
Sequence number: 3000 book)
(partial
Acknowledgment number = 1001
5 0 0 1 0 0 1 0 Window size = 4096
Checksum Urgent pointer
only
รูปที่ 27.8: เฮดเดอร์เซกเมนต์ของ TCP ที่ตำแหน่ง 2
KKU
เพื่อระบุถึงหมายเลขของเซกเมนต์ถัดไปที่ต้องการจะต้องเริ่มต้นที่ 1001 HLEN มีค่าเท่าเดิมเนื่องจากไม่มี Options
ใดเพิ่มขึ้น ถัดไปใน Control บิตของ ACK ถูกกำหนดให้เป็น 1 เพื่อแสดงถึงว่ามีการใช้งานของ ACK นอกจากนี้ในที่
นี้ window ถูกกำหนดให้เป็น 4096 แสดงให้เห็นว่า TCP กำหนดให้เซกเมนต์ถัดไปสามารถส่งได้ 4096 ไบต์ หรือ
เริ่มจาก Sequence Number = 1001 ถึง 5096 ส่วน Checksum ใช้เพื่อตรวจสอบเฮดเดอร์ตามปกติ ส่วนสุดท้าย
Urgent pointer ในที่นี้ไม่ได้ใช้งาน เนื่องจากบิต URG ถูกกำหนดให้เป็น 0 ตามเติม
Source port = 3456 Destination port = 21
Sequence number: 1001
Acknowledgment number = 3001
5 0 0 1 0 0 0 0 Window size = 2000
Checksum Urgent pointer
รูปที่ 27.9: เฮดเดอร์เซกเมนต์ของ TCP ที่ตำแหน่ง 3
27.3. TRANSPORT CONTROL PROTOCOL (TCP) 219
รูปที่ 27.9 แสดงเซกเมนต์สุดท้ายของขบวนการทำงานของ TCP Three-way Handshake (ตำแหน่ง 3 ) ดู
เหมือนว่าจะไม่แตกต่างจากเซกเมนต์แรกเท่าใดนัก ในส่วนของพอร์ตมีค่าเหมือนเดิม Sequence number ระบุ
หมายเลขที่ส่งและหมายเลขต้องการเมื่อได้รับการตอบรับใน ACK และใน Control จะเหลือเพียงบิต ACK เท่านั้น
ที่มีค่าเป็น 1 ส่วนของ Window สมมติว่าเป็น 2000 ทำให้เซกเมนต์ถัดไปที่ต้องการอยู่ที่ 3001 ถึง 5000
หมายเลข Initial Sequence Number (ISN) มาจากไหน? เพื่อป้องกันเซกเมนต์ที่มีหมายเลขซํ้ากันถูก
ส่งในอินเทอร์เน็ต การกำหนด Sequence Number จะต้องมั่นใจว่าจะไม่มีการกำหนดซํ้ากันเกิดขึ้น ทำให้ TCP
แนะนำให้ใช้หมายเลขเริ่มต้นของ Sequence number เพิ่มขึ้นทุกๆ 4 ไมโครวินาที หากระบบไม่สามารถกำหนด
เวลาเริ่มต้นได้ เนื่องมาจากสาเหตุใดก็ตามเช่นระบบล่ม ระบบจะต้องหยุดการส่งชั่วคราวหลังจากเริ่มเดินเครื่องใหม่
เวลาหน่วงที่เกิดขึ้นนี้เรียกว่า Quiet time
book)
ตัวอย่าง 27.1 แอพพลิเคชัน Line เป็นหนึ่งในแอพพลิเคชันที่ได้รับความนิยมอย่างมากในปัจจุบัน ผู้ใช้สามารถ
สื่อสารแบบข้อความปกติ รวมทั้งการสื่อสารผ่านการโทรฟรี หรือส่งรูปภาพระหว่างกัน แอพพลิเคชัน Line เป็น
แอพพลิเคชันที่ใช้ TCP เพื่อสื่อสารระหว่างผู้ใช้ ทำให้ต้องมีการสร้างการเชื่อมต่อแบบ Three-way handshaking
รูปที่ 27.10 แสดงการเชื่อมต่อของแอพพลิเคชันจาก IP address 192.168.1.8 ไปยังปลายทางที่ 125.209.254.16
(partial
จะเห็นว่าในเซกเมนต์หมาย 1, 2 และ 3 จะมีการทำงานตามหลักการของ Three-way handshaking ที่ได้กล่าวไป
แล้ว
only
KKU
รูปที่ 27.10: ตัวอย่างการทำงาน Three-way handshaking บนแอพพลิเคชัน Line
27.3.4 การสิ้นสุดการเชื่อมต่อ
เมื่อการรับส่งข้อมูลสิ้นสุด สิ่งที่ TCP ต้องทำคือการยกเลิกการเชื่อมต่อ ซึ่งทั้งสองฝ่ายจะต้องยอมรับการยกเลิกนี้
ดังนั้นจึงจำเป็นต้องมีการแลกเปลี่ยนเซกเมนต์ของ TCP อีกครั้ง เมื่อฝั่งหนึ่งแจ้งว่าต้องการที่จะปิดและอีกฝั่งยอมรับ
การเชื่อมต่อของ TCP จึงสิ้นสุดลง
ในทำนองเดียวกันกับการสร้างการเชื่อมต่อ เรากำหนดให้บิต SYN เป็น 1 ในการยกเลิกการเชื่อมต่อนี้ เราจะ
กำหนดให้บิต FIN เป็น 1 แทน เพื่อแจ้งถึงการสิ้นสุดการเชื่อมต่อ รูปที่ 27.11 แสดงขั้นตอนการยกเลิกการเชื่อมต่อ
นี้
การยกเลิกเริ่มจากไคลเอนต์ส่งเซกเมนต์ TCP พร้อมกำหนดให้บิต FIN มีค่าเป็น 1 โดยมี Sequence number
เป็น x และ ACK เป็น y เมื่อเซิร์ฟเวอร์ได้รับเซกเมนต์นี้ จะตอบกลับด้วย ACK ในขณะเดียวกันเซิร์ฟเวอร์แจ้งไปยัง
แอพพลิเคชันที่ใช้การเชื่อมต่อนี้ เซิร์ฟเวอร์รอจนกระทั่งได้รับการตอบรับจากแอพพลิเคชันเพื่อยืนยันการสิ้นสุดการ
220 บทที่ 27. TRANSPORT LAYER
รูปที่ 27.11: การหยุดการเชื่อมต่อของ Three-way handshaking
ใช้งาน เซิร์ฟเวอร์จะส่งเซกเมนต์ของ TCP ที่กำหนดให้บิต FIN เป็น 1 เมื่อไคลเอนต์ได้รับเซกเมนต์นี้จะตอบกลับ
book)
ด้วย ACK ทำให้การเชื่อมต่อสิ้นสุด
(partial
only
KKU
รูปที่ 27.12: compare udp tcp
บทที่ 28
การป้องกันความคับคั่ง
book)
28.1 TCP Sliding Windows
TCP ใช้การทำงานของ sliding windows เพื่อให้การส่งของข้อมูลเป็นไปอย่างมีประสิทธิภาพ และทำให้การส่ง
ของข้อมูลจากด้านส่งไม่ทำให้เกินกว่าความสามารถของด้านรับจะสามารถรับได้ ในการทำงานของ TCP จะทำ
(partial
ในรูปของไบต์ (byte-oriented) การทำงานของ Sliding Windows อาศัยหลักการเดียวกันกับการทำงานของ
Selective Repeat และ Go-Back-N เพื่อป้องกันกรณีที่มีข้อมูลที่ถูกส่งไปยังด้านรับมากเกินไป จนไม่สามารถรับได้
หรือประมวลผลทัน ดังนั้นด้านส่งจะต้องตรวจสอบจำนวนเซกเมนต์ที่ยังไม่ได้รับ ACK ก่อน จึงจะส่งเซกเมนต์ถัดไป
ซึ่งเซกเมนต์ที่ยังไม่ ACK จะต้องถูกเก็บไว้ เพื่อใช้ส่งใหม่หากจำเป็น
รูปที่ 28.1 แสดงการทำงานของ TCP sliding window โดยที่ส่วนของ Window จะถูกเลื่อนขึ้นไปเรื่อยๆ เมื่อ
only
ได้รับการตอบรับจากอีกฝั่งหนึ่ง จากรูปสามารถแบ่งออกได้เป็น 3 ส่วนคือ ส่วนที่ 1 คือช่วง 20-25 ช่วงนี้เซกเมนต์
ถูกส่งออกไปแล้ว และได้รับการตอบรับของ ACK เรียบร้อย (ในที่นี้สมมติให้หนึ่งเซกเมนต์มีขนาดมากกว่า 1 ไบต์ขึ้น
ไป) ในส่วนที่สองคือช่วง 26-32 ช่วงนี้แพกเกตส่งออกไปแล้ว แต่ยังรอการตอบกลับของ ACK จากภาครับ ซึ่งหาก
KKU
ได้รับ ACK แล้ว Window จะถูกขยับขึ้นไปเพื่อส่งในส่วนเซกเมนต์ที่รออยู่ ส่วนสุดท้ายคือส่วนที่รอให้ Window
ขยับขึ้นมาเพื่อจัดส่งต่อไป ดังนั้นจากรูป เมื่อภาคส่งได้รับ ACK ของเซกเมนต์ที่ 26 และเซกเมนต์ที่ 27 ภาคส่งจะ
ส่งในส่วนของเซกเมนต์ถัดไปที่รออยู่ในที่นี้คือ 33 และ 34
รูปที่ 28.1: TCP Sliding Window
ดังนั้น เมื่อแอพพลิเคชันต้องการส่งข้อมูล สิ่งที่เกิดขึ้นคือข้อมูลที่ส่ง จะเข้ามาในส่วนที่ 3 จากนั้น Window จะ
221
222 บทที่ 28. การป้องกันความคับคั่ง
เลื่อนขึ้นมาจนเป็นส่วนที่ 2 และ 1 ตามลำดับ เมื่อได้รับ ACK จากนั้นส่วนที่ 1 จะถูกกำจัดออกจากระบบไป
นอกจากการใช้ ACK เพื่อควบคุมการส่งข้อมูลแล้ว ขนาดของ Window size ใน TCP ไม่จำเป็นต้องเท่ากัน
ตลอดการเชื่อมต่อ โดยที่หากภาครับพบว่าตนไม่สามารถที่จะประมวลผลข้อมูลได้ทัน ภาครับสามารถที่จะลดขนาด
ของ Window ลง หรือแม้กระทั่งการลดขนาดลงจนกระทั่งเป็น 0 และรอให้มีการแจ้งจากภาครับเพื่อเปลี่ยนแปลง
ขนาดของ window อีกครั้ง
จากที่กล่าวไปแล้ว ในหัวข้อที่ ?? ถึง ?? เราอาจกล่าวได้ว่าค่า d คือค่าของ Round Trip Time (RTT) ของ
การส่งแพกเกต (การประมาณค่า RTT จะได้กล่าวโดยละเอียดต่อไปใน หัวข้อที่ 28.2) เราจะพบว่า หากต้องการ
ส่งโดยมีประสิทธิภาพสูงสุด เราควรให้ค่าของ Window size เท่ากับ แบนด์วิดท์คูณด้วยค่าของ RTT เรียกว่า
bandwidthdelay product การทำเช่นนี้เสมือนเราส่งข้อมูลอย่างต่อเนื่อง ทำให้เกิดการใช้งานของเน็ตเวิร์คสูงสุด
ดังนั้นหากสมมติอีเทอร์เน็ตความเร็ว 100 Mbps มีค่าของ RTT เป็น 5 มิลลิวินาที เราควรใช้ขนาดของ Window
size เป็น 64 kbytes (100 Mbps x 5 ms = 512 kbits หรือ 64 kbytes)
ใน Window XP เราสามารถแก้ไขขนาดของ Window size ที่ค่าของ TCPWindowSize ในระบบ Unix
book)
ทั่วไปสามารถแก้ไขที่ไฟล์ชื่อ etc/sysctl.conf อย่างไรก็ตามการเปลี่ยนแปลงค่าเหล่านี้ ท่านต้องแน่ใจว่าขนาด
ของบัฟเฟอร์มีเพียงพอไม่ทำให้ระบบล่ม
จากที่ผ่านมาจะเห็นว่าการใช้ window-based ในการควบคุมการส่งข้อมูลดูเหมือนจะเป็นวิธีที่ง่าย แต่อย่างไร
ก็ตามยังมีการขัดแย้งบางประการที่ยังต้องแก้ไข เช่นหากเราต้องการให้ทรูพุตของ TCP ให้มีค่าสูงสุด เราอาจ
(partial
ต้องการใช้ขนาดของ window size ที่สูง แต่การใช้ค่าของ window size ที่สูงไปจะทำให้มีความน่าจะเป็นของ
การสูญหายของเซกเมนต์สูงขึ้นด้วย เนื่องจากข้อจำกัดของเน็ตเวิร์คและความสามารถของภาครับ ดังนั้นการหาค่า
ของ window size ที่ดีที่สุด เพื่อให้ได้ค่าของทรูพุตที่ดี อีกทั้งไม่เกินข้อจำกัดของเน็ตเวิร์คและภาครับจึงเป็นอีกหนึ่ง
ปัญหาของ TCP[45]
only
28.1.1 TCP Window Size [45]
เพื่อป้องกันการที่จะทำให้ข้อมูลที่ส่งเกินกว่าภาครับจะสามารถทำงานได้ ใน RFC 793 ซึ่งถือเป็นข้อกำหนดแรกของ
KKU
การทำงานของ TCP ได้ออกแบบให้ TCP จะต้องไม่ส่งข้อมูลเกินกว่าบัฟเฟอร์ของภาครับที่มีอยู่ โดยการทำงานอยู่
บนพื้นฐานของ Receiver's Window (rwnd) รูปที่ 28.2 แสดงตัวอย่างการทำงานดังกล่าว
รูปที่ 28.2: การทำงานของ Receiver's Window (rwnd) [45]
จากรูปเมื่อเริ่มต้นการทำงาน ภาครับแจ้งไปยังภาคส่งเพื่อแสดงถึงจำนวนข้อมูลที่สามารถรับได้ สมมติว่าเริ่ม
ต้นภาครับให้ค่า rwnd เท่ากับ 8 จากนั้นภาคส่งจะเริ่มส่งจำนวนของข้อมูลที่ต้องการ โดยจะต้องไม่มากกว่าจำนวน
28.2. TCP ROUND TRIP TIME AND TIMEOUT [?] 223
ของ rwnd ที่แจ้งจากภาครับ ในที่นี้สมมติข้อมูลที่จะส่งไป wnd เท่ากับ 5 แต่เนื่องด้วยภาครับประมวลผลข้อมูล
ค่อนข้างช้า ทำให้ลดค่าของ rwnd ลงเหลือเท่ากับ 3 เพื่อแจ้งไปยังภาคส่ง ทำให้ภาคส่งทำการส่งเพียง wnd เท่ากับ
3 เท่านั้น อีกครั้ง เมื่อภาครับได้รับข้อมูล wnd เท่ากับ 3 และประมวลผลข้อมูลที่ได้รับแล้วมีค่า rwnd เท่ากับ 1
ภาครับจะลดค่าของ rwnd ลงอีกครั้ง ทำให้ส่ง rwnd เท่ากับ 1 เท่านั้น การทำงานทั้งหมดนี้ เพื่อป้องกันไม่ให้ข้อมูล
มีจำนวนมากเกินกว่าภาครับจะประมวลผลได้ทัน
28.2 TCP Round Trip Time and Timeout [28]
จากหัวข้อที่ ?? ทำให้เราทราบว่า RTT ถือเป็นปัจจัยสำคัญในการกำหนดขนาดของ Window เพื่อให้การใช้ช่อง
สัญญาณเป็นไปอย่างมีประสิทธิภาพสูงสุด และจะเห็นว่าการที่ใช้ขนาดของ window ที่ตํ่า ทำให้การใช้งานเน็ตเวิร์ค
เป็นไปอย่างไม่มีประสิทธิภาพ
เมื่อเราทราบถึงค่าของ RTT จะทำให้สามารถคำนวณหาค่าของ Timeout ของเซกเมนต์ในการส่งเซกเมนต์
ออกไปอีกครั้ง หากมีการสูญหายของข้อมูลเกิดขึ้น ยิ่งไปกว่านั้น ค่าของ Timeout ของ
ความคับคั่งของข้อมูลบน TCP ที่เราจะได้กล่าวต่อไป book) TCP ยังส่งผลต่อการจัดการ
• SampleRTT เป็นค่าของเวลาหนึ่งรอบของการส่งข้อมูลไปยังด้านรับและได้รับการตอบกลับ
(partial (28.1)
• EstimatedRTT เป็นค่าเฉลี่ยของ SampleRTT โดยความสัมพันธ์คือ
EstimatedRTT = (1 − α)EstimatedRTT + αSampleRTT
โดยที่ α เป็นค่าที่ใช้ในการปรับค่าของ RTT (smoothing factor) เพื่อใช้ในการประเมินผลของค่าที่ผ่าน
only โดยทั่วไปจะกำหนดให้มีค่าเป็น 1/8 หรือ 0.125 หากแทนค่าลง
มาว่าควรจะมีนํ้าหนัก (weight) เท่าใด
ในสมการ จะทำให้พบว่าค่าของ EstimatedRTT จะมีผลมากกว่าค่าของ SampleRTT การทำเช่นนี้จะ
ทำให้ค่าที่ได้มาไม่มีผลต่อการเปลี่ยนค่า RTT มากนัก เรียกว่า วิธีถัวเฉลี่ยถ่วงนํ้าหนักแบบเอ็กโปเน็นเชียล
KKU
(exponential weighted moving average)
• DevRTT ค่าของการเบี่ยงเบนมาตรฐานของ RTT โดยความสัมพันธ์คือ
DevRTT = (1 − β)DevRTT + β|SampleRTT − EstimatedRTT|
ดังนั้นจะได้ค่าของ timeout เป็น
Timeout = EstimatedRTT + 4DevRTT
28.3 Congestion Collapse
เนื่องด้วยการทำงานของ TCP เริ่มต้น มิได้คำนึงถึงความสามารถของเน็ตเวิร์คในการรองรับการทำงานของผู้ใช้
จำนวนมาก ทำให้เกิดปัญหาอันเนื่องมาจากความคับคั่งของข้อมูล เมื่อจำนวนข้อมูลที่ถูกส่งเข้ามารวมๆกันแล้วเกิน
กว่าความสามารถที่เน็ตเวิร์คจะสามารถรองรับได้ ทำให้เซกเมนต์ที่ส่งไปนั้นจำเป็นต้องถูกส่งออกไปใหม่ หากไม่
ได้รับ ACK ในเวลาที่กำหนดภายในช่วงเวลา Timeout รูปที่ 28.3 แสดงให้เห็นปรากฎการณ์ที่เกิดขึ้น จะเห็นว่า
ในขณะที่มีข้อมูล (offered load) ไม่มากนัก ประสิทธิภาพของระบบ (ทรูพุต) เพิ่มขึ้นในลักษณะที่เป็นเส้นตรง
เมื่อเน็ตเวิร์คมีข้อมูลจำนวนมากหรือเกิดความคับคั่ง (congest) ของข้อมูล สิ่งที่เกิดขึ้นคืออัตราการเพิ่มขึ้นของ
224 บทที่ 28. การป้องกันความคับคั่ง
รูปที่ 28.3: ปรากฎการณ์ที่เกิดขึ้นเนื่องจากมีจำนวนผู้ใช้จำนวนมากใน TCP
ประสิทธิภาพระบบเริ่มลดลง เมื่อถึงจุดที่ไม่สามารถรองรับได้ จะทำให้ประสิทธิภาพลดลง จนกระทั่งเลวร้ายสุดก็คือ
ตกลงมาเหลือศูนย์นั่นเอง
อัลกอริทึมในการควบคุมความคับคั่ง book)
28.4 อัลกอริทึมในการควบคุมความคับคั่ง (Congestion Control
(partial
Algorithms)
จากปัญหาที่พบในการทำงานของ TCP ทำให้มีการแก้ปัญหาต่างๆเกิดขึ้น หนึ่งในการแก้ปัญหาดังกล่าว โดย
มีการคำนึงถึงสถานะของเน็ตเวิร์คเพื่อให้มีการปรับเปลี่ยนการส่งข้อมูลของ TCP ให้เหมาะสมกับข้อจำกัดของ
only
เน็ตเวิร์ค (network limit) ในขณะนั้น โดยการทำงานดังกล่าวอยู่บนพื้นฐานที่ว่าความน่าจะเป็นของความผิดพลาด
ของข้อมูลน้อยมาก (น้อยกว่า 1 เปอร์เซ็นต์มาก) ทำให้ภาคส่งประเมินว่าสิ่งที่เกิดขึ้นอันเนื่องมาจากการสูญหายของ
เซกเมนต์มาจากการเกิดการคับคั่งของข้อมูลเท่านั้น โดยอัลกอริทึมที่พัฒนาใช้ได้แก่
KKU
Slow Start การเริ่มการส่งที่จำนวนเซกเมนต์เป็นหนึ่ง และเพิ่มขึ้นเป็นสองเท่าทุกครั้งที่ได้รับ ACK
Congestion avoidance การเพิ่มการส่งที่หนึ่งเซกเมนต์หรือ Additive increase เมื่อข้อมูลที่ส่งถึงภาครับครบ
ถ้วน เพื่อชะลอการส่งเซกเมนต์ไปในเน็ตเวิร์ค
Fast retransmit การเร่งการส่งเซกเมนต์ออกไปใหม่ เมื่อได้รับ ACK หมายเลขเดียวกันซํ้าๆ ก่อนที่จะเกิด
timeout
Fast recovery การลดจำนวนเซกเมนต์ที่จะส่งลงเหลือครึ่งหนึ่ง แทนที่จะลดเหลือหนึ่ง เพื่อเข้าสู่ทำงานของ
slow start โดยไม่จำเป็น
28.4.1 Slow Start
เนื่องจากการทำงานของ TCP อยู่บนการใช้ทรัพยากรร่วมกัน Slow start มีส่วนช่วยในการป้องกันไม่ให้เน็ตเวิร์ค
เกิดความคับคั่งอย่างรวดเร็ว เนื่องจากผู้ใช้แต่ละคนส่งข้อมูลจำนวนมากไปในเน็ตเวิร์คในครั้งเดียว การทำงานของ
Slow start จะค่อยเพิ่มจำนวนแพกเกตที่จะส่งขึ้นทุกครั้งที่ได้รับ ACK จากภาครับ เริ่มต้นจากการส่งที่หนึ่งเซกเมน
ต์ จากนั้นจะเพิ่มขึ้นที่ละหนึ่งทุกครั้งที่ได้รับการตอบกลับของ ACK ในที่นี้ TCP จะใช้ค่าของ Congestion Window
cwnd เพื่อจำกัดจำนวนของเซกเมนต์ที่จะส่งแทนที่จะเป็นขนาดของ window (ในที่นี้เรียกว่า credit) ที่กำหนด
28.4. อัลกอริทึมในการควบคุมความคับคั่ง (CONGESTION CONTROL ALGORITHMS) 225
โดยภาครับ โดยการส่งของ TCP จะพิจารณาจากความสัมพันธ์
awnd = Min [credit, cwnd]
โดย
awnd ขนาดของ window ที่อนุญาตให้ส่งได้ (MSS) เป็นเซกเมนต์
cwnd ขนาดของ congestion window เป็นเซกเมนต์ ใช้ในช่วงการส่งข้อมูล
credit จำนวนเซกเมนต์ที่สามารถส่งได้อีก จากการรับ ACK ล่าสุด
รูปที่ 28.4 แสดงการทำงานของ Slow start โดยภาคส่งเริ่มต้นที่หนึ่งเซกเมนต์ (cwnd = 1) เมื่อด้านส่งได้ ACK
จะเพิ่มขนาด cwnd เป็นสอง จากนั้นรอจนกระทั่งภาคส่งได้รับ ACK จะเพิ่ม cwnd เป็นสี่ ซึ่งจะทำเช่นนี้ไปเรื่อยๆ
book)
จนกระทั่งถึงค่าสูงสุดที่เป็นไปได้
(partial
only
KKU รูปที่ 28.4: การทำงานของ Slow start
28.4.2 Congestion avoidance
จากที่กล่าวไปแล้วการทำงานของ Slow start จะเพิ่มจำนวนเซกเมนต์ทุกครั้งที่ได้รับ ACK จากภาครับ จนกระทั่งมี
สัญญาณของการเกิดความคับคั่งของข้อมูลในเน็ตเวิร์คขึ้น ในการทำงานของ TCP สัญญาณสำคัญของที่ทำให้ทราบ
ถึงความคับคั่งของข้อมูล ซึ่งนำไปสู่การทำงานของ Congestion avidance ได้แก่การเกิด Timeout ของเซกเมนต์
หากเปรียบเทียบการทำงานของ Slow start (รูปที่ 28.5 (a)) และ Congestion avoidance (รูปที่ 28.5 (b))
แยกกัน จะเห็นว่าทั้งสองมีจุดประสงค์การทำงานที่แตกต่างกัน แต่เมื่อใดก็ตาม มีการเกิดการคับคั่งของข้อมูล TCP
จะลดจำนวนของเซกเมนต์ที่ส่งลงให้เหลือหนึ่ง พร้อมทั้งบันทึกค่าของ cwnd ล่าสุดที่ใช้ จากนั้นใช้การทำงานของ
Slow start เพื่อเพิ่มจำนวนของเซกเมนต์ที่จะส่งอีกครั้ง จนมีค่าเท่ากับครึ่งหนึ่งของ cwnd ล่าสุด (cwnd/2) ก่อน
ที่จะเข้าสู่การทำงานของ Congestion avoidance ในทางปฏิบัติอัลกอริทึมทั้งสอง ถูกพัฒนาใช้งานควบคู่กัน โดย
อาศัยตัวแปรสองตัว เพื่อใช้ในการทำงาน ได้แก่ค่าของ congestion window (cwnd) และ ค่าของ slow start
threshold size (ssthresh)
รูปที่ 28.6 แสดงการทำงานร่วมกันของ Slow start และ Congestion avoidance โดยขั้นตอนการทำงาน
ดังนี้
226 บทที่ 28. การป้องกันความคับคั่ง
รูปที่ 28.5: (a) การทำงานของ Slow start และ (b) การทำงานของ Congestion avoidance
book)
(partial
only
รูปที่ 28.6: การเปลี่ยนแปลงของ Window size เมื่อมีการเกิด Timeout
KKU
1. เริ่มด้วยการให้ค่า cwnd มีค่าเท่ากับหนึ่งเซกเมนต์ในการเริ่มต้นการทำงาน และให้ค่าของ ssthresh เป็น
65535 ไบต์
2. เมื่อภาคส่งได้รับ ACK จากภาครับ TCP จะเพิ่มค่าของ cwnd ขึ้นเป็นสองเท่าทุกครั้ง
3. เมื่อพบว่าการเพิ่มขึ้นของการทำงานแบบ Slow start ทำให้เกิดความคับคั่ง TCP จะลดจำนวนเซกเมนต์ที่
ส่งลงให้เท่ากับหนึ่ง พร้อมทั้งบันทึกค่าของ cwnd ล่าสุดที่ใช้ และกำหนดให้ค่าของ ssthresh มีค่าเป็นครึ่ง
หนึ่งของ cwnd รอบที่แล้ว
4. จากการที่เกิดการคับคั่งของข้อมูลในรอบที่แล้ว Slow start จะเริ่มต้นที่หนึ่งใหม่อีกครั้ง จากนั้นจะเพิ่ม
ขึ้นเป็นสองเท่าทุกครั้งที่ได้รับ ACK จนกระทั่งถึงครึ่งหนึ่งของขนาดของ window size ในครั้งที่แล้ว หรือ
ssthresh ที่บันทึกไว้ จากการเกิดการคับคั่งของข้อมูลในครั้งที่แล้ว จากนั้นการทำงานของ Congestion
avoidance จึงจะเริ่มทำงาน โดยการเพิ่มขึ้นที่ละหนึ่งแพกเกตในลักษณะที่เป็นเส้นตรง
5. จากนั้นหากเกิดความคับคั่งของข้อมูลขึ้นอีกครั้ง TCP จะลดจำนวนของเซกเมนต์ที่ส่งลงให้เหลือหนึ่ง พร้อม
ทั้งบันทึกค่าของ cwnd ล่าสุดที่ใช้ และกำหนดให้ค่าของ ssthresh มีค่าเป็นครึ่งหนึ่งของ cwnd รอบที่แล้ว
ก่อนที่จะเข้าสู่การทำงานของ Slow start และ Congestion avoidance ใหม่อีกครั้ง ซึ่งการทำงานจะเป็น
เช่นนี้จนกระทั่งสิ้นสุดการเชื่อมต่อ
28.4. อัลกอริทึมในการควบคุมความคับคั่ง (CONGESTION CONTROL ALGORITHMS) 227
จากขบวนการขั้นต้น จะเห็นว่าการกำหนดค่าของ Timeout มีความสำคัญอย่างมาก ซึ่งจะต้องสัมพันธ์กับค่า
ของ RTT ในระหว่างที่ไม่เกิดความคับคั่งขึ้น การกำหนด Timeout ที่สั้นเกินไป อาจทำให้เซกเมนต์เกิด Timeout
ที่เร็วเกินไป แต่ในทางตรงกันข้าม หากการกำหนด Timeout ที่สูงเกินไป อาจทำให้การตรวจจับการเกิดความคับคั่ง
ไม่ทันท่วงที การคำนวณหาค่าของ Timeout สามารถดูได้จากหัวข้อที่ 28.2
28.4.3 Fast Retransmit
เมื่อใดก็ตามที่ด้านรับได้รับเซกเมนต์ ด้านรับจะส่ง ACK เพื่อตอบกลับ ในบางครั้งอาจทำให้เกิด duplicated ACK
หรือการที่ได้รับ ACK ที่มีหมายเลขเดียวกันซํ้าๆ ที่ภาคส่ง ซึ่งกรณีเช่นนี้อาจเกิดจากเซกเมนต์ที่ส่งออกไปสูญหาย
หรือภาครับได้รับเซกเมนต์ไม่เป็นเรียงลำดับ (out of order) อย่างไรก็ตาม หากเกิดจากการที่เซกเมนต์ไปถึงปลาย
ทางอย่างไม่เป็นลำดับ การเกิดกรณีเช่นนี้ไม่ควรจะทำให้เซกเมนต์ที่ตามมาไปถึงได้เป็นจำนวนมาก โดยอาจเกิดขึ้น
เป็นจำนวน 1-2 เซกเมนต์ แต่หากมีมากกว่านั้น เราอาจคาดได้ว่าเซกเมนต์นั้นอาจเกิดการสูญหาย แม้ว่าจะยังไม่
book)
เกิด Timeout ของเซกเมนต์นั้น
เพื่อเร่งการส่งเซกเมนต์ที่คาดว่าเกิดการสูญหายให้เร็วขึ้นจากการที่ได้รับ ACK หมายเลขซํ้าๆ ดังนั้น เมื่อ TCP
ได้รับ ACK ที่มีหมายเลขเดียวกันจำนวน 3 ครั้ง TCP จะส่งเซกเมนต์นั้นออกไปทันทีเรียกว่า fast retransmission
โดยไม่รอให้ Timeout ก่อน รูปที่ 28.7 แสดงการทำงานของอัลกอริทึมดังกล่าว ในที่นี้ เราสมมติให้ เซกเมนต์ที่มี
(partial
Sequence number = 1301 เกิดการสูญหาย ทำให้เซกเมนต์ที่ Sequence number = 1401, 1501 และ 1601
ไปถึงภาครับก่อน พร้อมทั้งส่ง ACK ที่ Sequence number เป็น 1301 เมื่อภาคส่งได้รับ ACK ดังกล่าว ภาคส่งจะ
ส่งเซกเมนต์ที่ 1301 ออกมาทันที โดยไม่จำเป็นต้องรอให้เกิด Timeout ของ Sequence number = 1301
only
KKU
รูปที่ 28.7: การทำงานของ Fast Retransmission เมื่อรับ ACK ซํ้า
คล้ายกับการทำงานของ Selective repeat ใน ARQ แพกเกตที่ภาครับได้รับจะถูกเก็บในบัฟเฟอร์ เพื่อรอการ
จัดเรียงก่อนที่จะถูกส่งขึ้นไปยังแอพพลิเคชัน เมื่อภาครับได้รับเซกเมนต์ที่ Sequence number = 1301 ภาครับจะ
ตอบกลับด้วย ACK ที่ระบุถึงเซกเมนต์ถัดไป (Sequence number = 1701) เพื่อให้ทราบว่าเซกเมนต์ก่อนหน้านี้
ทั้งหมดได้รับแล้ว การทำเช่นนี้เรียกว่า Cumulative ACK ทำให้เซกเมนต์ที่ Sequence number = 1401, 1501
และ 1601 ไม่ต้องถูกส่งใหม่อีกครั้ง
228 บทที่ 28. การป้องกันความคับคั่ง
28.4.4 Fast Recovery
เนื่องจากในกรณีของ fast retransmission เป็นการทำงานของภาคส่งของ TCP ตรวจสอบพบว่า ในช่วงเวลา
Timeout ของหมายเลข ACK ที่ต้องการ มีการตอบกลับจากภาครับ แต่มิใช่หมายเลขตอบกลับของ ACK ที่ถูกต้อง
กรณีเช่นนี้ ถือว่าเน็ตเวิร์คไม่ได้เกิดความคับคั่งจนส่งเซกเมนต์ไม่ได้ ทำให้ไม่จำเป็นที่จะลดค่าของ window size ลง
ให้เหลือหนึ่ง เพื่อเริ่มการทำ slow start ใหม่ ดังเช่นในกรณีของการเกิด Timeout ดังนั้น ในกรณีนี้จะลด window
size ให้เหลือครึ่งหนึ่งจากค่าของ congestion window เดิม (cwnd/2) และเริ่มการทำงานของ Congestion
avoidance ได้ทันที เรียกว่าการทำ Fast recovery ทำให้ TCP ไม่ต้องลด windows size อย่างรุนแรงโดยไม่
จำเป็น เนื่องจาก ยังไม่ได้เกิด Timeout ขึ้น และยังสามารถที่จะส่งเซกเมนต์และได้รับ ACKs จากภาครับ ทำให้
เข้าใจได้ว่าในเน็ตเวิร์คยังมิได้เกิดความคับคั่งของข้อมูลจนเกินไป รูปที่ 28.8 แสดงการเปลี่ยนแปลงของ window
size เมื่อเกิด Fast retransmission และ Fast recovery
book)
(partial
only
รูปที่ 28.8: การเปลี่ยนแปลงของ Window size เมื่อใช้ Fast retransmission
KKU
28.5 สรุป
เพื่อเติมเต็มฟังก์ชันที่อยู่นอกเหนือจากการทำงานของ Network Layer การทำของ Transport Layer ทำให้การ
สื่อสารเป็นอย่างน่าเชื่อถือมากขึ้น โดยการเพิ่มเติมฟังก์ชันต่าง ๆ เช่น การตรวจสอบเมื่อได้รับข้อมูลที่ซํ้า การรับ
ข้อมูลที่ไม่เป็นไปตามลำดับ การสูญหายของข้อมูล การทำงานของ Transport Layer ช่วยในการทำงานในส่วนของ
การจัดการการเชื่อมต่อ รวมไปถึงการทำมัลติเพล็กซิงเพื่อการสื่อสารระหว่างโนดต้นทางและปลายทางเป็นไปอย่าง
ถูกต้อง
นอกจากการจัดการส่งข้อมูลให้ถูกต้องแล้ว การทำงานของ TCP บน Transport Layer ยังคำนึงถึงความ
สามารถของระบบในการรองรับการส่งข้อมูล ทำให้เพิ่มเติมฟังก์ชันในการบริหารจัดการกับความคับคั่งของข้อมูลที่
อาจเกิดขึ้น รวมถึงการแก้ไขหากมีข้อผิดพลาด ได้แก่ การทำ sliding windows การทำงานของ slow start และ
Fast Retransmission เป็นต้น อย่างไรก็ตาม แม้ว่า UDP จะไม่รองรับการจัดการในเรื่องเหล่านี้ แต่ UDP ถือเป็น
โพรโตคอลที่มีเฮดเดอร์ขนาดเล็ก ต้องการทรัพยากรในเน็ตเวิร์คที่ตํ่า ทำให้เหมาะสมกับแอพพลิเคชันที่รองรับการ
สูญหายของข้อมูลได้เช่น แอพพลิเคชันประเภทมัลติมีเดีย เป็นต้น
28.6 คำถามท้ายบท
1. ข้อดีของการใช้งาน UDP/IP เมื่อเทียบกับ TCP/IP
28.6. คำถามท้ายบท 229
2. จงเปรียบเทียบคุณลักษณะของ UDP/TCP อย่างละเอียด
3. อธิบายการทำงานของ Sliding Windows บน TCP
4. อธิบายการทำงานของ Flow Control และ Congestion Control ใน TCP
5. จากงานวิจัยการทำงานของ TCP บนการสื่อสารแบบไร้สายจากในเอกสารอ้างอิงที่ [46] พบว่าการทำงาา
นของ TCP มีลักษณะการทำงานดังแสดงในรูปที่ 28.9 ท่านสามารถอธิบายสิ่งที่เกิดขึ้นจากงานวิจัยดังกล่าว
ได้อย่างไร ตั้งแต่เริ่มการสื่อสารที่เวลา 0
book)
(partial
only
รูปที่ 28.9: ประสิทธิภาพของ TCP บนการสื่อสารแบบไร้สาย (รูปจาก [46])
6. สมมติว่า โฮสต์ A ส่ง 2 TCP เซกเมนต์ต่อเนื่องกันไปยังโฮสต์ B สมมติว่าเซกเมนต์แรกมี Sequence
KKU
number 150 และ เซกเมนต์ที่ 2 มี Sequence number 190
a) ข้อมูลที่ส่งไปในเซกเมนต์มีขนาดเท่าใด?
b) สมมติว่าเซกเมนต์แรกเกิดการสูญหายระหว่างทาง แต่เซกเมนต์ที่สองได้รับที่โฮสต์ B ในเซกเมน
ต์ ACK ของโฮสต์ B ไป ยังโฮสต์ A Sequence numnber ของ ACK ควรมีค่าเท่าใด
7. การคำนวณหาค่า Timeout ถือเป็นส่วนสำคัญของการทำงาน TCP เหตุใดเราไม่ใช้เวลาล่าสุดที่ได้เพื่อ
กำหนดค่าของ Timeout โดยตรง แทนที่ต้องใช้สมการที่ 28.1 ให้เกิดความซับซ้อนในการคำนวณ
8. การกำหนดค่าของ Timeout ที่สูงมีผลต่อการทำงานของ TCP หรือไม่ อย่างไร
9. ให้ใช้โปรแกรม Wireshark (www.wireshark.org) เพื่อตรวจสอบการเชื่อมต่อของแอพพลิเคชันที่ทำงาน
บน UDP และ TCP เปรียบเทียบการเชื่อมต่อของโพรโตคอลทั้งสอง
10. สมมติให้มีการโอนย้ายข้อมูลจากจุดหนึ่งไปยังอีกจุดหนึ่งบน TCP เริ่มต้นจากการทำงานของ Slow start
จากนั้นเกิด Timeout ที่ขนาดของ Windows = 100 จะทำให้เกิดอะไรจากนั้น สมมติไม่มีเกิดความผิด
พลาดขึ้นอีกเลย
230 บทที่ 28. การป้องกันความคับคั่ง
book)
(partial
only
KKU
รูปที่ 28.10: overflow
บทที่ 29
Application Layer
book)
I'm sorry, my responses are
limited...you must ask the right
questions.
Hologram of Dr. Lanning (I, Robot )
(partial
การทำงานของ ApplicationLayer ถือเป็นส่วนสำคัญที่ทำให้ผู้ใช้สามารถสื่อสารผ่านเน็ตเวิร์คได้อย่างไรก็ตาม
เมื่อกล่าวถึง Application Layer มิได้หมายถึงแอพพลิเคชันต่างๆที่ถูกใช้ผ่านทางเน็ตเวิร์ค แต่เป็นการร้องขอจาก
แอพพลิเคชันที่ถูกพัฒนาขึ้นเช่นเว็บเบราว์เซอร์ เพื่อเชื่อมต่อไปยังส่วนต่อประสานโปรแกรมประยุกต์ (Application
Program Interface, API) ที่ถูกพัฒนาขึ้น ทั้งนี้ในแต่ละระบบปฏิบัติการจะประกอบไปด้วยฟังก์ชันต่างๆที่แตกต่าง
only
กัน แต่อย่างไรก็ตามทุก API จะมีจุดประสงค์เดียวกันคือ การรองรับการเรียกใช้จากแอพพลิเคชันที่ต้องการสื่อสาร
ผ่านไปยังระบบปฏิบัติการ รูปที่ 29.1 แสดงการสื่อสารของแอพพลิเคชันของผู้ใช้ เพื่อเรียกใช้ API ที่เกี่ยวข้องบน
โมเดลมาตรฐาน OSI ตัวอย่าง API ที่สำคัญได้แก่ Berkeley socket (BSD socket) ซึ่งเป็น API พื้นฐานเพื่อการ
พัฒนาเน็ตเวิร์คแอพพลิเคชัน โดยได้รับการใช้งานอย่างแพร่หลายในระบบปฏิบัติการ UNIX และเป็นส่วนสำคัญที่
ผลักดันให้มีการพัฒนา Microsoft
KKU Windows WinSock API
รูปที่ 29.1: เลเยอร์ Application และ โมเดลมาตรฐาน OSI
ในบทนี้เพื่อเป็นพื้นฐานในการพัฒนาเน็ตเวิร์คแอพพลิเคชันให้แก่ผู้อ่าน เราจะได้กล่าวถึงการเขียนโปรแกรมใน
รูปของซ็อกเก็ตเบื้องต้น ก่อนที่จะได้กล่าวถึงการทำงานของโพรโตคอลต่างๆที่สำคัญ เช่น File Transfer Protocol
(FTP) และ Domain Name Service (DNS) รวมไปถึง Real-time Transport Protocol (RTP) เพื่อใช้งานด้าน
มัลติมีเดีย และ Simple Network Management Protocol (SNMP) เพื่อการจัดการด้านเน็ตเวิร์คเป็นต้น
231
232 บทที่ 29. APPLICATION LAYER
29.1 ซ็อกเก็ต (Socket)
การพัฒนาของระบบ UNIX เพื่อรองรับการใช้งานร่วมกันแบบแบ่งเวลา (time sharing) ทำให้เกิดการทำงานของ
ระบบปฏิบัติการในลักษณะที่เป็นโปรเซส (process) โดยที่แต่ละแอพพลิเคชันของผู้ใช้มีการทำงานเสมือนเป็น
โปรเซส โดยที่แต่ละแอพพลิเคชันติดต่อกับระบบปฏิบัติการในลักษณะที่เรียกว่า system call หรือการเรียกใช้
งานระบบ การเรียกใช้เพื่อการสื่อสารกับเน็ตเวิร์คจะอยู่ในลักษณะเดียวกัน แต่อยู่ในรูปแบบที่เรียกว่า ซ็อกเก็ต
(Socket) เสมือนเป็นไฟล์เพื่อใช้ในการเข้าถึงการเชื่อมต่อเน็ตเวิร์ค
29.1.1 การสร้างการเชื่อมต่อโดยซ็อกเก็ต
การที่แอพพลิเคชันจะร้องขอไปยังระบบปฏิบัติการเพื่อสร้างซ็อกเก็ตที่ต้องการ ผู้ใช้จำเป็นจะต้องระบุตัวแปร 3 ตัว
ได้แก่
• Protocolfamilyเพื่อใช้ระบุตระกูลของโพรโตคอลที่ใช้ทำให้ทราบรูปแบบของแอดเดรสที่ใช้เช่นAF_INET
เพื่อระบุ IPv4 book)
• Type of socket ระบุประเภทของซ็อกเก็ตการสื่อสารที่ใช้ เช่น SOCK_STREAM ใช้เพื่อการใช้งานแบบ
connnection-oriented หรือ SOCK_DGRAM เพื่อใช้งานแบบ datagram
• Protocol type ชนิดของโพรโตคอลที่ต้องสอดคล้องกับประเภทของซ็อกเก็ต เช่น SOCK_STREAM ต้อง
ใช้งานกับ IPPROTO_TCP (partial
การสร้างซ็อกเก็ตสามารถทำได้โดยคำสั่ง socket โดยการเรียกใช้คำสั่งดังกล่าว ระบบจะคืนค่าของจำนวนเต็มบวก
only
รูปแบบการเรียกใช้จะเป็น
result = socket(protocol family, type of socket, protocol type)
KKU
ตัวอย่างการการเรียกใช้ซ็อกเก็ตแสดงในตัวอย่างโค้ดที่ 29.1
ตัวอย่างโค้ด 29.1: การสร้างซ็อกเก็ตแบบ Connection-oriented
int result;
result = socket(AF_INET, SOCK_STREAM, PPRPOTO_TCP}
if(result < 0)
{
perror("SOCKET ERROR");
exit (1);
}
close(result);
จากตัวอย่างโค้ดที่ 29.1 เป็นการสร้างซ็อกเก็ตที่เป็นแบบ Connection-oriented เราสามารถสรุปขั้นตอนการ
สร้างได้ดังรูปที่ 29.2 จากรูปจะเห็นว่าการสร้างแบ่งเป็นสองฝั่งคือฝั่งของเซิร์ฟเวอร์และฝั่งของไคลเอนต์ โดยที่ในฝั่ง
ของเซิร์ฟเวอร์จะรอการร้องขอการเชื่อมต่อจากไคลเอนต์ ฟังก์ชันที่จำเป็นในฝั่งเซิร์ฟเวอร์ได้แก่
bind แม้ว่าจะมีการสร้างซ็อกเก็ตเรียบร้อย แต่ยังไม่ได้มีการกำหนดพอร์ตแอดเดรสและ IP address เพื่อการ
สื่อสาร ดังนั้นหลังจากการสร้างซ็อกเก็ต เซิร์ฟเวอร์ใช้คำสั่ง bind เพื่อกำหนดแอดเดรสตนเองและรอการ
ร้องขอจากไคลเอนต์ต่อไป โดยที่รูปแบบของคำสั่ง bind เป็น
bind(socket, local address, address length)
29.1. ซ็อกเก็ต (SOCKET) 233
book)
รูปที่ 29.2: การสร้างการเชื่อมต่อแบบ Connection-oriented
(partial
• socket หมายถึง ซ็อกเก็ตที่จะใช้ อ้างถึงแลขจำนวนเต็มที่สร้างขึ้น
• local address หมายถึง แอดเดรสที่จะถูก bind
• address lenght หมายถึง ความยาวของแอดเดรส หน่วยเป็นไบต์
listen คำสั่ง listen จะทำให้เซิร์ฟเวอร์สร้างซ็อกเก็ตเพื่อรอการเชื่อมต่อที่อาจเกิดขึ้น โดยรูปแบบของคำสั่ง listen
จะเป็น only listen(socket, qlength)
KKU
โดยที่ในที่นี้ qlength เป็นการกำหนดความยาวของคิวที่ร้องขอ (request) หากขนาดคิวเต็มการร้องขอนั้น
จะถูกกำจัดทิ้งไป
accept หลังการสร้างซ็อกเก็ตสิ้นสุด เซิร์ฟเวอร์จะรอเพื่อสร้างการเชื่อมต่อ โดยการเรียกใช้คำสั่ง accept จาก
ระบบ เมื่อเรียกใช้ accept เซิร์ฟเวอร์จะบล็อก (block) จนกระทั่งมีการร้องขอ โดยคำสั่ง block จะเป็น
newsock = accept(socket, address, address lenght)
• socket ระบุซ็อกเก็ตที่จะ wait
• address เมื่อได้รับการร้องขอส่วนของ แอดเดรส จะระบุแอดเดรสของไคลเอนต์ที่เซิร์ฟเวอร์ได้รับ
• address lenght เป็นความยาวของแอดเดรสที่ร้องขอ
ในส่วนของฝั่งไคลเอนต์หลังจากสร้างซ็อกเก็ตเสร็จ ไคลเอนต์จำเป็นต้องสร้างการเชื่อมต่อโดยการใช้คำสั่ง
connect ในการกำหนดแอดเดรสก่อนที่จะเริ่มการส่งขอมูล โดยที่รูปแบบของคำสั่ง connect จะเป็น
connect(socket, dest address, address lenght)
• socket หมายถึงซ็อกเก็ตที่จะเชื่อมต่อ (connect)
• destination address หมายถึงแอดเดรสของภาครับที่ต้องการเชื่อมต่อ
234 บทที่ 29. APPLICATION LAYER
• address lenght ความยาวของแอดเดรสภาครับ
ในทำนองเดียวกันการทำงานของการสร้างการเชื่อมต่อแบบ connnectionless สามารถแสดงได้ในรูปที่ 29.3
เนื่องจากไม่จำเป็นต้องมีการสร้างการเชื่อมต่อล่วงหน้า ทำให้การทำงานของ connectionless ลดขั้นตอนลง เหลือ
เพียงคำสั่ง bind และ connect เท่านั้น
book)
(partial
รูปที่ 29.3: การสร้างการเชื่อมต่อแบบ Connectionless
only
29.1.2 การรับส่งข้อมูลผ่านซ็อกเก็ต
จากรูปที่ 29.2 และ 29.3 หลังจากการเชื่อมต่อสิ้นสุด ภาคส่งและภาครับ หรือไคลเอนต์และเซิร์ฟเวอร์สามารถที่จะ
KKU
สื่อสารกันได้ โดยทั่วไปจะประกอบด้วย 5 คำสั่งได้แก่ send sendto sendmsg write และ writeev เพื่อใช้ในการ
ส่งข้อมูล ในทำนองเดียวกันในส่วนของภาครับมี 5 คำสั่งเช่นเดียวกัน ได้แก่ read, readv, recv, recvfrom และ
recvmsg การใช้งานของคำสั่งต่างๆ จะไม่กล่าวถึงในที่นี้ผู้สนใจสามารถศึกษาได้จาก Internetworking with TCP/
IP
29.2 File Transfer Protocol (FTP)
File Transfer Protocol (FTP) เป็นโปรแกรมที่ถูกใช้มาตั้งแต่การเกิดขึ้นของ ARPAnet จุดประสงค์หลักเพื่อใช้
ในการถ่ายโอนข้อมูลระหว่างคอมพิวเตอร์ FTP สามารถรองรับระบบไฟล์และรูปแบบข้อมูลที่แตกต่างกัน ตัวอย่าง
เช่น โฮสต์ที่ใช้รูปแบบไฟล์ที่เป็น รหัส EBCIDIC สามารถที่จะทำการส่งข้อมูลกับโฮสต์ที่ใช้รูปแบบที่เป็นรหัสแอสกี
(ASCII) ได้ แม้จะเห็นว่ารูปแบบทั้งสองแตกต่างกัน ปัจจุบันการทำงานของ FTP สามารถสนับสนุนรูปแบบที่เป็น
รหัสแอสกี (ASCII) และที่เป็นแบบไบนารี (binary) ได้
FTP ใช้ Network Virtual Terminal (NVT) เพื่อส่งคำสั่งติดตั้งต่างๆ โดยที่คำสั่งของ NVT จะปิดท้ายด้วย
carriage return (CR) และ line feed character (LF) ตัวอย่างคำสั่ง เช่น คำสั่ง LIST เป็นการเรียกไฟล์และได
เร็กทรอรี หรือ คำสั่ง SYST เพื่อเรียกดูข้อมูลระบบจากเครื่องเซิร์ฟเวอร์แต่ละคำสั่งจะได้รับการตอบกลับ (ACK)
ด้วยโค้ดต่างๆ ที่ถูกกำหนดขึ้นใน RFC 959 เช่น x2z เป็นการตอบกลับ Request จากการเรียกของ Status และ
คำสั่งขอความช่วยเหลือ การทำงานของ FTP จะใช้การเชื่อมต่อจำนวน 2 คอนเน็คชัน คอนเน็คชันแรกจะใช้พอร์ต
29.3. เว็บเบราว์เซอร์ (WEB BROWSER) 235
หมายเลข 21 ในการส่งคำสั่ง และอีกหนึ่งคอนเน็คชันเพื่อถ่ายโอนข้อมูลที่พอร์ตหมายเลข 20 ทั้งสองคอนเน็คชัน
เป็นแบบ TCP
รูปแบบการสื่อสารแบบ FTP
การสื่อสารของ FTP จะใช้ไปป์ไลน์ (pipeline) สองอันดังแสดงในรูปที่ 29.4 อันที่หนึ่งสำหรับการสื่อสารส่งผ่านคำ
สั่งระหว่างไคลเอนต์และเซิร์ฟเวอร์ อีกอันหนึ่งสำหรับการถ่ายโอนข้อมูลและอื่นๆ ในช่องแรกเพื่อใช้ในการส่งคำสั่ง
จะถูกเปิดไว้ตลอดการใช้งาน FTP ในส่วนของการถ่ายโอนข้อมูลจะเปิดเมื่อทำการถ่ายโอนเท่านั้น และจะเปิดแบบ
ทางเดียวเท่านั้น จากไคลเอนต์ไปเซิร์ฟเวอร์หรือในทางตรงข้าม
book)
(partial
รูปที่ 29.4: โครงสร้างการสื่อสารของ FTP
only
เมื่อเริ่มการใช้งาน FTP ไคลเอนต์จะใช้ช่องสื่อสารแรกในการเชื่อมต่อไปหาเซิร์ฟเวอร์ โดยใช้ TCP พอร์ต
หมายเลข 21 พร้อมทั้งชื่อผู้ใช้ (username) และรหัสผ่าน (password) เพื่อเริ่มการใช้งาน FTP session เพื่อการ
สื่อสารแบบง่ายๆ เช่นการร้องขอ (request) และการตอบกลับ (response) ช่องสื่อสารนี้จะถูกใช้งานเมื่อมีการ
KKU
ร้องขอการถ่ายโอนข้อมูล ช่องสัญญาณที่สองจะเริ่มถูกใช้งาน ซึ่งการที่จะใช้ช่องที่สอง สามารถทำได้สามวิธี การ
ทำงานโดยปริยายจะเกิดขึ้นโดยเซิร์ฟเวอร์จะสร้างการเชื่อมต่อที่สองโดยใช้ซ็อกเก็ตบน TCP พอร์ต 20 และเชื่อมไป
ยังซ็อกเก็ตที่สองบนไคลเอนต์โดยการใช้แอดเดรสและพอร์ตเดียวกันกับซ็อกเก็ตแรก
อย่างไรก็ตาม ไคลเอนต์อาจใช้แอดเดรสและพอร์ตอื่นเพื่อใช้ในการถ่ายโอนข้อมูล ในกรณีนี้เซิร์ฟเวอร์จะใช้
หมายเลขใหม่ เพื่อการเชื่อมไปยังไคลเอนต์อีกหนึ่งทางคือ การที่ไคลเอนต์ถ่ายโอนข้อมูล โดยให้เซิร์ฟเวอร์อยู่ใน
โหมดแพสซิฟ (passive) วิธีนี้ เซิร์ฟเวอร์จะตอบกลับด้วยแอดเดรสและพอร์ตที่จะใช้ในการโอนถ่ายข้อมูล (โดย
ทั่วไป หากไคลเอนต์เป็นคนเริ่มต้นการร้องขอการเชื่อมต่อ เซิร์ฟเวอร์จะใช้พอร์ตอื่นที่ไม่ใช่พอร์ต 20 และ 21)
หลังจากการโอนข้อมูลเรียบร้อย การเชื่อมต่อจะสิ้นสุดลง และจะเปิดใหม่เมื่อไคลเอนต์ที่คำสั่งเพื่อเปิดการ
เชื่อมต่อใหม่
29.3 เว็บเบราว์เซอร์ (Web Browser)
เบราว์เซอร์หรือเว็บเบราว์เซอร์เป็นแอพพลิเคชันที่ทำให้เราสามารถเชื่อมต่อไปยังเว็บเซิร์ฟเวอร์โดยทั่วไปจะประกอบ
ไปด้วยส่วนที่เป็น Markup language เรียกว่า Hypertext Markup Language (HTMP) [5] ในการสร้างหน้าเพจ
ในการติดต่อกับผู้ใช้HTMP เป็นหนึ่งในภาษาที่เขียนขึ้นโดยการใช้รูปแบบของtag เพื่อทำให้เกิดรูปแบบของเอกสาร
แบบ Hypertext และการเชื่อมต่อไปยังหน้าเอกสารอื่น โดยการเชื่อมต่อนี้ อาจประกอบไปด้วยตัวอักษร รูปภาพ
เสียง และวิดีโอ และในส่วนของ HyperText Transfer Protocol (HTTP) [47] เป็นโพรโตคอลใน Application
236 บทที่ 29. APPLICATION LAYER
Layer เพื่อใช้ในการสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ในเว็ปแอพพลิเคชันนอกเหนือจากนั้นยังอาจประกอบไป
ด้วยส่วนของ FTP, NNTP, อีเมล (POP และ SMTP)
29.3.1 หลักการทำงานของ HTTP
การทำงานของ HTTP เป็นการทำงานในรูปที่มีการร้องขอและการตอบกลับ (request-response interaction)
การสื่อสารเกิดขึ้นโดยไคลเอนต์ร้องขอไปยังเซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะตอบกลับ โดยการร้องขอนี้อาจประกอบ
ไปด้วยส่วนต่างเช่น คำสั่งที่เกี่ยวข้องกับการร้องขอ เช่น GET, PUT หรือ POST, Uniform Resource Locator
(URL) เพื่อระบุข้อมูลที่ร้องขอ และอื่นๆ เช่น ประเภทของข้อมูล ข้อมูลด้านความปลอดภัย เป็นต้น เมื่อเซิร์ฟเวอร์
ได้รับการร้องขอนี้จะตรวจสอบและส่งกลับไปยังไคลเอนต์ที่ร้องขอเพื่อแสดงสถานะของการร้องขอ เวอร์ชันของ
โพรโตคอลที่ใช้ และ ข้อมูลที่ร้องขอ ที่เกิดจากการทำงานของฝังเซิร์ฟเวอร์การทำงานของ HTTP สามารถแบ่งออก
เป็น 4 ขั้นตอนดังแสดงในรูปที่ 29.5
book)
(partial
รูปที่ 29.5: การทำงาน request-response ของ HTTP
only
1. เบราว์เซอร์สร้างการเชื่อมต่อโดย TCP/IP ไปยังเซิร์ฟเวอร์
KKU
2. เบราว์เซอร์ส่งการร้องขอไปยังเซิร์ฟเวอร์ อาจประกอบด้วย URL และข้อมูลอื่นๆ
3. เซิร์ฟเวอร์ตอบกลับไปยังเบราว์เซอร์เช่นข้อความบน HTML, รูปภาพ และ อื่นๆ
4. ปิดการเชื่อมต่อของ TCP/IP
การทำงานของ HTTP เป็นแบบ stateless protocol อยู่บนพอร์ต 80 โดยปริยาย เนื่องจากการทำงานของ
โพรโตคอล HTTP จะไม่มีการเก็บสถานะของผู้ใช้ หากผู้ใช้ร้องขอสิ่งเดียวกันในเวลาที่ใกล้กัน เซิร์ฟเวอร์จะตอบกลับ
การร้องขอไปใหม่โดยไม่แจ้งว่า สิ่งที่ร้องขอได้จัดส่งไปแล้ว การใช้การทำงานแบบ stateless นี้ถือว่าเป็นการลด
ภาระของระบบในการสนับสนุนผู้ใช้จำนวนมาก แต่อย่างไรก็ตามทำให้เกิดผลเสียในแง่ประสิทธิภาพกับการทำงาน
ของโพรโตคอล HTTP เช่นกัน จะเห็นได้จากการทำงานของโพรโตคอล HTTP เวอร์ชัน 1.0 หากผู้ใช้ร้องขอไปยังหน้า
เว็ปที่ประกอบไปด้วยข้อความและรูปจำนวนมากในหน้าเว็ป จะทำให้มีร้องขอเพื่อสร้างการเชื่อมต่อ (SYN) และการ
ปิดการเชื่อมของ TCP จำนวนมากดังแสดงในรูปที่ 29.6(a) ดังจะเห็นได้จากจำนวนของ RTT ที่เกิดขึ้น
เพื่อแก้ไขปัญหาที่เกิดขึ้น HTTP เวอร์ชัน 1.1 (รูปที่ 29.6(b)) จะรักษาการเชื่อมต่อของ TCP ตลอดการร้องขอ
หรือเรียกว่า persistent connection การทำงานของ HTTP เวอร์ชัน 1.1 นี้จะให้อนุญาตให้การสร้างการเชื่อม
ต่อ TCP แต่ละครั้งสามารถมีการหลายการร้องขอของ HTTP ทำให้ลดความจำเป็นในการสร้างการเชื่อมต่อกับ
TCP ใหม่ทุกครั้ง นอกจากนี้การทำงานของ HTTP เวอร์ชัน 1.1 ยังสามารถทำงานในลักษณะที่เป็น pipeline of
requests หมายถึง การที่การร้องขอของไคลเอนต์สามารถที่จะส่งต่อไปอย่างต่อเนื่อง โดยไม่จำเป็นต้องได้รับการ
ตอบกลับก่อน
29.4. สตรีมมิ่งมีเดีย (STREAMING MEDIA) 237
book)
รูปที่ 29.6: การทำงานของ HTTP 1.0 และ HTTP 1.1
(partial
นอกจากนี้ หากมองในแง่ของการทำงานใน TCP ที่จะมีการทำ slow start เมื่อมีการสร้างการเชื่อมต่อทุกครั้ง
ในการที่จะทดสอบประสิทธิภาพของเน็ตเวิร์คในการรองรับการส่งข้อมูลบน TCP เนื่องจากการร้องขอในแต่ละรอบ
ค่อนข้างเล็ก การทำงานของ HTTP เวอร์ชัน 1.0 ซึ่งมีการเปิดปิดการเชื่อมต่อบ่อยครั้ง ทำให้การทำงานของ slow
start ยังไม่แล้วเสร็จ การเชื่อมต่อก็สิ้นสุดลงก่อน ทำให้เกิดปัญหาในแง่ของความคับคั่งของข้อมูลและการสื่อสารที่
only
ไม่จำเป็นอื่นเกิดขึ้น (overhead) [30]
29.4 สตรีมมิ่งมีเดีย (Streaming Media)
KKU
แม้ว่าการทำงานของ HTTP จะสามารถทำการส่งข้อความรวมไปถึงรูปภาพได้ดี แต่อย่างไรก็ตามการใช้งานของ
HTTP ไม่สามารถที่จะใช้ในกรณีของสตรีมมิ่งมีเดียได้ดี เช่นการดูภาพยนต์หรือฟังเพลงออนไลน์ และการทำงาน
ของ HTTP อยู่บน TCP ซึ่งไม่เหมาะกับแอพพลิเคชันที่ต้องการส่งในลักษณะที่เป็นแบบมัลติมีเดีย ทำให้เราต้องการ
โพรโตคอลอื่นที่สามารถสนับสนุนการทำงานของมัลติมีเดียได้ดี ซึ่งปัจจุบันคงเลี่ยงไม่ได้ในการกล่าวถึงแอพพลิเคชัน
ที่เป็นมัลติมีเดียแบบต่างๆ เช่น Real Networks RealOne player, Microsoft's Windows Media Player,
Skepe, Apple's Facetime, Line for Android ถือเป็นแอพพลิเคชันที่สำคัญเพื่อการสื่อสารที่เป็นลักษณะภาพ
และเสียงหรือเป็นเสียงเท่านั้น
เพื่อให้ผู้อ่านเข้าใจการเข้าใจการทำงานของแอพพลิเคชันแบบมัลติมีเดียนี้ ในส่วนนี้จะได้กล่าวถึงการทำงาน
ของโพรโตคอลที่เกี่ยวข้อง ได้แก่ Real Time Protocol (RTP) และโพรโตคอลร่วม RTP Control Protocol (RTCP)
29.4.1 Real-time Transport Protocol (RTP)
Real-time Transport Protocol (RTP) ถูกออกแบบเพื่อสนับสนุนการทำงานของแอพพลิเคชันแบบมัลติมีเดียแบบ
เวลาจริง (Real-time multimedia application) เช่น เสียงหรือภาพผ่านการทำงานบนอินเทอร์เน็ต การทำงาน
ของ RTP จะเพิ่มฟังก์ชันที่จำเป็นบนโพรโตคอล UDP ทำให้สามารถสนับสนุนการทำงานแบบมัลติคาสท์ได้ ซึ่งเป็น
ฟังก์ชันที่สำคัญในการสนับสนุนการทำงานของวิดีโอบนอินเทอร์เน็ต นอกจากนั้นยังสามารถที่จะใช้ TCP ได้ เพื่อส่ง
238 บทที่ 29. APPLICATION LAYER
ผ่านไฟร์วอลล์ (firewall) การให้บริการของ RTP รวมถึงการระบุถึงประเภทของข้อมูล (payload) ลำดับของข้อมูล
(sequence number) การระบุเวลาส่ง (timestamping) และการตรวจสอบการส่งข้อมูล
การทำงานของ RTP อาศัยการสร้างเซสชัน (Session) ระหว่างผู้ใช้ ระหว่างการสื่อสารข้อมูล โดยมีการสร้าง
สัญญาณควบคุมอาศัย Real-time Transport Control Protocol (RTCP) โดยที่แต่ละเซสชันจะประกอบไปด้วย
• พอร์ตของ RTP: เพื่อใช้ในการโอนถ่ายข้อมูลระหว่างผู้ใช้ของ RTP หากการถ่ายโอนของข้อมูลที่กล่าวถึงใช้
UDP ในส่วนของ Transport Layer หมายเลขพอร์ตนี้จะถูกกำหนดลงใน Destination Port ของ UDP
• พอร์ตของ RTCP: เพื่อใช้ในการโอนถ่ายข้อมูลระหว่างผู้ใช้ของ RTCP
• IP Address ของผู้ใช้: สามารถเป็นได้ทั้ง Multicast Address หรือกลุ่มของ IP Address
book)
(partial
only รูปที่ 29.7: Real-Time Protocol
KKU
แม้ว่าการทำงานของ RTP สามารถที่จะส่งข้อมูลที่เป็นแบบ unicast ได้ แต่จุดเด่นของการสื่อสารของ RTP คือ
การสนับสนุนการสื่อสารแบบมัลติคาสท์ เพื่อสนับสนุนการทำงานนี้ แต่ละ RTP จะระบุต้นทางที่ทำการส่งข้อมูลเข้า
สู่ระบบ นอกจากนี้ยังกำหนดค่า Timestamp ทำให้ภาครับสามารถจัดการข้อมูลให้เหมาะสมตามเวลา โดยอาศัย
บัฟเฟอร์ของภาครับ และ RTP จะกำหนดรูปแบบของข้อมูลระหว่างการส่ง
29.4.2 รูปแบบของแพกเกต RTP (RTP Packet Format)
รายละเอียดของเฮดเดอร์มีดังนี้
• Ver : ระบุเวอร์ชันของ RTP ปัจจุบันเป็นเวอร์ชัน 2
• P : หากเป็น 1 แสดงว่ามีการใส่ข้อมูลเพิ่มเติมเพื่อการทำงานบางอย่าง เช่น การเพิ่มไบต์ให้เพียงพอใน
การเข้ารหัส หากเป็น 0 แสดงว่าไม่มีการเพิ่มจำนวนไบต์เข้าไป หากในเลเยอร์ล่างเป็น UDP ความยาวของ
ข้อมูล RTP สามารถที่จะทำการหาได้จากความยาวของข้อมูลใน UDP ลบด้วยความยาวของเฮดเดอร์ RTP
(RTP data = UDP data − RTP header) หากมีการเพิ่มเติมไบต์ความยาวของข้อมูลของ RTP จะต้องทำการลบ
ด้วยจำนวนที่เพิ่มเข้าไป จำนวนที่ทำการเพิ่มเข้าไปสามารถจะระบุในไบต์สุดท้ายของการเพิ่ม
• X : เป็นบิตเพื่อระบุกรณีที่มีเฮดเดอร์เพิ่มเดิม ขึ้นอยู่กับแอพพลิเคชันที่ระบุจะอยู่ต่อจากเฮดเดอร์หลัก ถ้า
เป็น 1 แสดงว่ามีเฮดเดอร์เพิ่มเดิม หากเป็น 0 แสดงว่าไม่มี
29.4. สตรีมมิ่งมีเดีย (STREAMING MEDIA) 239
0 7 8 15 31
Ver P X CC M Payload Type Sequence number
Timestamp
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifier (1)
...
Contributing source (CSRC) identifier (N)
Extension header
RTP Payload book)
(partial
รูปที่ 29.8: รูปแบบของ RTP เฮดเดอร์
only
รูปที่ 29.9: การเพิ่มจำนวนไบต์ของ RTP
• Contributor count : ในที่นี้ Contributor หมายถึงโนดที่ส่งข้อมูลเข้าสู่ระบบ (Source) หรือต้นทาง
KKU
เนื่องจากฟิลด์นี้ทำการกำหนดไว้ 4 บิตทำให้มีจำนวนต้นทางที่สามารถรองรับได้อยู่เท่ากับ 16 โนด (CSRC)
• M : เป็น Marker บิตขึ้นอยู่กับข้อมูลที่ทำการส่ง โดยทั่วไปจะใช้ในการระบุขอบเขตของข้อมูลที่ถูกส่งแบบ
ต่อเนื่อง (data stream) สำหรับ VDO จะถูกใช้เพื่อระบุจุดสิ้นสุดของเฟรม สำหรับเสียงจะใช้ในการระบุ
การเริ่มต้นการพูด
• Payload type : เป็นฟิลด์ขนาด 7 บิต เพื่อใช้ในการระบุประเภทของ payload (ข้อมูลที่ส่ง) ปัจจุบันได้มี
การกำหนด ประเภทข้อมูลไว้ เช่น Type = 14 เป็น MPEG audio, Type = 31 เป็น H.261, Type = 32
เป็น MPEG1 video และ Type = 33 เป็น MPEG2 video
• Sequence number : เสมือนการใช้งานใน TCP เพื่อระบุหมายเลขของแพกเกตโดยที่เลขเริ่มต้นจะถูก
เลือกอย่างอิสระ และเพิ่มขึ้นที่ละ 1 ของแพกเกตถัดมา การใช้งานเพื่อระบุการสูญหายของข้อมูล หรือการ
สลับหมายเลยการมาถึงของแพกเกต อย่างไรก็ตามการทำงานของ RTP จะไม่ทำการจัดการกับการสูญหาย
ของแพกเกต เหมือนดังเช่นใน TCP (เช่นทำการส่งใหม่) แต่ในที่นี้ จะปล่อยให้เป็นหน้าที่ของแอพพลิเคชัน
ในการจัดการกับการสูญหายนั้นๆ เช่น การปรับเปลี่ยนการเข้ารหัสเพื่อลงการใช้งานของแบนด์วิดท์เป็นต้น
• Timestamp : เป็นค่าเพื่อใช้แสดงความสัมพันธ์ของแพกเกต โดยที่ timestamp ของแพกเกตไบต์แรกจะ
เป็นการสุ่ม จากนั้นแพกเกตถัดมาจะเป็นค่าของผลบวกระหว่างค่าของ timestamp ก่อนหน้ากับค่าของ
ไบต์แรกที่ทำการสร้างขึ้น โดยค่าของสัญญาณเวลาจะถูกกำหนดโดยแอพพลิเคชัน
240 บทที่ 29. APPLICATION LAYER
• Synchronization source (SSRC) identifier : ใช้ในการระบุโนดต้นทาง ถ้าหากมีเพียงโนดต้นทางเดียว
32-บิตนี้จะกำหนดหมายเลขโนดที่ส่งข้อมูล แต่หากมีมากกว่าหนึ่งโนด มิกเซอร์จะทำหน้าที่ในการรวม
stream ทั้งหมดเป็นหนึ่ง stream เพื่อทำการส่งต่อ SSRC ส่วนที่เหลือจะเป็น contributing source หรือ
CSRC โดย SSRC เป็นค่าที่สุ่มขึ้น เพื่อทำการกำหนดต้นทางของเซสชัน
• Contributing source (CSRC) identifier : เป็นเลขขนาด 32 บิต เพื่อใช้ในการระบุโนดที่ส่งสตรีมจริง
หรือ Contributing source เช่นในกรณีมีโนดจำนวนสองโนดส่งสตรีมพร้อมกันผ่านมิกเซอร์ โดยมิกเซอร์
จะทำการรวมสตรีมทั้งสองเป็นสตรีมเดียวพร้อมทั้งให้กำหนด SSRC ตนเอง ส่วนโนดทั้งสองจะถูกกำหนด
เป็น CSRC
การทำงานของ RTP จะทำการสนับสนุนการทำงานของ Relay ด้วยกันสองแบบคือ Translators และ มิกเซอร์
(Mixesr) การทำงานของ Relay สามารถเป็นได้ทั้งภาคส่งและภาครับระหว่างการส่งข้อมูล ตัวอย่างได้แก่การส่ง
ข้อมูลระหว่างโนด A ไปยังโนด B โดยที่อาจเนื่องจากโนด B อยู่หลัง Firewall หรือโนด B ไม่รองรับข้อมูลที่ โนด A
ส่งมา ทำให้โนด A ไม่สามารถที่จะส่งไปโนด B ได้โดยตรง ทำให้โนด A ส่งไปให้โนด X แทน เพื่อส่งต่อไปให้โนด B
โดยโนด X อาจแปลงข้อมูลเพื่อให้เหมาะสมก่อนที่จะทำการส่งต่อไป B book)
• มิกเซอร์ (Mixer) ทำหน้าที่ในการสร้างสตรีมใหม่ จากโนดต้นทางหนึ่งหรือหลายโนด เพื่อส่งต่อไปให้ภาค
(partial
รับ ในระหว่างการส่งต่อ มิกเซอร์อาจแปลงสตรีมให้อยู่ในรูปแบบที่เหมาะสม เช่นการลดการใช้แบนด์วิด
ท์ลง หรือเพียงทำการรวมข้อมูลเท่านั้น ซึ่งสามารถเป็นได้ทั้งการส่งเพื่อไปหาโนดปลายทางเดียวหรือหลาย
โนดพร้อมกัน เพื่อทำการซิงโครไนซ์สตรีมทั้งหมดใหม่ มิกเซอร์อาจทำตนเองเสมือนโนดต้นทางใหม่ของ
การส่งข้อมูล (SSRC) และส่งข้อมูลเวลาของตนไปด้วย เนื่องจากเวลาของแต่ละโนดต้นทางอาจไม่เท่ากัน
นอกจากนี้ เพื่อให้สามารถระบุถึงโนดที่สื่อสารด้วยจริง แพกเกต RTP จะใส่โนดที่เป็นโนดที่ส่งข้อมูลจริง
only
(CSRC) ไปด้วย
• Translator ทำหน้าที่ในการสร้าง RTP แพกเกตขาออกสำหรับแต่ละ RTP ที่เข้ามา Translator อาจ
ทำการแปลงรูปแบบของข้อมูล หรือทำการใช้โพรโตคอลอื่นๆในการทำการแปลง ตัวอย่าง การทำงานของ
KKU
Translator ได้แก่
– ความไม่เท่าเทียมของความสามารถของภาครับ เนื่องจากภาครับบางส่วนอาจไม่สามารถรองรับ
VDO ที่ความเร็วสูงได้ ทำให้ Translator ต้องแปลงข้อมูลให้มีคุณภาพที่ตํ่าลง ก่อนที่จะทำการส่ง
ต่อไป
– Translator สามารถที่จะทำซํ้าแพกเกตที่เป็นแบบมัลติคาสท์เป็นแบบหลายยูนิคาสท์ เนื่องจากภาค
รับอาจไม่สามารถจะทำการรับแพกเกตที่เป็นแบบมัลติคาสท์ได้ และสามารถช่วยในการทำการส่ง
– Translator อาจจัดการกับแพกเกตให้สามารถส่งผ่านไฟร์วอลล์ได้
การทำงานของ Translator จะทำการส่งต่อข้อมูลซึ่งต่างจากการทำงานของมิกเซอร์ คือ Translator จะไม่
ทำตนเสมือนโนดต้นทางไหม่ ทำให้การส่งต่อไม่มีการเปลี่ยนหมายเของ SSRC และจะไม่ทำซิงโครไนซ์สตรีม
ทั้งหมดใหม่ หรือส่งข้อมูลเวลาของตนไปด้วย
รูปที่ 29.10 แสดงการทำงานของมิกเซอร์ และ Translator สมมุติให้ในระบบประกอบด้วยโนดภาคส่งจำนวน
สี่โนด อีกหนึ่งโนดเป็นภาครับ นอกจากนี้ ในระบบยังประกอบด้วยมิกเซอร์ และ Translotor สมมุติให้ในระบบมี
หมายเลขของ SSRC ID ตามรูป แม้ว่ามาในความเป็นจริงแล้วค่าของ SSRC ID และ CSRC ID นี้จะถูกกำหนดขึ้น
แบบสุ่ม จากรูปจะเห็นว่าเมื่อ SSRC =1 และ SSRC = 2 ส่งผ่านมายังมิกเซอร์ มิกเซอร์จะทำการรวมสตรีมทั้งสอง
เป็นสตรีมใหม่ ในที่นี้สมมุติให้เป็น SSRC =1 จากที่กล่าวมาแล้วเพื่อให้สามารถบ่งถึงโนดที่ส่งข้อมูลจริงได้ มิกเซอร์
29.4. สตรีมมิ่งมีเดีย (STREAMING MEDIA) 241
รูปที่ 29.10: ตัวอย่างการทำงานของมิกเซอร์ และ Translator
จะทำการกำหนด CSRC เป็น 1 และ 2 และใช้ SSRC ของตนเองได้แก่ SSRC = 11 เพื่อใช้ในการส่งแพกเกต RTP
book)
จากนั้นเมื่อสตรีมถูกส่งผ่านไปยัง Translator ในเวลาเดียวกันมีสตรีมจาก SSRC = 3 ด้วย ทำให้ Translator สลับ
การใช้บริการ (interleave) สตรีมทั้งสอง (SSRC = 11 และ SSRC =3) อย่างไรก็ตาม เนื่องจากการทำงานของ
Translator ไม่ได้ทำการซิงโครไนซ์สตรีมทั้งหมดใหม่ ทำให้ SSRC ทั้งสองมีค่าเท่าเดิม จากนั้นเมื่อสตรีมทั้งหมดถูก
ส่งไปยังปลายทางผ่านมิกเซอร์ SSRC = 12 สตรีมทั้งหมดจะถูกกำหนดให้เป็น CSRC แทนและใช้ SSRC = 12 ดัง
รูป
29.4.3 RTP Control Protocol (partial
RTP Control Protocol (RTCP) เป็นโพรโตคอลที่ใช้เพื่อเป็นการสื่อสารของสัญญาณควบคุมในการทำงานของ RTP
only
พื้นฐานการทำงานของ RTCP เพื่อสนับสนุนการใช้แจ้งกลับ (feedback) ของ QoS ด้วยการส่งข้อมูลทางสถิติให้กับ
สมาชิกในกลุ่ม (paticipants) ของ session มัลติมีเดียเป็นช่วงๆ
RTCP ทำการรวบรวมข้อมูลทางสถิติของมีเดีย เช่น จำนวนแพกเกต จำนวนแพกเกตที่สูญหาย ข้อมูล Jitter
KKU
และ RTT ทำให้แอพพลิเคชันสามารถที่จะใช้ข้อมูลนี้ เพื่อควบคุมการทำงานของ QoS เช่น การควบคุมขนาดของ
flow และการใช้งานของ codec แบบต่างๆ จากข้อมูลของ RFC 1889 กำหนดการทำงานของ RTCP เป็น 4 ฟังก์ชัน
1. Quality of Service (QoS) และ congestion control : RTCP แจ้งคุณภาพของข้อมูล เนื่องจาก RTCP
เป็นการทำงานแบบมัลติคาสท์ สมาชิกที่อยู่ใน session เดียวกันสามารถที่จะรับทราบว่าสมาชิกอื่นทำงาน
เป็นอย่างไร การแจ้งของภาคส่งทำให้ภาครับสามารถที่จะประมาณอัตราเร็วของข้อมูล และคุณภาพของการ
ส่งข้อมูล การแจ้งของภาครับทำให้ทราบถึงปัญหาที่เกิดขึ้นเช่น การสูญหายของแพกเกตหรือค่าของ Jitter
ทำให้ภาคส่งอาจลดความเร็วของการส่งของตนเองลง หากพบว่าคุณภาพของช่องสัญญาณไม่สามารถที่จะ
รองรับความต้องการของมัลติมีเดียที่ตนจะส่งได้
2. Identification : เพื่อเป็นการบอกถึงลักษณะของข้อมูล RTP เรียกว่า the canonical name หรือ
CNAME ที่นอกเหนือจากที่ระบุใน SSRC เนื่องจาก SSRC อาจมีการเปลี่ยนแปลงตลอดเวลา ทำให้ผู้ใช้
สามารถที่จะเข้าร่วมหลายสตรีมจากหลายเซสชัน เช่นการใช้งานเซสชันของวีดีโอ และเซสชันของเสียง
3. Session size estimation and scaling: เพื่อทำงานในฟังก์ชันทั้งสองที่กล่าวไป สมาชิกในกลุ่มจะส่ง
แพกเกต RTCP เป็นช่วง โดยที่อัตราการส่งของแพกเกตจะลดลงเมื่อมีสมาชิกในกลุ่มเพิ่มขึ้น ในกรณีของ
session ที่มีจำนวนสมาชิกในกลุ่มน้อย RTCP จะส่งในอัตราสูงสุดที่หนึ่งแพกเกตทุก 5 วินาที นอกจากนี้
ใน RFC 1889 ยังมีการกำหนดการใช้งานอัลกอริทึมเพื่อจำกัดอัตราการส่ง RTCP บนพื้นฐานของจำนวน
The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.
Discover the best professional documents and content resources in AnyFlip Document Base.
Search