@yjxjn 你的博客非常喜欢，能介绍下你这个前后端，用的什么吗？

@PUBG98k 这样啊，那看来对于我来说难度还是有点大，我对计算机底层知识比较欠缺，对 C 语言也不擅长

@PUBG98k 你发的这个是别人做好的，问题是，这个软件，他怎么去做到捕获别的进程，改变它的请求目的地，变成请求自己的代理服务器的呢？

@815979670 这个是成本问题，游戏服务商当然可以为玩家做官方代理，做多线优化，但是这样需要的带宽是无法计量的，因为游戏用户太多了，又并不是每个用户网速都慢，你免费给人用，成本太高，收费的话，可能没人愿意玩。
如果你说，自己做一个加速器出来，但是市场有成熟产品了，自己公司去发展这一块，有没有必要？是老板考虑的事情。

另外，还有一些巧妙的防御思路，自己可以花点心思琢磨：
比如：接口调用顺序（一般用户去你网址注册，会先去首页，再点注册），你发现这个客户端，直接就调用注册接口的，就可归类为非法请求。前提也是不要抛出具体错误原因给客户端，让客户端猜不出什么原因造成的非法请求。

其实，短信的攻防没有完美的解决方案，在于攻击你的人愿不愿意付出更多的成本来攻击你，也就是从你那里获得的回报要能大于他的付出，控制好这个点就 ok 了，你做了图片验证，他使用 OCR 和打码平台也是需要成本的，当成本高于收益，他自然不会干这种傻事

可提供如下参考思路：
一：接口设计加一个 sign 字段，sign 不对的都为非法请求（这条只能拦截初级程序员，网页端源码较容易看到，APP 端需要反编译，能稍微提高一定的技术门槛吧）。
二：限制每个 IP 每天发送短信的频率。
三：增加一些技术成熟的验证码功能（如：极验）。
四：表单请求中，附带 token，避免重复提交。
五：APP 的话，可以要求前端传递设备唯一标识号。
六：后端捕获到客户端频繁、严重违反上诉行为的，直接封 IP 、封设备、封账号。
七：对于违反上诉行为的，后端不要返回具体错误原因给客户端，返回一个模糊错误即可，这样能增加客户端猜解接口报错原因的难度。

@guanyu 那这个劫持了数据包之后，是不是还得实现过滤器？识别出自己需要代理的某个软件

@kop1989 那这样看来，做这个东西，涉及的知识面还非常广啊，还必须对 Windows 和 MacOS 有一定了解才行

不想折腾的话，尝试下载一个旧点版本的 GO ？

你先看下 pid 文件里是什么内容，cat /var/run/nginx.pid
很有可能是这种情况，比如，pid 不存在于那个文件，或者 pid 文件里面存的 pid 是这样的：12345%，
他多了一个%号，然后命令就出错了

1：限制请求频率（通过定时器）
2：单次请求利用最大化，每次打包请求的时候，尽可能多的打包几条数据，比如：服务端上限是 1000 字符，那你客户端，看下在 1000 字符以内，尽量装多几条数据，可以提高效率

如果服务端完全不能动的话，那你客户端可以做 2 个事情：

你这个应该可以用 a_colum IN() 吧？

用 php 框架就尽量不要写原生 sql 了，php 框架的数据库操作非常完善和好用，如果某些特殊的需要写原生 sql，直接写就是了，一点都不要担心，我保证，这样的特例，是极少数的，并不会对后期造成太大的困扰

@Bramblex2 既然自己有主导权，也在重构，那么你可以做到统一风格了，我认为，你无论采用哪一种风格的接口，和前端解释一次，说之后都是采用此种风格，我相信一个能正常沟通的前端，都不会去纠结这个东西。

如果你仅仅是想知道，那种风格看起来比较标准，我平时是比较喜欢：B:null，前端有提出要求的话，我也是很乐意改的

个人看法，其实我觉得大家说的两种都没有问题，关键有两点：1 、该项目主要由谁来制定标准，该标准是否在各个客户端兼容性良好。2 、风格要统一。
什么是风格要统一呢？就是比如：你这个项目，数据结构用的是第一种，那就从头到尾都用第一种风格；用第二种亦是如此。
满足了这两点，我觉得前后端沟通成本就能有效降低，达成共识后，双方也就不再会纠结，这个接口怎么返回这种，那个接口怎么返回那种。

那么说下，既然风格统一有这么多好处，还会出现多风格的接口呢？出现这个往往都是有历史原因，经手人比较多，后来的人，不够了解前人的风格和做法，最后就造成了这种局面。
如果你看不惯目前的局面，要坚持自己的标准，那么请统一它、重构它。请问你做好这样的决心了吗？没有的话，请不要吐槽它，因为你自己也并不想花时间去改造它

@hyd8323268 如果你需求一定要时间排序的话，我觉得你可以试试，给时间戳建立索引，然后使用微秒级时间戳，看下这样能不能避免时间戳太多重复的情况？这个就要看你业务了