計網基礎知識

1. 網絡層次劃分

  除了標準的OSI七層模型之外,常見的網絡層次劃分還有TCP/IP四層協議以及TCP/IP五層協議,它們之間的對應關係以下圖所示:程序員

img

2. OSI七層網絡模型

  TCP/IP協議毫無疑問是互聯網的基礎協議,沒有它就根本不可能上網,任何和互聯網有關的操做都離不開TCP/IP協議。無論是OSI七層模型仍是TCP/IP的四層、五層模型,每一層中都要本身的專屬協議,完成本身相應的工做以及與上下層級之間進行溝通。因爲OSI七層模型爲網絡的標準層次劃分,因此咱們以OSI七層模型爲例從下向上進行一一介紹。面試

img 

1)物理層(Physical Layer)

  激活、維持、關閉通訊端點之間的機械特性、電氣特性、功能特性以及過程特性。該層爲上層協議提供了一個傳輸數據的可靠的物理媒體。簡單的說,物理層確保原始的數據可在各類物理媒體上傳輸。物理層記住兩個重要的設備名稱,中繼器(Repeater,也叫放大器)集線器redis

在物理層上所傳送的數據單位是比特算法

物理層(physical layer)的做用是實現相鄰計算機節點之間比特流的透明傳送,儘量屏蔽掉具體傳輸介質和物理設備的差別, 使其上面的數據鏈路層沒必要考慮網絡的具體傳輸介質是什麼「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化,對傳送的比特流來講,這個電路好像是看不見的。數據庫

數據鏈路層(data link layer)一般簡稱爲鏈路層。兩臺主機之間的數據傳輸,老是在一段一段的鏈路上傳送的,這就須要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送數據時,數據鏈路層將網絡層交下來的 IP 數據報組裝成幀,物理層傳上來的比特數據也會被組裝成幀,在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息(如同步信息,地址信息,差錯控制等)編程

接收數據時,控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。這樣,數據鏈路層在收到一個幀後,就可從中提取出數據部分上交給網絡層控制信息還使接收端可以檢測到所收到的幀中有無差錯。若是發現差錯,數據鏈路層就簡單地 丟棄 這個出了差錯的幀,以避免繼續在網絡中傳送下去白白浪費網絡資源。若是須要改正數據在鏈路層傳輸時出現差錯(這就是說,數據鏈路層不只要檢錯,並且還要糾錯),那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。瀏覽器

  數據鏈路層物理層提供的服務的基礎上向網絡層提供服務,其最基本的服務是將源自網絡層來的數據可靠地傳輸到相鄰節點的目標機網絡層。爲達到這一目的,數據鏈路必須具有一系列相應的功能,主要有:如何將數據組合成數據塊,在數據鏈路層中稱這種數據塊爲幀(frame),幀是數據鏈路層的傳送單位;如何控制幀在物理信道上的傳輸,包括如何處理傳輸差錯,如何調節發送速率以使與接收方相匹配;以及在兩個網絡實體之間提供數據鏈路通路的創建維持和釋放的管理。數據鏈路層在不可靠的物理介質上提供可靠的傳輸。該層的做用包括:物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。緩存

  有關數據鏈路層的重要知識點:安全

  1> 數據鏈路層爲網絡層提供可靠的數據傳輸;服務器

  2> 基本數據單位爲幀;

  3> 主要的協議:以太網協議;

  4> 兩個重要設備名稱:網橋和交換機。

3)網絡層(Network Layer)

​ 在 計算機網絡中進行通訊的兩個計算機之間可能會通過不少個數據鏈路,也可能還要通過不少通訊子網。網絡層的任務就是選擇合適的網間路由和交換結點, 確保數據及時傳送。 在發送數據時,網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP/IP 體系結構中,因爲網絡層使用 IP 協議,所以分組也叫 IP 數據報 ,簡稱 數據報

這裏要注意:不要把運輸層的「用戶數據報 UDP 」和網絡層的「 IP 數據報」弄混。另外,不管是哪一層的數據單元,均可籠統地用「分組」來表示。

這裏強調指出,網絡層中的「網絡」二字已經不是咱們一般談到的具體網絡,而是指計算機網絡體系結構模型中第三層的名稱.

互聯網是由大量的異構(heterogeneous)網絡經過路由器(router)相互鏈接起來的。互聯網使用的網絡層協議無鏈接的網際協議(Internet Protocol)和許多路由選擇協議,所以互聯網的網絡層也叫作網際層IP層

  網絡層的目的是實現兩個端系統之間的數據透明傳送,具體功能包括尋址和路由選擇鏈接的創建保持和終止等。它提供的服務使傳輸層不須要了解網絡中的數據傳輸和交換技術。若是您想用盡可能少的詞來記住網絡層,那就是「路徑選擇、路由及邏輯尋址」。

  網絡層中涉及衆多的協議,其中包括最重要的協議,也是TCP/IP的核心協議——IP協議。IP協議很是簡單,僅僅提供不可靠、無鏈接的傳送服務

IP協議的主要功能有:不可靠、無鏈接數據報傳輸數據報路由選擇和差錯控制。與IP協議配套使用實現其功能的還有地址解析協議ARP逆地址解析協議RARP因特網報文協議ICMP因特網組管理協議IGMP。具體的協議咱們會在接下來的部分進行總結

有關網絡層的重點爲:

  1> 網絡層負責對子網間的數據包進行路由選擇。此外,網絡層還能夠實現擁塞控制、網際互連等功能;

  2> 基本數據單位爲 IP數據報;

  3> 包含的主要協議:

  IP協議(Internet Protocol,因特網互聯協議);

  ICMP協議(Internet Control Message Protocol,因特網控制報文協議);

  ARP協議(Address Resolution Protocol,地址解析協議); ** 根據IP地址獲取MAC物理地址**的一個TCP/IP協議

  RARP協議(Reverse Address Resolution Protocol,逆地址解析協議)。

  4> 重要的設備:路由器。

IP和MAC區別:

