備戰秋招，面試知識點總結:計算機網絡（五）

 

TCP怎麼保證可靠性

TCP保證可靠性：

（1）序列號、確認應答、超時重傳

數據到達接收方，接收方須要發出一個確認應答，表示已經收到該數據段，而且確認序號會說明了它下一次須要接收的數據序列號。若是發送發遲遲未收到確認應答，那麼多是發送的數據丟失，也多是確認應答丟失，這時發送方在等待必定時間後會進行重傳。這個時間通常是2*RTT(報文段往返時間）+一個誤差值。

若是發送端發送的某個報文丟了，則超時後重傳一次。

若是接送段對發送端某個報文的確認丟了，則超時後重傳，發送端從新發送該報文，接受端接受後立馬丟棄，而後再次確認該報文。

若是接受端的確認遲到了，則超時後經歷一段丟失狀況的情形，而後遲到的報文到了發送端，此時發送端已經在重發後對該端確認過了，收到遲到報文後直接丟棄。

若是開啓了快重傳，則接受端每次接受到報文都立刻回一個苛求所丟報文的回覆，接收端收到三次後當即重傳。

流量控制和擁塞控制的區別：

流量控制針對的是使接收端能來得及接受發送端的數據，而調整發送速度

擁塞控制是防止過多的數據注入到網絡內

（2）窗口控制與高速重發控制/快速重傳（重複確認應答）

TCP會利用窗口控制來提升傳輸速度，意思是在一個窗口大小內，不用必定要等到應答才能發送下一段數據，窗口大小就是無需等待確認而能夠繼續發送數據的最大值。若是不使用窗口控制，每個沒收到確認應答的數據都要重發。

使用窗口控制，若是數據段1001-2000丟失，後面數據每次傳輸，確認應答都會不停地發送序號爲1001的應答，表示我要接收1001開始的數據，發送端若是收到3次相同應答，就會馬上進行重發；

（3）擁塞控制

若是把窗口定的很大，發送端連續發送大量的數據，可能會形成網絡的擁堵（你們都在用網，你在這狂發，吞吐量就那麼大，固然會堵），甚至形成網絡的癱瘓。因此TCP在爲了防止這種狀況而進行了擁塞控制。

慢啓動：定義擁塞窗口，一開始將該窗口大小設爲1，以後每次收到確認應答（通過一個rtt），將擁塞窗口大小*2。

擁塞避免：設置慢啓動閾值，通常開始都設爲65536。擁塞避免是指當擁塞窗口大小達到這個閾值，擁塞窗口的值再也不指數上升，而是加法增長（每次確認應答/每一個rtt，擁塞窗口大小+1），以此來避免擁塞。

將報文段的超時重傳看作擁塞，則一旦發生超時重傳，咱們須要先將閾值設爲當前窗口大小的一半，而且將窗口大小設爲初值1，而後從新進入慢啓動過程。

快速重傳：在遇到3次重複確認應答（高速重發控制）時，表明收到了3個報文段，可是這以前的1個段丟失了，便對它進行當即重傳。

而後，先將閾值設爲當前窗口大小的一半，而後將擁塞窗口大小設爲慢啓動閾值+3的大小。

快重傳是爲了防止發送端錯誤的認爲發送了擁塞，由於只有在超時的狀況下才會判斷爲擁塞，如今經過快重傳在超時前就重傳了數據段，若是接下來正常接收到確認，則的確沒有發送擁塞，而若是超時了，則說明發生了擁塞。

快恢復：執行快重傳後將閾值設爲當前窗口大小的一半

這樣能夠達到：在TCP通訊時，網絡吞吐量呈現逐漸的上升，而且隨着擁堵來下降吞吐量，再進入慢慢上升的過程，網絡不會輕易的發生癱瘓。

TCP創建鏈接和斷開鏈接的過程：

三次握手：

1. Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。

2. Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

3. Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

 第二次握手其實是統一了對對端第一次握手的確認和第三次（四次中的第三次）握手的發起，將四次精簡到三次。

A端爲何要對第二次握手在進行確認：

如今假設沒有這個確認，也就是隻有兩次握手，第一次A->B,第二次B->A

則如今假設A的第一個請求延誤在網絡中，超時後A再進行一次請求，並與B創建了鏈接。

而後交換完後A與B的鏈接斷開，而斷開後這個延誤的請求達到了B。

則這樣的狀況下若是沒有第三次的確認，則至關於A再次向B進行了一次請求，而B也立刻將這個請求確認，兩邊由於一個延誤的請求而創建起了鏈接。

對A來講，它是不想進行此次鏈接的，所以也不會向裏寫數據，只留B端留着這個套接字浪費資源。

所以第三次確認的做用就是用來防止這個延誤的請求。

四次揮手：

因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉。

1.數據傳輸結束後，客戶端的應用進程發出鏈接釋放報文段，並中止發送數據，客戶端進入FIN_WAIT_1狀態，此時客戶端依然能夠接收服務器發送來的數據。

2.服務器接收到FIN後，發送一個ACK給客戶端，確認序號爲收到的序號+1，服務器進入CLOSE_WAIT狀態。客戶端收到後進入FIN_WAIT_2狀態。

3.當服務器沒有數據要發送時，服務器發送一個FIN報文，此時服務器進入LAST_ACK狀態，等待客戶端的確認

4.客戶端收到服務器的FIN報文後，給服務器發送一個ACK報文，確認序列號爲收到的序號+1。此時客戶端進入TIME_WAIT狀態，等待2MSL（MSL：報文段最大生存時間），而後關閉鏈接。

爲何客戶端要有TIME_WAIT狀態，等待2MSL

1.爲了防止A發送的最後一個ACK報文。最後一個ACK報文可能丟失，若是沒有TIMEWAIT，而最後一個ACK也丟失，則沒法收到B重傳的FIN，也就使B沒法關閉這個套接字。

2.爲了防止延遲的報文。若是沒有TIMEWAIT，則當A與另外一個服務端創建鏈接後，這個報文才到來從而影響A。

IP地址：

IP地址分爲網絡號和主機號，一個IP地址有四個字節共32位：

網絡號分爲A,B,C三類：

A類有8位，首位爲0用於與B,C類相區別，真正可用的只有7位，而網絡號全0表示「本網絡」，要去除，127（剩下的7位全1）表示本環回地址的網絡號，所以網絡號爲127的根本不是一個網絡地址，所以A類可用的網絡號有126個，1~126.

B類有16位，前兩位1 0用於區別A，C類，真正可用的有14位。因爲首位是1，所以不可能出現前兩個字節爲全0，又由於第二位位爲1，也不可能出現127，所以不用像A同樣減去2個。而B中128.0.0.0(十四位全爲0)不指派，所以最小是128.1.0.0(前八位爲10000000,後八位爲00000001)

C類有24位，共3個字節，前三位1 1 0用於區分A,B類，還剩21位。和B同樣，192.0.0是不指派的（除110外全爲0），所以其實網絡號爲192.0.1.

主機號：

主機號全爲0表示本主機所鏈接到的網絡地址，也就是這個網絡的表明。

主機號全爲1表示該網絡上的全部主機，也就是對該網絡進行廣播的地址。

子網掩碼：

引入子網的緣由：

1.IP地址利用率低，若是一個單位申請了一個B類網絡，但主機數量C類就能知足，則能夠在不用從新申請一個C類的狀況下，將B類經過子網進行劃分，用於之後的發展。

2.給每個物理網絡分配一個網絡號會使路由表太大。

3.2級地址不夠靈活：若是開通了一個新網絡，在申請新的IP以前，利用子網來增長一個新的物理網絡。

增長子網以後，網絡之外的其餘網絡看不見子網，對外表現爲同一個網絡，只有對內才表現出不一樣的物理網絡。

子網用於對本網絡進行劃分，經過在主機號段拿一部分做爲子網號，把二級地址劃分爲三級地址。

子網掩碼：

用目的IP地址與子網掩碼按位與，就能獲得目的所處的子網的網絡號。

子網增長了靈活性，但減小了所能連結的主機數量。

ARP協議

爲了經過網絡層使用的IP地址，解析出在數據鏈路層使用的硬件地址。所以也被歸到了網絡層。

在傳輸過程當中，IP地址始終保持不變，而MAC地址由於處在鏈路層因此隨着鏈路改變而改變。

每一個主機都有一個 ARP 高速緩存，裏面有本局域網上的各主機和路由器的 IP 地址到 MAC 地址的映射表。 若是主機 A 知道主機 B 的 IP 地址，可是 ARP 高速緩存中沒有該 IP 地址到 MAC 地址的映射，此時主機 A 經過廣播 的方式發送 ARP 請求分組，主機 B 收到該請求後會發送 ARP 響應分組給主機 A 告知其 MAC 地址，隨後主機 A 向其 高速緩存中寫入主機 B 的 IP 地址到 MAC 地址的映射。

網際控制報文協議（ICMP）

ICMP 是爲了更有效地轉發 IP 數據報和提升交付成功的機會。它封裝在 IP 數據報中，可是不屬於高層協議。

1. Ping Ping 是 ICMP 的一個重要應用，主要用來測試兩臺主機之間的連通性。

Ping 的原理是經過向目的主機發送 ICMP Echo 請求報文，目的主機收到以後會發送 Echo 回答報文。Ping 會根據時 間和成功響應的次數估算出數據包往返時間以及丟包率。

2. Traceroute Traceroute 是 ICMP 的另外一個應用，用來跟蹤一個分組從源點到終點的路徑。

Traceroute 發送的 IP 數據報封裝的是沒法交付的 UDP 用戶數據報，並由目的主機發送終點不可達差錯報告報文。

源主機向目的主機發送一連串的 IP 數據報。第一個數據報 P1 的生存時間 TTL 設置爲 1，當 P1 到達路徑上的第 一個路由器 R1 時，R1 收下它並把 TTL 減 1，此時 TTL 等於 0，R1 就把 P1 丟棄，並向源主機發送一個 ICMP 時間超過差錯報告報文； 源主機接着發送第二個數據報 P2，並把 TTL 設置爲 2。P2 先到達 R1，R1 收下後把 TTL 減 1 再轉發給 R2，R2 收下後也把 TTL 減 1，因爲此時 TTL 等於 0，R2 就丟棄 P2，並向源主機發送一個 ICMP 時間超過差錯報文。 不斷執行這樣的步驟，直到最後一個數據報剛剛到達目的主機，主機不轉發數據報，也不把 TTL 值減 1。可是 由於數據報封裝的是沒法交付的 UDP，所以目的主機要向源主機發送 ICMP 終點不可達差錯報告報文。 以後源主機知道了到達目的主機所通過的路由器 IP 地址以及到達每一個路由器的往返時間。

路由器分組轉發流程

從數據報的首部提取目的主機的 IP 地址 D，獲得目的網絡地址 N。

若 N 就是與此路由器直接相連的某個網絡地址，則進行直接交付；

若路由表中有目的地址爲 D 的特定主機路由，則把數據報傳送給表中所指明的下一跳路由器；

若路由表中有到達網絡 N 的路由，則把數據報傳送給路由表中所指明的下一跳路由器；

若路由表中有一個默認路由，則把數據報傳送給路由表中所指明的默認路由器； 報告轉發分組出錯。

路由選擇協議：更新路由器到各地點的路線

互聯網能夠劃分爲許多較小的自治系統 AS，一個 AS 可使用一種和別的 AS 不一樣的路由選擇協議。

能夠把路由選擇協議劃分爲兩大類：

 

自治系統內部的路由選擇：RIP 和 OSPF

自治系統間的路由選擇：BGP

自洽系統表明使用同一種技術管理的路由器合集，對其餘AS，本AS表現爲一個單一和一致的路由器選擇策略

1. 內部網關協議 RIP（基於距離向量的路由選擇協議）

本路由器到直接相連的網絡的距離定義爲1（由於要交付）。到非直接相連的網絡的距離爲到達該網絡所通過的路由器+1，+1是由於要交付。

距離是指跳數，直接相連的路由器跳數爲 1。跳數最多爲 15，超過 15 表 示不可達。

RIP 按固定的時間間隔僅和相鄰路由器交換本身的路由表，通過若干次交換以後，全部路由器最終會知道到達本自治 系統中任何一個網絡的最短距離和下一跳路由器地址。

距離向量算法：找到道每一個目的網絡的最短距離，用於更新路由表

對地址爲 X 的相鄰路由器發來的 RIP 報文，先修改報文中的全部項目，把下一跳字段中的地址改成 X，並把所 有的距離字段加 1（由於要調到X）；

對修改後的 RIP 報文中的每個項目，進行如下步驟：

若原來的路由表中沒有目的網絡 N，則把該項目添加到路由表中；

不然：若下一跳路由器地址是 X，則把收到的項目替換原來路由表中的項目；

不然：若收到的項目中的距離 d 小於路由表中的距離，則進行更新（例如原始路由表項爲 Net2, 5, P，新表項爲 Net2, 4, X，則更新）；

不然什 麼也不作。

若 3 分鐘尚未收到相鄰路由器的更新路由表，則把該相鄰路由器標爲不可達，即把距離置爲 16。

RIP 協議實現簡單，開銷小。可是 RIP 能使用的最大距離爲 15，限制了網絡的規模。而且當網絡出現故障時，要通過比較長的時間才能將此消息傳送到全部路由器。

2. 內部網關協議 OSPF：開放最短路徑優先 OSPF

開放最短路徑優先 OSPF，是爲了克服 RIP 的缺點而開發出來的。

開放表示 OSPF 不受某一家廠商控制，而是公開發表的；最短路徑優先表示使用了 Dijkstra 提出的最短路徑算法 SPF。

OSPF 具備如下特色： 向本自治系統中的全部路由器發送信息，這種方法是洪泛法。

發送的信息就是與相鄰路由器的鏈路狀態，鏈路狀態包括與哪些路由器相連以及鏈路的度量，度量用費用、距 離、時延、帶寬等來表示。

只有當鏈路狀態發生變化時，路由器纔會發送信息。

全部路由器都具備全網的拓撲結構圖，而且是一致的。相比於 RIP，OSPF 的更新過程收斂的很快。

3. 外部網關協議 BGP:用於不一樣的自洽系統間。

BGP（Border Gateway Protocol，邊界網關協議）
AS 之間的路由選擇很困難，主要是因爲：
互聯網規模很大；
各個 AS 內部使用不一樣的路由選擇協議，沒法準肯定義路徑的度量；
AS 之間的路由選擇必須考慮有關的策略，好比有些 AS 不肯意讓其它 AS 通過。
BGP 只能尋找一條比較好的路由，而不是最佳路由。

每一個 AS 都必須配置 BGP 發言人，經過在兩個相鄰 BGP 發言人之間創建 TCP 鏈接來交換路由信息。

DNS：域名系統

用於將域名轉換爲IP地址。

DNS 可使用 UDP 或者 TCP 進行傳輸，使用的端口號都爲 53。大多數狀況下 DNS 使用 UDP 進行傳輸，這就要求
域名解析器和域名服務器都必須本身處理超時和重傳從而保證可靠性。在兩種狀況下會使用 TCP 進行傳輸：
若是返回的響應超過的 512 字節（UDP 最大隻支持 512 字節的數據）。
區域傳送（區域傳送是主域名服務器向輔助域名服務器傳送變化的那部分數據）。

DNS查詢：

1).遞歸查詢：

