計算機網絡面試題（一）

互聯網協議地址（英語：Internet Protocol Address，又譯爲網際協議地址），縮寫爲IP地址（英語：IP Address），是分配給用戶上網使用的網際協議（英語：Internet Protocol, IP）的設備的數字標籤。常見的IP地址分爲IPv4與IPv6兩大類，可是也有其餘不經常使用的小分類。

你知道IP數據報的格式嘛

版本 : 有 4（IPv4）和 6（IPv6）兩個值；
首部長度 : 佔 4 位，所以最大值爲 15。值爲 1 表示的是 1 個 32 位字的長度，也就是 4 字節。由於首部固定長度爲 20 字節，所以該值最小爲 5。若是可選字段的長度不是 4 字節的整數倍，就用尾部的填充部分來填充。
區分服務 : 用來得到更好的服務，通常狀況下不使用。
總長度 : 包括首部長度和數據部分長度。
生存時間 ：TTL，它的存在是爲了防止沒法交付的數據報在互聯網中不斷兜圈子。以路由器跳數爲單位，當 TTL 爲 0 時就丟棄數據報。
協議：指出攜帶的數據應該上交給哪一個協議進行處理，例如 ICMP、TCP、UDP 等。
首部檢驗和 ：由於數據報每通過一個路由器，都要從新計算檢驗和，所以檢驗和不包含數據部分能夠減小計算的工做量。
標識 : 在數據報長度過長從而發生分片的狀況下，相同數據報的不一樣分片具備相同的標識符。
片偏移 : 和標識符一塊兒，用於發生分片的狀況。片偏移的單位爲 8 字節

IP地址分爲哪幾類？簡單說一下各個分類

由兩部分組成，網絡號和主機號，其中不一樣分類具備不一樣的網絡號長度，而且是固定的。

IP 地址 ::= {< 網絡號 >, < 主機號 >}

IP地址分爲五大類：A類、B類、C類、D類和E類，以下圖所示：

IP地址的指派範圍：

通常不使用的特殊IP地址：

ARP（地址解析協議)

ARP是地址解析協議，簡單語言解釋一下工做原理。

ARP 實現由 IP 地址獲得 MAC 地址。

1：首先，每一個主機都會在本身的ARP緩衝區中創建一個ARP列表，以表示IP地址和MAC地址之間的對應關係。

2：當源主機要發送數據時，首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址，若是有，則直接發送數據，若是沒有，就向本網段的全部主機發送ARP數據包，該數據包包括的內容有：源主機IP地址，源主機MAC地址，目的主機的IP地址。

3：當本網絡的全部主機收到該ARP數據包時，首先檢查數據包中的IP地址是不是本身的IP地址，若是不是，則忽略該數據包，若是是，則首先從數據包中取出源主機的IP和MAC地址寫入到ARP列表中，若是已經存在，則覆蓋，而後將本身的MAC地址寫入ARP響應包中，告訴源主機本身是它想要找的MAC地址。

4：源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表，並利用此信息發送數據。若是源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

廣播發送ARP請求，單播發送ARP響應。

運輸層

TCP (傳輸控制協議)

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，由IETF的RFC 793定義。

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

TCP提供一種面向鏈接的、可靠的字節流服務。其中，面向鏈接意味着兩個使用TCP的應用（一般是一個客戶和一個服務器）在彼此交換數據以前必須先創建一個TCP鏈接。在一個TCP鏈接中，僅有兩方進行彼此通訊；而字節流服務意味着兩個應用程序經過TCP連接交換8bit字節構成的字節流，TCP不在字節流中插入記錄標識符。

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

數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時TCP發送數據端超時後會重發數據；
對失序數據包重排序：既然TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。TCP將對失序數據進行從新排序，而後才交給應用層；
丟棄重複數據：對於重複數據，可以丟棄重複數據；
應答機制：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒；
超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段；
流量控制：TCP鏈接的每一方都有固定大小的緩衝空間。TCP的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

TCP瞭解嗎，說一下滑動窗口

窗口是緩存的一部分，用來暫時存放字節流。發送方和接收方各有一個窗口，接收方經過 TCP 報文段中的窗口字段告訴發送方本身的窗口大小，發送方根據這個值和其它信息設置本身的窗口大小。

