CoAP (Constrained Application Protocol, Giao thức Ứng dụng cho Môi trường Hạn chế)

1. Tổng quan

A. Định nghĩa

CoAP (Constrained Application Protocol) là một giao thức tầng ứng dụng RESTful nhẹ được nhóm công tác IETF CoRE chuẩn hóa (RFC 7252, 2014) dành cho các thiết bị hạn chế (constrained device) và mạng hạn chế (mạng công suất thấp, dễ mất gói, LLN) vốn bị giới hạn nghiêm trọng về bộ nhớ, năng lực tính toán, điện năng và băng thông. Trong khi kế thừa mô hình hướng tài nguyên (REST) của HTTP, nó hoạt động trên UDP thay vì TCP và nén tiêu đề xuống còn 4 byte, nhờ đó các thiết bị đầu cuối Internet vạn vật (IoT) có thể giao tiếp theo cách giống Web với tài nguyên tối thiểu.

Điểm khởi đầu để hiểu CoAP là nhận thức thực tế rằng "không thể dùng HTTP cho IoT y nguyên". HTTP, vốn nâng đỡ Web, giả định các tiêu đề văn bản hàng chục đến hàng trăm byte, một bắt tay ba bước TCP để thiết lập kết nối, và chi phí duy trì trạng thái. Thế nhưng các thiết bị hạn chế như cảm biến và cơ cấu chấp hành phải trụ được nhiều năm với vài chục KB RAM, vài trăm KB flash và một pin cúc áo, còn mạng mà chúng nằm trong đó là mạng không dây (6LoWPAN, Zigbee, NB-IoT, v.v.) với băng thông vài kbps và tỷ lệ mất gói cao. Trong môi trường như vậy, chi phí kết nối và tiêu đề nặng nề của HTTP/TCP lập tức dẫn thẳng đến tiêu hao điện năng và rút ngắn tuổi thọ. CoAP được tạo ra chính để lấp khoảng cách này, với triết lý thiết kế "giữ lại sự quen thuộc của REST, nhưng cắt giảm chi phí truyền tải đến mức tối đa".

Kết quả là CoAP cung cấp ba giá trị cấu trúc. Thứ nhất, với tiêu đề cố định 4 byte và nền tảng UDP, nó tối thiểu hóa chi phí phụ trội và tiêu thụ điện năng. Thứ hai, vì là một mô hình REST dùng trực tiếp GET/POST/PUT/DELETE cùng URI và kiểu phương tiện, nó có độ tương thích khái niệm cao với các nhà phát triển và hệ thống Web hiện có, và có thể xử lý tài nguyên IoT với cùng lối tư duy như [[rest-api]]. Thứ ba, để bù cho tính không tin cậy của UDP, nó tự xếp chồng độ tin cậy tùy chọn (truyền lại, loại trùng) và quan sát bất đồng bộ (Observe) tại tầng thông điệp, qua đó bảo đảm một chất lượng giao tiếp nhẹ nhưng vẫn dùng được.

B. Đặc điểm chính

CoAP có các đặc điểm cốt lõi là: (1) truyền tải nhẹ dựa trên UDP (cổng mặc định 5683, bảo mật qua CoAPs dựa trên DTLS 5684), (2) tiêu đề cố định 4 byte và mã hóa nhị phân, (3) mô hình tài nguyên REST (phương thức, URI, mã phản hồi), (4) bốn loại thông điệp CON/NON/ACK/RST cùng Message ID và Token, và (5) các mở rộng đặc thù IoT như Observe (đăng ký thay đổi tài nguyên), Block-wise (truyền tải chia nhỏ khối lượng lớn), và khám phá tài nguyên (/.well-known/core). Các đặc điểm này cài khớp vào nhau: sự nhẹ nhàng của UDP cho phép công suất thấp, còn khoảng trống độ tin cậy nảy sinh từ đó được tầng thông điệp và các tính năng mở rộng bù đắp.

Đặc biệt ở khía cạnh định dạng biểu diễn (kiểu phương tiện), CoAP cung cấp một tùy chọn Content-Format tương ứng với Content-Type của HTTP, và ưa chuộng không chỉ văn bản và JSON mà còn CBOR (Concise Binary Object Representation), một định dạng nhị phân được tối ưu cho môi trường hạn chế. Mã hóa tải trọng bằng CBOR thay vì JSON dài dòng giúp giảm mạnh số byte, nên lợi ích của việc làm nhẹ tiêu đề kéo dài cả vào phần thân. Nghĩa là "sự nhẹ nhàng" của CoAP không dừng lại ở riêng tiêu đề mà xuyên suốt nhất quán qua toàn bộ ngăn xếp—tầng truyền tải (UDP), tiêu đề (4 byte), thân (CBOR) và bảo mật (OSCORE/COSE)—như một triết lý làm nhẹ toàn ngăn xếp, và điều này cho thấy độ hoàn chỉnh của thiết kế.

C. Bối cảnh ra đời và sự cần thiết

