CoAP協(xié)議詳解PPT課件_第1頁
CoAP協(xié)議詳解PPT課件_第2頁
CoAP協(xié)議詳解PPT課件_第3頁
CoAP協(xié)議詳解PPT課件_第4頁
CoAP協(xié)議詳解PPT課件_第5頁
已閱讀5頁,還剩86頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

CoAP TheConstrainedApplicationProtocol 協(xié)議詳解 Jade2016 12 目錄 概述MessageModelRequest ResponseModelOptionsCoAP組播CoAP代理SecuringCoAP CoAP是什么 CoAP是IETF為滿足物聯(lián)網(wǎng) M2M場景制定的協(xié)議 特點(diǎn)如下 類似HTTP 基于REST模型 Servers將Resource通過URI形式呈現(xiàn) 客戶端可以通過諸如GET PUT POST DELETE方法訪問 但是相對HTTP簡化實(shí)現(xiàn)降低復(fù)雜度 代碼更小 封包更小 應(yīng)用于資源受限的環(huán)境 內(nèi)存 存儲 無良好的隨機(jī)源 比如CPU為8 bit的單片機(jī) 內(nèi)存32Kb FLASH256Kb針對業(yè)務(wù)性能要求不高的應(yīng)用 低速率 10sofkbit s 低功耗滿足CoRE環(huán)境的HTTP簡化增強(qiáng)版本 協(xié)議模型 特征基于UDP的類似HTTP的Client Server交互模型Client發(fā)送Request 攜帶不同method 請求對資源 通過URI表示 的操作 Server返回Response 攜帶資源的representation 和狀態(tài)碼在M2M應(yīng)用場景 Endpoint實(shí)際同時(shí)是Server和Client 邏輯上分為Message和Request Response兩層 Request Response通過Message承載 從封包上不體現(xiàn)這種層次結(jié)構(gòu)DTLS DatagramTransportLayerSecurity 可選由于基于UDP 支持組播 協(xié)議參與方 協(xié)議定義了如下角色 Endpoint CoAP協(xié)議的參與方Sender 發(fā)出Message的Endpoint 等于sourceEndpointRecipient Message的目的Endpoint 等于destinationEndpointClient 發(fā)出Request的Endpoint Response的destinationEndpointServer Request的destinationEndpoint Response的sourceEndpointOriginServer resource的所在的ServerIntermediary 既作為Server由作為OriginServer的Client的Endpoint 可以理解為是Proxy的統(tǒng)稱 協(xié)議參與方 續(xù) Proxy 一種Intermediary 完成Request前轉(zhuǎn) Respone中繼 執(zhí)行緩存 namespace轉(zhuǎn)換 協(xié)議轉(zhuǎn)換等功能的Endpoint 基于前轉(zhuǎn)請求架構(gòu)中的位置 協(xié)議定義了forward proxy和reverse proxy兩種代理Forward Proxy 被Client用于代表Client執(zhí)行Request 并完成任何必要的轉(zhuǎn)換 Reverse Proxy 代表一個(gè)或多個(gè)其他服務(wù)器并代表它們滿足請求 執(zhí)行任何必要的翻譯的端點(diǎn) 與轉(zhuǎn)發(fā)代理不同 客戶端可能不知道它正在與反向代理通信 反向代理接收請求 就像它是目標(biāo)資源的源服務(wù)器一樣 CoAP to CoAPProxy 映射CoAPrequest到CoAPrequestCross Proxy 跨協(xié)議代理 比如COAP to HTTP和HTTP to COAP 目錄 概述MessageModelRequest ResponseModelOptionsCoAP組播CoAP代理SecuringCoAP Message模型 CoAPMessage用于承載Request Response模型 有兩種模式 ReliabilityModeConfirmableMessage需要AcknowledgementMessage確認(rèn)ConfirmableMessage和AcknowledgementMessage通過MessageID匹配Non ReliabilityModeNon ConfirmableMessage不需要AcknowledgementMessage確認(rèn) MessageFormat Messge組成部分固定4字節(jié)的頭部變長的Token 0 8byte 0或多個(gè)TLV格式的Option可選的PayloadMessage承載信息RequestResponseEmptyMessage 只有messageheader 且code為0 00 MessageHeader Ver 2bitversion 當(dāng)前版本為01 版本號非1的消息直接丟棄T Messagetype Confirmable 0 Non confirmable 1 Acknowledgement 2 Reset 3 TKL Tokenlength 當(dāng)前有效取值0 8 其他認(rèn)為是Messageformaterror MessageFormat Code Code 8bit無符號數(shù) 格式 c 3bitclasstype dd 5bitdetailcode Class分類 0 表示message為request dd表示具體的method 0 01表示GET 0 02表示POST 0 03表示PUT 0 04表示DELETE 特例 0 00表示emptymessage2 succsee4 clienterror5 servererrorMessageID 用于message的重復(fù)性檢測 以及Confirmablemsg non Confirmablemsg和ACK resetmsg的匹配Token 用于匹配Request和ResponseOption 可以0個(gè)或多個(gè) 每一個(gè)Option之后 可以是一個(gè)Option 或者是PayloadMaker和Payload或者message結(jié)束Payload 如果有payload 必然是payloadmarker 0 xFF 和直到udp報(bào)文結(jié)尾的payload Payloadmarker和payload必然同時(shí)出現(xiàn) Message分類 協(xié)議定義的Message有如下幾種ConfirmableMessage 需要確認(rèn)的消息 Receipt方必須對消息回復(fù)Acknowledgement或者ResetNon confirmableMessage 不需要確認(rèn)的消息 但是Receipt方可能回復(fù)ResetAcknowledgementMessage 用于向Sender確認(rèn)ConfirmableMessage已收到 可以攜帶PiggybackedResponseResetMessage 用于回復(fù)收到的無法處理的Message Confirmable和Non confirmableMessage 也可通過一個(gè)Empty的ConfirmableMessage觸發(fā)一個(gè)Rest 用于Endpoint的?;顧z測EmptyMessage 一個(gè)code為0 00的既不是request也不是response的Message EmptyMessage并不是協(xié)議定義和上述Messge并列的type 它只是一種特殊含義的Message Message和Response映射關(guān)系 表示此種情況只是為了讓接收方發(fā)出Resetmsg Message的可靠傳輸 Client構(gòu)造ConMsg發(fā)送到Server 未收到ACK或Reset時(shí) 支持基于指數(shù)回退的重發(fā)Server如果可以處理該Message 返回ACK 否則返回Reset Endpoint匹配CON和ACK ResetMessage中攜帶MessageID用于配對是一次可靠傳輸過程 支持重復(fù)檢測簡單的停等基于指數(shù)回退的重傳機(jī)制保證靠性 Message的可靠傳輸 Message的可靠傳輸由一個(gè)Confirmablemsg發(fā)起 Confirmablemsg總是承載一個(gè)Request或Response 除非是一個(gè)為了觸發(fā)Resetmsg的emptymsgReceipt收到一個(gè)Confirmablemsg 處理結(jié)果是 回復(fù)一個(gè)Acknowledgementmsg 攜帶匹配的messageID 或者在如下情況下Rejecting一個(gè)消息 recipient不能正確處理message message是一個(gè)emptymessage message中的code是1 6 7 Message存在格式錯(cuò)誤Rejecting一個(gè)msg的結(jié)果是回復(fù)Resetmsg或者忽略它 Message的可靠傳輸相關(guān)參數(shù) ACK TIMEOUT ACK RANDOM FACTOR 初始的ACK保護(hù)時(shí)間 重傳保護(hù)時(shí)間 隨后的MAX RETRANSMIT次重傳都乘以2NSTART 最大并發(fā)的處于活動(dòng)狀態(tài)的Message數(shù)目DEFAULT LEISURE Server休閑時(shí)間 用于收到多播Request時(shí) 何時(shí)返回Response的隨機(jī)時(shí)間的計(jì)算 上限 PROBING RATE 經(jīng)過重傳MAX RETRASMIT次的Request最終未收到Response后 Requester發(fā)送對端的平均速率要小于該值 Message的可靠傳輸導(dǎo)出參數(shù) MAX TRANS SPAN 最大重傳時(shí)間 ACK TIMEOUT 2 MAX RETRANSMIT 1 ACK RANDOM FACTOR 2 16 1 1 5 45sMAX TRANSMIT WAIT 最大等待響應(yīng)時(shí)間 ACK TIMEOUT 2 MAX RETRANSMIT 1 1 ACK RANDOM FACTOR 2 32 1 1 5 93 45 2 1 5 16 93sMAX LATENCY 封包從發(fā)送到期望完成接收的最大保護(hù)時(shí)間 100s 協(xié)議參考MSL直接隨意定義 即封包在傳輸鏈路上的時(shí)間PROCESSING DELAY 接收方從接收到該消息到發(fā)出響應(yīng)的處理時(shí)間 ACK TIMEOUT 2sMAX RTT 最大往返時(shí)間 2 MAX LATENCY PROCESSING DELAY 202sEXCHANGE LIFETIME MAX TRANSMIT SPAN 2 MAX LATENCY PROCESSING DELAY 45 200 2 247sNON LIFETIME non消息的MessageID最大安全重用保護(hù)時(shí)間 MAX TRANS SPAN MAX LATENCY 145 Message的非可靠傳輸 Client對于不需要可靠傳輸?shù)腗essage通過Non ConfirmableMsg傳遞雖然不需要ACK確認(rèn)NONMsg Server仍然可能會返回Reset給Client 比如Server不能處理這個(gè)NONmsg NONmsg中仍然攜帶MessageID用于重復(fù)檢測 Message的非可靠傳輸 Message的非可靠傳輸由一個(gè)NONmsg發(fā)起NONmsg總是承載一個(gè)Request或者Response 但是不能是一個(gè)Emptymsg不能用Acknowledgementmsg回復(fù)NONmsg雖然不需要ACK確認(rèn)NONMsg Server仍然可能會返回Reset給Client 比如Server不能處理這個(gè)NONmsg Receipt收到一個(gè)NONmsg 在如下情況下Rejecting一個(gè)消息 recipient不能正確處理message message是一個(gè)emptymessage message中的code是1 6 7 Message存在格式錯(cuò)誤Rejecting一個(gè)msg的結(jié)果是回復(fù)Resetmsg或者忽略它由于Sender不能確認(rèn)Receipt是否收到NONmsg 所以可以重傳多次 Receipt通過MsgID檢測是否是重復(fù)消息 目錄 概述MessageModelRequest ResponseModelOptionsCoAP組播CoAP代理SecuringCoAP Request Response模型 CoAPRequest和Response的語法通過Message承載可靠傳輸?shù)腞equest的Response方式 PiggybackedResponse 同步可靠響應(yīng)模式 piggybackedresponse 通過Conmsg的Ack攜帶Response異步可靠響應(yīng)模式 SeparateResponse 當(dāng)server不能立即響應(yīng)Request時(shí) 可以先通過空Ackmsg響應(yīng)Client 當(dāng)Server準(zhǔn)備好后 通過新的CONMsg將resonse發(fā)送給Client非可靠傳輸Request和Response piggybackedresponse Request和Response通過Token配對 異步可靠響應(yīng)模式 跨多對Msg的Request和Response通過Token配對 非可靠響應(yīng)模式 Request和Response通過Token配對對于通過NON承載的Request Server可以選擇通過CON返回Response PayloadsandRepresentations Request和Response中的Payload通常是是resourceRepresentations或者是requestaction的結(jié)果 格式由 Content Format 確定對于client或者servererror的response 如果包含 Content Format 則Payload是requestaction結(jié)果的Representation 否則是一個(gè)診斷DiagnosticPayload 診斷payload通常是一個(gè)描述錯(cuò)誤信息的字符串SelectedRepresentation 如果相應(yīng)的請求使用方法GET并且排除了任何條件請求選項(xiàng) 我們使用術(shù)語 選擇的表示 來引用對這些請求的成功響應(yīng)中選擇的目標(biāo)資源的當(dāng)前表示 client通過多次GET方法獲取了resource的Representation 并且回復(fù)Request的每個(gè)response指定了ETag 則client可以攜帶多個(gè)ETag的request Server選擇一個(gè)ETag返回2 03validresponse 這個(gè)就是SelectedRepresentation Request的Method rfc7252CoAP定義的方法GETPOSTPUTDELETE對于不能識別的Method 需要返回一個(gè)4 05 methodNotAllowed 的Piggybackedresponse GET Get方法用于Client向Server端檢索URI指定的resource的Representation如果Request包含AcceptOption 表示Client期望的Response的Content Format如果Request包含ETag 如果Etag關(guān)聯(lián)的Responsevalidate成功則返回2 03Valid 否則返回2 05Content 包含resource的Representation Get方法是安全并且正交的 POST POST方法用于Client請求Server處理Request中的Representation 如何處理依賴于originserver和targetresource 通常會導(dǎo)致創(chuàng)建一個(gè)新的resource或者更新targetresource如果resource被創(chuàng)建 response返回2 01created 需要攜帶resource的uri信息 一個(gè)或多個(gè)Location Path和Location QueryOption 如果request處理成功 且未創(chuàng)建新的Resource 返回2 04Changed如果request處理成功 且導(dǎo)致resource別刪除 返回2 02DeletedPOST方法既不安全也不正交 PUT Put方法用于Client請求Server使用Request中的Representation更新或者創(chuàng)建URI指定的資源 Representation的格式由Request中的Content Format確定 如果存在該Option 如果Server存在URI指定的resource 更新成功 返回2 04Changed如果resource不存在 并且Server成功創(chuàng)建 返回2 01Created如果resource無法更新也無法創(chuàng)建 返回相應(yīng)的errorresponse對Put方法結(jié)果的進(jìn)一步限制 可以通過If Match和If Not Match施加Put方法不安全但是是正交的 DELETE Put方法用于Client請求Server刪除URI指定的resource如果刪除成功或者resource根本不存在 返回2 02DeletedDelete方法不安全但是是正交的 ResponseCode 2 xxsuccess ThisclassofResponseCodeindicatesthattheclientsrequestwassuccessfullyreceived understood andaccepted2 01Created responsetoPOSTandPUT response中可能包含一個(gè)操作結(jié)果的Representation notcacheable2 02Deleted responsetoPOSTandDELETE notcacheable2 03Valid 用于指示Request中ETag指定的Response是有效的 Response必須包含ETag 不能包含payload2 04Changed responsetoPOST和PUT notcacheable2 05Content responsetoGET response中包含targetresource的Representation iscacheable ResponseCode 4 xxClientError 此類Code用于表示可能的客戶端錯(cuò)誤 可以應(yīng)用于所有method的response 并應(yīng)該包含一個(gè)Diagnosticpayload 此類Code的Response是cacheable的4 00BadRequest4 13RequestEntityTooLarge4 01Unauthorized4 15UnsupportedContent Format4 02BadOption4 03Forbidden4 04NotFound4 05MethodNotAllowed4 06NotAcceptable4 12PreconditionFailed ResponseCode 5 xxServerError 此類Code用于表示可能的Server端錯(cuò)誤 可以應(yīng)用于所有method的response 并應(yīng)該包含一個(gè)Diagnosticpayload 此類Code的Response是cacheable的5 00BadInternalServerError5 01NotImplement5 02BadGateway5 03ServiceUnavailable5 04GatewayTimeout5 05ProxyingNotSupported 目錄 概述MessageModelRequest ResponseModelOptionsCoAP組播CoAP代理SecuringCoAP Option分類 協(xié)議定義了Option Option的屬性有如下幾類 CriticalOption 接收方必須能夠理解的Option 否則消息無法正常處理ElectiveOption 接收方不識別該Option時(shí) 可以忽略 不影響消息的正常處理注意 Option本身和字面意義一樣 是否出現(xiàn)在Message中是可選的 UnsafeOption Proxy不識別不能轉(zhuǎn)發(fā)其所在Message的Option 并不是每個(gè)CriticalOption都是UnsafeOptionSafe to ForwardOption Proxy不識別仍可轉(zhuǎn)發(fā)其所在Message的Option CriticalvsElectiveOption 根據(jù)Endpoint對于不能識別的Option如何處理分類 規(guī)則 對于不能識別的ElectiveOption 無聲的忽略該Option在ConfirmableRequest中的不能識別的CriticalOption 需要返回4 02 BadOption reponse 且攜帶該Option用于診斷在Confirmableresponse中或者piggybackedResponse中的不能識別的CriticalOption 必須reject這個(gè)Response在non confirmablemsg中不能識別的Option 必須reject這個(gè)消息 返回reset并忽略該non Confirmablemsg RejectingaConfirmablemessageiseffectedbysendingamatchingResetmessageandotherwiseignoringit Critical和Elective規(guī)則應(yīng)用于non proxying的Endpoint ProxyUnsafe to ForwardvsSafe to Forward 根據(jù)Proxy如何處理Option分類Proxy如何處理這兩種Option的規(guī)則在Proxy中進(jìn)一步描述對于標(biāo)記為Safe to Forward的option 可以通過NoCacheKeybits來標(biāo)識其是否愿意成為一個(gè)Cache Key 如果someofNoCacheKeybits為0 表示愿意 如果NoCacheKeybits都是1 表示不愿意Cache Key用于Proxy對于Request中未實(shí)現(xiàn)的Option 作為替換采用Unsafe Safe to Forward標(biāo)識決定是否cache OptionFormat OptionDelta Option在message中的實(shí)例必須按照編號大小順序存放 option的實(shí)際編號由本Option中的Delta值 上一個(gè)Option的值確定 對于Message中的第一個(gè)Option實(shí)例 假定上一個(gè)Option的編號為0 同一個(gè)編號的多個(gè)Option的實(shí)例 其Delta值為0 OptionFormat OptionDelta 取值0 12表示Optiondelta 取值為13時(shí) 需要占用Optiondeltaextension中一個(gè)byte 存放實(shí)際optiondelta減13的取值 取值為14時(shí) 需要占用extension中兩個(gè)字節(jié) 存放實(shí)際Optiondelta減去269的部分 取值為15時(shí) 為payloadmarker保留 Optionlength 取值0 12表示option占用的字節(jié)數(shù) 取值13時(shí)表示需要占用擴(kuò)展中的一個(gè)字節(jié) 且表示optionlength減13的部分 取值14時(shí) 表示需要占用擴(kuò)展中的兩個(gè)字節(jié) 且表示optionlength減去269的部分 取值15時(shí) 保留 Optionvalueformat 0長度的字符序列不透明的字節(jié)序列無符號整數(shù)UTF 8編碼的Unicode字符串 Optionnumber 一個(gè)Option編號的最低字節(jié) 有如下mask組成 C 1表示是CriticalOption 0表示是ElectiveOption 即奇數(shù)編號是Critical 偶數(shù)編號是ElectiveOptionU Unsafe 1表示是一個(gè)UnsafeOption 否則是一個(gè)Safe to ForwardOptionNoCacheKey 三個(gè)bit全為1時(shí) 表示是一個(gè)NoCacheKey 其他情況表示是一個(gè)Cache Key Option項(xiàng) CoAP定義了如下可以應(yīng)用于Request和Response中的Option Content FormatETagLocation PathLocation QueryMax AgeProxy UriProxy schemeUri HostUri PathUri PortUri Query AcceptIf MatchIf No MatchSize1 Option項(xiàng)定義 NoCacheKey指示對于Safe to Forward選項(xiàng)才有意義 Uri Host Uri Port Uri Path Uri Query Uri Host Uri Port Uri Path Uri Query用于指定發(fā)往Server的Request中的目標(biāo)resource 用于組合出目標(biāo)resource的URIUri Host 指定目標(biāo)資源所在的主機(jī)Uri Port 指定目標(biāo)資源所在的端口Uri Path 指定目標(biāo)資源絕對路徑的一部分Uri Query 指定URI的參數(shù)的一部分Request可以包含多個(gè)上述Option Proxy Uri Proxy Scheme Proxy Uri用于發(fā)往Forward Proxy的Request中 表示一個(gè)絕對URIProxy Scheme表示代理scheme 比如coap coaps http https CoAPURI CoAP協(xié)議使用和http協(xié)議對稱的 coap 和 coaps URI標(biāo)識 定位一個(gè)coapresource語法符合AugmentedBackus NaurForm ABNF RFC5234 關(guān)于 host port path abempty query segment IP literal IPV4address reg name 定義源自RFC3986URIGenericSytax host 資源所在主機(jī) 可以是ip地址或者域名 不能為空port coap服務(wù)監(jiān)聽端口 coap默認(rèn)為5683 coaps默認(rèn)為5684path 指定resource在host內(nèi)的路徑 由 分隔query 用于進(jìn)一步參數(shù)化資源 由一系列的 分隔的參數(shù)組成 通常以 key value 的形式出現(xiàn) CoAPURI規(guī)范化和比較 coap 和 coaps URI編碼方案遵循RFC3986如果端口和默認(rèn)值相同 可以不列出空的path組件等效于根目錄 應(yīng)該直接列出 host port組件是大小寫不敏感的 通常用小寫呈現(xiàn)非host外的其他組件內(nèi)容是大小寫敏感的除 reserved 集合中的字符外 其和其百分號編碼含義等價(jià) 通常不需要采用百分號編碼形式如下形式的三個(gè)URI是等價(jià)的 URI分解 分解一個(gè)絕對路徑的url到CoAPRequest的URI 的步驟 如果url不是絕對URI 分解失敗參照RFC3986解析url字符串 此刻URL是ASCII編碼 經(jīng)過步驟5 8 9 將被翻譯為UTF 8編碼如果url不存在scheme 并且存在scheme 不是 coap 和 coaps 分解失敗如果url包括 fragment 組件 分解失敗將url的host的取值轉(zhuǎn)換為URI Host 如果不是ip地址的形式 轉(zhuǎn)換ASCII編碼為UTF 8編碼 并轉(zhuǎn)換掉百分號編碼的形式如果url的port不為空 翻譯成10進(jìn)制整數(shù) 否則使用默認(rèn)port如果url的port部分不等于request的目的port 將port轉(zhuǎn)化為URI Port如果url的path組件為空或者只有一個(gè) 轉(zhuǎn)下一步 否則 每個(gè)path部分分解為URI Path如果url包含query組件 將query中的每個(gè)參數(shù)轉(zhuǎn)化為URI Query 組裝URI 從CoAPRequest的URI option中組裝URI的步驟 如果request由DTLS加密 則url由 coaps 打頭 否則為 coap 如果request包含URI Host 轉(zhuǎn)化為url的host組件 如果host不是ip地址或者域名格式 組裝失敗 如果request不包含URI Host 則使用該request目的IP地址轉(zhuǎn)化為url的host組件appendhost到url如果request包含URI Port組件 url的port從URI Port的value中獲取 否則port從request中的目的port獲取如果port部位默認(rèn)端口 appendport到url將request中的URI Path拼裝程url的path部分 通過 分隔 對于不在 unreserved 集合中 不在 sub delims 集合中 不是 字符 不是 字符 需要轉(zhuǎn)換為百分號編碼格式如果path部分為空 將其指定為 如果存在URI Query 每個(gè)URI Query通過 連接第一個(gè)URI Query 通過 連接隨后所有的URI Query 對于不在 unreserved 集合中 不在 sub delims 集合中 不是 字符 不是 字符 需要轉(zhuǎn)換為百分號編碼格式將6 8中生成的path追加在url之后 Content Format 用于指定payload的格式Proxy Scheme表示代理scheme 比如coap coaps http https Accept 用于指定期望的Payload的格式 即Content FormatIfnoAcceptoptionisgiven theclientdoesnotexpressapreference thusnodefaultvalueisassumed TheclientpreferstherepresentationreturnedbytheservertobeintheContent Formatindicated TheserverreturnsthepreferredContent Formatifavailable IfthepreferredContent Formatcannotbereturned thena4 06 NotAcceptable MUSTbesentasaresponse unlessanothererrorcodetakesprecedenceforthisresponse Max Age 指定Response的生存時(shí)間 即保持fresh的時(shí)間默認(rèn)60秒 ETag 實(shí)體標(biāo)簽是由Server產(chǎn)生的 用于區(qū)分隨時(shí)間變化的相同資源的表示之間的資源本地標(biāo)識符 Response中的ETag在Response中只能出現(xiàn)一次IfnoLocation optionsarepresent thetaggedrepresentationistheselectedrepresentation Section5 5 3 ofthetargetresource IfoneormoreLocation optionsarepresentandthusalocationURIisindicated Section5 10 7 thetaggedrepresentationistherepresentationthatwouldberetrievedbyaGETrequesttothelocationURI Request中的ETag可以出現(xiàn)0或1或多次用于revalidate之前cache的Response Location Path Location Query Location Path和Location Query共同組成一個(gè)絕對路徑或者一個(gè)querystring或者兩者都有該組合出現(xiàn)2 01Createdresponse中表示Resource創(chuàng)建的相對路徑如果Location Path和Location Query與現(xiàn)有的cache的response匹配 這些Response需要刷新為un fresh ConditionalRequestOptions 作用用于指示Server當(dāng)ConditionalOption滿足時(shí) 才執(zhí)行Request條件滿足時(shí) 則執(zhí)行 否則返回4 12PreconditionFailed該Request導(dǎo)致的除2 xx和4 12的其他Responsecode時(shí) ConditionalOption被忽略If MatchIf Match用于攜帶ETagvalue可以有0個(gè)或多個(gè) 有一個(gè)匹配 則條件滿足用于resource條件更新 比如PUT方法If None MatchIf None Match未攜帶value用于以目標(biāo)資源不存在為條件提出請求 比如PUT方法 Sizel 作用TheSize1optionprovidessizeinformationabouttheresourcerepresentationinarequest Theoptionvalueisanintegernumberofbytes Itsmainuseiswithblock wisetransfers rfc7959 Inthepresentspecification itisusedin4 13responses Section5 9 2 9 toindicatethemaximumsizeofrequestentitythattheserverisableandwillingtohandle 目錄 概述MessageModelRequest ResponseModelOptionsResponse的緩存機(jī)制CoAP組播CoAP代理SecuringCoAP Caching Endpoint可以cacheresponse 也就是對當(dāng)前的Request 復(fù)用之前Request的Response 以縮短響應(yīng)時(shí)間 節(jié)約帶寬消耗 Caching機(jī)制Freshness機(jī)制Validation機(jī)制使用CacheResponse的條件Request和CachingResponse的method相同Request中的Option和CachingResponse相同 Cache key CachingResponse是fresh或者是validated的 Freshnessmodel 為了提高效率 cache中的Response如果是Fresh的 可以用來直接滿足后續(xù)的Requests 而不需要contactoriginserver如果判斷新鮮度 freshness Response中的Max Age用來指示該Response的生存 cache 時(shí)間 如果response沒有這個(gè)Option 默認(rèn)是60秒 如果Originserver不希望這個(gè)response被cache 顯示攜帶Max Age的值為0 Validationmodel Endpoint為request保存了多個(gè)Response 但是由于notfresh而不能使用 當(dāng)收到攜帶ETag的Request時(shí) originServer可以選擇一個(gè)保存的response 并且更新其新鮮度 此稱為 validating or revalidating 保存的Response 過程Endpoint發(fā)送攜帶ETagOption的Request 可以攜帶多個(gè) 每個(gè)代表一個(gè)保存的Response一個(gè)編號為2 03的Response攜帶ETag指定重用已保存的Reponse中的哪一個(gè)其他編號的Response指示沒有可以用來重用的Response 目錄 概述MessageModelRequest ResponseModelOptionsResponse的緩存機(jī)制CoAP組播CoAP代理SecuringCoAP 組播 組播是相對單播CoAP的一系列增強(qiáng)MessageLayer組播Message必須是non Confirmable Server必須能夠識別該消息是組播消息 對于收到的組播消息 Server不能回復(fù)Reset Client發(fā)出組播消息的MessageID不能和當(dāng)前Active的單播消息重復(fù)組播不能通過DTLS承載 在RFC7252寫作時(shí) Request ResponseLayerServer可以不理會組播的Request 取決于應(yīng)用 Server決定返回組播Message的單播響應(yīng)時(shí) 需要等一個(gè)隨機(jī)時(shí)間CachingClient每次發(fā)出一個(gè)新的組播請求 可以用repose更新cache的Response隨后針對組播server發(fā)出的單播GET請求的URI的主機(jī)部分 需要用reponse中的源IP地址替代到組播地址的GET請求 不能攜帶EtagOptionProxying 組播地址 發(fā)現(xiàn)機(jī)制 Discovery ServiceDiscovery 發(fā)現(xiàn)Server的方式 通過Server的URI發(fā)現(xiàn)Server通過組播方式 IPv4 發(fā)現(xiàn)Server通過AllCoAPNodes組播地址 IPv6 發(fā)現(xiàn)ServerServer默認(rèn)在端口5683或5684提供CoAP服務(wù)ResourceDiscovery 將受限Web服務(wù)器托管的資源 其屬性和其他資源關(guān)系的發(fā)現(xiàn)稱為CoRE資源發(fā)現(xiàn) 在M2M應(yīng)用場景 由于沒有人工接口 CoAPEndpoint建議支持RFC6690定義的可發(fā)現(xiàn)資源的CoRELinkFormat 用于資源發(fā)現(xiàn)CoAP為應(yīng)用RFC6690定義一個(gè)新的WebLinking RFC5988 ctAttribute 用于指示返回的Resource的Content Format 目錄 概述MessageModelRequest ResponseModelOptionsResponse的緩存機(jī)制CoAP組播CoAP代理SecuringCoAP Proxying Proxy是一種在CoAPClients驅(qū)動(dòng)下代表它們執(zhí)行Request的EndpointProxy按照功能分類Forward proxy 被Client顯示指定 并轉(zhuǎn)發(fā)Clientrequest到Server或下一個(gè)proxy 必要時(shí)可以直接從本地cache中查詢r(jià)esponse直接返回ClientReverse proxy 代表Server執(zhí)行Client的Request Reverse Proxy背后一般隱藏著多個(gè)originServer Reverse Proxy根據(jù)request URI和其配置策略 決定將Request發(fā)往哪一個(gè)originServer執(zhí)行Request 必要時(shí)也可以從本地cache中查詢r(jià)esponse直接返回clientProxy按照協(xié)議轉(zhuǎn)換分類CoAP to CoAPproxycrossproxy Proxy的一般行為 代理通常需要一種方式來基于其從客戶端接收到的請求來確定其放置到目的地的請求的潛在請求參數(shù)支持Freshnessmodel和Validationmodel緩存Response對于Request可以識別的Option 知道該option是否應(yīng)該作為cache key 比如URI Path必然是cache key 而Token不可以作為cache key對于Request中不識別的Option 知道根據(jù)Option中的Unsafe和NoCacheKey決定是否可以作為cache key 標(biāo)識為Safe to Forward的Option且NoCacheKey未全置1Request超時(shí)返回5 04 gatewaytimeout 或者server返回的Response無法處理 返回5 02 Badgateway 否則將originserver返回的響應(yīng)給clinet如果Reponse從Cache中選擇 返回Client中的Max Age需要減去在cache中的存活時(shí)間處理Request中Option時(shí) 對于不能識別的UnsafeOption 返回4 02 badoption 對于Response中不能識別的UnsafeOption 返回5 02 badgateway 對于不能識別的Safe to Forwardoption 不影響轉(zhuǎn)發(fā) Forward Proxy Forward Proxy需要顯示配置給CoAPClients發(fā)送到代理的Request和直接發(fā)往Originserver的Request中的resourceURI格式不同 到Proxy的Request中的URI以字符串形式出現(xiàn)在OptionProxy URI或者通過Proxy Scheme和Uri 組合 而到OriginServer的Request的URI分解為Uri Host Uri Port Uri Path Uri Query中 Endpoint不愿擔(dān)任proxy時(shí) 返回5 05 ProxynotSupported 除非代理被配置為將代理請求轉(zhuǎn)發(fā)到另一代理 否則它必須如下翻譯請求 Request中URI定義了輸出協(xié)議及其細(xì)節(jié) 例如 CoAP在 coap 方案上通過UDP使用 對于CoAP到CoAP代理 原始服務(wù)器的IP地址和端口由請求URI的確定 并且Proxy Uri或Proxy Scheme被解碼并分割成Uri Host Uri Port Uri Path和Uri Query選項(xiàng) Reverse Proxy Reverse Proxy不涉及Proxy Uri和Proxy scheme 但是需要根據(jù)Request的信息和配置信息 決定Request的下一跳 比如 例如 在通過資源發(fā)現(xiàn)知道它們的存在之后 反向代理可以提供各種資源 如同它們是它自己的資源一樣 反向代理可以自由地為標(biāo)識這些資源的URI構(gòu)建一個(gè)命名空間 反向代理還可以構(gòu)建命名空間 其給予客戶端例如通過將主機(jī)標(biāo)識符和端口號嵌入到所提供的資源的URI路徑中來更多地控制請求的去向 在處理Response時(shí) 反向代理必須小心 來自不同源的ETag選項(xiàng)值不會混合到提供給其所有客戶端的一個(gè)資源上 如果從Reverse Proxy提供的資源到由其各種OriginServer提供的資源的映射不是唯一的 則Reverse Proxy可能需要生成新的ETag 確保該選項(xiàng)的語義被適當(dāng)?shù)乇A?Cross ProxybetweenCoAPandHTTP 按代理方向分類COAP HTTPProxyingCoAPClient通過該代理訪問HTTPServer上resource的資源 Client通過發(fā)送攜帶Proxy URI或者Proxy Scheme指定到http或httpsURI的Request發(fā)起該訪問過程HTTP COAPProxyingHTTPClient通過該代理訪問CoAPServer上的資源 通過在HTTPRequest的request line中指定URI格式為coap或者coaps發(fā)起該訪問過程CoAP的Request Response模型和HTTP映射 CoAP底層的messagemodel不影響代理本身的功能 Reverse Proxy對于Client來說 和originServer是一樣的 協(xié)議認(rèn)為不需特別描述 但是從被代理的Server看 Reverse Proxy會導(dǎo)致proxy更廣泛的適用性 需要專門的協(xié)議定義 CoAP HTTPProxy COAP HTTPProxyCoAPClient發(fā)送攜帶Proxy URI或者Proxy Scheme的Request請求到ProxyProxy對HTTPresource執(zhí)行Request中method指定的操作 并返回響應(yīng)協(xié)議定義了Proxy對CoAPrequest應(yīng)該返回的Response 至于代理如何實(shí)現(xiàn)以滿足這個(gè)要求屬于實(shí)現(xiàn)細(xì)節(jié) 協(xié)議未具體定義如果Proxy不愿服務(wù)一個(gè)攜帶指定URI的Request 返回client一個(gè)5 05ProxyingNotSupported如果Proxy將Request轉(zhuǎn)發(fā)到originhttpserver 超時(shí)未得到響應(yīng) Proxy應(yīng)該給client返回5 04GatewayTimeout 或者得到了originserver的響應(yīng) 但是無法解析 給client返回一個(gè)5 02BadGateway響應(yīng) CoAP HTTPPro

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論