當本地域名服務器不知道被查詢域名的IP地址，那麼本地域名服務器向根域名服務器查詢，根服務器再向其餘域名服務器進行遞歸查詢，在獲得IP地址後返回給本地域名服務器，再由本地域名服務器返回給主機。

2).迭代查詢：

當本地域名服務器不知道被查詢域名的IP地址，那麼本地域名服務器向根域名服務器進行查詢，根域名服務器要麼給出答案，要麼告訴本地域名服務器應該向哪一個頂級域名服務器詢問。本地域名服務器向指定頂級域名服務器查詢後，要麼獲得答案，要麼再向某個權限域名服務器進行請求，直到獲得答案並返回給主機。

遞歸查詢，每一次查詢，被查詢服務器都以DNS客戶的身份向另外一個服務器進行查詢，就像壓棧同樣，獲得答案後一層層返回彈棧。

迭代查詢，每一次查詢，都是由本地域名服務器向某個服務器發起。

主機向本地域名服務器的必定是遞歸查詢，由於本地域名服務器必定是以DNS客戶的身份去請求答案。

而本地域名服務器向其餘服務器請求，能夠是遞歸查詢，也能夠是迭代查詢。

文件傳送協議FTP

FTP 使用 TCP 進行鏈接，它須要兩個鏈接來傳送一個文件：

