Proxy cho IoT: gateway, giao thức và hàng đợi mất mạng

Proxy cho IoT cần phù hợp với giao thức thiết bị, khả năng xử lý và cách hệ thống chịu mất mạng. ProxyVN cùng anh em phân biệt proxy chuyển tiếp với gateway và MQTT broker, thiết kế hàng đợi có giới hạn, quản lý danh tính từng thiết bị và lập bài kiểm tra khôi phục kết nối cho một mô hình cảm biến nhỏ.

Proxy cho IoT cần xuất phát từ giao thức thiết bị

Một cảm biến không nhất thiết gửi HTTP giống trình duyệt. Nó có thể phát bản tin MQTT, trao đổi CoAP hoặc dùng giao thức riêng của nhà sản xuất. Vì vậy, bước đầu tiên là xác định kết nối thực tế trước khi tìm nơi nhập địa chỉ proxy. Một máy chủ chỉ nhận HTTP không tự hiểu mọi bản tin phát ra từ mạng thiết bị.

Trong mô hình bài viết, các cảm biến nhiệt độ gửi dữ liệu tới một gateway tại nhà xưởng. Gateway chuyển tiếp tới dịch vụ trung tâm khi đường truyền cho phép. Đây là tình huống giả định để phân tích thiết kế và kiểm tra lỗi. Không có số đo hiệu năng hoặc tuyên bố đã triển khai mô hình này cho khách hàng của ProxyVN.

Phân biệt ba vai trò trung gian

Proxy chuyển tiếp giữ vai trò đại diện một đầu kết nối trong phạm vi giao thức mà nó hỗ trợ. Gateway có thể chuyển đổi định dạng hoặc nối hai giao thức khác nhau. MQTT broker lại quản lý cơ chế publish, subscribe và các phiên liên quan. Một sản phẩm có thể làm nhiều việc, nhưng anh em cần biết chức năng nào thực sự được bật và ai chịu trách nhiệm xử lý lỗi.

Nếu gateway nhận MQTT rồi tạo request HTTPS lên trung tâm, có hai quan hệ giao tiếp riêng. Bản tin thiết bị được broker chấp nhận chưa chứng minh request HTTPS đã tới trung tâm. Tương tự, phản hồi HTTP thành công chưa nói dữ liệu đã được ghi vào kho phân tích. Điểm xác nhận thành công phải gắn với yêu cầu nghiệp vụ, không chỉ với một chặng mạng.

Tài liệu MQTT 5.0 của OASIS là nguồn chuẩn cho cơ chế bản tin và phiên MQTT. Khi chọn thiết bị, hãy hỏi rõ nó hỗ trợ phiên bản nào, cách cấu hình chứng chỉ và hành vi sau mất điện. Nhãn hỗ trợ IoT trên sản phẩm không thay thế các thông tin tương thích cụ thể này.

Chọn vấn đề thật sự cần giải quyết

Anh em nên phân biệt nhu cầu quản lý đường ra, cách ly mạng thiết bị và chuyển đổi giao thức. Nếu chỉ cần cùng một địa chỉ gửi dữ liệu lên API, gateway có thể giữ kết nối HTTPS trực tiếp. Nếu cần kiểm soát đích được phép, bổ sung chính sách đường ra. Nếu cần đổi MQTT thành HTTP, phải có thành phần hiểu nội dung, không chỉ thêm một đường hầm TCP.

Với nhu cầu IP đường ra riêng, anh em có thể tham khảo mua proxy Việt Nam sau khi xác nhận ứng dụng gateway hỗ trợ giao thức tương ứng; phần mềm trên cảm biến không tự nhận proxy từ cấu hình máy gateway.

Proxy cho IoT trong kiến trúc cảm biến và gateway

Một mô hình dễ kiểm soát nên tách mạng cảm biến, gateway, broker và dịch vụ nhận dữ liệu. Thiết bị chỉ cần biết những địa chỉ thiết yếu để hoạt động. Gateway thực hiện chính sách gửi đi và lưu tạm theo giới hạn đã đặt. Dịch vụ trung tâm xác nhận bản tin theo một hợp đồng dữ liệu rõ ràng để việc gửi lại không tạo kết quả sai.

Mỗi chặng một giao thức

Giới hạn phạm vi tin cậy

