douhuangjie4503
2015-05-07 04:02
浏览 82

iOS和Go-使用NSURLSession保持活动

In my iOS app, I have a search feature that fetches results from a server. The search updates live as the user updates their query, so this results in several requests being made in succession.

So my question is, how can I ensure that TCP keep-alive is being used on these connections? I'd like to reduce as much latency as possible, so it's important that a connection be maintained after the first request and reused for the following requests.

I'm using NSURLSession, and I've heard that it employs keep-alive by default, but how can I know for sure? Logging the requests on the server show no difference between each successive request, but I wouldn't expect to see any change just from the header information.

Any help here? I'm using Go on my server, so it's possible that it needs some additional configuration on that side too.

图片转代码服务由CSDN问答提供 功能建议

在我的iOS应用中,我具有一个搜索功能,可从服务器获取结果。 搜索更新随着用户更新其查询而实时进行,因此这导致连续发出多个请求。

所以我的问题是,如何确保使用TCP保持活动状态 在这些连接上? 我想尽可能减少延迟,因此在第一个请求之后保持连接并在随后的请求中重新使用是很重要的。

我正在使用NSURLSession, 听说它默认使用保持活动状态,但是我怎么确定呢? 在服务器上记录请求不会显示每个后续请求之间的区别,但是我不希望仅从标头信息中看到任何变化。

这里有帮助吗? 我在服务器上使用的是Go,因此这边也可能需要一些其他配置。

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 邀请回答

2条回答 默认 最新

  • doz95923 2015-05-16 15:23
    最佳回答

    I believe you're confusing TCP keep-alive with HTTP keep-alive (persistent connections). These are unrelated concepts. From your question, you probably mean HTTP persistent connections.

    In HTTP/1.1, persistent connections are the default and are used by NSURLSession and nearly every HTTP/1.1 client. You have to ask to turn them off. You can check for a Connection: close in the HTTP header, or on the server side, you can check the Close field of the http.Request. But I'm sure you're getting persistent connections. This means that you don't have to renegotiate the TLS tunnel (or at a minimum the TCP three-way handshake) for every request. (Though if you make parallel requests, there will still be multiple connections that you have to negotiate. HTTP/1.1 can only handle one thing at a time, and NSURLSession will try to use a pool of connections to improve response times.)

    TCP keep-alives are a completely different thing. It sends a periodic "ping" to the other side to make sure it's still reachable. There are many ways for you to lose network connectivity and not know it until the next time you try to communicate, and the normal symptom is that the connection just hangs and you need to time it out. In theory TCP keep-alive is just the tool for discovering this, but I have almost never found it practical. It's difficult to configure properly (especially in Cocoa). You will almost always need to build a higher-level "ping" functionality for your application rather than relying on this.

    But bringing it around to your problem, HTTP/1.1 is probably fine for you as-is, but you're going to need to carefully manage your responses. If you make a new request for every letter and send back a massive response, then that's going to work badly. You're going to keep all your connection pool busy downloading things that you're going to throw away. You need to focus first on good algorithms. At a minimum, you probably only want to send a few results at a time and provide a "paging" approach in your API to ask for more results for the same search.

    评论
    解决 无用
    打赏 举报
查看更多回答(1条)

相关推荐 更多相似问题