彬彬的博客

  • 首页
  • 归档
  • 分类
  • 关于

苹果示例源码阅读:SimplePing

发表于 2016-11-07 | 分类于 iOS 技术文章

前言

手机网络连接状态的检测对于 iOS App 开发来说是一个非常基础的需求,在前一篇文章 苹果示例源码阅读:Reachability 我们介绍了如何通过 SCNetworkReachability 提供的一系列 C 函数 API 进行网络连接状态变化的监听。但事实上,此方案能获取的只是设备的本地连接状态,有时它很难为我们检测真正的网络连接状态,如以下场景:

  • 现在很多的公共场所的 WiFi,需要网页登录授权,授权之前无法上网,但本地连接已经建立;
  • 存在了本地网络连接,但信号很差,实际无法连接到服务器;
  • iOS 连接的路由设备本身没有连接外网等。
阅读全文 »

苹果示例源码阅读:Reachability

发表于 2016-10-08 | 分类于 iOS 技术文章

Reachability 是苹果官方提供的示例源码,它是对 SystemConfiguration.framework 模块中的 SCNetworkReachability.h 头文件里提供的一系列网络连接状态相关的 C 函数进行简单封装,以示范如何在 iOS App 开发中实现网络状态变化监听,由此也衍生出各种 Reachability 框架,比较著名的有 Github 上的 tonymillion/Reachability 以及 AFNetworking 中的 AFNetworkReachabilityManager 模块,它们的实现原理基本上是完全相同的。

下面我们就来阅读分析一下苹果提供的 Reachability 源码,源码中最核心的就 Reachability.h 和 Reachability.m 两个文件。

阅读全文 »

Objective-C 中 NULL、nil、Nil、NSNull 的定义及不同

发表于 2016-09-30 | 分类于 iOS 技术文章

理解”不存在“的概念不仅仅是一个哲学的问题,也是一个实际的问题。我们是有形宇宙的居民,而原因在于逻辑宇宙的存在不确定性。作为一个逻辑系统的物理体现,计算机面临一个棘手的问题,就是如何用”存在“表达”不存在“。–摘自 NSHipster

这段话读起来怪怪的,毕竟是翻译过来的,大概意思是说在计算机中如何描述”不存在“这个概念很重要。

在 C 语言中用 0 来作为“不存在”的原始值,而用 NULL 作为指针空值。在 Objective-C 中,则有几种不同的方式来表示“不存在”,分别有:NULL、nil、Nil、NSNull。下面我们来看看这几种空值的定义以及使用上的不同。

阅读全文 »

Objective-C 中 nullable、__nullable、_Nullable 的区别

发表于 2016-09-04 | 分类于 iOS 技术文章

缘由

在 Swift 中,我们会使用 ? 和 ! 去显式声明一个对象或者方法的参数是 optional 还是 non-optional,而在 Objective-C 中则没有这一区分,这样就会带来一个问题:在 Swift 与Objective-C 混编时,Swift 编译器并不知道一个 Objective-C 对象或者一个方法的参数到底是 optional 还是 non-optional,因此这种情况下编译器会隐式地都当成是 non-optional 来处理,这显然是不太好的。

阅读全文 »

谈谈 Objective-C 链式语法的实现

发表于 2016-08-29 | 分类于 iOS 技术文章

引言

对于 Objective-C 的语法,喜欢的人会觉得它是如此的优雅,代码可读性强,接近自然语言,开发者在调用大多数方法时不需要去查看注释或文档,通常只凭借方法名就可以大致知道这个方法的作用,可以理解为 代码即注释;而对于不喜欢的人来说,会觉得这种语法规则太啰嗦了!

直到第三方自动布局框架 Masonry 的出现,如下面代码,大家才发现,原来 Objective-C 还可以这么玩!

1
2
3
4
5
6
[view1 mas_makeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(superview.mas_top).with.offset(padding.top);
make.left.equalTo(superview.mas_left).with.offset(padding.left);
make.bottom.equalTo(superview.mas_bottom).with.offset(-padding.bottom);
make.right.equalTo(superview.mas_right).with.offset(-padding.right);
}];

