1. 應(yīng)用層

1.1 http協(xié)議格式是什么

請(qǐng)求報(bào)文格式：請(qǐng)求行、請(qǐng)求頭、空一行、請(qǐng)求體

請(qǐng)求行包括：請(qǐng)求方法、統(tǒng)一資源定位符（URL）、http協(xié)議及版本

響應(yīng)報(bào)文格式：狀態(tài)行、響應(yīng)頭、空一行、響應(yīng)體

狀態(tài)行包括：協(xié)議及版本、狀態(tài)碼、狀態(tài)碼解釋

1.2 http和https的區(qū)別

http：由于http是明文傳輸，所以其安全性低，易受攻擊，無(wú)法確認(rèn)對(duì)方的身份，也無(wú)法確保數(shù)據(jù)的完整性；http協(xié)議默認(rèn)端口號(hào)是80端口；它的優(yōu)點(diǎn)是簡(jiǎn)單快速，使用很靈活；http服務(wù)器的程序規(guī)模小所以通信速度很快；與https相比，http沒(méi)有額外的費(fèi)用。

https：由于https使用ssh加密傳輸協(xié)議，信息是密文，所以它的安全性高，可以認(rèn)證雙方的身份，防止信息被截取篡改；https協(xié)議默認(rèn)端口號(hào)是443端口；它會(huì)加重服務(wù)器負(fù)擔(dān)，需要資源來(lái)支撐，降低用戶的訪問(wèn)速度。

1.3 http常見(jiàn)狀態(tài)碼

1.4 cookie和session的區(qū)別

• 數(shù)據(jù)存放位置不同：cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。

• 安全程度不同：cookie不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙,考慮到安全應(yīng)當(dāng)使用session。

• 性能使用程度不同：session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問(wèn)增多，會(huì)比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。

• 數(shù)據(jù)存儲(chǔ)大小不同：?jiǎn)蝹€(gè)cookie保存的數(shù)據(jù)不能超過(guò)4K，很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie，而session則存儲(chǔ)與服務(wù)端，瀏覽器對(duì)其沒(méi)有限制。

• 會(huì)話機(jī)制不同：session會(huì)話機(jī)制：session會(huì)話機(jī)制是一種服務(wù)器端機(jī)制，它使用類似于哈希表（可能還有哈希表）的結(jié)構(gòu)來(lái)保存信息。cookies會(huì)話機(jī)制：cookie是服務(wù)器存儲(chǔ)在本地計(jì)算機(jī)上的小塊文本，并隨每個(gè)請(qǐng)求發(fā)送到同一服務(wù)器。

1.5 get和post的區(qū)別

他們本質(zhì)都是TCP連接，并無(wú)區(qū)別，但是由于http的規(guī)定以及瀏覽器和服務(wù)器的限制，導(dǎo)致他們?cè)趹?yīng)用過(guò)程中可能有所不同

1、get方法的特點(diǎn)

• 請(qǐng)求數(shù)據(jù)會(huì)附在URL之后（放在請(qǐng)求行中，以 ？分割URL和傳輸數(shù)據(jù)，多個(gè)參數(shù)用 & 連接）

• get是會(huì)被瀏覽器主動(dòng)緩存的，如果下一次傳輸?shù)臄?shù)據(jù)相同，那么就會(huì)返回緩存中的內(nèi)容，可以更快的展示數(shù)據(jù)

• get方法的UR一般都有長(zhǎng)度限制，但是需要注意的是http協(xié)議中并未規(guī)定get請(qǐng)求的長(zhǎng)度。這個(gè)長(zhǎng)度限制主要是由瀏覽器和web服務(wù)器決定的，并且各個(gè)瀏覽器對(duì)長(zhǎng)度限制各不相同

• get方法只產(chǎn)生一個(gè)TCP數(shù)據(jù)包，瀏覽器會(huì)把請(qǐng)求頭和請(qǐng)求數(shù)據(jù)一并發(fā)送出去，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）

2、post方法的特點(diǎn)

• 根據(jù)http規(guī)范，post可能改變服務(wù)器上的資源的請(qǐng)求（點(diǎn)贊就是post請(qǐng)求），因?yàn)橛锌赡苄薷姆?wù)器上的資源，所以不符合安全性和冪等性

