标签：Hash 请求 1.2 可信 传输 num 数据 sendNum
数据可信传输
整体设计
功能设计概要
1、网络通信防篡改机制
通过指针Hash+原发的方式进行网络通信。
1.1、总体设计
1.2、放篡改机制方案
1.2.1、协同验证
1.2.1.1、数据传输格式
采用http请求方式，其中指针保存请求头部，原文保存请求体。
1.2.1.1、数据防篡改校验
接收方接收到数据后，通过发送方提供的hash算法，将原文数据运算得出Hash，将得到的Hash与发送方提供的请求头提供的Hash做对比，如果相等，则接收方入库，如果不相等，接受发响应数据为“失败”，发送方接受到请求方的响应数据后，其中响应数据为“失败”。这时发送方将失败数据存在错误日志中，并报警。通过线下方式排查失败原因（网络原因或恶意攻击）。
1.2.1.2、总体设计
1.2.2、握手验证
1.2.2.1、总体设计
1.2.2.2、第一步发送方发送数据【请求】
发送方发送数据到接收方，其中数据格式为：Hash+sendNum+num+原文。
Hash值、sendNum 值和num值保存在请求的请求头中，原文保存在请求体中。
其中sendNum=1，num=1
1.2.2.3、第二步接受方接受到数据后，将数据重新发送给发送方。【请求】
数据格式为：Hash+sendNum+resNum+num+原文。
Hash值、sendNum 值、num值和resNum值保存在请求的请求头中，原文保存在请求体中。
其中sendNum=1，resNum=1，num=2。
发送方接收到请求方的数据后用原文去验证Hash值是否正确，如果正确则正常响应，如果不正确则异常响应，并将异常数据保存在错误日志中，同时系统报警。
1.2.2.4、第三步发送方响应。【响应】
经过第二步的请求和验证后，如果发送方验证成功，则正常响应，如果验证失败，则异常响应，接受收到异常响应后对数据不做任何处理，同时发送方将异常数据保存在错误日志系统中，同时触发系统报警。
其中响应数据格式为：Hash+sendNum+resNum+num+result
Hash值、sendNum 值、num值和resNum值保存在请求的请求头中，result值保存在请求体中。
sendNum=2，resNum=1，num=3，result=ture/false。
1.2.3、两种方案对比
| 验证维度 | 协同验证 | 握手验证 |
| 性能 | 快 | 慢 |
| 安全级别 | 低 | 高 |
Hash数据可信回溯
无论在任何分系统中，都应该有保存接受原始数据的日志（软件开发规范）。比如，一条数据在经历几个分系统中，突然数据发生该表，但不确定是在那个分系统中发生改变，同时也不确定原始数据是什么，那么怎么能找回原始数据，并同时知道在那个分系统中出现的问题？
- 通过区块链的保存数据的机制和区块链本身的数据安全策略。可以通过Hash可以快速找会原始数据。
- 找回原始数据后，可以通过数据流转的定位，去分系统的各个日志中通过Hash值定位每个分系统的日志数据。快速定位到其中那个分系统篡改了原始数据。前提条件是通过区块链系统得到原始信息。
标签：Hash,请求,1.2,可信,传输,num,数据,sendNum 来源： https://blog.csdn.net/wangyongxun1983/article/details/114535925
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。