【0179】Android 面試-網絡相關

時間 2019-11-08

標籤 android 面試網絡相關欄目 Android 简体版

原文原文鏈接

1.Http協議的基本認識

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（www.baidu.com）服務器傳輸超文本到本地瀏覽器的傳送協議。css

HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。html

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。前端

目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。java

HTTP協議工做於客戶端-服務端架構爲上。web

瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。面試

Web服務器根據接收到的請求後，向客戶端發送響應信息。算法

2.URI和URL的區別

【uri】編程

【url】跨域

HTTP之URL瀏覽器

HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和創建鏈接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息

URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。

如下面這個URL爲例，介紹下普通URL的各部分組成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL能夠看出，一個完整的URL包括如下幾部分：
1.協議部分：該URL的協議部分爲「http：」，這表明網頁使用的是HTTP協議。在Internet中能夠使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的「//」爲分隔符

2.域名部分：該URL的域名部分爲「www.aspxfans.com」。一個URL中，也能夠使用IP地址做爲域名使用

3.端口部分：跟在域名後面的是端口，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口

4.虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是「/news/」

5.文件名部分：

從域名後的最後一個「/」開始到「？」爲止，是文件名部分

若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分

若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。

本例中的文件名是「index.asp」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名

6.錨部分：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分

7.參數部分：從「？」開始到「#」爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲「boardID=5&ID=24618&page=1」。參數能夠容許有多個參數，參數與參數之間用「&」做爲分隔符

（原文：http://blog.csdn.net/ergouge/article/details/8185219 ）

URI和URL的區別

【總結：URI標記了一個網絡資源，僅此而已； URL標記了一個WWW互聯網資源（用地址標記），並給出了他的訪問地址】

URI，是uniform resource identifier，統一資源標識符，用來惟一的標識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻片斷、程序等都是一個來URI來定位的
URI通常由三部組成：
①訪問資源的命名機制
②存放資源的主機名
③資源自身的名稱，由路徑表示，着重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL能夠用來標識一個資源，並且還指明瞭如何locate這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各類WWW客戶程序和服務器程序上，特別是著名的Mosaic。
採用URL能夠用一種統一的格式來描述各類信息資源，包括文件、服務器的地址和目錄等。URL通常由三部組成：
①協議(或稱爲服務方式)
②存有該資源的主機IP地址(有時也包括端口號)
③主機資源的具體地址。如目錄和文件名等

URN，uniform resource name，統一資源命名，是經過名字來標識資源，好比mailto:java-net@java.sun.com。

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。

URL和URN都是一種URI。

籠統地說，每一個 URL 都是 URI，但不必定每一個 URI 都是 URL。

這是由於 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一個URI實例能夠表明絕對的，也能夠是相對的，只要它符合URI的語法規則。而URL類則不只符合語義，還包含了定位該資源的信息，所以它不能是相對的。
在Java類庫中，URI類不包含任何訪問資源的方法，它惟一的做用就是解析。
相反的是，URL類能夠打開一個到達資源的流。

3.http協議的特色

1.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

2.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

3.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
5.支持B/S及C/S模式。

3.1 http1.1/http2.0 區別

4. HTTP之請求消息Request

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：

請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本。

【if-none-match參數】

【If-None-Match】

做用: If-None-Match和ETag一塊兒工做，工做原理是在HTTP Response中添加ETag信息。

當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。

若是服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地緩存文件。

不然將返回200狀態和新的資源和Etag. 使用這樣的機制將提升網站的性能

例如: If-None-Match: "03f2b33c0bfcc1:0"

實例以下圖

【User-Agent】

做用：告訴HTTP服務器，客戶端使用的操做系統和瀏覽器的名稱和版本.

咱們上網登錄論壇的時候，每每會看到一些歡迎信息，其中列出了你的操做系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這每每讓不少人感到很神奇，

實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它屬性告訴服務器。

例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)

【Accept】

做用：瀏覽器端能夠接受的媒體類型,

例如： Accept: text/html 表明瀏覽器能夠接受服務器回發的類型爲 text/html 也就是咱們常說的html文檔,

若是服務器沒法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable)

通配符 * 表明任意類型

