Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "what is the basic principle of Linux Tcp kernel protocol stack Packet Drill". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Linux TCP kernel protocol stack is a very complex implementation, which not only precipitates the design and implementation of the past 20 years, but also is constantly updated. The related RFC and optimization work is still in progress. How to study and learn the Linux TCP kernel protocol stack has become a big problem.

Of course, the most important and basic thing is to read the relevant RFC and the code implementation in the kernel. This is the most basic requirement. It is not enough for a monster such as the TCP kernel protocol stack to simply browse and statically analyze the code. Because the whole implementation is full of boundary conditions and exception handling (this is partly because of the design of the TCP protocol itself), especially TCP is a stateful protocol, many boundary conditions need to be triggered by a series of messages, but also need to meet other conditions such as time delay.

Fortunately, Google solved this problem for everyone in 2013. Google released the TCP kernel protocol stack testing tool Packet Drill in 2013. This tool is worthy of the name and greatly simplifies the difficulty of learning and testing the TCP kernel protocol stack. You can touch almost every detail of the TCP kernel protocol stack at will. This tool of Google is really beneficial to mankind.

With Packet Drill, users can construct message sequences at will, specify all message formats (similar to tcpdump syntax), then communicate with the target system's TCP kernel protocol stack through the TUN interface, and verify the received messages from the target system TCP kernel protocol stack to determine whether they pass the test. Further combined with wireshark+Packet Drill users can get the most intuitive and specific experience. Every detail of every message is under control, slipping away, and life reaches its peak in an instant.

Basic principles of Packet Drill

TUN network equipment

TUN is a virtual network device under Linux, which can be directly connected to the network layer. So that the application can send and receive IP messages directly.

Packet Drill script parsing / execution engine

First of all, the Packet Drill script must be parsed and decomposed into the part of sending and receiving messages through the traditional socket interface and the part of sending and receiving messages through the TUN interface.

Perform the corresponding action on the traditional socket interface.

The corresponding actions are performed in the TUN interface, and the received data is compared.

In this article, the socket interface mainly plays the role of server side. The TUN interface acts as a client. Therefore, we can fully control the IP messages we are about to send through the TUN interface and receive feedback from the TCP protocol stack. And compare it with the preset data.

Introduction to Packet Drill Grammar

Relative time sequence

Packet Drill each event (send / receive / initiate a system call) has a cheaper time relative to the before and after events. Generally, + number is used to express it. For example, + 0 is initiated immediately after the end of the previous event. +. 1 is initiated 0.1 seconds after the end of the previous time. and so on

System call

Packet Drill integrates system calls, which can be done through scripts, such as socket,bind, read,write,getsocketoption, and so on. Students who are familiar with socket programming are easy to understand and use.

Transmission and reception of messages

Through the kernel stack side. You can send and receive messages by calling the system call read/write. But because tcp is a stateful protocol stack, the kernel stack itself sends messages (such as ACK/SACK) according to the state of the protocol stack.

TUN equipment side. Packet Drill usage

< 表示发送报文， 使用 >

Indicates that a message is received.

Format description of message

The expression of the message format is similar to tcpdump. For example, S 0:0 (0) win 1000 means that the win size of the syn packet is 1000, while the option mss (max segment size) for tcp is 1000.

Let's learn further through two examples.

Handshake and Teardown

Let's review this classic process through packet drill's script.

First, let's review the handshake and treardown processes of the TCP protocol standard.

Next, we reproduce the whole process with the script of packet drill.

/ / create a socket on server side The socket on the server side will communicate through the kernel protocol stack / / Note that the traditional system call 0 socket (., SOCK_STREAM, IPPROTO_TCP) = 3 / / sets the corresponding socket options / / Note that the traditional system call + 0 setsockopt (3, SOL_SOCKET, SO_REUSEADDR, [1] is used here 4) = 0 / / bind socket / / Note the traditional system call + 0 bind (3,...,...) = 0 / / listen on the socket / / Note that the traditional system call + 0 listen (3,1) = 0 / / client side (TUN) sends the first message of the syn handshake / / Note the syntax syn seq here is relative Start at 0. + 0

< S 0:0(0) win 1000 // client侧（TUN）期望收到的报文格式 syn+ack 且 ack.no=ISN(c)+1 // 参考标准流程图 最后的 表示任何tcp option都可以 // 这里是握手的第二步 +0 >

S. 0:0 (0) ack 1 / / client side (TUN) sends the ack message seq = ISN (c) + 1, ack = ISN (c) + 1 / / this is the third step of the handshake + .1

< . 1:1(0) ack 1 win 1000 //握手成功，server侧 socket 返回 established socket //这时通过accept 系统调用拿到这个stream 的socket +0 accept(3, ..., ...) = 4 //server侧向stream 写入 10 bytes //通过系统调用来完成写操作 +0 write(4, ..., 10)=10 //client侧期望收到receive 10 bytes +0 >

