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

• OSI分層 （7層）：物理層、資料鏈路層、網路層、傳輸層、會話層、表示層、應用層。

• TCP/IP分層（4層）：網路介面層、 網際層、運輸層、 應用層。

• 五層協議 （5層）：物理層、資料鏈路層、網路層、運輸層、 應用層。

• 每一層的協議如下：

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

TCP與UDP的區別

• TCP面向連線（如打電話要先撥號建立連線）;UDP是無連線的，即傳送資料之前不需要建立連線

• TCP提供可靠的服務。也就是說，通過TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付

• TCP面向位元組流，實際上是TCP把資料看成一連串無結構的位元組流;UDP是面向報文的
  UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時視訊會議等）

• 每一條TCP連線只能是點到點的;UDP支援一對一，一對多，多對一和多對多的互動通訊

• TCP首部開銷20位元組;UDP的首部開銷小，只有8個位元組

• TCP的邏輯通訊通道是全雙工的可靠通道，UDP則是不可靠通道

TCP報文結構

TCP的三次握手與四次揮手過程，各個狀態名稱與含義，TIMEWAIT的作用。

• 建立連線三次握手

  第一次握手：主機A傳送位碼為syn＝1,隨機產生seq number=10001的資料包到伺服器，主機B由SYN=1知道，A要求建立聯機，此時狀態為SYN_SENT；

  第二次握手：主機B收到請求後要確認聯機資訊，向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=20001的包，此時狀態由LISTEN變為SYN_RECV；

  第三次握手：主機A收到後檢查ack number是否正確，即第一次傳送的seq number+1,以及位碼ack是否為1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則連線建立成功，雙方狀態ESTABLISHED。

  完成三次握手，主機A與主機B開始傳送資料。

• 各個狀態名稱與含義

  • CLOSED: 這個沒什麼好說的了，表示初始狀態。

  • LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受連線了。

  • SYN_RECV: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連線時的三次握手會話過程中的一箇中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態 時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。

  • SYN_SENT: 這個狀態與SYN_RECV遙想呼應，當客戶端SOCKET執行CONNECT連線時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀 態，並等待服務端的傳送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已傳送SYN報文。

  • ESTABLISHED：這個容易理解了，表示連線已經建立了。

• 關閉連線四次揮手

  由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

  CP的連線的拆除需要傳送四個包，因此稱為四次揮手(four-way handshake)。客戶端或伺服器均可主動發起揮手動作，在socket程式設計中，任何一方執行close()操作即可產生揮手操作。

  1. 客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送。

  2. 伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將佔用一個序號。

  3. 伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A。

  4. 客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1。

• TIME_WAIT

  TIME_WAIT是TCP協議用以保證被重新分配的socket不會受到之前殘留的延遲重發報文影響的機制,是必要的邏輯保證。

TCP擁塞控制

TCP的擁塞控制由4個核心演算法組成：”慢啟動”(Slow Start)、”擁塞避免”(Congestion voidance)、”快速重傳”(Fast Retransmit)、”快速恢復”(Fast Recovery)。

TCP滑動視窗與回退N針協議

滑動視窗協議是傳輸層進行流控的一種措施，接收方通過通告發送方自己的視窗大小，從而控制傳送方的傳送速度，從而達到防止傳送方傳送速度過快而導致自己被淹沒的目的。

慢啟動為傳送方的TCP增加了另一個視窗：擁塞視窗(congestion window)，記為cwnd。當與另一個網路的主機建立TCP連線時，擁塞視窗被初始化為1個報文段（即另一端通告的報文段大小）。每收到一個ACK，擁塞視窗就增加一個報文段（cwnd以位元組為單位，但是慢啟動以報文段大小為單位進行增加）。傳送方取擁塞視窗與通告視窗中的最小值作為傳送上限。擁塞視窗是傳送方使用的流量控制，而通告視窗則是接收方使用的流量控制。

傳送方開始時傳送一個報文段，然後等待ACK。當收到該ACK時，擁塞視窗從1增加為2，即可以傳送兩個報文段。當收到這兩個報文段的ACK時，擁塞視窗就增加為4。這是一種指數增加的關係。

