git: ,-------------47-53,0-23--10-11-35-16-5-13-18-51-45-43-27-21,29-23-24,0
chrome访问目标网站用wireshark抓包得到：
第一个： ,--------------47-53,-0-23--10-11-35-16-5-13-18-51-45-43-27---41,-29-23-24,0
第二个： ,--------------47-53,-0-23--10-11-35-16-5-13-18-51-45-43-27---21,-29-23-24,0
仔细对比之后，也就刚好多了标记的去掉上面标记出来的，其实第一个和第二个是一样的，仅仅是这个被我马赛克马死的平台是这样，我猜应该是这个平台自己多加了一层握手流程，所以会有2个clienthello，具体为啥有两个不纠结了，我也不是该平台的开发，也没法得知具体原因，不重要了，能获取数据就行了。不过等等，突然有个疑问？为啥wireshark的ja3指纹，同一个golang脚本啊，就算两个clienthello，也应该是两个一样的ja3指纹啊，为了进一步分析，先用浏览器访问ja3后，同时看看wireshark抓包的是啥，这？我该信哪个？怎么wireshark多了点其他的东西这引出了一个新的问题，哪个才是对的ja3到底存在吗？按理来说，应该信ja3官方，因为这玩意儿就是别人搞出来的，那既然如此，是wireshark在搞事咯？（此时此刻突然想起了学生时代的一个数学逻辑题，假如你是侦探，现在有几个嫌疑人，已知里面有个人说了谎，从几个嫌疑人的供词里找出真凶。。。扯远了）为了进一步确认这个问题，根据青南大佬给文章的方案，可以伪造ja3指纹，那此时此刻，试下吧，现在的逻辑就是，我用一个我已知的指纹去请求ja3，然后看看ja3官方的返回，再看wireshark的ja3指纹对比，如果wireshark里的ja3不全等于我们自定义的ja3，那就确认是wireshark在他喵的搞事了首先澄清，没作弊哈，我用的第一个，跟我浏览器里的ja3是不一样的这里我用的ja3transport库了，因为ja3