控制鏈接：服務器打開端口號 21 等待客戶端的鏈接，客戶端主動創建鏈接後，使用這個鏈接將客戶端的命令傳 送給服務器，並傳回服務器的應答。（此進程用於接收客戶端請求，傳送數據使用數據鏈接）

數據鏈接：用來傳送一個文件數據。

根據數據鏈接是不是服務器端主動創建，FTP 有主動和被動兩種模式：

主動模式：服務器端主動創建數據鏈接，其中服務器端的端口號爲 20，客戶端的端口號隨機，可是必須大於 1024，由於 0~1023 是熟知端口號。

被動模式：客戶端主動創建數據鏈接，其中客戶端的端口號由客戶端本身指定，服務器端的端口號隨機。

主動模式要求客戶端開放端口號給服務器端，須要去配置客戶端的防火牆。被動模式只須要服務器端開放端口號便可，無需客戶端配置防火牆。可是被動模式會致使服務器端的安全性減弱，由於開放了過多的端口號。

動態主機配置協議

DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的連網方式，用戶再也不須要手動配置 IP 地址等信 息。

DHCP 配置的內容不只是 IP 地址，還包括子網掩碼、網關 IP 地址。

DHCP 工做過程以下：

1. 客戶端發送 Discover 報文，該報文的目的地址爲 255.255.255.255:67，源地址爲 0.0.0.0:68，被放入 UDP 中，該報文被廣播到同一個子網的全部主機上。若是客戶端和 DHCP 服務器不在同一個子網，就須要使用中繼代理。

