protocol buffers是google提供的一种将结构化数据进行序列化和反序列化的方法，其优点是语言中立，平台中立，可扩展性好，目前在google内部大量用于数据存储，通讯协议等方面。PB在功能上类似XML，但是序列化后的数据更小，解析更快，使用上更简单。用户只要按照proto语法在.proto文件中定义好数据的结构，就可以使用PB提供的工具（protoc）自动生成处理数据的代码，使用这些代码就能在程序中方便的通过各种数据流读写数据。PB目前支持Java, C++和Python3种语言。另外，PB还提供了很好的向后兼容，即旧版本的程序可以正常处理新版本的数据，新版本的程序也能正常处理旧版本的数据。
第三章用实际的示例探讨了请求-回应模式的高级用法。本章将探讨可靠性的问题，在ZeroMQ的核心请求-应答模式上创建可靠的消息模式。本章主要关注用户空间的模式，它们可以帮助你设计ZeroMQ应用程序。
请求-应答模式中，信封用于存储应答的返回地址。无状态的ZeroMQ网络通过使用信封才能创建来回的请求-应答会话。
一般的使用中不用理解请求-应答信封是如何工作的。使用REQ和REP的时候，套接字会自动处理信封。像上一章中那样编写设备的时候，也只需要读写消息的所有部分就可以了。ZeroMQ使用多段消息来实现信封，所以只要安全地复制多段消息，就隐含地复制信封了。
1 零之禅
名字中Zero的含义：
无需代理(zero broker）
零延迟（zero latency as possible)
Zero也表示设计目标：
零管理
零开销
零浪费
如何解释ZeroMQ？
用它可以完成的精彩的事情来解释：ZeroMQ是打了激素的套接字（It’s sockets on steroids）；ZeroMQ是带有路由的邮箱。
用人们对它的评价来解释：ZeroMQ很快；复杂性不见了，ZeroMQ让事情变得简单；ZeroMQ解放了思维。
通过比较来解释：ZeroMQ更小、更简单。
I´ve been working on integrating zeromq with libevent in order to implement some kind of high performance proxy server. The server is built as a mxn system, where we maintain m streamers that all respond to requests in the the same port (in this example, port 12000) and then forward requests to ndownloaders that do the real content download. The downloader then responds back to the streamer that the download has ended and that the content is ready.
最近对zeroconf协议进行了一系列深入的研究，深深地被这一技术折服，在1999年就出现的该协议，在技术的应用上已经走向成熟，走向向大众普及之路了。
apple的airplay，airprint都是依赖了zeroconf的基础上，才展现出强大的功能。
以NFC为代表的近距离无线通讯技术已经不是什么新鲜玩意了，而近场通讯的实用性和便利性，也使其成为业界一大热点，众多顶级公司都对这项技术寄予厚望，连全球最大的手机芯片制造商高通也推出了近距离P2P通讯技术AllJoyn，两台同样使用AllJoyn技术的设备可以快速实现数据共享。
apache 设置禁止访问某些文件或目录
ØMQ (ZeroMQ, 0MQ, zmq),这一堆表达方式看哪个顺眼就选哪个吧，都指的咱要讲的这玩意儿。
它出现的目的只有一个：更高效的利用机器。好吧，这是我个人的看法，官方说法是：让任何地方、任何代码可以互联。
应该很明白吧，如果非要做联想类比，好吧，可以想成经典的C/S模型，这个东东封装了所有底层细节，开发人员只要关注代码逻辑就可以了。(虽然联想成C/S，但可不仅仅如此哦，具体往下看)。
它的通信协议是AMQP,具体的Google之吧，在自由市场里，它有一个对头RabbitMQ，关于那只”兔子”，那又是另外一个故事了。