今天我们就来谈一谈在 Objective-C 中如何实现这种链式调用语法。

阅读全文 »

Hello JD

发表于 2016-07-22 | 分类于 其它
  • A New Beginning to My Career Life.

毕业

发表于 2016-06-08 | 分类于 其它

移动终端 Android、iOS、Windows Phone 中的推送通知服务

发表于 2015-07-15 | 分类于 移动端

有人的地方就有江湖,那么有智能手机的地方应该就会有推送通知。

推送并不是什么新技术,它在 PC 互联网时代就已经很流行了,最早被应用于 Email 中。只是随着进入移动互联网时代,推送技术显得更加重要。因为在智能手机中,推送通知从某种程度上,可以取代使用多年的短信,它可以展现更多形式的内容,而且用户比任何时候都渴望即时获取到新信息。

我们先来看一下,在使用推送通知技术以前,当服务器有新消息时,如何与手机客户端进行通信:

  • 轮询(Pull)方式:应用程序应当阶段性地与服务器进行连接并查询是否有新的消息,开发者必须自己实现与服务器之间的通信,如消息排队等。而且,还需要考虑轮询的频率,如果太慢可能导致某些消息延迟,如果太快,则会大量消耗网络流量和电池电量。

  • SMS(Push)方式:在 Android 平台上,应用程序可以通过拦截 SMS 消息并解析消息内容来了解服务器的意图,并获取其显示内容进行处理,这是一个很不错的想法,大概三四年前见过采用这种方案的应用,现在几乎没有了。这种方案的好处是,可以实现完全的实时操作,但是问题是这个方案的成本相对比较高,很难找到免费的短消息发送网关,而且目前 Android 系统权限管理日益严格,并不是所有应用程序都可以读取短信,所以现在基本弃用。

  • 持久连接(Push):这个方案可以解决由轮询带来的性能问题,但是还是会消耗手机的电池。Apple 的推送服务之所以工作得很好,是因为每一台手机仅仅保持一个与服务器之间的连接,事实上 Google 的 GCM 也是这么工作的。不过这个方案也存在不足,就是我们很难在手机上实现一个可靠的服务。Android 系统允许在低内存情况下杀死系统服务,所以你的通知服务很可能随时被操作系统 kill 掉了。

  • Push Notification:通常情况下,客户端主动向服务器发出请求,服务器才会向客户端传送数据,推送通知服务(Push Notification)的出现改变了这一状况,其思想是将客户端主动请求信息改变为服务器主动发送信息。服务器发送一批数据,客户端显示这些数据,同时保证与服务器的连接。当服务器需要再次发送一批数据时,客户端显示数据并保持连接。以后,服务器仍然可以发送批量数据,客户端继续显示数据,依次类推。Android、iOS、Windows Phone 平台上都有自己的推送服务,其中 Android 平台上还出现了第三方推送服务,其功能基本相同,只不过工作流程上略有差异。

Android 推送通知服务 GCM

Android Cloud to Device Messaging (C2DM) 是作为 Android 2.2 系统的一部分发布的,C2DM 允许第三方开发者开发相关应用来推送少量数据信息(1024 字节)到用户的手机上,它允许我们使用多种 Google 开发工具来创建一种简单但是相当实用的应用类型,用户可以使用该类型的应用把各种各样的信息从他们的服务端直接推送到手机上,不过,谷歌官方已经于 2012 年 6 月 26 日正式弃用,取而代之的是新版的 Google Cloud Messaging for Android (GCM) 服务,这意味着 C2DM 已经停止接受新用户和配额请求,也不会有新的特性被加入到 C2DM 中,然而,使用 C2DM 的应用当然会继续工作,现有的 C2DM 开发者都被鼓励迁移到新的 GCM 上,同时,开发者在开发新的应用的时候必须要使用 GCM。

