•了解TCP报文段的结构；
•掌握TCP数据流追踪的方法；
•理解TCP三次握手的基本过程；
•理解TCP连接终止的基本过程；
•理解TCP可靠数据传输的基本原理。
我们以抓取京东的页面为例，分析整个抓包过程。首先为了筛选抓包抓到的数据，我们首先进行pingwww.jd.com或者jd的ip，如下所示：
然后使用wireshark进行抓取京东的数据包，同时使用浏览器进行访问京东。根据ping获取的ip的地址进行数据筛选如下所示：
在筛选出京东发送的内容之后就可以利用wireshark进行tcp数据流的追踪，如下所示：
这样我们就可以得到整个流的数据，接下来我们对数据进行分析。
主要是由协议的头部和数据组成，协议的头部大部分是固定的，头部的主要结构如下所示：
接下来我们对获得到了tcp报文进行头部分析：
除了头部，接下来是tcp传输的数据部分，这里不再进行过多分析。
三次握手首先是客户端发送请求，第一条数据SYN=1，表明发起连接；与此同时客户端发送SYN=1，ack=1，表明收到请求，并请求连接；客户端再次发送ack=1表明确认应答。具体过程如下：
分析抓到的数据包如下：
为了更好地进行分析，这里我们采用实验一的数据进行分析，即通过建立ensp发送http的内容进一步分析四次挥手内容。如下所示：
首先是服务器发送fin=1的标志位，表明发送数据完毕，请求断开连接。然后客户端收到请求并应答，之后客户端发送请求断开，客户端发送收到请求。
第一次挥手:192.168.56.10向192.168.56.30发送携带FIN；Seq=160；Ack=308；的数据包，FIN表示请求断开连接，Seq=160表示这个数据包是第160段，Ack=308表示已经收到308段之前的数据包了，下一次请求第308段数据包开始发送。
第二次挥手:192.168.56.30向192.168.56.10发送携带Seq=308；Ack=161；的数据包，表示请求已经收到。
第三次挥手:192.168.56.10向192.168.56.30发送携带FIN；Seq=308；Ack=161；的数据包，表示请求断开连接。
第四次挥手:192.168.56.30向192.168.56.10发送携带Seq=161；Ack=309；的数据包，表示已经接收到请求。
为什么是四次挥手而不是三次：
TCP是全双工通信的，所以双方都可以主动断开。连接服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。
TCP重置
Ackreset:
对于一个Syn包响应Ack Reset包，是在服务端接收到了客户端的建联请求，但是无法在请求的端口进行建联的场景操作，原因可能是：
1.请求建联的服务端并没有监听这个端口。
2.一些原因导致服务端无法在这个端口建联成功，如资源被耗尽，从而无法建立起新的连接。在一些设备上如果没有监听该端口，请求将会被默认丢弃，而不是返回Ack + Reset包，这是出于安全性的考虑，比如防火墙。
传输失败reset：
在三次握手建联之后，当一个网络传输包传输失败（没有接收到该包的ack包超时）时，会进行重传，并尝试等待一段时间ack包，当重传五次依然失败，就会reset该连接。这里的重传次数可以设置，默认为5。reset的原因是我们认为此时在两个网络节点间或希望发送ack包的节点上发生了问题，这也意味着本次连接变得不再有效。
数据超时重传和数据应答机制的基本前提是对每个传输的字节进行编号，即我们通常所说的序列号。数据超时重传是发送端在某个数据包发送出去，在一段固定时间后如果没有收到对该数据包的确认应答，则（假定该数据包在传输过程中丢失）重新发送该数据包。而数据确认应答是指接收端在成功接收到一个有效数据包后，发送一个确认应答数据包给发送端主机，该确认应答数据包中所包含的应答序列号即指已接收到的数据中最后一个字节的序列号加1，加1 的目的在于指出此时接收端期望接收的下一个数据包中第一个字节的序列号。数据超时重传和数据确认应答以及对每个传输的字节分配序列号是TCP 协议提供可靠性数据传输的核心本质。
如下所示是有包丢失问题，在一直请求确认1732之后，如果没有接受到，将会进行重传，这样就解决了丢包问题
因为每一个数据段都有自己的序列号，所以即使重传也不会打乱顺序，tcp会再次进行排序，最终得到完成数据。
Tcp Dup Ack xxx#y代表了数据段丢失TCP状态，正如上图中715号数据丢失，然后开始发送重新发送第一段报文。