局域網數據傳輸須要依靠MAC來識別對方地址。發生數據的時候,數據發送端計算機容首先拿接收端的計算機IP與本身主機子網掩碼相匹配,匹配後,發現跟本身是同一網段的,則使用MAC地址去尋找對方,若是不是同一網段的,則封裝上對方的IP地址爲目標地址,發現網關,由網關發現其餘網絡,不過到達了目標網絡後,仍是要根據對方MAC地址來尋找目標主機
簡單的說,局域網內傳輸用MAC網間傳輸就要在MAC外面再加一層IP

4)傳輸層(Transport Layer)

運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務應用進程利用該服務傳送應用層報文「通用的」是指並不針對某一個特定的網絡應用,而是多種應用可使用同一個傳輸層服務。因爲一臺主機可同時運行多個線程,所以運輸層有複用和分用的功能。所謂複用就是指多個應用層進程可同時使用下面傳輸層的服務分用和複用相反,是傳輸層把收到的信息分別交付上面應用層中的相應進程

運輸層主要使用如下兩種協議:

  1. 傳輸控制協議 TCP(Transmission Control Protocol)--提供面向鏈接的,可靠的數據傳輸服務。
  2. 用戶數據協議 UDP(User Datagram Protocol)--提供無鏈接的,盡最大努力的數據傳輸服務(不保證數據傳輸的可靠性)。

  第一個端到端,即主機到主機的層次。傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸。此外,傳輸層還要處理端到端的差錯控制流量控制問題

  傳輸層的任務是根據通訊子網的特性,最佳的利用網絡資源,爲兩個端系統的會話層之間,提供創建、維護和取消傳輸鏈接的功能,負責端到端的可靠數據傳輸。在這一層,信息傳送的協議數據單元稱爲段或報文

  網絡層只是根據網絡地址源結點發出的數據包傳送到目的結點,而傳輸層則負責將數據可靠地傳送到相應的端口

  有關網絡層的重點:

  1> 傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸以及端到端的差錯控制和流量控制問題;

  2> 包含的主要協議:TCP協議(Transmission Control Protocol,傳輸控制協議)、UDP協議(User Datagram Protocol,用戶數據報協議);

  3> 重要設備:網關。

4> 數據單元:段或報文

5)會話層

  會話層管理主機之間的會話進程,即負責創建、管理、終止進程之間的會話。會話層還利用在數據中插入校驗點來實現數據同步和數據校驗

6)表示層

  表示層對上層數據或信息進行變換以保證一個主機應用層信息能夠被另外一個主機的應用程序理解。表示層的數據轉換包括數據的加密、壓縮、格式轉換等。

7)應用層

應用層(application-layer)的任務是經過應用進程間的交互完成特定網絡應用。應用層協議定義的是應用進程(進程:主機中正在運行的程序)間的通訊和交互的規則。對於不一樣的網絡應用須要不一樣的應用層協議。在互聯網中應用層協議不少,如域名系統DNS,支持萬維網應用HTTP協議,支持電子郵件SMTP協議等等。

應用層交互的數據單元稱爲報文

域名系統

域名系統(Domain Name System縮寫 DNS,Domain Name被譯爲域名)是因特網的一項核心服務,它做爲能夠將域名和IP地址相互映射的一個分佈式數據庫,可以令人更方便的訪問互聯網,而不用去記住可以被機器直接讀取的IP數串

HTTP協議

超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。全部的 WWW(萬維網) 文件都必須遵照這個標準。設計 HTTP 最初的目的是爲了提供一種發佈和接收 HTML 頁面的方法。

應用層爲操做系統或網絡應用程序提供訪問網絡服務的接口

會話層、表示層和應用層重點:

  1> 數據傳輸基本單位爲報文

  2> 包含的主要協議:FTP(文件傳送協議)、Telnet(遠程登陸協議)、DNS(域名解析協議)、SMTP(郵件傳送協議),POP3協議(郵局協議),HTTP協議(Hyper Text Transfer Protocol)。

七層體系結構圖

3. IP地址

  1)網絡地址

  IP地址由網絡號(包括子網號)和主機號組成,網絡地址的主機號爲全0,網絡地址表明着整個網絡

  2)廣播地址

  廣播地址一般稱爲直接廣播地址,是爲了區分受限廣播地址。

  廣播地址與網絡地址的主機號正好相反,廣播地址中,主機號爲全1。當向某個網絡的廣播地址發送消息時,該網絡內的全部主機都能收到該廣播消息。

  3)組播地址

  D類地址就是組播地址。

  先回憶下A,B,C,D類地址吧:

  A類地址以0開頭,第一個字節做爲網絡號,地址範圍爲:0.0.0.0~127.255.255.255;(modified @2016.05.31)

  B類地址以10開頭,前兩個字節做爲網絡號,地址範圍是:128.0.0.0~191.255.255.255;

  C類地址以110開頭,前三個字節做爲網絡號,地址範圍是:192.0.0.0~223.255.255.255。

  D類地址以1110開頭,地址範圍是224.0.0.0~239.255.255.255,D類地址做爲組播地址(一對多的通訊);

  E類地址以1111開頭,地址範圍是240.0.0.0~255.255.255.255,E類地址爲保留地址,供之後使用。

  注:只有A,B,C有網絡號和主機號之分,D類地址和E類地址沒有劃分網絡號和主機號。

  4)255.255.255.255

  該IP地址指的是受限的廣播地址。受限廣播地址與通常廣播地址(直接廣播地址)的區別在於,受限廣播地址只能用於本地網絡,路由器不會轉發以受限廣播地址爲目的地址的分組;通常廣播地址既可在本地廣播,也可跨網段廣播。例如:主機192.168.1.1/30上的直接廣播數據包後,另一個網段192.168.1.5/30也能收到該數據報;若發送受限廣播數據報,則不能收到。

  注:通常的廣播地址(直接廣播地址)可以經過某些路由器(固然不是全部的路由器),而受限的廣播地址不能經過路由器。

  5)0.0.0.0

  經常使用於尋找本身的IP地址,例如在咱們的RARP,BOOTP和DHCP協議中,若某個未知IP地址的無盤機想要知道本身的IP地址,它就以255.255.255.255爲目的地址,向本地範圍(具體而言是被各個路由器屏蔽的範圍內)的服務器發送IP請求分組。

  6)迴環地址

  127.0.0.0/8被用做迴環地址,迴環地址表示本機的地址,經常使用於對本機的測試,用的最多的是127.0.0.1。

  7)A、B、C類私有地址

  私有地址(private address)也叫專用地址,它們不會在全球使用,只具備本地意義。

  A類私有地址:10.0.0.0/8,範圍是:10.0.0.0~10.255.255.255

  B類私有地址:172.16.0.0/12,範圍是:172.16.0.0~172.31.255.255

  C類私有地址:192.168.0.0/16,範圍是:192.168.0.0~192.168.255.255

