บทความ2. อธิบาย Web Application

การทำงานชั้นแอพลิเคชั่น (Application Layer)

2.1 หลักการสำคัญของเน็ตเวิร์คแอพลิเคชั่น (Principles of Network Applications)

แกนหลักในการพัฒนาเน็ตเวิร์คแอพพลิเคชั่น คือการเขียนโปรแกรมที่สามารถทำงานบนระบบที่แตกต่างกัน แต่สามารถสื่อสารกันได้ผ่านระบบเครือข่าย เช่น โปรแกรมเว็บบราวซ์เซอร์ ที่ทำงานอยู่บนแพลตฟอร์มของระบบปฏิบัติการวินโดว์ส สามารถติดต่อ กับโปรแกรมเว็บเซิฟเวอร์ที่ทำงานอยู่บนแพลตฟอร์มลินุกซ์ เป็นต้น

ดังนั้น การพัฒนาเน็ตเวิรค์แอพลิเคชั่น จะต้องเขียนซอฟแวร์ที่สามารถรันหรือ ทำงานบนระบบปลายทางที่ต่างกัน  และที่สำคัญก็คือ การพัฒนาเน็ตเวิร์คแอพลิชั่น ไม่จำเป็นต้องเข้าไปยุ่งเกี่ยวกับส่วนที่เป็น แกนของเครือข่าย เช่น สวิทซ์ หรือ เร้าเตอร์  ตัวอย่างภาพการติดต่อของ

แอพลิเคชั่นถูกแสดงดังรูปที่ 2.1

2.1.1 สถาปัตยกรรมของ เน็ตเวิร์คแอพลิเคชั่น (Network Application Architectures)

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

1 สถาปัตยกรรมแบบ ไคลเอนต์-เซิฟเวอร์ (Client-Server)  จะเป็นแบบที่มีโฮสต์ ทำหน้าที่เป็น เซิฟเวอร์แบบทำงานตลอดเวลา (Always-on) ซึ่งทำหน้าที่ให้บริการแก่ เครื่องไคลเอนต์ ซึ่งจะทำหน้าที่ร้องขอบริการ ซึ่งอาจจะเป็นเครื่องที่ทำงานตลอดเวลาหรือไม่ก็ได้ ตัวอย่างที่เห็นชัดเจนของ สถาปัตยกรรมรูปแบบนี้คือ แอพลิเคชั่นของเว็บ (Web Application) เครื่องที่ทำหน้าที่เป็นเว็บเซิฟเวอร์ จะคอยตอบสนองการร้องขอจากเครื่องไคลเอนต์ที่ทำงานโปรแกรมเว็บบราวซ์เซอร์    นอกจากนั้นยังมีคุณสมบัติอื่นๆ ของสถาปัตยกรรมแบบนี้ เช่น เครื่องที่ทำหน้าที่ไคลเอนต์จะไม่สามารถสื่อสารกันเองได้ และ เครื่องเซิฟเวอร์ จะต้องมีหมายเลขไอพี ที่คงที่ (Fixed IP Address) เพื่อที่ว่าการเชื่อมต่อกับเซิฟเวอร์ สามารถเกิดขึ้นได้ตลอดเวลา ตัวอย่างการทำงานแสดงดังรูปที่ 2.2(ก)

         

อย่างไรก็ตาม สถาปัตยกรรมแบบนี้จะมีข้อจำกัดในกรณีที่ เซิฟเวอร์ มีการร้องขอบริการจากเครื่องไคลเอนต์จำนวนมาก  จะทำให้เซิฟเวอร์เพียงเครื่องเดียวไม่สามารถให้บริการ การร้องขอจำนวนมากได้ ดังนั้นเว็บที่ได้รับความนิยมสูงในปัจจุบันจึงมีการ รวมกลุ่มเซิฟเวอร์ (Server Clustering) แล้วจัดระบบเป็นเสมือนเซิฟเวอร์เดียวกัน รองรับบริการ จากไคลเอนต์จำนวนมาก การจัดกลุ่มเซิฟเวอร์ในบางครั้ง มักจะเรียกว่า เซิฟเวอร์ฟาร์ม (Server Farm)

         

