问题描述
我将APC用于操作码，与4-cpu许可证Litespeed相提并论.就性能而言，然后是安全性而言，针对这种情况的最佳PHP处理程序是什么?
I utilize APC for opcode in par with 4-cpu license Litespeed.What is the best PHP handler for this situation in term of performance first, and security later?
是suphp/dso/fcgi/cgi吗? (我读到，如果其中一个脚本存在错误，DSO可能会留下漏洞)?
Is it suphp / dso / fcgi / cgi ? (i read that DSO can leave a hole if one of the script has a bug) ?
myusername@mybox [~]# /usr/local/cpanel/bin/rebuild_phpconf --available
Available handlers: suphp dso fcgi cgi none
PHP4 SAPI: cgi
PHP5 SAPI: not installed
SUEXEC: available
RUID2: not available
谢谢.
推荐答案
在Servint博客上有一篇很棒的文章:
There is a great article on this on Servint Blog: http://blog.servint.net/2011/10/28/the-tech-bench-all-about-php-handlers/
请务必访问该网站，该网站还提供比较表.
Be sure to visit there site it also has comparison charts.
PHP处理程序列表
DSO
也称为mod_php.虽然这是一个较旧的配置，但其主要优点是速度.通常认为它是最快的处理程序.它直接从Apache运行PHP，而不必将其传递给单独的服务进行处理.这意味着PHP脚本将以Apache用户身份运行，在我们的服务器上，默认情况下该用户为"nobody"用户.
Also known as mod_php. While this is an older configuration, its main benefit is speed. It is generally considered the fastest handler. It runs PHP directly from Apache, without having to pass it to a separate service for processing. This means that PHP scripts will run as the Apache user, which by default on our servers is the user ‘nobody’.
在切换到DSO之前，有两点要考虑.首先，任何需要由网络服务器写入的文件都必须具有"nobody"用户的写入权限，并且由网络服务器创建的任何文件都将归"nobody"所有.需要通过PHP上传文件的网站可能会遇到权限问题，因为这些设置没有其他处理程序那么明确.对于通过WordPress界面上传文件或使用自动更新功能的WordPress用户，这很常见.
DSO has two things to consider before switching to it. First, any files that need to be written to by the webserver have to have write permissions for the ‘nobody’ user, and any file created by the webserver will be owned by ‘nobody’. Websites that need to upload files through PHP may run into permissions issues, since the settings aren’t as clear cut as the other handlers. This is common with WordPress users that upload files through the WordPress interface or utilize the auto-update feature.
关于上述内容的特别说明:常见的误解是文件必须具有777模式才能写入.这是不正确的，并且通常是一个坏主意，因为这意味着文件可以被任何人写入.为了使文件可被网络服务器写入，所需的最高权限应为664，并由用户"和无人"组拥有.对于目录，这将是775，而user:nobody.这应该足以允许Web服务器写入该位置，而又不使其所有人都能写入，并引入潜在的严重安全漏洞.
A special note about the above: it is a common misconception that files need to have the 777 mode to be writable. This is not true, and generally a bad idea since it means the files are writable by anyone. To make a file writable by the webserver, the highest permissions needed should be 664 and owned by ‘user’ and group ‘nobody’. For directories this would be 775 and user:nobody. This should be enough to allow the webserver to write to the location without making it writable by everyone and introducing a potentially critical security vulnerability.
另外，要知道DSO提供了不同于suPHP/FastCGI的另一种类型的安全性.由于服务器以无人"身份运行，因此任何能够利用服务器上的文件获得更高特权的人都可以访问网络服务器可以直接访问的任何其他文件.这只是意味着入侵者可以访问多个帐户中的文件，但只能访问没人"拥有的文件.有关更多信息，请参见下面的安全性"部分.
Also, know that DSO offers a different type of security as opposed to suPHP/FastCGI. Since the server runs it as ‘nobody’ anyone that would be able to exploit a file on your server to gain elevated privileges will have access to any other file that the webserver can directly access. What this simply means is that an intruder could have access to files across multiple accounts, but only those files that are owned by ‘nobody’. Please see the Security section below for more information.
DSO的主要优点是速度和资源使用率.安装了eAccelerator或APC等操作码缓存扩展后，DSO的运行速度将大大加快，并且占用的空间也将比其他处理程序少.这也是我们服务器上的默认设置.
The main advantage of DSO is speed and resource usage. With opcode caching extensions like eAccelerator or APC installed, DSO will run significantly faster and at a lower footprint than the other handlers. It is also the default setting on our servers.
一个很好的经验法则是，DSO最适合运行一个或两个大型网站的服务器，而这些网站都关注效率和速度.
A good rule of thumb is that DSO is best for servers that are running one or two large, high-performance websites where efficiency and speed are a concern.
CGI
CGI处理程序将PHP作为CGI模块而不是Apache模块运行.当DSO不可用时，CGI方法可用作后备处理程序.无论是否启用suEXEC，此方法都不快速也不安全.因此，ServInt不建议使用CGI.
CGI handler will run PHP as a CGI module as opposed to an Apache module. The CGI method is intended as a fallback handler for when DSO is not available. This method is neither fast nor secure, regardless of whether or not suEXEC is enabled. ServInt therefore does not recommend using CGI.
suPHP
suPHP将PHP作为单独的服务运行，然后将已编译的代码传递回Apache进行服务.从技术上讲，它是一个CGI模块，但是与上面提到的CGI处理程序有很大不同.拥有suPHP的主要区别和优点在于，启用suEXEC后，它将以调用脚本的用户身份而不是以"nobody"用户身份运行PHP脚本.例如，如果一个帐户归Spock用户所有，则为该用户的网站提供服务的所有Apache实例都将以Spock用户身份运行.这样做的好处是，它使使用过多资源的网站跟踪变得更加容易.
suPHP runs PHP as a separate service that then passes the compiled code back to Apache for serving. It is technically a CGI module, however it is much different than the CGI handler mentioned above. The main difference, and the advantage of having suPHP, is that with suEXEC enabled it runs the PHP scripts as the user calling them, rather than as the ‘nobody’ user. For example, if an account is owned by the user Spock, all instances of Apache serving that user’s website will run as user Spock. The advantage here is that it makes tracking down websites using excessive resources easier.
以用户身份运行该流程的另一个优点是，它简化了总体权限方案.网络服务器将能够写入用户拥有的文件，而不仅仅是没人".从长远来看，这意味着许多CMS解决方案中的自动更新/安装功能将更容易使用，并且文件/目录的一般权限更加明确:644，由文件的用户和组用户拥有，以及类似755和user:user的目录.
Another advantage of running the process as the user is that it simplifies the overall permissions scheme. The webserver will be able to write to files that are owned by the user and not just ‘nobody’. What this means in the long run is that auto-update/install features in many CMS solutions will work more easily, and the general permissions of your file/directories is more clear-cut: 644 and owned by user and group user for files, and similarly 755 and user:user for directories.
suPHP和DSO之间的安全性区别在于suPHP将入侵者限制在他/她受影响的特定用户身上.该漏洞利用程序无法跨帐户使用，但是会影响用户拥有的每个文件，而不仅仅是网络服务器可写的文件.有关更多信息，请参见下面的安全性"部分.
The security difference between suPHP and DSO is that suPHP confines an intruder to the particular user that he/she has affected. The exploit can’t cross accounts, however it can affect every single file the user owns as opposed to just the files writable by the webserver. Please see the Security section below for more information.
suPHP的主要缺点是速度和CPU负载. suPHP的运行速度比其他处理程序慢得多，切换到该处理程序后，您会发现总体CPU负载显着增加. suPHP也不能与诸如eAccelerator或APC之类的操作码缓存扩展一起使用，这是CPU使用率增加的部分原因.因此，如果将其与CMS一起使用，则建议您实现一个缓存插件，例如WordPress的W3-Total-Cache.对于较小的转销商客户端，建议更多使用此处理程序.这是因为它可以将漏洞利用锁定在一个受影响的帐户上，并且在站点较少繁忙或单个cPanel帐户较少的情况下，CPU负载的增长就不会那么明显.
The main disadvantage of suPHP is speed and CPU load. suPHP runs much slower than the other handlers, and you will see significant increase in your overall CPU load when switched to it. suPHP also cannot work with an opcode caching extension such as eAccelerator or APC, which is part of the reason for the increase in CPU usage. Because of this, it is recommended that you implement a caching plugin if you use this with a CMS, such as W3-Total-Cache for WordPress. This handler is recommended more for the smaller reseller client. This is because it locks down exploits to one affected account, and the CPU load increase will not be that significant with less busy sites or small number of individual cPanel accounts.
FastCGI
FastCGI(又称mod_fcgid)与suPHP相似，因为它是一个独立的过程，可编译PHP，然后将其发送回Apache.它也是一个CGI模块，这意味着在启用suEXEC的情况下，PHP以用户身份运行该进程.这使您具有上述suPHP相同的权限优势.但是，两者之间的区别在于它们如何控制PHP进程. suPHP每次需要编译PHP进程时都会运行，而FastCGI则使持久性连接保持打开状态，而同一PHP进程可以调用该持久性连接.这样一来，您便可以使用eAcceleartor或APC等操作码缓存扩展来提高性能.
FastCGI (aka: mod_fcgid) is similar to suPHP in that it is a separate process that compiles the PHP which is then sent back to Apache. It is also a CGI module, which means with suEXEC enabled PHP runs the process as the user. This allows you the same permissions advantages of suPHP mentioned above. The difference between the two, however, is how they control the PHP processes. suPHP runs each time a PHP process needs to be compiled, whereas FastCGI keeps persistent connections open that can be recalled by the same PHP process. This allows you to use an opcode caching extension such as eAcceleartor or APC with it to increase performance.
缺点是FastCGI具有很高的内存使用率.由于上述持久性连接存储在内存中，因此您将看到FastCGI占用了更多的可用内存.
The drawback is FastCGI has a high memory usage. Due to the persistent connections mentioned above being stored in memory, you are going to see much more available memory being taken up by FastCGI.
FastCGI和suPHP的一个很好的类比是想一本有几章的书.使用suPHP，这本书将没有目录，也没有索引，因此，每当您想查找某些内容时，都必须仔细阅读才能获得该书.这需要时间(CPU使用率增加)并且很慢.借助FastCGI，这本书具有广泛的索引和目录，因此您可以快速轻松地找到所需内容.但是，这些额外的页面使书变得更厚(增加了内存使用量).
A good analogy of FastCGI and suPHP is to think of a book with several chapters. With suPHP, this book will have no table of contents and no index, so each time you want to find something you have to look through the book to get it. This takes time (increased CPU usage) and is slow. With FastCGI, this book has an extensive index and table of contents, so you can quickly and easily find what you are looking for; however these additional pages make the book much thicker (increased memory usage).
这篇关于什么是APC的最佳PHP处理程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！