php的生命周期
① 怎么理解php Session的用法 生命周期 过期时间
session简介
Session直接翻译成中文比较困难，一般都译成时域。在计算机专业术语中，Session是指一个终端用户与交互系统进行通信的时间间隔，通常指从注册进入系统到注销退出系统之间所经过的时间以及如果需要的话，可能还有一定的操作空间。
具体到Web中的Session指的就是用户在浏览某个网站时，从进入网站到浏览器关闭所经过的这段时间，也就是用户浏览这个网站所花费的时间。因此从上述的定义中我们可以看到，Session实际上是一个特定的时间概念。
需要注意的是，一个Session的概念需要包括特定的客户端，特定的服务器端以及不中断的操作时间。A用户和C服务器建立连接时所处的Session同B用户和C服务器建立连接时所处的Session是两个不同的Session。
② asp.net 高手过来领分啦，急，急
主要分服务器的安全 程序的安全
服务器的安全 扯远了，你去相关论坛都能找到 关闭不必要端口服务等等。。。
程序的安全
主要有数据库的安全，比如sql注入 mdb文件安全 写相关数据库语句的时候注意一下就行了
还有就是上传文件的地方，做好处理，防止非法用户上传木马 提权
想到的就这些了，对应着搜索一下看看如何详细处理就行了
③ PHP的性能探讨和测试
缘起
关于PHP 很多人的直观感觉是PHP是一种灵活的脚本语言 库类丰富 使用简单 安全 非常适合WEB开发 但性能低下 PHP的性能是否真 的就如同大家的感觉一样的差呢？本文就是围绕这么一个话题来进行探讨的 从源码 应用场景 基准性能 对比分析等几个方面深入分析PHP之性能问题 并通 过真实的数据来说话
从原理分析PHP性能
从原理分析PHP的性能 主要从以下几个方面 内存管理 变量 函数 运行机制来进行分析
内存管理
类似Nginx的内存管理方式 PHP在内部也是基于内存池 并且引入内存池的生命周期概念 在内存池方面 PHP对PHP脚本和扩展的所有内 存相关操作都进行了托管 对大内存和小内存的管理采用了不同的实现方式和优化 具体可以参考以下文档 在内存分配和回收的生命周期内 PHP采用一次初始化申请+动态扩容+内存标识回收机制 并且在每次请求结束后直 接对内存池进行重新mask
变量
总所周知 PHP是一种弱变量类型的语言 所以在PHP内部 所有的PHP变量都对应成一种类型Zval 其中具体定义如下
图一PHP变量
在变量方面 PHP做了大量的优化工作 比如说Reference counting和 on writer机制 这样能够保证内存使用上的优化 并且亮简逗减少内存拷贝次数（请参考） 在数组方面 PHP内部采用高效的hashtable来实现
函数
在PHP内部 所有的PHP函数都回转化成内部的一个函数指针 比如说扩展中函数
ZEND_FUNCTION(my_function);//类似functionmy_function(){}
在内部展开后就会是一个函数
voidzif_my_function(INTERNAL_FUNCTION_PARAMETERS);
voidzif_my_function(
intht
zval*return_value
zval*this_ptr
intreturn_value_used
zend_executor_globals*executor_globals
);
从这个角度来看 PHP函数在内部也是对应一个函数指针
运行机制
敬卖在话说PHP性能的时候 很多人都会说“C/C++是编译型咐李 JAVA是半编译型 PHP是解释型” 也就是说PHP是先动态解析再代码运行的 所以从这个角度来看 PHP性能必然很差
的确 从PHP脚本运行来输出 的确是一个动态解析再代码运行的过程 具体来说 PHP脚本的运行机制如下图所示
图二 PHP运行机制
PHP的运行阶段也分成三个阶段
Parse 语法分析阶段
Compile 编译产出opcode中间码
Execute 运行 动态运行进行输出
所以说 在PHP内部 本身也是存在编译的过程 并且据此产生了大量的opcode cache工具 比如说apc eacc xcache等等 这些opcode cache在生产环境基本上在标配 基于opcode cache 能到做到“PHP脚本编译一次 多次运行”的效果 从这点上 PHP就和JAVA的半编译机制非常类似
所以 从运行机制上来看 PHP的运行模式和JAVA是非常类似的 都是先产生中间码 然后运行在不同虚拟机上
动态运行
从上面的几个分析来看 PHP在内存管理 变量 函数 运行机制等几个方面都做了大量的工作 所以从原理来看 PHP 不应该存在性能问题 性能至少也应该和Java 比较接近
这个时候就不得不谈PHP动态语言的特性所带来的性能问题了 由于PHP是动态运行时 所以所有的变量 函数 对象调用 作用域实现等等都是在 执行阶段中才确定的 这个从根本上决定了PHP性能中很难改变的一些东西 在C/C++等能够在静态编译阶段确定的变量 函数 在PHP中需要在动态运行 中确定 也就决定了PHP中间码不能直接运行而需要运行在Zend Engine上
说到PHP变量的具体实现 又不得不说一个东西了 Hashtable Hashtable可以说在PHP灵魂之一 在PHP内部广泛用到 包含变量符号栈 函数符号栈等等都是基于hashtable的
以PHP变量为例来说明下PHP的动态运行特点 比如说代码
<?php
$var=“hello blog xiuwz ”;
?>
该代码的执行结果就是在变量符号栈（是一个hashtable）中新增一个项
当要使用到该变量时候 就去变量符合栈中去查找（也就是变量调用对出了一个hash查找的过程）
同样对于函数调用也基本上类似有一个函数符号栈（hashtable）
其实关于动态运行的变量查找特点 在PHP的运行机制中也能看出一些 PHP代码通过解释 编译后的流程下图
图 PHP运行实例
从上图可以看出 PHP代码在pile之后 产出的了类符号表 函数符号表 和OPCODE 在真正执行的时候 zend Engine会根据op code去对应的符号表中进行查找 处理
从某种程度上 在这种问题的上 很难找到解决方案 因为这是由于PHP语言的动态特性所决定的 但是在国内外也有不少的人在寻找解决方案 因为 通过这样 能够从根本上完全的优化PHP 典型的列子有facebook的hiphop
结论
从上面分析来看 在基础的内存管理 变量 函数 运行机制方面 PHP本身并不会存在明显的性能差异 但由于PHP的动态运行特性 决定了 PHP和其他的编译型语言相比 所有的变量查找 函数运行等等都会多一些hash查找的CPU开销和额外的内存开销 至于这种开销具体有多大 可以通过后 续的基准性能和对比分析得出
因此 也可以大体看出PHP不太适合的一些场景 大量计算性任务 大数据量的运算 内存要求很严格的应用场景 如果要实现这些功能 也建议通过扩展的方式实现 然后再提供钩子函数给PHP调用 这样可以减低内部计算的变量 函数等系列开销
基准性能
对于PHP基准性能 目前缺少标准的数据 大多数同学都存在感性的认识 有人认为 QPS就是PHP的极限了 此外 对于框架的性能和框架对性能的影响很没有响应的权威数字
本章节的目的是给出一个基准的参考性能指标 通过数据给大家一个直观的了解
具体的基准性能有以下几个方面
裸PHP性能 完成基本的功能
裸框架的性能 只做最简单的路由分发 只走通核心功能
标准模块的基准性能 所谓标准模块的基准性能 是指一个具有完整服务模块功能的基准性能
环境说明
测试环境
Uname aPnux db forum test db _ # SMP Wed Aug : : CST x _ x _ x _ GNU/PnuxRed Hat Enterprise Pnux AS release (Nahant Update )
Intel(R) Xeon(R) CPU E @ GHz
软件相关
Nginx nginx version: nginx/ built by gcc (Red Hat )Php （采用php fpm）
PHP (cP) (built: Mar : : )
Copyright (c) The PHP Group
Zend Engine v Copyright (c) Zend Technologies
with eAccelerator v Copyright (c) eAccelerator by eAccelerator
bingo
PHP框架
其他说明
目标机器的部署方式 nginx >php fpm >php脚本
测试压力机器和目标机器独立部署
裸PHP性能
最简单的PHP脚本
<?php
require_once‘ /actions/indexAction php’;
$objAction=newindexAction();
$objAction >init();
$objAction >execute();
?>
Acitons/indexAction php里面的代码如下
<?php
classindexAction
{
pubPcfunctionexecute()
{
echo‘hello world!’;
}
}
?>
通过压力工具测试结果如下
裸PHP框架性能
为了和 的对比 基于bingo 框架实现了类似的功能 代码如下
<?php
require_once‘Bingo/Controller/Front php’;
$objFrontController=Bingo_Controller_Front::getInstance(array(
‘actionDir’=>‘ /actions’
));
$objFrontController >dispatch();
压力测试结果如下
从该测试结果可以看出 框架虽然有一定的消耗 但对整体的性能来说影响是非常小的
标准PHP模块的基准性能
所谓标准PHP模块 是指一个PHP模块所必须要具体的基本功能
路由分发
自动加载
LOG初始化&Notice日志打印 所以的UI请求都一条标准的日志
错误处理
时间校正
自动计算每个阶段耗时开销
编码识别&编码转化
标准配置文件的解析和调用
采用bingo 的代码自动生成工具产生标准的测试PHP模块 test
测试结果如下
结论
从测试数据的结论来看 PHP本身的性能还是可以的 基准性能完全能够达到几千甚至上W的QPS 至于为什么在大多数的PHP模块中表现不佳 其实这个时候更应该去找出系统的瓶颈点 而是简单的说OK PHP不行 那我们换C来搞吧 （下一个章节 会通过一些例子来对比 采用C来处理不见得有特 别的优势）
通过基准数据 可以得出以下几个具体的结论
PHP本身性能也很不错 简单功能下能够达到 QPS 极限也能过W
PHP框架本身对性能影响非常有限 尤其是在有一定业务逻辑和数据交互的情况下 几乎可以忽略
一个标准的PHP模块 基准性能能够达到 QPS（ cpu idle）
对比分析
lishixin/Article/program/PHP/201311/21287
④ websocket简介
WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）
首先HTTP有 1.1 和 1.0 之说，也就是所谓的 keep-alive，把多个HTTP请求合并为一个，但是 Websocket 其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充
他们有交集，但是并不是全部。
另外Html5是指的一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。。通俗来说，你可以用HTTP协议传输非Html数据，就是这样=。=
再简单来说，层级不一样。
首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。
HTTP的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次HTTP请求就结束了。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。
教练，你BB了这么多，跟Websocket有什么关系呢？ (:з”∠) 好吧，我正准备说Websocket呢。。
首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。
首先我们来看个典型的 Websocket 握手（借用Wikipedia的。。）
熟悉HTTP的童鞋可能发现了，这段类似HTTP协议的握手请求中，多了几个东西。我会顺便讲解下作用。
这个就是Websocket的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理~不是那个老土的HTTP。
首先， Sec-WebSocket-Key 是一个 Base64 encode 的值，这个是浏览器随机生成的，告诉服务器：泥煤，不要忽悠窝，我要验证尼是不是真的是Websocket助理。
然后， Sec_WebSocket-Protocol 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。简单理解：今晚我要服务A，别搞错啦~
最后， Sec-WebSocket-Version 是告诉服务器所使用的 Websocket Draft（协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦 大家都使用的一个东西 脱水： 服务员，我要的是13岁的噢→_→
然后服务器会返回下列东西，表示已经接受到请求， 成功建立Websocket啦！
这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦~
Upgrade: websocket
Connection: Upgrade
依然是固定的，告诉客户端即将升级的是 Websocket 协议，而不是mozillasocket，lurnarsocket或者shitsocket。
然后， Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key 。 服务器：好啦好啦，知道啦，给你看我的ID CARD来证明行了吧。。
后面的， Sec-WebSocket-Protocol 则是表示最终使用的协议。
至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。
——————技术解析部分完毕——————
你TMD又BBB了这么久，那到底Websocket有什么鬼用， http long poll ，或者ajax轮询 不都可以实现实时信息传递么。
好好好，年轻人，那我们来讲一讲Websocket有什么用。来给你吃点胡（苏）萝（丹）卜（红）
在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。
ajax轮询
ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
场景再现：
long poll
long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
场景再现：
从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。
简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。
说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）
从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
所以 ajax轮询 和 long poll 都有可能发生这种情况。
言归正传，我们来说Websocket吧
通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。
一种需要更快的速度，一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。
哦对了，忘记说了HTTP还是一个状态协议。
通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。
所以在这种情况下出现了，Websocket出现了。他解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。
就变成了这样，只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你 ）
这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢？
其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。简单地说，我们有一个非常快速的 接线员（Nginx） ，他负责把问题转交给相应的 客服（Handler） 。
本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。
这样就可以解决客服处理速度过慢的问题了。
同时，在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。
虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间。
但是Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。
同时由客户主动询问，转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的客服（Handler）了
——————–
至于怎么在不支持Websocket的客户端上使用Websocket。。答案是： 不能
但是可以通过上面说的 long poll 和 ajax 轮询 来 模拟出类似的效果