互聯網校招面試必備——計算機網絡 | 掘金技術徵文

本文首發於個人我的博客：尾尾部落

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

每一層的做用：

• 物理層：經過媒介傳輸比特,肯定機械及電氣規範（比特Bit）
• 數據鏈路層：將比特組裝成幀和點到點的傳遞（幀Frame）
• 網絡層：負責數據包從源到宿的傳遞和網際互連（包Packet）
• 傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）
• 會話層：創建、管理和終止會話（會話協議數據單元SPDU）
• 表示層：對數據進行翻譯、加密和壓縮（表示協議數據單元PPDU）
• 應用層：容許訪問OSI環境的手段（應用協議數據單元APDU）

每一層的協議：

• 物理層：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

TCP對應的應用層協議

• FTP：定義了文件傳輸協議，使用21端口。常說某某計算機開了FTP服務即是啓動了文件傳輸服務。下載文件，上傳主頁，都要用到FTP服務。
• Telnet：它是一種用於遠程登錄的端口，用戶能夠以本身的身份遠程鏈接到計算機上，經過這種端口能夠提供一種基於DOS模式下的通訊服務。如之前的BBS是-純字符界面的，支持BBS的服務器將23端口打開，對外提供服務。
• SMTP：定義了簡單郵件傳送協議，如今不少郵件服務器都用的是這個協議，用於發送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，因此在電子郵件設置-中常看到有這麼SMTP端口設置這個欄，服務器開放的是25號端口。
• POP3：它是和SMTP對應，POP3用於接收郵件。一般狀況下，POP3協議所用的是110端口。也是說，只要你有相應的使用POP3協議的程序（例如Fo-xmail或Outlook），就能夠不以Web方式登錄進郵箱界面，直接用郵件程序就能夠收到郵件（如是163郵箱就沒有必要先進入網易網站，再進入本身的郵-箱來收信）。
• HTTP：從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

UDP對應的應用層協議

• DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。
• SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。因爲網絡設備不少，無鏈接的服務就體現出其優點。
• TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。

IP地址的分類

• A類地址：以0開頭， 第一個字節範圍：0~127（1.0.0.0 - 126.255.255.255）；
• B類地址：以10開頭， 第一個字節範圍：128~191（128.0.0.0 - 191.255.255.255）；
• C類地址：以110開頭， 第一個字節範圍：192~223（192.0.0.0 - 223.255.255.255）；

10.0.0.0—10.255.255.255， 172.16.0.0—172.31.255.255， 192.168.0.0—192.168.255.255。（Internet上保留地址用於內部）

ARP協議

ARP地址解析協議，簡單說就是，在IP以太網中，當一個上層協議要發包時，有了該節點的IP地址，ARP就能提供該節點的MAC地址。它的工做原理以下：

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查詢失敗。
5. 若是目標IP與本身不在同一個網段，這種狀況須要將包發給默認網關，因此主要獲取網關的MAC地址。若是arp高速緩存有默認網關的MAC地址，直接發送IP數據報道默認網關，再由網關轉發到外網；若是arp高速緩存沒有默認網關的MAC地址，仍是發送ARP廣播請求默認網關的MAC地址，緩存該地址，而且發送數據報到網關。

HTTP協議

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。HTTP協議的主要特色可歸納以下：

• 支持客戶/服務器模式。
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
• 靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

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 鏈接都將被一直保持下去。

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

• 第一次揮手：客戶端主動關閉方發送一個FIN，用來關閉客戶端到服務端的數據傳送，也就是客戶端告訴服務端：我已經不會再給你發數據了(固然，在fin包以前發送出去的數據，若是沒有收到對應的ack確認報文，客戶端依然會重發這些數據)，可是，此時客戶端還能夠接受數據。
• 第二次揮手：服務端收到FIN包後，發送一個ACK給客戶端，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號）。
• 第三次揮手：服務端發送一個FIN，用來關閉服務端到客戶端的數據傳送，也就是告訴客戶端，個人數據也發送完了，不會再給你發數據了。
• 第四次揮手：客戶端收到FIN後，發送一個ACK給服務端，確認序號爲收到序號+1，至此，完成四次揮手。

第3次握手失敗會怎麼辦?

第三次失敗，只有客戶端處於成功狀態（由於第2次服務器返回了ACK），服務器端沒有接收到客戶端的 ACK。 這要分幾種狀況討論：

• In other words, if the ACK is dropped but the next packet is not dropped, then everything is fine. 也就是說客戶端發出的 ACK 丟失了，發出的 下一個數據包 沒有丟失，則服務端接收到下一個數據包（這個數據包裏也會帶上 ACK 信息），可以進入正常的 ESTABLISHED 狀態
• 若是服務端和客戶端都沒有數據發送，或者服務端想發送數據（可是發不了，由於沒有收到客戶端的 ACK），服務器都會有定時器發送第二步SYN+ACK數據包，若是客戶端再次發送ACK成功，創建鏈接。
• 若是一直不成功，服務器確定會有超時設置，超時以後會給客戶端發RTS報文，進入CLOSED狀態，防止SYN洪泛攻擊。

