欢迎光临
我的个人博客网站

使用 shell 做 tcp 协议模拟


问题背景

公司有一套消息推送系统(简称GCM),由于人事变动接手了其中的客户端部分。看了一下文档,仅通讯协议部分有几页简单的说明,代码呢又多又乱,一时理不出一个头绪。由于消息是从后台推送到端的,所以使用了 tcp 长连接通道来保证消息的及时性,基于 http 的一堆分析工具(如 postman)完全没有用武之地,因此决定写个小工具来模拟 tcp 上的通讯协议,作为深入熟悉代码之前的热身。

问题的解决

一开始想用 c++ 来写这个工具,但是想到 socket 一连串经典的(socket / bind / connect / send / recv…)的繁琐调用我还是算了,之前用 shell 写过几个小工具很舒爽,但那都是借用 curl 命令来处理 http 协议,面对 tcp 协议 curl 肯定是无能为力了,因为命令执行完成后连接也就断开了,无法模拟长连接。那是不是就不能用 shell 写了呢?非也。

连接的建立与断开

我突然想到 shell 本身好像可以支持将 tcp 连接打开为文件:

exec N <> /dev/tcp/host/port 

上面这段脚本就可以在句柄为 N 的文件上打开到 host 且端口为 port 的 tcp 连接了,并且可以进行双向读写。于是赶快在 msys2 中试了一下:

1 exec 3<>/dev/tcp/$gcm_host/$gcm_port 2 ret=$? 3 echo "open tcp $ret" 4 if [ $ret != 0 ]; then 5     echo "connect to gcmserver failed" 6     exit 1 7 fi 8  9 echo "connect with server"

 

这里脚本直接使用标准输入(0)、输出(1)、错误(2)之后的句柄 3 作为连接句柄,跑了一下,似乎什么也没有发生:

使用 shell 做 tcp 协议模拟

 

好在 Windows 上有 procexp 工具,可以查看进程创建的所有  tcp 连接:

使用 shell 做 tcp 协议模拟

 

看起来这个连接确实建立成功了。当然你也可以用 windows 上的 netstat 命令查看:

C:Usersyunh>netstat -no  活动连接    协议  本地地址          外部地址        状态           PID   TCP    10.2.56.38:1993        10.100.200.2:10003     ESTABLISHED     10320   TCP    10.2.56.38:2346        175.27.0.15:80         ESTABLISHED     14808   TCP    10.2.56.38:2474        121.51.139.161:8080    ESTABLISHED     15092   TCP    10.2.56.38:3147        10.2.56.13:7680        ESTABLISHED     8816   TCP    10.2.56.38:3576        47.97.243.182:80       ESTABLISHED     11292   TCP    10.2.56.38:3602        10.0.24.13:28888       ESTABLISHED     16224   TCP    10.2.56.38:3720        113.96.233.143:443     ESTABLISHED     15252   TCP    10.2.56.38:5006        10.2.61.20:7680        ESTABLISHED     8816   TCP    10.2.56.38:5022        10.2.25.16:7680        ESTABLISHED     8816   TCP    10.2.56.38:5303        49.232.126.211:443     ESTABLISHED     11292   TCP    10.2.56.38:6182        10.0.109.249:443       ESTABLISHED     16168   TCP    10.2.56.38:6183        10.0.109.249:443       ESTABLISHED     16168   TCP    10.2.56.38:6357        52.11.109.209:443      ESTABLISHED     11292   TCP    10.2.56.38:6697        40.90.189.152:443      ESTABLISHED     5268   TCP    10.2.56.38:7065        117.18.237.29:80       CLOSE_WAIT      4724   TCP    10.2.56.38:7100        220.170.53.122:443     TIME_WAIT       0   TCP    10.2.56.38:7113        220.181.174.166:443    TIME_WAIT       0   TCP    10.2.56.38:7117        180.163.150.166:443    ESTABLISHED     11292   TCP    10.2.56.38:7135        140.143.52.226:443     TIME_WAIT       0   TCP    10.2.56.38:7141        10.0.24.13:8888        CLOSE_WAIT      16224   TCP    10.2.56.38:7143        101.201.169.146:443    TIME_WAIT       0   TCP    10.2.56.38:7144        103.15.99.107:443      TIME_WAIT       0   TCP    10.2.56.38:7148        203.119.214.115:443    TIME_WAIT       0   TCP    10.2.56.38:7149        61.151.167.89:443      TIME_WAIT       0   TCP    10.2.56.38:7150        203.119.169.141:443    TIME_WAIT       0   TCP    10.2.56.38:7151        203.119.144.59:443     TIME_WAIT       0   TCP    10.2.56.38:7159        114.55.187.58:443      ESTABLISHED     11292   TCP    10.2.56.38:7160        42.121.254.191:443     TIME_WAIT       0   TCP    10.2.56.38:7162        118.178.109.187:443    TIME_WAIT       0   TCP    10.2.56.38:7165        47.110.223.99:443      TIME_WAIT       0   TCP    10.2.56.38:7166        116.62.93.118:443      TIME_WAIT       0   TCP    10.2.56.38:7195        123.150.76.171:80      CLOSE_WAIT      10772   TCP    10.2.56.38:6974        ##################     ESTABLISHED     10984   TCP    10.2.56.38:7215        192.168.0.9:80         CLOSE_WAIT      4700   TCP    10.2.56.38:7218        10.2.100.217:7680      SYN_SENT        8816   TCP    10.2.56.38:7219        192.168.56.1:7680      SYN_SENT        8816   TCP    10.2.56.38:7680        10.2.102.27:53199      ESTABLISHED     8816   TCP    10.2.56.38:9763        192.168.23.23:49156    ESTABLISHED     4600   TCP    10.2.56.38:10267       125.39.132.161:80      ESTABLISHED     10772   TCP    10.2.56.38:10816       60.205.204.27:80       ESTABLISHED     10872   TCP    127.0.0.1:443          127.0.0.1:7216         ESTABLISHED     8108   TCP    127.0.0.1:2002         127.0.0.1:2003         ESTABLISHED     11292   TCP    127.0.0.1:2003         127.0.0.1:2002         ESTABLISHED     11292   TCP    127.0.0.1:2013         127.0.0.1:2014         ESTABLISHED     9600   TCP    127.0.0.1:2014         127.0.0.1:2013         ESTABLISHED     9600   TCP    127.0.0.1:2015         127.0.0.1:2016         ESTABLISHED     12948   TCP    127.0.0.1:2016         127.0.0.1:2015         ESTABLISHED     12948   TCP    127.0.0.1:2040         127.0.0.1:2041         ESTABLISHED     13960   TCP    127.0.0.1:2041         127.0.0.1:2040         ESTABLISHED     13960   TCP    127.0.0.1:2109         127.0.0.1:2110         ESTABLISHED     15092   TCP    127.0.0.1:2110         127.0.0.1:2109         ESTABLISHED     15092   TCP    127.0.0.1:2349         127.0.0.1:50051        ESTABLISHED     6308   TCP    127.0.0.1:2566         127.0.0.1:30031        ESTABLISHED     10624   TCP    127.0.0.1:3032         127.0.0.1:3033         ESTABLISHED     20276   TCP    127.0.0.1:3033         127.0.0.1:3032         ESTABLISHED     20276   TCP    127.0.0.1:3517         127.0.0.1:3518         ESTABLISHED     18200   TCP    127.0.0.1:3518         127.0.0.1:3517         ESTABLISHED     18200   TCP    127.0.0.1:3768         127.0.0.1:3769         ESTABLISHED     14076   TCP    127.0.0.1:3769         127.0.0.1:3768         ESTABLISHED     14076   TCP    127.0.0.1:3854         127.0.0.1:3855         ESTABLISHED     17380   TCP    127.0.0.1:3855         127.0.0.1:3854         ESTABLISHED     17380   TCP    127.0.0.1:4895         127.0.0.1:4896         ESTABLISHED     15524   TCP    127.0.0.1:4896         127.0.0.1:4895         ESTABLISHED     15524   TCP    127.0.0.1:5320         127.0.0.1:5321         ESTABLISHED     16736   TCP    127.0.0.1:5321         127.0.0.1:5320         ESTABLISHED     16736   TCP    127.0.0.1:6688         127.0.0.1:10803        ESTABLISHED     10872   TCP    127.0.0.1:6688         127.0.0.1:10824        ESTABLISHED     10872   TCP    127.0.0.1:6688         127.0.0.1:10841        ESTABLISHED     10872   TCP    127.0.0.1:6688         127.0.0.1:10849        ESTABLISHED     10872   TCP    127.0.0.1:6689         127.0.0.1:10819        ESTABLISHED     10672   TCP    127.0.0.1:7187         127.0.0.1:443          TIME_WAIT       0   TCP    127.0.0.1:7216         127.0.0.1:443          ESTABLISHED     10548   TCP    127.0.0.1:8419         127.0.0.1:8420         ESTABLISHED     14716   TCP    127.0.0.1:8420         127.0.0.1:8419         ESTABLISHED     14716   TCP    127.0.0.1:10803        127.0.0.1:6688         ESTABLISHED     2256   TCP    127.0.0.1:10819        127.0.0.1:6689         ESTABLISHED     13436   TCP    127.0.0.1:10824        127.0.0.1:6688         ESTABLISHED     10672   TCP    127.0.0.1:10841        127.0.0.1:6688         ESTABLISHED     15448   TCP    127.0.0.1:10849        127.0.0.1:6688         ESTABLISHED     9772   TCP    127.0.0.1:30031        127.0.0.1:2566         ESTABLISHED     10608   TCP    127.0.0.1:50051        127.0.0.1:2349         ESTABLISHED     10608   TCP    [::1]:5900             [::1]:5901             ESTABLISHED     10548   TCP    [::1]:5901             [::1]:5900             ESTABLISHED     10548   TCP    [::1]:7188             [::1]:8307             FIN_WAIT_2      8108   TCP    [::1]:7217             [::1]:8307             ESTABLISHED     8108   TCP    [::1]:8307             [::1]:7188             CLOSE_WAIT      8108   TCP    [::1]:8307             [::1]:7217             ESTABLISHED     8108 

 