ในกรณีที่แอพลิเคชั่นต้องรองรับไคลเอนต์จำนวนมาก สถาปัตยกรรมแบบนี้ จะมีค่าใช้จ่ายในการดำเนินการสูงมาก เนื่องจากว่า จะต้องมีโครงสร้างพื้นฐานที่ดี ซึ่งหมายถึง ประสิทธิภาพของเครื่องเซิฟเวอร์ ความเร็วของลิงค์ การจัดทำเซิฟเวอร์ฟาร์ม เป็นต้น  

         

2 สถาปัตยกรรมแบบ เพียร์ทูเพียร์ (Peer-to-Peer,P2P) จะเป็นแบบที่มีการใช้โฮสต์ ที่เป็นเซิฟเวอร์แบบทำงานตลอดเวลา (Always-on Server) น้อย หรือบางครั้งอาจจะไม่มีการใช้งานเลย  การทำงานสถาปัตยกรรมแบบเพียร์ทูเพียร์นี้จะใช้การติดต่อกันโดยตรง ระหว่างโฮสต์ ซึ่งเรียกว่า เพียร์ (Peer) โดยเพียร์ที่สื่อสารกัน จะมีหน้าที่การทำงานไม่แตกต่างกัน กล่าวคือ เพียร์จะทำหน้าที่ได้ทั้งร้องขอบริการและ เป็นผู้ให้บริการ ตัวอย่างของแอพลิเคชั่นประเภทนี้ได้แก่ โปรแกรมบิตทอเรนท์ (Bittorrent) โปรแกรมสไกป์ (Skype)  เป็นต้น ตัวอย่างการทำงานแสดงดังรูปที่ 2.2 (ข)

อย่างไรก็ตาม ยังมีสถาปัตยกรรมที่ใช้โครงสร้างผสมระหว่างไคลเอนต์-เซิฟเวอร์และ เพียร์ทูเพียร์ เข้าด้วยกัน เช่น โปรแกรมเอ็มเอสเอ็น (MSN) เป็นต้น โดยการทำงานจะมีเซิฟเวอร์ทำหน้าที่ในการคอยติดตามหมายเลขไอพีของผู้ใช้ สถานะของผู้ใช้งาน แต่ในเวลาที่ผู้ใช้ ส่งข้อมูลถึงกัน จะทำงานโดยตรงไม่ผ่านเซิฟเวอร์

ข้อดีของสถาปัตยกรรมแบบนี้คือ การรองรับผู้ใช้ได้จำนวนมากโดยตัวเอง (Self-Scalability) กล่าวคือ การทำงานลักษณะนี้สามารถขยายตัวได้โดยไม่เป็นภาระของผู้ใช้ คนใดคนหนึ่ง

 2.1.2 การสื่อสารระหว่างโปรเซส (Process Communicating)

การทำงานของเน็ตเวิร์คแอพลิเคชั่น จะต้องมีการสื่อสารระหว่าง โปรแกรมที่ทำงานอยู่บนโฮสต์เดียวกัน หรือ อยู่ต่างโฮสต์กัน โดยโปรแกรมที่ทำงานอยู่บนโฮสต์แต่ละตัว จะมี โปรเซส (Process)  ที่ทำงานเพื่อรับส่งข้อมูลระหว่างโปรเซสด้วยกัน ในกรณีที่การสื่อสารที่อยู่ภายในโฮสต์เดียวกัน การสื่อสารระหว่างกันจะทำผ่านกระบวนการที่เรียกว่า อินเตอร์โปรเซส (Interprocess) ซึ่งจะถูกควบคุมด้วยระบบปฏิบัติการบนโฮสต์นั้น แต่ในกรณีที่การสื่อสารระหว่างโปรเซสที่อยู่บนโฮสต์ที่ต่างกัน จะใช้วิธีการแลกเปลี่ยนข้อความ (Message Exchange) ผ่านระบบเครือข่าย

โปรเซสไคลเอนต์ และโปรเซสเซิฟเวอร์ (Client and Server Process)