Đằng sau việc chuẩn hóa CoAP là sự bùng nổ số lượng thiết bị đầu cuối IoT vào khoảng năm 2010 và nhu cầu tích hợp chúng một cách tự nhiên vào hệ sinh thái Web. Các giao thức nhẹ như MQTT đã tồn tại ngay khi đó, nhưng MQTT là mô hình xuất bản/đăng ký (pub/sub) lấy broker làm trung tâm, vốn khác về bản chất so với mô hình hướng tài nguyên của Web là "nhận dạng một tài nguyên bằng URI rồi truy vấn hoặc thay đổi trạng thái của nó". IETF hướng tới một "Web of Things" trong đó hàng tỷ cảm biến đều được đối xử như một tài nguyên Web đơn lẻ, và vì thế cần một giao thức ánh xạ được về mặt ngữ nghĩa (mappable) với HTTP nhưng vẫn chạy được trong môi trường hạn chế.

Động lực thứ hai là giới hạn vật lý của thiết bị hạn chế. RFC 7228 phân loại thiết bị hạn chế theo RAM và kích thước mã thành Class 0 (≤10KB RAM), Class 1 (~10KB) và Class 2 (~50KB), và thiết bị Class 1 không đủ dư địa để nạp trọn một ngăn xếp TLS/HTTP. CoAP được thiết kế để có thể hiện thực trong vài KB mã ngay cả trên những thiết bị như vậy, giúp giao tiếp Web an toàn khả thi trong ngân sách điện năng và bộ nhớ. Thứ ba là đối phó với mạng dễ mất gói. Vì mất gói và trùng lặp là chuyện thường trong mạng không dây công suất thấp, CoAP đã hiện thực độ tin cậy tối thiểu trực tiếp trên UDP, không cần TCP, thông qua loại trùng dựa trên Message ID và truyền lại với lùi lũy thừa của thông điệp CON.

Ba động lực này mang tính củng cố lẫn nhau hơn là độc lập. Nhu cầu tích hợp Web dẫn tới mô hình REST, giới hạn thiết bị đòi hỏi UDP và tiêu đề nhị phân, còn mạng dễ mất gói sinh ra các cơ chế độ tin cậy của tầng thông điệp. Việc ba yếu tố đồng thời chỉ về "một giao thức nhẹ nhưng tương thích Web" là điều đã xác lập CoAP thành một trục của các chuẩn IoT.

Một điểm cần lưu ý ở đây là CoAP không tìm cách "thay thế" MQTT mà cung cấp một hệ hình giao tiếp khác. Nếu MQTT là "đường ống truyền dòng (streaming) dữ liệu" thì CoAP gần với "tay nắm thao tác (manipulating) tài nguyên" hơn. Mô hình hướng tài nguyên của CoAP là tự nhiên khi tương tác cần đọc ngay giá trị hiện tại của một cảm biến, đặt trạng thái của một cơ cấu chấp hành về một giá trị cụ thể, và nhận dạng tài nguyên đó bằng một URI duy nhất. Khác biệt này là lý do căn bản để về sau hai giao thức cùng tồn tại thông qua phân chia vai trò chứ không phải cạnh tranh.

2. Cấu trúc giao thức CoAP

CoAP là một giao thức đơn lẻ, nhưng điều mấu chốt là hiểu nó như được chia nội bộ thành hai phân tầng. Tầng thông điệp (Message Layer) phía dưới phụ trách độ tin cậy và loại trùng của thông điệp trên UDP, còn tầng yêu cầu/phản hồi (Request/Response Layer) phía trên phụ trách ngữ nghĩa REST (phương thức, token, mã phản hồi). Nhờ cấu trúc kép này, có thể xử lý tách biệt độ tin cậy (có truyền lại hay không) và ngữ nghĩa (yêu cầu có thành công hay không). Sơ đồ cấu trúc tổng thể dưới đây cho thấy vị trí của CoAP trong ngăn xếp giao thức và quan hệ giữa hai phân tầng.

flowchart TB
  APP["Ứng dụng IoT(tài nguyên cảm biến·cơ cấu chấp hành)"]
  subgraph COAP["CoAP"]
    RR["Tầng yêu cầu/phản hồi(REST: phương thức·token·mã phản hồi)"]
    MSG["Tầng thông điệp(CON·NON·ACK·RST, loại trùng·truyền lại Message ID)"]
    RR --- MSG
  end
  SEC["DTLS / OSCORE(tùy chọn bảo mật)"]
  UDP["UDP (mặc định 5683 / bảo mật 5684)"]
  NET["IP·6LoWPAN·không dây công suất thấp(LLN)"]
  APP --> RR
  MSG --> SEC
  SEC --> UDP
  UDP --> NET
  style COAP fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style SEC fill:#fef3e8,stroke:#ed8f2f,stroke-width:1px

