TCP之SYN报文、FIN报文和ACK报文能够携带数据么？

[lookupheaven]

刚才用TCP/UDP测试工具调程序，发现三次握手和四次断开的最后一个ACK报文都带有6字节全零数据，这个是否正常呢？

[排山和倒海]

正常啊，为什么不正常？ 三次握手过程中的报文是不含数据的，只包含tcp协议首部。

[碼上道]

引用 楼主 Razor87 的回复:

刚才用TCP/UDP测试工具调程序，发现三次握手和四次断开的最后一个ACK报文都带有6字节全零数据，这个是否正常呢？

那个其实不叫数据或者不叫有效的数据，三次握手和四次断开的最后一个ACK报文，这两个报文，ip头+tcp头长度为20+20=40byte, 当报文要发出去的时候，还要加上一个链路层的头14个byte,那么这个报文总共就是40+14=54个byte,但是好像协议规定以太网的帧的长度最小为60，所以有些设备会在报文后面加上6个字节,全部填充为0.这就是楼主为啥会觉得有数据。 你可以看一下ip头中的数据长度，应该为40，而不是46

[mujiok2003]

引用 4 楼 jerry_dqh 的回复:

[quote=引用 楼主 Razor87 的回复:] 刚才用TCP/UDP测试工具调程序，发现三次握手和四次断开的最后一个ACK报文都带有6字节全零数据，这个是否正常呢？

那个其实不叫数据或者不叫有效的数据，三次握手和四次断开的最后一个ACK报文，这两个报文，ip头+tcp头长度为20+20=40byte, 当报文要发出去的时候，还要加上一个链路层的头14个byte,那么这个报文总共就是40+14=54个byte,但是好像协议规定以太网的帧的长度最小为60，所以有些设备会在报文后面加上6个字节,全部填充为0.这就是楼主为啥会觉得有数据。 你可以看一下ip头中的数据长度，应该为40，而不是46[/quote] ++

[Cnwanglin]

你可以 好好看看TCP IP 协议卷，慢慢理解，里面说的很透彻 TCP 的知识涵盖面比较广，单一的知识点的讲解提高不了

[我看你有戏]

OSI参考模型中的网络层，在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认； 第二次握手：服务器收到syn包，必须确认客户的syn（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

[KangRoger]

SYN报文不能携带数据，因为连接还没建立。 ACK报文段要分情况，假设A主动发起连接到B，在B发给A的ACK报文不携带数据，连接没建立，但是A给B的ACK报文可以带数据（在B发送ACK后，A到B的连接就已经建立了）。 FIN报文可以携带数据，因为连接还没释放。

[lookupheaven]

引用 2 楼 Cnwanglin 的回复:

你可以 好好看看TCP IP 协议卷，慢慢理解，里面说的很透彻 TCP 的知识涵盖面比较广，单一的知识点的讲解提高不了

看来这本书终归是要看的呀，网络编程终于让我发现了软件的另一个世界

[lookupheaven]

引用 4 楼 jerry_dqh 的回复:

[quote=引用 楼主 Razor87 的回复:] 刚才用TCP/UDP测试工具调程序，发现三次握手和四次断开的最后一个ACK报文都带有6字节全零数据，这个是否正常呢？

那个其实不叫数据或者不叫有效的数据，三次握手和四次断开的最后一个ACK报文，这两个报文，ip头+tcp头长度为20+20=40byte, 当报文要发出去的时候，还要加上一个链路层的头14个byte,那么这个报文总共就是40+14=54个byte,但是好像协议规定以太网的帧的长度最小为60，所以有些设备会在报文后面加上6个字节,全部填充为0.这就是楼主为啥会觉得有数据。 你可以看一下ip头中的数据长度，应该为40，而不是46[/quote] got it，多谢了