Linux Tcp 内核协议栈学习三种武器 之 Packet Drill

Posted Linux阅码场

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux Tcp 内核协议栈学习三种武器 之 Packet Drill相关的知识，希望对你有一定的参考价值。

作者简介

作者Liam，海外老码农，对应用密码学、CPU微架构、高速网络通信等领域都有所涉猎。

Linux阅码场原创文章

Linux TCP 内核协议栈是一个非常复杂的实现， 不但沉淀了过去20多年的设计与实现，同时还在不停的更新。相关的RFC与优化工作一直还在进行中。如何研究和学习Linux TCP内核协议栈这样一块硬骨头就成了一大难题。

当然最重要也是最基本的还是要阅读相关的RFC和内核中的代码实现。这个是最最基本的要求。想要驯服TCP 内核协议栈这样的monster 仅仅浏览和静态分析代码是完全不够的。因为整个实现中充斥着各种边界条件和异常的处理（这里有部分原因是因为TCP协议本身设计造成的），尤其是TCP是有状态的协议， 很多边界条件的触发需要一系列的报文来构成，同时还需要满足时延等其它条件。

幸运的是Google在2013年替大家解决了这个难题。Google 在2013 年发布了TCP 内核协议栈 测试工具 Packet Drill。这个工具是名副其实，大大的简化了学习和测试TCP 内核协议栈的难度。基本可以随心所欲的触摸TCP 内核协议栈的每个细节。Google的这件工具真是造福了人类。PacketDrill GitHub link: 

https://github.com/google/packetdrill/

使用Packet Drill， 用户可以随心所欲的构造报文序列，可以指定所有的报文格式（类似tcpdump语法）然后通过TUN接口和目标系统的TCP 内核协议栈来通信， 并对接收到的来自目标系统TCP 内核协议栈 的报文进行校验，来确定是否通过测试。再进一步结合wireshark+Packet Drill 用户可以获得最直观而且具体的体验。每个报文的每个细节都在掌控之中，溜得飞起，人生瞬间到达了巅峰。

Packet Drill 基本原理

TUN 网络设备

TUN 是Linux 下的虚拟网络设备， 可以直通到网络层。使得应用程序可以直接收发IP报文。

Packet Drill 脚本解析/执行引擎

  • 首先 Packet Drill 脚本必须要被解析和分解为 通过传统socket 接口收发报文的部分和通过TUN接口收发报文的部分

  • 在传统socket 接口执行对应的动作。

  • 在TUN接口执行对应的动作，并对收到的数据进行比对。

  • 在本文中 socket 接口主要扮演的是 server side的角色。TUN接口扮演的是client的角色。因而我们可以通过TUN接口完全掌控我们将要发送出去的IP报文，并受到TCP协议栈的反馈。并和预设数据进行比对。

Packet Drill 语法简介

相对时间顺序

Packet Drill 每一个事件（发送/接收/发起系统调用）都有相对前后事件的时间便宜。一般使用+number 来表达。例如+0 就是在之前的事件结束之后立即发起。+.1 表示为在之前时间结束0.1秒之后发起。以此类推

系统调用

Packet Drill 中集成了系统调用， 可以通过脚本来完成例如 socket，bind， read，write，getsocketoption 等等系统调用。熟悉socket 编程的同学很容易理解并使用。

报文的发送与接受

  • 通过内核栈侧。可以通过调用系统调用 read/write 来完成报文的发送与接受。但是因为tcp是有状态的协议栈，所以内核栈本身也会根据协议栈所处状态发送报文（例如ACK/SACK).

  • TUN 设备侧. Packet Drill 使用 < 表示发送报文， 使用 > 表示接收报文。

报文的格式描述

报文格式的表达比较类似tcpdump。例如 S 0:0(0) win 1000 表示syn包 win大小为1000， 同时tcp的选项 mss （max segment size)为1000. 如果不熟悉报文格式， 可以先复习一下《TCP/IP协议详解》 卷1.

进一步的信息请参考 Drilling Network Stacks with packetdrill:

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/41848.pdf

实战示例

下面我们通过2个例子来进一步学习

Handshake and Teardown

我们通过packet drill的脚本 复习一下这个经典的流程。

首选来回顾一下 TCP协议标准的 handshake 和 treardown 流程

Linux Tcp 内核协议栈学习三种武器 之 Packet Drill

