เอชทีทีพี

เอชทีทีพี
มาตรฐานสากล	RFC 1945 HTTP/1.0; RFC 9110 HTTP Semantics; RFC 9111 HTTP Caching; RFC 9112 HTTP/1.1; RFC 9113 HTTP/2; RFC 7541 HTTP/2: HPACK Header Compression; RFC 8164 HTTP/2: Opportunistic Security for HTTP/2; RFC 8336 HTTP/2: The ORIGIN HTTP/2 Frame; RFC 8441 HTTP/2: Bootstrapping WebSockets with HTTP/2; RFC 9114 HTTP/3; RFC 9204 HTTP/3: QPACK: Field Compression;
ผู้พัฒนา	เริ่มต้นโดย CERN; IETF, W3C
ริเริ่ม	1991; 33 ปีที่แล้ว
เว็บไซต์	https://httpwg.org/specs/

เกณฑ์วิธีขนส่งข้อความหลายมิติ ^[1] หรือ เอชทีทีพี (อังกฤษ: HyperText Transfer Protocol: HTTP) คือโพรโทคอลในระดับชั้นโปรแกรมประยุกต์เพื่อการแจกจ่ายและการทำงานร่วมกันกับสารสนเทศของสื่อผสม ^[2] ใช้สำหรับการรับทรัพยากรที่เชื่อมโยงกับภายนอก ซึ่งนำไปสู่การจัดตั้งเวิลด์ไวด์เว็บ

การพัฒนาเอชทีทีพีเป็นการทำงานร่วมกันของเวิลด์ไวด์เว็บคอนซอร์เทียม (W3C) และคณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต (IETF) ซึ่งมีผลงานเด่นในการเผยแพร่เอกสารขอความเห็น (RFC) หลายชุด เอกสารที่สำคัญที่สุดคือ RFC 2616 (เดือนมิถุนายน พ.ศ. 2542) ได้กำหนด HTTP/1.1 ซึ่งเป็นรุ่นที่ใช้กันอย่างกว้างขวางในปัจจุบัน

เอชทีทีพีเป็นมาตรฐานในการร้องขอและการตอบรับระหว่างเครื่องลูกข่ายกับเครื่องแม่ข่าย ซึ่งเครื่องลูกข่ายคือผู้ใช้ปลายทาง (end-user) และเครื่องแม่ข่ายคือเว็บไซต์ เครื่องลูกข่ายจะสร้างการร้องขอเอชทีทีพีผ่านทางเว็บเบราว์เซอร์ เว็บครอว์เลอร์ หรือเครื่องมืออื่น ๆ ที่จัดว่าเป็น ตัวแทนผู้ใช้ (user agent) ส่วนเครื่องแม่ข่ายที่ตอบรับ ซึ่งเก็บบันทึกหรือสร้าง ทรัพยากร (resource) อย่างเช่นไฟล์เอชทีเอ็มแอลหรือรูปภาพ จะเรียกว่า เครื่องให้บริการต้นทาง (origin server) ในระหว่างตัวแทนผู้ใช้กับเครื่องให้บริการต้นทางอาจมีสื่อกลางหลายชนิด อาทิพร็อกซี เกตเวย์ และทุนเนล เอชทีทีพีไม่ได้จำกัดว่าจะต้องใช้ชุดเกณฑ์วิธีอินเทอร์เน็ต (TCP/IP) เท่านั้น แม้ว่าจะเป็นการใช้งานที่นิยมมากที่สุดบนอินเทอร์เน็ตก็ตาม โดยแท้จริงแล้วเอชทีทีพีสามารถ "นำไปใช้ได้บนโพรโทคอลอินเทอร์เน็ตอื่น ๆ หรือบนเครือข่ายอื่นก็ได้" เอชทีทีพีคาดหวังเพียงแค่การสื่อสารที่เชื่อถือได้ นั่นคือโพรโทคอลที่มีการรับรองเช่นนั้นก็สามารถใช้งานได้

ปกติเครื่องลูกข่ายเอชทีทีพีจะเป็นผู้เริ่มสร้างการร้องขอก่อน โดยเปิดการเชื่อมต่อด้วยเกณฑ์วิธีควบคุมการขนส่งข้อมูล (TCP) ไปยังพอร์ตเฉพาะของเครื่องแม่ข่าย (พอร์ต 80 เป็นค่าปริยาย) เครื่องแม่ข่ายเอชทีทีพีที่เปิดรอรับอยู่ที่พอร์ตนั้น จะเปิดรอให้เครื่องลูกข่ายส่งข้อความร้องขอเข้ามา เมื่อได้รับการร้องขอแล้ว เครื่องแม่ข่ายจะตอบรับด้วยข้อความสถานะอันหนึ่ง ตัวอย่างเช่น "HTTP/1.1 200 OK" ตามด้วยเนื้อหาของมันเองส่งไปด้วย เนื้อหานั้นอาจเป็นแฟ้มข้อมูลที่ร้องขอ ข้อความแสดงข้อผิดพลาด หรือข้อมูลอย่างอื่นเป็นต้น