• 1位元滑動視窗協議

  當傳送視窗和接收視窗的大小固定為1時，滑動視窗協議退化為停等協議（stop－and－wait）。該協議規定傳送方每傳送一幀後就要停下來，等待接收方已正確接收的確認（acknowledgement）返回後才能繼續傳送下一幀。由於接收方需要判斷接收到的幀是新發的幀還是重新發送的幀，因此傳送方要為每一個幀加一個序號。

• 後退n協議

  由於停等協議要為每一個幀進行確認後才繼續傳送下一幀，大大降低了通道利用率，因此又提出了後退n協議。後退n協議中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個資料幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。且傳送方在每傳送完一個數據幀時都要設定超時定時器。只要在所設定的超時時間內仍收到確認幀，就要重發相應的資料幀。如：當傳送方傳送了N個幀後，若發現該N幀的前一個幀在計時器超時後仍未返回其確認資訊，則該幀被判為出錯或丟失，此時傳送方就不得不重新發送出錯幀及其後的N幀。

• 選擇重傳協議

  在後退n協議中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩衝區中，同時要求傳送方重新傳送出錯的那一幀。一旦收到重新傳來的幀後，就可以原已存於緩衝區中的其餘幀一併按正確的順序遞交高層。這種方法稱為選擇重發(SELECTICE REPEAT)，其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。

Http的報文結構

HTTP 有兩類報文：

(1) 請求報文—-從客戶向伺服器傳送請求報文.

(2) 響應報文—-從伺服器到客戶的回答

HTTP請求報文和響應報文都是由三個部分組成。可以看出，這兩種報文格式的區別就是開始行不同。

(1) 開始行 用於區分是請求報文還是響應報文。在請求報文中的開始行叫做請求行(Request-Line),
而在響應報文中的開始行叫做狀態行(Staus-Line).在開始行的三個欄位之間都以空格隔開，最後的“CR”
和“LF”分別表示“回車”和“換行”。

(2)首部行 用來說明瀏覽器，伺服器或報文主體的一些資訊。首部可以有好幾行，也可以不使用。
在每一個首部行中都有首部欄位名和它的值，每一行在結束的地方都要有“回車”和“換行”。整個首部行
結束時，還有一空行將首部行和後面的實體主體分開。

(3)實體主體 在請求報文中一般都不用這個欄位，而在響應報文中也可能沒有這個欄位。

Http的狀態碼含義

• 200狀態碼：
  　
  成功2××： 成功處理了請求的狀態碼。
  　　
  1、200 ：伺服器已成功處理了請求並提供了請求的網頁。
  　　
  2、204： 伺服器成功處理了請求，但沒有返回任何內容。

• 300狀態碼：

  重定向3×× ：每次請求中使用重定向不要超過 5 次。

  1、301： 請求的網頁已永久移動到新位置。當URLs發生變化時，使用301程式碼。搜尋引擎索引中儲存新的URL。
  　　
  2、302： 請求的網頁臨時移動到新位置。搜尋引擎索引中儲存原來的URL。
  　　
  3、304： 如果網頁自請求者上次請求後沒有更新，則用304程式碼告訴搜尋引擎機器人，可節省頻寬和開銷。

• 400狀態碼：

  客戶端錯誤4×× ：表示請求可能出錯，妨礙了伺服器的處理。
  　　
  1、400： 伺服器不理解請求的語法。
  　　
  2、403： 伺服器拒絕請求。
  　　
  3、404： 伺服器找不到請求的網頁。伺服器上不存在的網頁經常會返回此程式碼。
  　　
  4、410 ：請求的資源永久刪除後，伺服器返回此響應。該程式碼與 404（未找到）程式碼相似，但在資源以前存在而現在不存在的情況下，有時用來替代404 程式碼。如果資源已永久刪除，應當使用 301 指定資源的新位置。
  　

• 500狀態碼：
  　　
  伺服器錯誤5×× ：表示伺服器在處理請求時發生內部錯誤。這些錯誤可能是伺服器本身的錯誤，而不是請求出錯。
  　　
  1、500 ：伺服器遇到錯誤，無法完成請求。
  　　
  2、503： 伺服器目前無法使用（由於超載或停機維護）。

