Beschreibung des Herzschlagpakets und des Registrierungspakets in 4G-DTUs, seriellen Port-Servern und anderen IoT - Übertragungsmodulen

Quelle: Modbus Chinesisches Netzwerk (modbus.cn) - führende Modbus Kommunikationsprotokoll Technologie-Community in China

Dieser Artikel: Internet der Dinge Übertragungsmodule Herzschlag Paket und Registrierung Paket: Mechanismus, Design und Fehlerbehebung · Autor: Modbus-Technik - Team · Veröffentlicht am 2026 - 07 - 01

Zusammenfassung: 4G DTU, serieller Server, Edge-Gateway und andere Internet der Dinge Übertragungsmodule, Herzschlag Paket und Registrierung Paket sind die wichtigsten Mechanismen für die Aufrechterhaltung der Verbindungsstabilität und Gerät Identität. Dieser Artikel erklärt den Herzschlagmechanismus von TCP KeepAlive, MQTT KeepAlive, Anwendungsebene benutzerdefinierter Herzschlag auf drei Ebenen; vom DTU-Registrierungspaket bis zur Cloud-Plattform - Geräte-Authentifizierung und Kämmerung Registrierungsmechanismus, mit Parameter-Berechnungsformeln, Codebeispielen und Fehlerbehebungsschritten. Schlagwörter: Heartbeat Pack, Registrierungspaket, 4G DTU, Keep Alive, MQTT Heartbeat, TCP Live, Geräte-Registrierung.

Ein Stück 4G DTU in die SIM-Karte stecken, mit seriellen Anschlussparametern, verbinden Sie sich mit dem Server - Daten, Sie denken, es ist fertig. Nach einer Nacht, am nächsten Tag zu finden, dass das Gerät offline war, aber die Signallampe war noch auf. Wieder starten, gut. In ein paar Tagen wieder aus dem Netz.

Das ist ein typisches Problem bei langen Verbindungen. Im IoT-Szenario sind Geräte im ganzen Land verteilt, einige in abgelegenen Bergregionen, andere in Kellern. Die Kommunikationsverbindung geht vom seriellen Anschluss des Geräts über das 4G-Modul der DTU, über das NAT-Gateway des Betreibers und über das öffentliche Netzwerk zu Ihrem Cloud-Server. Jede Verbindung auf diesem Link könnte Ihre Verbindung töten, aber Sie werden nicht benachrichtigt.

Dieser Artikel erklärt das Herzbeat - und Registrierungspaket vom Prinzip bis zum Einsatz - nicht nur das Konzept, sondern auch die Parameter, den Code und die Fehlerbehebungsmethoden, die Sie direkt in Ihrem Projekt verwenden.

Warum die lange Verbindung unterbrochen wird

Bevor wir über Herzschläge sprechen, sollten wir herausfinden, wie lange Verbindungen abbrechen - aus verschiedenen Gründen, die verschiedenen Strategien entsprechen, um das Leben zu erhalten.

Betreiber NAT Timeout. Die 4G-DTU verwendet eine private IP für das Mobilfunknetz (10.x.x.x / 100.x.x.x) und kann über das NAT-Gateway des Betreibers auf das öffentliche Netzwerk zugreifen. Um Ressourcen zu sparen, setzt ein NAT-Gateway eine Zeitüberschreitung für freie Verbindungen ein. Typische Werte der drei großen inländischen Betreiber:

• China Mobile: 5 Minuten
• China Unicom: etwa 2 - 3 Minuten
• China Telecom: etwa 3 - 5 Minuten

Die NAT-Timeout - Zeit für verschiedene Regionen und verschiedene Paketkarten ist nicht ganz gleich, aber im Grunde liegen sie zwischen 2 - 5 Minuten. Wenn über diese Zeit hinaus kein Paket durchläuft, wird der Zuordnungsaufzeichnis auf dem NAT-Gateway gelöscht. Wenn der Server später einen Vertrag an die DTU senden wollte, erkennt das NAT-Gateway das Paket nicht mehr und verwerft es direkt - das Gerät scheint noch online zu sein (4G-Anbindung ist normal), aber der Datenkanal ist tot.

