使用shell做tcp协议模拟
shell 只能做 http 协议测试？今天搞个 shell 版 tcp 协议测试工具玩玩。难倒我的不是怎么接收异步消息，而是怎么让 read 适时返回……
问题背景
公司有一套消息推送系统（简称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_port2 ret=$?3echo"open tcp $ret"
4if [ $ret != 0 ]; then
5echo"connect to gcmserver failed"
6 exit 1
7fi
8
9echo"connect with server"
这里脚本直接使用标准输入(0)、输出(1)、错误(2)之后的句柄 3 作为连接句柄，跑了一下，似乎什么也没有发生：
好在 Windows 上有 procexp 工具，可以查看进程创建的所有 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 中就可以这样验证了：
最后仍然是通过 procexp 工具或 netstat 命令来查看执行结果。另外使用 echo $? 获取 exec 执行结果为 0 似乎并不能确认连接已经建立，因为我对一个错误的 host + port 使用 exec 仍然能得到 0。
机器上下线
连接建立好以后，需要向后台上报本机的一些基本信息，这个协议称为机器上线：
1function 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 } }") 6echo $msg >&37 local ret=$?
8if [ $ret -ne 0 ]; then
9echo"connection break, send failed"
10 exit 3
11fi
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）又是在脚本启动前就从注册表中读取并传入的。机器上线后才可以进行产品的上下线，而且相应的，当客户端停止时，也要告诉后台机器下线：
1function 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 }") 6echo $msg >&37 local ret=$?
8echo"send 101 msg to gcm $ret" >> log.txt
9if [ $ret -ne 0 ]; then
10echo"connection break, send failed"
11 exit 3
12fi
13
14 # no response for101 message
15echo"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 -lhrttotal 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 id4 # $4: device id
5function 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 } }")
11echo $msg >&3
12 local ret=$?
13echo"send 102 msg to gcm $ret" >> log.txt
14if [ $ret -ne 0 ]; then
15echo"connection break, send failed"
16 exit 3
17fi
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 id3 # $3: device id
4function 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 }")
10echo $msg >&3
11 local ret=$?
12echo"send 103 msg to gcm $ret" >> log.txt
13if [ $ret -ne 0 ]; then
14echo"connection break, send failed"
15 exit 3
16fi
17
18 # no response for103 message
19echo"$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）。除了固定的产品，用户也可以在命令行指定某个产品去上线，这个工具跑起来后长这个样子：
红框中的部分其实是一个循环，用户可以不停的输入要上下线的产品进行操作，这部分的代码相应的也位于一段 while 循环中：
1 # online/offline products 2while : 3do4echo"-------------------------------------------"
5echo -n "product name to operate (exit|quit to quit): "
6 read product
7if [ "$product" == "exit" -o "$product" == "quit" ]; then
8 break;
9fi
10
11echo -n "operation (online|offline): "
12 read resp
13 online=0
14case"$resp"in
15""|"o"|"O"|"on"|"ON"|"online"|"ONLINE")
16 online=1
17 ;;
18 *)
19 ;;
20esac
21
22if [ $online == 1 ]; then
23echo -n "version: "
24 read version
25fi
26
27echo -n "user id: "
28 read userid
29
30if [ $online == 1 ]; then
31 send_request_102 "$product""$version""$userid""$devid"
32else
33 send_request_103 "$product""$userid""$devid"
34fi
35
36sleep1
37done
下面做个简单讲解：
- line 4-9：如果用户输入 quit 或 exit，退出循环从而退出整个脚本。否则收集到要操作的产品标识；
- line 11-20：提示用户输入进行何种操作，上线 or 下线；
- line 22-25：如果是上线操作，则需要用户输入产品版本；
- line 27-28：提示用户输入用户 ID；
- line 30-34：根据用户输入的操作类型，调用前面封装好的函数来完成产品上下线。
接收推送消息
产品上线成功后，就可以接收来自后台的“问候”了。这块和前面那种一问一答模式不一样，需要异步处理连接上到达的数据。我的第一反应就是开个线程来处理，但是 shell 里并没有线程这种东西，只有子进程可以用。问题是开子进程后原句柄 (3) 还能代表以前的连接吗？在 linux 上这一点不容置疑，但是 windows 上可没有 fork 这东东啊，怎么保证新启动的子进程复制父进程的用户空间呢？带着疑问，我尝试了下面的代码：
1echo"connect with server"2 on_recv &
3 cpid=$!
将接收消息相关代码封装在 on_recv 函数中，就可以直接用 ‘&’ 启动一个单独的进程去跑这个函数啦！作为测试，一开始我只在 on_recv 中处理了几个简单的应答消息（100->201,102->301……）：
1function on_recv 2{ 3 # can not break read !4 #trap "echo recv exit signal from parent" INT
5while :
6do
7 #read msg <&3
8 #msg=$(tail -f <&3)
9 #read -t 1 msg <&3
10 local msg=""
11 read -d "}" msg <&3
12if [ -z "$msg" ]; then
13echo -e "
connection break, receive failed"
14 exit 3
15fi
16
17 msg="$msg}"
18 local type=$(echo"$msg" | jq -r ".msgtype")
19case"$type"in
20"201")
21 local guid=$(echo"$msg" | jq -r ".guid")
22echo"online success! devid=$guid"
23 ;;
24"301")
25 local appname=$(echo"$msg" | jq -r ".appclientid")
26 local userid=$(echo"$msg" | jq -r ".dstuserid")
27echo"$appname online success! userid=$userid"
28 ;;
29 *)
30echo"unknown response type: $type"
31 #exit
32 ;;
33esac
34done
35 }
收到这几个应答消息时，会将其中关键的字段打印在屏幕上。应答消息同请求消息一样，也是纯 json 格式，因此这里使用 jq 来做解析 (line 17-33)。
不过难点倒不在这儿，真正让我费了半天劲儿的地方是在读取，可能有人说了，读取有什么难的，直接 read 不就行了吗？我一开始就是这样做的 (line 7)，然而 read 会一直卡在那里读数据，即使已经有消息读到了也不返回。简单分析一下：看起来 read 在等一个结束标志，一般而言就是换行 "
"，这也是为什么你可以一直在 console 界面输入内容、直到回车结束的原因。然而后台应答消息并没有换行符作为消息结束，于是我尝试了另外一个方案，使用 tail -f 读取连接中的内容 (line 8)，然而没有任何改进。
因此这里我又试了第三个方案 (line 9)，为 read 增加了一个超时时间 (1s)，这样当时间足够长了以后也能返回之前读到的消息，缺点是 read 会每隔一秒中断一次；然而我忽略了一个更严重的问题的，那就是当产品积压了很多消息没有推送后，当它上线的一刻后台会同时给它推送多个消息，这样一来，这个带超时的 read 常常会将多个消息粘在一起返回，导致后面的解析出错。
于是我试了现在这个方案 (line 11)，告诉 read 一直读、直到遇到 json 结尾符 "}"。当然这也不是完全保险的，因为 json 中有可能存在嵌套的子结构、导致内部含有 ‘}’，但好在现有的协议中应答消息都比较简单，基本上一对花括号之内不会再有花括号了，所以可以这样搞。这个脚本跑起来的效果，其实前面那张图已经展示过了，这次重新划一下重点：
可以看到，新的子进程可以很好的收到机器和产品上线的应答消息（下线没有应答消息），看起来就像它与父进程共享了这个连接一样。验证了 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") 8echo""9echo"*******************************************"
10echo"receive customer message "
11echo"product: $appclientid"
12echo"userid : $appuserid"
13echo"msgid : $msgid"
14 local body_utf8=$(echo"$msgbody" | base64 -d)
15 local body=$(echo"$body_utf8" | iconv -f utf-8 -t gb2312)
16echo"content: $body"
17echo"*******************************************"
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") 8echo""9echo"*******************************************"
10echo"receive popup message "
11echo"product: $appclientid"
12echo"userid : $appuserid"
13echo"msgid : $msgid"
14echo""
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
23echo"title : $title"
24echo"content: $content"
25echo"ctxurl : $ctxurl"
26echo"image : $image"
27echo"imgurl : $imgurl"
28echo"*******************************************"
29
30 # prepare 108 message
31 send_request_108 "$guid""$appclientid""$appuserid""$msgid"
32sleep1
33 # prepare 402 message
34 send_request_402 "$msg""$hardid"
35 ;;
401 就是弹窗消息，本来是要给用户在屏幕右下角弹个小窗显示的，这里为了简化问题，也直接打印在屏幕上。收到 401 消息后要先给后台回复一个 108 表示成功接收，再回复一个 402 来表示弹窗最终结果，例如用户点击、关闭、查看详情…等等，这里直接返回用户关闭作为模拟。下面是产品上线后，收到推送消息的效果：
这里演示了两个消息，分别是弹窗消息与自定义消息，可以看到都能正常的解析与显示。后台也可以正常的统计到这两个消息的推送情况：
最后，当用户退出操作循环后，需要及时回收子进程：
1 exec 3>&-2kill -INT $cpid
3wait
这里通过 kill 产生 INT 消息来通知子进程退出接收循环，接着通过 wait 等待子进程完全退出。之前也尝试在子进程中捕获 (trap) INT 信号并优雅的退出，但是发现在 windows 环境下加了这个捕获反而导致 read 不能被中断了，so 放弃之。现在这种方式可能是直接把子进程给杀死了，虽然“暴力”一点，但是起码可以正常工作。
后记
通过构建这个小工具，我甚至发现了协议文档中书写错误或不详的地方。不过最让我感到好奇的还是 —— windows 上是怎么实现两个进程共享一个连接句柄的? 为了解答这个问题，祭出 procexp 大杀器：
可以看到连接只在父进程(20612)中展示，子进程(16844)中并没有对应的连接，那它是怎么在连接上读数据的呢？左看右看没有看出什么头绪。想用 msys2 的 lsof 命令查看下进程句柄，但是翻遍了安装目录也没有找到这个命令，看来 msys2 也不是移植了所有的命令。不过好在 lsof 也是通过 proc 文件子系统实现的，那能不能查看进程的 proc 目录呢？答案是可以的：
$ ls -l /proctotal 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 servertotal 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
以上是 使用shell做tcp协议模拟 的全部内容， 来源链接： utcz.com/z/519529.html