發送窗口內的字節都容許被髮送，接收窗口內的字節都容許被接收。若是發送窗口左部的字節已經發送而且收到了確認，那麼就將發送窗口向右滑動必定距離，直到左部第一個字節不是已發送而且已確認的狀態；接收窗口的滑動相似，接收窗口左部字節已經發送確認並交付主機，就向右滑動接收窗口。

接收窗口只會對窗口內最後一個按序到達的字節進行確認，例如接收窗口已經收到的字節爲 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，所以只對字節 31 進行確認。發送方獲得一個字節的確認以後，就知道這個字節以前的全部字節都已經被接收。

TCP的擁塞控制怎麼實現的

計算機網絡中的帶寬、交換結點中的緩存及處理機等都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞，這種狀況就叫作擁塞。擁塞控制就是防止過多的數據注入網絡中，這樣可使網絡中的路由器或鏈路不致過載。

若是網絡出現擁塞，分組將會丟失，此時發送方會繼續重傳，從而致使網絡擁塞程度更高。所以當出現擁塞時，應當控制發送方的速率。這一點和流量控制很像，可是出發點不一樣。流量控制是爲了讓接收方能來得及接收，而擁塞控制是爲了下降整個網絡的擁塞程度。

注意，擁塞控制和流量控制不一樣，前者是一個全局性的過程，然後者指點對點通訊量的控制。擁塞控制的方法主要有如下四種： A、慢啓動 B、擁塞避免 C、快重傳 D、快恢復

發送方須要維護一個叫作擁塞窗口（cwnd）的狀態變量，注意擁塞窗口與發送方窗口的區別：擁塞窗口只是一個狀態變量，實際決定發送方能發送多少數據的是發送方窗口。

爲了便於討論，作以下假設：

A、接收方有足夠大的接收緩存，所以不會發生流量控制；

B、雖然 TCP 的窗口基於字節，可是這裏設窗口的大小單位爲報文段。

慢啓動與擁塞避免

慢啓動：

不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增長擁塞窗口的大小。

擁塞避免：

擁塞避免算法讓擁塞窗口緩慢增加，即每通過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規律緩慢增加。

發送的最初執行慢開始，令 cwnd = 1，發送方只能發送 1 個報文段；當收到確認後，將 cwnd 加倍，所以以後發送方可以發送的報文段數量爲：二、四、8 …

注意到慢開始每一個輪次都將 cwnd 加倍，這樣會讓 cwnd 增加速度很是快，從而使得發送方發送的速度增加速度過快，網絡擁塞的可能性也就更高。設置一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每一個輪次只將 cwnd 加 1。

若是出現了超時，則令 ssthresh = cwnd / 2，而後從新執行慢開始。

快重傳與快恢復

快重傳：

快重傳要求接收方在收到一個 失序的報文段 後就當即發出 重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到本身發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段，而沒必要繼續等待設置的重傳計時器時間到期。

快恢復：

快重傳配合使用的還有快恢復算法，當發送方連續收到三個重複確認時，就執行「乘法減少」算法，把ssthresh門限減半，可是接下去並不執行慢開始算法：由於若是網絡出現擁塞的話就不會收到好幾個重複的確認，因此發送方如今認爲網絡可能沒有出現擁塞。因此此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，而後執行擁塞避免算法。

在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應當發送對 M2 的確認。

在發送方，若是收到三個重複確認，那麼能夠知道下一個報文段丟失，此時執行快重傳，當即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，當即重傳 M3。

在這種狀況下，只是丟失個別報文段，而不是網絡擁塞。所以執行快恢復，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。

慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增加速率。慢開始 cwnd 設定爲 1，而快恢復 cwnd 設定爲 ssthresh。

TCP流量控制的流程圖：

講講TCP握手的三次流程

SYN：同步SYN(SYNchronization),在鏈接創建使用來同步序號。SYN置1表示這是一個鏈接請求或鏈接接受請求。

ACK：確認ACK(ACKnowledgment),僅當ACK=1時確認號字段纔有效。TCP規定，在鏈接創建後全部的報文段都必須把ACK置1。

seq: 序號。

ack: 確認號。

最初兩端的TCP進程都處於CLOSE(關閉)狀態。