• 因?yàn)閜ost方法是放在請(qǐng)求數(shù)據(jù)的，所以它的請(qǐng)求信息是沒(méi)有長(zhǎng)度限制的

• post方法會(huì)產(chǎn)生兩個(gè)TCP數(shù)據(jù)包，瀏覽器會(huì)先將請(qǐng)求頭發(fā)送給服務(wù)器，待服務(wù)器返回100 continue，瀏覽器再發(fā)送請(qǐng)求數(shù)據(jù)，服務(wù)器響應(yīng) 200 ok（返回?cái)?shù)據(jù)），這個(gè)看起來(lái)get比post快一些，但是實(shí)際上，在網(wǎng)絡(luò)狀況良好的情況下，他們的傳輸速度基本相同。

2. 傳輸層

2.1 講講三次握手

• 建立客戶端向服務(wù)端的連接：發(fā)送客戶端的請(qǐng)求連接數(shù)據(jù)包SYN到服務(wù)端

• 響應(yīng)客戶端的連接并建立服務(wù)端的連接：服務(wù)端發(fā)送響應(yīng)客戶端連接的數(shù)據(jù)包ACK和服務(wù)端的請(qǐng)求連接數(shù)據(jù)包SYN到客戶端

• 響應(yīng)服務(wù)端的連接：客戶端發(fā)送響應(yīng)服務(wù)端連接的數(shù)據(jù)包ACK到服務(wù)端

服務(wù)端新建套接字，綁定地址信息后開(kāi)始監(jiān)聽(tīng)，進(jìn)入LISTEN狀態(tài)。客戶端新建套接字綁定地址信息后調(diào)用connect，發(fā)送連接請(qǐng)求SYN，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器的確認(rèn)。服務(wù)端一旦監(jiān)聽(tīng)到連接請(qǐng)求，就會(huì)將連接放入內(nèi)核等待隊(duì)列中，并向客戶端發(fā)送SYN和確認(rèn)報(bào)文段ACK，進(jìn)入SYN_RECD狀態(tài)。客戶端收到SYN+ACK報(bào)文后向服務(wù)端發(fā)送確認(rèn)報(bào)文段ACK，并進(jìn)入ESTABLISHED狀態(tài)，開(kāi)始讀寫數(shù)據(jù)。服務(wù)端一旦收到客戶端的確認(rèn)報(bào)文，就進(jìn)入ESTABLISHED狀態(tài)，就可以進(jìn)行讀寫數(shù)據(jù)了

2.1.1 為什么是三次握手，而不是兩次或四次

兩次不安全，四次沒(méi)必要

tcp通信需要確保雙方都具有數(shù)據(jù)收發(fā)的能力，得到ACK響應(yīng)則認(rèn)為對(duì)方具有數(shù)據(jù)收發(fā)的能力，因此雙方都要發(fā)送SYN確保對(duì)方具有通信的能力。第一次握手是客戶端發(fā)送SYN，服務(wù)端接收，服務(wù)端得出客戶端的發(fā)送能力和服務(wù)端的接收能力都正常；第二次握手是服務(wù)端發(fā)送SYN+ACK，客戶端接收，客戶端得出客戶端發(fā)送接收能力正常，服務(wù)端發(fā)送接收能力也都正常，但是此時(shí)服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常；第三次握手客戶端發(fā)送ACK，服務(wù)器接收，服務(wù)端才能得出客戶端發(fā)送接收能力正常，服務(wù)端自己發(fā)送接收能力也都正常。

2.2 講講四次揮手

• 客戶端向服務(wù)端發(fā)送斷開(kāi)連接請(qǐng)求FIN

• 服務(wù)端響應(yīng)客戶端的斷開(kāi)連接請(qǐng)求，發(fā)送ACK響應(yīng)包給客戶端

• 服務(wù)端向客戶端發(fā)送斷開(kāi)連接請(qǐng)求FIN

• 客戶端響應(yīng)服務(wù)端的斷開(kāi)連接請(qǐng)求，發(fā)送ACK響應(yīng)給客戶端