Gateway có vị trí thuận lợi để điều phối kết nối nhưng cũng trở thành nơi tập trung thông tin của nhiều thiết bị. Không nên cho nó quyền sửa cấu hình mọi cảm biến chỉ vì nó cần nhận nhiệt độ. Hãy tách tài khoản đọc dữ liệu với tài khoản điều khiển, giới hạn đích kết nối và giảm các dịch vụ quản trị mở trên giao diện mạng thiết bị.

Một thiết bị bị chiếm quyền có thể gửi dữ liệu sai qua đường truyền được mã hóa hợp lệ. TLS xác thực đầu kết nối và bảo vệ đường truyền, nhưng không chứng minh nhiệt độ báo về là đúng với môi trường. Ứng dụng cần kiểm tra miền giá trị, nhịp phát, thứ tự thời gian và những bất thường phù hợp với loại cảm biến đang dùng.

Tách luồng dữ liệu và luồng điều khiển

Dữ liệu quan sát có thể chịu chậm trong một khoảng được chấp nhận, còn lệnh điều khiển thường cần biết còn hiệu lực hay không. Một lệnh mở van lưu trong hàng đợi nhiều giờ rồi phát lại sau khi mạng phục hồi có thể không còn phù hợp. Anh em cần thời hạn lệnh, mã nhận diện và xác nhận thực thi ở thiết bị, thay vì chỉ xác nhận đã gửi tới broker.

Đừng dùng cùng topic và cùng quyền cho việc đo nhiệt độ với cập nhật firmware. Cập nhật cần xác minh nguồn gói, điều kiện nguồn điện và khả năng quay lại phiên bản cũ. Proxy có thể chuyển tiếp tệp cập nhật nhưng không thay thế việc kiểm tra chữ ký ở thiết bị. Thiết kế luồng cập nhật riêng sẽ giúp cô lập hậu quả khi một thành phần trung gian gặp lỗi.

Một sơ đồ kiến trúc nên ghi nhãn giao thức trên từng mũi tên, vị trí chấm dứt TLS và nơi lưu dữ liệu chờ. Chỉ vẽ biểu tượng cảm biến nối với đám mây dễ làm người đọc bỏ qua hai hoặc ba chặng xác thực khác nhau. Khi sơ đồ đủ chi tiết, anh em sẽ nhìn thấy chỗ nào cần chứng chỉ, hàng đợi hoặc quy tắc tường lửa.

Proxy cho IoT với MQTT và CoAP có ranh giới rõ

MQTT và CoAP phục vụ những cách tương tác khác nhau. Đừng chọn chỉ dựa vào việc một giao thức nghe có vẻ nhẹ hơn. Cần xem loại dữ liệu, nhu cầu đăng ký nhận tin, độ ổn định của kết nối và thư viện thật sự có trên thiết bị. Việc chuyển đổi giữa hai giao thức còn cần định nghĩa cách ánh xạ lỗi và xác nhận.

Hiểu phạm vi của xác nhận MQTT

QoS mô tả cách chuyển giao bản tin trong phạm vi giao thức giữa các đầu tham gia. Nó không tự bảo đảm một phép tính nghiệp vụ chỉ được thực hiện một lần trong toàn bộ hệ thống. Gateway, hàng đợi HTTP và dịch vụ trung tâm có thể tạo thêm những điểm gửi lại. Vì vậy, mã bản tin ở tầng ứng dụng vẫn hữu ích để tránh lưu trùng khi xảy ra mất xác nhận.

Retained message cũng cần được hiểu riêng với lịch sử dữ liệu. Nó giúp subscriber nhận trạng thái lưu giữ phù hợp với topic, không biến broker thành kho chuỗi thời gian đầy đủ. Nếu muốn phân tích nhiệt độ trong nhiều ngày, cần một kho lưu trữ được thiết kế cho nhiệm vụ đó. Đừng suy ra rằng cấu hình lưu giữ đã đáp ứng yêu cầu truy xuất lịch sử.

Không ép CoAP qua một proxy HTTP thông thường

RFC 7252 về CoAP mô tả giao thức dành cho các nút và mạng có giới hạn tài nguyên, bao gồm cơ chế proxy riêng. Nếu cần nối CoAP với HTTP, gateway phải ánh xạ phương thức, mã phản hồi và tài nguyên. Một phép chuyển đổi thiếu rõ ràng có thể khiến lỗi thiết bị trở thành phản hồi thành công ở phía API.

