ข้อสังเกต
จากรูปที่
2.6
การทำงานของไคลเอนต์-เซิฟเวอร์
ภายใต้โปรโตคอลเอชทีทีพี สามารถที่จะทำงานจากระบบปฏิบัติการที่ต่างกัน หรือ โปรแกรมบราวเซอร์ที่ต่างกันได้
เอชทีทีพี
ใช้การเชื่อมต่อในชั้นทรานสปอตเป็นแบบ TCP เพราะต้องการการทำงานแบบ
น่าเชื่อถือ (Reliable)
กล่าวคือการส่งข้อมูลจากต้นทางจะต้องไปถึงปลายทางเสมอ
โดยก่อนที่จะมีการส่งข้อความของโปรโตคอลเอชทีทีพี (HTTP Message) ต้องมีการติดตั้ง TCP คอนเน็คชั่น เสียก่อน (ขั้นตอนการติดตั้ง TCP
คอนเน็คชั่นเรียกว่า 3-Way Handshake จะอธิบายในบทที่
3) โดยพอร์ตที่ใช้สำหรับการเชื่อมต่อคือ พอร์ต 80
ขั้นตอนการทำงานโดยรวมจะเป็นดังต่อไปนี้
1
ไคลเอนต์เริ่มต้นขอสร้าง TCP คอนเน็คชั่นที่พอร์ต 80 ไปยังเซิฟเวอร์
2
เซิฟเวอร์ตอบรับการขอสร้าง TCP คอนเน็คชั่น
3 ไคลเอนต์และเซิฟเวอร์ทำการแลกเปลี่ยนข้อมูลระหว่างกัน โดยไคลเอนต์ส่ง HTTP
Request ไปยังเซิฟเวอร์ ขณะที่เซิฟเวอร์ตอบกลับด้วย HTTP Response
4 เมื่อการแลกเปลี่ยนข้อมูลสิ้นสุด จะทำการปิด TCP คอนเน็คชั่น
คุณสมบัติที่น่าสนใจอีกอย่างหนึ่งของการทำงานโปรโตคอล
เอชทีทีพี คือ การไม่เก็บสถานะการเชื่อมต่อระหว่างไคลเอนต์กับเซิฟเวอร์
หรือเรียกว่า Stateless
คุณสมบัตินี้ทำให้การทำงานของเซิฟเวอร์ไม่ซับซ้อน ถ้าโปรโตคอลใดๆที่มีการเก็บสถานะของการทำงาน
ระหว่างไคลเอนต์และเซิฟเวอร์ หรือเรียกว่า Stateful
จะมีการทำงานของเซิฟเวอร์ที่ซับซ้อนกว่า และมีข้อเสียในกรณีที่
เกิดปัญหาบนเซิฟเวอร์ซึ่งทำให้ต้องรีเซทเซิฟเวอร์ใหม่ จะทำให้สถานะเดิมที่เก็บอยู่สูญหายไปด้วย
2.2.2 คอนเน็คชั่นของ
HTTP
รูปแบบของคอนเน็คชั่นของ HTTP จะมี 2 ลักษณะ
1
Non-Persistent HTTP คือการที่ทางด้านเซิฟเวอร์สามารถส่งข้อมูล 1
ออปเจ็ค ต่อ TCP คอนนเคชั่น 1 ครั้ง
2
Persistent HTTP คือการที่ ทางด้านเซิฟเวอร์สามารถส่งข้อมูล
ได้มากว่า 1 ออปเจ็ค ต่อ TCP คอนนเคชั่น 1 ครั้ง
ตารางที่ 2.1
ลำดับการทำงานแบบ Non-Persitent HTTP
|
การทำงานด้านไคลเอนต์
|
การทำงานด้านเซิฟเวอร์
|
 1a ไคลเอนต์เริ่มต้นขอสร้าง
TCP คอนเน็คชั่น ที่พอร์ต 80 ไปยังเซิฟเวอร์ ของ
www.someSchool.edu
|
|
|
|
1b เซิฟเวอร์ของ
www.someSchool.edu ตอบรับการขอสร้าง TCP คอนเน็คชั่น และแจ้งกลับไปยังไคลเอนต์
|
 2 ไคลเอนต์
