計算機網絡知識點整理

【筆試】計算機網絡知識點整理

2018-07-25 23:51:39 Sha777wee 閱讀數 8526更多

分類專欄： 筆試

1. OSI與TCP/IP各層的結構與功能，都有哪些協議。 
 
OSI模型 
　　OSI（Open System Interconnection，開放系統互連）七層網絡模型稱爲開放式系統互聯參考模型 ，是一個邏輯上的定義，一個規範，它把網絡從邏輯上分爲了7層。每一層都有相關、相對應的物理設備，好比路由器，交換機。 
　　OSI七層模型是一種框架性的設計方法，創建七層模型的主要目的是爲解決異種網絡互連時所遇到的兼容性問題，其最主要的功能就是幫助不一樣類型的主機實現數據傳輸。它的最大優勢是將服務、接口和協議這三個概念明確地區分開來，經過七個層次化的結構模型使不一樣的系統不一樣的網絡之間實現可靠的通信。

OSI是Open System Interconnect的縮寫，意爲開放式系統互聯。

OSI七層參考模型的各個層次的劃分遵循下列原則： 
一、同一層中的各網絡節點都有相同的層次結構，具備一樣的功能。 
二、同一節點內相鄰層之間經過接口（能夠是邏輯接口）進行通訊。 
三、七層結構中的每一層使用下一層提供的服務，而且向其上層提供服務。 
四、不一樣節點的同等層按照協議實現對等層之間的通訊。

各層簡介：

　　【1】物理層：主要定義物理設備標準，如網線的接口類型、光纖的接口類型、各類傳輸介質的傳輸速率等。它的主要做用是傳輸比特流（就是由一、0轉化爲電流強弱來進行傳輸,到達目的地後在轉化爲一、0，也就是咱們常說的數模轉換與模數轉換），這一層的數據叫作比特。

　　【2】數據鏈路層：負責物理傳輸的準備。在物理層提供比特流服務的基礎上，創建相鄰結點之間的數據鏈路，經過差錯控制提供數據幀（Frame）在信道上無差錯的傳輸，並進行各電路上的動做系列。數據鏈路層在不可靠的物理介質上提供可靠的傳輸。該層的做用包括：物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。在這一層，數據的單位稱爲幀（frame）。數據鏈路層協議的表明包括：SDLC、HDLC、PPP、STP、幀中繼等。MAC地址和交換機在這一層。

　　【3】網絡層：在 計算機網絡中進行通訊的兩個計算機之間可能會通過不少個數據鏈路，也可能還要通過不少通訊子網。網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。網絡層將數據鏈路層提供的幀組成數據包，包中封裝有網絡層包頭，其中含有邏輯地址信息- -源站點和目的站點地址的網絡地址。如 果你在談論一個IP地址，那麼你是在處理第3層的問題，這是「數據包」問題，而不是第2層的「幀」。IP是第3層問題的一部分，此外還有一些路由協議和地 址解析協議（ARP）。有關路由的一切事情都在這第3層處理。地址解析和路由是3層的重要目的。網絡層還能夠實現擁塞控制、網際互連等功能。在這一層，數據的單位稱爲數據包（packet）。網絡層協議的表明包括：IP、IPX、RIP、OSPF等。負責管理網絡地址、定位設備、決定路由，路由器工做在這層。包括用戶數據包，路由更新包。

　　【4】傳輸層：OSI中最重要的一層，負責分割組合數據，實現端到端的邏輯鏈接。第4層的數據單元也稱做數據包（packets）。可是，當你談論TCP等具體的協議時又有特殊的叫法，TCP的數據單元稱爲段 （segments）而UDP協議的數據單元稱爲「數據報（datagrams）」。這個層負責獲取所有信息，所以，它必須跟蹤數據單元碎片、亂序到達的 數據包和其它在傳輸過程當中可能發生的危險。第4層爲上層提供端到端（最終用戶到最終用戶）的透明的、可靠的數據傳輸服務。所爲透明的傳輸是指在通訊過程當中 傳輸層對上層屏蔽了通訊傳輸系統的具體細節。傳輸層協議的表明包括：TCP、UDP、SPX等。

　　【5】會話層：負責在網絡中兩個節點間創建、維護、控制會話，區分不一樣的會話，以及提供單工、半雙工、全雙工三種通訊模式服務。經過傳輸層（端口號：傳輸端口與接收端口）創建數據傳輸的通路，主要在你的系統之間發起會話或者接受會話請求（設備之間須要互相認識能夠是IP也能夠是MAC或者是主機名）。NFS、X Windows、RPC都在這一層。

　　【6】表示層：可確保一個系統的應用層所發送的信息能夠被另外一個系統的應用層讀取。例如，PC程序與另外一臺計算機進行通訊，其中一臺計算機使用擴展二一十進制交換碼（EBCDIC），而另外一臺則使用美國信息交換標準碼（ASCII）來表示相同的字符。若有必要，表示層會經過使用一種通格式來實現多種數據格式之間的轉換。這一層主要解決信息的語法表示問題。它將欲交換的數據從適合於某一用戶的抽象語法，轉換爲適合於OSI系統內部使用的傳送語法。即提供格式化的表示和轉換數據服務。數據的壓縮和解壓縮， 加密和解密等工做都由表示層負責。

　　【7】應用層： 是最靠近用戶的OSI層，這一層爲用戶的操做系統或應用程序（例如電子郵件、文件傳輸和終端仿真）提供網絡服務。。應用層協議的表明包括：Telnet、FTP、HTTP、SNMP等。 
　　 
TCP/IP模型：

是最基本的Internet協議，有網絡層的IP和傳輸層的TCP構成。指TCP/IP協議簇。

分爲四層，每一層都呼叫他的下一層所提供的網絡來實現本身的需求。

一、網絡接口層負責底層的傳輸，常見協議有Ethernet 802.3 、Token Ring 802.五、X.25等。

二、網絡層負責不一樣計算機之間的通訊

三、傳輸層負責應用程序間的通訊，主要包括格式化信息流，提供可靠地傳輸等。

四、應用層傾向於向用戶提供服務，如電子郵件，遠程登陸等。

