物聯網網路編程和web編程

標籤：內容   流量控制   ftp   asc   展現   道路   key   sock   電話   

本文是基於嵌入式物聯網研發project師的視覺對網路編程和web編程進行闡述。

對於專註J2EE後端服務開發的同學來說，這篇文章可能略微簡單。可是網路編程和web編程對於絕大部分嵌入式物聯網project師來說是一塊真空鄰域。

的確。物聯網研發應該以團隊協作分工的方式進行，所以有嵌入式裝置端、網關、web前端、APP、後端開發等專屬崗位。作為系統架構師。自然須要掌握各種崗位的關鍵技術。

作為嵌入式project師。掌握網路編程、web編程。能極大地擴充自己的視野和構架思維，可以主動地對系統的各種協議和應用情境提出最佳化的見解，而不不過接受任務攤派，至少，可以在不須要依賴後端project師的情況。可以高速搭建一個物聯網demo系統。

因此。掌握一些主要的網路編程、web編程技能，對於提升物聯網研發project師的開發能力是很重要的。

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

OSI七層模型是網路通訊協定的理論研究模型，或者能夠稱之為理想的模型，而TCP/IP四層模型才是事實標準，是已經被廣泛使用的模型。兩者之間的關聯圖例如以下：

衡量一個物聯網平台或者協議是否有用的關鍵技術的因素是它提供的訊息觸達能力，直接影響物聯網應用開發。

所以，我們從訊息觸達能力去分析TCP/IP這個事實標準模型。我們設想下面情境，並分析。

         

1.網路介面層。路由器1和wifi音箱、空調、熱水器組成一個家庭區域網路，其使用wifi（802.11）協議進行通訊。該協議定義了物理訊號、資料幀格式、丟包重發機制、流量控制等等。

這些都是網路介面層的任務。還有。多個裝置共用通道，同一時候發資料會產生衝突。它是怎麼解決的。這也是網路介面層的內容。事實上，物聯網project師不必在意這些內容。由於wifi物理訊號方面的內容是由wifi晶片廠商負責，而wifi單晶片（wifi+SOC）則會提供SDK包並提供SOCKET編程介面了。所以，我們職責的重點是關注網路層以上的編程開發知識。

2.網路層。即IP協議。最基礎的認識是每一個IP相應一個物聯裝置、手機或者一個後方server。

原則上一個網卡相應一個IP，中wifi音箱、wifi熱水器均有一個獨立的IP。網路之間的通訊都是基於IP進行的，網路包會通過路由器終於送到目標IP所相應的裝置上。

Wifi音箱等家庭裝置增加家庭區域網路。事實上是各獲得一個區域網路IP。192.168.*.*，包含路由器1也有一個區域網路地址。可是路由器1另一個互連網IP。僅僅有路由器的互連網IP才幹被外界所獲知。外界是不能主動獲知區域網路IP詳細相應哪個裝置的。僅僅有路由器1才知道，因此全部對外發送的資料包的源IP都是路由器1的互連網IP，外界發送給裝置的資料包的目標IP也是路由器的互連網IP。

我們都知道，裝置上線時須要向物聯平台server告知自己的狀態，以便於使用者控制。

因此物聯平台server的IP必須是一個互連網IP。或者是一個網域名稱（DNS協議能夠將網域名稱解析為IP）。假設它是一個區域網路IP。那裝置是不可能訪問到的。

這裡，我們還必需要記住一點，裝置和物聯平台的第一次通訊永遠都應該裝置主動發出。由於就算物聯平台知道路由器1的公網IP，它也無法將訊息傳送到內部的裝置的。另外，server必需要持續裝置到達物聯平台最後一跳的路由資訊，由於路由資訊原路返回的過程中具有路由器1記錄是哪個裝置發出的資訊。假設不記錄這個資訊，物聯平台單靠路由器1的互連網IP是無法觸達到詳細裝置的。

假設你不能理解上面這一段話，就記住，物聯平台通過路由器1的互連網IP主動發一條訊息到裝置是不能成功的，可是。當裝置發一條訊息給物聯平台後。物聯平台直接響應該資料包（IP源地址和目標地址調換位置）是能夠觸達裝置的。假設是滿足一問一答的方式，那麼server不須要記錄這個路由資訊，假設須要滿足server主動發訊息給裝置的情境。那麼server是須要記錄這個資訊的。

