八股文七：計網

七、計算機網絡

1、TCP/IP 五層模型

• 實體層：RJ45、CLOCK、IEEE802.3（中繼器、集線器）

主要定義實體裝置标準，例如網線的接口類型、光線的接口類型、各種傳輸媒體的傳輸速率等。他的主要作用是傳入比特流（就是由1、0轉化為電流強弱來進行傳輸，到達目的地後再轉化為1、0，也就是我們通常所說的數模轉換與模數轉換）。這一層的資料叫做比特流。

• 資料鍊路層：PPP、FR、HDLC、VLAN、MAC（網橋、交換機）

定義了如何讓資料格式化進行傳輸，以及如何讓控制對實體媒體的通路。這一層通常還提供了錯誤檢測和糾正，以保證資料的可靠傳輸。

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

在位于不同地理位置的網絡中的兩個主機之間提供連接配接和路徑選擇。Internet的發展使得從世界各站點通路資訊的使用者數大大增加，而網絡層正是管理這種連接配接的層。（RARP:Reverse Address Resolution Protocal,逆位址解析協定。 允許區域網路的實體機器從網關伺服器的ARP表或緩存上請求IP位址。）（ARP協定的作用是通過目标裝置的IP位址，查詢目标裝置的MAC位址，以保證通信的順利進行，将計算機的網絡位址【IP位址32位】轉化為實體位址【MAC位址48位】。）

• 傳輸層：TCP、UDP、SPX

定義了一些傳輸資料的協定和端口号（WWW端口80等），如：TCP（傳輸控制協定TCP，傳輸效率低，可靠性強，用于傳輸可靠性要求高，資料量大的資料）和UDP（使用者資料報協定UDP，與TCP特性恰恰相反，用于傳輸可靠性要求不高、資料量小的資料，如QQ聊天資料就是通過這種方式傳輸的）。主要是将從下層的接收的資料進行分段和傳輸，到達目的地後再進行傳輸。常常把這一層資料叫做段。

• 會話層：NFS、SQL、NETBIOS、RPC

通過運輸層（端口号：傳輸端口與接收端口）建立資料傳輸的通路。主要在你的系統之間發起會話或者就受會話請求（裝置之間需要互相認識可以是IP位址也可以是MAC位址或者主機名）。

• 表示層：JPEG、MPEG、ASII

可以確定一個系統的應用層所發送的資訊可以被另一個系統的應用層讀取。例如，PC程式與另一台程式計算機進行通信，其中一台計算機使用擴充二一十進制交換碼（EBCDIC），而另一台則使用美國資訊交換标準碼（ASCII）來表示相同的字元。如有必要，表示層會通過使用一種通用格式來實作多種資料格式之間的轉換。

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

是最靠近使用者的OSI層。這一層為使用者的應用程式（如：電子郵件、檔案傳輸和仿真終端）提供網絡服務。

2、浏覽器輸入位址後做了什麼？

1、在浏覽器中輸入www.qq.com域名，作業系統會先檢查自己本地的hosts檔案是否有這個網址映射關系，如果有，就先調用這個IP位址映射，完成域名解析。

2、如果hosts裡沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關系，如果有，直接傳回，完成域名解析。

3、如果hosts與本地DNS解析器緩存都沒有相應的網址映射關系，首先會找TCP/ip參數中設定的首選DNS伺服器，在此我們叫它本地DNS伺服器，此伺服器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則傳回解析結果給客戶機，完成域名解析，此解析具有權威性。

4、如果要查詢的域名，不由本地DNS伺服器區域解析，但該伺服器已緩存了此網址映射關系，則調用這個IP位址映射，完成域名解析，此解析不具有權威性。

5、如果本地DNS伺服器本地區域檔案與緩存解析都失效，則根據本地DNS伺服器的設定（是否設定轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13台根DNS，根DNS伺服器收到請求後會判斷這個域名(.com)是誰來授權管理，并會傳回一個負責該頂級域名伺服器的一個IP。本地DNS伺服器收到IP資訊後，将會聯系負責.com域的這台伺服器。這台負責.com域的伺服器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS伺服器位址(qq.com)給本地DNS伺服器。當本地DNS伺服器收到這個位址後，就會找qq.com域伺服器，重複上面的動作，進行查詢，直至找到www.qq.com主機。