โดยปกติแล้ว เน็ตเวิร์คแอพลิเคชั่นจะประกอบด้วย โปรเซสที่ใช้ในการรับข้อความและ โปรเซสที่ใช้ในการส่งข้อความ ระหว่างกัน เช่น เว็บแอพลิเคชั่น จะมีโปรเซสบนเว็บบราวเซอร์ ที่ทำงานแลกเปลี่ยนข้อความกับเว็บเซิฟเวอร์ หรือ ระบบแบ่งปันไฟล์แบบเพียร์ทูเพียร์  โปรเซสของแต่ละเพียร์ จะมีการแลกเปลี่ยนข้อความระหว่างกัน เป็นต้น  โดยทั่วไปแล้ว โปรเซสที่ทำหน้าที่ในการเริ่มต้นการติดต่อ (Initiate) หรือร้องขอการทำงาน จะถูกเรียกว่า ไคลเอนต์โปรเซส (Client Process) ในขณะที่โปรเซสที่รอการติดต่อ หรือตอบสนองการทำงาน จะถูกเรียกว่า เซิฟเวอร์โปรเซส (Server Process)  ดังนั้น ในเว็บแอพลิเคชั่น โปรเซสที่ทำงานบนเว็บบราวซ์เซอร์ จะมีแต่ไคลเอนต์โปรเซส และโปรเซสที่เว็บเซิฟเวอร์ก็จะมีแต่ เซิฟเวอร์โปรเซส ในขณะที่ ระบบแบ่งปันไฟล์แบบเพียร์ทูเพียร์  แต่ละเพียร์ จะมีโปรเซสทั้ง 2 แบบ คือจะมีทั้งไคลเอนต์โปรเซส และเซิฟเวอร์โปรเซส เนื่องจากว่า แต่ละเพียร์ สามารถทำหน้าที่ในการ ดาวน์โหลดไฟล์ (Download)  และทำหน้าที่ในการอัพโหลดไฟล์ (Upload)  ได้

การเชื่อมต่อระหว่างโปรเซสและเครือข่ายคอมพิวเตอร์ 

ดังที่ได้กล่าวมา โปรเซสที่อยู่ต่างโฮสต์  จะต้องรับส่งข้อความระหว่างกันโดยผ่าน ระบบเครือข่าย การรับส่งข้อความของโปรเซสผ่านระบบเครือข่ายจะทำผ่าน การเชื่อมต่อที่เรียกว่า ซ็อคเก็ต (Socket) เมื่อเปรียบเทียบ โปรเซสเสมือนกับบ้าน ซ็อคเก็ตจะเปรียบเหมือนประตูบ้าน ดังนั้น การที่ข้อความจะถูกส่งออก หรือรับเข้าก็จะต้องวิ่งผ่านซ็อคเก็ต แสดงตัวอย่างการ

2.1.3 การบริการของชั้นทรานสปอตที่มีให้กับแอพลิเคชั่น

จากหัวข้อที่แล้วจะเห็นว่า ซ็อคเก็ตทำหน้าที่ในการเชื่อมต่อการรับส่งข้อมูลจากแอพลิเคชั่นกับชั้นทรานสปอต ซึ่งในการทำงานของระบบอินเตอร์เน็ตนั้นมีทางเลือกที่แอพลิเคชั่นจะเลือกโปรโตคอลในชั้นทรานสปอตที่แตกต่างกัน ขึ้นอยู่กับลักษณะของแอพลิเคชั่นว่าต้องการบริการในลักษณะใดซึ่ง เมื่อพิจารณาลักษณะความต้องการอาจแบ่งเป็นกลุ่มต่างๆดังนี้

การส่งข้อมูลแบบน่าเชื่อถือ (Reliable Data Transfer)