ส่ง HTTP
Request ซึ่งมีข้อมูลของ URL ไปบน TCP คอนเน็คชั่น
โดย URL
จะเป็นตัวบ่งบอกว่าต้องการไฟล์ใด และอยู่ที่ Path ใดบนเซิฟเวอร์
ในตัวอย่างนี้คือต้องการไฟล์ชื่อว่า home.index อยู่ภายใต้
Path /someDepartment ดังตัวอย่างด้านล่าง someDepartment/home.index
|
|
|
|
3 เซิฟเวอร์ทำการรับ HTTP Request และแปลความหมายของการร้องขอ
ว่าต้องการไฟล์ใด และที่ Path ใด
จากนั้นก็ทำส่งข้อมูลไฟล์ที่ไคลเอนต์ร้องขอกลับไปใน HTTP Response บน TCP คอนเน็คชั่น
|
|
|
4 เซิฟเวอร์ทำการปิด TCP
คอนเน็คชั่น
|
|
5
เมื่อ ไคลเอนต์ได้รับ HTTP Response แล้วก็จะนำข้อมูลไฟล์ที่ได้รับไปแสดงผล
เมื่อโปรแกรมบราวเซอร์ ตรวจสอบไฟล์ HTML ว่ามีออปเจ็คภายในอยู่
อีก 10 ออปเจ็ค
|
|
|
6
เริ่มทำงานขั้นตอน 1-5
ใหม่ อีก 10 ครั้ง
|
|
ตารางที่ 2.2
ลำดับการทำงานแบบ Persistent HTTP
|
การทำงานด้านไคลเอนต์
|
การทำงานด้านเซิฟเวอร์
|
1a ไคลเอนต์เริ่มต้นขอสร้าง
TCP คอนเน็คชั่น ที่พอร์ต 80 ไปยังเซิฟเวอร์ ของ
www.someSchool.edu
|
|
|
|
1b เซิฟเวอร์ของ
www.someSchool.edu ตอบรับการขอสร้าง TCP คอนเน็คชั่น และแจ้งกลับไปยังไคลเอนต์
|
2 ไคลเอนต์
ส่ง HTTP
Request ซึ่งมีข้อมูลของ URL ไปบน TCP คอนเน็คชั่น
โดย URL
จะเป็นตัวบ่งบอกว่าต้องการไฟล์ใด และอยู่ที่ Path ใดบนเซิฟเวอร์
ในตัวอย่างนี้คือต้องการไฟล์ชื่อว่า home.index อยู่ภายใต้
Path /someDepartment ดังตัวอย่างด้านล่าง someDepartment/home.index
|
|
|
|
3 เซิฟเวอร์ทำการรับ HTTP Request และแปลความหมายของการร้องขอ
ว่าต้องการไฟล์ใด และที่ Path ใด
จากนั้นก็ทำส่งข้อมูลไฟล์ที่ไคลเอนต์ร้องขอกลับไปใน HTTP Response บน TCP คอนเน็คชั่น
|
|
4
เมื่อ ไคลเอนต์ได้รับ HTTP Response แล้วก็จะนำข้อมูลไฟล์ที่ได้รับไปแสดงผล
เมื่อโปรแกรมบราวเซอร์ ตรวจสอบไฟล์ HTML ว่ามีออปเจ็คภายในอยู่
อีก 10 ออปเจ็ค
|
|
|
5 เริ่มทำงานขั้นตอน
2-4
ใหม่ อีก 10 ครั้ง
|
|
|
|
6 ทำการปิด TCP
คอนเน็คชั่นเมื่อไม่มีการติดต่อในระยะเวลาที่กำหนด
|
จากการทำงานของ Persistent
HTTP จะเห็นว่าทางด้านเซิฟเวอร์จะเปิด TCP
คอนเน็คชั่นรอไว้จนกว่า จะไม่มีการส่ง HTTP Request จึงจะทำการปิด TCP คอนเน็คชั่น ในการทำงานของ Persistent HTTP จะมีรูปแบบที่แตกต่างกันอีก 2 รูปแบบคือ
1
Persistent แบบ Non-Pipelining
2
Persistent แบบ Pipelining
การทำงาน Persistent แบบ Non-Piplining ในขั้นตอนที่ 2-4 จะทำงานเป็นแบบเรียงลำดับโดยกล่าวคือการส่ง HTTP Request
จะเกิดขึ้นได้ก็ต่อเมื่อทางด้านไคลเอนต์
ได้รับข้อมูลจากเซิฟเวอร์เรียบร้อยแล้ว ดังรูปที่
2.7(ก) ส่วนการทำงาน Persistent แบบ Pipelining
ในขั้นตอนที่ 2 สามารถส่ง HTTP Request ได้ต่อเนื่อง
โดยไม่ต้องรอให้เซิฟเวอร์ส่งข้อมูลมาที่ไคลเอนต์เสร็จสิ้นก่อน โดยแสดงดังรูปที่ 2.7(ข)
การวิเคราะห์ประสิทธิภาพการทำงานของ
HTTP คอนเน็คชั่นแบบต่างๆ
Non-Persistent HTTP เป็นแบบที่มีประสิทธิภาพต่ำที่สุด
เนื่องจากว่าจะต้องเสียเวลาในการเปิด และปิดคอนเน็คชั่นทุกๆครั้ง
ที่มีการร้องขอข้อมูล ทุกๆออปเจ็ค
Persistent
HTTP แบบ Non-Pipelining เป็นแบบที่มีประสิทธิภาพที่ดีกว่าแบบ Non-Persistent
กล่าวคือ เซิฟเวอร์จะยังคงเปิดคอนเน็คชั่นค้างไว้
จนกระทั่งไม่มีการร้องขอจากด้านไคลเอนต์
แต่มีข้อเสียที่การร้องขอออปเจ็คใหม่จะเกิดขึ้นได้จะต้องได้รับออปเจ็คที่ได้ร้องขอจากเซิฟเวอร์เสร็จสมบูรณ์ก่อน
Persistent
HTTP แบบ Pipelining เป็นแบบที่มีประสิทธิภาพที่ดีที่สุด กล่าวคือ
เซิฟเวอร์จะยังคงเปิดคอนเน็คชั่นค้างไว้
จนกระทั่งไม่มีการร้องขอจากด้านไคลเอนต์
แต่ต่างจาก Persistent HTTP แบบ
Non-Pipelining คือ การร้องขอออปเจ็คใหม่จะเกิดขึ้นได้ต่อเนื่องโดยไม่ต้องรอ
ออปเจ็คที่ได้ร้องขอจากเซิฟเวอร์เสร็จสมบูรณ์ก่อน ทำให้การร้องขอออปเจ็คทั้งหมดที่อยู่ใน
HTML ไฟล์เดียวกัน สามารถร้องขอทั้งหมดได้เกือบจะพร้อมกัน
และข้อมูลทั้งหมดที่ถูกร้องขอก็จะส่งกลับมาก็จะกลับมาภายในเวลาที่ใกล้เคียงกัน การทำงาน Persistent HTTP แบบ Pipelining เป็นโหมดปริยาย (Default Mode) ที่กำหนดในการทำงานบนเซิฟเวอร์ของ
HTTP
2.2.3 รูปแบบของ HTTP
Message
ข้อกำหนดของ HTTP ใน RFC 2616 ระบุถึงรูปแบบของ HTTP Message
ว่ามี 2 รูปแบบคือ HTTP Request และ HTTP
Response
HTTP Request
จากรูปที่
2.8
แสดงโครงสร้างการทำงานของ HTTP Request ดังนี้
HTTP Request จะใช้รหัสแอสกี้แทนตัวอักษรทั้งหมด
(เป็นรหัสที่สามารถอ่านหรือพิมพ์ได้) โดยแบ่งแยกการทำงานเป็นบรรทัด
ซึ่งคั่นด้วยรหัสการขึ้นบรรทัดใหม่ (Carriage Return & Linefeed,CRLF)
บรรทัดแรกสุดจะ เป็นบรรทัด Request บรรทัดที่สองเป็นต้นไปเป็นบรรทัดส่วนหัว (Header Line) จนกระทั่งสิ้นสุดโดยการใช้รหัสขึ้นบรรทัดใหม่
2 ครั้ง บรรทัดหลังจากนั้น(ถ้ามี) จะเป็นข้อมูลเอ็นติตี้ (Entity Body) ที่ส่งไปกับ HTTP Request
จากตัวอย่างในรูปที่
2.8
บรรทัดที่
1
เป็นการร้องขอโดยใช้วิธีการ Get ไปยัง Path /somedir/page.html ซึ่งทำงานโดยโปรโตคอล
HTTP เวอร์ชั่น 1.1
บรรทัดที่
3 (User-Agent) เป็นส่วนหัวที่บอกถึงโปรแกรมไคลเอนต์ที่ใช้งานชื่อ
Mozilla เวอร์ชัน 4.0
บรรทัดที่
4 (Connection) เป็นส่วนหัวที่บอกถึงสถานะของ TCP
คอนเน็คชั่นว่า ปิด (Close)
บรรทัดที่
5
(Accept-language) เป็นส่วนหัวที่บอกถึงภาษาของออปเจ็คที่ต้องการ
ถ้าเซิฟเวอร์มีออปเจ็คที่เป็นภาษาต่างๆ จากตัวอย่างในกรณีนี้ ส่วนหัวบอกถึงความต้องการขอออปเจ็คภาษาฝรั่งเศส
รูปที่
2.9 แสดงรูปแบบทั่วไปของ HTTP Request โดยบรรทัดแรกเป็นบรรทัดร้องขอ
หรือ Request Line ทำหน้าที่ระบุวิธีการที่จะใช้ติดต่อกับเซิฟเวอร์ผ่านทางฟิลด์
Method ซึ่งสามารถกำหนดทางเลือกในการติดต่อได้หลายวิธีการ
เช่น GET, POST, HEAD PUT และ DELETE เป็นต้น ในบรรทัดร้องขอ นี้แต่ละ
ฟิลด์จะแบ่งโดยการใช้ตัวอักษรว่าง (Space)
ฟิลด์ต่อมาคือ URLเป็นการระบุชื่อไฟล์และPath
บนเซิฟเวอร์ ที่ไคลเอนต์ต้องการ ฟิลด์ต่อมาคือ Version เป็นการระบุเวอร์ชั่นของ HTTP ตั้งแต่บรรทัดที่สอง
ก็จะเป็นส่วนหัว โดยเริ่มต้นด้วยฟิลด์ Header Field Name ซึ่งจะระบุชื่อของส่วนหัวต่างๆ
ดังตัวอย่างในรูปที่ 2.8 ฟิลด์ในส่วนหัวจะตามด้วยเครื่องหมาย
: (Colon) แบ่งด้วยการใช้รหัสว่าง จากนั้นตามด้วยฟิลด์ Value เป็นการบอกค่า ของส่วนหัวนั้นๆ ส่วนหัวจะสิ้นสุดเมื่อมีการใส่รหัสขึ้นบรรทัดใหม่
(CR//LF) ติดกัน 2 ครั้ง ต่อจากส่วนหัวจะเป็นพื้นที่ของข้อมูล
(Entity Body) ที่ต้องการจะส่งไปยังเซิฟเวอร์
HTTP
Request สามารถที่จะส่งข้อมูลไปยังเซิฟเวอร์ได้ 2 วิธีคือ
1 การส่งข้อมูลไปยังเซิฟเวอร์โดยกำหนดฟิลด์
Method เป็น GET จะเป็นการส่งข้อมูลไปยังเซิฟเวอร์
โดยข้อมูลจะถูกใส่อยู่ในฟิลด์ URL วิธีการนี้มักจะใช้ในกรณีที่จำนวนข้อมูลไม่มาก
ตัวอย่างเช่นเว็บไซต์สำหรับการค้นหาข้อมูล ที่ผู้ใช้ต้องป้อนข้อความในกาค้นหา
เพื่อส่งไปให้เซิฟเวอร์ประมวลผล
2 การส่งข้อมูลไปยังเซิฟเวอร์โดยกำหนดฟิลด์
Method เป็น POST จะเป็นการส่งข้อมูลไปยังเซิฟเวอร์
โดยข้อมูลจะถูกใส่อยู่ในฟิลด์ Entity Body
วิธีการนี้มักจะใช้ในการส่งข้อมูลจำนวนมาก และรูปแบบของข้อมูลมีความซับซ้อน
ตัวอย่างเช่น ข้อมูลแบบฟอร์มประวัติ เมื่อมีการสมัครสมาชิกของเว็บไซต์ เป็นต้น
Method
ที่สำคัญของ HTTP เวอร์ชั่น 1.1
GET/POST
– ทำหน้าที่ในการร้องขอข้อมูลจากเซิฟเวอร์ มีความแตกต่างกันในการส่งข้อมูลไปยังเซิฟเวอร์
ตามที่กล่าวมาแล้ว
HEAD – ทำหน้าที่ในการร้องขอเฉพาะข้อมูลส่วนหัว
เมื่อเซิฟเวอร์ได้รับ Method นี้จะส่งข้อมูล เฉพาะส่วนหัวของ HTTP Response
PUT
– ทำหน้าที่ในการส่งข้อมูลเข้าไปบนเซิฟเวอร์
โดยสามารถระบุตำแหน่งในการเก็บข้อมูลบนเซิฟเวอร์ได้
DELETE
– ทำหน้าที่ในการลบข้อมูลที่อยู่บนเซิฟเวอร์
โดยสามารถระบุตำแหน่งในการลบข้อมูลบนเซิฟเวอร์ได้
HTTP Response
จากรูปที่
2.10
แสดงโครงสร้างการทำงานของ HTTP Response ดังต่อไปนี้
HTTP Response จะใช้รหัสแอสกี้แทนตัวอักษรทั้งหมด
(เป็นรหัสที่สามารถอ่านหรือพิมพ์ได้) โดยแบ่งแยกการทำงานเป็นบรรทัด
ซึ่งคั่นด้วยรหัสการขึ้นบรรทัดใหม่ (Carriage Return & Linefeed, CRLF)
บรรทัดแรกสุดจะเป็นบรรทัด Status บรรทัดที่สองเป็นต้นไปเป็นบรรทัดส่วนหัว (Header Line) จนกระทั่งสิ้นสุดโดยการใช้รหัสขึ้นบรรทัดใหม่
2 ครั้ง บรรทัดหลังจากนั้น(ถ้ามี) จะเป็นข้อมูลเอ็นติตี้ (Entity Body) ที่ส่งไปกับ HTTP Response
จากตัวอย่างในรูปที่
2.10
บรรทัดที่
1
เป็นการบอกสถานะของการตอบกลับ โดยประกอบด้วยข้อมูล เวอร์ชั่นของ HTTP หมายเลขของสถานะ (Status Code) และ คำอธิบายสถานะ (Status
Pharse)
บรรทัดที่
2 (Connection) เป็นส่วนหัวที่บอกถึงสถานะของ TCP
คอนเน็คชั่นว่า ปิด (Close)
บรรทัดที่
3 (Date) เป็นส่วนหัวที่บอกถึงวันที่
ที่เซิฟเวอร์ตอบข้อมูลกลับ
บรรทัดที่
4 (Server) เป็นส่วนหัวที่บอกถึงการทำงานของเซิฟเวอร์
จากตัวอย่างในรูปที่ 2.9โปรแกรมเซิฟเวอร์ที่กำลังทำงานคือ Apache
เวอร์ชัน 1.3.0 และทำงานบนระบบ Unix
บรรทัดที่
5
(Last-modified) เป็นส่วนหัวที่บอกถึงวันที่
ที่ข้อมูลถูกสร้างหรือแก้ไขครั้งล่าสุด
บรรทัดที่
6
(Content-length) เป็นส่วนหัวที่บอกถึงความยาวของข้อมูล (จำนวนไบต์) ที่อยู่ใน Entity body
บรรทัดที่
7
(Content-type) เป็นส่วนหัวที่บอกถึงชนิดของข้อมูลที่อยู่ใน Entity
body จากตัวอย่างเป็นการบอกว่า ข้อมูลเป็นรูปแบบข้อความ (Text) ของ
HTML
รูปที่
2.11 แสดงรูปแบบทั่วไปของ HTTP Response โดยบรรทัดแรกเป็นบรรทัดสถานะ
หรือ Status Line ทำหน้าที่บอกสถานะ
การติดต่อกับเซิฟเวอร์ว่าเป็นอย่างไร ในบรรทัดสถานะ
นี้แต่ละฟิลด์จะแบ่งโดยการใช้ตัวอักษรว่าง (Space) ฟิลด์เริ่มต้นจะเป็นฟิลด์ Version
ซึ่งบอกถึงเวอร์ชันของ HTTP ฟิลด์ต่อมาคือ Status
Code เป็นการระบุรหัสสถานะ ฟิลด์ต่อมาคือ Status Phrase เป็นการบอกสถานะ ตั้งแต่บรรทัดที่สอง ก็จะเป็นส่วนหัว โดยเริ่มต้นด้วยฟิลด์
Header Field Name ซึ่งจะระบุชื่อของส่วนหัวต่างๆ
ดังตัวอย่างในรูปที่ 2.10 ฟิลด์ในส่วนหัวจะตามด้วยเครื่องหมาย
: (Colon) และคั่นด้วยตัวอักษรว่าง จากนั้นตามด้วยฟิลด์ Value เป็นการบอกค่าของส่วนหัวนั้นๆ ส่วนหัวจะสิ้นสุดเมื่อมีการใส่รหัสขึ้นบรรทัดใหม่
(CR//LF) ติดกัน 2 ครั้ง ต่อจากส่วนหัวจะเป็นพื้นที่ของข้อมูล
(Entity Body) ที่ต้องการจะส่งกลับไปยังไคลเอนต์
ตัวอย่างของสถานะ
การตอบกลับของเซิฟเวอร์
200
OK – เป็นการบอกว่าการร้องขอไฟล์บนเซิฟเวอร์ สามารถทำได้สำเร็จ
ข้อมูลที่ร้องขอจะถูกส่งกลับไปยังไคลเอนต์
301
Moved Permanently – เป็นการบอกว่าข้อมูลที่ร้องขอได้ถูกย้ายไปอยู่ตำแหน่งอื่นซึ่ง
URL ใหม่ได้ถูกระบุอยู่ในส่วนหัว Location ของการตอบกลับ
ดังนั้นโปรแกรมบราวเซอร์จะต้องทำการร้องขอใหม่ โดยใช้ URL ใหม่
400
Bad Request – เป็นการบอกว่า ไม่สามารถแปลความหมายของ HTTP Request
ที่ได้รับเข้ามา
404
Not Found – เป็นการบอกว่าหาข้อมูลที่ร้องขอไม่พบ
505
HTTP Version Not Supported – เป็นการบอกว่า
เซิฟเวอร์ไม่รองรับการทำงานของ HTTP เวอร์ชันที่ได้ร้องขอ
2.2.4
การเก็บสถานะของผู้ใช้บนเซิฟเวอร์ โดยใช้ คุกกี้ (Cookie)
ก่อนหน้านี้
เราได้อธิบายการทำงานของ HTTP ว่าเป็นการทำงานแบบไม่มีการเก็บสถานะ (Stateless)
เพราะต้องการให้การทำงานบนเซิฟเวอร์ไม่ซับซ้อน และสามารถรองรับ TCP
คอนน็คชั่นจำนวนมากได้ อย่างไรก็ตาม
ความต้องการในการที่จะทำให้เซิฟเวอร์มีความรู้ของผู้ใช้ จำเป็นมากขึ้นโดยเฉพาะการระบุตัวตนของผู้ใช้
ดังนั้นจึงมีการกำหนดการใช้งาน Cookie ขึ้นมา ใน RFC 2965
ที่อนุญาติให้เว็บไซต์ต่างๆสามารถที่จะเก็บข้อมูลของผู้ใช้ได้ ซึ่งเป็นที่นิยมในการทำงานของเว็บไซต์ที่เป็นเชิงพาณิชย์ (E-Commerce)
Cookie
จะมีส่วนประกอบอยู่ 4 ส่วนดังต่อไปนี้
1)
บรรทัดส่วนหัว Set-Cookie ของ HTTP
Response
2)
บรรทัดส่วนหัว Cookie ของ HTTP Request
3)
ไฟล์ Cookie ที่เก็บไว้บนเครื่องของผู้ใช้
ซึ่งโปรแกรมเว็บบราวเซอร์จะเป็นตัวจัดการ
4)
ฐานข้อมูลสำหรับเก็บข้อมูลผู้ใช้ ที่อยู่บนเว็บไซต์
ตัวอย่างการทำงานของ
Cookie
จากรูปที่
2.12 เมื่อผู้ใช้เริ่มต้นติดต่อไปยังเว็บไซต์ใดๆ ที่รองรับการทำงาน Cookie ไว้
เช่น เว็บไซต์ Amazon.com เริ่มต้นจะเป็นการส่ง HTTP Request ปกติ
จากนั้นเมื่อเว็บไซต์ได้รับ HTTP Request จะทำการสร้างหมายเลขที่เป็นการระบุตัวต้นของผู้ใช้ขึ้นมาและสร้างพื้นที่บนฐานข้อมูลเพื่อเก็บสถานะการทำงานของผู้ใช้ จากนั้นจึงส่ง HTTP Response ที่มีบรรทัดส่วนหัวเป็น Set-Cookie พร้อมกับหมายเลขที่ได้สร้างขึ้น
(ในรูปคือหมายเลข 1678) เมื่อโปรแกรมบราวเซอร์ได้รับ HTTP
Response ที่มีส่วนหัว Set-Cookie ก็จะทำการต่อมาเก็บหมายเลขนี้ไว้ในไฟล์
Cookie ต่อมาเมื่อผู้ใช้ทำการติดต่อไปยังเว็บไซต์นี้ HTTP
Request จะมีการเพิ่มบรรทัดส่วนหัว Cookie พร้อมระบุหมายเลขที่เคยได้รับจากเว็บไซต์นั้นๆไปด้วย
เมื่อเว็บไซต์ได้รับ HTTP Request ที่มีหมายเลข Cookie
ก็จะทำการนำหมายเลขนี้ตรวจสอบดูภายในฐานข้อมูลของเว็บไซต์
เพื่อประมวลผลต่อไป
จากกระบวนการทำงานของ
Cookie ทำให้มีการนำ Cookie
ไปประยุกต์ใช้ในหลายๆด้านเช่น การให้คำแนะนำกับผู้ใช้
การกำหนดสิทธิของผู้ใช้ การรักษาสถานะของเซสชั่น (Session State) ในการทำงานของเว็บเมล การใช้งานสำหรับตระกร้าซื้อของสำหรับเว็บเชิงพาณิชย์
เป็นต้น
อย่างไรก็ตาม
การใช้งาน Cookie
บนเว็บไซต์ทำให้ เว็บไซต์สามารถเรียนรู้พฤติกรรมของผู้ใช้ ได้มากทำให้เกิดข้อกังวลในแง่
การละเมิดความเป็นส่วนตัวของผู้ใช้ (Privacy)
2.2.5
การทำ Web Cache
Web
Cache หรือ เรียกอีกชื่อหนึ่งว่า Proxy Server คือ เซิฟเวอร์ที่ทำหน้าที่ตอบสนอง HTTP Request แทนของ
Origin Server โดยมีจุดประสงค์เพื่อทำให้ผู้ใช้งานเว็บได้รับการตอบสนองที่เร็ว
ซึ่งลักษณะการทำงานแสดงดังรูปที่ 2.13
ขั้นตอนการทำงานของ
Proxy
Server
1
โปรแกรมบราวเซอร์บนเครื่องไคลเอนต์ ทำการสร้าง TCP คอนเน็คชั่นไปยัง
Proxy Server และส่ง HTTP Request ไปยัง Proxy Server
2
Proxy Server ทำการตรวจสอบดูว่า ข้อมูลออปเจ็คที่ร้องขอ มีอยู่ภายในเซิฟเวอร์ตัวเอง
หรือไม่ ในกรณีที่มีก็จะทำการส่ง HTTP Response กลับไปยังไคลเอนต์
3
ถ้า Proxy Server ไม่มีข้อมูลออปเจ็คที่ไคลเอนต์ร้องขอ
ก็จะทำการสร้าง TCP คอนเน็คชั่น และส่ง HTTP Request ไปยัง Origin Server เพื่อร้องขอออปเจ็ค
4
จากนั้นเมื่อได้รับข้อมูลจาก Origin Server
ก็จะทำการเก็บข้อมูลไว้ภายใน (Caching) และส่ง HTTP Response
กลับไปยังไคลเอนต์
ข้อสังเกต
การทำงานของ
Proxy Server จะทำหน้าที่เป็นทั้งไคลเอนต์และ เซิฟเวอร์ในเวลาเดียวกัน
เมื่อใดก็ตามที่ Proxy Server ทำหน้าที่เป็นการร้องขอข้อมูล และรับข้อมูล
ก็จะทำหน้าที่เป็นไคลเอนต์ และเมื่อใดก็ตามที่ Proxy Server
ทำหน้าที่เป็นการรับข้อมูลและส่งข้อมูลกลับ ก็จะทำหน้าที่เป็นเซิฟเวอร์
การติดตั้ง
Proxy
Server หรือ Web Cache ช่วยลดเวลาการตอบกลับจาก
Origin Server ได้อย่างมาก
และสามารถช่วยลดปริมาณจราจรที่จะส่งออกไปภายนอกทำให้การใช้งาน Link ภายนอกมีประสิทธิภาพมากขึ้น
รวมถึงลดปริมาณการจราจรบนระบบเครือข่ายอินเตอร์เน็ตโดยรวมได้อีกด้วย
การวิเคราะห์ผลการทำงาน
Web
Caching
สมมติว่าระบบเครือข่ายมีโครงสร้างดังรูปที่
2.14
โดยที่เครือข่าย LAN ความเร็ว 100 Mbps
และ Link ที่เชื่อมต่อไปยังเครือข่ายอินเตอร์เน็ตความเร็ว 15
Mbps เวลาที่ใช้ในการเดินทางไป-กลับ
ของระยะทางจาก เร้าเตอร์ของหน่วยงานกับ Origin Server ใช้เวลา
2 วินาที และค่าเฉลี่ยของการร้องขอจากเว็บบราวเซอร์ไปยัง Origin Server 15ครั้งต่อวินาที และขนาดของออปเจ็ค 100000 บิต
จากสมมติฐานด้านบน
สามารถคำนวณเป็นความเข้มข้นของจราจร (Traffic Intensity) บนระบบ
LAN ได้ดังนี้
ความเข้มข้นจราจร
=
อัตราการร้องขอไปยัง Origin Server x ขนาดออปเจ็ค
/ ความเร็วบน LAN
ความเข้มข้นจราจร
=
15 ครั้ง/วินาที x 1 Mbits / 100Mbps = 0.15
เมื่อพิจารณาความเข้มข้นของจราจรภายใน
LAN
จะเห็นว่าประมาณ 15 % ของการใช้งานบน LAN
ดังนั้นการตอบสนองเกิดการหน่วงเวลาถือว่าน้อยมาก (ระดับประมาณ
มิลลิวินาที)
อย่างไรก็ตามเมื่อพิจารณาความเข้มข้นของจราจรบน
Link
ภายนอกจะได้เป็น
ความเข้มข้นจราจร
=
อัตราการร้องขอไปยัง Origin Server x ขนาดออปเจ็ค
/ ความเร็วบน Link
ความเข้มข้นจราจร
=
15 ครั้ง/วินาที x 1 Mbits / 15Mbps = 1
เมื่อพิจารณาความเข้มข้นของจราจรบน
Link
จะเห็นว่าประมาณ 100 % ของการใช้งาน Link ดังนั้นการตอบสนองจะเกิดการหน่วงเวลาสูงมาก (หลายนาที) และอาจจะนานไปจนไม่มีขอบเขต ซึ่งเป็นเวลาที่ยอมรับไม่ได้ของการทำงานบนอินเตอร์เน็ต
ในการหาเวลาหน่วงทั้งหมดที่เกิดจากสมมติฐานด้านบนจะได้ว่า
เวลาหน่วงทั้งหมด
(Total
Delay) = เวลาหน่วงจากอินเตอร์เน็ต + เวลาหน่วงของการรอส่งข้อมูลบน
Link ภายนอก + เวลาหน่วงบน LAN
เวลาหน่วงทั้งหมด
(Total
Delay) = 2 วินาที + หลายนาที
+ มิลิวินาที
จะเห็นว่าเวลาหน่วงทั้งหมดที่เกิดขึ้นนั้น
เวลาที่ใช้มากที่สุดเกิดจากเวลาในการรอคอยการส่งข้อมูลบน Link
ถ้าต้องการให้การตอบสนองเร็วขึ้นจะมีวิธีการแก้ไขได้ดังต่อไปนี้
1
เพิ่มความเร็วของ Link ภายนอกขึ้นเป็น 100 Mbps ภายใต้เงื่อนไขเดิม ก็จะทำให้ความเข้มข้นของจราจร เหลือเพียง 0.15 ดังนั้นเมื่อพิจารณาเวลาหน่วงทั้งหมดจะเป็นดังนี้
เวลาหน่วงทั้งหมด
(Total
Delay) = เวลาหน่วงจากอินเตอร์เน็ต + เวลาหน่วงของการรอส่งข้อมูลบน
Link ภายนอก + เวลาหน่วงบน LAN
เวลาหน่วงทั้งหมด
(Total
Delay) = 2 วินาที + มิลลิวินาที +
มิลลิวินาที
อย่างไรก็ตามวิธีการนี้จะต้องเสียค่าใช้จ่ายในการเพิ่มความเร็วของ
Link
ที่อาจจะสูงมาก
2
ติดตั้ง Proxy Server ภายในเครือข่าย LAN โดยมีสมมติฐานว่า อัตราการตอบสนองที่เกิดจาก
Proxy Server อยู่ที่ประมาณ 40 % ของการติดต่อทั้งหมด (Hit
Rate 0.4) ดังนั้นจะเหลือ 60% ของการร้องขอที่ต้องไปติดต่อที่
Origin Server ดังนั้น ความเข้มข้นของจราจรบน Link จะลดลงเหลือ 60%
ซึ่งค่าเวลาหน่วงจากการรอคอย จะอยู่ที่ประมาณระดับมิลลิวินาที ดังนั้นเมื่อ
พิจารณาเวลาหน่วงเฉลี่ยทั้งหมดจะเป็นดังนี้
เวลาหน่วงทั้งหมดเฉลี่ย
(Average
Total Delay) = 0.4 (เวลาหน่วงที่เกิดภายใน LAN) + 0.6 (เวลาหน่วงที่เกิดจากการติดต่อภายนอก)
เวลาหน่วงทั้งหมดเฉลี่ย
(Average Total Delay) = 0.4(0.01 วินาที) + 0.6 (2 วินาที + 0.01 วินาที )
เวลาหน่วงทั้งหมดเฉลี่ย
(Average Total Delay) = ประมาณ 1.2 วินาที
ดังนั้นจะเห็นว่าการใช้
Proxy
Server นั้นให้ผลลัพธ์ในแง่เวลาหน่วงที่เกิดจากการติดต่อที่น้อยกว่าและ ค่าใช้จ่ายในการติดตั้ง Proxy Server ก็น้อยกว่า
การเพิ่มความเร็วของ Link ภายนอก
วิธีการนี้จึงเป็นที่นิยมในการใช้งานตามองค์กรต่างๆ อย่างแพร่หลาย
2.2.6
Conditional GET
การทำ
Web
cache ได้ช่วยให้เกิดประโยชน์ ในด้านต่างๆที่กล่าวมา แต่ก็มีปัญหาใหม่เกิดขึ้นนั่นคือ
ข้อมูลที่เก็บอยู่ใน Cache อาจล้าสมัย เพราะข้อมูลบนเว็บเซิฟเวอร์อาจมีการแก้ไขหลังจากที่ส่งข้อมูลไปให้กับ
Proxy Server แล้ว แต่อย่างไรก็ตาม การแก้ปัญหานี้คือ ข้อมูลที่อยู่ใน
Cache จะมีการหมดอายุ กล่าวคือ ข้อมูลใน Cache จะคงอยู่ชั่วระยะเวลาหนึ่งเท่านั้น
หลังจากนั้นข้อมูลนี้จะหายไป นอกจากนั้นเมื่อเครื่องไคลเอนต์ทำการร้องขอข้อมูลดังกล่าวในช่วงเวลาที่ข้อมูลถูก
Cache อยู่ Proxy
Server จะทำการติดต่อไปยัง Origin Server โดยใช้
Conditional GET เพื่อช่วยตรวจสอบ
ว่าข้อมูลมีการเปลี่ยนแปลงหรือไม่ โดยการใส่ข้อมูลส่วนหัวเป็นดังนี้
If-modified-since: <ข้อมูลเวลาที่ทำการร้องขอ>
ทางด้านเซิฟเวอร์จะตอบกลับเป็น
2
ลักษณะคือ ในกรณีที่ข้อมูลไม่มีการเปลี่ยนแปลงจะตอบกลับด้วยรหัส 304
Not Modified และไม่มีการส่งข้อมูล
แต่ถ้าข้อมูลมีการเปลี่ยนแปลงก็จะตอบกลับเป็น 200 OK
พร้อมกับส่งข้อมูลใหม่มาให้ ดังรูปที่ 2.15
2.3
File Transfer Protocol (FTP)
การทำงานของแอพลิเคชั่นอีกรูปแบบที่พบเห็นได้บ่อยครั้งคือ
การถ่ายโอนไฟล์ระหว่างเครื่องท้องถิ่น (Local Host) ไปยังเครื่องระยะไกล
(Remote Host) การทำงานของแอพลิเคชั่นแบบนี้ผู้ใช้จะต้องป้อนข้อมูล)
Username /Password เพื่อทำการพิสูจน์ตัวตน (Authentication
และกำหนดสิทธิของการเข้าใช้ (Authorization)
ล์
จากรูปที่
2.16
โครงสร้างการทำงานของการถ่ายโอนไฟล์จะมีโปรแกรมที่อยู่บนเครื่องไคลเอนต์ ทำหน้าที่ติดต่อกับผู้ใช้งาน
(User) และโปรแกรมที่อยู่บนเครื่องเซิฟเวอร์
ทำหน้าที่เป็นที่ เก็บไฟล์ ซึ่งอยู่ระยะไกลออกไป
การทำงานเพื่อถ่ายโอนไฟล์ (File Transfer) ระหว่างไคลเอนต์กับเซิฟเวอร์จะทำงานบนโปรโตคอล
FTP
การทำงานของโปรโตคอล
FTP
เกิดขึ้นบนคอนเน็คชั่นของ
TCP 2 คอนเน็คชั่น ดังรูปที่ 2.17
· คอนเน็คชั่นของ
TCP
พอร์ต 21 สำหรับการสื่อสารที่เป็นคำสั่ง (Command)
หรือ การตอบกลับ (Response)
· คอนเน็คชั่นของ
TCP
ที่พอร์ต 20 สำหรับการสื่อสารข้อมูลระหว่างกัน
ขั้นตอนการทำงานของ FTP เริ่มต้นโดยที่ไคลเอนต์ทำการติดต่อไปยัง FTP เซิฟเวอร์ โดยสร้าง
คอนเน็คชั่นของ TCP ผ่านพอร์ต 21 จากนั้นไคลเอนต์จะส่งข้อมูล
Username/Password เพื่อทำการพิสูจน์ตัวตนและสิทธิในการเข้าใช้งานบนเซิฟเวอร์ เมื่อผ่านขั้นตอนพิสูจน์ตัวตนแล้ว ไคลเอนต์สามารถที่จะกระทำการต่างๆตามสิทธิที่ได้รับ
เช่นการดูข้อมูลในไดเรกทอรี่ การดาวน์โหลดไฟล์ การส่งไฟล์ขึ้นบนเซิฟเวอร์ อย่างไรก็ตามเมื่อมีการดาวน์โหลด หรือ
โหลดไฟล์ขึ้นบนเซิฟเวอร์ จะมีการสร้างคอนเน็คชั่น TCP ใหม่ที่พอร์ต
20 สำหรับการถ่ายโอนข้อมูลไฟล์ และเมื่อการถ่ายโอนข้อมูล 1
ไฟล์สิ้นสุดจะทำการปิดคอนเน็คชั่นที่พอร์ต 20 ทันที
แต่คอนเน็คชั่นของ TCP ที่พอร์ต 21 จะเปิดอยู่ตลอดเวลาจนสิ้นสุดการทำงาน ตลอดการทำงานเซิฟเวอร์จะทำการเก็บสถานะการใช้งานของไคลเอนต์
ทำให้การรองรับผู้ใช้จำนวนมากในเวลาเดียวอาจส่งผลกระทบกับประสิทธิผลของการทำงานได้
ลักษณะการทำงานที่มีการแยกคอนเน็คชั่นเป็น
2
คอนเน็คชั่นคือ คอนเน็คชั่นควบคุมและ คอนเน็คชั่นข้อมูลนั้น เป็นการทำงานที่เรียกว่า
Out-of-band กล่าวคือ การสื่อสารข้อมูลควบคุมกับข้อมูลไฟล์
อยู่บนคอนเน็คชั่นที่ต่างกัน ซึ่งเมื่อเปรียบเทียบกับ HTTP จะเห็นว่าการทำงานเป็นแบบ
in-band เพราะ ข้อมูลควบคุมและข้อมูลไฟล์
จะอยู่บนคอนเน็คชั่นเดียวกันที่ พอร์ต 80
2.3.1 FTP Commands และ Replies
รูปแบบคำสั่งของ
FTP และการตอบกลับ จะใช้รหัสแอสกี้แบบ 7 บิต (ตัวอักษรที่อ่านได้)
และแต่ละคำสั่งหรือการตอบกลับจะสิ้นสุดโดยการปิดท้ายด้วยรหัสขึ้นบรรทัดใหม่ (CR & LF)
ตัวอย่างคำสั่งที่ใช้บ่อยในการทำงานของ FTP เช่น
· USER
username: ใช้ในการระบุชื่อผู้ใช้
· PASS
password: ใช้ในการส่งข้อมูลรหัสผ่านของผู้ใช้
· LIST:
· RETR
filename: ใช้ในการดาวน์โหลดข้อมูลจากเครื่องเซิฟเวอร์
คำสั่งนี้จะทำให้เซิฟเวอร์สร้างคอนเน็คชั่นของ TCP ที่พอร์ต 20 ขึ้นมา
· STOR
filename: ใช้ในการส่งข้อมูลขึ้นบนเครื่องเซิฟเวอร์
การตอบกลับจะใช้รูปแบบรหัสตัวเลขสถานะ
(Status
code) 3 หลัก และข้อความ (Pharse) เช่น
· 331 Username
OK, password required
· 125 Data
connection already open; transfer starting
· 425 Can’t
open data connection
· 452 Error
writing file
2.4
Electronic Mail (Email)
โครงสร้างการทำงานของจดหมายอีเล็กทรอนิคส์ ประกอบด้วย 3 ส่วนคือ
1
โปรแกรมจดหมายอีเล็กทรอนิคส์ (User Agent, UA)
2
โปรแกรมเซิฟเวอร์ของจดหมายอีเล็กทรอนิกส์ (Mail Server)
3
SMTP (Simple Mail Transfer Protocol)
จากรูปที่
2.18 User Agent (UA) เป็นโปรแกรมที่ทำหน้าที่ติดต่อกับผู้ใช้เพื่ออ่าน
เขียน แก้ไข จดหมายอีเล็กทรอนิคส์ เช่นโปรแกรม Outlook, Eudora,
Thunderbird เป็นต้น เมื่อผู้ใช้ทำการส่งจดหมายอีเล็กทรอนิคส์ UA จะทำหน้าที่ติดต่อกับ เซิฟเวอร์เมล
โดยใช้โปรโตคอล SMTP จากนั้นข้อมูลจดหมายจะถูกเก็บบนเซิฟเวอร์ในคิวการส่งข้อความ (Outgoing
Message Queue) เมื่อเซิฟเวอร์พร้อมที่จะทำการส่ง
เซิฟเวอร์ต้นทางจะติดต่อกับเซิฟเวอร์ปลายทางที่ต้องการโดยใช้โปรโตคอล SMTP เช่นกัน
เพื่อส่งข้อมูลจดหมายไปยังเซิฟเวอร์ปลายทาง ข้อมูลจดหมายก็จะถูกเก็บบนเซิฟเวอร์ใน
กล่องจดหมาย (Mail box) ของผู้รับปลายทาง
ดังนั้นพอสรุปได้ว่า
เซิฟเวอร์เมล ทำหน้าที่เป็นทั้งไคลเอนต์ และเซิฟเวอร์
เนื่องจากว่าเมื่อรับข้อมูลจาก UA จะทำหน้าที่เป็นเซิฟเวอร์
แต่เมื่อส่งข้อมูลไปหาเซิฟเวอร์ปลายทางจะทำหน้าที่ เป็นไคลเอนต์
2.4.1
SMTP (Simple Mail Transfer Protocol)
ในยุคเริ่มต้นการทำงานของระบบอินเตอร์เน็ต
แอพลิเคชั่นตัวแรกๆที่ทำงานบนระบบอินเตอร์เน็ตคือ การใช้งานอีเมล โดยมี SMTP
เป็นโปรโตคอลที่กำหนดรูปแบบและวิธีการทำงานของอีเมล รายละเอียดต่างๆได้มีการจัดทำเป็นเอกสาร
RFC
821 (เผยแพร่ปี1982) ในข้อกำหนดของ SMTP
ยุคแรกกำหนดว่า ข้อมูลที่เป็นส่วนหัว (Header) และข้อมูลส่วนลำตัว (Body)
ต้องเป็นรหัสแอสกี้แบบ 7 บิต เท่านั้น
อย่างไรก็ตามในปัจจุบัน RFC5321 ได้มีการปรับปรุงข้อกำหนดและรูปแบบเพื่ออนุญาตให้มีการส่งข้อมูลในส่วนลำตัวเป็นรหัสอื่นๆเช่น
รหัสที่สามารถแสดงภาษาต่างๆ และ รหัสที่แสดงข้อมูลสื่อประสม เป็นต้น
การทำงานของ
SMTP โดยทั่วไปเป็นการส่งข้อความจากผู้ส่งเมล ไปยังผู้รับ
ผู้ส่งเมลสามารถที่จะเป็นเครื่องไคลเอนต์ หรือ เซิฟเวอร์เมล ในขณะที่ผู้รับจะเป็น
เซิฟเวอร์เมลเท่านั้น ตัวอย่างลำดับการทำงานของการส่งอีเมลเป็นดังรูปที่ 2.19
จากรูปที่
2.19
อธิบายเป็นลำดับขั้นได้ดังต่อไปนี้
1
อลิส ทำการเขียนอีเมล โดยใช้ UA (User Agent)
ซึ่งได้มีการระบุผู้รับปลายทางคือ บ๊อบ (bob@someschool.edu)
2
UA ของอลิสทำการติดต่อเซิฟเวอร์เมลของตัวเองด้วยโปรโตคอล SMTP
เมื่อเซิฟเวอร์เมลได้รับแล้วจะนำข้อมูลอีเมลนี้ไปเก็บไว้ในคิว (Message
Queue)
3
เมื่อมีข้อมูลเข้ามาอยู่ในคิวแล้ว เซิฟเวอร์เมล
ก็จะทำการตรวจสอบดูว่าเซิฟเวอร์ปลายทางที่จะติดต่อด้วยคือใคร ในตัวอย่างนี้คือเซิฟเวอร์เมลของ someschool.edu
4
เซิฟเวอร์เมลของอลิสจะทำหน้าที่เป็นผู้ส่งจดหมาย ไปยังเซิฟเวอร์เมลของบ๊อบผ่านโปรโตคอล
SMTP
5
เมื่อเซิฟเวอร์เมลของบ๊อบได้รับข้อมูลจะทำการจัดเก็บอีเมลนั้นเข้ากล่องจดหมาย
(Mail box) ตามที่อยู่ปลายทางในตัวอย่างนี้
ข้อมูลจะจัดเก็บไว้ในกล่องจดหมายของบ๊อบ
6
บ๊อบใช้ UA เพื่ออ่านข้อมูลออกจากกล่องจดหมายของตัวเอง
โดยใช้โปรโตคอล POP3 หรือ IMAP4
ข้อสังเกต
1
การทำงานของอีเมลจะไม่มีการติดต่อผ่านเซิฟเวอร์ตัวกลาง
เป็นการติดต่อโดยตรงระหว่างเซิฟเวอร์ต้นทางไปยังปลายทางโดยตรง
2
SMTP จะใช้ในการส่งอีเมลไปยังเซิฟเวอร์เมล (ขั้นตอนที่
2 และ 4) และจะใช้ใน POP3 หรือ IMAP4 ในการอ่านข้อมูลออกมาจากเซิฟเวอร์ (ขั้นตอนที่ 6)
การแลกเปลี่ยนข้อความของ
SMTP
ใช้การส่งข้อมูลชั้นทรานสปอตแบบ TCP ที่พอร์ต 25 โดยทั่วไปมีเฟสการแลกเปลี่ยนข้อความเป็น
3 เฟส คือ เฟสการทักทาย (Handshaking) เฟสการถ่ายโอนข้อความ (Transfer Message) และเฟสปิดการทำงาน
(Closure)
จากรูปที่
2.20 บรรทัดที่ 1-3 เป็นเฟสการทักทาย
โดยหลังจากมีการสร้างคอนเน็คชั่น TCP ไปยังพอร์ต 25 เซิฟเวอร์เมล ส่งข้อมูลบรรทัดแรกออกมา
เพื่อแนะนำตัวเองว่าเป็นเซิฟเวอร์ชื่อ hamburger.edu ในบรรทัดถัดมา
ทางด้านไคลเอนต์ส่งคำสั่ง HELO crepes.fr เพื่อแนะนำตัวเองว่าชื่อ
crepes.fr เมื่อเซิฟเวอร์เมลได้รับข้อความก็จะส่งคำทักทายมาในบรรทัดที่
3 โดยมีรหัส 250 Hello crepes.fr, pleased to meet
you ตั้งแต่บรรทัดที่ 4-13
เป็นเฟสการแลกเปลี่ยนข้อความของ SMTP โดยมีการกำหนดชื่อของผู้ส่งจากคำสั่ง
MAIL FROM: กำหนดชื่อผู้รับจากคำสั่ง RCPT TO: กำหนดข้อความที่จะส่งใช้คำสั่ง DATA
และ สิ้นสุดข้อความพร้อมส่งข้อความใช้เครื่องหมายจุลภาค (.)
บรรทัดที่ 14-15 เป็นเฟสปิดการทำงาน โดยใช้คำสั่ง
QUIT
2.4.2
การเปรียบเทียบระหว่าง SMTP กับ HTTP
เมื่อพิจารณาถึงการทำงานของโปรโตคอลทั้งสองจะเห็นว่าเป็นโปรโตคอลที่ใช้สำหรับการถ่ายโอนข้อมูลจากโฮสต์หนึ่งไปยังอีกโฮสต์หนึ่ง
โดย HTTP ถ่ายโอนไฟล์จากเซิฟเวอร์ ไปยังเว็บไคลเอนต์ ขณะที่ SMTP
ถ่ายโอนไฟล์ จากเซิฟเวอร์เมลหนึ่งไปยัง เซิฟเวอร์เมลอีกแห่งหนึ่ง การทำงานของทั้ง HTTP และ SMTP ใช้คอนเน็คชั่นแบบ Persistent
(การเปิดคอนเน็คชั่นของ TCP ค้างจนกว่าจะไม่มีการสิ้นสุดการส่งข้อมูล) ทั้งสองโปรโตคอล
อย่างไรก็ตามทั้งสองโปรโตคอลมีลักษณะสำคัญที่แตกต่างกันหลายประการ
· การทำงานของ
HTTP
เป็นแบบ Pull หมายถึงการติดต่อเพื่อดึงข้อมูลออกจากเซิฟเวอร์
ขณะที่การทำงานของ SMTP เป็นแบบ Push หมายถึง
การติดต่อเพื่อส่งข้อมูลไปยังเซิฟเวอร์
· การส่งข้อมูลในกรณีที่มีจำนวนข้อมูลหลายตัว
การทำงานของ HTTP
จะแยกส่งออปเจ็ค บน HTTP Response แต่ละครั้ง
(ตัวอย่างเช่นถ้ามี 10 ออปเจ็คก็จะมีการส่ง HTTP
Response 10 ครั้ง) ขณะที่ SMTP จะรวมทุกออปเจ็คเป็นข้อความเดียวกัน เพื่อส่งเป็น 1 ข้อความ
2.4.3
รูปแบบของข้อความเมล (Mail Message Format)
ในการส่งข้อความอีเมลบนอินเตอร์เน็ตนั้น
ได้มีการกำหนดรูปแบบโดย RFC
5322 โดยแบ่งลักษณะข้อความออกเป็น 2 ส่วนดังรูปที่
2.21
จากรูปที่
2.21
ส่วนหัว (Header) ทำหน้าที่กำหนดคุณสมบัติของเมล
เช่น กำหนดผู้ส่ง (Sender) ผู้รับ (Recepient) หัวเรื่อง (Subject) เป็นต้น ส่วนลำตัวเป็นส่วนข้อมูลในเมล
จากรูปที่
2.22
บรรทัดที่ 1-3 เป็นข้อมูลส่วนหัวซึ่งบอกว่าเมลนี้มาจากใคร
(บรรทัด From) ส่งไปหาใคร (บรรทัด To)
และหัวเรื่องอะไร (บรรทัด Subject)
จากนั้นส่วนหัวและส่วนข้อความจะแยกจากกันด้วยบรรทัดว่าง
บรรทัดที่เหลือทั้งหมด (ตั้งแต่ Dear Bob จนกระทั่งถึงบรรทัด Alice) คือส่วนลำตัวของเมล
2.4.4
โปรโตคอลสำหรับเข้าถึงข้อมูลเมลจากเซิฟเวอร์ (Mail Access
Protocols)
เมื่อพิจารณาการส่งข้อมูลจากอลิสถึงบ๊อบ
อีกครั้งจะเห็นว่าเมื่อข้อมูลอีเมลของอลิส มาอยู่ที่กล่องจดหมายของบ๊อบแล้ว
บ๊อบจะต้องใช้ UA
(User Agent) ในการเข้าถึงข้อมูลอีเมลบนเซิฟเวอร์
ดังรูปที่ 2.23
การเข้าถึงข้อมูลบนเซิฟเวอร์เมล
สามารถกระทำได้ 3
ลักษณะคือ
· การเข้าถึงโดยใช้โปรโตคอล
POP
เวอร์ชั่น 3 หรือเรียกสั้นๆว่า POP3
· การเข้าถึงโดยใช้โปรโตคอล
IMAP
เวอร์ชั่น 4 หรือเรียกสั้นๆว่า IMAP
· การเข้าถึงโดยใช้โปรโตคอล
HTTP
(สำหรับ UA ที่เป็นประเภท Web เช่น Hotmail หรือ Gmail เป็นต้น)
POP3
(Post Office Protocol-Version 3)
RFC1939
เป็นเอกสารที่อธิบายการทำงานของโปรโตคอลนี้
โดยที่โปรโตคอลนี้ออกแบบให้การทำงานง่ายและไม่ซับซ้อน
ดังนั้นจึงมีความสามารถในการทำงานไม่มาก ซึ่งจะกล่าวรายละเอียดในภายหลัง
POP3
เป็นแอพลิเคชั่นโปรโตคอลที่ใช้ คอนเน็คชั่นของ TCP ที่พอร์ต
110 มีการทำงานเป็น 3 เฟส คือ เฟสการกำหนดสิทธิ (Authorization)
เฟสการโต้ตอบ (Transaction) และเฟสอัพเดท (Update)
ระหว่างเฟสการกำหนดสิทธิ UA จะส่งข้อมูล Username
/Password ไปยังเซิฟเวอร์เมลเพื่อพิสูจน์ตัวตนและกำหนดสิทธิการเข้าถึงข้อมูลเมล หลังจากนั้นจะเข้าเฟสที่สองคือ UAส่งข้อมูลโต้ตอบเพื่ออ่านข้อมูลเมลออกมาจากเซิฟเวอร์ และ UA สามารถทำเครื่องหมายเพื่อแสดงว่าต้องการลบเมล
( Mail Deletion) ต้องการสถิติของเมล (Mail
Statistics) เป็นต้น เฟสสุดท้ายจะเป็นการอัพเดทข้อมูลเมล
เฟสนี้จะเกิดขึ้นหลังจากทำงานคำสั่ง Quit เฟสนี้จะทำงานตามข้อกำหนดในเฟสที่
2 เช่นการลบข้อมูลเมลที่มีการทำเครื่องหมาย เป็นต้น
รูปแบบการแลกเปลี่ยนข้อมูลของ
POP3
จะเป็นลักษณะ Command/Respond โดยการ Respond จะตอบเป็น 2 แบบคือ +OK
ในกรณีที่ไม่ข้อผิดพลาดและ –ERR กรณีที่เกิด ข้อผิดพลาดขึ้น ดังรูปที่
2.24
)
จากรูปที่
2.24 ในการส่งข้อมูล Username/Password ของ POP3
จะใช้รูปแบบคือ user ตามด้วยชื่อผู้ใช้ และ pass
ตามด้วย Password ซึ่งเป็นรหัสแอสกี้ หลังจากนั้นจะเป็นเฟสการโต้ตอบเพื่อที่จะอ่านข้อมูลโดยการใช้คำสั่ง list
สำหรับการตรวจสอบจำนวนอีเมลที่อยู่บนเซิฟเวอร์
ผลลัพธ์ที่ได้จะแสดงรายการอีเมลที่อยู่บนเซิฟเวอร์เป็นหมายเลข พร้อมบอกขนาดของไฟล์
เมื่อต้องการอ่านไฟล์ออกมา จะใช้คำสั่ง retr
ตามด้วยหมายเลขไฟล์ และเมื่อสิ้นสุดการอ่านไฟล์
ก็จะทำการใส่เครื่องหมายเพื่อลบไฟล์ออกจากเซิฟเวอร์หลังจากจบการติดต่อโดยใช้คำสั่ง
dele ตามด้วยหมายเลขไฟล์
จากนั้นเมื่ออ่านค่าข้อมูลเมลและใส่เครื่องหมายลบไฟล์ทั้งหมดแล้ว
ก็ใช้คำสั่ง Quit เพื่อเข้าเฟสอัพเดท
เป็นการลบข้อมูลออกจากเซิฟเวอร์ และยกเลิกคอนเน็คชั่น
ตัวอย่างการทำงานเฟสการโต้ตอบ แสดงดังรูปที่ 2.25
ลักษณะการทำงานของ
POP3
ในตัวอย่างรูปที่ 2.25 เป็นแบบ download-and-delete ซึ่งเป็นแบบที่ใช้งานทั่วไปเพราะจะประหยัดพื้นที่บนเซิฟเวอร์ของผู้ใช้แต่ละคน
แต่มีข้อเสียที่ว่ากรณีที่ผู้ใช้ไม่ได้ทำการอ่านอีเมลจากโฮสต์เครื่องเดิม เช่น
ช่วงเวลาทำงานใช้เครื่องคอมพิวเตอร์ที่ทำงาน
และช่วงเวลาเย็นใช้เครื่องคอมพิวเตอร์ที่บ้าน จะทำให้ข้อมูลเมลถูกเก็บแยกกัน
ซึ่งส่งผลให้เมื่อผู้ใช้ต้องการอ่านข้อมูลเมลย้อนหลัง
อาจจะหาไม่พบบนเครื่องใดเครื่องหนึ่ง
จึงทำให้เกิดแนวคิดที่ว่าข้อมูลเมลทั้งหมดควรจะถูกเก็บไว้บนเซิฟเวอร์ที่เดียว
แต่เนื่องจาก POP3 มีความสามารถน้อย จึงมีการออกแบบโปรโตคอล IMAP
เพื่อแก้ปัญหาดังกล่าว
IMAP
(Internet Mail Access Protocol)
RFC
3501 ได้อธิบายการทำงานของ IMAP ไว้อย่างละเอียด
โดยการทำงานของ IMAP จะเป็นโปรโตคอลที่ใช้สำหรับติดต่อกับเมลบน
เซิฟเวอร์ แต่รองรับการทำงานที่มากกว่า POP3 กล่าวคือ IMAP
มีคำสั่งที่อนุญาตให้ผู้ใช้สามารถสร้างโฟลเดอร์ (Folder) และเคลื่อนย้ายข้อมูลระหว่างโฟลเดอร์ได้ และอนุญาตให้ผู้ใช้สามารถค้นหาข้อมูลบนเซิฟเวอร์ได้
นอกเหนือจากนั้น
IMAP
อนุญาติให้โปรแกรม UA (User Agent) ดึงข้อมูลบางส่วนของเมลได้ เช่น
ดึงค่าข้อมูลเฉพาะส่วนหัวของเมล หรือ บางส่วนของ MIME
(Multipurpose Internet Mail Extension) ลักษณะการทำงานเช่นนี้เป็นประโยชน์ต่อการเชื่อมต่อที่มีแบนด์วิทธ์ต่ำ
เพราะไม่ต้องดาวน์โหลดข้อมูลเมลทั้งหมดเข้ามาในครั้งเดียว
โดยสามารถดาวน์โหลดข้อมูลเฉพาะหัวข้อของเมลมาดูก่อนได้
WEB-Based
Email
ปัจจุบันการใช้งานอีเมล
บนเว็บเมลเช่น Hotmail,
Gmail เป็นต้น ได้รับความนิยมมาก เนื่องจากมีความสะดวก
ในการเข้าใช้งาน โดยหลักการทำงานของเว็บเมล เป็นดังนี้ โปรแกรมบนเว็บทำหน้าที่เป็น
UA เพื่อสร้างและอ่านเมล ดังนั้นกระบวนการทำงานระหว่างผู้ใช้
กับเซิฟเวอร์ จะทำงานโดยโปรโตคอล HTTP ซึ่งเป็นโปรโตคอลของเว็บแอพลิเคชั่น
อย่างไรก็ตาม SMTP จะถูกใช้ในกระบวนการติดต่อระหว่างเซิฟเวอร์เมลด้วยกันเองเหมือนเดิม
2.5
DNS (Domain Name System)
เครื่องทุกเครื่องที่ใช้งานบนระบบอินเตอร์เน็ต
นั้นต้องมีหมายเลข IP
(Internet Protocol) เพื่อบอกตำแหน่งที่อยู่ของเครื่องนั้นๆ หมายเลข IP
นั้นเป็นตัวเลขขนาด 32 บิทซึ่งถูกเขียนในลักษณะเลขฐานสิบคั่นด้วยจุด
(Dotted Decimal) เช่น 203.209.55.194 เป็นต้น
การเขียนในลักษณะดังกล่าวทำให้สามารถอ่านได้ง่ายกว่าเลขฐานสอง (Binary) หรือ
เลขฐานสิบหก (Hexadecimal)
แต่อย่างไรก็ตามในการติดต่อกับเครื่องต่างๆบนอินเตอร์เน็ต
ผู้ใช้ไม่สามารถที่จะจำตัวเลขดังกล่าวได้มาก
ดังนั้นจึงมีความคิดในการใช้ชื่อที่เป็นโดเมน (Domain Name) มาแทนตัวเลขเพื่อที่ผู้ใช้สามารถจดจำได้ง่ายและได้มากกว่า เช่นแทนที่จะจำตัวเลข IP อาจจะจำชื่อโดเมน www.it.mut.ac.th
แทน เป็นต้น
แต่ในกระบวนการทำงานของการสื่อสารบนอินเตอร์เน็ต ต้องใช้ค่าที่เป็นหมายเลข IP
เท่านั้นจึงต้องมีกระบวนการแปลงชื่อโดเมนเป็นค่าตัวเลข IP ระบบที่ให้บริการดังกล่าวคือ DNS นั่นเอง
บริการที่เกิดจาก
DNS
โดยปกติแล้ว
DNS มีหน้าที่หลักคือทำการแปลงข้อมูลชื่อโดเมน เป็นค่าหมายเลข IP ซึ่งแอพลิเคชั่นที่ต้องการใช้ชื่อแทนหมายเลขจะต้องมีกระบวนการทำงานของ DNS
ร่วมด้วยเสมอ เช่น Web /Email /File Transfer เป็นต้น
นอกจากนั้น DNS สามารถให้บริการในแง่อื่นๆดังนี้
·
ชื่อที่เรียกแทนโฮสต์ (Host
Aliasing) เนื่องจากการตั้งชื่อของเซิฟเวอร์หรือเครื่องบางเครื่องมีชื่อที่ยาวและจดจำได้ยาก
จึงต้องการชื่อที่ง่ายสำหรับใช้แทน เช่น ชื่อเครื่องคือ relay1.west-coast.enterprise.com ต้องการชื่อที่คนทั่วไปจดจำได้ง่ายเป็น
www.enterprise.com เป็นต้น ชื่อเครื่องจริง เรียกว่า canaonical ส่วนชื่อที่ใช้สำหรับเรียกแทน
เรียกว่า alias
·
ชื่อเรียกแทนเซิฟเวอร์เมล (Mail Server
Aliasing) บ่อยครั้งที่ การตั้งชื่อของเซิฟเวอร์เมล มีความซับซ้อน และจดจำได้ยาก
ไม่สะดวกกับผู้ใช้งาน เช่น ถ้า bob เป็นผู้ใช้งานเมลของ Hotmail
ก็จะใช้การเขียนชื่อเมลต่อท้ายเป็น bob@hotmail.com แต่จริงๆแล้วชื่อของเซิฟเวอร์เมลอาจจะเป็น relay1.west-coast.hotmail.com
ซึ่งเป็นชื่อที่ยาวและไม่สะดวกกับผู้ใช้ ดังนั้น DNS สามารถให้บริการในการใช้ชื่อแทนของเมลเพื่อสะดวกกับผู้ใช้งานเมล
·
การกระจายภาระ (Load
Distribution) เนื่องจากลักษณะการทำงานแบบ ไคลเอนต์-เซิฟเวอร์
เมื่อมีผู้ใช้จำนวนมากทำการติดต่อมายังระบบ
จะต้องมีเซิฟเวอร์รองรับการทำงานมากกว่า 1 ตัวซึ่งเซิฟเวอร์เหล่านี้
(Replicated Server) จะมีข้อมูลแบบเดียวกัน แต่ละเซิฟเวอร์ก็จะมีหมายเลข
IP ที่ต่างกันออกไป ดังนั้นการติดต่อไปยังเซิฟเวอร์เหล่านี้จะถูกควบคุมโดยกระบวนการของ
DNS ซึ่งเครื่องไคลเอนต์ทำการสอบถาม (Query) มาที่เซิฟเวอร์ DNS เซิฟวอร์ DNS
จะตอบกลับไปด้วยรายการที่ประกอบด้วยหมายเลข IP ของทั้งกลุ่ม Replicated เซิฟเวอร์
แต่จะมีการหมุนวนลำดับของหมายเลข IP ทุกๆครั้งที่มีการสอบถาม
โดยปกติแล้วเครื่องไคลเอนต์จะทำการเลือกหมายเลข IP ตัวแรกสุดมาใช้ในการติดต่อ
จึงทำให้ทุกๆครั้งที่มีการติดต่อมาที่เซิฟเวอร์
จะติดต่อไปที่เซิฟเวอร์เรียงสลับกันไป
2.5.2
ภาพรวมการทำงานของ DNS
การทำงานของ DNS
เป็นระบบการทำงานแบบกระจายตัว (Distributed System) ซึ่งประกอบด้วยเซิฟเวอร์ที่ทำหน้าที่เก็บข้อมูลการจับคู่ระหว่างหมายเลข
IP และชื่อโดเมน รวมถึงข้อมูลที่ใช้ในการทำงานที่กล่าวมาแล้ว
เหตุผลสำคัญที่การทำงานของ DNS เป็นแบบกระจายตัวคือ
·
การป้องกันการล้มเหลวจากจุดเดียว (Single Point
of Failure) ในกรณีที่มีเซิฟเวอร์ตัวใดตัวหนึ่งล้มเหลว
เซิฟเวอร์ตัวอื่นสามารถทำงานแทนได้
·
ปริมาณการจราจร (Traffic
Volume) สามารถกระจายไปยังเซิฟเวอร์ที่ต่างๆ
ซึ่งมีประสิทธิภาพดีกว่า
ปริมาณจราจรจำนวนมากที่วิ่งไปหาเซิฟเวอร์เพียงตัวเดียว
·
ลดระยะเวลาการติดต่อกับเซิฟเวอร์ลง
เนื่องจากสามารถติดต่อไปยังเซิฟเวอร์ที่ใกล้กับตำแหน่งที่ไคลเอนต์อยู่ได้
·
การดูแลรักษา (Maintenance)
ทำได้ง่ายกว่า
เพราะไม่จำเป็นต้องเก็บข้อมูลทั้งหมดไว้บนเซิฟเวอร์ตัวเดียว
โครงสร้างการทำงานของ
DNS
เป็นแบบกระจายตัว และมีชั้นการควบคุม (Hierarchy) ดังรูปที่ 2.26
จากรูปที่
2.26
ชั้นของ Root Serverห
เป็นชั้นที่อยู่สูงสุดของโครงสร้าง Root Server จะมีข้อมูลที่เกี่ยวข้องกับ
ชั้น TLD Server ทั้งหมด ปัจจุบัน Root
Server ทั่วโลกมี 13 กลุ่ม
ตามประเทศต่างๆดังรูปที่ 2.27
TLD
Servers (Top Level Domain Servers) เป็นชั้นรองลงมาจาก Root Server
ทำหน้าที่รับผิดชอบข้อมูลที่เกี่ยวข้องกับระดับ Top level Domain เช่น .com, .org, .net, .edu gxHo9ho รวมไปถึง Top
Level Domain ของประเทศต่างๆเช่น .uk, .fr, .th เป็นต้น
ตัวอย่างบริษัทที่ดูแลDNS เซิฟเวอร์ของ .com
คือบริษัท Network Solution และบริษัทที่ดูแล DNS เซิฟเวอร์ของ .edu
คือ บริษัท Educause
Authoritative
DNS Server เป็น DNS Server ที่ทำหน้าที่เก็บข้อมูลของชื่อโดเมนต่างๆที่ใช้งานภายในองค์กร
ว่ามีหมายเลข IP อะไร โดยปกติแล้วองค์กรขนาดกลางถึงใหญ่จะมีการติดตั้ง
Authoritative DNS Server มากกว่า 1 ตัว
(ป้องกันการล้มเหลวของเซิฟเวอร์ตัวใดตัวหนึ่ง) ในองค์กรขนาดเล็ก
อาจจะไม่มีการติดตั้งเอง สามารถข้อมูลนำไปฝากไว้กับ Authoritative DNS
Server ของผู้ให้บริการรับฝากโฮสต์ได้
ในการทำงานของ
DNS
มีเซิฟเวอร์ที่ทำหน้าที่แปลงข้อมูลชื่อโดเมนเป็นหมายเลข IP ที่อยู่ภายในองค์กรว่า Local DNS Server ซึ่งไม่เกี่ยวข้องกับกระบวนการในชั้นการทำงานที่ได้กล่าวมาแล้ว
Local DNS Server เป็นเซิฟเวอร์ที่ไคลเอนต์ต่างๆ
ภายในองค์กรทำการติดต่อเพื่อสอบถามข้อมูล และเป็นตัวแทนของไคลเอนต์ในการสอบถามไปยัง
DNS Server ภายนอกตามชั้นการทำงาน
ตัวอย่างขั้นตอนการทำงานของการสอบถามข้อมูล
DNS
จากรูปที่
2.28 สมมติว่าเครื่องไคลเอนต์ที่อยู่ภายใต้โดเมน cis.poly.edu
ต้องการติดต่อไปที่เครื่องชื่อว่า gaia.cs.umass.edu
การทำงานจะแบ่งเป็นขั้นตอนต่างๆดังนี้
1 เครื่องไคลเอนต์ทำการสอบถามหมายเลข
IP ของเครื่องปลายทางชื่อ gaia.cs.umass .edu ไปยัง Local DNS Server ที่ dns.poly.edu
2 กรณีที่ Local
DNS Server ไม่สามารถตอบได้ (ไม่มีข้อมูลของ gaia.cs.umass.edu)
Local DNS Server จะทำการส่งคำถามที่ได้รับไปยัง Root DNS
Server
3
Root DNS Server ทำการตอบกลับด้วยข้อมูลของ TLD Server
ที่รับผิดชอบ .edu
4 Local DNS Server ทำการส่งคำถามไปยัง TLD Server ของ .edu
5 TLD Server ทำการตอบกลับด้วยข้อมูลของ
Authoritative DNS Server ที่เป็นของ .umass.edu
6 Local DNS Server ทำการส่งคำถามไปยัง Authoritative DNS Server
7 Authoritative DNS Server ส่งคำตอบว่าหมายเลข IP ของเครื่องที่ชื่อว่า gaia.cs. umass.edu ว่าคือหมายเลขอะไร
กระบวนการทำงานในรูปที่ 2.28 จะมีการสอบถามอยู่ 2 วิธี คือ
· การสอบถามแบบ
Recursive เป็นการสอบถามโดยที่ผู้ถามมอบภาระการหาคำตอบให้กับผู้ที่ถูกถาม ตัวอย่างคือขั้นตอนที่
1 ในรูปที่ 2.28
· การสอบถามแบบ
Iterative
เป็นการสอบถามที่ผู้ถามจะถามไปเรื่อยๆจนกว่าจะได้รับคำตอบ
ตัวอย่างคือขั้นตอนที่ 2,4,6 ในรูปที่ 2.28
การสอบถามในลักษณะที่เป็น
Recursive ทั้งหมดแสดงดังรูปที่ 2.29
การทำ
Cache
ของ DNS
ในทางปฏิบัติการที่ต้องส่งคำถามไปยัง
Root Server บ่อยๆ อาจทำให้เกิดเวลาหน่วงและกระทบกับประสิทธิภาพโดยรวมของการทำงาน DNS ดังนั้นจึงมีการทำ
Cache ที่ Local DNS Server โดยที่ เมื่อ Local DNS Server
ได้รับข้อมูลตอบกลับก็จะทำการเก็บข้อมูลชื่อเครื่องและหมายเลข IP
ที่สัมพันธ์กันไว้ในหน่วยความจำ (ช่วงเวลาการ Cacheโดยปกติคือ 2 วัน)
เมื่อมีการสอบถามชื่อเครื่องที่มีอยู่ในหน่วยความจำก็สามารถที่จะตอบกลับได้เลยโดยที่ไม่ต้องสอบถามไปยัง
Root Server ภายนอกอีก
นอกจากนี้ยังมีการ Cache อีกลักษณะหนึ่งคือการ Cache ข้อมูลของ TLD
Server ต่างๆ เพื่อที่ Local DNS Server จะได้ไม่ต้องถามไปยัง Root Server กล่าวคือสามารถติดต่อไปที่ TLD ได้เลย
2.5.3
DNS Record และ Messages
DNS
Server จะมีการจัดเก็บฐานข้อมูลของ Resource Record (RRs) ซึ่ง มีรูปแบบดังนี้
(Name, Value,
Type, TTL)
ความหมายของค่าต่างๆเป็นดังนี้
ถ้า
Type
=A , Name หมายถึง ชื่อเครื่อง (Hostname) และ Value หมายถึง หมายเลข IP
โดยปกติ
Type
นี้จะใช้บอกข้อมูลการจับคู่ระหว่างชื่อเครื่องและหมายเลข IP
ถ้า
Type
=NS , Name หมายถึง ชื่อโดเมน (เช่น test.com)
และ Value หมายถึง ชื่อเครื่องที่ทำหน้าที่เป็น Authoritative
DNS Server ตัวอย่างการกำหนดค่าใน
NS record (test.com, dns.test.com, NS)
ถ้า Type=CNAME,
Name หมายถึง ชื่อที่ใช้เรียกแทน (Alias Name)
และ Value หมายถึง ชื่อเครื่องที่เป็นชื่อเต็ม (Canonical Name) ตัวอย่างการกำหนดค่าใน CNAM Record (test.com,
relay1.bar.test.com, CNAME)
ถ้า
Type=MX,
Name หมายถึง ชื่อที่ใช้เรียกแทนของเซิฟเวอร์เมล และ Value หมายถึง ชื่อเครื่องที่เป็นชื่อเต็ม
(Canonical Name) ตัวอย่างการกำหนดค่าใน MX Record (test.com, mail.test.com, MX)
TTL
– หมายถึงเวลาที่ RR สามารถคงอยู่ได้
DNS
Messages
ชนิดของ
DNS
Message จะแบ่งเป็น 2 ชนิดคือ DNS Query และ DNS Reply แต่ทั้งสองชนิดนี้จะใช้รูปแบบข้อมูลเดียวกันดังรูปที่ 2.30 ซึ่งมีรายละเอียดในแต่ละฟิลด์ดังนี้
· ส่วนหัว
(Header
Section) มีขนาด 12 ไบท์ ซึ่งแบ่งฟีลด์ต่างๆคือ
o
Identification
ขนาด 16 บิท ทำหน้าที่กำหนดหมายเลขID
ของ Message ทั้งสองแบบโดย หมายเลข ID นี้จะถูกคัดลอกจาก Query
Message ไปใส่ใน Reply Message
o
Flags
ขนาด 16 บิท ทำหน้าที่กำหนดความหมายของ Message เช่น บิท Flag query/reply ถ้าบิทนี้เป็น 0 หมายถึง Query ถ้าเป็น 1 หมายถึง
Reply หรือบิท Flag
Authoritative จะถูกกำหนดเป็น 1 ใน Reply Message เมื่อ DNS Server เป็น Authoritative Server หรือบิท Recursion-desire
ถ้ากำหนดเป็น 1 เมื่อไคลเอนต์ต้องการทำ Recursive Query (ให้ Server ที่ได้รับคำถามไปหาคำตอบให้ในกรณีที่ไม่มีข้อมูล) หรือ บิท Recursion
available ถ้ากำหนดเป็น 1 ใน Reply
Message ถ้า DNS Server นั้นๆสามารถรองรับการทำ
Recursive Query ได้
o
ฟิลด์จำนวนคำถาม (Number of
Questions)
o
ฟิลด์จำนวนคำตอบ RR (Number of answer
RRs)
o
ฟิลด์จำนวน Authority RR (Number of authority RRs)
o
ฟิลด์จำนวน Additional RR (Number of additional RRs)
· ส่วนคำถาม
(Question
Section) ทำหน้าที่กำหนดข้อมูลการ Query มีฟิลด์คือ
o
ฟิลด์ระบุชื่อโดเมนที่ต้องการถาม
o
ฟิลด์ระบุชนิด เช่น Type A หรือ Type MX
ส่วนคำตอบ
ส่วน
Authority และส่วน Additional จะมีโครงสร้างข้อมูลเป็น RR เหมือนกัน
· ส่วนคำตอบ
(Answer
Section) ทำหน้าที่ใส่ข้อมูลของ RR ในการตอบกลับ โดยข้อมูล RR
สามารถมีมากกว่า 1 ชุดข้อมูล
· ส่วน Authority
(Authority Section) ทำหน้าที่ใส่ข้อมูลของ RR ที่เป็นของ Authoritative
Server
· ส่วน Additional
(Additional Section) ทำหน้าที่ให้ข้อมูลเพิ่มเติม เช่น
ถ้าคำตอบเป็นชื่อเครื่องแบบ Canonical ของเซิฟเวอร์เมล ส่วน Additonal
จะใส่ข้อมูล Type A ซึ่งบอกหมายเลข IP ของชื่อเครื่องแบบ Canonical
การใส่ข้อมูล
Record
เข้าไปในฐานข้อมูล DNS
สมมติว่า
เราต้องการใช้งานชื่อโดเมน networkutopia.com สิ่งแรกที่จะต้องทำคือ การจด
ทะเบียนเพื่อขอใช้ชื่อโดเมนนี้กับ นายทะเบียน (Registrar) ในกรณีนี้นายทะเบียนที่รับลงทะเบียนการใช้ชื่อโดเมนนี้คือ บริษัทที่ดูแล TLD
กลุ่ม .com ในยุคก่อนบริษัทที่ดูแลกลุ่มนี้จะมีแค่บริษัทเดียวคือ
Network Solution แต่ปัจจุบัน ICANN (Internet
Corporation for Assigned Names and Numbers) อนุญาตอีกหลายบริษัทให้ทำหน้าที่เป็นนายทะเบียนสำหรับกลุ่ม
.com
เมื่อเราทำการลงทะเบียนขอใช้ชื่อกับนายทะเบียน
เราจะต้องให้ข้อมูลกับนายทะเบียนคือชื่อและหมายเลข IP ของเครื่องที่ทำหน้าที่เป็น Authoritative DNS Server หลักและรอง (Primary and Secondary Authoritative DNS Server) เช่น ชื่อเครื่องหลักคือ dns1.networkutopia.com และเครื่องรองคือ dns2.networkutopia.com
และหมายเลข IP คือ 212.212.212.1 และ 212.212.212.2 ทางบริษัทนายทะเบียนจะทำการใส่ข้อมูลเข้าไปฐานข้อมูลสำหรับข้อมูลเครื่อง
Authoritative DNS Server แต่ละเครื่อง 2 Record เช่นการใส่ข้อมูลเครื่อง Authoritati
(networkutopia.com,
dns1.networkutopia.com,NS)
(dns1.networkutopia.com,
212.212.212.1,A)
และในเครื่อง
Authoritative
DNS Server จะต้องมีการใส่ข้อมูล Type A ของชื่อเว็บเซิฟเวอร์โดเมนที่จะใช้งานเช่น www.networkutopia.com ไว้ในฐานข้อมูลตัวเอง
รวมถึง Type MX สำหรับเซิฟเวอร์เมล