上圖中A主動打開鏈接，B被動打開鏈接。
B打開鏈接後處於LISTEN(監聽狀態)，等待客戶的鏈接請求。
A向B發送請求報文，SYN=1,ACK=0,選擇一個初始序號seq=x。
B 收到鏈接請求報文，若是贊成創建鏈接，則向 A 發送鏈接確認報文，SYN=1，ACK=1，確認號爲ack= x+1，同時也選擇一個初始的序號 seq=y。
A 收到 B 的鏈接確認報文後，還要向 B 發出確認，確認號爲ack= y+1，序號爲 seq=x+1。
B 收到 A 的確認後，鏈接創建。

講講TCP的四次揮手過程

數據傳輸結束後，通訊的雙方均可釋放鏈接。

此處爲A的應用進程先向其TCP發出鏈接釋放報文段，可是A結束TCP鏈接的時間要比B晚一些。

FIN: 終止FINs,用來釋放一個鏈接。當FIN等於1時，代表此報文段的發送方的數據已發送完畢，並要求釋放運輸鏈接。

ACK: 確認ACK(ACKnowledgment),僅當ACK=1時確認號字段纔有效。TCP規定，在鏈接創建後全部的報文段都必須把ACK置1。

seq: 序號。

ack: 確認號。

如下描述不討論序號和確認號，由於序號和確認號的規則比較簡單。而且不討論 ACK，由於 ACK 在鏈接創建以後都爲 1。

A 發送鏈接釋放報文，FIN=1。
B 收到以後發出確認，此時 TCP 屬於半關閉狀態，B 能向 A 發送數據可是 A 不能向 B 發送數據。
當 B 再也不須要鏈接時，發送鏈接釋放報文，FIN=1。
A 收到後發出確認，進入 TIME-WAIT 狀態，等待 2 MSL（最大報文存活時間）後釋放鏈接。
B 收到 A 的確認後釋放鏈接。

TCP四次揮手的緣由

四次揮手的緣由

CLOSE-WAIT

客戶端發送了 FIN 鏈接釋放報文以後，服務器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是爲了讓服務器端發送還未傳送完畢的數據，傳送完畢以後，服務器會發送 FIN 鏈接釋放報文。

TIME-WAIT

客戶端接收到服務器端的 FIN 報文後進入此狀態，此時並非直接進入 CLOSED 狀態，還須要等待一個時間計時器設置的時間 2MSL。

爲何A在TIME-WAIT狀態必須等待2MSL的時間呢？

這麼作有兩個理由：

爲了保證A發送的最後一個ACK報文段可以到達B。

A發送的這個ACK報文段有可能丟失，若是 B 沒收到 A 發送來的確認報文，那麼A就會從新發送鏈接釋放請求報文，A 等待一段時間就是爲了處理這種狀況的發生。
防止「已經失效的鏈接請求報文段」出如今本連接中。

A在發送完最後一個ACK報文段後，再通過時間2MSL，就可使本鏈接的時間內所產生的全部報文段都從網絡中消失。這樣下一個新的鏈接中就不會出現這種舊的鏈接請求報文段。

爲何創建鏈接協議是三次握手，而關閉鏈接倒是四次握手呢？

這是由於服務端的LISTEN狀態下的SOCKET當收到SYN報文的鏈接請求後，它能夠把ACK和SYN(ACK起應答做用，而SYN起同步做用)放在一個報文裏來發送。但關閉鏈接時，當收到對方的FIN報文通知時，**它僅僅表示對方沒有數據發送給你了；但未必你全部的數據都所有發送給對方了，**因此你可能未必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

UDP（用戶數據報協議）

用戶數據包協議（英語：User Datagram Protocol，縮寫：UDP），又稱用戶數據包協議，是一個簡單的面向數據報的傳輸層協議。該協議由 David P. Reed 在 1980 年設計且在RFC 768中被規範。

在TCP/IP模型中，UDP爲網絡層以上和應用層如下提供了一個簡單的接口。UDP只提供數據的不可靠傳遞，它一旦把應用程序發給網絡層的數據發送出去，就不保留數據備份（因此UDP有時候也被認爲是不可靠的數據報協議）。UDP在IP數據報的頭部僅僅加入了複用和數據校驗（字段）

TCP和UDP的區別與聯繫

TCP面向鏈接，傳輸數據以前要須要創建會話。UDP是無鏈接的。
TCP提供可靠傳輸，保證數據不丟包、不重複且按順序到達；UDP只盡努力交付，不保證可靠交付
TCP提供了擁塞控制；UDP不提供
TCP是面向字節流的；UDP面向報文。
TCP只支持點到點通訊；UDP支持一對1、一對多、多對多的交互通訊。
TCP首部開銷大20字節，UDP首部開銷小8字節。
- UDP的首部格式
- TCP的首部格式

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服務。

