[[393039]]

簡述OSI七層協(xié)議

OSI七層協(xié)議包括：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡層，運輸層，會話層，表示層， 應用層

簡述TCP/IP五層協(xié)議

TCP/IP五層協(xié)議包括：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡層，運輸層，應用層

物理層有什么作用

主要解決兩臺物理機之間的通信，通過二進制比特流的傳輸來實現(xiàn)，二進制數(shù)據(jù)表現(xiàn)為電流電壓上的強弱，到達目的地再轉化為二進制機器碼。網(wǎng)卡、集線器工作在這一層。

數(shù)據(jù)鏈路層有什么作用

在不可靠的物理介質上提供可靠的傳輸，接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層;同樣，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉發(fā)到物理層。這一層在物理層提供的比特流的基礎上，通過差錯控制、流量控制方法，使有差錯的物理線路變?yōu)闊o差錯的數(shù)據(jù)鏈路。提供物理地址尋址功能。交換機工作在這一層。

網(wǎng)絡層有什么作用

將網(wǎng)絡地址翻譯成對應的物理地址，并決定如何將數(shù)據(jù)從發(fā)送方路由到接收方，通過路由選擇算法為分組通過通信子網(wǎng)選擇最佳路徑。路由器工作在這一層。

傳輸層有什么作用

傳輸層提供了進程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網(wǎng)絡層的核心細節(jié)，使應用程序看起來像是在兩個傳輸層實體之間有一條端到端的邏輯通信信道。

會話層有什么作用

建立會話：身份驗證，權限鑒定等;保持會話：對該會話進行維護，在會話維持期間兩者可以隨時使用這條會話傳輸局;斷開會話：當應用程序或應用層規(guī)定的超時時間到期后，OSI會話層才會釋放這條會話。

表示層有什么作用

對數(shù)據(jù)格式進行編譯，對收到或發(fā)出的數(shù)據(jù)根據(jù)應用層的特征進行處理，如處理為文字、圖片、音頻、視頻、文檔等，還可以對壓縮文件進行解壓縮、對加密文件進行解密等。

應用層有什么作用

提供應用層協(xié)議，如HTTP協(xié)議，F(xiàn)TP協(xié)議等等，方便應用程序之間進行通信。

TCP與UDP區(qū)別

TCP作為面向流的協(xié)議，提供可靠的、面向連接的運輸服務，并且提供點對點通信 UDP作為面向報文的協(xié)議，不提供可靠交付，并且不需要連接，不僅僅對點對點，也支持多播和廣播

為何TCP可靠

TCP有三次握手建立連接，四次揮手關閉連接的機制。除此之外還有滑動窗口和擁塞控制算法。最最關鍵的是還保留超時重傳的機制。對于每份報文也存在校驗，保證每份報文可靠性。

為何UDP不可靠

UDP面向數(shù)據(jù)報無連接的，數(shù)據(jù)報發(fā)出去，就不保留數(shù)據(jù)備份了。僅僅在IP數(shù)據(jù)報頭部加入校驗和復用。UDP沒有服務器和客戶端的概念。UDP報文過長的話是交給IP切成小段，如果某段報廢報文就廢了。

簡述TCP粘包現(xiàn)象