จากที่ได้ผ่านมาในบทที่ 1 เราจะทราบว่าระบบอินเตอร์เน็ตเป็นระบบที่ทำงานผ่านการสวิทซ์แบบแพ็คเก็ต (Packet Switching) ซึ่งข้อมูลแพ็คเก็ต สามารถสูญหายเนื่องจากอุปกรณ์เร้าเตอร์ทิ้ง (Drop) แพ็คเก็ต เพราะบัฟเฟอร์เต็มได้ ดังนั้นแอพลิเคชั่นบางชนิด ที่ต้องการการส่งข้อมูลไปยังปลายทางที่ครบถ้วนสมบูรณ์ จึงต้องใช้การบริการแบบน่าเชื่อถือ แอพลิเคชั่นประเภทนี้ได้แก่ อีเมล เว็บ และการถ่ายโอนไฟล์เป็นต้น

ในขณะที่แอพลิเคชั่นอีกลุ่มหนึ่ง สามารถยอมให้มีข้อมูลแพ็คเก็ตสูญหายได้ (Loss-tolerant Application) ก็ไม่จำเป็นที่ต้องใช้บริการแบบน่าเชื่อถือ โดยปกติ จะเป็น แอพลิเคชั่นสื่อผสม (Multimedia Application)  เช่น การส่งภาพ/เสียงแบบเวลาจริง (Real Time Audio/Video) หรือ การส่งภาพ/เสียง แบบสำรองไว้ก่อน (Stored Audio/Video)  การสูญหายของแพ็คเก็ตอาจจะทำให้เกิดการกระตุก (Glitch) เล็กน้อยซึ่งไม่ถือว่าเป็นข้อบกพร่องที่ร้ายแรง

ทรูพุท (Throughput)

แอพลิเคชั่นบางชนิดต้องการความเร็วหรือทรูพุท ขั้นต่ำสำหรับการทำงาน เช่น ถ้าการเข้ารหัส (Encoding) ในการโทรศัพท์ผ่านอินเตอร์เน็ต (Internet Telephony) เป็นแบบ 32 กิโลบิตต่อวินาที ดังนั้นการส่งข้อมูลบนระบบเครือข่ายก็ต้องใช้ความเร็วขั้นต่ำในการติดต่อที่อัตราเดียวกัน  แอพพลิเคชั่นประเภทนี้จะถูกเรียกว่า แบนด์วิทธ์-เซ็นสิทีฟ แอพลิเคชั่น (Bandwidth-Sensitive Application) โดยมากจะเป็นแอพลิเคชั่นสื่อผสม

ในขณะที่แอพลิเคชั่นอีกลุ่มหนึ่ง ไม่จำเป็นต้องมีการรับประกันความเร็วหรือทรูพุท ของการรับส่ง กล่าวคือ แอพลิเคชั่นสามารถทำงานได้แม้ว่า ทรูพุทของระบบเครือข่ายจะมากหรือน้อย เราเรียกแอพลิเคชั่นประเภทนี้ว่า อีลาสติค แอพลิเคชั่น (Elastic Application)  ตัวอย่างของแอพลิเคชั่นเหล่านี้ได้แก่ เว็บ อีเมล การถ่ายโอนไฟล์เป็นต้น

จังหวะเวลา (Timing)

แอพลิเคชั่นบางชนิดจะทำงานได้ไม่ดี ถ้าข้อมูลแพ็คเก็ต มีระยะเวลานานห่างกันมากเกินไป เช่น แอพลิเคชั่นแบบเวลาจริง (Real Time Application) การโทรศัพท์ผ่านระบบอินเตอร์เน็ต หรือเกมออนไลน์ที่เล่นหลายคน (Multiplayer Games) เป็นต้น ส่วนแอพลิเคชั่นที่ไม่ใช่แบบเวลาจริง จะไม่มีปัญหาที่กล่าวมา

ความมั่นคงปลอดภัย (Security)

 การทำงานชั้นทรานสปอต สามารถให้บริการความมั่นคงปลอดภัยของข้อมูลแอพลิเคชั่น ได้ ตัวอย่างเช่น ในด้านส่ง โปรโตคอลในชั้นทรานสปอตสามารถเข้ารหัสข้อมูลทั้งหมดที่ถูกส่งออกจาก โปรเซสการส่ง และที่ด้านรับ ข้อมูลจะถูกถอดรหัสและส่งถ่ายไปยังโปรเซสด้านรับ ดังนั้นข้อมูลที่สื่อสารกันระหว่างโปรเซส จะเป็นความลับ นอกจากนั้นการทำงานชั้นทรานสปอตสามารถให้บริการ ในด้านความสมบูรณ์ข้อมูล (Intregity) การพิสูจน์ตัวตนระหว่างปลายถึงปลาย (End-End Authentication)  