屬於TCP/IP協議簇的全部協議都位於該模型的上面三層。

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協議屬於傳輸層協議。其中TCP提供IP環境下的數據可靠傳輸，它提供的服務包括數據流傳送、可靠性、有效流控、全雙工操做和多路復 用。經過面向鏈接、端到端和可靠的數據包發送。通俗說，它是事先爲所發送的數據開闢出鏈接好的通道，而後再進行數據發送；而UDP則不爲IP提供可靠性、 流控或差錯恢復功能。通常來講，TCP對應的是可靠性要求高的應用，而UDP對應的則是可靠性要求低、傳輸經濟的應用。TCP支持的應用協議主要 有：Telnet、FTP、SMTP等；UDP支持的應用層協議主要有：NFS（網絡文件系統）、SNMP（簡單網絡管理協議）、DNS（主域名稱系 統）、TFTP（通用文件傳輸協議）等.

TCP/IP協議與低層的網絡接口層無關，這也是TCP/IP的重要特色。

除了層的數量以外，開放式系統互聯（OSI）模型與TCP/IP協議有什麼區別？

開放式系統互聯模型是一個參考標準，解釋協議相互之間應該如何相互做用。TCP/IP協議是美國國防部發明的，是讓互聯網成爲了目前這個樣子的標準之一。開放式系統互聯模型中沒有清楚地描繪TCP/IP協議，可是在解釋TCP/IP協議時很容易想到開放式系統互聯模型。二者的主要區別以下：

TCP/IP協議中的應用層處理開放式系統互聯模型中的第五層、第六層和第七層的功能。

TCP/IP協議中的傳輸層並不能老是保證在傳輸層可靠地傳輸數據包，而開放式系統互聯模型能夠作到。TCP/IP協議還提供一項名爲UDP（用戶數據報協議）的選擇。UDP不能保證可靠的數據包傳輸。

2. 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 ……

總結

• TCP面向鏈接（如打電話要先撥號創建鏈接）;UDP是無鏈接的，即發送數據以前不須要創建鏈接
• TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付
• TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流;UDP是面向報文的 
  UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）
• 每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊
• TCP首部開銷20字節;UDP的首部開銷小，只有8個字節
• TCP的邏輯通訊信道是全雙工的可靠信道，UDP則是不可靠信道

3. TCP報文結構。 
 
一、端口號：用來標識同一臺計算機的不一樣的應用進程。

1）源端口：源端口和IP地址的做用是標識報文的返回地址。

2）目的端口：端口指明接收方計算機上的應用程序接口。

TCP報頭中的源端口號和目的端口號同IP數據報中的源IP與目的IP惟一肯定一條TCP鏈接。

二、序號和確認號：是TCP可靠傳輸的關鍵部分。序號是本報文段發送的數據組的第一個字節的序號。在TCP傳送的流中，每個字節一個序號。 
這裏可參考理解TCP序列號（Sequence Number）和確認號（Acknowledgment Number）

三、數據偏移／首部長度：4bits。因爲首部可能含有可選項內容，所以TCP報頭的長度是不肯定的，報頭不包含任何任選字段則長度爲20字節，4位首部長度字段所能表示的最大值爲1111，轉化爲10進製爲15，15*32/8 = 60，故報頭最大長度爲60字節。首部長度也叫數據偏移，是由於首部長度實際上指示了數據區在報文段中的起始偏移值。

四、保留：爲未來定義新的用途保留，如今通常置0。

五、控制位：URG ACK PSH RST SYN FIN，共6個，每個標誌位表示一個控制功能。

1）URG：緊急指針標誌，爲1時表示緊急指針有效，爲0則忽略緊急指針。

2）ACK：確認序號標誌，爲1時表示確認號有效，爲0表示報文中不含確認信息，忽略確認號字段。

3）PSH：push標誌，爲1表示是帶有push標誌的數據，指示接收方在接收到該報文段之後，應儘快將這個報文段交給應用程序，而不是在緩衝區排隊。

4）RST：重置鏈接標誌，用於重置因爲主機崩潰或其餘緣由而出現錯誤的鏈接。或者用於拒絕非法的報文段和拒絕鏈接請求。

5）SYN：同步序號，用於創建鏈接過程，在鏈接請求中，SYN=1和ACK=0表示該數據段沒有使用捎帶的確認域，而鏈接應答捎帶一個確認，即SYN=1和ACK=1。

6）FIN：finish標誌，用於釋放鏈接，爲1時表示發送方已經沒有數據發送了，即關閉本方數據流。

六、窗口：滑動窗口大小，用來告知發送端接受端的緩存大小，以此控制發送端發送數據的速率，從而達到流量控制。窗口大小時一個16bit字段，於是窗口大小最大爲65535。

七、校驗和：奇偶校驗，此校驗和是對整個的 TCP 報文段，包括 TCP 頭部和 TCP 數據，以 16 位字進行計算所得。由發送端計算和存儲，並由接收端進行驗證。

八、緊急指針：只有當 URG 標誌置 1 時緊急指針纔有效。緊急指針是一個正的偏移量，和順序號字段中的值相加表示緊急數據最後一個字節的序號。 TCP 的緊急方式是發送端向另外一端發送緊急數據的一種方式。

九、選項和填充：最多見的可選字段是最長報文大小，又稱爲MSS（Maximum Segment Size），每一個鏈接方一般都在通訊的第一個報文段（爲創建鏈接而設置SYN標誌爲1的那個段）中指明這個選項，它表示本端所能接受的最大報文段的長度。選項長度不必定是32位的整數倍，因此要加填充位，即在這個字段中加入額外的零，以保證TCP頭是32的整數倍。

十、數據部分： TCP 報文段中的數據部分是可選的。在一個鏈接創建和一個鏈接終止時，雙方交換的報文段僅有 TCP 首部。若是一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多狀況中，也會發送不帶任何數據的報文段。

4. TCP的三次握手與四次揮手過程，各個狀態名稱與含義，TIMEWAIT的做用。 
 
詳細過程 