Khi cần bảo vệ thông điệp qua các trung gian, RFC 8613 về OSCORE cung cấp một cơ chế ở tầng ứng dụng cho CoAP. Điều này khác với giả định mọi proxy đều được đọc nội dung. Đội thiết kế cần quyết định trung gian có quyền quan sát những trường nào trước khi giao cho nó nhiệm vụ lọc, sửa hoặc tổng hợp dữ liệu.

Proxy cho IoT và danh tính riêng từng thiết bị

Mật khẩu dùng chung cho cả nhà xưởng đơn giản lúc cài đặt nhưng khó thu hồi khi một thiết bị thất lạc. Tắt mật khẩu đó có thể làm nhiều cảm biến ngừng gửi. Danh tính riêng giúp giới hạn sự cố và tạo dấu vết rõ hơn khi kiểm tra. Tùy phần cứng, anh em có thể dùng chứng chỉ thiết bị hoặc thông tin xác thực riêng được quản lý đúng vòng đời.

Kiểm soát quyền trên topic

Thiết bị đo số 17 có thể chỉ cần gửi vào topic cảm biến của nó và nhận lệnh trong phạm vi được cấp. Nó không cần đọc toàn bộ dữ liệu của các thiết bị khác hoặc gửi vào topic quản trị. Cấp quyền theo danh tính đã xác thực giúp giảm phụ thuộc vào client ID do phía thiết bị tự khai báo trong một bản tin kết nối.

Tài liệu cấu hình Eclipse Mosquitto mô tả xác thực bằng chứng chỉ và cách dùng Common Name làm tên người dùng. Đoạn sau là khung tham khảo cho một listener TLS dùng chứng chỉ riêng. Các đường dẫn là chỗ cần thay bằng tệp đã cấp, không có khóa hay chứng chỉ thật đi kèm bài viết.

listener 8883
cafile /etc/mosquitto/ca.pem
certfile /etc/mosquitto/server.pem
keyfile /etc/mosquitto/server.key
require_certificate true
use_identity_as_username true
allow_anonymous false

Cấu hình này chưa cấp quyền topic hẹp cho từng thiết bị. Anh em phải bổ sung cơ chế phân quyền được phiên bản Mosquitto của mình hỗ trợ, rồi thử cả nhánh cho phép lẫn từ chối. Tài liệu hiện hành khuyến nghị giải pháp plugin cho một số cách quản lý ACL; không nên sao chép một tệp cấu hình từ bản cũ rồi mặc định mọi tùy chọn còn được khuyến nghị.

Danh tính riêng từng thiết bị

Chuẩn bị gia hạn trước ngày chứng chỉ hết hạn

Thiết bị ngủ lâu có thể không nhận cấu hình mới đúng lúc. Nếu chứng chỉ hết hạn trước khi nó kết nối lại, đường gia hạn cũng có thể bị chặn. Cần kế hoạch cho thời gian ngủ, đồng hồ thiết bị, khoảng chuyển tiếp CA và cách phục hồi có xác thực. Không nên tắt kiểm tra chứng chỉ hàng loạt để giải quyết một đợt hết hạn đã biết trước.

Baseline trong NIST IR 8259A về khả năng an ninh thiết bị IoT giúp đặt việc nhận dạng, cấu hình, bảo vệ dữ liệu và cập nhật vào cùng vòng đời. Proxy là một phần của hệ thống đó. Nó không sửa được firmware không còn cập nhật hoặc thiết bị không có cách xác minh phần mềm mới.

Proxy cho IoT cần hàng đợi có giới hạn khi mất mạng

Lưu tạm dữ liệu giúp gateway chịu được gián đoạn đường truyền nhưng không tạo thêm dung lượng vô hạn. Anh em phải chọn giới hạn theo số bản tin, tổng byte và tuổi dữ liệu. Khi chạm giới hạn, hệ thống cần hành vi rõ ràng: từ chối dữ liệu mới, loại dữ liệu cũ theo chính sách hoặc tổng hợp thông tin có kiểm soát.