例如 Accept: */* 表明瀏覽器能夠處理全部類型,(通常瀏覽器發給服務器都是發這個)

【referer】

Referer頭域容許客戶端指定請求uri的源資源地址，這能夠容許服務器生成回退鏈表，可用來登錄、優化cache等。

他也容許廢除的或錯誤的鏈接因爲維護的目的被追蹤。

若是請求的uri沒有本身的uri地址，Referer不能被髮送。若是指定的是部分uri地址，則此地址應該是一個相對地址。

【Accept-Encoding】：

做用：瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate），（注意：這不是隻字符編碼）;

例如： Accept-Encoding: gzip, deflate

【Accept-Language】

做用：瀏覽器申明本身接收的語言。

語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等；

例如： Accept-Language: en-us

【If-Modified-Since】

做用：把瀏覽器端緩存頁面的最後修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最後修改時間進行對比。

若是時間一致，那麼返回304，客戶端就直接使用本地緩存文件。若是時間不一致，就會返回200和新的文件內容。客戶端接到以後，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中.

例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT

實例以下圖

5. HTTP之請求消息Response

一樣使用Fiddler 查看Response header, 點擊Inspectors tab ->Response tab-> headers 以下圖所示

咱們也按照Fiddler那樣把header 進行分類，這樣比較清晰也容易記憶。

Cache頭域

Date

做用: 生成消息的具體時間和日期

例如：　Date: Sat, 11 Feb 2012 11:35:14 GMT

Expires

做用: 瀏覽器會在指定過時時間內使用本地緩存

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

cache-control

Cache-Control指定請求和響應遵循的緩存機制。

在請求消息或響應消息中設置Cache-Control並不會修改另外一個消息處理過程當中的緩存處理過程。

請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，

響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

proxy-connection

例如：　Connection: keep-alive 當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接

例如： Connection: close 表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉，當客戶端再次發送Request，須要從新創建TCP鏈接。

給瀏覽器設置了代理（Proxy）。而神器 Fiddler 的抓包原理就是讓瀏覽器請求走它開的本地代理

Vary

做用：

例如: Vary: Accept-Encoding

Cookie/Login 頭域

P3P

做用: 用於跨域設置Cookie, 這樣能夠解決iframe跨域訪問cookie的問題

例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

Set-Cookie

做用：很是重要的header, 用於把cookie 發送到客戶端瀏覽器，每個寫入cookie都會生成一個Set-Cookie.

例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

Entity頭域

ETag

做用: 和If-None-Match 配合使用。（實例請看上節中If-None-Match的實例）

例如: ETag: "03f2b33c0bfcc1:0"

Last-Modified:

做用：用於指示資源的最後修改日期和時間。（實例請看上節的If-Modified-Since的實例）

例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

Content-Type

做用：WEB服務器告訴瀏覽器本身響應的對象的類型和字符集,

例如:

Content-Type: text/html; charset=utf-8

Content-Type:text/html;charset=GB2312

Content-Type: image/jpeg

Content-Length

指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程當中，Content-Length的方式要預先在服務器中緩存全部數據，而後全部數據再一古腦兒地發給客戶端。

例如: Content-Length: 19847

Content-Encoding

WEB服務器代表本身使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。

例如：Content-Encoding：gzip

Content-Language

做用： WEB服務器告訴瀏覽器本身響應的對象的語言者

例如： Content-Language:da

Miscellaneous 頭域

Server:

做用：指明HTTP服務器的軟件信息

例如:Server: Microsoft-IIS/7.5

X-AspNet-Version:

做用：若是網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本

例如: X-AspNet-Version: 4.0.30319

X-Powered-By:

做用：表示網站是用什麼技術開發的

例如： X-Powered-By: ASP.NET

Location頭域

Location

做用：用於重定向一個新的位置, 包含新的URL地址

實例請看304狀態實例

6.狀態碼

Response 消息中的第一行叫作狀態行，由HTTP協議版本號，狀態碼，狀態消息三部分組成。

狀態碼用來告訴HTTP客戶端,HTTP服務器是否產生了預期的Response.

HTTP/1.1中定義了5類狀態碼，狀態碼由三位數字組成，第一個數字定義了響應的類別

1XX 提示信息 - 表示請求已被成功接收，繼續處理

2XX 成功 - 表示請求已被成功接收，理解，接受

3XX 重定向 - 要完成請求必須進行更進一步的處理

4XX 客戶端錯誤 - 請求有語法錯誤或請求沒法實現

5XX 服務器端錯誤 - 服務器未能實現合法的請求

看看一些常見的狀態碼

200 OK

最多見的就是成功響應狀態碼200了，這代表該請求被成功地完成，所請求的資源發送回客戶端

以下圖，打開博客園首頁

302 Found

重定向，新的URL會在response 中的Location中返回，瀏覽器將會自動使用新的URL發出新的Request

例如在IE中輸入， http://www.baidu.com. HTTP服務器會返回302， IE取到Response中Location header的新URL, 又從新發送了一個Request.

304 Not Modified

表明上次的文檔已經被緩存了，還能夠繼續使用，

例如打開博客園首頁, 發現不少Response 的status code 都是304

提示：　若是你不想使用本地緩存能夠用Ctrl+F5 強制刷新頁面

400 Bad Request 客戶端請求與語法錯誤，不能被服務器所理解

403 Forbidden 服務器收到請求，可是拒絕提供服務

404 Not Found

請求資源不存在（輸錯了URL）

好比在IE中輸入一個錯誤的URL， http://www.cnblogs.com/tesdf.aspx

500 Internal Server Error 服務器發生了不可預期的錯誤

503 Server Unavailable 服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

7.常見的易混淆的問題

7.1 http1.0/http 1.1 區別

HTTP1.0產生的背景
超文本傳輸協議（HyperText Transfer Protocol）伴隨着計算機網絡和瀏覽器的誕生，HTTP1.0也隨之而來，處於計算機網絡中的應用層。

HTTP1.0所作的優化
咱們知道HTTP協議（應用層）是創建在TCP協議（傳輸層）之上，因此的HTTP協議的優化與瓶頸都是基於TCP協議自己的，

好比說咱們的TCP創建鏈接須要三次握手，斷開鏈接須要四次揮手，以及每次鏈接帶來的延遲時間，這些都是能夠優化的角度。
早在HTTP1.0創建的開始，主要是將HTML文檔從Web服務器傳輸到客服端瀏覽器上，隨着時間的推移，前端發展到如今，

HTML文檔變得更加複雜了，裏面可能有不少圖片以及大量的css樣式和js代碼來顯示界面，無論這些內容如何的變化，本質上都是基於HTTP協議的。

能夠從如下幾個方面進行優化

帶寬：帶寬這塊目前基本已經解決了，如今已經不是撥號上網的時代了，在撥號上網時能夠會成爲影響網絡請求的重要因素，如今網絡基礎設施已經獲得質的升級，基本不會擔憂因帶寬帶來影響網速問題。

延遲（三個方面）

【1】瀏覽器阻塞：瀏覽器對於同一個域名，同時只能有4個鏈接，就是說瀏覽器由於一些網絡緣由阻塞請求，不一樣瀏覽器的鏈接數是有限制的，當請求數達到瀏覽器最大鏈接數時，後續的請求就會被阻塞，直到前面的請求執行完畢後，纔會接着後面鏈接請求。

【2】DNS查詢：瀏覽器須要知道目標服務器的IP才能創建鏈接；將咱們的域名解析IP的地址就是所謂的DNS請求，一般能夠利用DNS緩存來達到減小請求的目的，好比說反覆查詢某個域名的IP地址，不須要每次經過這個請求，而是DNS緩存就能夠達到這個目的。

【3】創建鏈接：三次握手；HTTP協議是基於在TCP協議之上的，瀏覽器最快最快也只能在第三次握手後才能夠攜帶HTTP請求報文達到真正創建鏈接的目的，可是這些鏈接是沒法複用的，這就致使了每次請求都要進行三次握手，這是比較頭痛的地方，尤爲是在一些高延遲的場景，三次握手的延遲會更加明顯。

7.2 HTTP1.1與HTTP1.0的具體區別

【緩存】緩存策略具備較大的不一樣

HTTP/1.0中，If-Modified-Since頭域使用的是絕對時間戳，精確到秒，但使用絕對時間會帶來不一樣機器上的時鐘同步問題。

而HTTP/1.1中引入了一個ETag頭域用於重激活機制，它的值entity tag能夠用來惟一的描述一個資源。

請求消息中能夠使用If-None-Match頭域來匹配資源的entitytag是否有變化。

【帶寬優化及網絡鏈接的使用】

HTTP/1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了。例如，客戶端只須要顯示一個文檔的部份內容，又好比下載大文件時須要支持斷點續傳功能，而不是在發生斷連後不得不從新下載完整的包。

HTTP/1.1中在請求消息中引入了range頭域，它容許只請求資源的某個部分。在響應消息中Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。

HTTP/1.1加入了一個新的狀態碼100（Continue）。客戶端事先發送一個只帶頭域的請求，若是服務器由於權限拒絕了請求，就回送響應碼401（Unauthorized）；

若是服務器接收此請求就回送響應碼100，客戶端就能夠繼續發送帶實體的完整請求了。

注意，HTTP/1.0的客戶端不支持100響應碼。但可讓客戶端在請求消息中加入Expect頭域，並將它的值設置爲100-continue。

【Host頭的處理】

在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。

HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。此外，服務器應該接受以絕對路徑標記的資源請求。

【長鏈接】

HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。

此外，因爲大多數網頁的流量都比較小，一次TCP鏈接不多能經過slow-start區，不利於提升帶寬利用率。

HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。

例如：一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。

HTTP 1.1還容許客戶端不用等待上一次請求結果返回，就能夠發出下一次請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間。

在HTTP/1.0中，要創建長鏈接，能夠在請求消息中包含Connection: Keep-Alive頭域，若是服務器願意維持這條鏈接，在響應消息中也會包含一個Connection: Keep-Alive的頭域。同時，能夠加入一些指令描述該長鏈接的屬性，如max，timeout等。

7.3 http1.1和http1.0存在的問題

a.HTTP1.x在傳輸數據時，每次都須要從新創建鏈接，無疑增長了大量的延遲時間

b.HTTP1.x在傳輸數據時，全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份

c.HTTP1.x在使用時，header裏攜帶的內容過大，在必定程度上增長了傳輸的成本

d.雖然HTTP1.x支持了keep-alive,來彌補屢次建立鏈接產生的延遲，可是keep-alive使用多了一樣會給服務端帶來大量的性能壓力

7.4 get/post方法的區別

get和post是HTTP與服務器交互的方式，
說到方式，其實總共有四種：put，delete，post，get。
他們的做用分別是對服務器資源的增，刪，改，查。
因此，get是獲取數據，post是修改數據。

1)提交的數據

get把請求的數據放在url上，即HTTP協議頭上，其格式爲：
以?分割URL和傳輸數據，參數之間以&相連。
數據若是是英文字母/數字，原樣發送，
若是是空格，轉換爲+，
若是是中文/其餘字符，則直接把字符串用BASE64加密，及「%」加上「字符串的16進制ASCII碼」。

post把數據放在HTTP的包體內（requrest body）

2)提交的數據大小是否有限制

get提交的數據最大是2k（原則上url長度無限制，那麼get提交的數據也沒有限制咯？限制實際上取決於瀏覽器，(大多數)瀏覽器一般都會限制url長度在2K個字節，即便(大多數)服務器最多處理64K大小的url。也沒有卵用。）。
post理論上沒有限制。實際上IIS4中最大量爲80KB，IIS5中爲100KB。

3)取得變量的值使用的方法不同

get使用的方法：Request.QueryString

post使用的方法： Request.From

4)安全問題

GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留

GET產生一個TCP數據包，瀏覽器會把http header和data一併發送出去，服務器響應200(返回數據); 
POST產生兩個TCP數據包，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok(返回數據)。

GET在瀏覽器回退時是無害的，POST會再次提交請求。

GET產生的URL地址能夠被Bookmark，而POST不能夠。

GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。

GET請求只能進行url編碼，而POST支持多種編碼方式。

GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。

GET只接受ASCII字符的參數的數據類型，而POST沒有限制

那麼，post那麼好爲何還用get？get效率高！。

8. session和cookie的區別

8.1 cookie

【cookie】cookie技術是客戶端的解決方案，cookie就是由服務器發送給客戶端的特殊信息

Cookie技術是客戶端的解決方案，Cookie就是由服務器發給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，

而後客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息

讓咱們說得更具體一些：當用戶使用瀏覽器訪問一個支持Cookie的網站的時候，用戶會提供包括用戶名在內的我的信息而且提交至服務器；

接着，服務器在向客戶端回傳相應的超文本的同時也會發回這些我的信息，固然這些信息並非存放在HTTP響應體（Response Body）中的，

而是存放於HTTP響應頭（Response Header）

當客戶端瀏覽器接收到來自服務器的響應以後，瀏覽器會將這些信息存放在一個統一的位置，

對於Windows操做系統而言，咱們能夠從： [系統盤]:\Documents and Settings[用戶名]\Cookies目錄中找到存儲的Cookie；

自此，客戶端再向服務器發送請求的時候，都會把相應的Cookie再次發回至服務器。而此次，Cookie信息則存放在HTTP請求頭（Request Header）了。

有了Cookie這樣的技術實現，服務器在接收到來自客戶端瀏覽器的請求以後，就可以經過分析存放於請求頭的Cookie獲得客戶端特有的信息，從而動態生成與該客戶端相對應的內容。

一般，咱們能夠從不少網站的登陸界面中看到「請記住我」這樣的選項，若是你勾選了它以後再登陸，那麼在下一次訪問該網站的時候就不須要進行重複而繁瑣的登陸動做了，而這個功能就是經過Cookie實現的。

----每次請求客戶端都會把cookies放在請求頭請求過來

HTTP協議是無狀態的協議。一旦數據交換完畢，客戶端與服務器端的鏈接就會關閉，再次交換數據須要創建新的鏈接。這就意味着服務器沒法從鏈接上跟蹤會話。

即用戶A購買了一件商品放入購物車內，當再次購買商品時服務器已經沒法判斷該購買行爲是屬於用戶A的會話仍是用戶B的會話了。

要跟蹤該會話，必須引入一種機制。

Cookie就是這樣的一種機制。它能夠彌補HTTP協議無狀態的不足。在Session出現以前，基本上全部的網站都採用Cookie來跟蹤會話。

因爲HTTP是一種無狀態的協議，服務器單從網絡鏈接上無從知道客戶身份。怎麼辦呢？

就給客戶端們頒發一個通行證吧，每人一個，不管誰訪問都必須攜帶本身通行證。這樣服務器就能從通行證上確認客戶身份了。這就是Cookie的工做原理。

Cookie其實是一小段的文本信息。客戶端請求服務器，若是服務器須要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。

客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。

服務器檢查該Cookie，以此來辨認用戶狀態。

服務器還能夠根據須要修改Cookie的內容。

8.2 session

除了使用Cookie，Web應用程序中還常用Session來記錄客戶端狀態。

Session是服務器端使用的一種記錄客戶端狀態的機制，使用上比Cookie簡單一些，相應的也增長了服務器的存儲壓力。

8.2.1 什麼是Session

Session是另外一種記錄客戶狀態的機制，不一樣的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。

客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session。

客戶端瀏覽器再次訪問時只須要從該Session中查找該客戶的狀態就能夠了。

若是說Cookie機制是經過檢查客戶身上的「通行證」來肯定客戶身份的話，那麼Session機制就是經過檢查服務器上的「客戶明細表」來確認客戶身份。

Session至關於程序在服務器上創建的一份客戶檔案，客戶來訪的時候只須要查詢客戶檔案表就能夠了。

8.3 session和cookie的區別

【1】存放位置不一樣：cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

【2】存取方式不一樣：cookie存放的是ascii字符串，session中能夠存取任何類型的數據；

【3】cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session

【4】cookie會在客戶端存放很長的時間；可是sessio依賴與session id，若是id爲-1，若是關閉瀏覽器，則session會失效了；

【5】對服務器形成的壓力不一樣：session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE。

【6】將登錄信息等重要信息存放爲SESSION；其餘信息若是須要保留，能夠放在COOKIE中

9.HTTPS

HTTP & HTTPS網絡協議重點總結（基於SSL/TLS的握手、TCP/IP協議基礎、加密學）

本文以總結的形式，先大致介紹TCP／IP協議總體組成，再擇其應用層上的HTTP協議進行詳細總結，繼而拓展知識點講解加密學，過渡到HTTPS協議的學習，除去網絡知識必備掌握的三次握手、四次揮手，另需瞭解基於SSL/TLS的握手，也是重要的一個環節。

本文涉及到的知識點以下：

網絡基礎TCP/IP
HTTP協議基礎與重點
加密與簽名
HTTPS協議（基於SSL/TLS的握手）

（若想要詳細瞭解TCP三次握手、四次揮手相關知識點，可看此篇博客：
深刻淺出之 TCP協議（三次握手與四次揮手、超時重發、流量控制、擁塞控制、與UDP區別））

9.1 . 網絡基礎TCP/IP

在正式介紹HTTP網絡知識以前，先追其根源—–TCP/IP協議族，一般使用的網絡是在TCP/IP協議族的基礎上運做的，而HTTP屬於它內部的一個子集，因此先了解有關TCP/IP有關知識，爲HTTP作鋪墊。

Transmission Control Protocol/Internet Protocol的簡寫，中譯名爲傳輸控制協議/因特網互聯協議，又名網絡通信協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。

1. TCP/IP協議分層管理

（1）協議（protocal）

計算機與網絡相互通訊，雙方必須基於相同的方法，例如由哪一方先發起通訊、使用哪一種語言進行通訊、如何結束通訊等都須要事先規定。不一樣的硬件、OS之間的通訊都須要一種規則，就是協議（protocal）。

（2）TCP/IP協議定義

協議中存在各類內容，例如從電纜規格到IP地址的選定方法、雙方創建通訊的順序，以及web頁面顯示須要處理的步驟等。

以上這種與互聯網相關聯的協議集合起來總稱爲 TCP/IP（有的說法是TCP/IP是指TCP和IP這兩種協議，還有一種說法是TCP/IP是在IP協議的通訊過程當中使用的協議族的統稱）

（3）分層管理

TCP/IP協議族裏重要的一點是分層，可分爲：應用層、傳輸層、網絡層、數據鏈路層。

其實層次化是有它的好處，若是互聯網只有一個協議統籌，某個地方須要改動時須要將全部部分換掉，而分層以後只需替換變更層便可。每一層也只需考慮本身的任務便可。

應用層：應用層決定了向用戶提供應用服務時通訊的活動

TCP/IP協議族內預存了各種通用的應用服務，例如FTP（File Transfer Protocol文件傳輸協議）和DNS（Domain Name System域名系統）服務就是其中兩類，HTTP協議也處於改層。

傳輸層：傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。

在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol傳輸控制協議）和UDP（User Data Protocol用戶數據報協議）。

網絡層（網絡互連層）：網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（傳輸路線）到達對方計算機，並把數據包傳送給對方。

與對方計算機之間經過多臺計算機或網絡設備進行傳輸時，網絡層所起做用就是在衆多選項內選擇一條傳輸路線。

鏈路層（網絡接口層）：用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、網卡，以及光纖等物流可見部分。硬件上的範疇均在鏈路層的做用範圍內。

2. TCP/IP通訊傳輸流

利用TCP/IP協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端的順序從應用層往下走，接收端則往應用層上走。

舉個HTTP的例子：做爲發送端的客戶端在應用層（HTTP協議）發出一個想看某個Web頁面的HTTP請求。

爲了傳輸方便，在傳輸層（TCP協議）把應用層處收到的數據（HTTP請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層。
在網絡層（IP協議），增長做爲通訊目的地的MAC地址後轉發給鏈路層。這樣發送網絡的通訊請求就準備徹底了。
接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸層到應用層，纔算真正接收到由客戶端發送過來的HTTP請求。

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。

這種包裝數據信息的行爲稱爲封裝（encapsulate）

3. 與HTTP關係密切的協議：IP、TCP和DNS

（1）負責傳輸的IP協議

定義做用

定義： IP（Internet Protocol）網際協議位於網絡層。IP佔據了TCP/IP協議族的「一半」，可見其重要性，切勿將IP同IP地址搞混，「IP」是一種協議的名稱。
做用：把各類數據包傳送給對方。要保證確實傳送到對方那裏，需知足各種條件，其中兩個重要的條件：（IP地址能夠和MAC地址進行配對，IP地址可變換，但MAC地址基本上不會改變。）
- IP地址：指明節點被分配的位置。
- MAC地址（Media Access Control Address）：指網卡所屬的固定地址。

使用ARP協議憑藉MAC地址進行通信

IP間的通訊依賴MAC地址。在網絡上，通訊的雙方在同一局域網（LAN）內的狀況不多，一般是通過多臺計算機和網絡設備中轉才能鏈接到對方。

在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時會採用ARP協議（Address Resolution Protocol），它是一種用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址。

沒法全面掌握互聯網中的傳輸情況

在到達通訊目標前的中轉過程當中，那些計算機和路由器等網絡設備只能獲悉很粗略的傳輸路線。

這種機制稱爲路由選擇（rounting），有點像快遞送貨，寄快遞時把貨物送到集散中心，便可知道是否肯收件，接着檢查送達地址，明確下一站送達的集散中心，下一個集散中心再判斷是否能送達目的地。（其中的中轉過程沒法掌握，因此沒法掌握互聯網中的細節。）

（2）確保可靠性的TCP協議

TCP位於傳輸層，提供可靠的字節流服務（Byte Stream Service）。

字節流服務：爲了方便傳輸，將大塊數據分割以報文段（segment）爲單位的數據包進行管理。
可靠的傳輸服務：可以把數據準確可靠地傳給對方。

TCP協議爲了更容易傳送大數據才把數據分割，並且TCP協議可以確認數據最終是否送達到對方。

確保數據能到達目標

爲了準確無誤地將數據送達目標處，TCP協議採用了三次握手（three-way handshaking）策略。

用TCP協議將數據包送出去後，TCP必定會向對方確認是否成功送達。

若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的順序包。

握手過程

定義：三次握手，是指創建一個TCP鏈接時，須要客戶端和服務器總共發送3個包。
目的：是鏈接服務器指定端口，創建TCP鏈接,並同步鏈接雙方的序列號和確認號並交換 TCP 窗口大小信息

在socket編程中，客戶端執行connect()時，將觸發三次握手。

第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

完成三次握手，客戶端與服務器開始傳送數據。

（若想要詳細瞭解TCP三次握手、四次揮手相關知識點，請看此篇博客：
深刻淺出之 TCP協議（三次握手與四次揮手、超時重發、流量控制、擁塞控制、與UDP區別））

（3）負責域名解析的DNS服務

DNS（Domain Name System）服務是和HTTP協議同樣位於應用層的協議，它提供域名到IP地址之間的解析服務。

計算機不只能夠被賦予IP地址，也能夠被賦予主機名和域名。

例如 www.baidu.com。用戶常用這種方式來訪問對方計算機，但要讓計算機去理解名稱就顯得困難，所以DNS服務應運而生，

DNS協議提供經過域名查找IP地址，或逆向從IP地址反查域名的服務。

4. 各類協議與HTTP協議的關係

這張圖是客戶端向服務器請求資源時的過程，在HTTP通訊過程當中包含了IP協議、TCP協議、DNS服務，發揮着各自的做用，查看下圖。

二. Http協議

1. 基本概念

（1）HTTP協議及特色

協議：指計算機通訊網絡中兩臺計算機之間進行通訊所必須共同遵照的規定或規則。
HTTP協議：超文本傳輸協議（HTTP）是一種通訊協議，它容許將超文本標記語言（HTML）文檔從Web服務器傳送到客戶端的瀏覽器。

如上圖，其實HTTP協議是基於TCP/IP協議來傳遞數據，從服務器端獲取到數據，是C/S架構——客戶端到服務端通訊的接口。瀏覽器做爲HTTP協議下的客戶端，經過URL發送請求到服務端，服務端作出響應將內容返回給瀏覽器顯示，這就是一個基本的C/S架構的HTTP協議。

HTTP協議特色：

支持客戶/服務器模式。
簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、 HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
靈活： HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。限制地每次鏈接只處理一個請求，處理完請求後收到客戶端應答從而斷開鏈接。採用這種方式可節省傳輸時間。
無狀態： HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

（2） Http 版本區別

（3）HTTP請求報文和響應報文

HTTP請求報文主要由請求行、請求頭、空行、請求正文（GET方式無請求正文）4部分組成。

請求行：由請求方法、URL和協議版本3部分組成。
請求頭：爲請求報文添加一些信息，由「名／值」組成。
空行：請求頭的最後會有一個空行，表明請求頭部結束，接下來爲請求正文。此部分不可少。
請求正文

HTTP響應報文主要由狀態行、響應頭、空行、響應正文4部分組成。

狀態行：由狀態碼、狀態碼描述和協議版本3部分組成。
響應頭：爲響應報文添加一些信息，由「名／值」組成。
空行：頭的最後會有一個空行，表明響應頭部結束，接下來爲響應正文。此部分不可少。
響應正文

（4） Http的請求方式總結

方式名稱	含義
GET	請求獲取Request-URI所標識的資源
POST	在Request-URI所標識的資源後附加新的數據
HEAD	請求獲取由Request-URI所標識的資源的響應信息報頭
PUT	請求服務器存儲一個資源，並用Request-URI做爲其標識
DELETE	請求服務器刪除Request-URI所標識的資源
TRACE	請求服務器回送收到的請求信息，主要用於測試或診斷
CONNECT	保留未來使用
OPTIONS	請求查詢服務器的性能，或者查詢與資源相關的選項

HEAD、GET、OPTIONS和TRACE是安全的方法，由於它們只從服務器得到資源而不對服務器作任何修改，可是前三個在用戶端不安全，POST相對安全，但POST會影響服務器的資源。TRACE方法對於服務端盒用戶端必定是安全的。

（5）請求頭信息

請求頭	說明
User-Agent	中文名爲用戶代理，是Http協議中的一部分，它是一個特殊字符串頭，是一種向訪問網站提供你所使用的瀏覽器類型及版本、操做系統及版本、瀏覽器內核、等信息的標識
Referer	先前網頁的地址，當前請求網頁緊隨其後,即來路
Cache-Control	指定請求和響應遵循的緩存機制
Connection	表示是否須要持久鏈接。（HTTP 1.1默認進行持久鏈接）
If-Match	只有請求內容與實體相匹配纔有效
If-Modified-Since	若是請求的部分在指定時間以後被修改則請求成功，未被修改則返回304代碼
If-None-Match	若是內容未改變返回304代碼，參數爲服務器先前發送的Etag，與服務器迴應的Etag比較判斷是否改變

這裏只介紹舉例部分重要的請求響應頭，關於更詳細信息可看：
http://tools.jb51.net/table/http_header

（6）響應頭信息

應答頭	說明
Content-Encoding	文檔的編碼（Encode）方法。只有在解碼以後才能夠獲得Content-Type頭指定的內容類型。
Content-Type	表示後面的文檔屬於什麼MIME類型。
Date	當前的GMT時間。你能夠用setDateHeader來設置這個頭以免轉換時間格式的麻煩。
Expires	過時時間
Last-Modified	檔的最後改動時間。客戶能夠經過If-Modified-Since請求頭提供一個日期，該請求將被視爲一個條件GET，只有改動時間遲於指定時間的文檔纔會返回，不然返回一個304（Not Modified）狀態。

.
（7）狀態碼信息

HTTP狀態碼分類

分類	描述
1**	信息，服務器收到請求，須要請求者繼續執行操做
2**	成功，操做被成功接收並處理
3**	重定向，須要進一步的操做以完成請求
4**	客戶端錯誤，請求包含語法錯誤或沒法完成請求
5**	服務器錯誤，服務器在處理請求的過程當中發生了錯誤

較經常使用狀態碼

200 - 請求成功
301 - 資源（網頁等）被永久轉移到其它URL
404 - 請求的資源（網頁等）不存在
500 - 內部服務器錯誤

2. Http請求方式Get和Post的區別

安全冪等性質

GET通常用於獲取或者查詢資源信息，這就意味着它是冪等的（對同一個URL的屢次請求返回一樣的結果）和安全的（沒有修改資源的狀態）
POST通常用於更新資源信息，既不是安全，也非冪等。

參數存放位置

GET方法中，客戶端把要發送的數據添加到URL後面（即把數據放到HTTP協議頭中，GET是經過URL請求數據的），使用「？」鏈接，參數之間使用「&」鏈接。注意：HTTP協議中並無對URL長度進行限制，可是瀏覽器和服務器會對其限制！（面試中常常會問到URL長度限制問題，必定要明白協議中並未對此規定！）
POST是將須要傳遞的數據放到HTTP請求報文的消息體中（一樣，協議未對此部分大小進行限制），不過傳送的數據量比GET更大且安全性更高（若不對數據進行加密，可以使用抓包軟件進行獲取）。

瀏覽器緩存

GET請求的數據會被瀏覽器緩存起來，留下歷史記錄。
POST提交的數據不會。

3. 爲何HTTP是無狀態的？如何保持狀態？

HTTP無狀態：是指協議對於事務處理沒有記憶能力，不能保存每次客戶端提交的信息，即當服務器返回應答後，這次事務的全部消息會被丟掉。即便客戶端發來一個新的相同的請求，服務器沒法知道它是否與上次請求有聯繫。

舉個例子：一個包含多個圖片的網頁瀏覽步驟：

創建鏈接，客戶端發送一個網頁請求，服務端返回一個HTML頁面（一個純文本頁面），關閉鏈接。
瀏覽器解析HTML文件，遇到圖片標記獲得URL，此時客戶端和服務器再創建鏈接，客戶端發送一個圖片請求，服務器返回圖片應答，關閉鏈接。（涉及到無狀態定義，對於服務器而言，即便是同一個客戶端請求，無記憶能力沒法識別）

優缺點

優勢：服務器不用爲每一個客戶端鏈接分配內存來記憶大量狀態，也不用在客戶端失去鏈接時去清除內存，節省服務器端資源。
缺點：若是後續處理須要前面的信息，客戶端必須重傳，可能致使每次鏈接傳送的數據量增大。

解決辦法

針對這些問題，能夠採用會話跟蹤技術，即把狀態保存在服務器，只發送回一個標識符，瀏覽器在下次提交中把這個標識符發送過來，這樣能夠定位存儲在服務器上的狀態信息。技術有如下：

COOKIE
SESSION
URL重寫
做爲隱藏域嵌入HTML表單中

4. cookie與session

（1）Cookie

定義

Cookie技術是客戶端的解決方案，由服務器發送給客戶端的特殊信息，存放在response的header中，這些信息以文本文件方式存放在客戶端，由客戶端每次向服務器發送請求時帶上，此時是存放在request的header中。

以下圖，Cookie的設置可分爲如下幾個步驟：

客戶端向服務端Request請求。
服務器在response的header中設置Cookie，發送給客戶端。
客戶端會將請求request和Cookie一塊兒打包發送給服務端。
服務端會根據Cookie判斷將response返回給客戶端。

由於HTTP協議「無狀態」的特色，在請求完畢後會關閉鏈接，再次交換數據須要創建新的鏈接，沒法跟蹤會話。Cookie機制的引入正好彌補了HTTP協議「無狀態」的缺陷。

工做原理

因爲HTTP協議是「無狀態」的，因此服務器沒法從網絡上獲取用戶的真實身份。

解決辦法：此時客戶端給服務端發一個「通行證」，它是一個惟一的標識，不管哪一個用戶訪問服務器須要帶上此標識，這樣服務器便可辨識用戶，這也就是Cookie的原理—–我的身份標識。

總結

在客戶端向服務端請求時，若服務器要記錄該用戶信息，就發送一個攜帶cookie的response，客戶端會保留此cookie，當客戶端須要再次請求時，將請求URL和Cookie信息一同打包發送給服務端，此時服務器便可根據cookie辨認狀態再作出響應（也可修改）。

總而言之，Cookie就是用戶識別標誌，保存在客戶端！

（2）session

定義

Session是另外一種記錄客戶狀態的機制，不一樣的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器行。客戶端瀏覽器訪問的時候，服務器把客戶端信息以某種形式記錄在服務器上。

注意：當客戶端瀏覽器再次請求服務器時是不須要攜帶信息的，在服務器上已有記錄。

工做原理

在服務端運行程序時建立Session
在建立Session的同時，服務器會爲該Session生成惟一的Session ID
在Session被建立後，能夠調用相關方法往Session中添加內容，注意發送到客戶端的只有Session ID
當客戶端再次發送請求時，會將Session ID帶上，服務器接受到請求以後就會依據ID確認用戶身份，找到相應的Session。

（3）二者的區別

存放位置不一樣
- Cookie：保存在客戶端；
- Session：保存在服務端；
存取方式不一樣
- Cookie：只能保存ASCII碼字符串；
- Session：可保存任何數據；
安全性（隱私策略）不一樣
- Cookie：因爲它存放在瀏覽器中，因此對客戶端是可見的，客戶端的程序有可能修改內容；
- Session：存放在服務端，不存在敏感信息泄露；
有效期不一樣
- Cookie：客戶端通常設置有效期較長，這樣可保存較長時間；
- Session：設置成-1後，在用戶關閉瀏覽器後，session就會失效；
對服務器形成的壓力不一樣
- Cookie：保存在客戶端，不佔用服務器內存；
- Session：因爲它存放在服務端，多個用戶併發訪問服務器時，會產生多個session，十分消耗內存；

5. HTTP的短鏈接和長鏈接的原理

在HTTP1.0中默認採用的是短鏈接，即瀏覽器和服務器每進行一次HTTP操做須要進行一次鏈接，任務結束時中斷。若客戶端訪問的某個HTML或其餘類型的Web中又包含其餘Web資源，例如JS文件、圖像文件、CSS文件，那麼每次遇到以一個Web資源都會創建一個HTTP會話，進行三次握手，十分耗費資源。所以，經過在Request中增長「Connection：keep-alive」可支持長鏈接。

當HTTP採用長鏈接時的數據交互流程以下：

客戶端發出request，其中該版本號爲1.0，而且在request中包含了一個header：「Connection：keep-alive」。
服務器收到該請求的長鏈接後，將會在response加上「Connection：keep-alive」，同時不會關閉已創建的TCP鏈接。
同時，客戶端收到response中的header，發現是一個長鏈接，一樣不會關閉已創建的TCP鏈接。

在HTTP1.1起，默認使用長鏈接，來保持鏈接特性，即在請求頭和響應頭中默認加入「Connection：keep-alive」。HTTP長鏈接利用同一個TCP鏈接處理多個HTTP請求和響應。

Keep-Alive不會永久保持鏈接，有一個保持時間，能夠在不一樣的服務器中設定時間，實現長鏈接要求客戶端和服務器都支持長鏈接。

三. 加密與簽名

在講解HTTPS以前須要瞭解一些預備知識，即加密與簽名。

1. 密碼學

若是不對傳輸數據進行加密，很容易被第三方竊取或篡改，因此加密是保護數據的措施。最多見的就是對數據進行MD5加密，獲取數據後再將其解密。

（1）組成

所以，加密包含算法和密鑰這兩個元素，二者結合會使原有數據加密爲明文，而加密分爲如下兩個部分：

對稱加密
- 定義：加密數據用的密鑰，跟解密數據用的密鑰是同樣的。
- 優點：此定義決定了它的特色：加密和解密過程效率很是高
- 劣勢：可是缺點也很明顯，即雙方執同一個密鑰，必需要確保密鑰的安全性，帶來的技術成本很高。
不對稱加密：其中含有兩個密鑰，一個是一方保管的私有密鑰，另外一個是雙方公有的公有密鑰。這種方式決定了發送祕文的一方先獲取對方的公有密鑰，經過算法進行處理，對方收到加密數據後，使用本身的私有密鑰進行解密。

（2）數字證書

定義：數字證書就是互聯網通信中標誌通信各方身份的一串數字。

產生的緣由：請求方如何肯定它想要的公鑰未通過第三方篡改，必定是從目標主機而來的？此時須要一個權威機構來發放密鑰，來解決數字證書的安全問題。

頒發過程：首先用戶要產生本身的密鑰，和公有密鑰一塊兒交給認證中心，認證中心覈實身份以後會將確認中心發給用戶，會頒發一個數字證書，含有密鑰信息。

2. 密鑰

（1）定義

密鑰是一種參數，它是在使用密碼cipher算法過程當中輸入的參數。同一個明文在相同的密碼算法和不一樣的密鑰計算下會產生不一樣的密文。密鑰纔是決定加密數據是否安全的重要參數。

（2）明文到密文的加密過程

（3）密鑰組成

對稱密鑰
- 定義：又稱爲共享密鑰加密，對稱密鑰在加密、解密過程當中使用的密鑰相同，常見對稱加密算法有：DES、3DES、AES、RC五、RC6。
- 優勢：計算速度快；
- 缺點：密鑰須要在通信的兩端共享，存在安全性問題；
不對稱密鑰
- 定義：又稱爲公開密鑰加密。服務端會生成一對密鑰，一個私鑰保存在服務端，僅本身知道，另外一個公鑰能夠自由發佈供任何人使用。常見的是RSA算法。
- 優勢：無需在客戶端和服務端之間共享密鑰，只要私鑰不發給任何用戶，即便公鑰在網絡上被截獲，也沒法破解數據。

（4）RSA加密簡單過程

服務端生成配對的公鑰和私鑰；
密鑰保存在服務端，公鑰發送給客戶端；
客戶端使用公鑰加密明文傳輸給服務端；
服務端使用私鑰解密密文獲得明文。

3. 數字簽名

首先思考一個問題：瀏覽器和服務器直接傳輸數據時，有可能被黑客篡改，如何保證數據安全性？須要引出此部分核心——數字簽名。

（1）定義

數字簽名是用於驗證傳輸內容是不是真實服務器發送的數據，是否被篡改過，主要驗證這兩件事，是非對稱加密的一種應用場景，但它是反過來用祕鑰加密，經過與之配對的公鑰解密。

（2）加密過程

第一步：查看上圖，服務端將報文進行哈希處理後生成摘要信息，摘要信息使用私鑰加密以後纔會生成簽名，而服務端將簽名連同報文一塊兒發送給客戶端。

第二步：查看上圖，客戶端接收到數據後，把簽名提取出來用公鑰解密，若是能正常將Digest2 解密出來，便可確認是對方發的。
第三步：客戶端把報文Text提取出來作一樣的哈希出來，獲得的摘要信息Digest1，再與以前解密出來的Digest2 對比。

四. HTTPS（TLS與SSL握手）

1. HTTP的缺點

在瞭解HTTP特色以後，不可忽視的是它的不足之處：

通訊使用明文（不加密），內容可能被監聽；
不驗證通訊方的身份，有可能遭遇假裝；
沒法證實報文的完整性，有可能已遭篡改；

以上三個問題不只在HTTP上出現，其它未加密的協議也存在這些問題。除此以外，還有其它的缺點。

（1）通訊使用明文可能會被竊聽

因爲HTTP自己不具有加密功能，因此沒法作到對通訊總體（使用HTTP協議通訊的請求和響應的內容）進行加密，即HTTP報文使用明文的方式發送。

TCP/IP是可能被竊聽的網絡

按照TCP/IP 協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。

加密處理防止被竊聽

防止竊聽保護信息的幾種對策中，最爲普及的就是加密技術，加密對象有如下幾個：

通訊的加密： HTTP協議中沒有加密機制，能夠經過SSL（Secure Socket Layer安全套接層）或TLS（Transport Layer Security安全傳輸層協議）的組合使用，加密HTTP的通訊內容。用SSL創建安全通訊線路以後，就能夠在這條線路上進行HTTP通訊。與SSL組合使用的HTTP被稱爲HTTPS。
內容的加密：對HTTP協議傳輸內容自己加密。客戶端須要對HTTP報文進行加密處理後再發送請求。爲了作到有效的內容加密，前提是客戶端和服務器同時具有加密和解密機制。（該方法不一樣於SSL或TLS將整個通訊線路加密處理，因此內容有篡改的風險，後續講解）

（2）不驗證通訊方的身份可能遭遇假裝

在HTTP協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求，服務器只有收到請求，不管是誰都返回響應，所以存在如下隱患：

沒法肯定請求發送至目標的Web服務器是不是真實返回響應的服務器。（多是假裝的）
沒法肯定響應返回到客戶端是不是真實接收響應的客戶端。（多是假裝的）
沒法肯定正在通訊的對方是否具有訪問權限。由於某些Web服務器保存重要信息，只想發給特定用戶通訊的權限。
沒法斷定請求出處。
即便是無心義的請求也會照單全收。沒法阻止海量請求下的DoS攻擊。

查明對手的證書

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

經過使用證書，來證實通訊方就是意料中的服務器，這對使用者我的來說減小了信息泄露的危險。另外客戶端持有證書便可完成我的身份驗證，可用於Web認證環節。

（3）沒法證實報文完整性，可能已遭篡改

因爲HTTP協議沒法證實通訊報文的完整性，即便請求或響應內容遭到篡改，也沒有辦法獲悉。

像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊（Man-in-the-Middle attack）

如何防止篡改

雖然有使用HTTP協議肯定報文完整性的方法，事實上並不可靠，經常使用的是MD5（單向函數生成的散列值）和SHA-1等散列值校驗方法，及用來確認文件的數字簽名方法。惋惜的是若是MD5自己被改寫，用戶沒有辦法意識到。

爲了有效防止以上這些弊端，須要使用到HTTPS。SSL提供認證和加密處理及摘要功能。僅靠HTTP確保完整性是很是困難的，所以經過和其餘協議組合來實現此目標。

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

（1）定義

HTTPS並不是是應用層的一種新協議，只是HTTP通訊接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。經過在TCP和HTTP之間加入TLS來加密，由此保證數據傳輸的安全性。HTTPS就是身披SSL協議這串外殼的HTTP。

（2）SSL/TLS協議

SSL協議是一種安全傳輸協議，TLS是SSL v3.0的升級版。

（3）HTTPS層次圖

查看HTTPS層次圖，最底層是NetWork，依次往上是網絡層、傳輸層、應用層。

傳輸層上面夾着TLS層，它就是安全傳輸協議在現實中的應用版，其中最上方的3個綠色小方框組成了TLS協議。上圖相似於TCP/IP模型，只是多了一層TLS層，用來加密數據。

（4）HTTPS架構圖

查看HTTPS架構圖，其實HTTPS協議就是在HTTP基礎上加上了加密、驗證以及數據的保護。在使用HTTPS通訊時，使用的是 https://

（注意：HTTPS並不是是新協議，他只是HTTP通訊接口中加了一個SSL協議）

在HTTPS通訊時會先和SSL層創建通訊，而後SSL層再和傳輸層中的TCP通訊。因此HTTPS就是披了一層SSL外殼的HTTP協議

（5）HTTPS傳輸速度

SSL的慢可歸於如下兩點：一是通訊慢，一是因爲大量消耗CPU及內存等資源，致使處理速度變慢。

通訊慢：同HTTP協議相比，網絡負載會變慢，由於除去TCP鏈接、HTTP請求與響應外，還必須處理SSL、TSL通訊，致使通訊量的增長。
SSL必須進行加密處理：在服務器端和客戶端都要經過加密、解密進行數據的安全處理，所以從結果而言，比起HTTP會更多地消耗服務器和客戶端的硬件資源，致使負載加強。

綜合以上因素，只有在處理敏感信息時才使用HTTPS加密通訊。

3. TLS與SSL握手過程

查看上圖，TLS與SSL握手過程能夠總結如下5個步驟：

（1）客戶端發起請求

首先客戶端會將它支持的協議版本、加密壓縮算法，並生成一個隨機數（握手過程的第一個隨機數）一塊兒傳送給服務端。注意：此隨機數與後續服務端產生的隨機數會組成密鑰。

（2）服務器迴應

當服務端收到客戶端 hello的請求後，會肯定加密的協議算法，也會生成本身的一個隨機數（握手過程的第二個隨機數），連同證書一塊兒發送給客戶端。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱祕鑰時用到。

（3）客戶端驗證證書

當客戶端再次迴應時，首先對服務端發來的證書進行驗證，驗證完畢後會再次產生一個隨機數（握手過程的第三個隨機數），此隨機數是使用證書中公鑰加密的，通知服務端編碼已改變、握手結束。

（4）生成密鑰

服務端接收到密鑰以後，用私鑰對這加密的數據進行解密並驗證，驗證完畢後向客戶端發出通知確認編碼改變、握手結束。

（5）客戶端發送數據

客戶端收到服務端發來的通知確認後，能夠和服務端進行HTTPS安全的消息通信了。

注意

因爲SSL協議在握手階段使用的是非對稱加密，通常是RSA加密算法，因此需知隨機數是不能隨意破解的，它是安全性的保證。

4. 再論TLS與SSL握手過程

以上第3點對TLS與SSL握手過程的總結適合新手初次學習，而此部分就正式地去介紹其細節，查看如下時序圖：

(1)client_hello

客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息：

支持的最高TSL協議版本version；
客戶端支持的加密套件 cipher suites 列表，每一個加密套件對應前面 TLS 原理中的四個功能的組合：認證算法 Au (身份驗證)、
密鑰交換算法 KeyExchange(密鑰協商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗)；
支持的壓縮算法；
擴展字段 extensions；
隨機數 random_C（此過程的第一個隨機數），用於後續的密鑰的生成；

(2)server_hello + server_certificate + sever_hello_done

server_hello：服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 random_S（此過程的第二個隨機數）等，其中隨機數用於後續的密鑰協商;
server_certificates：服務器端配置對應的證書鏈，用於身份驗證與密鑰交換;
server_hello_done：通知客戶端 server_hello 信息發送結束;

(3)證書校驗

客戶端驗證證書的合法性，若是驗證經過纔會進行後續通訊，不然根據錯誤狀況不一樣作出提示和操做，合法性驗證包括以下：

證書鏈的可信性 trusted certificate path，方法如前文所述;
證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不一樣的客戶端行爲會不一樣;
有效期 expiry date，證書是否在有效時間範圍;
域名 domain，覈查證書域名是否與當前的訪問域名匹配，匹配規則後續分析;

(4)client_key_exchange + change_cipher_spec + encrypted_handshake_message

client_key_exchange：合法性驗證經過以後，客戶端計算產生隨機數字 Pre-master（此過程的第三個隨機數），並用證書公鑰加密，發送給服務器。

此時客戶端已經獲取所有的計算協商密鑰須要的信息：兩個明文隨機數 random_C 和 random_S 與本身計算產生的 Pre-master，計算獲得協商密鑰。

change_cipher_spec：客戶端通知服務器後續的通訊都採用協商的通訊密鑰和加密算法進行加密通訊。
encrypted_handshake_message：，結合以前全部通訊參數的 hash 值與其它相關信息生成一段數據，採用協商密鑰 session secret 與算法進行加密，而後發送給服務器用於數據與握手驗證。

(5) change_cipher_spec + encrypted_handshake_message

服務器用私鑰解密加密的 Pre-master 數據，基於以前交換的兩個明文隨機數 random_C 和 random_S，計算獲得協商密鑰

enc_key=Fuc(random_C, random_S, Pre-Master)

計算以前全部接收信息的 hash 值，而後解密客戶端發送的 encrypted_handshake_message，驗證數據和密鑰正確性。
change_cipher_spec：驗證經過以後，服務器一樣發送 change_cipher_spec 以告知客戶端後續的通訊都採用協商的密鑰與算法進行加密通訊。
encrypted_handshake_message：服務器也結合全部當前的通訊參數信息生成一段數據並採用協商密鑰 session secret 與算法加密併發送到客戶端。

(6)握手結束

客戶端計算全部接收信息的 hash 值，並採用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證經過則握手完成。

(7)加密通訊

開始使用協商密鑰與算法進行加密通訊。

注意：

服務器也能夠要求驗證客戶端，即雙向認證，能夠在過程2要發送 client_certificate_request 信息，客戶端在過程4中先發送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相同，certificate_verify_message 是採用client的私鑰加密的一段基於已經協商的通訊信息獲得數據，服務器能夠採用對應的公鑰解密並驗證。

後續相關知識還有：爲了加快創建握手的速度，減小協議帶來的性能下降和資源消耗(具體分析在後文)，TLS 協議有兩類會話緩存機制：會話標識 session ID 與會話記錄 session ticket。可查看如下連接。

此小節是借鑑於TLS/SSL握手過程，推薦查看。

5. 總結

HTTPS實際上就是在TCP層與HTTP層之間加入了SSL/TLS來爲上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書等技術進行客戶端與服務器的數據加密傳輸，最終達到保證整個通訊的安全性。

10.tcp/ip模型

互聯網協議按照功能不一樣分爲osi七層或tcp/ip五層或tcp/ip四層

每層運行常見物理設備

各層網絡協議的做用

物理層：鏈接兩臺主機之間的物理介質，單純的01傳輸電信號
數據鏈路層：數據鏈路層規定電信號的分組方式，使用廣播的方式在子網絡中經過Mac地址的匹配，實現不一樣電腦上的數據傳輸
網絡層：經過arp協議，使用ip來區分不一樣的計算機是否屬於同一個子網絡，再經過廣播的方式在子網絡中經過Mac地址的匹配，實現不一樣電腦上的數據傳輸
傳輸層：創建一個端口到另外一個端口的通訊（TPC/IP協議）
應用層：規定應用程序的數據格式（HTTP協議）

【轉載】

1、概述

1.1 五層模型

互聯網的實現，分紅好幾層。每一層都有本身的功能，就像建築物同樣，每一層都靠下一層支持。

用戶接觸到的，只是最上面的一層，根本沒有感受到下面的層。要理解互聯網，必須從最下層開始，自下而上理解每一層的功能。

如何分層有不一樣的模型，有的模型分七層，有的分四層。我以爲，把互聯網分紅五層，比較容易解釋。

如上圖所示，最底下的一層叫作"實體層"（Physical Layer），最上面的一層叫作"應用層"（Application Layer），中間的三層（自下而上）分別是"連接層"（Link Layer）、"網絡層"（Network Layer）和"傳輸層"（Transport Layer）。越下面的層，越靠近硬件；越上面的層，越靠近用戶。

它們叫什麼名字，其實並不重要。只須要知道，互聯網分紅若干層就能夠了。

1.2 層與協議

每一層都是爲了完成一種功能。爲了實現這些功能，就須要你們都遵照共同的規則。

你們都遵照的規則，就叫作"協議"（protocol）。

互聯網的每一層，都定義了不少協議。這些協議的總稱，就叫作"互聯網協議"（Internet Protocol Suite）。它們是互聯網的核心，下面介紹每一層的功能，主要就是介紹每一層的主要協議。

2、實體層

咱們從最底下的一層開始。

電腦要組網，第一件事要幹什麼？固然是先把電腦連起來，能夠用光纜、電纜、雙絞線、無線電波等方式。

這就叫作"實體層"，它就是把電腦鏈接起來的物理手段。它主要規定了網絡的一些電氣特性，做用是負責傳送0和1的電信號。

3、連接層

3.1 定義

單純的0和1沒有任何意義，必須規定解讀方式：多少個電信號算一組？每一個信號位有何意義？

這就是"連接層"的功能，它在"實體層"的上方，肯定了0和1的分組方式。

3.2 以太網協議

早期的時候，每家公司都有本身的電信號分組方式。逐漸地，一種叫作"以太網"（Ethernet）的協議，佔據了主導地位。

以太網規定，一組電信號構成一個數據包，叫作"幀"（Frame）。每一幀分紅兩個部分：標頭（Head）和數據（Data）。

"標頭"包含數據包的一些說明項，好比發送者、接受者、數據類型等等；"數據"則是數據包的具體內容。

"標頭"的長度，固定爲18字節。"數據"的長度，最短爲46字節，最長爲1500字節。所以，整個"幀"最短爲64字節，最長爲1518字節。若是數據很長，就必須分割成多個幀進行發送。

3.3 MAC地址

上面提到，以太網數據包的"標頭"，包含了發送者和接受者的信息。那麼，發送者和接受者是如何標識呢？

以太網規定，連入網絡的全部設備，都必須具備"網卡"接口。數據包必須是從一塊網卡，傳送到另外一塊網卡。網卡的地址，就是數據包的發送地址和接收地址，這叫作MAC地址。

每塊網卡出廠的時候，都有一個全世界獨一無二的MAC地址，長度是48個二進制位，一般用12個十六進制數表示。

前6個十六進制數是廠商編號，後6個是該廠商的網卡流水號。有了MAC地址，就能夠定位網卡和數據包的路徑了。

3.4 廣播

定義地址只是第一步，後面還有更多的步驟。

首先，一塊網卡怎麼會知道另外一塊網卡的MAC地址？

回答是有一種ARP協議，能夠解決這個問題。這個留到後面介紹，這裏只須要知道，以太網數據包必須知道接收方的MAC地址，而後才能發送。

其次，就算有了MAC地址，系統怎樣才能把數據包準確送到接收方？

回答是以太網採用了一種很"原始"的方式，它不是把數據包準確送到接收方，而是向本網絡內全部計算機發送，讓每臺計算機本身判斷，是否爲接收方。

上圖中，1號計算機向2號計算機發送一個數據包，同一個子網絡的3號、4號、5號計算機都會收到這個包。它們讀取這個包的"標頭"，找到接收方的MAC地址，而後與自身的MAC地址相比較，若是二者相同，就接受這個包，作進一步處理，不然就丟棄這個包。這種發送方式就叫作"廣播"（broadcasting）。

有了數據包的定義、網卡的MAC地址、廣播的發送方式，"連接層"就能夠在多臺計算機之間傳送數據了。

4、網絡層

4.1 網絡層的由來

以太網協議，依靠MAC地址發送數據。理論上，單單依靠MAC地址，上海的網卡就能夠找到洛杉磯的網卡了，技術上是能夠實現的。

可是，這樣作有一個重大的缺點。以太網採用廣播方式發送數據包，全部成員人手一"包"，不只效率低，並且侷限在發送者所在的子網絡。也就是說，若是兩臺計算機不在同一個子網絡，廣播是傳不過去的。這種設計是合理的，不然互聯網上每一臺計算機都會收到全部包，那會引發災難。

互聯網是無數子網絡共同組成的一個巨型網絡，很像想象的電腦會在同一個子網絡，這幾乎是不可能的。

所以，必須找到一種方法，可以區分哪些MAC地址屬於同一個子網絡，哪些不是。若是是同一個子網絡，就採用廣播方式發送，不然就採用"路由"方式發送。（"路由"的意思，就是指如何向不一樣的子網絡分發數據包，這是一個很大的主題，本文不涉及。）遺憾的是，MAC地址自己沒法作到這一點。它只與廠商有關，與所處網絡無關。

這就致使了"網絡層"的誕生。它的做用是引進一套新的地址，使得咱們可以區分不一樣的計算機是否屬於同一個子網絡。這套地址就叫作"網絡地址"，簡稱"網址"。

因而，"網絡層"出現之後，每臺計算機有了兩種地址，一種是MAC地址，另外一種是網絡地址。兩種地址之間沒有任何聯繫，MAC地址是綁定在網卡上的，網絡地址則是管理員分配的，它們只是隨機組合在一塊兒。

網絡地址幫助咱們肯定計算機所在的子網絡，MAC地址則將數據包送到該子網絡中的目標網卡。所以，從邏輯上能夠推斷，一定是先處理網絡地址，而後再處理MAC地址。

4.2 IP協議

規定網絡地址的協議，叫作IP協議。它所定義的地址，就被稱爲IP地址。

目前，普遍採用的是IP協議第四版，簡稱IPv4。這個版本規定，網絡地址由32個二進制位組成。

習慣上，咱們用分紅四段的十進制數表示IP地址，從0.0.0.0一直到255.255.255.255。

互聯網上的每一臺計算機，都會分配到一個IP地址。這個地址分紅兩個部分，前一部分表明網絡，後一部分表明主機。好比，IP地址192.168.0.1，這是一個32位的地址，假定它的網絡部分是前24位（192.168.0.1），那麼主機部分就是後8位（最後的那個1）。處於同一個子網絡的電腦，它們IP地址的網絡部分一定是相同的，也就是說192.168.0.25應該與192.168.0.1處在同一個子網絡。

可是，問題在於單單從IP地址，咱們沒法判斷網絡部分。仍是以192.168.0.1爲例，它的網絡部分，究竟是前24位，仍是前16位，甚至前28位，從IP地址上是看不出來的。

那麼，怎樣才能從IP地址，判斷兩臺計算機是否屬於同一個子網絡呢？這就要用到另外一個參數"子網掩碼"（subnet mask）。

所謂"子網掩碼"，就是表示子網絡特徵的一個參數。它在形式上等同於IP地址，也是一個32位二進制數字，它的網絡部分所有爲1，主機部分所有爲0。好比，IP地址192.168.0.1，若是已知網絡部分是前24位，主機部分是後8位，那麼子網絡掩碼就是11111111.11111111.11111111.00000000，寫成十進制就是255.255.255.0。

知道"子網掩碼"，咱們就能判斷，任意兩個IP地址是否處在同一個子網絡。方法是將兩個IP地址與子網掩碼分別進行AND運算（兩個數位都爲1，運算結果爲1，不然爲0），而後比較結果是否相同，若是是的話，就代表它們在同一個子網絡中，不然就不是。

好比，已知IP地址192.168.0.1和192.168.0.1的子網掩碼都是255.255.255.0，請問它們是否在同一個子網絡？二者與子網掩碼分別進行AND運算，結果都是192.168.0.0，所以它們在同一個子網絡。

總結一下，IP協議的做用主要有兩個，一個是爲每一臺計算機分配IP地址，另外一個是肯定哪些地址在同一個子網絡。

4.3 IP數據包

根據IP協議發送的數據，就叫作IP數據包。不難想象，其中一定包括IP地址信息。

可是前面說過，以太網數據包只包含MAC地址，並無IP地址的欄位。那麼是否須要修改數據定義，再添加一個欄位呢？

回答是不須要，咱們能夠把IP數據包直接放進以太網數據包的"數據"部分，所以徹底不用修改以太網的規格。這就是互聯網分層結構的好處：上層的變更徹底不涉及下層的結構。

具體來講，IP數據包也分爲"標頭"和"數據"兩個部分。

"標頭"部分主要包括版本、長度、IP地址等信息，"數據"部分則是IP數據包的具體內容。它放進以太網數據包後，以太網數據包就變成了下面這樣。

IP數據包的"標頭"部分的長度爲20到60字節，整個數據包的總長度最大爲65,535字節。所以，理論上，一個IP數據包的"數據"部分，最長爲65,515字節。前面說過，以太網數據包的"數據"部分，最長只有1500字節。所以，若是IP數據包超過了1500字節，它就須要分割成幾個以太網數據包，分開發送了。

4.4 ARP協議

關於"網絡層"，還有最後一點須要說明。

由於IP數據包是放在以太網數據包裏發送的，因此咱們必須同時知道兩個地址，一個是對方的MAC地址，另外一個是對方的IP地址。一般狀況下，對方的IP地址是已知的（後文會解釋），可是咱們不知道它的MAC地址。

因此，咱們須要一種機制，可以從IP地址獲得MAC地址。

這裏又能夠分紅兩種狀況。第一種狀況，若是兩臺主機不在同一個子網絡，那麼事實上沒有辦法獲得對方的MAC地址，只能把數據包傳送到兩個子網絡鏈接處的"網關"（gateway），讓網關去處理。

第二種狀況，若是兩臺主機在同一個子網絡，那麼咱們能夠用ARP協議，獲得對方的MAC地址。ARP協議也是發出一個數據包（包含在以太網數據包中），其中包含它所要查詢主機的IP地址，在對方的MAC地址這一欄，填的是FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。它所在子網絡的每一臺主機，都會收到這個數據包，從中取出IP地址，與自身的IP地址進行比較。若是二者相同，都作出回覆，向對方報告本身的MAC地址，不然就丟棄這個包。

總之，有了ARP協議以後，咱們就能夠獲得同一個子網絡內的主機MAC地址，能夠把數據包發送到任意一臺主機之上了。

5、傳輸層

5.1 傳輸層的由來

有了MAC地址和IP地址，咱們已經能夠在互聯網上任意兩臺主機上創建通訊。

接下來的問題是，同一臺主機上有許多程序都須要用到網絡，好比，你一邊瀏覽網頁，一邊與朋友在線聊天。當一個數據包從互聯網上發來的時候，你怎麼知道，它是表示網頁的內容，仍是表示在線聊天的內容？

也就是說，咱們還須要一個參數，表示這個數據包到底供哪一個程序（進程）使用。這個參數就叫作"端口"（port），它實際上是每個使用網卡的程序的編號。每一個數據包都發到主機的特定端口，因此不一樣的程序就能取到本身所須要的數據。

"端口"是0到65535之間的一個整數，正好16個二進制位。0到1023的端口被系統佔用，用戶只能選用大於1023的端口。無論是瀏覽網頁仍是在線聊天，應用程序會隨機選用一個端口，而後與服務器的相應端口聯繫。

"傳輸層"的功能，就是創建"端口到端口"的通訊。相比之下，"網絡層"的功能是創建"主機到主機"的通訊。只要肯定主機和端口，咱們就能實現程序之間的交流。所以，Unix系統就把主機+端口，叫作"套接字"（socket）。有了它，就能夠進行網絡應用程序開發了。

5.2 UDP協議

如今，咱們必須在數據包中加入端口信息，這就須要新的協議。最簡單的實現叫作UDP協議，它的格式幾乎就是在數據前面，加上端口號。

UDP數據包，也是由"標頭"和"數據"兩部分組成。

"標頭"部分主要定義了發出端口和接收端口，"數據"部分就是具體的內容。而後，把整個UDP數據包放入IP數據包的"數據"部分，而前面說過，IP數據包又是放在以太網數據包之中的，因此整個以太網數據包如今變成了下面這樣：

UDP數據包很是簡單，"標頭"部分一共只有8個字節，總長度不超過65,535字節，正好放進一個IP數據包。

5.3 TCP協議

UDP協議的優勢是比較簡單，容易實現，可是缺點是可靠性較差，一旦數據包發出，沒法知道對方是否收到。

爲了解決這個問題，提升網絡可靠性，TCP協議就誕生了。這個協議很是複雜，但能夠近似認爲，它就是有確認機制的UDP協議，每發出一個數據包都要求確認。若是有一個數據包遺失，就收不到確認，發出方就知道有必要重發這個數據包了。

所以，TCP協議可以確保數據不會遺失。它的缺點是過程複雜、實現困難、消耗較多的資源。

TCP數據包和UDP數據包同樣，都是內嵌在IP數據包的"數據"部分。TCP數據包沒有長度限制，理論上能夠無限長，可是爲了保證網絡的效率，一般TCP數據包的長度不會超過IP數據包的長度，以確保單個TCP數據包沒必要再分割。

6、應用層

應用程序收到"傳輸層"的數據，接下來就要進行解讀。因爲互聯網是開放架構，數據來源五花八門，必須事先規定好格式，不然根本沒法解讀。

"應用層"的做用，就是規定應用程序的數據格式。

舉例來講，TCP協議能夠爲各類各樣的程序傳遞數據，好比Email、WWW、FTP等等。那麼，必須有不一樣協議規定電子郵件、網頁、FTP數據的格式，這些應用程序協議就構成了"應用層"。

這是最高的一層，直接面對用戶。它的數據就放在TCP數據包的"數據"部分。所以，如今的以太網的數據包就變成下面這樣。

至此，整個互聯網的五層結構，自下而上所有講完了。這是從系統的角度，解釋互聯網是如何構成的。下一篇，我反過來，從用戶的角度，自上而下看看這個結構是如何發揮做用，完成一次網絡數據交換的。

11.DNS

【參考博客】https://blog.csdn.net/root_robot/article/details/53872812

什麼是DNS？

DNS( Domain Name System)是「域名系統」的英文縮寫，是一種組織成域層次結構的計算機和網絡服務命名系統，它用於TCP/IP網絡，它所提供的服務是用來將主機名和域名轉換爲IP地址的工做。你能夠把它想象成一本巨大的電話本。
舉例來講，若是你要訪問域名www.baidu.,com，首先要經過DNS查出它的IP地址是151.101.129.69。
若是你不清楚爲何必定要查出IP地址，才能進行網絡通訊，建議先閱讀我寫的《互聯網協議入門》。

DNS就是這樣的一位「翻譯官」，它的基本工做原理可用下圖來表示：

DNS服務的工做過程

當 DNS 客戶機須要查詢程序中使用的名稱時，它會查詢本地DNS 服務器來解析該名稱。客戶機發送的每條查詢消息都包括3條信息，以指定服務器應回答的問題。
● 指定的 DNS 域名，表示爲徹底合格的域名 (FQDN) 。
● 指定的查詢類型，它可根據類型指定資源記錄，或做爲查詢操做的專門類型。
● DNS域名的指定類別。
對於DNS 服務器，它始終應指定爲 Internet 類別。例如，指定的名稱能夠是計算機的徹底合格的域名，如im.qq.com，而且指定的查詢類型用於經過該名稱搜索地址資源記錄。
DNS 查詢以各類不一樣的方式進行解析。客戶機有時也可經過使用從之前查詢得到的緩存信息就地應答查詢。DNS 服務器可以使用其自身的資源記錄信息緩存來應答查詢，也可表明請求客戶機來查詢或聯繫其餘 DNS 服務器，以徹底解析該名稱，並隨後將應答返回至客戶機。這個過程稱爲遞歸。
另外，客戶機本身也可嘗試聯繫其餘的 DNS 服務器來解析名稱。若是客戶機這麼作，它會使用基於服務器應答的獨立和附加的查詢，該過程稱做迭代，即DNS服務器之間的交互查詢就是迭代查詢。

DNS的查詢過程以下所示：

一、在瀏覽器中輸入www . qq .com 域名，操做系統會先檢查本身本地的hosts文件是否有這個網址映射關係，若是有，就先調用這個IP地址映射，完成域名解析。
二、若是hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，若是有，直接返回，完成域名解析。
三、若是hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/ip參數中設置的首選DNS服務器，在此咱們叫它本地DNS服務器，此服務器收到查詢時，若是要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具備權威性。
四、若是要查詢的域名，不禁本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具備權威性。
五、若是本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，若是未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來受權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，若是本身沒法解析，它就會找一個管理.com域的下一級DNS服務器地址(http://qq.com)給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找http://qq.com域服務器，重複上面的動做，進行查詢，直至找到www . qq .com主機。
六、若是用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器若是不能解析，或找根DNS或把轉請求轉至上上級，以此循環。無論是本地DNS服務器用是是轉發，仍是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。
從客戶端到本地DNS服務器是屬於遞歸查詢，而DNS服務器之間就是的交互查詢就是迭代查詢。

12.https算法相關

密鑰(key)

密鑰是一種參數，它是在使用密碼（cipher）算法過程當中輸入的參數。同一個明文在相同的密碼算法和不一樣的密鑰計算下會產生不一樣的密文。
不少知名的密碼算法都是公開的，密鑰纔是決定密文是否安全的重要參數，一般密鑰越長，破解的難度越大，好比一個8位的密鑰最多有256種狀況，使用窮舉法，能很是輕易的破解，
知名的DES算法使用56位的密鑰，目前已經不是一種安全的加密算法了，主要仍是由於56位的密鑰過短，在數小時內就能夠被破解。密鑰分爲對稱密鑰與非對稱密鑰。

明文/密文

明文（plaintext）是加密以前的原始數據，密文是經過密碼（cipher）運算後獲得的結果成爲密文（ciphertext）

對稱密鑰

對稱密鑰（Symmetric-key algorithm）又稱爲共享密鑰加密，對稱密鑰在加密和解密的過程當中使用的密鑰是相同的，
常見的對稱加密算法有DES、3DES、AES、RC五、RC6。
對稱密鑰的優勢是計算速度快，可是他也有缺點，密鑰須要在通信的兩端共享，讓彼此知道密鑰是什麼對方纔能正確解密，
若是全部客戶端都共享同一個密鑰，那麼這個密鑰就像萬能鑰匙同樣，能夠憑藉一個密鑰破解全部人的密文了，若是每一個客戶端與服務端單獨維護一個密鑰，那麼服務端須要管理的密鑰將是成千上萬，這會給服務端帶來噩夢

非對稱密鑰

非對稱密鑰（public-key cryptography），又稱爲公開密鑰加密，服務端會生成一對密鑰，一個私鑰保存在服務端，僅本身知道，
另外一個是公鑰，公鑰能夠自由發佈供任何人使用。客戶端的明文經過公鑰加密後的密文須要用私鑰解密。非對稱密鑰在加密和解密的過程的使用的密鑰是不一樣的密鑰，
加密和解密是不對稱的，因此稱之爲非對稱加密。與對稱密鑰加密相比，非對稱加密無需在客戶端和服務端之間共享密鑰，只要私鑰不發給任何用戶，
即便公鑰在網上被截獲，也沒法被解密，僅有被竊取的公鑰是沒有任何用處的。常見的非對稱加密有RSA，非對稱加解密的過程：

1.服務端生成配對的公鑰和私鑰
2.私鑰保存在服務端，公鑰發送給客戶端
3.客戶端使用公鑰加密明文傳輸給服務端
4.服務端使用私鑰解密密文獲得明文

數字簽名

數據在瀏覽器和服務器之間傳輸時，有可能在傳輸過程當中被冒充的盜賊把內容替換了，那麼如何保證數據是真實服務器發送的而不被調包呢，同時如何保證傳輸的數據沒有被人篡改呢，
要解決這兩個問題就必須用到數字簽名，數字簽名就如同平常生活的中的簽名同樣，一旦在合同書上落下了你的大名，從法律意義上就肯定是你本人籤的字兒，這是任何人都無法仿造的，
由於這是你專有的手跡，任何人是造不出來的。那麼在計算機中的數字簽名怎麼回事呢？數字簽名就是用於驗證傳輸的內容是否是真實服務器發送的數據，發送的數據有沒有被篡改過，
它就幹這兩件事，是非對稱加密的一種應用場景。不過他是反過來用私鑰來加密，經過與之配對的公鑰來解密。

第一步：服務端把報文通過Hash處理後生成摘要信息Digest，摘要信息使用私鑰private-key加密以後就生成簽名，服務器把簽名連同報文一塊兒發送給客戶端。

第二步：客戶端接收到數據後，把簽名提取出來用public-key解密，若是能正常的解密出來Digest2，那麼就能確認是對方發的。

第三步：客戶端把報文Text提取出來作一樣的Hash處理，獲得的摘要信息Digest1，再與以前解密出來的Digist2對比，若是二者相等，就表示內容沒有被篡改，
不然內容就是被人改過了。由於只要文本內容哪怕有任何一點點改動都會Hash出一個徹底不同的摘要信息出來。

數字證書（Certificate Authority）

數字證書簡稱CA，它由權威機構給某網站頒發的一種承認憑證，這個憑證是被你們（瀏覽器）所承認的，爲何須要用數字證書呢，難道有了數字簽名還不夠安全嗎？有這樣一種狀況，就是瀏覽器沒法肯定全部的真實服務器是否是真的是真實的，舉一個簡單的例子：A廠家給大家家安裝鎖，同時把鑰匙也交給你，只要鑰匙能打開鎖，你就能夠肯定鑰匙和鎖是配對的，若是有人把鑰匙換了或者把鎖換了，你是打不開門的，你就知道確定被竊取了，可是若是有人把鎖和鑰匙替換成另外一套表面看起來差很少的，但質量差不少的，雖然鑰匙和鎖配套，可是你卻不能肯定這是否真的是A廠家給你的，那麼這時候，你能夠找質檢部門來檢驗一下，這套鎖是否是真的來自於A廠家，質檢部門是權威機構，他說的話是能夠被公衆承認的（呵呵）。

一樣的， 由於若是有人（張三）用本身的公鑰把真實服務器發送給瀏覽器的公鑰替換了，因而張三用本身的私鑰執行相同的步驟對文本Hash、數字簽名，最後獲得的結果都沒什麼問題，但事實上瀏覽器看到的東西卻不是真實服務器給的，而是被張三從裏到外（公鑰到私鑰）換了一通。那麼如何保證你如今使用的公鑰就是真實服務器發給你的呢？咱們就用數字證書來解決這個問題。數字證書通常由數字證書認證機構（Certificate Authority）頒發，證書裏面包含了真實服務器的公鑰和網站的一些其餘信息，數字證書機構用本身的私鑰加密後發給瀏覽器，瀏覽器使用數字證書機構的公鑰解密後獲得真實服務器的公鑰。這個過程是創建在被你們所承認的證書機構之上獲得的公鑰，因此這是一種安全的方式。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。