作為騰訊無(wú)線(xiàn)的一名研發(fā)人員，我和我們的團隊在開(kāi)發(fā)和運營(yíng)過(guò)程中碰到了一些有線(xiàn)網(wǎng)絡(luò )環(huán)境碰不到的問(wèn)題，也積累了一些經(jīng)驗，希望分享給大家。
我們經(jīng)常碰到的網(wǎng)絡(luò )問(wèn)題都和網(wǎng)關(guān)有關(guān)，由于無(wú)線(xiàn)網(wǎng)關(guān)設備的供應商很多（華為，中興，諾西等），難免存在不同的限制和規則，而且一旦發(fā)現問(wèn)題，設備的更新速度也比較慢，但業(yè)務(wù)又需要快速調整，所以要想辦法兼容這些規則。
首先對兩個(gè)出現比較多的名詞解釋下：
接入點(diǎn)（apn）：上網(wǎng)方式，常見(jiàn)的有cmwap，cmnet，ctwap，ctnet，3gnet，3gwap等。
Wap網(wǎng)關(guān)：在用戶(hù)手機和業(yè)務(wù)服務(wù)器中間的一個(gè)代理層，在這里會(huì )控制一些計費，頭部轉換等。
1.關(guān)于網(wǎng)關(guān)限制回包和限制上傳包的大小
機制回溯：國內幾乎所有廠(chǎng)家的網(wǎng)關(guān)都有一個(gè)開(kāi)關(guān)，可以來(lái)設置用戶(hù)上傳數據或服務(wù)器返回數據的大小，如果超過(guò)大小就截斷或者直接失敗，例如諾西的一些網(wǎng)關(guān)限制回包為3M，華為部分是10M，有些沒(méi)有打開(kāi)這個(gè)開(kāi)關(guān)。原因主要是性能問(wèn)題，因為網(wǎng)關(guān)的策略一般是把數據包收全后發(fā)給用戶(hù)或者服務(wù)器，那么對于高并發(fā)的請求以及大量的用戶(hù)，一旦下載或者上傳增加，那么系統內存必然是個(gè)瓶頸，所以用限制大小來(lái)緩解，這個(gè)在設備上修改的難度也很大。
導致問(wèn)題：用戶(hù)經(jīng)常下載失敗或者下載成功了安裝失敗，上傳的時(shí)候直接提示錯誤，小圖成功，大圖失敗等。
開(kāi)發(fā)建議：下載包那個(gè)實(shí)在是沒(méi)有辦法了，現在安卓和愛(ài)瘋的包動(dòng)不動(dòng)就十幾兆，所以還是推薦支持斷電續傳，通過(guò)多次少量來(lái)下載，這樣可以提高成功率，也是運營(yíng)商推薦的做法。上傳有點(diǎn)矛盾，高清無(wú)碼是我們的追求，但是大小限制擺在這里，建議是有限壓縮，分片上傳，也是用迂回的策略來(lái)提高成功率，讓用戶(hù)無(wú)碼。
2.關(guān)于資費提醒頁(yè)面，業(yè)務(wù)推薦頁(yè)面，網(wǎng)絡(luò )歡迎頁(yè)面
機制回溯：這里的問(wèn)題也是出現在當月第一次聯(lián)網(wǎng)或者當天第一次聯(lián)網(wǎng)的時(shí)候（具體視網(wǎng)關(guān)配置而定），用戶(hù)聯(lián)網(wǎng)的時(shí)候如果訪(fǎng)問(wèn)的域名或者ip不在資費提醒白名單中，則會(huì )出現資費提醒頁(yè)面或者是歡迎頁(yè)面，而這個(gè)時(shí)候用戶(hù)需要手動(dòng)點(diǎn)一下允許才能通過(guò)這個(gè)頁(yè)面，具體的引導多為302和直接200返回提醒頁(yè)面。
導致問(wèn)題：這里的問(wèn)題就是我們的請求拿到的并不是我們希望返回的數據，而且在有些提醒中，如果用戶(hù)不點(diǎn)擊允許，只是重連，多少次也還是會(huì )有這個(gè)提醒，這就導致了如果終端支持go也支持了重連，但是仍然會(huì )失敗。
開(kāi)發(fā)建議：支持go和重連同時(shí)post盡量不放第一個(gè)請求，另外加上重試次數的限制，比如重試5次都失敗，則頁(yè)面上提示用戶(hù)用瀏覽器打開(kāi)或者直接調用系統瀏覽器來(lái)打開(kāi)網(wǎng)址，很有可能就會(huì )涉及需要用戶(hù)主動(dòng)點(diǎn)擊的頁(yè)面，然后再回來(lái)軟件內部進(jìn)行操作。
3.關(guān)于x-online-host頭部的作用和設定
機制回溯：這個(gè)字段算是wap方式下一個(gè)特殊產(chǎn)物了，因為wap網(wǎng)關(guān)全部代理了手機的上網(wǎng)行為，也就是任何訪(fǎng)問(wèn)都會(huì )到10.0.0.172（類(lèi)似這個(gè)）去接受網(wǎng)關(guān)的代理，如果需要往其他域名發(fā)送請求就有問(wèn)題，因為請求都要用
http://10.0.0.172/xxxxxxx類(lèi)似的格式發(fā)到網(wǎng)關(guān)，那么網(wǎng)關(guān)就沒(méi)有辦法知道要訪(fǎng)問(wèn)的真實(shí)目標域名，于是就有了xonline這個(gè)頭，讓業(yè)務(wù)把目標的域名放在這個(gè)頭部里面，然后由網(wǎng)關(guān)解析：如果沒(méi)有http://的話(huà)，則作為相對URI，用X-Online-Host字段進(jìn)行補全；如果有http://字段的話(huà)，則將host替換為X-Online-Host的值。
導致問(wèn)題：現在網(wǎng)關(guān)基本都有優(yōu)化，如果沒(méi)有這個(gè)頭也沒(méi)有關(guān)系，不過(guò)在工作中還是碰到了幾個(gè)與之相關(guān)的問(wèn)題，2011年有一段時(shí)間如果在cmwap接入點(diǎn)下不加x-online-host頭，則手機側發(fā)送任何post包都會(huì )直接被拒絕，另外還有一個(gè)問(wèn)題就是這里中劃線(xiàn)還是下劃線(xiàn)的問(wèn)題，應該是中劃線(xiàn)，但是有些網(wǎng)關(guān)碰到下劃線(xiàn)也能正常工作，不過(guò)不能保證。
開(kāi)發(fā)建議：判斷用戶(hù)的聯(lián)網(wǎng)方式，如果是wap方式則將x-online-host頭加上，內容為業(yè)務(wù)具體的域名。另外推薦一種做法，服務(wù)器拿到用戶(hù)ip后計算出合適的服務(wù)器ip給用戶(hù)，然后用戶(hù)采用直接ip的方式來(lái)訪(fǎng)問(wèn)，同時(shí)還能減少域名解析的時(shí)間。
4.關(guān)于serverlist以及寫(xiě)死服務(wù)器ip
機制回溯：這個(gè)不用多說(shuō)，相信大家都被放出去的終端版本里面有寫(xiě)死ip，導致遷移難，故障恢復難的事情困擾過(guò)。
導致問(wèn)題：難容災，不方便遷移，而且一旦沒(méi)有記錄，后續撤銷(xiāo)服務(wù)器的時(shí)候會(huì )因為不知道哪里來(lái)的訪(fǎng)問(wèn)而頭疼。
開(kāi)發(fā)建議：支持可以配置的serverlist。大部分產(chǎn)品的做法是下發(fā)serverlist，客戶(hù)端按照順序嘗試，比如聯(lián)通的用戶(hù)給下發(fā)依次為聯(lián)通、電信、移動(dòng)的服務(wù)器，如果聯(lián)通服務(wù)器失敗則走電信，然后如果全部失敗需要有一個(gè)域名解析作為備份策略，以防失敗的時(shí)候能夠從域名的dns來(lái)控制用戶(hù)的訪(fǎng)問(wèn)。當然serverlist如何下發(fā)，客戶(hù)端按照什么方式來(lái)請求需要單獨考慮。
5.關(guān)于泛域名解析的一個(gè)潛規則
機制回溯：android自帶瀏覽器以及部分瀏覽器不能解析cname到泛域名的域名。比如a.qq.com cname到*.qq.com，那么瀏覽器在訪(fǎng)問(wèn)a.qq.com就會(huì )出錯。（關(guān)于泛域名，其實(shí)就是如果xxx.qq.com沒(méi)有單獨申請解析，但是*這個(gè)泛域名有解析那么就會(huì )走*，這個(gè)可以減少域名解析申請工作）。
導致問(wèn)題：域名訪(fǎng)問(wèn)失敗。
開(kāi)發(fā)建議：盡量避免cname到一個(gè)泛域名。
6.關(guān)于wap網(wǎng)關(guān)主動(dòng)超時(shí)斷開(kāi)或者超時(shí)重連
機制回溯：wap網(wǎng)關(guān)上通常有一個(gè)設定，是關(guān)于和手機之間的超時(shí)的設定，具體就是當tcp鏈接建立以后如果一段時(shí)間沒(méi)有任何數據交互，則網(wǎng)關(guān)會(huì )主動(dòng)發(fā)送fin或者rst關(guān)閉這個(gè)tcp鏈接，這里主動(dòng)發(fā)送是指分別向手機和服務(wù)器各發(fā)送結束包。這里一段時(shí)間可能是15s或者30s不等。目的是為網(wǎng)關(guān)節省tcp established的鏈接。
導致問(wèn)題：第一是對于主動(dòng)使用keepalive頭的應用，一般keepalive的鏈接，服務(wù)器發(fā)完數據后不會(huì )主動(dòng)去斷開(kāi)這個(gè)鏈接，中間如果沒(méi)有數據的時(shí)候很可能被網(wǎng)關(guān)主動(dòng)斷開(kāi)，導致訪(fǎng)問(wèn)耗時(shí)增加。第二是對于有長(cháng)連接的應用比如手機QQ，問(wèn)題也是沒(méi)有數據的時(shí)候被網(wǎng)關(guān)斷開(kāi)，增加耗時(shí)。第三是有些信號差的地方手機到網(wǎng)關(guān)中間質(zhì)量不太好，會(huì )有短暫沒(méi)有數據的情況，網(wǎng)關(guān)也會(huì )主動(dòng)關(guān)閉，導致訪(fǎng)問(wèn)失敗，比如軟件下載這種耗時(shí)比較長(cháng)的應用。
開(kāi)發(fā)建議：斷開(kāi)鏈接一般只會(huì )導致耗時(shí)增高，因為需要重新建立鏈接，重新dns等，所以一般業(yè)務(wù)不用十分在意，對于延時(shí)有較高要求，且對于鏈接保持有要求的應用應該考慮定期的數據交互，比如每15s中在同一個(gè)鏈接上發(fā)送心跳等策略，當然流量需要另外考慮。
7.關(guān)于server端開(kāi)發(fā)和服務(wù)器設定的一些建議
機制回溯：這里主要還是因為網(wǎng)關(guān)功能比較多，經(jīng)常出問(wèn)題的：經(jīng)過(guò)網(wǎng)關(guān)后一個(gè)訪(fǎng)問(wèn)可能由相對路徑變成全路徑訪(fǎng)問(wèn)，也就是會(huì )出現由GET /qcy.jsp變成GET
http://a.qq.com/qcy.jsp這樣的全路徑；經(jīng)過(guò)網(wǎng)關(guān)后一些訪(fǎng)問(wèn)請求里面的特殊字符可能會(huì )被轉義，比如空格變成%20之類(lèi)；經(jīng)過(guò)網(wǎng)關(guān)后http header里面的字段可能由首字母大寫(xiě)變成小寫(xiě)，從Host變成host這樣。
造成問(wèn)題：如果服務(wù)器不支持，訪(fǎng)問(wèn)就會(huì )失敗，404或者500返回。
開(kāi)發(fā)建議：服務(wù)器需要支持絕對路徑訪(fǎng)問(wèn)（rfc標準），要能夠兼容header的大小寫(xiě)。那個(gè)被轉碼沒(méi)有辦法，只能說(shuō)在開(kāi)發(fā)過(guò)程盡量保持大小寫(xiě)的一致（最好都是小寫(xiě)）并且少用特殊字符尤其是空格，最后就是server默認要支持keepalive方式。
服務(wù)器設定：服務(wù)器本身這里只說(shuō)下最關(guān)鍵的tcp快速回收參數（tcp_tw_recycle），部署在最前面和用戶(hù)直接交互的機器（接入層，或者對外提供服務(wù)的機器）這個(gè)參數必須要0，關(guān)閉。原因就是網(wǎng)關(guān)是屬于很多用戶(hù)公用一個(gè)出口的，時(shí)間戳會(huì )對系統的判斷造成影響，可能導致服務(wù)器一個(gè)時(shí)間只給最新時(shí)間戳的服務(wù)，其他都直接回收。另外，對于下載類(lèi)的
server，最好放棄關(guān)于一個(gè)鏈接超時(shí)的設置，在無(wú)線(xiàn)環(huán)境下多久的時(shí)間也有，比如下載一個(gè)20M的需要幾個(gè)小時(shí)，是可能的，需要特別關(guān)注下。
8.關(guān)于數據大小對于用戶(hù)速度和成功率的影響
機制回溯：正是因為在無(wú)線(xiàn)環(huán)境中用戶(hù)的包往往需要經(jīng)過(guò)幾百ms才能到服務(wù)器，這里就可以想到在tcp鏈接中，客戶(hù)端的一個(gè)ack有多值錢(qián)，如果一個(gè)請求被分成了10個(gè)包，假設客戶(hù)端回復了三個(gè)ack，那么就光這里就耗去了大概兩秒鐘，而且等待ack的過(guò)程中基本訪(fǎng)問(wèn)是卡住的。另外就是多一次來(lái)回失敗率也會(huì )上升的。
導致問(wèn)題：體驗差，訪(fǎng)問(wèn)慢，失敗率高。
開(kāi)發(fā)建議：首先控制回復的數據的大小，這是重中之重；用gzip來(lái)盡量縮小回包；另外就是想辦法調優(yōu)tcp協(xié)議，讓客戶(hù)端需要發(fā)的ack盡量少，但是這里很大程度和手機系統的實(shí)現還相關(guān)，這里沒(méi)有太多嘗試過(guò)，能做的應該是調大初始窗口，發(fā)送緩存，加快重傳的時(shí)間間隔等，讓一次性盡可能發(fā)更多的數據，發(fā)現問(wèn)題后也能盡快發(fā)起重傳。
希望這些經(jīng)驗能對剛進(jìn)入無(wú)線(xiàn)領(lǐng)域的朋友有所幫助。
