HTTP

       Hypertext Transfer Protocol (HTTP) คือโปรโตคอลที่เป็นรากฐานของเวิลด์ไวด์เว็บ (World Wide Web : WWW) และสามารถนำมาประยุกต์ใช้ได้กับแอพพลิเคชันจำพวกไคลเอ็นต์/เซิร์ฟเวอร์ใดๆ ที่มีลักษณะของความเป็นไฮเปอร์เท็กซ์ ชื่อของโปรโตคอลนี้อาจทำให้เกิดความเข้าใจผิดว่า HTTP เป็นโปรโตคอลที่ใช้ในการโอนย้ายไฮเปอร์เท็กซ์ แต่ความจริงแล้วมันเป็นโปรโตคอลสำหรับส่งผ่านข้อมูล ซึ่งมีความสามารถเพียงพอที่จะก่อให้เกิดลักษณะของไฮเปอร์เท็กซ์ ข้อมูลที่ถูกเคลื่อนย้ายผ่านโปรโตคอลนี้อาจเป็นเพียงข้อความธรรมดาๆ,ไฮเปอร์เท็กซ์, ภาพ, เสียง หรือข้อมูลอื่นใดที่ช่วยให้ผู้ใช้เข้าถึงอินเทอร์เน็ตได้ ในการใช้งานเครือข่ายคอมพิวเตอร์ทั่วไปหรือในเครือข่ายอินเตอร์เน็ตก็ตามจะมีการส่งผ่านข้อมูลไป มาระหว่างเครื่องคอมพิวเตอร์หรือข้ามเครือข่ายออกไป ระบบคอมพิวเตอร์ที่เชื่อมต่ออยู่ในแต่ละเครือข่ายอาจจะใช้ฮาร์ดแวร์และซอฟต์แวร์ที่เหมือนกันหรือแตกต่างกันได้ ดังนั้นการที่จะทำให้สามารถส่งผ่านข้อมูลถึงกันและตีความได้อย่างได้อย่างถูกต้องจะต้องมีการกำหนดกลไกในการสื่อสารกันเสียก่อน เรียกว่าจะต้องกำหนดระเบียบวิธีในการติดต่อกันให้ตรงกัน เปรียบเหมือนกับการสื่อสารกันของมนุษย์เรา ถ้าเราต้องการจะติดต่อกับผู้คนต่างเชื้อชาติต่างภาษากันให้เช้าใจกันได้ถูกต้องตรงกันก็จะต้องตกลงกำหนดกันเสียก่อนว่า จะติดต่อกันอย่างไร ด้วยภาษาใดที่จะเข้าใจกันได้เช่น ปัจจุบันมีการใช้ภาษาอังกฤษเป็นภาษากลางในการติดต่อกันมาก ทำให้เราพูดได้ว่า ภาษาอังกฤษเปรียบเสมือนเป็นภาษามาตรฐานในการสื่อสารของมนุษย์ได้ ถ้าพูดในแง่การสื่อสารข้อมูล เราก็พูดได้ว่า ภาษาอังกฤษเป็นโปโตคอลในการสื่อสารของมนุษย์ที่มีการใช้งานอย่างแพร่หลาย เช่นเดียวกันกับโปรโตคอล TCP/IP เป็นโปรโตคอลหลักที่ใช้ในการสื่อสารข้อมูลในเครือข่ายอินเตอร์เน็ต

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

1. ชนิดของการตรวจสอบข้อผิดพลาด ที่จะใช้

2. วิธีบีบอัดข้อมูล (ถ้ามี)

3. วิธีที่ระบบที่ส่งข้อมูลรับรู้ว่ามันได้ส่งข้อมูลเสร็จแล้ว

4. วิธีที่ระบบที่รับข้อมูลรับรู้ว่ามันได้รับข้อมูลแล้ว

       ปัจจุบันโปรโตคอลในการสื่อสารข้อมูลมีอยู่หลายโปรโตคอลนอกเหนือจาก TCP/IP คล้ายกับภาษาต่างๆในโลกนี้ ที่นอกจากภาษาอังกฤษแล้วยังมีภาษาจีน ญี่ปุ่น ฝรั่งเศส เยอรมัน และอื่นอีกมากมาย ในด้านของโปรโตคอลสื่อสารข้อมูลก็เช่นกัน ซึ่งได้มีการออกแบบโปรโตคอลอื่นๆขึ้นมาช้างานอีกมาก เช่น โปรโตคอลIPX/SPX, โปรโตคอล NetBIOS และ โปรโตคอล AppleTalk เป็นต้น

       เนื้อหาของรายงานฉบับนี้จะเริ่มต้นจากการอธิบายแนวความคิดและการดำเนินงานของโปรโตคอล HTTP หลังจากนั้นจึงพิจารณาเข้าไปในรายละเอียดบางอย่าง โดยอิงกับ HTTP เวอร์ชัน 1.1 (RFC 2068) ทั้งนี้เราได้สรุปความหมายของคำศัพท์ต่างๆ ที่ปรากฏอยู่ในข้อกำหนดของโปรโตคอล HTTP ไว้ใน