4. 子網掩碼及網絡劃分

  隨着互連網應用的不斷擴大,原先的IPv4的弊端也逐漸暴露出來,即網絡號佔位太多,而主機號位太少,因此其能提供的主機地址也愈來愈稀缺,目前除了使用NAT在企業內部利用保留地址自行分配之外,一般都對一個高類別的IP地址進行再劃分,以造成多個子網,提供給不一樣規模的用戶羣使用。

  這裏主要是爲了在網絡分段狀況下有效地利用IP地址,經過對主機號的高位部分取做爲子網號,從一般的網絡位界限中擴展或壓縮子網掩碼,用來建立某類地址的更多子網。但建立更多的子網時,在每一個子網上的可用主機地址數目會比原先減小。

  什麼是子網掩碼?

  子網掩碼是標誌兩個IP地址是否同屬於一個子網的,也是32位二進制地址,其每個爲1表明該位是網絡位,爲0表明主機位。它和IP地址同樣也是使用點式十進制來表示的。若是兩個IP地址在子網掩碼的按位與的計算下所得結果相同,即代表它們共屬於同一子網中。

  在計算子網掩碼時,咱們要注意IP地址中的保留地址,即「 0」地址和廣播地址,它們是指主機地址或網絡地址全爲「 0」或「 1」時的IP地址,它們表明着本網絡地址和廣播地址,通常是不能被計算在內的。

  子網掩碼的計算:

  對於無須再劃分紅子網的IP地址來講,其子網掩碼很是簡單,即按照其定義便可寫出:如某B類IP地址爲 10.12.3.0,無須再分割子網,則該IP地址的子網掩碼255.255.0.0。若是它是一個C類地址,則其子網掩碼爲 255.255.255.0。其它類推,再也不詳述。下面咱們關鍵要介紹的是一個IP地址,還須要將其高位主機位再做爲劃分出的子網網絡號,剩下的是每一個子網的主機號,這時該如何進行每一個子網的掩碼計算。

  下面總結一下有關子網掩碼和網絡劃分常見的面試考題:

  1)利用子網數來計算

  在求子網掩碼以前必須先搞清楚要劃分的子網數目,以及每一個子網內的所需主機數目。

  (1) 將子網數目轉化爲二進制來表示;

  如欲將B類IP地址168.195.0.0劃分紅27個子網:27=11011;

  (2) 取得該二進制的位數,爲N;

  該二進制爲五位數,N = 5

  (3) 取得該IP地址的類子網掩碼,將其主機地址部分的的前N位置1即得出該IP地址劃分子網的子網掩碼。

  將B類地址的子網掩碼255.255.0.0的主機地址前5位置 1,獲得 255.255.248.0

  2)利用主機數來計算

  如欲將B類IP地址168.195.0.0劃分紅若干子網,每一個子網內有主機700臺:

  (1) 將主機數目轉化爲二進制來表示;

  700=1010111100;

  (2) 若是主機數小於或等於254(注意去掉保留的兩個IP地址),則取得該主機的二進制位數,爲N,這裏確定 N<8。若是大於254,則 N>8,這就是說主機地址將佔據不止8位;

  該二進制爲十位數,N=10;

  (3) 使用255.255.255.255來將該類IP地址的主機地址位數所有置1,而後從後向前的將N位所有置爲 0,即爲子網掩碼值。

  將該B類地址的子網掩碼255.255.0.0的主機地址所有置1,獲得255.255.255.255,而後再從後向前將後 10位置0,即爲:11111111.11111111.11111100.00000000,即255.255.252.0。這就是該欲劃分紅主機爲700臺的B類IP地址 168.195.0.0的子網掩碼。

  3)還有一種題型,要你根據每一個網絡的主機數量進行子網地址的規劃和****計算子網掩碼。這也可按上述原則進行計算。

  好比一個子網有10臺主機,那麼對於這個子網須要的IP地址是:

  10+1+1+1=13

  注意:加的第一個1是指這個網絡鏈接時所需的網關地址,接着的兩個1分別是指網****絡地址和廣播地址。

  由於13小於16(16等於2的4次方),因此主機位爲4位。而256-16=240,因此該子網掩碼爲255.255.255.240。

  若是一個子網有14臺主機,很多人常犯的錯誤是:依然分配具備16個地址空間的子網,而忘記了給網關分配地址。這樣就錯誤了,由於14+1+1+1=17,17大於16,因此咱們只能分配具備32個地址(32等於2的5次方)空間的子網。這時子網掩碼爲:255.255.255.224。

