通信协议设计(通信协议设计案例与实现)

物联网需要黑莓

这个可以从osi的七层模型角度来看。tcp和udp是传输层的协议，通常是用ip协议为他们的承载层。而在上面有 表示层 会话层 应用层。这最上面的三层可以统称为应用层，在网络数据传输的过程中可以把它看成是数据date。http属于应用层的协议，只有下四层的网络通了，才能有上层应用的成功使用。所谓的通信协议都处于不同的网络层次，他们的顺序都是由数据封装的顺序来定的。就像你 寄送包裹时 填地址，先填省市区县镇街道一样。

我和其他很多人以前分析过文曲星串口的协议 emsky.net上有文章，你去找找几年前的帖子
毕设？

网络上有大量关于 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通信

比如： 我发送一个数据如下：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值。} 说白了。你定的协议只是一个标识，你接到数据后取标识位进行判断，这样才知道接收过来的数据是干什么的。要存储到哪。你给客户端回什么样的数据。
体现在 发送 接收 数据 的 格式上