CoAP
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
CoAP(Constrained Application Protocol)는 저전력, 저성능 장치를 위해 설계된 응용 계층 프로토콜이다. 주로 사물 통신(M2M) 애플리케이션에 적합하며, UDP를 기본 전송 프로토콜로 사용하고 DTLS를 통한 보안을 제공한다. CoAP는 메시지 형식으로 요청과 응답을 사용하며, 4바이트의 고정 헤더, 토큰(0-8바이트), 옵션, 페이로드로 구성된다. 주요 특징으로는 낮은 오버헤드, URI 및 미디어 타입 지원, 리소스 검색, 리소스 구독 및 푸시 알림, HTTP와의 매핑을 통한 프록시 구축 등이 있다. CoAP는 다양한 확장 기능을 지원하며, 그룹 통신 및 여러 보안 모드를 제공하지만, DDoS 증폭 공격과 같은 보안 문제점도 존재한다. 다양한 프로그래밍 언어로 구현된 클라이언트 및 서버 라이브러리가 존재하며, HTTP-CoAP 프록시를 통해 HTTP 환경에서 CoAP 리소스에 접근할 수 있다.
더 읽어볼만한 페이지
- HTTP - HTTPS
HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다. - HTTP - HTTP 쿠키
HTTP 쿠키는 웹 서버가 사용자 브라우저에 저장하는 작은 텍스트 파일로, 웹 사이트가 방문 기록, 로그인 정보 등을 기억하여 HTTP의 상태 비저장성을 보완하고 세션 관리, 개인 설정, 사용자 추적 등에 활용되지만 개인 정보 보호 및 보안 문제에 대한 논란이 있다. - 사물인터넷 - 스마트 스피커
스마트 스피커는 음성 명령으로 다양한 기능을 수행하는 인공지능 스피커로, 여러 기업이 경쟁하며 액정 모니터 탑재 제품도 출시되고 있지만, 개인 정보 보호, 보안 취약점, 디지털 격차 등의 문제도 안고 있다. - 사물인터넷 - 웨어러블 테크놀로지
웨어러블 테크놀로지는 신체에 착용하는 전자 장치 및 기술로, 시계에서 시작하여 스마트워치 등으로 발전해왔으며 다양한 분야에서 활용되지만 개인 정보 보호와 같은 과제도 안고 있다. - 응용 계층 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다. - 응용 계층 프로토콜 - D-Bus
D-Bus는 2002년에 시작된 프로세스 간 통신 시스템으로, 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다.
| CoAP | |
|---|---|
| 개요 | |
| 유형 | 인터넷 프로토콜 |
| 하위 유형 | 애플리케이션 계층 프로토콜 |
| 약칭 | CoAP |
| 개발 | IETF (제한된 노드에서의 인터넷 엔지니어링 태스크 포스) |
| RFC | RFC 7252 |
2. 메시지 형식
CoAP는 간단한 이진 헤더 형식을 사용하여 요청과 응답의 두 가지 메시지 유형을 사용한다.[20] CoAP는 기본적으로 UDP에 바인딩되며, 선택적으로 DTLS에 바인딩되어 높은 수준의 통신 보안을 제공한다. UDP에 바인딩된 경우 전체 메시지는 단일 데이터그램 내에 포함되어야 한다. 6LoWPAN과 함께 사용될 때, 메시지는 단편화를 최소화하기 위해 단일 IEEE 802.15.4 프레임에 포함되어야 한다.
가장 작은 CoAP 메시지는 토큰, 옵션 및 페이로드 필드가 생략된 경우, 즉 CoAP 헤더만으로 구성된 경우 길이가 4바이트이다. 헤더 뒤에는 최적화된 타입-길이-값 형식의 옵션 목록이 뒤따를 수 있는 토큰 값(0~8바이트)이 온다. 헤더, 토큰 및 옵션(있는 경우) 뒤의 모든 바이트는 1바이트 "페이로드 마커"(0xFF)가 앞에 붙는 메시지 페이로드로 간주된다. 페이로드의 길이는 데이터그램 길이에 의해 암시된다.[20]
CoAP는 HTTP 상태 코드와 유사한 구조를 가지는 요청/응답 코드를 사용한다. CoAP 메시지 헤더의 주요 필드는 다음과 같다.
- 버전(VER) (2비트): CoAP 버전 번호
- 유형(Type) (2비트): 메시지 유형
- 0: 확인 가능(Confirmable)
- 1: 비확인 가능(Non-confirmable)
- 2: 확인 응답(Acknowledgement)
- 3: 리셋(Reset)
- 토큰 길이(TKL) (4비트): 토큰 필드의 길이 (0~8바이트)
- 요청/응답 코드 (8비트):
- 상위 3비트: 클래스 (예: 0 - 메서드, 2 - 성공, 4 - 클라이언트 오류, 5 - 서버 오류)
- 하위 5비트: 코드 (자세한 내용)
- 일반적으로 `클래스.코드` 형식으로 표현 (예: 2.05 - 콘텐츠)
- 메시지 ID(MID) (16비트): 메시지 중복 감지 및 메시지 일치에 사용
2. 1. CoAP 메시지 구조
CoAP 메시지는 4바이트의 고정 크기 헤더, 0~8바이트 길이의 토큰, 옵션, 그리고 페이로드로 구성된다.[20] 최소 CoAP 메시지 길이는 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 | 페이로드 (사용 가능한 경우) | |||||||||||||||||||||||
CoAP는 요청과 응답, 두 가지 메시지 유형을 사용하며, 간단한 이진 헤더 형식을 가진다. 기본적으로 UDP에 바인딩되며, 선택적으로 DTLS에 바인딩되어 높은 수준의 통신 보안을 제공한다. UDP에 바인딩된 경우 전체 메시지는 단일 데이터그램 내에 포함되어야 한다. 6LoWPAN과 함께 사용될 때, 메시지는 단편화를 최소화하기 위해 단일 IEEE 802.15.4 프레임에 포함되어야 한다.
헤더 뒤에는 최적화된 타입-길이-값 형식의 옵션 목록이 뒤따를 수 있는 토큰 값(0~8바이트)이 온다. 헤더, 토큰 및 옵션(있는 경우) 뒤의 모든 바이트는 1바이트 "페이로드 마커"(0xFF)가 앞에 붙는 메시지 페이로드로 간주된다. 페이로드의 길이는 데이터그램 길이에 의해 암시된다.
C 언어 매크로를 사용하여 헤더 정보를 추출할 수 있다.
```c
#define COAP_HEADER_VERSION(data) ( (0xC0 & data[0])>>6 )
#define COAP_HEADER_TYPE(data) ( (0x30 & data[0])>>4 )
#define COAP_HEADER_TKL(data) ( (0x0F & data[0])>>0 )
#define COAP_HEADER_CLASS(data) ( ((data[1]>>5)&0x07) )
#define COAP_HEADER_CODE(data) ( ((data[1]>>0)&0x1F) )
#define COAP_HEADER_MID(data) ( (data[2]<<8)|(data[3]) )
2. 1. 1. 버전 (VER)
CoAP 버전 번호를 나타내며, 2비트 크기이다.2. 1. 2. 유형 (TYPE)
CoAP 메시지 유형은 2비트 크기로, 요청(Request)과 응답(Response) 두 가지 컨텍스트를 가진다.- 요청(Request)
- 0: 확인 가능(Confirmable) - 확인 응답 메시지를 기대한다.
- 1: 비-확인 가능(Non-confirmable) - 확인 메시지를 기대하지 않는다.
- 응답(Response)
- 2: 승인(Acknowledgement) - 확인 가능한 메시지에 대한 응답이다.
- 3: 재설정(Reset) - 메시지를 수신했지만 처리할 수 없었음을 나타낸다.
CoAP 헤더에서 유형(Type) 필드는 메시지 유형을 나타내며, C 헤더에서는 다음 매크로를 사용하여 추출할 수 있다.
```c
#define COAP_HEADER_TYPE(data) ( (0x30 & data[0])>>4 )
2. 1. 3. 토큰 길이 (TKL)
토큰 길이(TKL)는 4비트 크기로, 가변 길이 토큰 필드의 길이(0~8바이트)를 나타낸다.| 오프셋 | 옥텟 | 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 | VER | 유형 | 토큰 길이 | CoAP 요청/응답 코드 | 메시지 ID | |||||||||||||||||||||||||||
| 8 | 64 | 토큰 (0-8바이트) | |||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| 16 | 128 | 옵션 (존재하는 경우) | |||||||||||||||||||||||||||||||
| 20 | 160 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 페이로드 (존재하는 경우) | |||||||||||||||||||||||
2. 1. 4. CoAP 요청/응답 코드
CoAP 요청/응답 코드는 8비트 크기로, 상위 3비트는 클래스, 하위 5비트는 코드로 구성된다. 보통 `클래스.코드` 형태로 표현된다.| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Class | Code | ||||||
이는 HTTP 상태 코드 클래스와 유사한 개념이다. 최신 CoAP 요청/응답 코드는 [https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#codes]에서 확인할 수 있다. 다음은 주요 코드 클래스 예시이다.
- 메서드: 0.XX
- 성공: 2.XX
- 클라이언트 오류: 4.XX
- 서버 오류: 5.XX
- 신호 코드: 7.XX
C 헤더에서 정보를 추출하기 위해 다음과 같은 매크로를 사용할 수 있다.
```c
#define COAP_HEADER_CLASS(data) ( ((data[1]>>5)&0x07) )
#define COAP_HEADER_CODE(data) ( ((data[1]>>0)&0x1F) )
2. 1. 5. CoAP 등록 코드
CoAP의 최신 등록 코드는 [https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#codes]에서 확인할 수 있다.[1]가장 중요한 세 비트는 HTTP 상태 코드 클래스와 유사한 "클래스"를 나타내며, 덜 중요한 다섯 비트는 요청 또는 응답에 대한 자세한 내용을 전달하는 코드를 형성한다. 전체 코드는 일반적으로 `class.code` 형식으로 전달된다.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Class | Code | ||||||
다음은 코드의 몇 가지 예시이다.
- 메서드: 0.XX
| 코드 | 설명 |
|---|---|
| 0.01 | GET |
| 0.02 | POST |
| 0.03 | PUT |
| 0.04 | DELETE |
| 0.05 | FETCH |
| 0.06 | PATCH |
| 0.07 | iPATCH |
- 성공: 2.XX
| 코드 | 설명 |
|---|---|
| 2.01 | 생성됨 |
| 2.02 | 삭제됨 |
| 2.03 | 유효함 |
| 2.04 | 변경됨 |
| 2.05 | 콘텐츠 |
| 2.31 | 계속 |
- 클라이언트 오류: 4.XX
| 코드 | 설명 |
|---|---|
| 4.00 | 잘못된 요청 |
| 4.01 | 권한 없음 |
| 4.02 | 잘못된 옵션 |
| 4.03 | 금지됨 |
| 4.04 | 찾을 수 없음 |
| 4.05 | 메서드 허용 안 됨 |
| 4.06 | 허용 불가 |
| 4.08 | 요청 엔터티 불완전 |
| 4.09 | 충돌 |
| 4.12 | 사전 조건 실패 |
| 4.13 | 요청 엔터티가 너무 큼 |
| 4.15 | 지원되지 않는 콘텐츠 형식 |
- 서버 오류: 5.XX
| 코드 | 설명 |
|---|---|
| 5.00 | 내부 서버 오류 |
| 5.01 | 구현되지 않음 |
| 5.02 | 잘못된 게이트웨이 |
| 5.03 | 서비스 사용 불가 |
| 5.04 | 게이트웨이 시간 초과 |
| 5.05 | 프록시 지원 안 됨 |
- 신호 코드: 7.XX
| 코드 | 설명 |
|---|---|
| 7.01 | CSM |
| 7.02 | 핑 |
| 7.03 | 퐁 |
| 7.04 | 릴리스 |
| 7.05 | 중단 |
2. 1. 6. 메시지 ID (MID)
메시지 ID는 16비트 크기로, 메시지 중복을 감지하고 확인 응답(Acknowledgement)/재설정(Reset) 유형의 메시지를 확인 가능(Confirmable)/비확인 가능(Non-confirmable) 유형의 메시지와 일치시키는 데 사용된다.| 오프셋 | 옥텟 | 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 | VER | 유형 | 토큰 길이 | CoAP 요청/응답 코드 | 메시지 ID | |||||||||||||||||||||||||||
| 8 | 64 | 토큰 (0-8바이트) | |||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| 16 | 128 | 옵션 (존재하는 경우) | |||||||||||||||||||||||||||||||
| 20 | 160 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 페이로드 (존재하는 경우) | |||||||||||||||||||||||
2. 2. 토큰 (Token)
CoAP에서 모든 요청에는 클라이언트가 생성한 토큰이 포함된다. 토큰의 길이는 0~8바이트이며, 서버는 이 토큰 값을 변경하지 않고 응답에 그대로 포함시켜 클라이언트에 다시 보낸다. 이 토큰은 특히 여러 요청이 동시에 발생할 때, 클라이언트가 요청과 응답을 짝 맞추는 데 사용하는 식별자 역할을 한다.요청과 응답을 일치시키는 작업은 메시지 ID가 아닌 토큰으로 수행된다. 응답이 확인(Acknowledgement, 메시지 ID로 일치)과 함께 다른 메시지로 전송될 수 있기 때문이다. 예를 들어, 결과를 얻는 데 시간이 오래 걸리는 경우, 재전송을 막기 위해 이러한 방식을 사용할 수 있다. 이렇게 확인 메시지와 분리된 응답을 "별도 응답"이라고 한다. 반대로, 확인 메시지에서 바로 응답을 보내는 것을 "피기백 응답"이라고 하며, 효율성 때문에 더 선호되는 방식이다.
CoAP 헤더에서 토큰 길이는 4비트로 표현되며, 가변 길이 토큰 필드의 길이를 나타낸다. 길이는 0에서 8바이트까지 가능하다.
2. 3. 옵션 (Option)
CoAP 옵션은 타입-길이-값 (TLV) 형식으로 구성된다. 각 옵션은 옵션 델타, 옵션 길이, 옵션 값으로 구성된다.| 비트 위치 | |||||||
|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 옵션 델타 | 옵션 길이 | ||||||
| 옵션 델타 확장 (없음, 8비트, 16비트) | |||||||
| 옵션 길이 확장 (없음, 8비트, 16비트) | |||||||
| 옵션 값 | |||||||
- 옵션 델타:
- 0 ~ 12: 마지막 옵션 ID와 현재 옵션 ID 간의 차이값을 나타낸다. 옵션 델타 확장 값은 없다.
- 13: 13부터 268까지의 델타는 8비트 옵션 델타 확장 값(옵션 델타 값에서 13을 뺀 값)을 갖는다.
- 14: 269부터 65,804까지의 델타는 16비트 옵션 델타 확장 값(옵션 델타 값에서 269를 뺀 값)을 갖는다.
- 15: 페이로드 마커용으로 예약되며, 옵션 델타와 옵션 길이는 모두 0xFF로 설정된다.
- 옵션 길이:
- 0 ~ 12: 0부터 12까지의 옵션 길이 값을 나타낸다. 옵션 길이 확장 값은 없다.
- 13: 13부터 268까지의 옵션 길이는 8비트 옵션 길이 확장 값(옵션 길이 값에서 13을 뺀 값)을 갖는다.
- 14: 269부터 65,804까지의 옵션 길이는 16비트 옵션 길이 확장 값(옵션 길이 값에서 269를 뺀 값)을 갖는다.
- 15: 향후 사용을 위해 예약됨. 옵션 길이 필드가 0xFF로 설정된 것은 오류이다.
3. 주요 특징
CoRE 그룹은 다음과 같은 주요 특징을 염두에 두고 CoAP를 설계했다.[11]
- 낮은 오버헤드와 구문 분석 복잡성
- URI 및 미디어 타입 지원
- 알려진 CoAP 서비스에서 제공하는 리소스 검색 지원
- 리소스에 대한 단순한 구독 및 그 결과 푸시 알림
- max-age 기반의 단순 캐시
CoAP와 HTTP의 매핑도 정의되어 있어, HTTP를 통해 CoAP 리소스에 통일된 방식으로 접근할 수 있는 프록시를 구축할 수 있다.[11] CoAP의 도입으로, 제약된 장치 및 환경에 적합한 오픈 표준 프로토콜의 완전한 네트워크 스택을 사용할 수 있게 된다.[12]
4. CoAP 확장
5. CoAP 그룹 통신
IETF는 실험적 RFC 형태의 CoAP 선택적 확장인 CoAP용 그룹 통신(RFC 7390)을 개발했다.[3] 이 확장은 IP 멀티캐스트에 의존하여 CoAP 요청을 모든 그룹 구성원에게 전달한다. 멀티캐스트를 사용하면 요청을 구성원에게 전달하는 데 필요한 패킷 수를 줄이는 등 특정 이점이 있다. 그러나 멀티캐스트는 신뢰성이 낮고 캐시 친화적이지 않다는 제한 사항도 있다.
멀티캐스트 대신 유니캐스트를 사용하는 CoAP 그룹 통신을 위한 대안적인 방법은 그룹이 생성되는 중개자를 두는 것이다. 클라이언트는 그룹 요청을 중개자에게 보내고, 중개자는 개별 유니캐스트 요청을 그룹 구성원에게 보낸 후, 구성원으로부터 응답을 수집하여 클라이언트에게 집계된 응답을 다시 보낸다.[4]
6. 보안
- NoSec: DTLS가 비활성화된다.
- PreSharedKey: DTLS가 활성화되고, 사전 공유 키 목록이 있으며, 각 키에는 통신에 사용할 수 있는 노드 목록이 포함된다. 장치는 AES 암호 제품군을 지원해야 한다.
- RawPublicKey: DTLS가 활성화되고 장치는 인증서 없이 비대칭 키 쌍을 사용하며, 이는 대역 외에서 검증된다. 장치는 키 교환을 위해 AES 암호 제품군 및 타원 곡선 알고리즘을 지원해야 한다.
- Certificate: DTLS가 활성화되고 장치는 검증을 위해 X.509 인증서를 사용한다.
CoAP 트래픽에 대한 보안 래퍼로 DTLS를 사용하는 대신, CoAP 리소스로 보안 연관을 구현하여 DTLS를 최적화하는 연구가 수행되었다. 이 연구는 최적화되지 않은 구현보다 최대 6.5배의 개선을 나타냈다.[6]
DTLS 외에도 RFC8613[7]은 애플리케이션 계층에서 CoAP에 대한 보안을 제공하는 제약된 RESTful 환경을 위한 객체 보안(OSCORE) 프로토콜을 정의한다.
7. 보안 문제점
CoAP 프로토콜 표준에는 DDoS 증폭 공격의 위협을 완화하기 위한 조항이 포함되어 있다.[8] 그러나 이러한 조항은 실제로 구현되지 않아[9] 주로 중국에 위치한 580,000개 이상의 표적이 존재하고 최대 320Gbit/s의 공격이 발생한다.[10]
8. 구현체
CoAP는 다양한 프로그래밍 언어로 구현되어 있으며, 클라이언트 및 서버 라이브러리 형태로 제공된다. 다음은 주요 CoAP 구현체 목록이다.
| 이름 | 프로그래밍 언어 | 클라이언트/서버 | 구현된 CoAP 기능 | 라이선스 | 링크 | |
|---|---|---|---|---|---|---|
| aiocoap | Python 3 | 클라이언트 + 서버 | 블록 단위 전송, 관찰 (부분) | MIT | https://pypi.python.org/pypi/aiocoap | |
| Californium | Java | 클라이언트 + 서버 | 관찰, 블록 단위 전송, DTLS | EPL+EDL | https://www.eclipse.org/californium https://github.com/eclipse/californium | |
| cantcoap | C++/C | 클라이언트 + 서버 | BSD | https://github.com/staropram/cantcoap | ||
| Canopus | Go | 클라이언트 + 서버 | Core | Apache License 2.0 | https://github.com/zubairhamed/canopus | |
| Go-CoAP | Go | 클라이언트 + 서버 | 핵심, 관찰, 블록 단위, 멀티캐스트, TCP/TLS | 아파치 라이선스 2.0 | https://github.com/plgd-dev/go-coap | |
| Go용 CoAP 구현 | Go | 클라이언트 + 서버 | 핵심 + 초안 구독 | MIT | https://github.com/dustin/go-coap | |
| CoAP.NET | C# | 클라이언트 + 서버 | 핵심, 관찰, 블록 단위 전송 | 3-clause BSD | https://github.com/smeshlink/CoAP.NET | |
| CoAPSharp | C#, .NET | 클라이언트 + 서버 | 핵심, 관찰, 블록, RD | LGPL | http://www.coapsharp.com | |
| CoAPthon | Python | 클라이언트 + 서버 + 전달 프록시 + 역 프록시 | 관찰, 멀티캐스트 서버 검색, CoRE 링크 형식 구문 분석, 블록 단위 | MIT | https://github.com/Tanganelli/CoAPthon | |
| CoAP Shell | Java | 클라이언트 | 관찰, 블록 단위 전송, DTLS | Apache License 2.0 | https://github.com/tzolov/coap-shell | |
| Copper | JavaScript (브라우저 플러그인) | 클라이언트 | 관찰, 블록 단위 전송 | 3-clause BSD | https://github.com/mkovatsc/Copper | |
| eCoAP | C | 클라이언트 + 서버 | 핵심 | MIT | https://gitlab.com/jobol/ecoap | |
| Contiki용 Erbium | C | 클라이언트 + 서버 | 관찰, 블록 단위 전송 | 3-clause BSD | http://www.contiki-os.org/ (er-rest-example) | |
| FreeCoAP | C | 클라이언트 + 서버 + HTTP/CoAP 프록시 | 핵심, DTLS, 블록 단위 전송 | BSD | https://github.com/keith-cullen/FreeCoAP | |
| guile-coap | Guile | 클라이언트 + 서버 | GPL-3.0-or-later | https://codeberg.org/eris/guile-coap | ||
| iCoAP | Objective-C | 클라이언트 | 핵심, 관찰, 블록 단위 전송 | MIT | https://github.com/stuffrabbit/iCoAP | |
| java-coap | Java | 클라이언트 + 서버 | 아파치 라이선스 2.0 | https://github.com/PelionIoT/java-coap | ||
| jCoAP | Java | 클라이언트 + 서버 | 관찰, 블록 단위 전송 | Apache License 2.0 | https://code.google.com/p/jcoap/ | |
| libcoap | C | 클라이언트 + 서버 | 핵심, 관찰, 멀티캐스트, 블록 단위 전송, 패치/가져오기, OSCORE, DTLS | BSD/GPL | https://github.com/obgm/libcoap | |
| LibNyoci | C | 클라이언트 + 서버 | 핵심, 관찰, 블록, DTLS | MIT | https://github.com/darconeous/libnyoci | |
| lobaro-coap | C | 클라이언트 + 서버 | 관찰, 블록 단위 전송 | MIT | http://www.lobaro.com/lobaro-coap | |
| microcoap | C | 클라이언트 + 서버 | MIT | https://github.com/1248/microcoap | ||
| microCoAPy | MicroPython | 클라이언트 + 서버 | 핵심 | 아파치 라이선스 2.0 | https://github.com/insighio/microCoAPy | |
| nanoCoAP | C | 클라이언트 + 서버 | 핵심, 블록 단위 전송, DTLS | LGPL | https://api.riot-os.org/group__net__nanocoap.html | |
| nCoap | Java | 클라이언트 + 서버 | 관찰, 블록 단위 전송, CoRE 링크 형식, https://tools.ietf.org/html/draft-kleine-core-coap-endpoint-id-01 Endpoint-ID-Draft | BSD | https://github.com/okleine/nCoAP | |
| node-coap | Javascript | 클라이언트 + 서버 | 핵심, 관찰, 블록 | MIT | https://github.com/mcollina/node-coap | |
| Qt CoAP | C++ | 클라이언트 | 핵심, 관찰, 블록 단위 전송 | GPL, 상업용 | https://doc.qt.io/qt-6/qtcoap-index.html | |
| Ruby coap | Ruby | 클라이언트 + 서버 (david) | 핵심, 관찰, 블록, RD | MIT, GPL | https://github.com/nning/coap https://github.com/nning/david | |
| Sensinode C 장치 라이브러리 | C | 클라이언트 + 서버 | 핵심, 관찰, 블록, RD | 상업용 | https://silver.arm.com/browse/SEN00 | |
| Sensinode Java 장치 라이브러리 | Java SE | 클라이언트 + 서버 | 핵심, 관찰, 블록, RD | 상업용 | https://silver.arm.com/browse/SEN00 | |
| Sensinode NanoService 플랫폼 | Java SE | 클라우드 서버 | 핵심, 관찰, 블록, RD | 상업용 | https://silver.arm.com/browse/SEN00 | |
| SwiftCoAP | Swift | 클라이언트 + 서버 | 핵심, 관찰, 블록 단위 전송 | MIT | https://github.com/stuffrabbit/SwiftCoAP | |
| TinyOS CoapBlip | nesC/C | 클라이언트 + 서버 | 관찰, 블록 단위 전송 | BSD | https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP | |
| txThings | Python (Twisted) | 클라이언트 + 서버 | 블록 단위 전송, 관찰 (부분) | MIT | https://github.com/mwasilak/txThings/ | |
| coap-rs | Rust | 클라이언트 + 서버 | 핵심, 멀티캐스트, 관찰 옵션, 요청이 너무 많음 응답 코드 | MIT | https://github.com/Covertness/coap-rs https://docs.rs/coap/ | |
| YaCoAP | C | MIT | https://github.com/RIOT-Makers/YaCoAP | |||
| coap | Dart | 클라이언트 | 블록 단위 전송, 관찰, 멀티캐스트, 프록시 (부분) | MIT | https://github.com/shamblett/coap |
각 구현체는 지원하는 기능, 라이선스, 사용된 프로그래밍 언어 등이 다양하므로, 특정 요구사항에 맞는 구현체를 선택하여 사용할 수 있다.
9. 프록시 구현
HTTP-CoAP 프록시를 사용하면 HTTP 환경에서도 CoAP 리소스에 접근할 수 있다. 다음은 몇 가지 프록시 구현 사례이다.
- Squid 3.1.9: 투명 HTTP-CoAP 매핑 모듈을 포함한다.
- jcoap Proxy
- Californium cf-proxy
- Californium cf-proxy2
- CoAPthon
- FreeCoAP
참조
[1]
문서
RFC 7252, Constrained Application Protocol (CoAP)
https://tools.ietf.o[...]
[2]
웹사이트
Integrating Wireless Sensor Networks with the Web
http://hinrg.cs.jhu.[...]
Walter, Colitti
2017-08-30
[3]
문서
RFC 7390, Group Communication for CoAP
https://tools.ietf.o[...]
[4]
간행물
Flexible Unicast-Based Group Communication for CoAP-Enabled Devices
http://www.mdpi.com/[...]
Sensors
[5]
문서
RFC 7252, Constrained Application Protocol (CoAP)
https://tools.ietf.o[...]
[6]
서적
2015 IEEE International Conference on Communications (ICC)
2015-06
[7]
간행물
Object Security for Constrained RESTful Environments (OSCORE)
https://tools.ietf.o[...]
2021-05-07
[8]
뉴스
TLS 1.3 is going to save us all, and other reasons why IoT is still insecure
https://blog.cloudfl[...]
2017-12-24
[9]
뉴스
When Machines Can't Talk: Security and Privacy Issues of Machine-to-Machine Data Protocols
https://i.blackhat.c[...]
2018-12-06
[10]
뉴스
The CoAP protocol is the next big thing for DDoS attacks
https://www.zdnet.co[...]
2018-12-05
[11]
문서
Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
https://www.rfc-edit[...]
[12]
문서
IETF Standardization in the Field of the Internet of Things (IoT): A Survey
http://www.mdpi.com/[...]
[13]
문서
Group Communication for CoAP
https://www.rfc-edit[...]
[14]
간행물
Flexible Unicast-Based Group Communication for CoAP-Enabled Devices
http://www.mdpi.com/[...]
Sensors
[15]
뉴스
TLS 1.3 is going to save us all, and other reasons why IoT is still insecure
https://blog.cloudfl[...]
2017-12-24
[16]
뉴스
When Machines Can't Talk: Security and Privacy Issues of Machine-to-Machine Data Protocols
https://i.blackhat.c[...]
2018-12-06
[17]
뉴스
The CoAP protocol is the next big thing for DDoS attacks
https://www.zdnet.co[...]
2018-12-05
[18]
문서
RFC 7252, Constrained Application Protocol (CoAP)
https://tools.ietf.o[...]
[19]
웹사이트
Integrating Wireless Sensor Networks with the Web
http://hinrg.cs.jhu.[...]
Walter, Colitti
2017-08-30
[20]
문서
Options Numbers
https://www.iana.org[...]
[21]
뉴스
TLS 1.3 is going to save us all, and other reasons why IoT is still insecure
https://blog.cloudfl[...]
2017-12-24
[22]
뉴스
When Machines Can't Talk: Security and Privacy Issues of Machine-to-Machine Data Protocols
https://i.blackhat.c[...]
2018-12-06
[23]
뉴스
The CoAP protocol is the next big thing for DDoS attacks
https://www.zdnet.co[...]
2018-12-05
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com