接下来我们结合packet drill 的脚本来重现 整个过程

 
   
   
 
    
  
    
    
  
  1. //创建server侧socket， server侧socket 将通过内核协议栈来通信
    2. 
  
    
    
  
  2. // 注意这里使用的是传统的系统调用
    3. 
  
    
    
  
  3. 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
    4. 
  
    
    
  

    5. 
  
    
    
  
  5. //设置对应的socket options
    6. 
  
    
    
  
  6. // 注意这里使用的是传统的系统调用
    7. 
  
    
    
  
  7. +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
    8. 
  
    
    
  

    9. 
  
    
    
  
  9. //bind socket
    10. 
  
    
    
  
  10. // 注意这里使用的是传统的系统调用
    11. 
  
    
    
  
  11. +0 bind(3, ..., ...) = 0
    12. 
  
    
    
  

    13. 
  
    
    
  
  13. //listen on the socket
    14. 
  
    
    
  
  14. // 注意这里使用的是传统的系统调用
    15. 
  
    
    
  
  15. +0 listen(3, 1) = 0
    16. 
  
    
    
  

    17. 
  
    
    
  
  17. // client侧（TUN）发送 syn 握手的第一个报文
    18. 
  
    
    
  
  18. // 注意这里的语法 syn seq都是相对的，从0开始。
    19. 
  
    
    
  
  19. +0 < S 0:0(0) win 1000 <mss 1000>
    20. 
  
    
    
  

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

    26. 
  
    
    
  
  26. // client侧（TUN）发送 ack 报文 seq = ISN(c)+1, ack = ISN(c) +1
    27. 
  
    
    
  
  27. // 这里是握手的第三步
    28. 
  
    
    
  
  28. +.1 < . 1:1(0) ack 1 win 1000
    29. 
  
    
    
  

    30. 
  
    
    
  
  30. //握手成功，server侧 socket 返回 established socket
    31. 
  
    
    
  
  31. //这时通过accept 系统调用拿到这个stream 的socket
    32. 
  
    
    
  
  32. +0 accept(3, ..., ...) = 4
    33. 
  
    
    
  

    34. 
  
    
    
  
  34. //server侧向stream 写入 10 bytes
    35. 
  
    
    
  
  35. //通过系统调用来完成写操作
    36. 
  
    
    
  
  36. +0 write(4, ..., 10)=10
    37. 
  
    
    
  

    38. 
  
    
    
  
  38. //client侧期望收到receive 10 bytes
    39. 
  
    
    
  
  39. +0 > P. 1:11(10) ack 1
    40. 
  
    
    
  

    41. 
  
    
    
  
  41. //client侧应答 ack 表示接收到 10 bytes
    42. 
  
    
    
  
  42. +.0 < . 1:1(0) ack 11 win 1000
    43. 
  
    
    
  

    44. 
  
    
    
  
  44. // client 关闭连接 发送fin包
    45. 
  
    
    
  
  45. +0 < F. 1:1(0) ack 11 win 4000
    46. 
  
    
    
  

    47. 
  
    
    
  
  47. // client侧期望接收到server端的对于fin的ack报文
    48. 
  
    
    
  
  48. // 这里由内核协议栈发回。ack = server seq +1, seq = server ack
    49. 
  
    
    
  
  49. // 参考标准流程图
    50. 
  
    
    
  
  50. +.005 > . 11:11(0) ack 2
    51. 
  
    
    
  

    52. 
  
    
    
  
  52. // server 关闭连接 通过系统调用完成
    53. 
  
    
    
  
  53. +0 close(4) = 0
    54. 
  
    
    
  

    55. 
  
    
    
  
  55. // client期望接收到的fin包格式
    56. 
  
    
    
  
  56. +0 > F. 11:11(0) ack 2
    57. 
  
    
    
  

    58. 
  
    
    
  
  58. // client 发送server端fin包的应答ack包
    59. 
  
    
    
  
  59. +0 < . 2:2(0) ack 12 win 4000
    60.

至此， 我们纯手动的完成了全部的发起和关闭连接的过程。然后我们用wireshark 来验证一下

Linux Tcp 内核协议栈学习三种武器 之 Packet Drill

