1. php 的垃圾回收機(jī)制

PHP 可以自動(dòng)進(jìn)行內(nèi)存管理，清除不需要的對(duì)象。

PHP 使用了引用計(jì)數(shù) (reference counting) GC 機(jī)制。

每個(gè)對(duì)象都內(nèi)含一個(gè)引用計(jì)數(shù)器 refcount，每個(gè) reference 連接到對(duì)象，計(jì)數(shù)器加 1。當(dāng) reference 離開(kāi)生存空間或被設(shè)為 NULL，計(jì)數(shù)器減 1。當(dāng)某個(gè)對(duì)象的引用計(jì)數(shù)器為零時(shí)，PHP 知道你將不再需要使用這個(gè)對(duì)象，釋放其所占的內(nèi)存空間。

參考 http://www.php.net/manual/zh/features.gc.refcounting-basics.php

2. session 與 cookie 的區(qū)別和聯(lián)系

區(qū)別：

1. 存放位置：Session 保存在服務(wù)器，Cookie 保存在客戶(hù)端。

2. 存放的形式：Session 是以對(duì)象的形式保存在服務(wù)器，Cookie 以字符串的形式保存在客戶(hù)端。

3. 用途：Cookies 適合做保存用戶(hù)的個(gè)人設(shè)置，愛(ài)好等，Session 適合做客戶(hù)的身份驗(yàn)證

4. 路徑：Session 不能區(qū)分路徑，同一個(gè)用戶(hù)在訪問(wèn)一個(gè)網(wǎng)站期間，所有的 Session 在任何一個(gè)地方都可以訪問(wèn)到。而 Cookie 中如果設(shè)置了路徑參數(shù)，那么同一個(gè)網(wǎng)站中不同路徑下的 Cookie 互相是訪問(wèn)不到的。

5. 安全性：Cookie 不是很安全，別人可以分析存放在本地的 COOKIE 并進(jìn)行 COOKIE 欺騙，考慮到安全應(yīng)當(dāng)使用 session

6. 大小以及數(shù)量限制：每個(gè)域名所煲含的 cookie 數(shù)：IE7/8,FireFox:50 個(gè)，Opera30 個(gè)； Cookie 總大?。篎irefox 和 Safari 允許 cookie 多達(dá) 4097 個(gè)字節(jié)，Opera 允許 cookie 多達(dá) 4096 個(gè)字 節(jié)，InternetExplorer 允許 cookie 多達(dá) 4095 個(gè)字節(jié)；一般認(rèn)為 Session 沒(méi)有大小和數(shù)量限制。

關(guān)系：

1. Session 需要借助 Cookie 才能正常工作。如果客戶(hù)端完全禁止 Cookie，Session 將失效！因?yàn)?Session 是由應(yīng)用服務(wù)器維持的一個(gè) 服務(wù)器端的存儲(chǔ)空間，用戶(hù)在連接服務(wù)器時(shí)，會(huì)由服務(wù)器生成一個(gè)唯一的 SessionID, 用該 SessionID 為標(biāo)識(shí)符來(lái)存取服務(wù)器端的 Session 存儲(chǔ)空間。而 SessionID 這一數(shù)據(jù)則是保存到客戶(hù)端，用 Cookie 保存的，用戶(hù)提交頁(yè)面時(shí)，會(huì)將這一 SessionID 提交到服務(wù)器端，來(lái)存取 Session 數(shù)據(jù)。這一過(guò)程，是不用開(kāi)發(fā)人員干預(yù)的。所以一旦客戶(hù)端禁用 Cookie，那么 Session 也會(huì)失效。

3. 如何修改 SESSION 的生存時(shí)間

1. 設(shè)置瀏覽器保存的 sessionid 失效時(shí)間 setcookie (session_name (), session_id (), time () + $lifeTime, "/");

2. 可以使用 SESSION 自帶的 session_set_cookie_params (86400); 來(lái)設(shè)置 Session 的生存期

3. 通過(guò)修改 php.ini 中的 session.gc_maxlifetime 參數(shù)的值就可以改變 session 的生存時(shí)間

4. PHP 頁(yè)面重定向的方法有哪些

1. header('Location: http://www.baidu.com/') ;

2. echo '';

3 echo '';

5. PDO、adoDB、PHPLib 數(shù)據(jù)庫(kù)抽象層比較

PHP 數(shù)據(jù)庫(kù)抽象層就是指，封裝了數(shù)據(jù)庫(kù)底層操作的介于 PHP 邏輯程序代碼和數(shù)據(jù)庫(kù)之間的中間件。

