📝个人主页🌹:Eternity._
⏩收录专栏⏪:Linux “ 登神长阶 ”
🌹🌹期待您的关注 🌹🌹
❀ 传输层UDP/TCP协议
- 📒端口号
- 📜UDP协议
- UDP协议端格式
- UDP的特点
- UDP的缓冲区
- 📝TCP协议
- TCP协议段格式
- 确认应答和TCP发送数据的模式
- 📖总结
前言:传输层协议,特别是用户数据报协议(UDP)和传输控制协议(TCP),是网络通信中最为基础也最为重要的部分。它们不仅决定了数据的传输方式,还影响着数据的可靠性、顺序性和实时性。对于想要深入了解互联网运行机制、掌握网络通信技术的朋友们来说,学习UDP/TCP协议无疑是必经之路。
UDP协议以其简单、高效的特点,在网络通信中发挥着不可替代的作用。它无需建立连接,直接发送数据包,这种“尽最大努力交付”的传输方式,使得UDP在实时性要求较高的应用场景中表现出色。例如,视频直播、在线游戏等领域,UDP都扮演着重要的角色。
TCP协议以其可靠、有序的数据传输特性,赢得了广泛的认可和应用。它通过建立连接、确认数据到达、重传丢失数据等一系列机制,确保了数据的完整性和顺序性。这使得TCP在需要高可靠性数据传输的场景中,如文件传输、网页浏览等,成为首选的协议。
本问旨在帮助广大读者深入了解UDP/TCP协议的原理和应用。我们将从协议的基本概念入手,逐步深入协议的内部机制,解析协议的报文结构。
📒端口号
在之前的学习中,我们简单的了解了一下端口号,这次让我们来重新对端口号有个新的认识。
在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信
端口号范围划分:
0 - 1023
:知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的1024 - 65535
:操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的
知名端口号:
- ssh服务器:22端口
- ftp服务器:21端口
- telnet服务器:23端口
- http服务器:80端口
- https服务器:443端口
cat /etc/services // 查看知名端口号
注意:
- 一个进程可以
bind多个端口号
- 一个端口号只能
被一个进程bind
netstat:
- netstat是一个用来查看网络状态的重要工具
- 语法:
netstat [选项]
- 功能: 查看网络状态
- 常用选项:
n: 拒绝显示别名,能显示数字的全部转化成数字
l: 仅列出有在 Listen (监听) 的服務状态
p: 显示建立相关链接的程序名
t: (tcp)仅显示tcp相关选项
u: (udp)仅显示udp相关选项
a: (all)显示所有选项,默认不显示LISTEN相关
pidof:
- 在查看服务器的进程id时非常方便.
- 语法: pidof [进程名]
- 功能: 通过进程名, 查看进程id
📜UDP协议
UDP(User Datagram Protocol,用户数据报协议)是一种面向无连接的传输层协议,它是TCP/IP协议簇的一部分。
UDP协议端格式
- 16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度
- 如果校验和出错, 就会直接丢弃
UDP报头是固定的8字节,我们直接提取前8字节的数据,解析16位UDP长度,然后截断得到报文数据
UDP的特点
UDP传输的过程类似于寄信
- 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接
- 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息
- 面向数据报: 不能够灵活的控制读写数据的次数和数量
面向数据报:
- 应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并
- 如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节
UDP的缓冲区
- UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作
- UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的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的socket既能读, 也能写, 这个概念叫做
全双工
UDP使用注意事项:
- UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部),然而64K在当今的互联网环境下, 64K是一个非常小的数字。
- 如果我们需要传输的数据超过64K , 分包, 多次发送并在接收端手动拼装
📝TCP协议
TCP(Transmission Control Protocol)即传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议。
我们在使用TCP协议时,只需要考虑两个问题:
- 报头和有效载荷之间分离的问题
- 有效载荷向上交付的问题
TCP协议段格式
4位首部长度:
TCP协议段格式与UDP协议段格式相比来看是稍微复杂些的,TCP的报头并没有像UDP那样有固定的长度,出去选项报头的定长是20字节,报头的真实大小需要通过4位首部长度来确定,而首部长度只有4位,但它的取值绝对不是
0000->1111(0->15)
,必然是要乘上它的单位,不然长度远远不够,其实首部长度的单位是:4字节
它的真实长度也就是[0->60]
,所以选项最多是40个字节!
16位窗口大小:
我们在发送和接收数据时,接收缓冲区是有大小限制,如果超出限制将会被直接丢弃。所以我们要进行流量控制。所谓流量控制就是发送方要知道接收方的接受能力,而我们的16位窗口大小就是用来流量控制的字段,里面填的就是剩余空间的大小
确认应答和TCP发送数据的模式
确认应答:
为了更好地理解TCP确认应答机制的工作原理,我们先来看一个简单的例子:
- 假设你在邮寄一个包裹给朋友小明
- 小明收到包裹后,给你打电话确认:“我收到了你的包裹!”
- 你知道小明收到了包裹,你就不再担心是否丢失。如果你没有收到小明的确认电话,你会重新寄一次包裹,确保包裹能送到他手中
只有对方回应了你的话,你才能确认对方一定接收到了你的信息
TCP发送数据的模式:
32位序号:
接收方报头会根据此序号进行排序,因为乱序是不可靠的发送方式
32位确认序号:
历史上自己发送的哪些报头被对方接收了
我们一般在确认报文时,都会顺带给出回应,既是数据又是应答,所以我们需要对序号和确认序号同时使用,所以这两个必须是分开的值。
6位标志位:
- URG: 紧急指针是否有效
- ACK: 确认号是否有效
- PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
- FIN: 通知对方, 本端要关闭了 我们称携带FIN标识的为结束报文段
URG:紧急指针是否有效
16位紧急指针:
紧急数据在有效载荷中的偏移量
PSH:尽快进行数据的向上交付
RST:对方要求重新建立连接
缓冲区:
📖总结
在探索传输层UDP(用户数据报协议)与TCP(传输控制协议)协议段格式的旅程即将告一段落之际,我们不禁对这两个协议在现代网络通信中所扮演的基石角色有了更深的理解与敬畏。
- UDP以其无连接、快速传输和最小开销的特点,成为对实时性要求高、能容忍一定数据丢失的应用场景的首选。
- 而TCP,则凭借其面向连接、可靠传输、流量控制和错误检测与纠正的机制,构建了互联网通信的坚固基石,确保了数据在复杂多变的网络环境中准确无误地送达。
让我们带着这份收获,继续在技术的海洋中遨游,不断探索未知,用我们的智慧与热情,为构建更加高效、安全、可靠的互联网世界贡献力量。在传输层协议的引领下,让我们携手前行,共创网络技术的辉煌未来。
希望本文能够为你提供有益的参考和启示,让我们一起在编程的道路上不断前行!
谢谢大家支持本篇到这里就结束了,祝大家天天开心!