Điểm đáng chú ý trong cấu trúc này là CoAP được thiết kế để ánh xạ một-một với HTTP. Vì các phương thức (GET, POST, PUT, DELETE) và mã phản hồi (2.xx thành công, 4.xx lỗi phía máy khách, 5.xx lỗi phía máy chủ) tuân theo cùng hệ ngữ nghĩa với HTTP, đặt một proxy CoAP-HTTP tại ranh giới sẽ cho phép thiết bị đầu cuối CoAP bên trong mạng hạn chế và dịch vụ HTTP trên Internet liên thông trong suốt qua phiên dịch. Đây là lợi thế quyết định để ghép nối thiết bị IoT vào hạ tầng Web và đám mây hiện có.

Tuy nhiên không được hiểu lầm sự tách biệt hai tầng này. "Thành công (nhận được ACK)" của tầng thông điệp và "thành công (phản hồi 2.xx)" của tầng yêu cầu/phản hồi là hai sự kiện riêng biệt. Một ACK rỗng cho một yêu cầu CON chỉ có nghĩa là "thông điệp đã đến", chứ không phải "yêu cầu đã được xử lý", và kết quả xử lý thực tế được truyền bằng mã phản hồi theo sau (trong trường hợp phản hồi tách rời). Nhờ sự tách biệt này, máy chủ có thể thực hiện xử lý dài một cách bất đồng bộ trong khi vẫn báo ngay cho mạng rằng "tôi còn sống", nhưng người hiện thực phải cẩn thận không lẫn lộn trạng thái của hai tầng mà nhầm "ACK = xử lý hoàn tất". Đây là một trong những sai lầm thường mắc trong thiết kế ứng dụng CoAP.

A. Tiêu đề thông điệp và các định danh

Một thông điệp CoAP bắt đầu bằng tiêu đề cố định 4 byte. Nó gồm Phiên bản (2 bit), Kiểu (2 bit), Độ dài Token (4 bit), Mã (8 bit, phương thức hoặc mã phản hồi) và Message ID (16 bit), tiếp theo là Token, Các tùy chọn (đường dẫn URI, truy vấn, định dạng nội dung, v.v.) và Tải trọng. Hai định danh đóng vai trò cốt lõi ở đây. Message ID được dùng tại tầng thông điệp để lọc nhận trùng và đối ứng một ACK với một thông điệp cụ thể, còn Token được dùng tại tầng yêu cầu/phản hồi để ghép đôi phản hồi nào thuộc về yêu cầu nào. Nếu Message ID là "nhãn của đơn vị truyền tải" thì Token là "nhãn của cuộc đối thoại logic"; vì hai cái được tách ra nên ngay cả các phản hồi bất đồng bộ đến muộn—như phản hồi tách rời (separate response) giải thích bên dưới—cũng được ghép đúng.

Tùy chọn (Option) đi sau tiêu đề truyền các siêu dữ liệu tương ứng với tiêu đề HTTP, và để tiết kiệm byte, nó được mã hóa bằng cách chỉ ghi giá trị hiệu (delta) của số hiệu tùy chọn. Uri-Path và Uri-Query biểu diễn đường dẫn tài nguyên và truy vấn, Content-Format biểu diễn định dạng tải trọng, ETag biểu diễn tính hợp lệ của bộ nhớ đệm, Max-Age biểu diễn thời hạn lưu đệm, và Observe biểu diễn việc đăng ký. Thiết kế truyền chỉ các siêu dữ liệu cần thiết, nén theo số hiệu như vậy, chính là điều tạo ra khác biệt chi phí phụ trội quyết định so với HTTP, vốn mang lặp lại các tiêu đề văn bản.

B. Bốn loại thông điệp

Tầng thông điệp cung cấp một phổ độ tin cậy trên UDP qua bốn loại: CON, NON, ACK và RST. CON (Confirmable) là truyền tải tin cậy, được truyền lại với lùi lũy thừa cho đến khi nhận được ACK của bên nhận. NON (Non-confirmable) là truyền tải không tin cậy, dùng cho dữ liệu mà mất một hai cái cũng không sao, như báo cáo cảm biến định kỳ. ACK (Acknowledgement) là xác nhận nhận của một CON, còn RST (Reset) là tín hiệu từ chối gửi khi không thể xử lý một thông điệp (ví dụ, mất ngữ cảnh do khởi động lại). Việc cho phép chọn độ tin cậy theo từng đơn vị truyền tải như vậy là một thiết kế phản ánh kinh tế học của môi trường hạn chế: "ép buộc độ tin cậy mức TCP cho mọi giao tiếp thì tốn kém".

Việc truyền lại CON được thiết kế để hội tụ về các tham số đã định chứ không tùy tiện. Theo mặc định, nó định điểm truyền lại đầu tiên bằng cách pha nhiễu ngẫu nhiên vào thời gian chờ ban đầu (ACK_TIMEOUT, khoảng 2 giây), rồi nhân đôi thời gian chờ mỗi lần và bỏ cuộc sau khi chỉ thử tới số lần truyền lại tối đa (MAX_RETRANSMIT, mặc định 4 lần). Đặt một trần như vậy là để ngăn sụp đổ do tắc nghẽn, trong đó truyền lại vô hạn trên một mạng mất gói nặng sẽ ngược lại làm tê liệt mạng và cạn kiệt điện năng. Ngoài ra, khi gửi yêu cầu tới nhiều máy chủ cùng lúc (ví dụ, multicast), còn có một quy tắc để trải rộng độ trễ (Leisure) sao cho các phản hồi không dồn đến một lúc, qua đó kiểm soát nhẹ nhàng tắc nghẽn trong mạng hạn chế ngay cả khi không có TCP. Theo cách này, CoAP có đặc trưng là tái hiện việc kiểm soát tắc nghẽn phức tạp của tầng truyền tải bằng "các quy tắc tối thiểu" ở mức giao thức ứng dụng.