PDO 以 PHP 5.1 為基礎(chǔ)進(jìn)行設(shè)計(jì)，它使用 C 語(yǔ)言做底層開(kāi)發(fā)，設(shè)計(jì)沿承 PHP 的特點(diǎn)，以簡(jiǎn)潔易用為準(zhǔn)，從嚴(yán)格意義上講，PDO 應(yīng)該歸為 PHP 5 的 SPL 庫(kù)之一，而不應(yīng)該歸于數(shù)據(jù)抽象層，因?yàn)槠浔旧砗?MySQL 和 MySQLi 擴(kuò)展庫(kù)的功能類(lèi)似。PDO 是不適合用在打算或者有可能會(huì)變更數(shù)據(jù)庫(kù)的系 統(tǒng)中的。

ADODB 不管后端數(shù)據(jù)庫(kù)如何，存取數(shù)據(jù)庫(kù)的方式都是一致的；

轉(zhuǎn)移數(shù)據(jù)庫(kù)平臺(tái)時(shí)，程序代碼也不必做太大的更動(dòng)，事實(shí)上只需要改動(dòng)數(shù)據(jù)庫(kù)配置文 件。提供了大量的拼裝方法，目的就是針對(duì)不同的數(shù)據(jù)庫(kù)在抽象層的底層對(duì)這些語(yǔ)句進(jìn)行針對(duì)性的翻譯，以適應(yīng)不同的數(shù)據(jù)庫(kù)方言！但是這個(gè)抽象層似乎體積過(guò)于龐 大了，全部文件大概有 500K 左右，如果你做一個(gè)很小的網(wǎng)站的話，用這個(gè)似乎大材小用了

PHPLib 可能是伴隨 PHP 一同成長(zhǎng)最老的數(shù)據(jù)庫(kù)抽象層（但和 ADODB 相比，它只算是一個(gè) MySQL 抽象類(lèi)庫(kù)），這個(gè)抽象類(lèi)使用方法相當(dāng)簡(jiǎn)單，體積小，是小型網(wǎng)站開(kāi)發(fā)不錯(cuò)的選擇。

PDO 提供預(yù)處理語(yǔ)句查詢(xún)、錯(cuò)誤異常處理、靈活取得查詢(xún)結(jié)果（返回?cái)?shù)組、字符串、對(duì)象、回調(diào)函數(shù)）、字符過(guò)濾防止 SQL 攻擊、事務(wù)處理、存儲(chǔ)過(guò)程。

ADODB 支持 緩存查詢(xún)、移動(dòng)記錄集、（HTML、分頁(yè)、選擇菜單生成）、事務(wù)處理、輸出到文件。 參考 http://apps.hi.baidu.com/share/detail/463678

6. 長(zhǎng)連接、短連接的區(qū)別和使用

長(zhǎng)連接：client 方與 server 方先建立連接，連接建立后不斷開(kāi)，然后再進(jìn)行報(bào)文發(fā)送和接收。這種方式下由于通訊連接一直存在。此種方式常用于 P2P 通信。

短連接：Client 方與 server 每進(jìn)行一次報(bào)文收發(fā)交易時(shí)才進(jìn)行通訊連接，交易完畢后立即斷開(kāi)連接。此方式常用于一點(diǎn)對(duì)多點(diǎn)通訊。C/S 通信。

長(zhǎng)連接與短連接的使用時(shí)機(jī)：

長(zhǎng)連接：

短連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多的情況。每個(gè) TCP 連 接的建立都需要三次握手，每個(gè) TCP 連接的斷開(kāi)要四次握手。如果每次操作都要建立連接然后再操作的話處理速度會(huì)降低，所以每次操作下次操作時(shí)直接發(fā)送數(shù)據(jù) 就可以了，不用再建立 TCP 連接。例如：數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接，如果用短連接頻繁的通信會(huì)造成 socket 錯(cuò)誤，頻繁的 socket 創(chuàng)建也是對(duì)資源的浪 費(fèi)。

短連接：

web 網(wǎng)站的 http 服務(wù)一般都用短連接。因?yàn)殚L(zhǎng)連接對(duì)于服務(wù)器來(lái)說(shuō)要耗費(fèi)一定 的資源。像 web 網(wǎng)站這么頻繁的成千上萬(wàn)甚至上億客戶(hù)端的連接用短連接更省一些資源。試想如果都用長(zhǎng)連接，而且同時(shí)用成千上萬(wàn)的用戶(hù)，每個(gè)用戶(hù)都占有一個(gè) 連接的話，可想而知服務(wù)器的壓力有多大。所以并發(fā)量大，但是每個(gè)用戶(hù)又不需頻繁操作的情況下需要短連接。

參考 http://www.cnblogs.com/Roberts/archive/2010/12/05/1986550.html

7. HTTP 協(xié)議詳解、應(yīng)用

http（超文本傳輸協(xié)議）是一個(gè)基于請(qǐng)求與響應(yīng)模式的、無(wú)狀態(tài)的、短連接、靈活、應(yīng)用層的協(xié)議，?；?TCP 的連接方式。

參考 http://blog.csdn.net/gueter/article/details/1524447 (http 協(xié)議詳解)

(HTTP 響應(yīng)狀態(tài)碼)

HTTP 響應(yīng)狀態(tài)碼

