引自：https://blog.csdn.net/qq_39322743/article/details/79700863

1、Http和Https的區別

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

• 埠不同：Http與Http使用不同的連線方式，用的埠也不一樣，前者是80，後者是443；

• 資源消耗：和HTTP通訊相比，Https通訊會由於加減密處理消耗更多的CPU和記憶體資源；

• 開銷：Https通訊需要證書，而證書一般需要向認證機構購買；
  

  　
  Https的加密機制是一種共享金鑰加密和公開金鑰加密並用的混合加密機制。

2、對稱加密與非對稱加密

　　對稱金鑰加密是指加密和解密使用同一個金鑰的方式，這種方式存在的最大問題就是金鑰傳送問題，即如何安全地將金鑰發給對方；而非對稱加密是指使用一對非對稱金鑰，即公鑰和私鑰，公鑰可以隨意釋出，但私鑰只有自己知道。傳送密文的一方使用對方的公鑰進行加密處理，對方接收到加密資訊後，使用自己的私鑰進行解密。

　　由於非對稱加密的方式不需要傳送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送訊息，但對稱加密所使用的金鑰我們可以通過非對稱加密的方式傳送出去。

3、三次握手與四次揮手

　(1). 三次握手(我要和你建立連結，你真的要和我建立連結麼，我真的要和你建立連結，成功)：

• 第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。

• 第二次握手：Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。

• 第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。

  　　　　　　　　　　　　

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

• 第一次揮手：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狀態，完成四次揮手。

  　　　　　　　　　　　　

4、為什麼TCP連結需要三次握手，兩次不可以麼，為什麼？

　　為了防止已失效的連結請求報文突然又傳送到了服務端，因而產生錯誤。

　　客戶端發出的連線請求報文並未丟失，而是在某個網路節點長時間滯留了，以致延誤到連結釋放以後的某個時間才到達Server。這是，Server誤以為這是Client發出的一個新的連結請求，於是就向客戶端傳送確認資料包，同意建立連結。若不採用“三次握手”，那麼只要Server發出確認資料包，新的連結就建立了。由於client此時並未發出建立連結的請求，所以其不會理睬Server的確認，也不與Server通訊；而這時Server一直在等待Client的請求，這樣Server就白白浪費了一定的資源。若採用“三次握手”，在這種情況下，由於Server端沒有收到來自客戶端的確認，則就會知道Client並沒有要求建立請求，就不會建立連結。

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

　　TCP提供一種面向連線的、可靠的位元組流服務。其中，面向連線意味著兩個使用TCP的應用（通常是一個客戶和一個伺服器）在彼此交換資料之前必須先建立一個TCP連線。在一個TCP連線中，僅有兩方進行彼此通訊；而位元組流服務意味著兩個應用程式通過TCP連結交換8bit位元組構成的位元組流，TCP不在位元組流中插入記錄識別符號。

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

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

• 對失序資料包重排序：既然TCP報文段作為IP資料報來傳輸，而IP資料報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序資料進行重新排序，然後才交給應用層；

• 丟棄重複資料：對於重複資料，能夠丟棄重複資料；

• 應答機制：當TCP收到發自TCP連線另一端的資料，它將傳送一個確認。這個確認不是立即傳送，通常將推遲幾分之一秒；

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

• 流量控制：TCP連線的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端傳送接收端緩衝區所能接納的資料，這可以防止較快主機致使較慢主機的緩衝區溢位，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動視窗協議。

6、客戶端不斷進行請求連結會怎樣？DDos(Distributed Denial of Service)攻擊？

　　伺服器端會為每個請求建立一個連結，並向其傳送確認報文，然後等待客戶端進行確認

1)、DDos 攻擊

• 客戶端向服務端傳送請求連結資料包
• 服務端向客戶端傳送確認資料包
• 客戶端不向服務端傳送確認資料包，伺服器一直等待來自客戶端的確認

2)、DDos 預防( 沒有徹底根治的辦法，除非不使用TCP )

• 限制同時開啟SYN半連結的數目
• 縮短SYN半連結的Time out 時間
• 關閉不必要的服務

7、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請求則是沒有大小限制的。

1). GET請求中URL編碼的意義

　　我們知道，在GET請求中會對URL中非西文字元進行編碼，這樣做的目的就是為了避免歧義。看下面的例子，

