十二條Linux運維面試必備經典筆試/面試題，來挑戰一下

又到了一年一度的秋招，做爲運維方向，看了一些面經，收集了一些筆試面試題，總結了一下，貼出來僅供參考，有錯誤的地方還請指出.

1.Linux設置環境變量

暫時的：export MYNAME=」new name」

echo $MYNAME

new name

永久的：經過改變/etc/profile實現

EG: export CLASSPATH=./java_HOME/lib;$JAVA_HOME/jre/lib

更改文件後執行 source  /etc/profile

2.TCP鏈接的特色

（1）面向鏈接：採用C/S模型

（2）全雙工

（3）安全可靠：①流量控制：解決接收方不能不及時處理數據的問題

               ②擁塞控制：解決因網絡通訊延遲帶來的數據丟失問題

               ③差錯控制：解決數據被破壞、重複、時序和丟失的問題

（4）基於字節流

3.爲何TCP鏈接須要三次握手，兩次不能夠嗎？爲何？

兩次不能夠

三次握手鍊接過程

（1）創建鏈接時，客戶端發送SYN（SYN=j）包到服務器，並進入SYN_SEND狀態，等待服務器響應、、確認

（2）服務器收到SYN包，必須確認客戶端的SYN（ACK=j+1），同時本身也發送一個SYN包，即SYN+ACK包此時服務器進入SYN_RECV狀態

（3）客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK（ack=k+1），此包發送完畢客戶端和服務器端進入ESTABLISHED狀態，完成三次握手

爲了保證服務端能收到客戶端的信息並能作出正確的響應而進行前兩次握手，爲了保證客戶端可以收到服務端的信息並能作出正確的響應而進行後兩次響應

四、代理的實現原理

代理服務器有不少種，大致分爲三類：HTTP、FTP、SOCKS，其中又分爲透明代理和不透明代理，透明代理通常是網關，爲硬件

過程：

（1）客戶端先和代理服務器通信，創建TCP鏈接，目的IP是代理服務器的IP

（2）客戶端發出GET命令，GET命令中包含URL或IP地址、明文

（3）代理服務器將其中的URL轉換爲IP地址，可能會有DNS，將源數據包中的數據拷貝下來，去掉URL，從新組包再發出去

（4）代理服務器和真實服務器通信，源IP是代理服務器的IP

五、TCP和UDP分別有什麼優缺點

TCP：

優勢：可靠、穩定

TCP的可靠體如今TCP在傳輸數據以前，會有三次握手來創建鏈接，並且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完以後，還會斷開鏈接用來節約系統資源

缺點：慢，效率低，佔用系統資源高，易被***

在傳遞數據以前要先創建鏈接，這會消耗時間，並且在數據傳遞時，確認機制、重傳機制、擁塞機制等都會消耗大量時間，並且要在每臺設備上維護全部的傳輸鏈接。然而，每一個連接都會佔用系統的CPU、內存等硬件資源。由於TCP有確認機制、三次握手機制，這些也致使TCP容易被利用，實現DOS、DDOS、CC等***

UDP：

優勢：快,比TCP稍安全

UDPm沒有TCP擁有的各類機制，是一個無狀態的傳輸協議，因此傳遞數據很是快，沒有TCP的這些機制，被***利用的機制就少一些，可是也沒法避免被***

缺點：不可靠，不穩定

由於沒有TCP的那些機制，UDP在傳輸數據時，若是網絡質量很差，就會很容易丟包，形成數據的缺失

適用場景：

TCP：當對網絡通信質量有要求時，好比HTTP、HTTPS、FTP等傳輸文件的協議，                              POP、SMTP等郵件傳輸的協議

UDP：對網絡通信質量要求不高時，要求網絡通信速度要快的場景

六、面向對象和麪向過程的區別

面向過程就是分析出解決問題所須要的步驟，而後用函數把這些步驟一步一步實現，使用的時候一個一個依次調用就行。

面向對象是把構成問題事物分解成各個對象，創建對象的目的不是爲了完成一個步驟，而是爲了描述某個事物在整個解決問題的步驟中的行爲。面向對象是以功能來劃分問題，而不是步驟

七、HTTP請求的過程與原理

HTTP是一種無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和你以前打開這個服務器上的網頁之間沒有任何聯繫。HTTP遵循請求/應答模型

（1）創建TCP鏈接

（2）Web瀏覽器向Web服務器發送請求命令

（3）Web瀏覽器發送請求頭信息

（4）Web服務器應答

（5）Web服務器發送應答頭信息

（6）Web服務器向瀏覽器發送數據

（7）Web服務器關閉TCP鏈接

HTTP的長鏈接與短鏈接：

在HTTP/1.0中，默認使用的是短鏈接。也就是說，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，但任務結束就中斷鏈接，在服務端不保留鏈接的有關信息。

從 HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的HTTP協議，會在響應頭有加入這行代碼：

Connection:keep-alive

在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的 TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。實現長鏈接要客戶端和服務端都支持長鏈接。

HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

長鏈接短鏈接操做過程

短鏈接的操做步驟：

創建鏈接----數據傳輸-----關閉鏈接。。。創建鏈接-----數據傳輸----關閉鏈接