狀態(tài)代碼有三位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類(lèi)別，且有五種可能取值：

1xx：指示信息 -- 表示請(qǐng)求已接收，繼續(xù)處理

2xx：成功 -- 表示請(qǐng)求已被成功接收、理解、接受

3xx：重定向 -- 要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作

4xx：客戶(hù)端錯(cuò)誤 -- 請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)

5xx：服務(wù)器端錯(cuò)誤 -- 服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

常見(jiàn)狀態(tài)代碼、狀態(tài)描述、說(shuō)明：

200 OK // 客戶(hù)端請(qǐng)求成功

400 Bad Request // 客戶(hù)端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解

401 Unauthorized // 請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用 403 Forbidden // 服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)

404 Not Found // 請(qǐng)求資源不存在，eg：輸入了錯(cuò)誤的 URL

500 Internal Server Error // 服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤

503 Server Unavailable // 服務(wù)器超時(shí) // 可能恢復(fù)正常

304 Not Modifed // 自從上次請(qǐng)求后，請(qǐng)求的網(wǎng)頁(yè)未修改過(guò)。

// 服務(wù)器返回此響應(yīng)時(shí)，不會(huì)返回網(wǎng)頁(yè)內(nèi)容。

8. 異構(gòu)系統(tǒng)通訊中的通訊加密方案

參考 http://blog.csdn.net/linvo/article/details/5741942

9. socket 連接步驟

Socket（套接字）概念

套接字（socket）是通信的基石，是支持 TCP/IP 協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)絡(luò)通信過(guò)程中端點(diǎn)的抽象表示，煲含進(jìn)行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議，本地主機(jī)的 IP 地址，本地進(jìn)程的協(xié)議端口，遠(yuǎn)地主機(jī)的 IP 地址，遠(yuǎn)地進(jìn)程的協(xié)議端口。

Socket 連接過(guò)程

建立 Socket 連接至少需要一對(duì)套接字，其中一個(gè)運(yùn)行于客戶(hù)端，稱(chēng)為 ClientSocket ，另一個(gè)運(yùn)行于服務(wù)器端，稱(chēng)為 ServerSocket

套接字之間的連接過(guò)程可以分為三個(gè)步驟：服務(wù)器監(jiān)聽(tīng)，客戶(hù)端請(qǐng)求，連接確認(rèn)。

服務(wù)器監(jiān)聽(tīng)：是服務(wù)器端套接字并不定位具體的客戶(hù)端套接字，而是處于等待連接的狀態(tài)，實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)狀態(tài)。

客戶(hù)端請(qǐng)求：是指由客戶(hù)端的套接字提出連接請(qǐng)求，要連接的目標(biāo)是服務(wù)器端的套接字。為此，客戶(hù)端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號(hào)，然后就向服務(wù)器端套接字提出連接請(qǐng)求。

連接確認(rèn)：是指當(dāng)服務(wù)器端套接字監(jiān)聽(tīng)到或者說(shuō)接收到客戶(hù)端套接字的連接請(qǐng)求，它就響應(yīng)客戶(hù)端

套接字的請(qǐng)求，建立一個(gè)新的線程，把服務(wù)器端套接字的描述發(fā)給客戶(hù)端，一旦客戶(hù)端確認(rèn)了此描述，連接就建立好了。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽(tīng)狀態(tài)，繼續(xù)接收其他客戶(hù)端套接字的連接請(qǐng)求。

10. TCP 協(xié)議，三次握手、四次揮手

TCP 協(xié)議 (Transmission Control Protocol) 是主機(jī)對(duì)主機(jī)層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認(rèn)建立一個(gè)連接，四次揮手?jǐn)嚅_(kāi)連接。

位碼即 tcp 標(biāo)志位，有 6 種標(biāo)示:

SYN (synchronous 建立聯(lián)機(jī)) 同步

ACK (acknowledgement 確認(rèn))

PSH (push 傳送)

FIN (finish 結(jié)束)

RST (reset 重置)

URG (urgent 緊急)

11. php 中常用作用相似，性能差異很大的函數(shù)區(qū)分及舉例

參考 http://apps.hi.baidu.com/share/detail/43169774

12. posix 及 perl 兼容正則比較，及函數(shù)性能分析

POSIX 正則和 PCRE 正則最顯著的需要知道的不同點(diǎn)：

1. PCRE 函數(shù)需要模式以分隔符閉合.

2. POSIX 兼容正則沒(méi)有修正符。不像 POSIX, PCRE 擴(kuò)展沒(méi)有專(zhuān)門(mén)用于大小寫(xiě)不敏感匹配的函數(shù)。取而

代之的是，支持使用 /i 模式修飾符完成同樣的工作。其他模式修飾符同樣可用于改變匹配策略.

1. POSIX 函數(shù)從最左面開(kāi)始尋找最長(zhǎng)的匹配，但是 PCRE 在第一個(gè)合法匹配后停止。如果字符串 不匹

