编辑：我已经看到这个问题在其他地方与ADSL连接，而不是只有USB调制解调器或单元networking。
我有我的单元networkingUSB调制解调器连接和configuration，在Ubuntu 10.04下运行一般来说，连接速度慢，虽然build立连接后数据stream良好，但问题是实际build立连接需要很长时间。 IP查找速度非常快，所以根本不可能是这个问题。 我已经尝试了SSH，Skype和FTP。 这些都没有问题。
这个问题主要出现在HTTP连接中，尤其是对于有多个资源从多个源收集的站点，最终这些资源中的一个或两个（图像，CSS或JS文件）加载失败，浏览器不停地报告“等待.com …“为munites，冻结并不断等待这个单一的资源被加载。 我想这可能是一个线索。 我尝试了Firefox以外的浏览器：Chrome和Opera，问题也在那里！
幕后会发生什么？ 任何问题都欢迎。
如果HTTP以外的其他服务正在为您运行，也许您的Internet提供商正在使用重载的反向代理caching事物并节省带宽。 您可以尝试连接到运行在非标准的远程HTTP服务器上（但ISP可以使用7层fw来拦截您的请求），或者在某个地方设置一个openvpn服务器，并将所有stream量通过该服务器进行传输。
小区networking可能会有较高的延迟，因此，您的数据包往返时间可能在一秒钟内。 只要检查一下，发出一个ping已知的恒定延迟的互联网主机，例如：
# ping www.gogle.de PING www.l.google.com (74.125.79.99) 56(84) bytes of data. 64 bytes from ey-in-f99.1e100.net (74.125.79.99): icmp_seq=1 ttl=53 time=12.7 ms 64 bytes from ey-in-f99.1e100.net (74.125.79.99): icmp_seq=2 ttl=53 time=16.1 ms 64 bytes from ey-in-f99.1e100.net (74.125.79.99): icmp_seq=3 ttl=53 time=17.2 ms ^C --- www.l.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 12.794/15.377/17.218/1.886 ms 由于TCP的内部缓冲和发送大量数据的能力，TCP能够适应高延迟的networking，而不需要立即收到响应，所以您可能会看到使用连接的批量传输的吞吐率良好。 但是，高延迟当然会大大影响TCP握手（即连接发起）的性能和每一个在进行任何进一步处理之前等待另一方的响应的“乒乓式”协议（例如具有许多小的HTTP对象来获取，甚至更糟，如果他们相互依赖，就像是帧和iframes和包括javascript文件的情况）。
编辑：你应该使用类似Firebug的东西来看看更详细的情况。 甚至运行Wireshark跟踪协议级别的信息。 如果您收到指向ISP的问题的数据，则可能要向他们投诉。 除此之外，使用较小的MTU值得一试 – 一些传输可能受MTU黑洞的影响 。
您应该调查DNS设置。 如果IP查询速度很快，那么您可能正在等待来自慢速DNS服务器的响应，或者您已configuration为轮询多个DNS服务器，并且前几个服务器处于closures/无响应状态。 在Ubuntu上，您可以编辑/etc/resolv.conf以临时更改您的DNS设置。 首先删除文件中的所有内容，然后replace为：
nameserver 8.8.8.8 nameserver 8.8.4.4
如果您的USB浏览情况得到改善，那么USB调制解调器的DNSconfiguration会造成您的麻烦。
在单元networking上，它实际上有助于在后台获得持续不断的数据stream（例如互联网广播stream），以便为您的所有stream量获得较低的延迟。 这与小区networking如何调度分组有关。 不断使用networking，你会得到更好的服务。