[[203888]]

又到了一年一度的秋招，作為運(yùn)維方向，看了一些面經(jīng)，收集了一些筆試面試題，總結(jié)了一下，貼出來(lái)僅供參考，有錯(cuò)誤的地方還請(qǐng)指出。

1.Linux設(shè)置環(huán)境變量

暫時(shí)的：export MYNAME=”new name”

echo $MYNAME

new name

永久的：通過(guò)改變/etc/profile實(shí)現(xiàn)

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

更改文件后執(zhí)行 source /etc/profile

2.TCP連接的特點(diǎn)

(1)面向連接：采用C/S模型

(2)全雙工

(3)安全可靠：

①流量控制：解決接收方不能不及時(shí)處理數(shù)據(jù)的問(wèn)題

②擁塞控制：解決因網(wǎng)絡(luò)通信延遲帶來(lái)的數(shù)據(jù)丟失問(wèn)題

③差錯(cuò)控制：解決數(shù)據(jù)被破壞、重復(fù)、時(shí)序和丟失的問(wèn)題

(4)基于字節(jié)流

3.為什么TCP連接需要三次握手，兩次不可以嗎?為什么?

兩次不可以

三次握手連接過(guò)程

(1)建立連接時(shí)，客戶端發(fā)送SYN(SYN=j)包到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器響應(yīng)、、確認(rèn)

(2)服務(wù)器收到SYN包，必須確認(rèn)客戶端的SYN(ACK=j+1)，同時(shí)自己也發(fā)送一個(gè)SYN包，即SYN+ACK包此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)

(3)客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢客戶端和服務(wù)器端進(jìn)入ESTABLISHED狀態(tài)，完成三次握手

為了保證服務(wù)端能收到客戶端的信息并能做出正確的響應(yīng)而進(jìn)行前兩次握手，為了保證客戶端能夠收到服務(wù)端的信息并能做出正確的響應(yīng)而進(jìn)行后兩次響應(yīng)

4、代理的實(shí)現(xiàn)原理

代理服務(wù)器有很多種，大體分為三類：HTTP、FTP、SOCKS，其中又分為透明代理和不透明代理，透明代理一般是網(wǎng)關(guān)，為硬件

過(guò)程：

(1)客戶端先和代理服務(wù)器通訊，建立TCP連接，目的IP是代理服務(wù)器的IP

(2)客戶端發(fā)出GET命令，GET命令中包含URL或IP地址、明文

(3)代理服務(wù)器將其中的URL轉(zhuǎn)換為IP地址，可能會(huì)有DNS，將源數(shù)據(jù)包中的數(shù)據(jù)拷貝下來(lái)，去掉URL，重新組包再發(fā)出去

(4)代理服務(wù)器和真實(shí)服務(wù)器通訊，源IP是代理服務(wù)器的IP

5、TCP和UDP分別有什么優(yōu)缺點(diǎn)

TCP：

優(yōu)點(diǎn)：可靠、穩(wěn)定

TCP的可靠體現(xiàn)在TCP在傳輸數(shù)據(jù)之前，會(huì)有三次握手來(lái)建立連接，而且在數(shù)據(jù)傳遞時(shí)，有確認(rèn)、窗口、重傳、擁塞控制機(jī)制，在數(shù)據(jù)傳完之后，還會(huì)斷開連接用來(lái)節(jié)約系統(tǒng)資源

缺點(diǎn)：慢，效率低，占用系統(tǒng)資源高，易被攻擊

在傳遞數(shù)據(jù)之前要先建立連接，這會(huì)消耗時(shí)間，而且在數(shù)據(jù)傳遞時(shí)，確認(rèn)機(jī)制、重傳機(jī)制、擁塞機(jī)制等都會(huì)消耗大量時(shí)間，而且要在每臺(tái)設(shè)備上維護(hù)所有的傳輸連接。然而，每個(gè)鏈接都會(huì)占用系統(tǒng)的CPU、內(nèi)存等硬件資源。因?yàn)門CP有確認(rèn)機(jī)制、三次握手機(jī)制，這些也導(dǎo)致TCP容易被利用，實(shí)現(xiàn)DOS、DDOS、CC等攻擊

