🌱 Tản mản về nền tảng OSI model cho sản phẩm IoT thực tế
Thực ra trước khi viết bài này, mình cũng từng nghĩ OSI model là một thứ gì đó khá "học thuật", kiểu học để thi là chính. Nhưng sau vài năm đi làm, khi đụng vào các hệ thống thực tế như IoT, Cloud, Gateway..., thì mới nhận ra là những thứ tưởng chừng lý thuyết này lại xuất hiện ở khắp mọi nơi.
Giống như bao anh em, khi đi học, mình biết về OSI model, tuy nhiên mức độ hiểu biết không được sâu. Thời điểm đó, mình chỉ nhớ kiểu học thuộc lòng: Layer 1 là Physical, Layer 2 là Data Link..., rồi thi xong là... quên gần hết 😄. Cũng chưa từng nghĩ là sau này khi làm sản phẩm thật, mình sẽ phải "đụng" vào nó nhiều như vậy.
Sau khi đi làm, khi được tiếp xúc trực tiếp với các sản phẩm thực tế, và mapping vào các kiến thức đã học, thì nghĩ lại, những kiến thức đó thật sự sâu sắc về mặt thiết kế và đang được áp dụng ở các hệ thống lớn.
Chính vì vậy, mình chia sẻ bài viết này để đưa ra những góc nhìn về OSI model theo hướng ứng dụng trong sản phẩm IOT.
↪ Mọi người nên đọc bài trước về "🌱 Tổng quan IOT Architecture thông qua ví dụ SmartHome"
1 - Nhắc lại OSI Model
Về mặt lý thuyết OSI Model, bạn có thể xem lại trong link bên dưới!
Link tham khảo: https://www.geeksforgeeks.org/computer-networks/open-systems-interconnection-model-osi/
Theo cách mình hiểu, OSI model là một framework chung được ISO tạo ra để mô tả cách dữ liệu được truyền tải quan mạng bằng kiến trúc 7 layer.
❓Tại sao cần nhiều layer như vậy khi truyền dữ liệu
Chúng ta sẽ phân tích từ layer thấp nhất của OSI, đó là Physical Layer. Về cơ bản, việc truyền dữ liệu giữa 2 thiết bị sẽ cần có kết nối vật lý nào đó, ví dụ kết nối có dây (CAN, Ethernet, ...) hoặc không dây (Wi-Fi, Bluetooth, Zigbee, ...).
Nhưng thực tế là chưa đủ!! Giả sử chỉ có kết nối vật lý thôi thì chuyện gì xảy ra?
⍰ Hai thiết bị có thể truyền tín hiệu điện cho nhau, nhưng làm sao biết dữ liệu nào thuộc về ai? ⍰ Làm sao biết dữ liệu có bị lỗi hay không? ⍰ Làm sao gửi dữ liệu đi xa qua nhiều mạng khác nhau? ⍰ Và quan trọng hơn, làm sao để ứng dụng phía trên hiểu được dữ liệu đó là gì?
↪ Đó chính là lý do OSI model chia nhỏ hệ thống truyền thông thành nhiều layer khác nhau. Mỗi layer đảm nhiệm một phần việc riêng, và layer phía trên chỉ cần quan tâm đến interface của layer phía dưới, không cần biết chi tiết implementation bên trong.
Nếu làm embedded lâu một chút, anh em sẽ thấy mô hình này rất giống với cách chúng ta thiết\ kế driver và middleware.
Ví dụ driver UART chỉ quan tâm đến thanh ghi phần cứng, còn middleware phía trên chỉ quan tâm đến việc gửi và nhận byte, không cần biết UART hoạt động chi tiết ra sao.
OSI model thực chất cũng là một cách "modular hóa" hệ thống mạng theo hướng rất kỹ thuật và có tính mở rộng cao.
2 - Ví dụ: Smart Device gửi nhiệt độ lên Cloud > Mobile App
Để dễ hình dung hơn, mình thử lấy một ví dụ khá quen thuộc trong IoT: Một thiết bị Smart Home gửi dữ liệu nhiệt độ từ sensor lên Cloud ➜ Mobile App.
Giả sử thiết bị có một chip Wi-Fi ESP32 đọc dữ liệu từ sensor nhiệt độ, sau đó gửi dữ liệu này lên MQTT Broker đặt trên Cloud. Mobile App sẽ subscribe topic và hiển thị nhiệt độ theo thời gian thực.
Note: Ví dụ này sẽ tập trung vào một số giao thức được chỉ định sẵn ở tầng Layer (như MQTT, TCP/IP). Thực tế hệ thống sẽ sử dụng các giao thức các nhau!
Chúng ta sẽ mapping vào OSI model, nói về giao tiếp giữa Device và Cloud Server, làm sao một dữ liệu nhiệt độ có thể truyền từ Device lên Server (và sau đó hiển thị đúng trên điện thoại).
Có thể hình dung như mô tả bên dưới, bạn nên nhìn vào 2 layer cao nhất và thấp nhất trước khi đi vào các layer trung gian.
🔻Layer 7 – Application
home/livingroom/temperature
Payload: 28.5
🔻Layer 6 – Presentation
Một số phương pháp encode: JSON, XML, Protobuf, CBOR, Base64, Encryption, Compression.
↪ Tại đây, giả sử sử dụng Json để encode dữ liệu:
Topic: home/livingroom/temperature
Payload: {"temp":28.5}
🔻Layer 5 – Session
↪ Do điểm tách biết không quá rõ dàng, nên đối với một số mô hình dựa theo TCP model, họ thường gộp Layer 7 / 6 / 5 và gọi chung là Application Layer.
🔻Layer 1 – Physical
Device sử dụng một chip Wi-Fi, ví dụ ESP32 sử dụng sóng Wi-Fi 2.4GHz để truyền tín hiệu vật lý đến Access Point (Thường được đảm nhận bởi Router Wi-Fi trong nhà). Sóng Wi-Fi 2.4GHz chính là tín hiệu vật lý dùng để truyền thông tin.
🔻Layer 2 – Data Link
Đối với trường hợp thiết bị truyền dữ liệu nhiệt độ, Access Point sẽ đóng gói bản tin cùng địa chỉ MAC của thiết bị để gửi lên Server, giúp Server phân biệt được ID của thiết bị gửi lên.
🔻Layer 3 – Network
Và đến đây, chúng ta có thể nhắn đến giao thức TCP/IP một lần nữa, hiểu đơn giản là giao thức để trao đổi dữ liệu thông qua mạng Internet, ở đây là giữa Router ⟺ Server.
🔻Layer 4 – Transport
Nếu packet bị mất, TCP sẽ tự động retransmit. Tại đây, TCP sẽ thêm TCP Header:
TCP Header:
Source Port: 52341
Destination Port: 1883
Sequence Number: 1001
Data:
MQTT PUBLISH (home/livingroom/temp, {"temp":28.5)
IP Header:
Source IP: 192.168.1.10 // ESP32
Destination IP: 34.120.88.10 // Cloud Server
Data:
TCP Segment
MAC Header:
Source MAC: AA:BB:CC:DD:EE:01
Destination MAC: AA:BB:CC:DD:EE:FF
Data:
IP Packet
sequenceDiagram
participant Sensor
participant ESP32
participant Router
participant Internet
participant Server
participant MobileApp
Sensor->>ESP32: Read temperature (28.5°C)
Note right of ESP32: Layer 6 - Convert to JSON
ESP32->>ESP32: {"temp":28.5}
Note right of ESP32: Layer 7 - MQTT Publish
ESP32->>Router: TCP/IP Packet (Wi-Fi)
Note right of Router: Layer 2 - MAC routing
Router->>Internet: IP Packet
Internet->>Server: Routed via IP
Note right of Server: Decapsulation MAC-IP-TCP-MQTT
Server->>MobileApp: MQTT Publish
MobileApp->>Server: Send command {"led":1}
Server->>Internet: TCP/IP Packet
Internet->>Router: Routed IP
Router->>ESP32: Wi-Fi Frame
ESP32->>ESP32: Parse JSON
ESP32->>ESP32: Turn LED ON
3 - Mobile App > Cloud Server điều khiển Device
Để dễ hình dung hơn, giả sử người dùng mở Mobile App và nhấn nút Turn ON LED để điều khiển thiết bị.
🔻Layer 7 – Application
Mobile App sẽ gửi một bản tin MQTT đến Cloud Server (MQTT Broker). Ví dụ:Topic: home/livingroom/led
Payload: {"led":1}
Cloud Server nhận bản tin này và publish lại đến tất cả các device đang subscribe topic tương ứng.🔻Layer 6 – Presentation
Dữ liệu điều khiển được encode dưới dạng JSON trước khi gửi đi. Trong một số hệ thống bảo mật cao, dữ liệu còn có thể được mã hóa bằng TLS (MQTTS) trước khi truyền qua Internet.Encoded Payload:
{"led":1}🔻Layer 5 – Session
Mobile App và Device đều duy trì MQTT session với Broker. Nếu mất mạng tạm thời và reconnect lại, session có thể được resume mà không cần subscribe lại topic. Điều này giúp giảm độ trễ khi reconnect và đảm bảo hệ thống hoạt động ổn định.🔻Layer 4 – Transport
MQTT tiếp tục sử dụng TCP để đảm bảo dữ liệu được truyền đầy đủ và đúng thứ tự. TCP sẽ thêm header vào bản tin:TCP Header:
Source Port: 52341
Destination Port: 1883
Sequence Number: 2055
Data:
MQTT PUBLISH (home/livingroom/led, {"led":1})🔻Layer 3 – Network
IP Header được thêm vào để định tuyến bản tin từ Cloud Server đến đúng thiết bị trong mạng nội bộ.IP Header:
Source IP: 34.120.88.10 // Cloud Server
Destination IP: 192.168.1.10 // ESP32
Data:
TCP Segment🔻Layer 2 – Data Link
Router trong nhà (Access Point) sẽ sử dụng địa chỉ MAC để gửi frame đến đúng thiết bị trong mạng Wi-Fi.MAC Header:
Source MAC: AA:BB:CC:DD:EE:FF
Destination MAC: AA:BB:CC:DD:EE:01
Data:
IP Packet🔻Layer 1 – Physical
Cuối cùng, dữ liệu được truyền dưới dạng sóng Wi-Fi 2.4GHz từ Router đến thiết bị ESP32.Sau khi nhận được bản tin, ESP32 sẽ thực hiện quá trình decapsulation theo thứ tự ngược lại:
- Nhận frame Wi-Fi
- Đọc IP Packet
- Xử lý TCP Segment
- Nhận MQTT Message
- Parse JSON
- Thực hiện lệnh: Turn LED ON
💤 Nhận xét
Một điều khá thú vị là khi làm việc với hệ thống thực tế, anh em sẽ nhận ra rằng chúng ta hiếm khi làm việc với toàn bộ 7 layer cùng lúc. Thông thường, mỗi nhóm kỹ sư sẽ tập trung vào một số layer nhất định.
Ví dụ với anh em Embedded, phần lớn thời gian sẽ làm việc với các layer thấp: Physical, Data Link và một phần Network. Chúng ta quan tâm đến driver Wi-Fi, Ethernet, CAN, hoặc cách cấu hình IP, socket,...
Trong khi đó, phía Backend hoặc Cloud thường làm việc nhiều hơn với Application Layer như MQTT Broker, HTTP API hoặc database.
Chính việc chia layer rõ ràng như vậy giúp các team có thể làm việc song song, mà không cần phải hiểu toàn bộ hệ thống từ đầu đến cuối. Đây cũng là một trong những điểm mạnh nhất của OSI model trong thiết kế hệ thống lớn.
Kết luận
Nhìn lại thì OSI model không chỉ là một mô hình lý thuyết để học thuộc, mà thực sự là một cách tư duy khi thiết kế hệ thống truyền thông.
Khi hiểu rõ từng layer đang làm gì, chúng ta sẽ dễ dàng debug hệ thống hơn. Ví dụ khi thiết bị không gửi được dữ liệu lên Cloud, chúng ta có thể lần lượt kiểm tra:
- Wi-Fi có kết nối không?
- Có IP chưa?
- TCP có connect được không?
- MQTT có publish thành công không?
Hy vọng bài viết mang tính tản mạn này giúp anh em có thêm một góc nhìn gần gũi hơn về OSI model, đặc biệt là khi làm việc với các hệ thống IoT thực tế.
>>>>>> Follow ngay <<<<<<<
Để nhận được những bài học miễn phí mới nhất nhé 😊
Chúc các bạn học tập tốt 😊