TCP是面向流協(xié)議，發(fā)送的單位是字節(jié)流，因此會將多個小尺寸數(shù)據(jù)被封裝在一個tcp報文中發(fā)出去的可能性?？梢院唵蔚睦斫獬煽蛻舳苏{用了兩次send，服務器端一個recv就把信息都讀出來了。

TCP粘包現(xiàn)象處理方法

固定發(fā)送信息長度，或在兩個信息之間加入分隔符。

簡述TCP協(xié)議的滑動窗口

滑動窗口是傳輸層進行流量控制的一種措施，接收方通過通告發(fā) 送方自己的窗口大小，從而控制發(fā)送方的發(fā)送速度，防止發(fā)送方發(fā)送速度過快而導致自己被淹沒。

簡述TCP協(xié)議的擁塞控制

擁塞是指一個或者多個交換點的數(shù)據(jù)報超載，TCP又會有重傳機制，導致過載。為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡擁塞，還需要設置一個慢開始門限ssthresh狀態(tài)變量.

當cwnd < ssthresh 時，使用慢開始算法。當cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。當cwnd = ssthresh 時，即可使用慢開始算法，也可使用擁塞避免算法。

慢開始：由小到大逐漸增加擁塞窗口的大小，每接一次報文，cwnd指數(shù)增加。

擁塞避免：cwnd緩慢地增大，即每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1。

快恢復之前的策略：發(fā)送方判斷網(wǎng)絡出現(xiàn)擁塞，就把ssthresh設置為出現(xiàn)擁塞時發(fā)送方窗口值的一半，繼續(xù)執(zhí)行慢開始，之后進行擁塞避免。

快恢復：發(fā)送方判斷網(wǎng)絡出現(xiàn)擁塞，就把ssthresh設置為出現(xiàn)擁塞時發(fā)送方窗口值的一半，并把cwnd設置為ssthresh的一半，之后進行擁塞避免。

簡述快重傳

如果在超時重傳定時器溢出之前，接收到連續(xù)的三個重復冗余ACK，發(fā)送端便知曉哪個報文段在傳輸過程中丟失了，于是重發(fā)該報文段，不需要等待超時重傳定時器溢出再發(fā)送該報文。

TCP三次握手過程

1. 第一次握手:客戶端將標志位SYN置為1，隨機產(chǎn)生一個值序列號seq=x，并將該數(shù)據(jù)包發(fā)送給服務端，客戶端 進入syn_sent狀態(tài)，等待服務端確認。
2. 第二次握手:服務端收到數(shù)據(jù)包后由標志位SYN=1知道客戶端請求建立連接，服務端將標志位SYN和 ACK都置為1，ack=x+1,隨機產(chǎn)生一個值seq=y，并將該數(shù)據(jù)包發(fā)送給客戶端以確認連接請求，服務端進入syn_rcvd狀態(tài)。
3. 第三次握手:客戶端收到確認后檢查,如果正確則將標志位ACK為1，ack=y+1，并將該數(shù)據(jù)包發(fā)送給服務端，服務端進行檢查如果正確則連接建立成功，客戶端和服務端進入established狀態(tài)，完成三次握手，隨后客戶端和服務端之間可以開始傳輸 數(shù)據(jù)了

為什么TCP握手需要三次，兩次行不行?

不行。TCP進行可靠傳輸?shù)年P鍵就在于維護一個序列號，三次握手的過程即是通信雙方相互告知序列號起始值， 并確認對方已經(jīng)收到了序列號起始值。

如果只是兩次握手， 至多只有客戶端的起始序列號能被確認， 服務器端的序列號則得不到確認。

簡述半連接隊列

TCP握手中，當服務器處于SYN_RCVD 狀態(tài)，服務器會把此種狀態(tài)下請求連接放在一個隊列里，該隊列稱為半連接隊列。

簡述SYN攻擊

SYN攻擊即利用TCP協(xié)議缺陷，通過發(fā)送大量的半連接請求，占用半連接隊列，耗費CPU和內存資源。

優(yōu)化方式：

1. 縮短SYN Timeout時間
2. 記錄IP，若連續(xù)受到某個IP的重復SYN報文，從這個IP地址來的包會被一概丟棄。

TCP四次揮手過程

1. 第一次揮手：客戶端發(fā)送一個FIN，用來關閉客戶端到服務端的數(shù)據(jù)傳送，客戶端進入fin_wait_1狀態(tài)。
2. 第二次揮手：服務端收到FIN后，發(fā)送一個ACK給客戶端，確認序號為收到序號+1，服務端進入Close_wait狀態(tài)。此時TCP連接處于半關閉狀態(tài)，即客戶端已經(jīng)沒有要發(fā)送的數(shù)據(jù)了，但服務端若發(fā)送數(shù)據(jù)，則客戶端仍要接收。
3. 第三次揮手：服務端發(fā)送一個FIN，用來關閉服務端到客戶端的數(shù)據(jù)傳送，服務端進入Last_ack狀態(tài)。
4. 第四次揮手：客戶端收到FIN后，客戶端進入Time_wait狀態(tài)，接著發(fā)送一個ACK給服務端，確認后，服務端進入Closed狀態(tài)，完成四次揮手。

為什么TCP揮手需要4次

主要原因是當服務端收到客戶端的 FIN 數(shù)據(jù)包后，服務端可能還有數(shù)據(jù)沒發(fā)完，不會立即close。