3. Mô hình yêu cầu/phản hồi và các tính năng đặc thù IoT

Yêu cầu/phản hồi của CoAP diễn ra theo hai cách dưới truyền tải tin cậy (CON). Nếu máy chủ có thể xử lý yêu cầu ngay, nó gửi phản hồi cõng trên ACK—phản hồi cõng (piggybacked); nếu xử lý mất thời gian, trước tiên nó chỉ xác nhận việc nhận bằng một ACK rỗng rồi sau đó gửi kết quả trong một CON riêng—phản hồi tách rời (separate response). Sơ đồ tuần tự dưới đây cho thấy hai cách và việc ghép token. Mấu chốt là ngay cả trên tính vô trạng thái của UDP, cả độ tin cậy lẫn tính bất đồng bộ đều đạt được thông qua sự phân công giữa Message ID và Token.

sequenceDiagram
  participant C as Máy khách
  participant S as Máy chủ(cảm biến)
  Note over C,S: Phản hồi cõng(xử lý tức thì)
  C->>S: CON [MID=1, Token=A] GET /temperature
  S-->>C: ACK [MID=1, Token=A] 2.05 Content "21.5"
  Note over C,S: Phản hồi tách rời(xử lý trễ)
  C->>S: CON [MID=2, Token=B] GET /slow-sensor
  S-->>C: ACK [MID=2] (xác nhận rỗng)
  S->>C: CON [MID=9, Token=B] 2.05 Content "data"
  C-->>S: ACK [MID=9]

A. Observe — Đăng ký thay đổi tài nguyên

Trong yêu cầu/phản hồi của HTTP, để biết trạng thái máy khách phải thăm dò (poll) lặp đi lặp lại, và thăm dò là một sự lãng phí điện năng trên thiết bị hạn chế. CoAP giải quyết điều này bằng tùy chọn Observe (RFC 7641). Khi máy khách gắn tùy chọn Observe vào một yêu cầu GET, máy chủ "đăng ký quan sát" tài nguyên đó và chủ động đẩy một thông báo (notification) mỗi khi giá trị tài nguyên thay đổi. Điều này hiện thực một hiệu ứng gần với xuất bản/đăng ký theo kiểu đầu-cuối mà không cần broker, cho phép giao tiếp theo sự kiện ở công suất thấp, như một cảm biến nhiệt độ chỉ báo cáo khi vượt ngưỡng. Mỗi thông báo mang một số thứ tự (sequence number) để phát hiện đảo thứ tự, và máy chủ có thể hủy đăng ký quan sát tùy theo giới hạn bộ nhớ của nó.

Lý do Observe hiệu quả về điện năng hơn thăm dò là rõ ràng về mặt định lượng. Thăm dò mỗi phút gây ra một vòng khứ hồi yêu cầu/phản hồi mỗi phút ngay cả khi giá trị không đổi, buộc thiết bị phải thức dậy, trong khi Observe chỉ phát sinh lưu lượng khi thực sự có thay đổi, nên trong một mạng cảm biến ở trạng thái ổn định, lượng giao tiếp và số lần thức dậy giảm hàng chục lần. Tuy nhiên, vì máy chủ phải giữ trạng thái đăng ký trong bộ nhớ, một số lượng người quan sát quá lớn có thể làm cạn tài nguyên của thiết bị hạn chế, và nếu một thông báo bị mất do mất kết nối mạng thì có rủi ro máy khách tin vào một giá trị cũ. Do đó các thông báo thường được gửi định kỳ dưới dạng CON để kiêm việc kiểm tra tính sống (liveness), và thiết kế để máy khách truy vấn lại một khi Max-Age đã trôi qua. Theo cách này, Observe là một tính năng phải cân nhắc cả "hiệu quả của việc đẩy" lẫn "độ tin cậy của việc đồng bộ trạng thái".

B. Block-wise Transfer — Truyền tải chia nhỏ khối lượng lớn