这里主要是通过过滤进程 ID 来实现快速定位的。连接也可以被主动关闭,这需要使用下面的重定向语法(其实就是关闭普通文件):

exec N < &- 

其中 N 就是刚才打开的文件句柄,可以用 > 等效替换 <。在 msys2 中就可以这样验证了:

使用 shell 做 tcp 协议模拟

 

最后仍然是通过 procexp 工具或 netstat 命令来查看执行结果。另外使用 echo $? 获取 exec 执行结果为 0 似乎并不能确认连接已经建立,因为我对一个错误的 host + port 使用 exec 仍然能得到 0。

机器上下线

连接建立好以后,需要向后台上报本机的一些基本信息,这个协议称为机器上线:

 1 function send_request_100 ()  2 {  3     local msg=$(cat protocol/100.gcm)  4     # do replace  5     msg=$(echo "$msg" | jq --arg guid "$devid" --arg hwid "$hardid" -c '{ version, msgtype, guid: $guid, devinfo: { hwid: $hwid, devid: $guid, os: .devinfo.os, os_version: .devinfo.os_version, sysbit: .devinfo.sysbit, languageid: .devinfo.languageid } }')  6     echo $msg >&3  7     local ret=$?  8     if [ $ret -ne 0 ]; then   9         echo "connection break, send failed" 10         exit 3 11     fi 12 } 13  14 # online myself 15 send_request_100

 

机器上线的过程被封装成了一个函数:send_request_100,这里 100 是机器上线的消息号。其实消息发送就是一句代码的事儿(line 6),这个函数的主要工作是组装 100 协议的内容(line 3-5)。消息都是 json 格式的串,为了降低代码与协议的耦合度,这里把每个协议都放在单独的文件中,例如上面的 “100.gcm” 文件存放的就是机器上线的消息模板:

{     "version": "3.1",     "msgtype": "100",     "guid": "",     "devinfo": {         "hwid": "",         "devid": "",         "os": "Windows",         "os_version": "7",         "sysbit": "64",         "languageid": "2052"     } } 

 

从文件中读取到本地变量后,需要做一些填充工作(guid / hwid / devid… 字段),这里使用了 jq 命令的 –arg 选项来传递外部参数并基于它们重新捏合 json 串,这些参数(devid / hardid)又是在脚本启动前就从注册表中读取并传入的。机器上线后才可以进行产品的上下线,而且相应的,当客户端停止时,也要告诉后台机器下线:

 1 function send_request_101  2 {  3     local msg=$(cat protocol/101.gcm)  4     # do replace  5     msg=$(echo "$msg" | jq --arg guid "$devid"  -c '{ version, msgtype, guid: $guid }')  6     echo $msg >&3  7     local ret=$?  8     echo "send 101 msg to gcm $ret" >> log.txt  9     if [ $ret -ne 0 ]; then  10         echo "connection break, send failed" 11         exit 3 12     fi 13  14     # no response for 101 message 15     echo "offline success! devid=$devid" 16 } 17  18 # -1st offline myself 19 send_request_101

 

这个过程封装在 send_request_101 函数中,这里 101 是机器下线的消息号。同样的,这个消息也有模板文件:

{     "version": "3.1",     "msgtype": "101",     "guid": "" } 

 

相对简单一点。protocol 子目录包含了所有消息协议的模板:

$ ls -lhrt total 7.0K -rw-r--r-- 1 yunh 1049089 312 5月  28  2019 102.gcm -rw-r--r-- 1 yunh 1049089 102 5月  28  2019 101.gcm -rw-r--r-- 1 yunh 1049089 350 5月  28  2019 100.gcm -rw-r--r-- 1 yunh 1049089 141 5月  28  2019 412.gcm -rw-r--r-- 1 yunh 1049089 166 5月  28  2019 108.gcm -rw-r--r-- 1 yunh 1049089 193 5月  28  2019 103.gcm -rw-r--r-- 1 yunh 1049089 478 7月  26  2019 custom.gcm 

 

机器下线的其它处理流程和上线差不太多,这里就不赘述了。后面不会对消息内容做详细介绍了,主要是涉及到协议保密的问题。

产品上下线

机器在开机上线,产品在启动时上线,这样当后台有推送内容时,相应的消息就可以推送过来(不会对没上线的产品推送):

 1 # $1: app name  2 # $2: app version  3 # $3: user id  4 # $4: device id  5 function send_request_102 ()  6 {  7     local guid=$(echo "$4$1$3" | sha1sum | awk '{ print $1 }')  8     local msg=$(cat protocol/102.gcm)  9     # do replace 10     msg=$(echo "$msg" | jq --arg appname "$1" --arg appver "$2" --arg userid "$3" --arg guid "$guid" -c '{ version, msgtype, guid: $guid, appclientid: $appname, appuserid: $userid, clientinfo: { appversion: $appver, platform: .clientinfo.platform, bits: .clientinfo.bits } }') 11     echo $msg >&3 12     local ret=$? 13     echo "send 102 msg to gcm $ret" >> log.txt 14     if [ $ret -ne 0 ]; then  15         echo "connection break, send failed" 16         exit 3 17     fi 18 } 19  20 # online GCMPopBox/GUX/GSUP 21 send_request_102 "GCMPopBox" "2.0.0.0" "$hardid" "$devid" 22 send_request_102 "GUX" "$version" "$devid" "$devid" 23 send_request_102 "GSUP" "$version" "$devid" "$devid"

 

这个过程封装在 send_request_102 函数中,这里 102 是产品上线的消息号。这个函数接收四个参数,分别是产品标识、产品版本、用户标识和机器标识。在机器上线后,会固定上线三个产品:GCMPopBox、GUX 和 GSUP,都是客户端自带的几个服务产品。当产品关闭时,要向后台发送产品下线消息:

 1 # $1: app name  2 # $2: user id  3 # $3: device id  4 function send_request_103  5 {  6     local guid=$(echo "$3$1$2" | sha1sum | awk '{print $1}')  7     local msg=$(cat protocol/103.gcm)  8     # do replace  9     msg=$(echo "$msg" | jq --arg appname "$1" --arg userid "$2" --arg guid "$guid" -c '{ version, msgtype, guid: $guid, appclientid: $appname, appuserid: $userid }') 10     echo $msg >&3 11     local ret=$? 12     echo "send 103 msg to gcm $ret" >> log.txt 13     if [ $ret -ne 0 ]; then  14         echo "connection break, send failed" 15         exit 3 16     fi 17  18     # no response for 103 message 19     echo "$1 offline success! userid=$2" 20 } 21  22 # -2nd offline GCMPopBox/GUX/GSUP 23 send_request_103 "GCMPopBox" "$hardid" "$devid" 24 send_request_103 "GUX" "$devid" "$devid" 25 send_request_103 "GSUP" "$devid" "$devid"

 

这个过程封装在 send_request_103 函数中,其中 103 是产品下线的消息号。和产品上线消息相比,不用再提供产品版本了,其它方面大同小异。在机器下线前,需要对之前上线的几个客户端服务产品一一下线(GCMPopBox / GUX / GSUP)。除了固定的产品,用户也可以在命令行指定某个产品去上线,这个工具跑起来后长这个样子:

使用 shell 做 tcp 协议模拟

 

 红框中的部分其实是一个循环,用户可以不停的输入要上下线的产品进行操作,这部分的代码相应的也位于一段  while 循环中:

 1 # online/offline products  2 while :  3 do   4     echo "-------------------------------------------"  5     echo -n "product name to operate (exit|quit to quit): "  6     read product  7     if [ "$product" == "exit" -o "$product" == "quit" ]; then   8         break;   9     fi 10  11     echo -n "operation (online|offline): " 12     read resp 13     online=0 14     case "$resp" in 15       ""|"o"|"O"|"on"|"ON"|"online"|"ONLINE") 16         online=1 17         ;; 18       *) 19         ;; 20     esac 21  22     if [ $online == 1 ]; then  23         echo -n "version: " 24         read version 25     fi 26  27     echo -n "user id: " 28     read userid 29  30     if [ $online == 1 ]; then  31         send_request_102 "$product" "$version" "$userid" "$devid" 32     else  33         send_request_103 "$product" "$userid" "$devid" 34     fi 35  36     sleep 1 37 done 

下面做个简单讲解:

  • line 4-9:如果用户输入 quit 或 exit,退出循环从而退出整个脚本。否则收集到要操作的产品标识;
  • line 11-20:提示用户输入进行何种操作,上线 or 下线;
  • line 22-25:如果是上线操作,则需要用户输入产品版本;
  • line 27-28:提示用户输入用户 ID;
  • line 30-34:根据用户输入的操作类型,调用前面封装好的函数来完成产品上下线。

 

接收推送消息

产品上线成功后,就可以接收来自后台的“问候”了。这块和前面那种一问一答模式不一样,需要异步处理连接上到达的数据。我的第一反应就是开个线程来处理,但是 shell 里并没有线程这种东西,只有子进程可以用。问题是开子进程后原句柄 (3) 还能代表以前的连接吗?在 linux 上这一点不容置疑,但是 windows 上可没有 fork 这东东啊,怎么保证新启动的子进程复制父进程的用户空间呢?带着疑问,我尝试了下面的代码:

1 echo "connect with server" 2 on_recv & 3 cpid=$!

 

将接收消息相关代码封装在 on_recv 函数中,就可以直接用 ‘&’ 启动一个单独的进程去跑这个函数啦!作为测试,一开始我只在 on_recv 中处理了几个简单的应答消息(100->201,102->301……):

 1 function on_recv  2 {  3     # can not break read !  4     #trap "echo recv exit signal from parent" INT  5     while :  6     do  7         #read msg <&3  8         #msg=$(tail -f <&3)  9         #read -t 1 msg <&3 10         local msg="" 11         read -d '}' msg <&3 12         if [ -z "$msg" ]; then  13             echo -e "nconnection break, receive failed" 14             exit 3 15         fi  16      17         msg="$msg}" 18         local type=$(echo "$msg" | jq -r '.msgtype') 19         case "$type" in 20           "201") 21             local guid=$(echo "$msg" | jq -r '.guid') 22             echo "online success! devid=$guid" 23             ;; 24           "301") 25             local appname=$(echo "$msg" | jq -r '.appclientid') 26             local userid=$(echo "$msg" | jq -r '.dstuserid') 27             echo "$appname online success! userid=$userid" 28             ;; 29           *) 30             echo "unknown response type: $type" 31             #exit 32             ;; 33         esac 34     done 35 }

 

收到这几个应答消息时,会将其中关键的字段打印在屏幕上。应答消息同请求消息一样,也是纯 json 格式,因此这里使用 jq 来做解析 (line 17-33)。

不过难点倒不在这儿,真正让我费了半天劲儿的地方是在读取,可能有人说了,读取有什么难的,直接 read 不就行了吗?我一开始就是这样做的 (line 7),然而 read 会一直卡在那里读数据,即使已经有消息读到了也不返回。简单分析一下:看起来 read 在等一个结束标志,一般而言就是换行 ‘n’,这也是为什么你可以一直在 console 界面输入内容、直到回车结束的原因。然而后台应答消息并没有换行符作为消息结束,于是我尝试了另外一个方案,使用 tail -f 读取连接中的内容 (line 8),然而没有任何改进。

因此这里我又试了第三个方案 (line 9),为 read 增加了一个超时时间 (1s),这样当时间足够长了以后也能返回之前读到的消息,缺点是 read 会每隔一秒中断一次;然而我忽略了一个更严重的问题的,那就是当产品积压了很多消息没有推送后,当它上线的一刻后台会同时给它推送多个消息,这样一来,这个带超时的 read 常常会将多个消息粘在一起返回,导致后面的解析出错。

于是我试了现在这个方案 (line 11),告诉 read 一直读、直到遇到 json 结尾符 ‘}’。当然这也不是完全保险的,因为 json 中有可能存在嵌套的子结构、导致内部含有 ‘}’,但好在现有的协议中应答消息都比较简单,基本上一对花括号之内不会再有花括号了,所以可以这样搞。这个脚本跑起来的效果,其实前面那张图已经展示过了,这次重新划一下重点:

使用 shell 做 tcp 协议模拟

 

可以看到,新的子进程可以很好的收到机器和产品上线的应答消息(下线没有应答消息),看起来就像它与父进程共享了这个连接一样。验证了 msys2 这个功能没问题后,下面就开始我们的重头戏了 —— 接收后台推送的消息:

 1           "105")  2             local guid=$(echo "$msg" | jq -r '.guid')  3             local appclientid=$(echo "$msg" | jq -r '.appclientid')  4             local msgid=$(echo "$msg" | jq -r '.msgid')  5             local msgbody=$(echo "$msg" | jq -r '.msgbody')  6             local appuserid=$(echo "$msg" | jq -r '.appuserid')  7             local dstuserid=$(echo "$msg" | jq -r '.dstuserid')  8             echo ""  9             echo "*******************************************" 10             echo "receive customer message " 11             echo "product: $appclientid" 12             echo "userid : $appuserid" 13             echo "msgid  : $msgid" 14             local body_utf8=$(echo "$msgbody" | base64 -d) 15             local body=$(echo "$body_utf8" | iconv -f utf-8 -t gb2312) 16             echo "content: $body" 17             echo "*******************************************" 18             send_request_108 "$guid" "$appclientid" "$appuserid" "$msgid" 19             ;;

 