Google Cloud Messaging for Android (GCM) 允许你从服务器发送数据到安卓设备中,同时也可以利用这个连接来接收安卓设备发过来的数据。GCM 服务处理各方面的消息队列,并将其传递到运行安卓应用程序的目标设备上。无论发送的消息多么大 GCM 都是完全免费的,并且没有配额的限制。GCM 消息应该是一个轻量级的消息,提醒应用程序需要在服务器上获取新的数据(例如:“新邮件”提醒可以提示应用程序去服务器上同步邮件),或者它也可以包含不超过 4KB 的有效载荷数据(这样,即时通讯类的应用程序就可以直接来传递消息)。

下面是 GCM 服务的一些特性:

  • 它允许第三方应用程序服务器向安卓应用程序发送消息。
  • 使用 GCM 云连接服务器,你可以接受用户设备上传过来的消息。
  • 安卓设备上的应用程序不需要保持运行来接收消息,当消息到达时,只要应用程序建立了适当的广播接收机制和权限,系统就会通过内部广播通知来唤醒应用程序。
  • 它并没有提供任何内置的用户界面或处理数据的机制,GCM 只是简单的将接收到的原始数据直接传递给应用程序,应用程序对接收到的数据有着完全控制权限。例如,应用程序会发送一条通知、显示一个自定义的用户界面,或者在后台同步数据。
  • 它需要在设备上运行安卓 2.2 或者更高的版本并且安装有谷歌应用商店,或者运行带有谷歌 API 的安卓 2.2 的模拟器。然而你可以不受限制的通过谷歌应用商店来部署你的应用程序。
  • 它需要一个已经存在的谷歌服务连接,对于安卓 3.0 之前的设备,这需要用户在移动设备中登录他们的谷歌账户,对于安卓 4.0.4 或更高版本,谷歌账户并不是必须的。

工作原理和流程

一个 GCM 的实现包括了谷歌提供的连接服务器,与连接服务器交互的第三方应用程序服务器,和在安卓设备上运行的启用了 GCM 的客户端应用程序。

  • (1)谷歌提供的 GCM 连接服务器从第三方应用程序服务器上获取消息,然后将消息发送到运行在设备上的启用了 GCM 的安卓应用程序(客户端应用)。截至目前,谷歌为 HTTP 和 XMPP 提供连接服务器。
  • (2)第三方应用程序服务器是你和你所选择的 GCM 连接服务器实施工作的一个组件,应用程序服务器将消息发送到 GCM 连接服务器,连接服务器将这些消息加入队列名存储,然后当设备在线的时候将其发送给设备。更多信息请参见实现 GCM 服务器。
  • (3)客户端应用程序是运行在设备上的启用了 GCM 的的应用程序。为了接收 GCM 消息,应用程序必须和 GCM 注册,并获取到注册 ID,如果你使用 XMPP(CCS) 连接服务器,则客户端可以使用上传数据流来向服务端发送消息。关于实现客户端应用的更多信息,请参见实现 GCM 客户端。

第三方推送

由于 GFW 的原因,谷歌的 GCM 服务在国内基本是无法使用,所以现在国内安卓应用开发商一般基于 XMPP 协议或者 MQTT 协议自己实现持久连接通信。当然国内也有类似很多成熟的提供推送服务的厂商,如:腾讯信鸽、极光推送等。

iOS 推送通知服务 APNS

APNS(Apple Push Notification Services)是苹果公司官方提供的消息推送服务,也是 iOS 上唯一的消息推送服务,任何想要使用推送服务的 APP 都必须使用此项服务。每台设备要与推送服务建立起加密认证的 IP 连接并通过这个持续的连接来接收通知。如果通知到达的时候应用程序没有在运行,则设备会提示用户该应用程序有数据等待处理。

应用开发者(供应商)在他们的服务器软件中生成通知消息,供应商通过一个持续的安全的通道与 APNS 进行连接并同时监视要发送到客户端程序中的数据,当新的数据到达时,提供者就会准备好并通过上面的通道将通知发送到 APNS,这会将通知推送到目标设备中。