若是理解了上面的序號和確認號，這裏的理解也不難。 
一、客戶端發送報文SYN=1請求創建鏈接，並進入SYN-SENT狀態。這裏客戶端的初始序號爲隨機數X（可理解爲發送端發送的數據應排在接收端X位置上）。 
二、服務端接收到請求，發送報文SYN=1和ACK=1，前者表示贊成鏈接，後者表示客戶端上次發送過來的數據已經正常接收，並進入SYN-RCYD狀態。這裏服務端的初始序號爲隨機數Y，確認號爲X+1（可理解爲下次發送過來的數據應該在X+1位置上才正確）。 
三、客戶端接收到信息後再發送報文ACK=1表示確認，開啓鏈接，進入ESTABLISHED狀態。 
四、服務端接收到確認信息開啓鏈接，進入ESTABLISHED狀態。

關閉鏈接同理。

【注意】 在TIME_WAIT狀態中，若是TCP client端最後一次發送的ACK丟失了，server端等不到者個ACT將從新發送FIN給client端，client端接收到知道ACT報文丟失了將從新發送ACT報文。TIME_WAIT狀態中所須要的時間是依賴於實現方法的。典型的值爲30秒、1分鐘和2分鐘。等待以後鏈接正式關閉，而且全部的資源(包括端口號)都被釋放。

【問題1】爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？ 
答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，」你發的FIN報文我收到了」。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

【問題2】爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，咱們能夠直接進入CLOSE狀態了，可是咱們必須假象網絡是不可靠的，有能夠最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

5. TCP擁塞控制。 
通常原理：發生擁塞控制的緣由：資源(帶寬、交換節點的緩存、處理機)的需求>可用資源。

做用：擁塞控制就是爲了防止過多的數據注入到網絡中，這樣能夠使網絡中的路由器或者鏈路不至於過載。擁塞控制要作的都有一個前提：就是網絡可以承受現有的網絡負荷。

對比流量控制：擁塞控制是一個全局的過程，涉及到全部的主機、路由器、以及下降網絡相關的全部因素。流量控制每每指點對點通訊量的控制。是端對端的問題。

擁塞窗口：發送方爲一個動態變化的窗口叫作擁塞窗口，擁塞窗口的大小取決於網絡的擁塞程度。發送方讓本身的發送窗口=擁塞窗口，可是發送窗口不是一直等於擁塞窗口的，在網絡狀況好的時候，擁塞窗口不斷的增長，發送方的窗口天然也隨着增長，可是接受方的接受能力有限，在發送方的窗口達到某個大小時就不在發生變化了。

發送方如何知道網絡擁塞了呢？發送方發送一些報文段時，若是發送方沒有在時間間隔內收到接收方的確認報文段，則就能夠人爲網絡出現了擁塞。

慢啓動算法的思路：主機開發發送數據報時，若是當即將大量的數據注入到網絡中，可能會出現網絡的擁塞。慢啓動算法就是在主機剛開始發送數據報的時候先探測一下網絡的情況，若是網絡情況良好，發送方每發送一次文段都能正確的接受確認報文段。那麼就從小到大的增長擁塞窗口的大小，即增長髮送窗口的大小。

例子：開始發送方先設置cwnd（擁塞窗口）=1,發送第一個報文段M1，接收方接收到M1後，發送方接收到接收方的確認後，把cwnd增長到2，接着發送方發送M二、M3，發送方接收到接收方發送的確認後cwnd增長到4，慢啓動算法每通過一個傳輸輪次（認爲發送方都成功接收接收方的確認），擁塞窗口cwnd就加倍。

擁塞避免：爲了防止cwnd增長過快而致使網絡擁塞，因此須要設置一個慢開始門限ssthresh狀態變量（我也不知道這個究竟是什麼，就認爲他是一個擁塞控制的標識）,它的用法：

一、當cwnd < ssthresh,使用慢啓動算法，

二、 當cwnd > ssthresh,使用擁塞控制算法，停用慢啓動算法。

三、 當cwnd = ssthresh，這兩個算法均可以。

擁塞避免的思路：是讓cwnd緩慢的增長而不是加倍的增加，每經歷過一次往返時間就使cwnd增長1，而不是加倍，這樣使cwnd緩慢的增加，比慢啓動要慢的多。

不管是慢啓動算法仍是擁塞避免算法，只要判斷網絡出現擁塞，就要把慢啓動開始門限(ssthresh)設置爲設置爲發送窗口的一半（>=2），cwnd(擁塞窗口)設置爲1，而後在使用慢啓動算法，這樣作的目的能迅速的減小主機向網絡中傳輸數據，使發生擁塞的路由器可以把隊列中堆積的分組處理完畢。

實例：一、TCP鏈接進行初始化的時候，cwnd=1,ssthresh=16。

二、在慢啓動算法開始時，cwnd的初始值是1，每次發送方收到一個ACK擁塞窗口就增長1，當ssthresh =cwnd時，就啓動擁塞控制算法，擁塞窗口按照規律增加，

三、當cwnd=24時，網絡出現超時，發送方收不到確認ACK，此時設置ssthresh=12,(二分之一cwnd),設置cwnd=1,而後開始慢啓動算法，當cwnd=ssthresh=12,慢啓動算法變爲擁塞控制算法，cwnd按照線性的速度進行增加。 

快重傳：

快重傳算法要求首先接收方收到一個失序的報文段後就馬上發出重複確認，而不要等待本身發送數據時才進行捎帶確認。接收方成功的接受了發送方發送來的M一、M2而且分別給發送了ACK，如今接收方沒有收到M3，而接收到了M4，顯然接收方不能確認M4，由於M4是失序的報文段。若是根據可靠性傳輸原理接收方什麼都不作，可是按照快速重傳算法，在收到M四、M5等報文段的時候，不斷重複的向發送方發送M2的ACK,若是接收方一連收到三個重複的ACK,那麼發送方沒必要等待重傳計時器到期，因爲發送方儘早重傳未被確認的報文段。

快恢復：

當發送方連續接收到三個確認時，就執行乘法減少算法，把慢啓動開始門限（ssthresh）設置爲cwnd的一半，可是接下來並不執行慢開始算法。

此時不執行慢啓動算法，而是把cwnd設置爲新的ssthresh值， 而後執行擁塞避免算法，使擁塞窗口緩慢增大。

6. TCP滑動窗口與回退N針協議。 
滑動窗口協議 
 