这里直接上 case 语句。105 是自定义消息,这个应用自己“偷摸”处理掉就好啦,不用给用户展示,这边出于演示目的直接将消息内容打印在屏幕上(有一些 base64 解码及 utf8 编码转换的工作:line 14-15)。收完消息后,给后台回复一个 108 消息表示成功接收,send_request_108 与其它 send 函数大同小异,这里不展开说明了。真正复杂的部分是接收弹窗消息:

 1           "401")  2             local guid=$(echo "$msg" | jq -r '.guid')  3             local appclientid=$(echo "$msg" | jq -r '.appclientid')  4             local msgid=$(echo "$msg" | jq -r '.msgid')  5             local msgbody=$(echo "$msg" | jq -r '.msgbody')  6             local appuserid=$(echo "$msg" | jq -r '.appuserid')  7             local dstuserid=$(echo "$msg" | jq -r '.dstuserid')  8             echo ""  9             echo "*******************************************" 10             echo "receive popup message " 11             echo "product: $appclientid" 12             echo "userid : $appuserid" 13             echo "msgid  : $msgid" 14             echo "" 15             local body=$(echo "$msgbody" | base64 -d) 16             local title_utf8=$(echo "$body" | jq -r '.title') 17             local title=$(echo "$title_utf8" | iconv -f utf-8 -t gb2312) 18             local content_utf8=$(echo "$body" | jq -r '.content') 19             local content=$(echo "$content_utf8" | iconv -f utf-8 -t gb2312) 20             local ctxurl=$(echo "$body" | jq -r '."content-url"') # - is not recognized 21             local image=$(echo "$body" | jq -r '.image') 22             local imgurl=$(echo "$body" | jq -r '."image-url"') # - is not recognized 23             echo "title  : $title" 24             echo "content: $content" 25             echo "ctxurl : $ctxurl" 26             echo "image  : $image" 27             echo "imgurl : $imgurl" 28             echo "*******************************************" 29  30             # prepare 108 message 31             send_request_108 "$guid" "$appclientid" "$appuserid" "$msgid" 32             sleep 1 33             # prepare 402 message 34             send_request_402 "$msg" "$hardid" 35             ;;

 

