iOS 和 Go - 使用 NSURLSession 保持事件状态

Question

在我的 iOS 应用程序中，我有一个从服务器获取结果的搜索功能。搜索更新随着用户更新他们的查询而实时更新，因此这会导致连续发出多个请求。

所以我的问题是，如何确保在这些连接上使用 TCP keep-alive？我想尽可能减少延迟，因此在第一次请求后保持连接并为后续请求重复使用非常重要。

我正在使用 NSURLSession，我听说它默认使用 keep-alive，但我怎么能确定呢？在服务器上记录请求显示每个连续请求之间没有区别，但我不希望仅从 header 信息中看到任何变化。

这里有什么帮助吗？我在我的服务器上使用 Go，因此它可能也需要在该端进行一些额外的配置。

Answer 1

我相信您将 TCP keep-alive 与 HTTP keep-alive(持久连接)混淆了。这些是不相关的概念。根据您的问题，您可能是指 HTTP 持久连接。

在 HTTP/1.1 中，持久连接是默认的，并且被 NSURLSession 和几乎每个 HTTP/1.1 客户端使用。你必须要求关闭它们。您可以在 HTTP header 中检查 Connection: close，或者在服务器端，您可以检查 http.Request 的 Close 字段>。但我敢肯定你会得到持久的连接。这意味着您不必为每个请求重新协商 TLS 隧道(或至少 TCP 三向握手)。 (虽然如果你发出并行请求，仍然会有多个连接需要协商。HTTP/1.1 一次只能处理一件事，NSURLSession 会尝试使用连接池来缩短响应时间。)

TCP keep-alives 是完全不同的东西。它会定期向另一端发送“ping”以确保它仍然可以访问。有很多方法让您失去网络连接，直到您下次尝试通信时才知道，正常的症状是连接挂起，您需要超时。从理论上讲，TCP keep-alive 只是发现这一点的工具，但我几乎从未发现它实用。很难正确配置(尤其是在 Cocoa 中)。您几乎总是需要为您的应用程序构建更高级别的“ping”功能，而不是依赖于此。

但是解决您的问题，HTTP/1.1 可能适合您，但您需要仔细管理您的响应。如果你对每封信都提出新的要求，然后发回大量的回复，那效果会很差。您将让所有连接池忙于下载您将要丢弃的东西。你需要首先关注好的算法。至少，您可能只想一次发送几个结果，并在您的 API 中提供“分页”方法来为同一搜索请求更多结果。