苹果推送通知服务从一个指定的供应商到一个指定的设备传输通知,一条通知是一个由两个主要部分组成的短消息:设备令牌和有效载荷。设备令牌是一种类似于电话号码的东西,它包含了能够使 APNS 定位到安装了客户端程序的设备上。APNS 也使用设备令牌来验证一条通知的路由。有效载荷是一条 JSON 定义的属性列表,指定了设备上的应用程序如何来提醒用户。

推送通知的数据流是单向的,供应商(Provider)为客户端应用程序创建一条包含了设备令牌的通知和有效载荷,供应商将通知发送到 APNS,反过来 APNS 又将通知推送到设备中。当供应商验证自身身份到 APNS 之后 他会将自己的主题发送到 APNS 服务器,这个主题标识了它将会向哪个应用程序提供数据。主题目前也是绑定目标应用程序的标识符。

下图表示了一条推送通知从供应商到客户端应用程序的路径。

上图是一个大大简化了的 APNS 虚拟网络,实际情况中,APNS 的设备端和供应商端都有许多连接点。在供应商那一侧的连接点叫做网关。有许多供应商,每个供应商都通过网关和 APNS 维持一个或多个持续的安全连接,这些供应商通过 APNS 向安装了他们应用程序的设备上推送通知,下图是一个比较接近实际的描述。

另外,每次推送的回执服务向供应商提供关于消息无法被成功送达的消息,例如因为目标应用程序已经从设备上卸载。更多信息,请参见“回执服务”。

工作流程

在发送消息到客户端设备接收到消息的过程中,始终伴随这一个令牌的传送(device token)。要想使用 APNS 提供消息服务,应用程序需要先向 iOS 注册需要提供的一个必要的信息就是与当前设备有关的 device token,iOS 在接收到 device token 后,会向 APNS 查询这个 device token 是否在 APNS 上注册了,如果已经注册,APNS 会直接向应用程序返回这个 device token。应用程序获得这个 device token 后,表示 APNS 已经允许向自己推送消息了,接着还需要将该 device token 发送给推送服务器(Provider)。到这里应用程序已经成功将自己注册到 APNS 中了。现在就可以通过 Provider 产生要推送的消息,然后 Provider 会将消息发送给 APNS 服务器,最后 APNS 服务器会直接向应用程序发送消息。这个过程比较复杂,不过看一下图的描述就会对这一过程更加了解了。每一个流程描述前面的数字表示发送的时间先后顺序。

Windows Phone 推送通知服务 MPNS

推送通知是 Windows Phone 上的内置特性,开发者可以利用 Windows Phone 的消息推送服务来实现网络服务器向手机客户端推送一些通知或者消息。Microsoft Push Notification Service 是 Windows Phone 上的一个异步的推送服务,向第三方应用程序开发者提供了一条高效能的从云端向 Windows Phone 应用程序传递数据的通道。

Windows Phone 的推送通知有3种不同的类型,分别是原生通知(Raw Notification)、Toast通知(Toast Notification)和磁贴通知(Tile Notification)。这三种通知的表现形式和消息传送的格式各不相同,可以根据应用的具体情况来选择需要的通知形式。

下图展示了推送消息是如何发送的。

  • (1)你的应用程序向推送客户端服务发送一个推送 URI 的请求。
  • (2)推送客户端服务与 Microsoft Push Notification Service 交互,然后 MPNS 向推送客户端服务返回一条通知 URI。
  • (3)推送客户端服务将通知 URI 返回给你的应用程序。
  • (4)你的应用程序将推送 URI 发送到你的云服务中。
  • (5)当你的云服务需要向你的应用程序发送消息的时候,他使用这个通知 URI 向 MPNS 发送一条通知。
  • (6)MPNS 将这条推送通知发送到你的应用程序。

