一、Overview
这是一系列文章的第一篇，主要是利用Wireshark对网络包进行分析。一是为了熟练掌握网络协议的内容，二是为了熟练使用Wireshark，了解它的各种提示和特性。以便能够在将来，你也可以使用Wireshark解决工作中、生活中遇到的网络问题。
我分析的数据包可能来自自己日常所抓、也可能来自他人。但不论如何，我都会掰开揉碎，帮你了解所应明白的一切。
二、场景介绍
这是一次HTTP POST请求，但是失败，应用层报错。
一共11个包，下面会详细的介绍。
三、数据包剖析
3.1、1-3 号包
这就是众所周知的三次握手啦。如果你对具体细节还不清楚，可以参考我的这篇文章：
不过在继续分析下面的数据包之前，我想问你一个问题：这些数据包是HTTP请求和响应，那么通信就分成client与server两个端。那么这些数据包是从哪端所抓去的呢？
想清楚这个问题，有助于下面的分析。
我提供最起码两种方式来判定，这些数据包到底在哪一端抓取。
1、time
注意看数据包中Time这一栏，我所采用的是
我们选择的是「Seconds Since Previous Displayed Packet」，即表示以相邻两个数据包为单位，Time展示当前数据包与上一个数据包的接收时间差。
仔细观察三次握手，1-2号包的时间差为0.000014,2-3号包的时间差为0.30001。这说明数据包是从server端抓取的。
只有这样，才能解释上述的时间差。
server收到第一次握手的包，然后发送出去，这样1-2之间的时间差还能如此之短，因为这两个数据包都是在server上抓到的，没有经过在网络上的传输。
相反，server发出数据包，到接收第三次握手，是经过了网络传输的。
由此可见，这些数据包确实是从server端获取的。
2、TTL
这种方式是借助网络IP协议的TTL字段。
wiki:Time to live(TTL) or hop limitis a mechanism which limits the lifespan or lifetime of data in a computer or network. TTL may be implemented as a counter or timestamp attached to or embedded in the data. Once the prescribed event count or timespan has elapsed, data is discarded or revalidated. In computer networking , TTL prevents a data packet from circulating indefinitely. In computing applications, TTL is commonly used to improve the performance and manage the [caching] (en.wikipedia.org/wiki/Cache_...of "https://en.wikipedia.org/wiki/Cache_(computing))of") data.
你可以简单理解为：数据包在网络上传输，没经过一个路由器 TTL 的值就减少一个。
你会发现这两者是完全不同的。1号包的TTL一看就知道经过了多个路由器，值被减少了。2号包的TTL值就比1的大很多。
但你能说2号包就没经过路由器进而TTL减少吗？
还真能大差不差的确定。为何？
64 is the standard number for a TTL field in Linux.
Linux机器的TTL标准值就是64喽。
3.2、4-5 号包
4号包表示client发送HTTP post请求，但只是请求headers，请求体在后续包中。
5号包表示我收到你的请求headers了，请继续发送吧
5号包的Ack=309=4号包seq+tcpLen=4号包nextSeq，就是表示收到4号包的内容
到此为止，过程比较顺利。下面开始问题连连
3.3、6 号包
这里的细节太多了，让我们慢慢分析。
首先就是醒目的「TCP Previous segment not captured」，wireshark给我们这个提示，是表示什么意思呢？
这个包不大对劲，它前面本应该是有数据包的，但却提前收到了它。
何以见得？
看seq=777，根据4/5号包的分析，接下来client应该从seq=309开始发送，这个包却是777开头。
6号包的seq=777，TCP Len=0，为什么NextSeq=708？不应该是777+0=777吗？
不是的，一般来说确实nextSeq=Seq+Len。只有两种情况例外，那就是三次握手中的SYN包和四次挥手中的FIN包。而这6号包就是这两种情况中的一种------FIN包。
6号包的Info信息中其实也告诉我们了。
3.4、7 号包
7号包表示很无辜，嘿，兄弟，你应该从seq=309开始发送哈。
「TCP Dup ACK」告诉client端，我收到了你的6号包，不过你是不是丢了一些包没法给我。
重复确认，顾名思义，server端肯定已经确认过了一遍。如图中所示：
3.5、8-9 号包
8号包：client端终于把seq=309的数据包发送过来了，姗姗来迟啊。
到底有多姗姗来迟呢？
居然是7号包之后的16s！过了好久。
其实从时间上，4号包也是有问题的，三次握手之后过了2s才发送请求。
看到这里，就应该重点排查一下client端方面的问题，这绝对不正常。
「TCP Retransmission」这个提示，表示wireshark告诉我们这个包是重传的，也就是并非首次发送。
9号包：server端对8号包的确认
3.6、10-11 号包
10号包：server对client POST请求的回复
11号包：client端直接返回RST，暴力断开连接
3.7、总结
这是一次不同寻常的POST请求，client没有发送完整的请求体，没准重传了n次，才将请求body补齐，但最后本次请求仍以失败而告终。
四、其他注意的点
4.1、10 号包的NextSeq
NextSeq = 70，但是Seq+Len = 1+68，又对不上了？
还记得我上面讲的，三次握手的SYN和四次挥手的FIN都相当于Len=1。
难道10号包是其中一种？
果然是FIN包。
那10号包为什么没有像6号包一样，在Info列中展示FIN标志信息呢？
其实这也是Wireshark的特色：Info列会优先展示应用层协议的内容（FIN标志是控制层TCP层面的信息哩）
4.2、8号包 为什么有重传标志？
或者说，Wireshark到底根据什么，给数据包标上「TCP Retransmission」呢？
直接看源代码啦
如果一个数据包包含数据（或者为SYN/FIN包），并且没有使seq变大，它一定是重传、快速重传、乱序中的一种。
五、结语
本次数据包分析之旅到此结束，不知大家是否喜欢这种形式的文章，欢迎大家来交流学习。