《圖解http》知識點筆記

1.

http正式做爲標準被公佈是在1996年5月，版本被命名爲http/1.0，並記載於RFC1945

 

2.

1997年公佈的HTTP/1.1是目前主流的HTTP協議版本，當初的標準是RFC2068，以後發佈的修訂版RFC2616就是當前的最新版本

 

3.

TCP/IP協議族按層次分別分爲如下4層：應用層，傳輸層，網絡成，數據鏈路層

 

4.

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個蓋層所屬的首部信息

 

5.

IP網際協議位於網絡層。

 

6.

ip間的通訊依賴mac地址

 

7.

ARP是一種用以解析地址的協議，根據通訊放的ip地址就能夠反查出對應MAC地址

 

8.

不管哪臺計算機，哪臺網絡設備，他們都沒法全面掌握互聯網中的細節

 

9.

TCP位於傳輸層，提供可靠地字節流服務，所謂的字節流服務是指，爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。

 

10.

爲了準確無誤的將數據送達目標處，TCP協議採用了三次握手策略。發送端首先發送一個帶SYN標誌的數據包給對方，接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶ACK標誌的數據包，表明「握手」結束。

 

11.

URI統一資源標識符，URL統一資源定位符。

URI用字符串標識某一互聯網資源，而URL表示資源的地點（互聯網上所處的位置）。可見URL是URI的子集

 

12.

RFC是互聯網的設計文檔，要是不按照RFC標準執行，就有可能致使沒法通訊的情況。

 

13.

http報文大體可分爲報文首部和報文主體兩塊，二者由最初出現的空行（CR+LF）來劃分

 

14.

常見的內容編碼有如下幾種：

1.gzip（GNU zip）

2.compress（UNIX系統標準壓縮）

3.deflate（zlib）

4.identity（不進行編碼）

 

15.

在http通訊過程當中，請求的編碼實體資源還沒有被所有傳輸完成以前，瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割城多塊，可以讓瀏覽器逐步顯示畫面，這種把實體主體分塊的功能稱爲分塊傳輸編碼（chunked transfer Coding）

 

16.

在http報文中使用多部分對象集合時，須要在首部字段里加上content-type

 

17.

要實現能從以前下載中斷處恢復下載須要指定下載的實體範圍，像這樣，指定範圍發送的請求叫作範圍請求。由Range這個請求頭控制。例如 

Range: bytes=5001-10000 表示請求資源的5001-10000字節的範圍。

 bytes=5001- 表示從5001到以後全部

bytes=-3000， 5000-7000 從一開始到3000和5000-7000字節的多重範圍

 

 

18.

針對範圍請求，響應會返回狀態碼206。另外，對於多重範圍的範圍請求，響應會在首部字段content-type標明multipart-byteranges後返回響應報文。若是服務器沒法響應範圍請求，則會返回狀態碼200 OK和完整的實體內容

 

19.

內容協商常見請求頭：

1.Accept

2.Accept-Charset

3.Accept-Encoding

4.Accept-Language

5.Content-Langeuage

 

20.

Accept:text/xml； 

Content-Type:text/html 

即表明但願接受的數據類型是xml格式，本次請求發送的數據的數據格式是html。

 

21.

1** 接受的請求正在處理

2** 請求正常處理完畢

3** 須要進行附加操做以完成請求

4** 服務器沒法處理請求

5** 服務器處理請求出錯

 

22.

只要遵照狀態碼類別的定義，即時改變RFC2616中定義的狀態碼或服務端自行建立狀態碼都沒問題

 

23.

常見狀態碼：

200 OK 

204 No Content請求處理成功，但沒有資源可返回

206 Partial Content表示客戶端進行了範圍請求，響應報文中包含由Content-Range指定範圍的試題內容

301 Moved Permanently 永久重定向

302 Found 臨時重定向

303 See Other 但願客戶端能以GET方法重定向到另外一個URI上

304 Not Modified 用緩存的時候會出現

400  Bad Request請求報文中存在語法錯誤

401 Unauthorized 發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）

403 Forbidden 服務器拒絕提供，通常是權限的問題

404 Not Found

500 Internal Server Error 服務器端內部出錯

503 Service Unavailable 服務器在更新或者忙，一會再來

 

24.

當30一、30二、303響應狀態碼返回時，幾乎全部的瀏覽器都會把POST改成GET

 

25.

HTTP/1.1規範容許一臺HTTP服務器搭建多個WEB站點，由於利用了虛擬主機功能，即時物理層面只有一臺服務器，但只要使用虛擬主機的功能，則能夠假想已具備多臺服務器

 

26.

當請求發送到服務器時，已是以IP地址形式訪問了

 

27.

代理，它扮演了位於服務器和客戶端「中間人」的角色

網關，是轉發其餘服務器通訊數據的服務器，接受從客戶端發送來的請求時，他就像擁有資源的源服務器同樣對請求進行處理

