Constrained Application Protocol

Internetprotokollsvit
Applikationslager
Transportlager
Internetlager
Länklager

Constrained Application Protocol ( CoAP ) är ett specialiserat internetapplikationsprotokoll för begränsade enheter, enligt definitionen i RFC 7252 . Det gör det möjligt för de begränsade enheterna som kallas "noder" att kommunicera med det bredare Internet med liknande protokoll. CoAP är designad för användning mellan enheter på samma begränsade nätverk (t.ex. lågeffektsnätverk med förluster), mellan enheter och allmänna noder på Internet och mellan enheter på olika begränsade nätverk som båda är anslutna till ett internet. CoAP används också via andra mekanismer, såsom SMS på mobila kommunikationsnät.

CoAP är ett applikationslagerprotokoll som är avsett för användning i resursbegränsade Internetenheter, såsom trådlösa sensornätverksnoder . CoAP är designat för att enkelt översätta till HTTP för förenklad integration med webben, samtidigt som de uppfyller specialiserade krav som multicast- stöd, mycket låg overhead och enkelhet. Multicast, låg overhead och enkelhet är viktiga för Internet of things (IoT) och maskin-till-maskin- kommunikation (M2M), som tenderar att vara inbäddade och har mycket mindre minne och strömförsörjning än vad traditionella internetenheter har. Därför är effektivitet mycket viktigt. CoAP kan köras på de flesta enheter som stöder UDP eller en UDP-analog.

Internet Engineering Task Force ( IETF ) Constrained RESTful Environments Working Group ( CoRE ) har gjort det stora standardiseringsarbetet för detta protokoll. För att göra protokollet lämpligt för IoT- och M2M-applikationer har olika nya funktioner lagts till.

Specifikation

  Kärnan i protokollet specificeras i RFC 7252 . Olika förlängningar har föreslagits, särskilt:

  •   RFC 7641 (2015) Observationsresurser i Constrained Application Protocol
  •   RFC 7959 (2016) Block-Wise Transfers in the Constrained Application Protocol (CoAP)
  •   RFC 8323 (2018) CoAP (Constrained Application Protocol) över TCP, TLS och WebSockets
  •   RFC 8974 (2021) Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)

Meddelandeformat

CoAP använder sig av två meddelandetyper, förfrågningar och svar, med ett enkelt binärt headerformat. CoAP är som standard bundet till UDP och valfritt till DTLS , vilket ger en hög kommunikationssäkerhet. När det är bundet till UDP måste hela meddelandet rymmas i ett enda datagram. När de används med 6LoWPAN enligt definitionen i RFC 4944, bör meddelanden passa in i en enda IEEE 802.15.4- ram för att minimera fragmentering.

Det minsta CoAP-meddelandet är 4 byte långt, om token-, alternativ- och nyttolastfälten utelämnas, dvs om det bara består av CoAP-huvudet. Rubriken följs av tokenvärdet (0 till 8 byte) som kan följas av en lista med alternativ i ett optimerat typ-längd-värdeformat. Eventuella byte efter rubriken, token och alternativ (om några) anses vara meddelandenyttolasten, som föregås av en-byte "nyttolastmarkören" (0xFF). Längden på nyttolasten antyds av datagrammets längd.

CoAP-meddelande
Oktett offset 0 1 2 3
Bit offset 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 typ token längd begäran/svarskod meddelande-ID
8 64 token (0–8 byte)
12 96
16 128 alternativ (om tillgängligt)
20 160 1 1 1 1 1 1 1 1 nyttolast (om tillgänglig)

CoAP Header med fast storlek

De första 4 byten är obligatoriska i alla CoAP-datagram, de utgör rubriken med fast storlek.

Dessa fält kan extraheras från dessa 4 byte i C via dessa makron:






 #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] )

Version (ver) (2 bitar)

Indikerar CoAP-versionsnumret.

Typ (2 bitar)

Detta beskriver datagrammets meddelandetyp för de två meddelandetypskontexterna Request and Response.
  • Begäran
    • 0 : Bekräftas : Detta meddelande förväntar sig ett motsvarande bekräftelsemeddelande.
    • 1 : Ej bekräftad : Detta meddelande förväntar sig inget bekräftelsemeddelande.
  • Svar
    • 2: Kvittering: Detta meddelande är ett svar som bekräftar ett bekräftat meddelande
    • 3 : Återställ : Detta meddelande indikerar att det hade tagit emot ett meddelande men inte kunde bearbeta det.

