tcpdump使用时tcp三次握手抓包，ack置1的一些说明
在使用tcpdump抓包的时候，发现tcp的三次握手，第三次的时候竟然将ack置1了，百思不得其解，难道是现在tcp的协议变了吗，让我困惑不已，直接上结果
[root@www test_cpp]# tcpdump -i any port 53 -nn -v
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes17:09:32.524005 IP (tos 0x0, ttl 64, id 30266, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.46894 > 127.0.0.1.53: Flags [S], cksum 0x3e3d (correct), seq 3479715283, win 65495, options [mss 65495,sackOK,TS val 20728809 ecr 0,nop,wscale 7], length 0
17:09:32.524066 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.53 > 127.0.0.1.46894: Flags [S.], cksum 0x74c2 (correct), seq 729305304, ack 3479715284, win 65483, options [mss 65495,sackOK,TS val 20728809 ecr 20728809,nop,wscale 7], length 0
17:09:32.524100 IP (tos 0x0, ttl 64, id 30267, offset 0, flags [DF], proto TCP (6), length 52)
127.0.0.1.46894 > 127.0.0.1.53: Flags [.], cksum 0x9b7e (correct), ack 1, win 512, options [nop,nop,TS val 20728809 ecr 20728809], length 0
首先握手先在本地启了一个dns server，用tcpdump抓53端口的包，然后使用dig 命令+tcp进行查询，然后就出现了上面的结果，当然，通过Telnet,也可以重现这个现象。
现象就是三次握手的最后一次，ack 1？？？？
第一次客户端127.0.0.1.46894 发送seq 3479715283，随机生成的
第二次服务器 127.0.0.1.53 发送seq 729305304, ack 3479715284 ，，ack是前一次的seq+1
第三次客户端127.0.0.1.46894发送ack 1，这不科学，按理来说应该是第二次的seq+1。
重复了几次，都是这样的，通过telnet也是一样的，自己开个网页，去访问抓包也是这样的，这怎么办！！
然后将抓包的报文保存下来-w ，在wireshark上打开，是这样的：
只看前三条，是三次握手的过程在这里：
第一次客户端127.0.0.1.46894 发送seq 0，随机生成的
第二次服务器 127.0.0.1.53 发送seq 0, ack 1 ，，ack是前一次的seq+1
第三次客户端127.0.0.1.46894发送seq 1,ack 1， ack是第二次的seq+1。
再看下面的详细解释：
第一条：
看第二条的解释：
第三条：
原来seq,ack,还是用的原来的tcp协议，没有改变，只不过在wireshark中使用了相对量来显示，
第一次seq:30 aa 5d 22
第二次seq: 8a 5d 87 9b ack:30 aa 5d 23 ack恰好是上一次的seq➕1
第三次seq：30 aa 5d 23 ack: 8a 5d 87 9b ack恰好是上一次的seq➕1。
那么现在可以知道了，抓包本身确实是没有问题的，那问题就只能是tcpdump自己显示的功能有问题了，
应该是tcpdump，前两次都是用的绝对量，第三次然后使用了个相对量，ack 1，这逻辑也是没谁了！！！！无力吐槽，还以为是tcp协议改了呢。