Linux网络基础2之UDP协议

 (｡･∀･)ﾉﾞ嗨！你好这里是ky233的主页：这里是ky233的主页，欢迎光临~https://blog.csdn.net/ky233?type=blog

点个关注不迷路⌯'▾'⌯

目录

一、传输层

1.端口号

2.端口号范围划分

3.认识知名端口号

4.有三个问题

5.netstat

6.pidof

二、UDP协议

1.UDP协议端格式

1.几乎任何协议都要首先解决两个问题:

1.那么是如何分离或封装的呢？

2.那么是如何交付的呢？

2.理解一下udp/tcp报文 -- 理解报文本身

3.UDP的特点

4.面向数据报

5.如何理解如send\recvfron\write\read等io类接口呢？

6.UDP的缓冲区

7.全双工与半双工

8.UDP使用注意事项

9.基于UDP的应用层协议

---

一、传输层

负责数据能够从发送端传输接收端

1.端口号

端口号(Port)标识了一个主机上进行通信的不同的应用程序;

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

2.端口号范围划分

0 - 1023: 知名端口号, HTTP, FTP, SSH 等这些广为使用的应用层协议, 他们的端口号都是固定的.

1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的

3.认识知名端口号

有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号

• ssh服务器, 使用22端口
• ftp服务器, 使用21端口
• telnet服务器, 使用23端口
• http服务器, 使用80端口
• https服务器, 使用443 

4.有三个问题

1.一个进程是否可以绑定多个端口号

这个是可以的，甚至可以创建多个端口号，用不同的端口号都是可以的，如用一组端口号通信，另一组对服务器发起控制等等

2.一个端口号是否可以被多个进程绑定

这是不能的，原则上是不能的，端口号和进程的关系是为了通过端口号这种方式来快速的找到这个进程，所以端口号到进程必须是唯一的

3.进程不是有pid吗为什么还要用端口号呢？

这是不是因为所有进程都需要对外提供网络服务，pid是OS的，端口号是网络的，这样可以进行解耦。

5.netstat

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

语法：netstat [选项]

功能：查看网络状态

n 拒绝显示别名，能显示数字的全部转化成数字

l 仅列出有在 Listen (监听) 的服務状态

p 显示建立相关链接的程序名

t (tcp)仅显示tcp相关选项

u (udp)仅显示udp相关选项

a (all)显示所有选项，默认不显示LISTEN相关

6.pidof

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

语法：pidof [进程名]

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

配合xargs可以直接关掉进程，xargs是把标准输入的内容转化成命令行参数，像kill这样的命令，是要在命令行参数里面输出的，就可以用这个

二、UDP协议

1.UDP协议端格式

a.如何分离(封装)b.如何交付

首先我们传输层的到数据要往应用层上传，这时候我们的端口号就要起效了

1.几乎任何协议都要首先解决两个问题:

1.那么是如何分离或封装的呢？

这采用的是定长报头，前八个字节是报头，后面是有效载荷，就是这样

2.那么是如何交付的呢？

获取报头之后，根据报头中的16位端口号，进行向上交付，因为进程band了端口号！

• 16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度;
• 如果校验和出错, 就会直接丢弃;

为什么我们在应用层编写代码的时候，我每一次写端口号的时候，都喜欢uint16_t？

因为协议用的端口号是16位的

udp如何正确的提取整个完整报文的？

固定长度的报头，报头中有16位udp长度，那么获取到之后固定-8，就是有效载荷也就是数据的长度

所以udp是具有将报文一个一个正确接受的能力的！这对应的就是udp是面向数据报的

2.理解一下udp/tcp报文 -- 理解报文本身

所谓报头在内核里面其实就是一个结构体

 当我们想把数据从应用层传输到内核层的时候，内核层就会有报头结构体生成，第一步实现把数据放到内核层，第二部在把内核报头结构体拷贝到数据前面，这就叫做封装报头

而此时，报头加上数据就是一个udp报文

3.UDP的特点

UDP传输的过程类似于寄信

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

4.面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;

用UDP传输100个字节的数据:如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;

5.如何理解如send\recvfron\write\read等io类接口呢？

你可能以为，调用这些接口是在网络中进行收发，但其实这些函数本质是拷贝函数

其实是把对应的用户层数据拷贝到操作系统的缓冲区中，然后这些函数会返回

在接收数据时，也是从内核的缓冲区，拷贝到用户数据的。

交给了内核层，这是由传输层的协议提供的。

数据什么时候发，发多少，这些都是OS关心的，也就是传输层的协议帮我们提供并关心的

6.UDP的缓冲区

• UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后 续的传输动作;
• UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果 缓冲区满了, 再到达的UDP数据就会被丢弃;

7.全双工与半双工

UDP的套接字既能读, 也能写, 这个概念叫做全双工

既能读又能写就是全双工

半双工也可以读也可以写，但是不能同时干就是半双工

8.UDP使用注意事项

我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首 部). 然而64K在当今的互联网环境下, 是一个非常小的数字.

如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

9.基于UDP的应用层协议

• NFS: 网络文件系统
• TFTP: 简单文件传输协议
• DHCP: 动态主机配置协议
• BOOTP: 启动协议(用于无盘设备启动)
• DNS: 域名解析协议