本文是基于嵌入式物聯(lián)網(wǎng)研發(fā)project師的視覺對網(wǎng)絡(luò)編程和web編程進(jìn)行闡述。

對于專注J2EE后端服務(wù)開發(fā)的同學(xué)來說，這篇文章可能略微簡單?？墒蔷W(wǎng)絡(luò)編程和web編程對于絕大部分嵌入式物聯(lián)網(wǎng)project師來說是一塊真空鄰域。

的確。物聯(lián)網(wǎng)研發(fā)應(yīng)該以團(tuán)隊協(xié)作分工的方式進(jìn)行，所以有嵌入式設(shè)備端、網(wǎng)關(guān)、web前端、APP、后端開發(fā)等專屬崗位。作為系統(tǒng)架構(gòu)師。自然須要掌握各種崗位的關(guān)鍵技術(shù)。

作為嵌入式project師。掌握網(wǎng)絡(luò)編程、web編程。能極大地擴(kuò)展自己的視野和構(gòu)架思維，可以主動地對系統(tǒng)的各種協(xié)議和應(yīng)用場景提出優(yōu)化的見解，而不不過接受任務(wù)攤派，至少，可以在不須要依賴后端project師的情況?？梢愿咚俅罱ㄒ粋€物聯(lián)網(wǎng)demo系統(tǒng)。

因此。掌握一些主要的網(wǎng)絡(luò)編程、web編程技能，對于提升物聯(lián)網(wǎng)研發(fā)project師的開發(fā)能力是很重要的。

一、OSI七層模型和TCP/IP四層模型

OSI七層模型是網(wǎng)絡(luò)協(xié)議的理論研究模型，或者能夠稱之為理想的模型，而TCP/IP四層模型才是事實標(biāo)準(zhǔn)，是已經(jīng)被廣泛使用的模型。兩者之間的關(guān)聯(lián)圖例如以下：

衡量一個物聯(lián)網(wǎng)平臺或者協(xié)議是否有用的關(guān)鍵技術(shù)的因素是它提供的消息觸達(dá)能力，直接影響物聯(lián)網(wǎng)應(yīng)用開發(fā)。

所以，我們從消息觸達(dá)能力去分析TCP/IP這個事實標(biāo)準(zhǔn)模型。我們設(shè)想下面場景，并分析。

? ? ? ? ?

1.網(wǎng)絡(luò)接口層。路由器1和wifi音箱、空調(diào)、熱水器組成一個家庭局域網(wǎng)，其使用wifi（802.11）協(xié)議進(jìn)行通信。該協(xié)議定義了物理信號、數(shù)據(jù)幀格式、丟包重發(fā)機(jī)制、流量控制等等。

這些都是網(wǎng)絡(luò)接口層的任務(wù)。還有。多個設(shè)備共享信道，同一時候發(fā)數(shù)據(jù)會產(chǎn)生沖突。它是怎么解決的。這也是網(wǎng)絡(luò)接口層的內(nèi)容。事實上，物聯(lián)網(wǎng)project師不必在意這些內(nèi)容。由于wifi物理信號方面的內(nèi)容是由wifi芯片廠商負(fù)責(zé)，而wifi單芯片（wifi+SOC）則會提供SDK包并提供SOCKET編程接口了。所以，我們職責(zé)的重點是關(guān)注網(wǎng)絡(luò)層以上的編程開發(fā)知識。

2.網(wǎng)絡(luò)層。即IP協(xié)議。最基礎(chǔ)的認(rèn)識是每一個IP相應(yīng)一個物聯(lián)設(shè)備、手機(jī)或者一個后方server。

原則上一個網(wǎng)卡相應(yīng)一個IP，如圖中wifi音箱、wifi熱水器均有一個獨立的IP。網(wǎng)絡(luò)之間的通信都是基于IP進(jìn)行的，網(wǎng)絡(luò)包會通過路由器終于送到目標(biāo)IP所相應(yīng)的設(shè)備上。

Wifi音箱等家庭設(shè)備增加家庭局域網(wǎng)。事實上是各獲得一個局域網(wǎng)IP。192.168.*.*，包含路由器1也有一個局域網(wǎng)地址?？墒锹酚善?另一個互聯(lián)網(wǎng)IP。僅僅有路由器的互聯(lián)網(wǎng)IP才干被外界所獲知。外界是不能主動獲知局域網(wǎng)IP詳細(xì)相應(yīng)哪個設(shè)備的。僅僅有路由器1才知道，因此全部對外發(fā)送的數(shù)據(jù)包的源IP都是路由器1的互聯(lián)網(wǎng)IP，外界發(fā)送給設(shè)備的數(shù)據(jù)包的目標(biāo)IP也是路由器的互聯(lián)網(wǎng)IP。

我們都知道，設(shè)備上線時須要向物聯(lián)平臺server告知自己的狀態(tài)，以便于用戶控制。

