小周(就是你!)所在的团队管理着一个服务 A,这个服务 A 需要访问服务 B 的 HTTP 接口。服务 A 和服务 B 部署在同一个 IDC 中,所以延迟很低,可以忽略不计。服务 B 处理请求需要花费 100ms,所以一个 HTTP 请求的总延迟大概是 100ms。
最近由于合规的要求,服务 B 需要迁移到另一个 IDC 中,物理延迟会上升。迁移之后,如果从服务 A 的 IP 去 ping 服务 B 的 IP,ping 显示延迟为 200ms。
在打开抓包文件分析之前,请问:如果服务 A 发送一个 HTTP 请求到服务 B,总延迟现在是多少?
注意:
- TCP 需要重新建立连接
- 请求的大小是 16KiB
- 响应的大小是 20KiB
然后用 Wireshark 打开抓包文件,分析实际的延迟是多少?和自己的答案作对比。
提示:在分析延迟问题的时候,可以使用这里的方法,打开 Time Delta 列。
==计算机网络实用技术 目录==
这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。
如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!
没有链接的目录还没有写完,敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器?
- 网工闯了什么祸?
- 网络中的环路和防环技术
- 延迟增加了多少?
- TCP 延迟分析
- 重新认识 TCP 的握手和挥手
- 重新认识 TCP 的握手和挥手:答案和解析
- TCP 下载速度为什么这么慢?
- TCP 长肥管道性能分析
- 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
500ms? 算来三次握手延迟和server端处理延迟,再返回给client端的延迟
已经考虑的很全面了,但是还有一个遗漏的点,可以分析下抓包文件,实际的延迟不是 500ms。
好的,我下载抓包文件看看,对了,其他目录的文章近期会更新吗? 每天都在等你更新,
谢谢,会的,前几周比较忙,最近应该每周更新没问题。
Content-Type 说是 form,实际传了个 json
这里不支持 emoji 吗 :)
观察的真仔细,不过请求的内容不是重点,我就不修改了。
不支持 emoji 哦。可以用颜文字 >_<
Pingback: TCP 延迟分析 | 卡瓦邦噶!