用脚本帮朋友抢个专家号居然没抢到

[tracymcladdy]

拿到微信 h5 页面的 token ，chrome 控制台拿到请求参数，postman 模拟了几个不用抢的专家号通过了。。

然后写了个循环 100ms 请求一次 7 点放号的专家号，之前一直返回 7 点开抢。然后 7 点直接请求卡了 2 秒返回没号了。。

感觉要不是别人也是脚本，要不就是后台有手脚。。

[X3en]

@jeeyong 天眼查？

[meshell]

@zhulixin @lslhz 遇到有验证码这些是不是要识别验证码了，不可以人工写码吧。我上次为了抢浙中的专家号，直接 dump 支付宝里面小程序，改改本地 node 直接发. 上海华山的有验证码就不好搞了。

[moult]

@chapiom #19
时间差获取其实不是很麻烦的。依靠 Response Header 的 Date 字段来确定，但因为 Date 是秒级的，所以需要一些技巧。
先找一个同服务器上几乎不耗时的路径。比如 /robots.txt /favicon.ico 这类很小的且响应很快的静态资源。
每隔 20ms 左右发送一次请求，记录发出时间、网络耗时、Date 头。

举例来说：
本地发出时间 12:00:05.800 ，服务器响应 Date 是 12:00:05 秒
本地发出时间 12:00:05.820 ，服务器响应 Date 是 12:00:06 秒
不考虑网络耗时的情况下，意味着服务器时间是 800-820 之间，从 5 跳到了 6 ，所以服务器快了 190 毫秒左右。
实际上上面这个时间含网络耗时的，要精确点的话，再结合网络耗时计算一下，大概就能算出服务器的时差了。

[v2Donuts]

@lslhz 为什么现在不用了

[kuanat]

手动 tcp 发包的方法也太扯淡了……没实践过就别瞎说。

这种行为本质上和 Slowloris 攻击没区别，当服务器都是傻子呢。

[kenvix]

所有不加行为验证码的抢购就是图一乐,成事在天🤣

[c2const]

除了上面提到的“确定服务器与标准北京时间时差”、“降低发送的延时”、“直接分析协议”，
-----------------------
你还应该增加账号数量，比如微信，那就弄几十个微信账号，几十个公网 IP ，一起开程序/脚本来抢，增加成功概率 :)

干黄牛的活就得专业一点 :)

[kuanat]

鉴于楼上说的手动 tcp 方案太扯淡了，本来想简单吐槽一句，结果没忍住还是把这个事情说清楚吧。

我这么说是有理论和实践经验做支撑的，tcp 手动发包几乎没有统计学上的有效性。这类需求前些年几乎是外包市场仅次于网站开发的业务，钱多门槛低。我自己做得很少，基本上是给别人指导一下，不做的原因主要是业务容易擦边，再就是现在多数大平台的都从抢的逻辑变成抽签逻辑了。

先解释一下为什么有人认为“手动发包”是个有意义的方案。

因为按照一般的“抢”的逻辑，以某个时刻为分界线，在此时刻之后某个特定资源就生效了。在此时刻之前到达服务器的请求是无效的，你希望你的请求恰好在这个时刻之后到达服务器。

那么我们有能力确定服务器的时间吗？绝大多数时间不能。（少数情况下可以通过触发服务器错误等等获得一个相对时间差，然后加上网络延迟做一个粗略估计。）即使能够确定服务器时间，实际应用里也没有太大意义。“上线”这个事情 99% 不是自动化的而是人为的。

因此所有人的策略都做出调整了，用大量链接去覆盖资源上线的可能时段。只要保证资源上线之后有一部分请求以尽量低的延迟到达服务器即可。

这个时候 tcp 手动发包好像就体现出优势了？提前建立好（大量）连接，然后看情况开始发数据。注意这里的潜台词是，网站卡的原因在于 tcp 连接数不够，而且新建立连接会多 1RTT 的延时。

但是这个思路是不是有点眼熟？如果很多人都是这样做，或者某个人控制机器人程序这样做，在服务器看来，客户端只连接不发数据，这连接还不会主动关闭，那它是不是就是 DoS 攻击？（这一类攻击有个专门的名字叫 Slowloris ）

这里设定个非常简单也非常普遍的模型，来看看这个做法有没有可行性。或者说“连接数不够”这个假设是不是真的符合现实。

就非常普通的单服务器 nginx 做 ssl offloading 和反代，配置近似默认，upstream 大概是某种动态语言的服务端。网络请求在闲时 10 QPS 忙时 10000 QPS 这样。（意思就是，规模不大，用户量有限。服务器网络带宽不是瓶颈，nginx 也大概率不是瓶颈，瓶颈在后端应用，挂号服务基本上就是这个水平。）