5. ARP/RARP協議

  地址解析協議,即ARP(Address Resolution Protocol),是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的全部主機,並接收返回消息,以此肯定目標的物理地址;收到返回消息後將該IP地址和物理地址存入本機ARP緩存中並保留必定時間,下次請求時直接查詢ARP緩存以節約資源。地址解析協議是創建在網絡中各個主機互相信任的基礎上的,網絡上的主機能夠自主發送ARP應答消息,其餘主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存;由此攻擊者就能夠向某一主機發送僞ARP應答報文,使其發送的信息沒法到達預期的主機或到達錯誤的主機,這就構成了一個ARP欺騙。ARP命令可用於查詢本機ARP緩存中IP地址和MAC地址的對應關係、添加或刪除靜態對應關係等。

  ARP工做流程舉例:

  主機A的IP地址爲192.168.1.1,MAC地址爲0A-11-22-33-44-01;

  主機B的IP地址爲192.168.1.2,MAC地址爲0A-11-22-33-44-02;

  當主機A要與主機B通訊時,地址解析協議能夠將主機B的IP地址(192.168.1.2)解析成主機B的MAC地址,如下爲工做流程:

  (1)根據主機A上的路由表內容,IP肯定用於訪問主機B的轉發IP地址是192.168.1.2。而後A主機在本身的本地ARP緩存中檢查主機B的匹配MAC地址。

  (2)若是主機A在ARP緩存中沒有找到映射,它將詢問192.168.1.2的硬件地址,從而將ARP請求幀廣播到本地網絡上的全部主機。源主機A的IP地址和MAC地址都包括在ARP請求中。本地網絡上的每臺主機都接收到ARP請求而且檢查是否與本身的IP地址匹配。若是主機發現請求的IP地址與本身的IP地址不匹配,它將丟棄ARP請求。

  (3)主機B肯定ARP請求中的IP地址與本身的IP地址匹配,則將主機A的IP地址和MAC地址映射添加到本地ARP緩存中。

  (4)主機B將包含其MAC地址的ARP回覆消息直接發送回主機A。

  (5)當主機A收到從主機B發來的ARP回覆消息時,會用主機B的IP和MAC地址映射更新ARP緩存。本機緩存是有生存期的,生存期結束後,將再次重複上面的過程。主機B的MAC地址一旦肯定,主機A就能向主機B發送IP通訊了。

  逆地址解析協議,即RARP,功能和ARP協議相對,其將局域網中某個主機的物理地址轉換爲IP地址,好比局域網中有一臺主機只知道物理地址而不知道IP地址,那麼能夠經過RARP協議發出徵求自身IP地址的廣播請求,而後由RARP服務器負責回答。

  RARP協議工做流程:

  (1)給主機發送一個本地的RARP廣播,在此廣播包中,聲明本身的MAC地址而且請求任何收到此請求的RARP服務器分配一個IP地址;

  (2)本地網段上的RARP服務器收到此請求後,檢查其RARP列表,查找該MAC地址對應的IP地址;

  (3)若是存在,RARP服務器就給源主機發送一個響應數據包並將此IP地址提供給對方主機使用;

  (4)若是不存在,RARP服務器對此不作任何的響應;

  (5)源主機收到從RARP服務器的響應信息,就利用獲得的IP地址進行通信;若是一直沒有收到RARP服務器的響應信息,表示初始化失敗。

6. 路由選擇協議

  常見的路由選擇協議有:RIP協議、OSPF協議。

  RIP協議 :底層是貝爾曼福特算法,它選擇路由的度量標準(metric)是跳數,最大跳數是15跳,若是大於15跳,它就會丟棄數據包

  OSPF協議 :Open Shortest Path First開放式最短路徑優先,底層是迪傑斯特拉算法,是鏈路狀態路由選擇協議,它選擇路由的度量標準是帶寬,延遲

7. TCP/IP協議

  TCP/IP協議是Internet最基本的協議、Internet國際互聯網絡的基礎,由網絡層的IP協議傳輸層的TCP協議組成。通俗而言:TCP負責發現傳輸的問題,一有問題就發出信號,要求從新傳輸,直到全部數據安全正確地傳輸到目的地。而 IP 是給因特網的每一臺聯網設備規定一個地址

  IP層接收由更低層網絡接口層例如以太網設備驅動程序)發來的數據包,並把該數據包發送到更高層---TCP或UDP層;相反,IP層也把從TCP或UDP層接收來的數據包傳送到更低層IP數據包是不可靠的,由於IP並沒有作任何事情來確認數據包是否按順序發送的或者有沒有被破壞,IP數據包中含有發送它的主機的地址(源地址)接收它的主機的地址(目的地址)

 TCP是面向鏈接的通訊協議,經過三次握手創建鏈接,通信完成時要拆除鏈接,因爲TCP是面向鏈接的因此只能用於端到端的通信

​ TCP提供的是一種可靠的數據流服務,採用「帶重傳的確定確認」技術來實現傳輸的可靠性。TCP還採用一種稱爲「滑動窗口」的方式進行流量控制,所謂窗口實際表示接收能力,用以限制發送方的發送速度

  TCP報文首部格式:

img

  TCP協議的三次握手和四次揮手:

img

  注:seq:"sequance"序列號;ack:"acknowledge"確認號;SYN:"synchronize"請求同步標誌;ACK:"acknowledge"確認標誌"FIN:"Finally"結束標誌。

TCP鏈接創建過程:

首先Client端發送鏈接請求報文,Server段接受鏈接後回覆ACK報文,併爲此次鏈接分配資源 (syn+ack)。Client端接收到ACK報文後也向Server段發送ACK報文,並分配資源 (ack),這樣TCP鏈接就創建了。

TCP鏈接斷開過程:

假設Client端發起中斷鏈接請求,也就是發送FIN報文。Server端接到FIN報文後,意思是說"我Client端沒有數據要發給你了",可是若是Server還有數據沒有發送完成,則沒必要急着關閉Socket,能夠繼續發送數據。因此Server端先發送ACK,"告訴Client端,你的請求我收到了,可是我還沒準備好,請繼續等個人消息"。這個時候Client端就進入FIN_WAIT狀態,繼續等待Server端的FIN報文。

​ 當Server端肯定數據已發送完成,則向Client端發送FIN報文,"告訴Client端,好了,我這邊數據發完了,準備好關閉鏈接了"。Client端收到FIN報文後,"就知道能夠關閉鏈接了,可是他仍是不相信網絡怕Server端不知道要關閉,因此發送ACK後進入TIME_WAIT狀態,若是Server端沒有收到ACK則能夠重傳。「,Server端收到ACK後,"就知道能夠斷開鏈接了"。Client端等待了2MSL後依然沒有收到回覆,則證實Server端已正常關閉,那好,我Client端也能夠關閉鏈接了。Ok,TCP鏈接就這樣關閉了!

爲何要三次揮手?