　　針對“name1=value1&name2=value2”的例子，我們來談一下資料從客戶端到服務端的解析過程。首先，上述字串在計算機中用ASCII嗎表示為：

1. 6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
2. 6E616D6531：name1
3. 3D：=
4. 76616C756531：value1
5. 26：&
6. 6E616D6532：name2
7. 3D：=
8. 76616C756532：value2

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

　　服務端在接收到該資料後就可以遍歷該位元組流，一個位元組一個位元組的吃，當吃到3D這位元組後，服務端就知道前面吃得位元組表示一個key，再往後吃，如果遇到26，說明從剛才吃的3D到26子節之間的是上一個key的value，以此類推就可以解析出客戶端傳過來的引數。

　　現在考慮這樣一個問題，如果我們的引數值中就包含=或&這種特殊字元的時候該怎麼辦？比如，“name1=value1”，其中value1的值是“va&lu=e1”字串，那麼實際在傳輸過程中就會變成這樣“name1=va&lu=e1”。這樣，我們的本意是隻有一個鍵值對，但是服務端卻會解析成兩個鍵值對，這樣就產生了歧義。

　　那麼，如何解決上述問題帶來的歧義呢？解決的辦法就是對引數進行URL編碼：例如，我們對上述會產生歧義的字元進行URL編碼後結果：“name1=va%26lu%3D”，這樣服務端會把緊跟在“%”後的位元組當成普通的位元組，就是不會把它當成各個引數或鍵值對的分隔符。更多關於URL編碼的內容，請參考我的博文《使用 URLDecoder 和 URLEncoder 對中文字元進行編碼和解碼》，此不贅述。

8、TCP與UDP的區別

　　TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協議屬於傳輸層協議，它們之間的區別包括：

• TCP是面向連線的，UDP是無連線的；

• TCP是可靠的，UDP是不可靠的；

• TCP只支援點對點通訊，UDP支援一對一、一對多、多對一、多對多的通訊模式；

• TCP是面向位元組流的，UDP是面向報文的；

• TCP有擁塞控制機制;UDP沒有擁塞控制，適合媒體通訊；

• TCP首部開銷(20個位元組)比UDP的首部開銷(8個位元組)要大；

9、TCP的擁塞處理

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

1).慢啟動：不要一開始就傳送大量的資料，先探測一下網路的擁塞程度，也就是說由小到大逐漸增加擁塞視窗的大小;

2).擁塞避免：擁塞避免演算法讓擁塞視窗緩慢增長，即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1，而不是加倍，這樣擁塞視窗按線性規律緩慢增長。

3).快重傳：快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認（為的是使傳送方及早知道有報文段沒有到達對方）而不要等到自己傳送資料時捎帶確認。快重傳演算法規定，傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設定的重傳計時器時間到期。

4).快恢復：快重傳配合使用的還有快恢復演算法，當傳送方連續收到三個重複確認時，就執行“乘法減小”演算法，把ssthresh門限減半，但是接下去並不執行慢開始演算法：因為如果網路出現擁塞的話就不會收到好幾個重複的確認，所以傳送方現在認為網路可能沒有出現擁塞。所以此時不執行慢開始演算法，而是將cwnd設定為ssthresh的大小，然後執行擁塞避免演算法。

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

　　(1). 瀏覽器查詢 DNS，獲取域名對應的IP地址:具體過程包括瀏覽器搜尋自身的DNS快取、搜尋作業系統的DNS快取、讀取本地的Host檔案和向本地DNS伺服器進行查詢等。對於向本地DNS伺服器進行查詢，如果要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具有權威性)；如果要查詢的域名不由本地DNS伺服器區域解析，但該伺服器已快取了此網址對映關係，則呼叫這個IP地址對映，完成域名解析（此解析不具有權威性）。如果本地域名伺服器並未快取該網址對映關係，那麼將根據其設定發起遞迴查詢或者迭代查詢；

　　(2). 瀏覽器獲得域名對應的IP地址以後，瀏覽器向伺服器請求建立連結，發起三次握手；

　　(3). TCP/IP連結建立起來後，瀏覽器向伺服器傳送HTTP請求；

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

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

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

11、Session、Cookie 與 Application

　　Cookie和Session都是客戶端與伺服器之間保持狀態的解決方案，具體來說，cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。

(1). Cookie及其相關API

