New composite based captcha image

recaptcha的验证码新增了alpha composite的新机制取代干扰线，今天用了一些时间在YAN上也实现了这种绘图机制。

使用Java2D的AlphaComposite实现，选用的Rule为alpha 1.0的SrcOut，即通过公式

Ar = As * (1 – Ad )
Cr = Cs * (1 – Ad )
用语言描述就是叠加区域的透明度为0. 使用这种机制必须采用BufferedImage.TYPE_INT_ARGB的图像，并且输出支持alpha通道的格式。

Web 2.0 Icon Captcha

Yan 新增了一种验证码类型，Web 2.0 图标验证码。用户根据图标的内容和提示的信息，提交验证码。验证码图片如下：

提示文字： Please figure out twitter icons.

用户输入Twitter图标左上角上的字母，即可进行验证。在Yan的测试界面上使用如图：

Web2.0 Icon实际上是Yan中新增的拼图验证码的一个实例，利用拼图验证码可以生成相似的更有创意的验证码。在我的开发环境中生成这样一张图片大约需要80ms。

项目中使用的图标均从互联网收集，遵循CC等协议或经作者授权，详情参考项目中README文件。

祝DAF同学生日快乐。

Load Test on Yan

给Yan的验证码图片服务做了压力测试。测试环境：

• Intel Xeon 3.00GHz 4核
• 内存2G
• Red Hat Enterprise Linux AS release 4 (Nahant Update 7)
• Jetty 6 / JDK 6

Jetty采用默认配置 maxThreads 200。

测试工具：ab (Apache Bench)

分别用10/50/100/200/500/1000并发用户，每个用户请求100次进行测试。结果如下：

	10	50	100	200	500	1000
Requests per second	487.11	472.09	442.74	421.63	408.11	326.12
Time per request	2.05	2.12	2.26	2.37	2.45	3.07
Transfer rate	987.91	955.54	896.85	854.31	826.25	660.45



目前对每个请求独立使用JDK的awt实时绘图，吞吐量可以达到400以上，如果稍稍优化一下Jetty的配置，性能还有一定的提升空间。这个结果还是不错的。

Yan Captcha Service

I’d like to announce my recent works, a project called Yan Captcha Service written in Java which is aimed to provide whole solutions of captcha for your websites. It will be very easy to use the service because 1. interfaces are based on plain http url; 2. different kinds of usage are supported to fit your requirements; 3. the architecture is open so you can add your own solid implementation of captcha; 4. less coupling with your system. And designed for scalability, currently, it applies JGroups to share sessions (memcached support will be added soon), thus you can setup a cluster for the service.

As you may know, the open-source project is split from my current work-time project because it is more closed to my idea. However, soon we will have the product opened to our thousands (millions ?) of users. I can gain feedback from the challenge and improve the open-source edition.

The code is maintained by open-source scm, mercurial (also known as hg). The project is now hosted on bitbucket.org. You can clone the code to local via:
$ hg clone https://sunng@bitbucket.org/sunng/yan/

To build the project, run this command in root of project directory:
mvn install

To run in a develop environment:
mvn jetty:run

Issue reporting and patches are always welcomed.

Check the wiki pages for more information about the project:
http://bitbucket.org/sunng/yan/wiki/Home

另一种验证码方式

今天又讨论了一种验证码服务的机制，这种机制相对前两天说的简化的验证码生成的部分，由两步生成变成了一步生成，当然由于生成图片的接口直接暴露给用户，存在被刷的可能。

1. 用户浏览器向应用服务器请求包含验证码的页面；
2. 应用服务器将包含验证码地址的网页发送给用户浏览器；
3. 用户浏览器通过img的src中的固定链接向验证码服务器请求验证码图片；
4. 验证码服务器输出验证码图片流到用户浏览器，将sessionid写入cookie；
5. 用户判读验证码图片，提交表单；
6. 应用服务器取出cookie中的sessionid和用户输入发往验证码服务器；
7. 验证码服务器进行验证，返回通过或拒绝；
8. 应用服务器根据验证码服务器结果进行响应。

优点：
固定链接，简化了接入，便于接入静态页面；

缺点：
写cookie受到域的限制，只能在相同的域中使用该服务；
验证码接口暴露给用户，可能被穷举

百度和腾讯使用的都是这种方式。

验证码服务的两种方式

方式1，应用服务器负责生成验证码字符，验证码服务器主要负责验证码图片生成。

1. 用户浏览器向应用服务器请求包含验证码的页面；
2. 应用服务器生成验证码字符，存储在session中；应用服务器发送相关图片参数（验证码字符、宽、高、复杂度、背景色等）到验证码服务器；
3. 验证码服务器返回图片地址到应用服务器；
4. 应用服务器将包含验证码地址的网页发送给用户浏览器；
5. 用户浏览器通过img的src方式向验证码服务器请求验证码图片；
6. 验证码服务器输出验证码图片流到用户浏览器；
7. 用户判读验证码图片，提交表单；
8. 应用服务器取出session中的验证码字符比对，返回结果。

这种方式的优点：

1. 较少的HTTP请求调用
2. 替换原应用中独立的验证码功能相对容易
3. 验证码服务器相对简单

方式2，验证码服务器承担验证功能，应用服务器在验证中仅起到传递作用。

1. 用户浏览器向应用服务器请求包含验证码的页面；
2. 应用服务器发送相关图片参数（宽、高、复杂度、背景色等）到验证码服务器；
3. 验证码服务器返回图片地址、惟一的会话id到应用服务器；
4. 应用服务器将包含验证码地址的网页发送给用户浏览器；
5. 用户浏览器通过img的src方式向验证码服务器请求验证码图片；
6. 验证码服务器输出验证码图片流到用户浏览器；
7. 用户判读验证码图片，提交表单；
8. 应用服务器将第三步获得的会话id和用户输入的验证码字符传给验证码服务器；
9. 验证码服务器进行验证，返回通过或拒绝；
10. 应用服务器根据验证码服务器结果进行响应。

这种方式的优点：

1. 验证码服务功能完善，涵盖整个验证流程；
2. 验证码服务端有详细的验证日志记录，便于数据分析；

欢迎大家就两种方式发表意见～