所以服務端會先將 ACK 發(fā)過去告訴客戶端我收到你的斷開請求了，但請再給我一點時間，這段時間用來發(fā)送剩下的數(shù)據(jù)報文，發(fā)完之后再將 FIN 包發(fā)給客戶端表示現(xiàn)在可以斷了。之后客戶端需要收到 FIN 包后發(fā)送 ACK 確認斷開信息給服務端。

為什么四次揮手釋放連接時需要等待2MSL

MSL即報文最大生存時間。設置2MSL可以保證上一次連接的報文已經(jīng)在網(wǎng)絡中消失，不會出現(xiàn)與新TCP連接報文沖突的情況。

簡述DNS協(xié)議

DNS協(xié)議是基于UDP的應用層協(xié)議，它的功能是根據(jù)用戶輸入的域名，解析出該域名對應的IP地址，從而給客戶端進行訪問。

簡述DNS解析過程

1、客戶機發(fā)出查詢請求，在本地計算機緩存查找，若沒有找到，就會將請求發(fā)送給dns服務器

2、本地dns服務器會在自己的區(qū)域里面查找，找到即根據(jù)此記錄進行解析，若沒有找到，就會在本地的緩存里面查找

3、本地服務器沒有找到客戶機查詢的信息，就會將此請求發(fā)送到根域名dns服務器

4、根域名服務器解析客戶機請求的根域部分，它把包含的下一級的dns服務器的地址返回到客戶機的dns服務器地址

5、客戶機的dns服務器根據(jù)返回的信息接著訪問下一級的dns服務器

6、這樣遞歸的方法一級一級接近查詢的目標，最后在有目標域名的服務器上面得到相應的IP信息

7、客戶機的本地的dns服務器會將查詢結果返回給我們的客戶機

8、客戶機根據(jù)得到的ip信息訪問目標主機，完成解析過程

簡述HTTP協(xié)議

http協(xié)議是超文本傳輸協(xié)議。它是基于TCP協(xié)議的應用層傳輸協(xié)議，即客戶端和服務端進行數(shù)據(jù)傳輸?shù)囊环N規(guī)則。該協(xié)議本身HTTP 是一種無狀態(tài)的協(xié)議。

簡述cookie

HTTP 協(xié)議本身是無狀態(tài)的，為了使其能處理更加復雜的邏輯，HTTP/1.1 引入 Cookie 來保存狀態(tài)信息。

Cookie是由服務端產(chǎn)生的，再發(fā)送給客戶端保存，當客戶端再次訪問的時候，服務器可根據(jù)cookie辨識客戶端是哪個，以此可以做個性化推送，免賬號密碼登錄等等。

簡述session

session用于標記特定客戶端信息，存在在服務器的一個文件里。一般客戶端帶Cookie對服務器進行訪問，可通過cookie中的session id從整個session中查詢到服務器記錄的關于客戶端的信息。

簡述http狀態(tài)碼和對應的信息

1XX：接收的信息正在處理

2XX：請求正常處理完畢

3XX：重定向

4XX：客戶端錯誤

5XX：服務端錯誤

常見錯誤碼：301：永久重定向 302：臨時重定向 304：資源沒修改，用之前緩存就行 400：客戶端請求的報文有錯誤 403：表示服務器禁止訪問資源 404：表示請求的資源在服務器上不存在或未找到

轉發(fā)和重定向的區(qū)別

轉發(fā)是服務器行為。服務器直接向目標地址訪問URL,將相應內容讀取之后發(fā)給瀏覽器，用戶瀏覽器地址欄URL不變，轉發(fā)頁面和轉發(fā)到的頁面可以共享request里面的數(shù)據(jù)。

重定向是利用服務器返回的狀態(tài)碼來實現(xiàn)的，如果服務器返回301或者302，瀏覽器收到新的消息后自動跳轉到新的網(wǎng)址重新請求資源。用戶的地址欄url會發(fā)生改變，而且不能共享數(shù)據(jù)。

簡述http1.0

規(guī)定了請求頭和請求尾，響應頭和響應尾(get post)

每一個請求都是一個單獨的連接，做不到連接的復用

簡述http1.1的改進

HTTP1.1默認開啟長連接，在一個TCP連接上可以傳送多個HTTP請求和響應。使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。