Firewall / ZwischengeräteDie Export-Firewall eines Unternehmensnetzwerks bereinigt in der Regel auch leere TCP-Verbindungen. Ein industrieller Steuergerät hat über WiFi Zugang zum Intranet des Unternehmens und unterhält eine Modbus-TCP - Verbindung zum Cloud-Server. Wenn keine Kommunikation für eine halbe Stunde besteht, markiert die überzeugende / Huawei-Firewall in der Mitte den Status dieser Verbindung als abgelaufen und freigegeben. Der Server glaubt, dass das Gerät noch verbunden ist, und das Gerät glaubt, dass der Server noch da ist - das ist „Auslöschung".

Gerät wurde außergewöhnlich abgeschaltet。Stromausfall von Geräten vor Ort, 4G-Signalverlust, Neustart des Switches - in diesen Fällen erhält der Gegenüber der TCP-Verbindung kein FIN-Paket. Die vier Schichten haben kein Signal getrennt, und die Anwendungsschicht kann nicht wahrgenommen werden. Wenn Sie sich nicht auf die Herzschlagerkennung verlassen, wird der Server immer davon ausgehen, dass das Gerät online ist, und die Planungsaufgabe wird wie gewohnt ausgeliefert und alle Zeitüberschreiten.

TCP HalbverbindungDas eine Ende der TCP-Verbindung ist abgeschaltet (z. B. der Server wurde neu gestartet), das andere Ende ist nicht bekannt und befindet sich immer noch im Keep-alive - Zustand. Dies ist ein Standard-Szenario "halbige Verbindung".

Zweite und dreistufige Aufrechterhaltung Mechanismen: TCP KeepAlive, MQTT KeepAlive, Anwendungsschicht Herzschlag

Es gibt drei Ebenen der Preservation, die unterschiedlichen Szenarien und Granularität entsprechen.

2.1 KeepAlive in der TCP-Protokollschicht - die unterste, am wenigsten flexibel

Der TCP-Stack enthält einen KeepAlive-Mechanismus. Wenn die Verbindung innerhalb der angegebenen Zeit keine Datenübertragung erfolgt, sendet der Betriebssystemkernel automatisch ein Sondepaket (leere ACK) an das Gegenüber und wartet darauf, dass das Gegenüber antwortet. Wenn das Gegenüber am Leben ist, antwortet er mit einem ACK; wenn er tot ist, schließt er die Verbindung nach mehreren ergebnislosen Tests.

Die drei wichtigsten Parameter des Linux-Kernels:

net.ipv4.tcp_keepalive_time = 7200    # 首次探测前的空闲时间（秒），默认 2 小时
net.ipv4.tcp_keepalive_intvl = 75     # 探测间隔（秒），默认 75 秒
net.ipv4.tcp_keepalive_probes = 9     # 探测次数，默认 9 次

Das bedeutet, dass eine TCP-Verbindung nach 2 Stunden 11 Minuten 15 Sekunden (7200 + 75 × 9) unterbrochen wird, bevor das Betriebssystem die Anwendungsschicht benachrichtigt: "Diese Verbindung ist tot". Diese Zeit ist für das IoT-Szenario völlig unbrauchbar - wenn Sie feststellen, dass das Gerät offline ist und die Batterie des Geräts zweimal ausgetauscht wurde.

Sie können kürzere Parameter für ein einzelnes Socket im Code festlegen (Linux ≥ 2.6.37 unterstützt):

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
# 以下三个参数需要 Linux 2.6.37+ 且 socket 为 IPPROTO_TCP
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)    # 60 秒空闲后开始探测
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 10)   # 每 10 秒探测一次
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)      # 3 次无响应判定断开

Auf diese Weise konfiguriert wird die Entdeckungszeit für die Verbindung = 60 + 10 × 3 = 90 Sekunden.

Aber TCP KeepAlive hat zwei tödliche Fehler.。