一、發送端和接收端分別設定發送窗口和接收窗口。 
二、三次握手的時候，客戶端把本身的緩衝區大小也就是窗口大小發送給服務器，服務器迴應是也將窗口大小發送給客戶端，服務器客戶端都知道了彼此的窗口大小。 
三、好比主機A的發送窗口大小爲5，主機A能夠向主機B發送5個單元，若是B緩衝區滿了，A就要等待B確認才能繼續發送數據。 
四、若是緩衝區中有1個報文被進程讀取，主機B就會回覆ACK給主機A，接收窗口向前滑動，報文中窗口大小爲1，就說明A還能夠發送1個單元的數據，發送窗口向前滑動，以後等待主機B的確認報文。 
只有接收窗口向前滑動併發送了確認時，發送窗口才能向前滑動。

中止等待ARQ協議（stop and wait） 
 
當發送窗口和接收窗口都等於1時，就是中止等待協議。發送端給接收端發送數據，等待接收端確認回覆ACk，並中止發送新的數據包，開啓計時器。數據包在計時器超時以前獲得確認，那麼計時器就會關閉，併發送下一個數據包。若是計時器超時，發送端就認爲數據包丟失或被破壞，須要從新發送以前的數據包，說明數據包在獲得確認以前，發送端須要存儲數據包的副本。 
中止等待協議是發出一個幀後獲得確認才發下一個，下降了信道的利用率。

退後N幀協議 
 
在發送完一個幀後，不用停下來等待確認，而是能夠連續發送多個數據幀，這樣就減小了等待時間，整個通訊的通吞吐量提升。 
若是前一個幀在超時時間內未獲得確認，就認爲丟失或被破壞，須要重發出錯幀及其後面的全部數據幀。這樣有可能有把正確的數據幀重傳一遍，下降了傳送效率。 
線路不好時，使用退後N幀的協議會浪費大量的帶寬重傳幀。

選擇重傳協議 
 
NAK：非確認幀，當在必定時間內沒有收到某個數據幀的ACK時，回覆一個NACK。 
在發送過程當中，若是一個數據幀計時器超時，就認爲該幀丟失或者被破壞，接收端只把出錯的的幀丟棄，其後面的數據幀保存在緩存中，並向發送端回覆NAK。發送端接收到NAK時，只發送出錯的幀。 
若是落在窗口的幀從未接受過，那麼存儲起來，等比它序列號小的全部幀都按次序交給網絡層，那麼此幀才提交給網絡層。 
接收端收到的數據包的順序可能和發送的數據包順序不同。所以在數據包裏必須含有順序字符來幫助接受端來排序。 
選擇重傳協議能夠避免重複傳送那些正確到達接收端的數據幀。可是接收端要設置具備至關容量的緩存空間，這在許多狀況下是不夠經濟的。

7. Http的報文結構。 
http報文是面向文本的，報文中每個字段都是一些ASCII碼串，各個字段的長度是不肯定的。http有兩類報文：請求報文 響應報文

請求報文 
 
一、請求行

請求行由請求方法字段、URL字段和HTTP協議版本字段，組成，它們用空格分隔，例如：GET /index.html HTTP/1.1

HTTP協議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。這裏介紹最經常使用的GET和POST方法；

GET：當client要從server中讀取文檔時，使用GET方法。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，回送給client。

使用GET方法時，請求參數和對應的值附加在URL後面，利用一個問號（」?」）表明URL的結尾與請求參數的開始，傳遞參數長度受限制，例如： /index.jsp?id=100&op=bind

POST:當client給服務器提供信息較多時， 使用POST方法。POST方法將請求參數封裝在HTTP請求數據中，以key/value的形式出現，能夠傳遞大量數據，可用來傳遞文件

二、消息頭部

請求頭部由key/value鍵值對組成，每行一對，key和value用冒號」:」分隔，請求頭部通知服務器有關於client端的請求信息，典型的請求頭：

User-Agent：產生請求的瀏覽器類型 
Accept：client端可識別的內容類型列表 
Host：請求的主機名，容許多個域名同處一個ip地址，即虛擬主機　　　　

三、空行

最後一個請求頭以後是一個空行，發送回車符和換行符，通知服務器請求頭結束。

對於一個完整的http請求來講空行是必須的，不然服務器會任務本次請求的數據還沒有徹底發送到server，處於等待狀態

四、請求正文

請求數據不在GET方法中使用，而是在POST中使用。POST方法適用於須要client填寫表單的場合，與請求數據相關的最經常使用的請求頭是Content-Type 和Content-Length

響應報文 
 
一、狀態行：狀態行由 HTTP 協議版本字段、狀態碼和狀態碼的描述文本 3 個部分組成，他們之間使用空格隔開;

　　● 狀態碼由三位數字組成，第一位數字表示響應的類型，經常使用的狀態碼有五大類以下所示：

　　1xx：表示服務器已接收了客戶端請求，客戶端可繼續發送請求;

　　2xx：表示服務器已成功接收到請求並進行處理;

　　3xx：表示服務器要求客戶端重定向;

　　4xx：表示客戶端的請求有非法內容;

　　5xx：表示服務器未能正常處理客戶端的請求而出現意外錯誤;

　　● 狀態碼描述文本有以下取值：

　　200 OK：表示客戶端請求成功;

　　400 Bad Request：表示客戶端請求有語法錯誤，不能被服務器所理解;

　　401 Unauthonzed：表示請求未經受權，該狀態代碼必須與 WWW-Authenticate 報頭域一塊兒使用;

　　403 Forbidden：表示服務器收到請求，可是拒絕提供服務，一般會在響應正文中給出不提供服務的緣由;

　　404 Not Found：請求的資源不存在，例如，輸入了錯誤的URL;

　　500 Internal Server Error：表示服務器發生不可預期的錯誤，致使沒法完成客戶端的請求;

　　503 Service Unavailable：表示服務器當前不可以處理客戶端的請求，在一段時間以後，服務器可能會恢復正常;

二、響應頭部：響應頭可能包括：

　　Location：Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，爲了讓客戶端重定向到這個頁面新的位置，服務器端能夠發回Location響應報頭後使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源;

　　Server：Server 響應報頭域包含了服務器用來處理請求的軟件信息及其版本。它和 User-Agent 請求報頭域是相對應的，前者發送服務器端軟件的信息，後者發送客戶端軟件(瀏覽器)和操做系統的信息。

