校验和

原 UDP协议的详细解析 2018年12月26日 17:16:34 一只小菜鸟z 阅读数 6220 更多 分类专栏： 计算机网络-传输层 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/aa1928992772/article/details/85240358 UDP数据报 一、UDP的概述（User Datagram Protocol，用户数据报协议） UDP是传输层的协议，功能即为在IP的数据报服务之上增加了最基本的服务：复用和分用以及差错检测。 UDP提供不可靠服务，具有TCP所没有的优势： UDP无连接，时间上不存在建立连接需要的时延。空间上，TCP需要在端系统中维护连接状态，需要一定的开销。此连接装入包括接收和发送缓存，拥塞控制参数和序号与确认号的参数。UCP不维护连接状态，也不跟踪这些参数，开销小。空间和时间上都具有优势。 举个例子： DNS如果运行在TCP之上而不是UDP，那么DNS的速度将会慢很多。 HTTP使用TCP而不是UDP，是因为对于基于文本数据的Web网页来说，可靠性很重要。 同一种专用应用服务器在支持UDP时，一定能支持更多的活动客户机。 分组首部开销小**，TCP首部20字节，UDP首部8字节。 UDP没有拥塞控制

在查询hive中的数据时，报如下错误： 错误原因： 从提示用可以看出是：CheckSumException ，即 校验和异常， 出现该错误的 原因 ：存储的数据与hadoop系统为该数据生成的校核和数据不一致导致错误，说白了，就是你存储的数据出现问题了，如：人为手动更改了数据，网络不稳定以及硬件损坏等因素导致的。本博客是我自己为了复现这个错误， 特地更改 了hive上的源数据。 如上图，我是通过notepad++更改了源数据，不是通过hive命令更改了数据，导致crc文件并没有做相应的更新，当我再次在hive使用select查询语句查询源数据的时候，就报了 校验和 异常。说明源数据遭到了损坏。此时，为了能查询到数据，直接将crc文件删除，再使用select查询语句即可查询到响应的数据。 为了详细了解hadoop的校验原理，参考下面的博客： 博客链接： https://blog.csdn.net/lb812913059/article/details/79718303 博客标题：Hadoop数据完整性与CheckSum校验原理 博客原文： 一、HDFS数据完整性 用户肯定都希望系统在存储和处理数据时，数据不会有任何丢失或损坏。但是，受网络不稳定、硬件损坏等因素，IO操作过程中难免会出现数据丢失或脏数据，难免会出现数据丢失或脏数据，数据传输的量越大，出现错误的概率就越高。

第一章：就是介绍一下Hadoop的历史及发展过程。 第二章：MapReduce 从一个统计气象学的例子，来引出MapReduce的写法，对比了一下新旧API的区别以及不同。新的API主要采用的是虚类而不是接口的方式来提供服务。讨论了数据流：Hadoop的存储，以及工作原理，还有Combiner函数的使用。最后，谈到了使用不同语言来实现mapreduce功能（Streaming， Pipes）， 原因是因为Hadoop使用了Unix标准作为流作为输入输出和应用程序之间的接口 ，所以我们可以使用任何编程语言通过标准输入输出来写MapReduce程序。 第三章：Hadoop分布式文件系统 首先讲解了文件系统的概念，以及Hadoop文件系统的特点：超大文件、流式数据访问、商用硬件、不满足低延迟数据访问、不适合大量小文件、不支持多写入以及任意修改等等。然后又介绍了块存储的特点。利用块存储的原理的优点是： 一个文件的大小可以大于网络中任意一个磁盘的容量 使用抽象块而非整个文件作为存储单元大大简化了存储子系统的设计 然后又继续讲解了namenode和datanode这两个老生常谈的话题，你需要知道这两个node的功能是什么。需要注意的是namenode的 安全机制 ，因为它事关整个文件系统的生死。关于Hadoop文件系统HDFS的高可用性的实现，有很多文章都探讨过了，大家可以去网上搜搜。

版本控制 　　版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 版本控制系统（VCS）作用 　　1 回溯文件到之前的某个状态 　　2 回退整个项目到之前的某个时间点 　　3 比较文件的变化细节 　　4 恢复项目中修改过的文件到原先的样子 　　。。。 本地版本控制系统 　　采用某种简单的数据库来记录文件的历次更新差异。 集中化的版本控制系统（CVCS） 　　有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 　　坏处：中央服务器的单点故障：宕机、中心数据库所在的磁盘发生损坏。这些故障会导致无法工作或者丢失所有历史更新记录。 分布式版本控制系统（DVCS） 　　客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。每一次的克隆操作，实际上都是一次对代码仓库的完整备份。 Git的特点 　　1 速度 　　2 简单的设计 　　3 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 　　4 完全分布式 　　5 有能力高效管理类似Linux内核一样的超大规模项目（速度和数据量） Git的思想和工作原理 　　Git把数据看做是对小型文件系统的一组快照。每次提交更新，或在Git中保存项目状态时

