V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  brader  ›  全部回复第 131 页 / 共 133 页
回复总数  2643
1 ... 123  124  125  126  127  128  129  130  131  132 ... 133  
2020-05-26 17:20:47 +08:00
回复了 brader 创建的主题 程序员 请教迅游加速器实现原理?
@PUBG98k 你发的这个是别人做好的,问题是,这个软件,他怎么去做到捕获别的进程,改变它的请求目的地,变成请求自己的代理服务器的呢?
2020-05-26 17:18:56 +08:00
回复了 brader 创建的主题 程序员 请教迅游加速器实现原理?
@815979670 这个是成本问题,游戏服务商当然可以为玩家做官方代理,做多线优化,但是这样需要的带宽是无法计量的,因为游戏用户太多了,又并不是每个用户网速都慢,你免费给人用,成本太高,收费的话,可能没人愿意玩。
如果你说,自己做一个加速器出来,但是市场有成熟产品了,自己公司去发展这一块,有没有必要?是老板考虑的事情。
2020-05-25 16:18:16 +08:00
回复了 ksc010 创建的主题 程序员 网站注册页面的短信验证接口被利用了,有一个思路
另外,还有一些巧妙的防御思路,自己可以花点心思琢磨:
比如:接口调用顺序(一般用户去你网址注册,会先去首页,再点注册),你发现这个客户端,直接就调用注册接口的,就可归类为非法请求。前提也是不要抛出具体错误原因给客户端,让客户端猜不出什么原因造成的非法请求。

其实,短信的攻防没有完美的解决方案,在于攻击你的人愿不愿意付出更多的成本来攻击你,也就是从你那里获得的回报要能大于他的付出,控制好这个点就 ok 了,你做了图片验证,他使用 OCR 和打码平台也是需要成本的,当成本高于收益,他自然不会干这种傻事
2020-05-25 16:08:08 +08:00
回复了 ksc010 创建的主题 程序员 网站注册页面的短信验证接口被利用了,有一个思路
可提供如下参考思路:
一:接口设计加一个 sign 字段,sign 不对的都为非法请求(这条只能拦截初级程序员,网页端源码较容易看到,APP 端需要反编译,能稍微提高一定的技术门槛吧)。
二:限制每个 IP 每天发送短信的频率。
三:增加一些技术成熟的验证码功能(如:极验)。
四:表单请求中,附带 token,避免重复提交。
五:APP 的话,可以要求前端传递设备唯一标识号。
六:后端捕获到客户端频繁、严重违反上诉行为的,直接封 IP 、封设备、封账号。
七:对于违反上诉行为的,后端不要返回具体错误原因给客户端,返回一个模糊错误即可,这样能增加客户端猜解接口报错原因的难度。
2020-05-25 15:25:29 +08:00
回复了 brader 创建的主题 程序员 请教迅游加速器实现原理?
@guanyu 那这个劫持了数据包之后,是不是还得实现过滤器?识别出自己需要代理的某个软件
2020-05-25 15:21:30 +08:00
回复了 brader 创建的主题 程序员 请教迅游加速器实现原理?
@kop1989 那这样看来,做这个东西,涉及的知识面还非常广啊,还必须对 Windows 和 MacOS 有一定了解才行
不想折腾的话,尝试下载一个旧点版本的 GO ?
2020-04-26 10:16:48 +08:00
回复了 endlesslove 创建的主题 NGINX nginx 无法停止
你先看下 pid 文件里是什么内容,cat /var/run/nginx.pid
很有可能是这种情况,比如,pid 不存在于那个文件,或者 pid 文件里面存的 pid 是这样的:12345%,
他多了一个%号,然后命令就出错了
2020-04-23 10:34:57 +08:00
回复了 MrMike 创建的主题 PHP 如何优化远程获取请求数据过大造成服务器报错的问题?
1:限制请求频率(通过定时器)
2:单次请求利用最大化,每次打包请求的时候,尽可能多的打包几条数据,比如:服务端上限是 1000 字符,那你客户端,看下在 1000 字符以内,尽量装多几条数据,可以提高效率
2020-04-23 10:33:25 +08:00
回复了 MrMike 创建的主题 PHP 如何优化远程获取请求数据过大造成服务器报错的问题?
如果服务端完全不能动的话,那你客户端可以做 2 个事情:
2020-04-23 10:30:30 +08:00
回复了 madpecker009 创建的主题 程序员 关于在循环中对数据库操作的问题
你这个应该可以用 a_colum IN() 吧?
2020-04-14 09:50:58 +08:00
回复了 taaaang 创建的主题 PHP PHP 的 sql 到底该写在哪儿?
用 php 框架就尽量不要写原生 sql 了,php 框架的数据库操作非常完善和好用,如果某些特殊的需要写原生 sql,直接写就是了,一点都不要担心,我保证,这样的特例,是极少数的,并不会对后期造成太大的困扰
2020-04-13 17:20:59 +08:00
回复了 Bramblex2 创建的主题 程序员 后端接口这样设计是否合理
@Bramblex2 既然自己有主导权,也在重构,那么你可以做到统一风格了,我认为,你无论采用哪一种风格的接口,和前端解释一次,说之后都是采用此种风格,我相信一个能正常沟通的前端,都不会去纠结这个东西。