另外。我們知道。網路裝置在物理上表現為一個真實的網卡。網卡的MAC地址是6個位元組。48位。在一個區域網路內通訊，網路編程時都是基於IP地址的，路由器或者交換器怎樣通過IP地址找到相應的MAC地址。即為ARP位址解析通訊協定。這個也是網路層的職責，可是作為開發人員來說。我們瞭解就可以。

3. 傳輸層。即TCP/UDP協議。

對於傳輸層，我們須要理解的是。一台PC或者手機上執行的網路運用可能非常多，可是他們都相應相同一個IP。作業系統怎樣將一個資料包分發給相應的網路運用呢？這就依靠傳輸層所定義的port來區分。常見的網路應用程式層協議都會預設傳輸層port號，如FTP相應21，HTTP相應80。SMTP相應25等等。傳輸層除了定義port號之外，還有兩個非常重要的協議，即TCP連線導向的協議和UDP資料包協議。前者能夠理解為一個虛擬電話連線協定，一旦兩方打電話建立起串連後兩方通話的過程中，全部的資料包均是走相同的路由路徑。

由於連線導向的協議會在頻寬中預留資源來保障。所以連線導向協議能夠保證品質，因此適用於一些對資料品質要求嚴格的網路運用中，如電子郵件應用，假設不保證品質，郵件內容都不保證正確，誰會使用這個郵件系統呢？可是，對於一些音頻視頻類運用，丟一兩幀全然不影響使用者體驗，則會使用UDP協議，其不是連線導向。發完後之前的路由資訊能夠不在儲存，其是使用最大努力交付（即trymy best）。

4. 應用程式層。常見的網路應用協議包含HTTP、FTP、SMTP、POP等等。

嵌入式物聯應用是建立在這些網路應用協議的基礎之上的。

這些協議會規範主要的請求串連、響應和傳輸資料等方面的格式。作為嵌入式物聯網應用來說，其應該自行定義應用協議的格式，這些資料格式能夠簡單自己定義，也能夠使用成熟的標準格式，如HTML、XML、JSON等等。因為防火牆一般僅僅放開port為80的HTTP資料包，所以物聯網應用一般都會構建在HTTP的基礎上。

所以，我們要區分網路應用程式層協議HTTP和應用自己定義協議。後者使用前者進行傳輸通訊。無論應用自己定義協議使用哪一種格式。都須要通訊兩方同一時候使用。

物聯裝置和物聯平台後台通訊時，能夠使用簡單的XML格式或者JSON格式。而物聯平台還要被PC瀏覽器訪問，那麼。因為瀏覽器僅僅支援HTML格式。則要求物聯平台後台提供HTML格式的內容服務，同理，物聯網平台和手機APP之間的通訊能夠用XML或者JSON。

甚至，我們能夠自己定義簡單的命令來實現功能。可是使用XML或者JSON這些格式有助於資料有良好的可讀性，並且也有成熟的類庫來解釋。

這些都是建立在HTTP網路應用協議的基礎上的。

二、socket編程

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

可見，TCP/UDP的socket通訊端在通訊之前須要綁定（bind）IP和port地址。對於TCP來說，server須要先偵聽listen，而client發起connect請求後，server才幹accept，之後即建立連線導向的通訊環境。通過send/recv函數進行通訊。

而UDP編程則非常easy，綁定之後能夠馬上開始傳輸資料。

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

1）堵塞和非堵塞。網路通訊端有堵塞和非堵塞之分。如如果建立的socket是堵塞的，那麼其recv函數就一定要等到對方傳送資料過來，才會返回，否則會一直處於堵塞狀態。而非堵塞狀態則是馬上看看緩衝有沒有資料，如果有就返回資料，沒有會返回錯誤，而不是一直死等。堵塞模式能夠簡單地理解為同步工作模式，而非堵塞模式能夠理解為非同步工作模式。

2）多工。作為server，可能會存在多個client串連。假設輪詢每一個clientsocket有沒有資料，那效率多累啊。

Socket編程的select和poll介面用來解決這類多路IO複用的問題，它可以同一時候偵測多個串連的資料通訊。

三、B/S和C/S

1.B/S是瀏覽器和client模式，使用HTML文法格式。其使用一問一答，即server是無狀態的，它不知道client之前是否已經訪問過。無狀態有助於server高效率並且穩定地服務。可是這樣的模式對於物聯網應用的影響是致命的。由於server無法主動地發送訊息給物聯裝置。