　　Cookie實際上是一小段的文字資訊。客戶端請求伺服器，如果伺服器需要記錄該使用者狀態，就使用response向客戶端瀏覽器頒發一個Cookie，而客戶端瀏覽器會把Cookie儲存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給伺服器，伺服器檢查該Cookie，以此來辨認使用者狀態。伺服器還可以根據需要修改Cookie的內容。

(2). Session及其相關API

　　同樣地，會話狀態也可以儲存在伺服器端。客戶端請求伺服器，如果伺服器記錄該使用者狀態，就獲取Session來儲存狀態，這時，如果伺服器已經為此客戶端建立過session，伺服器就按照sessionid把這個session檢索出來使用；如果客戶端請求不包含sessionid，則為此客戶端建立一個session並且生成一個與此session相關聯的sessionid，並將這個sessionid在本次響應中返回給客戶端儲存。儲存這個sessionid的方式可以採用cookie機制，這樣在互動過程中瀏覽器可以自動的按照規則把這個標識發揮給伺服器；若瀏覽器禁用Cookie的話，可以通過URL重寫機制將sessionid傳回伺服器。

(3). Session 與 Cookie 的對比

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

• 大小限制：Cookie有大小限制並且瀏覽器對每個站點也有cookie的個數限制，Session沒有大小限制，理論上只與伺服器的記憶體大小有關；

• 安全性：Cookie存在安全隱患，通過攔截或本地檔案找得到cookie後可以進行攻擊，而Session由於儲存在伺服器端，相對更加安全；

• 伺服器資源消耗：Session是儲存在伺服器端上會存在一段時間才會消失，如果session過多會增加伺服器的壓力。

  Application（ServletContext）：與一個Web應用程式相對應，為應用程式提供了一個全域性的狀態，所有客戶都可以使用該狀態。

(4). Application

　　Application（Java Web中的ServletContext）：與一個Web應用程式相對應，為應用程式提供了一個全域性的狀態，所有客戶都可以使用該狀態。

12、SQL 注入

　　SQL注入就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字串，最終達到欺騙伺服器執行惡意的SQL命令。

1). SQL注入攻擊的總體思路

　　(1). 尋找到SQL注入的位置
　　(2). 判斷伺服器型別和後臺資料庫型別
　　(3). 針對不通的伺服器和資料庫特點進行SQL注入攻擊

2). SQL注入攻擊例項

　　比如，在一個登入介面，要求輸入使用者名稱和密碼，可以這樣輸入實現免帳號登入：

1. 使用者名稱： ‘or 1 = 1 --
2. 密 碼：

• 1
• 2

　　使用者一旦點選登入，如若沒有做特殊處理，那麼這個非法使用者就很得意的登陸進去了。這是為什麼呢?下面我們分析一下：從理論上說，後臺認證程式中會有如下的SQL語句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，當輸入了上面的使用者名稱和密碼，上面的SQL語句變成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL語句我們知道，
username=‘ or 1=1 這個語句一定會成功；然後後面加兩個-，這意味著註釋，它將後面的語句註釋，讓他們不起作用。這樣，上述語句永遠都能正確執行，使用者輕易騙過系統，獲取合法身份。

3). 應對方法

(1). 引數繫結

　　使用預編譯手段，繫結引數是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實現了SQL預編譯和引數繫結功能，攻擊者的惡意SQL會被當做SQL的引數而不是SQL命令被執行。在mybatis的mapper檔案中，對於傳遞的引數我們一般是使用#和$來獲取引數值。當使用#時，變數是佔位符，就是一般我們使用javajdbc的PrepareStatement時的佔位符，所有可以防止sql注入；當使用$時，變數就是直接追加在sql中，一般會有sql注入問題。

(2). 使用正則表示式過濾傳入的引數

13、 XSS 攻擊

　　XSS是一種經常出現在web應用中的電腦保安漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網站沒有對使用者提交資料進行轉義處理或者過濾不足的缺點，進而新增一些指令碼程式碼嵌入到web頁面中去，使別的使用者訪問都會執行相應的嵌入程式碼，從而盜取使用者資料、利用使用者身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

1). XSS攻擊的危害

• 盜取各類使用者帳號，如機器登入帳號、使用者網銀帳號、各類管理員帳號

• 控制企業資料，包括讀取、篡改、新增、刪除企業敏感資料的能力

• 盜竊企業重要的具有商業價值的資料

