sockets - 何时关闭套接字 tcp

Question

我正在使用 GPS 追踪器。我正在通过套接字收听 gps 跟踪器设备。目前我同时收听的设备总数为 20 台。我心里有几个问题

最初我打开一个套接字并在读取后关闭，这个循环继续进行。我按时从设备接收数据。问题是当设备增加时，多个设备的收听时间变慢并且不再实时

然后我选择socket打开后不关闭。它变得实时并按时获得每个设备的响应，但现在当我通过运行此命令检查进程时

 sudo netstat -tulnap | grep :8153

现在总共建立了 750 个连接。所以我假设我可能做错了什么？

所以我想知道如果我想一次从所有设备接收数据应该怎么做？或者有没有更好的方法来实现它？如果有人能指导我走向正确的方向，我将不胜感激。

注意:我的设备可能连接到 20 到 20,000 台设备，因此您提供的解决方案应该能够实时监听来自任意数量设备的数据

提前谢谢你

Answer 1

规则是:当你用完一个套接字时关闭它； OTOH 如果您打算将来继续通过该套接字接收/发送数据，请将其保持打开状态以便您可以这样做。何时保持套接字打开(与关闭套接字然后重新打开新的 TCP 连接相比)是一个判断调用，这将取决于您的程序试图完成什么。

听起来您的程序可能遇到“套接字泄漏”，在某些情况下您的程序会忘记调用 close()在不再打算使用的 socket 上；而且您的程序不断创建新套接字。在那种情况下，这些打开但被遗忘的套接字会随着时间的推移而累积，最终您的程序将耗尽资源并且无法创建更多套接字。这是一件坏事。

你没有说你在用什么语言编程，但如果你在用 C++ 编程，避免套接字泄漏的一个简单方法是将每个套接字包装到一个套接字持有对象中:

class SocketHolder
{
public:
   SocketHolder(int socketfd) : _fd(fd) {/* empty */}
   ~SocketHolder() {if (_fd >= 0) close(fd);}

   int GetSocketFD() const {return _fd;}

private:
   SocketHolder(const SocketHolder &);  // private and unimplemented (to prevent accidental copying of SocketHolder objects)

   int _fd;
};

...然后每当您调用 socket()/accept()/etc 来创建一个新的套接字 FD 时，立即将它交给一个由智能指针持有的 SocketHolder 对象，例如:

int s = socket();
std::shared_ptr<SocketHolder> holder(new SocketHolder(s));

... 并修改您的程序以存储和/或传递 std::shared_ptr<SocketHolder>对象而不是 int套接字值。

这样做的好处是，一旦你这样做了，你就不再需要记得调用close(s)了。在适当的时候显式地显示，因为它会在其 SocketHolder 时自动为您调用对象被删除，SocketHolder当引用它的最后一个智能指针消失时，对象将被自动删除。自 close()调用现在无需程序员的任何努力即可发生，套接字泄漏发生的可能性要小得多。

问题的另一个可能来源是操作系统(默认情况下)会在内存中短时间保留最近关闭的 TCP 连接的记录，即使在您关闭它们之后也是如此；这样做有助于操作系统确保在关闭之前发送到这些套接字的任何数据都可以交付，还有助于操作系统避免误解 future 的 TCP 数据包。然而，这确实意味着 TCP 套接字记录可以在 TCP 套接字关闭后短暂停留；如果这对您来说是个问题，您可以通过设置 SO_LINGER 来解决它套接字选项，如前所述here .

如果您要同时打开数十个或数百个设备的 TCP 连接，那很好；你可以这样做并使用 select() 在它们之间进行多路复用或 poll()或 epoll()或 kqueue()或设计用于一次处理多个套接字的类似 API。根据我的经验，从长远来看，使用非阻塞 I/O 会更简单，因为它避免了一个非常慢(或出现故障)的客户端设备挂断整个服务器的可能性。

如果您真的需要同时支持数千个 TCP 连接而不是几十个或数百个，您可能会遇到一些扩展问题；你可能想阅读 The C10K Problem ，这是一篇有些过时但仍然内容丰富的文章，介绍了处理这种大小的连接负载的各种方法。

正如 paulsm4 所提到的，另一种选择可能是使用 UDP 而不是 TCP 进行通信。这样做的好处是您只需要创建一个套接字(可用于与任意数量的设备通信)而不是每个设备一个套接字。一些缺点包括通常很难通过 Internet 路由 UDP 数据包(默认情况下防火墙往往会拒绝传入的 UDP 数据包)，而且 UDP 数据包无法像 TCP 流那样获得任何交付或排序保证。当然，如果您的设备只使用 TCP，那么 UDP 将不是您的选择。