Web 开发人员：AT&T 3g 上的“连接重置”错误，无处可去答案

【问题标题】：Web Devs: "Connection reset" Errors On AT&T 3g, Nowhere ElseWeb 开发人员：AT&T 3g 上的“连接重置”错误，无处可去
【发布时间】：2011-08-31 12:09:04
【问题描述】：

我们为客户维护一个服务器端报告应用程序。在一个报告页面上，页面中间有几个繁重的数据库调用，导致页面需要 5-10 秒才能呈现。

问题：通过 iPad 通过 AT&T 3G 访问页面时，页面成功加载的几率约为 50%。但是，有时 Mobile Safari 会呈现页面的上半部分，然后给出“服务器连接已重置”错误。

背景资料

如果您将 iPad 从 3G 切换到稳定的宽带 Wifi 连接，则页面 100% 的时间都可以正常工作
该页面在我的 Verizon iPhone 上通过 3G 运行 100% 的时间
无论使用何种设备或浏览器（PC、Mac、手机、iPad 等），该页面 100% 的时间都可以通过宽带运行。
页面不是特别重。所有资产的总重量为 108 KB（440 KB 未压缩）
即使在 AT&T 3G 上，报告网站上的其他页面也能 100% 正确加载。
最初，数据库调用需要 10+ 秒，iPad+AT&T 3G 问题发生的概率为 100%。一些简单的优化将调用时间缩短到 5-10 秒，现在我们看到它的时间大约为 50%。
服务器平台为 IIS6
新信息 在 IIS 的日志文件中，“失败”页面请求（在 Mobile Safari 中导致“连接重置”错误的请求）看起来像一个正常的 HTTP 请求，结果代码为 200（成功）
新信息 暂时，iPad 上的 Opera Mini 似乎不会出现此问题。令人费解，因为这似乎是 AT&T 网络问题。我在这里说“暂时”是因为我们不能排除它。我们目前有一名实习生在刷新 Opera 页面并记录任何错误。 :)
新信息我们对该 5-10 秒的数据库查询进行了一些快速优化。现在暂停更像是 3-5 秒而不是 5-10 秒。因此，Mobile Safari“连接重置”错误的发生率现在接近 10%，而不是 50%。

所以现在我不知道该怎么想。如果是网络问题，为什么 Opera Mini 可以工作，而 Mobile Safari 在其他情况相同的情况下却不行？但是……如果是 Mobile Safari 的问题，为什么 Mobile Safari 在宽带+Wifi 连接上可以正常工作？

Mobile Safari 是否根据宽带或 wifi 使用不同的超时设置？我不知道那是不是……它做的事情。

为了奖励赏金，我想我正在寻找一个专门解决以下一个或两个问题的答案 (1) Mobile Safari 是否会根据当前活动的网络连接的类型改变其超时设置 (2 ) AT&Ts 代理服务器是否存在某种已知的特定问题，并且会终止已空闲几秒钟的连接？比如：“是的，他们将在 4.25 秒后终止空闲连接”

【问题讨论】：

我和朋友一起编写的 Android 应用程序也遇到了类似的问题。问题是连接会随机重置。我们能够使用一些原生 API 调用来解释它，告诉它检查连接并在它关闭时重新连接。不过，我不确定如何为移动网站执行此操作。
HTML5 样板将 javascripts 放在内容的末尾，以便在执行脚本之前加载内容。您可能想尝试一下。
是否可以重新设计页面以异步呈现来自数据库调用的结果？如果您随后通过 JavaScript 检查结果，您有一半的机会判断中间路由器是否通过了 200 OK 但破坏了您的响应。

【解决方案1】：

我认为简短的回答是 3G 数据连接不可靠。这部分取决于物理特性——它永远不会像有线连接那样可靠——部分取决于运营商玩的游戏。

几乎所有运营商似乎都使用具有不同程度损坏的透明代理服务器。

我不能确定 AT&T 在做什么，但我可以列出一些我从我的应用（访问 REST Web 服务）的客户那里看到的东西：

很长一段时间以来，我都认为这是我代码中的一个潜在错误，但后来在 Vodafone 而不是 O2 的手机上尝试了我的应用程序...

除非您在公司环境中并且可以假设一个特定的运营商，否则除了使您的代码更具弹性之外，您无能为力。我试图让我的代码：

我认为最后一点是最重要的，尽管不幸的是不可能 100% 做到这一点。

【讨论】：

【解决方案2】：

您应该阅读this 文章，了解您在通过 AT&T 的 3G 网络连接时遇到问题的原因。

关于 Opera Mini ......好吧，Opera 使用这种类似代理的技术将所有数据通过自己的服务器传递，压缩然后发送给您。这会减少移动设备之间的流量，从而缩短加载时间。

除了压缩输出和优化所有内容以提高速度外，您无能为力 - 甚至用单引号替换双引号（对不起，我是 PHP 编码器，不知道这在 ASP 中是否相同）使得感觉这里。对于今天的宽带连接 - 没有人真正关心这一点，但移动连接还没有那么先进，在优化技术方面有点让我们回到拨号调制解调器时代。

【讨论】：

【解决方案3】：

我怀疑问题不在于 Safari，而在于 AT&T 的 3G 路由器/代理。我通过切换到 HTTPS 成功避免了类似问题，这似乎可以防止 AT&T 进行缓冲，并有助于避免虚假连接重置。

我的猜测是，AT&T 正在使用他们的网络玩游戏以平衡负载或防止其他带宽问题，这可能出于某种原因与您的特定数据搞砸了。

【讨论】：

【解决方案4】：

我建议对数据检索进行批处理以返回记录子集，并使用连续滚动模式来提高页面的性能。随着连续滚动，新项目将在您向下滚动页面时加载。我已经看到在类似情况下成功使用了这种技术。

这里有一篇文章解释了如何将 ASP.NET 中的连续滚动模式与 JavaScript 结合起来：

这是另一个使用 jQuery 的好例子：

希望这会有所帮助。

【讨论】：