面試準備——計算機網絡複習

Http和Https的區別

Http協議運行在TCP之上，明文傳輸，客戶端與服務器端都無法驗證對方的身份；Https是身披SSL外殼的Http，運行於SSL上，SSL運行於TCP之上，是添加了加密和認證機制的HTTP。二者之間存在如下不同：

• 端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，後者是443；

• 資源消耗：和HTTP通信相比，Https通信會由於加減密處理消耗更多的CPU和內存資源；

• 開銷：Https通信需要證書，而證書一般需要向認證機構購買；

三次握手

三次握手(我要和你建立鏈接，你真的要和我建立鏈接麼，我真的要和你建立鏈接，成功)

• 第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。

• 第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求建立連接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。

• 第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，如果正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。

問題：爲什麼TCP鏈接需要三次握手，兩次不可以麼，爲什麼？

答：爲了防止 已失效的鏈接請求報文突然又傳送到了服務端，因而產生錯誤。

四次揮手

四次揮手(我要和你斷開鏈接；好的，斷吧。我也要和你斷開鏈接；好的，斷吧)

• 第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

• 第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。此時TCP鏈接處於半關閉狀態，即客戶端已經沒有要發送的數據了，但服務端若發送數據，則客戶端仍要接收。

• 第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

• 第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。

Get與POST的區別

• GET一般用來從服務器上獲取資源，POST一般用來更新服務器上的資源；

• 從請求參數形式上看，GET請求的數據會附在URL之後，即將請求數據放置在HTTP報文的 請求頭 中；而POST請求會把提交的數據則放置是HTTP請求報文的 請求體 中。

• POST的安全性要比GET的安全性高，因爲GET請求提交的數據將明文出現在URL上，而且POST請求參數則被包裝到請求體中，相對更安全。

• 從請求的大小看，GET請求的長度受限於瀏覽器或服務器對URL長度的限制，允許發送的數據量比較小，而POST請求則是沒有大小限制的。

TCP與UDP的區別

TCP和UDP協議屬於傳輸層協議，它們之間的區別包括：

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

• TCP是可靠的，UDP是不可靠的；

• TCP只支持點對點通信，UDP支持一對一、一對多、多對一、多對多的通信模式；

• TCP是面向字節流的，UDP是面向報文的；

• TCP有擁塞控制機制;UDP沒有擁塞控制，適合媒體通信；

• TCP首部開銷(20個字節)比UDP的首部開銷(8個字節)要大

TCP的擁塞處理

計算機網絡中的帶寬、交換結點中的緩存及處理機等都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞，這種情況就叫做擁塞。擁塞控制就是 防止過多的數據注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載。注意，擁塞控制和流量控制不同，前者是一個全局性的過程，而後者指點對點通信量的控制。擁塞控制的方法主要有以下四種：

• 慢啓動：不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小;
• 擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規律緩慢增長。
• 快重傳：快重傳要求接收方在收到一個 失序的報文段 後就立即發出 重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。
• 快恢復：快重傳配合使用的還有快恢復算法，當發送方連續收到三個重複確認時，就執行“乘法減小”算法，把ssthresh門限減半，但是接下去並不執行慢開始算法：因爲如果網絡出現擁塞的話就不會收到好幾個重複的確認，所以發送方現在認爲網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，然後執行擁塞避免算法

從輸入網址到獲得頁面的過程

1. 瀏覽器查詢 DNS，獲取域名對應的IP地址
2. 瀏覽器獲得域名對應的IP地址以後，瀏覽器向服務器請求建立鏈接，發起三次握手
3. TCP/IP鏈接建立起來後，瀏覽器向服務器發送HTTP請求；
4. 服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將處理結果及相應的視圖返回給瀏覽器；
5. 瀏覽器解析並渲染視圖，若遇到對js文件、css文件及圖片等靜態資源的引用，則重複上述步驟並向服務器請求這些資源；
6. 瀏覽器根據其請求到的資源、數據渲染頁面，最終向用戶呈現一個完整的頁面。

Session、Cookie 與 Application

Cookie和Session都是客戶端與服務器之間保持狀態的解決方案，具體來說，cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。

1. Cookie
   實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie，而客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器，服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容
2. Session
   同樣地，會話狀態也可以保存在服務器端。客戶端請求服務器，如果服務器記錄該用戶狀態，就獲取Session來保存狀態，這時，如果服務器已經爲此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用；如果客戶端請求不包含sessionid，則爲此客戶端創建一個session並且生成一個與此session相關聯的sessionid，並將這個sessionid在本次響應中返回給客戶端保存。保存這個sessionid的方式可以採用 cookie機制 ，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器；若瀏覽器禁用Cookie的話，可以通過 URL重寫機制 將sessionid傳回服務器。
3. Application
   Application（Java Web中的ServletContext）：與一個Web應用程序相對應，爲應用程序提供了一個全局的狀態，所有客戶都可以使用該狀態

OSI網絡體系結構與TCP/IP協議模型

TCP/IP與OSI最大的不同在於：OSI是一個理論上的網絡通信模型，而TCP/IP則是實際上的網絡通信標準。但是，它們的初衷是一樣的，都是爲了使得兩臺計算機能夠像兩個知心朋友那樣能夠互相準確理解對方的意思並做出優雅的迴應

1. 物理層
   實現了相鄰計算機節點之間比特流的透明傳送，並儘可能地屏蔽掉具體傳輸介質和物理設備的差異，使其上層(數據鏈路層)不必關心網絡的具體傳輸介質
2. 數據鏈路層
   這一層在物理層提供的比特流的基礎上，通過差錯控制、流量控制方法，使有差錯的物理線路變爲無差錯的數據鏈路，即提供可靠的通過物理介質傳輸數據的方法
3. 網絡層
   將網絡地址翻譯成對應的物理地址，並通過路由選擇算法爲分組通過通信子網選擇最適當的路徑。
   
4. 傳輸層
   在源端與目的端之間提供可靠的透明數據傳輸，使上層服務用戶不必關係通信子網的實現細節
   
5. 會話層
   會話層是OSI模型的第五層，是用戶應用程序和網絡之間的接口，負責在網絡中的兩節點之間建立、維持和終止通信
6. 表示層
   數據的編碼，壓縮和解壓縮，數據的加密和解密
7. 應用層
   爲用戶的應用進程提供網絡通信服務

TCP和UDP分別對應的常見應用層協議

IP地址與物理地址

物理地址是數據鏈路層和物理層使用的地址，IP地址是網絡層和以上各層使用的地址，是一種邏輯地址，其中ARP協議用於IP地址與物理地址的對應。