제약된 응용 프로그램 프로토콜
Constrained Application Protocol인터넷 프로토콜 스위트 |
---|
응용 프로그램레이어 |
트랜스포트 레이어 |
인터넷 레이어 |
링크 레이어 |
Constrainted Application Protocol(CoAP)은 RFC 7252에서 정의된 제약 장치를 위한 특수한 인터넷응용 프로그램 프로토콜입니다.이를 통해 "노드"라고 불리는 제약이 있는 장치가 유사한 프로토콜을 사용하여 더 넓은 인터넷과 통신할 수 있습니다.CoAP는 같은 제약 네트워크상의 디바이스(저전력 손실 네트워크 등), 인터넷상의 디바이스와 일반 노드 간 및 인터넷에 접속되어 있는 다른 제약 네트워크상의 디바이스 간에 사용하도록 설계되어 있습니다.CoAP는 이동통신 네트워크의 SMS와 같은 다른 메커니즘을 통해서도 사용되고 있습니다.
CoAP는 무선 센서 네트워크 노드 등 리소스가 제한된 인터넷 장치에서 사용하기 위한 서비스 계층 프로토콜입니다.CoAP는 HTTP로 쉽게 변환하여 웹과의 통합을 간소화하는 동시에 멀티캐스트 지원, 매우 낮은 오버헤드, 단순성 등의 특수한 요건을 [1][2]충족하도록 설계되었습니다.멀티캐스트, 낮은 오버헤드 및 단순성은 사물인터넷(IoT) 및 머신 투 머신(M2M) 통신에 중요합니다.이러한 통신에는, 깊이 짜여져 있는 경향이 있어, 기존의 인터넷 디바이스에 비해 메모리와 전원 장치의 수가 큰폭으로 적어집니다.따라서 효율은 매우 중요합니다.CoAP는 UDP 또는 UDP 아날로그를 지원하는 대부분의 디바이스에서 실행할 수 있습니다.
Internet Engineering Task Force(IETF) Constrainted RESTful Environments Working Group(CoRE; 제약 RESTful 환경 작업 그룹)은 이 프로토콜의 주요 표준화 작업을 수행했습니다.IoT 및 M2M 애플리케이션에 적합한 프로토콜을 만들기 위해 다양한 기능이 추가되었습니다.
사양
프로토콜의 핵심은 다음에서 지정됩니다. RFC7252.특히 다음과 같은 다양한 확장이 제안되고 있습니다.
- RFC 7641 (2015) 제약된 애플리케이션 프로토콜에서의 자원 감시
- RFC 7959 (2016) 제약 애플리케이션 프로토콜(CoAP)에서의 Block-Wise 전송
- RFC 8323 (2018) TCP, TLS, WebSockets를 통한 CoAP (Constrainted Application Protocol)
- RFC 8974 (2021) Constrainted Application Protocol (CoAP)에서의 확장 토큰과 스테이트리스 클라이언트
메시지 형식
토큰, 옵션 및 페이로드 필드가 생략된 경우 CoAP 메시지의 최소 길이는 4바이트입니다.CoAP에서는 요청과 응답이라는2가지 메시지유형을 사용합니다.단순한 바이너리 기본 헤더 형식을 사용합니다.기본 헤더 뒤에 최적화된 type-length-value 형식의 옵션이 이어지는 경우가 있습니다.CoAP는 기본적으로는 UDP에 바인드되며 옵션으로 DTLS에 바인드되어 높은 수준의 통신 보안을 제공합니다.
패킷 내의 헤더 뒤에 바이트가 있으면 메시지 본문으로 간주됩니다.메시지 본문의 길이는 데이터그램 길이에 의해 암시됩니다.UDP에 바인드할 경우 메시지 전체가 단일 데이터그램 내에 있어야 합니다.RFC 4944에 정의되어 있는6 LoWPAN과 함께 사용하는 경우 메시지는 단편화를 최소화하기 위해1개의 IEEE 802.15.4 프레임에 들어갈 필요가 있습니다.
옥텟 오프셋 | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
비트 오프셋 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
4 | 32 | 베루 | 유형 | 토큰 길이 | 요청/응답 코드 | 메시지 ID | |||||||||||||||||||||||||||
8 | 64 | 토큰(0~8바이트) | |||||||||||||||||||||||||||||||
12 | 96 | ||||||||||||||||||||||||||||||||
16 | 128 | 옵션(사용 가능한 경우) | |||||||||||||||||||||||||||||||
20 | 160 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | payload(사용 가능한 경우) |
CoAP 고정 헤더
첫 번째 4바이트는 모든 CoAP 데이터그램에서 필수입니다.
다음 필드는 다음 매크로를 통해 C의 다음 4바이트에서 추출할 수 있습니다.
#정의 COAP_HEADER_VERSION(데이터) (0xC0 & (데이터)[0]>> 6 ) #COAP_HEADER_TYPE(데이터)( (0x30 & (데이터)[0])>> 4 )의 정의 #COAP_HEADER_TKL(데이터)의 정의(0x0F & (데이터)[0]>> 0 ) #정의 COAP_HEADER_CLASS(데이터)((데이터)[1]>> 5) & 0x07 ) #COAP_HEADER_CODE(데이터)((데이터)[1]>> 0) & 0x1F)의 정의 #정의 COAP_HEADER_MID(데이터)((데이터)[2] << 8) (데이터)[3] )
버전 (ver) (2비트)
- CoAP 버전 번호를 나타냅니다.
유형(2비트)
- 요청과 응답의 두 가지 메시지 유형 컨텍스트에 대한 데이터그램의 메시지 유형을 설명합니다.
- 부탁한다
- 0 : Confirmable : 이 메시지는 대응하는 확인 응답 메시지를 요구합니다.
- 1 : Non-confirmable : 이 메시지는 확인 메시지를 예상하지 않습니다.
- 대답
- 2 : Acknowledgement : 이 메시지는 확인 가능한 메시지를 확인하는 응답입니다.
- 3 : Reset : 이 메시지는 메시지를 받았으나 처리할 수 없음을 나타냅니다.
- 부탁한다
토큰 길이(4비트)
- 가변 길이 토큰 필드의 길이를 나타냅니다.길이는 0 ~8바이트입니다
요청/응답 코드(8비트)
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
---|---|---|---|---|---|---|---|
학급 | 코드 |
최상위 3비트는 HTTP 상태 코드의 클래스와 유사한 "클래스"라고 불리는 번호를 형성합니다.최하위 5비트는 요청 또는 응답에 대한 자세한 내용을 전달하는 코드를 형성합니다.코드 전체는 일반적으로 다음 형식으로 전달됩니다.class.code
.
최신 CoAP 요구/응답 코드는 [1]에서 확인할 수 있습니다.다만, 다음의 리스트는 몇개의 예를 나타내고 있습니다.
- 방법: 0.XX
- 빈
- 얻다
- 포스트.
- 놓다
- 삭제
- 가지고 오다
- 패치
- 아이패치
- 성공: 2XX
- 창조했다
- 삭제됨
- 유효한
- 변경되었다.
- 내용
- 계속하다.
- 클라이언트 오류: 4.XX
- 부정한 요구
- 무허가
- 잘못된 옵션
- 금지된
- 찾을 수 없음
- 허용되지 않는 메서드
- 받아들일 수 없다
- 요청 엔티티 미완료
- 갈등.
- 사전 조건 실패
- 요청 엔티티가 너무 큽니다.
- 지원되지 않는 콘텐츠 형식
- 서버 오류: 5.XX
- 내부 서버 오류
- 미실장
- 불량 게이트웨이
- 서비스를 사용할 수 없습니다.
- 게이트웨이 타임아웃
- 프록시는 지원되지 않습니다.
- 시그널링 코드: 7 。XX
- 미할당
- CSM
- ping
- 퐁
- 풀어주다
- 중단
메시지 ID(16비트)
- 메시지 중복을 검출하여 확인 응답/리셋 유형의 메시지를 확인 가능/확인 불가 유형의 메시지와 대조하기 위해 사용합니다.응답 메시지는 요청과 동일한 메시지 ID를 가집니다.
상품권
토큰 길이 필드에 의해 크기가 지정되며 값이 클라이언트에 의해 생성됩니다.서버는 변경 없이 모든 토큰 값을 클라이언트에 에코해야 합니다.특정 동시 트랜잭션에 대한 추가 컨텍스트를 제공하기 위해 클라이언트 로컬 식별자로 사용하기 위한 것입니다.
선택
비트 위치 | |||||||
---|---|---|---|---|---|---|---|
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
옵션 델타 | 옵션 길이 | ||||||
옵션 델타 확장(없음, 8비트, 16비트) | |||||||
확장 옵션 길이(없음, 8비트, 16비트) | |||||||
옵션값 |
옵션 델타:
- 0 ~ 12 : delta가 0 ~12인 경우 : 마지막 옵션 ID와 원하는 옵션 ID 사이의 정확한 델타 값을 나타냅니다.옵션 델타 확장 값은 없습니다.
- 13: 델타가 13 ~268인 경우:옵션 델타 확장값은 옵션 델타 값에서 13을 뺀 값을 나타내는8비트 값입니다.
- 14: 델타가 269 ~65,804인 경우: Option delta extended는 옵션 델타 값에서 269를 뺀 16비트 값입니다.
- 15: 페이로드 마커용으로 예약되어 있습니다.옵션 델타와 옵션 길이를 0xFF로 설정합니다.
옵션 길이:
- 0 ~ 12: 옵션 길이가 0 ~12인 경우: 정확한 길이 값을 나타냅니다.옵션 길이 확장 값은 없습니다.
- 13: 옵션 길이가 13 ~268인 경우: 옵션 길이가 확장되는 값은 옵션 길이 값에서 13을 뺀 값을 나타내는 8비트 값입니다.
- 14: 옵션 길이가 269 ~65,804인 경우:옵션 길이가 확장되는 값은 옵션 길이 값에서 269를 뺀 16비트 값입니다.
- 15: 향후 사용을 위해 예약되어 있습니다.옵션 길이 필드가 0xFF로 설정되는 것은 오류입니다.
옵션 값:
- 옵션 값 필드의 크기는 옵션 길이 값(바이트)으로 정의됩니다.
- 이 필드의 의미 및 형식은 각 옵션에 따라 달라집니다.
실장
이름. | 프로그래밍 언어 | 구현된 CoAP 버전 | 클라이언트/서버 | CoAP 기능 구현 | 면허증. | 링크 |
---|---|---|---|---|---|---|
코프 | 다트 | RFC 7252 | 고객 | Blockwise 전송, 감시, 멀티캐스트, 프록시(부분) | MIT | https://github.com/shamblett/coap |
아이오쿠 | 파이썬 3 | RFC 7252 | 클라이언트 + 서버 | 블록별 전송, 관찰(부분) | MIT | https://pypi.python.org/pypi/aiocoap |
칼리포늄 | 자바 | RFC 7252, RFC 7641, RFC 7959 | 클라이언트 + 서버 | 감시, Blockwise Transfers, Multicast(2.x 이후), DTLS(+DTLS 1.2 접속 ID) | EPL+EDL | https://www.eclipse.org/californium https://github.com/eclipse/californium |
할 수 없다 | C++/C | RFC 7252 | 클라이언트 + 서버 | BSD | https://github.com/staropram/cantcoap | |
카노푸스속 | 가세요 | RFC 7252 | 클라이언트 + 서버 | 핵심 | Apache 라이센스 2.0 | https://github.com/zubairhamed/canopus |
Go-CoAP | 가세요 | RFC 7252, RFC 8232, RFC 7641, RFC 7959 | 클라이언트 + 서버 | 코어, 감시, 블록화, 멀티캐스트, TCP/TLS | Apache 라이센스 2.0 | https://github.com/go-ocf/go-coap |
Go를 위한 CoAP 구현 | 가세요 | RFC 7252 | 클라이언트 + 서버 | 코어 + 드래프트 구독 | MIT | https://github.com/dustin/go-coap |
CoAP.NET | C# | RFC 7252, coap-13, coap-08, coap-03 | 클라이언트 + 서버 | 코어, 감시, 블록 단위 전송 | 3절 BSD | https://github.com/smeshlink/CoAP.NET |
CoAPSharp | C#, .NET | RFC 7252 | 클라이언트 + 서버 | 코어, 감시, 블록, RD | LGPL | http://www.coapsharp.com |
CoAPthon | 파이썬 | RFC 7252 | 클라이언트 + 서버 + 전송 프록시 + 역방향 프록시 | 감시, 멀티캐스트서버 검출, CoRE 링크 포맷 해석, 블록 단위 | MIT | https://github.com/Tanganelli/CoAPthon |
CoAP 쉘 | 자바 | RFC 7252 | 고객 | 감시, Blockwise Transfers, DTLS | Apache 라이센스 2.0 | https://github.com/tzolov/coap-shell |
구리 | JavaScript(브라우저 플러그인) | RFC 7252 | 고객 | 관찰, Blockwise 전송 | 3절 BSD | https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/[영구 데드링크] |
eCoAP | C | RFC 7252 | 클라이언트 + 서버 | 핵심 | MIT | https://gitlab.com/jobol/ecoap |
콘티키용 엘비움 | C | RFC 7252 | 클라이언트 + 서버 | 관찰, Blockwise 전송 | 3절 BSD | http://www.contiki-os.org/ (er-rest-module) |
Free CoAP | C | RFC 7252 | 클라이언트 + 서버 + HTTP/CoAP 프록시 | 코어, DTLS, Blockwise 전송 | BSD | https://github.com/keith-cullen/FreeCoAP |
iCoAP | 목표-C | RFC 7252 | 고객 | 코어, 감시, 블록 단위 전송 | MIT | https://github.com/stuffrabbit/iCoAP |
자바맵 | 자바 | RFC 7252, RFC 7641, RFC 7959, RFC 8323 | 클라이언트 + 서버 | Apache 라이센스 2.0 | https://github.com/PelionIoT/java-coap | |
jCoAP | 자바 | RFC 7252 | 클라이언트 + 서버 | 관찰, Blockwise 전송 | Apache 라이센스 2.0 | https://code.google.com/p/jcoap/ |
libcoap | C | RFC 7252 | 클라이언트 + 서버 | 감시, Blockwise Transfers, DTLS | BSD/GPL | https://github.com/obgm/libcoap |
리브뇨치 | C | RFC 7252 | 클라이언트 + 서버 | 코어, 감시, 블록, DTLS | MIT | https://github.com/darconeous/libnyoci |
로바로코프 | C | RFC 7252 | 클라이언트 + 서버 | 관찰, Blockwise 전송 | MIT | http://www.lobaro.com/lobaro-coap |
마이크로코프 | C | RFC 7252 | 클라이언트 + 서버 | MIT | https://github.com/1248/microcoap | |
마이크로 CoAPY | 마이크로피톤 | RFC 7252 | 클라이언트 + 서버 | 핵심 | Apache 라이센스 2.0 | https://github.com/insighio/microCoAPy |
나노캡 | C | RFC 7252 | 클라이언트 + 서버 | 코어, Blockwise 전송 | LGPL | https://api.riot-os.org/group__net__nanocoap.html |
nCoap | 자바 | RFC 7252 | 클라이언트 + 서버 | 감시, Blockwise 전송, CoRE 링크 형식, 엔드포인트 ID 드래프트 | BSD | https://github.com/okleine/nCoAP |
노드 맵 | 자바스크립트 | RFC 7252, RFC 7641, RFC 7959 | 클라이언트 + 서버 | 코어, 감시, 블록 | MIT | https://github.com/mcollina/node-coap |
루비코프 | 루비 | RFC 7252 | 클라이언트 + 서버 (데이비드) | 코어, 감시, 블록, RD | MIT, GPL | https://github.com/nning/coap https://github.com/nning/david |
Sensinode C 디바이스 라이브러리 | C | RFC 7252 | 클라이언트 + 서버 | 코어, 감시, 블록, RD | 상업의 | https://silver.arm.com/browse/SEN00 |
Sensinode Java 장치 라이브러리 | 자바 SE | RFC 7252 | 클라이언트 + 서버 | 코어, 감시, 블록, RD | 상업의 | https://silver.arm.com/browse/SEN00 |
Sensinode Nano Service 플랫폼 | 자바 SE | RFC 7252 | 클라우드 서버 | 코어, 감시, 블록, RD | 상업의 | https://silver.arm.com/browse/SEN00 |
Swift CoAP | 재빠르다 | RFC 7252 | 클라이언트 + 서버 | 코어, 감시, 블록 단위 전송 | MIT | https://github.com/stuffrabbit/SwiftCoAP |
TinyOS CoapBlip | nesC/C | 코프-13 | 클라이언트 + 서버 | 관찰, Blockwise 전송 | BSD | https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP |
txThings | Python(트위스트) | RFC 7252 | 클라이언트 + 서버 | 블록별 전송, 관찰(부분) | MIT | https://github.com/mwasilak/txThings/ |
코퍼 | 녹 | RFC 7252 | 클라이언트 + 서버 | 코어, 멀티캐스트, 감시 옵션, 너무 많은 요청 응답 코드 | MIT | https://github.com/Covertness/coap-rs |
YaCoAP | C | MIT | https://github.com/RIOT-Makers/YaCoAP |
프록시 실장
CoAP 그룹 통신
많은 CoAP 응용 프로그램 도메인에서는 각 리소스를 개별적으로 처리하는 것이 아니라 여러 CoAP 리소스를 그룹으로 처리하는 기능이 필수적입니다(예를 들어 조명 스위치를 전환하여 트리거되는 단일 CoAP 요청을 사용하여 실내의 모든 CoAP 지원 조명을 켜는 것).이 요구에 대응하기 위해 IETF는 실험적인 RFC: Group Communication for CoAP - RFC 7390[3] 형식으로 CoAP용 옵션 확장을 개발했습니다.이 확장은 모든 그룹 멤버에게 CoAP 요구를 전달하기 위해 IP 멀티캐스트에 의존합니다.멀티캐스트를 사용하면 멤버에게 요구를 전달하기 위해 필요한 패킷 수를 줄이는 등의 이점이 있습니다.그러나 멀티캐스트에는 낮은 신뢰성과 캐시 프렌들리(cache-friendly)라는 한계도 있습니다.멀티캐스트 대신 유니캐스트를 사용하는 CoAP 그룹 통신의 대체 방법은 그룹이 생성되는 매개체가 있어야 합니다.클라이언트는 자신의 그룹 요구를 중개자에게 송신합니다.중개자는 개별 유니캐스트 요구를 그룹 멤버에게 송신하고 그룹 멤버로부터 응답을 수집하여 [4]집약 응답을 클라이언트에 반환합니다.
보안.
CoAP는 4가지 보안[5] 모드를 정의합니다.
- NoSec. 여기서 DTLS는 디세이블입니다.
- PreSharedKey(DTLS가 네이블로 되어 있는 경우)에는 사전 공유 키 목록이 있으며 각 키에는 통신에 사용할 수 있는 노드의 목록이 포함됩니다.디바이스는 AES 암호 스위트를 지원해야 합니다.
- RawPublicKey: DTLS가 네이블로 되어 있어 디바이스는 증명서 없이 비대칭 키쌍을 사용합니다.이 쌍은 대역외로 검증됩니다.디바이스는 키 교환을 위해 AES 암호 스위트 및 타원 곡선 알고리즘을 지원해야 합니다.
- Certificate:DTLS가 네이블로 디바이스는 검증에 X.509 증명서를 사용합니다.
DTLS를 CoAP 트래픽의 보안 래퍼로 사용하는 것이 아니라 CoAP 리소스로서 보안 어소시에이트를 실장함으로써 DTLS를 최적화하는 연구가 진행되어 왔습니다.이 조사에서는 최적화되지 않은 구현이 최대 6.5배 향상되는 것으로 나타났습니다.[6]
DTLS와 더불어 RFC8613에서는[7] 애플리케이션 층에서 CoAP의 보안을 제공하는 OSCORE(Object Security for Constrained RESTful Environments) 프로토콜을 정의하고 있습니다.
보안 문제
프로토콜 표준에는 DDoS 증폭 [8]공격의 위협을 완화하기 위한 조항이 포함되어 있지만,[9] 이러한 조항은 실제로 구현되지 않아 주로 중국에 58만 개 이상의 대상이 있으며 최대 320 Gbps의 [10]공격이 발생합니다.
「 」를 참조해 주세요.
레퍼런스
- ^ RFC 7252, Constrained Application Protocol(CoAP)
- ^ "무선 센서 네트워크와 웹 통합", Walter, Colitti 2011
- ^ RFC 7390, CoAP용 그룹 통신
- ^ "CoAP 지원 장치를 위한 유연한 유니캐스트 기반 그룹 통신", I., I., Hoeke, J., Van den Abele, F., Rossey, J., Moerman, I., Deemester, P Sensors 2014.
- ^ RFC 7252, Constrained Application Protocol(CoAP)
- ^ Capossele, Angelo; Cervo, Valerio; De Cicco, Gianluca; Petrioli, Chiara (June 2015). "Security as a CoAP resource: An optimized DTLS implementation for the IoT". IEEE: 529–554. doi:10.1109/ICC.2015.7248379.
- ^ Palombini, Francesca; Seitz, Ludwig; Selander, Goeran; Mattsson, John. "Object Security for Constrained RESTful Environments (OSCORE)". tools.ietf.org. Retrieved 2021-05-07.
- ^ "TLS 1.3은 우리 모두를 구할 것입니다. IoT가 여전히 안전하지 않은 다른 이유들도 있습니다.", Dani Grant, 2017-12-24
- ^ "머신이 말을 할 수 없는 경우: 머신 투 머신 데이터 프로토콜의 보안 및 개인 정보 보호 문제", Federico Maggi 및 Rainer Vosseler, 2018-12-06
- ^ Catalin Cimpanu, 2018-12-05년, "CoAP 프로토콜은 DDoS 공격의 차세대 주요 요소입니다."
외부 링크
- RFC 7252 "제한된 애플리케이션 프로토콜(CoAP)"
- coap.me – 브레멘 대학에서 운영하는 CoAP 테스트 서버