　　Vary：指示不可緩存的請求頭列表;

　　Connection：鏈接方式;

　　對於請求來講：close(告訴 WEB 服務器或者代理服務器，在完成本次請求的響應後，斷開鏈接，不等待本次鏈接的後續請求了)。keepalive(告訴WEB服務器或者代理服務器，在完成本次請求的響應後，保持鏈接，等待本次鏈接的後續請求);

　　對於響應來講：close(鏈接已經關閉); keepalive(鏈接保持着，在等待本次鏈接的後續請求); Keep-Alive：若是瀏覽器請求保持鏈接，則該頭部代表但願WEB 服務器保持鏈接多長時間(秒);例如：Keep-Alive：300;

　　WWW-Authenticate：WWW-Authenticate響應報頭域必須被包含在401 (未受權的)響應消息中，這個報頭域和前面講到的Authorization 請求報頭域是相關的，當客戶端收到 401 響應消息，就要決定是否請求服務器對其進行驗證。若是要求服務器對其進行驗證，就能夠發送一個包含了Authorization 報頭域的請求;

三、空行：最後一個響應頭部以後是一個空行，發送回車符和換行符，通知服務器如下再也不有響應頭部。

四、實體主體：服務器返回給客戶端的文本信息; 
8. Http的狀態碼含義。 
　1、200狀態碼： 
　　成功2××： 成功處理了請求的狀態碼。 
　　一、200 ：服務器已成功處理了請求並提供了請求的網頁。 
　　二、204： 服務器成功處理了請求，但沒有返回任何內容。 
　　2、300狀態碼： 
　　重定向3×× ：每次請求中使用重定向不要超過 5 次。 
　　一、301： 請求的網頁已永久移動到新位置。當URLs發生變化時，使用301代碼。搜索引擎索引中保存新的URL。 
　　二、302： 請求的網頁臨時移動到新位置。搜索引擎索引中保存原來的URL。 
　　三、304： 若是網頁自請求者上次請求後沒有更新，則用304代碼告訴搜索引擎機器人，可節省帶寬和開銷。 
　　3、400狀態碼： 
　　客戶端錯誤4×× ：表示請求可能出錯，妨礙了服務器的處理。 
　　一、400： 服務器不理解請求的語法。 
　　二、403： 服務器拒絕請求。 
　　三、404： 服務器找不到請求的網頁。服務器上不存在的網頁常常會返回此代碼。 
　　四、410 ：請求的資源永久刪除後，服務器返回此響應。該代碼與 404（未找到）代碼類似，但在資源之前存在而如今不存在的狀況下，有時用來替代404 代碼。若是資源已永久刪除，應當使用 301 指定資源的新位置。 
　　4、500狀態碼： 
　　服務器錯誤5×× ：表示服務器在處理請求時發生內部錯誤。這些錯誤多是服務器自己的錯誤，而不是請求出錯。 
　　一、500 ：服務器遇到錯誤，沒法完成請求。 
　　二、503： 服務器目前沒法使用（因爲超載或停機維護）。 
　　一般，這只是暫時狀態。 但願你們在分析日誌的時候能夠參照一下，根據具體的狀態碼解決問題。

9. Http request的幾種類型。 
一、 OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法。也能夠利用向Web服務器發送’*’的請求來測試服務器的功能性。

二、HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息。

三、GET：向特定的資源發出請求。

四、POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的建立和/或已有資源的修改。

五、PUT：向指定資源位置上傳其最新內容。

六、DELETE：請求服務器刪除Request-URI所標識的資源。

七、TRACE：回顯服務器收到的請求，主要用於測試或診斷。

八、CONNECT：HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。

10. Http1.1和Http1.0的區別 
一、長鏈接 
HTTP 1.0須要使用keep-alive參數來告知服務器端要創建一個長鏈接，而HTTP1.1默認支持長鏈接。

HTTP是基於TCP/IP協議的，建立一個TCP鏈接是須要通過三次握手的,有必定的開銷，若是每次通信都要從新創建鏈接的話，對性能有影響。所以最好能維持一個長鏈接，能夠用個長鏈接來發多個請求。

二、節約帶寬 
HTTP 1.1支持只發送header信息(不帶任何body信息)，若是服務器認爲客戶端有權限請求服務器，則返回100，不然返回401。客戶端若是接受到100，纔開始把請求body發送到服務器。

這樣當服務器返回401的時候，客戶端就能夠不用發送請求body了，節約了帶寬。

另外HTTP還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源後，只須要跟服務器請求另外的部分資源便可。這是支持文件斷點續傳的基礎。

三、HOST域 
如今能夠web server例如tomat，設置虛擬站點是很是常見的，也便是說，web server上的多個虛擬站點能夠共享同一個ip和端口。

HTTP1.0是沒有host域的，HTTP1.1才支持這個參數。

11. Http怎麼處理長鏈接。 
在HTTP1.0和HTTP1.1協議中都有對長鏈接的支持。其中HTTP1.0須要在request中增長Connection： keep-alive header纔可以支持，而HTTP1.1默認支持。

一、http1.0請求與服務端的交互過程:

（1）客戶端發出帶有包含一個header：」Connection： keep-alive「的請求

（2）服務端接收到這個請求後,根據http1.0和」Connection： keep-alive「判斷出這是一個長鏈接,就會在response的header中也增長」Connection： keep-alive「，同時不會關閉已創建的tcp鏈接.

（3）客戶端收到服務端的response後,發現其中包含」Connection： keep-alive「，就認爲是一個長鏈接，不關閉這個鏈接。並用該鏈接再發送request.轉到（1）

二、http1.1請求與服務端的交互過程:

（1）客戶端發出http1.1的請求

（2）服務端收到http1.1後就認爲這是一個長鏈接,會在返回的response設置Connection： keep-alive,同時不會關閉已創建的鏈接.

（3）客戶端收到服務端的response後,發現其中包含」Connection： keep-alive「，就認爲是一個長鏈接，不關閉這個鏈接。並用該鏈接再發送request.轉到（1）

基於http協議的長鏈接減小了請求,減小了創建鏈接的時間,可是每次交互都是由客戶端發起的,客戶端發送消息,服務端才能返回客戶端消息。