Ví dụ sau minh họa hàng đợi SQLite cục bộ với mã sự kiện duy nhất và trần số bản tin. Hàm chỉ nhận dữ liệu đã được kiểm tra ở lớp ứng dụng; nó chưa triển khai MQTT, gửi HTTP, xác thực hay cơ chế chạy nền. Các con số giới hạn là giá trị minh họa do người viết chọn, cần tính lại theo thiết bị lưu trữ và yêu cầu giữ dữ liệu.

import json
import sqlite3
 
def open_queue(path):
    db = sqlite3.connect(path)
    db.execute("CREATE TABLE IF NOT EXISTS queue "
               "(id TEXT PRIMARY KEY, body TEXT NOT NULL)")
    return db
 def enqueue(db, event, limit=1000):
    body = json.dumps(event, ensure_ascii=False)
    if len(body.encode("utf-8")) > 4096:
        raise ValueError("event_too_large")
    db.execute("BEGIN IMMEDIATE")
    try:
        if db.execute("SELECT 1 FROM queue WHERE id=?",
                      (event["id"],)).fetchone():
            db.rollback()
            return False
        count = db.execute("SELECT COUNT(*) FROM queue").fetchone()[0]
        if count >= limit:
            raise OverflowError("queue_full")
        db.execute("INSERT INTO queue VALUES (?, ?)",
                   (event["id"], body))
        db.commit()
        return True
    except Exception:
        db.rollback()
        raise

Hàm dùng giao dịch ghi để kiểm tra trần và thêm bản tin trong một khối xử lý. Mã sự kiện trùng được giữ nguyên bản đã có, thay vì âm thầm ghi đè nội dung. Tuy nhiên, nếu cùng ID nhưng nội dung khác, lớp nhận dữ liệu nên ghi nhận xung đột để điều tra. Không nên coi mọi bản trùng là cùng một dữ liệu hợp lệ.

Xác nhận rồi mới xóa bản tin

Tiến trình gửi nên đọc bản tin chờ, gửi tới trung tâm và chỉ xóa khi nhận xác nhận đáp ứng hợp đồng. Khi timeout xảy ra sau lúc trung tâm đã lưu, gateway không biết kết quả cuối cùng. Nó sẽ gửi lại cùng ID, còn trung tâm cần nhận diện trùng trong một cửa sổ phù hợp. Đây là lý do mã sự kiện phải tồn tại qua lần gửi lại.

Ví dụ SQLite chỉ chống trùng khi ID còn trong hàng đợi. Sau khi bản tin được xóa, một lần gửi lại muộn có thể được thêm vào lần nữa. Muốn chống trùng lâu hơn phải có nhật ký ID đã xử lý hoặc dựa vào cơ chế idempotency ở trung tâm. Phạm vi của hai cơ chế cần được ghi rõ để không tuyên bố bảo đảm vượt quá khả năng triển khai.

Kiểm tra dữ liệu trước khi xếp hàng

Mỗi sự kiện nên có định danh thiết bị, ID sự kiện, thời gian quan sát, phiên bản schema và giá trị đo có kiểu dữ liệu rõ. Thiếu đồng hồ tin cậy thì lưu thêm thời gian gateway nhận bản tin, không giả vờ hai thời điểm là một. Kiểm tra giới hạn kích thước và miền giá trị trước khi ghi sẽ tránh để một thiết bị lỗi chiếm hết hàng đợi.

Proxy cho IoT khi gửi lại và khôi phục sau mất điện

Khôi phục đường truyền có thể gây một đợt dữ liệu dồn lên trung tâm. Nếu mọi gateway cùng gửi ngay toàn bộ phần tồn, hệ thống nhận dễ bị quá tải. Anh em cần giới hạn số kết nối, giới hạn tốc độ xả hàng và độ trễ gửi lại có phân tán. Mục tiêu là phục hồi có kiểm soát, không chỉ làm hàng đợi trống càng nhanh càng tốt.

Phân biệt lỗi tạm thời và lỗi dữ liệu

Lỗi kết nối hoặc phản hồi quá tải có thể phù hợp để gửi lại theo chính sách. Bản tin sai schema thường không sửa được bằng cách gửi thêm nhiều lần. Hãy chuyển bản tin lỗi sang vùng cách ly có giới hạn, lưu lý do và cho phép người vận hành xử lý. Nếu một bản lỗi nằm đầu hàng đợi mãi, nó có thể chặn cả dữ liệu hợp lệ phía sau.

