[译]将套接字用作服务器套接字/监听套接字

[译]将套接字用作服务器套接字/监听套接字

文章介绍了监听套接字的定义、操作和一些注意事项。虽然原文系列是.Net语言下socket的FAQ,但实际上socket的内容是语言无关的，值得使用其他语言的程序员来阅读。
原文作者：Stephen Cleary
原文链接：https://blog.stephencleary.com/2009/05/using-socket-as-server-listening-socket.html

一般来说，服务器的套接字可以接受多个用户的连接。从概念来说，一个服务器套接字监听一个已知端口，当一个连接到达，服务器上的监听套接字(listening socket)创建一个新的套接字（它的子套接字，根据上下文我觉得此处的子套接字就是连接套接字，但原文没有点明），然后在子套接字上建立连接。然后监听套接字释放出来重新监听同一个端口，此时子套接字已经建立连接并且跟它的父套接字（监听套接字）是相互独立的了。
这一体系的一个结果是监听套接字实际上从不执行读写操作，它只用来创建连接套接字(connected socket）
监听套接字经常通过以下操作运行

1. 创建 套接字的创建跟所有的TCP/IP套接字创建都是一致的，详细点击Socket Operations
2. 绑定 对监听端口的绑定一般只在端口上完成，设置IP地址参数（setting the IP address parameter to IPAddress.Any (MSDN). 绑定发生错误一般是因为另一个进程已经绑定到同一个端口了（可能是服务器进程的另一个实例）
3. 监听 监听套接字此时才实际开始监听它还没有接受连接，但操作系统可能代表它接受连接（The listening socket actually begins listening at this point. It is not yet accepting connections, but the OS may accept connections on its behalf.）

令人疑惑的“backlog”参数。Socket.Listen函数的参数“backlog”表示操作系统代表应用可能接受的连接数目。这并不是活跃连接的总数，它只表示多少连接将要被建立如果应用“落后了”，一旦连接建立了，连接会从backlog队里中移出并不再受backlog的数目限制 it is only how many connections will be established if the application “gets behind”. Once connections are Accepted, they move out of the backlog queue and no longer “count” against the backlog limit.）

关于把backlog参数
python socket模块的解释https://docs.python.org/3/library/socket.html#socket.socket.listen
stackoverflow上的相关问题：
https://stackoverflow.com/questions/36594400/what-is-backlog-in-tcp-connections

个人理解：backlog表示等待队列的大小，一个TCP连接到达服务器，成功建立连接需要一定的时间，
比如三次握手传输数据的时延，监听套接字创建连接套接字的时间。
如果同一时间有多个TCP连接到达服务器，则会有部分连接放入等待队列，
当连接成功建立后则会从等待队列移出。如果等待队列满了，则服务器会拒绝新到达的连接。
所以上面说到backlog并不代表活跃连接的总数，而只代表了待连接的队列大小

下面一段是.Net语言相关的对backlog参数值的大小设置问题的说明，我就不翻译了
（The value to pass for the “backlog” parameter. Historically, this has been restricted to 
a maximum of 5, though modern systems have a cap of 200. Specifying a backlog higher 
than the maximum is not considered an error; the maximum value is used instead. 
The .NET docs fail to mention that int.MaxValue can be used to invoke 
the “dynamic backlog” feature (Windows Server systems only), 
essentially leaving it up to the OS. It is tempting to set this value very high
 (e.g., always passing int.MaxValue), 
 but this would hurt system performance (on non-server machines) 
 by pre-allocating a large amount of scarce resources. 
 This value should be set to a reasonable amount (usually between 2 and 5), 
 based on how many connections one is realistically expecting and how quickly they can be Accepted.）

4. （重复）接受（Accept） 当一个套接字连接被监听套接字接受了，一个新的套接字连接被创建出来。监听套接字应在创建新套接字完成后立即重新启动接受操作（Accept operation。完整的接受操作的结果是一个新的连接套接字，这个新的套接字可能会用于读写，关于使用连接套接字的更多信息，可以参考Using Socket as a Connected Socket。新的套接字跟监听套接字是完全独立的，关闭任一个套接字不影响其他套接字
5. 关闭 既然监听套接字实际上从不连接（它只接受连接套接字），它是没有断开连接的操作的。取而代之的是，关闭一个监听套接字简单地通知操作系统这个套接字不再监听这个端口并马上释放相关资源。

原文里上面的序号是12而不是45，我觉得是作者编写时的格式问题，因为接受和关闭其实也是监听套接字的操作

在上述主题有一些一般的变化：

1. 一个监听端口除了绑定到一个端口，还可能选择绑定到一个实际IP地址，这么做一般是为了安全考虑，如果绑定到一个实际IP地址，绑定操作（Bind Operation）可能会失败当网线被拨开或者无线路由器关机了。
2. 一个监听套接字可能选择不绑定（实际上，套接字还是绑定了，只是它绑定到一个操作系统选择的端口），这是非常少见的，只会在一些非常老的协议例如non-PASV FTP上见到。这需要一个能够通知通信另一端操作系统选择哪个端口进行绑定的的应用协议。不推荐这种紧耦合的应用协议（例如FTP）用例如TCP这样的传输机制。一个原因是紧耦合的应用协议需要任意的NATing（network address translating）设备来监控协议和动态预测必要的端口转发。（and this tight coupling of the application protocol (e.g., FTP) with the transport mechanism (e.g., TCP) is not recommended. One reason is that it requires any NAT’ing (network address translating) devices to monitor the protocol and dynamically predict the necessary port forwarding.）