首頁 > 軟體

Linux運維工程師12道面試題整理

2020-06-16 16:47:48

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狀態,完成三次握手

為了保證伺服器端能收到用戶端的資訊並能做出正確的響應而進行前兩次握手,為了保證用戶端能夠收到伺服器端的資訊並能做出正確的響應而進行後兩次響應

4、代理的實現原理

代理伺服器有很多種,大體分為三類:HTTP、FTP、SOCKS,其中又分為透明代理和不透明代理,透明代理一般是閘道器,為硬體

過程:

(1)用戶端先和代理伺服器通訊,建立TCP連線,目的IP是代理伺服器的IP

(2)用戶端發出GET命令,GET命令中包含URL或IP地址、明文

(3)代理伺服器將其中的URL轉換為IP地址,可能會有DNS,將源封包中的資料拷貝下來,去掉URL,重新組包再發出去

(4)代理伺服器和真實伺服器通訊,源IP是代理伺服器的IP

5、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:對網路通訊品質要求不高時,要求網路通訊速度要快的場景

6、物件導向和程序導向的區別

程序導向就是分析出解決問題所需要的步驟,然後用函數把這些步驟一步一步實現,使用的時候一個一個依次呼叫就行。

物件導向是把構成問題事物分解成各個物件,建立物件的目的不是為了完成一個步驟,而是為了描述某個事物在整個解決問題的步驟中的行為。物件導向是以功能來劃分問題,而不是步驟

7、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報文格式:

請求訊息格式:

  • 請求行

  • 頭部行

  • 附屬行

響應訊息格式:

  • 狀態行

  • 頭部行

8、常見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--伺服器暫時不可用

9、什麼是死鎖

進程死鎖,它是作業系統或系統軟體執行的一種狀態:在多工系統下,當一個或多個進程等待系統資源,而資源又被進程本身或其他進程佔用時,就形成了死鎖

產生死鎖的原因:

①系統資源不足

②進程執行推進的順序不合適

③資源分配不當等

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

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

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

③不剝奪條件:進程已獲得的資源,在未使用完之前,不能強行剝奪

④迴圈等待條件:若干進程之間形成一種頭尾相連的迴圈等待資源關係

避免死鎖的方法:

①有序的資源分配法

②銀行家演算法

解決死鎖:

①進行系統的重新啟動(最簡單粗暴)

②復原進程,剝奪資源

銀行家演算法

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

我們可以把作業系統看作是銀行家,作業系統管理的資源相當於銀行家管理的資金,進程向作業系統請求分配資源相當於使用者向銀行家貸款。作業系統按照銀行家制定的規則為進程分配資源,當進程首次申請資源時,要測試該進程對資源的最大需求量,如果系統現存的資源可以滿足它的最大需求量則按當前的申請量分配資源,否則就推遲分配。當進程在執行中繼續申請資源時,先測試該進程已佔用的資源數與本次申請的資源數之和是否超過了該進程對資源的最大需求量。若超過則拒絕分配資源,若沒有超過則再測試系統現存的資源能否滿足該進程尚需的最大資源量,若能滿足則按當前的申請量分配資源,否則也要推遲分配。

10、close_wait

在被動關閉連線的情況下,在已經接收到FIN,但是還沒有傳送自己FIN的時刻,連線處於close_wait狀態。通常來講,close_wait狀態持續的時間應該很短,如SYN_RECV狀態,但是在一些特殊情況下,就會出現連線長時間處於close_wait狀態的情況。出現大量close_wait的現象,主要原因是某種情況下對方關閉了socket連線,但是我方忙於讀或者寫。沒有關閉連線,程式碼需要判斷socket,一旦讀到0,斷開連線,read返回負,檢查一下errno,如果不是AGAIN,就斷開連線。

11、time_wait

主動關閉的socket端會進入此狀態,並且持續2MSL(最大分節生命期)時間長度,這是一個IP封包能在網際網路上生存的最長時間,超過這個時間將在網路消失。

作用:

a:可靠的實現TCP全雙工連線的終止

b:允許老的重複分節在網路中消失

12、進程間通訊機制

管道、訊息佇列、共用記憶體(速度最快)、號誌、檔案對映、匿名/命名管道

Linux公社的RSS地址:https://www.linuxidc.com/rssFeed.aspx

本文永久更新連結地址https://www.linuxidc.com/Linux/2018-08/153700.htm


IT145.com E-mail:sddin#qq.com