三次握手的目的是創建可靠的通訊信道,說到通信,簡單來講就是數據的發送與接收,而三次握手最主要的目的就是雙方確認本身與對方的發送與接收是正常的。

第一次握手:Client 什麼都不能確認;Server 確認了對方發送正常,本身接收正常

第二次握手:Client 確認了:本身發送、接收正常,對方發送、接收正常;Server 確認了:對方發送正常,本身接收正常

第三次握手:Client 確認了:本身發送、接收正常,對方發送、接收正常;Server 確認了:本身發送、接收正常,對方發送、接收正常

因此三次握手就能確認雙發收發功能都正常,缺一不可

爲何要四次揮手?

任何一方均可以在數據傳送結束後發出鏈接釋放的通知,待對方確認後進入半關閉狀態。當另外一方也沒有數據再發送的時候,則發出鏈接釋放通知,對方確認後就徹底關閉了TCP鏈接

  • 客戶端-發送一個 FIN,用來關閉客戶端到服務器的數據傳送
  • 服務器-收到這個 FIN,它發回一 個 ACK,確認序號爲收到的序號加1 。和 SYN 同樣,一個 FIN 將佔用一個序號
  • 服務器-關閉與客戶端的鏈接,發送一個FIN給客戶端
  • 客戶端-發回 ACK 報文確認,並將確認序號設置爲收到序號加1

斷開一個 TCP 鏈接則須要「四次揮手」:

  試想一下,假如如今你是客戶端你想斷開跟Server的全部鏈接該怎麼作?第一步,你本身先中止向Server端發送數據,並等待Server的回覆。但事情尚未完,雖然你自身不往Server發送數據了,可是由於大家以前已經創建好平等的鏈接了,因此此時他也有主動權向你發送數據;故Server端還得終止主動向你發送數據,並等待你的確認。其實,說白了就是保證雙方的一個合約的完整執行

  使用TCP的協議:FTP文件傳輸協議)、Telnet遠程登陸協議)、SMTP簡單郵件傳輸協議)、POP3(和SMTP相對,用於接收郵件)、HTTP協議等。

8. UDP協議

  UDP用戶數據報協議,是面向無鏈接的通信協議,UDP數據包括目的端口號源端口號信息,因爲通信不須要鏈接,因此能夠實現廣播發送UDP通信時不須要接收方確認,屬於不可靠的傳輸,可能會出現丟包現象,實際應用中要求程序員編程驗證

  UDP與TCP位於同一層(傳輸層),但它無論數據包的順序、錯誤或重發。所以,UDP不被應用於那些使用虛電路的面向鏈接的服務,UDP主要用於那些面向查詢---應答的服務,例如NFS。相對於FTP或Telnet,這些服務須要交換的信息量較小

  每一個UDP報文UDP報頭和UDP數據區兩部分。報頭由四個16位長(2字節)字段組成,分別說明該報文的源端口、目的端口、報文長度以及校驗值UDP報頭4個域組成,其中每一個域各佔用2個字節,具體以下:
  源端口號目標端口號數據報長度校驗值

  使用UDP協議包括:TFTP簡單文件傳輸協議)、SNMP簡單網絡管理協議)、DNS域名解析協議)、NFSBOOTP

TCP UDP 的區別:

image-20201205165706103

TCP是面向鏈接的,可靠的字節流服務;UDP是面向無鏈接的,不可靠的數據報服務

UDP 在傳送數據以前不須要先創建鏈接,遠地主機在收到 UDP 報文後,不須要給出任何確認。雖然 UDP 不提供可靠交付,但在某些狀況下 UDP 確是一種最有效的工做方式(通常用於即時通訊),好比: QQ 語音、 QQ 視頻 、直播等等

TCP 提供面向鏈接的服務。在傳送數據以前必須先創建鏈接,數據傳送結束後要釋放鏈接。 TCP 不提供廣播或多播服務。因爲 TCP 要提供可靠的,面向鏈接的傳輸服務(TCP的可靠體如今TCP在傳遞數據以前,會有三次握手來創建鏈接,並且在數據傳遞時,有確認、窗口、重傳、擁塞控制機制,在數據傳完後,還會四次握手來斷開鏈接用來節約系統資源),這一難以免增長了許多開銷,如確認,流量控制,計時器以及鏈接管理等。這不只使協議數據單元的首部增大不少 (20-60字節),還要佔用許多處理機資源。TCP 通常用於文件傳輸、發送和接收郵件、遠程登陸等場景。

運行於TCP協議之上的協議:

HTTP協議:超文本傳輸協議,用於普通瀏覽

HTTPS協議:安全超文本傳輸協議,身披SSL外衣的HTTP協議

FTP協議:文件傳輸協議,用於文件傳輸

POP3協議:郵局協議,收郵件使用

SMTP協議:簡單郵件傳輸協議,用來發送電子郵件

Telent協議:遠程登錄協議,經過一個終端登錄到網絡

SSH協議:安全外殼協議,用於加密安全登錄,替代安全性差的Telent協議

運行於UDP協議之上的協議:TFTP簡單文件傳輸協議)、SNMP簡單網絡管理協議)、DNS域名解析協議)、NFS

DHCP協議:動態主機配置協議,動態配置IP地址

NTP協議:網絡時間協議,用於網絡時間同步

BOOTP協議:引導程序協議,DHCP協議的前身,用於無盤工做站從中心服務器上獲取IP地址

9. DNS協議

  DNS域名系統(DomainNameSystem)的縮寫,該系統用於命名組織到域層次結構中的計算機和網絡服務,能夠簡單地理解爲將URL轉換爲IP地址。域名是由圓點分開一串單詞或縮寫組成的,每個域名都對應一個惟一的IP地址,在Internet上域名與IP地址之間是一一對應的,DNS就是進行域名解析的服務器。DNS命名用於Internet等TCP/IP網絡中,經過用戶友好的名稱查找計算機和服務