客戶端主動(dòng)調(diào)用close時(shí)，向服務(wù)端發(fā)送結(jié)束報(bào)文段FIN報(bào)，同時(shí)進(jìn)入FIN_WAIT1狀態(tài)；服務(wù)器會(huì)收到結(jié)束報(bào)文段FIN報(bào)，服務(wù)器返回確認(rèn)報(bào)文段ACK并進(jìn)入CLOSE_WAIT狀態(tài)，此時(shí)如果服務(wù)端有數(shù)據(jù)要發(fā)送的話，客戶端依然需要接收?？蛻舳耸盏椒?wù)器對(duì)結(jié)束報(bào)文段的確認(rèn)，就會(huì)進(jìn)入到FIN_WAIT2狀態(tài)，開(kāi)始等待服務(wù)器的結(jié)束報(bào)文段；服務(wù)器端數(shù)據(jù)發(fā)送完畢后，當(dāng)服務(wù)器真正調(diào)用close關(guān)閉連接時(shí)，會(huì)向客戶端發(fā)送結(jié)束報(bào)文段FIN包，此時(shí)服務(wù)器進(jìn)入LAST_ACK狀態(tài)，等待最后一個(gè)ACK的帶來(lái)；客戶端收到服務(wù)器發(fā)來(lái)的結(jié)束報(bào)文段, 進(jìn)入TIME_WAIT, 并發(fā)出送確認(rèn)報(bào)文段ACK；服務(wù)器收到了對(duì)結(jié)束報(bào)文段確認(rèn)的ACK，進(jìn)入CLOSED狀態(tài)，斷開(kāi)連接。而客戶端要等待2MSL的時(shí)間，才會(huì)進(jìn)入到CLOSED狀態(tài)

2.2.1 為什么握手是三次，而揮手需要四次呢

第二步屬于系統(tǒng)自動(dòng)響應(yīng)數(shù)據(jù)包

第三步是程序手動(dòng)調(diào)用close()方法發(fā)送關(guān)閉連接的請(qǐng)求數(shù)據(jù)包

其實(shí)在TCP握手的時(shí)候，接收端將SYN包和ACK確認(rèn)包合并到一個(gè)包中發(fā)送的，所以減少了一次包的發(fā)送。對(duì)于四次揮手，由于TCP是全雙工通信，主動(dòng)關(guān)閉方發(fā)送FIN請(qǐng)求不代表完全斷開(kāi)連接，只能表示主動(dòng)關(guān)閉方不再發(fā)送數(shù)據(jù)了。而接收方可能還要發(fā)送數(shù)據(jù)，就不能立即關(guān)閉服務(wù)器端到客戶端的數(shù)據(jù)通道，所以就不能將服務(wù)端的FIN包和對(duì)客戶端的ACK包合并發(fā)送，只能先確認(rèn)ACK，等服務(wù)器無(wú)需發(fā)送數(shù)據(jù)時(shí)在發(fā)送FIN包，所以四次揮手時(shí)需要四次數(shù)據(jù)包的交互

2.2.2 一臺(tái)主機(jī)上出現(xiàn)大量的TIME_WAIT是什么原因？應(yīng)該如何處理？

TIME_WAIT是主動(dòng)關(guān)閉方出現(xiàn)的，一臺(tái)主機(jī)出現(xiàn)大量的TIME_WAIT證明這臺(tái)主機(jī)上發(fā)起大量的主動(dòng)關(guān)閉連接。常見(jiàn)于一些爬蟲(chóng)服務(wù)器。這時(shí)候我們應(yīng)該調(diào)整TIME_WAIT的等待時(shí)間，或者開(kāi)啟套接字地址重用選項(xiàng)

2.2.3 一臺(tái)主機(jī)上出現(xiàn)大量的CLOSE_WAIT是什么原因？應(yīng)該如何處理？

CLOSE_WAIT是被動(dòng)關(guān)閉方收到FIN請(qǐng)求進(jìn)行回復(fù)之后的狀態(tài)，等待上層程序進(jìn)一步處理，若出現(xiàn)大量CLOSE_WAIT，有可能是被動(dòng)關(guān)閉方主機(jī)程序中忘了最后一步斷開(kāi)連接后調(diào)用close釋放資源。這是一個(gè) BUG，只需要加上對(duì)應(yīng)的 close 即可解決問(wèn)題