根据推送通知的格式以及附加的有效载荷,该信息以原始数据的形式被发送给应用程序,然后应用程序的图标会被更新,或者显示 Toast 通知。在发送完推送通知之后, MPNS 给你的云服务会返回一个回执码,表示该消息已经被 MPNS 接收并将在何时的时机发送给目标设备。尽管 MPNS 并没有提供端到端的服务来确认你的推送通知已经从你的云服务发送到了你的手机中,如果该条消息不能被发送到设备中,MPNS 会向你的云服务中返回一条错误码。更多关于回执和错误码的信息,请参见 Windows Phone 推送通知服务的响应代码.aspx)。在 MPNS 表明消息无法被传递的时候,你的服务应该在需要的情况下重新提交这条消息。

Reference

  • http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378971.html
  • http://www.cnblogs.com/nokiaguy/p/3304192.html
  • http://segmentfault.com/a/1190000000520755
  • https://www.microsoft.com/china/msdn/x-platform/developing_08.html

LNMP + Apache 架构配置:Nginx 做前端代理 + Apache 做后端服务

发表于 2015-01-17 | 分类于 服务端

前面两篇文章:

  • Win7 下 VMware 虚拟机中安装 CentOS 服务器
  • CentOS 服务器环境搭建:Linux + Apache + MySQL + PHP + Nginx

我们分别介绍了如何在 Win7 虚拟机中安装 CentOS 服务器、如何在本地主机 Win7 中通过 PuTTY “远程”登录虚拟机中的 CentOS 服务器,以及如何在 CentOS 中搭建 LAMP 环境和 LNMP 环境。

本文将介绍如何配置 LNMPA 环境,即用 Nginx 做前端反向代理服务器,接收 HTTP 请求,并处理静态文件(如 js/css/jpg/png/swf/… 等),而把动态脚本 .php/.py 等交给后端的 Apache 解析处理。

Apache 和 Nginx 说是当今最流行的两个 Web 服务器一点也不为过,Apache 用户基数大,稳定,兼容性高(比如 jsp/php/cgi/python 等等),但与 Ngnix 相比,Apache过于臃肿以及对静态文件响应过于缓慢让很多使用者感到头疼,而 Nginx 对于高并发性能出众,Proxy 功能强效率高,占用系统资源少。

但是 Nginx 也有劣势,它在处理 php 脚本时需要通过 php-fpm(FastCGI) 解析,而 php-fpm 不够稳定,经常出现 502 错误,生成相对复杂的页面没有优势,反而会使 php-cgi 进程变为僵尸进程。而 Apache 在高并发时对队列的处理比 FastCGI 更好,并且在处理动态 php 页面时,mod_php 模块也比 php-cgi 模块更稳定更高效。

事实上很多大型的网站都是采用 Nginx 前端 + Apache 后端的服务器架构,这样可以很好地结合了 Nginx 高并发和静态页面高效率以及 Apache 稳定的动态页面处理特点,再也不用担心 Nginx 以 FastCGI 模式运行 PHP 时的502问题和 Apache 处理静态页面过慢、负载过高的问题。

PS:我们都说 Nginx 一个高性能的 HTTP 和反向代理服务器,至于什么是反向代理,对应的正向代理又是什么意思,这篇文章已经讲得很清楚了,这里不再赘述:图解正向代理、反向代理、透明代理。

配置 LNMP + Apache 架构

在上一篇文章中,我们已经在 CentOS 服务器中分别搭建了 LAMP 环境和 LNMP 环境,这里接上文继续进行配置。

打开编辑 Nginx 的默认配置文件:

1
# vi /etc/nginx/conf.d/default.conf

注释掉之前 FastCGI 监听的配置,并添加如下代码:

1
2
3
4
# proxy the PHP scripts to Apache listening on 127.0.0.1:8080
location ~ \.php$ {
proxy_pass http://127.0.0.1:8080
}

即当 Nginx 接收 http 请求遇到需要解析 php 脚本时,则交给 127.0.0.1:8080 端口来处理,而我们等下配置让 Apache 来监听处理这个端口发来的请求。

最终 Nginx 的配置文件 default.conf 如下,此处保留 Nginx 的默认网站目录 /var/share/nginx/html 不变,可自行修改。

接下来打开编辑 Apache 的配置文件:

1
# vi /etc/httpd/conf/httpd.conf