配這沒(méi)有什么區(qū)別，但是如果匹配，兩者在結(jié)果和速度上都會(huì)有差別。為了說(shuō)明這個(gè)不同，考慮下面的例子 (來(lái)自 Jeffrey Friedl 的《精通正則表達(dá)式》一書(shū)). 使用模式 one (self)?(selfsufficient)? 在字符串 oneselfsufficient 上匹配，PCRE 會(huì)匹配到 oneself, 但是使用 POSIX, 結(jié)果將是整個(gè)字符串 oneselfsufficient. 兩個(gè)子串都匹配原始字符串，但是 POSIX 將 最長(zhǎng)的最為結(jié)果.

PCRE 可用的修飾符: (i,s,m)

13. 實(shí)現(xiàn) PERL 正則表達(dá)式，抓取 html 文件 a 標(biāo)簽的所有 href 超鏈接

正則：/<a\s+.*?href='"['" >]/is

$html = <<<HTML

HTML;

$matches = array();

preg_match_all ( "/<a\s+.*?href='"['">]/is", matches ); print_r ($matches [1]); // 輸出所有超鏈接

?>

14. 預(yù)定義變量、魔術(shù)變量、魔術(shù)方法比較，及作用舉例

預(yù)定義變量（超級(jí)全局變量）

$GLOBALS

$_SERVER

$_GET

$_POST

$_COOKIE

$_SESSION

$_REQUEST

$_ENV

魔術(shù)方法 http://apps.hi.baidu.com/share/detail/17851228

construct 和 destruct

__autoload

get 和 set

isset 和 unset

call 和 callStatic

__clone

__toString

sleep 和 wakeup

__invoke

魔術(shù)變量 http://apps.hi.baidu.com/share/detail/17851228

LINE

FILE

DIR

CLASS

FUNCTION

METHOD

NAMESPACE

15. spl 常用數(shù)據(jù)結(jié)構(gòu)類(lèi)

16. PHP 設(shè)計(jì)模式

工廠模式

建立一個(gè)工廠（一個(gè)函數(shù)或一個(gè)類(lèi)方法）來(lái)制造新的對(duì)象

工廠模式 是一種類(lèi)，它具有為您創(chuàng)建對(duì)象的某些方法。您可以使用工廠類(lèi)創(chuàng)建對(duì)象，而不直接使用 new。這樣，如果您想要更改所創(chuàng)建的對(duì)象類(lèi)型，只需更改該工廠即可。使用該工廠的所有代碼會(huì)自動(dòng)更改。

單例模式

某些應(yīng)用程序資源是獨(dú)占的，因?yàn)橛星抑挥幸粋€(gè)此類(lèi)型的資源。例如，通過(guò)數(shù)據(jù)庫(kù)句柄到數(shù)據(jù)庫(kù)的連接是獨(dú)占的。您希望在應(yīng)用程序中共享數(shù)據(jù)庫(kù)句柄，因?yàn)樵诒３诌B接打開(kāi)或關(guān)閉時(shí)，它是一種開(kāi)銷(xiāo)，在獲取單個(gè)頁(yè)面的過(guò)程中更是如此。

單元素模式可以滿(mǎn)足此要求。

PHP 中的單例模式（singleton pattern）：指的是在 PHP 的應(yīng)用程序的范圍內(nèi)只對(duì)指定的類(lèi)創(chuàng)建一個(gè)實(shí)例。

在 PHP 中使用單例模式的類(lèi)通常擁有一個(gè)私有構(gòu)造函數(shù)和一個(gè)私有克隆函數(shù)，以防 止用戶(hù)通過(guò)創(chuàng)建對(duì)象或者克隆對(duì)其進(jìn)行實(shí)例化。還有一個(gè)靜態(tài)私有成員變量 instance 靜態(tài)成員變量中，以確保只有一個(gè)實(shí)例被創(chuàng)建。

觀察者模式

命令鏈模式

策略模式

17. 負(fù)載均衡的 web 應(yīng)用服務(wù)器設(shè)計(jì)，例如 youku

用 PHP 做負(fù)載均衡指南

思考如何應(yīng)對(duì)以下問(wèn)題？ 參考 http://www.examw.com/linux/all/142494/

在 Apache 負(fù)載均衡的情況下，做 PHP 開(kāi)發(fā)如何考慮一下幾方面：

PHP 源文件在服務(wù)器、PHP 文件上傳處理、相關(guān)配置文件、Session 會(huì)話放置、日志放置

Apache 負(fù)載均衡的原則：

參考 http://s456123123b.blog.163.com/blog/static/5632332220101080474642/

輪詢(xún)均衡策略 （輪詢(xún)轉(zhuǎn)發(fā)請(qǐng)求）

按權(quán)重分配均衡策略 （按響應(yīng)數(shù)量轉(zhuǎn)發(fā)請(qǐng)求）