Không sử dụng vòng lặp gửi vô hạn không nghỉ. Mỗi lần thử cần timeout, tổng thời gian hoặc số lần thử phù hợp và cách lưu trạng thái bền vững. Khi tiến trình khởi động lại, các giới hạn vẫn cần ý nghĩa; nếu mọi bộ đếm chỉ nằm trong RAM, việc khởi động liên tục có thể vô tình xóa lịch sử lỗi và tăng tải lên trung tâm.

Phục hồi dữ liệu có giới hạn

Tính cả sự cố bộ nhớ và ổ đĩa

Một gateway còn mạng nhưng hết chỗ lưu có thể mất dữ liệu âm thầm nếu chỉ kiểm tra trạng thái kết nối. Cần theo dõi dung lượng trống, lỗi ghi, số bản tin tồn và tuổi bản tin lâu nhất. Với thiết bị dùng thẻ nhớ, chính sách ghi và độ bền lưu trữ cũng quan trọng như tốc độ mạng. Không nên giữ log chi tiết vô hạn trên cùng phân vùng hàng đợi.

Khi kiểm tra mất điện, hãy xác định dữ liệu nào đã được ứng dụng chấp nhận trước thời điểm ngắt. Sau khởi động lại, đối chiếu các ID được xác nhận với bản tin còn chờ và bản tin trung tâm đã nhận. Một lần thử tiến trình đóng bình thường chưa đại diện cho mất nguồn đột ngột. Báo cáo cần gọi đúng loại sự cố đã mô phỏng và điều kiện lưu trữ đã dùng.

Hàng đợi chỉ hữu ích khi biết rõ giới hạn, điểm xác nhận và cách gửi lại; lưu được nhiều bản tin chưa chứng minh dữ liệu đến đúng nơi.

Proxy cho IoT với bộ kiểm tra từ thiết bị tới trung tâm

Bài kiểm tra nên đi theo đường dữ liệu thay vì chỉ ping gateway. Tạo một tập sự kiện nhỏ có ID biết trước, gửi qua từng chặng rồi đối chiếu ở trung tâm. Phân biệt thời điểm quan sát, nhận tại gateway và lưu tại trung tâm. Cách này cho thấy chặng nào đang chậm mà không cần suy đoán từ một con số độ trễ tổng.

Chạy các tình huống thất bại có kiểm soát

Đầu tiên thử một thiết bị hợp lệ và một thiết bị không có quyền để xác nhận lớp xác thực. Tiếp theo thử topic ngoài phạm vi, dữ liệu quá lớn và sự kiện sai schema. Sau đó ngắt đường gateway tới trung tâm trong môi trường thử, quan sát hàng đợi tăng rồi phục hồi. Không cần làm gián đoạn thiết bị sản xuất để kiểm tra các hành vi cơ bản này.

Thử hàng đợi đầy với giới hạn nhỏ để thấy rõ cách từ chối. Kiểm tra ứng dụng có báo lỗi cho phía gửi hay vẫn trả thành công. Nếu dữ liệu bị bỏ theo chính sách, phải có bộ đếm và dấu hiệu đủ điều tra. Một dashboard luôn xanh trong khi dữ liệu bị loại không giúp người vận hành biết hệ thống đang vượt khả năng thiết kế.

Kiểm tra đúng phạm vi ví dụ trong bài

Với hàm SQLite, có thể dùng cơ sở dữ liệu tạm để kiểm tra thêm mới, ID trùng, quá kích thước, hàng đợi đầy và khả năng đọc lại sau đóng mở. Các thử nghiệm này kiểm tra logic lưu tạm cục bộ. Chúng không chứng minh gateway thật chịu được mất điện, broker hỗ trợ toàn bộ cấu hình TLS hoặc trung tâm thực hiện idempotency đúng.

Mỗi biên bản nên ghi phiên bản firmware, thư viện giao tiếp, broker và cấu hình xác thực. Khi một thiết bị cũ không kết nối được, cần biết nó thiếu giao thức, không tin CA hay bị từ chối quyền. Việc gọi chung tất cả là lỗi proxy khiến anh em dễ đổi IP hoặc đổi cổng mà không tác động tới nguyên nhân thực tế.

Proxy cho IoT với kế hoạch mở rộng và bảo trì