这里套不套应用层防火墙差别非常大。一旦套一层 cf 之类的服务，手动 tcp 发包就没意义了。因为 cf 之类的服务会缓存请求然后回源，不可能在这个层面预先抢占 tcp 连接。

如果退一步讲，服务器裸跑。这个时候你通过手动 tcp 发包，那能够获得的时间窗口有多长？

在 tcp 层面，理论上 keepalive 是无限长的。但是实际上以国内的网络环境来说，经过 NAT 之后中间设备的映射缓存大概就是 150 秒这个水平。实践里可以找公网服务器、代理来绕开这个限制。提这个限制的意思是，利用 keepalive 机制几乎不需要你在程序层面上做很大的改动。

但是在 nginx 服务器层面上，时间窗口就小得多。这类服务器默认对慢速攻击有应对，tcp 连接建立后，headers/body 的默认容忍延迟基本在 60 秒。（但凡看过一点点所谓的优化经验，这个值应该不会超过 10 秒）

那就又回到之前的问题上了，你本来打算预先抢占 tcp 连接，结果时间窗口太小，当所有人的策略都是提前覆盖可能的时段，你的连接会被淹没在海量连接里面。

这里有个非常极端的情况，这个 tcp 手动发包，利用 tcp 的机制，强行把 headers 分成多个包发送，然后每个发送间隔卡在目标服务器的限制之内。（这里就不提这个程序的复杂性了，要么魔改底层网络库，要么纯手写然后一直处理到应用层协议）

但问题是 nginx 这类服务器的反代，一样会先缓存请求，在收到完整请求之后，再转发给 upstream 服务器。也就是说，你抢占了本地到 nginx 的连接，而没有能力抢占 nginx 的 upstream 的连接。

现在回到核心的问题上，服务器在高并发的时候变卡的核心原因是什么？

核心是服务端应用要对特定资源加锁，业务逻辑在高并发的情况下只能等。

由于一般网站的瓶颈都在后端应用服务器上，nginx 能承载的客户端连接数远大于 nginx 到 upstream 的连接数。

当应用服务器不需要处理锁事务的时候，平均响应可以做到很低。但是一旦遇到加锁资源的时候，这个响应时间会成倍增加，理论 QPS 就大幅下降。而此时所有人会更加疯狂地反复刷新，这时候 nginx 到 upstream 的连接就会长期占满。

所以体感上就是，网站先变卡，因为 nginx 在等 upstream 释放出新的连接。等 nginx 撑不住了才会 502 错误。而从客户端来说，没有任何手段能保证你优先获得到 upstream 的连接。

所以说 tcp 手动发包这个事情……别挣扎了。

[keymao]

你这抢票还等返回的。。 太文明了，这玩意儿只有他那边存库就行了，你只管发请求，使劲的超发。

[alouha]

给你个思路，就是去那些约号 app 上找那些专家，他们都可以花钱私聊，然后把症状都给医生说了，巴拉巴拉一大堆，最后说您的号太难约了，我已经约了 xx 天了，您看方便加个号不，最后就是第二天去加个号

[alouha]

@alouha 还有个楼上说了，一些银行的信用卡（白金及以上）权益都有帮忙约号陪诊权益，可以试试

[tracymcladdy]

@kuanat 是的 瓶颈肯定不是 tcp 连接，不魔改底层发包协议，手动发 tcp 包肯定会被淹没在海量的请求中，而且很有可能当 Dos 被干掉。
抢购的逻辑在后台不搞鬼的情形下，确实更像是一堆脚本抽奖了。

[Z1R0]

直接进后台自己加不好吗

[kuanat]

@tracymcladdy #72

如果服务方不愿意改变抢模式，这个事情就会演变成脚本大战。

脚本大战一旦有人不讲武德，大量暴力发请求，结果就会变成另一个意义上的抽签。最终所有人的最优策略就是加资源提高中签率，尽管大家都知道这么做边际收益很低，但不得不这么做。

另一方面你可以看到提供这种服务的主要模式都变成了“代抢”，甚至承诺抢不到加倍退款。对于商家来说，投入达到某个阈值之后中签率是比较稳定的，成本也是稳定的，只要代抢客户足够多就能赚。因为他们可以保证总有账号可以抢到，但没法保证某个特定账号能抢到。

[caicaiwoshishui]

@zhulixin 这操作虽然骚，但是我不相信，除非 show you code /doge

[xyzv3]

之前一直有同事说要搞抢茅台，却没成功

[qingRider]

作为爬过的过来人来讲，你尽量提前 20 分钟。一般他们都是提前 10 分钟，很不准时的。而且有 goujie

[needpp]

@qingRider 让我想起来提前一天上高速的大聪明

[chackchackGO]

这栋楼的佬们, 我想问问电商哪些整点下单的送大礼的业务是不是同一批人也有在干.

[v2vip]

@hytirrb 我是用 java 写的，有很多方式和语言都行