支持管道(pipeline)網(wǎng)絡傳輸，只要第一個請求發(fā)出去了，不必等其回來，就可以發(fā)第二個請求出去，可以減少整體的響應時間。

服務端無法主動push

簡述HTTP短連接與長連接區(qū)別

HTTP中的長連接短連接指HTTP底層TCP的連接。

短連接：客戶端與服務器進行一次HTTP連接操作，就進行一次TCP連接，連接結束TCP關閉連接。

長連接：如果HTTP頭部帶有參數(shù)keep-alive，即開啟長連接網(wǎng)頁完成打開后，底層用于傳輸數(shù)據(jù)的TCP連接不會直接關閉，會根據(jù)服務器設置的保持時間保持連接，保持時間過后連接關閉。

簡述http2.0的改進

提出多路復用。多路復用前，文件時串行傳輸?shù)?，請求a文件，b文件只能等待，并且連接數(shù)過多。引入多路復用，a文件b文件可以同時傳輸。

引入了二進制數(shù)據(jù)幀。其中幀對數(shù)據(jù)進行順序標識，有了序列id，服務器就可以進行并行傳輸數(shù)據(jù)。

http與https的區(qū)別

http所有傳輸?shù)膬热荻际敲魑模⑶铱蛻舳撕头掌鞫硕紵o法驗證對方的身份。https具有安全性的ssl加密傳輸協(xié)議，加密采用對稱加密， https協(xié)議需要到ca申請證書，一般免費證書很少，需要交費。

簡述TLS/SSL, HTTP, HTTPS的關系

SSL全稱為Secure Sockets Layer即安全套接層，其繼任為TLSTransport Layer Security傳輸層安全協(xié)議，均用于在傳輸層為數(shù)據(jù)通訊提供安全支持。

可以將HTTPS協(xié)議簡單理解為HTTP協(xié)議+TLS/SSL

https的連接過程

瀏覽器將支持的加密算法信息發(fā)給服務器

服務器選擇一套瀏覽器支持的加密算法，以證書的形式回發(fā)給瀏覽器

客戶端(SSL/TLS)解析證書驗證證書合法性，生成對稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，用服務器的公鑰對客戶端密鑰進行非對稱加密。

客戶端會發(fā)起HTTPS中的第二個HTTP請求，將加密之后的客戶端對稱密鑰發(fā)送給服務器

服務器接收到客戶端發(fā)來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對數(shù)據(jù)進行對稱加密，這樣數(shù)據(jù)就變成了密文。

服務器將加密后的密文發(fā)送給客戶端

客戶端收到服務器發(fā)送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發(fā)送的數(shù)據(jù)。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成

Get與Post區(qū)別

Get：指定資源請求數(shù)據(jù)，刷新無害，Get請求的數(shù)據(jù)會附加到URL中，傳輸數(shù)據(jù)的大小受到url的限制。

Post：向指定資源提交要被處理的數(shù)據(jù)。刷新會使數(shù)據(jù)會被重復提交。post在發(fā)送數(shù)據(jù)前會先將請求頭發(fā)送給服務器進行確認，然后才真正發(fā)送數(shù)據(jù)。

Get方法參數(shù)有大小限制嗎

一般HTTP協(xié)議里并不限制參數(shù)大小限制。但一般由于get請求是直接附加到地址欄里面的，由于瀏覽器地址欄有長度限制，因此使GET請求在瀏覽器實現(xiàn)層面上看會有長度限制。

了解REST API嗎

REST API全稱為表述性狀態(tài)轉移(Representational State Transfer，REST)即利用HTTP中get、post、put、delete以及其他的HTTP方法構成REST中數(shù)據(jù)資源的增刪改查操作：

• Create ：POST
• Read ：GET
• Update ：PUT/PATCH
• Delete：DELETE

瀏覽器中輸入一個網(wǎng)址后，具體發(fā)生了什么

進行DNS解析操作，根據(jù)DNS解析的結果查到服務器IP地址

通過ip尋址和arp，找到服務器，并利用三次握手建立TCP連接

瀏覽器生成HTTP報文，發(fā)送HTTP請求，等待服務器響應

服務器處理請求，并返回給瀏覽器

根據(jù)HTTP是否開啟長連接，進行TCP的揮手過程

瀏覽器根據(jù)收到的靜態(tài)資源進行頁面渲染