开发者社区 问答 正文

android webview加载ssl页面很慢:报错

android客户端通过https加载应用很慢。
服务器环境是这样搭建的,一台对外的服务器上面配置了ssl,将客户端发送过来的请求转发到内部应用所在服务器上。现在android webview加载网页很慢。android客户端和ssl服务器建立连接很慢。
android客户端对请求https是这样处理的。重些WebViewClient中的onReceivedSslError方法

public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
	handler.proceed();
}

对ssl服务器抓包数据信息如下
15:31:13.798061 17.1.6.6.44866 > 17.1.5.46.5443: S 2938284858:2938284858(0) win 5840 <mss 1460,sackOK,timestamp 11167357 0,nop,wscale 4> (DF)
15:31:13.798108 17.1.5.46.5443 > 17.1.6.6.44866: S 1738119760:1738119760(0) ack 2938284859 win 17520 <mss 1460> (DF)
15:31:13.801394 17.1.6.6.44866 > 17.1.5.46.5443: . ack 1 win 5840 (DF)
15:31:23.827178 17.1.6.6.44866 > 17.1.5.46.5443: P 1:81(80) ack 1 win 5840 (DF)
15:31:23.827261 17.1.5.46.5443 > 17.1.6.6.44866: P 1:1159(1158) ack 81 win 17520
15:31:23.833176 17.1.6.6.44866 > 17.1.5.46.5443: . ack 1159 win 8106 (DF)
15:31:23.848509 17.1.6.6.44866 > 17.1.5.46.5443: P 81:391(310) ack 1159 win 8106 (DF)
15:31:23.848599 17.1.5.46.5443 > 17.1.6.6.44866: . ack 391 win 17482
15:31:23.850690 17.1.5.46.5443 > 17.1.6.6.44866: P 1159:1202(43) ack 391 win 17520
15:31:23.870509 17.1.6.6.44866 > 17.1.5.46.5443: P 391:1071(680) ack 1202 win 8106 (DF)
15:31:23.877229 17.1.5.46.5443 > 17.1.6.6.44866: P 1202:2662(1460) ack 1071 win 17520
15:31:23.877249 17.1.5.46.5443 > 17.1.6.6.44866: P 2662:2917(255) ack 1071 win 17520
15:31:23.877861 17.1.5.46.5443 > 17.1.6.6.44866: P 2917:4377(1460) ack 1071 win 17520
15:31:23.877881 17.1.5.46.5443 > 17.1.6.6.44866: P 4377:4398(21) ack 1071 win 17520
15:31:23.881204 17.1.5.46.5443 > 17.1.6.6.44866: P 4398:5858(1460) ack 1071 win 17520
15:31:23.881225 17.1.5.46.5443 > 17.1.6.6.44866: P 5858:7042(1184) ack 1071 win 17520
15:31:23.883176 17.1.6.6.44866 > 17.1.5.46.5443: . ack 2917 win 13140 (DF)
15:31:23.883190 17.1.6.6.44866 > 17.1.5.46.5443: . ack 4398 win 16060 (DF)
15:31:23.883237 17.1.5.46.5443 > 17.1.6.6.44866: P 7042:8502(1460) ack 1071 win 17520
15:31:23.883259 17.1.5.46.5443 > 17.1.6.6.44866: P 8502:8841(339) ack 1071 win 17520
15:31:23.883928 17.1.5.46.5443 > 17.1.6.6.44866: P 8841:10301(1460) ack 1071 win 17520
15:31:23.883951 17.1.5.46.5443 > 17.1.6.6.44866: P 10301:10322(21) ack 1071 win 17520
15:31:23.884545 17.1.5.46.5443 > 17.1.6.6.44866: P 10322:11782(1460) ack 1071 win 17520
15:31:23.884567 17.1.5.46.5443 > 17.1.6.6.44866: P 11782:13158(1376) ack 1071 win 17520
15:31:23.889178 17.1.6.6.44866 > 17.1.5.46.5443: . ack 7042 win 21900 (DF)
15:31:23.889233 17.1.5.46.5443 > 17.1.6.6.44866: P 13158:14618(1460) ack 1071 win 17520
15:31:23.889258 17.1.5.46.5443 > 17.1.6.6.44866: P 14618:15653(1035) ack 1071 win 17520
15:31:23.895842 17.1.6.6.44866 > 17.1.5.46.5443: . ack 8841 win 27740 (DF)
15:31:23.895855 17.1.6.6.44866 > 17.1.5.46.5443: . ack 10322 win 30660 (DF)
15:31:23.895871 17.1.6.6.44866 > 17.1.5.46.5443: . ack 13158 win 36500 (DF)
15:31:23.897174 17.1.6.6.44866 > 17.1.5.46.5443: . ack 15653 win 42340 (DF)
15:31:24.014506 17.1.6.6.44866 > 17.1.5.46.5443: P 1071:1774(703) ack 15653 win 42340 (DF)
15:31:24.024527 17.1.5.46.5443 > 17.1.6.6.44866: P 15653:17110(1457) ack 1774 win 17520
15:31:24.067838 17.1.6.6.44866 > 17.1.5.46.5443: . ack 17110 win 45260 (DF)
15:31:31.928335 17.1.6.6.44866 > 17.1.5.46.5443: P 1774:1797(23) ack 17110 win 45260 (DF)
15:31:31.928351 17.1.6.6.44866 > 17.1.5.46.5443: F 1797:1797(0) ack 17110 win 45260 (DF)
15:31:31.928414 17.1.5.46.5443 > 17.1.6.6.44866: . ack 1798 win 17519
15:31:31.929031 17.1.5.46.5443 > 17.1.6.6.44866: F 17110:17110(0) ack 1798 win 17519
15:31:31.935001 17.1.6.6.44866 > 17.1.5.46.5443: . ack 17111 win 45260 (DF)
15:31:42.033449 17.1.6.38.51614 > 17.1.5.46.5443: . 1302:1303(1) ack 4253 win 17520 (DF)
15:31:42.033467 17.1.6.38.51615 > 17.1.5.46.5443: . 1287:1288(1) ack 24995 win 17520 (DF)
15:31:42.033519 17.1.5.46.5443 > 17.1.6.38.51614: . ack 1303 win 17520
15:31:42.033538 17.1.5.46.5443 > 17.1.6.38.51615: . ack 1288 win 17520
15:31:42.168121 17.1.6.38.51610 > 17.1.5.46.5443: . 2939:2940(1) ack 81618 win 16064 (DF)
15:31:42.168160 17.1.5.46.5443 > 17.1.6.38.51610: . ack 2940 win 17520
15:32:12.401640 17.1.5.46.5443 > 17.1.6.38.51615: R 337360665:337360665(0) win 668 (DF)
15:32:12.401683 17.1.5.46.5443 > 17.1.6.38.51614: R 4083442179:4083442179(0) win 668 (DF)
15:32:12.401698 17.1.5.46.5443 > 17.1.6.38.51610: R 3752975235:3752975235(0) win 668 (DF)

