本文主要是介绍【linux网络(四)】传输层协议详解(上)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
💓博主CSDN主页:杭电码农-NEO💓
⏩专栏分类:Linux从入门到精通⏪
🚚代码仓库:NEO的学习日记🚚
🌹关注我🫵带你学更多操作系统知识
🔝🔝
Linux网络
- 1. 前言
- 2. UDP协议报文详解
- 3. TCP协议的报文格式
- 4. TCP的确认应答机制
- 5. 16位窗口大小的用处
- 6. TCP的超时重传机制
- 7. 总结
1. 前言
本篇文章将核心从应用层转移到传输层, 传输层绕不开的两座大山: TCP和UDP. 由于UDP是一种简洁的协议,所以主要讲本篇文章的核心放在TCP协议上!
注: 如果对HTTP协议了解不深刻,建议先阅读这篇文章
HTTP详解
本章重点:
本篇文章会讲解UDP协议的报文格式, 深度解析UDP协议是怎样进行解包/封装的. 之后会讲解TCP的报文格式, 以及TCP协议中为了保证可靠性和效率而采用的方法.
任务:
- 对于如何协议都要解决的问题: 如何分离(解包), 如何交互(封装)
- 理解协议的报文本身
- 详细的了解具体的报文字段
2. UDP协议报文详解
直接上图:
UDP协议的报头是固定大小的,八字节. 所以解包也很简单: 提取前八个字节的数据, 解析16位UDP长度. 拿到长度后截断整个报文数据!
UDP的报头实际上就是结构体类型:
struct udp_hdr
{uint32_t src_port:16;uint32_t dst_port:16;uint32_t udp_len:16;uint32_t udp_check:16;
}
UDP传输过程类似于寄信, 无连接, 不可靠, 面向数据报, 这个在前面的文章有讲解过. 注意UDP的最大数据是2^16-1. 也就是64K. 这里经常会在面试中被问到.
3. TCP协议的报文格式
直接上图:
一眼看去, TCP协议确实比UDP要复杂的多, TCP协议的报头并不是定长的, 你可能会发现它除了选项和数据的长度是定长的20字节. 但是它的选项的长度是不定的. 在前20字节中有一个叫4位首部长度的字段. 它代表了报头一共有多大.
范围是: 20~60字节
TCP报头的其他字段数据, 比如: 序号, 确认序号, 窗口大小, 6位标志位等. 就是TCP用来保证它的效率和可靠性时需要使用到的字段
4. TCP的确认应答机制
讲个小例子帮助大家理解:
我们看电视剧中的特种兵用对讲机进行通信时, 比如张三对李四说: A点发现敌人, 张三说了这句话后并不确定李四是否听见这句话. 所以此时李四往往会回复一句: 收到. 此时张三才能确信李四收到了刚才的信息
确认应答机制(ACK机制):
为了保证可靠性
确认应答机制就是在说, A端向B端发送一段数据后, B端必须返回给A端一条信息, 代表B端确实收到了这条消息. 那么在上面的TCP协议中, 有一种类型的字段叫六位标记位. 其中之一的ACK标记位就用于确认应答
除此之外, 确认应答不仅仅会用到ACK标记位, 还会用到确认序号. 那么什么是确认序号? 先来了解TCP对数据的结构划分: TCP将发送缓冲区的每个字节的数据都进行了编号. 即为序列号(将发送缓冲区想象为字符串,编号就是字符串下标).
比如主机A给主机B发送了1000字节的数据, 那么这个TCP包中的序号就为1000. 当B主机收到TCP包后, 会给A主机发送确认应答, 并且会将确认序号设置为1001, 代表1001以前的数据我都收到了. 可以从1001个字节开始给我发数据了
同理,要是B主机没有给A发送1001确认序号,而是直接发送了2001. 证明2001以前的数据都收到了, 包括1~1000的
TCP的报头中包含序号和确认序号, 这是因为TCP是全双工的, 一端既可以发数据同时也能接受数据. 并且,系统调用recv,read并不是从网络从将数据读取到内存, 而是将接受缓冲区的数据读取上来. 同理, send和write函数也是讲数据写入发送缓冲区, 而不是直接写入网络
对确认应答的深刻理解:
确认应答机制只能保证历史发的数据都被接收了, 但是最新的数据对方是否接收了是未知数. 比如B端向A端发送ACK应答后, B端怎么在这里插入图片描述
知道A端有没有收到这条消息? 答案是B端是不知道的!
5. 16位窗口大小的用处
相信聪明的你也思考过, 要是客户端无脑一直给服务器发数据, 把服务器的接受缓冲区塞满了咋办? 是的, TCP协议当然也考虑到了这一点, 于是专门设置了16位窗口大小
用处:
16位窗口大小表示对端接受缓冲区的剩余空间大小, 当客户端收到的窗口大小太小时, 就会减缓发送数据的速度, 留给服务器喘息的机会. 所以发包的一方需要填写窗口大小, 而收包的一方需要解析对端的窗口大小. 当然你可能会问这些工作是谁做的? 答案是操作系统帮我们做的
6. TCP的超时重传机制
上面讲到, 每一次收到数据都会给对方发一个ACK应答表明我收到了. 那么如果我确实没有收到呢?应该怎么办? TCP协议当然也考虑到了这一点
超时重传机制:
主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B,如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
这里还有一种情况: 主机A没收到B的确认应答:
聪明的你可能又会问了, 超过一定时间会重发, 那么这一定时间具体是多久?
为了在任何环境下都能高性能的通信, 会动态计算超时时间.
- Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时
- 时间都是500ms的整数倍.
- 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
- 如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
- 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接.
7. 总结
TCP协议会有很多方案来保证自身数据传输时的可靠性和效率性, 当然, 今天学习的机制都是和可靠性有关的. 与效率性有关的方案会放在传输层协议详解(下)中讲解. 博主最近在秋招总复习, 所以会更新的比较快. 休息一下, 马上回来!
这篇关于【linux网络(四)】传输层协议详解(上)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