6、如果用的是轉發模式，此DNS伺服器就會把請求轉發至上一級DNS伺服器，由上一級伺服器進行解析，上一級伺服器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS伺服器用是是轉發，還是根提示，最後都是把結果傳回給本地DNS伺服器，由此DNS伺服器再傳回給客戶機。

從用戶端到本地DNS伺服器是屬于遞歸查詢，而DNS伺服器之間就是的互動查詢就是疊代查詢。

3、三次握手與四次揮手

• 三次握手

  

• 為什麼要三次握手？

  如果不是三次握手，隻有兩次

  如果用戶端送出請求連接配接時，封包延時了，于是用戶端重新發送了一次連接配接請求消息

  後來收到了确認，建立了連接配接，然後完成了資料傳輸，關閉了連接配接

  此時，伺服器收到了那個遲到的請求消息，此時他應該是個廢物了

  但是如果隻有兩次握手，伺服器收到請求就響應建立了連接配接了

  但是如果是三次，用戶端不會再次确認，伺服器也就随後知道了這消息有問題，不會建立連接配接

• 三次握手的過程

  1）主機A向主機B發送TCP連接配接請求資料包，其中包含主機A的初始序列号seq(A)=x。（其中封包中同步标志位SYN=1，ACK=0，表示這是一個TCP連接配接請求資料封包；序号seq=x，表明傳輸資料時的第一個資料位元組的序号是x）；

  2）主機B收到請求後，會發回連接配接确認資料包。（其中确認封包段中，辨別位SYN=1，ACK=1，表示這是一個TCP連接配接響應資料封包，并含主機B的初始序列号seq(B)=y，以及主機B對主機A初始序列号的确認号ack(B)=seq(A)+1=x+1）

  3）第三次，主機A收到主機B的确認封包後，還需作出确認，即發送一個序列号seq(A)=x+1；确認号為ack(A)=y+1的封包；

• 四次揮手

  

• 四次揮手也是一個互相确認的過程，你說不玩了，别人答應了，還要等别人都搞好了再告訴你可以走了，你才能走

  用戶端：我不想玩了

  伺服器：好的我知道了

  伺服器：你可以走了

  用戶端：好的我走了

  就如同在網吧上網，你點選下機之後，再去網管那邊結賬

  結賬清楚了之後才徹底結束，而不是你說走就走了，難道你辦會員卡了麼

  這個過程很好了解，用戶端送出請求後，并不意味着伺服器都已經完成響應

  是以當用戶端請求斷開時，并不能立即斷開，還需要等待伺服器那邊處理妥當，再來通知你的确是可以斷開了

  消息發出來誰知道别人收沒收到，是以還需要一個确認

• 四次揮手過程

  假設主機A為用戶端，主機B為伺服器，其釋放TCP連接配接的過程如下：

  1） 關閉用戶端到伺服器的連接配接：首先用戶端A發送一個FIN，用來關閉客戶到伺服器的資料傳送，然後等待伺服器的确認。其中終止标志位FIN=1，序列号seq=u。

  2） 伺服器收到這個FIN，它發回一個ACK，确認号ack為收到的序号加1。

  3） 關閉伺服器到用戶端的連接配接：也是發送一個FIN給用戶端。

  4） 客戶段收到FIN後，并發回一個ACK封包确認，并将确認序号seq設定為收到序号加1。 首先進行關閉的一方将執行主動關閉，而另一方執行被動關閉。

4、TIME_WAIT 與 CLOSE_WAIT

5、TCP 滑動視窗

TCP 流量控制，主要使用滑動視窗協定，滑動視窗是接受資料端使用的視窗大小，用來告訴發送端接收端的緩存大小，以此可以控制發送端發送資料的大小，進而達到流量控制的目的。這個視窗大小就是我們一次傳輸幾個資料。對所有資料幀按順序賦予編号，發送方在發送過程中始終保持着一個發送視窗，隻有落在發送視窗内的幀才允許被發送；同時接收方也維持着一個接收視窗，隻有落在接收視窗内的幀才允許接收。

