物聯網網絡編程、Web編程綜述

　　本文是基於嵌入式物聯網研發工程師的視覺對網絡編程和web編程進行闡述。對於專一J2EE後端服務開發的童鞋們來講，這篇文章可能稍顯簡單。可是網絡編程和web編程對於絕大部分嵌入式物聯網工程師來講是一塊真空領域。本文的知識體系屬於全棧工程師的範疇。

　　的確，物聯網研發應該以團隊協做分工的方式進行，因此有嵌入式設備端、網關、web前端、APP、後端開發等專屬崗位。做爲系統架構師，天然須要掌握各類崗位的關鍵技術。做爲嵌入式工程師，掌握網絡編程、web編程，可以極大地拓展本身的視野和架構思惟，可以主動地對系統的各類協議和應用場景提出優化的看法，而不只僅是接受任務攤派。至少，可以在不須要依賴後端工程師的狀況，可以快速搭建一個物聯網demo系統。所以，掌握一些基本的網絡編程、web編程技能，對於提高物聯網研發工程師的開發能力是很是重要的。

　　本文能夠視爲嵌入式企鵝圈發佈微信Wifi接入解決方案的首篇原創技術分享。微信Wifi接入方案系列技術分享將陸續公開，敬請關注。本篇文章對物聯網涉及的知識進行概述，以後的文章再進行詳細的指導開發。

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

　　OSI七層模型是網絡協議的理論研究模型，或者能夠稱爲理想的模型，而TCP/IP四層模型纔是事實標準，是已經被普遍使用的模型。二者之間的關聯圖示以下：

　　對於兩種模型的解讀，我想說的是做爲開發人員沒必要強行去理解各層的含義，例如會話層負責什麼，表示層負責什麼。當你在開發過程當中沒有涉及到這些層次所解決的問題的時候，你想理解並記住是比較困難的。可是，當你遇到問題並須要去解決的時候，這時你必定會對這些層次的職責很是清晰。

　　衡量一個物聯網平臺或者協議是否實用的很是關鍵的因素是它提供的消息觸達能力，其直接影響物聯網應用開發。因此，咱們從消息觸達能力去分析TCP/IP這個事實標準模型。咱們設想如下場景，並進行分析。

　　1.網絡接口層。路由器1和wifi音箱、空調、熱水器組成一個家庭局域網，其使用wifi（802.11）協議進行通訊。該協議定義了物理信號、數據幀格式、丟包重發機制、流量控制等等。這些都是網絡接口層的任務。還有，多個設備共享信道，同時發數據會產生衝突，它是怎麼解決的，這也是網絡接口層的內容。其實，物聯網工程師沒必要在乎這些內容。由於wifi物理信號方面的內容是由wifi芯片廠商負責，而wifi單芯片（wifi+SOC）則會提供SDK包並提供SOCKET編程接口了。因此，咱們職責的重點是關注網絡層以上的編程開發知識。

　　2.網絡層，即IP協議，最基礎的認識是每一個IP對應一個物聯設備、手機或者一個後方服務器。原則上一個網卡對應一個IP，如圖中wifi音箱、wifi熱水器均有一個獨立的IP。網絡之間的通訊都是基於IP進行的，網絡包會經過路由器最終送到目標IP所對應的設備上。

　　Wifi音箱等家庭設備加入家庭局域網，實際上是各得到一個局域網IP，192.168.*.*，包括路由器1也有一個局域網地址，可是路由器1還有一個互聯網IP。只有路由器的互聯網IP才能被外界所獲知，外界是不能主動獲知局域網IP具體對應哪一個設備的，只有路由器1才知道，所以全部對外發送的數據包的源IP都是路由器1的互聯網IP，外界發送給設備的數據包的目標IP也是路由器的互聯網IP。

　　咱們都知道，設備上線時須要向物聯平臺服務器告知本身的狀態，以便於用戶控制。所以物聯平臺服務器的IP必須是一個互聯網IP，或者是一個域名（DNS協議能夠將域名解析爲IP）。若是它是一個局域網IP，那設備是不可能訪問到的。

　　這裏，咱們還必需要記住一點，設備和物聯平臺的第一次通訊永遠都應該設備主動發出，由於就算物聯平臺知道路由器1的公網IP，它也沒法將消息傳送到內部的設備的。另外，服務器必需要持續設備到達物聯平臺最後一跳的路由信息，由於路由信息原路返回的過程當中具備路由器1記錄是哪一個設備發出的信息。若是不記錄這個信息，物聯平臺單靠路由器1的互聯網IP是沒法觸達到具體設備的。

