Linux基础：linux系统下UDP的详解
一、UDP、linux基础介绍
套接字：就是IP地址+端口号
IP地址：4字节
端口号：2字节，也就是说范围是0~65535
端口号分为：知名端口号、一些固定的端口号
知名端口号
0–1023：http，ssh，ftp，telnet等一些协议端口号都是固定的，对于操作系统来说是不能对其进行分配的
一些固定的端口号
ssh服务器，使用22端口
ftp服务器，使用21端口
telnet服务器，使用23端口
http服务器，使用80端口
https服务器，使用443端口
操作系统动态分配的端口号
客户端服务器的端口号，这个范围的端口号操作系统可以对其进行分配
查看端口号
less /etc/services //就可以查看Linux下所有的端口号了
IP地址的理解：
IP地址用来标识一个主机
端口号的理解：
端口号就是用来告诉操作系统要对于那一个进程进行操作，也就是说端口号就是用来标识一个进程
一个端口号只可被一个进程所占用，但是一个进程可以拥有多个端口号，也就是进程和端口号是一对多的关系
当我们写一个程序使用端口号的时候，要避开这些知名端口号
【问题】
（1）一个进程是否可以bind多个端口号呢？
可以，因为一个进程可以打开多个文件描述符，而每一个文件描述符都对应着一个端口号，所以一个进程可以绑定多个端口号
（2）一个端口号是否可以被多个进程bind？
不可以
如果一个进程先绑定一个端口号，然后再fork一个子进程，这样的话就实现了多个进程绑定一个端口号，但是不同的进程绑定同一个端口号是不可以的
TIME_WAIT状态，服务器不能立即重启也说明不用进程不能同时绑定同一个端口号
（3）多个进程可以监听同一个端口号吗？
可以。监听之前要进行创建套接字->绑定ip::端口号->监听。我们可以在bind之前使用setsockopt函数，设置套接字选项，其中就包括REUSEADDR这个选项，表明多个进程可以复用bind函数中指定的地址和端口号
所以套接字就可以准确的标识一台主机上的一个进程，从而完成计算机之间的通信（主机A的某个进程与主机B上的另一个进程进行通信
）
网络字节序转换：
对于数据在网络中传输的时候有着自己遵循的传输规则大端传输
对于主机上的数据的传输序列有着两种：
大端：即高位字节序放在低地址上
小端：即低位字节序放在低地址上
传输：均是先传输低地址上的数据然后是高地址上的数据
所以对于主机上的数据传输的时候传输到网络上的时候有可能导致数据错误（例如主机上是小端的时候，所以需要进行转换）
转换函数：
uint32_t htonl(uint32_t hostlong); uint16_t htons(uint16 hostshort); uint32_t ntohl(uint32_t netlong); uint16_t ntohs(uint16_t netshort); h：表示主机host name n：表示网络network l：表示4字节long s：表示2字节short
地址转换函数：
字符串转化为in_addr in_addr_t inet_addr(const char* strptr) in_addr转化为字符串 char* inet_ntoa(struct in_addr inaddr)
具有不可重入性，也就是不可多次调用，因为该函数自己在静态区开辟一块空间用来存放IP地址字符串的
UDP协议：
UDP协议端格式
- 16为UDP长度，表示整个数据报（UDP首部+UDP数据）的最大长度（64KB）
- 检验和：如果校验和出错，就会直接丢弃（检验的是把首部和数据部分一起都检验）
- 校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还要在重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检验是否出错。
- 源端口号：在对方回信是选用，不需要时可用全0
- 目的端口号：在终点交付报时必须要用到
- 长度：UDP用户数据报的长度，其最小值是8（仅有首部）
UDP的特点：
- 无连接：直到对端的IP和端口号就直接进行传输，不需要建立连接
- 不可靠：没有确认机制，没有重传机制；因为没有网络故障该段无法发送到对方，UDP协议层也不会给应用层返回任何错误信息
- 面向数据报：不能够灵活的控制读写数据的次数和数量
- 控制选项较少，数据传输过程中延迟小，数据传输效率高
- 面向数据报
- 应用层交给UDP多长的报文，UDP原样发送，既不会拆分也不会合并
例：用UDP传输100个字节的数据
如果发送端调用一次sendto，发送100个字节。那么接收端也必须调用对应的一次recvfrom，接收100字节；而不能循环调用10次recvfrom，每次发送10个字节
UDP的缓存区
UDP没有发送缓存区，调用sendto之后会直接交给内核，由内核·将数据传给网络层协议进行后续的传输动作。因为UDP是不面向连接的，所以没有重发机制，也就不需要发送缓存区将已经发送的数据保存下来为了发送失败进行重传做准备
UDP具有接收缓存区。但是这个接收缓存区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；如果缓存区满了，在到达的UDP数据就会被丢弃
UDP的Socket既能读，也能写，全双工
UDP的使用注意事项：
UDP协议首部中有一个16位的最大长度，也就是说一个UDP能传输的数据的最大长度是64K（包含UDP首部）。但是64K在当今的互联网环境下，是一个非常小的数字。如果我们需要传输的数据超过64K，就需要应用层手动的分包，多次发送，并在接收端拼装
UDP首部中校验和的计算方法有些特殊。在计算校验和时，要在UDP用户数据报之前增加12个字节的伪首部
伪首部既不向下传输也不想上递送，而仅仅是为了计算校验和
与IP数据报的校验和只检验IP数据报的首部不同，UDP的校验和是把首部和数据部分一起都检验
伪首部：
基于UDP的应用层的协议：
- NFS：网络文件系统
- TFTP：简单文件传输文件协议
- DHCP：动态主机配置协议
- DNS：域名解析协议
用UDP实现可靠传输？
- 参考TCP的可靠性机制，在应用层实现类似的逻辑
- 引用序列号，保证数据顺序
- 引入确认应答，确保对端收到了数据
- 引入超时重传，如果隔一段时间没有应答，就重发数据
二、对于各函数使用
1、对于socket函数的使用
1.1 函数原型
int socket(int domain, int type, int protocol);
domain: 领域
AF_INET：IPV4
AF_INET6：IPV6
type: 类型
SOCK_STREAM
SOCK_DGARM
protocol: 协议
1.2 函数的作用
在通信领域中创建一个未被绑定的套接字，并且返回一个文件描述符，可以在以后对套接字进行操作的函数调用中使用
2、 对于bind函数的使用
2.1 函数原型
int bind(int socket, const struct sockaddr* address, socklen_t address_len);
2.2. 函数的作用
该函数采用先前创建好的套接字来对于IP地址以及端口号进行绑定，也就是表示该套接字可以标识出在一个网络中一台确定的主机并且主机中的进程
3、 对于recvfrom函数的使用
3.1 函数原型
ssize_t recvfrom(int socket, void* restrict buffer, size_t length,
int flags, struct sockaddr* restrict address,
socklen_t* restrict address_len);
socket：要接受那一个套接字的消息
buffer：用来接收消息的缓存区
length：接收的消息的长度
flags：类型
address：空指针或者存储发送信息的sockaddr结构
addless_len：指定地址参数指向的sockaddr结构的长度
3.2 函数的作用
用来接收从socket套接字发送来的消息。该套接字的sockaddr结构也知道
4、 对于sendto函数的使用
4.1 函数原型
ssize_t recvfrom(int socket, const void* message, size_t length,
int flags, const struct sockaddr* dest_addr,
socklen_t* dest_len);
4.2 函数的作用
该函数是socket套接字从dest_addr出接收消息
三、 扩展知识
1、 netstat
netstat是一个用来监控TCP/IP网络非重要工具
语法：netstat [选项]
功能：查看网络状态
选项：
-a，显示所有连线的Socket
-c，持续列出网络状态
-n，直接使用ip地址，而不通过域名服务器，也就是显示为数字
-l，显示监控中的服务器的Socket，仅列出监听（Listen）状态下的Socket
-p，显示正在使用Socket的程序的识别码和名称(PID/Program name)
-t，显示TCP传输协议的连线状况
-u，显示UDP传输协议的连线状况
-v，显示指令执行过程
-V，显示版本信息
-x，显示UNIX传输协议的连线状况
-s，显示网络工作信息统计表
-h，在线帮助
2、 pidof
查看服务器进程id是非常方面
语法：pisdof [进程名]
功能：通过进程名，查看进程id
到此这篇关于Linux基础：linux系统下UDP的详解的文章就介绍到这了,更多相关linux内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