2. DHCP 服務器收到 Discover 報文以後，發送 Offer 報文給客戶端，該報文包含了客戶端所須要的信息。由於客戶端可能收到多個 DHCP 服務器提供的信息，所以客戶端須要進行選擇。

3. 若是客戶端選擇了某個 DHCP 服務器提供的信息，那麼就發送 Request 報文給該 DHCP 服務器。

4. DHCP 服務器發送 Ack 報文，表示客戶端此時可使用提供給它的信息。

Discover用於尋找DHCP

Offer用於提供IP及所需信息

Request用於正式申請

Ack爲贊成申請

遠程登陸協議

TELNET 用於登陸到遠程主機上，而且遠程主機上的輸出也會返回。
TELNET 能夠適應許多計算機和操做系統的差別，例如不一樣操做系統系統的換行符定義。

電子郵件協議

一個電子郵件系統由三部分組成：用戶代理、郵件服務器以及郵件協議。
郵件協議包含發送協議和讀取協議，發送協議經常使用 SMTP，讀取協議經常使用 POP3 和 IMAP。

1. SMTP SMTP 只能發送 ASCII 碼，而互聯網郵件擴充 MIME 能夠發送二進制文件。MIME 並無改動或者取代 SMTP，而是 增長郵件主體的結構，定義了非 ASCII 碼的編碼規則。

2.POP3
POP3 的特色是隻要用戶從服務器上讀取了郵件，就把該郵件刪除。
3. IMAP
IMAP 協議中客戶端和服務器上的郵件保持同步，若是不手動刪除郵件，那麼服務器上的郵件也不會被刪除。IMAP這種作法可讓用戶隨時隨地去訪問服務器上的郵件。

經常使用協議及端口

Web 頁面請求過程

 

1).DHCP 配置主機信息
假設主機最開始沒有 IP 地址以及其它信息，那麼就須要先使用 DHCP 來獲取。
主機生成一個 DHCP 請求報文，並將這個報文放入具備目的端口 67 和源端口 68 的 UDP 報文段中。該報文段則被放入在一個具備廣播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 數據報中。
該數據報則被放置在 MAC 幀中，該幀具備目的地址 FF:FF:FF:FF:FF:FF，將廣播到與交換機鏈接的全部設備。
鏈接在交換機的 DHCP 服務器收到廣播幀以後，不斷地向上分解獲得 IP 數據報、UDP 報文段、DHCP 請求報文，以後生成 DHCP ACK 報文，該報文包含如下信息：IP 地址、DNS 服務器的 IP 地址、默認網關路由器的 IP地址和子網掩碼。該報文被放入 UDP 報文段中，UDP 報文段有被放入 IP 數據報中，最後放入 MAC 幀中。
該幀的目的地址是請求主機的 MAC 地址，由於交換機具備自學習能力，以前主機發送了廣播幀以後就記錄了MAC 地址到其轉發接口的交換表項，所以如今交換機就能夠直接知道應該向哪一個接口發送該幀（由於雖然IP地址還沒分配下來，但MAC地址已經知道了）。
主機收到該幀後，不斷分解獲得 DHCP 報文。以後就配置它的 IP 地址、子網掩碼和 DNS 服務器的 IP 地址，並
在其 IP 轉發表中安裝默認網關。

2. ARP 解析 MAC 地址

主機經過瀏覽器生成一個 TCP 套接字，套接字向 HTTP 服務器發送 HTTP 請求。爲了生成該套接字，主機須要 知道網站的域名對應的 IP 地址。

主機生成一個 DNS 查詢報文，該報文具備 53 號端口，由於 DNS 服務器的端口號是 53。

該 DNS 查詢報文被放入目的地址爲 DNS 服務器 IP 地址的 IP 數據報中。

該 IP 數據報被放入一個以太網幀中，該幀將發送到網關路由器。

DHCP 過程只知道網關路由器的 IP 地址，爲了獲取網關路由器的 MAC 地址，須要使用 ARP 協議。

主機生成一個包含目的地址爲網關路由器 IP 地址的 ARP 查詢報文，將該 ARP 查詢報文放入一個具備廣播目的 地址（FF:FF:FF:FF:FF:FF）的以太網幀中，並向交換機發送該以太網幀，交換機將該幀轉發給全部的鏈接設備， 包括網關路由器。

網關路由器接收到該幀後，不斷向上分解獲得 ARP 報文，發現其中的 IP 地址與其接口的 IP 地址匹配，所以就 發送一個 ARP 回答報文，包含了它的 MAC 地址，發回給主機（單播）。

3. DNS 解析域名

