網絡相關面試題

本文是在網上看了各類面試指南收集的題目及答案。無心冒犯各位原創做者，若是在您的博客或者寫做平臺有類似問題答案能夠跟我說，我給您連接加上，我只是爲了方便之後本身須要的時候刷一刷，不用在處處找題。

Http和https的區別

• http是HTTP協議運行在TCP之上。全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份。
• https是HTTP運行在SSL/TLS之上，SSL/TLS運行在TCP之上。全部傳輸的內容都通過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。此外客戶端能夠驗證服務器端的身份，若是配置了客戶 端驗證，服務器方也能夠驗證客戶端的身份。
• https協議須要到ca申請證書，通常免費證書不多，須要交費。
• http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議
• http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
• http的鏈接很簡單,是無狀態的
• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全

TCP如何保證可靠傳輸

○ 數據包校驗
○ 超時重傳機制
○ 應答機制
○ 對失序數據包重排序
○ TCP還能提供流量控制

爲何TCP鏈接須要三次握手，兩次不能夠嗎，爲何

• 爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。
• 例子 「已失效的鏈接請求報文段」的產生在這樣一種狀況下:client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。 因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。」

若是客戶端不斷的發送請求鏈接會怎樣?

• 服務器端會爲每一個請求建立一個連接，而後向client端發送建立連接時的回覆，而後進行等待客戶端發送第三次握手數據包，這樣會白白浪費資源 • DDos攻擊
簡單的說就是想服務器發送連接請求，首先進行 第一步:客戶端向服務器端發送鏈接請求數據包(1) 第二步:服務器向客戶端回覆鏈接請求數據包(2)，而後服務器等待客戶端發送tcp/ip連接的第三步數據包(3) 第三步:若是客戶端不向服務器端發送最後一個數據包(3)，則服務器須等30s到2min中才能將此連接進行關閉。當大量的請求只進行到第二步，而不進行第三步，服務器又大量的資源等待第三個數據包。則形成DDos攻擊。
• DDos預防(沒有根治的辦法，除非不用TCP/IP連接)、
• 確保服務器的系統文件是最新版本，並及時更新系統補丁
• 關閉沒必要要的服務
• 限制同時打開SYN的半鏈接數目
• 縮短SYN半鏈接的time out時間
• 正確設置防火牆
• 禁止對主機的非開放服務的訪問
• 限制特定IP短地址的訪問
• 啓用防火牆的防DDos的屬性
• 嚴格限制對外開放的服務器的向外訪問
• 運行端口映射程序禍端口掃描程序，要認真檢查特權端口和非特權端口。
• 認真檢查網絡設備和主機/服務器系統的日誌。只要日誌出現漏洞或是時間變動，那這臺機器就可能遭到了攻擊。
• 限制在防火牆外與網絡文件共享。這樣會給黑客截取系統文件的機會，主機的信息暴露給黑客，無疑是給了對方入侵的機會。

GET和POST的區別?

• GET 被強制服務器支持
• 瀏覽器對URL的長度有限制，因此GET請求不能代替POST請求發送大量數據
• GET請求發送數據更小
• GET請求是不安全的
• GET請求是冪等的
• POST請求不能被緩存
• POST請求相對GET請求是「安全」的
• 在如下狀況中，請使用 POST 請求:

1. 沒法使用緩存文件(更新服務器上的文件或數據庫)
2. 向服務器發送大量數據(POST 沒有數據量限制)
3. 發送包含未知字符的用戶輸入時，POST 比 GET 更穩定也更可靠 >4.post比Get安全性更高

TCP和UDP區別?如何改進TCP

• TCP和UDP區別
○ UDP 是無鏈接的，即發送數據以前不須要創建鏈接。
○ UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制。
○ UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通訊的要求。
○ UDP 支持一對1、一對多、多對一和多對多的交互通訊。
○ UDP 的首部開銷小，只有 8 個字節。
○ TCP 是面向鏈接的運輸層協議。
○ 每一條 TCP 鏈接只能有兩個端點(endpoint)，每一條TCP鏈接只能是點對點的(一對一)。
○ TCP 提供可靠交付的服務。
○ TCP 提供全雙工通訊。
○ TCP是面向字節流。
○ 首部最低20個字節。
• TCP加快傳輸效率的方法
○ 採起一塊確認的機制

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

