3G网络下TCP性能差的解释
来源:互联网 发布:ntfs for mac怎么卸载 编辑:程序博客网 时间:2024/06/06 01:48
转载自http://blog.davidsingleton.org/mobiletcp
文章介绍了为什么3G网络环境下TCP性能差(RTT是一个变化的值).
WIFI网络也有类似的问题,一些中低端的android手机问题WIFI性能非常差.
Why mobile apps suck when you're mobile.
Tweet
In 2011, Smartphones are ubiquitous and everyone and his dog is writing mobile apps, but using apps when you're not in range of a fixed wifi hotspot or standing still in an urban area is often extremely frustrating. How often have you tried to refresh and found yourself staring at an interminable spinner that makes you want to throw your phone at the wall? Here's why (and a plea to app developers to do something about it!)
The graph above shows the round-trip time (RTT) for 1000 IP packets I traced over a supposed super-fast HSDPA connection while travelling on a train in the UK. All the while, my phone had signal, though it was switching pretty frequently from HSDPA to (still supposedly broadband-speed) 3G. But apps on the phone were totally useless for anything involving a network connection - refreshing resulted in nothing more than a spinner.
What can we see here?
- The connection is relatively good at sending and receiving data. The green crosses represent packets that were actually lost which only happened for 75 of 1000.
- There are some crazy-high round trip times. The minimum round trip time was 107ms (which would put my home cable connection to shame) and even the median is pretty awesome at 239ms but the maximum was a whopping 20226 ms - that's more than 20 seconds!
On wired connections, such a long RTT as 20s just wouldn't be seen, so what's going on? The underlying radio connection is flaky, but 3G data connections make their own attempt at implementing reliable delivery. So when the radio link comes back, buffered packets will still make it to/from the device. Hooray, we've compensated for the flaky radio connection and all those great apps should work great, right? Wrong.
Most apps communicate with the services they depend on in the cloud via HTTP which in turn uses a TCP connection to transfer data reliably and have the parts of every request and response show up in the right order. TCP gives us reliability by re-transmitting packets which haven't been acknowledged (i.e. a corresponding packet returned from the other end of the link) within its estimate of the round-trip time of the connection. TCP assumes that the connection has a more or less constant RTT and assumes delays are losses due to congestion somewhere on the path from A to B. To avoid overloading the network and give the congestion a chance to clear, TCPbacks off - waiting longer and longer on each loss to send the next packet.
On our mobile link, with an underlying reliable data connection but with highly variable delay, there is little/no loss and no congestion, but of course TCP doesn't know that and backs off making the connection our apps see next-to-useless. The same effect means that running TCP over TCP (with or without a mobile link underneath) is also a bad idea, as described in this excellent article by Olaf Titz:Why TCP over TCP is a bad idea.
So what can you do as a mobile developer? I'm not suggesting that everyone should go out and implement their own proprietary reliable-but-delay-tolerant protocol over UDP - you're unlikely to do a better job than TCP (though maybesomebody should :-) ), but there are a couple of practical things you could try. In the above trace, you can probably see that established TCP connections which haven't managed to transfer data yet (due to lots of exponential backing off) are unlikely to recover and when the underlying connection "comes back" will not perform as well as a newly established TCP connection. If your application needs to transfer relatively small amounts of data in response to a user action you could try setting aggressive timeouts and retrying with new TCP connections. You may also choose to avoid the system's HTTP stack and open TCP sockets directly, since the system stack will often re-use an already established HTTP connection to the same host - a great idea in a system with constant delay since the TCP connection will already be "up to speed", but not so great in the conditions above. If you do this, you'll probably want to keep track of the type of connection in use and only apply these tweaks when on a mobile link. Most mobile app platforms provide a mechanism to discover the underlying link type (for example Android'sConnectivityManager). More importantly, this is (another) reason to build a great offline / flaky mode for your app so that users aren't quite so frustrated by those spinners.
David Singleton@dps
Here's a closer look at the variance in RTT - the y-axis is a log scale.
- 3G网络下TCP性能差的解释
- 无外网IP如何做3G网络下的TCP通信测试或应用程序
- Tcp/IP下Socket 网络性能优化
- 【网络协议】TCP/IP模型的一个简单解释
- WinCE下3G模块的调试----解释了假连接状况
- Android下检测网络状态 3G WIFI
- Android下检测网络连接 3G WIFI
- Android下检测网络连接 3G WIFI
- Android 3G网络下 http refused 解决办法
- android 3G网络下Socket通信
- 配置Linux下的TCP IP网络
- 网络编程--TCP下的Socket
- 排队理论解释TCP/IP网络拥塞是如何影响TCP的RTT的波动
- Android手机3G网络访问TCP服务器失败
- CE下可用的3G
- WinCE下可用的3G
- Linux下3G的应用
- 高性能网络编程2----TCP消息的发送
- ubuntu 如何让桌面显示“我的电脑”及去掉桌面上的“磁盘图标”
- 环境搭建
- TCP/IP协议详解
- linux之无名管道pipe
- OpenVPN遇到的Secondary地址问题
- 3G网络下TCP性能差的解释
- Shell 中位运算符的应用(特别举例按位非)
- websphere启动时初始化报错解决方法
- Java性能的优化
- 一道理解c#中对象(引用类型)相互赋值和方法覆盖(overriding)的题目
- 之后的打算
- jquery控制换行
- Android开发笔记之一 Hello World
- 已知二叉树的中序遍历和后序遍历,如何求前序遍历