Mở rộng từ vài cảm biến sang nhiều điểm lắp đặt đòi hỏi quản lý cấu hình và danh tính theo vòng đời. Anh em cần biết thiết bị thuộc địa điểm nào, ai chịu trách nhiệm và khi nào phải thu hồi khóa. Không nên để danh sách quản lý chỉ tồn tại trong tên file chứng chỉ hoặc ghi chú cá nhân của người lắp đặt ban đầu.

Vòng đời cảm biến và dữ liệu

Quản lý thay thế và ngừng sử dụng

Khi thay cảm biến, giữ nguyên mã nghiệp vụ của vị trí đo nhưng cấp danh tính kỹ thuật mới nếu đó là thiết bị mới. Việc tái sử dụng khóa riêng từ thiết bị cũ làm mất ý nghĩa của thu hồi. Trung tâm có thể ánh xạ nhiều đời thiết bị vào cùng một vị trí, nhưng cần lưu thời gian chuyển giao để dữ liệu lịch sử không bị hiểu nhầm.

Thiết bị ngừng sử dụng cần được thu hồi quyền kết nối và xóa bí mật theo khả năng phần cứng. Đồng thời kiểm tra hàng đợi còn dữ liệu cần giữ hay không. Ngắt kết nối mạng chưa đồng nghĩa đã chấm dứt quyền, vì thiết bị có thể được bật lại ở nơi khác. Quy trình ngừng sử dụng nên có bằng chứng ở cả kho quản lý và điểm xác thực.

Đối chiếu đồng hồ và thứ tự sự kiện

Một cảm biến vừa khởi động có thể gửi thời gian sai trong lúc chưa đồng bộ. Trung tâm nên giữ thời gian thiết bị quan sát và thời gian gateway nhận ở hai trường riêng, kèm trạng thái độ tin cậy của đồng hồ nếu có. Không ghi đè thời gian cũ bằng thời gian nhận rồi gọi đó là thời điểm đo. Sai khác này ảnh hưởng việc phát hiện ngưỡng và ghép sự kiện giữa nhiều cảm biến.

Nếu thiết bị có số thứ tự, xác định cách nó thay đổi khi khởi động lại. Một bộ đếm quay về đầu cần kết hợp với mã phiên khởi động hoặc cách tạo ID không xung đột. Chỉ dùng số thứ tự làm ID có thể khiến hàng đợi từ chối nhầm dữ liệu mới. Phép thử nên bao gồm hai lần khởi động và những sự kiện đến muộn từ lần trước.

Với dữ liệu điều khiển, thêm thời hạn sử dụng và phiên bản cấu hình mà lệnh dựa vào. Gateway không nên phát lại một lệnh đã hết hạn chỉ vì hàng đợi còn giữ. Khi loại lệnh cũ, hệ thống cần phản hồi trạng thái rõ cho bên gửi và lưu bằng chứng đủ xử lý. Việc giao lệnh thành công và việc thiết bị thực thi đúng là hai bước xác nhận khác nhau.

Chọn mức phức tạp phù hợp

Nếu một nhóm thiết bị gửi HTTPS trực tiếp ổn định, có cơ chế xác thực riêng và không cần chuyển đổi giao thức, thêm proxy có thể chỉ tạo một điểm lỗi mới. Nếu thiết bị bị giới hạn tài nguyên hoặc đường truyền thường gián đoạn, gateway có thể mang lại giá trị rõ hơn. Quyết định nên dựa vào yêu cầu dữ liệu và khả năng phục hồi đã kiểm tra.

Một thiết kế tốt cần trả lời được điều gì xảy ra với một sự kiện cụ thể từ lúc đo tới lúc được lưu. Anh em nên biết nó được xác thực ở đâu, chờ ở đâu, khi nào gửi lại và ai chịu trách nhiệm nếu bản tin hết hạn. Khi các câu trả lời rõ ràng, việc chọn giao thức hoặc nhà cung cấp đường truyền sẽ có cơ sở hơn.

Proxy cho IoT nên được chọn theo giao thức, danh tính và khả năng phục hồi dữ liệu của thiết bị. Hãy kiểm tra quyền topic, hàng đợi đầy và mất xác nhận trước khi mở rộng. Anh em có thể trao đổi cùng Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam về nhu cầu IP đường ra trong mô hình proxy cho IoT.