計算機網絡之面試常考

整理一下計算機網絡部分的面試常考點，參考書籍：《計算機網絡》第五版 謝希仁的那本，但願對你們有所幫助

OSI，TCP/IP，五層協議的體系結構，以及各層協議

OSI分層      （7層）：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。

TCP/IP分層（4層）：網絡接口層、              網際層、運輸層、                            應用層。

五層協議     （5層）：物理層、數據鏈路層、網絡層、運輸層、                            應用層。

 

每一層的協議以下：

物理層：RJ4五、CLOCK、IEEE802.3    （中繼器，集線器，網卡）

數據鏈路：PPP、FR、HDLC、VLAN、MAC  （網橋，交換機）

網絡層：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）

傳輸層：TCP、UDP、SPX   （網關）

會話層：NFS、SQL、NETBIOS、RPC

表示層：JPEG、MPEG、ASII

應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

 

每一層的做用以下：

物理層：經過媒介傳輸比特,肯定機械及電氣規範（比特Bit）

數據鏈路層：將比特組裝成幀和點到點的傳遞（幀Frame）

網絡層：負責數據包從源到宿的傳遞和網際互連（包PackeT）

傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）

會話層：創建、管理和終止會話（會話協議數據單元SPDU）

表示層：對數據進行翻譯、加密和壓縮（表示協議數據單元PPDU）

應用層：容許訪問OSI環境的手段（應用協議數據單元APDU）

 

ARP是地址解析協議，簡單語言解釋一下工做原理。

1：首先，每一個主機都會在本身的ARP緩衝區中創建一個ARP列表，以表示IP地址和MAC地址之間的對應關係。

2：當源主機要發送數據時，首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址，若是有，則直接發送數據，若是沒有，就向本網段的全部主機發送ARP數據包，該數據包包括的內容有：源主機IP地址，源主機MAC地址，目的主機的IP地址。

3：當本網絡的全部主機收到該ARP數據包時，首先檢查數據包中的IP地址是不是本身的IP地址，若是不是，則忽略該數據包，若是是，則首先從數據包中取出源主機的IP和MAC地址寫入到ARP列表中，若是已經存在，則覆蓋，而後將本身的MAC地址寫入ARP響應包中，告訴源主機本身是它想要找的MAC地址。

4：源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表，並利用此信息發送數據。若是源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

廣播發送ARP請求，單播發送ARP響應。

 

描述：RARP

RARP是逆地址解析協議，做用是完成硬件地址到IP地址的映射，主要用於無盤工做站，由於給無盤工做站配置的IP地址不能保存。工做流程：在網絡中配置一臺RARP服務器，裏面保存着IP地址和MAC地址的映射關係，當無盤工做站啓動後，就封裝一個RARP數據包，裏面有其MAC地址，而後廣播到網絡上去，當服務器收到請求包後，就查找對應的MAC地址的IP地址裝入響應報文中發回給請求者。由於須要廣播請求報文，所以RARP只能用於具備廣播能力的網絡。

 HTTP協議

http://www.javashuo.com/article/p-kfljnpvz-bn.html

TCP三次握手和四次揮手的全過程

三次握手：

第一次握手：客戶端發送syn包(syn=x)到服務器，並進入SYN_SEND狀態，等待服務器確認；

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時本身也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP鏈接一旦創建，在通訊雙方中的任何一方主動關閉鏈接以前，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狀態，完成四次揮手。

 

 在瀏覽器中輸入www.baidu.com後執行的所有過程

  

　(1). 瀏覽器查詢 DNS，獲取域名對應的IP地址:具體過程包括瀏覽器搜索自身的DNS緩存、搜索操做系統的DNS緩存、讀取本地的Host文件和向本地DNS服務器進行查詢等。對於向本地DNS服務器進行查詢，若是要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具備權威性)；若是要查詢的域名不禁本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析（此解析不具備權威性）。若是本地域名服務器並未緩存該網址映射關係，那麼將根據其設置發起遞歸查詢或者迭代查詢；

　　(2). 瀏覽器得到域名對應的IP地址之後，瀏覽器向服務器請求創建連接，發起三次握手；

　　(3). TCP/IP連接創建起來後，瀏覽器向服務器發送HTTP請求；

　　(4). 服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將處理結果及相應的視圖返回給瀏覽器；

