第二十六節 http協議原理
標籤（空格分隔）： Linux實戰教學筆記-陳思齊javascript
---本教學筆記是本人學習和工做生涯中的摘記整理而成，此爲初稿（尚有諸多不完善之處），爲原創做品，容許轉載，轉載時請務必以超連接形式標明文章原始出處，做者信息和本聲明。不然將追究法律責任。http://www.cnblogs.com/chensiqiqi/php
第1章 Web服務基礎
1.1 http服務重要基礎
1.1.1 用戶訪問網站基本流程
- 咱們天天都會使用Web客戶端上網瀏覽網頁。最多見的Web客戶端就是Web瀏覽器，如通用的微軟Internet Explorer（IE）以及技術人員偏心的火狐瀏覽器，谷歌瀏覽器等。當咱們在Web瀏覽器裏輸入網站地址（例如：www.baidu.com）時，很快就會看到網站的內容。這看起來很神奇的背後，究竟是怎樣的實現流程呢？也許普通的上網者無需關注，但做爲一個IT技術人員，特別是合格的Linux運維人員，就須要清晰的掌握了。
-
下面就給你們介紹從客戶端用戶在Web瀏覽器裏輸入網站地址，到看到網站內容的完整訪問流程。css
-
[x] 第一步：客戶端用戶從瀏覽器裏輸入www.baidu.com網站地址，回車後，系統首先會查找系統本地的DNS緩存及hosts文件信息，查找是否存在www.baidu.com域名對應的IP解析記錄，若是有就直接獲取IP地址，而後去訪問這個IP地址對應域名www.baidu.com的服務器，通常第一次請求時，DNS緩存是沒有解析記錄的，而hosts多在內部臨時測試時使用。html
-
[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域名作解析設置，即網站還沒架設好。java
-
[x] 第四步：baidu.com域名的受權DNS服務器會把www.baidu.com對應的最終IP解析記錄發給LDNS。linux
-
[x] 第五步：LDNS把收到的來自受權DNS服務器www.baidu.com對應的IP解析記錄發給客戶端瀏覽器，而且再LDNS把本地域名和IP的對應解析緩存起來，以便下一次更快的返回相同解析請求的記錄，這些緩存記錄在指定的時間（DNS TTL值控制）內不會過時。nginx
-
[x] 第六步：客戶端瀏覽器獲取到了www.etiantian.org的對應IP地址，接下來，瀏覽器會請求得到的IP地址對應的網站服務器，網站服務器接收到客戶端的請求並響應處理（此處的處理多是數百臺集羣的服務器系統，也多是一臺雲主機），將客戶請求的內容返回給客戶端瀏覽器，至此，一次訪問瀏覽網頁的完整過程就完成了。web
提示：
上述僅僅是客戶端用戶第一次訪問網站的基本過程，連續訪問後，系統本地和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系列。
官方地址：http://www.apache.org/
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!
登陸信息
而後FQ去了國外網站查看
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版本上執行任意代碼。這可以使攻擊者在未受權的狀況下訪問計算機系統。