ACM_Someone like you

在ios平臺上做網絡開發最常用的兩個類：

NSMutableURLRequest *urlRequest = [[NSMutableURLRequestalloc] initWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicytimeoutInterval:10];  
NSURLConnection *_connection = [[NSURLConnectionalloc] initWithRequest:urlRequest delegate:selfstartImmediately:YES]; 

   一個用來創建請求，一個用來將請求發送出去。然后我們實現 NSUrlConnectionDelegate 的幾個回調函數就能完成整個流程了。

   一般發送網絡請求都會去設置一個超時時間，防止請求在那一直等待。根據不同的場景，我們還需要設置不同的超時時間。在上面的代碼中我們設置了10秒超時。




   上面的故事看起來很完美。但是 apple的開發人員在這里給我們挖了一個坑。

如果你的請求是個簡單的“Get”請求，或者木有 body的“post”請求。一切都是那么完美，請求能夠按照我們設定的時間自動超時。但是如果你發的是個“POST”請求，并且[urlRequest setHTTPBody:httpBody]; 那么，不好意思，你被潛規則了。




   ios3.0 以后 蘋果的sdk對這種情況做了調整，如果是post請求，并且設置了 httpBody，那么請求的超時時間就被默認設置為 240 秒了。就算你再使用[urlRequest setTimeoutInterval:10];也是無效的，我們可以再設置完成后再讀取這個值，發現它不會變成10，依然保持240秒。于是乎，網絡不穩定的時候，你的程序就可能會陷入漫長的等待。




   發現這個問題后。我們通過自己起timer的方式來控制超時。具體怎么弄這里就不細說。只說下我們的策略。

我們將整個網絡過程分為  鏈接建立，發送數據，數據發送完成等待回包，接收數據 4個階段來控制具體的超時。




設置我們的標準超時時間為 N （系統默認為 10秒，網絡模塊通過暴露相關接口，調用方可自由設置）




    鏈接建立鏈接超時時間：    N * 1.5

    每數據包發送超時時間：    N * 1.5

    數據發送完成等帶回包超時： N * 2

    每數據包接收超時時間：    N * 1




以上超時分別在 NSUrlConnectionDelegate 的各個回調階段進行相關設置就能達到比較精細的控制。

特別說明下，為什么數據發送完成后等待回包的超時會設置的比較長。因為在實際測試過程中發現發包完成到接收到第一個數據包比較耗時，一般httpbody越大越明顯，初步猜測是網絡模塊在發送數據緩沖區的數據，所以這里做了特殊的控制。




哦了。羅嗦了半天，終于說完了。希望能對大家有幫助。能跳過這個坑。