應用層

HTTP(超文本傳輸協議)

超文本傳輸協議（英語：HyperText Transfer Protocol，縮寫：HTTP）是一種用於分佈式、協做式和超媒體信息系統的應用層協議[1]。HTTP是萬維網的數據通訊的基礎。

HTTP協議定義了瀏覽器（即互聯網客戶進程）怎樣向萬維網文檔，以及服務器怎樣把文檔傳送給瀏覽器。從層次的角度看，HTTP是面向事務的應用層協議，它是萬維網可以可靠的交付文件的重要基礎。

HTTP構建於TCP/IP協議之上，默認端口號是80
HTTP是無鏈接無狀態的

HTTP 協議包括哪些請求？

HTTP協議中共定義了八種方法或者叫「動做」來代表對Request-URI指定的資源的不一樣操做方式，具體介紹以下：

GET：向特定的資源發出請求。
POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的建立和/或已有資源的修改。
OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法。也能夠利用向Web服務器發送’*'的請求來測試服務器的功能性。
HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息。
PUT：向指定資源位置上傳其最新內容。
DELETE：請求服務器刪除Request-URI所標識的資源。
TRACE：回顯服務器收到的請求，主要用於測試或診斷。
CONNECT：HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。

雖然HTTP的請求方式有8種，可是咱們在實際應用中經常使用的也就是get和post，其餘請求方式也均可以經過這兩種方式間接的來實現。

摘自：https://www.cnblogs.com/web100/p/http-8-request.html

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

常見的HTTP狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息–表示請求已接收，繼續處理
2xx：成功–表示請求已被成功接收、理解、接受
3xx：重定向–要完成請求必須進行更進一步的操做
4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤–服務器未能實現合法的請求

常見狀態代碼、狀態描述、說明：

200 OK      //客戶端請求成功
400 Bad Request  //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用 
403 Forbidden  //服務器收到請求，可是拒絕提供服務
404 Not Found  //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable  //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

HTTPS（超文本傳輸安全協議）

超文本傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱爲HTTP over TLS，HTTP over SSL或HTTP Secure）是一種經過計算機網絡進行安全通訊的傳輸協議。HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密數據包。HTTPS開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私與完整性。這個協議由網景公司（Netscape）在1994年首次提出，隨後擴展到互聯網上。

Http和Https的區別

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

端口不一樣：Http與Http使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443；
資源消耗：和HTTP通訊相比，Https通訊會因爲加減密處理消耗更多的CPU和內存資源；
開銷：Https通訊須要證書，而證書通常須要向認證機構購買；
Https的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。

詳情：我是這樣理解HTTP和HTTPS的

DNS

DNS是一中用於TCP/IP應用程序的分佈式數據庫，它提供域名到IP地址的轉換。舉例來講，若是你要訪問域名math.stackexchange.com，首先要經過DNS查出它的IP地址是151.101.129.69 。

域名的解析過程

詳見：https://blog.csdn.net/Lammonpeter/article/details/81358387

DNS域名系統，簡單描述其工做原理。

當DNS客戶機須要在程序中使用名稱時，它會查詢DNS服務器來解析該名稱。客戶機發送的每條查詢信息包括三條信息：指定的DNS域名，指定的查詢類型，DNS域名的指定類別。基於UDP服務，端口53. 該應用通常不直接爲用戶使用，而是爲其餘應用服務，如HTTP，SMTP等在其中須要完成主機名到IP地址的轉換。

客戶機向其本地域名服務器發出DNS請求報文
本地域名服務器收到請求後，查詢本地緩存，假設沒有該記錄，則以DNS客戶的身份向根域名服務器發出解析請求
根域名服務器收到請求後，判斷該域名所屬域，將對應的頂級域名服務器的IP地址返回給本地域名服務器
本地域名服務器向頂級域名服務器發出解析請求報文
頂級域名服務器收到請求後，將所對應的受權域名服務器的IP地址返回給本地域名服務器
本地域名服務器向受權域名服務器發起解析請求報文
受權域名服務器收到請求後，將查詢結果返回給本地域名服務器
本地域名服務器將查詢結果保存到本地緩存，同時返回給客戶機

摘自：https://www.jianshu.com/p/4bb72930231b