權(quán)重請(qǐng)求響應(yīng)負(fù)載均衡策略 （按響應(yīng)流量轉(zhuǎn)發(fā)請(qǐng)求）

18. 如何優(yōu)化前端性能

1. 頁(yè)面內(nèi)容的優(yōu)化

a) 降低請(qǐng)求數(shù)

合并 css、js 文件，集成 CSS 圖片

b) 減少交互通信量

壓縮技術(shù)：壓縮 css、js 文件，優(yōu)化圖像，減少 cookie 體積；

合理利用緩存：使用外部 js/css 文件，緩存 ajax；

減少不必要的通信量：剔除無(wú)用腳本和樣式、推遲加載內(nèi)容、使用 GET 請(qǐng)求

c) 合理利用 “并行” 盡量避免重定向

慎用 Iframe 樣式表置于頂部 腳本放到樣式后面加載

d) 節(jié)約系統(tǒng)消耗

避免 CSS 表達(dá)式、濾鏡

2. 服務(wù)器的優(yōu)化

a) b)

c)

d)

19. yahoo 的 34 條前端優(yōu)化法則

減少 HTTP 請(qǐng)求、利用 CDN 技術(shù)、 設(shè)置頭文件過(guò)期或者靜態(tài)緩存、Gzip 壓縮、把 CSS 放頂部、 把 JS 放底部、避免 CSS 表達(dá)式、將 JS 和 CSS 外鏈、減少 DNS 查找、減小 JS 和 CSS 的體積、 避免重定向、刪除重復(fù)腳本、 配置 ETags、緩存 Ajax、盡早的釋放緩沖、

用 GET 方式進(jìn)行 AJAX 請(qǐng)求、延遲加載組件、 預(yù)加載組件、減少 DOM 元素?cái)?shù)量、跨域分離組件、

減少 iframe 數(shù)量、不要出現(xiàn) 404 頁(yè)面、減小 Cookie、 對(duì)組件使用無(wú) Cookie 的域名、減少 DOM 的訪問(wèn)次數(shù)、開(kāi)發(fā)靈活的事件處理句柄、使用 <link> 而非 @import、避免過(guò)濾器的使用、優(yōu)化圖片、優(yōu)化 CSS Sprites、 不要在 HTML 中縮放圖片、縮小 favicon. ico 的大小并緩存它、保證組件在 25K 以下、將組件打煲進(jìn)一個(gè)多部分的文檔中

20. 數(shù)據(jù)庫(kù)緩存的基本理論，參考 memcached

什么是 Memcached？

memcached 是高性能的分布式內(nèi)存緩存服務(wù)器。一般的使用目的是，通過(guò)緩存數(shù)據(jù)庫(kù)查詢(xún)結(jié)果，減少數(shù)據(jù)庫(kù)訪問(wèn)次數(shù)，以提高動(dòng)態(tài) Web 應(yīng)用的速度、提高可擴(kuò)展性。

雖然 memcached 使用了同樣的 “Key=>Value” 方式組織數(shù)據(jù)，但是它和共享內(nèi)存、APC 等本地緩存有非常大的區(qū)別。Memcached 是分布式的，也就是說(shuō) 它不是本地的。它基于網(wǎng)絡(luò)連接（當(dāng)然它也可以使用 localhost）方式完成服務(wù)，本身它是一個(gè)獨(dú)立于應(yīng)用的程序或守護(hù)進(jìn)程（Daemon 方式）

PHP 與 Memcached

Memcached 使用 libevent 庫(kù)實(shí)現(xiàn)網(wǎng)絡(luò)連接服務(wù)，理論上可以處理無(wú)限多的連接，但是它和

基于反向代理的 Web 緩存；

基于反向代理的 Web 緩存

23. PHP 安全模式

php 安全模式：safe_mode=on|off

啟用 safe_mode 指令將對(duì)在共享環(huán)境中使用 PHP 時(shí)可能有危險(xiǎn)的語(yǔ)言特性有所限制?？梢詫?safe_mode 是指為布爾值 on 來(lái)啟用，或者設(shè)置為 off 和腳本嘗試訪問(wèn)的文件的 UID，以此作為限制機(jī)制的基礎(chǔ)。如果 UID 相同，則知性腳本；否則，腳本失敗。

當(dāng)啟用安全模式時(shí)，一些限制將生效

1、 所有輸入輸出函數(shù)（例如 fopen ()、file () 和 require ()）的適用會(huì)受到限制，只能用于與調(diào)用這些函數(shù)的

腳本有相同擁有者的文件

2、 如果試圖通過(guò)函數(shù) popen ()、system () 或 exec () 等執(zhí)行腳本，只有當(dāng)腳本位于 safe_mode_exec_dir

配置指令指定的目錄才可能

3、HTTP 驗(yàn)證得到進(jìn)一步加強(qiáng)，因?yàn)轵?yàn)證腳本用于者的 UID 劃入驗(yàn)證領(lǐng)域范圍內(nèi)。此外，當(dāng)啟用安