401 就是弹窗消息,本来是要给用户在屏幕右下角弹个小窗显示的,这里为了简化问题,也直接打印在屏幕上。收到 401 消息后要先给后台回复一个 108 表示成功接收,再回复一个 402 来表示弹窗最终结果,例如用户点击、关闭、查看详情…等等,这里直接返回用户关闭作为模拟。下面是产品上线后,收到推送消息的效果:

使用 shell 做 tcp 协议模拟

 

这里演示了两个消息,分别是弹窗消息与自定义消息,可以看到都能正常的解析与显示。后台也可以正常的统计到这两个消息的推送情况:

使用 shell 做 tcp 协议模拟

 

最后,当用户退出操作循环后,需要及时回收子进程:

1 exec 3>&- 2 kill -INT $cpid 3 wait

 

这里通过 kill 产生 INT 消息来通知子进程退出接收循环,接着通过 wait 等待子进程完全退出。之前也尝试在子进程中捕获 (trap) INT 信号并优雅的退出,但是发现在 windows 环境下加了这个捕获反而导致 read 不能被中断了,so 放弃之。现在这种方式可能是直接把子进程给杀死了,虽然“暴力”一点,但是起码可以正常工作。

后记

通过构建这个小工具,我甚至发现了协议文档中书写错误或不详的地方。不过最让我感到好奇的还是 —— windows 上是怎么实现两个进程共享一个连接句柄的? 为了解答这个问题,祭出 procexp 大杀器:

使用 shell 做 tcp 协议模拟

 

可以看到连接只在父进程(20612)中展示,子进程(16844)中并没有对应的连接,那它是怎么在连接上读数据的呢?左看右看没有看出什么头绪。想用 msys2 的 lsof 命令查看下进程句柄,但是翻遍了安装目录也没有找到这个命令,看来 msys2 也不是移植了所有的命令。不过好在 lsof 也是通过 proc 文件子系统实现的,那能不能查看进程的 proc 目录呢?答案是可以的:

$ ls -l /proc total 0 dr-xr-xr-x 3 yunh           1049089 0 11月 24 14:47 16796/ dr-xr-xr-x 3 yunh           1049089 0 11月 24 13:35 17992/ dr-xr-xr-x 3 yunh           1049089 0 11月 24 14:47 18468/ dr-xr-xr-x 3 yunh           1049089 0 11月 25 15:36 20828/ dr-xr-xr-x 3 yunh           1049089 0 11月 24 13:35 7464/ -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 cpuinfo lrwxrwxrwx 1 yunh           1049089 0 11月 25 15:36 cygdrive -> // -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 devices -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 filesystems -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 loadavg -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 meminfo -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 misc lrwxrwxrwx 1 yunh           1049089 0 11月 25 15:36 mounts -> self/mounts dr-xr-xr-x 2 yunh           1049089 0 11月 25 15:36 net/ -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 partitions dr-xr-xr-x 8 yunh           1049089 0 11月 25 15:36 registry/ dr-xr-xr-x 8 yunh           1049089 0 11月 25 15:36 registry32/ dr-xr-xr-x 8 yunh           1049089 0 11月 25 15:36 registry64/ lrwxrwxrwx 1 yunh           1049089 0 11月 25 15:36 self -> 20828/ -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 stat -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 swaps drwxrwx--- 1 Administrators      18 0 11月 25 15:36 sys/ dr-xr-xr-x 2 yunh           1049089 0 11月 25 15:36 sysvipc/ -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 uptime -r--r--r-- 1 yunh           1049089 0 11月 25 15:36 version 

 