爲何TCP連接須要三次握手，兩次不能夠麼，爲何？

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

爲何鏈接的時候是三次握手，關閉的時候倒是四次握手?

TCP是全雙工模式，關閉鏈接時，當主機B收到主機A的FIN報文時，僅僅表示主機 A再也不發送數據了可是還能接收數據。此時，主機B也未必所有數據都發送給A了，因此B能夠當即close；也能夠發送一些數據給A後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，主機BACK和FIN通常都會分開發送。

TCP的擁塞處理

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

• 慢啓動：不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增長擁塞窗口的大小;

• 擁塞避免：擁塞避免算法讓擁塞窗口緩慢增加，即每通過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規律緩慢增加。

  

• 快重傳：快重傳要求接收方在收到一個 失序的報文段 後就當即發出 重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到本身發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段，而沒必要繼續等待設置的重傳計時器時間到期。

  

• 快恢復：快重傳配合使用的還有快恢復算法，當發送方連續收到三個重複確認時，就執行「乘法減少」算法，把ssthresh門限減半，可是接下去並不執行慢開始算法：由於若是網絡出現擁塞的話就不會收到好幾個重複的確認，因此發送方如今認爲網絡可能沒有出現擁塞。因此此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，而後執行擁塞避免算法。

  

TCP協議如何來保證傳輸的可靠性

TCP提供一種面向鏈接的、可靠的字節流服務。其中，面向鏈接意味着兩個使用TCP的應用（一般是一個客戶和一個服務器）在彼此交換數據以前必須先創建一個TCP鏈接。在一個TCP鏈接中，僅有兩方進行彼此通訊；而字節流服務意味着兩個應用程序經過TCP連接交換8bit字節構成的字節流，TCP不在字節流中插入記錄標識符。 對於可靠性，TCP經過如下方式進行保證：

• 數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時TCP發送數據端超時後會重發數據；
• 對失序數據包重排序：既然TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。TCP將對失序數據進行從新排序，而後才交給應用層；
• 丟棄重複數據：對於重複數據，可以丟棄重複數據；
• 應答機制：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒；
• 超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段；
• 流量控制：TCP鏈接的每一方都有固定大小的緩衝空間。TCP的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

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

1. 瀏覽器查詢 DNS，獲取域名對應的IP地址:具體過程包括瀏覽器搜索自身的DNS緩存、搜索操做系統的DNS緩存、讀取本地的Host文件和向本地DNS服務器進行查詢等。對於向本地DNS服務器進行查詢，若是要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具備權威性)；若是要查詢的域名不禁本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析（此解析不具備權威性）。若是本地域名服務器並未緩存該網址映射關係，那麼將根據其設置發起遞歸查詢或者迭代查詢；
2. 瀏覽器得到域名對應的IP地址之後，瀏覽器向服務器請求創建連接，發起三次握手；
3. TCP/IP連接創建起來後，瀏覽器向服務器發送HTTP請求；
4. 服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將處理結果及相應的視圖返回給瀏覽器；
5. 瀏覽器解析並渲染視圖，若遇到對js文件、css文件及圖片等靜態資源的引用，則重複上述步驟並向服務器請求這些資源；
6. 瀏覽器根據其請求到的資源、數據渲染頁面，最終向用戶呈現一個完整的頁面。

Session 與 Cookie 的對比

實現機制：Session的實現經常依賴於Cookie機制，經過Cookie機制回傳SessionID； 大小限制：Cookie有大小限制而且瀏覽器對每一個站點也有cookie的個數限制，Session沒有大小限制，理論上只與服務器的內存大小有關； 安全性：Cookie存在安全隱患，經過攔截或本地文件找獲得cookie後能夠進行攻擊，而Session因爲保存在服務器端，相對更加安全； 服務器資源消耗：Session是保存在服務器端上會存在一段時間纔會消失，若是session過多會增長服務器的壓力。 Application（ServletContext）：與一個Web應用程序相對應，爲應用程序提供了一個全局的狀態，全部客戶均可以使用該狀態。

交換機和路由器分別的實現原理是什麼？分別在哪一個層次上面實現的？

交換機用於局域網，利用主機的MAC地址進行數據傳輸，而不須要關心IP數據包中的IP地址，它工做於數據鏈路層。路由器識別網絡是經過IP數據包中IP地址的網絡號進行的，因此爲了保證數據包路由的正確性，每一個網絡都必須有一個惟一的網絡號。路由器經過IP數據包的IP地址進行路由的（將數據包遞交給哪一個下一跳路由器）。路由器工做於網絡層。因爲設備如今的發展，如今不少設備既具備交換又具備路由功能，二者的界限愈來愈模糊。

TCP和UDP的區別

