+
 新版
2014-01-08 08:37

引用来自“BruceWan”的评论

引用来自“晏雨涵”的评论

动态的里面每一帧都是静态的图片吧。感觉动态只对人有影响

gif动画提前生成几十万个,用时引用。既不会影响网站性能,又使得打码公司的雇员头痛

用户体验不好

引用来自“codepat”的评论

GIF动画取其中一帧就是静态的了,出这个主意的人没大脑

gif动画提前生成几十万个,用时引用。既不会影响网站性能,又使得打码公司的雇员头痛,不过呢打码公司可以取一帧给打码员。

引用来自“kut”的评论

引用来自“雅各布奇”的评论

开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人

说实在的,应付这么大并发的网站,真的是很难的。

gif动画提前生成几十万个,用时引用。既不会影响网站性能,又使得打码公司的雇员头痛

引用来自“codepat”的评论

GIF动画取其中一帧就是静态的了,出这个主意的人没大脑

gif动画提前生成几十万个,用时引用。既不会影响网站性能,又使得打码公司的雇员头痛

引用来自“YuKunYi”的评论

动态的验证码完全扯淡啊。。。那玩意是专门防正常用户给机器人用的。。。

gif动画提前生成几十万个,用时引用。既不会影响网站性能,又使得打码公司的雇员头痛

引用来自“晏雨涵”的评论

动态的里面每一帧都是静态的图片吧。感觉动态只对人有影响

gif动画提前生成几十万个,用时引用。既不会影响网站性能,又使得打码公司的雇员头痛

引用来自“铂金小猫”的评论

搞笑。

打码公司的雇员,头痛了。

引用来自“codepat”的评论

GIF动画取其中一帧就是静态的了,出这个主意的人没大脑

楼主正解,不过干扰钱和噪点还是挺管用的
2014-01-07 18:08
可以学习一下,根据,颜色,语义,形状,计算等得出验证码
2014-01-07 11:40

引用来自“杨金焕”的评论

引用来自“莫慌张”的评论

引用来自“杨金焕”的评论

每个字符每次都扭曲、大小变化、排列间距变化、相粘连,在目前,相信再牛逼的的技术,机器识别是相当困难。我暂时没有见过可以的。

我以前搞过几年验证码识别,说实话。他这种验证码不算复杂。机器很难识别的像雅虎谷歌的部分验证码,他这种识别难道不高。。而且要识别验证码的话还有一种是手打平台识别。。所以只要人能识别的验证码都是识别出来,不同的是成功率和成本差距。

我只讲机器不能识别:扭曲、大小变化、排列间距变化、相粘连的验证码,没有讲过人工打码:人工打码是人识别了,是需要付费的了。

以12306当前验证码难易度,机器识别没问题
2014-01-07 10:38
多数春节返家的客流路线基本固定,干脆来个全国性的实名制预登记,来个车票配给制。
2014-01-07 10:13

引用来自“白文”的评论

引用来自“eechen”的评论

引用来自“白文”的评论

引用来自“eechen”的评论

引用来自“白文”的评论

引用来自“宅男小何”的评论

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

不太懂orcale,但是我说的验证码都获取不到啊,验证码应该是单独的服务器吧,跟你说的逻辑也没啥关系啊。你说的是购票!

同时请求访问数据库的进程过多时,会按照一定的调度策略排队,增加服务器没有任何作用,反而无法维持数据一致性。余票动态变化的性质决定了服务器的数量

购票请求全部进队,队列很容易横向扩展,而且也可以控制请求对数据库的压力,避免遭遇节假日瞬间的高负载。余票查询不需要考虑队列里的请求,用户提交购票请求后马上响应用户“购票请求已提交”,但能不能买到票还要看队列的处理进度和结果,处理完成则通知(比如短信通知)用户购票成功。

数据库方面如果能像MySQL那样配置多主多从、读写分离,那很容易就可以在读(查询)方面横向扩展。另外限定登录后才能查票也能减少读压力。

最后如果连刷票器都对付不了的话只能是自身技术问题,这没什么好说的。

你没有从硬件方面考虑,多个进程访问同一存储区域必须排队,否则会发生数据相关错误,一般这种排队由操作系统管理即可,但12306这种势必需要专门进程干预,提高处理器流水线效率,否则延迟相当惊人。

