序号(seq)用来标识从TCP发端向TCP收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动,则TCP用序号对每个字节进行计数。序号是32bit的无符号数,序号到达232-1后又从0开始。
当建立一个新的连接时,SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN(InitialSequenceNumber)。该主机要发送数据的第一个字节序号为这个ISN加1,因为SYN标志消耗了一个序号。既然每个传输的字节都被计数,确认序号包含发送确认的一端所期望收到的下一个序号。因此,确认序号(ack)应当是上次已成功收到数据字节序号加1。只有ACK标志(下面介绍)为1时确认序号字段才有效。
发送ACK无需任何代价,因为32bit的确认序号字段和ACK标志一样,总是TCP首部的一部分。因此,我们看到一旦一个连接建立起来,这个字段总是被设置,ACK标志也总是被设置为1。
TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此,连接的每一端必须保持每个方向上的传输数据序号。
- sequence number:表示的是我方(发送方)这边,这个packet的数据部分的第一位应该在整个data stream中所在的位置。(注意这里使用的是“应该”。因为对于没有数据的传输,如ACK,虽然它有一个seq,但是这次传输在整个data stream中是不占位置的。所以下一个实际有数据的传输,会依旧从上一次发送ACK的数据包的seq开始)
- acknowledge number:表示的是期望的对方(接收方)的下一次sequence number是多少。
- 注意,SYN/FIN的传输虽然没有data,但是会让下一次传输的packet seq增加一,但是,ACK的传输,不会让下一次的传输packet加一。
三次握手过程
TCP连接的建立是通过三次握手来实现的
序号 | 方向 | seq | ack | SYN | ACK |
1 | A->B | 10000(ISN) | 0 | 1 | 0 |
2 | A<-B | 20000(ISN) | 10000+1=10001 | 1 | 1 |
3 | A->B | 100001 | 20000+1=20001 | 0 | 1 |
解释:
1:(A) –> [SYN] –> (B)
A向B发起连接请求,以一个随机数初始化A的seq,这里假设为10000,此时ACK=0
2:(A) <– [SYN/ACK] <–(B)
B收到A的连接请求后,也以一个随机数初始化B的seq,这里假设为20000,意思是:你的请求我已收到,我这方的数据流就从这个数开始。B的ACK是A的seq加1,即10000+1=10001
3:(A) –> [ACK] –> (B)
A收到B的回复后,它的seq是它的上个请求的seq加1,即10000+1=100001,意思也是:你的回复我收到了,我这方的数据流就从这个数开始。A此时的ACK是B的seq加1,即20000+1=20001
数据传输过程
序号 | 方向 | seq | ack | 数据长度 | 数据包长度 |
23 | A->B | 40000 | 70000 | 1460 | 1514 |
24 | A<-B | 70000 | 40000+1514-54=41460 | 0 | 54 |
25 | A->B | 41460 | 70000+54-54=70000 | 1460 | 1514 |
26 | A<-B | 70000 | 41460+1514-54=42920 | 0 | 54 |
解释:
23:B接收到A发来的seq=40000,ack=70000,size=1514的数据包
24:于是B向A也发一个数据包,告诉A,你的上个包我收到了。A的seq就以它收到的数据包的ack填充,ack是它收到的数据包的seq加上数据包的大小(不包括:以太网协议头=14字节,IP头=20字节,TCP头=20字节),以证实B发过来的数据全收到了。
25:A在收到B发过来的ack为41460的数据包时,一看到41460,正好是它的上个数据包的seq加上包的大小,就明白,上次发送的数据包已安全到达。于是它再发一个数据包给B。
26:B->A这个正在发送的数据包的seq也以它收到的数据包的ack填充,ack 就以它收到的数据包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是头长,没数据项)。通过tcpdump发现确认包ack,确认传输过程中最后字节长度。
参考:TCP-IP详解卷-基础知识 IP TCP UPD 协议
减去54的原因 ,以太网封装格式(链路层使用的是Ethernet II 格式,这个格式有14字节以太网首部+4字节以太网尾部):
应用数据=size-14-20-20=size-54。(假设IP首部和TCP首部都没有可选选项)
为什么不减去以太网尾部的4字节呢?
因为在物理层上网卡要先去掉前导同步码和帧开始定界符,然后对帧进行CRC检验,如果帧校验和错,就丢弃此帧。如果校验和正确,就判断帧的目的硬件地址是否符合自己的接收条件(目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等),如果符合,就将帧交“设备驱动程序”做进一步处 理。这时我们的抓包软件才能抓到数据,因此,抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS之外的数据
四次挥手过程
序号 | 方向 | seq | ack | FIN | ACK |
1 | A->B | 80000 | 90000 | 1 | 1 |
2 | A<-B | 90000 | 80000+1=80001 | 0 | 1 |
3 | A<-B | 90000 | 80001 | 1 | 1 |
4 | A->B | 80001 | 90000+1=90001 | 0 | 1 |
1:(A) –> [FIN/ACK] –> (B)
客户端A没有要发送给服务端B的数据了,想要关闭链接,则发送一个FIN=1,ACK=1的包,告诉B可以关闭连接了,我没有什么数据要给你了。
2:(A) <– [ACK] <– (B)
然后B会发送ACK=1的包给A,告诉A我知道你没有什么想给我的了,但是我还有数据要给你,你先等下,我先不想FINISH呢。
3:(A) <– [FIN/ACK] <– (B)
等B把数据都发送给A之后,B会再次发送一个包,这次FIN=1,表示我这边也想关闭了,咱俩一起关把。在2和3之间,可能还会有很多B->A的传递,ack均为80001。
4:(A) –> [ACK] –> (B)
然后A回应一个ACK,表示我知道了,一起关吧。B收到这个ACK后,就会CLOSE。但是实际上A不会直接CLOSE,还会进入一个等待时间状态TIME_WAIT,持续2倍的MSL(Maximum Segment Lifetime,报文段在网络上能存活的最大时间)。过了这个状态,才会CLOSE。
为什么要等待一段时间?原因有二:
(1)保证TCP的全双工连接能够可靠关闭
假如A发送的最后一次ACK丢包了,没有被B收到,那B超时之后,会再次发送一个FIN包,然后这个包被处于TIME_WAIT状态的A收到,A会再次发送一个ACK包,并重新开始计时,一直循环这个过程,直到A在TIME_WAIT的整个过程中都没有收到B发过来的FIN包,这说明B已经收到了A的ACK包并CLOSE了,因此A这时候才可以安心CLOSE。如果A没有TIME_WAIT状态而是直接close,那么当ACK丢包之后,B会再次发送一个FIN包,但是这个包不会被A回应,因此B最终会收到RST,误以为是连接错误,不符合可靠连接的要求。因此需要等待ACK报文到达B+BRST是TCP数据报中6个控制位之一,6个控制位的作用如下:
URG 紧急:当 URG=1 时,它告诉系统此报文中有紧急数据,应优先传送(比如紧急关闭),这要与紧急指针字段配合使用。
ACK 确认:仅当 ACK=1 时确认号字段才有效。建立 TCP 连接后,所有报文段都必须把 ACK 字段置为 1。
PSH 推送:若 TCP 连接的一端希望另一端立即响应,PSH 字段便可以“催促”对方,不再等到缓存区填满才发送。
RST复位:若 TCP 连接出现严重差错,RST 置为 1,断开 TCP 连接,再重新建立连接。
SYN 同步:用于建立和释放连接,稍后会详细介绍。
FIN 终止:用于释放连接,当 FIN=1,表明发送方已经发送完毕,要求释放 TCP 连接。
(2)保证这次连接的重复数据段从网络中消失
如果A直接close了,然后向B发起了一个新的TCP连接,可能两个连接的端口号相同。一般不会有什么问题,但是如果旧的连接有一些数据堵塞了,没有达到B呢,新的握手连接就已经到B了,那么这时候,由于区分不同TCP连接是依据套接字,因此B会将这批迟到的数据认为是新的连接的数据,导致数据混乱(源IP地址和目的IP地址以及源端口号和目的端口号的组合称为套接字,新旧连接的套接字很有可能相同)如果我们终止一个客户程序,并立即重新启动这个客户程序,则这个新客户程序将不能重用相同的本地端口。服务端处于被动关闭,不会出现该状态。
总结:
通常TCP在接收到数据时并不立即发送ACK;相反,它推迟发送,以便将ACK与需要沿该方向发送的数据一起发送(有时称这种现象为数据捎带ACK)。
挥手关闭过程中,处于半关闭状态,被动关闭状态传输的数据ack都是一致的。
类型 | 握手(SYN)或终止(FIN) | 传输 | 数据包为0 |
seq(自己发送) | 上次发送 seq+1 | 上次发送seq+数据长度 | 上次发送seq |
ack(接收对方) | 上次接收 seq+1 | 上次接收seq+数据长度 | 上次接收seq |
实战列表:
4、
seq:上一次发送时为【1】,【1】中seq为0且为SYN数据包,所以这一次的seq为1(0增加1)。
ack:上次接收到时为【2】,【2】中seq为0,且为SYN数据包,所以可预计,server端下一次seq为1(0增加1)。
5、
seq:上一次发送时为【2】,【2】中seq为0,且为SYN数据包,所以这一次的seq为1(0增加1)。
ack:上一次接收时为【4】,【4】中的seq为1,数据包的长度为725,所以可以预计,下一次client端的seq为726(1+725)。
6、
seq:上一次发送时为【5】,【5】中seq为1,但【5】为ACK数据包,所以数据长度为0且不会驱使seq加1,所以这一次的seq为1(1+0)。
ack:上一次接收时为【4】,【4】中的seq为1,数据包的长度为725,所以可以预计,下一次client端的seq为726(1+725)。
参考:TCP协议中的seq/ack序号是如何变化的? - 简书