同时使用INADDR_ANY和特定IP绑定到同一端口 [英] Binding to same port using INADDR_ANY and a specific IP simultaneously

问题描述

在python中(在Windows上)进行的一个简单实验表明，我能够同时绑定到通配符地址和特定地址上的同一端口:

A simple experiment in python (on Windows) shows that I am able to bind to the same port on both the wildcard address and a specific address simultaneously:

import socket
import select

MY_PORT = 13337

sany = socket.socket()
sany.bind(('', MY_PORT))
sany.listen(0)

sloc = socket.socket()
sloc.bind(('127.0.0.1', MY_PORT))
sloc.listen(0)

socks = [sany, sloc]
ready, _, _ = select.select(socks, [], [])
print socks.index(ready[0])

从概念上讲，它们在本应涵盖的内容中重叠.通过从不同的提示连接到('127.0.0.1', 13337)继续进行实验，表明更具体的套接字获胜"(即打印了1). 我在SOCK_DGRAM套接字中看到了类似的行为.

Conceptually, they overlap in what they're supposed to cover. Continuing the experiment by connecting to ('127.0.0.1', 13337) from a different prompt indicates that the more specific socket 'wins' (i.e. 1 is printed). I'm seeing similar behavior in SOCK_DGRAM sockets.

我的问题如下:

• 这种行为是否具有契约性(Winsock，Berkeley Sockets等)?
• 这对于多播套接字应该如何表现?
• 这在* nix系统上应该如何表现?

推荐答案

您所描述的内容在Windows Server 2003和更高版本上是可能的，但是仅当两个bind()调用是由同一用户帐户进行的时:

What you describe is possible on Windows Server 2003 and later, but only when the two bind() calls are made by the same user account:

使用SO_REUSEADDR和SO_EXCLUSIVEADDRUSE

增强的套接字安全性是在Windows Server 2003发行版中添加的.在以前的Microsoft服务器操作系统发行版中，默认的套接字安全性很容易使进程从不怀疑的应用程序中劫持端口.在Windows Server 2003中，默认情况下套接字不处于可共享状态.因此，如果应用程序希望允许其他进程重用已经绑定了套接字的端口，则必须专门启用它.如果是这种情况，则第一个在端口上调用绑定的套接字必须在套接字上设置SO_REUSEADDR. 这种情况的唯一例外是第二次绑定调用是由进行原始绑定的同一用户帐户执行的.该例外仅是为了提供向后兼容性.

Enhanced socket security was added with the release of Windows Server 2003. In previous Microsoft server operating system releases, the default socket security easily allowed processes to hijack ports from unsuspecting applications. In Windows Server 2003, sockets are not in a sharable state by default. Therefore, if an application wants to allow other processes to reuse a port on which a socket is already bound, it must specifically enable it. If that is the case, the first socket to call bind on the port must have SO_REUSEADDR set on the socket. The only exception to this case occurs when the second bind call is performed by the same user account that made the original call to bind. This exception exists solely to provide backward compatibility.

下表描述了当第二个套接字尝试使用特定的套接字选项绑定到先前由第一个套接字绑定的地址时，Windows Server 2003和更高版本的操作系统中发生的行为.

The table below describes the behavior that occurs in Windows Server 2003 and later operating systems when a second socket attempts to bind to an address previously bound to by a first socket using specific socket options.

...

在不同用户帐户下进行套接字绑定调用时，套接字绑定行为会更改.下表指定了第二个套接字尝试绑定时在Windows Server 2003和更高版本的操作系统中发生的行为.到先前使用特定套接字选项和其他用户帐户由第一个套接字绑定的地址.

The socket binding behavior changes when the socket bind calls are made under different user accounts. The table below specifies the behavior that occurs in Windows Server 2003 and later operating systems when a second socket attempts to bind to an address previously bound to by a first socket using specific socket options and a different user account.

在Windows的早期版本中，行为是不同的:

In earlier Windows versions, the behavior was different:

下表描述了Windows XP和更早版本中当第二个套接字尝试使用特定的套接字选项绑定到先前由第一个套接字绑定的地址时发生的行为.

The table below describes the behavior that occurs in Windows XP and earlier when a second socket attempts to bind to an address previously bound to by a first socket using specific socket options.

...

如果第一个绑定调用设置为SO_REUSEADDR 或根本没有套接字选项，则第二个绑定调用将劫持"端口，应用程序将无法确定哪个端口两个套接字接收到发送到共享"端口的特定数据包.

In the case where the first call to bind sets either SO_REUSEADDR or no socket options at all, the second bind call will "hijack" the port and the application will be unable to determine which of the two sockets received specific packets sent to the "shared" port.

这篇关于同时使用INADDR_ANY和特定IP绑定到同一端口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！