計算機網絡安全

對稱加密與非對稱加密

對稱密鑰加密，又稱私鑰加密，即信息的發送方和接收方用同一個密鑰去加密和解密數據。

它的最大優點是加/解密速度快，適合於對大數據量進行加密，但密鑰管理困難且較爲不安全。
進行一對一的雙向保密通訊。
常見的對稱加密算法：DES，AES等。

非對稱密鑰加密，又稱公鑰加密，它須要使用一對密鑰來分別完成加密和解密操做，一個公開發布，即公開密鑰，另外一個由用戶本身祕密保存，即私用密鑰。信息發送者用公開密鑰去加密，而信息接收者則用私用密鑰去解密。

從功能角度而言非對稱加密比對稱加密功能強大且較爲安全，但加密和解密速度卻比對稱密鑰加密慢得多。
多對一的單向保密通訊。
最經常使用的非對稱加密算法：RSA

因爲非對稱加密的方式不須要發送用來解密的私鑰，因此能夠保證安全性；可是和對稱加密比起來，它很是的慢，因此咱們仍是要用對稱加密來傳送消息，但對稱加密所使用的密鑰咱們能夠經過非對稱加密的方式發送出去。

數字簽名

數字簽名必須保證明現如下三點功能：

報文鑑別。即接受者可以覈實發送者對報文的簽名。
報文的完整性。即接受者確信所收到的數據和發送者發送的徹底同樣而沒有被篡改過。
不能否認。發送者過後不能抵賴對報文的簽名。

數字簽名圖解：

該圖只是進行了數字簽名並無對報文進行加密。

數字簽名過程：A用私鑰SKA對明文X進行D運算簽名成爲密文DSKA，B用A的公鑰PKA對密文DSKA進行E運算還原出明文X。

那麼這個過程是如何知足報文鑑別、報文的完整性、不能否認三個特色的呢？

只有A擁有私鑰SKA，只有他能生成密文DSKA，因此只要B用A的公鑰能成功還原出可讀的明文X就說明密文DSKA必定是A發來的。這裏體現出報文的鑑別的特色。
同理若是中途密文DSKA被篡改，那麼篡改者沒有A的私鑰SKA來對篡改事後的報文進行加密，那麼B對被篡改過的報文進行解密時就會獲得不可讀的明文，就知道收到的報文被修改過了。這裏體現了報文的完整性的特色。
若A抵賴曾發過該報文給B，B可把X和密文DSKA出示給進行公證的第三者，第三者很容易用PKA去證明A確實發送了X給B。這裏體現了不能否認的特色。

具備保密性的數字簽名圖解：

其餘

cookie和session區別？

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

應用場景

平常登陸一個網站，今天輸入用戶名密碼登陸了，次日再打開不少狀況下就直接打開了。這個時候用到的一個機制就是cookie。

session的一個場景是購物車，添加了商品以後客戶端處能夠知道添加了哪些商品，而服務器端如何判別呢，因此也須要存儲一些信息，這裏就用到了session。

Cookie

通俗講，Cookie是訪問某些網站之後在本地存儲的一些網站相關的信息，下次再訪問的時候減小一些步驟。另一個更準確的說法是：Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器，是一種在客戶端保持狀態的方案。

Cookie的主要內容包括：名字，值，過時時間，路徑和域。使用Fiddler抓包就能夠看見，比方說咱們打開百度的某個網站能夠看到Headers包括Cookie，以下：
BIDUPSID: 9D2194F1CB8D1E56272947F6B0E5D47E
PSTM: 1472480791
BAIDUID: 3C64D3C3F1753134D13C33AFD2B38367:FG
ispeed_lsm: 2
MCITY: -131:
pgv_pvi: 3797581824
pgv_si: s9468756992
BDUSS: JhNXVoQmhPYTVENEdIUnQ5S05xcHZMMVY5QzFRNVh5SzZoV0xMVDR6RzV-bEJZSVFBQUFBJCQAAAAAAAAAAAEAAACteXsbYnRfY2hpbGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALlxKVi5cSlYZj
BD_HOME: 1
H_PS_PSSID: 1423_21080_17001_21454_21408_21530_21377_21525_21193_21340
BD_UPN: 123253
sug: 3
sugstore: 0
ORIGIN: 0
bdime: 0
能夠看見是key, value的形式，也就是咱們說的對應着的名字，值。過時時間是能夠設置的，若是不設置，則瀏覽器關掉就消失了，是存儲在內存當中的，不然就是按照咱們設置的時間來存儲在硬盤上的，當過時後自動清除，比方說咱們開機關機關閉再打開瀏覽器後他都會還存在，前者稱之爲Session cookie 又叫 transient cookie，後者稱之爲Persistent cookie 又叫 permenent cookie。路徑和域就是對應的域名，a網站的cookie天然不能給b用。