这是我在另一个终端中打印的内容。不过找了一下,没有找到上面两个进程 ID 对应的目录。那在脚本里直接打印呢?

ls -lhrt /proc/self/

其中 self 就是指自己啦。将这句代码分别放置在父进程连接建立后的位置与子进程 on_recv 函数开头中,得到下面的输出:

connect with server total 0 lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 0 -> /dev/null lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 1 -> /dev/cons0 lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 2 -> /tools/gsupgo/error.txt lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 3 -> socket:[1] lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 4 -> /proc/8532/fd total 0 lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 0 -> /dev/cons0 lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 1 -> /dev/cons0 lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 2 -> /tools/gsupgo/error.txt lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 3 -> socket:[1] lrwxrwxrwx 1 yunh Domain Users 0 Nov 25 15:31 4 -> /proc/15580/fd 

 

上面一段是父进程的输出,句柄 3 对应的确实是 tcp 连接;下面一段是子进程的输出,看起来与父进程无异。最有意思的是两个进程的 4 号文件句柄,显示出了它们各自的 pid,显然和它们在 windows 上的进程 ID 是不一样的。这也可能是之前我在 /proc 目录下找不到它们的原因吧。但是再次查看 /proc 目录,仍然没有上面两个 pid,可见这个 pid 可能只是局限于本进程组的 (?),并不是全局共享,因而也没有什么利用价值。

探索到这就走到死胡同了,有了解 msys2 在 windows 上实现的大神请不吝赐教。

 

最后这个小工具没有资源可供下载 —— 涉及到公司内部协议安全的问题。不过写了这么多,相信拿来改改写一个自己的也不是什么难事了吧~

参考

[1]. Linux shell脚本中发起tcp、udp连接

[2]. netstat–查看服务器[有效]连接数–统计端口并发数–access.log分析

[3]. jq add or update a value with multiple –arg

赞(0) 打赏
未经允许不得转载:张拓的天空 » 使用 shell 做 tcp 协议模拟
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

专业的IT技术经验分享 更专业 更方便

联系我们本站主机

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