1 报文与实体 如果将HTTP对内容的传输比喻成实际生活中一些货物的运输的化。那HTTP报文就相当于是用于运输货物的“箱子”，而实体内容则是我们真正需要运输的“货物”。所以实体也就是被封装在了报文当中。 现实货物运输中，一般箱子上也会有一些描述信息，用于对运输的货物进行描述说明。HTTP报文中也是一样，也会有相应的实体首部，对实体内容进行描述说明，以便我们的接收方能正确处理实体内容。在HTTP/1.1中常用的实体首部如下所示： Content-Type：实体内容的MIME类型 Content-Length：实体内容的长度或大小 Content-Language：传输的实体内容最匹配的语言类型 Content-Encoding：对实体数据所做的变换（如：压缩） Content-Location：实体数据的一个备用位置 Content-Range：将实体分为几个部分进行传输的时候，说明该部分实体是属于哪个部分 Content-MD5：内容数据的校验和 Last-Modified：所传输内容最近一次创建或者修改时间 Expires：数据的失效时间 Allow：该资源所允许的请求方法（如：GET, HEAD等） ETag：该份实体数据的唯一验证码 Cache-Control：实体内容缓存有关的控制 2 实体大小（长度）控制 Content-Length首部指示出报文中实体主体的字节大小

过滤器的作用 通过上面所述的两篇我们，我们已经能够实现请求的路由功能，所以我们的微服务应用提供的接口就可以通过统一的API网关入口被客户端访问到了。但是，每个客户端用户请求微服务应用提供的接口时，它们的访问权限往往都需要有一定的限制，系统并不会将所有的微服务接口都对它们开放。然而，目前的服务路由并没有限制权限这样的功能，所有请求都会被毫无保留地转发到具体的应用并返回结果，为了实现对客户端请求的安全校验和权限控制，最简单和粗暴的方法就是为每个微服务应用都实现一套用于校验签名和鉴别权限的过滤器或拦截器。不过，这样的做法并不可取，它会增加日后的系统维护难度，因为同一个系统中的各种校验逻辑很多情况下都是大致相同或类似的，这样的实现方式会使得相似的校验逻辑代码被分散到了各个微服务中去，冗余代码的出现是我们不希望看到的。所以，比较好的做法是将这些校验逻辑剥离出去，构建出一个独立的鉴权服务。在完成了剥离之后，有不少开发者会直接在微服务应用中通过调用鉴权服务来实现校验，但是这样的做法仅仅只是解决了鉴权逻辑的分离，并没有在本质上将这部分不属于业余的逻辑拆分出原有的微服务应用，冗余的拦截器或过滤器依然会存在。 对于这样的问题，更好的做法是通过前置的网关服务来完成这些非业务性质的校验。由于网关服务的加入，外部客户端访问我们的系统已经有了统一入口，既然这些校验与具体业务无关

转载于：https://blog.csdn.net/liuchenxia8/article/details/80428157 TCP协议传输的特点主要就是面向字节流、传输可靠、面向连接。 TCP保证数据可靠传输的方式主要有以下六点：校验和、确认应答与序列号、超时重传、连接管理、流量控制、拥塞控制。 1、校验和 在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。发送方在发送数据之前计算校验和，并进行校验和的填充。接收方收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。 注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致， 数据不一定传输成功。 2、确认应答与序列号 序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。 确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。 序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。 3、超时重传 简单理解就是发送方在发送完数据后等待一个时间

Action 类: • Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 • Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去 实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。 线程模式: • Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。 • Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题） Servlet 依赖: • Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。 • Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2

TCP协议传输的特点主要就是面向字节流、传输可靠、面向连接。这篇博客，我们就重点讨论一下TCP协议如何确保传输的可靠性的。 确保传输可靠性的方式 TCP协议保证数据传输可靠性的方式主要有 ： 校验和 序列号 确认应答 超时重传 连接管理 流量控制 拥塞控制 校验和 计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。 发送方：在发送数据之前计算检验和，并进行校验和的填充。 接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。 注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。 确认应答与序列号 序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。 确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。 　　序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。 超时重传 　　在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后

Embedded的世界里，Hex文件是可以烧录到MCU中，被MCU执行的一种文件格式。 整个文件以行为单位，每行以冒号开头，内容全部为16进制码（以ASCII码形式显示）。 // 一个简单的HEX文件内容 :020000040008F2 :1000080080318B1E0828092820280B1D0C280D2854 :10000400FF00A0E314209FE5001092E5011092E5A3 :1002B00026854128FD576308F502294535A0975743 :00000001FF Hex文件里每一行都可以理解为该结构： Record mark(:) - 数据长度Length(1Byte) - 地址Load offset(2Byte) - 数据类型Record type(1Byte) - 数据INFO or DATA(nByte) - 校验码CHKSUM(1Byte) 可以按照如下的方式进行拆分来分析其中的内容，例如 “:1000080080318B1E0828092820280B1D0C280D2854” 可以被看作“0x10 0x00 0x08 0x00 0x80 0x31 0x8B 0x1E 0x08 0x28 0x09 0x28 0x20 0x28 0x0B 0x1D 0x0C 0x28 0x0D 0x28 0x54” 第一个字节