6、TCP 粘包和拆包

• 現象

  

• 産生原因 1、要發送的資料大于 TCP 發送緩沖區剩餘空間大小，将會發生拆包。 2、待發送資料大于 MSS（最大封包長度），TCP 在傳輸前将進行拆包。 3、要發送的資料小于 TCP 發送緩沖區的大小，TCP 将多次寫入緩沖區的資料一次發送出去，将會發生粘包。 4、接收資料端的應用層沒有及時讀取接收緩沖區中的資料，将發生粘包。
• 解決方式 1、發送端給每個資料包添加包首部，首部中應該至少包含資料包的長度，這樣接收端在接收到資料後，通過讀取包首部的長度字段，便知道每一個資料包的實際長度了。 2、發送端将每個資料包封裝為固定長度（不夠的可以通過補 0 填充），這樣接收端每次從接收緩沖區中讀取固定長度的資料就自然而然的把每個資料包拆分開來。 3、可以在資料包之間設定邊界，如添加特殊符号，這樣，接收端通過這個邊界就可以将不同的資料包拆分開。

常見問題：

• http狀态碼？

1**	資訊，伺服器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收并處理
3**	重定向，需要進一步的操作以完成請求
4**	用戶端錯誤，請求包含文法錯誤或無法完成請求
5**	伺服器錯誤，伺服器在處理請求的過程中發生了錯誤

http狀态碼304的含義：304(未修改)自從上次請求後，請求的網頁未修改過。伺服器傳回此響應時，不會傳回網頁内容。如果網頁自請求者上次請求後再也沒有更改過，您應将伺服器配置為傳回此響應(稱為 If-Modified-Since HTTP 标頭)。伺服器可以告訴 Googlebot 自從上次抓取後網頁沒有變更，進而節省帶寬和開銷。

502和504的差別：

• 502：作為網關或者代理工作的伺服器嘗試執行請求時，從上遊伺服器接收到無效的響應。
• 504：作為網關或者代理工作的伺服器嘗試執行請求時，未能及時從上遊伺服器（URI辨別出的伺服器，例如HTTP、FTP、LDAP）或者輔助伺服器（例如DNS）收到響應。

• http&https差別？

• https協定要申請證書到ca，需要一定經濟成本；
• http是明文傳輸，https是加密的安全傳輸；
• 連接配接的端口不一樣，http是80，https是443；
• http連接配接很簡單，沒有狀态；（無狀态是指協定對于事務處理沒有記憶功能。缺少狀态意味着，假如後面的處理需要前面的資訊，則前面的資訊必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要前面資訊時，應答就較快。直覺地說，就是每個請求都是獨立的，與前面的請求和後面的請求都是沒有直接聯系的是互相隔離的，請求本身包含了相應端為相應這一請求所需的全部資訊。）
• https是ssl加密的傳輸，身份認證的網絡協定，相對http傳輸比較安全。

SSL協定過程：（有狀态的協定，https是無狀态加有狀态）

1、 用戶端送出請求：首先，用戶端（通常是浏覽器）先向伺服器發出加密通信的請求，這被叫做ClientHello請求。

2、伺服器回應：伺服器收到用戶端請求後，向用戶端發出回應，這叫做SeverHello。

3、用戶端回應：用戶端收到伺服器回應以後，首先驗證伺服器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一緻、或者證書已經過期，就會向通路者顯示一個警告，由其選擇是否還要繼續通信。

4、伺服器的最後回應：伺服器收到用戶端的第三個随機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。然後，向用戶端最後發送下面資訊。

（1）編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。

（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供用戶端校驗。

至此，整個握手階段全部結束。接下來，用戶端與伺服器進入加密通信，就完全是使用普通的HTTP協定，隻不過用"會話密鑰"加密内容。

• tcp為什麼更加可靠？

（三次握手，四次揮手，逾時重傳，滑動視窗，擁塞控制。）

• http1.1&1.0的差別？

緩存處理，在HTTP1.0中主要使用header裡的If-Modified-Since,Expires來做為緩存判斷的标準，HTTP1.1則引入了更多的緩存控制政策例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存政策。

