利用Wireshark学习tcp/ip——握手和挥手

利用wireshark学习http之——tcp三次握手合四次挥手

早上起床后，离上班还有段时间，下载了Wireshark玩玩。
随机选取了一个http，然后右键follow tcp stream，此时界面上就会被自动筛选为该http上下文的报文。

如图所示，
no.130 172.20.10:57019向183.192.195.147:80发送了一个Syn tcp包，该包tcp头部有额外的24字节的option信息，其中一个tcp option表示了maximum segment size(MSS)为1460 bytes，告诉对方我单个tcp包最多可传输1460bytes。
列表上的length表示链路层上的数据长度，我们可以算一下
tcp包内容长度0 + tcp头部20+24 + ip头部20 + 链路层头部14 = 78
后续no.131和no.132是第二次和第三次握手，网上有很多文章这里就不展开讲了。我们可以看到三次握手之后，172.20.10:57019发送的数据包的长度都是1400，满足了183.192.195.147:80的要求。

我们选中no.136，如下图

所以该http请求总共用了4个tcp报文，最后一个的tcp报文长度只有94，总共4294

再看no.137-no.140，每一项ack都对应了请求的数据，回复“我正常收到了数据”。
No.141 是no.136的http请求的响应。

最后看挥手，发现了有个tcp out-of-order的情况，这个是因为tcp的包乱序接收了，所以这里的顺序有问题。我再抓了一个例子

看最后4个包
这里的挥手就正常了
B：我这边没有东西发送了
A：好的，我收到你的通知了，我可能还需要给你发送
A：我这边发送完毕了
B：我收到你的关闭通知了

我们发现在关闭该连接之前，49.120向32.119发送了tcp keep-alive的保活包，保活包里网络层包总长度是40(头部20)，在传输层里头部占20，也就是该tcp包没有负载任何内容。

在wireshark里，发现了这个，wireshark帮我们分析了该包是tcp keep-alive的包，那么wireshark是这么知道的呢？
我们可以看到No.2320，seq是4153，再看No.1076的ack是4154，也就是说明了保活包的seq是对方ack - 1。其实就是该包没有任何的负载内容，所以seq并没有增加。