　　若是你不能理解上面這一段話，就記住，物聯平臺經過路由器1的互聯網IP主動發一條消息到設備是不能成功的，可是，當設備發一條消息給物聯平臺後，物聯平臺直接響應該數據包（IP源地址和目標地址調換位置）是能夠觸達設備的。若是是知足一問一答的方式，那麼服務器不須要記錄這個路由信息，若是須要知足服務器主動發消息給設備的場景，那麼服務器是須要記錄這個信息的。

　　另外，咱們知道，網絡設備在物理上表現爲一個真實的網卡，網卡的MAC地址是6個字節，48位。在一個局域網內通訊，網絡編程時都是基於IP地址的，路由器或者交換機如何經過IP地址找到對應的MAC地址，即爲ARP地址解析協議，這個也是網絡層的職責，可是做爲開發人員來講，咱們瞭解便可。

　　3. 傳輸層，即TCP/UDP協議。對於傳輸層，咱們須要理解的是，一臺PC或者手機上運行的網絡運用可能不少，可是他們都對應一樣一個IP。操做系統如何將一個數據包分發給對應的網絡運用呢？這就依靠傳輸層所定義的端口來區分。常見的網絡應用層協議都會默認傳輸層端口號，如FTP對應21，HTTP對應80，SMTP對應25等等。傳輸層除了定義端口號以外，還有兩個很是重要的協議，即TCP面向鏈接的協議和UDP數據包協議。前者能夠理解爲一個虛擬的電話鏈接協議，一旦雙方打電話創建起鏈接後雙方通話的過程當中，全部的數據包均是走一樣的路由路徑。由於面向鏈接的協議會在帶寬中預留資源來保障，因此面向鏈接協議可以保證質量，所以適用於一些對數據質量要求嚴格的網絡運用中，如電子郵件應用，若是不保證質量，郵件內容都不保證正確，誰會使用這個郵件系統呢？可是，對於一些音頻視頻類運用，丟一兩幀徹底不影響用戶體驗，則會使用UDP協議，其不是面向鏈接，發完後以前的路由信息能夠不在保存，其是使用最大努力交付（即trymy best）。

　　4. 應用層。常見的網絡應用協議包括HTTP、FTP、SMTP、POP等等。嵌入式物聯應用是創建在這些網絡應用協議的基礎之上的。這些協議會規範基本的請求鏈接、響應和數據傳輸等方面的格式。做爲嵌入式物聯網應用來講，其應該自行定義應用協議的格式，這些數據格式能夠簡單自定義，也可使用成熟的標準格式，如HTML、XML、JSON等等。因爲防火牆通常只放開端口爲80的HTTP數據包，因此物聯網應用通常都會構建在HTTP的基礎上。

　　因此，咱們要區分網絡應用層協議HTTP和應用自定義協議。後者使用前者進行傳輸通訊。無論應用自定義協議使用哪種格式，都須要通訊雙方同時使用。物聯設備和物聯平臺後臺通訊時，可使用簡單的XML格式或者JSON格式，而物聯平臺還要被PC瀏覽器訪問，那麼，因爲瀏覽器只支持HTML格式，則要求物聯平臺後臺提供HTML格式的內容服務，同理，物聯網平臺和手機APP之間的通訊能夠用XML或者JSON。甚至，咱們能夠自定義簡單的命令來實現功能，可是使用XML或者JSON這些格式有助於數據有良好的可讀性，並且也有成熟的類庫來解釋。

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

2、 socket編程

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

　　可見，TCP/UDP的socket套接字在通訊以前須要綁定（bind）IP和端口地址。對於TCP來講，服務器須要先偵聽listen，而客戶端發起connect請求後，服務器才能accept，以後即創建面向鏈接的通訊環境，經過send/recv函數進行通訊。

　　而UDP編程則很簡單，綁定以後能夠當即開始數據傳輸。

　　除了掌握基本的socket編程以外，還須要清楚如下知識：

　　1）阻塞和非阻塞。網絡套接字有阻塞和非阻塞之分。如假設建立的socket是阻塞的，那麼其recv函數就必定要等到對方傳送數據過來，纔會返回，不然會一直處於阻塞狀態。而非阻塞狀態則是當即看看緩衝有沒有數據，若是有就返回數據，沒有會返回錯誤，而不是一直死等。阻塞模式能夠簡單地理解爲同步工做模式，而非阻塞模式能夠理解爲異步工做模式。

　　2）多路複用。做爲服務器，可能會存在多個客戶端鏈接，若是輪詢每一個客戶端socket有沒有數據，那效率多累啊。Socket編程的select和poll接口用來解決這類多路IO複用的問題，它可以同時偵測多個鏈接的數據通訊。

3、 B/S和C/S