　　(5). 瀏覽器解析並渲染視圖，若遇到對js文件、css文件及圖片等靜態資源的引用，則重複上述步驟並向服務器請求這些資源；

　　(6). 瀏覽器根據其請求到的資源、數據渲染頁面，最終向用戶呈現一個完整的頁面。

 

Http和Https的區別

　　Http協議運行在TCP之上，明文傳輸，客戶端與服務器端都沒法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行於SSL上，SSL運行於TCP之上，是添加了加密和認證機制的HTTP。兩者之間存在以下不一樣：

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

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

• 開銷：Https通訊須要證書，而證書通常須要向認證機構購買； 
  　 
  Https的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。

TCP和UDP的區別？

TCP提供面向鏈接的、可靠的數據流傳輸，而UDP提供的是非面向鏈接的、不可靠的數據流傳輸。

TCP傳輸單位稱爲TCP報文段，UDP傳輸單位稱爲用戶數據報。

TCP注重數據安全性，UDP數據傳輸快，由於不須要鏈接等待，少了許多操做，可是其安全性卻通常。

 

TCP對應的協議和UDP對應的協議

TCP對應的協議：

（1） FTP：定義了文件傳輸協議，使用21端口。

（2） Telnet：一種用於遠程登錄的端口，使用23端口，用戶能夠以本身的身份遠程鏈接到計算機上，可提供基於DOS模式下的通訊服務。

（3） SMTP：郵件傳送協議，用於發送郵件。服務器開放的是25號端口。

（4） POP3：它是和SMTP對應，POP3用於接收郵件。POP3協議所用的是110端口。

（5）HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

UDP對應的協議：

（1） DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。

（2） SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。因爲網絡設備不少，無鏈接的服務就體現出其優點。