2.3 TCP是如何保證可靠性的

可靠性和提高性能可參考此鏈接！?。?/p>

確認(rèn)應(yīng)答、超時(shí)重傳、連接管理、流量控制、擁塞控制

2.4 TCP是如何提高性能的

滑動(dòng)窗口、延遲應(yīng)答、捎帶應(yīng)答

2.5 TCP和UDP的區(qū)別

TCP是可靠，穩(wěn)定的，TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會(huì)有三次握手來(lái)建立連接，而且在數(shù)據(jù)傳遞時(shí)，有確認(rèn)應(yīng)答、超時(shí)重傳、連接管理、流量管理、擁塞控制機(jī)制，在數(shù)據(jù)傳完后，還會(huì)四次揮手?jǐn)嚅_(kāi)連接用來(lái)節(jié)約系統(tǒng)資源。但是它相對(duì)UDP較慢，效率低，占用系統(tǒng)資源高，而且在數(shù)據(jù)傳遞時(shí)，確認(rèn)機(jī)制、重傳機(jī)制、擁塞控制機(jī)制等都會(huì)消耗大量的時(shí)間，而且要在每臺(tái)設(shè)備上維護(hù)所有的傳輸連接，每個(gè)連接都會(huì)占用系統(tǒng)的CPU、內(nèi)存等硬件資源。

UDP沒(méi)有TCP的確認(rèn)應(yīng)答、超時(shí)重傳、連接管理、流量管理、擁塞控制等機(jī)制，是一個(gè)無(wú)狀態(tài)的傳輸協(xié)議，所以它在傳遞數(shù)據(jù)時(shí)非常快。但是UDP不可靠、不穩(wěn)定，因?yàn)閁DP沒(méi)有TCP那些可靠的機(jī)制，在數(shù)據(jù)傳遞時(shí)，如果網(wǎng)絡(luò)質(zhì)量不好，就會(huì)很容易丟包。

總的來(lái)說(shuō)

TCP是面向連接的，UDP無(wú)連接
TCP是可靠的，UDP不可靠
TCP只支持對(duì)點(diǎn)的通信；UDP支持一對(duì)一，一對(duì)多，多對(duì)一，多對(duì)多通信
TCP是面向字節(jié)流的；UDP是面向數(shù)據(jù)報(bào)的
TCP首部開(kāi)銷大，20個(gè)字節(jié)；UDP只有8個(gè)字節(jié)
TCP可以保證傳輸?shù)捻樞?，UDP不可以保證

3. 其他問(wèn)題

3.1 瀏覽器輸入U(xiǎn)RL后發(fā)生了什么

• 首先，在瀏覽器地址欄中輸入url，先解析url，檢測(cè)url地址是否合法

• 瀏覽器先查看瀏覽器緩存——系統(tǒng)緩存——路由器緩存，如果緩存中有，直接在屏幕上顯示內(nèi)容，如果沒(méi)有，到第三步

瀏覽器緩存：瀏覽器會(huì)記錄DNS一段時(shí)間，因此只有第一個(gè)地方解析DNS請(qǐng)求
操作系統(tǒng)緩存：如果在瀏覽器中不包含這個(gè)記錄，則會(huì)使用系統(tǒng)調(diào)用操作系統(tǒng)，獲取操作系統(tǒng)記錄（保存最近的DNS查詢緩存）
路由器緩存：如果上述兩個(gè)步驟均不能獲取DNS記錄，繼續(xù)搜索路由器緩存

• 在發(fā)送http請(qǐng)求前，需要域名解析（DNS解析），獲取相應(yīng)的IP地址

• 瀏覽器向服務(wù)器發(fā)起TCP連接，與瀏覽器建立三次握手

• 握手成功后，瀏覽器向服務(wù)器發(fā)送http請(qǐng)求，請(qǐng)求數(shù)據(jù)包

• 服務(wù)器處理收到的請(qǐng)求，將數(shù)據(jù)返回至瀏覽器

• 四次揮手釋放TCP連接

• 瀏覽器收到http響應(yīng)

• 瀏覽器解析響應(yīng)，如果響應(yīng)可以緩存，則存入緩存

