Linux：传输层(1) -- UDP协议

Li&ShuaiShuai

于 2024-07-24 10:17:23 发布

阅读量393

点赞数 13

文章标签： linux 服务器运维

本文链接：https://blog.csdn.net/qq_52568001/article/details/140653359

版权

1. 端口号

同一台主机的不同端口号(Port)标记了主机上不同的进程，如下图所示：

在 TCP/IP 协议中 , 用 " 源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信 ( 可以通过netstat -n查看 );

1.1 端口号划分

0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的.
1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的

1.2 知名端口号

ssh服务器, 使用22端口
ftp服务器, 使用21端口
telnet服务器, 使用23端口
http服务器, 使用80端口
https服务器, 使用443
执行下面的命令, 可以看到知名端口号：cat /etc/services

那么此时就会有 两个问题：

一个端口号是否能被多个进程bind？-- 默认情况下，一个端口号在同一时间不能被多个进程绑定到同一个IP地址，当然会有写特殊的处理。
一个进程能否bind、多个端口号？-- 是可以的，一个进程可以创建多个套接字，每个套接字绑定到不同的端口上。

2. netstat

netstat是一个用来查看网络状态的重要工具.

语法：netstat [选项]

功能：查看网络状态

常用选项：

n 拒绝显示别名，能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服務状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项，默认不显示LISTEN相关

pidof

在查看服务器的进程 id 时非常方便 .

语法： pidof [ 进程名 ]

功能：通过进程名 , 查看进程 id

3. UDP协议

3.1 格式

UDP采用固定长度的报头 -- 前8字节
16位UDP长度：表示整个数据报(报头+有效载荷)的长度
16位UDP校验和：发送前OS会按照算法计算出数据报的有效载荷并填充到报头中，在接收方接收到数据报以后，会以同样的算法计算校验和与包头中的对比，检验和不一致则直接丢弃

对报头的理解：OS层面定制的一种协议，其实就是一种结构化的数据对象，如下所示(这里只是示例，并不代表真实的结构体也一定如此)：

//UDP头部，总长度8字节  
typedef struct _udp_hdr  
{  
    unsigned short src_port; //远端口号  
    unsigned short dst_port; //目的端口号  
    unsigned short uhl;      //udp头部长度  
    unsigned short chk_sum;  //16位udp检验和  
}udp_hdr;

3.2 UDP的特点

无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
面向数据报: 不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并

3.3 接受/发送缓冲区

我们在用的网络的IO接口并不是发送和接受和接口，实际上是一种拷贝的接口，将数据拷贝到缓冲区，再用OS决定何时发送和接收。

调用read/recv时，实际上是从传输层协议的接收缓冲区中读取(拷贝)数据；调用write/send时，时间上是将数据经过封装拷贝到了传输层协议的发送缓冲区，此时应用层的任务就结束了，由OS将数据刷新到网络中。就像下面这个图一样：

传输层的UDP/TCP协议都是全双工的，发送/接收数据不使用相同的公共缓冲区，在发送数据的同时也可以接受别人发来的数据。

注：

UDP是没有真正意义的发送给缓冲区的(调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作)，它具有接收缓冲区。
我们注意到 , UDP 协议首部中有一个 16位的最大长度 . 也就是说一个 UDP能传输的数据最大长度是64K(包含UDP 部 )。然而64K 在当今的互联网环境下 , 是一个非常小的数字。如果我们需要传输的数据超过64K, 就需要在应用层手动的分包 , 多次发送 , 并在接收端手动拼装。