• 非法轉賬

• 強制傳送電子郵件

• 網站掛馬

• 控制受害者機器向其它網站發起攻擊

2). 原因解析

　　主要原因：過於信任客戶端提交的資料！

　　解決辦法：不信任任何客戶端提交的資料，只要是客戶端提交的資料就應該先進行相應的過濾處理然後方可進行下一步的操作。

　　進一步分析細節：客戶端提交的資料本來就是應用所需要的，但是惡意攻擊者利用網站對客戶端提交資料的信任，在資料中插入一些符號以及javascript程式碼，那麼這些資料將會成為應用程式碼中的一部分了，那麼攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的資料！！！

3). XSS 攻擊分類

(1). 反射性XSS攻擊 (非永續性XSS攻擊)

　　漏洞產生的原因是攻擊者注入的資料反映在響應中。一個典型的非永續性XSS攻擊包含一個帶XSS攻擊向量的連結(即每次攻擊需要使用者的點選)，例如，正常傳送訊息：

http://www.test.com/message.php?send=Hello,World！

• 1

接收者將會接收資訊並顯示Hello,World；但是，非正常傳送訊息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

• 1

接收者接收訊息顯示的時候將會彈出警告視窗！

(2). 永續性XSS攻擊 (留言板場景)

　　XSS攻擊向量(一般指XSS攻擊程式碼)儲存在網站資料庫，當一個頁面被使用者開啟的時候執行。也就是說，每當使用者使用瀏覽器開啟指定頁面時，指令碼便執行。與非永續性XSS攻擊相比，永續性XSS攻擊危害性更大。從名字就可以瞭解到，永續性XSS攻擊就是將攻擊程式碼存入資料庫中，然後客戶端開啟時就執行這些攻擊程式碼。

例如，留言板表單中的表單域：

<input type=“text” name=“content” value=“這裡是使用者填寫的資料”>

• 1

正常操作流程是：使用者是提交相應留言資訊 —— 將資料儲存到資料庫 —— 其他使用者訪問留言板，應用去資料並顯示；而非正常操作流程是攻擊者在value填寫:

<script>alert(‘foolish!’)；</script> <!--或者html其他標籤（破壞樣式。。。）、一段攻擊型程式碼-->

• 1

並將資料提交、儲存到資料庫中；當其他使用者取出資料顯示的時候，將會執行這些攻擊性程式碼。

4). 修復漏洞方針

　　漏洞產生的根本原因是太相信使用者提交的資料，對使用者所提交的資料過濾不足所導致的，因此解決方案也應該從這個方面入手，具體方案包括：

• 將重要的cookie標記為http only, 這樣的話Javascript 中的document.cookie語句就不能
  獲取到cookie了（如果在cookie中設定了HttpOnly屬性，那麼通過js指令碼將無法讀取到cookie資訊，這樣能有效的防止XSS攻擊）；

• 表單資料規定值的型別，例如：年齡應為只能為int、name只能為字母數字組合。。。。

• 對資料進行Html Encode 處理

• 過濾或移除特殊的Html標籤，例如: <script>, <iframe> , < for <, > for>, &quot for

• 過濾JavaScript 事件的標籤，例如 “οnclick=”, “onfocus” 等等。

  　　需要注意的是，在有些應用中是允許html標籤出現的，甚至是javascript程式碼出現。因此，我們在過濾資料的時候需要仔細分析哪些資料是有特殊要求（例如輸出需要html程式碼、javascript程式碼拼接、或者此表單直接允許使用等等），然後區別處理！

14、OSI網路體系結構與TCP/IP協議模型

　　為了更好地瞭解計算機網路體系結構，筆者以兩篇部落格的篇幅來介紹這個計算機網路中最為重要的知識點，具體見《計算機網路體系結構綜述（上）》和《計算機網路體系結構綜述（下）》。下面只做簡要的總結。

　　在《計算機網路體系結構綜述（下）》一文中，我們知道TCP/IP與OSI最大的不同在於：OSI是一個理論上的網路通訊模型，而TCP/IP則是實際上的網路通訊標準。但是，它們的初衷是一樣的，都是為了使得兩臺計算機能夠像兩個知心朋友那樣能夠互相準確理解對方的意思並做出優雅的迴應。現在，我們對OSI七層模型的各層進行簡要的介紹：