12. Cookie與Session的做用原理。

Cookie

一、工做原理 
（1）建立Cookie 
當用戶第一次瀏覽某個使用Cookie的網站時，該網站的服務器就進行以下工做： 
①該用戶生成一個惟一的識別碼（Cookie id），建立一個Cookie對象； 
②默認狀況下它是一個會話級別的cookie，存儲在瀏覽器的內存中，用戶退出瀏覽器以後被刪除。若是網站但願瀏覽器將該Cookie存儲在磁盤上，則須要設置最大時效（maxAge），並給出一個以秒爲單位的時間（將最大時效設爲0則是命令瀏覽器刪除該Cookie）； 
③將Cookie放入到HTTP響應報頭，將Cookie插入到一個 Set-Cookie HTTP請求報頭中。 
④發送該HTTP響應報文。 
（2）設置存儲Cookie 
瀏覽器收到該響應報文以後，根據報文頭裏的Set-Cookied特殊的指示，生成相應的Cookie，保存在客戶端。該Cookie裏面記錄着用戶當前的信息。 
（3）發送Cookie 
當用戶再次訪問該網站時，瀏覽器首先檢查全部存儲的Cookies，若是某個存在該網站的Cookie（即該Cookie所聲明的做用範圍大於等於將要請求的資源），則把該cookie附在請求資源的HTTP請求頭上發送給服務器。 
（4）讀取Cookie 
服務器接收到用戶的HTTP請求報文以後，從報文頭獲取到該用戶的Cookie，從裏面找到所須要的東西。

二、做用 
Cookie的根本做用就是在客戶端存儲用戶訪問網站的一些信息。典型的應用有：

（1）記住密碼，下次自動登陸。

（2）購物車功能。

（3）記錄用戶瀏覽數據，進行商品（廣告）推薦。

三、缺陷 
①Cookie會被附加在每一個HTTP請求中，因此無形中增長了流量。

②因爲在HTTP請求中的Cookie是明文傳遞的，因此安全性成問題。（除非用HTTPS）

③Cookie的大小限制在4KB左右。對於複雜的存儲需求來講是不夠用的。

Session

一、工做原理 
（1）建立Session 
當用戶訪問到一個服務器，若是服務器啓用Session，服務器就要爲該用戶建立一個SESSION，在建立這個SESSION的時候，服務器首先檢查這個用戶發來的請求裏是否包含了一個SESSION ID，若是包含了一個SESSION ID則說明以前該用戶已經登錄過併爲此用戶建立過SESSION，那服務器就按照這個SESSION ID把這個SESSION在服務器的內存中查找出來（若是查找不到，就有可能爲他新建立一個），若是客戶端請求裏不包含有SESSION ID，則爲該客戶端建立一個SESSION並生成一個與此SESSION相關的SESSION ID。這個SESSION ID是惟一的、不重複的、不容易找到規律的字符串，這個SESSION ID將被在本次響應中返回到客戶端保存，而保存這個SESSION ID的正是COOKIE，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發送給服務器。 
（2）使用Session 
咱們知道在IE中，咱們能夠在工具的Internet選項中把Cookie禁止，那麼會不會出現把客戶端的Cookie禁止了，那麼SESSIONID就沒法再用了呢？找了一些資料說明，能夠有其餘機制在COOKIE被禁止時仍然可以把Session id傳遞迴服務器。

常常被使用的一種技術叫作URL重寫，就是把Session id直接附加在URL路徑的後面一種是做爲URL路徑的附加信息,表現形式爲：

http://…./xxx;jSession=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764；

另外一種是做爲查詢字符串附加在URL後面，表現形式爲：

http://…../xxx?jSession=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

還有一種就是表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時可以把Session id傳遞迴服務器。

二、做用

Session的根本做用就是在服務端存儲用戶和服務器會話的一些信息。典型的應用有：

（1）判斷用戶是否登陸。

（2）購物車功能。

Cookie和Session的比較：

一、存放位置不一樣

Cookie保存在客戶端，Session保存在服務端。

2 、存取方式的不一樣

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數據，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微複雜的信息，運用Cookie是比擬艱難的。

而Session中可以存取任何類型的數據，包括而不限於String、Integer、List、Map等。Session中也可以直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。可以把Session看作是一個Java容器類。

三、安全性（隱私策略）的不一樣

Cookie存儲在瀏覽器中，對客戶端是可見的，客戶端的一些程序可能會窺探、複製以致修正Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的風險。 假如選用Cookie，比較好的方法是，敏感的信息如帳號密碼等儘可能不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務器後再進行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在服務器上，Session裏任何隱私都可以有效的保護。

四、有效期上的不一樣

只須要設置Cookie的過時時間屬性爲一個很大很大的數字，Cookie就能夠在瀏覽器保存很長時間。 因爲Session依賴於名爲JSESSIONID的Cookie，而Cookie JSESSIONID的過時時間默許爲–1，只需關閉了瀏覽器（一次會話結束），該Session就會失效。

五、對服務器形成的壓力不一樣

Session是保管在服務器端的，每一個用戶都會產生一個Session。假如併發訪問的用戶十分多，會產生十分多的Session，耗費大量的內存。而Cookie保管在客戶端，不佔用服務器資源。假如併發閱讀的用戶十分多，Cookie是很好的選擇。

六、 跨域支持上的不一樣

Cookie支持跨域名訪問，例如將domain屬性設置爲「.baidu.com」，則以「.baidu.com」爲後綴的一切域名均可以訪問該Cookie。跨域名Cookie現在被廣泛用在網絡中。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。

13. 電腦上訪問一個網頁，整個過程是怎麼樣的：DNS、HTTP、TCP、OSPF、IP、ARP。

首先了解一下各個協議是什麼：

應用層： 
一、DNS（53）： 
咱們輸入的是一個URL須要轉化成IP地址。首先咱們知道咱們本地的機器上在配置網絡時都會填寫DNS，這樣本機就會把這個url發給這個配置的DNS服務器，若是可以找到相應的url則返回其ip，不然該DNS將繼續將該解析請求發送給上級DNS，整個DNS能夠看作是一個樹狀結構，該請求將一直髮送到根直到獲得結果。

二、HTTP（80） 
HTTP協議的主要職責是生成針對目標web服務器的http請求報文（請求行、請求頭部）