10. NAT協議

  NAT網絡地址轉換(Network Address Translation)屬接入廣域網(WAN)技術,是一種將私有(保留)地址轉化爲合法IP地址的轉換技術,它被普遍應用於各類類型Internet接入方式和各類類型的網絡中。緣由很簡單,NAT不只完美地解決了lP地址不足的問題,並且還可以有效地避免來自網絡外部的攻擊隱藏並保護網絡內部的計算機

11. DHCP協議

  DHCP動態主機設置協議(Dynamic Host Configuration Protocol)是一個局域網的網絡協議,使用UDP協議工做,主要有兩個用途:給內部網絡或網絡服務供應商自動分配IP地址,給用戶或者內部網絡管理員做爲對全部計算機做中央管理的手段。

12. HTTP協議

  超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。

  HTTP 協議包括哪些請求?

  GET:請求讀取由URL所標誌的信息。

  POST:給服務器添加信息(如註釋)。

  PUT:在給定的URL下存儲一個文檔。

  DELETE:刪除給定的URL所標誌的資源。

  HTTP 中, POST GET 的區別

  1)Get是從服務器上獲取數據(pull拉),Post是向服務器傳送數據(push推)

  2)Get是把參數數據隊列加到提交表單的Action屬性所指向的URL中,值和表單內各個字段一一對應,在URL中能夠看到

  3)Get傳送的數據量小不能大於2KB;Post傳送的數據量較大,通常被默認爲不受限制

  4)根據HTTP規範,GET用於信息獲取,並且應該是安全的和冪等的。

  I. 所謂 安全的 意味着該操做用於獲取信息而非修改信息。換句話說,GET請求通常不該產生反作用。就是說,它僅僅是獲取資源信息,就像數據庫查詢同樣,不會修改,增長數據,不會影響資源的狀態

  II. 冪等 的意味着對同一URL的多個請求應該返回一樣的結果

13. 一個舉例

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

  如今假設若是咱們在客戶端(客戶端)瀏覽器中輸入http://www.baidu.com, 而baidu.com爲要訪問的服務器(服務器),下面詳細分析客戶端爲了訪問服務器而執行的一系列關於協議的操做:

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

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

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

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

各層協議數據單元(PDU)

應用層的數據叫消息,傳輸層的數據叫段、網絡層叫包/分組/報文、數據鏈路層叫幀、物理層叫比特流

數據幀(Frame):是一種信息單位,它的起始點和目的點都是數據鏈路層
數據包(Packet):也是一種信息單位,它的起始和目的地是網絡層
數據報(Datagram):一般是指起始點和目的地都使用無鏈接網絡服務的網絡層的信息單元。
(Segment):一般是指起始點和目的地都是傳輸層的信息單元。
消息(message):是指起始點和目的地都在網絡層以上(常常在應用層)的信息單元。

簡單郵件傳輸協議(SMTP)

SMTP(Simple Mail Transfer Protocol)即簡單郵件傳輸協議,它是一組用於由源地址到目的地址傳送郵件的規則,由它來控制信件的中轉方式。 SMTP 協議屬於 TCP/IP 協議簇,它幫助每臺計算機在發送或中轉信件時找到下一個目的地。 經過 SMTP 協議所指定的服務器, 就能夠把 E-mail 寄到收信人的服務器上了,整個過程只要幾分鐘。SMTP 服務器則是遵循 SMTP 協議的發送郵件服務器,用來發送或中轉發出的電子郵件

TCP 協議如何保證可靠傳輸

  1. 應用數據被分割成 TCP 認爲最適合發送的數據塊
  2. TCP 給發送的每個包進行編號,接收方對數據包進行排序,把有序數據傳送給應用層
  3. 校驗和: TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和,目的是檢測數據在傳輸過程當中的任何變化。若是收到段的檢驗和有差錯,TCP 將丟棄這個報文段,不確認收到此報文段
  4. TCP 的接收端會丟棄重複的數據
  5. 流量控制: TCP 鏈接的每一方都有固定大小的緩衝空間,TCP的接收端只容許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理發送方的數據,能提示發送方下降發送的速率防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 (TCP 利用滑動窗口實現流量控制
  6. 擁塞控制: 當網絡擁塞時,減小數據的發送
  7. ARQ協議自動重傳請求,它的基本原理就是每發完一個分組就中止發送等待對方確認。在收到確認後再發下一個分組
  8. 超時重傳: 當 TCP 發出一個段後,它啓動一個定時器等待目的端確認收到這個報文段。若是不能及時收到一個確認,將重發這個報文段

ARQ協議

自動重傳請求(Automatic Repeat-reQuest,ARQ)是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它經過使用確認超時這兩個機制,在不可靠服務的基礎實現可靠的信息傳輸。若是發送方在發送後一段時間以內沒有收到確認幀,它一般會從新發送。ARQ包括中止等待ARQ協議連續ARQ協議

(1)中止等待ARQ協議

  • 中止等待協議是爲了實現可靠傳輸的,它的基本原理就是每發完一個分組就中止發送等待對方確認(回覆ACK)。若是過了一段時間(超時時間後),仍是沒有收到 ACK 確認,說明沒有發送成功,須要從新發送直到收到確認後再發下一個分組
  • 在中止等待協議中,若接收方收到重複分組,就丟棄該分組,但同時還要發送確認

優勢: 簡單

缺點: 信道利用率低,等待時間長

1) 無差錯狀況:

發送方發送分組,接收方在規定時間內收到, 而且回覆確認.發送方再次發送

2) 出現差錯狀況(超時重傳):

中止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認,就重傳前面發送過的分組(認爲剛纔發送過的分組丟失了)。所以每發送完一個分組須要設置一個超時計時器,其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱爲 自動重傳請求 ARQ

另外在中止等待協議中若收到重複分組,就丟棄該分組,但同時還要發送確認

