TCP和UDP可以同时绑定相同的端口吗？

之前有读者在字节面试的时候被问到TCP 和 UDP 可以同时监听相同的端口吗关于端口的知识点还是挺多可以讲的比如还可以牵扯到这几个问题多个 TCP 服务进程可以同时绑定同一个端口吗客户端的端口可以重复使用吗客户端 TCP 连接 TIME_WAIT 状态过多会导致端口资源耗尽而无法建立新的连接吗所以这次就跟大家盘一盘这些问题。TCP 和 UDP 可以同时绑定相同的端口吗其实我感觉这个问题「TCP 和 UDP 可以同时监听相同的端口吗」表述有问题这个问题应该表述成「TCP 和 UDP 可以同时绑定相同的端口吗」因为「监听」这个动作是在 TCP 服务端网络编程中才具有的而 UDP 服务端网络编程中是没有「监听」这个动作的。TCP 和 UDP 服务端网络相似的一个地方就是会调用 bind 绑定端口。给大家贴一下 TCP 和 UDP 网络编程的区别就知道了。TCP 网络编程如下服务端执行 listen() 系统调用就是监听端口的动作。TCP 网络编程UDP 网络编程如下服务端是没有监听这个动作的只有执行 bind() 系统调用来绑定端口的动作。UDP 网络编程TCP 和 UDP 可以同时绑定相同的端口吗答案可以的。在数据链路层中通过 MAC 地址来寻找局域网中的主机。在网际层中通过 IP 地址来寻找网络中互连的主机或路由器。在传输层中需要通过端口进行寻址来识别同一计算机中同时通信的不同应用程序。所以传输层的「端口号」的作用是为了区分同一个主机上不同应用程序的数据包。传输层有两个传输协议分别是 TCP 和 UDP在内核中是两个完全独立的软件模块。当主机收到数据包后可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP所以可以根据这个信息确定送给哪个模块TCP/UDP处理送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。因此 TCP/UDP 各自的端口号也相互独立如 TCP 有一个 80 号端口UDP 也可以有一个 80 号端口二者并不冲突。验证结果我简单写了 TCP 和 UDP 服务端的程序它们都绑定同一个端口号 8888。运行这两个程序后通过 netstat 命令可以看到TCP 和 UDP 是可以同时绑定同一个端口号的。多个 TCP 服务进程可以绑定同一个端口吗还是以前面的 TCP 服务端程序作为例子启动两个同时绑定同一个端口的 TCP 服务进程。运行第一个 TCP 服务进程之后netstat 命令可以查看8888 端口已经被一个 TCP 服务进程绑定并监听了如下图接着运行第二个 TCP 服务进程的时候就报错了“Address already in use”如下图我上面的测试案例是两个 TCP 服务进程同时绑定地址和端口是0.0.0.0 地址和8888端口所以才出现的错误。如果两个 TCP 服务进程绑定的 IP 地址不同而端口相同的话也是可以绑定成功的如下图所以默认情况下针对「多个 TCP 服务进程可以绑定同一个端口吗」这个问题的答案是如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同那么执行 bind() 时候就会出错错误是“Address already in use”。注意如果 TCP 服务进程 A 绑定的地址是 0.0.0.0 和端口 8888而如果 TCP 服务进程 B 绑定的地址是 192.168.1.100 地址或者其他地址和端口 8888那么执行 bind() 时候也会出错。这是因为 0.0.0.0 地址比较特殊代表任意地址意味着绑定了 0.0.0.0 地址相当于把主机上的所有 IP 地址都绑定了。重启 TCP 服务进程时为什么会有“Address in use”的报错信息TCP 服务进程需要绑定一个 IP 地址和一个端口然后就监听在这个地址和端口上等待客户端连接的到来。然后在实践中我们可能会经常碰到一个问题当 TCP 服务进程重启之后总是碰到“Address in use”的报错信息TCP 服务进程不能很快地重启而是要过一会才能重启成功。这是为什么呢当我们重启 TCP 服务进程的时候意味着通过服务器端发起了关闭连接操作于是就会经过四次挥手而对于主动关闭方会在 TIME_WAIT 这个状态里停留一段时间这个时间大约为 2MSL。当 TCP 服务进程重启时服务端会出现 TIME_WAIT 状态的连接TIME_WAIT 状态的连接使用的 IPPORT 仍然被认为是一个有效的 IPPORT 组合相同机器上不能够在该 IPPORT 组合上进行绑定那么执行 bind() 函数的时候就会返回了 Address already in use 的错误。而等 TIME_WAIT 状态的连接结束后重启 TCP 服务进程就能成功。重启 TCP 服务进程时如何避免“Address in use”的报错信息我们可以在调用 bind 前对 socket 设置 SO_REUSEADDR 属性可以解决这个问题。int on 1; setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, on, sizeof(on));因为 SO_REUSEADDR 作用是如果当前启动进程绑定的 IPPORT 与处于TIME_WAIT 状态的连接占用的 IPPORT 存在冲突但是新启动的进程使用了 SO_REUSEADDR 选项那么该进程就可以绑定成功。举个例子服务端有个监听 0.0.0.0 地址和 8888 端口的 TCP 服务进程。‍有个客户端IP地址192.168.1.100已经和服务端IP 地址172.19.11.200建立了 TCP 连接那么在 TCP 服务进程重启时服务端会与客户端经历四次挥手服务端的 TCP 连接会短暂处于 TIME_WAIT 状态客户端地址:端口 服务端地址:端口 TCP 连接状态 192.168.1.100:37272 172.19.11.200:8888 TIME_WAIT如果 TCP 服务进程没有对 socket 设置 SO_REUSEADDR 属性那么在重启时由于存在一个和绑定 IPPORT 一样的 TIME_WAIT 状态的连接那么在执行 bind() 函数的时候就会返回了 Address already in use 的错误。如果 TCP 服务进程对 socket 设置 SO_REUSEADDR 属性了那么在重启时即使存在一个和绑定 IPPORT一样的 TIME_WAIT 状态的连接依然可以正常绑定成功因此可以正常重启成功。因此在所有 TCP 服务器程序中调用 bind 之前最好对 socket 设置 SO_REUSEADDR 属性这不会产生危害相反它会帮助我们在很快时间内重启服务端程序。‍前面我提到过这个问题如果 TCP 服务进程 A 绑定的地址是 0.0.0.0 和端口 8888而如果 TCP 服务进程 B 绑定的地址是 192.168.1.100 地址或者其他地址和端口 8888那么执行 bind() 时候也会出错。这个问题也可以由 SO_REUSEADDR 解决因为它的另外一个作用是绑定的 IP地址 端口时只要 IP 地址不是正好(exactly)相同那么允许绑定。比如0.0.0.0:8888 和192.168.1.100:8888虽然逻辑意义上前者包含了后者但是 0.0.0.0 泛指所有本地 IP而 192.168.0.100 特指某一IP两者并不是完全相同所以在对 socket 设置 SO_REUSEADDR 属性后那么执行 bind() 时候就会绑定成功。客户端的端口可以重复使用吗客户端在执行 connect 函数的时候会在内核里随机选择一个端口然后向服务端发起 SYN 报文然后与服务端进行三次握手。所以客户端的端口选择的发生在 connect 函数内核在选择端口的时候会从 net.ipv4.ip_local_port_range 这个内核参数指定的范围来选取一个端口作为客户端端口。该参数的默认值是 32768 61000意味着端口总可用的数量是 61000 - 32768 28232 个。当客户端与服务端完成 TCP 连接建立后我们可以通过 netstat 命令查看 TCP 连接。$ netstat -napt 协议 源ip地址:端口 目的ip地址端口 状态 tcp 192.168.110.182.64992 117.147.199.51.443 ESTABLISHED那问题来了上面客户端已经用了 64992 端口那么还可以继续使用该端口发起连接吗这个问题很多同学都会说不可以继续使用该端口了如果按这个理解的话 默认情况下客户端可以选择的端口是 28232 个那么意味着客户端只能最多建立 28232 个 TCP 连接如果真是这样的话那么这个客户端并发连接也太少了吧所以这是错误理解。正确的理解是TCP 连接是由四元组源IP地址源端口目的IP地址目的端口唯一确认的那么只要四元组中其中一个元素发生了变化那么就表示不同的 TCP 连接的。所以如果客户端已使用端口 64992 与服务端 A 建立了连接那么客户端要与服务端 B 建立连接还是可以使用端口 64992 的因为内核是通过四元祖信息来定位一个 TCP 连接的并不会因为客户端的端口号相同而导致连接冲突的问题。比如下面这张图有 2 个 TCP 连接左边是客户端右边是服务端客户端使用了相同的端口 50004 与两个服务端建立了 TCP 连接。仔细看上面这两条 TCP 连接的四元组信息中的「目的 IP 地址」是不同的一个是 180.101.49.12 另外一个是 180.101.49.11。多个客户端可以 bind 同一个端口吗bind 函数虽然常用于服务端网络编程中但是它也是用于客户端的。前面我们知道客户端是在调用 connect 函数的时候由内核随机选取一个端口作为连接的端口。而如果我们想自己指定连接的端口就可以用 bind 函数来实现客户端先通过 bind 函数绑定一个端口然后调用 connect 函数就会跳过端口选择的过程了转而使用 bind 时确定的端口。针对这个问题多个客户端可以 bind 同一个端口吗要看多个客户端绑定的 IP PORT 是否都相同如果都是相同的那么在执行 bind() 时候就会出错错误是“Address already in use”。如果一个绑定在 192.168.1.100:6666一个绑定在 192.168.1.200:6666因为 IP 不相同所以执行 bind() 的时候能正常绑定。所以 如果多个客户端同时绑定的 IP 地址和端口都是相同的那么执行 bind() 时候就会出错错误是“Address already in use”。一般而言客户端不建议使用 bind 函数应该交由 connect 函数来选择端口会比较好因为客户端的端口通常都没什么意义。客户端 TCP 连接 TIME_WAIT 状态过多会导致端口资源耗尽而无法建立新的连接吗针对这个问题要看客户端是否都是与同一个服务器目标地址和目标端口一样建立连接。如果客户端都是与同一个服务器目标地址和目标端口一样建立连接那么如果客户端 TIME_WAIT 状态的连接过多当端口资源被耗尽就无法与这个服务器再建立连接了。但是因为只要客户端连接的服务器不同端口资源可以重复使用的。所以如果客户端都是与不同的服务器建立连接即使客户端端口资源只有几万个 客户端发起百万级连接也是没问题的当然这个过程还会受限于其他资源比如文件描述符、内存、CPU 等。如何解决客户端 TCP 连接 TIME_WAIT 过多导致无法与同一个服务器建立连接的问题前面我们提到如果客户端都是与同一个服务器目标地址和目标端口一样建立连接那么如果客户端 TIME_WAIT 状态的连接过多当端口资源被耗尽就无法与这个服务器再建立连接了。针对这个问题也是有解决办法的那就是打开 net.ipv4.tcp_tw_reuse 这个内核参数。因为开启了这个内核参数后客户端调用 connect 函数时如果选择到的端口已经被相同四元组的连接占用的时候就会判断该连接是否处于 TIME_WAIT 状态如果该连接处于 TIME_WAIT 状态并且 TIME_WAIT 状态持续的时间超过了 1 秒那么就会重用这个连接然后就可以正常使用该端口了。举个例子假设客户端已经与服务器建立了一个 TCP 连接并且这个状态处于 TIME_WAIT 状态客户端地址:端口 服务端地址:端口 TCP 连接状态 192.168.1.100:2222 172.19.11.21:8888 TIME_WAIT然后客户端又与该服务器172.19.11.21:8888发起了连接在调用 connect 函数时内核刚好选择了 2222 端口接着发现已经被相同四元组的连接占用了如果没有开启net.ipv4.tcp_tw_reuse 内核参数那么内核就会选择下一个端口然后继续判断直到找到一个没有被相同四元组的连接使用的端口 如果端口资源耗尽还是没找到那么 connect 函数就会返回错误。如果开启了 net.ipv4.tcp_tw_reuse 内核参数就会判断该四元组的连接状态是否处于 TIME_WAIT 状态如果连接处于 TIME_WAIT 状态并且该状态持续的时间超过了 1 秒那么就会重用该连接于是就可以使用 2222 端口了这时 connect 就会返回成功。再次提醒一次开启了 net.ipv4.tcp_tw_reuse 内核参数是客户端连接发起方 在调用 connect() 函数时才起作用所以在服务端开启这个参数是没有效果的。客户端端口选择的流程总结至此我们已经把客户端在执行 connect 函数时内核选择端口的情况大致说了一遍为了让大家更明白客户端端口的选择过程我画了一流程图。总结TCP 和 UDP 可以同时绑定相同的端口吗可以的。TCP 和 UDP 传输协议在内核中是由两个完全独立的软件模块实现的。当主机收到数据包后可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP所以可以根据这个信息确定送给哪个模块TCP/UDP处理送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。因此 TCP/UDP 各自的端口号也相互独立互不影响。多个 TCP 服务进程可以同时绑定同一个端口吗如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同那么执行 bind() 时候就会出错错误是“Address already in use”。如果两个 TCP 服务进程绑定的端口都相同而 IP 地址不同那么执行 bind() 不会出错。如何解决服务端重启时报错“Address already in use”的问题当我们重启 TCP 服务进程的时候意味着通过服务器端发起了关闭连接操作于是就会经过四次挥手而对于主动关闭方会在 TIME_WAIT 这个状态里停留一段时间这个时间大约为 2MSL。当 TCP 服务进程重启时服务端会出现 TIME_WAIT 状态的连接TIME_WAIT 状态的连接使用的 IPPORT 仍然被认为是一个有效的 IPPORT 组合相同机器上不能够在该 IPPORT 组合上进行绑定那么执行 bind() 函数的时候就会返回了 Address already in use 的错误。要解决这个问题我们可以对 socket 设置 SO_REUSEADDR 属性。这样即使存在一个和绑定 IPPORT一样的 TIME_WAIT 状态的连接依然可以正常绑定成功因此可以正常重启成功。客户端的端口可以重复使用吗在客户端执行 connect 函数的时候只要客户端连接的服务器不是同一个内核允许端口重复使用。TCP 连接是由四元组源IP地址源端口目的IP地址目的端口唯一确认的那么只要四元组中其中一个元素发生了变化那么就表示不同的 TCP 连接的。所以如果客户端已使用端口 64992 与服务端 A 建立了连接那么客户端要与服务端 B 建立连接还是可以使用端口 64992 的因为内核是通过四元祖信息来定位一个 TCP 连接的并不会因为客户端的端口号相同而导致连接冲突的问题。客户端 TCP 连接 TIME_WAIT 状态过多会导致端口资源耗尽而无法建立新的连接吗要看客户端是否都是与同一个服务器目标地址和目标端口一样建立连接。如果客户端都是与同一个服务器目标地址和目标端口一样建立连接那么如果客户端 TIME_WAIT 状态的连接过多当端口资源被耗尽就无法与这个服务器再建立连接了。即使在这种状态下还是可以与其他服务器建立连接的只要客户端连接的服务器不是同一个那么端口是重复使用的。如何解决客户端 TCP 连接 TIME_WAIT 过多导致无法与同一个服务器建立连接的问题打开 net.ipv4.tcp_tw_reuse 这个内核参数。因为开启了这个内核参数后客户端调用 connect 函数时如果选择到的端口已经被相同四元组的连接占用的时候就会判断该连接是否处于 TIME_WAIT 状态。如果该连接处于 TIME_WAIT 状态并且 TIME_WAIT 状态持续的时间超过了 1 秒那么就会重用这个连接然后就可以正常使用该端口了。完搞定