HTTP กลายเป็นไร้สัญชาติอย่างไร


26

HTTP ถูกกล่าวว่าไร้สัญชาติ ความหมายมันไม่จำเป็นต้องเก็บข้อมูลสำหรับการส่งข้อมูล

แต่ HTTP ใช้ TCP ซึ่งเป็นสถานะเชิง

หากเป็นเช่นนั้น HTTP จะกลายเป็นไร้สัญชาติได้อย่างไร


6
นี่ไม่ใช่สิ่งซ้ำกันหลังจาก 5 ปีหลังจากผู้ใช้ Super เปิดตัว?
Peter Mortensen

เพราะส่วนใหญ่ของเพลงอยู่บน StackOverflow ฉันแค่เดา
trysis

8
เพียงเพราะมันวิ่งผ่านสายเคเบิล (อื่น ๆ ) ไม่ได้ทำให้เป็นโปรโตคอลไฟฟ้าอย่างใดอย่างหนึ่ง
Hagen von Eitzen

คำตอบ:


42

HTTP ไม่สนใจ - และเป็นอิสระจาก - โปรโตคอลระดับล่างใด ๆ ที่ใช้เพื่อการส่งผ่านตัวมันเองถึงแม้ว่ามันจะไร้สัญชาติก็ตาม

เทคโนโลยีการขนส่งสามารถเป็น TCP หรือ SPX เก่าหรือ Novell ของ Novell หรืออะไรก็ได้ที่คุณฝันถึงและ HTTP จะยังคงทำงานเหมือนเดิม HTTP ต้องการโปรโตคอลการสตรีมหรือการเชื่อมต่อและขึ้นอยู่กับ URL ที่สามารถแก้ไขได้ แต่ไม่สนใจว่าจะทำอย่างไร

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

เพียงเพราะโปรโตคอลระดับล่างเป็น stateful ไม่ได้หมายความว่าอะไรที่อยู่ด้านบนของมันจะกลายเป็น stateful โดยอัตโนมัติหรือจำเป็นต้อง stateful

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


1
การจัดเส้นทางเกิดขึ้นที่ระดับ tcp / ip
Fiasco Labs

3
ภาพนี้อธิบายได้เป็นอย่างดี vichargrave.com/wp-content/uploads/2013/01/…
JakeGould

2
ความจริงที่ว่า HTTP ไม่สนใจสถานะของการเชื่อมต่อพื้นฐาน (ซึ่งมักจะเป็น TCP) เป็นหนึ่งในประสิทธิภาพการทำงานที่สำคัญที่ข้อผิดพลาดที่ HTTP2แนวทางต่างๆพยายามแก้ไข
skolima

2
@Fiasco: พูดอย่างเคร่งครัดการกำหนดเส้นทางจะเกิดขึ้นที่ระดับ IP การกำหนดเส้นทางขึ้นอยู่กับที่อยู่อินเทอร์เน็ตจะไม่มีข้อมูลจากเลเยอร์ TCP ที่ใช้ในการกำหนดเส้นทางพื้นฐาน
RedGrittyBrick

1
@skolima: ในขณะที่ statelessness คือเหตุผลที่ HTTP เป็นโปรโตคอลที่ปรับขนาดได้และเชื่อถือได้มากที่สุดในการใช้งานที่กว้างขวาง HTTP ได้รับการออกแบบมาอย่างชัดเจนเพื่อขยายขีดความสามารถมากกว่าประสิทธิภาพ (ใช่มันเป็นสิ่งที่แตกต่างกัน) ดังนั้นหากคุณคิดว่าคุณต้องการเวลาแฝงที่ต่ำมากกว่าที่คุณใช้โปรโตคอลที่ไม่ถูกต้องหรือคุณใช้โปรโตคอลไม่ถูกต้อง ในขณะที่ HTTP2 มุ่งมั่นที่จะปรับปรุงประสิทธิภาพ แต่ก็เป็นไปในลักษณะที่ยังคงเป็นความจริงที่ไร้สัญชาติ เมื่อใช้ในสิ่งที่ตั้งใจไว้ฉันไม่เคยเห็นภาวะไร้สัญชาติเป็นคอขวดของแอปพลิเคชั่น HTTP ที่ออกแบบมาอย่างดี
Lie Ryan

10

"HTTP คือไร้สัญชาติ" หมายความว่าแต่ละธุรกรรม HTTP (คำขอคู่การตอบกลับ) สามารถประมวลผลได้อย่างอิสระจากสถานะใด ๆ จากคู่คำขอตอบกลับก่อนหน้า

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

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

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


