这个超不时光就被称为 RTO，显然它必须略大年夜于 RTT，不然就会误报数据包损掉。但也不克不及过大年夜，不然会浪费时光。是以合理的 RTO 必须跟随 RTT 动态调剂，始终包管大年夜于 RTT 但也不至于太大年夜。不雅察膳绫擎的截图可以发明，某些情况下 RTT 会异常小，小到只有几毫秒。如不雅 RTO 也设置为几毫秒就会显得不太合理，这会加大年夜客户端和沿途各路由器的压力。是以 RTO 还会设置下限，不合的操作体系可能有不合的实现，比如 Linux 上是 200ms。同时，RTO 也会设置上限，具体的算法可以参考这篇文┞仿 和这篇文┞仿。

收集请求

同样的，我们发清楚明了握手花费了 20s 这一现象，但无法给出精确原因，只能解释为收集颤抖。

总结

经由过程 TCP 层面的抓包，我们不仅仅进修了 WireShark 的应用，也复习了 TCP 协定的相干常识，对问题的分析也加倍深刻。大年夜最初的收集问题开端细化发掘，得出了白屏时光过长、网页加载太慢的结论，最终又具体的计算出了有若干个 HTTP 请求，DNS 解析、TCP 握手、TCP 数据传输等各个阶段低砟瓯。由此看来，网页加载慢的祸首祸首并非告白主网页的质量问题，而是收集的不稳定问题。固然最终也没有获得有效的解决筹划，但至少明白了问题的产生原因，给出了令人佩服的解释。

　　推荐阅读

　　Android优化APP构建速度的17条建议

较长的构建时光将会减缓项目标开辟进度，特别是对于大年夜型的项目，app的构建时光长则十几分钟，短则几分钟，长的构建时光已经成了开辟瓶颈，本篇文┞仿根据Google官方文档，加上本身的一>>>详细阅读

本文标题：利用WireShark深入调试网络请求

地址：http://www.17bianji.com/lsqh/34846.html

 1/2    1