ตารางที่ 1 สรุปความหมายของคำศัพท์ที่เกี่ยวข้องกับโปรโตคอล HTTP

คำศัพท์

ความหมาย

แคช (Cache)

ไคลเอ็นต์ (Client)

โปรแกรมที่สร้างการเชื่อมต่อขึ้นเพื่อส่งคำร้องขอ (Request) ไป

การเชื่อมต่อ (Connection)

วงจรเสมือนที่ถูกสร้างขึ้นระหว่างโปรแกรม 2 โปรแกรม เพื่อให้โปรแกรมสามารถสื่อสารกันได้

เอ็นติตี้ (Entity)

เกตเวย์ (Gateway)

เมสเสจ (Message)

ออริจิ้นเซิร์ฟเวอร์ (Origin Server)

เซิร์ฟเวอร์ที่มีรีซอร์สอยู่ หรือรีซอร์สถูกสร้างขึ้น

พร็อกซี่ (Proxy)

รีซอร์ส (Resource)

ออบเจ็กต์ของข้อมูลหรือบริการ ที่สามารถอ้างถึงได้ด้วย URI

เซิร์ฟเวอร์ (Server)

โปรแกรมที่ยอมรับการเชื่อมต่อเพื่อให้บริการต่อคำร้องขอต่างๆ โดยส่งคำตอบสนอง (Response) กลับไป

ทันเนล (Tunnel)

ยูสเซอร์เอเจนต์ (User Agent)

ไคลเอ็นต์ที่เริ่มต้นส่งคำร้องขอ โดยทั่วไปหมายถึงบราวเซอร์, เอดิเตอร์, สไปเดอร์ หรือเครื่องมือใดๆ ของผู้ใช้ปลายทาง

 

ภาพโดยรวมของโปรโตคอล HTTP

       HTTP เป็นโปรโตคอลแบบไคลเอ็นต์/เซิร์ฟเวอร์ในลักษณะ transaction-oriented คือมีการติดต่อระหว่างโปรแกรม 2 โปรแกรม ซึ่งโดยทั่วไปได้แก่เว็บบราวเซอร์และเว็บเซิร์ฟเวอร์ เพื่อให้มีความน่าเชื่อถือ HTTP จึงใช้ประโยชน์จากโปรโตคอล TCP แต่ถึงกระนั้น HTTP ก็เป็นโปรโตคอลที่ "ปราศจากสถานะ" กล่าวคือ การติดต่อในแต่ละครั้งเป็นอิสระต่อกัน โดยการเชื่อมต่อระหว่างไคลเอ็นต์และเซิร์ฟเวอร์จะถูกสร้างขึ้นมาใหม่สำหรับการติดต่อในแต่ละครั้ง และถูกตัดขาดจากกันทันทีที่การติดต่อเสร็จสิ้นสมบูรณ์ ถึงแม้ว่าข้อกำหนดของ HTTP จะไม่ได้ระบุความสัมพันธ์ในแบบหนึ่งต่อหนึ่งระหว่างการติดต่อและช่วงเวลาของการเชื่อมต่อเช่นนี้ไว้ก็ตามที คุณสมบัติ "ปราศจากสถานะ" ดังกล่าวของโปรโตคอล HTTP นี้เหมาะสมต่อการนำมาประยุกต์ใช้เป็นอย่างยิ่ง การใช้งานเว็บบราวเซอร์นั้นโดยปกติเกี่ยวข้องกับการรับเอากลุ่มของเว็บเพจและเอกสารเข้ามา ซึ่งการดำเนินการตรงนี้เกิดขึ้นรวดเร็วมาก โดยเว็บเพจและเอกสารเหล่านี้อาจมาจากเซิร์ฟเวอร์ที่แตกต่างกันไป 

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

 