3) 確認丟失和確認遲到

  • 確認丟失 :確認消息在傳輸過程丟失。當A發送M1消息,B收到後,B向A發送了一個M1確認消息,但卻在傳輸過程當中丟失。而A並不知道,在超時計時事後,A重傳M1消息,B再次收到該消息後採起如下兩點措施
    • 一、丟棄這個重複的M1消息,不向上層交付。
    • 二、向A發送確認消息。(不會認爲已經發送過了,就再也不發送。A能重傳,就證實B的確認消息丟失)。
  • 確認遲到 :確認消息在傳輸過程當中遲到。A發送M1消息,B收到併發送確認。在超時時間內沒有收到確認消息,A重傳M1消息,B仍然收到並繼續發送確認消息(B收到了2份M1)。此時A收到了B第二次發送的確認消息。接着發送其餘數據。過了一會,A收到了B第一次發送的對M1的確認消息(A也收到了2份確認消息)。處理以下:
      1. A收到重複的確認後,直接丟棄
      1. B收到重複的M1後,也直接丟棄重複的M1

(2)連續ARQ協議

連續 ARQ 協議可提升信道利用率。發送方維持一個發送窗口,凡位於發送窗口內的分組能夠連續發送出去,而不須要等待對方確認。接收方通常採用累計確認,對按序到達的最後一個分組發送確認,代表到這個分組爲止的全部分組都已經正確收到了。

優勢: 信道利用率高,容易實現,即便確認丟失,也沒必要重傳

缺點: 不能向發送方反映出接收方已經正確收到的全部分組的信息。 好比:發送方發送了 5條 消息,中間第三條丟失(3號),這時接收方只能對前兩個發送確認。發送方沒法知道後三個分組的下落,而只好把後三個所有重傳一次。這也叫 Go-Back-N(回退 N),表示須要退回來重傳已經發送過的 N 個消息

滑動窗口和流量控制

TCP 利用滑動窗口實現流量控制。流量控制是爲了控制發送方發送速率,保證接收方來得及接收。 接收方發送的確認報文中的窗口字段能夠用來控制發送方窗口大小,從而影響發送方的發送速率。將窗口字段設置爲 0,則發送方不能發送數據。

擁塞控制

在某段時間,若對網絡中某一資源的需求超過了該資源所能提供的可用部分,網絡的性能就要變壞。這種狀況就叫擁塞。擁塞控制就是爲了防止過多的數據注入到網絡中,這樣就能夠使網絡中的路由器或鏈路不致過載

擁塞控制所要作的都有一個前提,就是網絡可以承受現有的網絡負荷。擁塞控制是一個全局性的過程,涉及到全部的主機,全部的路由器,以及與下降網絡傳輸性能有關的全部因素。相反,流量控制每每是點對點通訊量的控制,是個端到端的問題。流量控制所要作到的就是抑制發送端發送數據的速率,以便使接收端來得及接收

爲了進行擁塞控制,TCP 發送方要維持一個 擁塞窗口(cwnd) 的狀態變量。擁塞控制窗口的大小取決於網絡的擁塞程度,而且動態變化。發送方讓本身的發送窗口取爲擁塞窗口和接收方的接受窗口中較小的一個

TCP的擁塞控制採用了四種算法,即 慢開始擁塞避免快重傳快恢復。在網絡層也能夠使路由器採用適當的分組丟棄策略(如主動隊列管理 AQM),以減小網絡擁塞的發生。

  • 慢開始: 慢開始算法的思路是當主機開始發送數據時,若是當即把大量數據字節注入到網絡,那麼可能會引發網絡阻塞,由於如今還不知道網絡的符合狀況。經驗代表,較好的方法是先探測一下,即由小到大逐漸增大發送窗口,也就是由小到大逐漸增大擁塞窗口數值cwnd初始值爲1,每通過一個傳播輪次cwnd加倍
  • 擁塞避免: 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大,即每通過一個往返時間RTT就把發送放的cwnd加1.
  • 快重傳與快恢復:TCP/IP 中,快速重傳恢復(fast retransmit and recovery,FRR)是一種擁塞控制算法,它能快速恢復丟失的數據包。沒有 FRR,若是數據包丟失了,TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內,沒有新的或複製的數據包被髮送。
    • 快重傳:有了 FRR,若是接收機接收到一個不按順序的數據段,它會當即給發送機發送一個重複確認。若是發送機接收到三個重複確認,它會假定確認件指出的數據段丟失了,並當即重傳這些丟失的數據段
    • 快恢復:有了 FRR,就不會由於重傳時要求的暫停被耽誤。當有單獨的數據包丟失時,快速重傳和恢復(FRR)能最有效地工做。當有多個數據信息包在某一段很短的時間內丟失時,它則不能頗有效地工做。也就是說,FRR適用於單獨數據包丟失的快速恢復

面試

在瀏覽器中輸入url地址 ->> 顯示主頁的過程

  1. DNS解析
  2. TCP鏈接
  3. 發送HTTP請求
  4. 服務器處理請求返回HTTP報文
  5. 瀏覽器解析渲染頁面
  6. 鏈接結束

img

狀態碼

image-20201108202736970

協議之間的關係

各類協議與HTTP協議之間的關係

HTTP長鏈接、短鏈接

HTTP/1.0中默認使用短鏈接。也就是說,客戶端和服務器每進行一次HTTP操做,就創建一次鏈接任務結束就中斷鏈接。當客戶端瀏覽器訪問的某個HTML或其餘類型的Web頁中包含有其餘的Web資源(如JavaScript文件、圖像文件、CSS文件等),每遇到這樣一個Web資源,瀏覽器就會從新創建一個HTTP會話

而從HTTP/1.1起,默認使用長鏈接,用以保持鏈接特性。使用長鏈接的HTTP協議,會在響應頭加入這行代碼:Connection:keep-alive

在使用長鏈接的狀況下,當一個網頁打開完成後,客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉,客戶端再次訪問這個服務器時,會繼續使用這一條已經創建的鏈接Keep-Alive不會永久保持鏈接,它有一個保持時間,能夠在不一樣的服務器軟件(如Apache)中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接

HTTP協議的長鏈接和短鏈接,實質上是TCP協議的長鏈接和短鏈接

HTTP是不保存狀態的協議,如何保存用戶狀態?

