通信协议入门(socket通信协议)

一般来说初学者要学习网络知识还是先看网络方面的书，推荐Cisco认证的书，可以先看CCNA的相关内容，包括网络基础知识、路由协议及概念、接入WAN、LAN交换和无线，后期等入门了再看更高级的CCNP CCIE的书。 网络基础知识不管看哪类厂家推出的认证的书都是一样的，是基础，后续就要看相关考哪个认证了，有能力的推荐还是Cisco认证，NA-NA-IE，国内比较吃香试用的是华为/华三的H3C NE、SE、TE认证。网络方面推荐入门书籍：思科网络技术学院教程CCNA Exploration全套四册 通信其实和网络是两块内容，要学的话要看通信方面的书了。
个人向您推荐由谢希仁主编、电子工业出版社出版的《计算机网络》第4版，第5版。其内容较为丰富，由OSI/AM分层次的系统模型逐层讲解，层层递进，颇具分量，便于理解。学习计算机网络的话，这本书是个不错的选择。总的来说，您可以找些清华大学或者是电子工业出版社的计算机类专业书籍来看，它们出版的计算机类专业书籍相当不错，值得一看。
ccna ccnpccne

网络层(network layer)是实现互联网的最重要的一层。正是在网络层面上，各个局域网根据IP协议相互连接，最终构成覆盖全球的Internet。更高层的协议，无论是TCP还是UDP，必须通过网络层的IP数据包(datagram)来传递信息。操作系统也会提供该层的socket，从而允许用户直接操作IP包。 IP数据包是符合IP协议的信息(也就是0/1序列)，我们后面简称IP数据包为IP包。IP包分为头部(header)和数据(Data)两部分。数据部分是要传送的信息，头部是为了能够实现传输而附加的信息(这与以太网帧的头部功能相类似,如果对帧感到陌生，可参看 小喇叭 一文)。IP协议可以分为IPv4和IPv6两种。IPv6是改进版本，用于在未来取代IPv4协议。出于本文的目的，我们可以暂时忽略两者的区别，只以IPv4为例。下面是IPv4的格式IPv4包 我们按照4 bytes将整个序列折叠，以便更好的显示与帧类似，IP包的头部也有多个区域。我们将注意力放在红色的发出地(source address)和目的地(destination address)。它们都是IP地址。IPv4的地址为4 bytes的长度(也就是32位)。我们通常将IPv4的地址分为四个十进制的数，每个数的范围为0-255,比如192.0.0.1就是一个IP地址。填写在IP包头部的是该地址的二进制形式。IP地址是全球地址，它可以识别”社区”(局域网)和”房子”(主机)。这是通过将IP地址分类实现的。IP class    From          To                Subnet MaskA           1.0.0.0       126.255.255.255    255.0.0.0B           128.0.0.0     191.255.255.255    255.255.0.0C           192.0.0.0     223.255.255.255    255.255.255.0每个IP地址的32位分为前后两部分，第一部分用来区分局域网，第二个部分用来区分该局域网的主机。子网掩码(Subnet Mask)告诉我们这两部分的分界线，比如255.0.0.0(也就是8个1和24个0)表示前8位用于区分局域网，后24位用于区分主机。由于A、B、C分类是已经规定好的，所以当一个IP地址属于B类范围时，我们就知道它的前16位和后16位分别表示局域网和主机。网络协议概览 中说，IP地址是分配给每个房子(计算机)的“邮编”。但这个说法并不精确。IP地址实际上识别的是网卡(NIC, Network Interface Card)。网卡是计算机的一个硬件，它在接收到网路信息之后，将信息交给计算机(处理器/内存)。当计算机需要发送信息的时候，也要通过网卡发送。一台计算机可以有不只一个网卡，比如笔记本就有一个以太网卡和一个WiFi网卡。计算机在接收或者发送信息的时候，要先决定想要通过哪个网卡。NIC路由器(router)实际上就是一台配备有多个网卡的专用电脑。它让网卡接入到不同的网络中，这样，就构成在 网络协议概览 中所说的邮局。比如下图中位于中间位置的路由器有两个网卡，地址分别为199.165.145.17和199.165.146.3。它们分别接入到两个网络：199.165.145和199.165.146。IP包的传输要通过路由器的接力。每一个主机和路由中都存有一个路由表(routing table)。路由表根据目的地的IP地址，规定了等待发送的IP包所应该走的路线。就好像下图的路标，如果地址是“东京”，那么请转左；如果地址是“悉尼”，那么请向右。A real world routing table比如我们从主机145.17生成发送到146.21的IP包：铺开信纸，写好信的开头(剩下数据部分可以是TCP包，可以是UDP包，也可以是任意乱写的字，我们暂时不关心)，注明目的地IP地址(199.165.146.21)和发出地IP地址(199.165.145.17)。主机145.17随后参照自己的routing table，里面有三行记录：145.17 routing table (Genmask为子网掩码,Iface用于说明使用哪个网卡接口)Destination        Gateway             Genmask             Iface199.165.145.0      0.0.0.0             255.255.255.0       eth00.0.0.0            199.165.145.17      0.0.0.0             eth0这里有两行记录。第一行表示，如果IP目的地是199.165.145.0这个网络的主机，那么只需要自己在eth0上的网卡直接传送(“本地社区”：直接送达)，不需要前往router(Gateway 0.0.0.0 = “本地送信”)。第二行表示所有不符合第一行的IP目的地，都应该送往Gateway 199.165.145.17，也就是中间router接入在eth0的网卡IP地址(邮局在eth0的分支)。我们的IP包目的地为199.165.146.21，不符合第一行，所以按照第二行，发送到中间的router。主机145.17会将IP包放入帧的payload，并在帧的头部写上199.165.145.17对应的MAC地址，这样，就可以按照 以太网与wifi协议 中的方法在局域网中传送了。中间的router在收到IP包之后(实际上是收到以太协议的帧，然后从帧中的payload读取IP包)，提取目的地IP地址，然后对照自己的routing table：Destination        Gateway             Genmask             Iface199.165.145.0      0.0.0.0             255.255.255.0       eth0199.165.146.0      0.0.0.0             255.255.255.0       eth10.0.0.0            199.165.146.8       0.0.0.0             eth1从前两行我们看到，由于router横跨eth0和eth1两个网络，它可以直接通过eth0和eth1上的网卡直接传送IP包。第三行表示，如果是前面两行之外的IP地址，则需要通过eth1，送往199.165.146.8(右边的router)。我们的目的地符合第二行，所以将IP放入一个新的帧中，在帧的头部写上199.165.146.21的MAC地址，直接发往主机146.21。(在Linux下，可以使用$route -n来查看routing table)IP包可以进一步接力，到达更远的主机。IP包从主机出发，根据沿途路由器的routing table指导，在router间接力。IP包最终到达某个router，这个router与目标主机位于一个局域网中，可以直接建立连接层的通信。最后，IP包被送到目标主机。这样一个过程叫做routing(我们就叫IP包接力好了，路由这个词实在是混合了太多的意思)。整个过程中，IP包不断被主机和路由封装入帧(信封)并拆开，然后借助连接层，在局域网的各个NIC之间传送帧。整个过程中，我们的IP包的内容保持完整，没有发生变化。最终的效果是一个IP包从一个主机传送到另一个主机。利用IP包，我们不需要去操心底层(比如连接层)发生了什么。在上面的过程中，我们实际上假设了，每一台主机和路由都能了解局域网内的IP地址和MAC地址的对应关系，这是实现IP包封装(encapsulation)到帧的基本条件。IP地址与MAC地址的对应是通过ARP协议传播到局域网的每个主机和路由。每一台主机或路由中都有一个ARP cache，用以存储局域网内IP地址和MAC地址如何对应。ARP协议(ARP介于连接层和网络层之间，ARP包需要包裹在一个帧中)的工作方式如下：主机会发出一个ARP包，该ARP包中包含有自己的IP地址和MAC地址。通过ARP包，主机以广播的形式询问局域网上所有的主机和路由：我是IP地址xxxx，我的MAC地址是xxxx，有人知道199.165.146.4的MAC地址吗？拥有该IP地址的主机会回复发出请求的主机：哦，我知道，这个IP地址属于我的一个NIC，它的MAC地址是xxxxxx。由于发送ARP请求的主机采取的是广播形式，并附带有自己的IP地址和MAC地址，其他的主机和路由会同时检查自己的ARP cache，如果不符合，则更新自己的ARP cache。这样，经过几次ARP请求之后，ARP cache会达到稳定。如果局域网上设备发生变动，ARP重复上面过程。(在Linux下，可以使用$arp命令来查看ARP的过程。ARP协议只用于IPv4。IPv6使用Neighbor Discovery Protocol来替代ARP的功能。)我们还有另一个假设，就是每个主机和路由上都已经有了合理的routing table。这个routint table描述了网络的拓扑(topology)结构。如果你了解自己的网络连接，可以手写自己主机的routing table。但是，一个路由器可能有多个出口，所以routing table可能会很长。更重要的是，周围连接的其他路由器可能发生变动(比如新增路由器或者路由器坏掉)，我们就需要routing table能及时将交通导向其他的出口。我们需要一种更加智能的探测周围的网络拓扑结构，并自动生成routing table。我们以北京地铁为例子。如果从机场前往朝阳门，那么可以采取2号航站楼->>三元桥->>东直门->>朝阳门。2号航站楼和朝阳门分别是出发和目的主机。而三元桥和东直门为中间的两个router。如果三元桥->>东直门段因为维修停运，我们需要更改三元桥的routing table，从而给前往朝阳门的乘客(IP包)指示：请走如下路线三元桥->>芍药居。然后依照芍药居的routing table前往朝阳门(芍药居->>东直门->>朝阳门)。一种用来生成routing table的协议是RIP(Routing Information Protocol)。它通过距离来决定routing table，所以属于distance-vector protocol。对于RIP来说，所谓的距离是从出发地到目的地途径的路由器数目(hop number)。比如上面从机场到朝阳门，按照2号航站楼->>三元桥->>东直门->>朝阳门路线，途径两个路由器，距离为2。我们最初可以手动生成三元桥的routing table。随后，根据RIP协议，三元桥向周围的路由器和主机广播自己前往各个IP的距离(比如到机场=0，团结湖=0，国贸=1，望京西=1，建国门=2)。收到RIP包的路由器和主机根据RIP包和自己到发送RIP包的主机的距离，算出自己前往各个IP的距离。东直门与三元桥的距离为1。东直门收到三元桥的RIP包(到机场的距离为0)，那么东直门途径三元桥前往机场的距离为1+0=1。如果东直门自己的RIP记录都比这个远(比如东直门->>芍药居->>三元桥->>机场 = 2)。那么东直门更改自己的routing table：前往机场的交通都发往三元桥而不是芍药居。如果东直门自身的RIP记录并不差，那么东直门保持routing table不变。上述过程在各个点不断重复RIP广播/计算距离/更新routing table的过程，最终所有的主机和路由器都能生成最合理的路径(merge)。(RIP的基本逻辑是：如果A距离B为6，而我距离A为1，那么我途径A到B的距离为7)RIP出于技术上的原因(looping hops)，认为距离超过15的IP不可到达。所以RIP更多用于互联网的一部分(比如整个中国电信的网络)。这样一个互联网的部分往往属于同一个ISP或者有同一个管理机构，所以叫做自治系统(AS,autonomous system)。自治系统内部的主机和路由根据通向外部的边界路由器来和其它的自治系统通信。各个边界路由器之间通过BGP(Border Gateway Protocol)来生成自己前往其它AS的routing table，而自治系统内部则参照边界路由器，使用RIP来决定routing table。BGP的基本工作过程与RIP类似，但在考虑距离的同时，也权衡比如政策、连接性能等其他因素，再决定交通的走向(routing table)。我们一开始讲述了IP包根据routing table进行接力的过程。为了顺利实现接力，我们又进一步深入到ARP和RIP/BGP。这三个协议都协助了IP传输。ARP让每台电脑和路由器知道自己局域网内IP地址和MAC地址的对应关系，从而顺利实现IP包到帧的封装。RIP协议可以生成自治系统内部合理的routing table。BGP协议可以生成自治系统外部的routing table。在整个过程中，我们都将注意力放在了IP包大的传输过程中，而故意忽略一些细节。 而上面的IP接力过程适用于IPv6。【TCP/IP详解】系列教程互联网协议入门 1互联网协议入门 2TCP-IP协议详解(1)网络协议概观TCP-IP协议详解(2) 以太网与WiFi协议TCP-IP协议详解(3) IP/ARP/RIP/BGP协议TCP-IP协议详解(4)IPv4与IPv6地址TCP-IP协议详解(5)IP协议详解TCP-IP协议详解(6) ICMP协议TCP-IP协议详解(7) UDP协议TCP-IP协议详解(8) TCP协议与流通信TCP-IP协议详解(9) TCP连接TCP-IP协议详解(10) TCP滑窗管理TCP-IP协议详解(11) TCP重传TCP-IP协议详解(12) TCP堵塞控制TCP-IP协议详解(13) DNS协议TCP-IP协议详解(14) CIDR与NATTCP-IP协议详解(15) HTTP协议概览 图解TCP-IP协议