Tokenlängd (4 bitar)

Indikerar längden på tokenfältet med variabel längd, som kan vara 0–8 byte långt.

Begäran/svarskod (8 bitar)

0 1 2 3 4 5 6 7
Klass Koda

De tre mest signifikanta bitarna bildar ett tal som kallas "klassen", vilket är analogt med klassen HTTP-statuskoder . De fem minst signifikanta bitarna bildar en kod som kommunicerar ytterligare detaljer om begäran eller svaret. Hela koden kommuniceras vanligtvis i formen class.code .

Du kan hitta de senaste CoAP-begäran/svarskoderna på [1] , även om listan nedan ger några exempel:

  • Metod: 0,XX
    1. TÖMMA
    2. SKAFFA SIG
    3. POSTA
    4. SÄTTA
    5. RADERA
    6. HÄMTA
    7. LAPPA
    8. iPATCH
  • Framgång: 2.XX
    1. Skapad
    2. raderade
    3. Giltig
    4. Ändrats
    5. Innehåll
    6. Fortsätta
  • Klientfel: 4.XX
    1. Dålig förfrågan
    2. Obehörig
    3. Dåligt alternativ
    4. Förbjuden
    5. Hittades inte
    6. metoden är inte tillåten
    7. Inte acceptabelt
    8. Begäran Entitet ofullständig
    9. Konflikt
    10. Förutsättningen misslyckades
    11. Begäran Entitet för stor
    12. Innehållsformat som inte stöds
  • Serverfel: 5.XX
    1. Internt serverfel
    2. Ej implementerad
    3. Dålig gateway
    4. Tjänsten är inte tillgänglig
    5. Gateway timeout
    6. Proxying stöds inte
  • Signaleringskoder: 7.XX
    1. Otilldelad
    2. CSM
    3. Ping
    4. Pong
    5. Släpp
    6. Avbryta

Meddelande-ID (16 bitar)

Används för att upptäcka meddelandeduplicering och för att matcha meddelanden av typen bekräftelse/återställning med meddelanden av typen bekräftabar/icke-bekräftelsebar.

Tecken

Varje begäran har en token (men den kan vara noll) vars värde genererades av klienten. Servern måste eka varje tokenvärde utan någon modifiering tillbaka till klienten i motsvarande svar. Den är avsedd att användas som en klient-lokal identifierare för att matcha förfrågningar och svar, särskilt för samtidiga förfrågningar.

Matchning av förfrågningar och svar görs inte med meddelande-ID eftersom ett svar kan skickas i ett annat meddelande än bekräftelsen (som använder meddelande-ID för matchning). Detta kan till exempel göras för att förhindra återsändningar om det tar lite tid att få resultatet. Ett sådant fristående svar kallas "separat svar". Däremot kallas sändning av svaret direkt i bekräftelsen "piggybacked response", vilket förväntas vara att föredra av effektivitetsskäl.

Alternativ

Alternativformat
Bitposition
0 1 2 3 4 5 6 7
Alternativ delta Alternativ längd
Alternativ delta utökad (ingen, 8 bitar, 16 bitar)
Alternativ längd utökad (ingen, 8 bitar, 16 bitar)
Alternativ värde

Alternativ delta:

  • 0 till 12: För delta mellan 0 till 12: Representerar det exakta deltavärdet mellan det sista alternativ-ID och önskat alternativ-ID, utan något utökat värde för delta
  • 13: För delta från 13 till 268: Alternativ delta utökat är ett 8-bitars värde som representerar optionens delta värde minus 13
  • 14: För delta från 269 till 65 804: Alternativ delta utökat är ett 16-bitars värde som representerar optionens deltavärde minus 269
  • 15: Reserverad för nyttolastmarkör, där alternativ delta och alternativ längd är satta tillsammans som 0xFF.

Alternativ längd:

  • 0 till 12: För alternativlängd mellan 0 till 12: Representerar det exakta längdvärdet, utan något utökat värde för optionlängden
  • 13: För optionlängd från 13 till 268: Alternativlängd förlängd är ett 8-bitars värde som representerar optionens längdvärde minus 13
  • 14: För optionlängd från 269 till 65 804: Alternativlängd förlängd är ett 16-bitars värde som representerar optionens längdvärde minus 269
  • 15: Reserverad för framtida bruk. Det är ett fel för alternativlängdsfältet att vara satt till 0xFF.