通过结合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中所描述的一样。

 
   
   
 
    
  
    
    
  
  1.  // 初始化部分建立服务器端socket， 不再赘述
    2. 
  
    
    
  
  2.  +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
    3. 
  
    
    
  
  3.  +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
    4. 
  
    
    
  
  4.  +0 bind(3, ..., ...) = 0
    5. 
  
    
    
  
  5.  +0 listen(3, 1) = 0
    6. 
  
    
    
  

    7. 
  
    
    
  
  7.  // Client 端发送 握手报文以及接受服务器响应，不再赘述。这里注意激活了SACK
    8. 
  
    
    
  
  8.  +.1 < S 0:0(0) win 50000 <mss 1000, sackOK,nop,nop,nop,wscale 7>
    9. 
  
    
    
  
  9.  +0 > S. 0:0(0) ack 1 win 32000 <mss 1000,nop,nop,sackOK>
    10. 
  
    
    
  
  10.  +0 < . 1:1(0) ack 1 win 50000
    11. 
  
    
    
  

    12. 
  
    
    
  
  12.  // Server 端就绪
    13. 
  
    
    
  
  13.  +.1 accept(3, ..., ...) = 4
    14. 
  
    
    
  

    15. 
  
    
    
  
  15.  //发送报文1
    16. 
  
    
    
  
  16.  +0 < . 1:1001(1000) ack 1 win 50000
    17. 
  
    
    
  
  17.  //发送报文3， 报文2 被调整到最后发送
    18. 
  
    
    
  
  18.  +0 < . 2001:3001(1000) ack 1 win 50000
    19. 
  
    
    
  
  19.  //发送报文5 报文4 被调整乱序
    20. 
  
    
    
  
  20.  +0 < . 4001:5001(1000) ack 1 win 50000
    21. 
  
    
    
  
  21.  //发送报文6
    22. 
  
    
    
  
  22.  +0 < . 5001:6001(1000) ack 1 win 50000 
    23. 
  
    
    
  
  23.  //发送报文8 报文7 被调整乱序
    24. 
  
    
    
  
  24.  +0 < P. 7001:8001(1000) ack 1 win 50000
    25. 
  
    
    
  
  25.  //发送报文4
    26. 
  
    
    
  
  26.  +0 < . 3001:4001(1000) ack 1 win 50000
    27. 
  
    
    
  
  27.  //发送报文7
    28. 
  
    
    
  
  28.  +0 < . 6001:7001(1000) ack 1 win 50000
    29. 
  
    
    
  
  29.  // 接收到第一个报文的ACK
    30. 
  
    
    
  
  30.  +0 > . 1:1(0) ack 1001
    31. 
  
    
    
  

    32. 
  
    
    
  
  32.  // 接收到SACK， 报告收到了乱序的报文3，但是没报文2。
    33. 
  
    
    
  
  33.  +0 > . 1:1(0) ack 1001 win 31000 <nop,nop,sack 2001:3001>
    34. 
  
    
    
  
  34.  // 接收到SACK， 报告收到了乱序的报文3，报文5，但是没报文2。没报文4
    35. 
  
    
    
  
  35.  +0 > . 1:1(0) ack 1001 win 31000 <nop,nop,sack 4001:5001 2001:3001>
    36. 
  
    
    
  
  36.  // 接收到SACK， 报告收到了乱序的报文3，报文5，但是没报文2。没报文4
    37. 
  
    
    
  
  37.  +0 > . 1:1(0) ack 1001 win 31000 <nop,nop,sack 4001:6001 2001:3001>
    38. 
  
    
    
  
  38.  // 接收到SACK， 报告收到了乱序的报文3，报文5，6， 报文8，但是没报文2。没报文4，没报文7
    39. 
  
    
    
  
  39.  +0 > . 1:1(0) ack 1001 win 31000 <nop,nop,sack 7001:8001 4001:6001 2001:3001>
    40. 
  
    
    
  
  40.  // 接收到SACK， 报告收到了乱序的报文3，4，5，6， 报文8，但是没报文2。没报文7
    41. 
  
    
    
  
  41.  +0 > . 1:1(0) ack 1001 win 31000 <nop,nop,sack 2001:6001 7001:8001>
    42. 
  
    
    
  
  42.  // 接收到SACK， 报告收到了乱序的报文3，4，5，6，7，8，但是没报文2
    43. 
  
    
    
  
  43.  +0 > . 1:1(0) ack 1001 win 31000 <nop,nop,sack 2001:8001>
    44. 
  
    
    
  

    45. 
  
    
    
  
  45.  //发送报文2 至此所有报文完结
    46. 
  
    
    
  
  46.  +0 < . 1001:2001(1000) ack 1 win 50000
    47. 
  
    
    
  

    48. 
  
    
    
  
  48.  +0 > . 1:1(0) ack 8001`
    49.

随后我们再来用wireshark 验证一下。

Linux Tcp 内核协议栈学习三种武器 之 Packet Drill

果然完全匹配。

Packet Drill 其实还有非常复杂而且更精巧的玩法， 可以充分测试各种边界条件。以后有机会再和大家进一步分享

参考信息

例子脚本的链接:

https://gitee.com/block_chainsaw/linux-kernel-tcp-study.git



更多精彩，尽在"Linux阅码场"，扫描下方二维码关注


别忘了分享、点赞或者在看哦~

以上是关于Linux Tcp 内核协议栈学习三种武器 之 Packet Drill的主要内容，如果未能解决你的问题，请参考以下文章

Linux 网络协议栈之内核锁—— 进程调度

多核心Linux内核路径优化的不二法门之-多核心平台TCP优化

Linux2.6内核协议栈系列--TCP协议1.发送

Linux2.6内核协议栈系列--TCP协议2.接收

Linux操作系统原理—内核网络协议栈

Linux 网络协议栈之内核锁—— 自旋锁在抢占(非抢占)单核和多核中的作用