我说的队列当然是指守护进程、服务类型的的队列,比如著名的使用Erlang编写的支持AMQP(高级消息队列协议)的队列服务RabbitMQ Server。

正是因为考虑到数据库的吞吐量上限,才需要引入队列,这种应用层面的队列完全由程序控制,消费者(数据库)的消费速率是可控的。超大规模并发下用户直接向数据库请求显然是不现实的。

大部分网站都不会允许直接访问数据库,你说的消息队列好像是应用程序级的,应用程序与DBMS之间的通信瓶颈不会太大,系统瓶颈多在与内存的交互上。如若大量用户针对同一车次发出订票和查询请求,就实际而言,只能写请求优先,过时数据没有意义,但也不能无限推迟查询请求,在DBMS存取数据时,要么自己处理多任务请求,要么操作系统处理。12306需要修改DBMS的多任务处理确定合理的优先级,或者修改内核进程优先级。考虑到效率,修改内核更可取,特别是高并发。目前12306的数据错误应该与内核有关。至于访存策略,应该是写直达法,来维持多处机Cache的一致性。这两项是很大的瓶颈,外在表现查询请求缓慢。目前尚不清楚12306采用何种DBMS与操作系统

请问一下,如果12306开放平台,允许淘宝一些电商接入,你觉得技术实现难度大吗?
2014-01-07 08:09
跟马云合作。
2014-01-06 20:24

引用来自“莫慌张”的评论

引用来自“杨金焕”的评论

每个字符每次都扭曲、大小变化、排列间距变化、相粘连,在目前,相信再牛逼的的技术,机器识别是相当困难。我暂时没有见过可以的。

我以前搞过几年验证码识别,说实话。他这种验证码不算复杂。机器很难识别的像雅虎谷歌的部分验证码,他这种识别难道不高。。而且要识别验证码的话还有一种是手打平台识别。。所以只要人能识别的验证码都是识别出来,不同的是成功率和成本差距。

我只讲机器不能识别:扭曲、大小变化、排列间距变化、相粘连的验证码,没有讲过人工打码:人工打码是人识别了,是需要付费的了。
2014-01-06 19:20
弱弱地问一下,静态和动态的有什么区别呢?做Web的同学能给解释下吗?
2014-01-06 18:14

引用来自“杨金焕”的评论

每个字符每次都扭曲、大小变化、排列间距变化、相粘连,在目前,相信再牛逼的的技术,机器识别是相当困难。我暂时没有见过可以的。

其实哪怕很简单的识别,这里设置成为每个用户每天只能登陆100次。

输入100次错误了无论对错今天就不能进去了

这样每个省份证号码才100次机会每天试一下,100次很难OCR识别准确的
2014-01-06 17:47
麻烦你把网站做好,验证码什么的不是越快输入越好吗,草
2014-01-06 17:18

引用来自“kut”的评论

引用来自“雅各布奇”的评论

开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人

说实在的,应付这么大并发的网站,真的是很难的。

开发投入的钱足够做几个这级别并发的站了。
2014-01-06 17:16

引用来自“杨金焕”的评论

每个字符每次都扭曲、大小变化、排列间距变化、相粘连,在目前,相信再牛逼的的技术,机器识别是相当困难。我暂时没有见过可以的。

我以前搞过几年验证码识别,说实话。他这种验证码不算复杂。机器很难识别的像雅虎谷歌的部分验证码,他这种识别难道不高。。而且要识别验证码的话还有一种是手打平台识别。。所以只要人能识别的验证码都是识别出来,不同的是成功率和成本差距。
2014-01-06 16:55
什么是缓存服务器,什么是linux服务器,什么是 tengine 。值得学习。每天都要学习,别等到放假了再学习。
2014-01-06 16:33

引用来自“袁国涛”的评论

引用来自“kut”的评论

引用来自“lxbzmy”的评论

我只想说SB动画,从没见过这么SB的,验证码用动画。

语音呢?

现在的语音识别也可以了,它总不能用方言播数字吧?

语言是有背景音的,我感觉还不如看字清楚呢,根本听不清
2014-01-06 16:19
人眼可以识别连续帧的图像 , 可以将验证码分成单独字符放到几张图片,组成gif,这样机器识别难度就加大了
2014-01-06 16:02

引用来自“白文”的评论