Erstens kann es nur erkennen, ob eine TCP-Verbindung von Ende zu Ende überlebt und nicht erkennen, ob die Zwischengeräte zwischen Ende zu Ende (NAT-Gateways, Firewalls) die Verbindung bereinigt haben. Sonde-Pakete fließen nur zwischen den TCP-Stacks an beiden Endpunkten und aktualisieren möglicherweise keine NAT-zuweisenden Einträge, wenn sie über das NAT-Gateway gehen - das heißt, die TCP-Schicht hält die Verbindung für normal, aber die NAT-Kanäle hat den Kanal geschlossen.

Zweitens, der Standardwert von 2 Stunden ist zu lang, und die Änderung der Parameter wird nur für das aktuelle Socket wirksam, und die Maschine wechselt wieder zur Standardkonfiguration. Und die Änderung von Parametern erfordert Root-Rechte, und der Kernel eines eingebetteten Geräts (DTU, serieller Port-Server) unterstützt möglicherweise nicht dynamische Änderungen.

TCP KeepAlive kann also nur als Hilfsmittel im IoT-Szenario dienen und kann nicht den Herzschlag der Anwendungsschicht ersetzen.

2.2 MQTT-Keep Alive - Standardisierung der Anwendungsschicht

Das MQTT-Protokoll definiert ein 16 - Bit-Keep Alive - Feld in Sekunden in einer CONNECT-Nachricht. Dieser Mechanismus ist näher an die Anforderungen der Anwendungsschicht als TCP KeepAlive:

• Der Client muss mindestens eine Kontrollnachricht während der Keep Alive-Zeit senden (es kann PUBLISH, SUBSCRIBE, PINGREQ usw.).
• Wenn der Server (Broker) innerhalb von 1,5 × Keep Alive keine Pakete vom Client erhält, wird der Client als getrennt angesehen, die TCP-Verbindung wird geschlossen und die Nachricht (Last Will) ausführt.
• In ähnlicher Weise sollte der Client, wenn er während der Keep Alive-Zeit keine Pakete vom Broker erhält, aktiv eine Wiederverbindung herstellen.

MQTT 5.0 geht noch einen Schritt weiter und ermöglicht es Brokern, den Server-Keep - Alive-Wert in einer CONNACK-Nachricht zurückzugeben - wenn der Broker den vom Client vorgeschlagenen Keep-Alive nicht akzeptiert, kann er mit seinem eigenen Wert überschrieben werden, und der Client muss den vom Broker zurückgegebenen Wert befolgen.

Schlüsselwerte wählen: Keep Alive für MQTT kann weder zu groß noch zu klein gesetzt werden. Es ist zu groß, dass das Gerät lange offline ist, bis der Broker es herausfindet; zu klein, dass das Herzschlagpaket häufig SIM-Kartenverkehr verbraucht. In realen Projekten ist der Keep Alive-Zeitraum von MQTT normalerweise zwischen 60 und 120 Sekunden eingestellt. Wenn das Gerät batteriebetrieben ist (NB-IoT - Szenario), kann es auf 300 - 600 Sekunden gelockert werden.

Unterschied zwischen TCP und KeepAliveMQTT Keep Alive ist ein Anwendungsschichtprotokollverhalten, bei dem PINGREQ-Nachrichten in TCP-Paketen versendet werden. Das NAT-Gateway sieht, dass ein TCP-Paket vorbeizieht, und aktualisiert die Zuordnung. Deshalb löst MQTTs Keep Alive NAT-Zeitüberschreitungen, während TCPs KeepAlive das nicht unbedingt kann.

2.3 Anwendungsschicht benutzerdefinierter Herzschlag - am flexibelsten und am meisten benötigt Design

Wenn Ihr Gerät keine MQTT verwendet, sondern nackte TCP / UDP-Transmission verwendet (Modbus TCP, benutzerdefinierte Binärprotokolle usw.), müssen Sie Ihren eigenen Application-Layer - Herzschlag entwickeln. Dies ist das am häufigsten verwendete Konzept des Heartbeat-Pakets in 4G-DTUs und seriellen Servern.

Designprinzipien：

