在我的 iOS 應用程序中，我有一個從服務器獲取結果的搜索功能。當用戶更新他們的查詢時，搜索會更新，因此這會導致連續發出多個請求。所以我的問題是，如何確保在這些連接上使用 TCP keep-alive？我想盡可能減少延遲，因此在第一個請求之后保持連接并在后續請求中重用連接非常重要。我正在使用 NSURLSession，我聽說它默認使用 keep-alive，但我怎么知道呢？在服務器上記錄請求顯示每個連續請求之間沒有區別，但我不希望僅從標頭信息中看到任何變化。這里有什么幫助嗎？我在我的服務器上使用 Go，所以它可能也需要在該端進行一些額外的配置。
2 回答
白豬掌柜的
TA貢獻1893條經驗 獲得超10個贊
我相信您將 TCP 保持連接與 HTTP 保持連接（持久連接）混淆了。這些是不相關的概念。從您的問題來看，您的意思可能是 HTTP 持久連接。
在 HTTP/1.1 中，持久連接是默認設置NSURLSession，幾乎每個 HTTP/1.1 客戶端都使用它。你必須要求關閉它們。您可以檢查一個Connection: close在HTTP標頭，或者在服務器端，您可以檢查Close的領域http.Request。但我相信你會得到持久的連接。這意味著您不必為每個請求重新協商 TLS 隧道（或至少是 TCP 三向握手）。（盡管如果您發出并行請求，仍然需要協商多個連接。HTTP/1.1 一次只能處理一件事，并且NSURLSession會嘗試使用連接池來提高響應時間。）
TCP keep-alives 是完全不同的事情。它會定期向另一端發送“ping”以確保它仍然可以訪問。有很多方法可以讓您失去網絡連接，并且直到您下次嘗試通信時才知道，通常的癥狀是連接掛起，您需要超時。理論上，TCP keep-alive 只是發現這一點的工具，但我幾乎從未發現它實用。很難正確配置（尤其是在 Cocoa 中）。您幾乎總是需要為您的應用程序構建更高級別的“ping”功能，而不是依賴于此。
但是把它解決你的問題，HTTP/1.1 可能對你來說很好，但是你需要仔細管理你的響應。如果你對每封信都提出一個新的請求并發回大量的回復，那么這會很糟糕。您將讓所有連接池忙于下載您要扔掉的東西。你需要首先關注好的算法。至少，您可能只想一次發送幾個結果，并在您的 API 中提供“分頁”方法，以便為同一搜索請求更多結果。
- 2 回答
- 0 關注
- 236 瀏覽
添加回答
舉報
0/150
提交
取消