IoT Protocol CoAP 메시지 요청/응답 모델 내용 정리

 본 포스트에서는 CoAP(Constrained Application Protocol, RFC 2752)의 메시지 모델에서 지원하는 Request의 메소드와 Response의 코드 및 옵션에 대해 알아보았다.

CoAP의 메시지 형식에 대한 내용은 아래 포스트에서 다룬 적이 있다.

IoT protocol CoAP 메시지 구조(Message Format) 요약 정리

∘ CoAP의 Request/Response 모델

CoAP는 HTTP의 Request/Response 모델과 유사하게 운영된다. 클라이언트는 서버로 CoAP Request를 보내고, 서버는 요청에 해당하는 응답을 클라이언트로 보내게 된다. 다만, CoAP는 HTTP와 달리 endpoint간에 TCP 연결을 필요로 하지 않는다.

CoAP는 HTTP와 유사한 GET, PUT, POST, DELETE 메소드를 제공한다. 

Request는 CoAP 헤더의 Code필드를 메소드 코드로 설정하고 Request 정보를 포함한다. Response는 헤더의 Code필드를 응답 코드로 하여 Response를 식별하도록 되어있다. 이는 HTTP에서 상태코드를 사용하는 것과 유사하다.

Code 필드는 아래와 같이 Class와 Detail로 나눠진다.

Class는 다음과 같은 카테고리로 구분된다. 

• 0 Request
• 2 Response Success
• 3 Response Client Error, The Request contains bad syntax or cannot be fulfilled
• 4 Response Server Error The server failed to fulfill an apparently valid request

∘ Request/Response 전송 모델

CoAP에서 Request/Response 송수신 모델은 다음 3가지로 구분될 수 있다.

1. Piggybacked

클라이언트의 Request에 대해 서버는 바로 Response를 반환한다.

2. Separate

서버는 Request를 받은 후 ACK를 보내고, 기 요청된 데이터가 준비되면 클라이언트로 메시지를 전송한다.

3. Non-confirmable

클라이언트에서 Non-confirmable 메시지로 Request를 보낼 경우, Server는 새로운 Non-confirm 메시지를 사용해 Response를 보낸다.

[Note] Request/Response의 매칭은 Piggybacked response의 경우 request의 Message ID와 Token이 동일해야 하며, separate response의 경우 해당 Request과 동일한 Token을 사용해야 한다. 

∘ Request Method

GET

Code는 0.01 이다.

Request URI로 구분되는 리소스에 메시지내의 representation에 해당하는 정보를 검색/요청한다.

Request에 Accept 옵션이 있을 경우, 이 옵션에서 지정한 콘텐츠 형식으로 Response의 Payload를 만들어야 한다.

만약 Request에 ETag 옵션이 포함되어 있을 경우, GET 메서드는 ETag의 유효성을 검사하고, 유효성이 실패한 경우에만 정보표현이 전송되도록 요청한다. 

요청에 성공할 경우 2.05(Content)나 2.03(Valid)가 Response Code에 들어 있어야 한다. (SHOULD)

[Note] representation은 CoAP 메시지의 payload에 들어있는 내용을 의미한다. 예를 들어 위 전송 모델 이미지내의 "temperature"로 문자열로 표현된 데이터를 representation이라 한다.

POST

Code는 0.02며 POST 메서드는 Request에 포함된 representation을 처리하도록 요청한다. 

서버에서 POST 메서드에 의해 리소스가 생성된 경우, Response에 2.01(Created) Response Code와 새 리소스의 URI가 포함된 Location-Path 와/혹은 Location-Query Option이 포함되어야 한다. (SHOULD)

서버에서 POST 처리가 성공했으나 새로운 리소스가 만들어지지 않은 겨우 Response에는 2.04(Changed) Response Code가 포함되어야 한다. (SHOULD)

만약 POST에 의해 리소스가 제거되었을 경우, Response에는 2.02(Deleted) Response Code가 포함되어야 한다.

PUT

Code는 0.03이며 PUT 메서드는 request URI로 식별된 리소스를 메시지내에 전달되는 representation을 이용하여 업데이트 하거나 생성하도록 요청한다. 

Representation 형식은 Content-Format 옵션이 있다면 이 형식에 따른다.