1. Das Herzpaket sollte so klein wie möglich sein.Fluss ist Geld. Das kleinste Herzschlagpaket kann ein Byte sein - zum Beispiel0x48(ASCII 'H') oder eine feste Zeichenfolge "Q".
2. Das Herzschlagintervall ist kleiner als die NAT-Zeitüberschreitung.Die kürzeste NAT-Zeitüberschreitung des inländischen Betreibers beträgt 2 Minuten, so dass das Herzschlagintervall im Allgemeinen 60 Sekunden oder kürzer ist. Konservative Empfehlungen 30 - 60 Sekunden.
3. Der Server sollte auf Herzschlag antworten.Ein einseitiger Herzschlag lässt nur den Server wissen, dass das Gerät am Leben ist, aber das Gerät weiß nicht, ob der Server am Leben ist. Zwei-Wege - Herzschlag (Gerät sendet, Server zurück) ermöglicht es beiden Enden, den Zustand des anderen Endes zu erkennen.
4. Wiederverbindung nach N aufeinanderfolgenden Herzschlägen ausgelöst.Es ist nicht ein Herzschlag, der abschneidet - gelegentliche Paketverlust ist auf Netzwerkebene normal. In der Regel wird der Wiedereinbindungsprozess nach drei aufeinanderfolgenden Herzschlägen ohne Antwort ausgelöst.

Beispiel für den Herzschlag der AIRIOT-Plattform: Das Gerät sendet regelmäßig das Zeichen "Q", und die Plattform antwortet sofort mit "A", sobald es empfangen wird. Das Gerät entscheidet, ob die Verbindung normal ist, indem es ein "A" empfängt - ein einfaches und effektives Design, das auf 4G-DTUs sehr kostengünstig implementiert wird.

Formel für die Berechnung des Herzschlagintervalls：

心跳间隔 < NAT超时时间 × 安全系数
安全系数 = 0.6 ~ 0.8

Wenn der Betreiber NAT Timeout 5 Minuten (300 Sekunden) beträgt, nehmen Sie den Sicherheitsfaktor 0,6 und das Herzschlagintervall ≤ 180 Sekunden. Unter Berücksichtigung der gelegentlichen Netzwerk-Jitter, ist es in einem tatsächlichen Projekt 60 bis 90 Sekunden sicherer.

TCP KeepAlive vs Application-Layer - Herzschlag: Wann und was

Für diese Frage gibt es keine Standardantwort, abhängig von Ihrem Szenario.

Empfohlene KombinationsstrategieIn einem Produktionsprojekt aktivieren Sie sowohl TCP KeepAlive (als Basis-Kapazität) als auch Applikations-Herzschlag (als Haupt-Erkennung). Der TCP KeepAlive-Parameter wird kürzer (60 Sekunden Leerlauf + 10 Sekunden Intervall + 3 Sonde) und der Herzschlag der Anwendungsschicht wird von 30 - 60 Sekunden festgelegt. Selbst wenn der Anwendungsschicht-Herzschlag aufgrund eines Bugs nicht ausgeschickt wird, erkennt TCP KeepAlive die Verbindung nach 90 Sekunden getrennt.

Wenn Ihr Gerät über UDP gehen muss (wie zum Beispiel der Registrierungsmodus für bestimmte DTUs), ist TCP KeepAlive völlig nutzlos - nur mit dem Herzschlag der Anwendungsschicht.

4. Registrierungspaket: Der Server soll wissen, wer ich bin

Der Herzschlag löst die Frage „Ich lebe", während das Registrierungspaket die Frage „Wer ich bin" löst.

4.1 Wesen des Registrierungspakets

Bei DTUs und Serien-Servern ist das Registrierungspaket das erste Paket, das ein Gerät sendet, nachdem eine TCP-Verbindung hergestellt wurde, um sich an den Server zu identifizieren. Der Server verknüpft die aktuelle TCP-Verbindung anhand des Inhalts des Registrierungspakets mit einem vorregistrierten Gerätesaatrag.

Ein typischer DTU-Registrierungsprozess:

