作者序
本文所谈的绝大部分内容在众多文章中都有讲到，再复述一遍并非本意。本文的目的是了解各种工具、定量分析网络状态；当遇到网络性能问题的时候，根据原理和出现的可能性，有的放矢。
- MSS vs MTU 有什么区别？
- 发送窗口 vs 接收窗口 vs 拥塞窗口 ？
- RTT & RTO 是什么含义
- 哪些常见的工具可以探查网络状态？
- 如何定量分析延迟、吞吐等性能问题？
其他说明：
- 文中 Wireshark 相关的使用，来源于 《Wireshark 网络分析就这么简单》、《Wireshark 网络分析的艺术》
IP 协议与机制
MTU
应用程序发送到协议栈的数据长度是由应用程序本身决定的。不同的应用程序有不同的实现方式，有些应用程序一次性发送所有数据，而有些应用程序则会逐字节或逐行发送数据。最终，发送到协议栈的数据量由应用程序决定，协议栈无法控制这种行为。
如果协议栈一接收到数据就立即发送，可能会发送大量的小数据包，导致网络效率降低。因此，需要在累积一定数量的数据后再发送。但是，累积多少数据才能发送取决于操作系统的种类和版本。
现在，假设有一个需要写入的操作比较大，例如 4000 字节，那么 TCP 层会如何处理呢？是否只需添加 TCP 标头并将其发送到网络层呢？
答案是否定的。因为网络对数据包大小有限制，最大传输单元（MTU，Maximum transmission unit）指的是网络可以传输的最大数据包大小。大多数网络的 MTU 为 1500 字节，这意味着 4000 字节的数据包要么会被丢弃，要么会被分片。如果数据包被丢弃，传输将彻底失败。如果数据包被分片，将会导致传输效率降低。
那被切分的包又该怎么重组呢？
仍然以一个数据包大小为 4000 字节，MTU 为 1500 字节为例，当发送端的 IP 层将该数据包发送到网络层时，会检查数据包大小是否超过 MTU 限制。
如果超过了，IP 层会将该数据包分成三个分片，分别是：
- 第一个分片，偏移量为 0，大小为 1500 字节；
- 第二个分片，偏移量为 1480（前一个分片占去了 20 字节的 IP 头部空间），大小为 1500 字节；
- 第三个分片，偏移量为 2960（前两个分片占去了 2960 字节的空间），大小为 1020 字节。
分片的重组需要依据 IP Header 中的标识（Identification）和标志（Flags）字段来完成。标识字段用于标识分片属于哪个数据报，而标志字段用于标识分片是否允许再分片和是否为最后一片。具体而言，同一个数据报的所有分片都应该具有相同的标识字段值，而 DF（Don’t Fragment，不分片）和 MF（More Fragments，还有更多分片）标志则用于标识分片是否允许再分片和是否为最后一片。
在接收端，当接收到这些分片时，它们会根据标识字段进行分类。如果一个数据报的所有分片都到达了接收端，那么接收端就可以使用偏移量和分片大小将这些分片按正确的顺序重新组装成原始数据包。如果某个分片没有到达接收端，那么接收端会等待一段时间，如果超时后仍然没有收到该分片，那么接收端就会向发送端发送一个请求重传的消息。
假设客户端和服务器的 MTU 大小分别为 1500 和 1200 字节。在这种情况下，客户端最大能发出多少字节的包呢？
根据上面的结论，发包的大小是由 MTU 较小的一方决定的，因此客户端最大只能发送 1200 字节的包。如果客户端尝试发送 1500 字节的包，那么这个包将被分片成两个部分，每个部分的大小分别为 1200 字节和 300 字节。如果 DF 标志位设置为 1，表示不允许分片，因此这个数据包会则会被丢弃，传输失败。
TTL
每个 IP 包都有一个 TTL 字段，表示该包的生存时间。每当一个 IP 包经过一个路由器，TTL 字段就会减 1，当 TTL 为 0 时，该包就会被丢弃。根据 TTL 的特性，只需翻出网络拓扑图，就能大概知道该包是哪台设备发出。
除此之外，TTL 还可以用于检测网络劫持和请求延迟问题。如果我们怀疑网络连接被劫持，可以通过检查 TTL 值来确定是否存在额外的跳数。而如果请求延迟较高，也可以通过检查 TTL 值来确定是否存在较远的跳数，从而进一步分析网络瓶颈所在。
TCP 协议与机制
MSS
由于 IP 层 MTU 的存在，TCP 协议需要控制 MTU，从而避免数据过大而需要分包传输的问题，提高网络传输效率。
在 TCP 连接建立过程中，客户端和服务器会互相通告各自的 MSS（Maximum Segment Size，最大分段大小），MSS 是指 TCP 数据段中数据部分的最大长度。MSS 加上 TCP 头和 IP 头的长度，就是双方可以承载的最大 MTU。
RTT
RTT（往返时延）是指从发送方发送数据到发送方接收到来自接收方的确认消息所经过的时间。在网络通信中，RTT 时延不仅与链路的传播时间有关，还包括路由器等网络中间节点的缓存和排队时间，以及末端系统的处理时间。
尽管在同一条链路上，报文的传输时间和应用处理时间相对固定，但网络设备和末端系统的网络拥堵情况下，排队时间的增加会导致 RTT 时延波动。
此外，流量负载均衡的存在会导致选择的传输路径和经过的网络设备不同，即使是同一个上下游服务的请求，也会出现 RTT 时延的差异。
MTR（My Traceroute）是一种网络诊断工具，可以通过在连续的时间间隔内将网络节点的 traceroute（跟踪路由）操作的结果显示在同一屏幕上，从而提供更详细的网络信息。
使用 MTR 可以帮助我们了解数据包在网络中的路径和每个跃点的 RTT，从而更方便地定位网络问题。例如，如果我们发现某些数据包延迟较高，我们可以使用 MTR 查看这些数据包的路径和每个跃点的 RTT，以确定延迟出现的具体位置。此外，MTR 还可以通过连续的监测，提供有关网络稳定性和性能的有用信息，从而帮助我们优化网络性能
流量控制
在我们日常生活中，排队和拥挤现象时常发生，如医院看病、邮局等候服务等。除了实际排队之外，还有一种无形的排队，即网络拥堵导致的网速变慢。
为了减少排队现象，增加服务窗口是一个可行的解决方案，但这也会增加服务成本。反之，缩小服务窗口可以提高窗口的利用率，降低成本，但会增加用户排队等待的时间。这两者是相互矛盾的。
为了在保证用户满意度（响应时间）的前提下，最大限度地挖掘系统潜力、提高利用率（控制成本），TCP 通过窗口（发送窗口/拥塞窗口）大小来实现这一目标。
