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

• 請求報文格式：請求行、請求頭、空一行、請求體

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

• 響應報文格式：狀態(tài)行、響應頭、空一行、響應體

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

1.2 http和https的區(qū)別

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

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

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

1.4 cookie和session的區(qū)別

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

2、安全程度不同：cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙,考慮到安全應當使用session。

3、性能使用程度不同：session會在一定時間內(nèi)保存在服務器上。當訪問增多，會比較占用你服務器的性能,考慮到減輕服務器性能方面，應當使用cookie。

4、數(shù)據(jù)存儲大小不同：單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie，而session則存儲與服務端，瀏覽器對其沒有限制。

5、會話機制不同：session會話機制：session會話機制是一種服務器端機制，它使用類似于哈希表（可能還有哈希表）的結(jié)構來保存信息。cookies會話機制：cookie是服務器存儲在本地計算機上的小塊文本，并隨每個請求發(fā)送到同一服務器。

1.5 get和post的區(qū)別

他們本質(zhì)都是TCP連接，并無區(qū)別，但是由于http的規(guī)定以及瀏覽器和服務器的限制，導致他們在應用過程中可能有所不同

1、get方法的特點

①請求數(shù)據(jù)會附在URL之后（放在請求行中，以 ？分割URL和傳輸數(shù)據(jù)，多個參數(shù)用 & 連接）

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

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

④get方法只產(chǎn)生一個TCP數(shù)據(jù)包，瀏覽器會把請求頭和請求數(shù)據(jù)一并發(fā)送出去，服務器響應200 ok（返回數(shù)據(jù)）

2、post方法的特點

①根據(jù)http規(guī)范，post可能改變服務器上的資源的請求（點贊就是post請求），因為有可能修改服務器上的資源，所以不符合安全性和冪等性

②因為post方法是放在請求數(shù)據(jù)的，所以它的請求信息是沒有長度限制的

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

2. 傳輸層

2.1 講講三次握手

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

2、響應客戶端的連接并建立服務端的連接：服務端發(fā)送響應客戶端連接的數(shù)據(jù)包ACK和服務端的請求連接數(shù)據(jù)包SYN到客戶端

3、響應服務端的連接：客戶端發(fā)送響應服務端連接的數(shù)據(jù)包ACK到服務端

服務端新建套接字，綁定地址信息后開始監(jiān)聽，進入LISTEN狀態(tài)?？蛻舳诵陆ㄌ捉幼纸壎ǖ刂沸畔⒑笳{(diào)用connect，發(fā)送連接請求SYN，并進入SYN_SENT狀態(tài)，等待服務器的確認。服務端一旦監(jiān)聽到連接請求，就會將連接放入內(nèi)核等待隊列中，并向客戶端發(fā)送SYN和確認報文段ACK，進入SYN_RECD狀態(tài)。客戶端收到SYN+ACK報文后向服務端發(fā)送確認報文段ACK，并進入ESTABLISHED狀態(tài)，開始讀寫數(shù)據(jù)。服務端一旦收到客戶端的確認報文，就進入ESTABLISHED狀態(tài)，就可以進行讀寫數(shù)據(jù)了

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

兩次不安全，四次沒必要

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

2.2 講講四次揮手

1、客戶端向服務端發(fā)送斷開連接請求FIN

2、服務端響應客戶端的斷開連接請求，發(fā)送ACK響應包給客戶端

3、服務端向客戶端發(fā)送斷開連接請求FIN

4、客戶端響應服務端的斷開連接請求，發(fā)送ACK響應給客戶端

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

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

• 第二步屬于系統(tǒng)自動響應數(shù)據(jù)包
• 第三步是程序手動調(diào)用close()方法發(fā)送關閉連接的請求數(shù)據(jù)包

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

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

TIME_WAIT是主動關閉方出現(xiàn)的，一臺主機出現(xiàn)大量的TIME_WAIT證明這臺主機上發(fā)起大量的主動關閉連接。常見于一些爬蟲服務器。這時候我們應該調(diào)整TIME_WAIT的等待時間，或者開啟套接字地址重用選項

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

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

2.3 TCP是如何保證可靠性的

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

確認應答、超時重傳、連接管理、流量控制、擁塞控制

2.4 TCP是如何提高性能的

滑動窗口、延遲應答、捎帶應答

2.5 TCP和UDP的區(qū)別

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

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

總的來說

TCP是面向連接的，UDP無連接

TCP是可靠的，UDP不可靠

TCP只支持對點的通信；UDP支持一對一，一對多，多對一，多對多通信

TCP是面向字節(jié)流的；UDP是面向數(shù)據(jù)報的

TCP首部開銷大，20個字節(jié)；UDP只有8個字節(jié)

TCP可以保證傳輸?shù)捻樞?，UDP不可以保證

3. 其他問題

3.1 瀏覽器輸入URL后發(fā)生了什么

1、首先，在瀏覽器地址欄中輸入url，先解析url，檢測url地址是否合法

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

瀏覽器緩存：瀏覽器會記錄DNS一段時間，因此只有第一個地方解析DNS請求

操作系統(tǒng)緩存：如果在瀏覽器中不包含這個記錄，則會使用系統(tǒng)調(diào)用操作系統(tǒng)，獲取操作系統(tǒng)記錄（保存最近的DNS查詢緩存）

路由器緩存：如果上述兩個步驟均不能獲取DNS記錄，繼續(xù)搜索路由器緩存

3、在發(fā)送http請求前，需要域名解析（DNS解析），獲取相應的IP地址

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

5、握手成功后，瀏覽器向服務器發(fā)送http請求，請求數(shù)據(jù)包

6、服務器處理收到的請求，將數(shù)據(jù)返回至瀏覽器

7、四次揮手釋放TCP連接

8、瀏覽器收到http響應

9、瀏覽器解析響應，如果響應可以緩存，則存入緩存

10、瀏覽器發(fā)送請求獲取嵌入在HTML的資源（對于未知類型，會彈出對話框）

11、瀏覽器發(fā)送異步請求

12、頁面渲染全部結(jié)束

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

（1）排除接觸故障

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

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

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

②輸入ipconfig，按Enter確認，可以看到機器的配置信息，輸入ipconfig/all,可以看到IP地址和網(wǎng)卡物理地址等相關網(wǎng)絡詳細信息。

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

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

（4）ping本機IP

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

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

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