1. DTU Einschalten, Wählen, Anschließen zum 4G-Netzwerk
2. DTU sendet Registrierungspaket, sobald die Verbindung über TCP zum angegebenen Port
3. erfolgreich hergestellt wurde (Kann eine Reihe benutzerdefinierter Zeichen oder IMEI / ICCID sein)
4. Der Server analysiert Registrierungspaket, erkennt die Geräteidentität, aktualisiert den Online-Status des Geräts
5. Registrierung abgeschlossen, Start der normalen bidirektionalen Datenübertragung

4.2 Zwei Sendenzeiten für Registrierungspakete

Einige DTUs unterstützen zwei Sendenarten für Registrierungspakete:

Senden einmal während der VerbindungSenden Sie nur, wenn eine TCP-Verbindung hergestellt wird. Danach enthält die normale Datenübertragung keine Registrierungsinformationen mehr. Dies gilt für Szenarien, in denen der Server die Identität eines Geräts per Verbindung verwaltet - eine TCP-Verbindung entspricht einem Gerät, und die Identität wird ermittelt, sobald die Verbindung hergestellt wird.

Vor jedem Paket Daten hinzufügen* Befügen Sie das Registrierungspaket vor jeder Übertragung von Daten. Geeignet für Szenarien, in denen mehrere Geräte über den gleichen seriellen Server oder Gateway zugreifen - der Server muss das Datenquellengerät anhand der Registrierungsinformationen in jedem Paket bestimmen. Der Nachteil ist, dass die Kosten pro Paket erhöht werden.

Nehmen wir zum Beispiel eine DTU, die die Konfiguration des Registrierungspakets verwendet:

• Aktivieren des Registrierungspakets
• Wählen Sie die Sendenmethode: "Einmal bei der Verbindung" oder "Einmal vor jedem Paket, das an den Server gesendet wird"
• Benutzen Sie den Inhalt des Registrierungspakets (z. B.01stellt Gerät Nr. 1,02Ausrüstung Nr. 2)
• Der Server empfängt Daten in diesem Format:注册包 + 透传数据

4.3 Dateninhaltsdesign des Registrierungspakets

Der Inhalt des Registrierungspakets hängt von Ihrer Back-End - Architektur ab. Gängige Praxis:

Verwenden Sie die IMEI als eindeutige Gerätekennzeichnung. IMEI (International Mobile Device Identification Code) ist eine 15 - stellige Zahl, die weltweit einzigartig ist und nicht im 4G-Modul verändert werden kann. Das DTU liest beim Starten die IMEI des Moduls und sendet es als Registrierungspaket an den Server. Der Vorteil ist natürlich eindeutig, keine menschliche Zuweisung erforderlich; Nachteile ist die IMEI-Länge von 15 Bytes, wenn Sie extrem Traffic sparen müssen, können Sie eine kurze ID (2 - 4 Bytes) mit der Plattformseite vorzuweisen in Betracht ziehen.

Verwenden Sie die Plattformvorzuweisende Seriennummer. Bei der Registrierung eines Geräts auf einer Cloud-Plattform erzeugt die Plattform eine eindeutige Seriennummer (entweder eine selbststeigernde ID oder ein kurzer Hash für die UUID). Schreiben Sie die DTU über das Konfigurationswerkzeug und senden Sie diese Seriennummer bei der Verbindung der DTU. Der Vorteil ist, dass die Seriennummer steuerbar ist (z. B. durch die Region kodiert) und die Länge ist kurz; der Nachteil ist, dass ein Konfigurationsverteilungsprozess erforderlich ist.

Verwenden Sie die ICCID。Die ICCID der SIM-Karte besteht aus 20 Ziffern und ist eindeutig. Es wird jedoch nicht empfohlen - da die SIM-Karte möglicherweise ausgetauscht werden kann und das Gerät durch den Austausch der Karte nicht zu einem „anderen Gerät" werden sollte.

4.4 Die Beziehung zwischen der Geräteregistrierung für die Cloud-Plattform und dem DTU-Registrierungspaket