長鏈接的操做步驟：

創建鏈接---數據傳輸。。（保持鏈接）。。數據傳輸---關閉鏈接

長鏈接和短鏈接的優勢和缺點

長鏈接能夠省去較多的TCP創建和關閉的操做，減小浪費，節約時間。對於頻繁請求資源的客戶來講，較適用長鏈接。可是會存在一個問題，隨着客戶端鏈接愈來愈多，server遲早有扛不住的時候，這時候server端須要採起一些策略，如關閉一些長時間沒有讀寫事件發生的鏈接，這樣能夠避免一些惡意鏈接致使server端服務受損；若是條件再容許就能夠以客戶端機器爲顆粒度，限制每一個客戶端的最大長鏈接數，這樣能夠徹底避免某一個客戶端連累後端服務。

短鏈接對於服務器來講管理較爲簡單，存在的鏈接都是有用的鏈接，不須要額外的控制手段。但若是客戶請求頻繁，將在TCP的創建和關閉操做上浪費時間和帶寬。

HTTP報文格式：

請求消息格式：請求行

頭部行

附屬行

響應消息格式：狀態行

頭部行

八、常見HTTP狀態碼

成功的狀態碼(基本以2開頭)：這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受

200--請求已成功，請求所但願的響應頭或數據體將隨此響應返回

202--服務器已接受請求，但還沒有處理

205--服務器成功處理了請求，且沒有返回任何內容

內容被重定向（基本以3開頭）：須要客戶端採起進一步的操做才能完成請求

301--被請求的資源已永久移動到新位置

302--請求的資源臨時從不一樣的 URI響應請求

303--對應當前請求的響應能夠在另外一個 URI 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源

305--被請求的資源必須經過指定的代理才能被訪問

307--請求的資源臨時從不一樣的URI 響應請求

請求失敗的狀態碼（基本以4開頭）：

400--語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求或者請求參數有誤

401--當前請求須要用戶驗證

403--服務器已經理解請求，可是拒絕執行

404--請求的網頁不存在

405--請求行中指定的請求方法不能被用於請求相應的資源

408--請求超時

服務器端的錯誤（基本以5開頭）：了服務器在處理請求的過程當中有錯誤或者異常狀態發生

500--服務器內部錯誤

503--服務器暫時不可用

九、什麼是死鎖

進程死鎖，它是操做系統或系統軟件運行的一種狀態：在多任務系統下，當一個或多個進程等待系統資源，而資源又被進程自己或其餘進程佔用時，就造成了死鎖

        產生死鎖的緣由：①系統資源不足

                ②進程運行推動的順序不合適

                ③資源分配不當等

產生死鎖的四個必要條件：

①互斥條件：一個資源每次只能被一個進程使用

②請求與保持條件：一個進程因請求資源而阻塞時，對已得到的資源保持不放

③不剝奪條件：進程已得到的資源，在未使用完以前，不能強行剝奪

④循環等待條件：若干進程之間造成一種頭尾相連的循環等待資源關係

避免死鎖的方法：①有序的資源分配法

                ②銀行家算法

解決死鎖：①進行系統的從新啓動（最簡單粗暴）

          ②撤銷進程，剝奪資源

銀行家算法

銀行家算法是一種最有表明性的避免死鎖的算法

咱們能夠把操做系統看做是銀行家，操做系統管理的資源至關於銀行家管理的資金，進程向操做系統請求分配資源至關於用戶向銀行家貸款。操做系統按照銀行家制定的規則爲進程分配資源，當進程首次申請資源時，要測試該進程對資源的最大需求量，若是系統現存的資源能夠知足它的最大需求量則按當前的申請量分配資源，不然就推遲分配。當進程在執行中繼續申請資源時，先測試該進程已佔用的資源數與本次申請的資源數之和是否超過了該進程對資源的最大需求量。若超過則拒絕分配資源，若沒有超過則再測試系統現存的資源可否知足該進程尚需的最大資源量，若能知足則按當前的申請量分配資源，不然也要推遲分配。

十、close_wait

在被動關閉鏈接的狀況下，在已經接收到FIN，可是尚未發送本身FIN的時刻，鏈接處於close_wait狀態。一般來說，close_wait狀態持續的時間應該很短，如SYN_RECV狀態，可是在一些特殊狀況下，就會出現鏈接長時間處於close_wait狀態的狀況。出現大量close_wait的現象，主要緣由是某種狀況下對方關閉了socket鏈接，可是我方忙於讀或者寫。沒有關閉鏈接，代碼須要判斷socket，一旦讀到0，斷開鏈接，read返回負，檢查一下errno，若是不是AGAIN，就斷開鏈接。

十一、time_wait

主動關閉的socket端會進入此狀態，而且持續2MSL（最大分節生命期）時間長度，這是一個IP數據包能在互聯網上生存的最長時間，超過這個時間將在網絡消失。

做用：

a：可靠的實現TCP全雙工鏈接的終止

b：容許老的重複分節在網絡中消失

十二、進程間通訊機制

管道、消息隊列、共享內存（速度最快）、信號量、文件映射、匿名/命名管道

做者：11944248

來源：http://11954248.blog.51cto.com/11944248/1965927