因此物聯(lián)平臺server的IP必須是一個互聯(lián)網(wǎng)IP?；蛘呤且粋€域名（DNS協(xié)議能夠?qū)⒂蛎馕鰹镮P）。假設(shè)它是一個局域網(wǎng)IP。那設(shè)備是不可能訪問到的。

這里，我們還必需要記住一點，設(shè)備和物聯(lián)平臺的第一次通信永遠(yuǎn)都應(yīng)該設(shè)備主動發(fā)出。由于就算物聯(lián)平臺知道路由器1的公網(wǎng)IP，它也無法將消息傳送到內(nèi)部的設(shè)備的。另外，server必需要持續(xù)設(shè)備到達(dá)物聯(lián)平臺最后一跳的路由信息，由于路由信息原路返回的過程中具有路由器1記錄是哪個設(shè)備發(fā)出的信息。假設(shè)不記錄這個信息，物聯(lián)平臺單靠路由器1的互聯(lián)網(wǎng)IP是無法觸達(dá)到詳細(xì)設(shè)備的。

假設(shè)你不能理解上面這一段話，就記住，物聯(lián)平臺通過路由器1的互聯(lián)網(wǎng)IP主動發(fā)一條消息到設(shè)備是不能成功的，可是。當(dāng)設(shè)備發(fā)一條消息給物聯(lián)平臺后。物聯(lián)平臺直接響應(yīng)該數(shù)據(jù)包（IP源地址和目標(biāo)地址調(diào)換位置）是能夠觸達(dá)設(shè)備的。假設(shè)是滿足一問一答的方式，那么server不須要記錄這個路由信息，假設(shè)須要滿足server主動發(fā)消息給設(shè)備的場景。那么server是須要記錄這個信息的。

另外。我們知道。網(wǎng)絡(luò)設(shè)備在物理上表現(xiàn)為一個真實的網(wǎng)卡。網(wǎng)卡的MAC地址是6個字節(jié)。48位。在一個局域網(wǎng)內(nèi)通信，網(wǎng)絡(luò)編程時都是基于IP地址的，路由器或者交換機(jī)怎樣通過IP地址找到相應(yīng)的MAC地址。即為ARP地址解析協(xié)議。這個也是網(wǎng)絡(luò)層的職責(zé)，可是作為開發(fā)者來說。我們了解就可以。

3. 傳輸層。即TCP/UDP協(xié)議。

對于傳輸層，我們須要理解的是。一臺PC或者手機(jī)上執(zhí)行的網(wǎng)絡(luò)運用可能非常多，可是他們都相應(yīng)相同一個IP。操作系統(tǒng)怎樣將一個數(shù)據(jù)包分發(fā)給相應(yīng)的網(wǎng)絡(luò)運用呢？這就依靠傳輸層所定義的port來區(qū)分。常見的網(wǎng)絡(luò)應(yīng)用層協(xié)議都會默認(rèn)傳輸層port號，如FTP相應(yīng)21，HTTP相應(yīng)80。SMTP相應(yīng)25等等。傳輸層除了定義port號之外，還有兩個非常重要的協(xié)議，即TCP面向連接的協(xié)議和UDP數(shù)據(jù)包協(xié)議。前者能夠理解為一個虛擬的電話連接協(xié)議，一旦兩方打電話建立起連接后兩方通話的過程中，全部的數(shù)據(jù)包均是走相同的路由路徑。

由于面向連接的協(xié)議會在帶寬中預(yù)留資源來保障。所以面向連接協(xié)議能夠保證質(zhì)量，因此適用于一些對數(shù)據(jù)質(zhì)量要求嚴(yán)格的網(wǎng)絡(luò)運用中，如電子郵件應(yīng)用，假設(shè)不保證質(zhì)量，郵件內(nèi)容都不保證正確，誰會使用這個郵件系統(tǒng)呢？可是，對于一些音頻視頻類運用，丟一兩幀全然不影響用戶體驗，則會使用UDP協(xié)議，其不是面向連接。發(fā)完后之前的路由信息能夠不在保存，其是使用最大努力交付（即trymy best）。

4. 應(yīng)用層。常見的網(wǎng)絡(luò)應(yīng)用協(xié)議包含HTTP、FTP、SMTP、POP等等。

嵌入式物聯(lián)應(yīng)用是建立在這些網(wǎng)絡(luò)應(yīng)用協(xié)議的基礎(chǔ)之上的。

這些協(xié)議會規(guī)范主要的請求連接、響應(yīng)和傳輸數(shù)據(jù)等方面的格式。作為嵌入式物聯(lián)網(wǎng)應(yīng)用來說，其應(yīng)該自行定義應(yīng)用協(xié)議的格式，這些數(shù)據(jù)格式能夠簡單自己定義，也能夠使用成熟的標(biāo)準(zhǔn)格式，如HTML、XML、JSON等等。因為防火墻一般僅僅放開port為80的HTTP數(shù)據(jù)包，所以物聯(lián)網(wǎng)應(yīng)用一般都會構(gòu)建在HTTP的基礎(chǔ)上。