Request URI에 리소스가 존재한다면, 동봉된 representation은 해당 리소스의 수정버전으로 인식되고, 2.04(Change) Response Code를 응답한다. 만약 리소스가 존재하지 않는다면, 2.01(Created) Response Code를 응답한다. 만약, 업데이트 하거나 새로 생성하지 못한다면 error response code를 응답한다. (SHOULD)

PUT 메소드에는 If-Match, IF-None-Match 옵션을 포함할 수 있다. 

DELETE

Code는 0.04이고, Request URI로 식별되는 리소스를 제거하는 요청을 한다.

제거 성공이나 해당 리소스가 없는 경우, 2.02(Deleted) Response Code를 응답한다.

∘ Response Code

Success 2.xx

2.01 Created - POST, PUT 요청의 응답. Location-Path/Location-Query 옵션이 포함될 수 있다. Not Cacheable

2.02 Deleted - DELETE, POST 요청의 응답. Not Cacheable

2.03 Valid - ETag 옵션으로 식별된 entity-tag로 식별된 응답이 유효한지 나타내기 위해 사용된다. 응답에 ETag 옵션이 포함돼야 하며, payload는 포함되어서는 안 된다. 

2.04 Changed - POST, PUT 요청의 응답. Not Cacheable

2.05 Content - HTTP 200 “OK”와 같으며 GET 요청의 응답으로만 사용된다. 요청된 데이터가 들어있는 Payload를 함께 반환한다. Cacheable 

Client Error 4.xx

4.00 Bad Request - HTTP 400 “Bad Request”와 같다. 

4.01 Unauthorized - 클라이언트가 요청 작업을 수행할 권한이 없음을 의미한다. 

4.02 Bad Option - 서버가 요청을 이해하지 못함을 의미한다. 

4.03 Forbidden - HTTP 403 “Forbidden”과 같아. 

4.04 Not Found - HTTP 404 “Not Found”와 같다. 

4.05 Method Not Allowed - HTTP 405 “Method Not Allowed와 유사하다.

4.06 Not Acceptable - HTTP 406 “Not Acceptable”과 같지만, response entity가 없다. 

4.12 Precondition Failed - HTTP 412 “Precondition Failed” 

4.13 Request Entity Too Large - HTTP 413 “Request Entity Too Large”와 같다. 응답에는 Size1 옵션을 포함해 처리가능한 최대 크기를 알려준다. (SHOULD)

4.15 Unsupported Content-Format - HTTP 415 “Unsupported Media type”과 같다. 

Server Error 5.xx

5.00 Internal Server Error - HTTP 500 “Internal Server Error”와 같다. 

5.01 Not Implemented - HTTP 501 “Not Implemented”와 같다.

5.02 Bad Gateway - HTTP 502 “Bad Gateway”와 같다. 

5.03 Service Unavailable - HTTP 503 “Service Unavailable”과 같으나, HTTP 헤더 필드의 “Retry-After” 대신 CoAP에서는 MAX-Age 옵션이 사용된다.

5.04 Gateway Timeout - HTTP 504 “Gateway Timeout”과 같다. 

5.05 Proxying Not Supported - 서버가 Proxy-Uri 옵션이나 Proxy-Scheme을 사용에 지정된 URI에 대해 forward-proxy 역할을 수행할 수 없거나 실행하지 않음을 의미한다. 

∘ Request/Response 옵션

CoAP의 옵션은 아래 표와 같으며, Option Number로 구분된다. 

Uri-Host, Uri-Port, Uri-Path, Uri-Query

Uri-Host, Uri-Port, Uri-Path, Uri-Query는 CoAP서버에 요청 대상 리소스를 지정하는데 사용된다. 

Uri-Host - 요청중인 리소스의 인터넷 호스트를 지정한다. 

Uri-Port - port 번호를 지정한다. 

Uri-Path - 리소스의 절대 경로를 지정한다. 

Uri-Query - 리소스를 매개 변수화 하는 하나의 인수를 지정한다. 

Proxy-Uri and Proxy-Scheme

Proxy-Uri는 forward-proxy에 대한 request를 만드는데 사용된다.

Forward-proxy는 request를 전달하거나 프록시 내부의 유효한 캐시에서 서비스하고 response를 반환하도록 요청된다. Option 값은 Absolute-Uri이다. 