Gói dữ liệu UDP bị giới hạn kích thước, và MTU của mạng hạn chế cũng nhỏ (6LoWPAN là hàng chục đến hàng trăm byte), khiến khó gửi một ảnh firmware hay dữ liệu cảm biến lớn trong một lần. Truyền tải Block-wise (RFC 7959) chia một biểu diễn lớn thành nhiều khối và truyền tuần tự, thương lượng số khối, kích thước và việc có khối tiếp theo hay không qua các tùy chọn Block1 (thân yêu cầu) và Block2 (thân phản hồi). Qua đó, các truyền tải lớn được thực hiện một cách tin cậy ở mức tầng ứng dụng mà không cần phân mảnh IP (fragmentation), và vì khi mất chỉ cần truyền lại khối bị mất nên nó hiệu quả. Cập nhật OTA firmware là một ví dụ sử dụng tiêu biểu. Chẳng hạn, chia một firmware 256KB thành các khối 64 byte sẽ cho ra hàng nghìn khối; nếu phó mặc cho phân mảnh IP thì mất chỉ một mảnh cũng đòi truyền lại toàn bộ, trong khi Block-wise chỉ cần nhận lại khối bị mất, giảm mạnh chi phí truyền lại trên mạng không dây mất gói nhiều. Vì kích thước khối được thương lượng cho khớp với bộ đệm và MTU của thiết bị, thiết bị càng bị hạn chế nặng càng có thể chọn khối nhỏ hơn để tránh áp lực bộ nhớ.

C. Khám phá tài nguyên và lưu đệm

CoAP công bố danh sách tài nguyên mà máy chủ cung cấp tại đường dẫn /.well-known/core theo CoRE Link Format (RFC 6690), để máy khách tự động khám phá có những tài nguyên nào. Nó cũng mang một tùy chọn Max-Age trong phản hồi để nêu rõ khoảng thời gian có thể lưu đệm, nhờ đó một proxy có thể đệm các giá trị cảm biến được truy vấn thường xuyên để giảm số lần thức dậy của thiết bị và tải mạng. Đặt một Resource Directory (RFC 9176) cho phép các tài nguyên của những thiết bị ngủ chập chờn (sleepy) được đăng ký và tìm kiếm tập trung, giúp việc quản lý thiết bị quy mô lớn dễ dàng hơn.

Điều quan trọng là lưu đệm và proxy là một chiến lược sinh tồn cho thiết bị hạn chế vượt lên trên việc chỉ tối ưu hiệu năng đơn thuần. Thiết bị chạy pin dành phần lớn thời gian để ngủ và chỉ thức dậy trong chốc lát, nên nếu mọi máy khách truy vấn trực tiếp thiết bị thì thiết bị thức dậy không ngơi nghỉ và pin cạn nhanh chóng. Nếu một proxy trả về phản hồi thay cho nó trong suốt Max-Age, thiết bị có thể ngủ suốt khoảng thời gian đó, kéo dài tuổi thọ đáng kể. Theo cách này, lưu đệm của CoAP, bên cạnh việc tối ưu kiểu HTTP là "không xử lý cùng một yêu cầu hai lần", còn mang theo ý đồ thiết kế từ góc độ điện năng là "không đánh thức thiết bị hạn chế".

4. So sánh: CoAP vs MQTT vs HTTP

Chính xác là nên xem ba giao thức như những thứ bổ sung có lĩnh vực áp dụng khác nhau chứ không phải những đối thủ cạnh tranh. Bảng dưới đây tóm tắt các khác biệt, nhưng mấu chốt nằm ở "vì sao" những khác biệt đó nảy sinh. Lựa chọn mô hình giao tiếp (yêu cầu/phản hồi vs xuất bản/đăng ký) và tầng truyền tải (UDP vs TCP) làm nảy sinh một chuỗi khác biệt về độ tin cậy, tính thời gian thực và khả năng mở rộng.

Hạng mục	CoAP	[[mqtt]]	HTTP
Tầng truyền tải	UDP(+DTLS)	TCP(+TLS)	TCP(+TLS)
Mô hình giao tiếp	Yêu cầu/phản hồi(REST) + Observe	Xuất bản/đăng ký(qua broker)	Yêu cầu/phản hồi(REST)
Tôpô	Đầu-cuối(P2P), có thể proxy	Lấy broker làm trung tâm(nhiều-nhiều)	Máy khách–máy chủ
Chi phí phụ trội tiêu đề	Rất thấp(4 byte)	Thấp(2 byte~)	Cao(tiêu đề văn bản)
Độ tin cậy	Tùy chọn(CON/NON)	QoS 0·1·2	Được TCP bảo đảm
Lĩnh vực phù hợp	Truy vấn·điều khiển tài nguyên của thiết bị hạn chế	Telemetry nhiều-nhiều kết nối chập chờn	Web·đám mây với tài nguyên dồi dào

Khác biệt ở tầng truyền tải đặc biệt mang tính quyết định. Việc CoAP chọn UDP không phải chỉ là làm nhẹ mà vì tính hướng-kết-nối của TCP không phù hợp với thiết bị hạn chế. TCP đòi hỏi trạng thái và bộ nhớ để thiết lập và duy trì kết nối, gây chặn đầu hàng (HOL blocking) vốn chặn toàn bộ luồng từ đầu khi mất gói, và đòi tái lập kết nối mỗi lần một thiết bị ngủ chập chờn thức dậy. Ngược lại, UDP vô trạng thái, nên một thiết bị có thể thức dậy bất cứ lúc nào, gửi chỉ một thông điệp rồi ngủ lại, và chỉ truyền lại các thông điệp bị mất một cách có chọn lọc. Nghĩa là UDP + độ tin cậy nhẹ vốn dĩ hợp với "một cảm biến thỉnh thoảng thức dậy để trao đổi một hai thông điệp" hơn là TCP, vốn giả định "hai máy chủ luôn kết nối". Đây là lý do căn bản để CoAP đi một con đường khác với HTTP trong khi dùng cùng một mô hình REST.