知道了網關路由器的 MAC 地址以後，就能夠繼續 DNS 的解析過程了。

網關路由器接收到包含 DNS 查詢報文的以太網幀後，抽取出 IP 數據報，並根據轉發表決定該 IP 數據報應該轉 發的路由器。

由於路由器具備內部網關協議（RIP、OSPF）和外部網關協議（BGP）這兩種路由選擇協議，所以路由表中已 經配置了網關路由器到達 DNS 服務器的路由表項。

到達 DNS 服務器以後，DNS 服務器抽取出 DNS 查詢報文，並在 DNS 數據庫中查找待解析的域名。

找到 DNS 記錄以後，發送 DNS 回答報文，將該回答報文放入 UDP報文段中，而後放入 IP 數據報中，經過路 由器反向轉發回網關路由器，並通過以太網交換機到達主機。

4. HTTP 請求頁面

有了 HTTP 服務器的 IP 地址以後，主機就可以生成 TCP 套接字，該套接字將用於向 Web 服務器發送 HTTP GET 報文。

在生成 TCP 套接字以前，必須先與 HTTP 服務器進行三次握手來創建鏈接。生成一個具備目的端口 80 的 TCP SYN 報文段，並向 HTTP 服務器發送該報文段。

HTTP 服務器收到該報文段以後，生成 TCP SYN ACK 報文段，發回給主機。

鏈接創建以後，瀏覽器生成 HTTP GET 報文，並交付給 HTTP 服務器。

HTTP 服務器從 TCP 套接字讀取 HTTP GET 報文，生成一個 HTTP 響應報文，將 Web 頁面內容放入報文主體 中，發回給主機。

瀏覽器收到 HTTP 響應報文後，抽取出 Web 頁面內容，以後進行渲染，顯示 Web 頁面。

HTTP 方法

1，GET：GET能夠說是最多見的了，它本質就是發送一個請求來取得服務器上的某一資源。資源經過一組HTTP頭和呈現據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。

2，HEAD：HEAD和GET本質是同樣的，區別在於HEAD不含有呈現數據，而僅僅是HTTP頭信息。有的人可能以爲這個方法沒什麼用，其實不是這樣的。想象一個業務情景：欲判斷某個資源是否存在，咱們一般使用GET，但這裏用HEAD則意義更加明確。

3，PUT：這個方法比較少見。HTML表單也不支持這個。本質上來說， PUT和POST極爲類似，都是向服務器發送數據，但它們之間有一個重要區別，PUT一般指定了資源的存放位置，而POST則沒有，POST的數據存放位置由服務器本身決定。
舉個例子：如一個用於提交博文的URL，/addBlog。若是用PUT，則提交的URL會是像這樣的」/addBlog/abc123」，其中abc123就是這個博文的地址。而若是用POST，則這個地址會在提交後由服務器告知客戶端。目前大部分博客都是這樣的。顯然，PUT和POST用途是不同的。具體用哪一個還取決於當前的業務場景。

4，DELETE：刪除某一個資源。基本上這個也不多見，不過仍是有一些地方好比amazon的S3雲服務裏面就用的這個方法來刪除資源。

5，POST：向服務器提交數據。這個方法用途普遍，幾乎目前全部的提交操做都是靠這個完成。

6，OPTIONS：這個方法頗有趣，但極少使用。它用於獲取當前URL所支持的方法。若請求成功，則它會在HTTP頭中包含一個名爲「Allow」的頭，值是所支持的方法，如「GET, POST」。

HTTP 狀態碼：

1XX 信息
100 Continue ：代表到目前爲止都很正常，客戶端能夠繼續發送請求或者忽略這個響應。

2XX 成功
200 OK
204 No Content ：請求已經成功處理，可是返回的響應報文不包含實體的主體部分。通常在只須要從客戶端
往服務器發送信息，而不須要返回數據時使用。
206 Partial Content ：表示客戶端進行了範圍請求，響應報文包含由 Content-Range 指定範圍的實體內容。

3XX 重定向
301 Moved Permanently ：永久性重定向
302 Found ：臨時性重定向
303 See Other ：和 302 有着相同的功能，可是 303 明確要求客戶端應該採用 GET 方法獲取資源。
注：雖然 HTTP 協議規定 30一、302 狀態下重定向時不容許把 POST 方法改爲 GET 方法，可是大多數瀏覽器都
會在 30一、302 和 303 狀態下的重定向把 POST 方法改爲 GET 方法。
304 Not Modified ：若是請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-
Match，If-Range，If-Unmodified-Since，若是不知足條件，則服務器會返回 304 狀態碼。
307 Temporary Redirect ：臨時重定向，與 302 的含義相似，可是 307 要求瀏覽器不會把重定向請求的
POST 方法改爲 GET 方法。

4XX 客戶端錯誤
400 Bad Request ：請求報文中存在語法錯誤。
401 Unauthorized ：該狀態碼錶示發送的請求須要有認證信息（BASIC 認證、DIGEST 認證）。若是以前已進
行過一次請求，則表示用戶認證失敗。
403 Forbidden ：請求被拒絕。
404 Not Found

5XX 服務器錯誤
500 Internal Server Error ：服務器正在執行請求時發生錯誤。
503 Service Unavailable ：服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

HTTP鏈接管理：

1. 短鏈接與長鏈接

當瀏覽器訪問一個包含多張圖片的 HTML 頁面時，除了請求訪問的 HTML 頁面資源，還會請求圖片資源。若是每進 行一次 HTTP 通訊就要新建一個 TCP 鏈接，那麼開銷會很大。

長鏈接只須要創建一次 TCP 鏈接就能進行屢次 HTTP 通訊。