P. 1:11 (10) ack 1 / / client side reply ack indicates receipt of 10 bytes +. 0

< . 1:1(0) ack 11 win 1000 // client 关闭连接 发送fin包 +0 < F. 1:1(0) ack 11 win 4000 // client侧期望接收到server端的对于fin的ack报文 // 这里由内核协议栈发回。ack = server seq +1, seq = server ack // 参考标准流程图 +.005 >

. 11:11 (0) ack 2 / / server close connection completed by system call + 0 close (4) = 0 / / fin packet format expected by client + 0 > F. 11:11 (0) ack 2 / / client sends a reply ack packet of a fin packet on the server side + 0

< . 2:2(0) ack 12 win 4000 至此， 我们纯手动的完成了全部的发起和关闭连接的过程。然后我们用wireshark 来验证一下 通过结合packetdrill与wireshark 使得每一步都在我们的掌控之中， SACK 我们将使用packet drill 来探索一些更为复杂的案例。例如内核协议栈对于 SACK中各种排列组合的响应。 SACK 是TCP协议中优化重传机制的一个重要选项(该选项一般都在报头的options部分)。 最原始的情况下如果发送方对于 每一个报文接受到ACK之后再发送下一个报文， 效率将是极为低下的。引入滑动窗口之后允许发送方一次发送多个报文 但是如果中间某个报文丢失(没有收到其对应的ACK)那么从那个报文开始，其后所有发送过的报文都要被重新发送一次。造成了极大的浪费。 SACK 是一种优化措施， 用来避免不必要的重发， 告知发送方那些报文已经收到，不用再重发。tcp 的选项中允许带有最多3个SACK的options。也就是三个已经收到了得报文区间信息。说了这么多， 还是有一些抽象， 我们来看一个具体的示例。 示例说明 在下面的这个例子中， 我们需要发送报文的顺序是 1，3，5，6，8，4，7，2 也就是测试一下内核tcp协议栈的SACK逻辑是否如同RFC中所描述的一样。 // 初始化部分建立服务器端socket， 不再赘述 +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // Client 端发送 握手报文以及接受服务器响应，不再赘述。这里注意激活了SACK +.1 < S 0:0(0) win 50000 +0 >

S.0:0 (0) ack 1 win 32000 + 0

< . 1:1(0) ack 1 win 50000 // Server 端就绪 +.1 accept(3, ..., ...) = 4 //发送报文1 +0 < . 1:1001(1000) ack 1 win 50000 //发送报文3， 报文2 被调整到最后发送 +0 < . 2001:3001(1000) ack 1 win 50000 //发送报文5 报文4 被调整乱序 +0 < . 4001:5001(1000) ack 1 win 50000 //发送报文6 +0 < . 5001:6001(1000) ack 1 win 50000 //发送报文8 报文7 被调整乱序 +0 < P. 7001:8001(1000) ack 1 win 50000 //发送报文4 +0 < . 3001:4001(1000) ack 1 win 50000 //发送报文7 +0 < . 6001:7001(1000) ack 1 win 50000 // 接收到第一个报文的ACK +0 >

. 1:1 (0) ack 1001 / / received SACK, reporting out-of-order message 3, but no message 2. + 0 >. 1:1 (0) ack 1001 win 31000 / received SACK, reporting out-of-order message 3, message 5, but no message 2. No message 4 + 0 >. 1:1 (0) ack 1001 win 31000 / received SACK, reporting out-of-order message 3, message 5, but no message 2. No message 4 + 0 >. 1:1 (0) ack 1001 win 31000 / received SACK, reported receipt of out-of-order message 3, message 5jin6, message 8, but no message 2. No message 4, no message 7 + 0 >. 1:1 (0) ack 1001 win 31000 / / received SACK, reported receipt of out-of-order message 3jin4jin5jin6, message 8, but no message 2. There is no message 7 + 0 >. 1:1 (0) ack 1001 win 31000 / / received SACK, reported receipt of out-of-order message 3magentin 4jin5jingle 6jin7 jingle 8, but no message 2 + 0 >. 1:1 (0) ack 1001 win 31000 / / send message 2 so that all messages are finished + 0

< . 1001:2001(1000) ack 1 win 50000 +0 >

. 1:1 (0) ack 8001`

Then let's verify it with wireshark.

It's a perfect match.

In fact, Packet Drill has a very complex and more sophisticated way to play, can fully test a variety of boundary conditions. I will have the opportunity to share with you further in the future.

This is the end of the content of "what is the basic principle of Linux Tcp kernel protocol stack Packet Drill". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.