这里写目录标题
- UDP
- UDP的基本特点
- UDP协议报文格式
- TCP
- TCP协议报文格式
- TCP特点
- 可靠传输实现机制
- 确认应答
- 超时重传
- 数据丢了
- 应答报文丢了
- 小结
UDP
UDP的基本特点
- 无连接
- 不可靠传输
- 面向数据报
- 全双工
UDP协议报文格式
2个字节有效范围(无符号): 0 ~ 65535(2^16 - 1).
2个字节有效范围(有符号): -32768(-2 ^ 15) ~ 32767(2 ^ 15 - 1)
通过CRC校验检查数据是否在网络传输中出错了.
1 ~ 1024范围的端口号被系统赋予了特定的含义,一般不建议我们使用…
在网络传输过程中,收到外界干扰(光信号/电信号/电磁波),数据可能会出错!!!
可能会出现比特翻转(0->1/1->0).
这个时候,检验和就可以确认一下,这个数据是否是个错误的数据.
UDP的校验和是怎么实现的?
使用了一种简单粗暴的CRC校验算法(循环冗余校验和).
把UDP数据报的每个字节都依次进行累加,保存到2个字节的变量中.
可能会溢出,但是无所谓,所有字节都加了一遍,最终就得到了校验和…
传输数据时,把原始数据和检验和一起传递过去,接收方会计算新的校验和,
如果新旧校验和相同,就可以视为传输的数据是正确的.
TCP
TCP协议报文格式
TCP特点
- 有连接
- 可靠传输
- 面向字节流
- 全双工
可靠传输实现机制
确认应答
当ack = 0时,这是一个普通报文,此时只有32位序号是有效的.
当ack = 1时,这是一个应答报文,此时32位序号和32位确认序号都是有效的.
确认应答是TCP保证可靠性的最核心机制!!
超时重传也是TCP可靠性机制的有效补充.
超时重传
丢包是在网络上很容易出现的,发送一个数据,然后丢了.
超时重传相当于针对确认应答进行的重要补充.
丢包分为两种:
1. 发的数据丢了.
2. 应答报文丢了.
数据丢了
当是发送的数据丢了时,就可使用万能大法(重启),丢包实际上是一个概率问题,假设丢包概率是4%,传输成功概率是96%.那么我重传,再此传输失败的概率是0.16%.此时传输失败就变小了.
超时重传的轮次也不是无限的,当达到一定次数后,就会尝试"重置"TCP连接,当"RST"为1时,
表示一个复位报文,重新建立连接.
那么有没有连续重传依然丢包呢,大概率是网断了,不管咋传,都是丢的.
应答报文丢了
当应答报文丢了时,这个场景下,我们会多次发送相同的数据,此时就要进行去重.
直接使用TCP的序号作为判定依据,TCP会在内核中,给每个socket对象都安排一个内存空间,
相当于一个队列,称为"接收缓冲区",收到的数据都会被放到接收缓冲区中,并按照序号排好顺序
(也就解决了后发先至问题),这里也是一个生产者消费者模型,当数据被读走后,就可以从队列中删除掉了.
这里还有一个问题,假设前面的数据报文丢了,后面的数据先到了是会先把后到的数据放到队列中,还是会继续等待前面的数据?
一定是继续等待前面的数据.
小结
本篇博客总结UDP和TCP的相关知识,及TCP可靠性的实现机制,下篇博客将会总结三次握手,四次挥手方面的知识,希望在本篇博客有收获的小伙伴多多支持!