HTTP ย่อมาจาก Hyper Text Transfer Protocol เป็นโปรโตคอลสื่อสารที่ทำงานอยู่บนระบบโปรโตคอล TCP HTTP ใช้ในระบบเครือข่ายใยแมงมุม (World Wide Web)จำหน่าย,แจกจ่าย รวมไปถึงการรับข้อมูล จากระบบสื่อกลางชั้นสูง (Hypermedia System) ที่ประกอบด้วยเครื่องให้บริการ (Server) ที่มีอยู่มากมายทั่วโลก โปรโตคอล HTTP วิ่งอยู่บน TCP/IP อีกชั้นหนึ่ง รูปแบบการทำงานจะไม่มีการจองสายโดย Client จะเรียกข้อมูลจาก Server โดยการส่ง Request ไปแล้วจะตัดการติดต่อทันที จากนั้นรอจน Server ส่งข้อมูลมาให้
ประโยชน์ของการทำงานแบบไม่จองสายของ HTTP ทำให้ WWW server สามารถให้บริการ client ได้หลายๆ คนพร้อมๆ กัน การสื่อสารของ WWW จึงมีประสิทธิภาพมากขึ้น
WWW (World Wide Web) คืออะไร
ปัจจุบัน World Wide Web เป็นหนึ่งในเทคโนโลยีด้านข่าวสารที่สำคัญที่สุดอันหนึ่ง ได้มีผู้นิยามความหมายของ World Wide Web อย่างมากมาย ่ในที่นี้จึงไม่ขอเพิ่มคำนิยามใดๆอีก แต่จะสร้างความเข้าใจให้กับคุณ
รูปแบบของลูกข่ายและเครื่องให้บริการ ( The client/server model) หากมองกันในมุมมองของนักเขียนโปรแกรมแล้ว World Wide Web ก็คือระบบ client/server ที่มีขนาดใหญ่ที่สุด ประกอบด้วยเครื่องให้บริการ (Server) และ เครื่องลูกข่าย (Client) จำนวนมากมายนับไม่ถ้วน โดยทั้งหมดจะทำการแลกเปลี่ยนข้อมูลข่าวสารซึ่งกันและกันตลอดเวลา ในระบบ client/serve การติดต่อสื่อสารระหว่างเครื่องลูกข่ายและเครื่องให้บริการโดยปกติจะเกิดขึ้นเพื่อกระทำงานบางอย่าง โดยอาจเป็นคำสั่งซื้อทางจดหมายที่สั่งมาที่บริษัท หรือข้อมูลของระบบการวางแผนสำหรับกลุ่มผู้บริหาร web จะเปลี่ยนสิ่งเหล่านี้ให้เป็นงานที่ยุ่งยากสลับซับซ้อนและเป็นงานที่ง่ายไปพร้อมกัน ส่วนที่ง่ายก็คือส่วนที่มาจากโปรโตคอลที่ออกแบบอย่างดี ที่ใช้ระหว่างเครื่องให้บริการและเครื่องลูกข่าย ส่วนที่ยากก็คือส่วนที่มาจากโปรโคคอลที่ผู้เขียนโปรแกรมออกแบบ ซึ่งอาจจะยากและสิ้นเปลืองการคำนวนมาก หากจะอธิบายให้ละเอียดให้เป็นรูปธรรมขึ้นอีกสักนิด นั่นคือ ถ้าคุณจะต้องเขียนโปรแกรม applicationที่เข้าจัดการกับงานลงทะเบียนลำดับ (order entry) คุณจะต้องกำหนดชนิดของการติดต่อ (transaction) ที่จะใช้ระหว่างเครื่องลูกข่ายของคุณกับเครื่องให้บริการ ซึ่งอาจเป็นการแลกเปลี่ยนข้อมูลเพื่อค้นหาค่า (look up) ลักษณะรูปร่างของสิ่งของในบัญขีหรือรายชื่อ เครื่องลูกข่ายจะต้องสร้างการเชื่อมต่อกับเครื่องให้บริการแล้ว ส่งคำร้องขอซึ่งอาจอยู่ในรูปแบบของข้อความ (text) หรือรหัสเลขฐานสอง (binary) จะส่งไปสู่เครื่องให้บริการ จากนั้นจะได้รับคำตอบกลับมาซึ่งโดยมาก คำตอบกลับจะอยู่ในรูปแบบของข้อความ แต่บางครั้งมีรหัสเลขฐานสองผสมมาด้วยในกรณีที่เป็นรูปภาพ ถ้าเราใช้ซอกเก็ต ของ TCP/IP ในการติดต่อนั้น เครื่องลูกข่ายจะต้องสร้างการเชื่อมต่อสู่ port ที่เครื่องให้บริการรออยู่ แล้วจึงจะส่งแพกเกจข้อมูลไปสู่เครื่องให้บริการ เราอาจจะต้องกำหนดโครงสร้างของแพกเกจร้องขอ (request packet) ให้มีขนาด 4 byte เพื่อให้ง่ายต่อการแปลข้อมูล เครื่องให้บริการจะอ่าน 4 byte นี้ออกจากซอกเก็ตเพื่อตีความตามนั้น และส่งข้อมูลตอบกลับไปสู่เครื่องลูกข่ายในรูปแบบที่กำหนดไว้แน่นอน (ดูรูป)
ในกรณีนี้คุณได้กำหนดให้มีส่วนหัว (header) 4 byte ที่ประกอบด้วยความยาวของคำอธิบาย (length of description) ในรูปของข้อความ (text) และมีตัวคำบรรยาย (description)นั้นตามต่อมา จากนั้นก็เป็นอีก 4 byte ที่บอกถึงความยาวของข้อมูลรหัสฐานสอง และตามด้วยชุดรหัสฐานสองนั้น (รหัสฐานสองนี้เป็นรูปภาพ) เมื่อเครื่องลูกข่ายได้รับข้อมูลเรียบร้อยแล้ว เครื่องให้บริการก็จะปิดการเชื่อมต่อและถือเป็นอันสิ้นสุดการดำเนินงาน จะเห็นได้ว่าในกรณีที่คุณเป็นผู้เขียนโปรแกรมนั้นจะเป็นงานที่ยืดหยุ่นมากทีเดียว คุณสามารถจะกำหนดรูปแบบที่แน่นอนของแพกเกจ สร้างรหัสนั้นให้มีประสิทธิภาพ ลดจำนวนการติดต่อทางระบบเครือข่ายหรือที่เรียกว่า network trafic ลงให้น้อยที่สุด และเพิ่มจำนวนของข้อมูลที่ส่งในแต่ละการติดต่อให้ได้มากที่สุด ในส่วนของ application ก็สามารถจะกำหนดและดำเนินงานส่งถ่ายข้อมูล (transaction) ระหว่างเครื่องลูกข่ายกับเครื่องให้บริการได้อย่างรวดเร็ว ปัญหาอาจเกิดขึ้นหลังจากที่ใช้งานไปแล้วประมาณ2 -3 เดือน เมื่อ application อันสวยหรูของคุณเป็นที่ต้องการใช้ในกลุ่มเครื่องที่มีระบบปฎิบัติการ (OS) ที่เป็น Windows 95 หรือ OS/2 ในเวลานั้นคุณจะต้องกลับไปสร้างโปรแกรมใหม่อีกสองตัวเพื่อสนับสนุนทั้งสองระบบนี้ และอาจจะต้องทำเพิ่มขึ้นอีกเพื่อใช้กับระบบอื่นๆ ที่อาจตามมาในไม่ช้า คงดีกว่าถ้าสามารถเขียนโปรแกรมครั้งเดียวแล้วสามารถใช้ได้ทุกๆระบบปฎิบัติการ (นั่นคือคุณต้องหันมาพึ่งHTTP แล้ว) แทนที่คุณจะต้องเขียนโปรแกรมสำหรับทุกๆระบบ คุณก็ใช้เครื่องลูกข่ายบน Web (Web client) อย่างเช่น Netscape Navgator ทำงานสื่อสารกับเครื่องให้บริการบน Web (Web server) เพื่อสร้างระบบ client/server ของคุณ
รูปแบบเฟรมของ HTTP
เนื่องจาก HTTP เป็นโปรโตคอลที่ทำงานบน TCP ดังนั้น รูปแบบเฟรมของ HTTP จึงถูกจัดเป็นส่วนของข้อมูลของเฟรม TCP ดังรูป เฮดเดอร์ของ HTTP จะอยู่ในรูปของข้อความ (text) ข้อมูลของ HTTP โดยปกติจะเป็นข้อความ (text) ด้วยเช่นกัน แต่ก็เป็นรหัสฐานสอง (binary) ได้ใน เช่นกรณีที่เป็นรูปภาพ
การติดต่อสื่อสารของ HTTP
รูปแบบการสื่อสารของ HTTP เป็นรูปแบบที่ง่ายมาก : เครื่องลูกข่ายจะสถาปณาการเชื่อมต่อกับเครื่องให้บริการ (remote server) จากนั้นก็ส่งคำร้องขอ (Requests)ไปให้เครื่องให้บริการ เครื่องให้บริการเมื่อได้รับการร้องขอก็จะประมวลผลและส่งการตอบกลับ (Response) กลับไปให้เครื่องลูกข่าย แล้วปิดการเชื่อมต่อ
การร้องขอ (Requests)
คำร้องขอของ HTTP นั้นง่ายมาก บรรทัดแรกจะระบุวัตถุ (Object) พร้อมด้วยชื่อคำสั่งที่ระบุถึงวิธีการ คำสั่งที่ใช้โดยทั่วไปคือ "GET" ซึ่งเป็นการขอให้เครื่องให้บริการส่งสำเนาของวัตถุ (Object) นั้นมาให้เครื่องลูกข่าย เครื่องลูกข่ายสามารถส่งเฮดเดอร์ตัวเลือก (Optional headers) ตามมาอย่างต่อเนื่องได้ ตามรูปแบบของ RCF-822
เฮดเดอร์ที่ใช้โดยทั่วไปคือ
"Accept" ซึ่งจะแจ้งให้เครื่องให้บริการทราบว่า เครื่องลูกข่ายสามารถรับหรือทำงานกับวัตถุ (object) ชนิดใดได้บ้าง และ
"User-Agent" ซึ่งจะให้ชื่อการอิมพลีเมนท์ของเครื่องลูกข่าย
เมื่อไคลเอนต์ต้องการติดต่อกับเซิร์ฟเวอร์จะทำการส่ง Request Message โดยมีรูปแบบดังนี้
[method] http://[host]:[port]/[abs-path][? query] HTTP/1.0 [CRLF]
Content-Length: [msg-body-len][CRLF]
Proxy-Connection: [proxy-conn][CRLF]
[CRLF]
[msg-body]
[method] เพื่อระบุว่า Client ต้องการทำอะไรกับ Sever
[host] เพื่อระบุ Server ในรูปแบบ dot decimal เช่น 10.0.0.1
[port] เพื่อระบุ Port ที่ใช้ในการติดต่อ (ค่ามาตรฐานคือพอร์ตหมายเลข 80)
[abs-path] เพื่อระบุว่าต้องการไฟล์ไหนที่อยู่บน server ต้องเป็น Absolute Path และCase-sensitive
[query] เพื่อระบุค่าต่างๆในกรณีที่มีการส่งค่าไปประมวลผลฝั่งเซิร์ฟเวอร์
[msg-body] เพื่อระบุข้อความซึ่งส่งไปยังเซิร์ฟเวอร์เก็บข้อมูลแบบ Text
[msg-body-len] เพื่อระบุความยาวของข้อความในเลขฐานสิบมีหน่วยเป็นไบท์
[proxy-conn] เพื่อระบุว่าการเชื่อต่อจะเป็นแบบ Keep-Alive (เชื่อต่อแบบ Persistence) หรือ Close (เพื่อหยุดการเชื่อมต่อ)
[CRLF] คือตัวอักษรในระบบ ASCII 2 ตัวคือ Carrier Return (No.15) และตามด้วย Line Feed (No. 12)
การตอบกลับ (Responses)
การตอบกลับก็ยังคงอยู่ในรูปแบบที่ง่ายมาก เริ่มต้นด้วยบรรทัดแสดงสถานะ ซึ่งจะบ่งบอกรุ่น (version) ของ HTTP ที่เครื่องให้บริการใช้อยู่ พร้อมกับรหัสผลลัพท์และข้อความอื่นๆ ตามด้วยเฮดเดอร์วัตถุ (optional object headers) ต่อเนื่องเป็นลำดับ ซึ่งที่สำคัญที่สุดคือ
"Content-Type" ซึ่งจะบ่งบอกชนิดของวัตถุ (object) ที่ส่งกลับไปด้วย
"Content-Length" ซึ่งจะบอกความยาวของวัตถุนั้น
ส่วนที่เป็นเฮดเดอร์นี้จะต้องปิดท้ายด้วยบรรทัดว่างๆหนึ่งบรรทัด เมื่อจบส่วนเฮดเดอร์ก็จะตามด้วยข้อมูลที่เครื่องลูกข่ายร้องขอ และเครื่องให้บริการก็จะปิดการเชื่อมต่อหลังจากที่ส่งข้อมูลไปแล้ว
เมื่อเซิร์ฟเวอร์ทำการประมวลผลแล้วจะทำการตอบกลับด้วย Responses Message โดยมีรูปแบบดังนี้
HTTP/1.0 [status-code] [status-reason] [CRL
Content-Length: [msg-body-len][CRLF]
Proxy-Connection: [proxy-conn][CRLF]
[CRLF]
[msg-body]
[status-code] เพื่อระบุว่าการร้องขอมีสถานะเป็นเช่นไร
[status-reason] เพื่อระบุสาเหตุปัญหาอย่างย่อ
[msg-body] เพื่อระบุข้อความเพื่อส่งไปยังไคลเอ็นต์ซึ่งแล้วแต่ Status Codeถ้า status = 200 จะทำการส่งข้อมูลกลับไป
ถ้า status = 4XX, 5XX จะทำการส่งรายละเอียดของปัญหากลับไป
[msg-body-len] เพื่อระบุความยาวของข้อความ ในเลขฐานสิบมีหน่วยเป็นไบท์
[proxy-conn] เพื่อระบุว่าการเชื่อต่อเป็นแบบ Keep-Alive (เชื่อมต่อแบบ Persistence) หรือ Close (เพื่อหยุดการเชื่อมต่อ)
[CRLF] คือตัวอักษรในระบบ ASCII 2 ตัวคือ Carrier Return (No.15) และตามด้วย Line Feed (No. 12)
ปฏิบัติการส่งข้อมูลของ HTTP
ในการปฎิบัติการของ HTTP จะมีลูกโซ่ของการร้องขอ-ตอบรับ (request-response) รูปแบบที่หนึ่ง เมื่อเครื่องผู้ใช้ทำการเชื่อมต่อโดยตรงสู่เครื่องให้บริการบน port หมายเลข 80 (อาจเป็นเบอร์อื่นได้แล้วแต่จะกำหนด) และส่งคำร้องขอ (request) ออกไป เมื่อเครื่องให้บริการซึ่งกำลังรออยู่ได้รับการเชื่อมต่อก็จะสร้างกระบวนการ (process) ใหม่ (หากคุณศึกษาวิชา OS มาแล้วเราจะใช้ศัพท์เฉพาะว่า "thread" จะตรงกว่า) เพื่อให้บริการกับคำร้องขอนั้น เมื่อคำร้องขอได้รับการประมวลผลแล้ว เครื่องให้บริการจะส่งคำตอบที่ได้กลับไปทางการเชื่อมต่อที่ port เดิม
รุ่นของ HTTP (Version of HTTP)
ต่อไปนี้จะได้กล่าวถึง HTTP ในรุ่นต่างๆ ตั้งแต่รุ่นแรก โดยจะอธิบายในคุณสมบัติและคำสั่งที่เพิ่มขึ้นเป็นลำดับเรื่อยไป
HTTP รุ่น 0.9
เป็น HTTP รุ่นแรกที่มีการใช้งาน คำอธิบายของโปรโตคอลนี้สรุปได้เพียงไม่กี่หน้าเท่านั้น ในรุ่นนี้เครื่องลูกข่าย จะติดต่อกับเครื่องให้บริการผ่านทาง TCP ใน port ที่ 80 จากนั้นส่งคำร้องขอในรูปแบบดังนี้
.
GET document.html CRLF
.
คำร้องขอขึ้นด้วยคำว่า GET จากนั้นก็ตามด้วยตัวอักษรที่เป็นช่องว่างหนึ่งตัวและชื่อของเอกสารในที่นี้คือ document.html ชื่อในที่นี้ต้องเป็นชื่อเต็มๆ และไม่มีช่องว่างใดๆ ขั้นอยู่
และในตอนท้ายของบรรทัดเครื่องลูกข่ายต้องส่งเครื่องหมาย return (carriage return line feed combination) ซึ่งจะบ่งบอกให้เครื่องให้บริการควรจะยอมต่อเครื่องลูกข่าย โดยส่งป้อนเพียงบรรทัดตามด้วยเครื่องหมาย return เท่านั้น
อีกวิธีหนึ่งใช้กับชื่อของเอกสารได้คือ เครื่องลูกข่ายจะส่งคำร้องขอเพื่อค้นหาโดยการเพิ่มตัวอักษรคำถาม ‘?’ ตามด้วยพจน์ที่ต้องการหา ในกรณีที่ต้องการค้นหาแบบหลายๆ พจน์ ก็อาจกำหนดได้โดยการใส่เครื่องหมายบวก ‘+’ ระหว่างพจน์ คำร้องขอแบบนี้จะถูกสร้างขึ้นเมื่อเอกสารที่ระบุนั้นมีบ้าย ISINDEX.HTML เท่านั้น ดังตัวอย่างเช่น
.
GET document.html?help+me CRLF
.
ในด้านคำตอบนั้น เครื่องให้บริการจะตอบกลับด้วยข้อความที่บรรจุอยู่ในเอกสาร โดยจะไม่มีข้อความข่าวสาร (Content Information) ชนิด MIME หรือข่าวสารอื่นใดส่งกลับไปให้เครื่องลูกข่าย
ในความเป็นจริงแล้วโปรโตคอลชนิดนี้จำกัดอยู่ที่การส่งเอกสารแบบข้อความของ HTML (HTML text docmuent) เท่านั้น เมื่อเอกสารถูกส่งออกไปแล้ว เครื่องให้บริการจะปิดการเชื่อมต่อเพื่อแสดงว่าสิ้นสุดเอกสารแล้ว ที่ต้องทำอย่างนี้เป็นความจำเป็นเนื่องจากไม่มีการกำหนดความยาวของเอกสารที่จะส่งบอกให้ทราบระหว่างเครื่องให้บริการ และเครื่องลูกข่าย ในขณะที่ส่งเอกสาร เครื่องให้บริการจะต้องจำกัดแต่ละบรรทัดที่ส่งโดยเครื่องหมาย return (carriage return) ซึ่งตามด้วยอักษรป้อนบรรทัด (line feed character) จากข้อมูลข้างต้นจะเห็นว่าการสร้าง HTTP รุ่น 0.9 นั้นทำได้ง่ายๆ เพียงไม่กี่สิบบรรทัด ปัญหาก็คือข้อจำกัดที่กำหนดให้มีเพียงเอกสารที่เป็นข้อความเท่านั้นที่ส่งได้ และไม่มีวิธีที่เครื่องลูกข่ายจะส่งข้อมูลข่าวสารอื่นๆสู่เครื่องให้บริการได้เลย
HTTP รุ่น 1.0
HTTP ในรุ่นนี้ได้รับการพัฒนาตั้งแต่ปี 1992 จนถึงปี 1996 ปรากฎตัวครั้งแรกในเอกสาร RFC ในเดือนพฤษภาคมปี 1996 HTTP 1.0 อยู่บนพื้นฐานเดียวกันกับ web server/client โดยส่วนใหญ่ ในเอกสาร RFC 1945 นั้นเป็นเพียง RFC ข้อมูลข่าวสาร ( informational RFC) มิใช่มาตรฐานที่เป็นทางการสำหรับระบบอินเตอร์เนต ( Official Standard of theInternet) แต่ภายหลังก็ได้มีการอธิบายถึงวิธีการใช้งานโดยทั่วไปของ HTTP 1.0 รวมถึงคู่มืออ้างอิงสำหรับเครื่องให้บริการในรูปของ CD ที่แนบมาด้วย
HTTP 1.0 พัฒนาจากความต้องการที่จะแลกเปลี่ยนข้อมูลที่มากกว่า ข้อมูลแบบข้อความ (text) ทั่วๆไป และกลายเป็นทางเลือกหนึ่งที่จะสร้างระบบกระจายข่าวสารแบบ hypermedia (distributed hypermedia information system) ที่ปรับเปลี่ยนให้เข้ากับความต้องการและจุดประสงค์หลายๆแบบได้ จากปี 1994 ถึงปี 1997 การพัฒนาของระบบ web จากกลุ่มเล็กๆ ในสาขาวิทยาการคอมพิวเตอร์เพื่อจะแสดงผลงานวิจัยของตนออกสู่หน่วยงานศูนย์กลาง ได้พัฒนาขยายตัวอย่างรวดเร็ว จนปัจจุบันรายการโทรทัศน์กว่าครึ่งหนึ่งจะมีการประกาศ URLของตนเอง จึงเป็นที่ยืนยันได้ว่า HTTP ได้แพร่ขยายอย่างมากมายมหาศาล จุดเปลี่ยนหลักๆ จาก HTTP 0.9 เดิมคือการใช้เฮดเดอร์ที่เหมือนกับ MIME ในการร้องขอและการตอบรับ โครงสร้างของการร้องขอ (request message) ได้โตขึ้นจากเดิม ซึ่งมีเพียงบรรทัดเดียวมาเป็นโครงสร้างที่มีหลายบรรทัดดังนี้
Full-Request = Request-Line
*( General-Header
Request-Header
Entity-Header )
CRLF
[ Entity-Body ]
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
เฮดเดอร์ที่เพิ่มขึ้นเป็นผลมาจากความต้องการที่จะส่งข่าวสารให้มากขึ้น ซึ่งสำหรับเครื่องลูกข่ายนั้น ข่าวสารนี้จะรวมไปถึงการส่งชนิดของข้อมูลที่ตัวมันต้องการด้วย โดยจะแสดงอยู่ในรูปพจน์ของชนิดตัวกลางของ MIME (MIME media types) ตัวอย่างเช่นพจน์ text/html และ image/gif จะถูกกำหนดไว้ เพื่อว่าเครื่องลูกข่ายและเครื่องให้บริการ จะได้เข้าใจถึงข้อมูลที่ส่งให้กันและนำไปใช้ได้อย่างถูกต้อง
นอกจากนี้เฮดเดอร์ที่เพิ่มขึ้นยังแจ้งให้เครื่องลูกข่ายได้ทราบถึงเงื่อนไขของข้อมูลในหน่วยความจำ โดยใช้เฮดเดอร์ If-Modified-Since ซึ่งจะทำให้เครื่องลูกข่ายสามารถถามแหล่งต้นตอของข้อมูลให้ตอบกลับมาว่าข้อมูลชุดที่เครื่องลูกข่ายต้องการนั้นมีการเปลี่ยนแปลงไปจากที่มีอยู่ในหน่วยความจำ
(ประเภทแคช) ของมันหรือไม่ โดยดูจากวันที่ที่กำหนดไว้ ด้วยวิธีนี้เครื่องลูกข่ายจะทำการอัพเดทเฉพาะข้อมูลชุดหรือหน้าที่จำเป็นคือมีวันที่ไม่ตรงกันเท่านั้น ช่วยลดเวลาและประหยัดการใช้ช่วงสัญญาณ(bandwidth) ได้อย่างมาก ในด้านของเครื่องให้บริการ มันสามารถส่งข้อมูล (Information) ของสาระ (content) ที่ส่งมาได้ ใน HTTP 0.9 นั้นจะส่งได้แต่เพียงสาระซึ่งเป็นเพียงเอกสาร HTML เท่านั้น แต่ด้วยรูปแบบคำตอบรับที่ขยายเพิ่มขึ้นใน HTTP/1.0 นี้ สามารถแจ้งให้กับเครื่องลูกข่ายทราบได้อย่างแน่นอนว่าสาระที่จะส่งเป็นข้อมูลประเภทไหน ดังรูปแบบต่อไปนี้
Full-Response = Status-Line
*( General-Header
Request-Header
Entity-Header )
CRLF
[ Entity-Body ]
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
การมีเฮดเดอร์ที่เพิ่มขยายนั้น เพื่อให้เครื่องให้บริการบ่งบอกถึงชนิดของข้อมูลของสาระที่ส่งมาประกอบกับเอกสาร HTML พื้นฐานได้ ทำให้การใช้รูปภาพและข้อมูลเสียงเป็นที่นิยมจนกลายเป็นรูปแบบสาระที่เครื่องให้บริการต้องส่งเสมอๆ
นอกจากนี้ HTTP 1.0 ยังได้เปลี่ยนวิธีการร้องขอใหม่ โดยเพิ่มคำสั่งนอกเหนือจากคำร้องขอด้วย GET คือ HEAD และ POST การร้องขอด้วย HEAD จะอนุญาติให้เครื่องลูกข่ายร้องขอสาระจากเครื่องให้บริการ และ รับข้อมูลของสาระทั้งหมดได้โดยไม่ต้องรับสาระนั้นมาจริงๆ สิ่งนี้ได้ใช้กันมากในหุ่นยนต์และแมงมุม
Web ซึ่งใช้ในการสำรวจการเชื่อมต่อ (link) เพื่อรวบรวมและอัพเดทข้อมูล รวมถึงการตรวจสอบการเชื่อมต่อที่เสียหาย การร้องขอด้วย POST จะทำให้ web มีลักษณะของการตอบโต้กับผู้ใช้โดยตรง (interactive) มันทำให้เครื่องลูกข่ายสามารถส่งข้อมูลจริงๆไปให้เครื่องให้บริการเพื่อนำไปประมวลผลได้ เนื่องจากวิธีการแบบ GET เดิมนั้นการส่งข้อมูลจะถูกจำกัดด้วยจำนวนของข้อมูลที่เครื่องให้บริการจะสามารถรับได้ในส่วนของคำร้องขอ URI เท่านั้นดังที่เคยกล่าวไว้ในตอนต้น แต่ต้วยวิธีของ POST ซึ่งเสมือนไม่จำกัดในส่วนของ entity body จะทำให้การนำเข้า (input) ข้อมูลเช่น ใบสั่งของ, แบบประเมินผล, ใบสมัคร ต่างๆเหล่านี้สามารถทำได้บน Webpage ด้วย HTTP 1.0 นี้ เครื่องให้บริการยังสามารถตอบกลับ คำร้องของของเครื่องลูกข่าย ด้วยรหัสสถานะ (status code) รหัส 404 ที่เราคุ้นเคยและเกลียดที่สุดคือ รหัสสถานะระบุว่าไม่พบสาระนั้น
(Object Not found) จะถูกส่งจากเครื่องให้บริการ ในกรณีที่ไม่มีข้อมูลที่เครื่องลูกข่ายร้องขอมา รหัส 200 บ่งชี้ว่าเครื่องให้บริการสามารถตอบกลับได้อย่างสมบูรณ์ รหัส 302 บ่งชี้ว่าข้อมูลหรือสาระนั้นได้ย้ายได้ที่ตำแหน่ง (location) ชั่วคราว รหัส 401 คือต้องการการอนุญาติ ( authorization ) ในการเข้าถึงข้อมูลหรือสาระนั้น รหัส 500 บอกว่ามีความผิดพลาดเกิดขึ้นทางด้านเครื่องให้บริการ ขณะที่พยายามตอบรับการร้องขอของเครื่องลูกข่าย
รหัสที่น่าสนใจคือรหัส 401 คือรหัสสถานะไม่อนุญาติให้เข้าถึง นี่เป็นจุดเด่นของ HTTP 1.0 เลยทีเดียว
HTTP รุ่น 1.1
HTTP/1.1 ได้มีการจัดแบนด์วิดท์ให้ดียิ่งขึ้นไปกว่ารุ่น 1.0 ยกตัวอย่างเช่น HTTP/1.1 มีการแนะนำการเข้ารหัสขนส่งเป็นชิ้นส่วน (chunked transfer encoding) เพื่อทำให้เนื้อหาบนการเชื่อมต่อแบบคงอยู่ส่งถ่ายเป็นกระแสข้อมูลได้ (streaming) แทนที่จะเก็บลงในที่พักข้อมูล (buffer) การทำงานแบบสายท่อของเอชทีทีพี (HTTP pipelining) ก็เป็นอีกเทคนิคหนึ่งที่ช่วยลดความล่าช้าลงได้อย่างมาก ซึ่งทำให้เครื่องลูกข่ายสามารถส่งข้อความร้องขอได้หลายข้อความ ก่อนที่จะได้รับข้อความตอบรับของอันแรก อีกพัฒนาการหนึ่งคือการบริการเป็นไบต์ (byte serving) ซึ่งจะทำให้เครื่องแม่ข่ายส่งถ่ายข้อมูลมาเพียงแค่ส่วนหนึ่งจากทรัพยากรทั้งอัน ในช่วงตำแหน่งที่เครื่องลูกข่ายต้องการ
สถานะการทำงานของ HTTP
โปรโตคอล HTTP ได้กำหนดรหัสแสดงสถานการณ์ทำงานของโปรโตคอลไว้ โดย แบ่งกลุ่มของรหัสสถานะออกไว้เป็น 5 กลุ่มคือ
Response Status Code
1XX ได้รับข้อมูลและกำลังดำเนินการประมวลผลต่อ
100 Continue
101 Switching Protocol
2XX ได้รับข้อมูลประมวลผลและได้รับการตอบรับอย่างสมบูรณ์
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
3XX ข้อมูลต้องได้รับการประมวลผลต่อไป
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 ----
307 Temporary Redirect
4XX ข้อผิดพลาดเกิดจากไคลเอนต์
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allow
406 Not Acceptable
407 Proxy Authentication Required
408 Request Time-Out
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Large
415 Unsupported Media Type
416 Request range not satisfiable
5XX ข้อผิดพลาดเกิดจากเซิร์ฟเวอร์
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
570 Gateway Time-out
505 HTTP Version not supported
เอกสารอ้างอิง
- http://nanotech.sc.mahidol.ac.th/comlab/net/index.html
- http://www.modify.in.th/Website/Hypertext-Transfer-Protocol-HTTP-id70.aspx
- www.thaicert.org/paper/basic/tcp-ip.php
- http://www.widebase.net/knowledge/itterm/it_term_desc.php
-http://th.wikipedia.org/
การติดต่อระหว่าง Client และ Server ใน HTTP จะเกิดขึ้นอย่างไรเมื่อ Client ส่ง Request?
ตอบลบเข้าถึง Telkom University Jakarta