2.1.4 การบริการของชั้นทรานสปอตที่ถูกจัดเตรียมโดยอินเตอร์เน็ต

แอพลิเคชั่นที่ทำงานบนระบบเครือข่าย ที่พบเห็นทั่วไปบนระบบอินเตอร์เน็ต พอสรุปเป็นความ

 บนระบบอินเตอร์เน็ตจะมีบริการ 2 ชนิดของชั้นทรานสปอตที่มีให้กับแอพลิเคชั่น ก็คือ

บริการแบบทีซีพี (TCP Services)

บริการแบบทีซีพี จะให้บริการดังต่อไปนี้

บริการแบบมีการเชื่อมต่อ (Connection-Oriented Service) กล่าวคือ ก่อนจะมีการถ่ายโอนข้อมูลระหว่างกันจะต้องมีการสร้าง การเชื่อมต่อขึ้นมาก่อน โดยด้านไคลเอนต์ และเซิฟเวอร์จะมีการทำแฮนด์เชค (Handshaking) เมื่อผ่านขั้นตอนนี้แล้วจะถือว่า เกิดการเชื่อมต่อขึ้นระหว่างโปรเซสเรียบร้อยแล้ว หลังจากนั้นข้อมูลจากแอพลิเคชั่นจึงเริ่มถ่ายโอนระหว่างกันได้  เมื่อสิ้นสุดการถ่ายโอนจะต้องมีการยกเลิกการเชื่อมต่อ (Tear Down) 

         

บริการการถ่ายโอนข้อมูลแบบน่าเชื่อถือ (Reliable Data Service) กล่าวคือ ข้อมูลที่ถูกถ่ายโอนจะไปถึงปลายทางด้วยความถูกต้องและสมบูรณ์เสมอ รวมถึงลำดับของข้อมูล แม้ว่าข้อมูลอาจจะสูญหายได้ ระบบเครือข่ายก็ตาม ทีซีพีจะมีกลไกการตอบรับและส่งข้อมูลใหม่เพื่อจัดการกับหารสูญหายของข้อมูลที่เกิดขึ้น

นอกจากนี้  ทีซีพียังมีกลไกการทำงานในการควบคุมความแออัดของระบบเครือข่าย โดยกลไกนี้จะมีการบีบความเร็วการส่งให้ลดลง เมื่อตรวจสอบพบการแออัดบนเครือข่าย อย่างไรก็ตามกลไลนี้จะทำให้แอพลิเคชั่นที่ต้องการความเร็วสูง หรือต้องการทรูพุทขั้นต่ำ อาจจะไม่สามารถทำงานได้ เช่น แอพลิเคชั่นแบบเวลาจริง ของการส่งเสียงและภาพ  ดังนั้นการบริการของทีซีพีนั้นจะเหมาะกับการทำงานของแอพลิเคชั่นที่ต้องการความถูกต้องสมบูรณ์และไม่สนใจเรื่องเวลาหน่วง (Delay) และไม่สนใจทรูพุทขั้นต่ำ ตัวอย่างแอพลิเคชั่นที่ใช้การบริการของทีซีพี แสดงดังรูปที่ 2.5

บริการแบบยูดีพี (UDP Services)

ยูดีพี เป็นบริการในชั้นทรานสปอตที่มีการให้บริการน้อยมาก โดย ยูดีพี ทำงานถ่ายโอนข้อมูลแบบไม่มีการเชื่อมต่อ (Connectionless) ดังนั้นจึงไม่มีการทำแฮนด์เชค ก่อนที่จะมีการส่งข้อมูลระหว่างกัน หรืออีกนัยหนึ่งคือ สามารถถ่ายโอนข้อมูลระหว่างกันได้ทันทีที่ ด้านส่งต้องการ ซึ่งจะเป็นไปได้ว่า ข้อมูลไปถึงด้านรับโดยที่ด้านรับยังไม่พร้อมที่จะรับข้อมูล 

