====執行在TCP 或UDP的應用層協議分析？

執行在TCP協議上的協議：

HTTP（Hypertext Transfer Protocol，超文字傳輸協議），主要用於普通瀏覽。

HTTPS（HTTP over SSL，安全超文字傳輸協議）,HTTP協議的安全版本。

FTP（File Transfer Protocol，檔案傳輸協議），用於檔案傳輸。

POP3（Post Office Protocol, version 3，郵局協議），收郵件用。

SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議），用來發送電子郵件。

TELNET（Teletype over the Network，網路電傳），通過一個終端（terminal）登陸到網

絡。

SSH（Secure Shell，用於替代安全性差的TELNET），用於加密安全登陸用。

執行在UDP協議上的協議：

BOOTP（Boot Protocol，啟動協議），應用於無盤裝置。

NTP（Network Time Protocol，網路時間協議），用於網路同步。

DHCP（Dynamic Host Configuration Protocol，動態主機配置協議），動態配置IP地址。

執行在TCP和UDP協議上：

DNS（Domain Name Service，域名服務），用於完成地址查詢，郵件轉發等工作。

ECHO（Echo Protocol，迴繞協議），用於查錯及測量應答時間（執行在TCP和UDP協議

上）。

SNMP（Simple Network Management Protocol，簡單網路管理協議），用於網路資訊的

收集和網路管理。

DHCP（Dynamic Host Configuration Protocol，動態主機配置協議），動態配置IP地址。

====什麼是ARP協議 (Address Resolution Protocol)？

ARP協議完成了IP地址與實體地址的對映。每一個主機都設有一個 ARP 快取記憶體，裡面有所在的區域網上的各主機和路由器的 IP 地址到硬體地址的對映表。當源主機要傳送資料包到目的主機時，會先檢查自己的ARP快取記憶體中有沒有目的主機的MAC地址，如果有，就直接將資料包發到這個MAC地址，如果沒有，就向所在的區域網發起一個ARP請求的廣播包（在傳送自己的 ARP 請求時，同時會帶上自己的 IP 地址到硬體地址的對映），收到請求的主機檢查自己的IP地址和目的主機的IP地址是否一致，如果一致，則先儲存源主機的對映到自己的ARP快取，然後給源主機發送一個ARP響應資料包。源主機收到響應資料包之後，先新增目的主機的IP地址與MAC地址的對映，再進行資料傳送。如果源主機一直沒有收到響應，表示ARP查詢失敗。

如果所要找的主機和源主機不在同一個區域網上，那麼就要通過 ARP 找到一個位於本區域網上的某個路由器的硬體地址，然後把分組傳送給這個路由器，讓這個路由器把分組轉發給下一個網路。剩下的工作就由下一個網路來做。

====什麼是NAT (Network Address Translation, 網路地址轉換)？

用於解決內網中的主機要和因特網上的主機通訊。由NAT路由器將主機的本地IP地址轉換為全球IP地址，分為靜態轉換（轉換得到的全球IP地址固定不變）和動態NAT轉換。

====從輸入址到獲得頁面的過程?（重點常問）

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

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

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

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

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

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

====講一講TCP的三次握手(重點常問)?

在網路資料傳輸中，傳輸層協議TCP是要建立連線的可靠傳輸，TCP建立連線的過程，我們稱為三次握手。

1. 第一次握手：Client將SYN置1，隨機產生一個初始序列號seq傳送給Server，進入SYN_SENT狀態；

2. 第二次握手：Server收到Client的SYN=1之後，知道客戶端請求建立連線，將自己的SYN置1，ACK置1，產生一個acknowledge number=sequence number+1，並隨機產生一個自己的初始序列號，傳送給客戶端；進入SYN_RCVD狀態；

3. 第三次握手：客戶端檢查acknowledge number是否為序列號+1，ACK是否為1，檢查正確之後將自己的ACK置為1，產生一個acknowledge number=伺服器發的序列號+1，傳送給伺服器；進入ESTABLISHED狀態；伺服器檢查ACK為1和acknowledge number為序列號+1之後，也進入ESTABLISHED狀態；完成三次握手，連線建立。

簡單來說就是：

1). 客戶端向服務端傳送SYN

2). 服務端返回SYN,ACK

3). 客戶端傳送ACK

====建立連線可以兩次握手嗎？為什麼?

不可以。

因為可能會出現已失效的連線請求報文段又傳到了伺服器端。 > client 發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但 server 收到此失效的連線請求報文段後，就誤認為是 client 再次發出的一個新的連線請求。於是就向 client 發出確認報文段，同意建立連線。假設

不採用 “三次握手”，那麼只要 server 發出確認，新的連線就建立了。由於現在 client 並沒有發出建立連線的請求，因此不會理睬 server 的確認，也不會向 server 傳送資料。但 server 卻以為新的運輸連線已經建立，並一直等待 client 發來資料。這樣，server 的很多資源就白白浪費掉了。採用 “三次握手” 的辦法可以防止上述現象發生。例如剛才那種情況，client 不會向 server 的確認發出確認。server 由於收不到確認，就知道 client 並沒有要求建立連線。而且，兩次握手無法保證Client正確接收第二次握手的報文（Server無法確認Client是否收到），也無法保證Client和Server之間成功互換初始序列號。

====可以採用四次握手嗎？為什麼？

這個肯定可以。三次握手都可以保證連線成功了，何況是四次，但是會降低傳輸的效率。

====第三次握手中，如果客戶端的ACK未送達伺服器，會怎樣？

Server端：由於Server沒有收到ACK確認，因此會每隔 3秒 重發之前的SYN+ACK（預設重發五次，之後自動關閉連線進入CLOSED狀態），Client收到後會重新傳ACK給Server。

Client端，會出現兩種情況：

1). 在Server進行超時重發的過程中，如果Client向伺服器傳送資料，資料頭部的ACK是為1的，所以伺服器收到資料之後會讀取 ACK number，進入 establish 狀態

2). 在Server進入CLOSED狀態之後，如果Client向伺服器傳送資料，伺服器會以RST包應答。

==== TCP三次握手中如果已經建立了連線，但客戶端出現了故障怎麼辦？

伺服器每收到一次客戶端的請求後都會重新復位一個計時器，時間通常是設定為2小時，若兩小時還沒有收到客戶端的任何資料，伺服器就會發送一個探測報文段，以後每隔75秒鐘傳送一次。若一連發送10個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連線。

====TCP三次握手只能初始序列號是什麼？

TCP連線的一方A，隨機選擇一個32位的序列號（Sequence Number）作為傳送資料的初始序列號（Initial Sequence Number，ISN），比如為1000，以該序列號為原點，對要傳送的資料進行編號：1001、1002...三次握手時，把這個初始序列號傳送給另一方B，以便在傳輸資料時，B可以確認什麼樣的資料編號是合法的；同時在進行資料傳輸時，A還可以確認B收到的每一個位元組，如果A收到了B的確認編號（acknowledge number）是2001，就說明編號為1001-2000的資料已經被B成功接受。