Bei Standard-IoT - Plattformen wie Huawei Cloud IoTDA oder Alibaba Cloud IoT ist die Geräteregistrierung ein eigenständiger Prozess:

1. Erstellen von Produkten auf der Plattform (Datenmodell für das Gerät definieren)
2. Dann registrieren Sie das Gerät.(Plattform generiert Device ID und Device Secret)
3. Schreibt diese Anmeldeinformationen in die Firmware oder die Konfigurationsdatei des Geräts
4. Bei dem Start des Geräts wird eine authentifizierte Verbindung mit Device ID und Secret zur Plattform initiiert (normalerweise über das MQTT-Feld Benutzername / Passwort oder X.509 - Zertifikat)

In diesem Prozess ist das "Registrierungspaket" der DTU tatsächlich die Geräte-Authentifizierungsinformationen der entsprechenden Plattform. Beispielsweise verlangt die AIRIOT-Plattform, dass ein Gerät die Seriennummer zum ersten Mal nach der Herstellung einer TCP-Verbindung sendet, was im Wesentlichen eine vereinfachte Version des Geräte-Authentifizierungsprotokolls ist.

Wenn Ihr Back-End - Server selbst entwickelt wurdeDie Registrierung wird vollständig von Ihnen gestaltet. Die Kernanforderungen sind zwei: Die Identität des Geräts ist eindeutig und der Server kann die Identität überprüfen. Die minimalistische Lösung - 4G DTUs mit IMEI-Registrierung + HMAC-Signatur mit einem festen Schlüssel, reicht aus, um die meisten industriellen Szenarien mit nicht finanziellen Sicherheitsanforderungen zu erfüllen.

V. Vollständige Parameterempfehlungen und Konfiguration des Kampfes

5.1 Herzschlagparameterempfehlungen

5.2 Linux-Serverside TCP KeepAlive Parameter Empfehlung

在 /etc/sysctl.confIn:

net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3

Anschließendsysctl -pangewendet. Zusätzlich mit dem Anwendungsschicht Herzschlag (z. B. 60 Sekunden Abstand), die beiden Schichten halten lebendig unter sich.

5.3 Beispiel für die tatsächliche Konfiguration von DTU

Hier ist ein typisches 4G-DTU - Konfigurationsszenario (mit dem Beispiel USR-G780):

心跳包：启用
心跳周期：60 秒
心跳内容：Q（自定义字符串）

注册包：启用
注册包发送方式：连接时发送一次
注册包内容：IMEI（使用设备 IMEI 作为唯一标识）

连接类型：TCP Client
服务器地址：your-server.com
服务器端口：8001
断线重连：启用，间隔 10 秒，最多重连 30 次

Serverseitige Korrespondenzlogik:

1. TCP-Verbindungsanforderung empfangen → Verbindung akzeptieren
2. Warten innerhalb von 5 Sekunden Registrierungspaket empfangen → IMEI extrahieren, die Liste der übereinstimmenden Geräte in der Datenbank überprüfen → Aktualisieren des Online-Status des Geräts auf Online
3. Registrierungspaket beschlagnahmt innerhalb von 5 Sekunden → Beurteilung für eine illegale Verbindung, Schließen der Socket
4. Nach erfolgreicher Registrierung starten Sie den Herzschlag-Timer, Erwarten Sie, dass alle 60 Sekunden ein "Q" empfangen wird → Antwort "A"
5. 3 aufeinanderfolgende Herzschlagzyklen (180 Sekunden) Verbot von "Q" → Feststellung, dass das Gerät offline ist, Auslöser einer Wiederverbindung / Warnung

VI. Häufige Pit für Herzschlag und Registrierung

6.1 NAT-Timeout und Herzschlagzyklus-Ungerechtigkeit

Häufigste Probleme: Der Herzschlagzyklus ist auf 5 Minuten eingestellt, und der Betreiber NAT-Timeout beträgt 2 Minuten. Das Ergebnis ist, dass bei jedem Herzschlagintervall, NAT unterbrochen ist, das Herzschlagpaket kann nicht ausgeschickt werden, und das Gerät ist immer in einem unendlichen Kreislauf von "Verbindung → 2 Minuten später trennen → Herzschlag überschreiten Wiederverbindung → Verbinden → 2 Minuten später trennen".