can also easily be handled by different server and the client will never knowแม้ว่าจะเป็นเรื่องจริงทางเทคนิค แต่สิ่งนี้ทำให้เข้าใจผิดเนื่องจากเว็บแอปพลิเคชั่นจำนวนมากใช้เซสชันที่ติดหนึบซึ่งต้องการตัวโหลดบาลานซ์เพื่อกำหนดเส้นทางการร้องขอในอนาคตจากเซสชันการเรียกดูเดียวกันไปยังเซิร์ฟเวอร์เดียวกัน จากเปอร์สเปคทีฟ HTTP เซสชันจะไม่เกี่ยวข้อง แต่ประโยคเรียงลำดับสุดท้ายของคุณบอกเป็นนัยว่าประสบการณ์ของผู้ใช้ปลายทางจะไม่ได้รับผลกระทบซึ่งจะเป็นเท็จด้วยเซสชั่นเหนียว
แบรนดอน

1
@Brandon: แอปพลิเคชั่นดังกล่าวสร้างโปรโตคอล stateful บน HTTP และนี่เป็นการลงโทษสำหรับพวกเขา!
Jan Hudec

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

@slebetman: ใช่อะไรก็ตาม HTTP นั้นไม่มีสถานะดังกล่าวดังนั้นสำหรับ HTTP มันเป็นเรื่องง่าย หากแอปพลิเคชันเพิ่มสถานะของตัวเองบางอย่างมันเป็นการต่อสู้ของมัน
Jan Hudec

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

2

ลักษณะ "ไร้สัญชาติ" ของ HTTP หมายความว่าในชั้นนี้จะไม่มีการสร้างหรือใช้ข้อมูลสถานะ

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

ในทางตรงกันข้ามกลไกการล็อกอินตามคุกกี้นั้นเป็นของรัฐ แต่ไม่ใช่ส่วนหนึ่งของ HTTP


1

คุณต้องเข้าใจว่ามันเป็นตุ๊กตารัสเซีย (หรือกล่อง) ถ้าคุณต้องการ) ตุ๊กตาแต่ละตัวอุ้มอีกข้างหนึ่งนั่นคือวิธีการทำงาน: TCP ถือ HTTP "ข้างใน" แต่มันไม่สนใจหรือคุณสมบัติ

เพื่อให้ได้ภาพรวมผมขอแนะนำให้อ่านเกี่ยวกับOSI Modelเพราะทำให้ชัดเจนยิ่งขึ้น

TCP อยู่ด้านล่างของ HTTP ไม่กี่เลเยอร์ในโมเดล OSI แต่ละเลเยอร์จริง ๆ แล้วสอดคล้องกับโปรโตคอลอื่น

ในกรณีของเรา HTTP อยู่ในการนำเสนอและชั้นแอปพลิเคชันและ TCP ในชั้นการขนส่ง หรือถ้าคุณใช้โมเดล TCP / IP ทั้งโปรโตคอล TCP และ IP จะอยู่ในเลเยอร์เครือข่ายเชื่อมโยงและ HTTP ในแอปพลิเคชันและเลเยอร์การนำเสนอ


1
ปัญหาของแบบจำลอง OSI ก็คือตอนนี้ทางทฤษฎี (มีความพยายามที่จะใช้จริง แต่พวกเขาล้มเหลวในตลาดเนื่องจากความซับซ้อนของพวกเขา) ในความเป็นจริงไม่มีเลเยอร์ระหว่าง TCP และ HTTP นอกจากนี้เลเยอร์การนำเสนอจะเป็น HTML ไม่ใช่ HTTP
MSalters

ในรูปแบบ TCP / IP TCP ไม่ได้อยู่ในเลเยอร์เครือข่าย มันอาศัยอยู่ในเลเยอร์การขนส่งด้านบนของ IP ซึ่งอยู่ในเครือข่ายในภายหลัง การเข้าชม google ครั้งแรกสำหรับ "รุ่น TCP" แสดงให้เห็นถึงสิ่งนี้: technet.microsoft.com/en-us/library/cc786900(v=ws.10).aspx
Brandon

@MSalters: TLS ไม่ใช่เลเยอร์หรือไม่
grawity

1
@MSalters: คุณรู้หรือไม่ว่า HTTPS เป็นเพียงชื่อที่กำหนดโดย HTTP ที่ถูกช่องสัญญาณโดย TLS เช่น TLS นั้นเป็นเลเยอร์ภายใต้ HTTP และอยู่ด้านบนของคำสั่งผสม TCP และ TLS / SSL + HTTP เรียกว่า HTTPS
Slebetman

1
นอกจากนี้ยังมีอีกชื่อใหม่สำหรับคำสั่งผสม TLS / HTTP หาก TLS ที่มีการรับส่งข้อมูล HTTP จะใช้มัลติเพล็กซิ่งซ็อกเก็ต / สตรีมเสมือนเรียกว่า SPDY (แต่ URL ในเบราว์เซอร์ของคุณยังคงเป็น HTTPS)
Slebetman
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.