那麼，怎樣改進呢？

1）ajax技術。Ajax技術最新是為瞭解決頁面局部重新整理頻繁的效率問題的。

即一個HTML頁面的局部資料發送變化了。在ajax之前須要又一次發送一次請求，來重新整理整個頁面。而ajax則是只向server請求發送變化的資料。前者在請求時會看到頁面有閃爍，而後者則沒有。我們正好能夠利用ajax來定時向server發起請求，詢問server是否有更新的資料。假設詢問頻率高。那麼即時效果就好，可是會加重server負擔。本質上，還是一問一答的形式，而不是雙向通訊。Ajax須要瀏覽器支援人員。

2）websocket技術。Websocket是為瞭解決HTML的雙向通訊問題而提出的，其在第一條HTTP請求之後會讓server將興許的協議更新到Websocket進行通訊。

Websocket須要tomcat7.0以上的執行容器支援人員。

物聯網應用開發在裝置端能夠通過socket編程來類比HTTP協議，相同能夠類比HTTP之上的HTML、XML或者Websocket。

2. C/S

C/Sclient和server編程在智能機出現之前在PC案頭領域一度被覺得會在逐漸被B/S所代替。可是在智能機裝置端它又煥發新生。雖然HTML5發展迅速。可是個人覺得瀏覽器在手機等智慧型裝置端的體驗還是比不上原生APP。而HTML5更大的優勢是其移植性非常強。

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

眼下看來，非常多人都希望沿用J2EE那套業務架構來支援物聯網，可是物聯裝置畢竟是資源有限，有些終端可能是簡單的單片機，其跑完整的TCP/UDP協議都比較困難，因此有人提出了精簡版的TCP/IP協議。如CoAP（受限制的應用協議(ConstrainedApplicationProtocol)的代名詞）、ucIP、LWIP等等。

從業務應用協議來看，IBM研發的MQTT可能會成為物聯網應用協議的標準。

四、 Web編程

Web編程最先指的是瀏覽器展示內容的文法編程。Web靜態語言即是HTML。

1.HTML不支援資料的動態變化。因此產生了基於解釋引擎的動態語言，如ASP、PHP、JSP等等。這類語言會使用HTML/CSS來描寫敘述展現樣式，而使用動態語言來控制資料的展現，比如訪問資料庫擷取新資料等等。

須要知道，ASP，PHP。JSP這些語言是server程式設計語言，當使用者通過瀏覽器訪問server相應網頁時，該網頁的ASP/PHP/JSP等內容會經過server的解釋引擎轉化為詳細的資料，終於和其它的HTML、CSS資料一起返回給瀏覽器進行展現。因此。瀏覽器得到的永遠都是確定的HTML、CSS和資料，不存在ASP/PHP/JSP的語句。

2.javascript指令碼。

指令碼是瀏覽器支援人員的文法。而不是server支援人員的。比如一個登入介面。要確保使用者輸入的正確性，如不規則字元，長度太長等等，通常會使用javascript指令碼進行檢測，而不須要發送請求給server。上述講到的ajax技術也是瀏覽器支援的指令碼技術。

3.jQuery。它是對javascript技術的封裝，可以更好地進行前端編程式控制制。

4.HTML/CSS/JS指令碼，稱為web前端編程開發，而ASP/JSP/PHP等為後端開發。

5.後端開發自然會涉及到資料庫訪問、商務邏輯。而且其須要和前端進行互動。因此，web應用編程架構普遍使用MVC編程模型，即M為資料模型，負責資料庫訪問；V為視圖，負責展現；C為控制。MVC模型可以對展現和資料庫進行良好的分離。有助於應用開發。

6.作為總體執行架構來理解，server須要包含資料庫（如mysql）、web應用和解釋引擎和web服務（如apache和tomcat）。Apache提供http服務。

7.JSP的基礎是JAVA文法，J2EE架構提供servlet技術，用於支援網路運用。JSP事實上是對servlet的進階封裝並作為獨立的技術出現的，JSP側重支援B/S方面的網路運用。而servlet則通過映射類的方式支援C/S方式的網路運用，如藍芽接入和wifi接入的後端技術即使用servlet進行支援, 頂層使用XML/JSON格式。

物聯網網路編程和web編程