做实验网站,给wordpress添加引导页,微信个人公众号如何开通,许昌企业网站建设【Java网络编程03】网络原理进阶
1. UDP协议
1.1 基本介绍
我们首先再来回顾UDP协议的基本特点#xff1a;
无连接的不可靠传输的面向数据报的全双工的
既然谈到数据报#xff0c;我们就来看一下UDP数据报的格式#xff1a; UDP数据报分为报头和载荷部分#xff0c;其…【Java网络编程03】网络原理进阶
1. UDP协议
1.1 基本介绍
我们首先再来回顾UDP协议的基本特点
无连接的不可靠传输的面向数据报的全双工的
既然谈到数据报我们就来看一下UDP数据报的格式 UDP数据报分为报头和载荷部分其中载荷部分就是应用层报文报头固定8字节分为以下四个部分
源端口标识发送方位于源主机的哪个应用程序目的端口标识接收方位于目的主机的哪个应用程序数据报长度报头载荷部分的总长度最大为64KB检验和checksum用于检验传送过程中是否出现差错
1.2 相关机制
1.2.1 UDP检验和
校验和checksum由于网络传输过程中数据以光/电/电磁波信号进行传输因此难免遇到外界环境干扰导致数据出现差错造成比特0-1翻转。因此引入检验和checksum可以在一定程度上进行差错检验 **UDP校验和**UDP所采取的检验和的方式就是将报文中的所有16比特的和进行反码运算期间遇到的任何溢出都要回卷计算方式这里省略。。。 **校验过程**首先在发送方会进行一次检验和算法过程然后将结果value1存放到UDP数据报的检验和字段接收方会使用相同的算法处理接收到的数据再次得到一个结果记做value2此时比对value1与value2是否一致如果不一致那就证明一定出现了比特翻转直接丢弃该数据包即可但是检验和存在一个缺点就是如果有多于一位比特的比特差错此时有可能得到的校验和结果是一致的因此不一定能证明数据100%正确。 补充知识业界还有更高精度的校验和算法例如md5和sha1算法这里简单介绍md5的特点 定长无论原始数据如何生成的md5值一定是固定长度的常见的有16位、32位、64位版本分散只要原始数据变化一丁点生成的md5值就会大相径庭这样的特性也决定了它可以被用作字符串hash算法。不可逆对于A原始数据Bmd5值的过程是不可逆的原理上无法做到根据md5值反推原始数据这个特性也决定它可以用作加密算法。很多网站所谓md5解密本质是采取暴力打表的方式计算各种原始值的md4值并存放到数据库的过程。 2. TCP协议
2.1 报文格式
TCP协议段的格式如下
2.2 可靠传输机制
再来回顾TCP协议的特点
有连接可靠传输的面向字节流的全双工
其中有连接、面向字节流、全双工这几个特性我们都在TCP套接字编程中可以体会到但是体现不出可靠传输机制因此我们就来探究TCP实现可靠传输的网络原理 可靠传输再来强调一下可靠传输的含义并不是说使用TCP协议那么发送方发送的数据包能够百分百到达接收方此处的可靠性只是退而求其次利用相关机制可以让发送方知道发送的数据包是否成功到达接收方就认为是可靠传输了
2.2.1 确认应答机制核心
在保证TCP协议的可靠传输机制中最为核心的就是 **确认-应答机制 **了
Step1接收方需要根据接收到的数据包发回响应 此时我们引入应答报文就可以让发送方知道发送报文是否到达接收方了但是往往发送方发送的不止一个TCP段接下来让我们发送多个报文段看看
Step2发送方发送多个TCP报文段 好像似乎也没什么问题呀事实上如果数据包都是按序到达的是没有什么问题的但是现实中的网络情况十分错综复杂因此很有可能导致后发先至的情况。因此事实上很有可能出现的是下面的时序情况 此时难以区分第一个收到和第二个收到到底针对的是哪个数据包所回复的了。因此TCP又引入了 **序号与确认号 **的机制来匹配响应报文和发送报文之间的对应关系
Step3引入序号与确认序号机制 此时就算是出现后发先至的情况发送方也能够清楚的知晓响应报文是匹配哪个发送报文的了 注意 以上实际上是简化版本的模型真实的TCP的情况要更加复杂一些实际上TCP是面向字节流的而不是以上所展示的对一个一个数据包进行编号事实上TCP针对每一个字节进行编号
假设发送报文中载荷部分中一共有1000个字节编号为1001-2000由于序号是连续的因此只需要在TCP报头序号填上第一个字节的编号1001即可也可以通过计算得出最后一个字节的编号。 应答报文中的确认序号值是按照接收到的最后一个字节的序号1进行设定的因此如果应答报文中的确认序号为1001具有两种含义1、1001号以前的数据都已经接收完毕2、发送方接下来可以发送1001开始往后的数据了。
2.2.2 超时重传机制
超时重传机制这是对于确认应答机制的补充。如果一切顺利的情况下通过应答报文ACK报文就可以让发送方知晓当前数据是否成功被接收方接收。但是网络实际情况是错综复杂的很有可能出现丢包现象如果数据包没有发送到接收到也就不存在什么应答报文了这个情况下就需要超时重传机制了。本质上是设置一个等待时间阈值如果超过等待时间仍未收到应答报文就会触发重传数据包行为。 丢包现象由于网络中主机A与主机B并不是直连的中间会经过多个路由器、交换机等网络设备转发如果一个交换机/路由器在某个时刻负载量激增短时间内有多个数据包需要经过该设备进行转发超过了这个设备所能承受的最大转发量此时该网络设备就会有选择性的丢弃一部分数据包维持网络传输速率。 超时重传两种场景 超时重传可能出现以下两种情况
情况一发送数据包丢包 这种情况接收方本身就没有接收到数据因此进行超时重传理所应当是没有任何问题的
情况二应答报文丢包 这种情况属于接收方已经接收到数据但是由于应答报文丢包了导致发送方超时重传这种情况仔细想想其实是有问题的如果是转账业务呢那么接收方接收两次不就需要扣款两次吗事实上设计TCP的大佬们已经帮我们处理好了就是通过TCP的 **接收缓冲区 解决的 TCP接收缓冲区 TCP的socket在内核中存在接收缓冲区一段内存空间发送方发来的数据需要先保存在接收缓冲区当中然后应用程序调用read方法读取缓冲区的数据这里的读操作实际上针对的是缓冲区中的数据。其中接收缓冲区最重要的核心功能就是会进行去重**操作那么如何判断重复数据呢核心判断依据就是数据的序号。
当数据还在接收缓冲区时还没有被应用程序read读走那么就会拿着新到达的数据序号与接收缓冲区中的数据序号依次进行比对如果有一样的那就是有重复了直接丢弃。如果数据已经被应用程序从缓冲区读走了但是应用程序读取缓冲区的数据是按照序号的先后顺序读取即先读取序号小的再读取序号大的的因此如果新到达的数据序号为3000并且此时应用程序读取到的最后的数据序号为4000就可以证明4000以前的数据都被读走了因此可以判断出3000序号数据重复直接丢弃。
总结而言就是TCP的接收缓冲区实现了去重数据包的功能并且该去重机制还额外完成了排序数据包的工作。 超时重传策略 超时确实会导致发送方重传数据包但是重传不是无限制次数的重传重传也是有一定策略的
重传次数是有上限的重传到一定程度还没有收到ACK应答报文此时就会重置连接如果重置也失败就直接放弃连接重传的超时时间间隔并不是固定不变的随着重传次数的增多超时时间阈值也会增大重传频率变得更低
