TCP半开放连接、Winsock、侦听/接受行为
作为一名网络工程师，我非常熟悉TCP操作。作为一名程序员，我曾涉足套接字编程，但从未编写过任何产品服务。
我们有一个与PTZ (平移/倾斜/变焦)相机集成的供应商系统。摄像机监视病人。摄像机数据被馈送到供应商服务器。供应商服务器将摄像机数据中继到客户端。(它做的更多，但这是一个简单的例子。)如果客户端想要调整摄像头，客户端会向供应商服务器上的自定义服务发送自定义命令。服务器解释该命令并将其发送到摄像机。摄像机移动。
我们遇到了服务器上的PTZ服务崩溃的问题。在测试过程中，对于网络捕获，我们发现在nmap执行半开放(萌芽)连接时服务崩溃-- nmap发送同步，服务器回复同步/确认，nmap没有发送最终确认。服务器发送了重复的SYN/ACK，试图完成会话但失败。
我想了解的是:服务使用listen监视TCP连接，然后使用accept接受连接。在什么时候，listen会告诉服务有一个新的连接，准备好进行accept了？在listen将其传递给要accept的服务之前，是否需要完成TCP连接？或者在listen通知服务之前，服务器只需要返回SYN/ACK？
如果在listen告诉服务之前握手需要完成-- SYN、SYN/ACK、ACK --那么我可能走错了路。如果套接字只需要到达SYN/ACK，则服务对不完整会话的处理可能存在问题。在其他测试中，我们完成一个TCP会话并发送虚假数据，试图使服务崩溃--这些测试并没有导致服务失败。但是重复的nmap测试相当可靠地使其崩溃，所以我倾向于半开放的连接问题。
回答 2
Stack Overflow用户
发布于 2016-08-30 02:35:10
listen()本身只是创建backlog队列，打开绑定端口进行通信，然后退出。在幕后，套接字堆栈现在被动地侦听操作系统层的连接，在backlog队列中缓存挂起的连接，并完成它们的握手。只有完全建立的连接才可用于accept()、WSAAccept()和AcceptEx()。
listen()退出后，根据应用程序代码对套接字I/O使用的模式(阻塞、非阻塞、重叠I/O或I/O完成端口)，代码可以：
- (阻塞)调用
accept()或WSAAccept()并让其阻塞，直到它从queue. - (non-blocking)检索到连接。使用
select()、WSAAsyncSelect()或WSAEventSelect()在连接就绪时收到通知，并等待通过accept()或callAcceptEx()检索以开始异步接受，然后等待指示已从队列中检索连接的事件/完成通知。
Stack Overflow用户
发布于 2016-08-30 05:20:16
在什么时候侦听服务有一个新的连接，准备接受？
绝不可能。
在listen将其传递给服务接受之前，是否需要完成TCP连接？或者在listen通知服务之前，服务器只需要返回SYN/ACK？
这一切都不会发生。listen()只是将套接字置于侦听状态，并使TCP开始接受连接并将它们放入backlog队列中。它是与服务通信的accept()：它在backlog队列为空(本质上)时阻塞，然后返回第一个条目，并在它周围构造一个新的套接字。
如果在listen告诉服务之前握手需要完成-- SYN、SYN/ACK、ACK --那么我可能走错了路。
在accept()将新套接字返回给服务之前，它需要完成。
如果套接字只需要同步/确认，则服务对不完整会话的处理可能存在问题。
这不是问题。它并不是这样的。
TCP其他测试--我们完成
会话并发送虚假数据，试图使服务崩溃--并没有导致服务失败。
QED。
，但重复的nmap测试相当可靠地使其崩溃，所以我倾向于半开放的连接问题。
请定义“崩溃”。
https://stackoverflow.com/questions/39210043
复制相似问题
腾讯云开发者