從 HTTP/1.1 開始默認是長鏈接的，若是要斷開鏈接，須要由客戶端或者服務器端提出斷開，使用 Connection : close ； 在 HTTP/1.1 以前默認是短鏈接的，若是須要使用長鏈接，則使用 Connection : Keep-Alive 。

2. 流水線 默認狀況下，HTTP 請求是按順序發出的，下一個請求只有在當前請求收到響應以後纔會被髮出。因爲受到網絡延遲 和帶寬的限制，在下一個請求被髮送到服務器以前，可能須要等待很長時間。 流水線是在同一條長鏈接上連續發出請求，而不用等待響應返回，這樣能夠減小延遲。

 

Cookie和Session

HTTP 協議是無狀態的，主要是爲了讓 HTTP 協議儘量簡單，使得它可以處理大量事務。HTTP/1.1 引入 Cookie 來
保存狀態信息。

Cookie:
Cookie 是服務器發送到用戶瀏覽器並保存在本地的一小塊數據，它會在瀏覽器以後向同一服務器再次發起請求時被
攜帶上，用於告知服務端兩個請求是否來自同一瀏覽器。因爲以後每次請求都會須要攜帶 Cookie 數據，所以會帶來
額外的性能開銷（尤爲是在移動環境下）。

1. 用途
會話狀態管理（如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息）
個性化設置（如用戶自定義設置、主題等）
瀏覽器行爲跟蹤（如跟蹤分析用戶行爲等）

2. 建立過程
服務器發送的響應報文包含 Set-Cookie 首部字段，客戶端獲得響應報文後把 Cookie 內容保存到瀏覽器中。

Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

客戶端以後對同一個服務器發送請求時，會從瀏覽器中取出 Cookie 信息並經過 Cookie 請求首部字段發送給服務
器。

Cookie: yummy_cookie=choco; tasty_cookie=strawberry

3. 分類
會話期 Cookie：瀏覽器關閉以後它會被自動刪除，也就是說它僅在會話期內有效。
持久性 Cookie：指定過時時間（Expires）或有效期（max-age）以後就成爲了持久性的 Cookie。

Session：
除了能夠將用戶信息經過 Cookie 存儲在用戶瀏覽器中，也能夠利用 Session 存儲在服務器端，存儲在服務器端的信
息更加安全。
Session 能夠存儲在服務器上的文件、數據庫或者內存中。也能夠將 Session 存儲在 Redis 這種內存型數據庫中，效
率會更高。
使用 Session 維護用戶登陸狀態的過程以下：
用戶進行登陸時，用戶提交包含用戶名和密碼的表單，放入 HTTP 請求報文中；
服務器驗證該用戶名和密碼，若是正確則把用戶信息存儲到 Redis 中，它在 Redis 中的 Key 稱爲 Session ID；
服務器返回的響應報文的 Set-Cookie 首部字段包含了這個 Session ID，客戶端收到響應報文以後將該 Cookie
值存入瀏覽器中；
客戶端以後對同一個服務器進行請求時會包含該 Cookie 值，服務器收到以後提取出 Session ID，從 Redis 中取
出用戶信息，繼續以前的業務操做。
應該注意 Session ID 的安全性問題，不能讓它被惡意攻擊者輕易獲取，那麼就不能產生一個容易被猜到的 Session
ID 值。此外，還須要常常從新生成 Session ID。在對安全性要求極高的場景下，例如轉帳等操做，除了使用 Session
管理用戶狀態以外，還須要對用戶進行從新驗證，好比從新輸入密碼，或者使用短信驗證碼等方式。

瀏覽器禁用 Cookie 此時沒法使用 Cookie 來保存用戶信息，只能使用 Session。除此以外，不能再將 Session ID 存放到 Cookie 中，而 是使用 URL 重寫技術，將 Session ID 做爲 URL 的參數進行傳遞。

Cookie 與 Session 選擇
Cookie 只能存儲 ASCII 碼字符串，而 Session 則能夠存儲任何類型的數據，所以在考慮數據複雜性時首選
Session；
Cookie 存儲在瀏覽器中，容易被惡意查看。若是非要將一些隱私數據存在 Cookie 中，能夠將 Cookie 值進行加
密，而後在服務器進行解密；
對於大型網站，若是用戶全部的信息都存儲在 Session 中，那麼開銷是很是大的，所以不建議將全部的用戶信
息都存儲到 Session 中。

HTTPS：

HTTP 有如下安全性問題：
使用明文進行通訊，內容可能會被竊聽；
不驗證通訊方的身份，通訊方的身份有可能遭遇假裝；
沒法證實報文的完整性，報文有可能遭篡改。

HTTPS 並非新協議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通訊，再由 SSL 和 TCP 通訊，也就是說HTTPS 使用了隧道進行通訊。

經過使用 SSL，HTTPS 具備了加密（防竊聽）、認證（防假裝）和完整性保護（防篡改）。

加密：

1. 對稱密鑰加密
對稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。
優勢：運算速度快；
缺點：沒法安全地將密鑰傳輸給通訊方。

2.非對稱密鑰加密
非對稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不一樣的密鑰。
公開密鑰全部人均可以得到，通訊發送方得到接收方的公開密鑰以後，就可使用公開密鑰進行加密，接收方收到通
信內容後使用私有密鑰解密。
非對稱密鑰除了用來加密，還能夠用來進行簽名。由於私有密鑰沒法被其餘人獲取，所以通訊發送方使用其私有密鑰
進行簽名，通訊接收方使用發送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。
優勢：能夠更安全地將公開密鑰傳輸給通訊發送方；
缺點：運算速度慢。

HTTPS 採用的加密方式
HTTPS 採用混合的加密機制，使用非對稱密鑰加密用於傳輸對稱密鑰來保證傳輸過程的安全性，以後使用對稱密鑰
加密進行通訊來保證通訊過程的效率。（下圖中的 Session Key 就是對稱密鑰）