ทรัพยากรที่ถูกเข้าถึงด้วยเอชทีทีพีจะถูกระบุโดยใช้ตัวระบุแหล่งทรัพยากรสากล (URI) (หรือเจาะจงลงไปก็คือ ตัวชี้แหล่งในอินเทอร์เน็ต (URL)) โดยใช้ http: หรือ https: เป็นแผนของตัวระบุ (URI scheme)

ข้อความร้องขอ

ข้อความร้องขอประกอบด้วยสิ่งต่อไปนี้

บรรทัดแรก ขึ้นต้นเป็นคำสั่งร้องขอ และเส้นทางไดเรกทอรีของแฟ้มที่ร้องขอ ตามด้วยรุ่นของ HTTP ตัวอย่างเช่น GET /images/logo.gif HTTP/1.1
บรรทัดต่อ ๆ ไปที่ไม่ใช่บรรทัดว่าง เรียกว่าเป็น ส่วนหัว (header) เป็นเมทาเดตาต่าง ๆ ประกอบการร้องขอ ตัวอย่างเช่น Accept-Language: en
บรรทัดว่าง เพื่อแบ่งแยกระหว่างส่วนหัวกับเนื้อหา
บรรทัดต่อ ๆ ไป เป็นเนื้อหาข้อมูล ซึ่งบางคำสั่งอาจไม่จำเป็นต้องใช้ส่วนนี้

แต่ละบรรทัดจะต้องลงท้ายด้วย CRLF (อักขระปัดแคร่ตามด้วยอักขระป้อนบรรทัด เหมือนการกดปุ่ม Enter ในวินโดวส์) บรรทัดที่ว่างจะมีเพียงแค่ CRLF เท่านั้นโดยไม่มีอักขระช่องว่างอยู่เลย สำหรับรุ่น HTTP/1.1 ส่วนหัว Host: จำเป็นต้องมีเสมอ แต่ส่วนหัวอื่น ๆ ไม่จำเป็นต้องมีก็ได้

บรรทัดคำสั่งที่มีเพียงเส้นทางไดเรกทอรี (ไม่มีชื่อแฟ้ม) ก็เป็นที่ยอมรับโดยเครื่องแม่ข่าย เพื่อรักษาความเข้ากันได้กับโปรแกรมตัวแทนรุ่นเก่าก่อนที่จะมีข้อกำหนดของ HTTP/1.0 ใน RFC 1945 ^[3] ส่วน HTTP/1.1 ได้กำหนดไว้ใน RFC 2068 ^[3]

คำสั่งร้องขอ

เอชทีทีพีได้กำหนดคำสั่งร้องขอไว้แปดคำสั่ง (หรือเรียกว่าวิธีการร้องขอ บางครั้งอาจเรียกว่าเป็น "กริยา") แสดงการกระทำที่ต้องการ เพื่อที่จะดำเนินการกับทรัพยากรที่ถูกระบุ สิ่งที่ทรัพยากรนั้นนำเสนอ ไม่ว่าเป็นข้อมูลที่มีอยู่ก่อนหรือสร้างขึ้นมาแบบพลวัตก็ตาม จะขึ้นอยู่กับการนำไปใช้ของเครื่องแม่ข่าย ซึ่งบ่อยครั้งทรัพยากรมักจะสอดคล้องกับไฟล์ หรือผลลัพธ์ส่งออกจากโปรแกรมข้างเคียงในเครื่องแม่ข่ายนั้น เครื่องให้บริการเอชทีทีพีจะต้องสามารถใช้คำสั่ง GET และ HEAD ได้เป็นอย่างน้อย ^[4]