全模式時(shí)，不會(huì)設(shè)置 PHP_AUTH。

4、如果適用 MySQL 數(shù)據(jù)庫(kù)服務(wù)器，鏈接 MySQL 服務(wù)器所用的用戶(hù)名必須與調(diào)用 mysql_connect ()

的文件擁有者用戶(hù)名相同。

以下是一些和安全模式相關(guān)的配置選項(xiàng)

safe_mode_gid=on|off

safe_mode_include_dir=string

safe_mode_env_vars=string

safe_mode_exec_dir=string

safe_mode_protected_env_vars=string

24. 常見(jiàn)的 web 攻擊方式

常見(jiàn)攻擊

XSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往 Web 頁(yè)面里插入惡意 html 代碼，當(dāng)用戶(hù)瀏覽該頁(yè)之時(shí)，嵌入的惡意 html 代碼會(huì)被執(zhí)行，從而達(dá)到惡意用戶(hù)的特殊 目的。XSS 屬于被動(dòng)式的攻擊，因?yàn)槠浔粍?dòng)且不好利用，所以許多人常呼略其危害性。但是隨著前端技術(shù)的不斷進(jìn)步富客戶(hù)端的應(yīng)用越來(lái)越多，這方面的問(wèn)題越來(lái) 越受關(guān)注。舉個(gè)簡(jiǎn)單例子 ： 假如你現(xiàn)在是 sns 站點(diǎn)上一個(gè)用戶(hù)，發(fā)布信息的功能存在漏洞可以執(zhí)行 js 你在 此刻輸入一個(gè) 惡意腳本，那么當(dāng)前所有看到你新信息的人的瀏覽器都會(huì)執(zhí)行這個(gè)腳本彈出提示框 （很爽吧 彈出廣告 ：）），如果你做一些更為激進(jìn)行為呢 后果難以想象。

CSRF (Cross Site Request Forgery)，跨站點(diǎn)偽造請(qǐng)求。顧名思義就是 通過(guò)偽造連接請(qǐng)求在用戶(hù)不知情的情況下，讓用戶(hù)以自己的身份來(lái)完成攻擊者需要達(dá)到的一些目的。csrf 的攻擊不同于 xss csrf 需要被攻擊者的主動(dòng)行為觸發(fā)。這樣聽(tīng)來(lái)似乎是有 “被釣魚(yú)” 的嫌疑。

多窗口瀏覽器這這方面似乎是有助紂為虐的嫌疑，因?yàn)榇蜷_(kāi)的新窗口是具有當(dāng)前所有 會(huì)話的，如果是單瀏覽器窗口類(lèi)似 ie6 就不會(huì)存在這樣的問(wèn)題，因?yàn)槊總€(gè)窗口都是一個(gè)獨(dú)立的進(jìn)程。舉個(gè)簡(jiǎn)單例子 ： 你正在玩白社會(huì)， 看到有人發(fā)了一個(gè)連接，你點(diǎn)擊過(guò)去，然后這個(gè)連接里面?zhèn)卧炝艘粋€(gè)送禮物的表單，這僅僅是一個(gè)簡(jiǎn)單的例子，問(wèn)題可見(jiàn)一般。

cookie 劫持。通過(guò)獲取頁(yè)面的權(quán)限，在頁(yè)面中寫(xiě)一個(gè)簡(jiǎn)單的到惡意站點(diǎn)的請(qǐng) 求，并攜帶用戶(hù)的 cookie 獲取 cookie 后通過(guò) cookie 就可以直以被盜用戶(hù)的身份登錄站點(diǎn)。這就是 cookie 劫持。舉個(gè)簡(jiǎn)單例子： 某人寫(xiě)了一篇很有意思的日志，然后分享給大家，很多人都點(diǎn)擊查看并且分享了該日志，一切似乎都很正常，然而寫(xiě)日志的人卻另有用心，在日志中偷偷隱藏了一個(gè) 對(duì)站外的請(qǐng)求，那么所有看過(guò)這片日志的人都會(huì)在不知情的情況下把自己的 cookie 發(fā)送給了 某人，那么他可以通過(guò)任意一個(gè)人的 cookie 來(lái)登錄這個(gè)人的賬戶(hù)。

SQL 注入攻擊

在 SQL 注入攻擊 中，用戶(hù)通過(guò)操縱表單或 GET 查詢(xún)字符串，將信息添加到數(shù)據(jù)庫(kù)查詢(xún)中。

DNS 攻擊

拒絕服務(wù)攻擊

拒絕服務(wù)攻擊即攻擊者想辦法讓目標(biāo)機(jī)器停止提供服務(wù)，是黑客常用的攻擊手段之。

攻擊者進(jìn)行拒絕服務(wù)攻擊，實(shí)際上讓服務(wù)器實(shí)現(xiàn)兩種效果：一是迫使服務(wù)器的緩沖區(qū)滿(mǎn)，不接收新的請(qǐng)求；二是使用 IP 欺騙，迫使服務(wù)器把合法用戶(hù)的連接復(fù)位，影響合法用戶(hù)的連接

