From 1364bebf55ffa6b4309e392bc4f1237fd00fc0b0 Mon Sep 17 00:00:00 2001
From: Jim <dashjim@gmail.com>
Date: Sat, 1 Feb 2014 10:11:31 +0800
Subject: [PATCH] add a post 14/02/01

---
 .../2014-02-01-Flex-real-time-video-app.md    | 48 +++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 _posts/2014/2014-02-01-Flex-real-time-video-app.md

diff --git a/_posts/2014/2014-02-01-Flex-real-time-video-app.md b/_posts/2014/2014-02-01-Flex-real-time-video-app.md
new file mode 100644
index 0000000..c02ab9e
--- /dev/null
+++ b/_posts/2014/2014-02-01-Flex-real-time-video-app.md
@@ -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的传输协议可以从根本上解决以上问题。
+