HEAD: ร้องขอการตอบรับจากทรัพยากรที่ระบุ คล้ายกับ GET แต่จะไม่มีส่วนเนื้อหาที่ร้องขอกลับมา คำสั่งนี้ใช้ประโยชน์ในการตรวจสอบข้อมูลส่วนหัวของการตอบรับ โดยไม่จำเป็นต้องส่งเนื้อหาเต็มมาทั้งหมด
GET: ร้องขอการนำเสนอจากทรัพยากรที่ระบุ คำสั่งนี้ไม่ควรใช้กับการดำเนินการที่อาจทำให้เกิดผลข้างเคียง เช่นการจัดการในเว็บแอปพลิเคชัน เหตุผลหนึ่งคือคำสั่ง GET มักจะถูกใช้อย่างไม่มีกฎเกณฑ์โดยอินเทอร์เน็ตบอตและเว็บครอว์เลอร์ ซึ่งไม่ควรพิจารณาให้การร้องขอของบอตและครอว์เลอร์ส่งผลกระทบต่อทรัพยากรในเว็บ (ดูเพิ่มที่หัวข้อ คำสั่งที่ปลอดภัย)
POST: ส่งข้อมูลไปยังทรัพยากรที่ระบุเพื่อให้นำไปประมวลผล โดยเฉพาะข้อมูลที่ส่งมาจากฟอร์มเอชทีเอ็มแอล ข้อมูลที่ส่งจะถูกบรรจุอยู่ในเนื้อหาของการร้องขอด้วย สิ่งนี้อาจทำให้เกิดการสร้างทรัพยากรใหม่ หรือการปรับปรุงทรัพยากรที่มีอยู่ หรือทั้งสองกรณี
PUT: อัปโหลดการนำเสนอของทรัพยากรที่ระบุ
DELETE: ลบทรัพยากรที่ระบุ
TRACE: ส่งข้อมูลร้องขอกลับมา เครื่องลูกข่ายจะเห็นว่ามีข้อมูลอะไรบ้างที่สื่อกลางเพิ่มหรือเปลี่ยนแปลงข้อความร้องขอก่อนไปถึงทรัพยากรปลายทาง
OPTIONS: คืนค่าเป็นรายชื่อคำสั่งเอชทีทีพีที่เครื่องแม่ข่ายนั้นรองรับสำหรับทรัพยากรที่ระบุ สิ่งนี้สามารถใช้ตรวจสอบฟังก์ชันการทำงานของเว็บเซิร์ฟเวอร์ได้โดยใส่ "*" แทนที่การระบุทรัพยากร
CONNECT: แปลงการเชื่อมต่อของการร้องขอไปเป็นทุนเนล TCP/IP แบบโปร่งใส มักใช้สำหรับแปลงการเชื่อมต่อที่เข้ารหัสแบบ SSL ให้เดินทางผ่านพร็อกซีที่ไม่มีการเข้ารหัสได้ง่ายขึ้น ^[5]

คำสั่งที่ปลอดภัย

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

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

รหัสสถานภาพ

ตั้งแต่ HTTP/1.0 เป็นต้นไป บรรทัดแรกของการตอบรับเอชทีทีพีเรียกว่า บรรทัดสถานภาพ (status line) ซึ่งประกอบด้วยตัวเลข รหัสสถานภาพ (status code เช่น 404) และข้อความ วลีเหตุผล (reason phrase เช่น "Not Found") โปรแกรมตัวแทนผู้ใช้จะพิจารณาการตอบรับในส่วนหัวโดยขึ้นอยู่กับรหัสสถานภาพเป็นหลัก และตามด้วยวลีเหตุผลเป็นรอง รหัสสถานภาพที่กำหนดขึ้นมาเองก็สามารถใช้ได้ ซึ่งหากตัวแทนผู้ใช้พบกับรหัสสถานภาพที่ไม่รู้จัก มันจะพิจารณาตัวเลขตัวแรกในรหัสเพื่อแยกประเภททั่วไปของการตอบรับ ^[6]

รหัสสถานภาพของเอชทีทีพีแบ่งออกเป็นกลุ่มใหญ่ได้ห้ากลุ่มได้แก่

1xx ข้อมูลทั่วไป
2xx การร้องขอสำเร็จ
3xx การเปลี่ยนทาง
4xx ความผิดพลาดจากเครื่องลูกข่าย
5xx ความผิดพลาดจากเครื่องแม่ข่าย

การเชื่อมต่อแบบคงอยู่

ใน HTTP/0.9 และ 1.0 การเชื่อมต่อจะถูกปิดทุกครั้งหลังจากการการร้องขอและการตอบรับจบไป ดังนั้นในรุ่น HTTP/1.1 จึงมีการแนะนำกลไกเพื่อให้การเชื่อมต่อยังคงอยู่ ซึ่งจะทำให้การเชื่อมต่อเพียงครั้งเดียวสามารถใช้ซ้ำได้อีกเรื่อย ๆ มากกว่าหนึ่งครั้ง การเชื่อมต่อแบบคงอยู่เช่นนั้นช่วยลดโอกาสของการเกิดความล่าช้า (lag) เพราะว่าเครื่องลูกข่ายไม่จำเป็นต้องต่อรองการเชื่อมต่อทีซีพีใหม่อีกครั้ง หลังจากข้อความร้องขอแรกได้ถูกส่งไปแล้ว