รูปที่ 1

       แสดงให้เห็นตัวอย่างการดำเนินงานของ HTTP กรณีที่ง่ายที่สุดกรณีหนึ่งเกิดขึ้นเมื่อยูสเซอร์เอเจนต์สร้างการเชื่อมต่อโดยตรงกับออริจิ้นเซิร์ฟเวอร์ ยูสเซอร์เอเจนต์ (User Agent) คือโปรแกรมที่เริ่มต้นส่งคำร้องขอ เช่น เว็บบราวเซอร์ที่รันอยู่ทางฝั่งผู้ใช้ เป็นต้น ส่วน ออริจิ้นเซิร์ฟเวอร์ (Origin Server) คือเซิร์ฟเวอร์ที่มีรีซอร์สอยู่ เช่น เว็บเซิร์ฟเวอร์ที่เก็บโฮมเพจไว้ เป็นต้น ในกรณีนี้ไคลเอ็นต์เป็นฝ่ายเปิดการเชื่อมต่อแบบ TCP ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ จากนั้นไคลเอ็นต์จะส่งคำร้องขอไปยังเซิร์ฟเวอร์ โดยคำร้องขอประกอบด้วยคำสั่งอย่างใดอย่างหนึ่ง หรือที่เรียกว่าเมธ็อด (method), URL, เมสเสจที่มีลักษณะคล้าย MIME (Multipurpose Internet Mail Extensions) ซึ่งบรรจุพารามิเตอร์ต่างๆ ของการร้องขอในครั้งนั้น, ข้อมูลเกี่ยวกับไคลเอ็นต์ และข้อมูลเพิ่มเติมอื่นๆ เมื่อเซิร์ฟเวอร์ได้รับคำร้องขอแล้ว มันจะพยายามปฏิบัติตามสิ่งที่ไคลเอ็นต์ร้องขอมา แล้วส่งคำตอบสนองกลับคืนไป คำตอบสนองประกอบด้วยข้อมูลสถานะ, รหัสความสำเร็จหรือความผิดพลาด, เมสเสจที่มีลักษณะคล้าย MIME ซึ่งบรรจุข้อมูลต่างๆ ของเซิร์ฟเวอร์, ข้อมูลที่เกี่ยวข้องกับการตอบสนอง และในบางครั้งจะรวมถึงส่วนที่เป็นเนื้อหา (body content) ด้วย หลังจากนั้นการเชื่อมต่อแบบ TCP จะถูกปิดลงไป

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

       ระบบตัวกลางที่ถูกระบุไว้ในข้อกำหนดของ HTTP จำแนกออกเป็น 3 รูปแบบคือ พร็อกซี่, เกตเวย์ และทันเนล ดังรายละเอียดในรูปที่ 2

        

 

คำสั่งของโปรโตคอล HTTP

       HTTP มีคำสั่งต่าง ๆ ไม่มากนัก เพื่อให้สามารถใช้งานได้อย่างสะดวกและรวดเร็ว โดยมีคำสั่งที่ใช้งานแพร่หลายอยู่เพียง 3 คำสั่ง คือ GET , HEAD และ POST ส่วนคำสั่งอื่นอีก 4 คำสั่งคือ PUT, DELETE ,LINK และ UNLINK มีให้ใช้งานเช่นกัน แต่ไม่เป็นที่นิยมมากนัก รายละเอียดของคำสั่งของ HTTP มีดังนี้

คำสั่ง

รายละเอียด

GET

ให้อ่านข้อมูลจากเว็บเซิร์ฟเวอร์และส่งไปยังไคลเอนต์โดยมีรูปแบบดังนี้

GET <URL> HTTP/1.0

ตัวอย่างเช่น ต้องการให้เว็บเซิร์ฟเวอร์ส่งไพล์ sale.html จากโดเมน

www.netcorp.com ไปยังไคลเอนต์จะใช้รูปแบบของคำสั่ง GET ดังนี้

GET www.netcorp.com/sale.html/HTTP/1.0

นอกจากนี้คำสั่ง GET ยังสามารถกำหนดเงื่อนไขให้อ่านข้อมูลจากเว็บ

เซิร์ฟเวอร์ เฉพาะที่มีการเปลี่ยนแปลงแก้ไขได้ด้วย

HEAD

คำสั่งนี้จะทำงานคล้ายกับคำสั่ง GET แต่เว็บเซิร์ฟเวอร์ จะส่งข้อมูลกลับมาให้

เฉพาะในรายละเอียดของ metadata หรือข้อมูลในเฮดเดอร์เท่านั้น ส่วนข้อมูล