Forward-proxy 동작은 예를 들어, 클라이언트가 example.com 에 연결하려고 하면 사용자 클라이언트가 직접 연결하는 것이 아니라 포워드 프록시 서버가 요청을 받아서 example.com 에 연결하여 그 결과를 클라이언트에 전달(forward) 해 준다. Forward-proxy는 대개 caching 기능이 있으므로 자주 사용되는 컨텐츠라면 월등한 성능 향상을 가져올 수 있으며 정해진 사이트만 연결하게 설정하는 등 웹 사용 환경을 제한할 수 있으므로 기업 환경 등에서 많이 사용한다.

Proxy-Uri를 받은 endpoint가 forward-proxy 역할을 수행하지 못할 경우 5.05 (Proxying Not Support) Response code를 응답해야 한다. (MUST)

Proxy-Uri는 Uri-Host,Uri-Port,Uri-Path, Uri-Query옵션보다 우선시되어야 한다.(MUST)

많은 프록시 클라이언트를 단수화 하기 위한 특별한 경우 Absolute-Uri는 Uri-* 옵션에서 구성할 수 있다.

Proxy-Scheme이 있는 경우 Absolute-Uri는 Uri-* 옵션들로 구성된 결과 URI에서, 초기 체계까지, 그러나 포함하지 않고, 다음 콜론이 Proxy-Scheme 내용으로 대체된다. 

Content-Format

Payload에 있는 메시지의 표현 형식을 지정한다. 표현 형식은 아래표의 숫자 ID를 사용한다.  

Accept

Accept은 클라이언트가 받아들일 수 있는 Content-Format을 알려주는데 사용한다. 포맷은 위 표의 숫자 ID를 사용하여 전달한다.

만약 Accept 옵션이 없는 경우 디폴트 값으로 인식되고 서버는 가능 하면 Content-format을 표시해 응답한다.  

만약 서버에서 선호된 Content-Format을 사용하여 응답메시지를 보낼 수 없으면, 4.06 (Not Acceptable) Response Code를 반환해야 한다. (MUST)

Max-Age

Max-Age는 Response가 최대로 캐시될 수 있는 시간을 지정한다. 만약 Max-Age 옵션이 없다면, 디폴트 값으로 60초다.

ETag

HTTP의 ETag 참조 https://en.wikipedia.org/wiki/HTTP_ETag

entity-tag는 오랜 시간후의 동일한 리소스의 표현을 구별하기 위해 resource-local 식별자로 사용하기 위한 것이다. 서버에의 해 생성되며 버전, 체크섬, 해시, 시간 등을 포함한 다양한 방식으로 생성될 수 있다. 

Location-Path and Location-Query

Location-Path와 Location-Query 옵션 둘은 절대 경로, 쿼리 문자열 또는 둘 다로 구성된 상대 URI를 나타낸다. 

이 조합은 2.01 (Created) Response에 포함되어 POST 요청의 결과로 리소스가 생성된 위치를 알려주는데 사용된다. 위치는 요청 URI의 기준으로 결정된다. 

Conditional Request Options (IF-Match, IF-None-Match)

이 옵션을 사용하면 서버는 특정 요건을 충족한 경우에만 클라이언트의 요청을 수행한다. 

조건을 만족하지 않으면, 요청을 수행해지 않아야 하며, 서버는 4.12 (Precondition Failed) Response Code를 반환해야 한다.

IF-Match/IF-None-Match 옵션은 일반적으로 여러 클라이언트가 동일한 리소스에서 병렬로 작동할 때 실수로 덮어쓰지 않도록 보호기이 위한 수단으로 사용되며, PUT Request에서 IF-Match는 리소스 업데이트에 IF-None-Match는 생성 요청에 유용한다. 

IF-Match 옵션의 값은 ETag거나 빈 문자열이다. ETag인 일치하는 representation ETag인 경우를 의미하고, 빈 문자열인 경우 대상 리소스의 representation이 존재하는가에 전제 조건을 부여한다. 

IF-None-Match 옵션의 값은 비어 있으며, 만약 리소스가 비어 있으면 조건을 충족하지 않는 것을 의미한다. 

Size1

Size1 옵션은 Request를 보낸 클라이언트가 처리할 수 있는 리소스의 크기 정보를 서버로 전달할 때 사용한다.