โดย เฌอดอน
ทำความรู้จักกับโมเดลการเชื่อมต่อระหว่างระบบเปิด
ภาพรวม
ตลอดซีรีส์นี้ เราจะพูดถึงเรื่องพื้นฐานต่างๆ เช่น:
(ตอนที่ 1) DNS ทำงานอย่างไร
(ตอนที่ 2) Network Stack, OSI Model [คุณอยู่ที่นี่!]
(ส่วนที่ 3) วิธีการและรูปแบบ HTTP
(ส่วนที่ 4) การระบุตัวตนลูกค้า
(ตอนที่ 5) การรับรองความถูกต้องขั้นพื้นฐาน/ย่อย
(ตอนที่ 6) HTTPS ที่ทำงานร่วมกับ SSL/TLS
โมเดล OSI
โมเดลการเชื่อมต่อระหว่างระบบเปิด (OSI) เป็นรูปแบบมาตรฐานสำหรับการสื่อสารโทรคมนาคมในระบบคอมพิวเตอร์ มันไม่ได้คำนึงถึงเทคโนโลยีพื้นฐาน แต่คำนึงถึงชั้นที่เกี่ยวข้องกับการสื่อสารแทน ให้เราสำรวจเลเยอร์ต่างๆ ภายในโมเดล OSI:
โมเดล OSI 5 เลเยอร์ทั่วไป
1. เลเยอร์แอปพลิเคชัน
เลเยอร์นี้อนุญาตให้แอปพลิเคชันสื่อสารผ่านเครือข่ายเมื่อสร้างการเชื่อมต่อแล้ว เช่น จากเว็บเบราว์เซอร์ (แอปพลิเคชัน) ไปยังเซิร์ฟเวอร์ ตัวอย่างของโปรโตคอลในเลเยอร์นี้ได้แก่ HTTP และ TELNET
ไฮเปอร์เท็กซ์ทรานสเฟอร์โปรโตคอล (HTTP)
ชุดกฎสำหรับการถ่ายโอนไฟล์ทางอินเทอร์เน็ต ตัวอย่างเช่น เมื่อคุณป้อน URL ลงในเบราว์เซอร์ เบราว์เซอร์จะส่งคำขอ HTTP สำหรับหน้าเว็บนั้น จากนั้นโฮสต์จะส่งคืนหน้าเว็บ พร้อมด้วยองค์ประกอบทั้งหมดที่อยู่ภายใน เช่น รูปภาพ ข้อความ วิดีโอ แบบอักษรสำหรับจัดรูปแบบ ฯลฯ
2. ชั้นขนส่ง
เลเยอร์นี้มีหน้าที่รับผิดชอบในการสื่อสารข้อความระหว่างโฮสต์กับโฮสต์ ตัวอย่างของโปรโตคอลในเลเยอร์นี้ได้แก่ TCP และ UDP
โปรโตคอลควบคุมการส่งผ่าน (TCP)
โปรโตคอลเชิงการเชื่อมต่อที่พบบ่อยที่สุด กำหนดวิธีการสร้างและรักษาการสนทนาบนเครือข่าย มีหน้าที่รับผิดชอบในการสร้างการเชื่อมต่อ (เรียกว่า ซ็อกเก็ต ) ระหว่างไคลเอนต์และโฮสต์ด้วยการจับมือ 3 ทาง
ผู้ใช้ที่ร้องขอข้อมูลจะส่งแพ็กเก็ตข้อมูล SYN ไปยังเซิร์ฟเวอร์ โดยร้องขอ การซิงโครไนซ์ . จากนั้นเซิร์ฟเวอร์จะตอบกลับด้วย SYN-ACK ไปยังผู้ใช้ โดยระบุว่าได้ รับทราบแล้ว แพ็กเก็ตข้อมูลและต้องการเชื่อมต่อด้วย การเชื่อมต่อจึงถูกสร้างขึ้นเมื่อผู้ใช้ส่ง ACK ล่าสุดไปยังเซิร์ฟเวอร์
TCP เป็นสิ่งที่พบได้บ่อยที่สุดเนื่องจากความสง่างาม ซึ่งสามารถนำเสนอสิ่งต่อไปนี้:
การสื่อสารที่มุ่งเน้นการเชื่อมต่อ
สร้างโปรโตคอลการจับมือระหว่างจุดสิ้นสุดเพื่อให้แน่ใจว่ามีการเชื่อมต่อก่อนที่จะมีการแลกเปลี่ยนข้อมูล และส่งเป็นสตรีมข้อมูล (แพ็กเก็ตข้อมูล)
ความน่าเชื่อถือ
การใช้เช็คซัมช่วยให้มั่นใจได้ว่าแพ็กเก็ตข้อมูลที่ส่งและรับเหมือนกัน หากมีแพ็กเก็ตที่หายไป/เสียหาย มันจะร้องขอให้ส่งแพ็กเก็ตข้อมูลอีกครั้งโดยส่งข้อความ NACK ไปยังผู้ส่ง
สั่งซื้อ
แพ็กเก็ตข้อมูลจะถูกกำหนดหมายเลขและส่ง ด้วยเหตุนี้ TCP จะตรวจสอบให้แน่ใจว่าแพ็กเก็ตที่ได้รับนั้นถูกเรียงลำดับใหม่ก่อนที่จะส่งแอปพลิเคชัน
การควบคุมการไหล
อัตราการส่งข้อมูลได้รับการควบคุมเพื่อปรับปรุงประสิทธิภาพในขณะเดียวกันก็ป้องกันการโอเวอร์รัน/อันเดอร์รันของบัฟเฟอร์ ซึ่งข้อมูลจะถูกส่งเร็วกว่าที่ผู้รับจะสามารถประมวลผลได้ และในทางกลับกัน
กลไกเบื้องหลังมีการอธิบายไว้ด้านล่างในส่วน TCP Slow Start
มัลติเพล็กซ์
โดยพื้นฐานแล้ว มันสามารถส่งข้อมูลหลายสตรีมพร้อมกันผ่านซ็อกเก็ตเดียวกัน สิ่งเหล่านี้ทำได้ผ่านพอร์ตต่างๆ บนซ็อกเก็ต เราจะหารือเกี่ยวกับความแตกต่างระหว่างมัลติเพล็กซ์และการวางท่อเพิ่มเติมในบทความ
โปรโตคอลเดตาแกรมผู้ใช้ (UDP)
แม้ว่าจะคล้ายกับ TCP แต่เป็นโปรโตคอลที่ไม่มีการเชื่อมต่อ มันตรงกันข้ามกับ TCP อย่างสิ้นเชิง ทำให้ไม่น่าเชื่อถือและไม่มีการเรียงลำดับ แพ็กเก็ตที่ทิ้งจะไม่ถูกส่งซ้ำ ทำให้เกิดช่องว่างในข้อมูล
อย่างไรก็ตาม นั่นทำให้ดีที่สุดสำหรับแอปพลิเคชันที่ต้องคำนึงถึงเวลา เช่น การโทรด้วยเสียงผ่านอินเทอร์เน็ต (VoIP) เนื่องจากไม่จำเป็นต้องมีการจับมือ 3 ทิศทางก่อนส่งสัญญาณจึงทำให้รวดเร็ว นอกจากนี้ แพ็กเก็ตข้อมูลที่ตกไม่เป็นปัญหาใน VoIP เนื่องจากหูของมนุษย์สามารถจัดการกับช่องว่างสั้นๆ ซึ่งเป็นเรื่องปกติของแพ็กเก็ตที่ตกได้ดีมาก
3. เลเยอร์เครือข่าย
เลเยอร์นี้มีหน้าที่รับผิดชอบในการจัดเตรียมเส้นทางข้อมูลสำหรับการเชื่อมต่อเครือข่าย โดยพื้นฐานแล้ว จะย้ายแพ็กเก็ตข้อมูลข้ามเครือข่ายด้วยเส้นทางที่สมเหตุสมผลที่สุด
อินเทอร์เน็ตโปรโตคอล (IP)
กำหนดโครงสร้างของแพ็กเก็ตข้อมูล ตลอดจนการติดป้ายกำกับข้อมูลต้นทางและปลายทาง
ข้อมูลต้นทางและปลายทางจะอยู่ในรูปแบบ IP Addresses ซึ่งสามารถอยู่ในรูปแบบ 104.16.121.127 (IPv4) หรือ 2001:db8:0:1234:0:567:8:1 (IPv6)
4. ลิงก์/ฟิสิคัลเลเยอร์
เลเยอร์นี้เป็นรากของโมเดล OSI โดยที่ข้อมูลจะถูกส่งในเครือข่ายท้องถิ่น (LAN) สำหรับเลเยอร์ลิงก์ และสัญญาณทางกายภาพ เช่น ตัวกลางทางไฟฟ้า เครื่องกล ในรูปแบบของคำรหัสหรือสัญลักษณ์ในเลเยอร์ทางกายภาพ
การแสดงภาพเส้นทาง
ใช้ tracert google.com สามารถตรวจสอบเส้นทางจากฝั่งไคลเอ็นต์ (คอมพิวเตอร์ของคุณ) ไปยังโฮสต์ (google.com)
จากด้านบน คุณสามารถดูเส้นทางเริ่มต้นจากอุปกรณ์ของฉัน 192.168.1.254 ไปยังเราเตอร์ 10.243.128.1 ก่อนที่จะส่งผ่านผู้ให้บริการอินเทอร์เน็ต (ISP) ที่ตั้งอยู่ในโปรตุเกส และอื่นๆ
เลเยอร์เสริม
โมเดล TCP/IP
TCP จะขอให้ส่งแพ็กเก็ตข้อมูลที่ตกหล่นอีกครั้ง และจัดลำดับใหม่
IP รับผิดชอบเฉพาะโครงสร้างของแพ็กเก็ตข้อมูลเท่านั้น ดังนั้นจะไม่ทำการแก้ไขใดๆ หากแพ็กเก็ตข้อมูลเสียหายหรือตกหล่น นี่คือจุดที่ TCP เข้ามามีบทบาท โดยกำหนดหมายเลขแพ็กเก็ตข้อมูลก่อนที่จะส่งไปยังไคลเอนต์ ที่ฝั่งไคลเอ็นต์ TCP จะขอให้ส่งแพ็กเก็ตที่สูญหาย/เสียหายอีกครั้ง จากนั้นจัดเรียงแพ็กเก็ตข้อมูลใหม่
โมเดล HTTP/TCP
ดังที่เราได้กล่าวไปแล้ว ตอนนี้ HTTP สามารถส่งคำขอผ่านการเชื่อมต่อที่ทำโดย TCP Handshake แต่พวกเขาจะเติมเต็มซึ่งกันและกันได้อย่างไร
การเชื่อมต่อ HTTP แบบถาวร
ซึ่งจะอนุญาตคำขอ/ตอบกลับ HTTP หลายรายการบนการเชื่อมต่อ TCP เดียว ซึ่งตรงข้ามกับการเปิดการเชื่อมต่อใหม่ทุกครั้งที่มีคำขอ/ตอบกลับ
ตัวอย่างการตอบสนองสำหรับการเชื่อมต่อแบบถาวร
ซึ่งดำเนินการผ่านส่วนหัว HTTP โดยที่ Connection: Keep-Alive . ตามค่าเริ่มต้น การเชื่อมต่อจะปิดเฉพาะเมื่อมีการตอบสนองอื่นที่ Connection: Close ถูกส่งหลังจากไม่ได้ใช้งานเป็นเวลา 30 วินาที
TCP เริ่มต้นช้า
ตามที่กล่าวไว้ก่อนหน้านี้ TCP รองรับการควบคุมการไหล ซึ่งทำได้ผ่าน TCP Slow Start ซึ่งเป็นรูปแบบหนึ่งของการป้องกันความแออัดของเครือข่าย
ผู้ส่งมีหน้าต่างรับความแออัด (CWND) และผู้รับมีหน้าต่างรับ (RWND) หากข้อมูลมีขนาดใหญ่กว่าหน้าต่างความแออัด/ตัวรับ จะมีบัฟเฟอร์ต่ำกว่า/โอเวอร์รันตามลำดับ
เพื่อป้องกันสิ่งนั้น ผู้ส่งจะเริ่มต้นด้วยการส่งแพ็กเก็ตข้อมูลที่มีหน้าต่างความแออัดเล็กน้อย (CWND =1) เพื่อค่อยๆ ตรวจสอบตัวรับสำหรับหน้าต่างตัวรับ
ผู้รับจะตอบกลับด้วยการตอบรับ โดยแจ้งให้ผู้ส่งเพิ่มแพ็กเก็ตข้อมูลเป็นสองเท่าในแต่ละครั้งจนกว่าจะไม่ได้รับการตอบรับ ณ จุดนี้ มีการค้นพบจำนวนแพ็กเก็ตข้อมูลที่เหมาะสมที่สุด ซึ่งช่วยให้อัลกอริธึมควบคุมความแออัดอื่น ๆ สามารถรักษาการเชื่อมต่อที่ความเร็วนี้ได้
การทำงานร่วมกัน
ดังนั้น TCP Slow Start จึงสามารถคำนวณจำนวนแพ็กเก็ตข้อมูลที่เหมาะสมที่สุดที่จะส่งก่อนที่การเชื่อมต่อจะปิด ซึ่งจะทำให้ปริมาณข้อมูลที่ส่งจากโฮสต์ไปยังไคลเอนต์ได้รับการปรับให้เหมาะสมโดยไม่มีความเสี่ยงที่บัฟเฟอร์จะล้น (ข้อมูลจะถูกส่งเร็วกว่าที่สามารถรับได้)
คุณสมบัติ HTTP อื่นๆ
การวางท่อ HTTP
คุณลักษณะนี้ในเวอร์ชัน HTTP/1.1 ช่วยให้สามารถส่งคำขอหลายรายการพร้อมกันบนซ็อกเก็ตเดียวกัน โดยไม่ต้องรอการตอบกลับ อย่างไรก็ตาม ได้ถูกแทนที่ด้วย TCP Multiplexing ใน HTTP/2 เวอร์ชันใหม่กว่า
ข้อแตกต่างที่สำคัญคือ แม้ว่าทั้งสองจะอนุญาตให้มีการร้องขอหลายรายการพร้อมกันบนซ็อกเก็ตเดียวกัน แต่ Pipelining ยังคงต้องมีการตอบกลับตามลำดับ หมายความว่าหากสินค้าที่ร้องขออยู่ในคำสั่งซื้อ (A, B, C) ลูกค้าจะไม่ได้รับสินค้า C หากสินค้า B ไม่ได้รับการส่งมอบอย่างถูกต้อง
ในมัลติเพล็กซ์ ลำดับไม่สำคัญ ซึ่งจะช่วยให้สามารถจัดส่งได้เร็วขึ้น
วิธีการเหล่านี้เหมาะที่สุดสำหรับวิธี idempotent ซึ่งเป็นวิธีการที่ตอบสนองโดยไม่ขึ้นกับจำนวนครั้งที่ร้องขอ ตัวอย่างเช่น การขอหน้าเว็บหลายครั้งจะตอบสนองต่อหน้าเว็บเดียวกัน
การเชื่อมต่อแบบขนาน
เคยเปิดหน้าเว็บและเห็นส่วนประกอบต่างๆ ของหน้าเว็บ (แถบวิดีโอ รูปขนาดย่อ ปุ่ม) โหลดพร้อมกันหรือไม่
_การโหลดส่วนประกอบหลายรายการพร้อมกัน | ได้รับความอนุเคราะห์จาก [Cloudflare Mobile SDK](https://www.cloudflare.com/products/mobile-sdk/" rel="noopener" target="blank" title=")
สิ่งนี้เกิดขึ้นได้ด้วยการเชื่อมต่อแบบขนาน ซึ่งมีการเชื่อมต่อ TCP มากกว่าหนึ่งรายการที่สร้างขึ้นในเวลาเดียวกัน ทำให้ส่วนประกอบเหล่านี้สามารถโหลดพร้อมกันแทนที่จะเชื่อมต่อทีละรายการ
อย่างไรก็ตาม แม้ว่ามันอาจจะดูเหมือนโหลดเร็วขึ้น แต่อาจถูกระงับโดยแบนด์วิธที่จำกัดของไคลเอนต์ หากการเชื่อมต่อแบบขนานทั้งหมดแข่งขันกันเพื่อให้ได้แบนด์วิธที่จำกัด แต่ละส่วนประกอบจะโหลดช้าลงตามสัดส่วน ส่งผลให้ความเร็วในการโหลดทั้งหมดไม่มีข้อได้เปรียบ
บทสรุป
ด้วยโมเดล OSI เราจึงสามารถเข้าใจภาพรวมของเครือข่ายได้อย่างง่ายดาย และวิธีที่เครือข่ายเหล่านี้โต้ตอบกันตั้งแต่ฮาร์ดแวร์ไปจนถึงซอฟต์แวร์
โดยทั่วไปแล้ว มันเป็นเครื่องมือการสอนที่ยอดเยี่ยมและเป็นข้อมูลอ้างอิงสำหรับการแก้ไขปัญหา โมเดลยังมีประโยชน์สำหรับการออกแบบด้วย เนื่องจากมันจะตรวจสอบฟังก์ชันในทุกเลเยอร์ ทำให้เราต้องไตร่ตรองการออกแบบทีละเลเยอร์
สิ่งที่ฉันได้ผ่านมาจนถึงตอนนี้คือโมเดล OSI 5 เลเยอร์ ในขณะที่ยังมีโมเดล OSI 7 เลเยอร์ซึ่งเกี่ยวข้องกับการระบุตัวตน การรับรองความถูกต้อง และการเข้ารหัสข้อมูลด้วย
นี่คือส่วนที่ 2 ของซีรีส์การแนะนำ HTTP คุณสามารถอ่านบทความแรกเกี่ยวกับความสำคัญของเซิร์ฟเวอร์ DNS ได้ในส่วนที่ 1 มาสำรวจโครงสร้างของคำขอ HTTP ต่อไปในส่วนที่ 3!
สวัสดี! ฉันชื่อ Cher Don กำลังศึกษาวิชาเอกสาขาวิทยาศาสตร์ข้อมูล ฉันเป็น CTO ของ Paralegal Bot และคุณสามารถดูเว็บไซต์ของฉันได้ที่ด้านล่างนี้ ขอบคุณสำหรับการอ่าน!
ปิ๊ง;
_เนื้อหาคุณภาพ เรานำเสนอเนื้อหาที่ดีที่สุดสำหรับแนวคิดที่เข้าใจยาก เราเคยไปที่นั่น และรู้สึกแบบเดียวกับคุณ…_www.piqued.co
เรียนรู้การเขียนโค้ดฟรี หลักสูตรโอเพ่นซอร์สของ freeCodeCamp ช่วยให้ผู้คนมากกว่า 40,000 คนได้งานในตำแหน่งนักพัฒนา เริ่มต้น
