通信协议设计(通信协议设计规范)

用C语言肯定可以实现！要先在接收端的单片机处理设定好，就是你收到了什么数据，要判定数据是否正确，要是正确的话，就要回复什么数据；不正确就不响应。你可以看看485通信的例子。
如果是自己定义数据格式，一发一收。发送方拼数据包，接收方解析数据包。不知道你串口通讯还是网络通讯？

比如： 我发送一个数据如下：BYTE SendData[5];SendData[0] = 0XAA;SendData[1] = 0XBB;SendData[2] = 0XFF;SendData[3] = 0XBB;SendData[4] = 0XAA;协议格式：AA代表存储数据FF。接收端接到SendData发送出的数据后，对接到的数据进行分析。比如接收变量为BYTE Recv[5];数据接收的代码就不给你写了。反正现在你接收的数据都在变量Recv中。然后进行判断分析数据。if(Recv[0] == 0xAA){//进行存储Recv[2]中FF值。} 说白了。你定的协议只是一个标识，你接到数据后取标识位进行判断，这样才知道接收过来的数据是干什么的。要存储到哪。你给客户端回什么样的数据。
体现在 发送 接收 数据 的 格式上

计算机技术和通信技术的融合是目前通信协议软件的必由之路。大的通信公司往往是通过招收大量的计算机专业人才来解决这个问题，在同一个开发团队中，通信专家负责通信协议的设计和分析，而计算机专家负责协议软件的实现。这对于我们这样的高校团队就比较困难了，只能通过让同学在学习通信知识的同时，加强计算机软件方面的训练： 1）要熟悉实时操作系统系统的知识。协议软件的各种功能都是建立在操作系统的基础上的，特别是在通信软件中多个任务同时工作，所以操作系统中的线程管理、线程间通信就变得特别重要。 2）要熟悉计算机网络的知识。核心网已经全都采用基于IP的架构，不了解计算机网络的知识，寸步难行。 3）要熟悉软件工程的知识。通信软件体系庞大，必须通过团队开发来解决，而这都需要软件工程的思想、技术和工具来支撑。 4）要熟悉编程语言的知识。软件无线电和软交换的兴起，使得大量原本采用硬件实现的功能现在都要通过软件实现，软件开发在系统中的作用愈来愈突出，所以熟练地掌握一门甚至多门编程语言已经变得非常必须。 5）要熟悉各种开源工具软件。开源文化的兴起，给研究工作带来了新的机遇，我们可以不必事事从头做起，但是开源也带来新挑战，你必须熟悉开源工具的各种工具，必须接收开源社区自由开发所带来的工具繁多，文档匮乏和零碎所带来各种问题。 6）要学习数据结构的课程。通信软件中充斥着各种队列、图、树之类的描述，如果不熟悉数据结构，对于这些复杂的对象就无从下手。 7）要学习编译原理的知识。当然，用到这一步就比较高深了。通信软件的工作量往往是巨大的，为了提高效率，许多大公司都或多或少地采用一些自动工具，而编译原理就是开发这些自动工具的基础。我们项目中就曾经自己开发过ASN.1的编译生成工具。 想想一个通信的研究生要在两年半的时间中，除了学习通信知识，还要学习这么多的计算机知识，再要完成研究工作，的确是一项艰巨的任务。

网络上有大量关于 HTTPS 的技术文章，但是大部分文章都在以“英译汉”的方式，把 TLS 的握手流程讲出来。 本文将尝试从“如何实现”的角度，通过从零开始设计一个安全的通信协议的方式，帮助读者加快对信息安全的理解。HTTP 面临的三个安全问题分别是：eavesdropping（窃听）,tampering（篡改）,message forgery（信息伪造）。浏览器和服务器进行信息传递时，会通过第三方转发信息。此时，信息安全面临三个问题：为了防止第三方伪造信息，我们很容易的想到通过 签名 的方式。讲解签名之前，我们需要先对非对称加密方式以及消息摘要：（Digital Digest）有所了解。对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。常用的非对称加密方式有:RSA、ECC。具体的原理，这里不进行展开。我们只需要了解用于签名的非对称加密需要满足的两个特性即可：非对称加密通常对等待加密的信息长度有要求，所以，我们一般只对消息摘要加密。消息摘要：（Digital Digest）又称为指纹（Finger Print）。可以通过单向哈希(one-way hash)函数，为不定长度的信息生成一个固定长度的摘要。有了以上知识，我们来看一下数字签名是如何进行的？签名：通对某一份数据进行单向哈希，缩短等待加密信息的长度=》单项哈希通过私钥对信息摘要进行加密运算并生成签名，表示我认可了这份数据（只有我拥有私钥，第三方难以伪造）=》签名验签：通过公钥解析签名对数据进行单向哈希判等我们可以模拟一下会话的握手阶段的通信流程：浏览器：hello服务器：服务器公钥 + encrypt(服务器公钥，服务器私钥)浏览器：encrypt(hash(信息)，服务器公钥) + 信息服务器：encrypt(hash(信息)，服务器私钥) + 信息上面的通信方式是不是安全多了？且慢，如果服务器返回公钥时，被第三方拦截，然后替换为第三方的公钥，我们该如何怎么办？考虑到把所有网站的公钥提前存储到浏览器中并不现实（数量巨大，并且新增公钥、撤销公钥都极为不便）。我们可以提前浏览器内置一份或多份公钥（根证书），然后再把流程升级一下：会话的握手阶段的通信流程：浏览器：hello服务器：服务器公钥 + encrypt(服务器公钥，第三方私钥)浏览器：encrypt(hash(信息)，服务器公钥) + 信息服务器：encrypt(hash(信息)，服务器私钥) + 信息但是，签名在解决信息伪造和篡改的同时又引入了另外一个问题：性能消耗。虽然只需要对摘要信息进行签名，但是，它依然给服务器带来了非常巨大的运算压力。一般情况下，签名操作会导致服务器的处理速度变为原来的万分之一甚至更低（根据算法的不同，实际情况可能会有数量级的变化）。并且，它还面临一个非常巨大安全问题：窃听。第三方仍然可以看到通信内容。既然非对称加密对性能影响巨大，剩下的唯一方案是对称加密。因为服务器需要和数量众多的浏览器进行通信，所以，每条通信用到的对称加密密钥都应该是不同的。否则，浏览器和服务器之间的通信依然会被第三方解密。引入对称加密后，就可以再次升级通信流程：会话的握手阶段的通信流程：浏览器：hello服务器：服务器公钥 + encrypt(服务器公钥，第三方私钥) + 第一个随机数浏览器：encrypt(第二个随机数，服务器公钥)双方根据PRF算法生成一个对称加密的密钥并用于之后的通信：浏览器：encrypt(hash(信息)，对称密钥) +encrypt(信息，对称密钥)服务器：encrypt(hash(信息)，对称密钥) +encrypt(信息，对称密钥)这种双方各自生成一个随机数的方式可以应对浏览器或者服务器单方面出现漏洞（随机数不随机）的情况。与此同时，在一次会话的建立中，服务器只需要解析一次就可以完成整个会话。 安全故事:1996年，研究人员就发现了网景浏览器1.1的伪随机数发生器仅仅利用了三个参数：当天的时间，进程ID和父进程ID。在1996年，利用当时的机器仅需要25秒钟的时间就可以破解一个SSL通信

物联网需要黑莓