IP协议能够进行数据的无连接不可靠传输服务，为什么还需要UDP协议？

Posted 2021-04-15 车小胖谈网络

这是一个有深度的问题，这个问题无数次困扰着我。看到这个问题的一瞬间，仿佛看到沉迷于书海但却无法找到答案的自己。。。

 

接下来的写作手法，有点像哄幼儿园的小朋友，既然小朋友不开心了，那就顺着小朋友的思路来，让小朋友无路可走，最终认识到自己的错误。

 

咱们不要UDP协议了，好不好？

 

好的！

 

原先，小朋友使用DNS来解析互联网上服务器IP，而DNS使用UDP协议来传输。既然现在没有UDP了，而是直接使用IP协议来传输。

 

• 问题来了，IP进程需要知道是哪个程序发送DNS报文的吧？

 

如果把IP进程比作会所的客户经理，而发DNS域名查询的程序就是客户。

 

客户经理必须唯一地标识每一个客户，对吗？否则当返回的DNS域名回复报文到达时，客户经理如何知道是哪位客户的？

 

小朋友说，这个简单啊，IP协议头不是有一个字节的“Protocol”字段的吗？用不同的“Protocol ID”来唯一识别客户，可以哇？

 

  

说的很好，小朋友竟然知道IP协议能够为上层程序（协议）提供复用/分用（Multiplex/De-Multiplex）服务！

 

 

• 问题又来了，“Protocol”字段只有一个字节，是给客户端程序使用，还是服务器使用？

 

小朋友犹豫了一下，略加思考之后回答说，客户端、服务器公用“Protocol”字段可以哇？

 

当然可以啦！

 

以TCP为例，客户端使用“Protocol”= 6，而服务器也使用“Protocol”= 6。

 

 

咱们假设IP使用“Protocol”= 53，来识别客户端程序、服务器DNS程序。

 

这一点问题没有，IP协议可以识别客户端、服务器程序，一切工作正常！

 

 

• 小朋友同时又打开一个网页，这又是一个程序，IP协议如何识别这个新的程序呢？

 

“Protocol”= 53 已经被使用了，使用别的ID（1-255），服务器不同意，因为服务器固定使用“Protocol”= 53！如果ID不固定，客户端IP报文如何找到它？

 

 

小朋友豁然大悟，哦，我明白了！使用一个“Protocol”不容易识别同一台主机上的多个用户进程！

 

既然小朋友已经认识到自己的错误，接下来就给小朋友讲一些大道理！

 

 

• 操作系统如何管理程序（进程）？

 

在操作系统上运行的任何程序，包括系统进程（TCP/IP程序）、用户进程（浏览器），都会分配一个独一无二的进程ID，这个进程ID通常为2个字节。

 

所以，当用户进程通过操作系统向互联网发送IP报文时，操作系统根据进程ID是哪个程序要发IP报文。

 

但是，当从互联网上返回的IP报文到达时，操作系统如何通过IP报文里的字段，来找到特定的进程ID，并将IP报文转交给该进程ID呢？

 

 

• UDP端口号

操作系统可以在UDP端口里，事先写上用户进程ID，现在操作系统就可以根据端口号里的进程ID，找到特定的进程，并将IP报文转交给该进程ID！

 

 

源端口、目的端口两个字段，分别用来识别客户端、服务器端进程ID。

 

 

但是，用进程ID来填充源端口、目的端口，缺点也是显而易见的！

 

比如DNS工作在端口53，意味着DNS必须使用进程ID = 53，这非常不灵活！

 

 

• 操作系统负责端口号与进程号的映射

 

只要操作系统，维护一张映射表，将进程ID与端口号作一一映射，就可以解决灵活性不足的问题！