25. PHP 做好防盜鏈的基本思想 防盜鏈

什么是盜鏈？

盜鏈?zhǔn)侵阜?wù)提供商自己不提供服務(wù)的內(nèi)容，通過(guò)技術(shù)手段繞過(guò)其它有利益的最終用戶(hù)界面 (如廣告)，直接在自己的網(wǎng)站上向最終用戶(hù)提供其它服務(wù)提供商的服務(wù)內(nèi)容，騙取最終用戶(hù)的瀏覽和點(diǎn)擊率。受益者不提供資源或提供很少的資源，而真正的服務(wù)提供商卻得不到任何的收益。

網(wǎng)站盜鏈會(huì)大量消耗被盜鏈網(wǎng)站的帶寬，而真正的點(diǎn)擊率也許會(huì)很小，嚴(yán)重?fù)p害了被盜鏈網(wǎng)站的利益。 如何做防盜鏈？

不定期更名文件或者目錄

限制引用頁(yè)

原理是，服務(wù)器獲取用戶(hù)提交信息的網(wǎng)站地址，然后和真正的服務(wù)端的地址相比較， 如果一致則表明是站內(nèi)提交，或者為自己信任的站點(diǎn)提交，否則視為盜鏈。實(shí)現(xiàn)時(shí)可以使用 HTTP_REFERER1 和 htaccess 文件 (需要啟用 mod_Rewrite)，結(jié)合正則表達(dá)式去匹配用戶(hù)的每一個(gè)訪問(wèn)請(qǐng)求。

文件偽裝

文件偽裝是目前用得最多的一種反盜鏈技術(shù)，一般會(huì)結(jié)合服務(wù)器端動(dòng)態(tài)腳本 (PHP/JSP/ASP)。實(shí)際上用戶(hù)請(qǐng)求的文件地址，只是一個(gè)經(jīng)過(guò)偽裝的腳本文件，這個(gè)腳本文件會(huì)對(duì)用戶(hù)的請(qǐng)求作認(rèn)證，一般會(huì)檢查 Session，Cookie 或 HTTP_REFERER 作為判斷是否為盜鏈的依據(jù)。而真實(shí)的文件實(shí)際隱藏在用戶(hù)不能夠訪問(wèn)的地方，只有用戶(hù)通過(guò)驗(yàn)證以后才會(huì)返回給用戶(hù)

加密認(rèn)證

這種反盜鏈方式，先從客戶(hù)端獲取用戶(hù)信息，然后根據(jù)這個(gè)信息和用戶(hù)請(qǐng)求的文件名 字一起加密成字符串 (Session ID) 作為身份驗(yàn)證。只有當(dāng)認(rèn)證成功以后，服務(wù)端才會(huì)把用戶(hù)需要的文件傳送給客戶(hù)。一般我們會(huì)把加密的 Session ID 作為 URL 參數(shù)的一部分傳遞給服務(wù)器，由于這個(gè) Session ID 和用戶(hù)的信息掛鉤，所以別人就算是盜取了鏈接，該 Session ID 也無(wú)法通過(guò)身份認(rèn)證，從而達(dá)到反盜鏈的目的。這種方式對(duì)于分布式盜鏈非常有效。

隨機(jī)附加碼

每次，在頁(yè)面里生成一個(gè)附加碼，并存在數(shù)據(jù)庫(kù)里，和對(duì)應(yīng)的圖片相關(guān)，訪問(wèn)圖片時(shí)和此附加碼對(duì)比，相同則輸出圖片，否則輸出 404 圖片

加入水印

26. HTTP 請(qǐng)求頭信息和響應(yīng)頭信息

請(qǐng)求頭信息

POST /scp1.1.0/prs/new_rnaseqtask/run_go HTTP/1.1

Host: 172.30.4.102

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0

Accept: /

Accept-Language: zh-cn,zh;q=0.5

Accept-Encoding: gzip, deflate

Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

X-Requested-With: XMLHttpRequest

Referer: http://172.30.4.102/scp1.1.0/index.php/prs/new_rnaseqtask/index_continue/13/364 Content-Length: 1819

Cookie:

ci_session=a%3A4%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%22e31556053ff9407a454f6a1e146d43eb%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%22172.16.23.42%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A50%3A%22Mozilla%2F5.0+%28Windows+NT+6.1%3B+rv%3A6.0%29+Gecko%2F2010010%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1314955607%3B%7D664b51a01ef99bac95f3e2206e79cb00;PHPSESSID=v33mlm1437lmop1fquta675vv4;username=linjinming; tk=1314955601855 Pragma: no-cache

Cache-Control: no-cache

響應(yīng)頭信息

HTTP/1.1 200 OK

Date: Fri, 02 Sep 2011 09:27:07 GMT

Server: Apache/2.2.3 (Red Hat)

