本文是基于嵌入式物联网研发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格式。