Hàm ý thực tiễn là rõ ràng. CoAP có lợi thế cho điều khiển cảm biến/cơ cấu chấp hành nơi việc truy vấn và điều khiển tài nguyên bằng URI cùng tương tác đầu-cuối độ trễ thấp là quan trọng, trong khi MQTT dựa trên broker có lợi thế cho telemetry và giám sát vốn thu gom trạng thái của nhiều thiết bị một cách tập trung rồi phân phối cho nhiều bên tiêu thụ. Trên thực tế, hai giao thức thường được dùng chung, nên một kiến trúc lai là phổ biến, trong đó cảm biến hiện trường được điều khiển bằng CoAP còn dữ liệu thu thập được đẩy lên đám mây qua MQTT tại cổng kết nối. HTTP được dùng ở các phân đoạn cổng kết nối và đám mây nơi không có ràng buộc tài nguyên, kết nối với mạng hạn chế qua một proxy CoAP-HTTP. Rốt cuộc, ba giao thức không phải là "những đối thủ phải chọn lấy một" mà là "các thành phần được bố trí theo từng phân đoạn", và thiết kế đúng đắn là kết hợp chúng đúng chỗ tùy theo việc một phân đoạn nhất định đòi hỏi ràng buộc tài nguyên, tính thời gian thực, độ phân tán (fan-out) hay bảo mật.

Dẫu vậy, cũng phải nhận thức rõ các giới hạn của CoAP. Thứ nhất, vì dựa trên UDP nên việc vượt NAT và tường lửa khá rắc rối. Nhiều mạng doanh nghiệp chặn UDP 5683 hoặc để ánh xạ NAT hết hạn sớm, nên có nhiều ràng buộc đối với giao tiếp băng qua Internet công cộng. Thứ hai, nó yếu ở độ phân tán (fan-out) quy mô lớn. Vì là một mô hình đầu-cuối không có broker, MQTT pub/sub phù hợp hơn để phân phối một mẩu dữ liệu tới rất nhiều bên tiêu thụ cùng lúc. Thứ ba, độ trưởng thành về hệ sinh thái và công cụ của nó tương đối nông so với HTTP và MQTT, nên có rào cản gia nhập về mặt thư viện và kinh nghiệm vận hành. Do đó, CoAP nên được định vị không phải là "thuốc chữa bách bệnh cho mọi IoT" mà là "một công cụ chuyên biệt được tối ưu cho giao tiếp hướng tài nguyên của các thiết bị hạn chế".

5. Chuyên sâu — Bảo mật và xu hướng mới nhất

CoAP đã phát triển những giải pháp riêng của mình cho bài toán khó là làm sao đạt được bảo mật trong môi trường hạn chế, vượt lên trên việc chỉ là một giao thức nhẹ. Bảo mật của CoAP về mặt lịch sử lấy DTLS (Datagram TLS) làm nền tảng. CoAPs (cổng 5684) được cấu hình bằng DTLS, vốn cung cấp tính bảo mật, toàn vẹn và xác thực ngang với TLS trên UDP, và nó hỗ trợ các chế độ PSK (khóa chia sẻ trước), RPK (khóa công khai thô) và chứng chỉ làm phương thức xác thực. Tuy nhiên, bắt tay DTLS vẫn còn nặng trên thiết bị hạn chế, và đặc biệt có một vấn đề cấu trúc là đi qua một proxy CoAP-HTTP sẽ cắt đứt DTLS tại proxy và phá vỡ tính bảo mật đầu-cuối. Vì proxy phải thấy bản rõ để phiên dịch yêu cầu, chỉ riêng bảo mật truyền tải không thể bảo vệ "chính thông điệp" theo kiểu đầu-cuối.

Thứ xuất hiện để giải bài toán này là OSCORE (Object Security for Constrained RESTful Environments, RFC 8613). Vì OSCORE mã hóa và xác thực chính thông điệp CoAP (đối tượng) bằng CBOR và COSE chứ không phải tầng truyền tải, một proxy trung gian chỉ thấy các tùy chọn ngoài mà nó cần cho định tuyến, trong khi tải trọng và phương thức nhạy cảm được chuyển tới điểm cuối vẫn trong tình trạng được mã hóa. Nghĩa là nếu DTLS "bảo vệ đường đi (hop-by-hop)" thì OSCORE "bảo vệ nội dung (đầu-cuối)", cung cấp bảo mật đầu-cuối trong môi trường đa proxy và bộ đệm. Để thiết lập khóa, nó kết hợp EDHOC (RFC 9528), một giao thức trao đổi khóa có xác thực nhẹ, để thiết lập khóa phiên một cách hiệu quả ngay trên thiết bị hạn chế. Điều này đồng điệu với lối tư duy của [[zero-trust]] ở chỗ lấy chính dữ liệu, chứ không phải đường truyền tải, làm đơn vị tin cậy.