UDP：

優(yōu)點(diǎn)：快,比TCP稍安全

UDPm沒(méi)有TCP擁有的各種機(jī)制，是一個(gè)無(wú)狀態(tài)的傳輸協(xié)議，所以傳遞數(shù)據(jù)非?？欤瑳](méi)有TCP的這些機(jī)制，被攻擊利用的機(jī)制就少一些，但是也無(wú)法避免被攻擊

缺點(diǎn)：不可靠，不穩(wěn)定

因?yàn)闆](méi)有TCP的那些機(jī)制，UDP在傳輸數(shù)據(jù)時(shí)，如果網(wǎng)絡(luò)質(zhì)量不好，就會(huì)很容易丟包，造成數(shù)據(jù)的缺失

適用場(chǎng)景：

TCP：當(dāng)對(duì)網(wǎng)絡(luò)通訊質(zhì)量有要求時(shí)，比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議， POP、SMTP等郵件傳輸?shù)膮f(xié)議

UDP：對(duì)網(wǎng)絡(luò)通訊質(zhì)量要求不高時(shí)，要求網(wǎng)絡(luò)通訊速度要快的場(chǎng)景

6、面向?qū)ο蠛兔嫦蜻^(guò)程的區(qū)別

面向過(guò)程就是分析出解決問(wèn)題所需要的步驟，然后用函數(shù)把這些步驟一步一步實(shí)現(xiàn)，使用的時(shí)候一個(gè)一個(gè)依次調(diào)用就行。

面向?qū)ο笫前褬?gòu)成問(wèn)題事物分解成各個(gè)對(duì)象，建立對(duì)象的目的不是為了完成一個(gè)步驟，而是為了描述某個(gè)事物在整個(gè)解決問(wèn)題的步驟中的行為。面向?qū)ο笫且怨δ軄?lái)劃分問(wèn)題，而不是步驟

7、HTTP請(qǐng)求的過(guò)程與原理

HTTP是一種無(wú)狀態(tài)的，指的是協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。也就是說(shuō)，打開一個(gè)服務(wù)器上的網(wǎng)頁(yè)和你之前打開這個(gè)服務(wù)器上的網(wǎng)頁(yè)之間沒(méi)有任何聯(lián)系。HTTP遵循請(qǐng)求/應(yīng)答模型

(1)建立TCP連接

(2)Web瀏覽器向Web服務(wù)器發(fā)送請(qǐng)求命令

(3)Web瀏覽器發(fā)送請(qǐng)求頭信息

(4)Web服務(wù)器應(yīng)答

(5)Web服務(wù)器發(fā)送應(yīng)答頭信息

(6)Web服務(wù)器向?yàn)g覽器發(fā)送數(shù)據(jù)

(7)Web服務(wù)器關(guān)閉TCP連接

HTTP的長(zhǎng)連接與短連接：

在HTTP/1.0中，默認(rèn)使用的是短連接。也就是說(shuō)，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接，在服務(wù)端不保留連接的有關(guān)信息。

從 HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議，會(huì)在響應(yīng)頭有加入這行代碼：

Connection:keep-alive

在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件(如Apache)中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接要客戶端和服務(wù)端都支持長(zhǎng)連接。

HTTP協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。

長(zhǎng)連接短連接操作過(guò)程

短連接的操作步驟：

建立連接----數(shù)據(jù)傳輸-----關(guān)閉連接。。。建立連接-----數(shù)據(jù)傳輸----關(guān)閉連接

長(zhǎng)連接的操作步驟：

建立連接---數(shù)據(jù)傳輸。。(保持連接)。。數(shù)據(jù)傳輸---關(guān)閉連接

長(zhǎng)連接和短連接的優(yōu)點(diǎn)和缺點(diǎn)

