《手机电视提示缓冲而无法继续观看问题分析》由会员分享，可在线阅读，更多相关《手机电视提示缓冲而无法继续观看问题分析（7页珍藏版）》请在金锄头文库上搜索。
1、 IPHONE手机电视提示缓冲而无法继续观看问题分析1月4日马鞍山分公司反映使用IPHONE手机看电视时经常数据缓冲而无法继续观看，经分析初步判断是RAB拆链可能会引起IPHONE和手机电视平台间TCP会话问题，而导致业务异常终止。继续分析TCP会话过程，产生问题的原因是IPHONE在RAB没有拆除后发的TCP连接时会发两个重复的建链请求（两个一样的SYN报文），电视平台侧可能有负载分担机制，可能会把这两个请求转到不同的电视服务器上，可能导致TCP会话异常。一、 IPHONE看手机电视流程分析通过消息看IPHONE连接手机电视时通过3GNET连接到公网.网站。过程如下：1、 手机通过3GNET
2、进行PDP上下文激活普通手机会直接转到，IPHONE手机会转到iP.，然后在点击手机电视后连接到.网站。 然后点击WEB网页中的电视节目消息，通过不断获取节目数据块文件名，通过TCP方式收看数据文件（普通手机一般使用RTP方式）。过程如下：1、 获取电视节目最新数据块文件名。GET /video1/index_128k.m3u8?username=&random=&ip=58.243.254.6&date=807&key=ffdaeae3243da2e3f3d32e072b 得到结果为：#EXTM3U#EXT-X-TARGETDURATION:10#EXT-X-MEDIA-SEQUENCE:1
3、739#EXTINF:./video1/sample_128k-01739.ts#EXTINF:./video1/sample_128k-01740.ts#EXTINF:./video1/sample_128k-01741.ts#EXTINF:./video1/sample_128k-01742.ts#EXTINF:./video1/sample_128k-01743.ts#EXTINF:./video1/sample_128k-01744.ts#EXTINF:./video1/sample_128k-01745.ts#EXTINF:./video1/sample_128k-01746.ts#
4、EXTINF:./video1/sample_128k-01747.ts#EXTINF:./video1/sample_128k-01748.ts#EXTINF:./video1/sample_128k-01749.ts#EXTINF:./video1/sample_128k-01750.ts#EXTINF:./video1/sample_128k-01751.ts#EXTINF:./video1/sample_128k-01752.ts#EXTINF:./video1/sample_128k-01753.ts2、 下载最新的数据块文件，第一次从倒数第三个开始，并在IPHONE手机实时观看（每
5、个文件块约为500K左右，10秒钟播放时间） GET /video1/sample_128k-01751.ts GET /video1/sample_128k-01752.tsGET /video1/sample_128k-01753.ts3、 再次获取最新数据块文件名， GET /video1/index_128k.m3u8?username=&random=&ip=58.243.254.6&date=807&key=ffdaeae3243da2e3f3d32e072b 二、 问题分析测试中发现异常情况出现在手机重复获取M3U8文件的过程中，该文件含有最新数据块文件列表。异常情况出现在手机和
6、电视平台TCP三次握手后，发GET请求，平台不回应，手机在重复三次GET请求后认为平台异常终止了请求，并终止了本次手机电视业务。该TCP会话过程如下：第一个包是平台发给手机的TCP握手信号但ACK=0（正常情况下ACK应该=1），同时随后还发了一个带SYN的握手信号而SEQ很大（正常情况下应该为0）。IPHONE因为收到第一个包，所以认为与平台的TCP连接已建立起来，随后就发送GET请求。但平台重复发送带SYN的ACK=0的消息，导致手机不能获取正常结果，在GET请求重复三次后断开，并终止了手机电视业务。一般情况下服务器回应【SYN ACK】报文中ACK=1，但在实际测试中也发现ACK=0时能
7、获取业务的情况，如：和异常情况比较TCP会话过程一样，不同的是异常情况下客户GET后，平台返回依然返回ACK=0，似乎没有消息发出。经过总部相关负责人协调，与平台技术工程师讨论发现出现异常时均伴随RAB释放和建立过程。现网数据业务，RNC在用户链路空闲6秒时会发起RAB释放过程，把无线资源腾出给其它人使用。IPHONE视频分成10秒一段，因此系统设置取M3U文件时是要求间隔10秒，但在无线环境较好的情况下500K字节的文件下载时间可能缩短到2秒钟，这就导致可能有超过6秒不收发数据包的情况，从而会有RAB释放，当手机在获取M3U时就需要RAB建立。出现这种现象本身是正常，不会影响应用层消息的交互
8、。如果要避免RAB释放和建立现象，可以通过修改RNC空闲时间参数或更改M3U文件获取的频率，因RNC参数是全局的，不能随意修改。总部为此开通一个测试页面.live.wovo.tv/ahtest.html，其M3U文件控制内容修改为：#EXTM3U#EXT-X-TARGETDURATION:5#EXT-X-MEDIA-SEQUENCE:187#EXTINF:5时间间隔改为5秒。随后请马鞍山公司协助测试，测试20分钟没出现异常情况。 三、 TCP会话异常分析在出现异常时经常丢失手机发出的SYN报文，后经分析是RNC在发RAB建立成功消息前，先传送了数据包报文，导致抓包不全。因此TCP会话分析使用G
9、n口抓包消息。IPHONE GET请求无响应的完整过程为：1、首先手机从TCP 49185端口向114.247.0.124连续发送了两个TCP SYN请求（只有在RAB需要重新建立时才出现，正常时只发一个）2、114.247.0.124也回了两个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
10、 ACK请求为本次TCP会话的对端）4、再往后手机发出了GET请求，4秒钟内还没有得到响应，并且114.247.0.124在包序号为9332的消息中重发了一条SYN ACK，手机予以ACK响应。（负载均衡器选择了和手机不一致的服务器）5、114.247.0.124在包序号为9334的消息中又重发了一条SYN ACK，手机在9335中予以ACK响应6、后面是手机的GET消息重发过程以及TCP连接关闭请求 从上面的消息过程看，当手机发往服务器的两个TCP SYN请求，存在两个服务器侧的TCP SYN ACK，这两个TCP SYN的区别如下：第一条SYN ACK的TCP本端序号为0X6CB978EF
11、，TTL为53第二条SYN ACK的TCP本端序号为0XB,TTL为52由于TCP本端序号应在TCP实体上产生，因此这两个SYN ACK的序号为两个不同的手机电视服务器产生，114.247.0.124这个地址是一个手机电视平台对外暴露的公共地址，这个地址对应的设备具备负责均衡功能，可将消息、数据分发到不同的手机电视服务器上 TCP连接用五元组区分，即源IP地址，源端口，目的IP地址，目的端口，协议类型。同一时间也只能由一个五元组的TCP会话。当手机选的TCP连接和负载均衡器选的TCP连接不一样时，TCP会话就无法建立了。如图：1、 RAB重建后IPHONE手机和平台侧的处理此时IPHONE发的
12、SYN是重复的希望建立一个TCP会话，而负载均衡器处理后变成向两个SERVER的两个TCP会话过程。2、IPHONE手机TCP建立和平台负载服务器选择一致时会话成功 TCP由五元组识别，IPHONE并不知道回应来自不同SERVER，也不可能去建两个TCP会话，它会认为与第一个返回SYN ACK回应报文的服务器建立连接，返回的消息。负责均衡处理机制应该也会根据五元组以及负载映射关系找到处理的服务器，如果它找对了这次会话过程就成功了。2、 IPHONE手机TCP建立和平台负载服务器选择不一致时会话失败 负责均衡处理机制应该也会根据五元组以及负载映射关系找到处理的服务器，如果它找错了这次会话过程就失
13、败了。 四、 解决方案产生问题的原因是IPHONE在RAB没有拆除后发的TCP连接时会发两个重复的建链请求（两个一样的SYN报文），电视平台侧可能有负载分担机制，可能会把这两个请求转到不同的电视服务器上，可能导致TCP会话异常。因此解决办法由三个：1、请平台侧解决负载均衡器处理重复SYN请求问题，负载均衡器应能够识别出重复的SYN请求，从而正确的把重复SYN均送到一台服务器上。2、避免RAB拆除，调整M3U文件内容，使IPHONE手机看电视时始终保持空口连接。此方法可能会在业务量上升后影响无线资源，并增加手机耗电。3、修改IPHONE手机在RAB拆除后的TCP连接机制。方案1是最好的解决方案，请总部协调解决。在线文档：.（.）成立于2004年，专注于企业管理培训。2019整理的各行业企管，经济，房产，策划，方案等工作范文，希望你用得上，不足之处请指正