DTLS và OSCORE không phải là một lựa chọn loại trừ nhau mà được dùng song song và bổ sung tùy theo tình huống. Với một kết nối trực tiếp một chặng, chỉ DTLS là đủ, trong khi với nhiều chặng nơi một proxy hay bộ đệm xen vào, cũng khả thi một kiểu phòng thủ kép trong đó OSCORE bảo vệ tải trọng theo kiểu đầu-cuối còn DTLS bảo vệ bổ sung các phân đoạn chặng. Mấu chốt là sự phán đoán về ranh giới tin cậy—"có thể tin đường đi hay phải bảo vệ chính dữ liệu"—vốn đồng điệu với xu hướng của các kiến trúc bảo mật hiện đại là không tin cậy các nút trung gian.

Ba xu hướng mới nhất nổi bật lên. Thứ nhất, đa dạng hóa truyền tải. RFC 8323 làm cho việc chạy CoAP trên cả TCP, TLS và WebSocket trở nên khả thi, mở ra một lối để giao tiếp trong khi vẫn giữ ngữ nghĩa CoAP ngay cả ở các phân đoạn mạng doanh nghiệp và đám mây nơi UDP bị chặn. Thứ hai, kết hợp với các nền tảng IoT dựa trên chuẩn. Khi OMA LwM2M, một chuẩn quản lý thiết bị nhẹ, chọn CoAP làm truyền tải của mình, các trường hợp thực hiện quản lý firmware, điều khiển từ xa và giám sát theo cách được chuẩn hóa trên CoAP đang lan rộng khắp ngành công nghiệp. Thứ ba, tích hợp biên và cổng kết nối. Cấu hình trong đó một cổng kết nối [[edge-computing]] tiếp nhận các thiết bị đầu cuối CoAP và chuyển tiếp lên trên qua HTTP/MQTT đang trở nên phổ biến, và CoAP đang củng cố vai trò của mình như "giao thức hướng tài nguyên của biên hiện trường".

Từ góc độ áp dụng công nghiệp, CoAP được dùng trong điều khiển tòa nhà thông minh và chiếu sáng, đo đếm thông minh, mạng cảm biến công nghiệp, mạng cảm biến không dây nông nghiệp, v.v. Chẳng hạn, người ta điều khiển hàng nghìn nút chiếu sáng công suất thấp một cách riêng lẻ bằng URI trong khi đăng ký các thay đổi trạng thái qua Observe để giám sát tiêu thụ năng lượng mà không cần thăm dò. Về mặt số liệu, so với gửi cùng một thông điệp qua HTTP, CoAP có chi phí phụ trội tiêu đề và kết nối nhỏ hơn vài lần, tạo ra lợi thế rõ rệt về tuổi thọ pin và băng thông (hiệu quả thực tế thay đổi theo kích thước tải trọng, tần suất truyền và phương thức không dây, nên cần đo đạc trước khi áp dụng).

Một trường hợp hệ sinh thái chuẩn tiêu biểu là OMA LwM2M (Lightweight M2M). Khi một nhà mạng hoặc nền tảng IoT quản lý từ xa hàng triệu thiết bị đầu cuối, LwM2M dùng CoAP làm truyền tải để định nghĩa đăng ký thiết bị, cập nhật firmware, cấu hình từ xa và báo cáo trạng thái kết nối như một mô hình tài nguyên chuẩn. Nhờ đó, các thiết bị đầu cuối từ những nhà sản xuất khác nhau được quản lý qua cùng một giao diện CoAP/LwM2M, cho phép vận hành một đội thiết bị (fleet) quy mô lớn mà không bị khóa chặt vào nhà cung cấp. Trong đo đếm thông minh cũng vậy, một cấu hình xếp chồng CoAP/LwM2M lên IoT di động (NB-IoT) để thu thập dữ liệu đo đếm ở công suất thấp được áp dụng rộng rãi, điều này cho thấy CoAP đang được triển khai trong các vận hành thương mại quy mô lớn, vượt lên trên việc chỉ là một giao thức nghiên cứu.

6. Cân nhắc và hàm ý

Việc đưa CoAP vào sử dụng không phải là một lựa chọn đơn giản "dùng một giao thức nhẹ" mà là một quyết định kiến trúc trải suốt mô hình giao tiếp, bảo mật, môi trường mạng và hệ thống vận hành. Đặc biệt, vì nhiều thiết bị IoT có tuổi thọ vượt quá 10 năm, một giao thức và phương thức bảo mật đã chọn sẽ bị cố định trong thời gian dài, nên hiệu ứng lan tỏa của thiết kế ban đầu là lớn. Các cân nhắc cần phán đoán một cách chiến lược từ góc độ Kỹ sư chuyên nghiệp như sau.