X-Powered-By: PHP/5.1.6

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Vary: Accept-Encoding

Content-Encoding: gzip

Content-Length: 31

Connection: close

Content-Type: text/html; charset=UTF-8

27. MySQL

MySQL 數(shù)據(jù)庫(kù)性能優(yōu)化

使用 mysqlreport；

正確使用索引：explain 分析查詢(xún)語(yǔ)句，組合索引，索引副作用（占空間、update）

開(kāi)啟慢查詢(xún)?nèi)罩尽⑹褂寐樵?xún)分析工具 mysqlsla；

索引緩存、索引代價(jià)（插入更新索引）；

表鎖，行鎖，行鎖副作用（update 多時(shí)候變慢），在 select 和 update 混合的情況下，行鎖巧妙解決了讀寫(xiě)互斥的問(wèn)題；

開(kāi)啟使用查詢(xún)緩存；

修改臨時(shí)表內(nèi)存空間；

開(kāi)啟線程池；

MySQL Query 語(yǔ)句優(yōu)化的基本思路和原則

1. 優(yōu)化需要優(yōu)化的 Query；

2. 定位優(yōu)化對(duì)象的性能瓶頸；

3. 明確優(yōu)化目標(biāo)；

4. 從 Explaing 入手；

5. 多使用 Profile；

6. 永遠(yuǎn)用小結(jié)果集推動(dòng)大的結(jié)果集；

7. 盡可能在索引中完成排序；

8. 只取自己需要的 Columns；

9. 僅僅使用最有效的過(guò)濾條件；

10. 盡可能避免復(fù)雜的 Join 和子查詢(xún)。

MySQL 中 MyISAM 引擎和 InnoDB 引擎的區(qū)別以及它們的性能

1：Innodb 支持事物，Myisam 不支持

2：鎖定機(jī)制不一樣，Myisam 支持表鎖定，而 Innodb 支持行鎖

3：Myisam 不支持外鍵，Innodb 能支持

4：Myisam 能在特定環(huán)境下支持全文索引，而 Innodb 不支持

5：Myisam 支持?jǐn)?shù)據(jù)壓縮，Innodb 不支持

6：在數(shù)據(jù)存儲(chǔ)上，Myisam 占用的空間少，Innodb 相對(duì)多些

7：Myisam 在批量插入和查詢(xún)方面速度上有優(yōu)勢(shì)，而 Innodb 由于支持行鎖，所以在數(shù)據(jù)修改方面更勝一籌

MySQL 存儲(chǔ)引擎

MyISAM：不支持事務(wù)、表鎖和全文索引，操作速度快

InnoDB：行鎖設(shè)計(jì)、支持外鍵、支持安全事務(wù)

HEAP：數(shù)據(jù)存放在內(nèi)存中，臨時(shí)表

NDB Cluster：MySQL 的簇式數(shù)據(jù)庫(kù)引擎

CSV: 存儲(chǔ)引擎把數(shù)據(jù)以逗號(hào)分隔的格式存儲(chǔ)在文本文件中。

FEDERATED：存儲(chǔ)引擎表并不存放數(shù)據(jù)，它只是指向一臺(tái)遠(yuǎn)程 MySQL 數(shù)據(jù)庫(kù)服務(wù)器上的表 Archive: 只支持 INSERT 和 SELECT 操作，壓縮后存儲(chǔ)，非常適合存儲(chǔ)歸檔數(shù)據(jù)

Merge：允許將一系列等同的 MyISAM 表以邏輯方式組合在一起，并作為 1 個(gè)對(duì)象引用它們 表類(lèi)型，區(qū)分表類(lèi)型

優(yōu)化表設(shè)計(jì)的常用思路

負(fù)載均衡的數(shù)據(jù)庫(kù)設(shè)計(jì)

數(shù)據(jù)類(lèi)型及詳細(xì)定義，區(qū)分

28. Apache

性能優(yōu)化，配置，fastCGI 等幾種工作模式

29. Ajax

用 JS 實(shí)現(xiàn) Ajax 功能

var createXHR = function(){
 
}
 
var addURLParam = function(url, name, value){
 
}
 
var xhr = createXHR();
 
xhr.onreadystatechange = function(){
 
}
 
var url = 'testAjax.php';
 
addURLParam(url, 'name', 'linjm');
 
xhr.open('get',url,true);
 
xhr.send(NULL);
 
if(xhr.readyState == 4){    } if(xhr.status > 200 && xhr.status < 300 || xhr.status == 304){  } alert(xhr.responseText); url += (url.indexOf('?') == -1 ? '?' : '&'); url += encodeURIComponent(name) + '=' + encodeURIComponent(value); return url; if(window.XMLHttpRequest){    } return new XMLHttpRequest(); return new ActiveXObject('Microsoft.XMLHTTP'); throw new Error('No XMLHttpRequest available'); }else{ }else{}

30. Javascript

變量、作用域、作用域鏈