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.

  • 写回答

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条)

报告相同问题?

悬赏问题

  • ¥15 关于#Java#的问题,如何解决?
  • ¥15 加热介质是液体,换热器壳侧导热系数和总的导热系数怎么算
  • ¥15 想问一下树莓派接上显示屏后出现如图所示画面,是什么问题导致的
  • ¥100 嵌入式系统基于PIC16F882和热敏电阻的数字温度计
  • ¥15 cmd cl 0x000007b
  • ¥20 BAPI_PR_CHANGE how to add account assignment information for service line
  • ¥500 火焰左右视图、视差(基于双目相机)
  • ¥100 set_link_state
  • ¥15 虚幻5 UE美术毛发渲染
  • ¥15 CVRP 图论 物流运输优化