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
index 90b9c89..c9f38f0 100644
--- a/_posts/2014/2014-02-01-Flex-real-time-video-app.md
+++ b/_posts/2014/2014-02-01-Flex-real-time-video-app.md
@@ -16,22 +16,29 @@ tags:
 ----------
 
 
-#### 3G下测试出的情况
+## 3G下测试出的情况
 在3G网络下测试的时候我先在设备上运行了一个网速测试的APP，得出当时的网速是上行4.5M下行1.6M左右，对WCDMA来说这是一个比较好的数字，而我们的服务器设置中视频质量仅需要320K的带宽就够了。然而实际通话时的视频和音频质量都非常差（最后双方关上视频，仅用音频的质量都比较差）。
 
-#### 服务器上抓包
+## 服务器上抓包
 > **NOTE:**
 > 需要注意抓包的准确性问题。在服务器上如果用tcpdump抓包，特别是像视频实时应用的时候由于数据量大，tcpdump依赖的底层库可能会来不及处理而buffer溢出，使得数据文件不完整。这样在用wireshark分析的时候会看到的丢包量就是不准确的。
 ![](/media/pic2014/0201-2.png)
-
-解决方法参考[tcpdump抓包丢失问题](http://wenku.baidu.com/view/74b3166e1eb91a37f1115cf6.html)。
+>解决方法参考[tcpdump抓包丢失问题](http://wenku.baidu.com/view/74b3166e1eb91a37f1115cf6.html)。
 
 在分析抓到的包时我们看到大量的丢包，如下图：
 ![](/media/pic2014/0201-1.png)
 
-更多测试的结果
+###更多测试的结果
+下面的对比测试中我们对比一下不同丢包情况所导致的不同TCP吞吐率曲线。（前面一个小峰是带宽测试留下的。）
+下图是视频质量好的时候的TCP呑吐率情况
+![](/media/pic2014/0201-4.png)
+下图是视频时断时续丟包
+![](/media/pic2014/0201-5.png)
+下图是视频几乎无法进行的情况
+![](/media/pic2014/0201-6.png)
 
-#### 3G带宽与TCP丢包
+由上面的图形我们看到不同的丢包对TCP传输率产生了不同的影响。
+## 3G带宽与TCP丢包
 
 这轮测试下来得出的重要结论是**TCP在WCDMA3G下的网速远达不到其宣称值**！因为丢包会导致TCP误以为是网络拥塞，而双方减小收发窗口，主动降速。
 下图就是我实测的TCP网速。
@@ -48,8 +55,8 @@ tags:
 
 注意标称网速不包括自身的信令消耗，所以150M的WiFi实际数据传输速度超不过80兆。3G消耗的信令可能更多。
 
-#### 如何改进
-=====
+## 如何改进
+
 
 **带宽检测**
 
diff --git a/media/pic2014/0201-4.png b/media/pic2014/0201-4.png
new file mode 100644
index 0000000..1d835cd
Binary files /dev/null and b/media/pic2014/0201-4.png differ
diff --git a/media/pic2014/0201-5.png b/media/pic2014/0201-5.png
new file mode 100644
index 0000000..0404fbb
Binary files /dev/null and b/media/pic2014/0201-5.png differ
diff --git a/media/pic2014/0201-6.png b/media/pic2014/0201-6.png
new file mode 100644
index 0000000..42e8009
Binary files /dev/null and b/media/pic2014/0201-6.png differ