MQTT 協(xié)議 3.1.1 中文完整版

概 術 標 CONNECT–連接服務 響 CONNACK–確認連接請 PUBLISH–發(fā)布消 響 動 PUBACK–發(fā)布確 動 PUBREC–發(fā)布收到（QoS2，第一步 動 PUBREL–發(fā)布釋放（QoS2，第二步 動 PUBCOMP–發(fā)布完成（QoS2，第三步 動 SUBSCRIBE-訂閱主 響 SUBACK–訂閱確 響 UNSUBACK–取消訂閱確 PINGREQ–心跳請 響 PINGRESP–心跳響 DISCONNECT–斷開連 響 QoS0:最多分發(fā)一 QoS1:至少分發(fā)一 QoS2:僅分發(fā)一 安 概 使用WebSocket作為網絡 MQTT–MQTT使用WebSocket作為網絡傳輸層必須MUST，不能MUSTNOT，要求REQUIRED，將會SHALL，不會SHALLNOT，SHOULD，SHOULDNOT，RECOMMENDED，可以MAY，可選IETFRFC2119[RFC2119]網絡連接（Network4.2節(jié)。客戶端服務端訂閱主題名（Topic主題過濾器（Topic會話控制報文（MQTTControlBradner,S.,"KeywordsforuseinRFCstoIndicateRequirementLevels",BCP14,RFC2119,March\hYergeau,F.,"UTF-8,atransformationformatofISO10646",STD63,RFC3629,November\hDierks,T.andE.Rescorla,"TheTransportLayerSecurity(TLS)ProtocolVersion1.2",RFC5246,August\hFette,I.andA.Melnikov,"TheWebSocketProtocol",RFC6455,December\hTheUnicodeConsortium.TheUnicode\hPostel,J.TransmissionControlProtocol.STD7,IETFRFC793,September\hAdvancedEncryptionStandard(AES)(FIPSPUB\hDataEncryptionStandard\hSecurityRequirementsforCryptographicModules(FIPSPUB140-\h[IEEEIEEEStandardforLocalandmetropolitanareanetworks-SecureDevice\hISO/IEC29192-1:2012Informationtechnology--Securitytechniques--Lightweightcryptography--Part1:General\h[MQTTMQTTsupplementalpublication,MQTTandtheNISTFrameworkforImprovingCriticalInfrastructure\hMQTTV3.1Protocol\hImprovingCriticalInfrastructureCybersecurityExecutiveOrder\hNISTIR7628GuidelinesforSmartGridCyber\hNSASuiteB\hPCI-DSSPaymentCardIndustryDataSecurity\hLeech,M.,Ganis,M.,Lee,Y.,Kuris,R.,Koblas,D.,andL.Jones,"SOCKSProtocolVersion5",RFC1928,March1996.\hSermersheim,J.,Ed.,"LightweightDirectoryAccessProtocol(LDAP):TheProtocol",RFC4511,June\hSalowey,J.,Zhou,H.,Eronen,P.,andH.Tschofenig,"TransportLayerSecurity(TLS)SessionResumptionwithoutServer-SideState",RFC5077,January2008.\hCooper,D.,Santesson,S.,Farrell,S.,Boeyen,S.,Housley,R.,andW.Polk,"InternetX.509PublicKeyInfrastructureCertificateandCertificateRevocationList(CRL)Profile",RFC5280,May2008.\hEastlake3rd,D.,"TransportLayerSecurity(TLS)Extensions:ExtensionDefinitions",RFC6066,January\hHardt,D.,Ed.,"TheOAuth2.0AuthorizationFramework",RFC6749,October\hSantesson,S.,Myers,M.,Ankney,R.,Malpani,A.,Galperin,S.,andC.Adams,"X.509InternetPublicKeyInfrastructureOnlineCertificateStatusProtocol-OCSP",RFC6960,June2013.\hSarbanes-OxleyActof\hU.S.-EUSafe\hbytebytebytebytebyte3UTF-8編碼字符串中的字符數據必須Unicode[UnicodeRFC3629[RFC3629]中UTF-8格式。特別需要指出的是，這些數據不能U+D800U+DFFF之間的UTF-8字符的控制報文，它必須關閉網絡連接[MQTT-文，它必須[MQTT-1.5.3-2]。Unicode規(guī)范定義的保留字符（U+0FFFF）UTF-80XEF0xBB0xBFU+FEFF（零寬度非換行空白字符），無論它出現在字符串的什么位置，報文接收者都不能跳過或者剝離它[MQTT-1.5.3-3]。A??AU+2A6D4(它表示一個中日韓統(tǒng)一表意文B中的字符)，這個字符串編碼如下：圖例1.2UTF-8byteMSBbyteLSBbyte‘A’bytebytebytebyteMQTTMQTT–圖例2.1MQTT-圖例2.2bytebyte-表格2.1QoS114[3-0]MQTT2.2標志位。2.2中任何標記為“保留”的標志位，都是保留給以后使用的，必須設置為表格中列出的值[MQTT-2.2.2-1]。如果收到非法的標志，接收者必須關閉網絡連接。有關錯誤處理的詳細信息見4.8[MQTT-表格2.2BitBitBitBitUsedinMQTT =控制報文的重復分發(fā)標志 =PUBLISH報文的服務質量等級RETAIN3=PUBLISH報文的保留標志,剩余長度（RemainingLength）表示當前報文剩余部分的字節(jié)數，包括可變報頭和負載的數據。剩余長度1287128個數值和一個延續(xù)位（continuationbit）4個字節(jié)。64會被編碼為一個字節(jié)，數值是64，十六進制表示為0x40,。十進制數字這允許應用發(fā)送最大256MB(268,435,455大小的控制報文。這個數值在報文中的表示是：表格2.40127128(0x80,16383(0xFF,16384(0x80,0x80,2097151(0xFF,0xFF,2097152(0x80,0x80,0x80,268435455(0xFF,0xFF,0xFF,encodedByte=XMOD128X=XDIV128//iftherearemoredatatoencode,setthetopbitofthisbyteif(X>0)encodedByte=encodedByteOR128'output'encodedBytewhile(X>0)multiplier=value=0encodedByte='nextbytefromvalue+=(encodedByteAND127)*multipliermultiplier*=128if(multiplier>throwError(MalformedRemainingLength)while((encodedByteAND128)!=0)MQTT控制報文包含一個可變報頭部分。它在固定報頭和負載之間。可變報頭的內容根據報文類型的不同而不同。可變報頭的報文標識符（PacketIdentifier）字段存在于在多個類型的報文里。圖例2.3bytebytePUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE,SUBACK，UNSUBSCIBE，符（PacketIdentifier）[MQTT-2.3.1-1]?？蛻舳嗣看伟l(fā)送一個新的這些類型的報文時都必須分配一個當前[MQTT-2.3.1-2]。如果一個客戶端要重發(fā)這個特殊的控制報文，在隨后重發(fā)那個報文QoS1PUBLISHPUBACK，QoS2PUBLISHPUBCOMPSUBSCRIBE或PUBACKPUBREC,PUBREL報文必須PUBLISH[MQTT-2.3.1-6]。類似地，SUBACKUNSUBACK必須SUBSCRIBEUNSUBSCRIBE報文中使用的[MQTT-2.3.1-7]。需要（QoS需要（QoS0x1234PUBLISH報文。--PUBLISHPacketIdentifier=0x1234--PUBACKPacket載荷就是應用消息。2.6–包含有效載荷的控制報文列出了需要有效載荷的控制報文。表格2.6MQTTCONNECT有效載荷包含一個或多個編碼的字段。包括客戶端的唯一標識符，Will主題，Will消息，用戶名和密碼。除3.1CONNECTbyteReservedbyteCONNECT報文的可變報頭按下列次序包含四個字段：協(xié)議名（ProtocolName），協(xié)議級別（ProtocolLevel），連接標志（ConnectFlags）和保持連接（KeepAlive）。圖例3.2byteMSBbyteLSBbytebytebytebyteMQTTUTF-8編碼的字符串。MQTT規(guī)范的后續(xù)版本不會改變這個字符串的偏移和于后一種情況，按照本規(guī)范，服務端不能CONNECT[MQTT-3.1.2-1]。圖例3.3ProtocolLevelbytebyte83.1.14(0x04)。如果發(fā)CONNECT[MQTT-3.1.2-2]。UserNameWillWillWillbyte如果清理會話（nessin）標志被設置為，服務端必須基于當前會話（使用客戶端標識符識別）的狀態(tài)恢復與客戶端的通信。如果沒有與這個客戶端標識符關聯(lián)的會話，服務端必須創(chuàng)建一個新的會話。在連接斷開之后，當連接斷開后，客戶端和服務端必須保存會話信息[MTT-2-。當清理會話標志為0的會話連接斷開之后，服務端必須將之后的QoS1和QoS2級別的消息保存為會話狀態(tài)的一部分，如果這些消息匹配斷開連接時客戶端的任何訂閱\hMQTT--]。服務端也可以保存滿足相同條件的QoS0級別的消息。如果清理會話（CleanSession）標志被設置為1，客戶端和服務端必須丟棄之前的任何會話并開始一個新QoS1QoS24.1節(jié)。1重復請求連接，直到連接成01，并且不交替使用兩種值。這個選擇取0的客戶端會收到所有在它連接斷開期間發(fā)QoS1QoS2QoS1或QoS20。0MQTT會話狀態(tài)。如果打0最后再連接一次，然后斷開連接。遺囑標志（WillFlag）1，表示如果連接請求被接受了，遺囑（WillMessage）消息必須被存儲在DISCONNECT報文時刪除了這個遺囑消息[MQTT-3.1.2-8]。1，連接標志中的WillQoSWillRetain字段會被服務端用到，同時有效載荷中必須包含WillTopic和WillMessage[MQTT-3.1.2-9]。[MQTT-3.1.2-10]。0，連接標志中的WillQoSWillRetain字段必須0，并且有效載荷中不能包含WillTopic和WillMessage[MQTT-3.1.2-11]。服務端應該迅速發(fā)布遺囑消息。在關機或故障的情況下，服務端可以推遲遺囑消息的發(fā)布直到之后的重啟。如果發(fā)生了這種情況，在服務器故障和遺囑消息被發(fā)布之間可能會有一個延遲。遺囑)0，遺囑保留（WillRetain）標志也必須0[MQTT-3.1.2-15]。1：如果用戶名（UserName）0，有效載荷中不能[MQTT-3.1.2-18]。0，密碼標志也必須0[MQTT-3.1.2-22]。圖例3.5byteKeepAlivebyteKeepAlive保持連接（plve）是一個以秒為單位的時間間隔，表示為一個6位的字，它是指在客戶端傳輸完成一個控制報文的時刻到發(fā)送下一個報文的時刻，兩者之間允許空閑的最大時間間隔?？蛻舳素撠煴ＷC控制報文發(fā)送的時間間隔不超過保持連接的值。如果沒有任何其它的控制報文可以發(fā)送，客戶端必須發(fā)送一個INGRQ報文[MQTT-2-。PINGREQPINGRESP報文判斷網如果保持連接的值非零，并且服務端在一點五倍的保持連接時間內沒有收到客戶端的控制報文，它必須斷開客戶端的網絡連接，認為網絡連接已斷開[MQTT-31.-。PINGREQPINGRESP報文，它應該關閉到服務保持連接的值為零表示關閉保持連接功能。這意味著，服務端不需要因為客戶端不活躍而斷開連接。注意：不管保持連接的值是多少，任何時候，只要服務端認為客戶端是不活躍或無響應的，可以斷開客戶端的連接。圖例3.6byteLengthMSBbyteLengthLSBbytebytebytebytebyteLevel4)byteUserNameFlag1)用戶名標志PasswordFlag(1)密碼標志WillRetain(0)Will保留標志WillQoS(01)Will服務質量WillFlag(1)Will標志CleanSession1)Reserved(0)byteMSBbyteLSBCONNECT報文的有效載荷（ald）包含一個或多個以長度為前綴的字段，可變報頭中的標志決定是否包含這些字段。如果包含的話，必須按這個順序出現：客戶端標識符，遺囑主題，遺囑消息，用戶名，密碼[MQTT-3-。服務端使用客戶端標識符(ClientId)識別客戶端。連接服務端的每個客戶端都有唯一的客戶端標識符（ClientId）ClientIdMQTT會話相關的狀態(tài)[MQTT-3.1.3-(ClientId必須存在而且必須CONNECT[MQTT-3.1.3-3]?？蛻舳藰俗R符必須1.5.3UTF-8編碼字符串[MQTT-3.1.3-4]。(ClientId)。服務端可以(ClientId，如果這樣做了，服務端必須將這看作特CONNECT[MQTT-3.1.3-6]合格）CONNACKCONNECT報文，然后關閉網絡連接[MQTT-3.1.3-8]。CONNECT報文，然后關閉網絡連接[MQTT-3.1.3-9]。ClientId0時應該1，有效載荷的下一個字段是遺囑主題（WillTopic）。遺囑主題必須1.5.3節(jié)定UTF-8編碼字符串[MQTT-3.1.3-10]。1，有效載荷的下一個字段是遺囑消息。遺囑消息定義了將被發(fā)布到遺囑主題的應編碼字符串圖例3.7bytebytebyte3MQTT3.1.1，那么它按照下面的方法驗證連接請求。CONNACK[MQTT-3.1.4-1]3.2節(jié)的描述，它應該發(fā)送一個適當的、返回碼非零的CONNACK響應，并且必須關閉這個網絡連接。ClientId表明客戶端已經連接到這個服務端，那么服務端必須斷開原有的客戶端連接報文之后發(fā)送的任何數據CONNACK須CONNACK[MQTT-3.2.0-1]。byteReservedbyteReservedbyte剩余長度ReservedbyteReservedbytebyte0(SP)（SessionPresent）標志。對應客戶端的會話狀態(tài)。如果服務端已經保存了會話狀態(tài)，它必須CONNACK報文中的當前會話標志設1[MQTT-3.2.2-2]。如果服務端沒有已保存的會話狀態(tài)，它必須CONNACK報文中的當前會話設置0CONNACK0[MQTT-3.2.2-3]。1，再次連接，然后再次CONNACK報文，它必須0[MQTT-3.1–連接返回碼的值中列出。如果服務端收到一個合CONNECT報文，但出于某些原因無法處理它，服務端應該嘗試發(fā)送一個包含非零返回碼（表格中的某一個）CONNACKCONNACK報文，那么它必須關閉網絡連接[MQTT-3.2.2-5].。表格3.1文[MQTT-3.2.2-6]。PUBLISHbytebytebyte1，表示這可能是一個早前報文請求的重發(fā)。PUBLISH報文時，必須DUP1[MQTT-3.3.1.-1].QoS0的消息，DUP標志必須0[MQTT-3.3.1-2]。PUBLISH報文給訂閱者時，收到（入站）PUBLISHDUP標志的值不會被傳播。發(fā)送（出站）PUBLISH報文與收到（入站）PUBLISHDUP標志是獨立設置的，它的值必須單獨的根據發(fā)送（出站）PUBLISH報文是否是一個重發(fā)來確定[MQTT-3.3.1-3]。2.3.1節(jié)提供了有關報文標識符的更多信息。-表格3.2QoSBitBit報文，它必須[MQTT-3.3.1-4]PUBLISH報文的保留（RETAIN）1，服務端必須存儲這個應用消息和它的服務質量等級（QoS），以便它可以被分發(fā)給未來的主題名匹配的訂閱者[MQTT-3.3.1-5]。一個新的訂閱建立時，對每個匹配的主題名，如果存在最近保留的消息，它必須被發(fā)送給這個訂閱者[MQTT-3.3.1-6]。如果服務端收到一條保留（RETAIN）1QoS0消息，它必須丟棄之前為那個主題保留的任何消息。它應該QoS0消息當作那個主題的新保留消息，但是任何時候都可以—1[MQTT-3.3.1-8]PUBLISH報文發(fā)送給客戶端是因為匹配一個已建立的訂閱時，服務端必須0，不管它收到的這個消息中保留標志的值是多少[MQTT-3.3.1-9]。保留標志為1且有效載荷為零字節(jié)的ULIH報文會被服務端當作正常消息處理，它會被發(fā)送給訂閱主題匹配的客戶端。此外，同一個主題下任何現存的保留消息必須被移除，因此這個主題之后的任何訂閱者都不會收到一個保留消息[MQTT-1-10]。當作正常意思是現存的客戶端收到的消息中保留標志未被設置。服務端不能存儲零字節(jié)的保留消息[MQTT-1-。PUBLISH0，服務端不能存儲這個消息也不能移除或替換任何現存的保留消息[MQTT-3.3.1-12]。包含通配符QoS12時，報文標識符（PacketIdentifier）PUBLISH報文中。2.3.13.11PUBLISH報文可變報頭非規(guī)范示例3.3PUBLISH報文非規(guī)范示例中簡要描PUBLISH報文的可變報頭。表格3.3PUBLISH圖例3.11PUBLISHTopicNamebyteLengthMSBbyteLengthLSBbyte‘a’byte‘/’byte‘b’byteMSBbyteLSBPUBLISH報文是合法的。PUBLISH報文的接收者必須PUBLISHQoS[MQTT-表格3.4PUBLISHQoSQoSQoSPUBLISH報文發(fā)送應用消息給每一個訂閱匹配的客戶端?？蛻舳耸褂脦ㄅ浞闹黝}過濾器請求訂閱時，客戶端的訂閱可能會重復，因此發(fā)布的消息可能會匹配多個過濾器。對于這種情況，服務端必須將消息分發(fā)給所有訂閱匹配的QoS等級最高的客戶端[MTT-5-。服務端之后可以按照訂閱的QoS等級，分發(fā)消息的副本給每一個匹配的訂閱者。PUBACK圖例3.12PUBACKbytebytebytebytebytePUBREC發(fā)布收到（QoS2，第一步圖例3.14PUBRECbyteMQTTebyte圖例3.15PUBRECbytebytePUBREL發(fā)布釋放（QoS2，第二步圖例3.16PUBRELbytebyte都當做是不合法的并關閉網絡連接[MQTT-3.6.1-1]。bytebytebytePUBCOMP發(fā)布完成（QoS2，第三步圖例3.18PUBCOMPbytebytebytebytebyteSUBSCRIBESUBSCRIBE報文用于創(chuàng)建一個或多個訂閱。每個訂閱注冊客戶端關心的一個或多個報文也（為每個訂閱）QoS等級，服務端根據這個發(fā)送應用消息給客戶端。圖例3.20SUBSCRIBEbytebyte[MQTT-3.8.1-1]。圖例3.21報文標識符等于10byteMSBbyteLSB報文有效載荷中的主題過濾器列表必須1.5.3UTF-8字符串[MQTT-3.8.3-1]。服務端應該支持包含通配符（4.7.1節(jié)定義的）的主題過濾器。如果服務端選擇不支持包含通配符的主題過濾器，必須拒絕[MQTT-3.8.3-2]報文是違反協(xié)議的QoS等級組合是連續(xù)地打包。圖例3.22SUBSCRIBEbytebytebytes主題過濾器（Topicbyte當前版本的協(xié)議沒有用到服務質量要求（RequestedQoS）字節(jié)的高六位。如果有效載荷中的任何位是非––圖例3.23byteLengthMSBbyteLengthLSBbyte‘a’byte‘/’byte‘b’bytebyteLengthMSBbyteLengthLSBbyte‘c’byte‘/’byte‘d’byte報文響應SUBACK報文必須SUBSCRIBE報文有相同的報文標識符[MQTT-3.8.4-2]。SUBSCRIBE報文，報文的主題過濾器與一個現存訂閱的主題過濾器相同，那么必須中斷\hSUBACKQoS等級都必須包含一個返回碼。這個返回\hQoSQoS必須是原始發(fā)布消息的QoSQoSQoS1QoS0，允許服\hQoS1，那么匹配這個過1再分發(fā)給客戶端，因此客戶端可能會收到重復的消息副本。QoS等級1的消息在傳輸給客戶端時可能會丟失或重復。QoS到更適合它的等級。SUBACK圖例3.24SUBACKbytebyteSUBSCRIBE報文的報文標識符。3.25SUBACK報文可變報頭描述了可圖例3.25SUBACKbytebyte碼的順序必須SUBSCRIBE報文中主題過濾器的順序相同[MQTT-3.9.3-1]。bytebyte0x00QoS0x01QoS0x02QoS20x80-Failure失敗0x000x01,0x02,0x80SUBACK返回碼是保留的，不能[MQTT-3.9.3-2]--Success-MaximumQoSSuccessSuccess-MaximumQoSSuccess-MaximumQoS3.27byteSuccess-MaximumQoSbyteSuccess-MaximumQoSbyteUNSUBSCRIBE圖例3.28UNSUBSCRIBEbytebyte它的值都是不合法的并關閉網絡連接[MQTT-3.10.1-1]。bytebytebyteUNSUBSCRIBE報文的有效載荷包含客戶端想要取消訂閱的主題過濾器列表。UNSUBSCRIBE報文中的主題過濾器必須1.5.3UTF-8編碼字符串[MQTT-3.10.3-1]。UNSUBSCRIBE報文的有效載荷必須UNSUBSCRIBE報文是違反協(xié)議的[MQTT-3.10.3-2]4.8節(jié)。--表格3.7-有效載荷非規(guī)范示例3.30byteLengthMSBbyteLengthLSBbyte‘a’byte‘/’byte‘b’byteLengthMSBbyteLengthLSBbyte‘c’byte‘/’byte‘d’[MQTT-3.10.4-1]。它必須QoS1QoS2[MQTT-3.10.4-3]服務端必須UNSUBACKUNSUBSCRIBE請求。UNSUBACK報文必須包含和UNSUBSCRIBE[MQTT-3.10.4-4]。即使沒有刪除任何主題訂閱，服務端也必須發(fā)SUBACK響應[MQTT-3.10.4-5]。UNSUBSCRIBE報文，它必須如同收到了一系列的多個UNSUBSCRIBEUNSUBACK報文外。UNSUBACK圖例3.31UNSUBACKbytebytebytebytebytePINGREQ圖例3.33PINGREQbytebyte報文PINGRESP圖例3.34PINGRESPbytebyteDISCONNECT圖例3.35DISCONNECTbytebyte必須[MQTT-3.14.4-1]通過那個網絡連接再發(fā)送任何控制報文節(jié)[MQTT-4.1.0-1]。會話必須[MQTT-4.1.0-2]。)QoS等級可能是不同的。QoS0:報文PUBLISHQoS0,PUBLISHQoS0,QoS1:服務質量確保消息至少送達一次。QoS1PUBLISH報文的可變報頭中包含一個報文標識符，需要QoS1的分發(fā)協(xié)議，接收者DUP標志的值。圖例4.2QoS1 QoS2:PUBREC報文后必須PUBREL報文。PUBRELPUBLISH報文對于QoS2的分發(fā)協(xié)議，接收者PUBLISH報文。在這種情況下，它不能重復分發(fā)消息給任何后續(xù)的接收者。圖例4.3QoS21。4.3QoS2協(xié)議流程圖，非規(guī)范示例QoS2等級消息的兩種處理方法。他們QoS流程的可靠性。PUBLISH報文（QoS>0）PUBREL[MQTT-4.4.0-1]。這是唯一要求客戶端或4.7節(jié)[MQTT-4.5.0-1]。正常情況下，客戶端收到發(fā)送給它的訂閱的消息?？蛻舳艘部赡苁盏讲皇桥c它的訂閱精確匹配的消息。如果服務端自動給客戶端分配了一個訂閱，可能發(fā)生這種情況。正在處理UUBCRIBE請求時也可能收到消息?？蛻舳吮仨毎凑湛捎玫姆召|量（Qo）規(guī)則確認它收到的任何ULIH報文，不管它選擇是否處理報文包含的應用消息[MQTT-0-。題當作是無序的[MQTT-4.6.0-5]。PUBLISH報文給消費者（QoS）[MQTT-4.6.0-6]。QoS1發(fā)布和訂閱的消息流，訂閱者按照消息發(fā)布時的順序收到每條1,2,3,41,2,3,2,3,4。不發(fā)送后面的那條消息），QoS11,2,3,3,41,2,3,2,3,4（in-flightwindow）1QoS等級的消息，它們的順序也被保topiclevel。斜杠（U+2F）用于分割主題的每個層級，為主題名提供一個分層結構。當客戶端訂閱指定的主題過濾器包含兩種通配符時，主題層級分隔符就很有用了。主題層級分隔符可以出現在主題過濾器或主題名字的任何位置。相鄰的主題層次分隔符表示一個零長度的主題層級。數字標志（‘#’U+0023）是用于匹配主題中任意層級的通配符。多層通配符表示它的父級和任意數量的子過濾器的最后一個字符[MQTT-4.7.1-2]。#U+002B[MQTT-4.7.1-3]?？梢栽谥黝}過濾器中的多個層級中使用它，也可以和多層通配符一起使用?！皊port/tennis/+”“sport/tennis/player1”“sport/tennis/player2”，但是不匹配“sport/tennis/player1/ranking“sport不匹配“sport”“sport/”。/#”“sport“/finance”“+”服務端不能$(#或[MQTT-4.7.2-1]。服務端應該阻止$開頭的主題名用作其他目的。/””/#”/”/+”“$SYS$開頭主題的消息，它需要同時訂閱“#”和““$SYS/#”。“/”“/”)]Unicode字符?！薄薄癆ccountspayable”“/finance”“finance”[MQTT-4.8.0-1]?？蛻舳嘶蚍斩藢崿F可能會遇到瞬時錯誤（TransientError）（例如內部緩沖區(qū)滿了的情況）導致無法成功MQTT報文。作為傳輸層協(xié)議，MQTTTLS[RFC5246]是[USEUSAFEHARB]），行業(yè)標準（[PCIDSS]），監(jiān)管方面的考慮（例如薩班斯-[SARBANES]）等問題。MQTTNIST[NISTCSF]，第三方支付行業(yè)數據安[PCIDSS][FIPS1402]NSAB[NSAB]。MQTT（MQTTandtheNISTFrameworkforImprovingCriticalInfrastructureCybersecurity[MQTTNIST]）NIST[NISTCSF]MQTT的指導。使用[AES]數據加密標準[DES]CONNECT報文包含用戶名和密碼字段。實現可以決定如何使用這些字段的內容。實現者可以提供自己的LDAP[RFC4511]OAuth[RFC6749]，還可以利用操作系統(tǒng)擊和重放攻擊的風險。5.4.5節(jié)介紹了確保數據私密的方法。TLS[RFC5246]SSL證書驗證客戶端的身份。TLS[RFC5246]SSLIP多域名MQTTRFC6066[RFC6066]3TLSSNI擴展。SNI允許客戶端TLS[RFC5246]TLSNULL，那么它TLS[RFC5246]TLS[RFC5246]SSL證TLS[RFC5246]的客戶端和服務端實現，可以選擇提供檢查證書吊銷列表(CRLs[RFC5280]和在線證書狀態(tài)協(xié)議(OSCP)[RFC6960]的功能，拒絕使用被吊銷的證書。沒有在未授權的地區(qū)使用。IEEE[IEEE802.1AR]就是用于實現這個機制的一個標準，它使IP地址或客戶端標識符實現一個動態(tài)黑名單列表。TLS[RFC5246]時應該允許重新協(xié)商會話以確認新的加密參數（替換會話密TLS[RFC5077]TLS[RFC5246]的成SOCKSSOCKSv5[RFC1928]MQTT實現可以利用安全隧道（SSH）SOCKSSOCKS時，它們應該同時支持匿SOCKSSOCKS可能使用明文認證，MQTT服務器。使用安全傳輸配置時，MQTTTLS[RFC5246]的物理或虛擬網絡上，它提供了身份認證，使用內置的用戶名和密碼字段，TLS[RFC5246]客戶端身份認證可被用于（或者代替）MQTT客戶端認[NIST7628]NISTIR7628[FIPS1402](FIPSPUB140-2[NSAB]NSAWebSocketMQTT在WebSocket[RFC6455]連接上傳輸，必須MQTT控制報文必須使用WebSocket二進制數據幀發(fā)送。如果收到任何其它類型的數據幀，接收者必須關閉網絡連接[MQTT-6.0.0-1]?？蛻舳吮仨歮qtt包含在它提供的WebSocket[MQTT-6.0.0-3]服務端選擇和返回的WebSocket子協(xié)議名必須mqtt[MQTT-6.0.0-4IANAIANA在WebSocketWebSocketMQTT圖例6.1IANAWebSocket\hMQTTMQTT服務端的要求[MQTT-7.0.0-1]。[MQTT-MQTT–MQTT–（MQTT的網絡層是]MQTT–MQTT（MQTT的網絡層是傳輸協(xié)議?？蛻舳丝梢?.2[MQTT-7.1.2-1要求的傳輸附錄B強制性規(guī)范聲明（非規(guī)范UTF-8編碼字符串中的字符數據必須Unicode[Unicode]定義的和在RFC3629[RFC3629]UTF-8格式。特別需要指出的是，這些數UTF-8字符的控制報文，它必須關閉網絡連接。U+0000的控制報文，它必須關閉網絡連接。UTF-80XEF0xBB0xBFU+FEFF（零寬度非換行空白字16位報文標識符（PacketIdentifier。PUBACKPUBREC,PUBREL報文必須PUBLISH報文相同的]CONNECT報文當作協(xié)議違規(guī)處理并斷開客戶端的連接。CONNECT報文。對于后一種情況，按照本規(guī)范，服務端不能繼續(xù)處理CONNECT報文。議級別）CONNACKCONNECT報文，然后斷開客戶端的連接。0必須斷開客戶端連接。0的會話連接斷開之后，服務端必須QoS1QoS2遺囑標志（WillFlag）1，表示如果連接請求被接受了，遺囑（Will閉時，服務端必須DISCONNECT報文時刪1，連接標志中的WillQoSWillRetain字段會被服務端用到，同時有效載荷中必須包含WillTopic和WillMessage字段。0，連接標志中的WillQoSWillReta