ที่เป็น HTML จะไม่ถูกส่งมาด้วย ซึ่งคำสั่ง HEAD นี้ใช้เพื่อทดสอบว่าข้อมูลตาม

URL นั้น ๆ มีการเปลี่ยนแปลงหรือไม่เท่านั้น

POST

เป็นคำสั่งที่ตรงข้ามกับคำสั่ง GET และ HEAD โดยทำหน้าที่ส่งข้อมูลจาก

ไคลเอนต์ไปยังเซิร์ฟเวอร์ แต่โดยปกติแล้วจะส่งข้อมูลจากไคลเอนต์ไปยัง

เซิร์ฟเวอร์นั้นจะไม่ค่อยมีการใช้งาน นอกจากในกรณีที่ HTML ทำงานใน

ลักษณะที่ให้ผู้ใช้กรอกข้อมูลลงตามแบบฟอร์ม (เช่น รายละเอียดส่วนตัวของผู้

ใช้งาน) และส่งข่อมูลนี้กลับมาเก็บไว้ที่เว็บเซิร์ฟเวอร์

PUT

เป็นคำสั่งที่ทำงานเหมือนกับคำสั่ง POST แต่ไม่เป็นที่นิยม

DELETE

เพื่อให้ไคลเอนต์สั่งเว็บเซิร์ฟเวอร์ลบ URL ที่กำหนดไว้ออกจากเซิร์ฟเวอร์แต่ไม่

เป็นที่นิยมใช้มากนัก เนื่องจากเว็บเซิร์ฟเวอร์ทั่วไปมักจะทำงานในแบบอ่านข้อ

มูลได้เท่านั้น (read-only)

LINK

เป็นคำสั่งที่เชื่อม URL ที่ต้องการไปยังเว็บเซิร์ฟเวอร์อื่น

UNLINK

ยกเลิกคำสั่ง LINK ให้กลับมาใช้เซิร์ฟเวอร์เดิมตามที่กำหนดไว้ใน URL

 

สถานะการทำงานของ HTTP

       โปรโตคอล HTTP ได้กำหนดรหัสแสดงสถานะการทำงานของโปรโตคอล โดยแบ่งกลุ่มของรหัสสถานะออกไว้เป็น 5 กลุ่มคือ

รหัสสถานะ

ประเภท

รายละเอียด

100 –199

Informational

เป็นรหัสสถานะกลุ่มที่เปิดให้โปรแกรมประยุกต์

ต่าง ๆ กำหนดใช้งานได้เอง

200-299

Successful

กลุ่มรหัสที่แสดงว่าการทำงานเสร็จแล้ว

300-399

Redirection

กลุ่มรหัสนี้จะใช้ภายในโปรโตคอล HTTP เอง

โดยเป็นการทำงานที่ต่อเนื่องมาจากโปรเซส

ก่อนหน้านี้ ซึ่งไคลเอนต์เป็นผู้สั่งงาน

400-499

Client Error

ใช้แสดงปัญหาที่เกิดขึ้นกับไคลเอนต์

500-599

Server Error

ใช้แสดงปัญหาที่เกิดขึ้นกับเซิร์ฟเวอร์

       รหัสแสดงสถานะในแต่ละตัว จะนำหน้าด้วยตัวเลข 3 หลักและตามด้วยตัวอักษร ซึ่งรหัสในกลุ่ม 100-199 จะเปิดกว่างให้ผู้พัฒนาโปแกรมประยุกต์สามารถกำหนดค่าขึ้นมาใช้งานเอง ส่วนรายละเอียดของรหัสในกลุ่มอื่น ๆ มีดังนี้

รหัสสถานะ

รายละเอียด

200 OK

การทำงานสำเร็จเรียบร้อย

201 Created

คำสั่ง POST ทำงานเสร็จสมบูรณ์

202 Accepted

ได้รับคำสั่งให้ทำงานเรียบร้อย แต่ไม่ต้องมีการตอบกลับ

301 Moved Permanently

URL ที่ร้องขอได้ถูกย้ายไปที่อื่นแล้ว ดังนั้นการร้องขอให้งาน

URL จะต้องเปลี่ยนเป็นแอดเดรสใหม่

302 Moved Temporarily

URL ที่ร้องขอมาได้ถูกย้ายไปที่อื่นชั่วคราว

304 Not Modify

ใช้แสดงสถานะเมื่อใช้คำสั่ง GET ที่กำหนดเงื่อนไขเฉพาะ

เว็บไซต์ที่มีการเปลี่ยนแปลง ส่วนเว็บไซต์ที่ไม่มีการเปลี่ยน

