PHPWeb開發相關知識

轉載：https://blog.csdn.net/wj610671226/article/details/78426698

正則表達式

做用：分割、查找、匹配、替換字符串
分割符：正斜線（/）、hash符號(#)以及取反符號(~)
通用原子：
\d: 匹配一個數字字符。等價於 [0-9]。
\D: 匹配一個非數字字符。等價於 [^0-9]。
\w: 匹配包括下劃線的任何單詞字符。等價於'[A-Za-z0-9_]'。
\W: 匹配任何非單詞字符。等價於 '[^A-Za-z0-9_]'。
\s: 匹配任何空白字符，包括空格、製表符、換頁符等等。等價於 [ \f\n\r\t\v]。
\S: 匹配任何非空白字符。等價於 [^ \f\n\r\t\v]。

元字符：
. : 匹配除 "\n" 以外的任何單個字符。要匹配包括 '\n' 在內的任何字符，請使用像"(.|\n)"的模式。
* : 匹配前面的子表達式零次或屢次。例如，zo* 能匹配 "z" 以及 "zoo"。* 等價於{0,}。
? : 匹配前面的子表達式零次或一次。例如，"do(es)?" 能夠匹配 "do" 或 "does"
$ : 匹配輸入字符串的結束位置
+ : 匹配前面的子表達式一次或屢次。例如，'zo+' 能匹配 "zo" 以及 "zoo"，但不能匹配 "z"。+ 等價於 {1,}。
{n} : n 是一個非負整數。匹配肯定的 n 次。例如，'o{2}' 不能匹配 "Bob" 中的 'o'，可是能匹配 "food" 中的兩個 o。
{n,}: n 是一個非負整數。至少匹配 n 次。例如，'o{2,}' 不能匹配 "Bob" 中的 'o'，但能匹配 "foooood" 中的全部 o。'o{1,}' 等價於 'o+'。'o{0,}' 則等價於 'o*'。
{n,m}: m 和 n 均爲非負整數，其中n <= m。最少匹配 n 次且最多匹配 m 次。例如，"o{1,3}" 將匹配 "fooooood" 中的前三個 o。'o{0,1}' 等價於 'o?'。請注意在逗號和兩個數之間不能有空格。
[] () [^] | [-]

　　

中文匹配：UTF-8漢字編碼的範圍是0x4e00-0x9fa5,在ANSI(gb2312)環境下，0xb0-0xf7,0xa1-0xfe
正則表達式PCRE函數：preg_match()、preg_match_all()、preg_replace()、preg_split()

魔術方法
__construct() 構造方法
__destruct() 析構方法
__call() 在對象中調用一個不可訪問或者不存在的方法時，__call() 會被調用
__callStatic() 在靜態上下文中調用一個不可訪問方法時，__callStatic() 會被調用
__get() 讀取不可訪問屬性的值時，__get() 會被調用
__set() 在給不可訪問屬性賦值時，__set() 會被調用
__isset() 當對不可訪問屬性調用 isset() 或 empty() 時，__isset() 會被調用
__unset() 當對不可訪問屬性調用 unset() 時，__unset() 會被調用
__toString() echo輸出一個對象會調用
__clone() 克隆一個對象
1
2
3
4
5
6
7
8
9
10
11
網絡
常見狀態碼：200 204 206 301 302 303 304 307 400 401 403 404 500 503的含義
OSI七層模型：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層
物理層：創建、維護、斷開物理鏈接
數據鏈路層：創建邏輯鏈接、進行硬件地址尋址、差錯校驗等功能
網絡層：進行邏輯地址尋址，實現不一樣網絡之間的路徑選擇
傳輸層：定義傳輸數據的協議端口號，以及流控和差錯校驗，協議有TCP UDP,數據包一旦離開網卡即進入網絡傳輸層
會話層：創建、管理、終止會話
表示層：數據的表示、安全、壓縮
應用層：網絡服務與最終用戶的一個接口，協議有：HTTP FTP TFTP SMTP SNMP DNS HTTPS POP3 DHCP

HTTP請求有三部分組成：請求行、消息報文、請求正文。
請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議版本
如：Method Request-URI HTTP-Version CRUF
Method：請求方法
Request-URI：一個統一資源標識符
HTTP-Version：請求的HTTP協議版本
CRLF：回車和換行

HTTP響應由狀態行、消息報文、響應正文組成
狀態行格式以下：
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version：服務器http協議版本
Status-Code ：服務器返回的響應狀態碼
Reason-Phrase：狀態代碼的文本描述

HTTP協議的工做特色和工做原理
工做特色：基於B/S模式，通訊開銷小、簡單快速、傳輸成本低，使用靈活、可以使用超文本傳輸協議，節省傳輸時間，無狀態
工做原理：客戶端發送請求給服務器，建立一個TCP鏈接，指定端口號，默認80，鏈接到服務器，服務器監聽瀏覽器請求，一旦監聽到客戶端請求，分析請求類型後，服務器向客戶端返回狀態信息和數據內容

HTTP協議常見請求/響應頭
Content-Type、Accept、Origin、Cookie、Cache-Control、User-Agent、Referrer、X-Forwarded-For、Access-Control-Allow-Origin、Last-Modified
Host: 請求資源的主機和端口號
User Agent: 發出請求的用戶信息，辨別客戶端所用設備的重要依據
Accept: 告訴服務器能夠接受的文件格式
Cache Control:指定請求和響應遵循的緩存機制
Referer: 頭域容許客戶端指定請求URL的資源地址
Content Length：內容長度
Content Range：響應資源範圍
Content Encoding:指定所能接收的編碼方式

HTTP協議常見請求/響應頭
Content-Type、Accept、Origin、Cookie、Cache-Control、User-Agent、Referrer、X-Forwarded-For、Access-Control-Allow-Origin、Last-Modified

HTTP協議的請求方法
GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE

HTTPS的工做原理
HTTPS是一種基於SSL/TLS的HTTP協議，全部的HTTP數據都是在SSL/TLS協議封裝之上傳輸的。
HTTPS協議在HTTP協議的基礎上，添加了SSL/TLS握手以及數據加密傳輸，也屬於應用層協議

常見網絡協議含義及端口
FTP、Telnet、SMTP、POP三、HTTP、DNS

數據庫
InnoDB表引擎
默認事務型引擎，最重要最普遍的存儲引擎，性能很是優秀。數據存儲在共享表空間，能夠經過配置分開。對主鍵查詢的性能高於其餘類型的存儲引擎。內部作了不少優化，從磁盤讀取數據時自動在內存構建hash索引，插入數據時自動構建插入緩衝區

經過一些機制和工具支持真正的熱備份，支持崩潰後的安全恢復，支持行級鎖，支持外鍵
MyISAM表引擎
5.1版本前，MyISAM是默認的存儲引擎，擁有全文索引、壓縮、空間函數。不支持事務和行級鎖，不支持奔潰後的安全恢復。表存儲在兩個文件，MYD和MYI。設計簡單，某些場景下性能很好

其餘的表引擎
Archive、Blackhole、CVS、Memory

索引對性能的影響
大大減小服務器須要掃描的數據量，幫助服務器避免排序和臨時表、將隨機I/O變順序I/O，大大提升查詢速度，下降寫的速度、佔用磁盤

索引的使用場景
對於很是小的表，大部分狀況下全表掃描效率更高。中到大型表，索引很是有效。特大型的表，創建和使用索引的代價隨之增加，可使用分區技術來解決

索引的類型
普通索引：最基本的索引，沒有任何約束限制
惟一索引：與普通索引相似，可是具備惟一性約束
主鍵索引：特殊的惟一索引，不容許有空值
組合索引：將多個列組合在一塊兒建立索引，能夠覆蓋多個列
外鍵索引：只有InnoDB類型的表纔可使用外鍵索引，保證數據的一致性、完整性和實現級聯操做
全文索引：MySQL自帶的全文索引只能用於MyISAM，而且只能對英文進行全文索引
一個表只能有一個主鍵索引，能夠有多個惟一索引。主鍵索引必定是惟一索引，惟一索引不是主鍵索引。主鍵能夠與外鍵構成參照完整性約束，防止數據不一致

MySQL索引的建立原則
一、最適合索引的列是在where子句中的列，或鏈接子句中的列而不是出如今select關鍵字後的列
二、索引列的基數越大。索引的效果越好
三、對字符串進行索引，應該制定一個前綴長度，能夠節省大量的索引空間
四、根據狀況建立複合索引，複合索引能夠提升查詢效率
五、避免建立過多索引，索引會額外佔用磁盤空間，下降寫操做效率
六、主鍵儘量選擇短的數據類型，能夠有效減小索引的磁盤佔用提升查詢效率

MySQL索引的注意事項
一、複合索引遵循前綴原則
二、like查詢。%不能在前，可使用全文索引
三、column is null可使用索引
四、若是MySQL估計使用索引比全表掃描更慢，會放棄使用索引
五、若是or前的條件中的列有索引，後面的沒有，索引都不會被用到
六、列類型是字符串，查詢時必定要給值加引號，不然索引失效

查找分析SQL查詢慢的緣由
一、記錄慢查詢日誌：分析查詢日誌，不要直接打開查詢日誌進行分析，這樣比較浪費時間和精力，可使用pt-query-digest工具進行分析
二、使用show profile: set profiling=1;開啓，服務器上執行的全部語句會檢測消耗的時間，存到臨時表中（show profiles；show profiles for query 臨時表ID）
三、使用show status: show status 會返回一些計數器，show global status 查看服務器級別的全部計數；有時根據這些計數，能夠猜想出哪些操做代價較高或者消耗時間多
四、使用show processlist 觀察是否有大量線程處於不正常的狀態
五、使用explain:分析單條SQL語句

優化查詢過程當中的數據訪問
訪問數據太多致使查詢性能降低
一、肯定應用程序是否在檢索大量超過須要的數據，多是太多行或列
二、確認MYSQL服務器是否在分析大量沒必要要的數據行
避免使用以下SQL語句
一、查詢不須要額記錄，使用limit解決
二、多表關聯返回所有列，指定A.id,B.age
三、老是取出所有列，SELECT * 會讓優化器沒法完成索引覆蓋掃描的優化
是否在掃描額外的記錄
使用explain來進行，若是發現查詢須要掃描大量數據但只返回少數的行，能夠經過以下技巧去優化：使用索引覆蓋掃描，把全部用的列都放到索引中，這樣存儲引擎不須要回表獲取對應行就能夠返回結果
改變數據庫和表的結構，修改數據表範式（冗餘）。重寫SQL語句，讓優化器能夠以更優的方式執行查詢

優化長難的查詢語句
一、一個複雜查詢仍是多個簡單查詢
MYSQL內部每秒能掃描內存中上百萬行數據，相比之下，響應數據給客戶端就要慢得多
使用盡量少的查詢是好的，可是有時將一個大的查詢分解爲多個小的查詢時頗有必要的
二、切分查詢
將一個大的查詢分爲多個小的相同的查詢
一次性刪除1000萬的數據要比一次刪除一萬，暫停一會的方案更加耗損服務器開銷
三、分解關聯查詢
能夠將一條關聯語句分解成多條SQL來執行，讓緩存的效率更高，執行單個查詢能夠減小鎖的競爭，在應用層作關聯能夠更容易對數據庫進行拆分

優化特定類型的查詢語句
優化count()查詢
count( * )中*會忽略全部的列，直接統計全部列數，所以不要使用count(列名)
MyISAM中，沒有任何where條件的count( * )很是快
當有where條件，MyISAM的count統計不必定比其餘表引擎快
優化關聯查詢
肯定on或者using子語句的列上有索引
確保group by和order by中只有一個表中的列，這樣MySQL纔有可能使用索引
優化group by 和distinct
這兩種查詢都可使用索引來優化，是最有效的優化方法
關聯查詢中，使用標識列進行分組的效率會更高
若是不須要order by,進行group by時使用order by null，MySQL不會再進行文件排序

分區表的原理
工做原理：對用戶而言，分區表是一個獨立的邏輯表，可是底層MySQL將其分紅了多個物理子表，這對用戶來講是透明的，每個分區表都會使用一個獨立的表文件。
建立表時使用partition by子句定義每一個分區存放的數據，執行查詢時，優化器會根據分區定義過濾那些沒有咱們須要數據的分區，這樣查詢只須要所需數據在的分區便可
分區的主要目的是將數據按照一個較粗的粒度分在不一樣的表中，這樣能夠將相關的數據存放在一塊兒，並且若是想一次性刪除整個分區的數據也很方便

適用場景
一、表很是大，沒法所有存在內存或者只在表最後有熱點數據，其餘都是歷史數據
二、分區表的數據更易維護，能夠對獨立的分區進行獨立的操做
三、分區表的數據能夠再不一樣的機器上，從而高效適用資源
四、可使用分區表來避免某些特殊的瓶頸
五、能夠備份和恢復獨立的分區

限制
一、一個表最多隻能有1024個分區
二、5.1版本中，分區表表達式必須是整數，5.5可使用列分區
三、分區字段中若是有主鍵和惟一索引列，那麼主鍵列和惟一列都必須包含進來
四、分區表中沒法使用外鍵約束
五、須要對現有表的結構進行修改
六、全部分區都必須使用相同的存儲引擎
七、分區函數中可使用的函數和表達式會有一些限制
八、某些存儲引擎不支持分區
九、對於MyISAM的分區表，不能使用load index into cache
十、對於MyISAM表，使用分區表時須要打開更多的文件描述

水平分表缺點
一、給應用增長複雜度，一般查詢時須要多個表名，查詢全部數據都需union操做
二、在許多數據庫應用中，這種複雜性會超過它帶來的優勢，查詢時會增長讀一個索引層的磁盤次數
使用場景
1.若是一個表中某些列經常使用，而另一些列不經常使用
2.可使數據行變小，一個數據頁能存儲更多數據，查詢時減小I/O次數

SQL查詢的安全方案
一、使用預處理語句防SQL注入
二、寫入數據庫的數據要進行特殊字符的轉義
三、查詢錯誤信息不要返回給用戶，將錯誤記錄到日誌
MySQL的其餘安全設置
一、按期作數據備份
二、不給查詢用戶root權限，合理分配權限
三、關閉遠程訪問數據庫權限
四、修改root口令，不用默認口令，使用較複雜的口令
五、刪除多餘的用戶
六、改變root用戶的名稱
七、限制通常用戶瀏覽其餘庫
八、限制用戶對數據文件的訪問權限

單一入口的工做原理
工做原理：用一個處理程序文件處理全部的HTTP請求，根據請求時的參數的不一樣區分不一樣模塊和操做的請求
優點：能夠進行統一的安全性檢查，集中處理程序
劣勢：URL不美觀,處理效率會稍低

常見模板引擎
PHP是一種HTML內嵌式的在服務端執行的腳本語言，可是PHP有不少可使PHP代碼和HTML代碼分開的模板引擎：Smary、Twig、Haml、Liquid等
模板引擎的工做原理：龐大的完善的正則表達式替換庫

PHP框架的差別和優缺點
Yaf框架
Yaf使用PHP擴展的形式寫的一個PHP框架，也就是以C語言爲底層編寫的，性能上要比PHP代碼寫的框架要快一個數量級
優勢：執行效率高、輕量級框架、可擴展性強
缺點：高版本兼容性差，底層代碼可讀性差，須要安裝擴展、功能單一，開發須要編寫大量的插件
Yii2框架
Yii2是一款很是優秀的通用Web後端框架，結構簡單優雅、實用功能豐富、擴展性強、性能高是它最突出的優勢。
缺點：學習成本高

時間複雜度和空間複雜度
時間複雜度：執行算法所須要的計算工做量。通常來講，計算機算法是問題規模n的函數f(n),算法的時間複雜度就是T(n)=O(f(n))。問題的規模n越大，算法執行的時間的增加率f(n)的增加率正相關，稱做漸進時間複雜度。
時間複雜度的計算方式：得出算法的計算次數公式；用常數1來取代全部時間中的全部加法常數；在修改後的運行次數函數中，只保留最高階項；若是最高階存在且不是1，則去除與這個項相乘的常數。
常見時間複雜度：常數階、線性階、平方階、立方階、對數階、nlog2n階、指數階
O(1)>O(log2n)>O(n)>O(nlog2n)>O(n^2)>O(n^3)>O(2^n)>O(n!)>O(n^n)

空間複雜度
算法須要消耗的內存空間，記做：S(n)=O(f(n))
包括程序代碼所佔用的空間，輸入數據所佔用的空間和輔助變量所佔的空間這三方面
計算和表示方法和時間複雜度相似，通常用複雜度的漸進性來表示

排序算法
冒泡排序、直接插入排序、希爾排序、選擇排序、快速排序、堆排序、歸併排序

冒泡排序：兩兩相鄰的數進行比較，若是反序就交換，不然不交換
時間複雜度：最壞(O(n^2)),平均(O(n^2))
空間複雜度：O(1)

直接插入排序
原理：每次從無序表中取出第一個元素，把它插入到有序表的合適位置，使有序表仍然有序
時間複雜度：最壞(O(n^2)),平均(O(n^2))
空間複雜度：O(1)

希爾排序
原理：把待排序的數據根據增量分紅幾個序列，對子序列進行插入排序，直至增量爲1，直接進行插入排序；增量的排序，通常是數組的長度的一半，再變爲原來增量的一半，直到增量爲1
時間複雜度：最差(O(n^2)),平均(O(n*log2n))
空間複雜度：O(1)

選擇排序
原理：每次從待排序的數據元素中選出最小(或最大)的一個元素，存放在序列的起始位置，直到所有待排序的數據元素排完
時間複雜度：最壞(O(n^2)),平均(O(n^2))
空間複雜度：O(1)

快速排序
原理：經過一趟排序將要排序的數據分割成獨立的兩部分，其中一部分的全部數據都比另一部分的全部數據都要小，而後再按照此方法對這兩部分數據分別進行快速排序，整個排序過程能夠遞歸完成
時間複雜度：最差(O(n^2)),平均(O(nlog2n))

堆排序
原理：把待排序的元素按照大小在二叉樹位置上排序，排序好的元素要知足：父節點的元素要大於等於子節點；這個過程叫作堆化過程，若是根節點存放的是最大的數，則叫作大根堆，若是是最小，就叫小根堆，能夠把根節點拿出來，而後再堆化，循環到最後一個節點
時間複雜度：最差(O(nlog2n)),平均(O(nlog2n))
空間複雜度：O(1)

歸併排序：
原理：將兩個(或兩個以上)有序表合併成一個新的有序表，即把待排序序列分爲若干個有序的子序列，再把有序的子序列合併爲總體有序序列
時間複雜度：最差(O(nlog2n)),平均(O(nlog2n))
空間複雜度：O(n)

總結：快速排序、歸併排序的理想時間複雜度都是O(nlog2n),可是快速排序的時間複雜度並不穩定，最壞狀況下複雜度爲O(n^2),因此最理想的算法仍是歸併排序

查找算法
二分查找
原理：從數組的中間元素開始，若是中間元素正好是要查找的元素，搜索結束，若是某一個特定元素大於或小於中間元素，則在數組大於或者小於中間元素的那一半中查找，並且跟開始同樣從中間開始比較，若是某一步驟數組爲空，表明找不到
時間複雜度：最差(O(log2n)),平均(O(log2n))
空間複雜度：迭代(O(1))、遞歸(O(log2n))

順序查找
原理：按必定的順序檢查數組中每個元素，直到找到所要尋找的特定值爲止
時間複雜度：最差(O(n)),平均(O(n))
空間複雜度：O(1)

總結：二分查找算法的時間複雜度最差是O(log2n)，順序查找的時間複雜度最差爲O(n),因此二分查找法更快，可是在遞歸狀況下，二分查找法更消耗內存，時間複雜度爲O(log2n)

常見的線性結構：
LinkedList
鏈表，線性表的一種，最基本、最簡單經常使用的數據結構
特性：元素之間的關係是一對一的關係(除了第一個和最後一個元素，其餘元素都是首尾相接)、順序存儲結構和鏈式存儲結構兩種存儲方式

Stack
棧，和隊列類似，一個帶有數據存儲特性的數據結構
特性：存儲數據時先進後出的、棧只有一個出口，只能從棧頂增長和移除元素

Heap
堆，通常狀況下，堆叫二叉堆，近似徹底二叉樹的數據結構
特性：子節點的鍵值或者索引老是小於它的父節點、每一個節點的左右子樹又是一個二叉樹、根節點最大的堆叫最打堆或者大根堆，最小的叫最小堆或者小根堆

List
線性表，由零個或多個數據元素組成的有序序列
特性：線性表時一個序列；0個元素構成的線性表是空；、第一個元素無先驅、最後一個元素無後繼、其餘元素都只有一個先驅和後續、有長度，長度是元素個數，長度有限

doubly-linked-list 雙向列表
特性：每一個元素都是一個對象，每一個對象有一個關鍵字key和兩個指針(next和prev)

queue 隊列
特性：先進先出、併發中使用、能夠安全將對象從一個任務傳給另外一個任務

高併發相關概念
QPS:每分鐘請求或者查詢的數量，在互聯網領域，指每秒響應請求數（HTTP請求）
吞吐量：單位時間內處理的請求數量（一般由QPS與併發數決定）
PV:綜合瀏覽量，即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問的頁面數量（同一人訪問網站同一頁面，只作一次PV）
UV:獨立訪客，即必定時間範圍內相同訪客屢次訪問網站，只計算爲一個獨立訪客
帶寬：計算帶寬大小需關注兩個指標，峯值流量和頁面的平均大小
日網站帶寬 = PV / 統計時間(秒) * 平均頁面大小(KB) * 8
QPS不等於併發鏈接數，QPS是每秒HTTP請求數量，併發鏈接數是系統同時處理的請求數量
(總PV * 80%) / (6小時秒數 * 20%) = 峯值每秒請求數(QPS)
80%的訪問量集中在20%的時間
高併發的問題應該關心：壓力測試，測試能承受的最大併發、測試最大承受的QPS值

經常使用性能測試工具
ab、wrk、http_load、Web Bench、Siege、Apache JMeter
ab的使用：
模擬併發請求100次，總共請求5000次
ab -c 100 -n 5000 www.baidu.com

高併發注意事項
一、測試機器與被測試機器分開
二、不要對線上服務作壓力測試
三、觀察測試工具ab所在機器，以及被測試的前端機的cpu，內存，網絡等都不超過最高限度的75%

QPS達到50：能夠稱之爲小型網站，通常的服務器就能夠應付
QPS達到100：假設關係型數據庫的每次請求在0.01秒完成，單頁面只有一個SQL查詢，那麼100QPS意味着1秒鐘完成100次請求，可是此時咱們並不能保證數據庫查詢能完成100次
方案：數據庫緩存層、數據庫的負載均衡
QPS達到800：假設使用百兆帶寬，意味着網站出口的實際帶寬是8M左右，每一個頁面只有10K，在這個併發條件下，百兆帶寬已經用完
方案：CDN加速、負載均衡
QPS達到1000：假設使用Memcache緩存數據庫查詢數據，每一個頁面對Memcachae的請求遠大於直接對DB的請求，Memecache的悲觀請求數在2W左右，但有可能以前的內網帶寬已經吃光，表現不穩定
方案：靜態HTML緩存
QPS達到2000，方案：作業務分離，分佈式存儲

高併發解決方案案例
流量優化：防盜鏈處理
前端優化：減小HTTP請求、添加異步請求、啓用瀏覽器緩存和文件壓縮、CDN加速、創建獨立的圖片服務器
服務端優化：頁面靜態化、併發處理、隊列處理
數據庫優化：數據庫緩存、分庫分表、分區操做、讀寫分離、負載均衡

防盜鏈
盜鏈：在本身頁面上展現一些並不在本身服務器上的內容。常見是小站盜用大站的圖片、音樂、視頻等。
防盜鏈：防止別人經過一些技術手段繞過本站的資源展現頁面，盜用本站的資源，讓繞開本站資源展現頁面的資源連接失效。能夠大大減輕服務器及帶寬的壓力
防盜鏈的工做原理：經過Referer或者簽名，經過計算簽名的方式，判斷請求是否合法，若是合法則顯示，不然返回錯誤信息
Referer
Nginx模塊ngx_http_referer_module用來阻擋來源非法的域名請求，Nginx指令valid_referers,全局變量$invalid_referer
valid_referers none|block|server_names|string…;
none: 「Referer」來源頭部爲空的狀況
blocked: 「Referer」來源頭部不爲空，可是裏面的值被代理或者防火牆刪除了，這些值都不以http://或者https://開頭
server_names: 「Referer」來源頭部包含當前server_names

//針對防盜鏈的實現非法
location ~.*\.(gif|jpg|png|swf|rar|zip)$
{
valid_referers none blocked my.com*.my.com;
if ($invalid_referer) 
{
rewrite ^/www.my.com/403.png;
}
}
// 針對目錄的防盜鏈
location /images/
{
valid_referers none blocked my.com*.my.com;
if ($invalid_referer) 
{
rewrite ^/www.my.com/403.png;
}
}

　　

加密簽名的方法：使用第三方模塊HttpAccessKeyModule實現Nginx防盜鏈
accesskey on|off 模塊開關
accesskey_hashmethod md5 | sha-1 簽名加密方式
accesskey_arg GET參數名稱
accesskey_signature 加密規則

location ~.*\.(gif|jpg|png|swf|rar|zip)$
{
accesskey on;
accesskey_hashmethod md5;
accesskey_arg "key";
accesskey_signature "mypasss$remote_addr"
}

　

減小HTTP請求的方式
一、合併腳本和樣式表：使用外部的js和css文件引用的方式，由於這要比直接寫在頁面中性能要更好一些；獨立的一個js比用多個js文件組成的頁面載入快38%
二、圖片使用base64編碼減小頁面請求數
三、圖片地圖：一個圖片關聯多個URL，目標URL的選擇取決於用戶點擊圖片的位置
四、CSS Sprites：CSS精靈，經過合併圖片，經過制定css的background-image和background-position來顯示元素

HTTP緩存機制
緩存分類：HTTP緩存模型中，若是請求成功會有三種狀況
200 from cache:直接從本地緩存中獲取響應，最快速，最省流量，沒有向服務器發送請求
304 not modified:協商緩存，瀏覽器在本地沒有命中的狀況下請求頭髮送必定的校驗數據到服務端，若是服務端數據沒有改變瀏覽器從本地緩存響應，返回304
快速，發送的數據不多，只返回一些基本的響應頭信息，數據量很小，不發送實際響應體
200 OK：以上兩種緩存都失敗，服務器返回完整響應。沒有用到緩存，相對最慢。

本地緩存
瀏覽器認爲本地緩存可使用，不會去請求服務端
本地緩存配置
add_header指令：添加狀態碼爲2XX和3XX的響應頭信息
add_header name value [always];
能夠設置Pragma/Expires/Cache-Control,能夠繼承
expires指令：通知瀏覽器過時時長
expires time;
爲負值時表示Cache-Control:no-cache;
當爲正或者0時，就表示Cache-Control:max-age=指定時間

location ~.*\.(gif|jpg|png|swf|rar|zip)$
{
expires 30d;
}

　

協商緩存相關配置
Etag指令：指定簽名
etag on | off; 默認是on

前端代碼和資源壓縮
Gzip壓縮
配置Nginx服務

gzip on|off; #是否開啓gzip
gzip_buffers 32 4K|16 8K #緩衝（在內存中緩衝幾塊，每塊多大）
gzip_comp_level [1-9] #推薦6 壓縮級別（級別越高，壓得越小，越浪費CPU資源）
gzip_disable #正則匹配UA 什麼樣的Uri不進行gzip
gzip_min_length 200 #開始壓縮的最小長度
gzip_http_version 1.0|1.1 #開始壓縮的http協議版本
gzip_proxied #設置請求者代理服務器，該如何緩存內容
gzip_types text/plain application/xml #對哪些類型的文件用壓縮 如txt,html
gzip_vary on|off #是否傳輸gzip壓縮標誌

　　

CDN：內容分發網絡，儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，是內容傳輸的更快、更穩定。
CDN系統可以實時地根據網絡流量和各節點的鏈接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上
優點：本地Cache加速，提升企業站點的訪問速度；垮運營商的網絡加速，保證不一樣網絡的用戶都獲得良好的訪問質量；遠程訪問用戶根據DNS負載均衡技術智能自動選擇Cache服務器；
CDN的工做原理
傳統訪問：用戶在瀏覽器輸入域名發起網絡->解析域名獲取服務器IP地址->根據IP地址找到對應的服務器->服務器響應並返回數據
使用CDN訪問：用戶發起請求->只能DNS解析(根據IP判斷地理位置、接入網類型、選擇路由最短負載最輕的服務器)->取得緩存服務器IP->把內容返回給用戶(若是緩存中有)->向源網站發起請求->將結果返回給用戶->將結果存入緩存服務器

CDN適用場景：站點或者應用中大量靜態資源的加速分發、大文件下載、直播網站等
CDN的實現：BAT等都提供有CDN服務、可用LVS作4層負載均衡、可用Nginx，Varnish，Squid，Apache TrafficServer作7層負載均衡和Cache、適用Squid反向代理，或者Nginx等的反向代理

七層負載均衡的實現
基於URL等應用層信息的負載均衡
Nginx的proxy是它一個很強大的功能，實現了7層負載均衡
優勢：功能強大、性能好、運行穩定；配置簡單靈活；可以自動剔除工做不正常的後端服務器；上傳文件使用異步模式；支持多種分配策略，能夠分配權重，分配方式靈活
Nginx負載均衡：內置策略、擴展策略
內置策略：IP Hash、加權輪詢
擴展策略：fair策略、通用hash、一致性hash

加權輪詢策略
首先將請求都分給高權重的機器，直到該機器的權值降到了比其餘機器低，纔開始將請求分給下一個高權重的機器。當全部後端機器都down掉時，Nginx會當即將全部機器的標誌位請成初始狀態，以免形成全部的機器都處在timeout的狀態

IP Hash策略
Nginx內置的另外一個負載均衡的策略，流程和輪詢很相似，只是其中的算法和具體的策略有些變化；IP Hash算法是一種變相的輪詢算法

fair策略
根據後端服務器的響應時間判斷負載狀況，從中選出負載最輕的機器進行分流

通用Hash、一致性Hash策略
通用Hash比較簡單，能夠以Nginx內置的變量爲key進行Hash，一致性Hash採用了Nginx內置的一致性Hash環，支持memcache

Nginx配置

http {
    upstream cluster {
        server srv1;
        server srv2;
        server srv3;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://cluster;
            }
        }
}

　　

四層負載均衡的實現經過報文的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器 LVS實現服務器集羣負載均衡有三種方式，NAT，DR和TUN--------------------- 做者：開發小貓 來源：CSDN 原文：https://blog.csdn.net/wj610671226/article/details/78426698 版權聲明：本文爲博主原創文章，轉載請附上博文連接！