長(zhǎng)連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費(fèi)，節(jié)約時(shí)間。對(duì)于頻繁請(qǐng)求資源的客戶來(lái)說(shuō)，較適用長(zhǎng)連接。但是會(huì)存在一個(gè)問(wèn)題，隨著客戶端連接越來(lái)越多，server早晚有扛不住的時(shí)候，這時(shí)候server端需要采取一些策略，如關(guān)閉一些長(zhǎng)時(shí)間沒(méi)有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損;如果條件再允許就可以以客戶端機(jī)器為顆粒度，限制每個(gè)客戶端的最大長(zhǎng)連接數(shù)，這樣可以完全避免某一個(gè)客戶端連累后端服務(wù)。

短連接對(duì)于服務(wù)器來(lái)說(shuō)管理較為簡(jiǎn)單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請(qǐng)求頻繁，將在TCP的建立和關(guān)閉操作上浪費(fèi)時(shí)間和帶寬。

HTTP報(bào)文格式：

請(qǐng)求消息格式：

• 請(qǐng)求行

• 頭部行

• 附屬行

響應(yīng)消息格式：

• 狀態(tài)行

• 頭部行

8、常見HTTP狀態(tài)碼

成功的狀態(tài)碼(基本以2開頭)：這一類型的狀態(tài)碼，代表請(qǐng)求已成功被服務(wù)器接收、理解、并接受

200--請(qǐng)求已成功，請(qǐng)求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回

202--服務(wù)器已接受請(qǐng)求，但尚未處理

205--服務(wù)器成功處理了請(qǐng)求，且沒(méi)有返回任何內(nèi)容

內(nèi)容被重定向(基本以3開頭)：需要客戶端采取進(jìn)一步的操作才能完成請(qǐng)求

301--被請(qǐng)求的資源已永久移動(dòng)到新位置

302--請(qǐng)求的資源臨時(shí)從不同的 URI響應(yīng)請(qǐng)求

303--對(duì)應(yīng)當(dāng)前請(qǐng)求的響應(yīng)可以在另一個(gè) URI 上被找到，而且客戶端應(yīng)當(dāng)采用 GET 的方式訪問(wèn)那個(gè)資源

305--被請(qǐng)求的資源必須通過(guò)指定的代理才能被訪問(wèn)

307--請(qǐng)求的資源臨時(shí)從不同的URI 響應(yīng)請(qǐng)求

請(qǐng)求失敗的狀態(tài)碼(基本以4開頭)：

400--語(yǔ)義有誤，當(dāng)前請(qǐng)求無(wú)法被服務(wù)器理解。除非進(jìn)行修改，否則客戶端不應(yīng)該重復(fù)提交這個(gè)請(qǐng)求或者請(qǐng)求參數(shù)有誤

401--當(dāng)前請(qǐng)求需要用戶驗(yàn)證

403--服務(wù)器已經(jīng)理解請(qǐng)求，但是拒絕執(zhí)行

404--請(qǐng)求的網(wǎng)頁(yè)不存在

405--請(qǐng)求行中指定的請(qǐng)求方法不能被用于請(qǐng)求相應(yīng)的資源

408--請(qǐng)求超時(shí)

服務(wù)器端的錯(cuò)誤(基本以5開頭)：了服務(wù)器在處理請(qǐng)求的過(guò)程中有錯(cuò)誤或者異常狀態(tài)發(fā)生

500--服務(wù)器內(nèi)部錯(cuò)誤

503--服務(wù)器暫時(shí)不可用

9、什么是死鎖

進(jìn)程死鎖，它是操作系統(tǒng)或系統(tǒng)軟件運(yùn)行的一種狀態(tài)：在多任務(wù)系統(tǒng)下，當(dāng)一個(gè)或多個(gè)進(jìn)程等待系統(tǒng)資源，而資源又被進(jìn)程本身或其他進(jìn)程占用時(shí)，就形成了死鎖

產(chǎn)生死鎖的原因：

