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

1、.：.； IPHONE手機電視提示緩沖而無法繼續(xù)觀看問題分析1月4日馬鞍山分公司反映運用IPHONE手機看電視時經(jīng)常數(shù)據(jù)緩沖而無法繼續(xù)觀看，經(jīng)分析初步判別是RAB拆鏈能夠會引起IPHONE和手機電視平臺間TCP會話問題，而導致業(yè)務異常終止。繼續(xù)分析TCP會話過程，產(chǎn)生問題的緣由是IPHONE在RAB沒有撤除后發(fā)的TCP銜接時會發(fā)兩個反復的建鏈懇求兩個一樣的SYN報文，電視平臺側能夠有負載分擔機制，能夠會把這兩個懇求轉到不同的電視效力器上，能夠導致TCP會話異常。IPHONE看手機電視流程分析經(jīng)過音訊看IPHONE銜接手機電視時經(jīng)過3GNET銜接到公網(wǎng)itv.wo網(wǎng)站。過程如下：手機經(jīng)過3GNE

2、T進展PDP上下文激活翻開 HYPERLINK wo wo頁面時，前往網(wǎng)頁腳本如下： if (site_host=site_url1|site_host=site_url2) if (userAgent.indexOf(iPhone)0) window.location=iphone.wo; else window.location=10010; 普通手時機直接轉到 HYPERLINK 10010 10010，IPHONE手時機轉到iPhone.wo，然后在點擊手機電視后銜接到itv.wo網(wǎng)站。 然后點擊WEB網(wǎng)頁中的電視節(jié)目音訊，經(jīng)過不斷獲取節(jié)目數(shù)據(jù)塊文件名，經(jīng)過TCP方式收看數(shù)據(jù)文件普通手

3、機普通運用RTP方式。過程如下：獲取電視節(jié)目最新數(shù)據(jù)塊文件名。GET /video1/index_128k.m3u8?username=&random=20210106140807039102&ip=58.243.254.6&date=20210106180807&key=f730484fdaeae3243da2e3f3d32e072b 得到結果為：#EXTM3U#EXT-X-TARGETDURATION:10#EXT-X-MEDIA-SEQUENCE:1739#EXTINF:10cctv1.itv.wo/video1/sample_128k-01739.ts#EXTINF:10cctv1.i

4、tv.wo/video1/sample_128k-01740.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01741.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01742.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01743.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01744.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01745.ts#EXTINF:10cctv1.i

5、tv.wo/video1/sample_128k-01746.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01747.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01748.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01749.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01750.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01751.ts#EXTINF:10cctv1.i

6、tv.wo/video1/sample_128k-01752.ts#EXTINF:10cctv1.itv.wo/video1/sample_128k-01753.ts下載最新的數(shù)據(jù)塊文件，第一次從倒數(shù)第三個開場，并在IPHONE手機實時觀看每個文件塊約為500K左右，10秒鐘播放時間 GET /video1/sample_128k-01751.ts GET /video1/sample_128k-01752.tsGET /video1/sample_128k-01753.ts再次獲取最新數(shù)據(jù)塊文件名， GET /video1/index_128k.m3u8?username=&random=2

7、0210106140807039102&ip=58.243.254.6&date=20210106180807&key=f730484fdaeae3243da2e3f3d32e072b 問題分析測試中發(fā)現(xiàn)異常情況出如今手機反復獲取M3U8文件的過程中，該文件含有最新數(shù)據(jù)塊文件列表。異常情況出如今手機和電視平臺TCP三次握手后，發(fā)GET懇求，平臺不回應，手機在反復三次GET懇求后以為平臺異常終止了懇求，并終止了本次手機電視業(yè)務。該TCP會話過程如下：第一個包是平臺發(fā)給手機的TCP握手信號但ACK=0正常情況下ACK應該=1，同時隨后還發(fā)了一個帶SYN的握手信號而SEQ很大正常情況下應該為0。IP

8、HONE由于收到第一個包，所以以為與平臺的TCP銜接已建立起來，隨后就發(fā)送GET懇求。但平臺反復發(fā)送帶SYN的ACK=0的音訊，導致手機不能獲取正常結果，在GET懇求反復三次后斷開，并終止了手機電視業(yè)務。普通情況下效力器回應【SYN ACK】報文中ACK=1，但在實踐測試中也發(fā)現(xiàn)ACK=0時能獲取業(yè)務的情況，如：和異常情況比較TCP會話過程一樣，不同的是異常情況下客戶GET后，平臺前往依然前往ACK=0，似乎沒有音訊發(fā)出。經(jīng)過總部相關擔任人協(xié)調，與平臺技術工程師討論發(fā)現(xiàn)出現(xiàn)異常時均伴隨RAB釋放和建立過程。現(xiàn)網(wǎng)數(shù)據(jù)業(yè)務，RNC在用戶鏈路空閑6秒時會發(fā)起RAB釋放過程，把無線資源騰出給其它人運用