นอกจากนั้น การบริการของยูดีพี  เป็นการบริการแบบไม่น่าเชื่อถือ (Unreliable Services) กล่าวคือ จะไม่มีกลไกของ การตอบรับหรือส่งข้อมูลใหม่ และไม่มีการเรียงลำดับข้อมูลใหม่เพื่อส่งให้ชั้นแอพลิเคชั่น ในกรณีที่ได้รับข้อมูลจากชั้นเน็ตเวิร์คที่มีลำดับของข้อมูลไม่เรียงกัน

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

 การกำหนดตำแหน่งที่อยู่ของโปรเซส (Adressing Processes)

ในการสื่อสารระหว่างแอพลิเคชั่นบนโฮสต์แต่ละตัวบนอินเตอร์เน็ต จะมีหมายเลขที่สำคัญเพื่อใช้ในการติดต่ออยู่ 2 หมายเลข หมายเลขตัวแรกคือ หมายเลข ไอพีแอดเดรส (IP Address) ซึ่งเป็นการระบุตำแหน่งที่อยู่ของโฮสต์บนระบบอินเตอร์เน็ต และอีกหมายเลขหนึ่งคือ หมายเลขพอร์ต (Port Number) ซึ่งจะเป็นการระบุถึงตำแหน่งที่อยู่ของโปรเซสของแอพลิเคชั่นที่ต้องการติดต่อ เช่น ถ้าข้อมูลมีการระบุหมายเลขของพอร์ตเป็น 80 หมายถึงว่า ข้อมูลนี้จะส่งไปยังโปรเซสของเว็บเซิฟเวอร์ หรือถ้าข้อมูลระบุหมายเลขของพอร์ตเป็น 25 หมายถึงว่า ข้อมูลนี้จะส่งไปยังโปรเซสของเมลเซิฟเวอร์ 

หมายเลขพอร์ตมีการจัดเรียงเป็นกลุ่มต่างๆๆดังต่อไปนี้

-          กลุ่มพอร์ตที่รู้จักดี (Well-Known Port) หมายเลขตั้งแต่ 0-1023 

-          พอร์ตที่มีการลงทะเบียน (Registered Port) หมายเลขตั้งแต่ 1024 -49151

และพอร์ตที่เป็นไดนามิก (Dynamic Port)

-  พอร์ตที่เป็น ส่วนตัว (Private Port) หมายเลขตั้งแต่ 49152 - 65535

2.1.5 โปรโตคอลชั้นแอพลิเคชั่น (Application Layer Protocols)

โปรโตคอลชั้นแอพลิเคชั่นทำหน้าที่กำหนดสิ่งต่างๆดังต่อไปนี้

-          ชนิดของข้อความที่ใช้ในการแลกเปลี่ยน เช่น ข้อความร้องขอ (Requested Message) และข้อความตอบรับ (Response Message)

-          รูปแบบ (Syntax) ของข้อความชนิดต่างๆ เช่น ฟีลด์ (Field) ต่างๆในข้อความ และวิธีการแบ่งฟีลด์ต่างๆ ออกจากกัน

-          ความหมาย(Semantic) ของข้อมูลใน ฟีลด์ต่างๆ

-          กฏเกณฑ์สำหรับการตัดสินใจว่า โปรเซสส่งหรือรับข้อความได้อย่างไร หรือ เมื่อใดข้อความจะถูกส่งหรือรับ

โปรโตคอลชั้นนี้จะมีการทำงานแบ่งเป็น 2 กลุ่มใหญ่ กล่าวคือ กลุ่มที่เผยแพร่สาธารณะ (Public Domain) และกลุ่มที่ไม่เผยแพร่เป็นโปรโตคอลที่มีเจ้าของสิทธิ์ (Proprietary)

