IPHONE手機電視提示緩沖而無法繼續(xù)觀看問題分析

1、IPHONE手機電視提示緩沖而無法繼續(xù)觀看問題分析1月4日馬鞍山分公司反映使用IPHONE手機看電視時經(jīng)常數(shù)據(jù)緩沖而無法繼續(xù)觀看，經(jīng)分析初步判斷是RAB拆鏈可能會引起IPHONE和手機電視平臺間TCP會話問題，而導致業(yè)務(wù)異常終止。繼續(xù)分析TCP會話過程，產(chǎn)生問題的原因是IPHONE在RAB沒有拆除后發(fā)的TCP連接時會發(fā)兩個重復的建鏈請求（兩個一樣的SYN報文），電視平臺側(cè)可能有負載分擔機制，可能會把這兩個請求轉(zhuǎn)到不同的電視服務(wù)器上，可能導致TCP會話異常。IPHONE看手機電視流程分析通過消息看IPHONE連接手機電視時通過3GNET連接到公網(wǎng)網(wǎng)站。過程如下：手機通過3GNET進行PDP上下文

2、激活打開 HYPERLINK 頁面時，返回網(wǎng)頁腳本如下：if (site_host=site_url1|site_host=site_url2) if (userAgent.indexOf(iPhone)0) window.location=; else window.location=; 普通手機會直接轉(zhuǎn)到 HYPERLINK ，IPHONE手機會轉(zhuǎn)到iP，然后在點擊手機電視后連接到網(wǎng)站。 然后點擊WEB網(wǎng)頁中的電視節(jié)目消息，通過不斷獲取節(jié)目數(shù)據(jù)塊文件名，通過TCP方式收看數(shù)據(jù)文件（普通手機一般使用RTP方式）。過程如下：獲取電視節(jié)目最新數(shù)據(jù)塊文件名。GET /video1/index_12

3、8k.m3u8?username=&random=20100106140807039102&ip=&date=20100106180807&key=f730484fdaeae3243da2e3f3d32e072b 得到結(jié)果為：#EXTM3U#EXT-X-TARGETDURATION:10#EXT-X-MEDIA-SEQUENCE:1739#EXTINF:10/video1/sample_128k-01739.ts#EXTINF:10/video1/sample_128k-01740.ts#EXTINF:10/video1/sample_128k-01741.ts#EXTINF:10/video

4、1/sample_128k-01742.ts#EXTINF:10/video1/sample_128k-01743.ts#EXTINF:10/video1/sample_128k-01744.ts#EXTINF:10/video1/sample_128k-01745.ts#EXTINF:10/video1/sample_128k-01746.ts#EXTINF:10/video1/sample_128k-01747.ts#EXTINF:10/video1/sample_128k-01748.ts#EXTINF:10/video1/sample_128k-01749.ts#EXTINF:10/v

5、ideo1/sample_128k-01750.ts#EXTINF:10/video1/sample_128k-01751.ts#EXTINF:10/video1/sample_128k-01752.ts#EXTINF:10/video1/sample_128k-01753.ts下載最新的數(shù)據(jù)塊文件，第一次從倒數(shù)第三個開始，并在IPHONE手機實時觀看（每個文件塊約為500K左右，10秒鐘播放時間）GET /video1/sample_128k-01751.tsGET /video1/sample_128k-01752.tsGET /video1/sample_128k-01753.ts再次獲

6、取最新數(shù)據(jù)塊文件名，GET /video1/index_128k.m3u8?username=&random=20100106140807039102&ip=&date=20100106180807&key=f730484fdaeae3243da2e3f3d32e072b 問題分析測試中發(fā)現(xiàn)異常情況出現(xiàn)在手機重復獲取M3U8文件的過程中，該文件含有最新數(shù)據(jù)塊文件列表。異常情況出現(xiàn)在手機和電視平臺TCP三次握手后，發(fā)GET請求，平臺不回應，手機在重復三次GET請求后認為平臺異常終止了請求，并終止了本次手機電視業(yè)務(wù)。該TCP會話過程如下：第一個包是平臺發(fā)給手機的TCP握手信號但ACK=0（正常情況

7、下ACK應該=1），同時隨后還發(fā)了一個帶SYN的握手信號而SEQ很大（正常情況下應該為0）。IPHONE因為收到第一個包，所以認為與平臺的TCP連接已建立起來，隨后就發(fā)送GET請求。但平臺重復發(fā)送帶SYN的ACK=0的消息，導致手機不能獲取正常結(jié)果，在GET請求重復三次后斷開，并終止了手機電視業(yè)務(wù)。一般情況下服務(wù)器回應【SYN ACK】報文中ACK=1，但在實際測試中也發(fā)現(xiàn)ACK=0時能獲取業(yè)務(wù)的情況，如：和異常情況比較TCP會話過程一樣，不同的是異常情況下客戶GET后，平臺返回依然返回ACK=0，似乎沒有消息發(fā)出。經(jīng)過總部相關(guān)負責人協(xié)調(diào)，與平臺技術(shù)工程師討論發(fā)現(xiàn)出現(xiàn)異常時均伴隨RAB釋放和建