• 瀏覽器發(fā)送請(qǐng)求獲取嵌入在HTML的資源（對(duì)于未知類型，會(huì)彈出對(duì)話框）

• 瀏覽器發(fā)送異步請(qǐng)求

• 頁(yè)面渲染全部結(jié)束

3.2 電腦網(wǎng)絡(luò)不通如何解決

（1）排除接觸故障

查看網(wǎng)線是否連接正常。如果網(wǎng)絡(luò)連接圖標(biāo)上顯示“紅叉”，則說(shuō)明網(wǎng)絡(luò)連接不正常。可檢查主機(jī)網(wǎng)卡口上的網(wǎng)線、交換器（路由器）上網(wǎng)線是否正常連接

（2）使用ipconfig查看計(jì)算機(jī)的上網(wǎng)參數(shù)

①單擊“開(kāi)始|所有程序|附件|命令提示符“，打開(kāi)命令提示符窗口

②輸入ipconfig，按Enter確認(rèn)，可以看到機(jī)器的配置信息，輸入ipconfig/all,可以看到IP地址和網(wǎng)卡物理地址等相關(guān)網(wǎng)絡(luò)詳細(xì)信息。

（3）使用ping命令測(cè)試網(wǎng)絡(luò)的連通性

在命令提示符窗口中輸入"ping 127.0.0.1"，數(shù)據(jù)顯示本機(jī)分別發(fā)送和接受了4個(gè)數(shù)據(jù)包，丟包率為零，可以判斷本機(jī)網(wǎng)絡(luò)協(xié)議工作正常，如顯示”請(qǐng)求超時(shí)“，則表明本機(jī)網(wǎng)卡的安裝或TCP/IP協(xié)議有問(wèn)題，接下來(lái)就應(yīng)該檢查網(wǎng)卡和TCP/IP協(xié)議，可以通過(guò)重新安裝該協(xié)議來(lái)解決。安裝方法：右擊“本地連接”——屬性——安裝——協(xié)議，選擇TCP/IP協(xié)議確定安裝。

（4）ping本機(jī)IP

如果ping 127.0.0.1 正常，則可以“ping 本機(jī)IP”來(lái)判斷本機(jī)的網(wǎng)卡是否正常工作。如不能ping通，說(shuō)明本機(jī)的網(wǎng)卡驅(qū)動(dòng)程序不正確，或者網(wǎng)卡與網(wǎng)線之間連接有故障，也有可能是本地的路由表面收到了破壞，此時(shí)應(yīng)檢查本機(jī)網(wǎng)卡的狀態(tài)是否為已連接，網(wǎng)絡(luò)參數(shù)是否設(shè)置正確，如果正確可是不能ping通，就應(yīng)該重新安裝網(wǎng)卡驅(qū)動(dòng)程序。丟失率為零，可以判斷網(wǎng)卡安裝配置沒(méi)有問(wèn)題，工作正常。

（5）ping網(wǎng)關(guān)IP

網(wǎng)關(guān)地址能被ping通的話，表明本機(jī)網(wǎng)絡(luò)連接已經(jīng)正常，如果命令不成功，可能是網(wǎng)關(guān)設(shè)備自身存在問(wèn)題，也可能是本機(jī)上網(wǎng)參數(shù)設(shè)置有誤，檢查網(wǎng)絡(luò)參數(shù)。如果ping 網(wǎng)關(guān)IP正常，可網(wǎng)頁(yè)卻無(wú)法打開(kāi)，同時(shí)QQ可以正確登錄。則一般是DNS填寫不正確，請(qǐng)聯(lián)系運(yùn)行商詢問(wèn)DNS地址，也可詢問(wèn)鄰居他們是怎么設(shè)置的，一個(gè)地區(qū)的同一運(yùn)行商所用的DNS都是一樣的。

推薦閱讀

50 道網(wǎng)絡(luò)面試題及答案（上）

50 道網(wǎng)絡(luò)面試題及答案（下）

IT運(yùn)維面試問(wèn)題總結(jié)-數(shù)據(jù)庫(kù)、監(jiān)控、網(wǎng)絡(luò)管理（NoSQL、MongoDB、MySQL、Prometheus、Zabbix）