1). 物理層

　　參考模型的最低層，也是OSI模型的第一層，實現了相鄰計算機節點之間位元流的透明傳送，並儘可能地遮蔽掉具體傳輸介質和物理裝置的差異，使其上層(資料鏈路層)不必關心網路的具體傳輸介質。

2). 資料鏈路層（data link layer）

　　接收來自物理層的位流形式的資料，並封裝成幀，傳送到上一層；同樣，也將來自上層的資料幀，拆裝為位流形式的資料轉發到物理層。這一層在物理層提供的位元流的基礎上，通過差錯控制、流量控制方法，使有差錯的物理線路變為無差錯的資料鏈路，即提供可靠的通過物理介質傳輸資料的方法。

3). 網路層

　　將網路地址翻譯成對應的實體地址，並通過路由選擇演算法為分組通過通訊子網選擇最適當的路徑。

4). 傳輸層（transport layer）

　　在源端與目的端之間提供可靠的透明資料傳輸，使上層服務使用者不必關係通訊子網的實現細節。在協議棧中，傳輸層位於網路層之上，傳輸層協議為不同主機上執行的程序提供邏輯通訊，而網路層協議為不同主機提供邏輯通訊，如下圖所示。

　　實際上，網路層可以看作是傳輸層的一部分，其為傳輸層提供服務。但對於終端系統而言，網路層對它們而言是透明的，它們知道傳輸層的存在，也就是說，在邏輯上它們認為是傳輸層為它們提供了端對端的通訊，這也是分層思想的妙處。

5). 會話層（Session Layer）

　　會話層是OSI模型的第五層，是使用者應用程式和網路之間的介面，負責在網路中的兩節點之間建立、維持和終止通訊。

6). 表示層（Presentation Layer）：資料的編碼，壓縮和解壓縮，資料的加密和解密

　　表示層是OSI模型的第六層，它對來自應用層的命令和資料進行解釋，以確保一個系統的應用層所傳送的資訊可以被另一個系統的應用層讀取。

7). 應用層（Application layer）：為使用者的應用程序提供網路通訊服務

15、TCP和UDP分別對應的常見應用層協議

1). 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伺服器傳輸超文字到本地瀏覽器的傳送協議。

2). UDP對應的應用層協議

• DNS：用於域名解析服務，將域名地址轉換為IP地址。DNS用的是53號埠。

• SNMP：簡單網路管理協議，使用161號埠，是用來管理網路裝置的。由於網路裝置很多，無連線的服務就體現出其優勢。

• TFTP(Trival File Transfer Protocal)：簡單檔案傳輸協議，該協議在熟知埠69上使用UDP服務。

3). 圖示

16、網路層的ARP協議工作原理

　　網路層的ARP協議完成了IP地址與實體地址的對映。首先，每臺主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址的對應關係。當源主機需要將一個數據包要傳送到目的主機時，會首先檢查自己ARP列表中是否存在該IP地址對應的MAC地址：如果有，就直接將資料包傳送到這個MAC地址；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求資料包裡包括源主機的IP地址、硬體地址、以及目的主機的IP地址。網路中所有的主機收到這個ARP請求後，會檢查資料包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此資料包；如果相同，該主機首先將傳送端的MAC地址和IP地址新增到自己的ARP列表中，如果ARP表中已經存在該IP的資訊，則將其覆蓋，然後給源主機發送一個ARP響應資料包，告訴對方自己是它需要查詢的MAC地址；源主機收到這個ARP響應資料包後，將得到的目的主機的IP地址和MAC地址新增到自己的ARP列表中，並利用此資訊開始資料的傳輸。如果源主機一直沒有收到ARP響應資料包，表示ARP查詢失敗。

17、IP地址的分類

　　IP地址是指網際網路協議地址，是IP協議提供的一種統一的地址格式，它為網際網路上的每一個網路和每一臺主機分配一個邏輯地址，以此來遮蔽實體地址的差異。IP地址編址方案將IP地址空間劃分為A、B、C、D、E五類，其中A、B、C是基本類，D、E類作為多播和保留使用，為特殊地址。

　　每個IP地址包括兩個標識碼（ID），即網路ID和主機ID。同一個物理網路上的所有主機都使用同一個網路ID，網路上的一個主機（包括網路上工作站，伺服器和路由器等）有一個主機ID與其對應。A~E類地址的特點如下：