Http request的幾種型別

HTTP協議中共定義了八種方法或者叫“動作”來表明對Request-URI指定的資源的不同操作方式，具體介紹如下：

• OPTIONS：返回伺服器針對特定資源所支援的HTTP請求方法。也可以利用向Web伺服器傳送’*’的請求來測試伺服器的功能性。

• HEAD：向伺服器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應訊息頭中的元資訊。

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

• POST：向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

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

• DELETE：請求伺服器刪除Request-URI所標識的資源。

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

• CONNECT：HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。

雖然HTTP的請求方式有8種，但是我們在實際應用中常用的也就是get和post，其他請求方式也都可以通過這兩種方式間接的來實現。

Http1.1和Http1.0的區別

• HTTP/1.0協議使用非持久連線,即在非持久連線下,一個tcp連線只傳輸一個Web物件,；

• HTTP/1.1預設使用持久連線(然而,HTTP/1.1協議的客戶機和伺服器可以配置成使用非持久連線)。在持久連線下,不必為每個Web物件的傳送建立一個新的連線,一個連線中可以傳輸多個物件!

Http怎麼處理長連線

基於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協議的長連線減少了請求,減少了建立連線的時間,但是每次互動都是由客戶端發起的,客戶端傳送訊息,服務端才能返回客戶端訊息。因為客戶端也不知道服務端什麼時候會把結果準備好，所以客戶端的很多請求是多餘的,僅是維持一個心跳,浪費了頻寬。

Cookie與Session的作用與原理

一、Cookie詳解

（1）簡介

  因為HTTP協議是無狀態的，即伺服器不知道使用者上一次做了什麼，這嚴重阻礙了互動式Web應用程式的實現。在典型的網上購物場景中，使用者瀏覽了幾個頁面，買了一盒餅乾和兩飲料。最後結帳時，由於HTTP的無狀態性，不通過額外的手段，伺服器並不知道使用者到底買了什麼。為了做到這點，就需要使用到Cookie了。伺服器可以設定或讀取Cookies中包含資訊，藉此維護使用者跟伺服器會話中的狀態。

Cookie（複數形態：Cookies），是指某些網站為了辨別使用者身份、進行session跟蹤而儲存在使用者本地終端上的資料（通常經過加密）。

Cookie是由服務端生成的，傳送給客戶端（通常是瀏覽器）的。Cookie總是儲存在客戶端中，按在客戶端中的儲存位置，可分為記憶體Cookie和硬碟Cookie：

記憶體Cookie由瀏覽器維護，儲存在記憶體中，瀏覽器關閉後就消失了，其存在時間是短暫的。

硬碟Cookie儲存在硬盤裡，有一個過期時間，除非使用者手工清理或到了過期時間，硬碟Cookie不會被刪除，其存在時間是長期的。所以，按存在時間，可分為非持久Cookie和持久Cookie。

（2）工作原理

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，從裡面找到所需要的東西。

（3）作用

  Cookie的根本作用就是在客戶端儲存使用者訪問網站的一些資訊。典型的應用有：

  1、記住密碼，下次自動登入。

  2、購物車功能。

  3、記錄使用者瀏覽資料，進行商品（廣告）推薦。

（4）缺陷

   ①Cookie會被附加在每個HTTP請求中，所以無形中增加了流量。

   ②由於在HTTP請求中的Cookie是明文傳遞的，所以安全性成問題。（除非用HTTPS）

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

二、Session詳解

（1）簡介

    Session代表伺服器與瀏覽器的一次會話過程，這個過程是連續的，也可以時斷時續的。

    Session是一種伺服器端的機制，Session 物件用來儲存特定使用者會話所需的資訊。

    Session由服務端生成，儲存在伺服器的記憶體、快取、硬碟或資料庫中。

（2）工作原理

    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傳遞迴伺服器。

（3）作用

Session的根本作用就是在服務端儲存使用者和伺服器會話的一些資訊。典型的應用有：

1、判斷使用者是否登入。

2、購物車功能。

三、Cookie和Session的區別

1、存放位置不同

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

