출 처 : Mod bus 중국 어 네트워크 (mod bus . cn) - 국내 선 도 적 인 Mod bus 통신 프로토 콜 기술 커뮤니티
이 게시 물 : IoT 전송 모듈 의 하 트 비 트 패키 지 및 등록 패키 지 : 메 커 니 즘 , 설계 및 문제 해결 · 작성 자 : mod bus 기술 팀 · 게시 20 26 - 07 - 01
요 약 : 4 G D TU , 직 렬 서버 , 에 지 게 이트 웨 이 및 기타 IoT 전송 모듈 에서 하 트 비 트 패키 지 및 등록 패키 지는 연결 안정 성과 장치 식별 을 유지하는 핵심 메 커 니 즘 입니다 .이 문서 에서는 TCP Keep Ali ve , M Q TT Keep Ali ve , 애플 리케이션 계 층 사용자 정의 하 트 비 트 세 가지 수준 에서 하 트 비 트 메 커 니 즘 을 설명 합니다 ; D TU 등록 패키 지에서 클 라우 드 플랫폼 장치 인증 및 등록 메 커 니 즘 에 이르 기까지 매 개 변 수 계산 공식 , 코드 예 제 및 문제 해결 단계 가 있습니다 .키 워 드 : 심장 박 동 패키 지 , 등록 패키 지 , 4 G D TU , Keep Ali ve , M Q TT 심장 박 동 , TCP 유지 , 장치 등록 .
SIM 카드 에 4 G D TU 를 꽂 고 직 렬 포 트 매 개 변 수를 갖추 고 서버 에 연결 하십시오 - 데이터가 연결되어 있습니다 . 당신은 완료 했다고 생각합니다 .다음날 밤 이 지나 서 장비 가 오 프 라인 이었 지만 신호 등 이 켜 져 있었다 는 것을 발견했습니다 .다시 시작 하면 되 죠 .며칠 후에 다시 오 프 라인 입니다 .
이것은 긴 연결 을 유지하는 전형 적인 문제 입니다 . IoT 시 나 리오 에서 장 치는 전 국에 분 포 되어 있으며 일부는 외 딴 산 악 지역에 있으며 일부는 지 하실 에 있습니다 .통신 링크 는 장치 의 직 렬 포 트 에서 시작 하여 D TU 의 4 G 모듈 을 통과 하여 운영 자의 N AT 게 이트 웨 이를 통과 하여 공 용 네트워크를 통해 클 라우 드 서버 에 도달 합니다 .이 링크 의 모든 링크 는 연결 을 죽일 수 있지만 통 지 하지 않습니다 .
이 기 사는 심장 박 동 패키 지와 등록 패키 지를 원칙 에서 실제 전투 에 이르 기까지 모두 설명 합니다 - 개념 뿐만 아니라 프로젝트 에서 직접 사용할 수있는 매 개 변 수 , 코드 및 장애 해결 방법을 제공합니다 .
왜 긴 연결 이 끊 어 지는 가
심장 박 동 에 대해 이야기 하기 전에 , 긴 연결 이 어떻게 끊 어 지는 지 알아 보십시오 - 다른 이유로 다른 생존 전략 에 대응 합니다 .
运营商 NAT タイムアウト4 G D TU 는 모바일 네트워크 의 전 용 IP (1 0. x . x . x / 100. x . x . x) 를 사용하여 운영 자의 N AT 게 이트 웨 이를 통해 공 용 네트워크 에 액세스 합니다 . N AT 게 이트 웨 이는 리 소 스를 절약 하기 위해 유 휴 연결 에 대한 시간 초 과 시간을 설정 합니다 .국내 3 대 사업 자의 전형 적인 값 :
- 中国移動：5 分
다른 지역 및 패키 지 카드 의 N AT 시간 초 과 시간은 동일 하지 않지만 기본적으로 2 - 5 분 입니다 .이 시간이 지나 면 패 킷 이 통과 하지 않으면 N AT 게 이트 웨 이의 매 핑 레 코 드가 지 워 집니다 .서버 가 D TU 에 패키 지를 보내 려고 할 때 N AT 게 이트 웨 이는 더 이상 패키 지를 인식 하지 못하고 직접 버 립니다 - 장 치는 여전히 온라인 (4 G 연결 은 정상) 으로 보이 지만 데이터 채널 은 이미 죽 었습니다 .
ファイアウォール / 中间デバイス엔 터 프 라이 즈 네트워크 의 출 구 방 화 벽 은 일반적으로 유 휴 TCP 연결 을 정리 합니다 .산업 용 컴퓨터 는 WiFi 를 통해 엔 터 프 라이 즈 인 트 라 넷 에 액세스 하고 클 라우 드 서버 와 Mod bus TCP 연결 을 유지 합니다 . 30 분 동안 통신 이 없다면 , 중 간에 있는 확신 / Huawei 방 화 벽 은 이 연결 상태를 만 료 로 표시 하고 해 제 합니다 .서버 는 장치 가 여전히 연결되어 있다고 생각 하며 , 장치 가 서버 가 여전히 연결되어 있다고 생각 하며 , 이는 " 연 결 이 죽은 것 " 입니다 .
デバイス異常掉线현 장 장치 의 전 원 공급 이 중단 되고 , 4 G 신호 가 손실 되고 , 스위 치가 재 부 팅 됩니다 . 이러한 경우 TCP 연결 의 상대 방 은 FIN 패 킷 을 수신 하지 않습니다 . 4 층 이 신호 를 끊 지 않으면 응용 계 층 은 감지 할 수 없습니다 .심장 박 동 검 출 에 의존 하지 않으면 서버 는 항상 장치 가 온라인 이라고 생각하고 스케 줄 링 작업 은 평소 와 같이 발 송 되며 모두 시간 초 과 됩니다 .
TCP 半开连接TCP 연결 의 한 쪽 끝 은 종료 되었으며 (서 버 가 재 부 팅 된 경우 와 같이) 다른 쪽 끝 은 알지 못하고 유지 - 살아 있습니다 .이것은 표준 " 반 개방 연결 " 시 나 리오 입니다 .
TCP Keep Ali ve , M Q TT Keep Ali ve , 애플 리케이션 레이 어 하 트 비 트
다양한 장면 과 세 분 화에 해당 하는 세 가지 레벨 이 있습니다 .
2. 1 TCP 프로토 콜 계 층 의 Keep Ali ve - 최 하 위 , 가장 유 연 하지 않은 계 층
TCP 프로토 콜 스 택 에는 Keep Ali ve 메 커 니 즘 이 포함되어 있습니다 .연결 이 설정 된 후 지정 된 시간 내에 데이터 전송 이 없으면 운영 체 제 커 널 은 자동 으로 프로 브 패 킷 (빈 AC K) 을 상대 엔 드에 보내 상대 엔 드가 응답 하기를 기다 립니다 .상대 방 은 아직 살아 있다면 AC K 를 반환 하고 , 죽은 경우 여러 번 무 결 한 탐 지 후 연결 을 닫 습니다 .
리 눅 스 커 널 의 세 가지 주요 매 개 변 수 :
net . ip v 4. t c p _ keep pali ve _ time = 7 200 # 처음 탐 지 전 의 유 휴 시간 (초), 기본 값 은 2 시간 입니다 .
net . ip v 4. t c p _ keep pali ve _ int v l = 75 # 프로 브 간 격 (초), 기본 값 은 75 초
net . ip v 4. t c p _ keep _ prob es = 9 # 프로 브 횟 수 , 기본 값 9 개즉 , 기본적으로 TCP 연결 이 2 시간 11 분 15 초 (7 200 + 75 x 9) 동안 끊 어 지면 운영 체 제가 응용 프로그램 계 층 에 " 이 연결 이 죽 었습니다 " 라고 알 립니다 .이 시간은 사 물 인터넷 시 나 리오 에 전혀 작동 하지 않습니다 - 장치 가 오 프 라인 이라는 것을 발견 하면 배터 리가 두 번 교체 됩니다 .
코드 에서 단일 소 켓 에 대해 더 짧은 매 개 변 수를 설정 할 수 있습니다 (Linux ≥ 2. 6. 37 지원):
소 켓 가져 오 기
so ck = so cket . so cket (so cket . AF _ IN ET , so cket . SO CK _ ST RE AM)
so ck . set so ck opt (so cket . SOL _ SO CK ET , so cket . SO _ KE EP AL IVE , 1)
# 다음 세 개의 매 개 변 수는 Linux 2. 6. 37 + 와 IP P RO TO _ TCP 소 켓 이 필요합니다 .
so ck . set so ck opt (so cket . IP P RO TO _ TCP , so cket . TCP _ KE EP ID LE , 60) # 60 초 유 휴 후에 탐 지 시작
so ck . set so ck opt (so cket . IP P RO TO _ TCP , so cket . TCP _ KE EP IN TV L , 10) # 10 초 마다 탐 지
so cket . set so ck opt (so cket . IP P RO TO _ TCP , so cket . TCP _ K EE PC NT , 3) # 3 무 응 답 판단 해 제이렇게 구성 하면 연결 끊 기 검색 시간 = 60 + 10 × 3 = 90 초 .
但 TCP KeepAlive 有2つ致命缺陷
첫째 , 엔 드 투 엔 드 TCP 연결 이 생존 하는지 여 부 만 감지 할 수 있으며 엔 드 투 엔 드 사이의 중간 장치 (N AT 게 이트 웨 이 , 방 화 벽) 가 연결 을 정리 했는지 여 부를 감지 할 수 없습니다 .프로 브 패 킷 은 두 엔 드 포 인트 의 TCP 스 택 사이에서 만 흐 르고 N AT 게 이트 웨 이를 통과 할 때 N AT 매 핑 항목 을 새로 고 치지 않을 수 있습니다 . 즉 , TCP 계 층 은 연결 이 정상 이라고 생각 하지만 N AT 는 채널 을 닫 습니다 .
둘째 , 2 시간의 기본 값 은 너무 길 고 , 매 개 변 수를 변경 하면 현재 소 켓 에만 적용 되며 , 기 계를 변경 하면 기본 구성 으로 돌아 갑니다 .또한 매 개 변 수를 수정 하려면 루 트 권한 이 필요 하며 임 베 디 드 장치 (D TU , 직 렬 서버) 의 커 널 은 동 적 수 정을 지원 하지 않을 수 있습니다 .
따라서 TCP Keep Ali ve 는 IoT 시 나 리오 에서 보조 수단 으로 만 작동 하며 응용 프로그램 계 층 의 심장 박 동을 대체 할 수 없습니다 .
2. 2 M Q TT 프로토 콜 의 Keep Ali ve - 표준 화된 애플 리케이션 계 층 유지
M Q TT 프로토 콜 은 CON N ECT 메시 지에 16 비트 의 Keep Ali ve 필 드를 정의 하며 , 단 위는 초 입니다 .이 메 커 니 즘 은 TCP Keep Ali ve 보다 애플 리케이션 계 층 요구 사항 에 더 가깝 습니다 .
- 클 라이언 트는 Keep Ali ve 기간 동안 적어도 하나의 제어 메시지 (PU BL ISH , SU BS CR IB E , P ING RE Q 등) 를 전송 해야 합니다 .
- 브 로 커 가 1. 5 x Keep Ali ve 시간 내에 클 라이언 트 로부터 어떤 패 킷 도 수신 하지 않으면 클 라이언 트가 연결 이 끊 어진 것으로 간주 되고 TCP 연결 이 닫 히 고 마지막 유 언 메시지를 실행 합니다 .
- 마찬가지로 , 클 라이언 트가 Keep Ali ve 시간 동안 Br oker 로부터 패 킷 을 받지 않으면 사전 재 연 결 해야합니다 .
M Q TT 5. 0 은 브 로 커 가 CON NA CK 메시 지에서 서버 의 Keep Ali ve 값을 반환 할 수 있도록 한 단계 더 나아 갑니다 - 브 로 커 가 클 라이언 트가 제안 한 Keep Ali ve 를 수 락 하지 않으면 자체 값 으로 덮 어 쓸 수 있으며 클 라이언 트는 브 로 커 가 반환 한 값을 준수 해야합니다 .
关键数值選択너무 커 서 장 치는 브 로 커 가 발견 하기 전에 오랫동안 오 프 라인 이었습니다 ; 너무 작 아서 심 박 패 킷 이 SIM 카드 트 래 픽 을 자주 소비 했습니다 .실제 프로젝트 에서 M Q TT 의 Keep Ali ve 는 일반적으로 60 - 120 초 사이 로 설정 됩니다 .장치 가 배터 리 전 원 (NB - IoT 시 나 리오) 인 경우 300 - 600 초 로 완 화 할 수 있습니다 .
和 TCP KeepAlive 違いはありませんN AT 게 이트 웨 이는 TCP 패 킷 이 통과 되는 것을 보고 매 핑 항목 을 새로 고 칩니다 .그렇기 때문에 M Q TT 의 Keep Ali ve 는 N AT 시간 초 과 문제를 해결 하지만 TCP Keep Ali ve 는 반드시 해결 하지 않습니다 .
2. 3 애플 리케이션 계 층 사용자 정의 심장 박 동 - 가장 유 연 하고 설계 가 가장 필요합니다 .
장치 가 M Q TT 를 사용하지 않고 누 드 TCP / U DP 트 랜 스 포 트 (Mod bus TCP , 사용자 정의 바이 너 리 프로토 콜 등) 를 사용하는 경우 자체 응용 프로그램 계 층 하 트 비 트를 설계 해야합니다 .이것은 4 G D TU 및 직 렬 서버 에서 가장 일반적인 하 트 비 트 패키 지 개념 입니다 .
设计原则
- 심장 박 동 가방 은 가능한 한 작 아야 합니다 . 흐름 은 돈 이다 .
最简ハートビートパック可以是一バイト単位。--比如 - 심장 박 동 간 격 은 N AT 시간 초 과 시간 보다 작 아야 합니다 . 국내 사업 자의 N AT 시간 초 과는 2 분 이 가장 짧 기 때문에 심장 박 동 간 격 은 일반적으로 60 초 이하 로 설정 됩니다 .보수 적 인 권장 사항 30 - 60 초 .
- 서버 가 하 트 비 트에 응답 해야 합니다 . 단 방 향 심장 박 동 은 서버 가 장치 가 살아 있는지 알 수 있지만 장치 가 살아 있는지 여 부를 알 수 없습니다 .양 방 향 하 트 비 트 (장 비 전송 , 서버 반환) 는 양 쪽 끝 에서 상대 방 의 상태를 감지 할 수 있습니다 .
- 연속 N 번의 심 박 이 실패 한 후 재 연 결 을 트 리 거 합니다 . 한 번의 심장 박 동 이 끊 어 지지 않습니다 - 가끔 패 킷 손실 은 네트워크 수준 에서 정상 적입니다 .일반적으로 3 번의 연속 심 박 이 응답 하지 않은 후에 재 연 결 프로세 스를 트 리 거 하도록 설정 합니다 .
AIRIOT プラットフォーム的心跳サンプル장 치는 " A " 를 수신 하는지 여 부를 통해 연결 이 정상 인지 여 부를 판단 합니다 - 이 설계 는 간단 하고 효율 적이며 4 G D TU 에서 구현 비용이 매우 낮 습니다 .
心跳間隔的計算公式
심장 박 동 간 격 N AT 시간 초 과 시간 × 안전 계 수<
안전 계 수 = 0. 6 ~ 0. 8운영 자 N AT 시간 초 과 가 5 분 (3 00 초) 인 경우 안전 계 수 0. 6 을 가져 와 심장 박 동 간 격 ≤ 180 초 .그리고 가끔 의 네트워크 흔들 림을 고려 하면 실제 프로젝트 에서 60 ~ 90 초 를 설정 하는 것이 더 안정 적입니다 .
TCP Keep Ali ve vs App lication L ayer Heart be at : 언제 어느 것을 사용 합니까 ?
이 질문에 대한 표준 대답은 없으며 시 나 리오 에 따라 다릅니다 .
| 维度 | TCP KeepAlive | アプリケーション層心跳 |
|---|
建议的组合策略TCP Keep Ali ve 매 개 변 수는 약간 짧 게 (60 초 유 휴 + 10 초 간 격 + 3 개의 탐 지) 설정 하고 응용 프로그램 계 층 의 심장 박 동 은 30 - 60 초 로 설정 됩니다 .애플 리케이션 레이 어 심장 박 동 이 버 그 때문에 보내 지 않 더라도 TCP Keep Ali ve 는 또한 90 초 후에 연결 이 끊 어 지는 것을 발견 합니다 .
장치 가 U DP 를 사용 해야 하는 경우 (예를 들어 일부 D TU 의 등록 모 드), TCP Keep Ali ve 는 응용 프로그램 계 층 하 트 비 트 만 사용할 수 있습니다 .
등록 패키 지 : 서버 가 " 내가 누구인지 " 알 수 있도록 하십시오 .
심장 박 동 은 " 나는 아직 살아 있다 " 라는 질문을 해결 하고 등록 패키 지는 " 나는 누구 인가 " 라는 질문을 해결 합니다 .
4. 1 등록 패키 지의 본질
D TU 및 직 렬 서버 에서 등록 패 킷 은 TCP 연결 을 설정 한 후 장치 가 서버 에 자신의 신 원을 선언 하는 데 사용하는 첫 번째 패 킷 입니다 .서버 는 등록 된 패키 지의 내용 에 따라 현재 TCP 연결 을 사전 등록 된 장치 레 코 드와 연관 시킵니다 .
일반적인 D TU 등록 프로세 스 :
- DTU 上电、拨号、附着 4G 网络
4. 2 등록 패키 지의 두 가지 전송 시 점
일부 D TU 는 등록 패키 지 전송 의 두 가지 방법을 지원 합니다 .
连接时送信一次그 후 정상적인 데이터 전달 은 더 이상 등록 정보를 포함 하지 않습니다 .이것은 서버 가 연결 별 로 장치 ID 를 관리 하는 시 나 리오 에 적용 됩니다 - TCP 연결 은 하나의 장치 에 해당 하며 연결 이 설정 되면 ID 가 결정 됩니다 .
每包データ前附加여러 장치 가 동일한 직 렬 서버 또는 게 이트 웨 이를 통해 액세스 하는 시 나 리오 에 적합 합니다 - 서버 는 각 데이터 패 킷 의 등록 정보를 통해 데이터 소 스 장치를 판단 해야합니다 .단 점은 패 킷 당 데이터 의 오 버 헤 드가 증가 한다는 것입니다 .
예를 들어 , 등록 패키 지를 사용하여 구성 하는 방법을 사용하여 사용자 D TU 를 사용합니다 .
- 勾选「有効パッケージの登録」
4. 3 등록 패키 지의 데이터 콘텐츠 설계
등록 패키 지의 내용은 백 엔 드 아 키 텍 처 에 따라 다릅니다 .일반적인 관 행 :
使用 IMEI 作为デバイス唯一标识IM EI (국 제 모바일 장치 식별 코드) 는 전 세계적으로 고유 한 15 자리 숫자 이며 4 G 모듈 에서 변경 할 수 없습니다 . D TU 가 시작 될 때 모듈 의 IM EI 를 읽고 서버 에 등록 패 킷 으로 전송 합니다 .장 점은 자연 적으로 고유 하고 인 위 적 할 당 이 필요하지 않습니다 ; 단 점은 IM EI 길이 15 바 이트 이며 , 트 래 픽 을 극 적으로 절약 해야 하는 경우 플랫폼 측 에서 미리 할 당 된 짧은 ID (2 - 4 바 이트) 를 고려 할 수 있습니다 .
使用プラットフォーム预分配的序列号클 라우 드 플랫폼 에 장치를 등록 할 때 플랫폼 은 고유 한 일련 번호 (자 동 증가 ID 또는 UU ID 의 짧은 해 시 일 수 있음) 를 생성 합니다 .구성 도구를 통해 D TU 에 기록 하여 D TU 가 연결 될 때 이 일련 번호 를 전송 합니다 .장 점은 일련 번호 를 제어 할 수 있으며 (예를 들어 , 지역 별 인 코 딩) 길 이가 짧 다는 것입니다 ; 단 점은 구성 배 포 프로세 스가 필요 하다는 것입니다 .
使用 ICCIDSIM 카드 의 ICC ID 는 또한 고유 한 20 자리 숫자 입니다 .그러나 일반적으로 권장 되지 않습니다 - SIM 카 드가 교체 될 수 있기 때문에 장치 가 카드를 교체 함으로써 " 다른 장치 " 가 되어 서는 안됩니다 .
4. 4 클 라우 드 플랫폼 의 장치 등록 과 D TU 등록 패키 지의 관계
Huawei Cloud IoT DA 또는 Alibaba Cloud IoT 와 같은 표준 IoT 플랫폼 에서는 장치 등록 은 독립 적 인 프로세 스 입니다 .
- 先在プラットフォーム上作成产品（定义デバイス的データ模型）
이 프로세 스에서 D TU 의 " 등 록 패키 지 " 는 실제로 해당 플랫폼 의 장치 인증 정보 입니다 .예를 들어 , A IR IO T 플랫폼 은 장치 가 TCP 연결 을 설정 한 후 처음으로 일련 번호 를 전송 하도록 요구 하며 , 이는 본질 적으로 장치 인증 프로토 콜 의 단순 화된 버전 입니다 .
もし你的后端サーバーは、自己开发的핵심 요구 사항 은 두 가지 입니다 : 장치 의 고유 한 ID 및 서버 가 신 원을 확인할 수 있습니다 .최소 화 - IM EI 등록 + 고정 키 H M AC 서 명을 가진 4 G D TU 는 대부분의 비 금융 수준의 보안 요구 사항을 충족 하기에 충분 합니다 .
V . 완전한 매 개 변 수 추천 및 실 전 구성
5. 1 심장 박 동 매 개 변 수 권장 값
| 시 나 리오 심장 박 동 간 격 심장 박 동 시간 초 과 (연 속 실패) 설명 4 G D TU 전송 (TC P) 30 - 60 초 3 회 (90 - 180 초) N AT 시간 초 과 , 트 래 픽 을 고려 4 G D TU 전송 (U DP) 15 - 30 초 5 회 (75 - 150 초) U DP 연결 없음 , 심장 박 동 이 더 자주 M Q TT (Wi Fi / 이 더 넷) 60 - 120 초 1. 5 × Keep Ali ve M Q TT 프로토 콜 규 격 준수 NB - IoT / 배터 리 전 원 300 - | |||
|---|---|---|---|
| 600 초 2 회 (6 00 - 1200 초) 전 력 절약 우선 , 더 긴 오 프 라인 검색 시간을 허용 로 컬 영역 네트워크 Mod bus TCP 게 이트 웨 이 120 - 300 초 3 회 유 선 네트워크 안정 성 , 완 화 할 수 있습니다 WiFi 직 렬 서버 30 - 60 초 3 회 WiFi 가 유 선 보다 더 높은 확률 | |||
5. 2 Linux 서버 측 TCP Keep Ali ve 매 개 변 수 권장 사항
在
net . ip v 4. t c p _ kee pali ve _ time = 120
net . ip v 4. t c p _ keep pali ve _ int v l = 10
net . ip v 4. t c p _ keep pali ve _ prob es = 3然后 적용 층 심장 박 동 (예 : 60 초 간 격) 을 더 하면 두 층 의 보 활 이 서로 밑 바 닥 을 덮 습니다 .
5. 3 D TU 실제 구성 예
다음은 일반적인 4 G D TU 구성 시 나 리오 입니다 (유 인 US R - G 7 80 의 예).
하 트 비 트 패키 지 : 활성화
심 박 주 기 : 60 초
하 트 비 트 내용 : Q (사 용 자 정의 문자 열)
등록 패키 지 : 사용
등록 패키 지 보내 기 방법 : 연결 시 한 번 보내 기
등록 패키 지 내용 : IM EI (장 치 IM EI 를 고유 식별 자로 사용)
연결 유형 : TCP Client
서버 주소 : your - server . com
서버 포 트 : 800 1
연결 끊 기 재 연 결 : 10 초 간 격 으로 최대 30 회 재 연 결서버 측 대응 논 리 :
- 收到 TCP 接続リクエスト → 接受连接
6. 심장 박 동 과 등록 의 일반적인 구 덩 이
6. 1 N AT 시간 초 과 및 심장 박 동 주 기 불 일 치
가장 일반적인 문제 : 심장 박 동 주 기는 5 분 으로 설정 되어 있으며 운영 자 N AT 시간 초 과는 2 분 입니다 .그 결과 , 모든 심장 박 동 간 격 , N AT 는 이미 끊 어 지고 , 심장 박 동 패 킷 은 보내 질 수 없으며 , 장 치는 영원히 " 연 결 → 2 분 후에 끊 기 → 심장 박 동 시간 초 과 재 연 결 → 연결 → 2 분 후에 끊 기 " 의 무한 루 프 에 있습니다 .
진단 방법 : 서버 측 에서 동일한 장치 의 연결 설정 시간 및 해 제 시간을 보고 해 제 시간 - 설정 시간이 거의 항상 고정 값 (예 : 120 초) 인 경우 기본적으로 N AT 시간 초 과 문제 입니다 .
解決：心跳周期
6. 2 연결 이 설정 된 후 즉시 등록 패키 지가 전송 되지 않았습니다 .
D TU 가 TCP 연결 을 설정 하면 등록 패 킷 이 아닌 트 랜 스 포 스 데이터를 먼저 전송 하면 서버 는 데이터가 어떤 장치 에서 왔 는지 확인할 수 없습니다 - 특히 여러 장치 가 서버 포 트를 공유 하는 경우 등록 패 킷 이 아닌 첫 번째 패 킷 이 수신 되면 서버 는 연결 을 삭제 하거나 종료 합니다 .
등록 패키 지가 소 켓 연결 이 성공 한 후 가능한 한 빨리 전송 되도록 보장 해야 합니다 .
6. 3 양 방 향 심장 박 동 은 한 쪽 만 한다 .
장치 가 심장 박 동 하고 서버 가 응답 하지 않습니다 - 서버 는 장치 가 살아 있다는 것을 알고 있지만 장치 가 살아 있는지 여 부를 알지 못합니다 .서버 가 프로그램 버 그 또는 네트워크 문제 로 인해 심 박 수에 응답 하지 않으면 장치 가 비즈니스 데이터 전송 시간이 초 과 될 때까지 계속 대기 할 수 있습니다 .
양 방 향 하 트 비 트를 사용하면 장치 측 도 서버 이상을 사전 예방 적으로 발견 하고 재 연 결 을 트 리 거 할 수 있습니다 .이 조 항 은 전 국에 분 포 되어 있으며 무 인 D TU 장비 에 매우 중요합니다 .
6. 4 TCP Keep Ali ve 의 플랫폼 간 차이 점
Windows , Linux , Free RT OS , L w IP 는 TCP Keep Ali ve 에 대한 기본 값 과 구성 가능한 매 개 변 수가 다릅니다 .리 눅 스는 기본 값 으로 7 200 초 , Windows 는 7 200 , 000 밀 리 초 (2 시간) 이며 , L w IP (임 베 디 드 TCP 프로토 콜 스 택) 는 기본 값 으로 큽 니다 .기본 값 에 의존 하지 마십시오 .
6. 5 등록 패키 지 내용이 검 증 되지 않았습니다 .
등록 된 패 킷 이 일반 텍스트 전송 (예를 들어 , IM EI 를 직접 보낸 경우) 은 네트워크 링크 에서 패 킷 에 의해 조작 될 수 있습니다 .보안 요구 사항 이 높은 시 나 리오 의 경우 등록 패키 지 에는 적어도 하나의 요 약 또는 서 명이 포함 되어야 합니다 .가장 간단한 방법 : 장비 는 미리 설정 된 대 칭 키 를 사용하여 IM EI + 타 임스 탬 프 에 H M AC 를 수행 하고 서버 는 H M AC 를 통과 한 후 등록 을 수 락 합니다 .
7. 체크 리스트 를 검사 하다
D TU 가 자주 오 프 라인 상태 가 되면 다음 순 서 로 확인 합니다 .
| 단계 검사 항목 방법 예상 1 하 트 비 트가 실제로 전송 중 인지 서버 측 로 그 / 패 킷 캡 처 설정 하 트 비 트 주 기에 따라 안정 적으로 수신 2 하 트 비 트 간 격 vs N AT 시간 초 과 비교 하 트 비 트 주 기와 운영 자 N AT 시간 초 과 하 트 비 트 주 기 N | |||
|---|---|---|---|
| <AT 시간 초 과 × 0. 6 3 서버 응답 여 부 디 바 이스 측 하 트 비 트 캡 처 로 그 " Q " 를 보낸 후 " A " 를 받은 후 4 자동 재 연 결 여 부 SIM 카드를 분리 하고 다시 연결 D TU 자동 재 연 결 + 등록 패 킷 전송 5 등록 패 킷 전송 여 부 캡 처 서버 TCP 연결 설정 후 첫 번째 패 킷 은 등록 패 킷 6 서버 측 TCP Keep Ali ve 매 개 변 수 ` s ys ct l net . ip v 4. TCP _ keep ali ve _ time ` ≤ 120 초 7 사업 자 신호 강 도 D TU AT 명령 ` AT + CS Q ` ≥ 15 (10 미 만 불안 정) 8 SIM 카드 트 래 픽 만 료 / 부 과 된 운영 자 트 래 픽 중단 백 그 라 운드 쿼 리 | |||
심장 박 동 과 등록 패키 지는 개념 이 간단 합니다 - 정기적으로 패키 지를 보내 자신이 누구인지 나타 냅니다 .그러나 실제로 , 세부 사항 은 매 개 변 수 선택 과 고 장 모 드에 대한 예측 에 있습니다 .이 기 사가 제공하는 숫자 (30 초 , 60 초 , 120 초) 는 임 의 로 작성 된 것이 아니며 국내 3 대 사업 자의 N AT 시간 초 과 , 4 G 모듈 의 전 력 제 약 및 서버 리 소 스 오 버 헤 드의 균형을 기반으로 합니다 .자신의 프로젝트 가 장면 이 다르 다면 테스트 환경에서 패키 지 검 증을 잡 으십시오 .
문제가 있으면 다시 이야기 하다 .
Leave a Reply