引用来自“eechen”的评论

引用来自“白文”的评论

引用来自“宅男小何”的评论

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

不太懂orcale,但是我说的验证码都获取不到啊,验证码应该是单独的服务器吧,跟你说的逻辑也没啥关系啊。你说的是购票!

同时请求访问数据库的进程过多时,会按照一定的调度策略排队,增加服务器没有任何作用,反而无法维持数据一致性。余票动态变化的性质决定了服务器的数量

购票请求全部进队,队列很容易横向扩展,而且也可以控制请求对数据库的压力,避免遭遇节假日瞬间的高负载。余票查询不需要考虑队列里的请求,用户提交购票请求后马上响应用户“购票请求已提交”,但能不能买到票还要看队列的处理进度和结果,处理完成则通知(比如短信通知)用户购票成功。

数据库方面如果能像MySQL那样配置多主多从、读写分离,那很容易就可以在读(查询)方面横向扩展。另外限定登录后才能查票也能减少读压力。

最后如果连刷票器都对付不了的话只能是自身技术问题,这没什么好说的。

你没有从硬件方面考虑,多个进程访问同一存储区域必须排队,否则会发生数据相关错误,一般这种排队由操作系统管理即可,但12306这种势必需要专门进程干预,提高处理器流水线效率,否则延迟相当惊人。

我说的队列当然是指守护进程、服务类型的的队列,比如著名的使用Erlang编写的支持AMQP(高级消息队列协议)的队列服务RabbitMQ Server。

正是因为考虑到数据库的吞吐量上限,才需要引入队列,这种应用层面的队列完全由程序控制,消费者(数据库)的消费速率是可控的。超大规模并发下用户直接向数据库请求显然是不现实的。
2014-01-06 14:51
这叫摸着石头过河不是?正儿八经的路咱不能走,干嘛都跟马云人家的电商平台一样?
2014-01-06 14:19

引用来自“lxbzmy”的评论

我只想说SB动画,从没见过这么SB的,验证码用动画。

腾讯搞过一段时间,后来又变成静态了
2014-01-06 14:14

引用来自“白文”的评论

引用来自“宅男小何”的评论

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

不太懂orcale,但是我说的验证码都获取不到啊,验证码应该是单独的服务器吧,跟你说的逻辑也没啥关系啊。你说的是购票!

同时请求访问数据库的进程过多时,会按照一定的调度策略排队,增加服务器没有任何作用,反而无法维持数据一致性。余票动态变化的性质决定了服务器的数量

购票请求全部进队,队列很容易横向扩展,而且也可以控制请求对数据库的压力,避免遭遇节假日瞬间的高负载。余票查询不需要考虑队列里的请求,用户提交购票请求后马上响应用户“购票请求已提交”,但能不能买到票还要看队列的处理进度和结果,处理完成则通知(比如短信通知)用户购票成功。

数据库方面如果能像MySQL那样配置多主多从、读写分离,那很容易就可以在读(查询)方面横向扩展。另外限定登录后才能查票也能减少读压力。

最后如果连刷票器都对付不了的话只能是自身技术问题,这没什么好说的。
2014-01-06 13:14

引用来自“白文”的评论

引用来自“宅男小何”的评论

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

当然购票我觉得12306也做得不行,具体逻辑不太清楚;但是有些东西跟购票没啥关系啊,比如登录。

每个用户登录都会建立一个TCP进程,当登录用户过多,急剧消耗服务器的带宽。由于抢票困难,很多用户滞留在网站上,进一步加大了负担。

HTTP持久连接keep-alive不是TCP进程,是TCP连接。
用Chrome访问一次本地的Nginx,用netstat可以方便看到:
sudo netstat -antp --timer|grep "127.0.0.1"|grep "ESTABLISHED"|egrep -i "chrome|nginx"

HTTP持久连接(keep-alive)能够在keepalive_timeout前省去每次传输报文都要建立连接(三次握手)的时间和开销。timeout时间由Web服务器设定,比如Nginx默认是72秒。对于活跃的用户而言,开启HTTP持久连接绝对是利大于弊。

另外维持HTTP持久连接不可能会消耗大量的带宽。
2014-01-06 11:34

引用来自“白文”的评论

引用来自“宅男小何”的评论

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