โปรโตคอลกลุ่มที่มีการเผยแพร่เป็นสารธารณะจะถูกเขียนในรูปแบบของอาร์เอฟซี (RFC) เช่น โปรโตคอลเอชทีทีพี (HTTP,HyperText Transfer Protocol) ถูกเขียนอธิบายใน อาร์เอฟซี 2616

โปรโตคอลที่มีเจ้าของสิทธิ์ จะไม่มีการเปิดเผยรูปแบบ และขั้นตอนการทำงานในเอกสารสาธารณะ ดังนั้น โปรโตคอลประเภทนี้จะใช้ได้กับกลุ่มแอพลิเคชั่นแบบเดียวกันเท่านั้น เช่น โปรโตคอลสไกป์ (Skype Protocol)

เรื่องสำคัญที่ต้องกล่าวถึงอีกเรื่องหนึ่งคือ ความสัมพันธ์กันของ เน็ตเวิร์คแอพลิเคชั่น และโปรโตคอลชั้นแอพลิเคชั่น กล่าวคือ โปรโตคอลชั้นแอพลิเคชั่น จะเป็นส่วนหนึ่งของเน็ตเวิร์คแอพลิเคชั่น ตัวอย่างเช่น เว็บ (Web) เป็นแอพลิเคชั่น แบบไคลเอนต์-เซิฟเวอร์ ที่อนุญาตให้ผู้ใช้สามารถได้รับเอกสารจากเว็บเซิฟเวอร์ได้ตามที่ต้องการ เว็บแอพลิเคชั่นนี้จะมีองค์ประกอบหลายส่วนคือ 1 รูปแบบมาตรฐานที่ใช้ในการเขียนเอกสาร (HTML,HyperText Mark-up Language) 2 เว็บบราวเซอร์ (Web Browser) ได้แก่ โปรแกรม ไออี (IE,Internet Explorer) เป็นต้น 3 เว็บเซิฟเวอร์ (Web Server) ได้แก่ โปรแกรมอาปาเช่ (Apache) เป็นต้น 4 โปรโตคอลชั้นแอพลิชั่น ได้แก่ เอชทีทีพี (HTTP) ซึ่งทำหน้าที่ในการกำหนดว่าเว็บบราวเซอร์และเว็บเซิฟเวอร์จะติดต่อกันอย่างไร  ดังนั้นจะเป็นว่า โปรโตคอลชั้นแอพลิเคชั่นเป็นส่วนหนึ่งของเน็ตเวิร์คแอพลิเคชั่น

2.2 เว็บ และ เอชทีทีพี (The Web and HTTP)

2.2.1 ภาพรวมการทำงานของเอชทีทีพี

เอชทีทีพี เป็นโปรโตคอลชั้นแอพลิเคชั่นสำหรับการทำงานของเว็บแอพลิเคชั่น ถูกอธิบายรายละเอียดอยู่ใน อาร์เอฟซี 1945 (RFC1945, HTTP เวอร์ชั่น 1.0)  และ อาร์เอฟซี 2616 (RFC2616, HTTP เวอร์ชั่น 1.1)  เอชทีทีพี จะถูกนำไปใช้ในการเขียนโปรแกรมทั้งทางด้านของเซิฟเวอร์ และทางด้านของบราวเซอร์  

ก่อนที่จะอธิบายการทำงานของเอชทีทีพี จะมีคำศัพท์ที่ใช้ในโปรโตคอลที่ต้องทราบความหมายก่อนเช่น

-          เว็บเพจ (Web Page) หรือบางครั้งเรียกว่า เอกสารเว็บ คือ สิ่งที่ประกอบด้วย ออปเจ็ค (Object) ต่างๆ

-          ออปเจ็ค คือ ไฟล์ต่างๆ ซึ่งอาจจะเป็น ไฟล์เอชทีเอ็มแอล (HTML file) รูปภาพ เจเป็ค (JPEG Image)  จาว่าแอพเพล็ต (Java Applet) หรือ คลิปวีดีโอ เป็นต้น ออปเจ็คต่างๆจะถูกอ้างอิงตำแหน่งผ่าน ยูอาร์แอล (URL, Uniform Resource Locator)