Alternativvärde:

  • Storleken på alternativvärdefältet definieras av optionens längdvärde i byte.
  • Semantisk och format detta fält beror på respektive alternativ.

Genomföranden

namn Programmeringsspråk Implementerad CoAP-version Klient-server Implementerade CoAP-funktioner Licens Länk
coap Pil RFC 7252 Klient Blockvisa överföringar, observera, multicast, proxy (delvis) MIT https://github.com/shamlett/coap
aiocoap Python 3 RFC 7252 Klient + Server Blockvisa överföringar, observera (delvis) MIT https://pypi.python.org/pypi/aiocoap
Kalifornien Java RFC 7252, RFC 7641, RFC 7959 Klient + Server Observera, Blockwise Transfers, Multicast (sedan 2.x), DTLS (+ DTLS 1.2 Connection ID) EPL+EDL https://www.eclipse.org/californium https://github.com/eclipse/californium
cantcoap C++/C RFC 7252 Klient + Server BSD https://github.com/staropram/cantcoap
Canopus Gå RFC 7252 Klient + Server Kärna Apache-licens 2.0 https://github.com/zubairhamed/canopus
Go-CoAP Gå RFC 7252, RFC 8232, RFC 7641, RFC 7959 Klient + Server Kärna, observera, blockvis, multicast, TCP/TLS Apache-licens 2.0 https://github.com/plgd-dev/go-coap
CoAP-implementering för Go Gå RFC 7252 Klient + Server Core + Draft Prenumerera MIT https://github.com/dustin/go-coap
CoAP.NET C# RFC 7252, coap-13, coap-08, coap-03 Klient + Server Kärna, observera, blockvisa överföringar 3-klausul BSD https://github.com/smeshlink/CoAP.NET
CoAPSharp C#, .NET RFC 7252 Klient + Server Kärna, observera, blockera, RD LGPL http://www.coapsharp.com
CoAPthon Pytonorm RFC 7252 Klient + Server + Forward Proxy + Reverse Proxy Observera, upptäckt av multicast-server, parsning av CoRE Link Format, blockvis MIT https://github.com/Tanganelli/CoAPthon
CoAP Shell Java RFC 7252 Klient Observera, Blockwise Transfers, DTLS Apache-licens 2.0 https://github.com/tzolov/coap-shell
Koppar JavaScript (webbläsarplugin) RFC 7252 Klient Observera, blockvisa överföringar 3-klausul BSD https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/ [ permanent död länk ]
eCoAP C RFC 7252 Klient + Server Kärna MIT https://gitlab.com/jobol/ecoap
Erbium för Contiki C RFC 7252 Klient + Server Observera, blockvisa överföringar 3-klausul BSD http://www.contiki-os.org/ (er-rest-example)
FreeCoAP C RFC 7252 Klient + Server + HTTP/CoAP-proxy Core, DTLS, Blockwise Transfers BSD https://github.com/keith-cullen/FreeCoAP
iCoAP Mål-C RFC 7252 Klient Kärna, observera, blockvisa överföringar MIT https://github.com/stuffrabbit/iCoAP
java-coap Java RFC 7252, RFC 7641, RFC 7959, RFC 8323 Klient + Server Apache-licens 2.0 https://github.com/PelionIoT/java-coap
jCoAP Java RFC 7252 Klient + Server Observera, blockvisa överföringar Apache-licens 2.0 https://code.google.com/p/jcoap/
libcoap C RFC 7252 Klient + Server Observera, Blockwise Transfers, DTLS BSD/GPL https://github.com/obgm/libcoap
LibNyoci C RFC 7252 Klient + Server Kärna, observera, blockera, DTLS MIT https://github.com/darconeous/libnyoci
lobaro-coap C RFC 7252 Klient + Server Observera, blockvisa överföringar MIT http://www.lobaro.com/lobaro-coap
mikrocoap C RFC 7252 Klient + Server MIT https://github.com/1248/microcoap
microCoAPy MicroPython RFC 7252 Klient + Server Kärna Apache-licens 2.0 https://github.com/insighio/microCoAPy
nanoCoAP C RFC 7252 Klient + Server Core, Blockwise Transfers, DTLS LGPL https://api.riot-os.org/group__net__nanocoap.html
nCoap Java RFC 7252 Klient + Server Observera, Blockwise Transfers, Core Link Format, Endpoint-ID-Draft BSD https://github.com/okleine/nCoAP
nod-coap Javascript RFC 7252,