（3） TFTP(Trival File Transfer Protocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。

 

DNS域名系統，簡單描述其工做原理。

當DNS客戶機須要在程序中使用名稱時，它會查詢DNS服務器來解析該名稱。客戶機發送的每條查詢信息包括三條信息：包括：指定的DNS域名，指定的查詢類型，DNS域名的指定類別。基於UDP服務，端口53. 該應用通常不直接爲用戶使用，而是爲其餘應用服務，如HTTP，SMTP等在其中須要完成主機名到IP地址的轉換。

 

面向鏈接和非面向鏈接的服務的特色是什麼？

面向鏈接的服務，通訊雙方在進行通訊以前，要先在雙方創建起一個完整的能夠彼此溝通的通道，在通訊過程當中，整個鏈接的狀況一直能夠被實時地監控和管理。

       非面向鏈接的服務，不須要預先創建一個聯絡兩個通訊節點的鏈接，須要通訊的時候，發送節點就能夠往網絡上發送信息，讓信息自主地在網絡上去傳，通常在傳輸的過程當中再也不加以監控。

 

TCP的三次握手過程？爲何會採用三次握手，若採用二次握手能夠嗎？

爲了防止 已失效的連接請求報文忽然又傳送到了服務端，於是產生錯誤。

　　客戶端發出的鏈接請求報文並未丟失，而是在某個網絡節點長時間滯留了，以至延誤到連接釋放之後的某個時間纔到達Server。這是，Server誤覺得這是Client發出的一個新的連接請求，因而就向客戶端發送確認數據包，贊成創建連接。若不採用「三次握手」，那麼只要Server發出確認數據包，新的連接就創建了。因爲client此時並未發出創建連接的請求，因此其不會理睬Server的確認，也不與Server通訊；而這時Server一直在等待Client的請求，這樣Server就白白浪費了必定的資源。若採用「三次握手」，在這種狀況下，因爲Server端沒有收到來自客戶端的確認，則就會知道Client並無要求創建請求，就不會創建連接。

爲何 是四次揮手，而不是三次

客戶端和服務器端的數據傳輸是雙向的，客戶端會給服務器段發送數據，服務器端也會給客戶端發送數據，這兩個得分別來關閉，客戶端數據傳輸結束後能夠請求關閉到服務器端的數據傳輸，須要兩次握手，而後服務器端數據傳輸完也請求關閉，也須要兩次（每次關閉都須要一個響應，因此每一個須要兩次揮手）。可能客戶端到服務器關閉之後，服務器到客戶端還有數據傳輸，因此中間兩次揮手不能合併。

session和cookie

cookie是客戶端技術，程序把每一個用戶的數據以cookie的形式寫給用戶各自的瀏覽器，當用戶使用瀏覽器再去訪問服務器的web資源時，就會帶着各自的數據去，這樣web處理的資源就是各個用戶本身的數據了，特色是會話數據保存在客戶端。

session是服務器端技術，服務器在運行時爲每一個用戶的數據建立一個其獨享的session對象，存在服務器，在cookie中設置可sessionID返回給客戶端，當客戶端再次訪問時，在請求中會帶上sessionID，服務器會經過sessionId找到session。

• 實現機制：Session的實現經常依賴於Cookie機制，經過Cookie機制回傳SessionID；

• 大小限制：Cookie有大小限制而且瀏覽器對每一個站點也有cookie的個數限制，Session沒有大小限制，理論上只與服務器的內存大小有關；

• 安全性：Cookie存在安全隱患，經過攔截或本地文件找獲得cookie後能夠進行攻擊，而Session因爲保存在服務器端，相對更加安全；

• 服務器資源消耗：Session是保存在服務器端上會存在一段時間纔會消失，若是session過多會增長服務器的壓力。

  Application（ServletContext）：與一個Web應用程序相對應，爲應用程序提供了一個全局的狀態，全部客戶均可以使用該狀態。

 

Get與POST的區別

　　GET與POST是咱們經常使用的兩種HTTP Method，兩者之間的區別主要包括以下五個方面：

(1). 從功能上講，GET通常用來從服務器上獲取資源，POST通常用來更新服務器上的資源；

(2). 從REST服務角度上說，GET是冪等的，即讀取同一個資源，老是獲得相同的數據，而POST不是冪等的，由於每次請求對資源的改變並非相同的；進一步地，GET不會改變服務器上的資源，而POST會對服務器資源進行改變；

(3). 從請求參數形式上看，GET請求的數據會附在URL以後，即將請求數據放置在HTTP報文的 請求頭 中，以?分割URL和傳輸數據，參數之間以&相連。特別地，若是數據是英文字母/數字，原樣發送；不然，會將其編碼爲 application/x-www-form-urlencoded MIME 字符串(若是是空格，轉換爲+，若是是中文/其餘字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII)；而POST請求會把提交的數據則放置在是HTTP請求報文的 請求體 中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，由於GET請求提交的數據將明文出如今URL上，並且POST請求參數則被包裝到請求體中，相對更安全。

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

對於可靠性，TCP經過如下方式進行保證：

• 數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時TCP發送數據端超時後會重發數據；

• 對失序數據包重排序：既然TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。TCP將對失序數據進行從新排序，而後才交給應用層；

• 丟棄重複數據：對於重複數據，可以丟棄重複數據；

• 應答機制：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒；

• 超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段；

• 流量控制：TCP鏈接的每一方都有固定大小的緩衝空間。TCP的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

Http的短鏈接和長鏈接

短鏈接:瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，但任務結束就中斷鏈接。

長鏈接:客戶端和服務器間創建鏈接後，該鏈接有必定的存活時間（keep-alive），在該時間內，客戶端訪問服務器不須要再新建鏈接，直接使用該鏈接實現長鏈接要客戶端和服務端都支持長鏈接。

TCP/IP的流量控制？

利用滑動窗口實現流量控制，若是發送方把數據發送得過快，接收方可能會來不及接收，這就會形成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。

 TCP爲每個鏈接設有一個持續計時器(persistence timer)。只要TCP鏈接的一方收到對方的零窗口通知，就啓動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口控測報文段（攜1字節的數據），那麼收到這個報文段的一方就從新設置持續計時器。

 

TCP擁塞控制？

防止過多的數據注入到網絡中，這樣可使網絡中的路由器或鏈路不致過載。擁塞控制所要作的都有一個前提：網絡可以承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到全部的主機、路由器，以及與下降網絡傳輸性能有關的全部因素。

幾種擁塞控制方法：

慢開始(slow-start )、擁塞避免(congestion avoidance )、快重傳( fastretransmit )和快恢復( fastrecovery )。

 

 

轉載：http://www.cnblogs.com/zyf-zhaoyafei/p/4716297.html