โดยมากแล้วเว็บเพจจะประกอบด้วย ไฟล์เอชทีเอ็มแอล ซึ่งมีการอ้างอิงออปเจ็คต่างๆอยู่ภายใน เช่น  เว็บเพจหนึ่ง มีข้อมูล ของ ข้อความอักษร เอชทีเอ็มแอล (HTML Text) และรูปภาพเจเป็ค 5 รูปภาพ ดังนั้นเว็บเพจนี้จะมี 6 ออปเจ็ค การอ้างอิงออปเจ็ค จะทำโดยการใช้ ยูอาร์แอล (URL, Uniform Resource Locator) ซึ่งโครงสร้างของ ยูอาร์แอลจะประกอบด้วยข้อมูล 2 ส่วน คือ ส่วนชื่อของโฮสต์ (Host Name) และ ส่วนชิ่อของพาทธ (Path Name) เช่น

          http://www.someSchool.edu/someDepartment/picture.gif

ส่วนชื่อของโฮสต์ – www.someSchool.edu

ส่วนชื่อของพาทธ - /someDepartment/picture.gif

โมเดลการทำงานของเอชทีทีพีจะเป็นแบบ ไคลเอนต์-เซิฟเวอร์ ซึ่งจะมีโปรแกรมบราวเซอร์ เช่น IE (Internet Explorer), Mozilla Firefox เป็นต้น ทำหน้าที่เป็นส่วนไคลเอนต์ และ โปรแกรมเซิฟเวอร์ เช่น IIS (Internet Information Service)  หรือ Apache ทำหน้าที่เป็น เซิฟเวอร์ เป็นต้น การทำงานเริ่มต้นที่โปรแกรมด้านไคลเอนต์ทำการร้องขอ โดยผ่าน HTTP request ไปยังเซิฟเวอร์ เมื่อไคลเอนต์ได้รับข้อมูลจาก HTTP Response แล้ว ก็จะทำการแปลความหมายของข้อมูลเพื่อแสดงผลที่จอภาพ ขณะที่เซิฟเวอร์ เมื่อรับ HTTP Request แล้วจะทำการแปลความหมายของข้อมูลที่ได้รับ เพื่อส่งออปเจค ที่ด้านไคลเอนต์ต้องการกลับไปโดยผ่าน HTTP Response

 ข้อสังเกต

จากรูปที่ 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 ครั้ง

ตัวอย่างการทำงานแบบ  Non-Persistent HTTP เมื่อผู้ใช้งานทำการป้อน URL บนเว็บบราวเซอร์เป็น  www.someSchool.edu/someDepartment/home.index  โดยที่หน้าเพจนี้จะมีข้อมูลอยู่ภายใน 10 ออปเจ็ค การทำงานจะเป็นตารางที่ 2.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 ครั้ง

ตัวอย่างการทำงานแบบ  Persistent HTTP เมื่อผู้ใช้งานทำการป้อน URL บนเว็บบราวเซอร์เป็น  www.someSchool.edu/someDepartment/home.index  โดยที่หน้าเพจนี้จะมีข้อมูลอยู่ภายใน 10 ออปเจ็ค การทำงานจะเป็นดังตารางที่ 2.2

ตารางที่ 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

บรรทัดที่ 2 (Host) เป็นส่วนหัวที่บอกถึงเซิฟเวอร์ที่กำลังติดต่อด้วยชื่อ www.someschool.edu

บรรทัดที่ 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

ข้อมูลเพิ่มเติมสามารถหาอ่านได้จาก RFC959 http://www.faqs.org/rfcs/rfc959.html

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 สำหรับเซิฟเวอร์เมล 

ที่มา https://www.google.co.th/?gws_rd=cr#fp=26ae62cc43fc803a&q=+%E0%B8%AD%E0%B8%98%E0%B8%B4%E0%B8%9A%E0%B8%B2%E0%B8%A2+Web+Application

บทที่ 2 การทำงานชั้นแอพลิเคชั่น (Application Layer)