如果你仅仅是想知道,那种风格看起来比较标准,我平时是比较喜欢:B:null,前端有提出要求的话,我也是很乐意改的
2020-04-13 17:13:02 +08:00
回复了 Bramblex2 创建的主题 程序员 后端接口这样设计是否合理
个人看法,其实我觉得大家说的两种都没有问题,关键有两点:1 、该项目主要由谁来制定标准,该标准是否在各个客户端兼容性良好。2 、风格要统一。
什么是风格要统一呢?就是比如:你这个项目,数据结构用的是第一种,那就从头到尾都用第一种风格;用第二种亦是如此。
满足了这两点,我觉得前后端沟通成本就能有效降低,达成共识后,双方也就不再会纠结,这个接口怎么返回这种,那个接口怎么返回那种。

那么说下,既然风格统一有这么多好处,还会出现多风格的接口呢?出现这个往往都是有历史原因,经手人比较多,后来的人,不够了解前人的风格和做法,最后就造成了这种局面。
如果你看不惯目前的局面,要坚持自己的标准,那么请统一它、重构它。请问你做好这样的决心了吗?没有的话,请不要吐槽它,因为你自己也并不想花时间去改造它
2020-04-13 15:50:23 +08:00
回复了 hyd8323268 创建的主题 MySQL mysql 近千万级数据表,在分页时有什么好的方案吗。
@hyd8323268 如果你需求一定要时间排序的话,我觉得你可以试试,给时间戳建立索引,然后使用微秒级时间戳,看下这样能不能避免时间戳太多重复的情况?这个就要看你业务了
2020-04-13 10:44:31 +08:00
回复了 hyd8323268 创建的主题 MySQL mysql 近千万级数据表,在分页时有什么好的方案吗。
请问你是执行 select 字段 from 表名 order by 时间戳 desc,id asc limit 0,10; 的时候慢,还是获取表的总行数的时候慢?可以提供你的具体分页需求吗?是只做下一页,还是需要做页码的?
就我所知,千万级,select 字段 from 表名 order by 时间戳 desc,id asc limit 0,10; 的效率还是能接受的
2020-04-08 18:25:55 +08:00
回复了 Evilk 创建的主题 PHP 你们生产环境 PHP 版本?
php7.2,mariadb10.12 ,不想升级 7.2 以上了,感觉没有必要去趟坑
1 ... 123  124  125  126  127  128  129  130  131  132 ... 133  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1633 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 43ms · UTC 16:51 · PVG 00:51 · LAX 09:51 · JFK 12:51
Developed with CodeLauncher
♥ Do have faith in what you're doing.