①系統(tǒng)資源不足

②進(jìn)程運(yùn)行推進(jìn)的順序不合適

③資源分配不當(dāng)?shù)?/p>

產(chǎn)生死鎖的四個(gè)必要條件：

①互斥條件：一個(gè)資源每次只能被一個(gè)進(jìn)程使用

②請(qǐng)求與保持條件：一個(gè)進(jìn)程因請(qǐng)求資源而阻塞時(shí)，對(duì)已獲得的資源保持不放

③不剝奪條件：進(jìn)程已獲得的資源，在未使用完之前，不能強(qiáng)行剝奪

④循環(huán)等待條件：若干進(jìn)程之間形成一種頭尾相連的循環(huán)等待資源關(guān)系

避免死鎖的方法：

①有序的資源分配法

②銀行家算法

解決死鎖：

①進(jìn)行系統(tǒng)的重新啟動(dòng)(最簡(jiǎn)單粗暴)

②撤銷進(jìn)程，剝奪資源

銀行家算法

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

我們可以把操作系統(tǒng)看作是銀行家，操作系統(tǒng)管理的資源相當(dāng)于銀行家管理的資金，進(jìn)程向操作系統(tǒng)請(qǐng)求分配資源相當(dāng)于用戶向銀行家貸款。操作系統(tǒng)按照銀行家制定的規(guī)則為進(jìn)程分配資源，當(dāng)進(jìn)程首次申請(qǐng)資源時(shí)，要測(cè)試該進(jìn)程對(duì)資源的最大需求量，如果系統(tǒng)現(xiàn)存的資源可以滿足它的最大需求量則按當(dāng)前的申請(qǐng)量分配資源，否則就推遲分配。當(dāng)進(jìn)程在執(zhí)行中繼續(xù)申請(qǐng)資源時(shí)，先測(cè)試該進(jìn)程已占用的資源數(shù)與本次申請(qǐng)的資源數(shù)之和是否超過(guò)了該進(jìn)程對(duì)資源的最大需求量。若超過(guò)則拒絕分配資源，若沒(méi)有超過(guò)則再測(cè)試系統(tǒng)現(xiàn)存的資源能否滿足該進(jìn)程尚需的最大資源量，若能滿足則按當(dāng)前的申請(qǐng)量分配資源，否則也要推遲分配。

10、close_wait

在被動(dòng)關(guān)閉連接的情況下，在已經(jīng)接收到FIN，但是還沒(méi)有發(fā)送自己FIN的時(shí)刻，連接處于close_wait狀態(tài)。通常來(lái)講，close_wait狀態(tài)持續(xù)的時(shí)間應(yīng)該很短，如SYN_RECV狀態(tài)，但是在一些特殊情況下，就會(huì)出現(xiàn)連接長(zhǎng)時(shí)間處于close_wait狀態(tài)的情況。出現(xiàn)大量close_wait的現(xiàn)象，主要原因是某種情況下對(duì)方關(guān)閉了socket連接，但是我方忙于讀或者寫。沒(méi)有關(guān)閉連接，代碼需要判斷socket，一旦讀到0，斷開連接，read返回負(fù)，檢查一下errno，如果不是AGAIN，就斷開連接。

11、time_wait

主動(dòng)關(guān)閉的socket端會(huì)進(jìn)入此狀態(tài)，并且持續(xù)2MSL(最大分節(jié)生命期)時(shí)間長(zhǎng)度，這是一個(gè)IP數(shù)據(jù)包能在互聯(lián)網(wǎng)上生存的最長(zhǎng)時(shí)間，超過(guò)這個(gè)時(shí)間將在網(wǎng)絡(luò)消失。

作用：

a：可靠的實(shí)現(xiàn)TCP全雙工連接的終止

b：允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消失

12、進(jìn)程間通信機(jī)制

管道、消息隊(duì)列、共享內(nèi)存(速度最快)、信號(hào)量、文件映射、匿名/命名管道