第二十六節 http協議原理
標簽（空格分隔）： Linux實戰教學筆記-陳思齊
---本教學筆記是本人學習和工作生涯中的摘記整理而成，此為初稿（尚有諸多不完善之處），為原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章原始出處，作者信息和本聲明。否則將追究法律責任。http://www.cnblogs.com/chensiqiqi/
第1章 Web服務基礎
1.1 http服務重要基礎
1.1.1 用戶訪問網站基本流程
-
我們每天都會使用Web客戶端上網瀏覽網頁。最常見的Web客戶端就是Web瀏覽器，如通用的微軟Internet Explorer（IE）以及技術人員偏愛的火狐瀏覽器，谷歌瀏覽器等。當我們在Web瀏覽器里輸入網站地址（例如：www.baidu.com）時，很快就會看到網站的內容。這看起來很神奇的背后，到底是怎樣的實現流程呢？也許普通的上網者無需關注，但作為一個IT技術人員，特別是合格的Linux運維人員，就需要清晰的掌握了。
-
下面就給大家介紹從客戶端用戶在Web瀏覽器里輸入網站地址，到看到網站內容的完整訪問流程。
-
[x] 第一步：客戶端用戶從瀏覽器里輸入www.baidu.com網站地址，回車后，系統首先會查找系統本地的DNS緩存及hosts文件信息，查找是否存在www.baidu.com域名對應的IP解析記錄，如果有就直接獲取IP地址，然后去訪問這個IP地址對應域名www.baidu.com的服務器，一般第一次請求時，DNS緩存是沒有解析記錄的，而hosts多在內部臨時測試時使用。
-
[x] 第二步：如果客戶端本地hosts及DNS緩存及hosts文件沒有www.baidu.com域名對應的解析記錄，那么，系統會把瀏覽器的解析請求發送給客戶端本地設置的DNS服務器地址（通常稱此DNS為LDNS，即Local DNS）解析，如果LDNS服務器的本地緩存有對應的解析記錄就會直接返回IP地址給客戶端，如果沒有，則LDNS會負責繼續請求其他的DNS服務器。
-
[x] 第三步：LDNS會從DNS系統的（.）開始請求www.baidu.com域名的解析，針對各個層級的DNS服務器系統進行一系列的查找，最終會查找到baidu.com域名對應的授權DNS服務器，而這個授權DNS服務器正是企業購買域名時用於管理域名解析的服務器，這個授權服務器會有www.baidu.com對應的IP解析記錄，如果此時沒有，就表示企業的域名管理人員沒有為www.baidu.com域名做解析設置，即網站還沒架設好。
-
[x] 第四步：baidu.com域名的授權DNS服務器會把www.baidu.com對應的最終IP解析記錄發給LDNS。
-
[x] 第五步：LDNS把收到的來自授權DNS服務器www.baidu.com對應的IP解析記錄發給客戶端瀏覽器，並且再LDNS把本地域名和IP的對應解析緩存起來，以便下一次更快的返回相同解析請求的記錄，這些緩存記錄在指定的時間（DNS TTL值控制）內不會過期。
-
[x] 第六步：客戶端瀏覽器獲取到了www.etiantian.org的對應IP地址，接下來，瀏覽器會請求獲得的IP地址對應的網站服務器，網站服務器接收到客戶端的請求並響應處理（此處的處理可能是數百台集群的服務器系統，也可能是一台雲主機），將客戶請求的內容返回給客戶端瀏覽器，至此，一次訪問瀏覽網頁的完整過程就完成了。
提示：
上述僅僅是客戶端用戶第一次訪問網站的基本過程，連續訪問后，系統本地和LDNS層級都會有緩存記錄，再訪問時流程就會有些變化，會直接取本地緩存記錄，這樣訪問過程就很快了。在上述整個訪問流程里，包含了DNS的解析流程以及HTTP協議的通信原理等重要的技術點。
1.1.2 DNS系統解析基本流程
-
了解完用戶訪問網站的基本流程后，再來了解下DNS解析的基本流程，這是企業針對運維崗位進行招聘時經常會面試的問題，因此，必須要熟練掌握了。
-
DNS，全稱Domain Name System/Serve，它在一個網站運行中起來了至關重要的作用，它的主要作用是負責把網站域名解析為對應的IP地址，例如：把www.baidu.com解析為對應的IP地址記錄如1.1.1.1,這個從域名到IP的解析過程，稱作A記錄，即Address Record。
-
DNS系統除了負責這個最重要的A記錄解析外，還有很多的功能。例如：
- 設置CNAME別名記錄，這個別名解析功能常被CDN加速服務商應用。
- 設置MX郵件記錄，這個MX記錄功能，在購買或搭建郵件服務時會被用到。
- 設置PTR記錄，反向解析，即把IP地址解析為對應的域名，和A記錄的解析相反，郵件服務等業務中會用到。
-
DNS 系統的架構類似於一顆倒掛着的樹（和Linux系統目錄結構類似），它的頂點也是根（"."），只不過這個根是用點（.）來表示的，不是目錄的根斜線（/）。
DNS解析原理流程
（1）DNS解析流程說明
- 在“用戶訪問網站基本流程”一節，我們了解了用戶訪問網站的基本實現過程，那么客戶端是怎樣一步步通過各個層級的DNS，獲取到域名對應的IP的呢？這里給大家做一個較為詳細的說明。
- DNS的解析流程實際上就是從用戶在客戶端瀏覽器中輸入網站地址並按回車開始的，一直持續到獲取域名對應的IP，整個過程可分為如下幾個步驟。
- [x] 第一步：客戶端用戶從瀏覽器里輸入www.baidu.com網站地址后回車，系統首先會查找系統本地的DNS緩存及hosts文件信息，確定是否存在www.baidu.com域名對應的IP解析記錄，如果有就直接獲取到IP地址，然后去訪問這個IP地址對應的www.baidu.com域名的服務器，一般第一次請求時，DNS緩存是沒有解析記錄的，而hosts多為內部臨時測試使用。
- [x] 第二步：如果客戶端DNS緩存及本地hosts文件沒有www.baidu.com域名對應的解析記錄，那么，系統會把瀏覽器的解析請求發送給在客戶端本地設置的DNS服務器地址（通常稱此DNS為LDNS，即：Local DNS）解析，如果LDNS服務器的本地緩存有對應的解析記錄就會直接返回IP地址給客戶端：如果沒有，則LDNS會負責繼續請求其他的DNS服務器。
- [x] 第三步：LDNS會從DNS系統的（.）根開始請求www.baidu.com域名的解析，根DNS服務器在全球一共有13台，根服務器下面是沒有www.baidu.com域名解析記錄的，但是根下面有www.baidu.com對應的頂級域.org的解析記錄，因此，根會把.org對應的DNS服務器地址返回給LDNS。
- [x] 第四步：LDNS獲取到.org對應的DNS服務器地址后，就會去.org服務器請求www.baidu.com域名的解析，而.org服務器下面也沒有www.baidu.com域名對應的解析記錄,但是有baidu.com域名的解析記錄，因此，.org服務器會把baidu.com對應的DNS服務器地址返回給LDNS
- [x] 第五步：同理，LDNS獲取到baidu.com對應的DNS服務器地址后，就會去baidu.org服務器請求www.baidu.com域名的解析，baidu.com域名對應的DNS服務器是該域名的授權DNS服務器，這個DNS服務器正是企業購買域名時管理解析所在的服務器（也可能是自建的授權DNS服務器），這個服務器會有www.baidu.com對應的IP解析記錄，如果此時沒有，就表示企業的域名人員沒有為www.baidu.com域名做解析，即網站還沒架設好。
- [x] 第六步：baidu.com域名DNS服務器會把www.baidu.com對應的IP解析記錄發給LDNS
- [x] 第七步：LDNS把收到的來自授權DNS服務器www.baidu.com對應的IP解析記錄發給客戶端瀏覽器，並且LDNS會把本地域名和IP的對應解析記錄緩存起來，以便下一次更快的返回相同解析請求的記錄。至此，整個DNS的解析流程就完成了。
（2）DNS解析流程圖
1.2 HTTP協議
1.2.1 HTTP協議簡介
- HTTP協議，全稱HyperText Transfer Protocol，中文名為超文本傳輸協議，是互聯網中最常用的一種網絡協議。HTTP的重要應用之一是WWW服務。設計HTTP協議最初目的就是提供一種發布和接收HTML（一種頁面標記語言）頁面的方法（請求返回）。
- HTTP協議是互聯網上常用的通信協議之一。它有很多的應用，但最流行的就是用於Web瀏覽器和Web服務器之間的通信，即WWW應用或稱Web應用。
- WWW，全稱World Wide Web，常稱為Web，中文譯為“萬維網”。它是目前互聯網上最受用戶歡迎的信息服務形式。HTTP協議的WWW服務應用的默認端口為80（端口的概念），另外的一個加密的WWW服務應用https的默認端口為443，主要用於網銀，支付等和錢相關的業務。當今，HTTP服務，WWW服務，Web服務三者的概念已經混淆了，都是指當下最常見的網站服務應用。
1.2.2 常見的HTTP請求方法
| HTTP方法 | 作用描述 |
|---|---|
| GET | 客戶端請求指定資源信息，服務器返回指定資源 |
| HEAD | 只請求響應報文中的HTTP首部 |
| POST | 將客戶端的數據提交到服務器，例：注冊表單 |
| PUT | 從客戶端向服務器傳送的數據取代指定的文檔內容 |
| DELETE | 請求服務器刪除Request-URI所標識的資源 |
| MOVE | 請求服務器將制定的頁面移至另一個網絡地址 |
1.2.3 HTTP狀態碼
- HTTP狀態碼（HTTP Status Code）是用來表示Web服務器響應http請求狀態的數字代碼。每當Web客戶端向Web服務器發送一個HTTP請求時，Web服務器都會返回一個狀態響應代碼。這個狀態碼是一個三位數字代碼，作用是告知Web客戶端此次的請求是否成功，或者是否要采取其他的動作方式。
- HTTP協議1.1版本中的狀態嗎可以分為五大類，如下表：
| 狀態碼范圍 | 作用描述 |
|---|---|
| 100-199 | 用於指定客戶端相應的某些動作 |
| 200-299 | 用於表示請求成功 |
| 300-399 | 用於已經移動的文件並且常被包含在定位頭信息中指定新的地址信息 |
| 400-499 | 用於指出客戶端的錯誤 |
| 500-599 | 用於指出服務器端的錯誤 |
提示：
http響應的狀態碼種類很多，但是在實際工作場景中，經常遇到的狀態碼卻不多，我把生產場景常見的重要狀態碼及對應的作用整理為下表。
生產場景常見的狀態嗎及其對應的作用
| 狀態代碼 | 詳細描述說明 |
|---|---|
| 200～OK | 服務器成功返回網頁，這是成功的http請求，返回的標准狀態碼 |
| 301-Moved Permanently | 永久跳轉，所有請求的網頁將永久跳轉到被設定的新的位置，例如：從baidu.com跳轉到www.baidu.com |
| 403-Forbidden | 禁止訪問，這個請求是合法的，但是服務器端因為匹配了預先設置的規則而拒絕響應客戶端的請求，此類問題一般為服務器或服務權限配置不當所致。 |
| 404-Not Found | 服務器找不到客戶端請求的指定頁面，可能是客戶端請求了服務器上不存在的資源導致 |
| 500-Internal Server Error | 內部服務器錯誤，服務器遇到了意料不到的情況，不能完成客戶的請求。這是一個較為籠統地報錯，一般為服務器的設置或者內部程序問題導致。例如SElinux開啟，而又沒有為http設置規則許可，客戶端訪問就是500 |
| 502-Bad Gateway | 壞的網關，一般是代理服務器請求后端服務時，后端服務不可用或沒有完成響應網關服務器。一般為反向代理服務器下面的節點出問題導致。 |
| 503-Service Unavailable | 服務當前不可用，可能因為服務器超載或停機維護導致，或者是反向代理服務器后面沒有可以提供服務的節點 |
| 504-Gateway Timeout | 網關超時，一般是網關代理服務器請求后端服務時，后端服務沒有在特定的時間內完成處理請求，一般是服務器過載導致沒有在指定的時間內返回數據給前端代理服務器。 |
1.2.4 HTTP響應報文介紹
HTTP響應報文由起始行，響應頭部，空行和響應報文主體幾個部分組成，和HTTP請求報文格式類似。報文如下表：
| 報文格式 | 報文信息 |
|---|---|
| 起始行 | 協議及版本號 數字狀態碼 狀態信息 |
| 響應頭部 | 字段1:值1 字段2：值2 |
| 空行 | 空白內容 |
| 響應報文主體 | 就是html的網頁 |
下面對響應報文的每個部分逐一闡述：
（1）起始行
響應報文的起始行，也叫狀態行，用來說明服務器響應客戶端請求的狀況。一般為協議及版本號，數字狀態碼，狀態情況。例如：HTTP/1.1 200 OK
（2）響應頭部
和請求報文類似，起始行的后面一般有若干個頭部字段。每個頭部字段都包含一個名字和一個值，兩者之間用冒號分隔。頭部結尾也是以一個空行結束。常見的頭部信息有：
（3）空行
最后一個響應頭部信息之后是一個空行，發送回車符和換行符，通知客戶端空行下文無頭部信息。
（4）響應報文主體
響應報文主體中裝載了要返回給客戶端的數據。這些數據可以是文本，也可以是二進制的（圖片，視頻）。
1.2.5 HTTP協議原理及重點分析
回顧：數據包，傳輸過程
HTTP協議屬於OSI模型中的第七層應用層協議，HTTP協議的重要應用就是WWW服務應用，下面就以WWW服務應用為例介紹HTTP協議的通信原理了，HTTP協議進行通信時，需要有客戶端（即終端用戶）和服務端（即Web服務器），在Web客戶端向Web服務器發送請求報文之前，先要通過TCP/IP協議在Web客戶端和服務器之間建立一個TCP/IP連接。整個http協議請求的工作流程如下：
1）終端客戶在Web瀏覽器地址欄輸入訪問地址http://www.baidu.com
2）Web瀏覽器請求DNS服務器把域名www.baidu.com轉換成Web服務器的IP地址，此處的解析過程就是DNS解析的原理流程，前面已經講過了，此處不再敘述。
3）Web瀏覽器將端口號（默認80）從訪問地址（URL）中解析出來。
4）Web瀏覽器通過解析后的IP地址及端口號於Web服務器之間建立一條TCP連接
5）建立TCP連接后，Web瀏覽器向Web服務器發送一條HTTP請求報文，請求報文內容格式及信息細節前面已經講過了，此處不在敘述。
6）Web服務器響應並讀取瀏覽器的請求信息，然后返回一條HTTP響應報文，響應報文內容格式及信息細節前文也已經講過了，此處不在敘述。
7）Web服務器關閉http連接，關閉TCP連接，Web瀏覽器顯示訪問的網站內容到屏幕。
上述就是HTTP協議通信原理過程，整個通信原理的重要知識點有：
- [x] 用戶訪問網站的流程
- [x] DNS解析流程細節
- [x] 建立TCP連接過程（TCP/IP三次握手原理知識）（11種狀態）
- [x] 發送HTTP報文及HTTP請求報文內容細節。
- [x] Web服務器響應客戶端請求處理細節（網站集群架構細節）
- [x] 響應HTTP報文及HTTP響應報文的細節
- [x] 關閉TCP連接，涉及TCP/IP協議四次揮手原理
事實上，DNS解析原理，http協議原理，tcp/ip協議原理都是高薪面試的重點，是高級運維必備知識，這里對其中的重要知識點進行匯總，如下：
- [x] http協議位於OSI模型中第7層應用層
- [x] http協議的重要應用是www服務。
- [x] 用戶上網流程，DNS解析原理流程
- [x] DNS解析獲取的IP后，建立TCP連接，然后發送http請求細節和服務器響應細節。
- [x] HTTP請求報文與HTTP響應報文知識
- [x] 到達HTTP服務后請求后端集群節點流程為Nginix-->fastcgi-->PHP-->(數據庫，存儲等)
- [x] TCP/IP協議三次握手和四次揮手原理。
1.3 HTTP資源
1.3.1 媒體類型
- 互聯網上的數據有很多不同的數據類型，Web服務器會把通過Web傳輸的每個對象都打上名為MIME類型（MIME Type）的數據格式標簽。最初涉及MIME（Multipurpose Internet Mail Extension 多用途因特網郵件擴展）是為了解決在不同的電子郵件系統之間搬移報文時存在的問題。MIME在電子郵件系統中工作的非常好，后來，HTTP也支持了這個功能，用它來把數據描述並標記不同的數據內容類型。
- 當Web服務器響應HTTP請求時，會為每一個HTTP對象數據加一個MIME類型，當Web瀏覽器獲取到服務器返回的對象時，會去查看相關的MIME類型，進行相應處理。
- MIME類型存在於HTTP響應豹紋的響應頭部信息里，它是一種文本標記，表示一種主要的對象類型和一個特定的子類型，中間由一條斜杠來分隔。
| MIME類型 | 文件類型 |
|---|---|
| text/html | html htm shtml文本類型 |
| text/css | css文本類型 |
| text/xml | xml文本類型 |
| image/gif | gif圖像類型 |
| image/jpeg | jpeg jpg圖像類型 |
| application/javascript | js文本類型 |
| text/plain | txt文本類型 |
| application/json | json文本類型 |
| text.plain | txt文本類型 |
| application/json | json文本類型 |
| video/mp4 | mp4視頻類型 |
| video/quicktime | mov視頻類型 |
| video/x-flv | flv視頻類型 |
| video/x-ms-wmv | wmv視頻類型 |
| video/x-msvideo | avi視頻類型 |
可以從www的重要服務軟件Nginx的配置文件conf目錄下，查看其支持的媒體（MIME）類型，相關命令及內容為：
[root@chensiqi conf]# head -10 mime.types
types {
text/html html htm shtml;
text/css css;
text/xml xml;
image/gif gif;
image/jpeg jpeg jpg;
application/javascript js;
application/atom+xml atom;
application/rss+xml rss;
以下內容省略....
1.3.2 URL介紹
URL，全稱Uniform Resource Location，中文翻譯為統一資源定位符，也被稱為網頁地址（網址）。如同在網絡上的門牌，它是因特網上標准的資源唯一地址。通俗地說，URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶端和服務器程序上。采用URL可以用一種統一的格式來描述各種信息資源，包括文件，服務器的地址和目錄等。嚴格的說，每個URL都是一個URI，它標識一個互聯網資源，並指定對其進行操作或取得該資源的方法。
URL的格式由下列三部分組成：
- [x] 第一部分是協議，例如：http
- [x] 第二部分是主機資源服務器IP地址或域名（端口號），例如：www.baidu.com
- [x] 第三部分是主機資源的具體地址，如目錄和文件名等，例如：chensiqi/index.html
提示：
第一部分和第二部分之間用“😕/”符號隔開，第二部分和第三部分用"/"符號隔開。第一部分和第二部分是不可缺少的，第三部分可以省略。
標准的URL及說明
| 協議 | 分隔符號 | IP地址域名 | 分隔符號 | 資源目錄地址 |
|---|---|---|---|---|
| http | 😕/ | www.chensiqi.com | / | chensiqi/index.html |
| http | 😕/ | www.chensiqiedu.com | / | video/index.html |
1.3.3 URI介紹
- URI，全稱Uniform Resource Identifier，中文翻譯為統一資源標識符，是一個用於標識某一互聯網資源名稱的字符串。這個字符串在世界范圍內唯一標識並定位某一個信息資源。互聯網上每個可用的數據資源，如HTML，圖片，視頻等皆通過統一資源標識符進行定位。
網站URL說明
| 協議 | 分隔符號 | IP地址域名 | 分隔符號 | 資源目錄地址 |
|---|---|---|---|---|
| http | 😕/ | www.chensiqi.com | / | chensiqi/index.html |
| http | 😕/ | www.chensiqiedu.com | / | video/index.html |
指向一個用戶郵箱的URI
| 協議（服務形式） | 分隔符號 | 用戶名 | 分隔符號 | 域名 |
|---|---|---|---|---|
| mailto | : | chensiqi | @ | chensiqi.com |
大多數同學都熟悉URL，而不是URI。URL是URI命名機制的一個子集
1.3.4 靜態網頁資源
靜態網頁資源介紹
在網站設計中，純粹HTML格式的網頁（可以包含圖片，視頻，JS（前端功能實現），CSS（樣式）等）通常被稱為“靜態網頁”，早期的網站大多都是靜態的。靜態網頁是相對於動態網頁而言的，是指沒有后台數據庫，不含程序（如php，jsp，asp）和可交互的網頁。
靜態網頁資源特點
- 靜態網頁資源的特點是，開發者編寫的是什么，它顯示的就是什么，一旦編寫完成，就不會有任何改變。靜態網頁的維護和更新相對比較麻煩，每個不同的網頁都需要單獨編集更新，靜態網頁一般適用於更新較少的宣傳展示型網站（例如：酒，家具，豬飼料等的宣傳網站），是早期很多中小網站展示的形式。
- 靜態網頁資源的對應程序及資源文件的常見擴展名為：
- 純文本類程序或文件，如htm，html，xml，shtml，js，css等
- 圖片類文件或數據文檔，如jpg，gif，png，bmp，txt，doc，ppt等
- 視頻類流媒體文件，如mp4，swf，avi，wmv，flv等
靜態網頁資源有幾個重要的特征：
- [x] 每個網頁都有一個固定的URL地址，且URL一般以.html,.html,shtml等常見形式為后綴，而且地址中不含郵問號“？”或“&”等特殊符號。
- [x] 網頁內容一經發布到網站服務器上，無論是否有用戶訪問，每個網頁的內容都是保存在網站服務器文件系統上的，也就是說，靜態網頁是實實在在保存在服務器上的文件實體，每個網頁都是一個獨立的文件。
- [x] 網頁內容是固定不變的，因此，容易被搜索引擎收錄（容易被用戶找到）（優點）
- [x] 網頁沒有數據庫支持，在網站制作和維護方面工作量較大，因此當網站信息量很大時完全依靠靜態網頁制作的方式比較困難（缺點）
- [x] 網頁的交互性較差，在程序功能實現方面有較大的限制（缺點）
- [x] 網頁程序在用戶瀏覽器端解析，如IE瀏覽器，程序解析效率很高，由於服務端不進行解析，並且不需要讀取數據庫，因此服務器端可以接受更多的並發訪問。當客戶端向服務器請求數據時，服務器直接把數據從磁盤文件系統上返回（不做任何解析），待客戶端拿到數據后，在瀏覽器端解析展現出來（優點）
網站靜態頁面的特點就相當於在餐館吃火鍋，餐館把原材料和工具都給你准備好，你自己只需要涮着吃就行，不需要飯店大廚給你炒菜做菜了，因此，對於飯店來講，服務顧客的效率大大提高了。而對於靜態頁面來講就是不需要服務器端解析，因此提供網站方服務器的壓力也大大減輕了。
靜態網頁語言
常見的靜態網頁語言有html，js，css，xml，shtml等，具體語言的特點不在這里細說。
回顧一下靜態網頁的核心特點，如下：
1）程序在客戶瀏覽器端解析，不讀取后端數據庫，因此性能和效率很高。
2）因為后端沒有數據庫支持，所以和用戶的交互性較差，功能實現也很少。
有關靜態網頁的架構思想
在高並發，高訪問量的場景下做架構優化，涉及的關鍵環節就是把動態網頁轉成靜態網頁，而不直接請求數據庫和動態服務器，並且可以把靜態內容推送到前端緩存（或CDN）中提供服務，這樣就可以提升用戶體驗，節約服務器和維護成本。
1.3.5 動態網頁資源
動態網頁資源介紹
所謂的動態網頁是與靜態網頁相對而言的，也就是說，動態網頁的URL后綴不是.htm,.html,.shtml,.xml,.js,.css等靜態網頁的常見后綴擴展名形式，而是以.asp,.aspx,.php,.js,.do,.cgi等形式作為后綴的，並且一般在動態網頁網址中會有標志性的符號--“？，&”，此外，在大多數情況下后端都需要有數據庫支持等。
動態網頁資源特點
1）網頁擴展名后綴常見為：.asp,.aspx,.php,.jsp,.do,cgi等
2）網頁一般以數據庫技術為基礎，大大降低了網站維護的工作量
3）采用動態網頁技術的網站可以實現更多的功能，如用戶注冊，用戶登錄，在線調查，投票，用戶管理，訂單管理，發博文等等
4）動態網頁並不是獨立存在於服務器上的網頁文件，當用戶請求服務器上的動態程序時，服務器解析這些程序並可能讀取數據庫返回一個完整的網頁內容。
5）動態網頁中的“？”在搜索引擎的收錄方面存在一定問題，搜索引擎一般不會從一個網站的數據庫中訪問全部網頁，或者出於技術等方面的考慮，搜索蜘蛛一般不會去抓去網址中“？”后面的內容，因此在企業通過搜索引擎進行推廣時，需要針對采用動態網頁的網站做一定的技術處理（偽靜態技術），以便適應搜索因窮的抓取要求。
6）程序在服務器端解析，這相當於顧客點餐，飯店廚師做飯做菜，耗時長，效率低。由於程序在服務端解析，因此，會消耗大量的CPU和內存，I/O等資源，並且多數還要讀取數據庫等服務，因此，其訪問效率遠不如靜態網頁，在服務端解析動態程序的服務常見的有PHP引擎，Java容器（tomcat,resin,jboss,weblogic）
有關動態網頁的架構思想
- 一般來說，靜態網頁的性能效率是動態網頁的10～30倍。且動態網站效率很差，並發能力也很低，在高並發場景中，應盡可能轉換成靜態網頁提供服務。動態轉靜態幾乎是所有高並發網站必備的架構方案思路，也是高級架構師的職責所在。
- 此外，動態轉靜態也要根據業務需求設計，例如，對於更新頻繁的網站如果設計不好就可能會產生數據不一致的情況，即用戶看到的數據不是網站最新的內容，而是靜態的內容。
1.3.6 生產Web架構優化實戰方案
由於靜態網頁程序在客戶端解析，大大降低了服務器端的訪問壓力，因此解析效率更高，在實際高並發網站架構中，可以考慮把用戶請求的數據解析后存成靜態文件放於磁盤中或放於內存中，來降低動態服務器的壓力，節約企業成本，提升用戶體驗。
（1）門戶新聞業務
新聞網站的特點是一旦發布完成，幾乎不會再改動網頁內容。因此，對於新聞業務內容的靜態化相對比較簡單。
程序===>生成靜態頁面
- [x] 第一步：程序要支持發布動態內容轉成靜態功能
- [x] 第二步：運營編輯人員發布新聞網頁后，后台程序立刻將動態網頁生成靜態文件。
- [x] 第三步：運維人員通過發布或事件觸發把運營編輯生成的靜態網頁發布到事先搭建好的公司緩存集群服務器上，或者把靜態內容同步到購買的全國所有CDN服務器節點上，然后，再提供給用戶訪問瀏覽。
（2）視頻網站業務
- 視頻網站和新聞網站類似，特點都是一旦發布完成，幾乎不會再改動網頁內容。因此，實現視頻業務網站高效訪問也很簡單。
- 以優酷視頻網為例，用戶在上傳視頻時，需要經歷轉碼-->審核的過程（大概1小時），然后一些熱點視頻也可能會被提前推送同步到CDN的核心節點或全國所有CDN服務器節點，用戶訪問時才會更快。
（3）Blog/BBS/SNS/微博社區業務/電商（如淘寶，京東）
這幾類業務的動態轉靜態是比較困難的，因為，用戶發布完成內容，可能會隨時更新並查看，這種情況一般會通過異步方式，例如消息中間件技術加上NoSQL集群技術實現轉換，當然也會改進產品細節，例如：在訪問的環節設置延時，異步加載等手段。
1.4 網站流量度量術語
1.4.1 IP（internet Protocol）
IP(獨立IP)即Internet Protocol，這里指獨立IP數，獨立IP數是指不同IP地址的計算機訪問網站時被計算的總次數。獨立IP數是衡量網站流量的一個重要指標。一般一天內（00:00 - 24:00）相同IP地址的客戶端訪問網站頁面只被計算為一次，記錄獨立IP的時間可為一天或一個月，目前通用的標准為“一天”。
-
[x] 假設有部分同學同時在某處的局域網中打開了www.baidu.com，請問對於百度來說網站是幾個獨立IP？答：是一個獨立IP。這是因為，國內幾乎所有的公司都是采用局域網共享上網的，即通過路由器NAT地址轉換上網，每個計算機在局域網內的私有IP是不同的，但是在外網上，就必須都要由路由器把每個私網地址轉換成了路由器接口的固定公網IP（多IP映射暫不考慮），所以說，對於網站來說一天內多個相同公司的IP的客戶端訪問計算為一個獨立IP
-
[x] 再假設一個客戶端用戶通過ADSL等直接撥號上網，但是上網的時候偶爾掉線，一共重新撥號了3次（相近時間重新撥號IP相同的幾率是極少的），然后每次都繼續打開百度的網頁地址，請問此時，網站獨立IP數是多少？還是一個獨立IP
由此可見，通過獨立iP數度量網站訪問量，和實際的訪問情況不是很匹配。國內的企業，學校大多數使用的NAT上網的，一個獨立IP背后可能有數十上百個客戶端訪問。獨立IP數雖然不是很准，但卻是IT技術人員比較關心的一個衡量網站的指標。
1.4.2 PV（Page View）
- PV（訪問量）即Page View，中文翻譯為頁面瀏覽，即頁面瀏覽器或點擊量，不管客戶端是不是相同，也不管IP是不是相同，用戶每次訪問一個網站頁面都會被計算一個PV。
- PV的具體度量方法就是從客戶瀏覽器發出一個對Web服務器的請求（Request），Web服務器接到這個請求后，將該請求對應的一個網頁（Page）發送給瀏覽器，就產生一個PV。這里有一個問題，就是只要這個請求發送給了瀏覽器，無論這個頁面是否完全打開（或下載完成），那么都是會被計數為1個PV（服務器日志），一般為了防止用戶快速刷PV，很多網站把PV的統計程序放在頁面的最下面。
- 用PV衡量網站時，PV數反映的是瀏覽某網站的頁面數量，每刷新一次頁面也算一次。因此，可以說PV數與來訪用戶的數量成正比，但PV數並不是真正的頁面來訪者數量，而是網站被訪問的頁面數量，因為一個來訪者可能產生多個PV。
問：如果一個用戶要訪問趕集網或58同城租房，你覺得用戶可能會產生多少PV？
答：平均可能會有十幾到幾十個PV，一個來訪者訪問網站的PV數的多少是和網站提供的業務直接相關的。
例如：這些分類網站，用戶瀏覽網站可能是為了找房子，找工作，因此一個用戶訪問的頁面會很多，因此PV就會很多。
PV（Page View）是網站被訪問的頁面數量的一個指標，但不能直接知道有多少人訪問了這個網站。
一個來訪者訪問網站，可能產生若干PV數，但是獨立IP數就只有1個，因此，如果對比一個網站的獨立IP數和PV數，不難看出，PV數一定會大於等於獨立IP數的，視網站的業務而定，例如，對於分類門戶，可能會達到10:1，甚至更多。
1.4.3 UV(Unique Visitor)
- UV(獨立訪客)即Unique Visitor，同一台客戶端（PC或移動端）訪問網站被計算為一個訪客。一天（00:00-24:00）內相同的客戶端訪問同一個網站只計算一次UV。UV一般是以客戶端Cookie等技術作為統計依據的，實際統計會有誤差。
- 考慮到一台客戶端電腦可能會有多人使用的情況，因此，UV（獨立訪客）實際上並不一定是獨立的自然人訪問。
1.http請求報文：瀏覽器版本，OS
2.http響應報文：cookie（id）
1.4.4 企業網站對IP，PV，UV的度量
- [x] 先來看對IP的度量：
- 分析所有Web服務器的訪問日志信息，對IP地址段去重后計數，這是IT人員的基本計算手段
- 在網站的每一個（所有）頁面結尾，嵌入JS等統計程序代碼，待用戶加載網頁后，IP即傳給統計IP的服務器，這種方法一般被第三方統計公司或企業內部開發日志分析程序時使用
- 用第三方大家比較信任的統計工具例如：谷歌的統計（GA）。
IP的統計方法簡單，易用，因此，成為了多數網站衡量網站流量的重要指標之一。
- [x] 對PV的度量如下：
- 分析Web服務的訪問日志（需要排除js，css及各種圖片的日志信息），只計算HTML，PHP等頁面數量。
- 在網站的每一個頁面結尾，嵌入JS等統計程序代碼，待用戶加載網頁后，訪問數量即傳給統計PV的服務器，這種方法一般被第三方統計公司或在企業內部開發日志分析程序時使用。
- 用第三方大家比較信任的統計工具例如：谷歌的統計（GA）
PV的統計方法也很簡單，易用，因此，也是多數網站衡量網站流量的重要指標之一。
特別提示：
IP和PV概念，統計方法也是Linux運維人員要掌握的重點。
- [x] 對於UV的度量如下：
- 通過客戶端HTTP請求報文分析
一個客戶端會多次請求網站服務器，每次HTTP請求都會攜帶客戶端自身的大量信息，比如：IP地址，請求發出時間，瀏覽器版本，操作系統版本等等。網站服務器對這些請求進行分析，如果這些請求滿足一些共同特征，比如來自同一個IP地址，且瀏覽器版本和操作系統版本相同，請求時間又相近等，那么就可以認為這些是來自於同一個客戶端，那么多個頁面訪問也只算一個UV。共同特征的定義是由服務器方決定的。通常，用IP地址+其他特征共同來定義的情況較多。但此種度量方法無法解決以下問題，例如：多個人的電腦軟硬件經常雷同，並且是一個公司或者學校的人；多個人共用一個電腦的情況。 - 通過cookie鑒別
當客戶端第一次訪問某個網站服務器的時候，網站服務器會給這個客戶端的電腦發出一個cookie，通常放在這個客戶端電腦的C盤當中。在這個cookie中會分配一個獨一無二的編號，這其中會記錄一些訪問服務器的信息，如訪問時間，訪問了哪些頁面，等等。當你下次再訪問這個服務器的時候，服務器就可以直接從你的電腦中找到上一次放進去的Cookie文件，並且對其進行一些更新，但那個獨一無二的編號是不會變的。如果在一定時間內，服務器發現2個來訪者對應的是一個編號，那么自然可以認為它來源於同一個來訪者了，於是就計算1個UV。 - 使用Cookie的方法要比分析客戶端HTTP請求頭部信息分析更精確些。但也存在一些問題，比如：有的客戶端為保證更高級別的安全，關閉了Cookie的功能；或者是有些客戶端設置了在退出頁面時自動刪除Cookie，亦或你經常自己去手動刪除Cookie，那么這個方法就不那么精確了。
- 因此，以上兩個方法都只能得到近似的UV，而不是絕對精確。
- UV的度量相對IP和PV來說，不但麻煩，而且要開發比較復雜的程序系統才能得到期望的結果，因此，在Linux運維領域大家提及的較少，一般企業市場及運營人員可能會關注網站的UV。
- 通過客戶端HTTP請求報文分析
1.4.5 IP,PV,UV的區別
- 針對該主題，通過一個訪問示例來講解吧
- 假設某城市的一個網吧里，有10個人都進入了www.baidu.com網站，每個人平均訪問了5個頁面，但是這個網吧對外出口是一個公網IP（注意：也可以配置多個IP出口，此處不計特殊情況），所以，對於baidu網站來說，只會計算一個獨立IP訪問，但是因為網吧里有10人在訪問www.baidu.com網站，並且平均都訪問了5次，因此，對於baidu網站來說，PV數就是10*5=50個PV，而因為有10個人訪問，就是10個不同的客戶端訪問，因此，UV為10。
- 那么，在訪問示例中：網站獨立IP數為1個，PV數為50個，UV（獨立訪客）為10個。
- 通過上述結果，我們不難得出一個結論，一個網站的獨立IP數量要比網站實際訪問的PV數量小的多。通常情況下（國內互聯網環境），網站的UV數也會大於獨立IP數。
- PV數高說明訪問的頁面數多，但是不一定就代表來訪者多：但PV數一定與來訪者的數量成正比，不過，PV並不直接決定頁面的真實來訪者數量。比如在訪問某網站時，一個人也可通過不斷的刷新頁面，制造出非常高的PV數。PV數多，用戶訪問網站頁面的總數量多，通常服務器的壓力會大一些。
1.4.6 並發連接
網站並發連接
在面試過程中Linux運維人員經常會被問到：你的公司網站最大並發是多少？
那么到底什么事並發？怎么理解並發呢？
A種理解：網站服務器每秒能夠接收的最大用戶請求數
B種理解：網站服務器每秒能夠響應的最大用戶請求數。
C種理解：網站服務器在單位時間內能夠處理的最大連接數。
雖然A，B的理解占IT人員中的大多數，但是，C理解更為准確一些。
舉個單位時間段的例子說明
我們去餐館吃飯，餐館里一共有10張桌子，每張桌最多坐4個人同時吃飯，那么一般人的理解，這個餐館能夠接收的並發吃飯人數為10*4，即40個並發，這里就沒有考慮時間問題，1秒並發可以是40個，10分鍾內並發也是40個。因為這里還有一個因素，就是每個人吃飯時長的問題，如果平均每個人10分鍾吃完，那么可以說10分鍾內，這個餐館的並發為40個，而不是每秒鍾並發40個，因為，第一秒可以是40個人同時進來，但是第二秒就無人可進了（滿員了），如果說10分鍾並發是40個，下一個10分鍾還能是40個，第三個10分鍾還可以是40個。即網站服務器在單位時間內能夠處理的最大連接數。
再舉個同一個時刻示例：
高速公路每個方向都有2條車道，那么，同一時刻並發的車輛為兩輛，並且並發可以永遠為2，如果按秒計算，每秒的並發可能就可以有十幾輛，這個例子和餐館不同，因為高速路處理並發不需要處理時間，但是對於Web服務器來講，需要花費時間處理請求，這個請求可能是1秒或數秒，因此說，並發不應該只是用戶訪問的請求數，而是服務器同時處理的並發數，並且單位時間不一定是1秒，可能是一個連接的處理周期內的連接數。
對於網站服務器來說，所謂的並發就是單位時間內，服務器能夠同時處理的最大連接數，因為有的請求1秒結束，有的請求可能10秒才結束（業務程序及配置不同），因此，網站並發不是客戶端每秒的並發請求數，而是服務器在一段時間內（1秒或者數秒內）可以處理的最大連接數，這個連接既包含正在建立的連接，也包含已經建立的連接。
例如：某網站的並發是5000
意味着：單位時間內（理解為1秒或數秒內），正在處理的連接數，正在建立的連接數。加起來一共是5000個。
- [x] Concurrent User表示網站並發用戶總數。
- [x] Request Per Second [RPS]表示每秒請求數（吞吐量）
- [x] Simultaneous Browser connections [SBC]表示並發瀏覽連接數。
- [x] Thinking Time 表示平均用戶思考時間
1.4.7 工作場景：統計並發數的基本方法
1）統計當下時刻的linux的網絡連接數並發，netstat -an|grep -i “est”|wc -l
2）nginx web 層 active status
其他服務並發連接
（1）QPS（Query Per Second）每秒查詢率
每秒查詢率QPS是用於衡量一個特定的查詢服務器在規定時間內所處理流量多少的標准。運維工作中，DNS系統以及數據庫等服務的查詢性能經常用每秒查詢率來衡量。
（2）IOPS（Input/Output Operations Per Second）
IOPS即每秒進行讀寫（I/O）操作的次數，多用於數據庫等場合，衡量隨機訪問的性能。存儲端的IOPS性能和主機端的I/O是不同的，IOPS是指存儲每秒可接受多少次主機發出的訪問，主機的一次I/O需要多次訪問存儲才可以完成。例如，主機寫入一個最小的數據塊，也要經過“發送寫入請求，寫入數據，收到寫入確認”等三個步驟，也就是3個存儲訪問。
如何測試磁盤的存儲性能？
1.連續的讀寫向磁盤中寫入大的文件
dd if=/dev/zero of=/tmp/test01.bin bs=1K count=10000
1.4.8 常見企業網站排名及PV/IP訪問量
|網站|獨立IP萬/日|PV數萬/日|網站並發級別|機器數量|
|--|--|--|--|
|www.51cto.com|582000|1338600|10000|數十台|
|www.ganji.com|17340000|13872000|10000-30000|幾百台|
|www.58.com|1398000|22927200|10000-30000|幾百台|
|www.weibo.com|30180000|166593600|幾十萬|千台|
|www.taobao.com|46620000|489510000|幾十萬-百萬|萬台|
|www.jd.com|6108000|98949600|數萬|千台|
|www.suning.com|930000|7254000|10000-30000|白台|
提示：以上數據於大約2015年7月從第三方http://alexa.chinaz.com/alexa_more.aspx 網站查找所得，僅供讀者參考，不同的統計程序差別也很大，有一定誤差，實際最高日訪問量要比此表大，因為網站訪問量也節假日等有關，另外統計的誤差和chinaz.com的統計方法有關，后面的最大並發以及機器數量級別為作者根據訪問量及業務類型估算而來，不代表網站的實際情況，僅對初學者是一個參考。
1.4.9 有關網站度量Linux企業運維常見面試題
常見面試題如下：
- 請問你們的網站並發是多少？
- 你們公司網站訪問量是多少？怎么計算？
一定要理解IP，PV，並發量這3個點的知識，在回答時才能有的放失，這三個點的多少決定面試時說多大的架構，對於沒有經驗的新手不能在說有幾萬的PV時，還說數十台的集群架構，這樣就烏龍了。
- 運維部分日志分析
- 開發在頁面嵌入JS程序統計收集，分析
- 運營市場通過第三方公司提供的工具程序統計，例如：GA統計
1.5 www服務軟件介紹
1.5.1 www軟件全球使用排名參考
從上述趨勢變化不難發現，Apache雖然份額最大，但是有逐年下降趨勢，而這個Nginx后起之秀上升趨勢顯著，另外，Nginx的分支Tengine也從看不見身影到逐漸占有一定份額了。
1.5.2 當前互聯網主流Web服務說明
常用來提供靜態Web服務的軟件：
- Apache：這是中小型Web服務的主流，Web服務器中的老大哥。
- Nginx：大型網站Web服務主流，曾經Web服務器中的初生牛犢，現已長大。Nginx的分支tengine（http://tengine.taobao.org/）目前也在飛速發展。
- Lighttpd：這是一個不溫不火的優秀的Web軟件，社區不活躍，靜態解析效率很高。在Nginx流行前，它是大並發靜態業務的首選，國內百度貼吧，豆瓣等眾多網站都有lighttpd奮斗的身影。
常用來提供動態服務的軟件
- PHP（fastcgi）：大中小型網站都會使用，動態網頁語言PHP程序的解析容器。它可配合Apache解析動態程序，不過，這里的PHP不是Fastcgi守護進程模式，而是mod_php5.so(module).也可配合Nginx解析動態程序，此時的PHP常用Fastcgi守護進程模式提供服務。
- tomcat:中小企業動態Web服務主流，互聯網Java容器主流（如jsp，do）
- resin：大型動態Web服務主流，互聯網Java容器主流（如jsp，do）
- IIS（internet information services）：微軟Windows下的Web服務軟件（asp，.aspx）
1.5.3 www 靜態程序服務軟件apache
- Apache軟件有幾個重要的版本系列，分別為：Apache1.3，Apache2.0，Apache2.2，Apache2.4等，其中，APache1.3和Apache2.0系列已經成為過去時，官方的網站也看不見其蹤影了，目前主流的Apache為2.2系列，正在向Apache2.4系列過渡階段。如果沒有特別要求，建議讀者當下使用Apache2.2系列。
1.5.4 www靜態服務軟件Nginx
Nginx的版本只有一個系列，但是版本更新很快，僅僅半年就有數個版本，這也看出來社區的活躍程序。具體內容參見文檔地址：http://www.nginx.org/以及http://www.nginx.org/en/docs/
1.5.5 www 動態服務軟件Resin
Resin官方號稱是世界上最快的Web服務，是大型動態Web服務主流，為互聯網Java程序的解析容器，百度，人人都曾用過Resin
目前企業用的較多的是3.1系列，正在向4.0過度
1.5.6 www動態服務軟件tomcat
tomcat一直是中小企業動態Web服務的主流，常用作解析Java的程序的容器，其版本發展變化如下表。
| Servlet/JSP Spec | Apache Tomcat version | Actual release revision | Mininum Java Version |
|---|---|---|---|
| 3.0/2.2 | 7.0.x | 7.0.26 | 1.6 |
| 2.5/2.1 | 6.0.x | 6.0.35 | 1.5 |
| 2.4/2.0 | 5.5.x | 5.5.35 | 1.4 |
| 2.3/1.2 | 4.1.x(archived) | 4.1.40(archived) | 1.3 |
| 2.2/1.1 | 3.3.x(archived) | 3.3.2(archived) | 1.1 |
目前企業使用的主流版本有6系列和7系列，官方也已經推出了更新的8.0系列
tomcat官方地址：
http://tomcat.apache.org/whicheversion.html
http://tomcat.apache.org/
1.5.7 www動態服務軟件PHP
- PHP軟件是大中小型網站程序前台頁面開發的首選，存世開源軟件眾多，也是中小企業網站開發的首選，它是動態網頁語言PHP程序的解析容器。PHP的版本系列有PHP5.2，PHP5.3，PHP5.4，PHP5.5，PHP5.6，其中最經典的版本為PHP5.2系列，企業應用的主流版本可以說是百花爭艷。
- 值得注意的是PHP提供解析的方式，在配合Apache解析動態程序時，用的是mod_php5.so(module)模塊的方式：在配合nginx解析動態程序時，常用Fastcgi守護進程模式提供服務。
1.6 本章重點回顧
- 用戶訪問網站基本流程
- DNS系統解析原理
- HTTP協議通信原理，包括HTTP協議，請求報文，響應報文，狀態碼等相關知識
- 動態，靜態概念特點以及偽靜態技術；
- 動態轉靜態Web優化方案
- IP，PV，UV的概念和區別
- 並發的概念理解
- 了解常用www服務軟件特點，如Apache，Nginx，PHP（Fastcgi），tomcat，Resin等
1.7 本章知識相關面試考試題
1）請描述DNS系統的解析原理？
2）請描述HTTP協議的工作原理？
3）請問你的公司的網站訪問量是多少？
4）請說出http狀態嗎200，301，403，404，500，502，504代表的意義？
附錄1:記錄一次linux線上服務器被黑時間
（1），原因：
本來在家正常休息，突然遠程托管的機房的線上服務器蹦了遠程不了，服務啟動不了，然后讓上海機房重啟了一次，還是直接掛了，一直到我遠程上才行。
（2）現象
遠程服務器發現出現這類信息
Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!
Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!
Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!
Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!
Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!
Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq for further information in regards to your files!
登錄信息
然后翻牆去了國外網站查看
Greetings,
Your server has been hacked and your files have been deleted.
Before they were deleted, we backed them up to a server we control.
You must send a total of 3 BTC to the address: 1B1oU6EdREYffif3**********
Failure to do so will result in your files being deleted after 5 days.
We may also leak your files.
You can e-mail onewayout@sigaint.org for support. We will not give any files before a payment has been made.
Goodbye!
發現被黑！！！
（3）.開始排查：
首先檢查日志，以前做過安全運維，所以寫過類似於檢查命令和工具，開始一一排查。
#查看是否為管理員增加或者修改
find / -type f -perm 4000
#顯示文件中查看是否存在系統以外的文件
rpm -Vf /bin/ls
rpm -Vf /usr/sbin/sshd
rpm -Vf /sbin/ifconfig
rpm -Vf /usr/sbin/lsof
#檢查系統是否有elf文件被替換
#在web目錄下運行
grep -r "getRuntime" ./
#查看是否有木馬
find . -type f -name "*.jsp" | xargs grep -i "getRuntime"
#運行的時候被連接或者被任何程序調用
find . -type f -name "*.jsp" | xargs grep -i "getHostAddress"
#返回ip地址字符串
find . -type f -name "*.jsp" | xargs grep -i "wscript.shell"
#創建WshShell對象可以運行程序、操作注冊表、創建快捷方式、訪問系統文件夾、管理環境變量
find . -type f -name "*.jsp" | xargs grep -i "gethostbyname"
#gethostbyname()返回對應於給定主機名的包含主機名字和地址信息的hostent結構指針
find . -type f -name "*.jsp" | xargs grep -i "bash"
#調用系統命令提權
find . -type f -name "*.jsp" | xargs grep -i "jspspy"
#Jsp木馬默認名字
find . -type f -name "*.jsp" | xargs grep -i "getParameter"
fgrep - R "admin_index.jsp" 20120702.log > log.txt
#檢查是否有非授權訪問管理日志
#要進中間件所在日志目錄運行命令
fgrep - R "and1=1"*.log>log.txt
fgrep - R "select "*.log>log.txt
fgrep - R "union "*.log>log.txt
fgrep - R "../../"*.log >log.txt
fgrep - R "Runtime"*.log >log.txt
fgrep - R "passwd"*.log >log.txt
#查看是否出現對應的記錄
fgrep - R "uname -a"*.log>log.txt
fgrep - R "id"*.log>log.txt
fgrep - R "ifconifg"*.log>log.txt
fgrep - R "ls -l"*.log>log.txt
#查看是否有shell攻擊
#以root權限執行
cat /var/log/secure
#查看是否存在非授權的管理信息
tail -n 10 /var/log/secure
last cat /var/log/wtmp
cat /var/log/sulog
#查看是否有非授權的su命令
cat /var/log/cron
#查看計划任務是否正常
tail -n 100 ~./bash_history | more
查看臨時目錄是否存在攻擊者入侵時留下的殘余文件
ls -la /tmp
ls -la /var/tmp
#如果存在.c .py .sh為后綴的文件或者2進制elf文件。
Apr 17 03:14:56 localhost sshd[11499]: warning: /etc/hosts.deny, line 14: missing ":" separator
Apr 17 03:15:01 localhost sshd[11499]: Address 46.214.146.198 maps to 46-214-146-198.next-gen.ro, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 17 03:15:01 localhost sshd[11499]: Invalid user ubnt from 46.214.146.198
Apr 17 03:15:01 localhost sshd[11500]: input_userauth_request: invalid user ubnt
Apr 17 03:15:01 localhost sshd[11499]: pam_unix(sshd:auth): check pass; user unknown
Apr 17 03:15:01 localhost sshd[11499]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=46.214.146.198
Apr 17 03:15:01 localhost sshd[11499]: pam_succeed_if(sshd:auth): error retrieving information about user ubnt
Apr 17 03:15:03 localhost sshd[11499]: Failed password for invalid user ubnt from 46.214.146.198 port 34989 ssh2
Apr 17 03:15:03 localhost sshd[11500]: Connection closed by 46.214.146.198
應該就是他了，查看歷史記錄
日志發現Invalid user ubnt from 46.214.146.198
歷史記錄和相關訪問日志已經刪除，痕跡清除
發現沒有異常
打開vi /etc/motd 發現
查找不出后門也找不到相關命令，感覺思路受損，暈頭轉向。
最后查找下單天的web訪問日志和相關ip訪問
發現一條命令讓我好奇，GET /cgi-bin/center.cgi?id=20
HTTP/1.1 ，並且有點異常
感覺很像目前流行的bash shell漏洞，測試一下，果然存在漏洞
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
[root@mall ~]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
(4) 修復升級命令
yum -y install yum-downloadonly
yum -y install bash-4.1.2-33.el6_7.1x86_64.rpm
(5)完成后做了如下措施
- 修改了系統賬戶密碼
- 修改了sshd端口為2220
- 修改了nginx用戶nologin
- 發現系統服務器存在bash嚴重漏洞 破殼漏洞（Shellshock）並修復。
- 更新完成后后面沒有發現入侵或者服務器自動掛機現象
（6）漏洞被利用過程
我發送GET請求-->目標服務器cgi路徑
目標服務器解析這個get請求，碰到UserAgent后面的參數，Bash解釋器就執行了后面的命令
（7）Shellshock介紹
Shellshock，又稱Bashdoor，是在Unix中廣泛使用的Bash shell中的一個安全漏洞，首次於2014年9月24日公開。許多互聯網守護進程，如網頁服務器，使用bash來處理某些命令，從而允許攻擊者在易受攻擊的Bash版本上執行任意代碼。這可使攻擊者在未授權的情況下訪問計算機系統。