mirror of
https://gh-proxy.org/https://github.com/klinsmaya/dashjim.github.com.git
synced 2026-11-08 01:16:54 +08:00
add a post 14/02/01
This commit is contained in:
@@ -0,0 +1,48 @@
|
||||
---
|
||||
layout: post
|
||||
title: 基于TCP和无线网络(3G等)的实时应用需要注意的问题
|
||||
categories:
|
||||
- Other
|
||||
tags:
|
||||
- Other
|
||||
---
|
||||
|
||||
基于TCP和无线网络(3G等)的实时应用需要注意的问题
|
||||
=====================
|
||||
|
||||
|
||||
最近工作中把一个实时的基于Adobe Air的实时视频聊天程序porting到Android上。原本PC版本测试时视频的质量很好,但是转到Android上后在3G网络上测试发现视频质量比较差。由于Air程序与服务器是通过RTMP这一基于TCP的协议来沟通的,在解决问题的过程中有一些关于TCP的小小发现。
|
||||
|
||||
----------
|
||||
|
||||
|
||||
#### 3G下测试出的情况
|
||||
在3G网络下测试的时候我先在设备上运行了一个网速测试的APP,得出当时的网速是上行4.5M下行1.6M左右,对WCDMA来说这是一个比较好的数字,而我们的服务器设置中视频质量仅需要320K的带宽就够了。然而实际通话时的视频和音频质量都非常差(最后双方关上视频,仅用音频的质量都比较差)。
|
||||
|
||||
#### 服务器上抓包
|
||||
> **NOTE:**
|
||||
> 需要注意抓包的准确性问题。在服务器上如果用tcpdump抓包,特别是像视频实时应用的时候由于数据量大,tcpdump依赖的底层库可能会来不及处理而buffer溢出,使得数据文件不完整。这样在用wireshark分析的时候会看到的丢包量就是不准确的。解决方法参考**?????????**
|
||||
|
||||
在分析抓到的包时我们看到大量的丢包,如下图:
|
||||
|
||||
更多测试的结果
|
||||
|
||||
#### 3G带宽与TCP丢包
|
||||
|
||||
这轮测试下来得出的重要结论是**TCP在WCDMA3G下的网速远达不到其宣称值**!
|
||||
|
||||
参考3G的标称网速。注意标称网速不包括自身的信令消耗,所以150M的WiFi实际数据传输速度超不过80兆。3G消耗的信令可能更多。
|
||||
|
||||
#### 如何改进
|
||||
|
||||
**带宽检测**
|
||||
大多数实时通信程序都会在链接建立前发几个包测试带宽,这种做法在传统网络问题不大(会部分受到tcp slow start的影响)。但是在3G下,这几个包如果不丢,测出的速度会过高,如果有丢包,则测出的速度会过低。
|
||||
|
||||
所以在3G下的应用必须在链接建立后实时监测通信质量,如果发现延迟增加等情况要实时降低视频分辨率以保证流畅。
|
||||
|
||||
另一种简单办法是延长一开始的带宽测试时间。比如说测十秒。我曾在与Skype的对比测试中发现从拨号到对方实际振铃有较长延迟,这中间有可能就是在测带宽。
|
||||
|
||||
|
||||
**UDP**
|
||||
使用j基于UDP的传输协议可以从根本上解决以上问题。
|
||||
|
||||
Reference in New Issue
Block a user