• TCP的優勢： 可靠，穩定 TCP的可靠體如今TCP在傳遞數據以前，會有三次握手來創建鏈接，並且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開鏈接用來節約系統資源。 TCP的缺點： 慢，效率低，佔用系統資源高，易被攻擊 TCP在傳遞數據以前，要先建鏈接，這會消耗時間，並且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，並且要在每臺設備上維護全部的傳輸鏈接，事實上，每一個鏈接都會佔用系統的CPU、內存等硬件資源。 並且，由於TCP有確認機制、三次握手機制，這些也致使TCP容易被人利用，實現DOS、DDOS、CC等攻擊。
• UDP的優勢：快，比TCP稍安全 UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，因此它在傳遞數據時很是快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是沒法避免攻擊的，好比：UDP Flood攻擊…… UDP的缺點： 不可靠，不穩定 由於UDP沒有TCP那些可靠的機制，在數據傳遞時，若是網絡質量很差，就會很容易丟包。 基於上面的優缺點，那麼： 何時應該使用TCP： 當對網絡通信質量有要求的時候，好比：整個數據要準確無誤的傳遞給對方，這每每用於一些要求可靠的應用，好比HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。 在平常生活中，常見使用TCP協議的應用以下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸 ………… 何時應該使用UDP： 當對網絡通信質量要求不高的時候，要求網絡通信速度能儘可能的快，這時就可使用UDP。 好比，平常生活中，常見使用UDP協議的應用以下： QQ語音 QQ視頻 TFTP …… 有些應用場景對可靠性要求不高會用到UPD，好比長視頻，要求速率

	TCP	UDP
鏈接	面向鏈接	面向無鏈接
可靠性	可靠，無差錯，不丟失，不重複	盡最大努力交付，即不保證可靠交付
模式	流模式（字節流）	數據報模式（報文）
鏈接	點到點	支持一對一，一對多，多對一和多對多的交互通訊
首部開銷	20字節	8個字節
邏輯通訊信道	全雙工的可靠信道	不可靠信道
速度	慢	快
對系統資源要求	較多	較少

HTTP和HTTPS

• HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。
• HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

Http和Https的區別

Http協議運行在TCP之上，明文傳輸，客戶端與服務器端都沒法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行於SSL上，SSL運行於TCP之上，是添加了加密和認證機制的HTTP。兩者之間存在以下不一樣： 端口不一樣：Http與Http使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443； 資源消耗：和HTTP通訊相比，Https通訊會因爲加減密處理消耗更多的CPU和內存資源； 開銷：Https通訊須要證書，而證書通常須要向認證機構購買； Https的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。

HTTPS採用混合加密機制

因爲公有密鑰的機制相對複雜，致使其處理速度相對較慢。因而HTTPS利用了二者的優點，採用了混合加密的機制。咱們知道，共享（對稱）密鑰未能解決的問題是如何可以安全地把密鑰發送給對方。只要解決了這個問題就能夠進行安全地通訊。因而，HTTPS首先是經過公有密鑰來對共享密鑰進行加密傳輸。當共享密鑰安全地傳輸給對方後，雙方則使用共享密鑰的方式來加密報文，以此來提升傳輸的效率。

步驟1：向服務器發起請求。 步驟2-3：取出公有密鑰及證書併發送給客戶端。 步驟4：客戶端判斷公有密鑰是否有效，無效則顯示警告。有效則生成一個隨機數串，並以今生成客戶端的共享密鑰。 步驟5：用步驟3獲得的公有密鑰對該隨機數串加密，發送到服務器。 步驟6：服務器獲得加密報文，用私有密鑰解密報文，獲得隨機數串，並以今生成服務器端的共享密鑰。此時客戶端和服務端擁有相同的共享密鑰，能夠用該共享密鑰進行安全通訊。 步驟7-8：服務器對響應進行加密，客戶端對報文進行解密。

HTTPS的優勢

儘管HTTPS並不是絕對安全，掌握根證書的機構、掌握加密算法的組織一樣能夠進行中間人形式的攻擊，但HTTPS還是現行架構下最安全的解決方案，主要有如下幾個好處： （1）使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器； （2）HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。 （3）HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。 （4）谷歌曾在2014年8月份調整搜索引擎算法，並稱「比起同等HTTP網站，採用HTTPS加密的網站在搜索結果中的排名將會更高」。

HTTPS的缺點

雖說HTTPS有很大的優點，但其相對來講，仍是存在不足之處的： （1）HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增長10%到20%的耗電； （2）HTTPS鏈接緩存不如HTTP高效，會增長數據開銷和功耗，甚至已有的安全措施也會所以而受到影響； （3）SSL證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用。 （4）SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。 （5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行。

socket

socket是通訊的基石。支持TCP/IP等協議的基本操做單元。 應用層經過傳輸層進行數據通訊時，TCP會遇到同時爲多個應用程序進程提供併發服務的問題。多個TCP鏈接或多個應用程序進程可能須要經過同一個TCP協議端口傳輸數據。爲了區別不一樣的應用程序進程和鏈接，許多計算機操做系統爲應用程序與TCP／IP協議交互提供了套接字(Socket)接口。應用層能夠和傳輸層經過Socket接口，區分來自不一樣應用程序進程或網絡鏈接的通訊，實現數據傳輸的併發服務。

參考

計算機網絡之面試常考 面試/筆試第一彈 —— 計算機網絡面試問題集錦

獲取更多最新資訊，免費獲取百G視頻教程 請關注微信公衆號：南強說晚安

我在參加掘金技術徵文 徵文活動地址