Session

Session是存在服務器的一種用來存放用戶數據的類HashTable結構。

當瀏覽器第一次發送請求時，服務器自動生成了一個HashTable和一個Session ID用來惟一標識這個HashTable，並將其經過響應發送到瀏覽器。當瀏覽器第二次發送請求，會將前一次服務器響應中的Session ID放在請求中一併發送到服務器上，服務器從請求中提取出Session ID，並和保存的全部Session ID進行對比，找到這個用戶對應的HashTable。

摘自http://caibaojian.com/477.html

通常這個值會有一個時間限制，超時後毀掉這個值，默認是20分鐘。

Session的實現方式和Cookie有必定關係。試想一下，創建一個鏈接就生成一個session id，那麼打開幾個頁面就好幾個了，這顯然不是咱們想要的，那麼該怎麼區分呢？這裏就用到了Cookie，咱們能夠把session id存在Cookie中，而後每次訪問的時候將Session id帶過去就能夠識別了，是否是很方便~

摘自:http://www.javashuo.com/article/p-guovnaad-y.html

(3).Session 與 Cookie 的對比

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

大小限制：Cookie有大小限制而且瀏覽器對每一個站點也有cookie的個數限制，Session沒有大小限制，理論上只與服務器的內存大小有關；

安全性：Cookie存在安全隱患，經過攔截或本地文件找獲得cookie後能夠進行攻擊，而Session因爲保存在服務器端，相對更加安全；

服務器資源消耗：Session是保存在服務器端上會存在一段時間纔會消失，若是session過多會增長服務器的壓力。

存放位置：cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

在瀏覽器中輸入www.baidu.com後執行的所有過程

客戶端瀏覽器經過DNS解析到www.baidu.com的IP地址220.181.27.48，經過這個IP地址找到客戶端到服務器的路徑。客戶端瀏覽器發起一個HTTP會話到220.161.27.48，而後經過TCP進行封裝數據包，輸入到網絡層。

在客戶端的傳輸層，把HTTP會話請求分紅報文段，添加源和目的端口，如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口。而後使用IP層的IP地址查找目的端。

客戶端的網絡層不用關係應用層或者傳輸層的東西，主要作的是經過查找路由表肯定如何到達服務器，期間可能通過多個路由器，這些都是由路由器來完成的工做，我不做過多的描述，無非就是經過查找路由表決定經過那個路徑到達服務器。

客戶端的鏈路層，包經過鏈路層發送到路由器，經過鄰居協議查找給定IP地址的MAC地址，而後發送ARP請求查找目的地址，若是獲得迴應後就可使用ARP的請求應答交換的IP數據包如今就能夠傳輸了，而後發送IP數據包到達服務器的地址。

瞭解交換機、路由器、網關的概念，並知道各自的用途

物理層使用的中間設備叫作轉發器。
數據鏈路層使用的中間設備叫作網橋或橋接器。
網絡層使用的中間設備叫作路由器。
在網絡層以上使用的中間設備叫作網關。

牛客網因爲訪問客戶量的增加,原來的服務器不足以維持請求,常常發生宕機的突發狀況,所以爲了解決這個問題,CEO決定新增長几臺服務器,那麼問題是這些接入WEB服務器第一次被訪問到時，不一樣協議的發生順序是下面中的（ARP -> DNS -> HTTP）。

當你給WEB服務器接上網線的時候，它會自動發送一條ARP信息，使得接入網關能找的到它；網關上會造成一條MAC地址到IP地址的映射記錄。如用戶在瀏覽器中輸入域名，如本地DNS緩存中沒有，必然會進行一次DNS查詢，以肯定該域名的IP地址。得到DNS對應的IP地址之後，使用HTTP協議訪問web服務器（不考慮TCP三次握手創建鏈接的階段）。

參考文章：

《計算機網絡(第七版)》謝希仁

維基百科

面試/筆試第一彈 —— 計算機網絡面試問題集錦