RFC 7641, RFC 7959

 Klient + Server Kärna, observera, blockera MIT https://github.com/mcollina/node-coap
Ruby coap Rubin RFC 7252 Klient + Server (david) Kärna, observera, blockera, RD MIT, GPL
https://github.com/nning/coap https://github.com/nning/david
Sensinode C enhetsbibliotek C RFC 7252 Klient + Server Kärna, observera, blockera, RD Kommersiell https://silver.arm.com/browse/SEN00
Sensinode Java-enhetsbibliotek Java SE RFC 7252 Klient + Server Kärna, observera, blockera, RD Kommersiell https://silver.arm.com/browse/SEN00
Sensinode NanoService Platform Java SE RFC 7252 Molnserver Kärna, observera, blockera, RD Kommersiell https://silver.arm.com/browse/SEN00
SwiftCoAP Snabb RFC 7252 Klient + Server Kärna, observera, blockvisa överföringar MIT https://github.com/stuffrabbit/SwiftCoAP
TinyOS CoapBlip nesC/C coap-13 Klient + Server Observera, blockvisa överföringar BSD https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP
txThings Python (twisted) RFC 7252 Klient + Server Blockvisa överföringar, observera (delvis) MIT https://github.com/mwasilak/txThings/
coap-rs Rost RFC 7252 Klient + Server Core, Multicast, Observe option, Too Many Requests Response Code MIT https://github.com/Covertness/coap-rs

https://docs.rs/coap/

YaCoAP C MIT https://github.com/RIOT-Makers/YaCoAP

Proxyimplementationer

CoAP gruppkommunikation

I många CoAP-applikationsdomäner är det viktigt att ha förmågan att adressera flera CoAP-resurser som en grupp, istället för att adressera varje resurs individuellt (t.ex. för att tända alla CoAP-aktiverade lampor i ett rum med en enda CoAP-begäran som utlöses genom att växla lampknapp). För att möta detta behov har IETF utvecklat en valfri förlängning för CoAP i form av en experimentell RFC: Group Communication for CoAP - RFC 7390. Denna förlängning är beroende av IP multicast för att leverera CoAP-förfrågan till alla gruppmedlemmar. Användningen av multicast har vissa fördelar som att minska antalet paket som behövs för att leverera begäran till medlemmarna. Men multicast har också sina begränsningar som dålig tillförlitlighet och att det är ovänligt med cache. En alternativ metod för CoAP-gruppkommunikation som använder unicasts istället för multicasts är beroende av att ha en mellanhand där grupperna skapas. Klienter skickar sina gruppförfrågningar till mellanhanden, som i sin tur skickar individuella unicast-förfrågningar till gruppmedlemmarna, samlar in svaren från dem och skickar tillbaka ett aggregerat svar till kunden.

säkerhet

CoAP definierar fyra säkerhetslägen

  • NoSec, där DTLS är inaktiverat
  • PreSharedKey, där DTLS är aktiverat, finns det en lista med fördelade nycklar, och varje nyckel innehåller en lista över vilka noder den kan användas för att kommunicera med. Enheter måste stödja AES-chiffersviten.
  • RawPublicKey, där DTLS är aktiverat och enheten använder ett asymmetriskt nyckelpar utan certifikat, som valideras utanför bandet. Enheter måste stödja AES-chiffersviten och Elliptic Curve-algoritmerna för nyckelutbyte.
  • Certifikat, där DTLS är aktiverat och enheten använder X.509 -certifikat för validering.

Forskning har utförts för att optimera DTLS genom att implementera säkerhetsassociationer som CoAP-resurser snarare än att använda DTLS som ett säkerhetsomslag för CoAP-trafik. Denna forskning har visat att förbättringar på upp till 6,5 gånger ingen optimerade implementeringar.

Förutom DTLS definierar RFC8613 protokollet Object Security for Constrained RESTful Environments (OSCORE) som tillhandahåller säkerhet för CoAP i applikationslagret.

Säkerhetsproblem

Även om protokollstandarden innehåller bestämmelser för att mildra hotet om DDoS- förstärkningsattacker, implementeras dessa bestämmelser inte i praktiken, vilket resulterar i närvaron av över 580 000 mål som primärt finns i Kina och attacker upp till 320 Gbps.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Constrained_Application_Protocol&oldid=1139948343 "