【网络】UDP协议——传输层、端口号、UDP协议、UDP协议端格式、UDP的特点、UDP的缓冲区、UDP使用注意事项

Linux网络

1. 传输层

  传输层：是 OSI 模型和 TCP/IP 模型中的重要层次，位于网络层之上、应用层之下。其主要职责是为不同进程之间提供端到端的（发送端到接收端）、可靠或不可靠的数据传输服务，实现复用和分用的功能，对网络层提供的服务进行增强。

  传输层协议：常见的传输层协议有 TCP（传输控制协议）和 UDP（用户数据报协议）。

  

1.1 端口号

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

  它是一个 16 位的整数，取值范围是 0 到 65535。端口号的作用是标识不同的应用程序或进程，使得网络中的数据能够准确地发送到目标应用程序。

  

  端口号换分为三类：

  熟知端口号：范围是 0 到 1023，这些端口号被分配给一些常见的应用层协议和服务。例如，HTTP 协议使用 80 端口，FTP 协议使用 21 端口。

  登记端口号：范围是 1024 到 49151，这些端口号通常被一些特定的用户进程或应用程序注册使用。

  动态（私有）端口号：范围是 49152 到 65535，这类端口号通常由客户端程序在运行时随机选择使用。

  

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

  

  

  认识知名端口号：

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

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

  执行下面的命令，可以看到知名端口号，我们自己写一个程序使用端口号时，要避开这些知名端口号。

cat /etc/services

  

1. 一个进程是否可以bind多个端口号? 可以

  一个进程可以 bind 多个端口号。 一个服务器进程可能同时提供多种服务，每种服务使用不同的端口号。

  

2. 一个端口号是否可以被多个进程bind? 不可以

  一个端口号在同一时刻不能被多个进程 bind 。这是为了避免端口冲突和数据混乱。但是要注意可能fork会导致父子进程绑定了同一个端口。

  

netstat

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

  语法：netstat [选项]

  功能：查看网络状态

  常用选项：

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

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

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

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

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

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

  

pidof

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

  语法：pidof [进程名]

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

  

1.2 UDP协议

  UDP 协议（用户数据报协议）UDP 是一种无连接、不可靠的传输层协议。

  

1.2.1 UDP协议端格式

  UDP 协议的端格式由以下几个部分组成：

  源端口（Source Port）：16 位字段，标识发送方进程所使用的端口号。

  目的端口（Destination Port）：16 位字段，标识接收方进程所使用的端口号。

  长度（Length）：16 位字段，指示包括 UDP 头部和数据在内的整个用户数据报的长度，单位为字节。

  校验和（Checksum）：16 位字段，用于检测整个 UDP 数据报在传输过程中是否出现错误。

  

1.2.2 UDP的特点

  UDP传输的过程类似于寄信。

  无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接。

  不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息。

  面向数据报：UDP 把数据当作一个个独立的数据报进行处理，不能够灵活的控制读写数据的次数和数量。

  

  所以应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。

  用UDP传输100个字节的数据：

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

  

1.2.3 UDP的缓冲区

  UDP 具有接收缓冲区和发送缓冲区。

  

发送缓冲区：

  实际上 UDP 没有真正意义上的发送缓冲区。当应用程序调用 sendto 函数发送数据时，UDP 只是简单地给数据加上头部，然后立即传递给网络层进行发送。

  但是，内核会把数据暂时保存一段时间，以等待是否有来自对端的应答，这段时间内数据会被保存在一个类似于缓冲区的地方。

  

接收缓冲区：

  接收缓冲区的大小有限，如果收到的数据报超出了缓冲区的大小，多余的数据将会被丢弃。

  由于 UDP 是无连接不可靠的协议，接收方应用程序未及时读取缓冲区中的数据时，新到达的数据可能会覆盖旧的数据。

  

  UDP的socket既能读，也能写，这个概念叫做全双工。

  

1.2.3 UDP使用注意事项

  数据大小限制：UDP 能传输的数据最大长度为 64K（包含首部）。若数据超过此限制，必须在应用层进行分包处理，这增加了应用程序的复杂性，且分包与重组过程可能出错。例如，一个图像编辑软件通过网络传输大型图片文件，就需要在应用层将图片数据合理分包发送。

  

  缺乏拥塞控制：UDP 不会根据网络拥塞状况调整发送速率，可能导致网络拥塞加剧，影响其他网络应用的性能。比如在网络繁忙时，大量使用 UDP 的应用持续高速发送数据，可能导致整体网络速度下降。

  

  不可靠性：没有确认和重传机制，数据丢失或出错难以恢复，对于重要数据可能造成严重后果。像远程医疗系统中关键的患者监测数据，若使用 UDP 传输且丢失，可能危及患者生命。

  

  无序到达：数据包可能无序到达接收端，应用程序需要有处理乱序的能力。例如实时互动游戏中，玩家操作指令的数据包到达顺序可能混乱，需要游戏程序进行排序处理。

  

  端口管理：要确保所使用的端口未被其他程序占用，避免端口冲突导致通信失败。假设一个新开发的网络应用选择了常用的 80 端口，而此端口已被 Web 服务占用，就会出现冲突。

  

  安全问题：UDP 本身提供的安全性较低，数据容易被篡改或窃取。在涉及敏感信息传输时，如密码或个人身份信息，单纯使用 UDP 存在较大风险。

  

  兼容性：不同的网络设备和系统对 UDP 的处理方式可能略有差异，需要进行充分的测试以确保兼容性。某些老旧的网络设备可能对较大的 UDP 数据包处理不佳。

  

1.2.5 基于UDP的应用层协议

  NFS: 网络文件系统

  TFTP: 简单文件传输协议

  DHCP: 动态主机配置协议

  BOOTP: 启动协议(用于无盘设备启动)

  DNS: 域名解析协议

  还包括我们自己写UDP程序时自定义的应用层协议。