HTTP 是一種不保存狀態,即無狀態(stateless)協議。也就是說 HTTP 協議自身不對請求和響應之間的通訊狀態進行保存。那麼咱們保存用戶狀態呢?Session 機制的存在就是爲了解決這個問題,Session 的主要做用就是經過服務端記錄用戶的狀態。典型的場景是購物車,當你要添加商品到購物車的時候,系統不知道是哪一個用戶操做的,由於 HTTP 協議是無狀態的。服務端給特定的用戶建立特定的 Session 以後就能夠標識這個用戶而且跟蹤這個用戶了(通常狀況下,服務器會在必定時間內保存這個 Session,過了時間限制,就會銷燬這個Session)。

在服務端保存 Session 的方法不少,最經常使用的就是內存和數據庫(好比是使用內存數據庫redis保存)。既然 Session 存放在服務器端,那麼咱們如何實現 Session 跟蹤呢?大部分狀況下,咱們都是經過在 Cookie 中附加一個 Session ID 來方式來跟蹤

Cookie 被禁用怎麼辦?

最經常使用的就是利用 URL 重寫Session ID 直接附加在URL路徑的後面

Cookie的做用是什麼?和Session有什麼區別?

Cookie 和 Session 都是用來跟蹤瀏覽器用戶身份的會話方式,可是二者的應用場景不太同樣。

Cookie 通常用來保存用戶信息 ,好比

① 咱們在 Cookie 中保存已經登陸過得用戶信息,下次訪問網站的時候頁面能夠自動幫你登陸的一些基本信息給填了;

②通常的網站都會有保持登陸也就是說下次你再訪問網站的時候就不須要從新登陸了,這是由於用戶登陸的時候咱們能夠存放了一個 Token 在 Cookie 中,下次登陸的時候只須要根據 Token 值來查找用戶便可(爲了安全考慮,從新登陸通常要將 Token 重寫);

③登陸一次網站後訪問網站其餘頁面不須要從新登陸。Session 的主要做用就是經過服務端記錄用戶的狀態。 典型的場景是購物車,當你要添加商品到購物車的時候,系統不知道是哪一個用戶操做的,由於 HTTP 協議是無狀態的。服務端給特定的用戶建立特定的 Session 以後就能夠標識這個用戶而且跟蹤這個用戶了。

Cookie 數據保存在客戶端(瀏覽器端),Session 數據保存在服務器端

Cookie 存儲在客戶端中,而Session存儲在服務器上,相對來講 Session 安全性更高。若是要在 Cookie 中存儲一些敏感信息,不要直接寫入 Cookie 中,最好能將 Cookie 信息加密而後使用到的時候再去服務器端解密

HTTP 1.0和HTTP 1.1的主要區別是什麼?

  1. 長鏈接 : 在HTTP/1.0中,默認使用的是短鏈接,也就是說每次請求都要從新創建一次鏈接。HTTP 是基於TCP/IP協議的,每一次創建和斷開鏈接都分別須要三次握手和四次揮手的開銷,若是每次請求都要這樣的話,開銷會比較大。所以最好能維持一個長鏈接,能夠用個長鏈接來發多個請求HTTP 1.1起,默認使用長鏈接 ,默認開啓 Connection: keep-alive。 HTTP/1.1的持續鏈接有非流水線方式流水線方式 。流水線方式是客戶在收到HTTP的響應報文以前就能接着發送新的請求報文。與之相對應的非流水線方式是客戶在收到前一個響應後才能發送下一個請求
  2. 錯誤狀態響應碼 :在HTTP1.1中新增了24個錯誤狀態響應碼,如409(Conflict)表示請求的資源與資源的當前狀態發生衝突410(Gone)表示服務器上的某個資源被永久性的刪除
  3. 緩存處理 :在HTTP1.0中主要使用header裏的 If-Modified-Since, Expires來作爲緩存判斷的標準HTTP1.1則引入了更多的緩存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供選擇的緩存頭來控制緩存策略。
  4. 帶寬優化及網絡鏈接的使用 : HTTP1.0中,存在一些浪費帶寬的現象,例如客戶端只是須要某個對象的一部分,而服務器卻將整個對象送過來了,而且不支持斷點續傳功能,HTTP1.1則在請求頭引入了range頭域,它容許只請求資源的某個部分,即返回碼是206(Partial Content),這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接

URI和URL的區別是什麼?

  • URI(Uniform Resource Identifier) 是統一資源標誌符,能夠惟一標識一個資源
  • URL(Uniform Resource Location) 是統一資源定位符,能夠提供該資源的路徑。它是一種具體的 URI,即 URL 能夠用來標識一個資源,並且還指明瞭如何 locate 這個資源

URI 的做用像身份證號同樣,URL的做用更像家庭住址同樣。URL是一種具體的URI,它不只惟一標識資源,並且還提供了定位該資源的信息

HTTP 和 HTTPS 的區別?

簡單來講,HTTPS 就是披着 SSL/TLS 外衣的 HTTP

  1. 端口 :HTTP的URL由「http://」起始且默認使用端口80,而HTTPS的URL由「https://」起始且默認使用端口443。
  2. 安全性和資源消耗HTTP協議運行在TCP之上,全部傳輸的內容都是明文,客戶端和服務器端都沒法驗證對方的身份HTTPS是運行在SSL/TLS之上的HTTP協議,SSL/TLS 運行在TCP之上。全部傳輸的內容都通過加密,加密採用對稱加密,但對稱加密的密鑰服務器方的證書進行了非對稱加密。因此說,HTTP 安全性沒有 HTTPS高,可是 HTTPS 比HTTP耗費更多服務器資源
    1. 對稱加密密鑰只有一個,同一個密鑰能夠同時用做信息的加密和解密,加密解密爲同一個密碼,且加解密速度快,典型的對稱加密算法有DESAES等;
    2. 非對稱加密密鑰成對出現(且根據公鑰沒法推知私鑰,根據私鑰也沒法推知公鑰),加密解密使用不一樣密鑰(公鑰加密須要私鑰解密,私鑰加密須要公鑰解密),相對對稱加密速度較慢,典型的非對稱加密算法RSADSA等。
  3. http的鏈接很簡單,是無狀態的;HTTPS協議是由HTTP+SSL協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全
相關文章
相關標籤/搜索