9、。IPHONE視頻分成10秒一段，因此系統(tǒng)設置取M3U文件時是要求間隔10秒，但在無線環(huán)境較好的情況下500K字節(jié)的文件下載時間能夠縮短到2秒鐘，這就導致能夠有超越6秒不收發(fā)數(shù)據(jù)包的情況，從而會有RAB釋放，當手機在獲取M3U時就需求RAB建立。出現(xiàn)這種景象本身是正常，不會影響運用層音訊的交互。假設要防止RAB釋放和建立景象，可以經(jīng)過修正RNC空閑時間參數(shù)或更改M3U文件獲取的頻率，因RNC參數(shù)是全局的，不能隨意修正?？偛繛榇碎_通一個測試頁面 HYPERLINK live.wovo.tv/ahtest.html live.wovo.tv/ahtest.html，其M3U文件控制內容修正為：#E

10、XTM3U#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端口向114.247.0.124延續(xù)發(fā)送了兩個TCP SYN懇求只需在RAB需求重新建立時才出現(xiàn)，正常時只發(fā)一個2、114.247.0.124也回了兩個

11、TCP SYN ACK，但這兩個SYN ACK中114.247.0.124本端的TCP SEQ NUM不一致因此判讀是不同的效力器前往的3、手機向114.247.0.124再回了兩個ACK，其中確認SEQ NUM全部為序號9325這個TCP的，也就是114.247.0.124回的第一個SYN ACK的本端SEQ NUM。手機選擇第一個前往的SYN ACK懇求為本次TCP會話的對端4、再往后手機發(fā)出了GET懇求，4秒鐘內還沒有得到呼應，并且114.247.0.124在包序號為9332的音訊中重發(fā)了一條SYN ACK，手機予以ACK呼應。負載平衡器選擇了和手機不一致的效力器5、114.247.0.

12、124在包序號為9334的音訊中又重發(fā)了一條SYN ACK，手機在9335中予以ACK呼應6、后面是手機的GET音訊重發(fā)過程以及TCP銜接封鎖懇求 從上面的音訊過程看，當手機發(fā)往效力器的兩個TCP SYN懇求，存在兩個效力器側的TCP SYN ACK，這兩個TCP SYN的區(qū)別如下：第一條SYN ACK的TCP本端序號為0X6CB978EF，TTL為53第二條SYN ACK的TCP本端序號為0XB5859630,TTL為52由于TCP本端序號應在TCP實體上產(chǎn)生，因此這兩個SYN ACK的序號為兩個不同的手機電視效力器產(chǎn)生，114.247.0.124這個地址是一個手機電視平臺對外暴露的公共地址

13、，這個地址對應的設備具備擔任平衡功能，可將音訊、數(shù)據(jù)分發(fā)到不同的手機電視效力器上 TCP銜接用五元組區(qū)分，即源IP地址，源端口，目的IP地址，目的端口，協(xié)議類型。同一時間也只能由一個五元組的TCP會話。當手機選的TCP銜接和負載平衡器選的TCP銜接不一樣時，TCP會話就無法建立了。如圖：RAB重建后IPHONE手機和平臺側的處置此時IPHONE發(fā)的SYN是反復的希望建立一個TCP會話，而負載平衡器處置后變成向兩個SERVER的兩個TCP會話過程。2、IPHONE手機TCP建立和平臺負載效力器選擇一致時會話勝利 TCP由五元組識別，IPHONE并不知道回應不同SERVER，也不能夠去建兩個TCP會話，它會以為與第一個前往SYN ACK回應報文的效力器建立銜接，前往的音訊。擔任平衡處置機制應該也會根據(jù)五元組以及負載映射關系找四處置的效力器，假設它找對了這次會話過程就勝利了。IPHONE手機TCP建立和平臺負載效力器選擇不一致時會話失敗 擔任平衡處置機制應該也會根據(jù)五元組以及負載映射關系找四處置的效力器，假設它找錯了這次會話過程就失敗了。 處理方案產(chǎn)生問題的緣由是IPHONE在RAB沒有撤除后發(fā)的TCP銜接時會發(fā)兩個反復的建鏈懇求兩個一樣的SYN報文，電視平臺側能夠有負載分擔機制，能夠會把這兩個懇求