Diagnosemethode: Auf der Serverseite schauen Sie sich die Verbindung des gleichen Geräts auf die Zeit und trennen, wenn die Trennzeit - die Aufbauzeit fast jedes Mal ein fester Wert (z. B. 120 Sekunden) ist, ist im Grunde ein NAT-Timeout - Problem.

Lösung: Herzschlagzyklus < 120 Sek.

6.2 Registrierungspaket nicht sofort nach der Verbindung hergestellt gesendet

DTU Nachdem eine TCP-Verbindung hergestellt wurde, kann der Server nicht erkennen, von welchem Gerät diese Daten stammen, wenn sie anstelle von Registrierungspaketen zuerst gesendet werden - insbesondere wenn mehrere Geräte einen Serverport teilen, kann der Server die Verbindung fallenlassen oder schließen, wenn das erste Paket keine Registrierungspakete empfangen wird.

Es muss sichergestellt werden, dass das Registrierungspaket nach erfolgreichem Socket Connect so schnell wie möglich ausgegeben wird.

6.3 Bidectional Heartbeat

Das Gerät schlägt ein Herz, der Server antwortet nicht - der Server weiß, dass das Gerät am Leben ist, aber das Gerät weiß nicht, ob der Server am Leben ist. Wenn der Server aufgrund eines Programmbeglers oder eines Netzwerkproblems nicht mehr auf Herzschläge antwortet, wartet das Gerät möglicherweise weiter, bis die Übertragung von Geschäftsdaten abgelaufen ist, um zu erkennen, dass etwas passiert ist.

Mit einem bidirektionalen Herzschlag kann die Gerätsseite auch proaktiv Server-Ausnahmen erkennen und eine Wiederverbindung auslösen. Dies ist wichtig für die über das ganze Land verteilten und unbewachten DTU-Ausrüstung.

6.4 Plattformübergreifende Unterschiede von TCP KeepAlive

Windows, Linux, FreeRTOS, LwIP sind die Standardwerte und konfigurierbaren Parameter für TCP KeepAlive unterschiedlich. Linux-Standard 7200 Sekunden, Windows-Standard 7200000 Millisekunden (2 Stunden) und LwIP (Embedded TCP-Protocol - Stack) ist auch groß. Verlassen Sie sich nicht auf den Defaultwert.

6.5 Der Inhalt des Registrierungspakets wurde nicht überprüft

Wenn das Registrierungspaket in Klartext übertragen wird (z. B. direkt mit IMEI), kann das Paket über den Netzwerkverbindung manipuliert werden. Für Szenarien mit hohen Sicherheitsanforderungen sollte das Registrierungspaket mindestens eine Zusammenfassung oder eine Signatur enthalten. Der einfachste Ansatz: Das Gerät verwendet den vordefinierten symmetrischen Schlüssel für den IMEI + Zeitstempel HMAC, der Server bestätigt, dass HMAC die Registrierung akzeptiert hat.

VII. Überprüfungsliste

Wenn die DTU häufig offline ist, sorgen Sie in dieser Reihenfolge:

Herzschlag und Registrierungspaket ist ein einfaches Konzept - eine Tasche zu einem bestimmten Zeitpunkt zu versenden, um zu zeigen, wer Sie sind. Aber wenn es wirklich getan wird, sind die Details in der Parameterwahl und der Vorhersage des Ausfallmodi. Die Zahlen in diesem Artikel (30 Sekunden, 60 Sekunden, 120 Sekunden) sind nicht zufällig geschrieben - sie basieren auf dem Gleichgewicht zwischen den NAT-Zeitüberschreitungen der drei großen inländischen Betreiber, den Stromverbrauchsbeschränkungen des 4G-Moduls und den Serverressourcen-Overhead. Wenn Ihre eigenen Projekte nicht die gleiche Szenario, sich selbst in der Testumgebung zu kaufen, um das Paket zu verifizieren.

Probleme noch mal reden.