传输层协议UDP详解

一. 知识准备

1.1 传输层

1.2 重识端口号

二. UDP协议

三. UDP协议特点

一. 知识准备

1.1 传输层

前面已经讲过，HTTP协议是应用层协议，在此之前，我们短暂的认为HTTP是直接通过应用层与外界通信的。但是我们要知道，应用层需要向下将数据传到传输层，再由传输层向下传送。最终才能通过网络传输到接收方。

传输层负责保证可靠性传输，确保数据能够可靠地传送到接收方。

1.2 重识端口号

端口号的作用是标识主机上的一个唯一的进程。当目标主机接收到数据之后，需要自底向上进行数据的传送，最后根据端口号来确定该传给上层哪个进程。

端口号是属于传输层的概念，因此在传输层协议中就会包含与端口相关的字段。

五元组标识一个通信：

在TCP/IP协议中，用“源IP地址”、“源端口号”、“目的IP地址”、“目的端口号”、“协议号”这样一个五元组来标识一个通信。

像上图这样，有多台主机访问服务器，这些主机中可能有多个进程在同时访问服务器。

而这台服务器收到请求之后，根据五元组分离出“源IP地址”、“源端口号”、“目的IP地址”、“目的端口号”、“协议号”这些元素。

根据目的IP地址和目的端口号确定这些主机确实是想跟这台服务器通信。
然后根据源IP地址和源端口号确定是哪台主机上的哪个进程想要通信。
最后根据协议号确定该用什么类型进行通信。

也可以通过netstat命令查看五元组信息。

其中Local Address就是源IP和源端口号，Foreign Address就是目的IP和目的端口号。而Proto代表的就是协议类型。

端口号范围划分：

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

例如：

• ssh 服务器, 使用 22 端口

• ftp 服务器, 使用 21 端口

• telnet 服务器, 使用 23 端口

• http 服务器, 使用 80 端口

• https 服务器, 使用 443

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

协议号 VS 端口号：

协议号是存在于IP报头当中的，其长度是8位。协议号指明了数据报所携带的数据是使用的何种协议，以便让目的主机的IP层知道应该将该数据交付给传输层的哪个协议进行处理。
端口号是存在于UDP和TCP报头当中的，其长度是16位。端口号的作用是唯一标识一台主机上的某个进程。
协议号是作用于传输层和网络层之间的，而端口号是作用于应用层于传输层之间的。

两个问题：

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

这是绝对不行的，因为我们是通过端口号来标识唯一的一个进程，如果我们将一个端口号绑定多个进程。通信时就不知道该与哪个进程通信。

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

这个是可以的，与“端口号唯一标识一个进程”不冲突，只不过现在变成了一个进程可以由多个端口号来标识。

二. UDP协议

网络套接字编程时用到的各种接口，是位于应用层和传输层之间的一层系统调用接口，这些接口是系统提供的，我们可以通过这些接口搭建上层应用，比如HTTP。我们经常说HTTP是基于TCP的，实际就是因为HTTP在TCP套接字编程上搭建的。

而socket接口往下的传输层实际就是由操作系统管理的，因此UDP是属于内核当中的，是操作系统本身协议栈自带的，其代码不是由上层用户编写的，UDP的所有功能都是由操作系统完成，因此网络也是操作系统的一部分。

16位源端口号：表示数据从哪里来。
16位目的端口号：表示数据要到哪里去。
16位UDP长度：表示整个数据报（UDP首部 + UDP数据）的长度。
16位UDP检验和：如果UDP报文的检验和出错，就会直接将报文丢弃。

我们在应用层看到的端口号大部分是16位的，其根本原因就是因为传输层协议当中的端口号就是16位的。

UDP如何实现报头与数据的分离？

可以看到，报头里面只有四个部分，每个部分的长度都是16位，总共8字节。所以可以将报头看做定长的，那么只需在读取的时候将前面8字节的报头读完，剩下的就是数据。

UDP如何决定将有效载荷交付给上层哪一个协议？

UDP上层也有很多应用层协议，因此UDP必须想办法将有效载荷交给对应的上层协议，也就是交给应用层对应的进程。

应用层的每一个网络进程都会绑定一个端口号，服务端进程必须显示绑定一个端口号，客户端进程则是由系统绑定的一个端口号。UDP就是通过报头当中的目的端口号来找到对应的应用层进程的。

特别注意：内核中用哈希的方式维护了端口号与进程ID之间的映射关系，因此传输层可以通过端口号得到对应的进程ID，进而找到对应的应用层进程。

三. UDP协议特点

UDP传输的过程类似于寄信，其特点如下：

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

注意：报文在网络中进行路由转发时，并不是每一个报文选择的路由路径都是一样的，因此报文发送的顺序和接收的顺序可能是不同的。

面向数据报：

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

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

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

UDP的缓冲区：

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

为什么UDP要有接收缓冲区？

如果UDP没有接收缓冲区，那么就要求上层及时将UDP获取到的报文读取上去，如果一个报文在UDP没有被读取，那么此时UDP从底层获取上来的报文数据就会被迫丢弃。

一个报文从一台主机传输到另一台主机，在传输过程中会消耗主机资源和网络资源。如果UDP收到一个报文后仅仅因为上次收到的报文没有被上层读取，而被迫丢弃一个可能并没有错误的报文，这就是在浪费主机资源和网络资源。

因此UDP本身是会维护一个接收缓冲区的，当有新的UDP报文到来时就会把这个报文放到接收缓冲区当中，此时上层在读数据的时候就直接从这个接收缓冲区当中进行读取就行了，而如果UDP接收缓冲区当中没有数据那上层在读取时就会被阻塞。因此UDP的接收缓冲区的作用就是，将接收到的报文暂时的保存起来，供上层读取。

UDP使用注意事项：

我们注意到, UDP 协议首部中有一个 16 位的最大长度。也就是说一个 UDP 能传输的数据最大长度是 64K(包含 UDP 首部)。

然而 64K 在当今的互联网环境下, 是一个非常小的数字。

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

基于UDP的应用层协议：