首先客戶端請求鏈接

服務器將一個非對稱加密的公開密鑰傳遞給客戶端，客戶端使用這個公開密鑰對對稱密鑰進行加密，加密後傳給服務器端

服務器端用非對稱加密的私有密鑰進行解鎖，解鎖後獲得了客戶端發送的對稱密鑰。

之後兩端的通訊都經過這個對稱密鑰來進行通訊。

這樣的方式能避免對稱密鑰被竊取。

 

 

認證:
經過使用 證書 來對通訊方進行認證。
數字證書認證機構（CA，Certificate Authority）是客戶端與服務器雙方均可信賴的第三方機構。
服務器的運營人員向 CA 提出公開密鑰的申請，CA 在判明提出申請者的身份以後，會對已申請的公開密鑰作數字籤
名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公開密鑰證書後綁定在一塊兒。
進行 HTTPS 通訊時，服務器會把證書發送給客戶端。客戶端取得其中的公開密鑰以後，先使用數字簽名進行驗證，
若是驗證經過，就能夠開始通訊了。

認證過程：

1. 客戶端發起HTTPS請求

這個沒什麼好說的，就是用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。

2. 服務端的配置

採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。若是對公鑰和私鑰不太理解，能夠想象成一把鑰匙和一個鎖頭，只是全世界只有你一我的有這把鑰匙，你能夠把鎖頭給別人，別人能夠用這個鎖把重要的東西鎖起來，而後發給你，由於只有你一我的有這把鑰匙，因此只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書

這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。

4. 客戶端解析證書

這部分工做是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨即值。而後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，否則看不到被鎖住的內容。

5. 傳送加密信息

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

6. 服務段解密信息

服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。

7. 傳輸加密後的信息

這部分信息是服務段用私鑰加密後的信息，能夠在客戶端被還原

8. 客戶端解密信息

客戶端用以前生成的私鑰解密服務段傳過來的信息，因而獲取瞭解密後的內容。整個過程第三方即便監聽到了數據，也一籌莫展。

 

完整性保護
SSL 提供報文摘要功能來進行完整性保護。
HTTP 也提供了 MD5 報文摘要功能，但不是安全的。例如報文內容被篡改以後，同時從新計算 MD5 的值，通訊接
收方是沒法意識到發生了篡改。
HTTPS 的報文摘要功能之因此安全，是由於它結合了加密和認證這兩個操做。試想一下，加密以後的報文，遭到篡
改以後，也很難從新計算報文摘要，由於沒法輕易獲取明文。
HTTPS 的缺點
由於須要進行加密解密等過程，所以速度會更慢；
須要支付證書受權的高額費用。

HTTP2.0

HTTP/1.x 缺陷
HTTP/1.x 實現簡單是以犧牲性能爲代價的：
客戶端須要使用多個鏈接才能實現併發和縮短延遲；
不會壓縮請求和響應首部，從而致使沒必要要的網絡流量；
不支持有效的資源優先級，導致底層 TCP 鏈接的利用率低下。

HTTP/2.0 將報文分紅 HEADERS 幀和 DATA 幀，它們都是二進制格式的。

在通訊過程當中，只會有一個 TCP 鏈接存在，它承載了任意數量的雙向數據流（Stream）。
一個數據流（Stream）都有一個惟一標識符和可選的優先級信息，用於承載雙向信息。
消息（Message）是與邏輯請求或響應對應的完整的一系列幀。
幀（Frame）是最小的通訊單位，來自不一樣數據流的幀能夠交錯發送，而後再根據每一個幀頭的數據流標識符重
新組裝。

 

服務端推送
HTTP/2.0 在客戶端請求一個資源時，會把相關的資源一塊兒發送給客戶端，客戶端就不須要再次發起請求了。例如客
戶端請求 page.html 頁面，服務端就把 script.js 和 style.css 等與之相關的資源一塊兒發給客戶端。

首部壓縮
HTTP/1.1 的首部帶有大量信息，並且每次都要重複發送。
HTTP/2.0 要求客戶端和服務器同時維護和更新一個包含以前見過的首部字段表，從而避免了重複傳輸。
不只如此，HTTP/2.0 也使用 Huffman 編碼對首部字段進行壓縮。

GET 和 POST 比較

http://www.javashuo.com/article/p-gpmpckag-cx.html

做用
GET 用於獲取資源，而 POST 用於傳輸實體主體。

參數
GET 和 POST 的請求都能使用額外的參數，可是 GET 的參數是以查詢字符串出如今 URL 中，而 POST 的參數存儲在
實體主體中。不能由於 POST 參數存儲在實體主體中就認爲它的安全性更高，由於照樣能夠經過一些抓包工具
（Fiddler）查看。

由於 URL 只支持 ASCII 碼，所以 GET 的參數中若是存在中文等字符就須要先進行編碼。例如 中文 會轉換爲
%E4%B8%AD%E6%96%87 ，而空格會轉換爲 %20 。POST 參數支持標準字符集。

下圖中，GET中參數出如今URL裏，而POST放在實體主體裏。

安全
安全的 HTTP 方法不會改變服務器狀態，也就是說它只是可讀的。
GET 方法是安全的，而 POST 卻不是，由於 POST 的目的是傳送實體主體內容，這個內容多是用戶上傳的表單數
據，上傳成功以後，服務器可能把這個數據存儲到數據庫中，所以狀態也就發生了改變。
安全的方法除了 GET 以外還有：HEAD、OPTIONS。
不安全的方法除了 POST 以外還有 PUT、DELETE。

冪等性
冪等的 HTTP 方法，一樣的請求被執行一次與連續執行屢次的效果是同樣的，服務器的狀態也是同樣的。換句話說就
是，冪等方法不該該具備反作用（統計用途除外）。
全部的安全方法也都是冪等的。
在正確實現的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。

 

 