找到 Listen 字段,并改为:Listen 127.0.0.1:8080,让 Apache 来监听这个端口,修改 Apache 的网站根目录为:”/usr/share/nginx/html”,与上述 Nginx 对应的网站目录保持一致,具体的修改细节如下加粗文字所示:

1
2
3
4
5
6
7
8
9
10
Listen 127.0.0.1:8080
...
ServerName localhost
...
DocumentRoot "/usr/share/nginx/html"
...
<Directory "/usr/share/nginx/html">
...
<⁄Directory>
...

保存退出编辑,重启 Nginx 服务,并启动 Apache 服务,并确保这两个服务开机自启:

1
2
3
4
# service nginx restart
# service httpd start
# chkconfig nginx on
# chkconfig httpd on

此时通过浏览器访问 :http://192.168.211.132/phpinfo.php(此处 192.168.211.132 为 CentOS 服务器的 IP,不同机器不同,phpinfo.php 为 PHP 测试脚本,内容为:<? php phpinfo(); ?>,放在网站目录 /usr/share/nginx/html 下)

发现出现 502 Bad Gateway 信息!!!

经查阅相关资料发现是由于开启了 selinux 服务导致的,关闭 selinux 即可。

打开 selinux 配置文件:

1
# vi /etc/selinux/config

将 SELINUX=enforcing 改为 SELINUX=disabled,如下所示:

修改保存后,通过 reboot 命令重启 CentOS 服务器,重新通过浏览器访问:http://192.168.211.132/phpinfo.php,得到如下信息。

借助于谷歌浏览器的工具我们可以发现,当浏览器向服务器发起 http://192.168.211.132/phpinfo.php 这个 HTTP 请求时,是由 Nginx 接收的,当 Nginx 发现需要处理 PHP 脚本时,则通过 127.0.0.1:8080 端口交给 Apache 处理,PHP 的输出信息也显示了 phpinfo.php 脚本正是由 Apache 2.0 Handler 解析处理的。

至此,LNMP + Apache 架构配置完成!

当然,这里只是简单介绍了如何配置让 Nginx 和 Apache 协同工作,在实际的生产环境中,需要详细阅读 Nginx 和 Apache 的配置文档,根据自己的应用需求,进行更加细致而复杂的设置。

Reference

  • http://os.51cto.com/art/201303/386266.htm
  • http://www.freehao123.com/lnmpa/
  • http://z00w00.blog.51cto.com/515114/1031287

CentOS 服务器环境搭建:Linux + Apache + MySQL + PHP + Nginx

发表于 2015-01-17 | 分类于 服务端

通过前一篇文章:Win7 下 VMware 虚拟机中安装 CentOS 服务器,我们得到了一个纯净的 CentOS 6.6 服务器,这里我们来介绍一下如何在 CentOS 上安装 LAMP 环境和 LNMP 环境。

LAMP 环境的搭建

根据前文介绍,通过 PuTTY “远程”登录 CentOS 服务器后,请按照以下命令及配置分别安装:Apache、MySQL、PHP

1、安装 Apache

1
# yum -y install httpd

安装完成后,打开 httpd 的配置文件,

1
# vi /etc/httpd/conf/httpd.conf

把 ServerName 前的 # 去掉,并修改为:ServerName localhost 并保存,启动 httpd:

1
# service httpd start

在 Win 7(主机)中打开浏览器访问:http://192.168.211.132/(该 IP 为服务器的 IP 地址,不同的机器不同,如何获取请详看前文),得到如下 Apache 默认欢迎页:

2、安装 MySQL

1
# yum -y install mysql mysql-server

安装完成后,启动 MySQL:

1
# service mysqld start

接下来开始初始化 MySQL,并按照提示设置 MySQL中的 root 用户的密码及其他配置:

1
# mysql_secure_installation
1
2
3
4
5
6
7
8
9
Enter current password for root (enter for none) (按回车)
Set root password? [Y/n] (输入 Y:回车)
New password: (输入新密码,回车)
Re-enter new password: (再次输入新密码,回车)