Modbus学习的书籍非常少。 刚搜了一下，只有清华出版的《Modbus软件开发实战指南》不错， 应该是Modbus开发方面第一书，很系统很全面，各种代码都是开源的。其实，modbus虽然比较简单，但是如果不注意有很多坑， 特别是寄存器的位数，大小端处理，浮点数，长整数的处理等等。 目前也没有什么其他合适的书籍系统介绍，帮助理解的。清华出版的《Modbus软件开发实战指南》，内容着重讲述如何快速入门并精通Modbus软件开发技术， 适用于初学Modbus通信协议的读者，可以看看，京东或者淘宝都有。作者：大家拿链接：https://www.zhihu.com/question/29056012/answer/150841996 来源：知乎

苦且绕不过去。经过多次放弃之后，我发现在我的职业生涯中，网络这一关无论如何也绕不过去。本来觉得写Java程序时可以依赖别人的库，所以就不用关心这么多底层的技术了，但是到后来才发现，服务数量一多，吞吐量一大，我们关心的不再仅仅是某个Java应用，而是要提升整个集群的性能，这时网络问题就会出现。而且大规模的微服务架构必定要上云、使用VPC网络，这时就必定要考虑双活和灾备，必定要做各个层次的负载均衡，这些都需要网络方面的技术。既然绕不过去，那就必须“啃”下它，于是我就进入了暗无天日的网络协议学习的过程。 见山开路、遇水搭桥，遇到一个知识点攻克一个，再将其写到博客或者笔记里面。有时候要看很多文章和书才能攻克一个知识点，但我还是每天下班抱着网络技术相关的文章和书看，直到将各个零散的知识点串连了起来。后来在定位网络问题的时候，我开始有了自己的思路，这时才感觉算是暂时趟过了这条河。网络协议知识点太多，学完记不住。大部分读者应该都学过计算机网络课程，学的时候感觉并不难，尤其这门课没有公式，更像是文科的东西。学了一大堆东西，也背了一大堆东西，但是最终应付完考试之后，都“还给了老师”每次都感觉自己好像学会了，但实际应用的时候依旧无从下手。虽然很多细节都摸索得差不多了，但是当自己去应用和调试时，才发现还是没有任何思路。比如，当创建出来的虚拟机不能上网时，还是无从下手，学过的很多东西，似乎都用不上。我把这种现象总结为：一看觉得懂，一问就打鼓，一用就糊涂。所以本书使用了“趣谈”这种方式，它可以解决从“入门到放弃”的问题，把晦涩的知识点和一些有趣的故事通过比喻的方式结合起来，这样更容易帮助读者系统、深入地了解网络技术的知识点和大致的工作流程。主要包括的内容和总结三部分给大家进行网络协议的拓展学习，希望大家能够喜欢！！第1 章 通信协议概述1.1 为什么要学习网络协议相信大家都信过通天塔的故事，上帝为了阻止人类联合起来，让人类说不同的语言，人类没法沟通，达不成“协议", 通天塔的计划就失败了。但是千年以后，有一种叫“程序猿”的物种，“敲”着一种这个群体通用的语言，打造着互联网世界的“通天塔”。如今的世界，正是因为互联网，才连接在一起。如果你是程序员，一定看得懂上面这一段文字。这是每一个程序员向计算机世界说“你好，世界”的方式。但是，你不一定知道，这段文字也是一种协议，是人类和计算机沟通的协议，只有通过这种协议，计算机才知道我们想让它做什么。第 2 章 从二层到三层2.1 从物理层到MAC 层：如何在宿舍里自己组网玩联机游戏第一层：物理层路由器的使用发生在第三层上。我们先从第一层物理层开始说。物理层能折腾什么？现在的同学可能想不到，我们当时去学校配电脑的地方买网线，卖网线的师傅都会问，你的网线是要电脑连电脑啊，还是电脑连网口啊？我们要的是电脑连电脑的网线。就是将一根网线的一头插在一台电脑的网卡上，另一头插在另一台电脑的网卡上。但是在当时，用普通的网线这样连接是通不了的，所以水晶头要做交叉线，用的就是所谓的1-3,2-6交叉接法。水晶头的第l、2脚和第3'6脚，分别起着WL发信号的作用。将一端的1号线和3号线、2号线和6号线互换一下位置，就能够在物理层实现两端通信。当然电脑连电脑，除了网线要交叉，还需要配置这两台电脑的IP地址、子网掩码和默认网关。这3个概念前文已经详细描述过了。要想两台电脑能够通信，两台电脑的这3项必须属于一个网络，否则是行不通的。第二层：MAC层你可能已经发现问题了。Hub采取的是广播的模式，如果每一台电脑发出的网络包，宿舍里的每台电脑都能收到，那就麻烦了。这时就需要解决以下几个问题：这个网络包是发给谁的？谁应该接受？大家都在发，会不会产生混乱？有没有谁先发、谁后发的规则？如果发送的时候出现了错误，怎么办这几个问题，都发生在第二层链路层，即MAC层要解决的问题。MAC的全称是MediumAccess Control，即媒体访问控制。控制什么呢？其实就是给媒体发送数据时，控制谁先发、谁后发，防止发生混乱。MAC层解决的是第二个问题，这个问题学名叫多路访问。有很多算法可以解决。就像车管所管理车辆一样，会想出很多办法，比如以下3种方式。方式一：分多个车道。每个车一个车道，你走你的，我走我的。这在计算机网络里叫作信道划分协议。方式二：今天单号出行，明天双号出行，轮着来。这在计算机网络里叫作轮流协议。方式三：不管三七二十一，有事儿先出门，发现特堵，就回去，错过高峰再出门。这在计算机网络里叫作随机接入协议。著名的以太网，用的就是这个协议。第 3 章 重要的传输层3.1 UDP：虽然简单但是可以走制化TCP和UDP有哪些区别一般在面试时，如果面试官问这两个协议的区别是什么，大部分面试者会回答，TCP是面向连接的，UDP是面向无连接的。什么叫面向无连接，什么叫面向无连接呢？在互通之前，面向连接的协议会先建立连接。例如，TCP会进行三次握手来建立连接，而UDP不会。为什么要建立连接呢？TCP可以进行三次握手，UDP可以发三个包，难道不都是建立连接吗？所谓的建立连接，是为了维护客户端和服务端的连接而去建立一定的数据结构，从而维护双方交互的状态，并用这样的数据结构来保证面向连接的特性。例如，TCP提供可靠交付。通过TCP连接传输的数据能够无差错、不丢失、不重复，并且可以按序到达。我们都知道IP包是没有提供任何可靠性保证的，一旦发出去，就像西天取经，走丢了、被妖怪吃了，都只能随它去。TCP号称能做到连接维护程序做的事情，这部分内容在下面两节中会详细描述。而UDP继承了IP包的特性，不保证传输的数据不丢失，也不保证按序到达。再如，TCP是面向字节流的，发送时发的是一个流，没头没尾。但TCP基于的E层发送的可不是一个流，而是一个个的IP包。到TCP层后之所以变成流，是因为TCP自身的状态维护做了相应的处理。而UDP则不一样，它继承了IP包的特性，也是一个一个地发，一个一个地收。在UDP层发送的一个个数据包，还有－个名字叫数据包。另外，TCP是可以进行拥塞控制的。它意识到包已经被丢弃或者网络环境变差时，就会根据情况调整自己的行为，看看是不是数据包发得太快了，要不要发慢点。UDP就不会，应用让我发，我就发，管它洪水滔天。因而TCP是有状态服务，通俗地讲就是它“有脑子”，它精确地知道数据包是否已经被发送出去、是否被接收、发送到哪儿了、应该接收哪个数据包了，错一点儿都不行。而UDP则是无状态服务，通俗地说就是它“没脑子”，天真无邪，发出去就发出去了，后续就不管了。如果说MAC层定义了本地局域网的传输行为，IP层定义了整个网络端到端的传输行为，那么这两层就基本定义了这样的“基因”：网络传输是以包为单位的（网络包在不同的层有不同的叫法，链路层叫帧，网络层叫包，传输层叫段，我们可以笼统地称之为包），包单独传输，自行选路，在不同的设备上进行封装、解封装，不保证到达。基于这个“基因”，生下来的“孩子”UDP就完全继承了这些特性，几乎没有自己的思想。第 4 章 常用的应用层4.1 HTTP：看个新闻原来这么麻烦接下来开始讲应用层的协议。就从最常用的HTTP开始讲起。HTTP几乎是每个人上网用的第一个协议，同时也是很容易被忽略的协议。既然本节要讲看新闻，咱们就先登录某新闻网站http://www.***·com。http//www.***.com是一个URL( Uniform Resource Locator，统一资源、定位符）。之所以叫统一，是因为它是有格式的。HTTP称为协议，www.＊忡.com是一个域名，表示互联网上的一个位置。有的URL会有更详细的位置标识，例如http://www.***·corn/index.html。正是因为URL是统一的，所以当你把这样一个字符串输入到浏览器的地址框里进行搜索的时候，浏览器才能知道如何进行统一处理。第 5 章 陌生的数据中心5.1 DNS：网络世界的地址簿什么是DNS服务器在网络世界，也是一样的。你肯定记得住网站的名称，但是很难记住网站的IP地址，因此也需要一个地址簿，即DNS(Domain Name System，域名系统）服务器。由此可见，DNS服务器在日常生活中多么重要。每个人上网都需要访问它。但是同时，这对它来讲也是非常大的挑战。一旦它出了故障，整个互联网都将瘫痪。另外，上网的人分布在世界各地，如果大家都去同一个地方访问某个服务器，时延将会非常大。因而，DNS服务器一定要设置成高可用、高并发和分布式的。于是，就有了树状的层次结构，如图所示。根DNS服务器：返回顶级域DNS服务器的IP地址。顶级DNS服务器：返回权威DNS服务器的IP地址。权威DNS服务器：返回相应主机的E地址。第 6 章 云计算中的网络6.1 云中网络：自己拿地成本高，购买公寓更灵活我们知道了数据中心里面堆着一大片一大片的机器，相互之间用网络连接。如果机器数量非常多，那么维护起来还是挺麻烦的，有好多不灵活的地方，比如以下几点采购不灵活：如果客户需要一台电脑，那就需要自己采购、上架、插网线、安装操作系统，周期非常长。一旦采购了，一用就得好多年，不能退货，｜哪怕业务不做了，机器还在数据中心里留着。运维不灵活：一旦需要扩容CPU、内存、硬盘，都需要去机房手动弄，非常麻烦。规格不灵活：采购的机器往往动不动几百GB的内存，而每个应用往往可能只需要4核8GB，所以很多应用混合部署在上面，端口可能会相互冲突，容易相互影响。复用不灵活：一台机器，一旦一个用户不用了，另外一个用户，就需要重装操作系统。因为原来的操作系统可能遗留着很多数据，非常麻烦。第 7 章 容器技术中的网络7.1 容器网络：来去自由的日子，不买公寓去合租如果说虚拟机是买公寓，容器则相当于合租，有一定的隔离，但是隔离性没有那么好。云计算解决了基础资源层的弹性伸缩问题，却没有解决由于基础资源层弹性伸缩而带来的PaaS层应用批量、快速部署问题。于是，容器应运而生。容器即Container，而Container的另一个意思是集装箱。其实容器的思想就是要变成软件交付的集装箱。集装箱有两个特点：一是打包，二是标准。在没有集装箱的时代，假设要将货物从A运到B，中间要经过三个码头、换三次船。那么每次都要将货物卸下船来，弄得乱七八糟，然后再搬上船重新摆好，如图7-1所示。在没有集装箱的时候，每次换船，船员们都要在岸上待几天才能干完活。有了尺寸全部都一样的集装箱以后，可以把所有的货物都打包在一起，每次换船的时候，把整个集装箱搬过去就行了，几个小时就能完成，船员换船时间大大缩短，如图7-2所示。这是集装箱的“打包”和“标准”两大特点在生活中的应用。第 8 章 微服务相关协议8.1 基于XML 的SOAP：不要说NBA，请说美国职业篮球联赛ONC RPC存在哪些问题ONCRPC将客户端要发送的参数及服务端要发送的回复都压缩为一个二进制串，这样固然能够解决双方协议约定的问题，但是仍然不方便。首先，需要双方的压缩格式完全一致，一点都不能差。一旦有少许的差错，多一位、少一位或者错一位，都可能造成无法解压缩。当然，我们可以通过提高传输层的可靠性，以及加入校验值等方式来减少传输过程中的差错。其次，协议修改不灵活。除了传输过程中造成的差错，客户端因为业务逻辑的改变添加或者删除了字段，或者服务端添加或者删除了语段而没有及时通知对方，或者线上系统没有及时升级，都会造成解压缩不成功。因而，当业务发生改变，需要多传输或者少传输一些参数时，都需要及时通知对方，并且根据约定好的协议文件重新生成双方的Stub程序。自然，这样操作的灵活性比较差。如果仅仅是沟通的问题还好解决，更难处理的是版本的问题。比如在服务端提供一个服务，参数的格式是版本l的，已经有50个客户端在线上调用了。现在有一个客户端有一个需求，要加一个字段，怎么办呢？这可是一个大工程，所有的客户端都要适配这个，重新写程序，哪怕不需要这个字段的客户端也要加上这个字段，并传输0，这些程序员就很委屈，本来没我什么事儿，为什么让我也忙活？最后，ONCRPC的设计明显是面向函数的，而非面向对象。而当前面向对象的业务逻辑设计与实现方式已经成为主流。这一切的根源就在于压缩。就像平时我们爱用缩略语。如果是篮球爱好者，你直接说NBA(National Basketball Association，美国职业篮球联赛），他马上就知道什么意思，但是如果你和一个大妈说NBA，她可能就听不懂。所以，这种RPC框架只能用于客户端和服务端全由一批人开发的场景，或者至少客户端和服务端的开发人员要密切沟通，相互合作，有大量的共同语言，才能按照既定的协议顺畅地进行工作。XML与SOAP但是，一般情况下，我们做一个服务，都是要提供给陌生人用的，你和客户不会经常沟通，也没有什么共同语言。这时就不适合用缩略语，就像你给别人介绍阳A，你要说美国职业篮球联赛，这样不管他是做什么的，都能听得懂。放到我们的场景中，就是用文本类的方式进行传输。无论哪个客户端获得这个文本，都能够知道它的意义。第 9 章 网络协议知识串讲9.1 知识串讲:用"双*"的故事串起网络协议的碎片知识(上)9.2 知识串讲:用"双*"的故事串起网络协议的碎片知识(中)9.3 知识串讲:用"双*“的故事串起网络协议的碎片知识（下)9.4 搭建—个网络实验环境:授人以鱼不如授人以渔总目录： 好了，本篇文章就分享到这里了，希望这份【趣谈网络协议】对大家有所帮助，我在这里也感谢大家对我的支持????