所以，我們要區(qū)分網(wǎng)絡(luò)應(yīng)用層協(xié)議HTTP和應(yīng)用自己定義協(xié)議。后者使用前者進(jìn)行傳輸通信。無論應(yīng)用自己定義協(xié)議使用哪一種格式。都須要通信兩方同一時候使用。

物聯(lián)設(shè)備和物聯(lián)平臺后臺通信時，能夠使用簡單的XML格式或者JSON格式。而物聯(lián)平臺還要被PC瀏覽器訪問，那么。因為瀏覽器僅僅支持HTML格式。則要求物聯(lián)平臺后臺提供HTML格式的內(nèi)容服務(wù)，同理，物聯(lián)網(wǎng)平臺和手機(jī)APP之間的通信能夠用XML或者JSON。

甚至，我們能夠自己定義簡單的命令來實現(xiàn)功能。可是使用XML或者JSON這些格式有助于數(shù)據(jù)有良好的可讀性，并且也有成熟的類庫來解釋。

這些都是建立在HTTP網(wǎng)絡(luò)應(yīng)用協(xié)議的基礎(chǔ)上的。

二、socket編程

socket編程分為TCP和UDP兩種方式。分別例如以下：

可見，TCP/UDP的socket套接字在通信之前須要綁定（bind）IP和port地址。對于TCP來說，server須要先偵聽listen，而client發(fā)起connect請求后，server才干accept，之后即建立面向連接的通信環(huán)境。通過send/recv函數(shù)進(jìn)行通信。

而UDP編程則非常easy，綁定之后能夠馬上開始傳輸數(shù)據(jù)。

除了掌握主要的socket編程之外，還須要清楚下面知識：

1）堵塞和非堵塞。網(wǎng)絡(luò)套接字有堵塞和非堵塞之分。如如果創(chuàng)建的socket是堵塞的，那么其recv函數(shù)就一定要等到對方傳送數(shù)據(jù)過來，才會返回，否則會一直處于堵塞狀態(tài)。而非堵塞狀態(tài)則是馬上看看緩沖有沒有數(shù)據(jù)，如果有就返回數(shù)據(jù)，沒有會返回錯誤，而不是一直死等。堵塞模式能夠簡單地理解為同步工作模式，而非堵塞模式能夠理解為異步工作模式。

2）多路復(fù)用。作為server，可能會存在多個client連接。假設(shè)輪詢每一個clientsocket有沒有數(shù)據(jù)，那效率多累啊。

Socket編程的select和poll接口用來解決這類多路IO復(fù)用的問題，它可以同一時候偵測多個連接的數(shù)據(jù)通信。

三、B/S和C/S

1.B/S是瀏覽器和client模式，使用HTML語法格式。其使用一問一答，即server是無狀態(tài)的，它不知道client之前是否已經(jīng)訪問過。無狀態(tài)有助于server高效率并且穩(wěn)定地服務(wù)?？墒沁@樣的模式對于物聯(lián)網(wǎng)應(yīng)用的影響是致命的。由于server無法主動地發(fā)送消息給物聯(lián)設(shè)備。

那么，怎樣改進(jìn)呢？

1）ajax技術(shù)。Ajax技術(shù)最新是為了解決頁面局部刷新頻繁的效率問題的。

即一個HTML頁面的局部數(shù)據(jù)發(fā)送變化了。在ajax之前須要又一次發(fā)送一次請求，來刷新整個頁面。而ajax則是只向server請求發(fā)送變化的數(shù)據(jù)。前者在請求時會看到頁面有閃爍，而后者則沒有。我們正好能夠利用ajax來定時向server發(fā)起請求，詢問server是否有更新的數(shù)據(jù)。假設(shè)詢問頻率高。那么實時效果就好，可是會加重server負(fù)擔(dān)。本質(zhì)上，還是一問一答的形式，而不是雙向通信。Ajax須要瀏覽器技術(shù)支持。

2）websocket技術(shù)。Websocket是為了解決HTML的雙向通信問題而提出的，其在第一條HTTP請求之后會讓server將興許的協(xié)議更新到Websocket進(jìn)行通信。

Websocket須要tomcat7.0以上的執(zhí)行容器技術(shù)支持。

物聯(lián)網(wǎng)應(yīng)用開發(fā)在設(shè)備端能夠通過socket編程來模擬HTTP協(xié)議，相同能夠模擬HTTP之上的HTML、XML或者Websocket。

2. C/S