Remove anonymous users? [Y/n] (输入 Y:回车)
Disallow root login remotely? [Y/n] (输入 Y:回车)
Remove test database and access to it? [Y/n] (输入 Y:回车)
Reload privilege tables now? [Y/n] (输入 Y:回车)

PS:在第一次启动 MySQL 是,可能会有如下一条警告,提示机器名称不能被反解(resolveip):

解决方法:打开 hosts 文件,

1
# vi /etc/hosts

在 hosts 文件底部添加服务器IP(这里为:192.168.211.132)到机器名(这里为:TestServer)的对应,并保存 hosts 文件。

1
192.168.211.132 TestServer(添加这一行到 hosts 文件底部)

使用 resolveip 确认是否ok:

1
# resolveip TestServer

输出:IP address of TestServer is 192.168.211.132

Reference:http://www.tuicool.com/articles/RZJnim

3、安装 PHP

1
2
# yum -y install php
# yum -y install php-mysql

安装结束后,重启 Apache:

1
# service httpd restart

在 Apache 的默认网站目录添加 phpinfo.php 文件,

1
# vi /var/www/html/phpinfo.php

往 phpinfo.php 里添加如下测试代码:

并保存退出后,在浏览器里访问:http://192.168.211.132/phpinfo.php(此处 IP 同上,为服务器 IP 地址,因机器而异),得到如下信息:

4、设置开机启动项

1
2
# chkconfig httpd on
# chkconfig mysqld on

至此,LAMP 环境安装完成!

安装 Nginx 和 PHP-FPM(FastCGI)

此步骤接上,为了避免冲突,先关闭 Apache:

1
# service httpd stop

默认情况下,CentOS 官方 rpm 源是没有 nginx 安装包的,需要手动添加,

1
2
# cd /etc/yum.repos.d/
# vi nginx.repo

往 nginx.repo 文件里添加如下代码:

1
2
3
4
5
6
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch
gpgcheck=0
enabled=1
保存后,即可开始安装 Nginx,
1
# yum -y install nginx

安装结束后,启动 Nginx,记得先关闭 Apache: service httpd stop,否则会出现冲突,

1
# service nginx start

打开浏览器访问:http://192.168.211.132/,得到如下 Nginx 默认欢迎页:

接下来安装 php-fpm 并启动它,用来解析 PHP 脚本,

1
2
# yum -y install php-fpm
# service php-fpm start

编辑 Nginx 的默认配置文件 default.conf,

1
# vi /etc/nginx/conf.d/default.conf

把 default.conf 文件中 # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 这一行下面的 # 注释去掉,并修改 root 后面的目录为:/usr/share/nginx/html;(此目录为 Nginx 的默认网站目录),修改 SCRIPT_FILENAME 后的参数为:$document_root$fastcgi_script_name; 修改结果如下图所示:

保存退出后,重启 Nginx,

1
# service nginx restart

同样,在 Nginx 的默认网站目录下添加 phpinfo.php 文件,

1
# vi /usr/share/nginx/html/phpinfo.php

往 phpinfo.php 里添加如下测试代码:

并保存退出后,在浏览器里访问:http://192.168.211.132/phpinfo.php,得到如下信息:

注意红框内与上述通过 Apache 解析 phpinfo.php 的区别,此处显示,这里 phpinfo.php 文件是由 FPM/FastCGI 模块解析的。

设置开机启动项

1
2
# chkconfig nginx on
# chkconfig php-fpm on

至此,LNMP 环境安装完成!

Reference

  • http://frozensky.sinaapp.com/centos-6-5-lamp-install/
  • http://www.cnblogs.com/highend/archive/2013/03/06/centos6_3_install_nginx_1_2_7.html

下文将介绍:LNMP + Apache 架构配置:Nginx 做前端代理 + Apache 做后端服务

1…8910
彬彬

彬彬

95 文章
12 分类
0%
© 2015 - 2025 kangzubin.com 京ICP备14046576号-1
Powered by Hexo
,
Theme from NexT.Gemini
本网站由 又拍云 提供 CDN 加速/云存储服务