2 、存取方式的不同

 Cookie中只能保管ASCII字串，假如需求存取Unicode字元或者二進位制資料，需求先進行編碼。Cookie中也不能直接存取Java物件。若要儲存略微複雜的資訊，運用Cookie是比擬艱難的。 

 而Session中能夠存取任何型別的資料，包括而不限於String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，物件等，運用起來十分便當。能夠把Session看做是一個Java容器類。 

3、安全性（隱私策略）的不同

Cookie儲存在瀏覽器中，對客戶端是可見的，客戶端的一些程式可能會窺探、複製以至修正Cookie中的內容。

而Session儲存在伺服器上，對客戶端是透明的，不存在敏感資訊洩露的風險。 

假如選用Cookie，比較好的方法是，敏感的資訊如賬號密碼等儘量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie資訊加密，提交到伺服器後再進行解密，保證Cookie中的資訊只要本人能讀得懂。

而假如選擇Session就省事多了，反正是放在伺服器上，Session裡任何隱私都能夠有效的保護。 

4、有效期上的不同

只需要設定Cookie的過期時間屬性為一個很大很大的數字，Cookie就可以在瀏覽器儲存很長時間。 由於Session依賴於名為JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許為–1，只需關閉了瀏覽器（一次會話結束），該Session就會失效。

5、對伺服器造成的壓力不同

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

6、 跨域支援上的不同

Cookie支援跨域名訪問，例如將domain屬性設定為“.baidu.com”，則以“.baidu.com”為字尾的一切域名均能夠訪問該Cookie。跨域名Cookie如今被普遍用在網路中。而Session則不會支援跨域名訪問。Session僅在他所在的域名內有效。

電腦上訪問一個網頁，整個過程是怎麼樣的

DNS、HTTP、TCP、OSPF、IP、ARP。

連線-》請求-》應答-》關閉連線

Ping的整個過程

• 首先查本地arp cache資訊，看是否有對方的mac地址和IP地址對映條目記錄

• 如果沒有，則發起一個arp請求廣播包，等待對方告知具體的mac地址

• 收到arp響應包之後，獲得某個IP對應的具體mac地址，有了實體地址之後才可以開始通訊了,同時對ip-mac地址做一個本地cache

• 發出icmp echo request包，收到icmp echo reply包

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

• socket函式

• bind函式

• listen函式

• accept函式

• connect函式

IP地址分類

• A類地址

  A類地址的表示範圍為：0.0.0.0~126.255.255.255，預設網路掩碼為：255.0.0.0；A類地址分配給規模特別大的網路使用。

  A類網路用第一組數字表示網路本身的地址，後面三組數字作為連線於網路上的主機的地址。分配給具有大量主機（直接個人使用者）而區域網絡個數較少的大型網路。例如IBM公司的網路。

• B類地址

  B類地址的表示範圍為：128.0.0.0~191.255.255.255，預設網路掩碼為：255.255.0.0；B類地址分配給一般的中型網路。

  B類網路用第一、二組數字表示網路的地址，後面兩組數字代表網路上的主機地址。

• C類地址

  C類地址的表示範圍為：192.0.0.0~223.255.255.255，預設網路掩碼為：255.255.255.0；C類地址分配給小型網路，如一般的區域網和校園網，它可連線的主機數量是最少的，採用把所屬的使用者分為若干的網段進行管理。

  C類網路用前三組數字表示網路的地址，最後一組數字作為網路上的主機地址。

  實際上，還存在著D類地址和E類地址。但這兩類地址用途比較特殊，在這裡只是簡單介紹一下：D類地址稱為廣播地址，供特殊協議向選定的節點發送資訊時用。E類地址保留給將來使用。

路由器與交換機區別

• 路由器工作於OSI模型的網路層，能夠識別IP地址，並根據IP地址轉發資料包，並維護著路由表，能夠基於路由表進行最佳路線選擇；

• 路由器上還能開啟ACL訪問控制列表、NAT地址轉換等功能，擴充套件網路應用,；

• 傳統交換機工作於OSI模型的資料鏈路層，能夠識別MAC地址，根據MAC地址轉發資料幀，並維護著一張橋表，根據橋表上MAC地址和埠的對應關係進行資料幀轉發。

• 交換機能夠隔離衝突域，並劃分VLAN。