傳輸層 
三、TCP 
將http請求報文分割成報文段，按序號分爲多個報文段。（三次握手）

網絡層 
四、IP 
搜索目標的地址，一邊中轉一邊傳送。（路由）

五、ARP 
由於最終都要在數據鏈路層上進行傳輸，而數據鏈路層並不認識IP地址，因此ARP的職責就是把IP地址轉換成數據鏈路層認識的MAC地址。

經過數據鏈路層到達目標機器以後。

網絡層 
六、RARP 
這實際上是ARP的逆過程，將MAC地址轉換成Ip地址

傳輸層 
七、TCP 
將接收到的報文段按序號進行重組。

應用層 
八、 HTTP 
HTTP協議對http請求進行解析處理。

例子： 
重點內容 
假設你用一個全新的瀏覽器（第一次啓動的那種），訪問百度（http://www.baidu.com/**），在你敲入網址並按下回車以後，將會發生如下神奇的事情： 
http://www.baidu.com/瀏覽器先嚐試從Host文件中獲取http://www.baidu.com/對應的IP地址，若是能取到固然萬事大吉你們都能嗨，若是不能，就使用DNS協議來獲取IP咯。 
在DNS協議中，PC會向你的本地DNS服務器求助（通常是路由器），但願從本地DNS服務器那裏獲得百度的IP，獲得就好，得不到還得向更高層次的DNS服務器求助，最終總能獲得百度的IP。 
獲得百度的IP，下一步是使用TCP協議，創建TCP鏈接。 
在TCP協議中，創建TCP須要與百度服務器握手三次，你先告訴服務器你要給服務器發東西（SYN），服務器應答你並告訴你它也要給你發東西（SYN、ACK），而後你應答服務器（ACK），總共來回了3次，稱爲3次握手。 
不過，創建TCP鏈接有個前提（或者說給服務器發消息有個前提）：你必須能成功地把消息發到服務器上。雖然已經知道IP，但並沒有啥用（好比說，你在廣東，你知道北京的地理座標經緯度就能到北京了？你得知道有哪些路通往北京吧你得準備盤纏吧你得花時間吧）。 
咱們都知道，你的PC和百度服務器之間通常會有許多路由器之類的東西，IP協議指定了出發地（你的PC）和目的地（服務器）；你的數據會通過一個又一個路由器，OSPF決定了會通過那些路由器（用一種叫路由算法的玩意，找出最佳路徑）；從一個路由器怎麼傳給下一個路由器？這是ARP協議的工做，ARP負責求下一個節點的地址（咱們不止是要目的地，還要中間節點的地址）。 
IP協議使用的是IP地址，整個發送過程當中只涉及出發地和目的地2個IP地址，而ARP協議使用的是MAC地址，整個發送過程當中涉及到每個節點的MAC地址 
如今，咱們能和服務器通訊，還創建了TCP鏈接，下一步幹嗎，固然是用HTTP協議請求網頁內容咯。 
你發個HTTP請求報文給服務器，若是服務器禁止你訪問它就給你回個」Forbidden」，若是它暫時掛掉了就給你回個「內部服務錯誤」，若是它正常纔給你回個「OK「並將你要的數據傳給你；若是你還須要其它的東西再去跟它要（它通常還會給你的-_-）。 
你收到了服務器的回覆，是一坨HTML形式的文本。瀏覽器必需要可以理解文本的內容，並快速地渲染到屏幕上（瀏覽器通常用有限自動機來理解文本內容，渲染的話就各看本事了，之因此微軟IE卡成狗而谷歌瀏覽器很6，就是它們的渲染速度不一樣…）

14. Ping的整個過程。ICMP報文是什麼。

這裏講ping的兩狀況,一種是同一網段內,一種是跨網段的ping ….

一、同一網段ping

首先，若是主機A，要去ping主機B，那麼主機A，就要封裝二層報文，他會先查本身的MAC地址表，若是沒有B的MAC地址，就會向外發送一個ARP廣播包，如圖: 

其中ARP報文格式以下: 
 
其中OP 
1:表示ARP請求 
2:表示ARP應答 
3:表示RARP請求 
4:表示RARP應答

首先,交換機會收到這個報文後，交換機有學習MAC地址的功能，因此他會檢索本身有沒有保存主機B有MAC，若是有，就返回給主機A，若是沒有，就會向全部端口發送ARP廣播，其它主機收到後，發現不是在找本身，就紛紛丟棄了該報文，不去理會。。直到主機B收到了報文後，就當即相應，個人MAC地址是多少，同時學到主機A的MAC地址,並按一樣的ARP報文格式返回給主機A,如圖: 

ARP報文格式: 

這時候主機A學到了主機B的MAC，就把這個MAC封裝到ICMP協議的二層報文中向主機B發送,報文格式以下： 

當主機B收到了這個報文後，發現是主機A 的ICPM回顯請求，就按一樣的格式，返回一個值給主機A，這樣就完成了同一網段內的ping過程… 

二、跨網段ping 
若是主機A要ping主機C,那麼主機A發現主機C的IP和本身不是同一網段,他就去找網關轉發,可是他也不知道網關的MAC狀況下呢?他就會向以前那個步驟同樣先發送一個ARP廣播,學到網關的MAC,再發封裝ICMP報文給網關路由器. 
報文格式以下: 

當路由器收到主機A發過來的ICMP報文,發現報文的目的地址是其自己MAC地址,根據目的的IP2.1.1.1,查路由表,發現2.1.1.1/24的路由表項,獲得一個出口指針,去掉原來的MAC頭部.加上本身的MAC地址向主機C轉發…(若是網關也沒有主機C的MAC地址,仍是要向前面一個步驟同樣,ARP廣播一下便可相互學到….路由器2端口能學到主機D的MAC,主機D也能學到路由器2端口的MAC..),報文格式以下: 

最後,在主機C已學到路由器2端口MAC,路由器2端口轉發給路由器1端口,路由1端口學到主機A的MAC的狀況下,他們就不須要再作ARP解析,就將ICMP的回顯請求回覆過來..報文格式大體以下: 