1.B/S是瀏覽器和客戶端模式，使用HTML語法格式。其使用一問一答，即服務器是無狀態的，它不知道客戶端以前是否已經訪問過。無狀態有助於服務器高效率並且穩定地服務。可是這種模式對於物聯網應用的影響是致命的。由於服務器沒法主動地發送消息給物聯設備。那麼，如何改進呢？

　　1）ajax技術。Ajax技術最新是爲了解決頁面局部刷新頻繁的效率問題的。即一個HTML頁面的局部數據發送變化了，在ajax以前須要從新發送一次請求，來刷新整個頁面。而ajax則是僅僅向服務器請求發送變化的數據。前者在請求時會看到頁面有閃爍，然後者則沒有。咱們正好能夠利用ajax來定時向服務器發起請求，詢問服務器是否有更新的數據。若是詢問頻率高，那麼實時效果就好，可是會加劇服務器負擔。本質上，仍是一問一答的形式，而不是雙向通訊。Ajax須要瀏覽器技術支持。

　　2）websocket技術。Websocket是爲了解決HTML的雙向通訊問題而提出的，其在第一條HTTP請求以後會讓服務器將後續的協議更新到Websocket進行通訊。Websocket須要tomcat7.0以上的運行容器技術支持。

物聯網應用開發在設備端能夠經過socket編程來模擬HTTP協議，一樣能夠模擬HTTP之上的HTML、XML或者Websocket。

2. C/S

　　C/S客戶端和服務器編程在智能機出現以前在PC桌面領域一度被認爲會在逐漸被B/S所取代，可是在智能機設備端它又煥發新生。儘管HTML5發展迅速，可是我的以爲瀏覽器在手機等智能設備端的體驗仍是比不上原生APP。而HTML5更大的優點是其移植性很強。

　　C/S編程能夠直接使用socket通訊進行通訊，那天然不存在雙方通訊的問題。若是C/S編程使用http類庫進行編程通訊，它一樣也會存在雙向通訊的問題。

　　目前看來，不少人都但願沿用J2EE那套業務架構來支持物聯網，可是物聯設備畢竟是資源有限，有些終端多是簡單的單片機，其跑完整的TCP/UDP協議都比較困難，所以有人提出了精簡版的TCP/IP協議，如CoAP（受限制的應用協議(ConstrainedApplicationProtocol)的代名詞）、ucIP、LWIP等等。從業務應用協議來看，IBM研發的MQTT可能會成爲物聯網應用協議的標準。

4、 Web編程

　　Web編程最早指的是瀏覽器展現內容的語法編程。Web靜態語言便是HTML。

　　1.HTML不支持數據的動態變化。所以產生了基於解釋引擎的動態語言，如ASP、PHP、JSP等等。這類語言會使用HTML/CSS來描述展示樣式，而使用動態語言來控制數據的展示，例如訪問數據庫獲取新數據等等。

　　須要知道，ASP，PHP，JSP這些語言是服務器編程語言，當用戶經過瀏覽器訪問服務器對應網頁時，該網頁的ASP/PHP/JSP等內容會通過服務器的解釋引擎轉化爲具體的數據，最終和其餘的HTML、CSS數據一塊兒返回給瀏覽器進行展示。所以，瀏覽器獲得的永遠都是肯定的HTML、CSS和數據，不存在ASP/PHP/JSP的語句。

　　2.javascript腳本。腳本是瀏覽器技術支持的語法，而不是服務器技術支持的。例如一個登陸界面，要確保用戶輸入的正確性，如不規則字符，長度太長等等，通常會使用javascript腳本進行檢測，而不須要發送請求給服務器。上述講到的ajax技術也是瀏覽器支持的腳本技術。

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

　　4.HTML/CSS/JS腳本，稱爲web前端編程開發，而ASP/JSP/PHP等爲後端開發。

　　5.後端開發天然會涉及到數據庫訪問、業務邏輯，而且其須要和前端進行交互。所以，web應用編程架構廣泛使用MVC編程模型，即M爲數據模型，負責數據庫訪問；V爲視圖，負責展示；C爲控制。MVC模型可以對展示和數據庫進行良好的分離，有助於應用開發。

　　6.做爲總體運行架構來理解，服務器須要包括數據庫（如mysql）、web應用和解釋引擎和web服務（如apache和tomcat）。Apache提供http服務。

　　7.JSP的基礎是JAVA語法，J2EE架構提供servlet技術，用於支持網絡運用。JSP實際上是對servlet的高級封裝並做爲獨立的技術出現的，JSP側重支持B/S方面的網絡運用，而servlet則經過映射類的方式支持C/S方式的網絡運用，如微信藍牙接入和wifi接入的後端技術即便用servlet進行支持, 頂層使用XML/JSON格式。

      更多嵌入式和物聯網原創技術分享敬請關注微信公衆號：嵌入式企鵝圈