可緩存
若是要對響應進行緩存，須要知足如下條件：
請求報文的 HTTP 方法自己是可緩存的，包括 GET 和 HEAD，可是 PUT 和 DELETE 不可緩存，POST 在多數情
況下不可緩存的。
響應報文的狀態碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
響應報文的 Cache-Control 首部字段沒有指定不進行緩存。

Select,poll與epoll

select:

有三種類型的描述符類型：readset、writeset、exceptset，分別對應讀、寫、異常條件的描述符集合。fd_set 使用
數組實現，數組大小使用 FD_SETSIZE 定義。
timeout 爲超時參數，調用 select 會一直阻塞直到有描述符的事件到達或者等待的時間超過 timeout。
成功調用返回結果大於 0，出錯返回結果爲 -1，超時返回結果爲 0。

poll:

pollfd 使用鏈表實現。

select與epoll的比較：

比較
1. 功能
select 和 poll 的功能基本相同，不過在一些實現細節上有所不一樣。
select 會修改描述符，而 poll 不會（當select()返回後，該數組中就緒的文件描述符便會被內核修改標誌位，使得進程能夠得到這些文件描述符從而進行後續的讀寫操做。）；
select 的描述符類型使用數組實現，FD_SETSIZE 大小默認爲 1024，所以默認只能監聽 1024 個描述符。若是
要監聽更多描述符的話，須要修改 FD_SETSIZE 以後從新編譯；而 poll 的描述符類型使用鏈表實現，沒有描述
符數量的限制；
poll 提供了更多的事件類型，而且對描述符的重複利用上比 select 高。
若是一個線程對某個描述符調用了 select 或者 poll，另外一個線程關閉了該描述符，會致使調用結果不肯定。

2. 速度
select 和 poll 速度都比較慢。
select 和 poll 每次調用都須要將所有描述符從應用進程緩衝區複製到內核緩衝區(而epoll不用)。
select 和 poll 的返回結果中沒有聲明哪些描述符已經準備好，因此若是返回值大於 0 時，應用進程都須要使用
輪詢的方式來找到 I/O 完成的描述符。
3. 可移植性
幾乎全部的系統都支持 select，可是隻有比較新的系統支持 poll。

epoll:

epoll_ctl() 用於向內核註冊新的描述符或者是改變某個文件描述符的狀態。已註冊的描述符在內核中會被維護在一棵
紅黑樹上，經過回調函數內核會將 I/O 準備好的描述符加入到一個鏈表中管理，進程調用 epoll_wait() 即可以獲得事
件完成的描述符。
從上面的描述能夠看出，epoll 只須要將描述符從進程緩衝區向內核緩衝區拷貝一次，而且進程不須要經過輪詢來獲
得事件完成的描述符。
epoll 僅適用於 Linux OS。
epoll 比 select 和 poll 更加靈活並且沒有描述符數量限制。

epoll 對多線程編程更有友好，一個線程調用了 epoll_wait() 另外一個線程關閉了同一個描述符也不會產生像 select 和
poll 的不肯定狀況：

假設從epoll_wait收到100個事件，A事件形成B事件關閉，若是移除B事件結構並關閉文件描述符，事件緩存仍然認爲有事件在等待文件描述符，從而形成混亂。

解決方法是，在A事件處理過程當中，調用epoll_ctl(EPOLL_CTL_DEL)來移除B文件描述符並關閉，而後標記關聯的數據結構爲已移除，並關聯到移除列表。在後續事件處理過程當中，當發現B文件描述符的新事件時，能夠經過檢查標記發現文件描述符已移除，避免產生混亂。

工做模式
epoll 的描述符事件有兩種觸發模式：LT（level trigger）和 ET（edge trigger）。
1. LT 模式
當 epoll_wait() 檢測到描述符事件到達時，將此事件通知進程，進程能夠不當即處理該事件，下次調用 epoll_wait()
會再次通知進程。是默認的一種模式，而且同時支持 Blocking 和 No-Blocking。
2. ET 模式
和 LT 模式不一樣的是，通知以後進程必須當即處理事件，下次再調用 epoll_wait() 時不會再獲得事件到達的通知。
很大程度上減小了 epoll 事件被重複觸發的次數，所以效率要比 LT模式高。只支持 No-Blocking，以免因爲一個文件句柄的阻塞讀/阻塞寫操做把處理多個文件描述符的任務餓死。

應用場景
很容易產生一種錯覺認爲只要用 epoll 就能夠了，select 和 poll 都已通過時了，其實它們都有各自的使用場景。
1. select 應用場景
select 的 timeout 參數精度爲 1ns，而 poll 和 epoll 爲 1ms，所以 select 更加適用於實時性要求比較高的場景，比
如核反應堆的控制。
select 可移植性更好，幾乎被全部主流平臺所支持。
2. poll 應用場景
poll 沒有最大描述符數量的限制，若是平臺支持而且對實時性要求不高，應該使用 poll 而不是 select。
3. epoll 應用場景
只須要運行在 Linux 平臺上，有大量的描述符須要同時輪詢，而且這些鏈接最好是長鏈接。
須要同時監控小於 1000 個描述符，就沒有必要使用 epoll，由於這個應用場景下並不能體現 epoll 的優點。
須要監控的描述符狀態變化多，並且都是很是短暫的，也沒有必要使用 epoll。由於 epoll 中的全部描述符都存儲在
內核中，形成每次須要對描述符的狀態改變都須要經過 epoll_ctl() 進行系統調用，頻繁系統調用下降效率。而且
epoll 的描述符存儲在內核，不容易調試。

HTTP和HTTPS的區別，以及HTTPS有什麼缺點？