ICMP報文 
一、 ICMP容許主機或路由報告差錯狀況和提供有關異常狀況。ICMP是因特網的標準協議，但ICMP不是高層協議，而是IP層的協議。一般ICMP報文被IP層或更高層協議（TCP或UDP）使用。一些ICMP報文把差錯報文返回給用戶進程。

二、 ICMP報文做爲IP層數據報的數據，加上數據報的首部，組成數據報發送出去。

三、 ICMP報文的種類有兩種，即ICMP差錯報告報文和ICMP詢問報文。

具體參考：ICMP報文分析

15. C/S模式下使用socket通訊，幾個關鍵函數。 

16. IP地址分類。 

A類網絡地址： 
（1）前1字節標識網絡地址部分，後3字節表示主機地址部分

（2）每一個網絡最多容納（2^24 - 2）臺主機

（3）最高位固定爲0，因此第1個字節表示範圍爲0~127

（4）具備A類地址特徵的網絡總數爲2^7個

B類網絡地址： 
（1）前2字節標識網絡地址部分，後2字節標識主機地址部分

（2）每一個網絡最多容納（2^16 - 2）臺主機

（3）前2位固定爲10，因此第一個字節表示範圍爲128~19一、

（4）具備B類地址特徵的網絡總數爲2^14個

C類地址 
（1）前3字節標識網絡地址部分，後1字節標識主機地址部分

（2）每一個網絡可容納(2^8 - 2)臺主機

（3）前3位固定爲110，因此第一字節表示範圍爲192~223

（4）具備C類地址的網絡總數爲2^21個

保留的地址

D類（224.0.0.0~239.0.0.0）組播地址

E類（240.0.0.0~254.0.0.0）用於科研試驗

網絡地址：主機部分全爲0的IP地址

廣播地址：主機部分全爲1的IP地址

例子：當發送信息到廣播地址100.255.255.255時，意思爲放鬆到網絡地址爲100.0.0.0的全部主機上。

0.0.0.0指這個主機、這個網絡，出如今路由表中的默認路由。

255.255.255.255 廣播地址：送達全網全部主機，會被路由器截至

子網的規劃

例子：某單位分到一個C類網絡號193.71.56.0，須要分紅五個子網，每一個子網須要鏈接20臺主機，如何規劃子網？

爲了分紅五個子網，咱們須要借主機位3位，可建立8個子網>5個子網；同時剩下5個主機位，提供主機位2^5-2=30個>20個，因此咱們能夠子網掩碼設置位255.255.255.224。

咱們這裏建立子網都是等大的，還能建立不等大的子網，就是子網中繼續建立子網，這樣能夠充分利用資源，就不贅述了。

17. 路由器與交換機區別。 

（1）外形上：

從外形上咱們區分二者，交換機一般端口比較多看起來比較笨重，而路由器的端口就少得多體積也小得多，實際上右圖並非真正的路由器只是集成了路由器的功能，除此以外還有交換機的功能（LAN口就是做爲交換機的端口來使用，WAN是用於鏈接外網的端口），而兩個天線則是無線AP接入點（便是一般所說的無線局域網wifi）。

（2）工做層次不一樣：

最初的交換機工做在OSI開放式系統互聯模型的數據鏈路層，也就是第二層，而路由器則工做在OSI模型的網絡層，就是第三層。也就是因爲這一點因此交換機的原理比較簡單，通常都是採用硬件電路實現數據幀的轉發，而路由器工做在網絡層，肩負着網絡互聯的重任，要實現更加複雜的協議，具備更加智能的轉發決策功能，通常都會在在路由器中跑操做系統，實現複雜的路由算法，更偏向於軟件實現其功能。

（3）數據的轉發對象不一樣： 
交換機是根據MAC地址轉發數據幀，而路由器則是根據IP地址來轉發IP數據報/分組。數據幀是在IP數據包/分組的基礎上封裝了幀頭（源MAC和目的MAC等）和幀尾（CRC校驗碼）。而對於MAC地址和IP地址你們也許就搞不明白了，爲什麼須要兩個地址，實際上IP地址決定最終數據包要到達某一臺主機，而MAC地址則是決定下一跳將要交互給哪一臺設備（通常是路由器或主機）。並且，IP地址是軟件實現的，能夠描述主機所在的網絡，MAC地址是硬件實現的，每個網卡在出廠的時候都會將全世界惟一的MAC地址固化在網卡的ROM中，因此MAC地址是不能被修改的，可是IP地址是能夠被網絡管理人員配置修改的。

（4）」分工「不一樣

交換機主要是用於組建局域網，而路由器則是負責讓主機鏈接外網。多臺主機能夠經過網線鏈接到交換機，這時就組建好了局域網，就能夠將數據發送給局域網中的其餘主機，如咱們使用的飛秋、極域電子教室等局域網軟件就是經過交換機把數據轉發給其餘主機的，固然像極域電子教室這樣的廣播軟件是利用廣播技術讓全部的主機都收到數據的。然而，經過交換機組建的局域網是不能訪問外網的（便是Internet）,這時須要路由器來爲咱們」打開外面精彩世界的大門「，局域網的全部主機使用的都是私網的IP，因此必須經過路由器轉化爲公網的IP以後才能訪問外網。

（5）衝突域和廣播域

交換機分割衝突域，可是不分割廣播域，而路由器分割廣播域。由交換機鏈接的網段仍屬於同一個廣播域，廣播數據包會在交換機鏈接的全部網段上傳播，在這種狀況下會致使廣播風暴和安全漏洞問題。而鏈接在路由器上的網段會被分配不一樣的廣播域，路由器不會轉發廣播數據。須要說明的是單播的數據包在局域網中會被交換機惟一地送往目標主機，其餘主機不會接收到數據，這是區別於原始的集線器的，數據的到達時間由交換機的轉發速率決定，交換機會轉發廣播數據給局域網中的全部主機。

最後須要說明的是：路由器通常有防火牆的功能，可以對一些網絡數據包選擇性過濾。如今的一些路由器都具有交換機的功能（如上圖右），一些交換機具有路由器的功能，被稱爲3層交換機，普遍使用。相比較而言，路由器的功能較交換機要強大，可是速度也較慢，價格昂貴，三層交換機既有交換機的線性轉發報文的能力，又有路由器的良好的路由功能所以獲得普遍的使用。