简述Zmq的三个模型：
SPDY协议
今天发现HttpWatch 8.3 Supports SPDY 支持SPDY协议了，那么这是个嘛玩意儿呢，点到官网看看说明 ：http://dev.chromium.org/spdy/spdy-whitepaper 发现这是个很牛的东东啊，谷歌如果依靠这个颠覆了HTTP，那对其霸主地位梦想的实现，颇有好处，如若提前关注这个东西，对于自身的提高，到也是极有好处的。
TCP控制协议（一）
The TCP is assumed to be a module in an operating system. The users access the TCP much like they would access the file system.
TCP是操作系统内置的一种模型，他的目的是为了让像访问本地文件系统一样，访问网络数据。
HTTP/1.1的那些状态码
- 状态码的定义
本章定义了一系列的状态码（服务器返回的）以及它所依附的方法。一共分为以下几类：
1xx：继续
2xx：正常
3xx：重定向
4xx：客户端错误
5xx：服务器端错误
HTTP/1.1的那些方法
最近没有更新是因为，时间比较紧张，另外，这几章比较繁琐，还是硬着头皮上吧，不然，老放在心里面，不踏实，而这几张是非常重要的几张，包括：方法、状态码、cache。
HTTP/1.1之连接（第八章）
HTTP/1.1之连接（第八章）
8.1 持久性连接
目的：
在以前，没有持久性连接的时候，为了获取每一个URL都要进行一次TCP连接，这显然加重了服务器的负担，容易引起互联网的堵塞，因为你要多次进行三次握手，尤其是页面里面有很多内联的图片、css样式表、js文件时候，简直让人崩溃。所以，持久连接有以下特点：
HTTP/1.1阅读之信息实体
7 信息主体
信息主体是由信息头和信息主体两部分组成的，除非被Status-code或是请求方法限制了，导致没有信息主体（为空）。我们在这章讨论的时候，发送和请求是辩证唯物的。当客户端请求服务器的时候，客户端是发送方，而服务器是接收方，但是服务器返回信息的时候，服务器是发送方，而客户端则是接收方。
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header 以上实体部分，有些选项是可选的，有些则是必须的。其中的extension-header可以不用升级协议版本就可以扩展信息主体，但是你不能期望人家 接收方能够正确的识别，如果对方识别不了，这个扩展区将被忽略，但是代理转发的时候，你不能随意的忽略这个扩展区，这很好理解，因为你是代理 你又不知道人家接收方能不能识别这个扩展信息。
entity-body = *OCTET 如果实体存在的话，他的编码方式是在信息头域的Transfer-Encoding来决定的，这东西就是用来保证信息能够被正确的传输。 如果实体信息存在的话，他们会由头域的Content-Encoding和Content-Type来确定的，这些头域定义了两层顺序的编码模型，例如：
entity-body := Content-Encoding( Content-Type( data ) )，其中前者一般用于定义使用了什么压缩方式，而后者type表示请求的是什么类型 如果没有指定，他就会去猜，实在猜不到就application/octet-stream这样了 实体信息的长度是编码前的长度，4.4节已经定义了，如果去确定信息的长度。
HTTP/1.1阅读之响应
HTTP/1.1阅读之请求
5.1 请求消息的构成
在上一章，我们知道一个请求的消息应该由以下几部分组成：
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
他们是请求头（由请求行、一般头、请求头和信息头）+信息主体构成。我们来看看请求行（Request-Line），他是由下面几部分构成的：
Method sp URI sp HTTP-Version CRLF,我们来像教科书一样，看看各个部分都是干啥的
慎用preg_replace的/e修饰符
最近，wooyun上面爆了一个ThinkPHP的漏洞（最新版已经修复），以前也是我用过的第一个框架，昨晚花时间重现了一下，查阅了下程序的原理，原来这东西还得慎用。主要是由mixed preg_replace ( mixed pattern, mixed replacement, mixed subject [, int limit]) 这个函数引起的，在官方说明中，
/e 修 正符使 preg_replace() 将 replacement 参数当作 PHP 代码（在适当的逆向引用替换完之后）。提示：要确 保 replacement 构成一个合法的 PHP 代码字符串，否则 PHP 会在报告在包含 preg_replace() 的行中出现语法解析错 误。