แปลงจะแสดงด้วยสถานะนี้

400 Bad Request

คำสั่งจากไคลเอนต์ไม่ถูกต้อง

401 Unauthorized

ปฎิเสธการทำงานจากไคลเอนต์ที่ไม่ได้รับอนุญาต

403 Forbidden

เซิร์ฟเวอร์ไม่อนุญาตให้ใช้งาน หรือไคลเอนต์มีสิทธิ ในการใช้

งานไม่เพียงพอ

404 Not Found

ไม่พบเซิร์ฟเวอร์ตาม URL ที่กำหนด

500 Internal Server Error

เซิร์ฟเวอร์มีปัญหา

501 Not Implemented

เซิร์ฟเวอร์ไม่รองรับคำสั่งที่สั่งไป

502 Bad Gateway

Proxy Server รับคำสั่งไม่ถูกต้องจากเว็บเซิร์ฟเวอร์

503 Service Unavailable

เซิร์ฟเวอร์กำลังทำงานอื่นอยู่ ไม่สามารถให้บริการได้ในขณะนี้

300 Multiple Choices

ถ้าค้นหาและพบแหล่งข้อมูลที่ต้องการหลายแห่งเซิร์ฟเวอร์จะตอบ

กลับไปทั้งหมดเพื่อให้ไคลเอนต์สามารถเลือกแหล่งข้อมูลที่

ต้องการเองได้

 

พร็อกซี่ (Proxy)

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

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

 

เกตเวย์ (Gateway)

       เกตเวย์คือเซิร์ฟเวอร์ที่ปรากฏต่อไคลเอ็นต์ราวกับว่าเป็นออริจิ้นเซิร์ฟเวอร์ โดยปฏิบัติงานอยู่ทางเซิร์ฟเวอร์ซึ่งไม่สามารถสื่อสารกับไคลเอ็นต์ได้โดยตรง ใช้งานใน 2 สถานการณ์ต่อไปนี้

 

ทันเนล (Tunnel)

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

 

เมสเสจ (Messages)

       วิธีที่อธิบายการทำงานของ HTTP ได้ดีที่สุดก็คือการอธิบายถึงแต่ละองค์ประกอบของเมสเสจ HTTP โดย HTTP ประกอบด้วยเมสเสจ 2 ประเภทคือ คำร้องขอจากไคลเอ็นต์ไปยังเซิร์ฟเวอร์ และคำตอบสนองจากเซิร์ฟเวอร์ไปยังไคลเอ็นต์ รูปที่ 3แสดงให้เห็นโครงสร้างทั่วไปของเมสเสจ ซึ่งสามารถเขียนให้เป็นทางการในรูปของ BNF (Backus-Naur Form) ได้ดังนี้
    

HTTP-Message = Simple-Request | Simple-Response | Full-Request | Full-Response
Full-Request = Request-Line
*( General-Header | Request-Header | Entity-Header )
CRLF
[ Entity-Body ]
Full-Response = Status-Line
*( General-Header | Response-Header | Entity-Header )
CRLF
[ Entity-Body ]
Simple-Request = "GET" SP Request-URL CRLF
Simple-Response = [ Entity-Body ]

                             รูปที่ 3

Request line


General header


Request header หรือ response header


Entity header




Entity body

 

เมสเสจ Simple-Request และ Simple-Response ได้ถูกกำหนดไว้ใน HTTP/0.9 สำหรับคำร้องขอนั้นเป็นเพียงคำสั่ง GET ง่ายๆ ที่ระบุถึง URL หนึ่งๆ ส่วนคำตอบสนองก็คือบล็อคที่บรรจุข้อมูลซึ่งถูกระบุใน URL นั้นคำร้องขอและคำตอบสนองที่สมบูรณ์จะใช้ประโยชน์จากฟีลด์ต่างๆ ต่อไปนี้

Request-Line

ระบุประเภทของเมสเสจและรีซอร์สที่ต้องการ

Response-Line

แสดงข้อมูลสถานะที่เกี่ยวข้องกับคำตอบสนองนั้น

General-Header

ประกอบด้วยฟีลด์ที่เกี่ยวข้องกับทั้งเมสเสจร้องขอและเมสเสจตอบสนอง แต่ไม่เกี่ยวข้องกับเอ็นติตี้ที่ส่งไป

Request-Header

บรรจุข้อมูลเกี่ยวกับคำร้องขอและไคลเอ็นต์

Response-Header