HTTP/1.1 ได้มีการจัดแบนด์วิดท์ให้ดียิ่งขึ้นไปกว่ารุ่น 1.0 ยกตัวอย่างเช่น HTTP/1.1 มีการแนะนำการเข้ารหัสขนส่งเป็นชิ้นส่วน (chunked transfer encoding) เพื่อทำให้เนื้อหาบนการเชื่อมต่อแบบคงอยู่ส่งถ่ายเป็นกระแสข้อมูลได้ (streaming) แทนที่จะเก็บลงในที่พักข้อมูล (buffer) การทำงานแบบสายท่อของเอชทีทีพี (HTTP pipelining) ก็เป็นอีกเทคนิคหนึ่งที่ช่วยลดความล่าช้าลงได้อย่างมาก ซึ่งทำให้เครื่องลูกข่ายสามารถส่งข้อความร้องขอได้หลายข้อความ ก่อนที่จะได้รับข้อความตอบรับของอันแรก อีกพัฒนาการหนึ่งคือการบริการเป็นไบต์ (byte serving) ซึ่งจะทำให้เครื่องแม่ข่ายส่งถ่ายข้อมูลมาเพียงแค่ส่วนหนึ่งจากทรัพยากรทั้งอัน ในช่วงตำแหน่งที่เครื่องลูกข่ายต้องการ

สถานะวาระของเอชทีทีพี

เอชทีทีพีเป็นโพรโทคอลที่ไม่มีการระบุสถานะ ข้อดีของโพรโทคอลแบบนี้คือเครื่องแม่ข่ายไม่จำเป็นต้องดึงสารสนเทศอื่นมาจากผู้ใช้ในระหว่างการร้องขอ แต่สิ่งนี้ทำให้ผู้พัฒนาเว็บต้องใช้วิธีการอื่นเพื่อรักษาสถานะของผู้ใช้ ตัวอย่างเช่น ผู้ใช้ที่ต้องการปรับแต่งเนื้อหาเว็บไซต์ เว็บแอปพลิเคชันจะต้องบันทึกติดตามกระบวนการต่าง ๆ ของผู้ใช้เป็นหน้าต่อหน้า หรือการล็อกอินเข้าสู่ระบบ ซึ่งจำเป็นต้องทราบว่าผู้ใช้นั้นอยู่ในสถานะล็อกอินหรือไม่ จึงจะส่งข้อความตอบรับได้อย่างเหมาะสม วิธีการที่เป็นปกติสำหรับปัญหานี้คือการรับและส่งคุกกี้ และวิธีการอื่นคื่อการสร้างตัวแปรวาระ (session) ทางฝั่งเครื่องแม่ข่าย หรือใช้ตัวแปรซ่อนผ่านทางหน้าแบบฟอร์ม หรือใช้พารามิเตอร์ที่เข้ารหัสแบบตัวชี้แหล่งในอินเทอร์เน็ต (เช่น /index.php?session_id=some_unique_session_code)

อ้างอิง

↑ "ศัพท์บัญญัติ ราชบัณฑิตยสถาน". คลังข้อมูลเก่าเก็บจากแหล่งเดิมเมื่อ 2017-07-15. สืบค้นเมื่อ 2009-05-09.
↑ http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-05.txt
↑ ^3.0 ^3.1 "Apache Week. HTTP/1.1". 090502 apacheweek.com
↑ HTTP 1.1 Section 5.1.1
↑ "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. สืบค้นเมื่อ 2007-05-10.
↑ 6.1 Status-Line

แหล่งข้อมูลอื่น

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

[1] "ศัพท์บัญญัติ ราชบัณฑิตยสถาน". คลังข้อมูลเก่าเก็บจากแหล่งเดิมเมื่อ 2017-07-15. สืบค้นเมื่อ 2009-05-09.

[2] ttps://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-05.txt

[apacheweek_com-http11-3] 3.0 ^3.1 "Apache Week. HTTP/1.1". 090502 apacheweek.com

[4] HTTP 1.1 Section 5.1.1

[5] "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. สืบค้นเมื่อ 2007-05-10.

[6] 6.1 Status-Line

[1]

[2]

[3]

[4]

[5]

[6]