从第三步到第四步之间相差了10s。目前慢就在这个地方,不知道是什么原因导致的

展开
收起
kun坤 2020-06-14 09:46:00 818 分享 版权
阿里云 AI 助理回答

从您提供的抓包数据来看,客户端与SSL服务器建立连接后,在发送第一个HTTP请求的数据包(即客户端向服务器发起实际应用层数据传输)之前有大约10秒的延迟。这10秒的空闲时间可能是由多种因素造成的,以下是一些可能的原因和建议:

  1. 客户端处理或准备时间:客户端可能在构建请求、加载资源或者执行其他初始化操作上花费了时间。检查您的Android应用代码,确认是否有耗时的操作,比如复杂的JavaScript执行、大文件预加载或其他初始化逻辑。

  2. 网络延迟:虽然握手过程看起来正常,但是客户端到服务器的网络路径可能存在高延迟。可以尝试使用ping命令或更专业的网络诊断工具来测试网络延迟,并考虑是否需要优化网络配置或选择更优的网络服务提供商。

  3. 服务器响应慢:尽管握手成功,但服务器可能需要较长时间来处理第一个请求。这可能是因为服务器端资源紧张、处理逻辑复杂或数据库查询缓慢等。查看服务器日志,监控CPU、内存和磁盘I/O使用情况,以及Web服务器和应用服务器的性能指标。

  4. SSL握手后的额外认证或验证:某些安全策略或中间件可能会在SSL握手之后进行额外的安全检查,如客户端证书验证、IP黑名单检查等,这些都可能导致延迟。检查您的SSL配置和服务器安全设置,看是否有这类延时因素。

  5. TCP慢启动:TCP连接初期会经历一个慢启动阶段,如果初始拥塞窗口较小,且数据包较大,可能会导致数据传输开始时速度较慢。不过,从抓包信息看,数据传输似乎不是问题所在,因为后续数据包传输相对迅速。

  6. DNS解析问题:虽然抓包显示的是IP地址直接通信,但如果DNS解析过程中存在问题,也可能间接影响到连接建立的时间。确保DNS解析快速且稳定。

解决这个问题,您可以从以下几个方面入手: - 优化客户端代码,减少初始化和请求构建时间。 - 检查并优化服务器配置及性能。 - 确认网络环境,包括客户端侧和服务器侧的网络状况。 - 查看SSL/TLS配置,简化不必要的安全检查流程。 - 考虑使用更高效的协议版本,如TLS 1.3,它通常能提供更快的握手时间。

如果问题依然存在,可能需要更深入地分析应用日志、服务器日志以及进行网络性能测试,以定位具体原因。您也可以通过ECS一键诊断全面排查并修复ECS问题。

有帮助
无帮助
AI 助理回答生成答案可能存在不准确,仅供参考
0 条回答
写回答
取消 提交回答