当然购票我觉得12306也做得不行,具体逻辑不太清楚;但是有些东西跟购票没啥关系啊,比如登录。

每个用户登录都会建立一个TCP进程,当登录用户过多,急剧消耗服务器的带宽。由于抢票困难,很多用户滞留在网站上,进一步加大了负担。

我知道很复杂,但是登录和验证码这块很容易扩展的吧?登录和验证的生成这块逻辑不难吧?我们先撇开余票查询和购票下单的复杂性!
2014-01-06 11:26

引用来自“codepat”的评论

GIF动画取其中一帧就是静态的了,出这个主意的人没大脑

说的是了,我们公司的验证码也是动态的
2014-01-06 11:26

引用来自“晏雨涵”的评论

动态的里面每一帧都是静态的图片吧。感觉动态只对人有影响

丫是明白人
2014-01-06 11:22
呵呵,为什么非要用数字+字母的验证方式?多学习学习“百度经验“产品的验证码吧,机器无解。
2014-01-06 11:17

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

当然购票我觉得12306也做得不行,具体逻辑不太清楚;但是有些东西跟购票没啥关系啊,比如登录。
2014-01-06 11:15

引用来自“StarGate”的评论

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性

不太懂orcale,但是我说的验证码都获取不到啊,验证码应该是单独的服务器吧,跟你说的逻辑也没啥关系啊。你说的是购票!
2014-01-06 11:06

引用来自“宅男小何”的评论

不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧

根据政策规定单人单日在同一线路不得买两张票,儿童票除外,另外同一线路同日票数必须有一个锁。请你也考虑下这个在后台使用Oracle数据库的情况下怎么设计分流,同时确保这个惟一性
2014-01-06 11:06

引用来自“kut”的评论

引用来自“雅各布奇”的评论

开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人

说实在的,应付这么大并发的网站,真的是很难的。

是的,很佩服12306的高并发
2014-01-06 10:28

引用来自“kut”的评论

引用来自“雅各布奇”的评论

开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人

说实在的,应付这么大并发的网站,真的是很难的。

跟双11比呢?12306可是每天晚上都要睡觉休息的哦
2014-01-06 10:22
不过多么牛逼,我只想说下技术不行,那么干不干多加台服务器啊,网页进不去,验证码获取不到,一切都卡死。给你们那么多钱做网站,多加台服务器不过分吧
2014-01-06 10:13

引用来自“kut”的评论

引用来自“雅各布奇”的评论

开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人

说实在的,应付这么大并发的网站,真的是很难的。

呵呵、世上无难事只怕有钱人
2014-01-06 10:09

引用来自“杨金焕”的评论

每个字符每次都扭曲、大小变化、排列间距变化、相粘连,在目前,相信再牛逼的的技术,机器识别是相当困难。我暂时没有见过可以的。

又不用读所有帧,拿出一帧来分析,分析不出来换一帧,被破解的可能性还大些。最好的验证码是10086的中文验证码。你无法准确识别中文,识别英文太容易了。
2014-01-06 10:01

引用来自“雅各布奇”的评论

开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人

说实在的,应付这么大并发的网站,真的是很难的。
2014-01-06 09:47
弄一个微信二维码,扫一下,关注,然后发送x,得到验证码回复。
瞬间就拥有了几千万关注
2014-01-06 09:46
刚去看了 登陆页 的验证码, 不是这样子的, 没有干扰线, 是歪歪斜斜的字母,数字~~
2014-01-06 09:41
开发这网站的同行,如果把这种小聪明用到提升网站性能上,也不至于做出这么大便的东西出来丢码农的人
2014-01-06 09:31

引用来自“lxbzmy”的评论

我只想说SB动画,从没见过这么SB的,验证码用动画。

语音呢?
2014-01-06 09:21
好强大
2014-01-06 09:06
每个字符每次都扭曲、大小变化、排列间距变化、相粘连,在目前,相信再牛逼的的技术,机器识别是相当困难。我暂时没有见过可以的。
2014-01-06 08:59
动态的验证码完全扯淡啊。。。那玩意是专门防正常用户给机器人用的。。。
2014-01-06 08:29
动态的里面每一帧都是静态的图片吧。感觉动态只对人有影响
2014-01-06 08:16
搞笑。
回复 @
{{emojiItem.symbol}}
返回顶部
顶部