时间：2018-07-26Q: 什么是网络连接？A:网络连接是传输层定义的概念，在传输层以下只存在网络数据包的相互交换。所谓连接，其实也不是在网络上有一条真实存在的数据通道。只要通信双方在一段时间内持续保持数据包交换，就可以视为双方建立的连接并没有断开。连接的建立是依托于TCP协议的三次握手，一旦连接已经建立完毕，通信双方就可以复用这条虚拟通道进行数据交换。如果连接保持长时间工作一直没有被中断，那么这样的TCP连接就俗称为长连接。Message Queue Telemetry Transport ，中文直译：消息队列遥测传输协议。在MQTT协议被设计出来的年代，还没有物联网这么时髦的词汇，当年叫做遥测设备。MQTT协议真正开始声名鹊起的原因，是其正好恰恰踩中移动互联网发展的节拍，为消息推送场景提供了一个既简便又具有良好扩展性的现成解决方案。http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html可以看出，MQTT对消息头的规定十分精简，固定头部占用空间大小仅为1个字节，一个最小的报文占用的空间也只有两个字节（带一字节的长度标识位）。这也是MQTT协议针对不稳定及带宽低下的网络环境做出的特定设计 - - - -尽可能地节省一切不必要的网络开销。Q：为什么MQTT协议需要心跳报文(PINGREQ, PINGRESP)来维护连接状态，只监控该TCP的连接状态是否可以实现目的？A:TCP数据传输默认的超时时间过长，不符合应用层上细粒度的要求。TCP数据传输超时的情况可分成三种： 服务端断开 、 客户端断开 、 中间网络断开 。在前两种场景下，若断开操作是一方主动发起的，即表示为TCP连接正常结束，双方走四次挥手流程；若程序异常结束，则会触发被动断开事件，通信另一方也能立刻感知到本次连接所打开的 Socket 出现中断异常。唯独中间网络的状态是通信双方不能掌握的。在Linux系统下，TCP的连接超时由内核参数来控制，如果通信中的一方没有得到及时回复，默认会主动再尝试6次。如果还没有得到及时回应，那么其才会认定本次数据超时。连带首次发包与六次重试，Linux系统下这7次发包的超时时间分别为2的0次方至2的6次方，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT协议认为如此长的超时时间对应用层而言粒度太大，因此其在应用层上还单独设计属于自身的心跳响应控制。常见的MQTT连接超时多被设定为 60秒 。扩展知识- TCP的KeepAlive机制： http://hengyunabc.github.io/why-we-need-heartbeat/由通信中的报文标识符(Packet Identifier )传达。Q：仅Publish与Pubrec能保证消息只被投递一次吗？A：业务上可以实现，但MQTT协议并没有如此设计，原因如下：每个消息都会拥有属于自己的报文标识符，但如果需要两次数据交换就实现消息仅只收到一次，就需要通信双方记录下每次使用的报文标识符，并且在处理每一条消息时都需要去重处理，以防消息被重复消费。但MQTT协议最初被设计的工作对象是轻量级物联设备，为此在协议的设计中报文标识符被约定为可重用，以减少对设备性能的消耗，换回的代价不得不使用四次网络数据交换，才能确保消息正好被消费一次。Q：两个不同客户端在发布与订阅同一Topic下的消息时，都可以提出通信Qos要求，此时以哪项为基准？A：伪命题，故意在分享时埋下坑，等人来踩。两个不同客户端的通信是需要 Broker 进行中转，而不是直连。因此，通信中存在两个不同的会话，双方的Qos要求仅仅作用于它们与 Broker 之间的会话，最终的Qos基准只会向最低要求方看齐。例：遗嘱消息的正确使用方式可参考此篇文章： https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament虽然可以借助Retain Message实现绑定一条消息至某个Topic，以达到消息的暂时保留目的。但首先Retain Message并不是为存储场景而设计的，再次MQTT协议并没有对消息的持久化作出规定，也就是说Broker重启后，现有保留消息也将丢失。Q：两种特殊消息的使用场景？A：遗嘱消息，多用于客户端间获取互相之间异常断线的消息通知；保留消息，可保存最近一条广播通知，多用于公告栏信息的发布。Eclipse Mosquitto ：MQTT协议的最小集实现有 EMQ ,HiveMQ ,RabbitMQ MQTT Adapter 等。Qos=2 消息保障的网络I/O次数过多，如果不是必需，尽少在程序里使用此类消息。毕竟当初其设计的目的是为了减少设备的性能占用，但若应用场景并不是物联网，而是用于手机、电脑或浏览器端等现在已不缺性能的设备上，最好在报文体中，使用UUID生成全局唯一的消息ID，然后自行在业务解析中判断此报文是否被消费过。或者，业务方在处理消息时保证其被消费的幂等性，也可消除重复消息对系统带来的影响。正如MQTT协议并没有依赖TCP连接状态，自己在应用层协议上实现心跳报文来控制连接状态，业务方作为MQTT协议的使用者，也不要完全依赖协议的工作状态，而是依托MQTT协议建立属于业务本身的信息汇报机制，以加强系统的稳健性。Retain Message 可视为客户端主动拉取的行为。如果业务系统采用HTTP+MQTT双协议描述业务过程，主动拉取的操作也可使用HTTP请求替代。作为一个长连接型的应用，上线前需要根据业务量级，评估对操作系统端口数与文件描述符的占用要求，以防服务器资源被打满。在服务端的配置文件和客户端的连接参数中，都拥有 max_inflight_messages 此项配置，来维护 Qos=1 or 2 消息是否被成功消费的状态。MQTT 最初被设计为物联网级的通信协议，因此此参数的默认配额较小（大多数情况下被限制到10至20）。但如果将MQTT协议应用至手机、PC或Web端的推送场景时，硬件性能已不在是瓶颈，在实际使用中推荐把此参数调大。Mosquitto提供Bridge功能，需要我们自己配置。Bridge 意为桥接，当我们把两台Broker桥接在一起时，只需要修改一台Broker的配置，填上另一台Broker的运行地址。前一台Broker将作为客户端发布与订阅后一台Broker的所有Topic，实现消息互通的目的。桥接带来的问题有以下几点：我的建议：Websockets协议被设计的目的是为浏览器提供一个全双工的通信协议，方便实现消息推送功能。在Websockets协议被设计出来前，受限于HTTP协议的一问一答模型，消息的推送只能靠轮询来实现，在资源消耗与时效性保障上，均难以达到令人满意的效果。Websockets协议复用了HTTP协议的头部信息，告知浏览器接下来的操作将触发协议升级，然后通信双方继续复用HTTP的Header，但报文内容已转变为双方均接受的新协议的格式。Websockets协议改进了网页浏览中的消息推送的方式，因此被广泛应用在聊天、支付通知等实时性要求比较高的场合下。MQTT协议重点在于消息队列的实现，其对消息投递的方式作出约定，并提供一些额外的通信保障。MQTT可采取原生的TCP实现，也有基于Websockets的实现版本。当然后者在网络字节的利用率上，不如前者那么精简。但浏览器端无法直接使用TCP协议，所以就只能基于Websockets协议开发。不过基于Websockets的应用也有方便之处：一是证书不需要额外配置，直接与网站共用一套基础设施；二是可使用Nginx等工具管理流量，与普通HTTP流量可共用一套配置方法。MQTT非常适合入门，原因如下：实际的应用场景远比理想中的复杂，无法一招走遍天下，必须做好取舍。MQTT协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。