隧道，是在相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序

 

28.

使用代理服務器的理由有：利用緩存技術減小網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的。

 

29.

代理有多種使用方法，按兩種基準分類，一種是是否使用緩存，另外一種是是否會修改報文。

 

30.

隧道使用SSL等加密手段進行通訊

 

31.

在請求中，HTTP報文由方法，URI，HTTP版本，HTTP首部字段等構成

在響應中，HTTP報文由HTTP版本，狀態碼（數字和緣由短語）、HTTP首部字段3部分構成

 

31.

從字面意思上很容易把no-cache誤解爲不緩存，但事實上no-cache表明不緩存過時的資源，緩存會像員服務器進行有效期確認後處理資源，no-store纔是真正的不進行緩存

 

32.

no-cache: 告訴瀏覽器、緩存服務器，無論本地副本是否過時，使用資源副本前，必定要到源服務器進行副本有效性校驗。也就是說必定會有http請求，服務器會告訴咱們資源有沒有更新過。

must-revalidate：告訴瀏覽器、緩存服務器，本地副本過時前，可使用本地副本；本地副本一旦過時，必須去源服務器進行有效性校驗。

 

33.

keep-alive: timeout=10， max=500

 

34.

Pragma是HTTP/1.1以前版本的歷史遺留字段，僅做爲與HTTP/1.0的向後兼容

 

35.

首部字段Transfer-Encoding規定了傳輸報文主體時採用的編碼方式

 

36.

首部字段Upgrade用於檢測HTTP協議及其餘協議是否可以使用更高的版本進行通訊，其參數值能夠用來指定一個徹底不一樣的通訊協議

 

37.

報文通過代理或網關時，會如今首部字段Via中附加該服務器的信息，而後進行轉發。

 

38.

Host首部字段在HTTP/1.1規範內是惟一一個必須被包含在請求內的首部字段

 

39.

If-match和ETag一塊兒使用，還可使用星號（*）指定If-match的字段值，這樣，服務器將會忽略ETag的值，只要資源存在就處理請求

 

40.

對主體進行內容編碼傳輸時，不能再使用content-length首部字段

 

41.

http主要有這些不足：

1.通訊使用明文，內容可能會被竊聽

2.不驗證通訊方的身份，所以可能遭遇假裝

3.沒法證實報文完整性，因此有可能已遭篡改

 

42.

與SSL組合使用的HTTP被稱爲HTTPS

 

43.

雖然使用HTTP協議沒法肯定通訊方，但若是使用SSL則能夠，SSL不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。

 

44.

常使用的肯定報文完整性的方法，MD5和SHA-1等散列值校驗，但他們並不便捷和可靠

 

45.

SSL提供認證和加密處理及摘要功能

 

46.

HTTP+加密+認證+完整性保護=HTTPS

 

47.

HTTPS是身披SSL外殼的HTTP，HTTPS只是HTTP通訊接口部分用SSL和TLS協議代替而已

 

48.

一般HTTP直接和TCP通訊，當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了，簡而言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP

 

49.

SSL採用一種叫公開密鑰加密的加密處理方式，近代的加密方法中加密算法是公開的，而密鑰確是保密的

 

50.

加密和解密同用一個密鑰的方式稱爲共享密鑰加密，也被叫作對稱密鑰加密

 

51.

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。

 

52.

HTTPS採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制

 

53.

爲了解決公開密鑰在傳輸中被替換的狀況，可使用由數字證書認證機構（CA，certificate Authority）和其相關機關頒發的公開密鑰證書

 

54.

公鑰證書也可叫作數字證書或直接稱爲證書

 

55.

接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事：1、認證服務器的公開密鑰是真實有效的數字證書認證機構。2、服務器的公開密鑰是值得信賴的。

 

56.

多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰

 

57.

銀行的網上銀行就採用了客戶端證書，在登錄網銀時不只要求用戶確認輸入ID和密碼，還要要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀

 

58.

HTTPS也存在一些問題，那就是當使用SSL時，它的處理速度會變慢

 

59.

SSL的慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗CPU及內存等資源，致使處理速度變慢。

 

60.

要進行HTTPS通訊，證書是必不可少的

 

61.

HTTP/1.1使用的認證方式：

1.BASIC認證（基本認證）

2.DIGEST認證（摘要認證）

3.SSL客戶端認證

4.FormBase（基於表單認證）

 

62.

當請求的資源須要BASIC認證時，服務器會隨狀態碼401返回帶WWW-Authenticate首部字段的響應

 

63.

google的spdy是做用在會話層，也就是SSL和HTTP中間

 

64.

爲了實現WebSocket通訊，須要用到HTTP的Upgrade首部字段，告知服務器通訊協議發生改變，已達到握手的目的，服務器返回狀態碼101

 

65.

成功握手確立WebSocket連接以後，通訊時再也不使用HTTP的數據幀，而採用WebSocket獨立的數據幀