工具|Wireshark抓包对其字TCP段理解

首先我们抓包,因为我们要分析TCP,所以wireshark中设置一下,把http和tls解析去掉,具体操作:
Analyze->Enabled Protols->取消http\http2\Tls,然后就出现如下图所示的抓包图:
工具|Wireshark抓包对其字TCP段理解
文章图片

很清楚的看到这是一个有三次握手的包。
1、首先我们看三次握手的时候两个要点:a)初始序列号的确认 b)Mss确认
下图是TCP报文的头,一般是20个字节(不包含选项数据)
工具|Wireshark抓包对其字TCP段理解
文章图片

首先我们看到端口,端口是TCP/UDP协议中非常重要的一个字段,这个是传输层跟网络层沟通的一个非常重要的标识,有了端口传输层就知道该往那个应用程序发送该层的数据了。
现在我们来看序号和确认序号,
工具|Wireshark抓包对其字TCP段理解
文章图片

上面截图是握手阶段第一个TCP报文的TCP协议段内容截图,从途中我们看到,源端口是45632,目标端口是443,看到下面[]内数据是wireshark解析的辅助信息,我们可以不用管,接下来就是Sequence number:0 这是一个相对序号,下面可以看到一个(raw)表示TCP包真正的序号,相对需要是wireshark设置的,真正的序号一般是一个随机值,表示我发包的时候的起始序号,下一个AcknowledgeMent表示期望收到对方的序号,后面就是FLags,窗口大小,校验和,紧急指针,选项,这个包我们发现选项有20个字节,展开后可以看到比如SACK(选项确认)选项,Window scal等(这些参数非常有用),我们看到这个包的大小是74个字节,那么这个字节是怎么来的呢:TCP+IP+Eth=20+20+20+14,TCP头40个字节,IP头20个字节,以太网14个字节。
序号说明:我发送的第一个序号是3941712145,期望收到的序号是0,因为是第一次握手,不知道对方起始序号,所以设置为0
接着下一个:
工具|Wireshark抓包对其字TCP段理解
文章图片

序号:我这边起始序号是1156976661,期望收到的是3941712145+1
工具|Wireshark抓包对其字TCP段理解
文章图片

序号:我发送的序号是1(相对),期望收到的是1(相对)
工具|Wireshark抓包对其字TCP段理解
文章图片

这个TCP的标示为PSH ACK ,因为TCP是双向连接的,所以每个数据包都是另外一个连接的ACK,这就是每个数据包都是ACK的原因,那么PSH是什么意思呢。书中是这样说的PSH -[接收方应该尽快给应用程序传递这个数据],直白说就是网卡中的数据不是每次来一点数据就上传到应用层,那么什么时候应用层recv才能收到数据呢,你猜对了,就是这个标示,或者缓存满了。收到这个标示的TCP包后,应用层就能将缓存中的数据全部读取到应用层。所以PSH大概意思就是发送者表明后面再没有数据了,请接受者赶快处理吧。有时候再四次挥手阶段也有该标示【PSH FIN ACK】
序号:我发送数据的起始序号是1,期望收到序号为1的包
我们发现,这个TCP中数据长度是517字节,那我们预测对方发送的ACK应该是seq=1,ACK=157+1=158
实际确实如此
【工具|Wireshark抓包对其字TCP段理解】接着看:
工具|Wireshark抓包对其字TCP段理解
文章图片

序号:我发送的序号是1,数据长度是3335,期望收到518的序号数据
对方回复:我发送的是518起始数据包,期待3336数据包
以此类推,有时候TCP并不是收到一个包就回复ACK,而是累计到一定数量后回复一个最后的序号包,这样说明前面的数据包都收到了,并且还会增加ACK的鲁棒性,比如某个ACK没有收到,只要后一个ACK收到,那么也不会导致重复传数据。

    推荐阅读