IPHONE手机电视提示缓冲而无法继续观看问题分析

1、.：.； IPHONE手机电视提示缓冲而无法继续观看问题分析1月4日马鞍山分公司反映运用IPHONE手机看电视时经常数据缓冲而无法继续观看，经分析初步判别是RAB拆链能够会引起IPHONE和手机电视平台间TCP会话问题，而导致业务异常终止。继续分析TCP会话过程，产生问题的缘由是IPHONE在RAB没有撤除后发的TCP衔接时会发两个反复的建链恳求两个一样的SYN报文，电视平台侧能够有负载分担机制，能够会把这两个恳求转到不同的电视效力器上，能够导致TCP会话异常。IPHONE看手机电视流程分析经过音讯看IPHONE衔接手机电视时经过3GNET衔接到公网itv.wo网站。过程如下：手机经过3GNE

2、T进展PDP上下文激活翻开 HYPERLINK wo wo页面时，前往网页脚本如下： 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网站。 然后点击WEB网页中的电视节目音讯，经过不断获取节目数据块文件名，经过TCP方式收看数据文件普通手

3、机普通运用RTP方式。过程如下：获取电视节目最新数据块文件名。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下载最新的数据块文件，第一次从倒数第三个开场，并在IPHONE手机实时观看每个文件块约为500K左右，10秒钟播放时间 GET /video1/sample_128k-01751.ts GET /video1/sample_128k-01752.tsGET /video1/sample_128k-01753.ts再次获取最新数据块文件名， GET /video1/index_128k.m3u8?username=&random=2

7、0210106140807039102&ip=58.243.254.6&date=20210106180807&key=f730484fdaeae3243da2e3f3d32e072b 问题分析测试中发现异常情况出如今手机反复获取M3U8文件的过程中，该文件含有最新数据块文件列表。异常情况出如今手机和电视平台TCP三次握手后，发GET恳求，平台不回应，手机在反复三次GET恳求后以为平台异常终止了恳求，并终止了本次手机电视业务。该TCP会话过程如下：第一个包是平台发给手机的TCP握手信号但ACK=0正常情况下ACK应该=1，同时随后还发了一个带SYN的握手信号而SEQ很大正常情况下应该为0。IP

8、HONE由于收到第一个包，所以以为与平台的TCP衔接已建立起来，随后就发送GET恳求。但平台反复发送带SYN的ACK=0的音讯，导致手机不能获取正常结果，在GET恳求反复三次后断开，并终止了手机电视业务。普通情况下效力器回应【SYN ACK】报文中ACK=1，但在实践测试中也发现ACK=0时能获取业务的情况，如：和异常情况比较TCP会话过程一样，不同的是异常情况下客户GET后，平台前往依然前往ACK=0，似乎没有音讯发出。经过总部相关担任人协调，与平台技术工程师讨论发现出现异常时均伴随RAB释放和建立过程。现网数据业务，RNC在用户链路空闲6秒时会发起RAB释放过程，把无线资源腾出给其它人运用

9、。IPHONE视频分成10秒一段，因此系统设置取M3U文件时是要求间隔10秒，但在无线环境较好的情况下500K字节的文件下载时间能够缩短到2秒钟，这就导致能够有超越6秒不收发数据包的情况，从而会有RAB释放，当手机在获取M3U时就需求RAB建立。出现这种景象本身是正常，不会影响运用层音讯的交互。假设要防止RAB释放和建立景象，可以经过修正RNC空闲时间参数或更改M3U文件获取的频率，因RNC参数是全局的，不能随意修正。总部为此开通一个测试页面 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秒。随后请马鞍山公司协助测试，测试20分钟没出现异常情况。 TCP会话异常分析在出现异常时经常丧失手机发出的SYN报文，后经分析是RNC在发RAB建立胜利音讯前，先传送了数据包报文，导致抓包不全。因此TCP会话分析运用Gn口抓包音讯。IPHONE GET恳求无呼应的完好过程为：1、首先手机从TCP 49185端口向114.247.0.124延续发送了两个TCP SYN恳求只需在RAB需求重新建立时才出现，正常时只发一个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、再往后手机发出了GET恳求，4秒钟内还没有得到呼应，并且114.247.0.124在包序号为9332的音讯中重发了一条SYN ACK，手机予以ACK呼应。负载平衡器选择了和手机不一致的效力器5、114.247.0.

12、124在包序号为9334的音讯中又重发了一条SYN ACK，手机在9335中予以ACK呼应6、后面是手机的GET音讯重发过程以及TCP衔接封锁恳求 从上面的音讯过程看，当手机发往效力器的两个TCP SYN恳求，存在两个效力器侧的TCP SYN ACK，这两个TCP SYN的区别如下：第一条SYN ACK的TCP本端序号为0X6CB978EF，TTL为53第二条SYN ACK的TCP本端序号为0XB5859630,TTL为52由于TCP本端序号应在TCP实体上产生，因此这两个SYN ACK的序号为两个不同的手机电视效力器产生，114.247.0.124这个地址是一个手机电视平台对外暴露的公共地址

13、，这个地址对应的设备具备担任平衡功能，可将音讯、数据分发到不同的手机电视效力器上 TCP衔接用五元组区分，即源IP地址，源端口，目的IP地址，目的端口，协议类型。同一时间也只能由一个五元组的TCP会话。当手机选的TCP衔接和负载平衡器选的TCP衔接不一样时，TCP会话就无法建立了。如图：RAB重建后IPHONE手机和平台侧的处置此时IPHONE发的SYN是反复的希望建立一个TCP会话，而负载平衡器处置后变成向两个SERVER的两个TCP会话过程。2、IPHONE手机TCP建立和平台负载效力器选择一致时会话胜利 TCP由五元组识别，IPHONE并不知道回应不同SERVER，也不能够去建两个TCP会话，它会以为与第一个前往SYN ACK回应报文的效力器建立衔接，前往的音讯。担任平衡处置机制应该也会根据五元组以及负载映射关系找四处置的效力器，假设它找对了这次会话过程就胜利了。IPHONE手机TCP建立和平台负载效力器选择不一致时会话失败 担任平衡处置机制应该也会根据五元组以及负载映射关系找四处置的效力器，假设它找错了这次会话过程就失败了。 处理方案产生问题的缘由是IPHONE在RAB没有撤除后发的TCP衔接时会发两个反复的建链恳求两个一样的SYN报文，电视平台侧能够有负载分担机制，能够会把这两个恳求