8、立過程?，F(xiàn)網(wǎng)數(shù)據(jù)業(yè)務(wù)，RNC在用戶鏈路空閑6秒時會發(fā)起RAB釋放過程，把無線資源騰出給其它人使用。IPHONE視頻分成10秒一段，因此系統(tǒng)設(shè)置取M3U文件時是要求間隔10秒，但在無線環(huán)境較好的情況下500K字節(jié)的文件下載時間可能縮短到2秒鐘，這就導致可能有超過6秒不收發(fā)數(shù)據(jù)包的情況，從而會有RAB釋放，當手機在獲取M3U時就需要RAB建立。出現(xiàn)這種現(xiàn)象本身是正常，不會影響應用層消息的交互。如果要避免RAB釋放和建立現(xiàn)象，可以通過修改RNC空閑時間參數(shù)或更改M3U文件獲取的頻率，因RNC參數(shù)是全局的，不能隨意修改?？偛繛榇碎_通一個測試頁面 HYPERLINK http:/live.wovo.tv

9、/ahtest.html http:/live.wovo.tv/ahtest.html，其M3U文件控制內(nèi)容修改為：#EXTM3U#EXT-X-TARGETDURATION:5#EXT-X-MEDIA-SEQUENCE:187#EXTINF:5時間間隔改為5秒。隨后請馬鞍山公司協(xié)助測試，測試20分鐘沒出現(xiàn)異常情況。TCP會話異常分析在出現(xiàn)異常時經(jīng)常丟失手機發(fā)出的SYN報文，后經(jīng)分析是RNC在發(fā)RAB建立成功消息前，先傳送了數(shù)據(jù)包報文，導致抓包不全。因此TCP會話分析使用Gn口抓包消息。IPHONE GET請求無響應的完整過程為：1、首先手機從TCP 49185端口向24連續(xù)發(fā)送了兩個TCP S

10、YN請求（只有在RAB需要重新建立時才出現(xiàn)，正常時只發(fā)一個）2、24也回了兩個TCP SYN ACK，但這兩個SYN ACK中24本端的TCP SEQ NUM不一致（因此判讀是不同的服務(wù)器返回的）3、手機向24再回了兩個ACK，其中確認SEQ NUM全部為序號9325這個TCP的，也就是24回的第一個SYN ACK的本端SEQ NUM。（手機選擇第一個返回的SYN ACK請求為本次TCP會話的對端）4、再往后手機發(fā)出了GET請求，4秒鐘內(nèi)還沒有得到響應，并且24在包序號為9332的消息中重發(fā)了一條SYN ACK，手機予以ACK響應。（負載均衡器選擇了和手機不一致的服務(wù)器）5、24在包序號為93

11、34的消息中又重發(fā)了一條SYN ACK，手機在9335中予以ACK響應6、后面是手機的GET消息重發(fā)過程以及TCP連接關(guān)閉請求從上面的消息過程看，當手機發(fā)往服務(wù)器的兩個TCP SYN請求，存在兩個服務(wù)器側(cè)的TCP SYN ACK，這兩個TCP SYN的區(qū)別如下：第一條SYN ACK的TCP本端序號為0X6CB978EF，TTL為53第二條SYN ACK的TCP本端序號為0XB5859630,TTL為52由于TCP本端序號應在TCP實體上產(chǎn)生，因此這兩個SYN ACK的序號為兩個不同的手機電視服務(wù)器產(chǎn)生，24這個地址是一個手機電視平臺對外暴露的公共地址，這個地址對應的設(shè)備具備負責均衡功能，可將消

12、息、數(shù)據(jù)分發(fā)到不同的手機電視服務(wù)器上TCP連接用五元組區(qū)分，即源IP地址，源端口，目的IP地址，目的端口，協(xié)議類型。同一時間也只能由一個五元組的TCP會話。當手機選的TCP連接和負載均衡器選的TCP連接不一樣時，TCP會話就無法建立了。如圖：RAB重建后IPHONE手機和平臺側(cè)的處理此時IPHONE發(fā)的SYN是重復的希望建立一個TCP會話，而負載均衡器處理后變成向兩個SERVER的兩個TCP會話過程。2、IPHONE手機TCP建立和平臺負載服務(wù)器選擇一致時會話成功 TCP由五元組識別，IPHONE并不知道回應來自不同SERVER，也不可能去建兩個TCP會話，它會認為與第一個返回SYN ACK回應報文的服務(wù)器建立連接，返回的消息。負責均衡處理機制應該也會根據(jù)五元組以及負載映射關(guān)系找到處理的服務(wù)器，如果它找對了這次會話過程就成功了。IPHONE手機TCP建立和平臺負載服務(wù)器選擇不一致時會話失敗負責均衡處理機制應該也會根據(jù)五元組以及負載映射關(guān)系找到處理的服務(wù)器，如果它找錯了這次會話過程就失敗了。解決方案產(chǎn)生問題的原因是IPHONE在RAB沒有拆除后發(fā)的TCP連接時會發(fā)兩個重復的建鏈請求（兩個一樣的SYN報文），電視平臺側(cè)可能有負載分擔機制，可能會把這兩個請求轉(zhuǎn)到不同的電視服務(wù)器上，可能導致