บรรจุข้อมูลเกี่ยวกับคำตอบสนอง

Entity-Header

บรรจุข้อมูลเกี่ยวกับรีซอร์สที่ถูกระบุจากคำร้องขอและข้อมูลเกี่ยวกับเอ็นติตี้

 

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

 

ตารางที่ 2 องค์ประกอบของ HTTP

เมสเสจทุกชนิด

ฟีลด์ในส่วนเฮดเดอร์ทั่วไป

ฟีลด์ในส่วนเฮดเดอร์ของเอ็นติตี้

Cache-Control
Connection
Data
Forwarded

Keep-Alive
MIME-Version
Pragma
Upgrade

Allow
Content-Encoding
Content-Language
Content-Length
Content-MDS
Content-Range
Content-Type
Content-Version

Derived-From
Expires
Last-Modified
Link
Title
Transfer-Encoding
URI-Header
extension-header

เมสเสจร้องขอ

เมธ็อดร้องขอ

ฟีลด์ในส่วนเฮดเดอร์ร้องขอ

OPTIONS
GET
HEAD
POST
PUT
PATCH
COPY

MOVE
DELETE
LINK
UNLINK
TRACE
WRAPPED
extension-method

Accept
Accept-Charset
Accept-Encoding
Accept-Language
Authorization
From
Host

If-Modified-Since
Proxy-Authorization
Range
Referer
Unless
User-Agent

เมสเสจตอบสนอง

รหัสตอบสนอง

ฟีลด์ในส่วนเฮดเดอร์ตอบสนอง

Continue
Switching Protocols
OK
Created
Accepted
Non-Authoritative
Information
No Content
Reset Content
Partial Content
Multiple Content
Moved Permanently
Moved Temporarily
See Other
Not Modified
Use Proxy
Bad Request
Unauthorized

Payment Required
Forbidden
Not Found
Method Not Allowed
None Acceptable
Proxy Authentication
Required
Request Timeout
Conflict
Gone
Length Required
Unless True
Internal Server Error
Not Implemented
Bad Gateway
Service Unavailable
Gateway Timeout
extension code

Location
Proxy-Authenticate
Public
Retry-After
Server
WWW-Authenticate

 

ฟีลด์ที่อยู่ในส่วนเฮดเดอร์ทั่วไป

       ฟีลด์ในส่วนนี้สามารถใช้ได้ทั้งในเมสเสจร้องขอและเมสเสจตอบสนอง ฟีลด์เหล่านี้ใช้ได้กับเมสเสจทั้ง 2 ประเภท โดยบรรจุข้อมูลที่ไม่ได้เกี่ยวข้องกับเอ็นติตี้โดยตรง ประกอบด้วยฟีลด์ดังต่อไปนี้

Cache-Control

ใช้ควบคุมกลไกการทำแคชสำหรับชุดคำร้องขอ/คำตอบสนอง จุดมุ่งหมายก็เพื่อป้องกันมิให้เกิดความขัดแย้งระหว่างแคชกับคำร้องขอหรือคำตอบสนอง

Connection

บรรจุรายการของคีย์เวิร์ดและชื่อฟิลด์ในส่วนเฮดเดอร์ซึ่งเกี่ยวเนื่องกับการเชื่อมต่อแบบ TCP ระหว่างผู้ส่งกับผู้รับที่ไม่ใช่ทันเนล

Date

วันและเวลาที่เมสเสจถูกสร้างขึ้น

Forwarded

ใช้โดยเกตเวย์และพร็อกซี่ เพื่อบ่งชี้ขั้นตอนกลางของคำร้องขอหรือคำตอบสนอง แต่ละเกตเวย์และพร็อกซี่ที่จัดการกับเมสเสจอาจผนวกฟีลด์ Forwarded นี้เพื่อแจ้ง URL ของตนเอง

Keep-Alive

จะปรากฏฟีลด์นี้ถ้ามีคีย์เวิร์ด keep-alive อยู่ในฟีลด์ Connection ที่ได้รับเข้ามา ฟีลด์นี้ทำหน้าที่แสดงข้อมูลต่อผู้ที่ร้องขอให้มีการเชื่อมต่อ ฟีลด์นี้อาจระบุช่วงเวลาสูงสุดที่ผู้ส่งจะเปิดการเชื่อมต่อรอไว้สำหรับคำร้องขอถัดไป หรือจำนวนคำร้องขอสูงสุดที่อนุญาตให้มีได้ในการเชื่อมต่อนั้น

MIME-Version