• 查詢DNS，獲取域名對應的IP地址
○ 瀏覽器搜索自身的DNS緩存 ○ 搜索操做系統的DNS緩存
○ 讀取本地的HOST文件
○ 發起一個DNS的系統調用
• 寬帶運營服務器查看自己緩存
• 運營商服務器發起一個迭代DNS解析請求
• 瀏覽器得到域名對應的IP地址後，發起HTTP三次握手
• TCP/IP鏈接創建起來後，瀏覽器就能夠向服務器發送HTTP請求了
• 服務器接受到這個請求，根據路徑參數，通過後端的一些處理生成HTML頁面代碼返回給瀏覽器
• 瀏覽器拿到完整的HTML頁面代碼開始解析和渲染，若是遇到引用的外部JS，CSS,圖片等靜態資源，它們一樣也是一個個的HTTP請求，都須要通過上面的步驟
• 瀏覽器根據拿到的資源對頁面進行渲染，最終把一個完整的頁面呈現給用戶

TCP鏈接的創建（三次握手）

1.TCP服務器進程先建立傳輸控制塊TCB，時刻準備接受客戶進程的鏈接請求，此時服務器就進入了LISTEN（監聽）狀態；
2.TCP客戶進程也是先建立傳輸控制塊TCB，而後向服務器發出鏈接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但須要消耗掉一個序號。
3.TCP服務器收到請求報文後，若是贊成鏈接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲本身初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，可是一樣要消耗一個序號。
4.TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，本身的序列號seq=x+1，此時，TCP鏈接創建，客戶端進入ESTABLISHED（已創建鏈接）狀態。TCP規定，ACK報文段能夠攜帶數據，可是若是不攜帶數據則不消耗序號。
5.當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就能夠開始通訊了。

爲何TCP客戶端最後還要發送一次確認呢？

一句話，主要防止已經失效的鏈接請求報文忽然又傳送到了服務器，從而產生錯誤。
若是使用的是兩次握手創建鏈接，假設有這樣一種場景，客戶端發送了第一個請求鏈接而且沒有丟失，只是由於在網絡結點中滯留的時間太長了，因爲TCP的客戶端遲遲沒有收到確認報文，覺得服務器沒有收到，此時從新向服務器發送這條報文，此後客戶端和服務器通過兩次握手完成鏈接，傳輸數據，而後關閉鏈接。此時此前滯留的那一次請求鏈接，網絡通暢了到達了服務器，這個報文本該是失效的，可是，兩次握手的機制將會讓客戶端和服務器再次創建鏈接，這將致使沒必要要的錯誤和資源的浪費。
若是採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文而且回覆了確認報文，可是客戶端不會再次發出確認。因爲服務器收不到確認，就知道客戶端並無請求鏈接。

TCP鏈接的釋放（四次揮手）

1.客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
2.服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3.客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。
4.服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
5.客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
6.服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

爲何客戶端最後還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP容許不一樣的實現能夠設置不一樣的MSL值。
第一，保證客戶端發送的最後一個ACK報文可以到達服務器，由於這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端尚未給我回應，應該是我發送的請求斷開報文它沒有收到，因而服務器又會從新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，而且會重啓2MSL計時器。
第二，防止相似與「三次握手」中提到了的「已經失效的鏈接請求報文段」出如今本鏈接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣新的鏈接中不會出現舊鏈接的請求報文。

爲何創建鏈接是三次握手，關閉鏈接確是四次揮手呢？

創建鏈接的時候，服務器在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。
而關閉鏈接時，服務器收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，而本身也未必所有數據都發送給對方了，因此己方能夠當即關閉，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送，從而致使多了一次。

若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲2小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。

本文部分問題答案來源下面連接：

blog.csdn.net/qzcsu/artic…