2025年P(guān)ython物聯(lián)網(wǎng)技術(shù)考試試卷：MQTT與CoAP押題考試時間：______分鐘總分：______分姓名：______一、選擇題（請將正確選項的代表字母填寫在題后的括號內(nèi)。每小題2分，共20分）1.下列哪一項不是MQTT協(xié)議的主要特點？（）A.支持發(fā)布/訂閱消息模型B.具有三種消息服務(wù)質(zhì)量（QoS）級別C.默認使用TCP/IP協(xié)議棧D.適用于所有需要實時數(shù)據(jù)傳輸?shù)膱鼍?.在MQTT消息模型中，接收方需要訂閱主題，該主題與發(fā)布方發(fā)布的消息的哪個屬性相關(guān)聯(lián)？（）A.消息IDB.消息內(nèi)容C.保留標志（Retained）D.QoS級別3.MQTT協(xié)議中，用于客戶端與服務(wù)器建立連接并維持心跳的機制是？（）A.訂閱B.發(fā)布C.連接保持（Keep-alive）D.消息確認4.CoAP協(xié)議的設(shè)計目標主要關(guān)注于？（）A.高吞吐量和低延遲的發(fā)布/訂閱服務(wù)B.資源受限設(shè)備（如傳感器、嵌入式設(shè)備）的通信C.企業(yè)級應(yīng)用的高可靠性和安全性D.支持大規(guī)模并發(fā)連接5.CoAP協(xié)議默認使用的傳輸層協(xié)議是？（）A.UDPB.TCPC.HTTPD.SMTP6.下列哪個CoAP請求類型用于請求從服務(wù)器獲取資源的當前狀態(tài)？（）A.POSTB.PUTC.DELETED.GET7.CoAP協(xié)議中，用于客戶端接收服務(wù)器推送的通知消息的機制是？（）A.資源注冊B.請求重試C.觀察者（Observer）D.消息確認8.以下哪種情況更適合使用MQTT協(xié)議進行物聯(lián)網(wǎng)數(shù)據(jù)傳輸？（）A.一個傳感器每分鐘發(fā)送少量數(shù)據(jù)給云端平臺B.一個智能家居系統(tǒng)需要實時控制多個設(shè)備的開關(guān)狀態(tài)C.一個車聯(lián)網(wǎng)應(yīng)用需要傳輸大量高清視頻流D.一個農(nóng)業(yè)監(jiān)控系統(tǒng)需要長時間存儲土壤濕度數(shù)據(jù)9.在Python中使用`paho-mqtt`庫創(chuàng)建客戶端時，哪個參數(shù)用于指定MQTT服務(wù)器的地址和端口？（）A.client_idB.usernameC.passwordD.(host,port)10.在Python中使用`coapthon`庫發(fā)送一個CoAPGET請求，通常需要創(chuàng)建哪個對象并調(diào)用其方法？（）A.ClientSocketB.MessageC.RequestD.Context二、填空題（請將正確答案填寫在橫線上。每空2分，共20分）1.MQTT協(xié)議中，客戶端與服務(wù)器之間建立的持久化會話依賴于客戶端的______和服務(wù)器端的______。2.MQTT消息的QoS級別有三種，分別是______、______和______。3.CoAP協(xié)議使用一個字節(jié)來表示消息的______，范圍從0x1到0x15。4.在CoAP中，以“/”開頭，用于標識資源位置的字符串稱為______。5.MQTT協(xié)議中，客戶端在無法連接到服務(wù)器時，可以配置自動______機制。6.CoAP協(xié)議默認端口號是______。7.如果一個MQTT消息被標記為QoS1，則服務(wù)器需要向客戶端發(fā)送______消息來確認接收。8.Python的`paho-mqtt`庫中，用于連接到MQTT服務(wù)器的函數(shù)是______。9.CoAP協(xié)議通過______機制來減少通信開銷，允許客戶端只接收狀態(tài)變化的通知。10.MQTT協(xié)議支持______機制，允許發(fā)布者向一個主題發(fā)布消息，而訂閱者可以訂閱該主題下的多個子主題。三、簡答題（請根據(jù)要求作答。每題5分，共15分）1.簡述MQTT協(xié)議中的“遺囑”（LastWillandTestament,Will）機制的作用。2.簡要說明CoAP協(xié)議中觀察者（Observer）機制與MQTT協(xié)議中的訂閱（Subscription）機制在實現(xiàn)推送通知方面的異同。3.解釋什么是CoAP的請求/響應(yīng)模型，并說明它與HTTP請求/響應(yīng)模型的區(qū)別。四、編程題（請根據(jù)要求完成代碼。每題10分，共20分）1.假設(shè)你已經(jīng)創(chuàng)建了一個名為`client`的`paho-mqtt.client.PahoClient`對象，請補全以下Python代碼片段，使其實現(xiàn)：當客戶端成功連接到MQTT服務(wù)器后，自動訂閱主題`"home/temperature"`，并設(shè)置消息處理回調(diào)函數(shù)`on_message`；當連接斷開時，調(diào)用`on_disconnect`函數(shù)。```pythonimportpaho.mqtt.clientasmqttdefon_message(client,userdata,msg):print(f"Received`{msg.payload.decode()}`from`{msg.topic}`topic")defon_disconnect(client,userdata,rc):ifrc!=0:print("Unexpecteddisconnection.")#---請在此處補全代碼---client=mqtt.Client(client_id="temp_sensor")client.on_message=on_messageclient.on_disconnect=on_disconnect#-----------------------------#...(后續(xù)代碼，如連接服務(wù)器、循環(huán)遍歷)...```2.使用`coapthon`庫編寫Python代碼，創(chuàng)建一個CoAP客戶端，向服務(wù)器``上的資源`/light`發(fā)送一個POST請求，請求負載（Payload）為`"on"`（表示打開燈）。假設(shè)服務(wù)器使用默認的CoAP端口5683，并假設(shè)不需要認證。```python#--請在此處編寫代碼--#------------------------```五、論述題（請根據(jù)要求作答。10分）在實際的物聯(lián)網(wǎng)應(yīng)用中，如何根據(jù)具體的場景需求，選擇使用MQTT協(xié)議還是CoAP協(xié)議？請從設(shè)備資源限制、網(wǎng)絡(luò)環(huán)境、數(shù)據(jù)傳輸頻率與量、可靠性要求、與應(yīng)用層協(xié)議的集成等方面進行比較分析，并舉例說明。試卷答案一、選擇題1.D2.D3.C4.B5.A6.D7.C8.B9.D10.C二、填空題1.ClientID,Session2.Level0,Level1,Level23.MessageType4.URI5.Reconnect6.56837.Acknowledgement(ACK)8.client.connect()9.Observe10.RetainedMessages三、簡答題1.解析思路：MQTTWill機制允許客戶端在異常斷開連接時，向訂閱者發(fā)送一條預(yù)定義的消息（遺囑），通知其連接中斷。這有助于其他應(yīng)用或系統(tǒng)了解客戶端狀態(tài)變化。2.解析思路：CoAPObserver機制是客戶端向服務(wù)器資源注冊興趣，當資源狀態(tài)變化時，服務(wù)器主動向該客戶端發(fā)送通知（通知消息類型）。MQTTSubscription機制是客戶端向服務(wù)器訂閱主題，當主題有新發(fā)布時，服務(wù)器將消息推送給所有訂閱該主題的客戶端。相同點都是實現(xiàn)服務(wù)器到客戶端的推送；不同點在于實現(xiàn)協(xié)議（CoAPObserver是CoAP協(xié)議原生的，MQTTSubscription是MQTT協(xié)議核心）、觸發(fā)方式（CoAP通常是狀態(tài)變化觸發(fā)，MQTT可以是發(fā)布觸發(fā)）。3.解析思路：CoAP請求/響應(yīng)模型是指客戶端發(fā)送一個請求消息到服務(wù)器，服務(wù)器在收到請求后，返回一個響應(yīng)消息給客戶端。這種模型類似于HTTP。區(qū)別在于：CoAP使用UDP作為傳輸層，通常是無連接的；CoAP消息結(jié)構(gòu)更簡單，字段較少，更適合資源受限設(shè)備；CoAP默認端口是5683，而HTTP默認端口是80。四、編程題1.解析思路：使用`paho-mqtt.client`庫，連接后需調(diào)用`client.subscribe()`方法訂閱主題，并傳入主題名稱和回調(diào)函數(shù)。連接斷開回調(diào)是`on_disconnect`，題目已給出。代碼補全部分是調(diào)用`subscribe`方法。2.解析思路：使用`coapthon`庫創(chuàng)建客戶端，通常通過`Client`類實現(xiàn)。需要指定服務(wù)器地址和端口。發(fā)送POST請求通常使用`Message`類創(chuàng)建請求對象，設(shè)置類型（POST）、URI、負載，然后通過客戶端的`request`方法發(fā)送。代碼補全部分是創(chuàng)建客戶端實例，設(shè)置目標，構(gòu)建并發(fā)送POST消息。五、論述題解析思路：選擇MQTT或CoAP需綜合考慮：*設(shè)備資源：CoAP更輕量，適合內(nèi)存、處理能力、電量極其受限的設(shè)備（如傳感器），MQTT相對資源消耗稍高，但功能更豐富。*網(wǎng)絡(luò)環(huán)境：CoAP基于UDP，更適應(yīng)不可靠、低帶寬的網(wǎng)絡(luò)（如LoRaWAN、NB-IoT），MQTT也支持UDP，但通常需要更可靠的連接（如TCP）。*數(shù)據(jù)傳輸：若需要頻繁、少量數(shù)據(jù)傳輸（如傳感器采樣），CoAP簡單高效；若需要發(fā)布/訂閱模式、大規(guī)模設(shè)備管理、發(fā)布者與訂閱者解耦，MQTT更優(yōu)。*可靠性：MQTT支持多種QoS，保證消息傳遞可靠性；CoAP本身可靠性較低，常需結(jié)合可靠傳輸層（如DTLS+RTP