ระบุให้รู้ว่าเมสเสจสอดคล้องกับเวอร์ชันใดของ MIME

Pragma

บรรจุคำสั่งควบคุมที่เกี่ยวข้องกับชุดคำร้องชอ/คำตอบสนองหนึ่งๆ

Upgrade

ใช้ในคำร้องขอเพื่อระบุถึงโปรโตคอลอื่นๆ ที่ไคลเอ็นต์รองรับและต้องการใช้ หรือใช้ในคำตอบสนองเพื่อระบุโปรโตคอลที่ถูกใช้

 

เมสเสจร้องขอ (Request Messages)

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

เมธ็อดร้องขอ (Request Method)

       เมสเสจร้องขอที่สมบูรณ์จะเริ่มต้นด้วยส่วน Request-Line เสมอ ซึ่งมีรูปแบบดังนี้

Request-Line = Method SP Request-URL SP HTTP-Version CRLF

 

       พารามิเตอร์ Method เป็นตัวระบุคำสั่งของการร้องขอที่แท้จริง หรือที่นิยมเรียกกันใน HTTP ว่าเมธ็อดนั่นเอง สำหรับ Request-URL คือ URL ของรีซอร์สที่ถูกร้องขอ และ HTTP-Version คือหมายเลขเวอร์ชันของ HTTP ที่ผู้ส่งใช้ HTTP/1.1 กำหนดให้มีเมธ็อดร้องขอดังต่อไปนี้

OPTIONS

ใช้สอบถามข้อมูลเกี่ยวกับตัวเลือกที่ใช้ได้ในคำร้องขอ/คำตอบสนองซึ่งระบุด้วย URL นี้

GET

ร้องขอข้อมูลที่ระบุใน URL โดยส่งกลับมาในส่วนของเอ็นติตี้

HEAD

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

POST

ร้องขอเอ็นติตี้ในฐานะที่เป็น subordinate ของ URL ที่ระบุ เอ็นติตี้ที่ส่งมานั้นเป็น subordinate ของ URL ในลักษณะเดียวกันกับที่ไฟล์เป็น subordinate ของไดเร็กทอรีที่บรรจุไฟล์นั้นไว้ ทำนองเดียวกับบทความข่าวที่เป็น subordinate ของกลุ่มข่าว (Newsgroup) และทำนองเดียวกับเรคอร์ดที่เป็น subordinate ของฐานข้อมูล

PUT

ร้องขอเอ็นติตี้ แล้วนำไปเก็บไว้ภายใต้ URL ที่กำหนด ซึ่งอาจเป็นรีซอร์สใหม่ของ URL ใหม่ หรือแทนที่รีซอร์สเดิมด้วย URL ที่มีอยู่แล้ว

PATCH

คล้ายคลึงกับเมธ็อด PUT แต่เอ็นติตี้จะเก็บรายการความแตกต่างจากเนื้อหาของรีซอร์สเดิมที่ระบุใน URL

COPY

ร้องขอให้มีการคัดลอกรีซอร์สที่ระบุด้วย URL ใน Request-Line ไปยังตำแหน่งที่ระบุด้วยฟีลด์ URL-Header ในส่วน Entity-Header ของเมสเสจ

MOVE

ร้องขอให้มีการย้ายรีซอร์สที่ระบุด้วย URL ใน Request-Line ไปยังตำแหน่งที่ระบุด้วยฟีลด์ URL-Header ในส่วน Entity-Header ของเมสเสจ เมธ็อดนี้เทียบเท่ากับการใช้เมธ็อด COPY แล้วตามด้วยเมธ็อด DELETE

DELETE

ร้องขอให้ออริจิ้นเซิร์ฟเวอร์ลบรีซอร์สที่ระบุด้วย URL ใน Request-Line

LINK

สร้างลิงค์ 1 ลิงค์หรือมากกว่าจากรีซอร์สที่ระบุใน Request-Line โดยลิงค์ต่างๆ จะถูกกำหนดไว้ในฟีลด์ Link ใน Entity-Header

UNLINK

ลบลิงค์ 1 ลิงค์หรือมากกว่าจากรีซอร์สที่ระบุใน Request-Line โดยลิงค์ต่างๆ จะถูกกำหนดไว้ในฟีลด์ Link ใน Entity-Header

TRACE

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

WRAPPED