帶寬優化及網絡連接配接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如用戶端隻是需要某個對象的一部分，而伺服器卻将整個對象送過來了，并且不支援斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許隻請求資源的某個部分，即傳回碼是206（Partial Content），這樣就友善了開發者自由的選擇以便于充分利用帶寬和連接配接。

錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀态響應碼，如409（Conflict）表示請求的資源與資源的目前狀态發生沖突；410（Gone）表示伺服器上的某個資源被永久性的删除。

Host頭處理，在HTTP1.0中認為每台伺服器都綁定一個唯一的IP位址，是以，請求消息中的URL并沒有傳遞主機名（hostname）。但随着虛拟主機技術的發展，在一台實體伺服器上可以存在多個虛拟主機（Multi-homed Web Servers），并且它們共享一個IP位址。HTTP1.1的請求消息和響應消息都應支援Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。

長連接配接，HTTP 1.1支援長連接配接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接配接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接配接的消耗和延遲，在HTTP1.1中預設開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要建立連接配接的缺點。

•  arp協定與arp攻擊

ARP協定的作用是通過目标裝置的IP位址，查詢目标裝置的MAC位址，以保證通信的順利進行，将計算機的網絡位址【IP位址32位】轉化為實體位址【MAC位址48位】。ARP攻擊的第一步就是ARP欺騙。由上述“ARP協定的工作過程”我們知道，ARP協定基本沒有對網絡的安全性做任何思考，當時人們考慮的重點是如何保證網絡通信能夠正确和快速的完成——ARP協定工作的前提是預設了其所在的網絡是一個善良的網絡，每台主機在向網絡中發送應答信号時都是使用的真實身份。不過後來，人們發現ARP應答中的IP位址和MAC位址中的資訊是可以僞造的，并不一定是自己的真實IP位址和MAC位址，由此，ARP欺騙就産生了。

• 路由器和交換機的差別

1、工作層次不同：交換機工作在資料鍊路層，而路由器工作在網絡層；

2、資料轉發所依據的對象不同：交換機的資料轉發依據是利用實體位址或者說MAC位址來确定轉發資料的目的位址轉發資料幀，而路由器是依據ip位址進行工作的；

3、傳統的交換機隻能分割沖突域，不能分割廣播域;而路由器可以分割廣播域

4、工作原理：交換機的原理比較簡單，一般都是采用硬體電路實作資料幀的轉發。路由器工作在網絡層，肩負着網絡互聯的重任，要實作更加複雜的協定，具有更加智能的轉發決策功能，一般都會在在路由器中跑作業系統，實作複雜的路由算法，更偏向于軟體實作其功能；

• 負載均衡&反向代理

（1）反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連接配接請求，然後将請求轉發給内部網絡上的伺服器，并将從伺服器上得到的結果傳回給internet上請求連接配接的用戶端，此時代理伺服器對外就表現為一個伺服器。

（2）反向代理負載均衡技術是把将來自internet上的連接配接請求以反向代理的方式動态地轉發給内部網絡上的多台伺服器進行處理，進而達到負載均衡的目的。

（3）反向代理負載均衡能以軟體方式來實作，如apache mod_proxy、netscape proxy等，也可以在高速緩存器、負載均衡器等硬體裝置上實作。反向代理負載均衡可以将優化的負載均衡政策和代理伺服器的高速緩存技術結合在一起，提升靜态網頁的通路速度，提供有益的性能；由于網絡外部使用者不能直接通路真實的伺服器，具備額外的安全性（同理，NAT負載均衡技術也有此優點）。

（4）其缺點主要表現在以下兩個方面

反向代理是處于OSI參考模型第七層應用的，是以就必須為每一種應用服務專門開發一個反向代理伺服器，這樣就限制了反向代理負載均衡技術的應用範圍，現在一般都用于對web伺服器的負載均衡。

針對每一次代理，代理伺服器就必須打開兩個連接配接，一個對外，一個對内，是以在并發連接配接請求數量非常大的時候，代理伺服器的負載也就非常大了，在最後代理伺服器本身會成為服務的瓶頸。

一般來講，可以用它來對連接配接數量不是特别大，但每次連接配接都需要消耗大量處理資源的站點進行負載均衡，如search等。