WireShark分析TCP协议

摘要：
利用wireshark分析TCP协议的报文，和其基本行为，包括三次握手，中间信息的交互，和最后的断开连接。其中通过中间信息的交互，可以看出TCP的累积式确认。

一：基本TCP报文分析

我们来看一个简单的TCP报文，现在蓝字选中的是源端口号，我们可以看到在这个报文中是14065，下面对应的是相应的二进制代码，我们可以看到的确是16bit。紧随其后的16bit就是目的端口号。
下面是序号，Sequence number: 1169。接下来的32bit是确认号，Acknowledgement number: 19353。再后面是首部长度，Header length: 20 bytes，和未用的3bit数据。
0= Urgent:Not set，1=Acknowledgement: set，0= Push:Not set，0= Reset:Not set，0= Syn:Not set，0= Fin:Not set，这些表示的是一些标识位，是URG紧急标识，ACK确认标识，PSH推送标识，RST、SYN、FIN用于建立和结束连接。window size value：65535 表示接收窗口。


二：三次握手分析
三次握手的第一步，客户机端会向服务器端发送一个特殊的TCP报文段，这个报文段的SYN被置为1，并会发送一个起始序号seq。

我们看到SYN为1，且Sequence number=0，这样，面对这样的请求报文段，服务器听该返回一个SYN=1，返回自己的初始seq，并且要求主机发送下一个报文段的序号，ack=1。下面是服务端实际返回的报文。

正如我们所期待的那样，服务器返回了自己的seq=0，并且要求主机端发送下一个报文段，并且SYN=1。这样主机端就应该返回seq=1，ack=1，要求服务端发送下一个报文，并且SYN=0，结束建立连接阶段，结束三次握手。

主机端返回了seqence number=1，acknowledgement number=1，SYN=10。这样三次握手就基本结束，开始真正的数据传送阶段。

三：信息的交互
建立了三次握手后，我们就开始利用这个链接来传送信息了。下面我们看看经过三次握手后的第四个TCP报文段。这是服务器返回来的报文段。

 我们惊奇的发现服务器返回了ack=554，即请求第554Byte的数据，而这553Bytes是什么时候发出去的呢，我们想到了在第三次握手的时候，客户端发送的TCP是能够携带数据的。怎么验证是否携带了553Bytes数据呢，我们想到了HTTP协议封装的报文，我我们来验证一下是否是553Bytes，打开HTTP协议如下。

我们看到，HTTP协议封装的报文，长度为Bytes in flight：553。表示已经发送了553Bytes，所以，服务器理应返回一个ack=554的确认，以表示接收到了553Bytes以前的数据，希望接受554bytes以及以后的数据。而上面的第四个报文也正是这么做的。
服务端返回了ack=554之后，服务端没有继续停下，而是继续向客户端发送了两个报文段。我们来看下第五、六个报文段。

第五个报文段发送了seq=1，ack=554告诉服务端，请求你的554数据，我这是第一个数据，但此报文段里有1380bytes。发完后服务端又发送了第六个报文，如下。

服务端发送了seq=1381，ack=554，TCP segment data=1380 Bytes，Bytes in flight=2760。
这表示：我请求第554Bytes，这是我的第1381 Bytes，报文段里一共有1380Bytes，一共传输了2760Bytes。
这次以后，服务端就暂时歇会了，等待客户端的确认。客户端也确实返回了第七个报文段，如下。

seq=554，ack=2761.表示：这是我的第554Bytes，收到了前面的2760个Bytes，请求2761个bytes。这个报文之后，服务端会继续给客户端传送数据，这里就不一一列出了。
我们看到其中服务端多次发送给客户端报文段，而客户端只返回了一个当前正确传输的最大字段，我们可以初步看出TCP是累积式确认的。


四：断开连接
断开连接时，要发送FIN=1，并且对方要回复ACK=1。我们来看下截取的报文段。

我们看到FIN=1。

返回了ACK=1，结束连接。