สวัสดีผู้อ่านบล็อกไซต์ที่รัก เมื่อศึกษากลไกที่รับผิดชอบการทำงานที่ถูกต้องของอินเทอร์เน็ต ไม่มีทางหนีจากความจำเป็นในการอุทิศเวลาให้กับประเด็นหลักซึ่งไม่ต้องสงสัยเลยว่ารวมถึงโปรโตคอลการถ่ายโอนข้อมูล HTTP และ HTTPS เวอร์ชันที่ปลอดภัย
พื้นฐานสำหรับการทำงานของเครื่องมือนี้ซึ่งช่วยให้เบราว์เซอร์ของผู้ใช้เปิดไฟล์และเอกสารที่จำเป็นเพื่อรับข้อมูลคือเทคโนโลยี "ไคลเอนต์ - เซิร์ฟเวอร์" ซึ่งจะกล่าวถึงรายละเอียดในบทความนี้ด้านล่าง
แน่นอนว่าผู้ที่ต้องการอุทิศกิจกรรมให้กับการทำงานกับเครือข่ายคอมพิวเตอร์และการพัฒนาโปรแกรมเครือข่ายอย่างแท้จริง จำเป็นต้องศึกษาประเด็นนี้ให้มากที่สุดเพื่อให้ได้คุณสมบัติที่เหมาะสม แต่เราไม่ต้องการสิ่งนี้
สิ่งสำคัญคือการเข้าใจว่า HTTP คืออะไรในแง่ทั่วไปและคุณสมบัติหลักของ HTTPS คืออะไรรวมทั้งเข้าใจหลักการพื้นฐานที่ฝังอยู่ในนั้น ความรู้ดังกล่าวจะเป็นประโยชน์เหนือสิ่งอื่นใดในการเพิ่มประสิทธิภาพและโปรโมตเว็บไซต์ของคุณ คุณจะได้รับการยืนยันอย่างไม่มีเงื่อนไขเกี่ยวกับสิ่งนี้จากบทความนี้และบทความต่อ ๆ ไปในหัวข้อนี้
HTTP คืออะไรและทำงานอย่างไร
ในการรับเอกสารที่ต้องการบนอินเทอร์เน็ต ผู้ใช้เพียงแค่ต้องป้อน URL ที่ต้องการลงในแถบค้นหาของเบราว์เซอร์ (เพิ่มเติมเกี่ยวกับโครงสร้าง URL) ซึ่งมีเพียงชื่อของโปรโตคอล HTTP (หรือ HTTPS)
3. HTTP/เวอร์ชัน— ระบุการแก้ไขโปรโตคอลในปัจจุบัน ในขณะนี้เป็น HTTP 1.1 (คุณสามารถอ่านข้อกำหนดได้) อย่างไรก็ตาม เวอร์ชันถัดไปของโปรโตคอล 2.0 ซึ่งใช้ .
บรรทัดล่างแสดงถึง ส่วนหัวของโฮสต์เป็นส่วนหนึ่งของคำขอ HTTP ที่เบราว์เซอร์ส่งไปยังเซิร์ฟเวอร์ตาม IP ที่ได้รับจาก DNS มีไว้เพื่ออะไร? เพื่อระบุไซต์ที่ต้องการ เนื่องจากเว็บเซิร์ฟเวอร์มักจะโฮสต์ทรัพยากรมากกว่าหนึ่งรายการ
เรามาดูตัวอย่างที่ชัดเจนเพื่อเสริมสิ่งที่เราได้เรียนรู้มา สมมติว่าเบราว์เซอร์ได้รับ "งาน" จากผู้ใช้ให้แสดงเพจที่มีที่อยู่ต่อไปนี้:
http://subscribe.ru/group/
จากนั้นคำขอ HTTP โดยใช้วิธี GET สามารถประกอบได้ดังนี้ (ในกรณีนี้โดยปกติจะไม่มีเนื้อหาข้อความ):
รับ /group/ HTTP/1.1 โฮสต์: Subscribe.ru
เพื่อความชัดเจน ฉันได้ยกตัวอย่างง่ายๆ ไว้เท่านั้น รวมถึงส่วนหัวของ Host หนึ่งอัน อันที่จริงอาจมีหลายรายการก็ได้ แต่นั่นไม่ใช่ทั้งหมด ท้ายที่สุดแล้ว การสื่อสารเต็มรูปแบบจำเป็นต้องมีบทสนทนา ซึ่งเกิดขึ้นหลังจากที่เซิร์ฟเวอร์ตอบสนองต่อคำขอของเบราว์เซอร์ บรรทัดเริ่มต้นของการตอบกลับสามารถแสดงเป็นแผนผังได้:
คำอธิบายรหัสสถานะ HTTP/เวอร์ชัน
ตอนนี้เรามาดูองค์ประกอบของการตอบกลับของเซิร์ฟเวอร์โดยย่อ:
1. เวอร์ชัน HTTPระบุโดยการเปรียบเทียบกับคำขอ
2. รหัสสถานะ(รหัสสถานะ) - ตัวเลขสามตัวที่แจ้งเกี่ยวกับสถานะของเอกสารที่เบราว์เซอร์ร้องขอ ตัวอย่างเช่น 200 - ตกลง มีหน้าเว็บอยู่และจะแสดงในเบราว์เซอร์ 301 - มีการเปลี่ยนเส้นทางไปยัง URL อื่น - ไม่มีหน้าเว็บตามที่อยู่นั้น (บางทีอาจถูกลบไปแล้วหรือผู้ใช้ทำผิดพลาด เมื่อป้อน URL)
3. คำอธิบาย(วลีเหตุผล) - ข้อความเพิ่มเติมของโค้ดตอบกลับ ในบางกรณีคำอธิบายอาจแตกต่างไปจากมาตรฐานหรือขาดหายไปโดยสิ้นเชิง นี่เป็นเพราะการกำหนดค่าของซอฟต์แวร์ที่โฮสต์บนเซิร์ฟเวอร์ด้วย
ตัวอย่างจริง? โปรด. ลองรับการตอบสนองของเซิร์ฟเวอร์ต่อคำขอที่ฉันให้ไว้เป็นตัวอย่างด้านบน (url “http://subscribe.ru/group/”) มันจะมีลักษณะเช่นนี้ (บรรทัดส่วนหัวเริ่มต้น):
HTTP/1.1 200 ตกลง เซิร์ฟเวอร์: nginx วันที่: เสาร์ 10 มิ.ย. 2560 06:36:38 GMT ประเภทเนื้อหา: text/html; charset=utf-8 การเชื่อมต่อ: Keep-alive เนื้อหา-ภาษา: ru Set-Cookie: สมัครสมาชิก::Viziter=UQkivlk7k3YO3DgjAxM2Ag==; หมดอายุ=พฤหัสบดี 31-ธ.ค.-37 23:55:55 GMT; โดเมน=subscribe.ru; path=/ P3P: Policyref="/w3c/p3p.xml", CP="NOI PSA รถบัสของเรา UNI"
ในกรณีนี้ ไม่มีคำอธิบายและเนื้อหาข้อความ ซึ่งเมื่อใช้วิธี GET อาจมี เช่น รหัส HTML ของเอกสารที่ร้องขอ (หน้าเว็บ) ส่วนเหล่านี้อาจมีอยู่ ขึ้นอยู่กับประเภทของแอปพลิเคชันไคลเอนต์
เอาล่ะ เรามาสรุปสั้นๆ ข้างต้นกันดีกว่า หากผู้ใช้ป้อน URL ของหน้าที่ค้นหาโดยตั้งใจที่จะดึงเนื้อหาเพื่อดู เบราว์เซอร์จะส่งคำขอ GET ไปยังเซิร์ฟเวอร์ที่ต้องการและได้รับการตอบกลับ จากผลของการสื่อสารนี้ (ภายใต้สถานการณ์ที่เอื้ออำนวย) เนื้อหาของเอกสารที่ร้องขอจะถูกแสดงหรือไม่ก็จะไม่ปรากฏ
ไม่ว่าในกรณีใด เนื้อหาของการตอบสนอง HTTP ของเซิร์ฟเวอร์ (รวมถึงรหัสสถานะ) สามารถให้ข้อมูลที่เป็นประโยชน์ที่เกี่ยวข้องกับเอกสารที่ร้องขอได้
เพื่อให้ข้อมูลข้างต้นเข้ากับปริศนาได้อย่างง่ายดาย จึงขาดตัวอย่างที่เฉพาะเจาะจงไป เราจะดูโดยใช้หนึ่งใน (เว็บเบราว์เซอร์นี้เป็นเครื่องมือทำงานของฉัน) ที่เรียกว่า HTTP Headers
สะดวกเพราะให้ภาพที่สมบูรณ์ของการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์โดยให้เนื้อหาใน "ขวดเดียว" คำขอ HTTP (คำขอ) และการตอบกลับ (ตอบกลับ)- ดูเอกสารที่ปลั๊กอินนี้สร้างขึ้นเมื่อติดตามลิงก์จากหน้าหนึ่งของบล็อกของฉันไปยังอีกหน้าหนึ่ง:
ที่ด้านบนสุดคือวิธีการ GET ซึ่งเบราว์เซอร์เข้าถึงเซิร์ฟเวอร์ตลอดจนสถานะของเพจที่มีรหัสสถานะ 200 OK ซึ่งทำให้ชัดเจนว่าเซิร์ฟเวอร์ได้ส่งข้อมูลทั้งหมดที่เกี่ยวข้องกับการร้องขอ หน้าเว็บ
ที่น่าสนใจอีกด้วย ส่วนหัว HTTPดังที่แสดงด้านล่าง ตัวอย่างเช่น รายการ "ผู้อ้างอิง"ให้ข้อมูลในรูปแบบของ URL ที่ทำการเปลี่ยนแปลง
หัวเรื่อง “ตัวแทนผู้ใช้”สะท้อนถึงแอปพลิเคชันไคลเอนต์ที่ส่งคำขอไปยังเว็บเซิร์ฟเวอร์อย่างแน่นอน ในกรณีนี้ นี่คือเบราว์เซอร์ แต่อาจมีเบราว์เซอร์อื่นๆ อีก (อุปกรณ์เคลื่อนที่ โรบ็อตการค้นหา ฯลฯ) ข้อมูลที่แสดงใน User Agent จำเป็นสำหรับซอฟต์แวร์เซิร์ฟเวอร์ในการระบุแอปพลิเคชันที่ส่งคำขอ
แค่ บอทเครื่องมือค้นหาซึ่งสแกนหน้าเว็บไซต์เพื่อรับข้อมูลที่มีอิทธิพลต่อการจัดอันดับถือเป็นความสนใจหลักสำหรับเรา เนื่องจากเป็นผู้ตัดสินชะตากรรมของหน้าใดหน้าหนึ่งในแง่ของประสิทธิภาพของการโปรโมต
นั่นเป็นเหตุผลที่ในสิ่งพิมพ์ครั้งต่อไป ฉันวางแผนที่จะกล่าวถึงรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการดูส่วนหัว HTTP และตรวจสอบรหัสตอบกลับของเซิร์ฟเวอร์โดยเฉพาะสำหรับคำขอโรบ็อต ซึ่งเป็นสิ่งสำคัญอย่างยิ่งสำหรับผู้ดูแลเว็บในแง่ของการเพิ่มประสิทธิภาพทรัพยากร SEO ดังนั้นสมัครสมาชิกเพื่อรับบทความล่าสุดได้ทันเวลา
มีอะไรพิเศษเกี่ยวกับโปรโตคอล HTTPS ที่ปลอดภัย?
ฉันแน่ใจว่าผู้ใช้อินเทอร์เน็ตทุกคน โดยไม่มีข้อยกเว้น รวมถึงผู้เริ่มต้น ตระหนักถึงการมีอยู่ของโปรโตคอลพิเศษที่เรียกว่า HTTPS (Hypertext Transfer Protocol Secure) ซึ่งทำหน้าที่ปกป้องข้อมูลส่วนบุคคลในบริการที่ใช้การถ่ายโอน (ระบบการชำระเงิน ออนไลน์ ร้านค้า พอร์ทัลเฉพาะขนาดใหญ่ ฯลฯ)
หากคุณป้อนที่อยู่หน้าของไซต์ที่คล้ายกันการเชื่อมต่อนี้จะถูกระบุในลักษณะพิเศษ ตัวอย่างเช่นใน Google Chrome () แม่กุญแจที่มีข้อความว่า "เชื่อถือได้" เป็นสีเขียวจะปรากฏขึ้นเมื่อคุณคลิกคุณจะเห็นข้อมูลบางอย่างที่เกี่ยวข้องกับการปกป้องข้อมูลส่วนบุคคล:
HTTPS คืออะไรพูดอย่างเคร่งครัด มันไม่ใช่โปรโตคอลอิสระ นี่คือ HTTP มาตรฐานซึ่งทำงานผ่านกลไก ทลสหรือ เอสเอสแอลสามารถรับประกันการเข้ารหัสซึ่งป้องกันแฮกเกอร์จากการสกัดกั้นและรับข้อมูลที่เป็นความลับ
ตามค่าเริ่มต้น เมื่อใช้งานโปรโตคอลที่ปลอดภัย ระบบจะใช้พอร์ต 443 (หากคุณจำได้ สำหรับ HTTP มาตรฐานจะเป็น 80) การเข้ารหัส HTTPS ใช้ความยาวคีย์ 40, 56, 128 และ 256 บิต () อย่างไรก็ตาม ไม่ควรพิจารณาสองตัวเลือกแรกด้วยซ้ำ เนื่องจากไม่สามารถให้ระดับความปลอดภัยที่เพียงพอได้
เมื่อเร็ว ๆ นี้เครื่องมือค้นหาโดยเฉพาะ Google ได้ชักชวนเจ้าของเว็บไซต์ทั้งหมดให้เปลี่ยนไปใช้โปรโตคอลที่ปลอดภัยโดยบอกเป็นนัย ๆ ว่าประเด็นนี้จะถูกนำมาพิจารณาเมื่อทำการจัดอันดับ ด้วยเหตุนี้ ทรัพยากรจำนวนมาก (แม้แต่บล็อกทั่วไป) ในปัจจุบันจึงทำงานร่วมกับ HTTPS ได้แล้ว ไม่ใช่แค่ไซต์ที่เกี่ยวข้องกับการถ่ายโอนข้อมูลส่วนบุคคลอย่างใกล้ชิดเท่านั้น
นอกจากนี้ ผู้ให้บริการโฮสต์ชั้นนำยังเสนอการซื้อใบรับรอง SSL ที่ปลอดภัย ซึ่งจำเป็นต่อการเปิดใช้งานการเชื่อมต่อที่ปลอดภัย
แน่นอนว่าเราไม่ได้คำนึงถึงความแตกต่างทั้งหมดของการใช้โปรโตคอล HTTP (HTTPS) ซึ่งมีอยู่มากมาย หัวข้อนี้อาจต้องใช้คู่มือที่น่าประทับใจหลายฉบับ อย่างไรก็ตาม ครอบคลุมประเด็นหลักที่จะเป็นประโยชน์ต่อทั้งผู้ใช้ขั้นสูงและผู้ดูแลเว็บแล้ว หากคุณยังคงไม่พอใจกับจำนวนข้อมูลที่ได้รับ คุณสามารถเสริมได้อย่างง่ายดายจากวิดีโอบรรยายต่อไปนี้ ซึ่งโดยเฉพาะอย่างยิ่งจะพูดถึงรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการ:
สวัสดีผู้อ่านเว็บไซต์บล็อก! มาทำความคุ้นเคยกับโปรโตคอล HTTP ต่อไปในส่วน เซิร์ฟเวอร์และโปรโตคอล และส่วน โปรโตคอล HTTP รายการนี้เป็นรายการสุดท้ายในชุดบันทึกย่อเกี่ยวกับโปรโตคอล HTTP หลังจากนั้นฉันจะเตรียมการนำทางและบางทีอาจมีบางรายการที่เกี่ยวข้องกับโปรโตคอล HTTP แต่ไม่เกี่ยวข้องโดยตรงกับมัน โดยพื้นฐานแล้ว โพสต์นี้จะช่วยให้คุณเข้าใจวิธีการทำงาน โปรโตคอล HTTPและหากคุณต้องการรายละเอียด ให้ไปตามลิงก์ที่ฉันวางไว้ตลอดทั้งบทความสำหรับคุณ
โปรโตคอล HTTP คืออะไร?
มากำหนดกันว่ามันคืออะไร โปรโตคอล HTTPแต่ก่อนที่เราจะนิยามคำว่า HTTP protocol มาทำความเข้าใจคำว่า protocol กันก่อน โปรโตคอลคำแปลตามตัวอักษรจากภาษากรีกเป็นคำแรกและกาว ในสมัยโบราณมันเป็นกระดาษแผ่นหนึ่งที่ติดอยู่กับม้วนหนังสือและผู้เขียนเขียนชื่อของเขาวันที่เขียนและข้อมูลอื่น ๆ ที่ไม่จำเป็นหรือเป็นข้อมูลที่เป็นทางการ ทำไมฉันถึงพูดสิ่งที่ไม่จำเป็น? ใช่ เพราะคนทั่วไปสนใจเนื้อหาในม้วนหนังสือมากกว่า ไม่ใช่สนใจว่าใครเป็นคนเขียน ดังนั้นเข้า โปรโตคอล HTTP: ผู้ใช้โดยเฉลี่ยไม่สนใจวิธีที่เขารับหน้าเว็บไซต์เลย เขาเพียงแค่เปิดเบราว์เซอร์เท่านั้น คำจำกัดความของคำว่าโปรโตคอลก็คืออัลกอริทึมหรือลำดับของการกระทำ โปรโตคอลคือชุดของกฎและข้อบังคับที่ควบคุมเหตุการณ์เฉพาะ โปรโตคอลการถ่ายโอนข้อมูลเป็นมาตรฐานที่อธิบายกฎสำหรับการโต้ตอบระหว่างบล็อกการทำงานเมื่อถ่ายโอนข้อมูล
ดังนั้นเราจึงตัดสินใจแล้วว่า HTTP เป็นโปรโตคอลการถ่ายโอนข้อมูล แต่ HTTP ย่อมาจากอะไร? HTTP หรือ HyperText Transfer Protocolเป็นโปรโตคอลการถ่ายโอนไฮเปอร์เท็กซ์ และตอนนี้ฉันจะให้คำจำกัดความที่น่าสนใจที่สุดของโปรโตคอล HTTP ที่ฉันเคยเจอมา
โปรโตคอล HTTP- นี่คือกฎจราจรบนอินเทอร์เน็ตเฉพาะในกรณีที่ผู้คนในชีวิตอาจไม่ปฏิบัติตามกฎจราจรและจะไม่มีอะไรเกิดขึ้นกับพวกเขาจากนั้นการไม่ปฏิบัติตามกฎของโปรโตคอล HTTP จะนำไปสู่ความจริงที่ว่า ผู้ใช้จะไม่สามารถทำงานบนอินเทอร์เน็ตได้
โปรโตคอล HTTP เป็นโปรโตคอลการถ่ายโอนข้อมูลของเลเยอร์ที่เจ็ดของโมเดล OSI ซึ่งทำงานบนพื้นฐานของเทคโนโลยีไคลเอ็นต์-เซิร์ฟเวอร์
โปรโตคอล HTTP เป็นนามธรรมเหนือระดับที่สามและสี่ของโมเดลอ้างอิง ซึ่งขยายความเป็นไปได้ในการสื่อสารระหว่างผู้คน
โปรโตคอล HTTP- โปรโตคอลการส่งไฮเปอร์เท็กซ์แบบง่าย ๆ ในตอนแรกซึ่งตอนนี้สามารถใช้เพื่อส่งอะไรก็ได้
โปรโตคอล HTTP เป็นการส่งข้อมูลสำหรับโปรโตคอลอื่นๆ เช่น JSON
โปรโตคอล HTTP เป็นเทคโนโลยีที่นักพัฒนาเว็บควรเข้าใจ
ฉันคิดว่าเราเข้าใจแล้วว่ามันคืออะไร โปรโตคอล HTTPและตอนนี้เราสามารถดูว่ามันถูกใช้ที่ไหน
โปรโตคอล HTTP ใช้ทำอะไร?
ฉันจะบอกคุณตามตรง โปรโตคอล HTTP- นี่คือพื้นฐานของอินเทอร์เน็ต หรือค่อนข้างไม่ใช่ นี่คือพื้นฐานที่ผู้บริโภคปลายทางเห็น: ผู้เยี่ยมชมเว็บไซต์ ดังนั้นโปรโตคอล HTTP จึงมีอยู่ทุกหนทุกแห่งบนอินเทอร์เน็ต วลีนี้ฟังดูแปลก แต่ฉันก็นึกคำอื่นไม่ออก เมื่ออ่านข่าวบนเว็บไซต์ คุณใช้โปรโตคอล HTTP เมื่อฟังเพลง VKontakte คุณใช้โปรโตคอล HTTP เมื่อคุณดูวิดีโอบน YouTube คุณกำลังใช้โปรโตคอล HTTP เมื่อคุณเล่นเกมเบราว์เซอร์ คุณจะใช้โปรโตคอล HTTP ด้วย นั่นเป็นเหตุผลที่ฉันเขียนว่ามีการใช้โปรโตคอล HTTP ทุกที่บนอินเทอร์เน็ต หากไม่มีมัน คุณจะไม่สามารถอ่านข้อความนี้ได้ โดยสรุป: โปรโตคอล HTTP ใช้เพื่อถ่ายโอนข้อมูลบนอินเทอร์เน็ต ในตอนแรกใช้เพื่อถ่ายโอนเอกสาร HTML แต่ตอนนี้อนุญาตให้คุณถ่ายโอนเนื้อหาต่าง ๆ และ .
ลักษณะของโปรโตคอล HTTP
เรามาแสดงรายการทางเทคนิคกัน ลักษณะโปรโตคอล HTTP:
- โปรโตคอล HTTPทำงานโดยใช้เทคโนโลยี
- โปรโตคอล HTTP เป็นของระดับที่เจ็ด
- โปรโตคอล HTTP เป็นของตระกูลโปรโตคอล TCP/IP
- ในการส่งข้อมูลผ่านโปรโตคอล HTTP จะใช้พอร์ต 80 TCP หรือ 8080
- ข้อกำหนดโปรโตคอล RFC 2616
- ในการระบุทรัพยากร โปรโตคอล HTTP จะใช้ URI (อ่านรายละเอียด)
- โปรโตคอล HTTP ไม่มีสถานะกลางระหว่างคำขอและการตอบกลับ แน่นอนว่าไคลเอ็นต์สามารถรับการตอบกลับด้วยรหัส 100 ได้ แต่นี่เป็นการตอบกลับแล้ว และไม่ใช่สถานะระดับกลาง
- โปรโตคอล HTTPซิงโครนัส แต่อนุญาตให้ไคลเอ็นต์ส่งคำขอหลายรายการติดต่อกันโดยไม่ต้องรอการตอบกลับจากเซิร์ฟเวอร์ โดยมีเงื่อนไขว่าเซิร์ฟเวอร์จะตอบสนองต่อคำขอตามลำดับที่มาถึง
นี่เป็นเพียงส่วนหนึ่งของคุณลักษณะทางเทคนิคของโปรโตคอล แต่ในความคิดของฉัน คุณลักษณะที่สำคัญที่สุดในการทำความเข้าใจสาระสำคัญของโปรโตคอล
โปรโตคอล HTTP ทำงานบนหลักการไคลเอ็นต์-เซิร์ฟเวอร์
ใช่, โปรโตคอล HTTPทำงานบนหลักการไคลเอ็นต์-เซิร์ฟเวอร์ ตัวอย่างที่ง่ายที่สุดที่อยู่ในใจของฉันตอนนี้เพื่ออธิบายสาระสำคัญของการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์คือตัวอย่างของผู้ซื้อและผู้ขายในร้านค้า ผู้ซื้อมาที่ร้านแล้วพูดกับผู้ขาย: สวัสดี! ถ้าผู้ขายหยาบคายก็ตอบ: ทาสีรั้ว! จากนั้นผู้ซื้อก็ยิ้ม ยืนดูหน้าต่างแสดงผล แล้วเลือกว่าจะซื้ออะไร ในขณะเดียวกันผู้ขายก็ยืนรอให้ลูกค้าเลือกอย่างเงียบๆ ลูกค้าได้เลือกแล้วบอกกับผู้ขายว่า: เอาไอ้บ้าสีน้ำตาลนั่นที่ชั้นบนสุดตรงมุมไกลๆ มาให้ฉันหน่อย ผู้ขายพูดว่า: ตอนนี้. หลังจากนั้นเขาก็หยิบเก้าอี้มาวางไว้ที่มุมไกล ๆ หยิบอึสีน้ำตาลออกจากชั้นวางแล้วนำไปให้ผู้ซื้อ ผู้ซื้อรับของไร้สาระสีน้ำตาลให้เงินและใบไม้ และผู้ขายเมื่อได้รับเงินแล้วจึงนำไปใส่ในเครื่องบันทึกเงินสด
ประเด็นของเรื่องราวนี้คือเพื่อแสดงปฏิสัมพันธ์ระหว่างไคลเอนต์และเซิร์ฟเวอร์ (ในกรณีนี้ผู้ซื้อ) ควบคุมการพัฒนากิจกรรมอย่างสมบูรณ์นั่นคือ (ในตัวอย่างของเราผู้ขาย) ไม่ว่าในกรณีใดจะสร้างการติดต่อกับตัวเอง เขาอดทนรอการกระทำของลูกค้าและตอบสนองต่อการกระทำเหล่านั้นด้วยวิธีใดวิธีหนึ่ง ฉันยกตัวอย่างที่ง่ายที่สุด แต่มันอาจซับซ้อนได้เช่นผู้ซื้อให้หนึ่งร้อยรูเบิลและอึสีน้ำตาลมีราคา 90 ในกรณีนี้ผู้ขายจะมอบเงินทอนให้กับลูกค้า ผู้ขายอาจตอบสนองต่อคำพูดของลูกค้า: สวัสดี! ด้วยวิธีอื่น หรือของสีน้ำตาลอาจจะไม่มีขายหรือขายแต่เฉพาะลูกค้าคนพิเศษเท่านั้น สิ่งที่ฉันหมายถึงคือสิ่งนี้ โปรโตคอล HTTPเป็นโปรโตคอลการถ่ายโอนข้อมูลตามการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์ และโดยหลักการแล้ว มันค่อนข้างอธิบายอัลกอริธึมการดำเนินการสำหรับทั้งไคลเอนต์และเซิร์ฟเวอร์ในสถานการณ์ต่าง ๆ ค่อนข้างครบถ้วน
ประวัติ HTTP: มาตรฐานโปรโตคอล HTTP
ตอนนี้เรามาดูเรื่องราวกัน โปรโตคอล HTTPตามมาตรฐานของเขา
- – เวอร์ชันของโปรโตคอล HTTP9 ได้รับการพัฒนาในปี 1991 ที่ CERN โดย Tim Berners-Lee Tim พัฒนาโปรโตคอล HTTP เพื่ออำนวยความสะดวกในการเข้าถึงและการนำทางโดยใช้ไฮเปอร์เท็กซ์ มาตรฐาน HTTP/0.9 ประกอบด้วยไวยากรณ์พื้นฐานและความหมายของโปรโตคอล HTTP
- ในปี 1996 RFC 1945 (มาตรฐาน HTTP/1.0) ได้รับการเผยแพร่
- ในปี 1997 เวอร์ชันของโปรโตคอล HTTP1 ได้รับการเผยแพร่: มาตรฐาน HTTP/1.1 ได้รับการพัฒนาและอธิบายไว้ใน RFC 2068 ในปี 1999 มาตรฐาน HTTP/1.1 ได้รับการสรุป (กล่าวคือ มาตรฐาน HTTP/1.1) ปัจจุบันแอปพลิเคชั่นส่วนใหญ่ใช้งาน โปรโตคอล HTTPเวอร์ชัน 1.1 โดยวิธีการส่งข้อมูลเกี่ยวกับตัวคุณเองในส่วนหัว
- ในปี 2558 เวอร์ชันสุดท้ายของโปรโตคอล HTTP 2 ได้รับการเผยแพร่ นี่ยังไม่ใช่มาตรฐาน แต่แบบร่าง "แสดง" ให้เราเห็นว่าการพัฒนาอินเทอร์เน็ตจะเคลื่อนไปในทิศทางใด
ไคลเอ็นต์โปรโตคอล HTTP
ตัวอย่างที่พบบ่อยที่สุดของไคลเอนต์โปรโตคอล HTTP คือเบราว์เซอร์ ต่อไปนี้คือไคลเอนต์โปรโตคอล HTTP ที่ได้รับความนิยมมากที่สุด:
- กูเกิลโครม;
- มอซซิลา ไฟร์ฟ็อกซ์;
- โอเปร่า;
- อินเทอร์เน็ตเอ็กซ์พลอเรอร์;
- เบราว์เซอร์ยานเดกซ์;
- ซาฟารี
บ่อยครั้ง แทนที่จะเป็นคำว่า ลูกค้า คุณอาจได้ยินตัวแทนผู้ใช้ โปรดทราบว่า โปรโตคอล HTTPไม่มีความแตกต่างระหว่างเงื่อนไขไคลเอนต์และตัวแทนผู้ใช้
เซิร์ฟเวอร์โปรโตคอล HTTP
บรรทัดสถานะถูกแยกออกจากส่วนหัวด้วยอักขระ CRLF ที่ท้ายบรรทัดนี้จากส่วนหัว HTTP (คุณสามารถรับอักขระนี้ใน Windows ได้โดยการกดปุ่ม Enter - ตัวแบ่งบรรทัด) และส่วนหัว HTTP จะถูกแยกออกจากข้อความ body ตามบรรทัดที่มีอักขระเพียงตัวเดียว - CRLF
คำขอและการตอบกลับมีส่วนหัวบริการทั่วไปที่สามารถใช้ได้ทั้งในคำขอและการตอบกลับจากเซิร์ฟเวอร์ HTTP ฉันยังต้องการทราบด้วยว่ามีกลุ่มส่วนหัวที่เกี่ยวข้องกับวัตถุ (เนื้อหาข้อความ) ซึ่งทั้งหมดสามารถใช้ได้ทั้งในคำขอและในการตอบกลับ ยกเว้นฟิลด์ Allow header ซึ่งใช้เฉพาะในการตอบกลับของเซิร์ฟเวอร์เมื่อโต้ตอบ ผ่านโปรโตคอล HTTP ข้อความ HTTP มีความยาวซึ่งวัดเป็นไบต์ หากข้อความ HTTP ของคุณมีเนื้อหา กฎต่อไปนี้จะนำไปใช้เพื่อกำหนดความยาวของข้อความ:
- ข้อความตอบกลับของเซิร์ฟเวอร์ HTTP ใดๆ ซึ่งต้องไม่มีเนื้อหาข้อความ จะต้องสิ้นสุดด้วยบรรทัดว่างหลังส่วนหัวเสมอ
- หากส่วนหัวของข้อความ HTTP มีฟิลด์ Transfer-Encoding (การเข้ารหัส HTTP) และฟิลด์นี้มีค่าเป็นก้อน ดังนั้นความยาวของข้อความ HTTP ควรถูกกำหนดโดยใช้วิธีการเข้ารหัสแบบก้อน
- หากส่วนหัวของข้อความ HTTP มีฟิลด์ Content-Length ค่าที่เขียนใน Content-Length จะเป็นความยาวของข้อความ HTTP ซึ่งวัดเป็นไบต์
- หากข้อความ HTTP ใช้ประเภทสื่อ "หลายส่วน/ช่วงไบต์" ซึ่งถูกคั่นด้วยตัวมันเอง ข้อความนั้นจะกำหนดความยาว
- ความยาวของข้อความ HTTP ถูกกำหนดโดยการปิดการเชื่อมต่อทางฝั่งเซิร์ฟเวอร์
เพื่อความชัดเจน ลองดูข้อความตัวอย่างในโปรโตคอล HTTP และสิ่งแรกที่เราจะดูคือคำขอตัวอย่างในโปรโตคอล HTTP:
POST /cgi-bin/process.cgi HTTP/1.1 ตัวแทนผู้ใช้: Mozilla/4.0 (เข้ากันได้; MSIE5.01; Windows NT) โฮสต์: www.example.com ประเภทเนื้อหา: application/x-www-form-urlencoded เนื้อหา - ความยาว: ความยาว ยอมรับภาษา: ru-ru ยอมรับ - เข้ารหัส: gzip, ยุบการเชื่อมต่อ: Keep-Alive LicenseID=string&content=string&/paramsXML=string
POST /cgi-bin/กระบวนการ ซีจีไอ HTTP/1.1 ตัวแทนผู้ใช้: Mozilla/4.0 (เข้ากันได้; MSIE5.01; Windows NT) พิธีกร: www. ตัวอย่าง. ดอทคอม เนื้อหา - ประเภท : application / x - www - form - urlencoded เนื้อหา - ความยาว : ความยาว ยอมรับ - ภาษา : ru - ru ยอมรับ - การเข้ารหัส : gzip , ยุบ การเชื่อมต่อ: Keep - Alive LicenseID=string&content=string&/paramsXML=string |
| ตัวเลข | รหัสสถานะคลาสในHTTP โปรโตคอลและคำอธิบาย |
| 1 | HTTP รหัสสถานะ 1xx: ข้อมูลเซิร์ฟเวอร์จะส่งรหัสสถานะนี้เมื่อได้รับคำขอแต่ยังไม่ได้ดำเนินการ |
| 2 | HTTP รหัสสถานะ 2xx: ประสบความสำเร็จเซิร์ฟเวอร์จะส่งรหัสนี้ให้คุณเมื่อได้รับและประมวลผลข้อความ HTTP ของลูกค้าเรียบร้อยแล้ว |
| 3 | HTTP รหัสสถานะ 3xx: เปลี่ยนเส้นทางหากคุณได้รับรหัสสถานะที่ขึ้นต้นด้วยสามจากเซิร์ฟเวอร์ หมายความว่าจำเป็นต้องมีขั้นตอนเพิ่มเติมเพื่อดำเนินกระบวนการประมวลผลคำขอ HTTP ให้เสร็จสิ้น |
| 4 | HTTP รหัสสถานะ 4xx: ข้อผิดพลาดของลูกค้าหากคุณเห็นรหัสสถานะที่ขึ้นต้นด้วยสี่ แสดงว่าเกิดข้อผิดพลาดเนื่องจากความผิดของลูกค้า |
| 5 | HTTP รหัสสถานะ 5xx: ข้อผิดพลาดของเซิร์ฟเวอร์รหัสสถานะที่ขึ้นต้นด้วยห้าบ่งชี้ว่ามีข้อผิดพลาดเกิดขึ้นที่ฝั่งเซิร์ฟเวอร์ |
ฟิลด์ส่วนหัวข้อความ HTTP
ใน โปรโตคอล HTTPมีฟิลด์ส่วนหัวที่ให้คุณกำหนดค่าการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์ รวมถึงวิธีการและรูปแบบที่ผู้ใช้จะได้รับข้อมูลที่เป็นประโยชน์ ไวยากรณ์ทั่วไปสำหรับฟิลด์ส่วนหัวนั้นค่อนข้างง่าย: ชื่อฟิลด์: value1, value2
ฟิลด์ส่วนหัวจะถูกคั่นด้วยอักขระ CRLF โปรโตคอล HTTPแบ่งฟิลด์ส่วนหัวออกเป็นสี่กลุ่ม:
- ฟิลด์ส่วนหัวทั่วไป ส่วนหัวดังกล่าวสามารถใช้ได้กับข้อความใดๆ ที่ส่งผ่านโปรโตคอล HTTP
- ฟิลด์ส่วนหัวของคำขอ ข้อความเหล่านี้สามารถส่งได้ในคำขอโปรโตคอล HTTP เท่านั้น
- ฟิลด์ส่วนหัวการตอบกลับ ตามชื่อที่แสดง ฟิลด์เหล่านี้จะใช้ในการตอบกลับ HTTP เท่านั้น
- ช่องส่วนหัวของข้อความ และฟิลด์เหล่านี้จะถูกใช้เมื่อจำเป็นเพื่อพิจารณาว่าข้อมูลจะถูกนำเสนอต่อผู้ใช้อย่างไรและในรูปแบบใดซึ่งจะถูกส่งผ่าน HTTP
การแคชโปรโตคอล HTTP
เพื่อลดภาระของเครือข่ายและปรับปรุงประสิทธิภาพ โปรโตคอล HTTPมีการนำกลไกการแคชไปใช้ มันมักจะเกิดขึ้นที่ผู้ใช้ไม่รู้ด้วยซ้ำว่าหน้าที่เปิดในเบราว์เซอร์ของเขานั้นไม่ได้โหลดจากไซต์ที่เขาเข้าถึง แต่มาจากแคช เราจะไม่เจาะลึกกลไกการแคชภายในของเซิร์ฟเวอร์/ไคลเอนต์เฉพาะ แต่จะดูว่ามีอะไรให้ใช้งานโดยตรงบ้าง โปรโตคอล HTTPเพื่อจัดการแคช และอย่างที่คุณอาจเดาได้แล้วในโปรโตคอล HTTP การแคชจะถูกควบคุมโดยฟิลด์ส่วนหัวและคำสั่งนั่นคือค่าของฟิลด์เหล่านี้เอง
ฉันสังเกตว่า โปรโตคอล HTTPนำไปใช้เพื่อให้ผู้เข้าร่วมทุกคนในห่วงโซ่ระหว่างไคลเอนต์และเซิร์ฟเวอร์สุดท้ายต้องปฏิบัติตามคำสั่งเหล่านี้ คำสั่งแบบมีเงื่อนไขสามารถแบ่งออกเป็นไคลเอนต์และเซิร์ฟเวอร์ มาดูคำสั่งโปรโตคอล HTTP ที่ออกแบบมาเพื่อควบคุมการแคชฝั่งไคลเอ็นต์
| ตัวเลข | คำสั่งฟิลด์ส่วนหัวแคช— ควบคุมสำหรับลูกค้าและคำอธิบายของพวกเขา |
| 1 | เลขที่— แคชคำสั่ง no-cache ของโปรโตคอล HTTP จะบอกเซิร์ฟเวอร์ว่าสำหรับคำขอครั้งต่อไป ไม่ควรส่งการตอบสนองจากแคชโดยไม่ตรวจสอบเนื้อหาของเซิร์ฟเวอร์ต้นทาง |
| 2 | เลขที่— เก็บคำสั่ง HTTP no-store แจ้งเซิร์ฟเวอร์ว่าไม่ควรแคชคำขอของไคลเอ็นต์หรือการตอบสนองของเซิร์ฟเวอร์ นี่เป็นเหตุผลด้านความปลอดภัย |
| 3 | สูงสุด— อายุ = วินาทีคำสั่งโปรโตคอล HTTP อายุสูงสุดบอกเซิร์ฟเวอร์ว่าแคชไม่ควรเก่ากว่าเวลาที่ระบุในหน่วยวินาที |
| 4 | สูงสุด— เหม็นอับ [ = วินาที ] คำสั่งโปรโตคอล HTTP ที่เก่าที่สุดจะบอกเซิร์ฟเวอร์ว่าไคลเอนต์จะยอมรับการตอบสนอง HTTP ที่แคชไว้หากอายุไม่เกินเวลาที่ระบุในหน่วยวินาที |
| 5 | นาที— สด = วินาทีคำสั่งโปรโตคอล HTTP min-fresh บอกเซิร์ฟเวอร์ว่าไคลเอ็นต์จะยอมรับการตอบสนอง HTTP ที่แคชไว้ หากอายุการใช้งานแคชไม่เกินวินาทีที่ระบุ |
| 6 | คำสั่ง HTTP min-fresh จะบอกเซิร์ฟเวอร์ว่าไม่ควรนำการเปลี่ยนแปลงใดๆ ไปใช้กับทรัพยากรที่ร้องขอ |
| 7 | เท่านั้น—
ถ้า—
แคชไว้ คำสั่งโปรโตคอล HTTP ขั้นต่ำจะบอกเซิร์ฟเวอร์ว่าไคลเอ็นต์จะยอมรับเฉพาะการตอบสนอง HTTP ที่แคชไว้เท่านั้น หากการตอบสนองที่เหมาะสมไม่อยู่ในแคชของเซิร์ฟเวอร์ ก็ไม่จำเป็นต้องดำเนินการใดๆ |
ตอนนี้เรามาดูคำสั่งที่อนุญาต .
| ตัวเลข | คำสั่งฟิลด์ส่วนหัวแคช— ควบคุมสำหรับเซิร์ฟเวอร์และคำอธิบาย |
| 1 | สาธารณะคำสั่งโปรโตคอล HTTP Public ระบุว่าการตอบสนองของเซิร์ฟเวอร์สามารถจัดเก็บไว้ในแคชใดก็ได้ |
| 2 | ส่วนตัวคำสั่งโปรโตคอล HTTP ส่วนตัวบ่งชี้ว่าการตอบสนองของเซิร์ฟเวอร์ควรเก็บไว้ในแคชส่วนตัวซึ่งมีไว้สำหรับผู้ใช้รายนี้เท่านั้น |
| 3 | เลขที่— แคชคำสั่งโปรโตคอล HTTP เลขที่— แคชระบุว่าไม่ควรส่งการตอบกลับที่แคชไว้ไปยังไคลเอนต์โดยไม่ตรวจสอบก่อน |
| 4 | เลขที่— เก็บคำสั่งโปรโตคอล HTTP เลขที่— เก็บบ่งชี้ว่าการตอบสนองของเซิร์ฟเวอร์ไม่สามารถจัดเก็บไว้ในแคชได้ |
| 5 | เลขที่— แปลงร่างคำสั่งโปรโตคอล HTTP เลขที่— แปลงร่างบ่งชี้ว่าไม่ควรใช้การแปลงกับการตอบสนองของเซิร์ฟเวอร์โดยโหนดใด ๆ ในห่วงโซ่ |
| 6 | ต้อง— ตรวจสอบอีกครั้งคำสั่งโปรโตคอล HTTP ต้อง— ตรวจสอบอีกครั้งบอกว่าหากข้อความ HTTP ของเซิร์ฟเวอร์เก่า ควรใช้การตรวจสอบล่วงหน้ากับข้อความนั้น |
| 7 | พร็อกซี— ตรวจสอบอีกครั้งคำสั่งโปรโตคอล HTTP พร็อกซี— ตรวจสอบอีกครั้งพูดเหมือนกับคำสั่งก่อนหน้า แต่สำหรับเซิร์ฟเวอร์ระดับกลางเท่านั้น |
| 8 | สูงสุด— อายุ = วินาทีคำสั่งโปรโตคอล HTTP สูงสุด— อายุระบุระยะเวลาที่แคชอยู่บนเซิร์ฟเวอร์ |
| 9 | คำสั่งฟิลด์ส่วนหัวแคช— ควบคุมการตอบสนองของเซิร์ฟเวอร์:ส— สูงสุด = วินาทีคำสั่งการตอบสนองของเซิร์ฟเวอร์สาธารณะบอกว่าเหมือนกับคำสั่งอายุสูงสุด แต่สำหรับเซิร์ฟเวอร์ CDN |
ทั้งแอปพลิเคชัน HTTP ของไคลเอนต์และเซิร์ฟเวอร์จะต้องสามารถเปรียบเทียบข้อมูลจากแคชเพื่อไม่ให้ส่งการรับส่งข้อมูลที่ไม่จำเป็นผ่านเครือข่ายและในเวลาเดียวกันผู้ใช้จะได้รับข้อมูลล่าสุดตามคำขอของพวกเขา ด้วยเหตุนี้ใน โปรโตคอล HTTPมีการแนะนำฟิลด์ Last-Modified พิเศษและวิธีการร้องขอแบบมีเงื่อนไขพร้อมฟิลด์ส่วนหัวแบบมีเงื่อนไข ฟิลด์แก้ไขล่าสุดระบุวันที่และเวลาของการสร้างเวอร์ชันแคช สามารถเปรียบเทียบค่าของฟิลด์นี้กับค่าวันที่และเวลาของช่วงเวลาที่ทรัพยากรดั้งเดิมได้รับการอัปเดตครั้งล่าสุด และหากค่าตรงกัน จากนั้นข้อมูลจะมาถึงไคลเอนต์จากแคช
และหากลูกค้าส่งคำขอซ้ำไปยังทรัพยากรเดียวกันเบราว์เซอร์สามารถรวมฟิลด์ส่วนหัวแบบมีเงื่อนไขในข้อความของลูกค้าได้เซิร์ฟเวอร์เมื่อได้รับฟิลด์ดังกล่าวจะวิเคราะห์เนื้อหาของทรัพยากรเปรียบเทียบกับสิ่งที่ส่งไป ก่อนหน้านี้และหากการเปรียบเทียบเท่ากันเบราว์เซอร์ก็จะส่งคืนข้อความ 304 (ไม่ได้แก้ไข) หลังจากนั้นเบราว์เซอร์จะแยกเนื้อหาของหน้าออกจากแคชสำหรับผู้ใช้
และยัง โปรโตคอล HTTPช่วยให้คุณสามารถกำหนดแท็กให้กับวัตถุ HTTP แต่ละรายการในฟิลด์ส่วนหัวของ ETag อันที่จริงนี่คือผลรวมแฮชของวัตถุนั้นเอง และสำหรับแต่ละวัตถุที่ไม่ซ้ำนั้นจะไม่ซ้ำกัน ดังนั้นกลไกการแคชโปรโตคอล HTTP จึงใช้ฟิลด์นี้อย่างแข็งขันเพื่อ ตรวจสอบความเกี่ยวข้องของข้อมูลที่เก็บไว้ในแคช
ความปลอดภัยของโปรโตคอล HTTP
โปรโตคอล HTTPออกแบบมาเพื่อการถ่ายโอนข้อมูลและไม่มีตะปู ไม่มีกลไกหรือกลไกการเข้ารหัสในโปรโตคอล HTTP เนื่องจากกลไกการเข้ารหัสทุกประเภทของโปรโตคอล HTTP แทบจะไม่เรียกว่าการปกป้องข้อมูล แต่ส่งข้อมูลการเข้าสู่ระบบและรหัสผ่านของผู้ใช้ในรูปแบบที่ไม่ได้เข้ารหัส
แต่โปรโตคอล HTTP มีส่วนขยาย HTTPS โปรดทราบว่า HTTPS ไม่ใช่โปรโตคอล แต่เป็นส่วนขยายของโปรโตคอล HTTP ที่ใช้พอร์ต TCP 433 ส่วนขยายนี้เป็นการรวมกันของสองโปรโตคอล: HTTP และ SSL หรือ HTTP และ TLS (TLS และ SSL เป็นสิ่งเดียวกันเหมือนกัน)
อย่าลืมแบ่งปันความคิดเห็นของคุณในความคิดเห็นและแสดงความคิดเห็นซึ่งจะช่วยให้งานของเราดีขึ้นด้วยความเคารพ!
เราได้เปิดตัวหนังสือเล่มใหม่ การตลาดเนื้อหาโซเชียลมีเดีย: วิธีเข้าถึงหัวของผู้ติดตามของคุณ และทำให้พวกเขาตกหลุมรักแบรนด์ของคุณ
HTTP คือสิ่งที่อนุญาตให้ถ่ายโอนข้อมูล ในตอนแรกมันถูกสร้างขึ้นสำหรับการส่งและรับเอกสารที่มีลิงก์ภายในเพื่อทำการเปลี่ยนไปใช้ทรัพยากรของบุคคลที่สาม
ตัวย่ออ่านว่า “HyperText Transfer Protocol” ซึ่งแปลว่า “โปรโตคอลการถ่ายโอน” HTTP อยู่ในกลุ่มเลเยอร์แอปพลิเคชันตามข้อมูลเฉพาะที่ใช้โดย OSI
เพื่อให้เข้าใจได้ดีขึ้นว่า HTTP หมายถึงอะไร เรามาดูการเปรียบเทียบง่ายๆ กัน ลองจินตนาการว่าคุณกำลังสื่อสารกับชาวต่างชาติบนโซเชียลเน็ตเวิร์ก เขาส่งข้อความถึงคุณเป็นภาษาอังกฤษ คุณได้รับมัน แต่คุณไม่สามารถเข้าใจเนื้อหาได้เนื่องจากคุณพูดภาษาไม่เก่ง หากต้องการถอดรหัสข้อความ ให้ใช้พจนานุกรม เมื่อเข้าใจสาระสำคัญแล้ว คุณจึงตอบชาวต่างชาติเป็นภาษารัสเซียและส่งคำตอบ ชาวต่างชาติได้รับคำตอบและถอดรหัสข้อความด้วยความช่วยเหลือจากนักแปล เพื่อให้กลไกทั้งหมดง่ายขึ้น อินเทอร์เน็ตโปรโตคอล HTTP จะทำหน้าที่เป็นนักแปล ด้วยความช่วยเหลือ เบราว์เซอร์สามารถแปลเนื้อหาที่เข้ารหัสของหน้าเว็บและแสดงเนื้อหาได้
HTTP มีไว้เพื่ออะไร?
โปรโตคอล HTTP ใช้เพื่อแลกเปลี่ยนข้อมูลโดยใช้โมเดลไคลเอ็นต์-เซิร์ฟเวอร์ ไคลเอนต์เขียนและส่งคำขอไปยังเซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะประมวลผลและวิเคราะห์ หลังจากนั้นการตอบสนองจะถูกสร้างขึ้นและส่งไปยังผู้ใช้ เมื่อสิ้นสุดกระบวนการนี้ ไคลเอ็นต์จะออกคำสั่งใหม่และทุกอย่างจะเกิดซ้ำ
ดังนั้น โปรโตคอล HTTP ช่วยให้คุณสามารถแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชันผู้ใช้ต่างๆ และเว็บเซิร์ฟเวอร์พิเศษ รวมถึงเชื่อมต่อกับทรัพยากรบนเว็บ (โดยปกติคือเบราว์เซอร์) ปัจจุบันโปรโตคอลที่อธิบายไว้ช่วยให้มั่นใจถึงการทำงานของเครือข่ายทั้งหมด โปรโตคอลการถ่ายโอนข้อมูล HTTP ยังใช้เพื่อถ่ายโอนข้อมูลผ่านโปรโตคอลระดับล่างอื่น ๆ เช่น WebDAV หรือ SOAP ในกรณีนี้ โปรโตคอลเป็นวิธีการขนส่ง หลายโปรแกรมยังใช้ HTTP เป็นเครื่องมือหลักในการแลกเปลี่ยนข้อมูล ข้อมูลถูกนำเสนอในรูปแบบต่างๆ เช่น JSON หรือ XML
HTTP เป็นโปรโตคอลสำหรับการแลกเปลี่ยนข้อมูลผ่านการเชื่อมต่อ IP/TCP โดยทั่วไปแล้ว เซิร์ฟเวอร์ใช้พอร์ต TCP 80 เพื่อจุดประสงค์นี้ หากไม่ได้ระบุพอร์ต ซอฟต์แวร์ไคลเอ็นต์จะใช้พอร์ตประเภท TCP 80 เป็นค่าเริ่มต้น ในบางกรณีอาจใช้พอร์ตอื่นได้
โปรโตคอล HTTP ใช้รูปแบบการเข้ารหัสแบบสมมาตรและใช้ระบบการเข้ารหัสแบบสมมาตร ระบบเข้ารหัสแบบสมมาตรเกี่ยวข้องกับการใช้คีย์เดียวกันในการเข้ารหัสและถอดรหัสข้อมูล
ความแตกต่างระหว่าง HTTP และ HTTPS คืออะไร
สามารถตรวจพบความแตกต่างได้แม้กระทั่งจากการถอดรหัสตัวย่อ HTTPS ย่อมาจาก Hypertext Transfer Protocol Security ดังนั้น HTTP จึงเป็นโปรโตคอลอิสระ และ HTTPS จึงเป็นส่วนขยายในการปกป้อง HTTP ส่งข้อมูลโดยไม่มีการป้องกัน ในขณะที่ HTTPS ให้การป้องกันการเข้ารหัส โดยเฉพาะอย่างยิ่งสำหรับทรัพยากรที่มีการอนุญาตที่รับผิดชอบ สิ่งเหล่านี้อาจเป็นโซเชียลเน็ตเวิร์กหรือไซต์ระบบการชำระเงิน
อะไรคืออันตรายของการส่งข้อมูลที่ไม่มีการป้องกัน? โปรแกรมสกัดกั้นสามารถถ่ายโอนข้อมูลเหล่านี้ไปยังผู้โจมตีได้ตลอดเวลา HTTPS มีองค์กรด้านเทคนิคที่ซับซ้อนซึ่งช่วยให้คุณสามารถปกป้องข้อมูลได้อย่างน่าเชื่อถือและขจัดความเป็นไปได้ในการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต ความแตกต่างอยู่ที่พอร์ต โดยทั่วไปแล้ว HTTPS จะทำงานบนพอร์ต 443
ดังนั้น HTTP จึงใช้สำหรับการถ่ายโอนข้อมูล และ HTTPS ช่วยให้ถ่ายโอนข้อมูลได้อย่างปลอดภัยโดยใช้การเข้ารหัสและการอนุญาตบนทรัพยากรที่มีการรักษาความปลอดภัยระดับสูง
ฟังก์ชั่นเพิ่มเติม
HTTP มีฟังก์ชันการทำงานมากมายและเข้ากันได้กับส่วนขยายต่างๆ ข้อมูลจำเพาะ 1.1 ที่ใช้ในปัจจุบันอนุญาตให้ใช้ส่วนหัวการอัพเกรดเพื่อสลับและทำงานผ่านโปรโตคอลอื่นเมื่อทำการแลกเปลี่ยนข้อมูล เมื่อต้องการทำเช่นนี้ ผู้ใช้ต้องส่งคำขอไปยังเซิร์ฟเวอร์ที่มีส่วนหัวนี้ หากเซิร์ฟเวอร์จำเป็นต้องสลับไปยังการแลกเปลี่ยนเฉพาะโดยใช้โปรโตคอลอื่น เซิร์ฟเวอร์จะส่งคืนคำขอไปยังไคลเอนต์ ซึ่งจะแสดงสถานะ “จำเป็นต้องอัปเกรด 426”
คุณลักษณะนี้มีความเกี่ยวข้องเป็นพิเศษสำหรับการแลกเปลี่ยนข้อมูลผ่าน WebSocket (มีข้อกำหนด RFC 6455 ช่วยให้คุณสามารถแลกเปลี่ยนข้อมูลได้ตลอดเวลา โดยไม่ต้องร้องขอ HTTP ที่ไม่จำเป็น) หากต้องการย้ายไปยัง WebSocket ผู้ใช้รายหนึ่งจะส่งคำขอพร้อมส่วนหัวการอัปเกรดและค่า "websocket" จากนั้นเซิร์ฟเวอร์จะตอบกลับด้วย “101 Switching Protocols” หลังจากช่วงเวลานี้ การถ่ายโอนข้อมูลผ่าน WebSocket จะเริ่มขึ้น
วัตถุประสงค์ของการบรรยาย:สร้างความเข้าใจในการทำงานของโปรโตคอล HTTP/HTTPS
HTTP (HyperText Transfer Protocol) เป็นหนึ่งในโปรโตคอลที่สำคัญที่สุดที่ช่วยให้สามารถถ่ายโอนข้อมูลผ่านอินเทอร์เน็ตได้ โปรโตคอล HTTP อยู่ที่เลเยอร์แอปพลิเคชันที่เจ็ดของโมเดล OSI และทำงานบนพื้นฐานของโปรโตคอล TCP
เนื่องจากโปรโตคอล HTTP อยู่ที่เลเยอร์แอปพลิเคชัน แอปพลิเคชันแอปพลิเคชันจึงสามารถใช้เพื่อจัดระเบียบการสื่อสารเครือข่ายได้โดยตรง นอกจากนี้ โปรโตคอล HTTP ยังเป็นส่วนสำคัญของเว็บแอปพลิเคชัน ในกรณีนี้ เบราว์เซอร์ที่ใช้ความสามารถ HTTP จะโต้ตอบกับเซิร์ฟเวอร์เพื่อรับข้อมูลที่จำเป็น
โปรโตคอล HTTP เกี่ยวข้องกับการถ่ายโอนข้อมูล ในโหมด "ร้องขอ-ตอบกลับ"- ยิ่งไปกว่านั้น ภายในกรอบของการโต้ตอบดังกล่าว ข้อมูลเกือบทุกประเภทสามารถส่งได้ - ข้อความธรรมดา, ไฮเปอร์เท็กซ์ (HTML), สไตล์ชีท, สคริปต์ไคลเอนต์, รูปภาพ, เอกสารในรูปแบบต่าง ๆ, ข้อมูลไบนารี ฯลฯ
ภายในโปรโตคอล HTTP จะมีความแตกต่างที่ชัดเจนระหว่างไคลเอ็นต์และเซิร์ฟเวอร์เสมอ ลูกค้าเป็นผู้ริเริ่มการโต้ตอบเสมอ ในทางกลับกัน เซิร์ฟเวอร์จะรับฟังการเชื่อมต่อขาเข้าทั้งหมดและประมวลผลแต่ละรายการ เนื่องจากการสื่อสาร HTTP ทำงานบนพื้นฐานการร้องขอและการตอบกลับ จึงต้องสร้างคำขอ HTTP เพื่อเริ่มต้นเซสชันการถ่ายโอนข้อมูล ในส่วนหนึ่งของคำขอนี้ ไคลเอนต์จะอธิบายว่าต้องการรับทรัพยากรใดจากเซิร์ฟเวอร์ และยังระบุพารามิเตอร์เพิ่มเติมต่างๆ อีกด้วย หลังจากนั้น คำขอจะถูกส่งไปยังเซิร์ฟเวอร์ จากนั้นคำขอจะประมวลผลและสร้างการตอบกลับ HTTP ซึ่งมีข้อมูลบริการและเนื้อหาของทรัพยากรที่ได้รับการร้องขอ โดยทั่วไป กระบวนการสามารถแสดงเป็นแผนผังได้ดังต่อไปนี้
คำขอ HTTP และการตอบสนอง HTTP มีโครงสร้างคล้ายกันและถูกเรียก ข้อความ HTTP- ในความเป็นจริง การสื่อสารทั้งหมดภายในโปรโตคอล HTTP ลงมาเพื่อส่งต่อข้อความ HTTP ข้อความ HTTP แต่ละข้อความเป็นข้อมูลข้อความธรรมดาที่นำเสนอในรูปแบบเฉพาะ มาดูรูปแบบข้อความ HTTP กันดีกว่า
ข้อความ HTTP แต่ละข้อความประกอบด้วยหลายบรรทัด บรรทัดแรกจะเป็นบรรทัดต้อนรับเสมอ ซึ่งจะแตกต่างอย่างมากสำหรับคำขอ HTTP และการตอบสนอง HTTP โดยปกติจะมีข้อมูลทั่วไปเกี่ยวกับคำขอ หลังจากบรรทัดแรกในข้อความ HTTP จะมีส่วนหัว HTTP - แต่ละส่วนหัวจะอยู่ในบรรทัดใหม่ ส่วนหัว HTTP มีอยู่ทั้งในคำขอ HTTP และการตอบกลับ HTTP วัตถุประสงค์ของส่วนหัว HTTP คือเพื่อชี้แจงข้อความ HTTP เพื่อให้ฝ่ายที่ได้รับข้อความ HTTP นี้สามารถประมวลผลข้อความขาเข้าได้แม่นยำยิ่งขึ้น จำนวนส่วนหัวของข้อความ HTTP เป็นตัวแปรและขึ้นอยู่กับข้อความ HTTP ที่ระบุ หากฝ่ายผู้ส่งเชื่อว่าส่วนหัว HTTP นี้จำเป็นในข้อความ HTTP นี้ ก็จะเพิ่มเข้าไป ถ้าไม่ ก็ไม่เพิ่ม ส่วนหัว HTTP แต่ละรายการจะเริ่มต้นด้วยบรรทัดใหม่ ส่วนหัว HTTP ประกอบด้วยชื่อและค่า และชื่อของส่วนหัวจะกำหนดวัตถุประสงค์
ชุดของส่วนหัว HTTP ตามด้วยบรรทัดว่าง ตามด้วยเนื้อหาของข้อความ HTTP ดังนั้นโครงสร้างทั่วไปของข้อความ HTTP จึงสามารถแสดงได้ดังนี้ถูกสร้างขึ้นบนไคลเอนต์และส่งไปยังเซิร์ฟเวอร์เพื่อรับข้อมูลจากไคลเอนต์ ประกอบด้วยข้อมูลเกี่ยวกับทรัพยากรที่คุณต้องการดาวน์โหลด รวมถึงข้อมูลเพิ่มเติม บรรทัดแรกประกอบด้วยวิธีการร้องขอ (ซึ่งเราจะดูในภายหลังในการบรรยายนี้) ชื่อทรัพยากร (รวมถึงเส้นทางสัมพัทธ์บนเซิร์ฟเวอร์) และเวอร์ชันของโปรโตคอล ตัวอย่างเช่น ประเภทของบรรทัดทักทายสามารถกำหนดเป็น " รับ /images/corner1.png HTTP/1.1" คำขอดังกล่าวขอให้เซิร์ฟเวอร์ส่งคืนรูปภาพที่อยู่ในโฟลเดอร์ " ภาพ" และเรียกว่า "corner1.png" ส่วนหัว HTTP มีความสำคัญสำหรับคำขอ HTTP เนื่องจากระบุข้อมูลที่ชี้แจงเกี่ยวกับคำขอ - เวอร์ชันของเบราว์เซอร์ ความสามารถของไคลเอ็นต์ในการยอมรับเนื้อหาที่บีบอัด ความสามารถในการแคช และพารามิเตอร์สำคัญอื่น ๆ ที่อาจส่งผลต่อการสร้างการตอบสนอง เนื้อหาของคำขอ HTTP มักจะมีข้อมูลที่จำเป็นต้องถ่ายโอนไปยังเซิร์ฟเวอร์ ตัวอย่างเช่น หากคุณต้องการอัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ เนื้อหาของไฟล์ก็จะอยู่ในเนื้อหาของคำขอ HTTP ไม่อนุญาตให้วางข้อมูลในเนื้อความของคำขอ HTTP ทั้งหมด ตัวอย่างเช่น เนื้อความของคำขอ HTTP จะว่างเปล่าเสมอหากใช้วิธี GET ดังนั้น คำขอ HTTP มาตรฐานอาจมีลักษณะเช่นนี้
ในคำขอ HTTP ต่อไปนี้ ไคลเอนต์ติดต่อกับเซิร์ฟเวอร์ " microsoft.com"ขอทรัพยากร" รูปภาพ/corner.png" และระบุว่าสามารถรับเนื้อหาที่บีบอัด "gzip" หรือ "deflate" ได้ ภาษาของมันคือภาษาอังกฤษและระบุเวอร์ชันของเบราว์เซอร์ ตามที่ระบุไว้ก่อนหน้านี้ จำนวนและชุดของส่วนหัวอาจแตกต่างกันอย่างมาก อีกตัวอย่างหนึ่งคือ HTTP - ขอ.
คำขอนี้แตกต่างจากคำขอก่อนหน้านี้ตรงที่ใช้วิธีการ POST ซึ่งจะอัปโหลดข้อมูลไปยังเซิร์ฟเวอร์ด้วย ในกรณีนี้ ข้อมูลจะอยู่ในเนื้อหาของคำขอ HTTP หลังบรรทัดว่าง
การตอบสนองของ HTTPสร้างโดยเว็บเซิร์ฟเวอร์เพื่อตอบสนองต่อคำขอ HTTP ขาเข้า มีโครงสร้างคล้ายกับคำขอ HTTP แต่มีความแตกต่างบางประการ ความแตกต่างที่สำคัญอยู่ในบรรทัดแรก แทนที่จะเป็นชื่อของทรัพยากรที่ร้องขอและวิธีการร้องขอ จะระบุสถานะของการตอบสนอง สถานะบ่งชี้ว่าคำขอ HTTP ประสบความสำเร็จเพียงใด ตัวอย่างเช่น หากพบเอกสารบนเซิร์ฟเวอร์และสามารถออกให้กับลูกค้าได้ สถานะจะมีค่าเป็น " ตกลง" ซึ่งบ่งชี้ว่าคำขอเสร็จสมบูรณ์แล้ว อย่างไรก็ตาม อาจเกิดสถานการณ์พิเศษขึ้น เช่น เอกสารไม่อยู่บนเซิร์ฟเวอร์หรือผู้ใช้ไม่มีสิทธิ์รับทรัพยากร เราจะพิจารณาชุดสถานะการตอบสนอง HTTP ต่างๆ ข้อความในการบรรยายครั้งนี้ ดังนั้น บรรทัดแรกของการตอบกลับ HTTP อาจเป็น "HTTP/1.1 200 OK" ส่วนหัว HTTP ในการตอบกลับ HTTP ก็เป็นองค์ประกอบที่สำคัญเช่นกัน ส่วนหัว HTTP เหล่านี้อาจมีข้อมูลเกี่ยวกับประเภทของเนื้อหา (เอกสาร HTML รูปภาพ ฯลฯ) ความยาวเนื้อหา (ขนาดเป็นไบต์) วันที่แก้ไข โหมดแคช ฯลฯ ส่วนหัวทั้งหมดนี้ส่งผลต่อวิธีการแสดงข้อมูล ไคลเอนต์และยังตั้งกฎสำหรับการจัดเก็บข้อมูลในแคชไคลเอนต์ การตอบสนอง HTTP ทั่วไปอาจมีลักษณะดังนี้:
ในตัวอย่างข้างต้น เซิร์ฟเวอร์ระบุว่าพบทรัพยากรแล้ว ประเภทของทรัพยากรคือเอกสาร HTML และยังระบุขนาดและวันที่แก้ไขด้วย หลังจากบรรทัดว่างมาถึงเนื้อหาของเอกสาร HTML เช่น โดยพื้นฐานแล้วสิ่งที่ลูกค้าร้องขอ เช่นเดียวกับคำขอ HTTP จำนวนส่วนหัวในการตอบกลับ HTTP อาจแตกต่างกันไปตามดุลยพินิจของเว็บเซิร์ฟเวอร์
เมื่อพิจารณาโครงสร้างของคำขอ HTTP แนวคิดนี้ก็ได้รับการสัมผัส วิธีการร้องขอ HTTP- วิธีการร้องขอ HTTP กำหนดวิธีการประมวลผลคำขอ HTTP ที่ระบุ เช่น ในแง่หนึ่งเป็นตัวกำหนดความหมายของมัน เนื่องจากคำขอ HTTP สามารถมีความหมายได้หลากหลาย การระบุวิธีการจึงเป็นส่วนสำคัญในการสร้างคำขอ HTTP คำขอ HTTP อาจมีความหมายดังต่อไปนี้: การร้องขอทรัพยากรจากเซิร์ฟเวอร์ การสร้างหรือแก้ไขทรัพยากรบนเซิร์ฟเวอร์ การลบทรัพยากรบนเซิร์ฟเวอร์ ฯลฯ
วิธีการร้องขอ HTTP ที่พบบ่อยที่สุดคือประเภทวิธีการต่อไปนี้:
| รับ | อนุญาตให้คุณรับข้อมูลจากเซิร์ฟเวอร์ เนื้อหาคำขอยังคงว่างเปล่าเสมอ |
| ศีรษะ | คล้ายกับ GET แต่เนื้อหาการตอบกลับยังคงว่างเปล่าอยู่เสมอ ทำให้คุณสามารถตรวจสอบความพร้อมใช้งานของทรัพยากรที่ร้องขอ และอ่านส่วนหัว HTTP ของการตอบกลับ |
| โพสต์ | ช่วยให้คุณสามารถอัปโหลดข้อมูลไปยังเซิร์ฟเวอร์ โดยพื้นฐานแล้วจะเป็นการเปลี่ยนแปลงทรัพยากรบนเซิร์ฟเวอร์ แต่มักใช้เพื่อสร้างทรัพยากรบนเซิร์ฟเวอร์ เนื้อความของคำขอประกอบด้วยทรัพยากรที่กำลังเปลี่ยนแปลง/สร้าง |
| ใส่ | คล้ายกับ POST แต่โดยพื้นฐานแล้วมันเกี่ยวข้องกับการสร้างทรัพยากรมากกว่าการเปลี่ยนแปลง เนื้อหาของคำขอมีทรัพยากรที่ถูกสร้างขึ้น |
| ลบ | ลบทรัพยากรออกจากเซิร์ฟเวอร์ |
นอกเหนือจากวิธีการ HTTP เหล่านี้แล้ว ยังมีวิธีการอื่นๆ จำนวนมากที่กำหนดไว้ในข้อกำหนดเฉพาะของโปรโตคอล HTTP อย่างไรก็ตาม เบราว์เซอร์มักจะใช้เฉพาะวิธี GET และ POST เท่านั้น อย่างไรก็ตาม แอปพลิเคชันอื่นอาจใช้วิธี HTTP ขึ้นอยู่กับดุลยพินิจของตน
ดังที่เราเห็นก่อนหน้านี้ การตอบสนองของ HTTP ประกอบด้วย รหัสสถานะหรือ รหัสส่งคืน- สถานะนี้แสดงสถานะของการตอบสนอง HTTP ที่ได้รับจากเซิร์ฟเวอร์ กลไกนี้จำเป็นสำหรับการทำงานของโปรโตคอล HTTP เนื่องจากอาจเกิดสถานการณ์ที่ไม่ได้มาตรฐานต่างๆ เมื่อประมวลผลคำขอ รหัสสถานะทั้งหมดเป็นตัวเลขสามหลัก นอกจากนี้ การตอบสนอง HTTP อาจมีคำอธิบายข้อความของสถานะ รหัสสถานะทั้งหมดแบ่งออกเป็นห้ากลุ่ม
รหัสสถานะแต่ละกลุ่มจะระบุสถานการณ์ที่คำขอพบ กลุ่มจะถูกกำหนดโดยหลักแรกของรหัสสถานะ ตัวอย่างเช่น รหัสสถานะของกลุ่ม 2xx บ่งชี้ถึงความสำเร็จของคำขอ HTTP รหัสสถานะที่ใช้บ่อยที่สุดจะแสดงอยู่ในตารางด้านล่าง
| รหัส | คำอธิบาย | |
|---|---|---|
| 1xx | รหัสข้อมูล | |
| 2xx | ดำเนินการตามคำขอให้สำเร็จ | |
| 200 | ประมวลผลคำขอสำเร็จแล้ว | |
| 201 | สร้างวัตถุแล้ว | |
| 202 | ยอมรับข้อมูลแล้ว | |
| 203 | ข้อมูลที่ไม่น่าเชื่อถือ | |
| 204 | ไม่มีเนื้อหา | |
| 205 | รีเซ็ตเนื้อหา | |
| 206 | เนื้อหาบางส่วน (เช่น เมื่อ "ดาวน์โหลดไฟล์") | |
| 3xx | การเปลี่ยนเส้นทาง (จำเป็นต้องดำเนินการบางอย่างเพื่อให้คำขอเสร็จสมบูรณ์) | |
| 300 | มีหลายตัวเลือกให้เลือก | |
| 301 | ทรัพยากรถูกย้ายอย่างถาวร | |
| 302 | ทรัพยากรถูกย้ายชั่วคราว | |
| 303 | ดูแหล่งข้อมูลอื่น | |
| 304 | เนื้อหาไม่มีการเปลี่ยนแปลง | |
| 305 | ใช้พร็อกซีเซิร์ฟเวอร์ | |
| 4xx | ปัญหาไม่ได้อยู่ที่เซิร์ฟเวอร์ แต่อยู่ที่คำขอ | |
| 400 | คำขอไม่ถูกต้อง | |
| 401 | ไม่มีสิทธิ์ในการดูทรัพยากร | |
| 402 | จำเป็นต้องชำระเงิน | |
| 403 | การเข้าถึงถูกปฏิเสธ | |
| 404 | ไม่พบทรัพยากร | |
| 405 | วิธีการไม่ถูกต้อง | |
| 406 | คำขอที่ไม่เหมาะสม | |
| 407 | จำเป็นต้องลงทะเบียนบนพร็อกซีเซิร์ฟเวอร์ | |
| 408 | การประมวลผลคำขอหมดเวลา | |
| 409 | ขัดแย้ง | |
| 410 | ไม่มีทรัพยากรอีกต่อไป | |
| 411 | ความยาวที่ต้องการ | |
| 412 | ไม่เป็นไปตามเงื่อนไขเบื้องต้น | |
| 413 | องค์ประกอบที่ร้องขอมีขนาดใหญ่เกินไป | |
| 414 | ตัวระบุทรัพยากร (URI) ยาวเกินไป | |
| 415 | ประเภททรัพยากรที่ไม่รองรับ | |
| 5xx | ข้อผิดพลาดของเซิร์ฟเวอร์ | |
| 500 | ข้อผิดพลาดเซิร์ฟเวอร์ภายใน | |
| 501 | ไม่ได้ใช้ฟังก์ชัน | |
| 502 | ข้อบกพร่องของเกตเวย์ | |
| 503 | บริการไม่พร้อมใช้งาน | |
| 504 | เวลาเกตเวย์หมดอายุแล้ว | |
| 505 | เวอร์ชัน HTTP ที่ไม่รองรับ | |
รหัสสถานะเหล่านี้และรหัสสถานะอื่น ๆ ใช้เพื่อถ่ายทอดข้อมูลเกี่ยวกับสถานะของคำขอจากไคลเอนต์ไปยังเซิร์ฟเวอร์
คุณลักษณะที่โดดเด่นของโปรโตคอล HTTP คือข้อมูลภายในโปรโตคอลนี้จะถูกส่งในรูปแบบของข้อความ ซึ่งหมายความว่าการทำงานกับโปรโตคอลดังกล่าวนั้นค่อนข้างง่าย นอกจากนี้ วิศวกรความปลอดภัยยังเปิดโปรโตคอล HTTP ทิ้งไว้แม้ว่าจะมีระบบการรักษาความปลอดภัยที่เข้มงวดก็ตาม ดังนั้นการใช้งานการโต้ตอบเครือข่ายภายในโปรโตคอล HTTP จึงเป็นหนึ่งในพื้นที่ที่น่าหวัง
อย่างไรก็ตาม แม้จะมีความเรียบง่ายของโปรโตคอล แต่ก็มีปัญหาการรั่วไหลของข้อมูลที่ส่ง เนื่องจากข้อมูลถูกส่งในรูปแบบข้อความธรรมดา การสกัดกั้นข้อมูลดังกล่าวจึงค่อนข้างง่าย ในบางสถานการณ์ปัญหานี้ไม่สำคัญ อย่างไรก็ตาม สำหรับเว็บแอปพลิเคชันที่ทำงานกับข้อมูลที่เป็นความลับ นี่เป็นข้อเสียเปรียบที่สำคัญพอสมควร
ด้วยเหตุนี้ จึงมีการแก้ไขโปรโตคอลนี้ - HTTPS, เช่น. โปรโตคอล HTTP พร้อมรองรับการเข้ารหัส
ดังที่คุณทราบ มีอัลกอริธึมการเข้ารหัสที่แข็งแกร่งแบบคลาสสิกที่เข้ารหัสข้อมูลตามคีย์ที่มีอยู่ คีย์เดียวกันนี้ใช้ในการเข้ารหัสและถอดรหัสข้อมูล ถ้าใครรู้คีย์ของข้อมูลที่เข้ารหัส ก็สามารถถอดรหัสได้ คีย์คือลำดับปกติของบิตที่มีความยาวที่แน่นอน ยิ่งคีย์ยาวเท่าไร การทำลายอัลกอริธึมการเข้ารหัสก็จะยิ่งยากขึ้นเท่านั้น ดังนั้นเพื่อปกป้องข้อมูลของคุณ คุณจะต้องเก็บคีย์การเข้ารหัสไว้เป็นความลับ อย่างไรก็ตาม จะทำสิ่งนี้ให้สำเร็จได้อย่างไรภายในกรอบการโต้ตอบผ่านโปรโตคอล HTTP ท้ายที่สุดหากคุณส่งคีย์นี้เป็นข้อความที่ชัดเจน ความหมายของการเข้ารหัสก็จะหายไป ในกรณีนี้จะใช้การเข้ารหัสประเภทเพิ่มเติม - แบบอสมมาตร ในกรณีนี้มีกุญแจอยู่คู่หนึ่ง - สาธารณะและส่วนตัว เมื่อใช้คีย์สาธารณะ คุณสามารถเข้ารหัสได้เฉพาะข้อมูล และเมื่อใช้คีย์ส่วนตัว คุณสามารถถอดรหัสได้
เมื่อไคลเอนต์ติดต่อกับเซิร์ฟเวอร์ผ่านช่องทางที่ปลอดภัย เซิร์ฟเวอร์จะจัดเก็บคีย์สาธารณะและส่วนตัว ในช่วงเวลาเริ่มต้น เซิร์ฟเวอร์จะส่งรหัสสาธารณะของการเข้ารหัสแบบอสมมาตรไปยังไคลเอนต์ ไคลเอนต์สุ่มสร้างคีย์เข้ารหัสแบบสมมาตรและเข้ารหัสโดยใช้คีย์สาธารณะที่ได้รับจากเซิร์ฟเวอร์ หลังจากนี้ ไคลเอ็นต์จะส่งคีย์ที่เข้ารหัสไปยังเซิร์ฟเวอร์ และ ณ จุดนี้ไคลเอ็นต์และเซิร์ฟเวอร์จะมีคีย์เดียวกันสำหรับการเข้ารหัสแบบสมมาตร ถัดมาเป็นการโต้ตอบ HTTP ซึ่งถูกเข้ารหัสโดยใช้คีย์สมมาตรนี้ คีย์สมมาตรยังคงเป็นความลับและไม่สามารถดักจับได้เนื่องจากคีย์ส่วนตัว (ซึ่งสามารถใช้เพื่อถอดรหัสข้อความแรกที่มีคีย์สมมาตร) ยังคงเป็นความลับบนเซิร์ฟเวอร์ ดังนั้นจึงมั่นใจได้ถึงการรักษาความลับและความสมบูรณ์ของข้อมูลที่ส่งผ่าน HTTP
สรุปสั้นๆ
เว็บแอปพลิเคชันทั้งหมดใช้โปรโตคอล HTTP โปรโตคอล HTTP ส่งข้อมูลข้อความและทำงานในโหมดตอบกลับคำขอ คำขอ HTTP และการตอบกลับ HTTP มีโครงสร้างที่กำหนดไว้อย่างเคร่งครัด - บรรทัดต้อนรับ ส่วนหัว และเนื้อหาข้อความ จำนวนส่วนหัว HTTP เป็นตัวแปร ส่วนหัว HTTP ถูกแยกออกจากเนื้อหาข้อความด้วยบรรทัดว่าง ทุกคำขอ HTTP จะถูกส่งไปยังเซิร์ฟเวอร์โดยเป็นส่วนหนึ่งของวิธี HTTP วิธีการ HTTP จะกำหนดความหมายของคำขอ (รับทรัพยากร เพิ่ม เปลี่ยนแปลง ลบ ฯลฯ) ในการตอบกลับ HTTP นอกเหนือจากข้อมูลบริการและข้อมูลที่เป็นประโยชน์แล้ว สถานะคำขอจะถูกส่งไป ซึ่งแจ้งให้ลูกค้าทราบเกี่ยวกับความสำเร็จของคำขอ รหัสสถานะทั้งหมดแบ่งออกเป็นกลุ่ม เนื่องจากข้อมูลที่ส่งผ่าน HTTP สามารถถูกดักจับได้ จึงไม่รับประกันการรักษาความลับของข้อมูลที่ส่ง
หากจำเป็นต้องมีระดับความปลอดภัยดังกล่าว คุณจะต้องใช้โปรโตคอล HTTPS ซึ่งให้การเข้ารหัสข้อมูลที่ส่งโดยอิงจากอัลกอริธึมการเข้ารหัสแบบสมมาตรและไม่สมมาตรร่วมกัน
6.1 บริการ WWW
บริการ WWW (เวิลด์ไวด์เว็บ) มีไว้สำหรับการแลกเปลี่ยนข้อมูลไฮเปอร์เท็กซ์
โครงการนี้ถูกเสนอในปี 1989 เบราว์เซอร์ตัวแรกปรากฏในปี 1993
WWW ถูกสร้างขึ้นตามโครงร่างไคลเอ็นต์-เซิร์ฟเวอร์(Internet Explorer, Opera...) เป็นไคลเอนต์หลายโปรโตคอลและล่าม HTML และเช่นเดียวกับล่ามทั่วไป ไคลเอนต์ทำหน้าที่ต่าง ๆ ขึ้นอยู่กับคำสั่ง (แท็ก) ฟังก์ชั่นเหล่านี้ไม่เพียงแต่รวมถึงการวางข้อความบนหน้าจอเท่านั้น แต่ยังรวมถึงการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ในขณะที่วิเคราะห์ข้อความ HTML ที่ได้รับ ซึ่งจะเกิดขึ้นได้ชัดเจนที่สุดเมื่อแสดงภาพกราฟิกที่ฝังอยู่ในข้อความ
เซิร์ฟเวอร์ HTTP(Apeche, IIS...) จัดการคำขอของลูกค้าเพื่อรับไฟล์ (ในกรณีที่ง่ายที่สุด)
การโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์ผ่านโปรโตคอล HTTP
ในตอนแรกบริการ WWW มีพื้นฐานมาจากสามมาตรฐาน:
HTML (HyperText Markup Lan-guage) - ภาษามาร์กอัปไฮเปอร์เท็กซ์สำหรับเอกสาร
URL (Universal Resource Locator) เป็นวิธีสากลในการจัดการกับทรัพยากรบนเครือข่าย
HTTP (HyperText Transfer Protocol) เป็นโปรโตคอลสำหรับการแลกเปลี่ยนข้อมูลไฮเปอร์เท็กซ์
CGI (Common Gateway Interface) เป็นอินเทอร์เฟซเกตเวย์สากล สร้างขึ้นเพื่อการโต้ตอบระหว่างเซิร์ฟเวอร์ HTTP และโปรแกรมอื่นๆ ที่ติดตั้งบนเซิร์ฟเวอร์ (เช่น DBMS)
6.2 โปรโตคอล HTTP
เอกสารแรก (แต่ไม่ใช่มาตรฐาน) คือ RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk พฤษภาคม 1996)
คุณสมบัติบางอย่างของโปรแกรม:
การตั้งค่าความลึกของการรวบรวมข้อมูลไซต์และลิงก์ภายนอก
การระบุประเภทไฟล์ (นามสกุล) ที่จะดาวน์โหลด เช่น ดาวน์โหลดได้เฉพาะกราฟิกเท่านั้น
กำหนดขีดจำกัดขนาดไฟล์
การสแกนกราฟิกการ์ด
กำหนดตารางการทำงาน Scheduler ในตัว
การระบุชื่อลูกค้าหากมีข้อจำกัดสำหรับลูกค้าบางราย
ตั้งค่าจำนวนไฟล์ที่ดาวน์โหลดพร้อมกัน
