9.20. สรุป

คุณได้เดินผ่านเลเยอร์ต่าง ๆ ที่ข้อความเครือข่ายต้องผ่านระหว่างทางจาก กล้อง ไปยังส่วนที่เหลือของโลก:

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

  • โมเดลแบบเลเยอร์ -- ห้าเลเยอร์ แต่ละเลเยอร์แก้ปัญหาหนึ่งและเสนอ interface ที่สะอาดให้กับเลเยอร์ถัดไป เลเยอร์ physical และ link จัดการบิตและเฟรมระหว่างเพื่อนบ้านโดยตรง เลเยอร์เครือข่ายจัดการการกำหนดที่อยู่และการกำหนดเส้นทางทั่วอินเทอร์เน็ต เลเยอร์การส่งจัดการการส่งจากโปรแกรมไปยังโปรแกรม และโปรโตคอลแอปพลิเคชันสร้างบนทั้งหมดนั้น

  • เลเยอร์ล่าง -- Ethernet และ Wi-Fi เป็นเทคโนโลยีลิงก์ที่ใช้งานจริง MAC address ระบุฮาร์ดแวร์บน segment ท้องถิ่น โมดูล network ของ กล้อง เปิดเผยปุ่มหนึ่งที่ควรรู้: เครือข่าย Wi-Fi ใดที่จะเข้าร่วม หลังจากนั้นทุกอย่างด้านล่างเป็นอัตโนมัติ

  • เลเยอร์เครือข่าย (IP) -- ที่อยู่ IPv4 และ IPv6 ระบุโฮสต์โดยไม่ขึ้นกับสายที่เสียบ เราเตอร์ hop แพ็กเก็ตระหว่าง segment ท้องถิ่นจนกว่าจะมาถึง ช่วงที่อยู่ private และ NAT คือเหตุผลที่เครือข่ายบ้านและออฟฟิศมีพื้นที่ที่อยู่ภายในของตัวเองและที่อยู่ public ที่ใช้ร่วมกันหนึ่งที่อยู่ที่ขอบ การรับส่งข้อมูลขาออกทำงานได้อย่างอิสระ ขาเข้าต้องการความช่วยเหลือ

  • เลเยอร์การส่ง -- port ระบุ โปรแกรม ภายในโฮสต์ คู่ (IP, port) เต็มระบุ socket เฉพาะหนึ่งรายการ UDP เป็นเลเยอร์บาง ๆ ที่ส่ง datagram ที่บรรจุในตัวเองครั้งละหนึ่งรายการโดยไม่มีการรับประกัน -- รวดเร็ว ประหยัด และเป็นเครื่องมือที่ถูกต้องเมื่อการสูญหายเป็นที่ยอมรับ TCP เป็นสตรีมไบต์ที่เชื่อถือได้ เรียงลำดับ แบบ connection-oriented -- เป็นเครื่องมือหลักสำหรับการสื่อสารทางอินเทอร์เน็ตส่วนใหญ่ โดยจ่ายด้วยเวลาแฝงของการจับมือกันหนึ่ง round-trip

  • Python API -- socket.socket คือ class เดียวสำหรับทั้งสองโปรโตคอล sendto() / recvfrom() สำหรับ UDP รูปแบบ connect-or-listen บวก send() / recv() สำหรับ TCP socket จับคู่ได้สะอาดกับ asyncio: asyncio.open_connection() และ asyncio.start_server() มอบคู่ reader/writer ให้กับทุกการเชื่อมต่อ TCP ดังนั้นการสนทนาพร้อมกันหลายรายการจึงใช้ event loop หนึ่งร่วมกันโดยไม่ต้อง threading

  • ชื่อและเวลา -- socket.getaddrinfo() แปลงชื่อเช่น example.com ให้เป็นที่อยู่ IP ที่พร้อมส่งให้ socket network.hostname() ตั้งชื่อของ cam เอง ซึ่งเราเตอร์ลงทะเบียนภายใต้ DNS ท้องถิ่นของพวกเขาและ mDNS responder ในตัวของ cam ตอบสนองเป็น <name>.local ntptime.settime() คือแนวคิดเดียวกัน "ค้นหาสิ่งหนึ่งบนเครือข่าย" ที่ใช้กับเวลาของนาฬิกา โดยตั้งค่านาฬิกาในตัวเป็น UTC จาก NTP server สาธารณะ

  • การเข้ารหัส -- ssl ห่อ socket ด้วย TLS cam มาพร้อมโดยไม่มีที่เก็บ certificate authority ดังนั้นโดยค่าเริ่มต้นคุณจะได้รับการเข้ารหัสเท่านั้น -- การสนทนาไม่อยู่ในรูปแบบธรรมดาอีกต่อไป แต่ cam ไม่ตรวจสอบว่าใครตอบ สำหรับการพิสูจน์ตัวตนจริง -- การตรวจสอบ HTTPS server สาธารณะ การเรียกใช้ cam เป็น TLS server mutual TLS -- workflow ที่ใช้ certificate ครอบคลุมใน การทำงานกับ TLS certificate DTLS (TLS บน UDP) ใช้โมดูลเดียวกันในลักษณะเดียวกัน

  • โปรโตคอลแอปพลิเคชันจริง -- MQTT เป็นตัวอย่างที่ทำงานจริงของทุกเลเยอร์ด้านล่างที่เชื่อมต่อกัน ไบต์ type-and-flags ขนาด 1 ไบต์ ฟิลด์ remaining-length แบบ variable-length ฟิลด์ UTF-8 topic ที่มีความยาว prefix และ payload ทั้งหมดเดินทางผ่าน TCP (และเลือกใช้ภายใน TLS) ไปยัง broker ที่กระจายข้อความให้กับทุก subscriber บน topic นั้น client mqtt ในตัวห่อรูปแบบ wire ในรูปแบบ API connect / publish / subscribe ที่เล็กพอจะอ่านในครั้งเดียว

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

9.20.1. การใช้งานข้อมูลอ้างอิงนี้ในภายหลัง

ใช้บทเครือข่ายเป็นเนื้อหาอ้างอิง การกลับมาดูรูปแบบของ UDP listener หรือรูปแบบ TLS-with-asyncio เป็นการใช้งานที่ตั้งใจไว้ หน้าอ้างอิง network --- การกำหนดค่าเครือข่าย, socket --- socket module, ssl --- โมดูล SSL/TLS, และ ntptime --- ไคลเอนต์ NTP แบบง่าย แสดงรายการทุก method, flag และ constant ในที่เดียวเมื่อคำถามคือเพียง "ชื่อที่แน่นอนของการเรียกนี้คืออะไร"

9.20.2. จะไปที่ไหนต่อจากนี้

เว็บเซิร์ฟเวอร์ คือหัวข้อหลักถัดไป ด้วย socket ที่ทำงานได้และ TLS พร้อมใช้งาน เลเยอร์ถัดขึ้นไปตามธรรมชาติคือโปรโตคอลที่สร้างบนนั้น ได้แก่ HTTP สำหรับให้บริการเนื้อหาและ API, WebSockets สำหรับเก็บการเชื่อมต่อเปิดทั้งสองทาง และ framework ขนาดเล็กที่ซ่อน boilerplate ทุกอย่างจากส่วนนี้ยังคงมีผลต่อไป -- เว็บเซิร์ฟเวอร์ท้ายที่สุดก็เป็นแค่ TCP server ที่พูด HTTP บน socket ที่รับแล้ว บ่อยครั้งมี TLS ห่อทั้งหมด