• A類地址：以0開頭，第一個位元組範圍：0~127；

• B類地址：以10開頭，第一個位元組範圍：128~191；

• C類地址：以110開頭，第一個位元組範圍：192~223；

• D類地址：以1110開頭，第一個位元組範圍為224~239；

• E類地址：以1111開頭，保留地址

1). A類地址：1位元組的網路地址 + 3位元組主機地址，網路地址的最高位必須是“0”

　　一個A類IP地址是指， 在IP地址的四段號碼中，第一段號碼為網路號碼，剩下的三段號碼為本地計算機的號碼。如果用二進位制表示IP地址的話，A類IP地址就由1位元組的網路地址和3位元組主機地址組成，網路地址的最高位必須是“0”。A類IP地址中網路的標識長度為8位，主機標識的長度為24位，A類網路地址數量較少，有126個網路，每個網路可以容納主機數達1600多萬臺。

　　A類IP地址的地址範圍1.0.0.0到127.255.255.255（二進位制表示為：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111 11111111），最後一個是廣播地址。A類IP地址的子網掩碼為255.0.0.0，每個網路支援的最大主機數為256的3次方-2=16777214臺。

2). B類地址: 2位元組的網路地址 + 2位元組主機地址，網路地址的最高位必須是“10”

　　一個B類IP地址是指，在IP地址的四段號碼中，前兩段號碼為網路號碼。如果用二進位制表示IP地址的話，B類IP地址就由2位元組的網路地址和2位元組主機地址組成，網路地址的最高位必須是“10”。B類IP地址中網路的標識長度為16位，主機標識的長度為16位，B類網路地址適用於中等規模的網路，有16384個網路，每個網路所能容納的計算機數為6萬多臺。

　　B類IP地址地址範圍128.0.0.0-191.255.255.255（二進位制表示為：10000000 00000000 00000000 00000000—-10111111 11111111 11111111 11111111），最後一個是廣播地址。B類IP地址的子網掩碼為255.255.0.0，每個網路支援的最大主機數為256的2次方-2=65534臺。

3). C類地址: 3位元組的網路地址 + 1位元組主機地址，網路地址的最高位必須是“110”

　　一個C類IP地址是指，在IP地址的四段號碼中，前三段號碼為網路號碼，剩下的一段號碼為本地計算機的號碼。如果用二進位制表示IP地址的話，C類IP地址就由3位元組的網路地址和1位元組主機地址組成，網路地址的最高位必須是“110”。C類IP地址中網路的標識長度為24位，主機標識的長度為8位，C類網路地址數量較多，有209萬餘個網路。適用於小規模的區域網絡，每個網路最多隻能包含254臺計算機。

　　C類IP地址範圍192.0.0.0-223.255.255.255（二進位制表示為: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111）。C類IP地址的子網掩碼為255.255.255.0，每個網路支援的最大主機數為256-2=254臺。

4). D類地址:多播地址，用於1對多通訊，最高位必須是“1110”

　　D類IP地址在歷史上被叫做多播地址(multicast address)，即組播地址。在乙太網中，多播地址命名了一組應該在這個網路中應用接收到一個分組的站點。多播地址的最高位必須是“1110”，範圍從224.0.0.0到239.255.255.255。

5). E類地址:為保留地址，最高位必須是“1111”

18、IP地址與實體地址

　　實體地址是資料鏈路層和物理層使用的地址，IP地址是網路層和以上各層使用的地址，是一種邏輯地址，其中ARP協議用於IP地址與實體地址的對應。

21、 常見狀態碼及原因短語

　　HTTP請求結構： 請求方式 + 請求URI + 協議及其版本
　　HTTP響應結構： 狀態碼 + 原因短語 + 協議及其版本

• 1×× : 請求處理中，請求已被接受，正在處理

• 2×× : 請求成功，請求被成功處理
  200 OK

• 3×× : 重定向，要完成請求必須進行進一步處理
  301 : 永久性轉移
  302 ：暫時性轉移
  304 ： 已快取

• 4×× : 客戶端錯誤，請求不合法
  400：Bad Request,請求有語法問題
  403：拒絕請求
  404：客戶端所訪問的頁面不存在

• 5×× : 伺服器端錯誤，伺服器不能處理合法請求
  500 ：伺服器內部錯誤
  503 ： 服務不可用，稍等