网络通信之校验

简介: 这是一个可选的选项,并不是所有的系统都对UDP数据包加以检验和数据(相对TCP协议的必须来说),但是RFC中标准要求,发送端应该计算检验和。   UDP检验和 覆盖UDP协议头和数据,这和IP的检验和是不同的,IP协议的检验和只是覆盖IP数据头,并不覆盖所有的数据。

这是一个可选的选项,并不是所有的系统都对UDP数据包加以检验和数据(相对TCP协议的必须来说),但是RFC中标准要求,发送端应该计算检验和。

  UDP检验和 覆盖UDP协议头和数据,这和IP的检验和是不同的,IP协议的检验和只是覆盖IP数据头,并不覆盖所有的数据。

TCP校验:首部和数据的校验和;

UDP校验:ipv4中首部和数据的校验和,但是是可选的;ipv6必选;

IP校验:首部校验和;

TCP是基于流的;什么是流呢?

UDP是基于数据包;

校验方法:二进制求反码相加即得和;

TCP半关闭;

 Nagle算法:

  由于Tcp中的微小分组(比如:41Byte的分组:20Byte的IP头,20Byte的TCP头和1个Byte的数据)在广域网上回增加拥塞的可能,Nagle算法就是优化该问题的;

该算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组,在该分组的确认到达之前不能发送其他的小分组;相反,TCP收集这些少量的分组,并在确认到来时以一个分组的方式发出去;

  该算法的优越之处在于它是自适应的:确认到达得越快,数据也就发送的越快;

 tcp的成块数据流:

  正常的数据流通常是采用“隔一个报文确认”的策略;就是说:s端收到报文段1,先不进行ack;而是等到收到报文段2之后,再ack回应客户端;

滑动窗口协议:(窗口的大小是不断变化的; )

  在c端保存,并受s端和c端共同控制;

假设先将待发送的字节编号:1、2、3、4、5、6、7、8、9、0、10、11、12;由三次握手建立连接之后,得到s端的tcp的buf大小即滑动窗口的初始化大小(假设为6Byte);

a:此时滑动窗口的左边沿是:1号,右边沿是:6号;此时发送1、2、3、号之后,滑动窗口位置不变,

b:s端向c端确认ack=4;win=6;此时窗口左边移动到7号处,右边移动到:4+6即10处;

c:接着:第二段报文发送4、5、6、7号,此时窗口不动,因为只有再收到s端的ack之后才改变位置、大小;

d:s端确认第二段报文,ack=8,win=3;说明s端的tcp缓存只有一个byte空间;滑动窗口左边移动到8号处,右边移动到3+8即11号处;

特殊情况:

    1、如果c端收到一个滑动窗口左边沿向左边移动的ack;则认为该ack是一个重复的ack;直接丢弃;(这是因为,滑动窗口的左边是由s端确认收到序号控制,因此不可能向左边移动)

    2、如果左边沿到达右边沿,则称其为一个零窗口,此时发送方不能够发送任何数据;

PUSH标志:

    在每一个tcp例子中,我们都看到了PUSH标志,其用途是c方使用该标志通知s方将所有接收到的数据全部提交给接收进程;这里的数据 包括:与PUSH一起传送的数据以及接收方tcp以及为接收进程接收到的其他数据;

  慢启动:(slow start)

    慢启动为c方tcp增加了另一个窗口:拥塞窗口(congestion  window,简写:cwnd);

  1、当与s端建立tcp连接时,cwnd被初始化为1个报文端;此后没收到一个s端的ack,cwnd就增加一个报文段(cwnd以字节为单位,但是慢启动以报文段大小为单位进行增加);

  2、c端取拥塞窗口与通告窗口中的最小值作为发送上限;

    拥塞窗口是c端式用的流量控制,通过窗口是s端的流量控制;

  具体的内容“创建tcp超时和重传机制”

 

    

 

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
Cloud Native NoSQL 关系型数据库
数据传输DTS校验问题之校验报错如何解决
数据传输服务(DTS)是一项专注于数据迁移和同步的云服务,在使用过程中可能遇到多种问题,本合集精选常见的DTS数据传输问题及其答疑解惑,以助用户顺利实现数据流转。
293 0
|
4月前
|
缓存
流量控制&可靠传输机制&停止-等待协议
流量控制&可靠传输机制&停止-等待协议
29 0
|
4月前
|
网络协议 网络性能优化
【传输层】概述、复用分用、UDP详解、UDP校验
【传输层】概述、复用分用、UDP详解、UDP校验
35 1
|
9月前
CRC校验-基于MODBUS协议实现源码
CRC校验-基于MODBUS协议实现源码
61 0
|
10月前
|
JSON 前端开发 JavaScript
前端数据传输失败
前端数据传输失败
100 0
|
网络协议
用户数据报协议(UDP)是干什么的?底层原理是什么?
用户数据报协议(UDP)是干什么的?底层原理是什么?
179 0
|
前端开发 安全 Java
前端校验和后端校验的区别和优缺点
前端校验和后端校验的区别和优缺点
724 0
前端校验和后端校验的区别和优缺点
|
算法 Ubuntu Java
数据包完整性校验总结
为了保证分发的数据包的一致性,常常需要增加数据包校验码,这样可以减少因为传递过程中造成的数据包不能使用问题,比如jar包的__invalid distance code__问题。在开始讨论数据包校验码生成方法前,先了解一下基本概念。 # 核心技术 ## 哈希 哈希是一种不可逆的映射,可以将数据经过哈希算法计算得到一个哈希值,而无法再将该哈希值反映射得到原始的数据。一般来说,不同的数据得到的哈
2707 0
|
JavaScript 前端开发 Go
【CDN】通过crc64校验数据传输的完整性
数据在客户端和服务器之间传输时有可能会出错。OSS现在支持对各种方式上传的Object返回其crc64值,客户端可以和本地计算的crc64值做对比,从而完成数据完整性的验证。
696 0
【CDN】通过crc64校验数据传输的完整性