Phán đoán sự phù hợp của mô hình giao tiếp (CoAP vs MQTT): Nên chọn trên cơ sở "có truy vấn và điều khiển tài nguyên bằng URI hay không (yêu cầu/phản hồi)" so với "có thu gom dữ liệu của nhiều thiết bị một cách tập trung rồi phân phối hay không (xuất bản/đăng ký)". Thay vì một chọn-một, một thiết kế lai phân chia điều khiển hiện trường cho CoAP và thu thập hướng lên cho MQTT là phổ biến, và đặt một cổng chuyển đổi giao thức tại ranh giới là thực tế.
Đối phó với ràng buộc UDP, NAT và tường lửa: Nền tảng UDP của CoAP là điểm mạnh bên trong mạng hạn chế nhưng trở thành điểm yếu—hết hạn ánh xạ NAT và chặn tường lửa—khi băng qua Internet công cộng. Nếu phải băng qua mạng công cộng, nên thiết kế đồng thời CoAP-over-TCP/WebSocket của RFC 8323, chuyển tiếp qua cổng kết nối, hoặc đường hầm, và thiết lập một chiến lược duy trì NAT (keep-alive).
Thiết kế mức bảo mật và bảo vệ đầu-cuối: Với giao tiếp một chặng đơn giản thì DTLS là đủ, nhưng với nhiều chặng đi qua proxy và bộ đệm, OSCORE ở mức bảo mật thông điệp phải bảo đảm tính bảo mật và toàn vẹn đầu-cuối. Nên chọn chế độ PSK/RPK/chứng chỉ có cân nhắc cả gánh nặng quản lý khóa, vòng đời chứng chỉ và làm mới firmware của thiết bị hạn chế, và cùng xem xét trao đổi khóa nhẹ như EDHOC.
Điều chỉnh đánh đổi độ tin cậy–điện năng: CON cho độ tin cậy nhưng dùng nhiều điện năng hơn qua truyền lại, còn NON thì nhẹ nhưng chấp nhận mất mát. Tùy theo mức quan trọng, chu kỳ và tỷ lệ mất cho phép của dữ liệu, nên tinh chỉnh loại thông điệp và chu kỳ Observe theo từng nhiệm vụ, thiết kế điểm cân bằng giữa tuổi thọ pin và tính trọn vẹn của dữ liệu.
Tận dụng tính liên thông và hệ sinh thái chuẩn: Kết hợp với các chuẩn ở mức cao hơn như LwM2M, CoRE Resource Directory và CoRE Link Format—thay vì chỉ CoAP đơn lẻ—mới làm cho việc quản lý, khám phá và vận hành thiết bị dễ dàng hơn. Để tránh bị khóa chặt vào nhà cung cấp, nên chọn các hiện thực tuân thủ chuẩn và nêu rõ các quy tắc ánh xạ CoAP-HTTP (RFC 8075, v.v.) để bảo đảm khả năng liên thông với hạ tầng Web và đám mây hiện có.

Nhìn về phía trước, giao tiếp IoT nhiều khả năng sẽ hội tụ không phải về một sự độc quyền giao thức đơn lẻ mà về một tổ hợp phân tầng biên (CoAP)–thu thập (MQTT)–đám mây (HTTP). CoAP, với tư cách trục cốt lõi chịu trách nhiệm giao tiếp hướng tài nguyên của các thiết bị hạn chế trong tầng đó, sẽ phát triển theo hướng tăng cường bảo mật và tính liên thông thông qua bảo mật đầu-cuối nhẹ dựa trên OSCORE/EDHOC và đa dạng hóa truyền tải. Đối với một Kỹ sư chuyên nghiệp, năng lực cốt lõi trở thành không phải "giao thức nào tốt hơn" mà là khả năng thiết kế "đâu là tổ hợp đúng đắn cho nhiệm vụ, môi trường mạng và yêu cầu bảo mật này".

Tài liệu tham khảo

IETF, "RFC 7252: The Constrained Application Protocol (CoAP)", https://www.rfc-editor.org/rfc/rfc7252
IETF, "RFC 7641: Observing Resources in the CoAP", https://www.rfc-editor.org/rfc/rfc7641
IETF, "RFC 7959: Block-Wise Transfers in CoAP", https://www.rfc-editor.org/rfc/rfc7959
IETF, "RFC 8613: Object Security for Constrained RESTful Environments (OSCORE)", https://www.rfc-editor.org/rfc/rfc8613
IETF, "RFC 8323: CoAP over TCP, TLS, and WebSockets", https://www.rfc-editor.org/rfc/rfc8323

Tóm tắt một câu: CoAP là một giao thức IoT RESTful nhẹ chạy trên UDP với tiêu đề 4 byte; nó cung cấp độ tin cậy tùy chọn qua các thông điệp CON/NON và token, hỗ trợ môi trường hạn chế bằng Observe, Block-wise và khám phá tài nguyên, và tích hợp các thiết bị hạn chế vào hệ sinh thái Web qua bảo mật DTLS/OSCORE và ánh xạ HTTP.