Linux网络编程: TCP协议之序号和确认号详解

noevil

已于 2024-03-21 19:30:28 修改

阅读量3.6k

点赞数 47

分类专栏：网络编程文章标签：网络 linux tcp/ip

于 2024-03-20 18:01:54 首次发布

本文链接：https://blog.csdn.net/noevil/article/details/136884316

版权

网络编程专栏收录该内容

8 篇文章 0 订阅

订阅专栏

一、TCP协议首部

在这里插入图片描述

二、序号（Sequence Number）

32位，表示该报文段所发送数据的第一个字节的编号。

实际上 TCP 的序号并不是按照 “一条两条” 这样的方式来编号的。在TCP连接中所传输字节流的每一个字节都会按顺序编号，由于序列号是由32位表示，所以每2^32个字节，就会产生序列号回绕，再次从0开始。

TCP在建立连接时由计算机生成的随机数作为其初始值，通过SYN包传给接收端主机，每发送一次数据，就「累加」一次该值。

每个TCP数据报报头填写的序号只需要写TCP数据的头一个字节的序号即可。

这样设计序号的好处？
TCP首部时可以携带选择性确认（Selective Acknowledgment，SACK）选项。如果通信双方支持SACK，那么在数据传输过程中发生了数据丢失或延迟等其他原因造成的接收端数据不连续，那么接收端就可以发送一个SACK包，通知哪一部分失序了。
在这里插入图片描述

Left Edge of Block, 不连续块的第一个数据的序列号
Right Edge of Block, 不连续块的最后一个数据的序列号之后的序列号
该选项参数告诉对方已经接收到并缓存的不连续的数据块，注意都是已经接收的，发送方可根据此信息检查究竟是哪个块丢失，从而发送相应的数据块。

这样就不用重传整个数据包。

三、确认号（Acknowledgment Number）

32位，表示接收方期望收到发送方下一个报文段的第一个字节数据的编号，也就是告诉发送方：我希望你下次发送的数据的第一个字节数据的编号为此确认号。确认号只有在ACK标志为1时才有效。发送端收到确认应答后代表确认序号之前的数据都已经被正常接收。

TCP规定，建立连接后，ACK必须为1，带ACK标志的TCP报文段称为确认报文段，也就是说连接建立之后所有的数据包都会设置确认号。

四、抓包测试

启动一个TCP server

https://github.com/NoevilMe/tinymuduo
这里是我改写的一个muduo网络库，去掉了boost依赖，带了一个sample tcp server。

# 编译
mkdir build && cd build && cmake .. -DBUILD_TINYMODUO_EXAMPLES=ON && make


# 启动
./test_tcp_server 38880

监听38880端口。

启动一个客户端

直接使用了网络调试助手，选择tcp client, 填写好地址和端口，然后连接
在这里插入图片描述

tcp server 日志

包含了整个过程的连接与断开，发送了两次TCP数据，每次发送3068字节，发送内容我省去了。

2024/03/20 12:10:43.148583 109826 INFO  TcpServer::NewConnection [Sample Tcp Server] - new connection[Sample Tcp Server-0.0.0.0:38880#3] from 180.165.165.51:2142 - tcp_server.cxx:56
2024/03/20 12:10:43.148635 109826 DEBUG TcpConnection TcpConnection::ctor[Sample Tcp Server-0.0.0.0:38880#3] at 0x562100CCD100 fd=23 - tcp_connection.cxx:23
2024/03/20 12:10:43.148714 109829 INFO  new connection from 180.165.165.51:2142 - test_tcp_server.cxx:14
2024/03/20 12:10:46.762928 109829 TRACE HandleRead TcpConnection::HandleRead length 3068 - tcp_connection.cxx:129
2024/03/20 12:10:46.762982 109829 INFO  Sample Tcp Server-0.0.0.0:38880#3 receive 3068 bytes, content: http://www.cmsoft.cn- ...
 - test_tcp_server.cxx:26
2024/03/20 12:10:48.987427 109829 TRACE HandleRead TcpConnection::HandleRead length 3068 - tcp_connection.cxx:129
2024/03/20 12:10:48.987481 109829 INFO  Sample Tcp Server-0.0.0.0:38880#3 receive 3068 bytes, content: http://www.cmsoft.cn- ...
 - test_tcp_server.cxx:26
2024/03/20 12:10:51.141446 109829 TRACE HandleRead TcpConnection::HandleRead length 0 - tcp_connection.cxx:129
2024/03/20 12:10:51.141487 109829 DEBUG HandleClose TcpConnection::HandleClose 23 - tcp_connection.cxx:177
2024/03/20 12:10:51.141499 109829 INFO  destory connection from 180.165.165.51:2142 - test_tcp_server.cxx:18
2024/03/20 12:10:51.141513 109829 INFO  TcpServer::RemoveConnection [Sample Tcp Server] - connection Sample Tcp Server-0.0.0.0:38880#3 - tcp_server.cxx:77
2024/03/20 12:10:51.141539 109826 INFO  TcpServer::RemoveConnectionInLoop [Sample Tcp Server] - connection Sample Tcp Server-0.0.0.0:38880#3 - tcp_server.cxx:85
2024/03/20 12:10:51.141565 109829 DEBUG ConnectDestroyed TcpConnection::ConnectDestroyed 23 - tcp_connection.cxx:214
2024/03/20 12:10:51.141574 109829 DEBUG ~TcpConnection TcpConnection::dtor[Sample Tcp Server-0.0.0.0:38880#3] at 0x562100CCD100 fd=23 - tcp_connection.cxx:29