อนุญาตให้ไคลเอ็นต์ส่งคำร้องในแบบ encapsulated 1 คำร้องหรือมากกว่า คำร้องอาจได้รับการเข้ารหัสไว้หรือได้รับการประมวลผลอย่างใดอย่างหนึ่ง ซึ่งเซิร์ฟเวอร์จะต้องแกะคำร้องนั้นออกมาแล้วประมวลผลไปตามความเหมาะสม

Extension-method

อนุญาตให้มีการกำหนดเมธ็อดขึ้นมาใหม่โดยไม่ต้องปรับเปลี่ยนโปรโตคอล อย่างไรก็ตาม เราไม่สามารถทึกทักได้ว่าผู้รับรู้จักกับเมธ็อดเหล่านั้น

 

ฟีลด์ในส่วนเฮดเดอร์ของคำร้องขอ

       ฟีลด์ในส่วนเฮดเดอร์ของคำร้องขอทำหน้าที่เป็นส่วนเพิ่มเติมของคำร้องขอ โดยจัดเตรียมข้อมูลและพารามิเตอร์ที่เกี่ยวข้องกับคำร้องขอนั้น ฟีลด์ต่างๆ ต่อไปนี้ถูกกำหนดไว้ใน HTTP/1.1

Accept

ประเภทของสื่อและช่วงค่าที่ยอมรับได้ในคำตอบสนองของคำร้องนั้น

Accept-Charset

ชุดอักขระที่ยอมรับได้ในคำตอบสนอง

Accept-Encoding

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

Accept-Language

จำกัดกลุ่มของภาษาที่ต้องการให้ใช้ในคำตอบสนอง

Authorization

บรรจุค่าที่เรียกว่าเป็น "หนังสือรับรอง" ซึ่งไคลเอ็นต์ใช้ยืนยันตนเองต่อเซิร์ฟเวอร์

From

อีเมล์แอดเดรสของผู้ควบคุมยูสเซอร์เอเจนต์ที่ใช้ร้องขอ

Host

ระบุโฮสต์ของรีซอร์สที่ร้องขอไป

If-Modified-Since

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

Proxy-Authorization

อนุญาตให้ไคลเอ็นต์ระบุตนเองต่อเซิร์ฟเวอร์ได้เมื่อจำเป็น

Range

เตรียมการไว้ใช้กับเมธ็อด GET ในอนาคต โดยไคลเอ็นต์สามารถร้องขอส่วนใดส่วนหนึ่งของรีซอร์สที่ระบุได้

Referer

คือ URL ของรีซอร์สซึ่ง Request-URL ได้รับมา

Unless

มีหน้าที่คล้ายกับฟีลด์ If-Modified-Since แต่ด้วยความแตกต่าง 2 ประการคือ (1) ไม่ถูกจำกัดอยู่กับเมธ็อด GET และ (2) การเปรียบเทียบจะกระทำกับค่าของฟีลด์ใดๆ ใน Entity-Header ก็ได้ แทนที่จะเป็นค่าของวัน/เวลา

User-Agent

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

 

โปรโตคอล HTTP นี้วิ่งอยู่บน TCP/IP อีกชั้นหนึ่ง รูปแบบการทำงานจะไม่มีการจองสาย โดย client จะเรียกข้อมูลจาก server โดยการส่ง request ไปแล้วจะตัดการติดต่อทันที จากนั้นจะรอจนกระทั่ง server ส่งข้อมูลมาให้

 

ประโยชน์ของการทำงานแบบไม่จองสายของ HTTP ทำให้ WWW server สามารถให้บริการ client ได้หลายๆ คนพร้อมๆ กัน การสื่อสารของ WWW จึงมีประสิทธิภาพมากขึ้น

          

         

 

ความสัมพันธ์ ระหว่าง HTTP กับ HTML

             

       จะว่าไปแล้ว HTTP กับ HTML นั้นก็เหมือนกาแฟกับคอฟฟี่เมท โดย HTTP คือโปรโตคอลที่ใช้สื่อสารระหว่าง client computer กับ server computer ทำให้ทั้งสองเครื่องรู้ว่าจะจัดการส่งข้อมูลไปอย่างไร ส่วน HTML คือสื่อภาษาที่ทำให้เอกสารหรือ contents ที่อยู่บนเครื่อง server computer เมื่อถูกส่งมาที่ client computer แล้วจะนำไปแสดงได้อย่างไร เราเรียกซอฟท์แวร์ที่ใช้แสดงนี้ว่า Browser

 

ข้อดีของการแยกชั้นการทำงานระหว่าง HTTP กับ HTML

  1. Contents
    2.

  2. Web Server

  3. Client Computer

  4. Browser

MENU