C/Sclient和server編程在智能機(jī)出現(xiàn)之前在PC桌面領(lǐng)域一度被覺得會在逐漸被B/S所代替。可是在智能機(jī)設(shè)備端它又煥發(fā)新生。雖然HTML5發(fā)展迅速?？墒莻€人覺得瀏覽器在手機(jī)等智能設(shè)備端的體驗還是比不上原生APP。而HTML5更大的優(yōu)勢是其移植性非常強。

C/S編程能夠直接使用socket通信進(jìn)行通信，那自然不存在兩方通信的問題。假設(shè)C/S編程使用http類庫進(jìn)行編程通信。它相同也會存在雙向通信的問題。

眼下看來，非常多人都希望沿用J2EE那套業(yè)務(wù)架構(gòu)來支持物聯(lián)網(wǎng)，可是物聯(lián)設(shè)備畢竟是資源有限，有些終端可能是簡單的單片機(jī)，其跑完整的TCP/UDP協(xié)議都比較困難，因此有人提出了精簡版的TCP/IP協(xié)議。如CoAP（受限制的應(yīng)用協(xié)議(ConstrainedApplicationProtocol)的代名詞）、ucIP、LWIP等等。

從業(yè)務(wù)應(yīng)用協(xié)議來看，IBM研發(fā)的MQTT可能會成為物聯(lián)網(wǎng)應(yīng)用協(xié)議的標(biāo)準(zhǔn)。

四、 Web編程

Web編程最先指的是瀏覽器展示內(nèi)容的語法編程。Web靜態(tài)語言即是HTML。

1.HTML不支持?jǐn)?shù)據(jù)的動態(tài)變化。因此產(chǎn)生了基于解釋引擎的動態(tài)語言，如ASP、PHP、JSP等等。這類語言會使用HTML/CSS來描寫敘述展現(xiàn)樣式，而使用動態(tài)語言來控制數(shù)據(jù)的展現(xiàn)，比如訪問數(shù)據(jù)庫獲取新數(shù)據(jù)等等。

須要知道，ASP，PHP。JSP這些語言是server編程語言，當(dāng)用戶通過瀏覽器訪問server相應(yīng)網(wǎng)頁時，該網(wǎng)頁的ASP/PHP/JSP等內(nèi)容會經(jīng)過server的解釋引擎轉(zhuǎn)化為詳細(xì)的數(shù)據(jù)，終于和其它的HTML、CSS數(shù)據(jù)一起返回給瀏覽器進(jìn)行展現(xiàn)。因此。瀏覽器得到的永遠(yuǎn)都是確定的HTML、CSS和數(shù)據(jù)，不存在ASP/PHP/JSP的語句。

2.javascript腳本。

腳本是瀏覽器技術(shù)支持的語法。而不是server技術(shù)支持的。比如一個登錄界面。要確保用戶輸入的正確性，如不規(guī)則字符，長度太長等等，通常會使用javascript腳本進(jìn)行檢測，而不須要發(fā)送請求給server。上述講到的ajax技術(shù)也是瀏覽器支持的腳本技術(shù)。

3.jQuery。它是對javascript技術(shù)的封裝，可以更好地進(jìn)行前端編程控制。

4.HTML/CSS/JS腳本，稱為web前端編程開發(fā)，而ASP/JSP/PHP等為后端開發(fā)。

5.后端開發(fā)自然會涉及到數(shù)據(jù)庫訪問、業(yè)務(wù)邏輯。而且其須要和前端進(jìn)行交互。因此，web應(yīng)用編程架構(gòu)普遍使用MVC編程模型，即M為數(shù)據(jù)模型，負(fù)責(zé)數(shù)據(jù)庫訪問；V為視圖，負(fù)責(zé)展現(xiàn)；C為控制。MVC模型可以對展現(xiàn)和數(shù)據(jù)庫進(jìn)行良好的分離。有助于應(yīng)用開發(fā)。

6.作為總體執(zhí)行架構(gòu)來理解，server須要包含數(shù)據(jù)庫（如mysql）、web應(yīng)用和解釋引擎和web服務(wù)（如apache和tomcat）。Apache提供http服務(wù)。

7.JSP的基礎(chǔ)是JAVA語法，J2EE架構(gòu)提供servlet技術(shù)，用于支持網(wǎng)絡(luò)運用。JSP事實上是對servlet的高級封裝并作為獨立的技術(shù)出現(xiàn)的，JSP側(cè)重支持B/S方面的網(wǎng)絡(luò)運用。而servlet則通過映射類的方式支持C/S方式的網(wǎng)絡(luò)運用，如微信藍(lán)牙接入和wifi接入的后端技術(shù)即使用servlet進(jìn)行支持, 頂層使用XML/JSON格式。

轉(zhuǎn)載于:https://www.cnblogs.com/liguangsunls/p/7255440.html

總結(jié)

以上是生活随笔為你收集整理的物联网网络编程和web编程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。