Http協議

(一)基礎知識

當咱們在瀏覽器的地址欄中輸入網址，而後點擊回車，接着，瀏覽器就會呈現出咱們須要的web界面，那麼，這個界面是怎麼產生的？

web的界面是根據咱們輸入的URL（網址、地址），瀏覽器從服務器端獲取對應的文件資源等信息，而後顯示在瀏覽器上面。

像這種經過發送請求獲取服務器資源的web瀏覽器等，均可以稱之爲客戶端（client）

web使用http（超文本傳輸協議）協議做爲規範，來完成從客戶端到服務端等一系列的運做流程，而協議指的就是規則的約定，能夠說，web是創建在http協議上進行通訊的

關於http的產生和發展，這裏就不贅述了，有興趣的童鞋能夠百度。。。。。。

 

爲了理解http，有必要簡單介紹下tcp/ip協議族

計算機與網絡設備之間互相通訊，雙方就必須基於一樣的方法。好比：如何發現通訊目標、由誰發起通訊、使用什麼語言通訊、怎麼結束通訊都須要事先肯定，全部這些都須要一種規則，

這就是協議。協議中存在多種的內容；從電纜的規格到ip地址的選定方法，尋找異地用戶的方法，創建通訊的順序，以及web頁面顯示須要處理的步驟等等

像這樣把與互聯網相關聯的協議集合起來統稱爲tcp/ip。

 

tcp/ip的分層

tcp/ip很重要的一個特色就是分層。按照層次分爲如下四層：應用層，傳輸層，網絡層和數據鏈路層

分層的好處：若是互聯網只由一個協議統籌，那麼某一地方出問題，總體都會出現問題，沒法使用；分層後，只需替換出現問題的或者須要修改的便可，並且分層後針對具體的設計也變得更爲簡單

 

應用層：體系的最高層，應用進程間通訊交互的規則

tcp/ip協議族預存了各種通用的應用服務，好比：

ftp：文件傳輸協議

dns：域名系統協議

http：萬維網應用協議

smtp：電子郵件協議

以上幾種是經常使用的幾種，還有不少其餘的協議，感興趣的能夠找找其餘專業的書籍看看

 

傳輸層：提供處於網絡鏈接中的兩臺計算機間的數據傳輸，其中包括tcp和udp兩種性質不一樣的協議

tcp：傳輸控制協議，傳輸的單位爲報文段，提供面向鏈接的，可靠的數據傳輸服務

udp：傳輸單位爲用戶數據報，它是盡最大努力的提供數據傳輸服務，不保證可靠性

 

網絡層：又名網絡鏈接層

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

 

鏈路層：又名數據鏈路層，網絡接口層

處理鏈接網絡的硬件部分。好比控制操做系統、硬件的驅動、網絡適配器、光釺等

 

數據的封裝：

用戶端發送一個請求，從應用層開始，一直到鏈路層，每一層都會被打上該層所屬的首部信息；反之，接收端在層與層之間傳輸時，每通過一層會去掉該層的首部信息，這種作法叫作封裝

 

與http密切相關的協議

IP協議：位於網絡層，做用是把各類數據包傳送給對方，而要準確的把數據傳送給對方，就須要知足各種條件，其中有2個很重要的條件：ip地址和mac地址

ip地址相信有點基礎的人都知道，就是節點被分配到的地址，mac地址則是指網卡所屬的固定地址，ip和mac地址能夠進行配對

ip間的通訊依賴於mac地址，在信息傳輸中，有時候因爲中轉太多，所以會採用ARP協議，這是個用來解析地址的協議，經過ip地址就能夠反查出對應的mac地址

 

tcp協議：位於傳輸層，確保傳輸的可靠性

數據傳輸中爲了傳輸方便，會將大塊數據分割成報文段，而tcp協議能確認數據最終是否傳送給對方

爲了準確傳輸，傳輸中採用了三次握手策略（這種手段能夠理解爲屢次確認，來確保數據傳輸的可靠性）

 

dns協議：負責域名解析，位於應用層，提供域名到ip地址間的解析

經過域名查找ip地址，或者逆向從ip地址反查域名

 

URL和URI

URL：統一資源定位符：表示資源的地點，具體指向（門牌號）

URI：統一資源標識符：用字符串標識某些互聯網資源（該門牌號的地方具體有什麼資源）

URL是URI的子集

 

(二)請求和響應報文的構成

http協議用於客戶端和服務器之間的通訊，請求訪問資源的一方稱爲客戶端，而提供資源響應的一方稱爲服務器端。

下面就是客戶端和服務端之間簡單的通訊過程

PS：請求必須從客戶端創建通訊，服務端沒收到請求以前不會發送響應

下面先來講說請求的構成：

1）請求方法URI協議/版本 

2）請求頭(Request Header) 

3）請求正文

下面是一個請求的例子：

GET/sample.jspHTTP/1.1

Accept:image/gif.image/jpeg,*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

1）請求方法URI協議/版本

以上請求中「GET」表明請求方法，「/sample.jsp」表示URI，「HTTP/1.1表明協議和協議的版本。

根據HTTP標準，HTTP請求能夠使用多種請求方法。具體的方法以及區別後面咱們介紹。

2）請求頭

Accept 可接受的內容類型

Accept-Language 語言

Connection鏈接狀態

Host 請求的域名（這裏我設置的是請求本地，固然，關於域名，就是所謂的URL）

User-Agent 瀏覽器端瀏覽器型號和版本

Accept-Encoding 可接受的壓縮類型 gzip,deflate

 

3）請求正文

請求頭和請求正文之間是一個空行，它表示請求頭已經結束，接下來的是請求正文。請求正文中能夠包含客戶提交的查詢字符串信息：

username=jinqiao&password=1234

在以上的例子中，請求的正文只有一行內容。固然，在實際應用中，HTTP請求正文能夠包含更多的內容。

 

響應的構成

HTTP響應與HTTP請求類似，HTTP響應也由3個部分構成：

1）狀態行

2）響應頭

3）響應正文

在接收和解釋請求消息後，服務器會返回一個HTTP響應消息。

狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。

格式:    HTTP-Version Status-Code Reason-Phrase CRLF

例如:    HTTP/1.1 200 OK 

 

狀態代碼：

狀態代碼由3位數字組成，表示請求是否被理解或被知足。

狀態描述：

狀態描述給出了關於狀態代碼的簡短的文字描述。

狀態代碼的第一個數字定義了響應的類別，後面兩位沒有具體的分類。

第一個數字有五種可能的取值：

- 1xx:   指示信息—表示請求已接收，繼續處理。

- 2xx:   成功—表示請求已經被成功接收、理解、接受。

- 3xx:   重定向—要完成請求必須進行更進一步的操做。

- 4xx:   客戶端錯誤—請求有語法錯誤或請求沒法實現。

- 5xx: 服務器端錯誤—服務器未能實現合法的請求。

狀態代碼 狀態描述    說明

  200     OK    客戶端請求成功

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

  401     Unauthonzed   請求未經受權。這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用

  403     Forbidden   服務器收到請求，可是拒絕提供服務。服務器一般會在響應正文中給出不提供服務的緣由

  404     Not Found   請求的資源不存在，例如，輸入了錯誤的URL。

  500     Internal Server Error 服務器發生不可預期的錯誤，致使沒法完成客戶端的請求。

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

 

響應頭

響應頭可能包括： 

Location：響應報頭域用於重定向接受者到一個新的位置。

Server：響應報頭域包含了服務器用來處理請求的軟件信息。它和User-Agent請求報頭域是相對應的，前者發送服務器端軟件的信息，後者發送客戶 端軟件(瀏覽器)和操做系統的信息。

Content-Encoding：實體報頭域被使用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，於是要得到Content- Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。

Content-Language：實體報頭域描述了資源所用的天然語言。Content-Language容許用戶遵守自身的首選語言來識別和區分實體。 

Content-Length：實體報頭域用於指明正文的長度，以字節方式存儲的十進制數字來表示，也就是一個數字字符佔一個字節，用其對應的ASCII碼存儲傳輸。

要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。

Content-Type：實體報頭域用語指明發送給接收者的實體正文的媒體類型。

Last-Modified：實體報頭域用於指示資源最後的修改日期及時間。

Expires：實體報頭域給出響應過時的日期和時間。

Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期格式，例如：

Expires: Thu, 15 Sep 2005 16:00:00 GMT

下面是一個HTTP響應的例子：

HTTP/1.1 200 OK

 

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:23:42 GMT

Content-Length:112

從上面的例子你們能夠對照着進行比對，或者本身能夠嘗試在電腦上操做，這裏給你們教一個方法：

使用chrome瀏覽器自帶的開發者工具查看http頭的方法

1.在網頁任意地方右擊選擇審查元素或者按下 shift+ctrl+c或者F12, 打開chrome自帶的調試工具;

2.選擇network標籤, 刷新網頁(在打開調試工具的狀況下刷新);

3.刷新後在左邊找到該網頁url,點擊 後右邊選擇headers,就能夠看到當前網頁的http請求和響應

 

 

PS：關於請求和響應的首部字段，因爲目前http協議規定的比較多，這裏就不一一列舉了，感興趣的能夠百度下具體的http首部字段。。。

 

(三)幾種數據傳輸方式

說說http協議的一些特色：

1）無狀態

http協議是一種自身不對請求和響應之間的通訊狀態進行保存的協議，即無狀態協議。

這種設置的好處是：更快的處理更多的請求事務，確保協議的可伸縮性

不過隨着web的不斷髮展，有時候，須要將這種狀態進行保持，隨即，就引入了cookie技術，cookie技術經過在請求和響應報文中寫入cookie信息來控制客戶端的狀態。

有關cookie的內容後面咱們再說。。。

2）持久性

正常在發送http時，都須要創建TCP的鏈接，再發送報文。

 

若是每次想要發送http報文都須要通過這個過程，那麼時間大部分都會消耗在創建和斷開鏈接的過程當中。

所以http中使用了connection屬性，用於指定鏈接的方式。

當設置成keep-alive，http就會創建一條持久化的鏈接，不須要每次都創建鏈接，再中斷。

這樣作的好處是：減輕了服務器端的負載，減小開銷的那部分時間，使http請求和響應都能更快的結束，相應的，web頁面顯示速度也就相對提高了。

3）管線化

若是一個http請求，請求了大量的圖片等大文件，那麼其餘的http請求怎麼辦呢？

如今，管線化技術的出現，使得http請求比持久性鏈接更要快；特色在於：請求數越多，時間差越明顯。

4）內容編碼

因爲某些報文的內容過大，所以在傳輸時，爲了減小傳輸的時間，會採起一些壓縮的措施。

例如上面的報文信息中，Accept-Encoding就定義了內容編碼的格式：gzip

有下面幾種方式：

gzip：GNU壓縮格式

compress：UNIX系統的標準壓縮格式

deflate：是一種同時使用了LZ77和哈弗曼編碼的無損壓縮格式

identity：不進行壓縮

5）多部分對象集合

有的時候傳輸的內容，不只僅是一些字符串，還有多是一些圖片，字符，音樂二進制等混雜的內容。

這就須要使用多部分對象集合，multipart，例如在使用java編寫web上傳文件的代碼時，須要在form中指定form的編碼格式。

設置form的enctype屬性的值爲multipart/form-data。

這是由於默認的狀況下form使用的編碼格式是：applicatin/x-www-form-urlencoded，這種編碼格式會把全部的內容進行編碼，不適合上傳文件這種狀況。

這兩種編碼格式的區別主要是：

multipart/form-data 會以控件爲基準，編碼form中的內容。

application/x-www-form-urlencoded 會把form中的內容編碼成鍵值對的形式。

6）範圍請求

有些場景下，http報文請求一些很大的圖片，可是加載過程很慢。

好比咱們登陸一些大圖片的網址，會發現有時候圖片是一塊一塊加載的。

這就是由於設置了http請求的長度，這樣就能夠分塊的加載資源文件。

在請求報文中使用Range屬性，在響應報文中使用Content-Type屬性均可以指定必定字節範圍的http請求。

 

接下來，說說幾種http協議的數據傳輸方式

http協議的傳輸方式有不少種，處於安全考慮，經常使用的通常都是GET和POST兩種，先來介紹下這兩種

1）GET：獲取資源

GET方法用來請求訪問已被URL識別的資源

2）POST：傳輸實體主體

POST方法用來請求服務器傳輸信息實體的主體

GET和POST的區別：

首先，使用目標不一樣：GET方法只是用來查詢，不會對瀏覽器上的信息產生影響，每次GET的方法都是相同的

其次，大小不一樣：GET是放在URL首部，所以大小隨着瀏覽器而定，而POST則是在報文中，只要沒有具體限制，文件的大小是沒限制的

而後，安全性不一樣：GET採用的是明文傳輸，而POST是放在報文內部，沒法看到

從使用場景的角度來講，通常像用戶註冊登陸這種信息都是私密的，採用POST，而針對查詢等，爲了快速，大多采用GET傳輸。

（關於關於GET和POST的區別，最近從新看了不少別人寫的博客啊資料什麼的，發現上面的解釋比較模糊，我就在下面的評論區裏面將區別清晰的描述一下，固然，後面的博客也會詳細的解釋）

 

接下來介紹其餘幾種數據傳輸方式：

3）PUT：傳輸文件

PUT要求在請求報文的主體中包含文件內容，而後保存到請求URL指定的位置

處於安全考慮，通常web網站不使用此方法，若配合web的安全驗證機制，或者架構採用REST標準的網站，就可能開放使用此方法

4）HEAD：得到報文首部

HEAD和GET方法同樣，只不過不返回報文主體部分，用於確認URI的有效性及資源更新的日期時間等

5）DELETE：刪除文件

DELETE是與PUT相反的方法，是按請求URI刪除指定的資源

處於安全考慮，通常web網站不使用此方法，若配合web的安全驗證機制，或者架構採用REST標準的網站，就可能開放使用此方法

6）OPTIONS：詢問支持的方法

用來查詢針對請求URI指定的資源支持的方法

7）TRACE：追蹤路徑

是讓web服務器端將以前的請求通訊還回給客戶端的方法

發送請求時，在Max-Frowards首部字段中填入數值，每通過一個服務器端就-1，當數值爲0時，中止傳輸，最後收到服務器返回狀態碼200 OK的響應

可是，這種方法基本不多使用，並且很容易引發XST（跨站追蹤）攻擊，就更不會用到了。

8）CONNECT：要求採用隧道協議鏈接代理

該方法要求在於代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊，主要使用SSL（安全套接層）和TLS（傳輸層安全）協議把通訊內容加密後通過網絡傳輸。

 

最後，附上一張http1.1和http1.0版本各自支持的方法，另外，注意用大寫。。。。。。

其中，LINK和UNLINK已被HTTP1.1廢棄，再也不支持！

 

(四)Http狀態碼

一：http狀態碼

表示客戶端http請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工做

狀態碼的類別以下：

http狀態碼種類繁多，大概有60多種，實際上常用的只有14種，下面爲一一介紹

 

一、2XX 成功：請求被正常處理

1.1 200 OK

表示從客戶端發來的請求在服務器端被正常處理

1.2 204 No Content

表示服務器接收的請求以成功處理，但沒有資源可返回，即：響應報文中不含實體的主體部分

1.3 206 Partial Content

表示客戶端進行了範圍請求且服務器成功執行了這部分的GET請求，響應報文中包含由Content_Range指定範圍的實體內容

「Content_Range爲請求首部的一種類型，後面的隨筆會講到」

 

二、3XX 重定向： 服務器須要執行某些特殊處理以正確處理請求（即URI地址或者資源的緩存的資源有效時間過時）

2.1 301 Moved Permanently

永久性重定向：表示請求的資源已被分配了新的URI，之後應使用資源如今的URI，若是已經保存了書籤，這時候應該按照Location首部提示的URI從新保存

2.2 302 Found

臨時性重定向：表示請求的資源已被分配到了新的URI，但願（本次）能使用新的URI訪問

2.3 303 See Other

表示請求對應的資源存在另外一個URI,應該使用GET方法定向獲取請求的資源

PS：當30一、30二、303響應狀態碼返回，幾乎全部瀏覽器都會把POST改爲GET，並刪除請求報文內的主體，以後請求自動再次發送

30一、302標準禁止將POST改成GET，但實際中都會容許這麼作~~~GG

2.4 304 Not Modified

表示客戶端發送得附帶條件的請求時，服務器運行請求訪問，但未知足條件的狀況，304返回時，不包含任何響應的主體部分

附帶條件：採用GET方法的請求報文中包含If-......條件的任一首部，後面的隨筆中介紹

2.5 307 Temporary Redirect

臨時重定向：禁止將POST轉換爲GET，該狀態碼會嚴格遵照瀏覽器標準

 

三、客戶端錯誤：4XX的響應結果代表客戶端是發生錯誤的緣由所在

3.1 400 Bad Ruquest

請求報文存在語法錯誤

3.2 401 Unauthorized

發送的請求須要有經過http認證（BASIC認證、DIGEST認證）的認證信息

PS：若以前已經進行了一次請求，則表示用戶認證失敗

       返回含有401的響應必須包含一個適用於被請求資源的WWW-Authenticate首部用來質詢用戶信息

3.3 403 Forbidden

對請求資源的訪問被服務器拒絕（服務端沒有必要給出拒絕的詳細理由，若是想作說明，可在實體主體部分對緣由進行描述）

舉例：未得到文件系統的訪問受權、訪問權限出現某些問題等

3.4 404 Not Found

服務器上沒法找到請求的資源

 

四、 5XX服務器錯誤：服務器自己發生錯誤

4.1 500 Internal Server Error

服務器端執行請求時發生錯誤

4.2 503 Server Unavailable

服務器暫時處於超負載或者正在停機維護，如今沒法處理請求　

 

(五)Web服務器

一、http1.1規範容許一臺http服務器搭建多個web站點。。。

好比提供web託管服務的供應商，能夠用一臺服務器爲多爲客戶服務，也能夠以每位客戶持有的域名運行各自不一樣的網站，這裏利用了虛擬服務器的功能。。。

客戶端使用http協議訪問服務器時，會常常採用相似www.baidu.con這樣的主機名和域名

在互聯網上，域名經過DNS服務映射到IP地址以後訪問目標網站，可見，請求發送到服務器時，已是以IP地址形式訪問

因此，若是一臺服務器內託管了www.baidu.com和www.sina.com這兩個域名，收到請求時就須要搞清楚究竟要訪問哪一個域名

在相同的IP地址下，發送請求時，必須在Host首部內完成指定主機名或者域名的URI。

 

二、通訊數據的轉發程序

http通訊時，出客戶端和服務器外，還有一些用於通訊數據轉發的應用程序，好比代理、網關、隧道

2.1 代理：具備轉發功能的應用程序

扮演了客戶端和服務器「中間人」的角色，接受請求並轉發給服務器，同時也接受響應並返回給客戶端

代理不會改變URI，會直接將請求發送給持有資源的源服務器，而後響應經過代理服務器後再傳給客戶端

http通訊中，能夠級聯多臺代理服務器，每次經過代理服務器轉發請求和響應時，會追加寫入Via首部信息，以標記出通過的主機信息

代理服務器的優勢：利用緩存技術（下文）減小網絡帶寬流量，組織內部針對特定網站的訪問控制，獲取訪問日誌爲主要目的等

緩存代理：預先將資源的副本緩存在代理服務器上，再次受到對相同資源的請求時，能夠將本身的緩存返回

透明代理：轉發請求或者響應時，不對報文作任何加工的代理類型

 

2.2 網關：轉發其餘服務器通訊數據的服務器

接受客戶端發來的請求，就像本身擁有資源的服務器同樣處理請求

網關的工做機制與代理什麼相似，而網關能夠使通訊線路上的服務器提供非http協議服務

特色：提升通訊安全性，能夠在客戶端和網關之間通訊線路上加密以確保鏈接安全。

 

2.3 隧道：在客戶端和服務器之間進行中轉，並保持雙方通訊鏈接的應用程序

特色：能夠使用SSL等加密手段進行通訊，確保客戶端能與服務器進行安全的通訊

 

三、資源的緩存

緩存是指代理服務器或者客戶端本地磁盤內保存的資源副本。

利用緩存可減小對源服務器的訪問，節省通訊流量和通訊時間。

3.1 緩存的有效期

當源服務器的資源更新時，或者由於客戶端要求，緩存的有效時間等因素，都須要向源服務器確認有效性，若是緩存失效，緩存服務器將再次向源服務器獲取最新的資源

 

3.2 客戶端的緩存

緩存不只能夠存與代理服務器內，還能夠存在客戶端瀏覽器中。若是緩存有效，就能夠直接從本地磁盤中讀取資源

一樣，當緩存過時，仍是須要向源服務器請求資源

 

(六)報文首部

http請求和響應報文內容比較多，會分爲大概四部分更新，最近比較忙，沒太多時間整理- -

 

首先來看看報文結構吧

一、http請求報文

http請求報文由方法、URI、http版本。http首部字段等構成

下面給你們示例一個訪問my_view_page.php的請求報文首部信息

GET /my_view_page.php HTTP/1.1

Host: 10.0.17.183:8000

Connection: keep-alive

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Referer: http://10.0.17.183:8000/my_view_page.php

Accept-Encoding: gzip, deflate, sdch

關於報文的首部信息，稍微詳解

 

二、http響應報文

http響應報文由http版本、狀態碼（數字和緣由短語）、http首部字段3部分組成

如下是剛纔訪問my_view_page.php時服務器返回的響應報文首部信息：

HTTP/1.1 200 OK

Cache-Control: no-store, no-cache, must-revalidate

Date: Tue, 26 Jul 2016 09:32:11 GMT

Expires: Tue, 26 Jul 2016 09:32:12 GMT

Vary: Accept-Encoding

Content-Encoding: gzip

Content-Length: 3892

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

Last-Modified: Tue, 26 Jul 2016 09:32:12 GMT

報文中含有衆多的字段，其中又以http首部字段內容最豐富，其同時存在於請求和響應中，並涵蓋http報文相關的內容

 

三、http首部字段

定義：構成http報文的要素之一，在客戶端與服務器之間以http協議傳輸信息的過程當中，起到傳遞額外重要信息的做用

3.1首部字段結構

首部字段名：字段值

例如：以Content-Type來表示報文主體的對象類型

Content-Type：text/html

另外，字段值對應的單個http首部字段能夠有多個值，好比

Keep-Alive:timeout=15,max=100

 

3.2    4種http首部字段類型

http1.1規範了47種首部字段

 

3.2.1  通用首部字段

定義：請求和響應報文都會使用的首部

 

3.2.2  請求首部字段

從客戶端向服務器發送請求報文時使用的首部，補充了請求的附加內容、客戶端信息、相應內容相關優先級信息

 

3.2.3  響應首部字段

從服務器向客戶端返回響應報文時使用的首部。補充了資源內容更新時間等與實體有關的信息

 

 

3.2.4  實體首部字段

針對請求報文和響應報文的實體部分使用的首部，補充了資源內容更新時間與實體有關的信息

 

3.2.5  End-to-end首部和Hop-by-hop首部

http首部字段將定義成緩存代理和非緩存代理的行爲，分紅2種類型

端到端首部（End-to-end Header）

此類別中的首部會轉發給請求/響應對應的最終接受目標，並且必須保存在由緩存生成的響應中，另外規定它必須被轉發。

逐跳首部（Hop-by-hop Header）

此類別中的首部只對單次轉發有效，會因經過緩存或代理而再也不轉發；http1.1和以後的版本，如要使用該首部，需提供Connection首部字段。

 

下面列舉下http/1.1中的逐跳首部字段，除了這8個，其餘全部字段都屬於端到端首部。

Connection: 

Keep-Alive

Proxy-Authenticate

Proxy-Authorization

Trailer

TE

Transfer-Encoding

Upgrade

 

(七)通用首部字段

通用首部字段的意思，就是：請求和響應報文雙方都會使用的首部

一、Cache-Control

經過指定它的指令，能操做緩存的工做機制

指令參數是可選的，多個指令經過「，」分隔

Cache-Control: private, max-age=0, no-cache

Cache-Control指令一覽：

1.1  緩存請求指令

指令	參數	說明
no-cache	無	強制向源服務器再次驗證
no-store	無	不緩存請求或相應的任何內容
max-age[秒]	必須	相應的最大Age值
max-stale(=[秒])	可省略	接收已過時的響應
min-fresh=[秒]	必須	指望在指定時間內的響應仍有效
no-transform	無	代理不可更改媒體類型
only-if-cached	無	從緩存獲取資源
cache-extension		新標記指令（token{-}）

 

                                                                          

    

 

 

 

 

 

 

 

 

 

 

 

1.2  緩存響應指令

指令	參數	說明
public	無	可向任意方提供響應的緩存
private	可省略	僅向特定用戶返回響應
no-cache	可省略	緩存前必須先確認其有效性
no-store	無	不緩存請求或響應的任何內容
no-transform	無	代理不可更改媒體類型
must-revalidate	無	可緩存但必須再向源服務器進行確認
proxy-revalidate	無	要求中間緩存服務器對換緩存的響應有效性再次確認
max-age=[秒]	必需	響應的最大Age值
s-maxage=[秒]	必需	公共緩存服務器響應的最大Age值
cache-extension		新指令標記（token{-}）

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.3  public

共享、公開的緩存狀態，與private相反

Cache-Control: public

 

1.4  private

指定緩存對象，須要驗證

Cache-Control: private

 

1.5  no-cache

防止從緩存中返回過去的資源，請求中如包含該命令，表示客戶端不會接收緩存過的響應，必須向源放武器轉發請求

若是響應中包含該命令，那麼緩存服務器不能對其資源進行緩存，且源服務器也將不在對緩存服務器請求中提出的資源有效性進行確認，且禁止其對相應資源進行緩存操做

Cache-Control: no-cache=Location

由服務器返回的響應報文首部字段中，若Cache-Control中對no-cache字段名具體制定參數值，那麼客戶端在收到這個被指定參數值的首部字段對應的報文後，就不能緩存

換言之，無參數值的首部字段能夠使用緩存，只能在響應中制定該參數

 

1.6  no-store

請求中包含機密信息，緩存不能在本地存儲請求或響應的任一部分k

Cache-Control: no-store

 

1.7  s-maxage

通常指代理服務器

與max-age指令相同，不一樣點在於s-maxage只適用於供多位用戶使用的公共緩存服務器

當使用該指令時，直接忽略對Expires首部字段及max-age指令的處理

Cache-Control: s-maxage=604800（單位：秒）

 

1.8  max-age

緩存資源緩存時間數值低於指定數值，就接受緩存的資源，如max-age爲0，則須要請求源服務器

http1.1中，如遇到存在Expires首部字段的狀況，會忽略Expires字段，優先處理max-age指令

Cache-Control: max-age=604800（單位：秒）

 

1.9  min-fresh

要求緩存服務器返回未過指定時間的資源

Cache-Control: min-fresh=60（單位：秒）

 

1.10  max-stale

規定緩存的有效期，如指令中沒有參數，則不管多久，客戶端均可以接受響應，如指定了參數，即便過了有效期，只要在指令的範圍內，客戶端均可以接受響應

Cache-Control: max-stale

 

1.11  only-if-cached

表示客戶端只在緩存服務器有對應資源的狀況下才接受響應，若無，則返回504

Cache-Control: only-if-cached

 

1.12  must-revalidate

代理向客戶端返回響應前再次向源服務器確認資源的有效性，若無，則返回504，且該指令會忽略請求中的max-stale指令

Cache-Control: must-revalidate

 

1.13  proxy-revalidate

要求全部的緩存服務器在向客戶端返回響應以前再次向源服務器確認資源的有效性

Cache-Control: proxy-revalidate

 

1.14  no-transform

要求不管請求仍是響應，都不能改變實體主體的媒體類型，防止緩存或者代理壓縮圖片等操做

Cache-Control: no-transform

 

二、Connection

該首部字段具有下面2個做用

1）控制再也不轉發給代理的首部字段

Connection:再也不轉發的字段名（即刪除後再轉發）

2）管理持久鏈接

http1.1默認都是持久鏈接，客戶端會在持久鏈接上持續發送請求，當服務器明確表示須要斷開鏈接時，則指明首部字段值爲close

Connection: close

http1.1以前的版本默認都是非持久鏈接，須要在舊版本上保持持久鏈接，須要加入Keep-Alive指令

Connection-Keep-Alive

 

三、Date

代表建立http報文的日期和時間

目前http1.1版本使用以下格式的時間：

Date: Sun, 31 Jul 2016 01:28:48 GMT

 

四、Pragma

是http1.1以前的版本歷史遺留字段，僅做爲與http1.0的向後兼容而定義，規範定義的形式惟一，以下所示

Pragma: no-cache

只用於客戶端發送的請求中，客戶端要求全部的中間服務器不返回緩存的內容

 

五、Trailer

事先說明在報文主體後記錄了哪些首部字段，可應用於http1.1版本分塊傳輸編碼時

 

六、Transfer-Encoding

規定報文主體的編碼方式

http1.1的傳輸編碼方式僅對分塊傳輸編碼有效

Transfer-Encoding: chunked

 

七、Upgrade

檢測http協議及其餘協議是否可以使用更高的版本進行通訊，其參數值可用來指定一個徹底不一樣的通訊協議

客戶端請求：

GMT /index.htm HTTP/1.1

Upgrade: TLS/1.0

Connection: Upgrade

服務器響應:

HTTP/1.1 101 Switching Protocols

Upgrade: TLS/1.0, HTTP/1.1

Connection: Upgrade

上面的例子中，首部字段Upgrade指定的值爲TLS/1.0，這裏的兩個首部字段的對應關係，Connection的值被指定爲Upgrade。

Upgrade對象僅限於客戶端和鄰近服務器之間，所以，使用首部字段Upgrade時，還須要額外指定Connection Upgrade

對於附有首部字段Upgrade的請求，服務器能夠用101Switch Protocols狀態碼做爲響應返回

 

八、Via

使用首部字段Via是爲了追蹤客戶端與服務器間的請求和響應報文的傳輸路徑

Via不只用於追蹤報文的轉發，還可避免請求迴環的發生，所以，必須在通過代理時附加該首部字段內容

 

九、Warning

告知用戶與一些與緩存相關的問題的警告

Warning的首部格式以下，日期部分可省略

Warning：[警告碼] [警告的主機：端口號] "[警告內容]" （[日期時間]）

http1.1中定義了7中警告，警告碼對應的警告內容僅供參考

另外，警告碼具有擴展性，從此有可能追加新的警告

 

(八)請求首部字段

請求首部字段

定義：請求首部字段是從客戶端到服務器發送請求報文中所使用的字段，裏面包含了附加信息、客戶端信息以及對響應內容相關的優先級等內容

一、Accept

通知服務器用戶代理可處理的媒體類型及媒體類型的相對優先級，可以使用type/subtype這種形式，一次指定多種媒體類型

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

q表示權重，默認值爲1.0，當服務器提供多種內容時，將會有優先返回權重值最高的媒體類型

下面舉幾個例子：

文本文件：

text/html,text/plain,text/css...

application/xhtml+xml,application/xml...

圖片文件：

image/jpeg,image/gif,image/png...

視頻文件：

video/mpeg,video/quicktime...

應用程序使用的二進制文件

application/octet-stream,application/zip...

 

二、Accept-Cherset

通知服務器用戶代理支持的字符集及字符集的相對優先級，可一次性指定多個字符集。

該首部字段可用權重q值來表示相對優先級

該首部字段應用於內容協商機制的服務器驅動協商

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

 

三、Accept-Encoding

告知服務器用戶代理支持的內容編碼及內容編碼優先級順序，可一次性指定多種內容編碼

Accept-Encoding: gzip, deflate

經常使用的幾種編碼格式：

gizp：由文件壓縮程序gzip（GUN zip）生成的編碼格式

compress：由UNIX文件壓縮程序compress生成的編碼格式

deflate：組合使用zlib格式及由deflate壓縮格式生成的編碼格式

jdentity：不執行壓縮或不會變化的默認編碼格式

一樣，這裏能夠使用q值表示相對優先級，也能夠使用（*）做爲通配符，指定任意的編碼格式

 

四、Accept-Lanuage

告知服務器用戶代理可以處理的天然語言集，以及其相對有限集，可一次指定多種天然語言集

一樣可以使用權重值q表示相對優先級

Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3

 

五、Authorization

告知服務器用戶代理的認證信息（證書值）。

一般想要經過驗證的用戶代理會在接受到第一次返回的401狀態碼響應後，把首部字段加入請求中，共用緩存接收到含有該字段的請求時操做處理會有所差別

 

六、Expect

客戶端使用該字段告知服務器，指望出現某種特定行爲

若是服務器沒法理解指望做出迴應而發生錯誤，會返回狀態碼417Expect Failed，客戶端能夠利用該字段，寫明所指望的擴展

http/1.1規範值定義了100-continue（轉檯嗎100Continue之意）

Expect: 100-continue

 

七、From

告知服務器使用用戶代理的用戶墊子郵件地址

目的：顯示搜索引擎等用戶代理的負責人的電子郵件聯繫方式 

From: IMyalost@163.com

 

八、Host

告知服務器請求的資源所處的互聯網主機名和端口號

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

Host: www.baidu.com

 

九、If-Match

格式如If-xxx這樣的請求首部字段，均可以稱之爲條件請求，服務器收到請求，只有斷定條件爲真時，纔會執行請求

該字段告知服務器匹配資源所用的實體標記（ETag）值，這時沒法使用弱ETag值

若是判斷條件不爲真，則返回412Precondition Failed響應

還能夠使用（*）指定If-Match的字段值，這種狀況下服務器將忽略ETag值，只要資源存在就處理請求

If-Match: "123456"

 

十、If-Modified-Since

條件請求，告知服務器若字段指定值早於資源更新時間，則但願能處理請求，若是在該字段指定的日期時間大於資源更新時間，則返回304Not Modified響應

用於確認代理或者客戶端擁有的本地資源的有消息

If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT

 

十一、If-None-Match

條件請求，和If-Match做用相反。當該字段值的實體標記（ETag）值與請求資源的ETag不一致時，告知服務器處理該請求

在GET或HEAD方法中使用該字段可獲取最新的資源

 

十二、If-Range

條件請求，告知服務器若指定的值和請求資源的值一致，則做爲範圍請求處理，反之，則返回所有資源

request：                                                   response：

GET /index.html                                         206 Partial Content

If-Range: "123456"                                    Content-Range: bytes 5001-10000/10000

Range: bytes=5001-10000                        Content-Length:5000

上面的請求和資源匹配一致，那麼久做爲範圍請求處理

 

1三、If-Unmodified-Since

條件請求，該字段和If-Unmodified-Since字段做用相反，做用是告知服務器，指定的請求資源只有在字段值內指定的日期以後，未發生更新的狀況下，才能處理請求。

如指定時間以後發生更新，則返回412 Precondition  Failed做爲響應返回

If-Unmodified-Since: Thu, 03 Jul 2016 00:00:00 GMT

 

1四、Max-Forwards

咱們都知道使用http協議通訊時，請求可能會通過代理等多臺服務器，若是因爲某些緣由致使請求轉發失敗，那麼客戶端收不到響應，咱們對此一無所知

經過TRACE或者OPTIONS方法，發送包含該字段的請求時，該字段以十進制整數形式指定可通過的服務器最大數目

簡單來說，就是指定Max-Forwards的值，每通過一次轉發，就-1.當值變爲0.直接返回響應

Max-Forwards: 10

 

1五、Proxy-Authorization

收到代理服務器發來的認證質詢時，客戶端向代理服務器發送包含首部字段的請求，以告知服務器所須要的認證的信息

Proxy-Authorization: Basic dGLwoPNLAGKGFY5

 

1六、Range

對於只需獲取部分資源的範圍請求，包含首部字段Range便可告知服務器資源的指定範圍

接收到附帶Range字段的服務器，會返回206Partial Content的響應；沒法處理請求時，則返回200 OK的響應及所有資源

Range: bytes=5001-10000

 

1七、Referer

告知服務器請求的原始資源的URI

Referer:www,baidu.com/index.xml

 

1八、TE

告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級

TE:gzip, deflate;q=0.5

該字段還能夠指定伴隨trailer字段的分塊傳輸編碼的方式

TE:trailers

 

1九、User-Agent

該字段會將建立請求的瀏覽器和用戶代理名稱等信息傳給服務器

若是由網絡爬蟲發起請求，可能會在請求中添加爬蟲做者的墊子郵件地址。所以，若是請求通過代理，那麼中間也極可能被添加上代理服務器名稱

User-Agent: Mozilla/5.0 (windows NT 6.1; WOW64; rv13.0) Gecko/=20100101 Firfox/13.0.1

 

(九)響應首部字段

響應首部字段：

服務器向客戶端返回響應報文中所使用的字段，用於補充的附加信息、服務器信息、以及對客戶端的附加要求等

一、Accept-Ranges

告知客戶端服務器可否處理範圍請求，以指定獲取服務器的某部分資源

可指定的字段值分2種：

1.1   bytes:可處理範圍請求

1.2   none:不能處理範圍請求

Accept-Ranges: bytes

 

二、Age

告知客戶端源服務器建立響應多久了，單位S

若建立響應的是緩存服務器，該字段指緩存後響應再次發起認證到認證完成的時間值，此時，必須加上首部字段Age

Age: 600

 

三、ETag

告知客戶端實體標識。

這是一種將資源以字符串形式作惟一標識的一種方式，服務器會爲沒份資源分配對應的ETag值

另外，當資源更新時，ETag值也須要更新

ETag: "82e22293907ce725faf67773957acd12"

強ETag值和弱ETag值

3.1   強ETag值：不論實體發生多麼細微的變化，都會改變其值

ETag: "usagi-1234"

3.2   弱ETag值

只提示資源是否相同；只有資源發生了根本改變，產生差別纔會改變ETag值，此時，會在字段值最開始處附加W/

ETag: W/"usagi-1234"

 

四、Location

將響應接受方引導至某個與請求URI位置不一樣的資源

基本上該字段都會配合3xx：Redirction的響應，提供重定向的URI

Location: http://www.usagidesign.jp/sample.html

 

五、Proxy-Authenticate

把代理服務器所要求的認證信息發給客戶端，他的認證行爲在客戶端與代理間進行

Proxy-Authenticate: basic realm="Usagidesign Auth"

 

六、Retry-After

告知客戶端在多久以後再次發送請求，主要配合狀態碼503 Service Unavailable響應，或者3XX Redirect響應一塊兒使用

字段值能夠指定具體的日期時間（Wed, 04 Jul 2012 06: 34: 24 GMT等格式），也能夠是建立響應後的秒數

Retry-After: 120

 

七、Server

告知客戶端當前服務器上安裝的http服務器應用程序的信息。其中包含軟件應用名稱，甚至版本號和安裝時的啓動項

Server: Apache/2.2.17（Unix）

Server: Apache/2.2.6（Unix） PHP/5.2.5

 

八、Vary

控制緩存。源服務器向代理傳達關於本地緩存使用方法的命令

客戶端收到從代理服務器收到的從源服務器返回的包含該字段指定項的響應以後，若再次進行緩存，僅對請求中含有相同字段的請求返回緩存

Vary: Accept-Language

 

九、WWW-Authenticate

HTTP訪問認證。告知客戶端適用於訪問請求URI所指定資源的認證方案和帶參數提示的查詢

狀態碼401 Unauthorized響應中，確定包含該字段

 

(十)實體首部字段

一、定義

包含在請求和響應中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息

二、Allow

通知客戶端可以支持的Request-URI指定資源的全部http方法：若是服務器接收到不支持的方法，會返回狀態碼405Method Not Allowed做爲響應返回

Allow：GET, HEAD

 

三、Content-Encoding

告知客戶端服務器對實體的主體部分的選用的內容編碼方式

內容編碼指在不丟失實體信息的前提下所進行的壓縮

主要採用如下這四種內容編碼方式

gizp,conpress,deflate,identity

Content-Encoding: gizp

 

四、Content-Lanuage

告知客戶端實體主體使用的天然語言（優先接收的語言）

Content-Lanuage: zh-CN

 

五、Content-Length

代表實體主體部分的大下（單位是字節）

若對實體主體進行編碼傳輸，不能使用該字段

Content-Length: 15000

 

六、Content-Location

給出了與報文主體部分相對應的URI。與Location不一樣，該字段表示的是報文主體返回資源的URI

Content-Location: http://www.baidu/com/index-miss.html

 

七、Content-MD5

由一串由MD5算法生成的值，其目的在於檢查報文 主體在傳輸中是否保持完整，以及確認傳輸到達。 

Content-MD5: OFJKGKLDFUIGNG35565FGNHLDGNH==

 

八、Content-Range

告知客戶端做爲響應返回的實體的哪一個部分符合範圍請求，（單位：字節），表示當前發送部分及整個實體大小

Content-Range: bytes 5001-10000/10000

 

九、Expires

告知客戶端資源失效的日期

若是首部字段存在Cache-Control有指定max-age指定時，會優先處理max-age指令

Expires: Wed, 04 Jul 2016 09:26:05 GMT

 

十、Last-Modified

指明資源的最終修改的時間

Last-Modified: Wed, 04 Jul 2016 09:26:05 GMT

 

這部分主要是附帶說說，通常工做中不經常使用到，但瞭解也是頗有好處的 -  -

爲Cookie服務的首部字段

Cookie的工做機制是用戶識別及狀態管理。

實現原理：方便管理用戶狀態，經過web瀏覽器將一些數據臨時寫入用戶的計算機內，當用戶訪問時可經過通訊方式取回以前發送的Cookle

        調用Cookie的時候，因爲能夠調用Cookie的有效期，以及發送方的域、路徑、協議等信息，因此正規發佈的Cookie不是由於來自其餘web站點和攻擊者的攻擊而泄漏

爲Cookle服務的首部字段：

 

一、Set-Cookie字段的屬性：

1）expires

指定瀏覽器可發送Cookie的有效期

若不指定則默認爲會話時間段內

一旦Cookie從服務端發送到客戶端，服務器就不存在可顯式刪除Cookie的方法，但可經過覆蓋已過時的Cookie，實現對客戶端的實質性刪除

 

2）path

用於限制指定Cookie發送範圍的文件目錄

 

3）domain

經過該屬性指定的域名可作到與結尾匹配一致

除了針對具體指定的多個域名發送的Cookie外，不指定domain屬性顯得更安全

 

4）secure

限制web界面僅在HTTPS安全鏈接時，才能夠發送Cookie

發送Cookie時，指定屬性的方法以下：

Set-Cookie: name=value; secure

 

5)HttpCookie

Cookie的擴展功能，使JavaScript腳本沒法得到Cookie。主要目的是爲了防止跨站腳本攻擊對Cookie的信息竊取

發送指定HttpOnly屬性的方法以下：

Set-Cookie: name=value; HttpOnly

 

二、Cookie

告知服務器，客戶端想得到http狀態管理支持時，就會在請求中包含從服務器接收到的Cookie。接收多個時，一樣能夠以多個發送

到這裏基本關於http協議的基礎就整理完了，整個的思路大概就是對TCP/IP的介紹，握手，數據傳輸的方式以及幾種數據傳輸方法，請求響應報文的類型，字段等知識。。。

 

(十一)http與https

1、http的缺點

以前有介紹過http協議相關的一些知識，http是至關優秀和方便的，但它也有缺點，主要不足表如今以下幾個方面：

△ 通訊使用明文（不加密），內容可能會被竊聽

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

△ 沒法證實報文的完整性，因此有可能已被篡改

其餘未加密的協議也存在這類問題

△ 某些特定web服務器和特定web瀏覽器存在安全漏洞

 

一、通訊使用明文可能被竊聽

http自己不具備加密功能，沒法作到對通訊總體（使用http協議通訊的請求和響應內容）進行加密，即：http報文使用明文（未經加密的報文）方式傳送

TCP/IP協議族的通訊機制：通訊內容在全部通訊線路上均可能被窺視

應對措施：對通訊進行加密處理防止被竊聽

加密對象：

①.通訊的加密

http協議沒有加密機制，能夠經過SSL（Secure Socket Layer:安全套接層）或TLS（Transport Layer Security:安全層傳輸協議）組合使用，

加密http的通訊內容，這就是常說的https（超文本傳輸安全協議）

②.內容的加密

http協議沒有加密機制，對傳輸的內容自己進行加密，即報文實體主體部分；客戶端對請求報文加密處理後傳輸，但前提是客戶端和服務器都具備加密和解密機制，

主要應用於WEB服務中（但仍然有被篡改的風險）

 

二、不驗證通訊方身份，可能遭遇假裝

http協議中請求和響應不會對通訊方進行確認，即存在「服務器是不是發送請求中URI真正指定的主機。返回的響應是否真的返回到實際提出請求的客戶端」等相似問題

任何人均可以發起請求，服務器只要接收到請求，無論對方是誰都會返回一個響應（僅限於發送端IP和端口號沒有被WEB服務器設定限制訪問的前提下）

http協議的隱患有如下幾點：

①.沒法肯定請求發送至目標的web服務器是不是按真實意圖返回響應的服務器；有多是已假裝的服務器

②.沒法肯定響應返回到的客戶端是不是按真實意圖接受響應的那個客戶端；有多是已假裝的客戶端

③.沒法肯定正在通訊的對方是否具有訪問權限；由於某些web服務器保存有重要信息，只發給特定用戶通訊的權限

④.沒法判斷請求來自何方

⑤.即便時無心義的請求也會接收，沒法阻止海量請求下的D0S攻擊（Denial of Service:拒絕服務攻擊）

 

三、沒法證實報文完整性，可能已遭篡改

完整性：指信息的準確度，若沒法證實其完整性，意味着沒法判斷信息是否正確

http協議沒法證實通訊的報文完整性，所以，請求或者響應在傳輸過程當中，若是遭到篡改，是沒法知道的；相似這種請求或響應傳輸中被攻擊者攔截篡改的攻擊

稱爲中間人攻擊（Man-in-the-Middle attack,MITM）

防止篡改：經常使用的方法有MD5和SHA-1等散列值校驗的方法，以及來確認文件的數字簽名方法

 

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

一、一般把添加了加密和身份認證機制的http協議稱爲https（HTTP Secure）；證書可證實服務器或者客戶端的身份

 

二、https至關於身披SSL外殼的http

https並不是應用層的一種新協議，而是在http通訊接口部分用SSL（Secure Socket Layer：安全套接字層）和TLS（Transport Layer Security：安全層傳輸協議）協議代替

一般，http和TCP直接通訊，當使用SSL時，先由http和SSL通訊，再由SSL和TCP通訊

 

SSL是獨立於http的協議，其餘應用層的如SMTP何Telnet等協議均可以配合SSL進行使用

 

三、加密技術

SSL採用公開密鑰加密（Public-key cryptography）的加密處理方式，加密方法中加密算法是公開的，但密鑰是保密的，以保持加密方法的安全性（密鑰用來對已經加密的內容進行解密）

加密和解密通用一個密鑰的方式稱爲共享密鑰加密（Common key crypto system），也稱爲對稱密鑰加密

公開密鑰加密方式：

公開密鑰加密使用一對非對稱密鑰，一把叫作私有密鑰（private key），一把叫作公開密鑰（public key）

過程：發送密文的一方使用對方公開的密鑰進行加密，對方收到被加密信息後，使用本身的私有密鑰進行解密（要想根據密文和公開密鑰解密，理論上能夠，但實際操做起來，很是困難）

HTTPS採用混合加密機制

https採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可實現安全交換，則可能僅使用公開密鑰加密（公開密鑰加密相比共享密鑰加密，速度較慢）

實際運用中應該合理運用兩種加密機制的優點，組合起來進行通訊（交換密鑰環節利用公開密鑰加密方式，創建通訊交換報文階段使用共享加密機制）

 

四、證書

由數字證書認證機構（CA:Certificate Authority）和其餘相關機關頒發的公開密鑰證書

處於客戶端和服務器雙方均可信賴的第三方機構立場，對經過申請的服務器公開密鑰作數字簽名，分配該公開密鑰，將其與共鑰證書綁定，而後服務器傳給客戶端，以進行公開密鑰加密方式通訊；

收到證書的客戶端使用數字證書認證機構的公開密鑰，對服務器證書的數字簽名進行認證，而後明確2點：

①.認證服務器的公開密鑰是真實有效的數字證書認證機構

②.服務器的公開密鑰是指的信賴的

做用：

①.證實通訊方的服務器是否規範

②.確認對方服務器背後運營的企業是否真實存在（擁有該功能的證書就是EV SSL證書：Extended Validation SSL Cetificate ）；特色：瀏覽器背景色是綠色的

 

五、HTTPS安全通訊機制

HTTPS通訊過程：

①.客戶端發送Client Hello報文開始通訊，報文中包含客戶端支持的SSL指定版本、加密組件、列表等

②.服務器接收到請求報文時，在響應報文中包含SSL版本以及加密組件發送Server Hello（加密組件內容從接收到的客戶端加密組件中篩選出來）

   而後服務器發送Certificate報文，其中包含公開密鑰證書

   最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束

③.第一次握手結束，客戶端Client Key Exchange報文迴應，報文中包含通訊加密中使用的一種名爲Pre-master sercet的隨機密碼串（該報文已用上一步驟的公開密鑰進行加密）

   接着客戶端你繼續發送Change Cipher Spec報文，該報文提示服務器，在此報文以後的通訊採用Pre-master sercet密鑰加密

   最後客戶端發送Finished報文；該報文包含通訊鏈接至今所有報文的總體校驗值（此次握手可否成功，以服務器是否能夠正確解密報文爲判斷標準）

④.服務器一樣發送Change Cipher Spec報文

   服務器一樣發送Finisher報文

⑤.服務器和客戶端Finished報文交換完成後，SSL鏈接完成，通訊收到SSL保護，

⑥.應用層協議開始通訊，即HTTP請求

⑦.最後由客戶端斷開鏈接；斷開鏈接時，發送close_notify報文，而後發送TCP FIN報文關閉與TCP的通訊

上面的通訊過程當中，應用層發送數據時會附加MAC（Message Authentication Code）報文摘要，MAC可查詢報文是否遭受篡改，保護報文完整性

通訊流程圖（服務器公開密鑰證書創建HTTPS的過程）

HTTPS使用SSL（Secure Socket Layer：安全套接字層）和TLS（Transport Layer Security：安全層傳輸協議）這兩種協議

△ ：使用SSL時，處理速度回變慢

①.通訊慢：通訊時候大量消耗CPU及內存資源，相比較HTTP而已，網絡負載可能變慢2-100倍（通訊量增長）

②.加密處理：在服務器和客戶端都要進行加密和解密，更多的消耗了服務器和客戶端硬件資源，致使負載加強

改善方案：使用SSL加速器（專用服務器），爲SSL通訊專硬件，能夠提升數倍SSL計算你速度，僅在SSL通訊處理時發揮做用，以分擔負載。

 

(十二)http概述

一、web客戶端和服務器

http客戶端發出請求，其中包含請求內容，發給服務器，服務器再返回內容中回送請求的數據，http客戶端和服務器構成了萬維網的基本組件

咱們常說的客戶端，就是web瀏覽器，好比微軟的IE、Google的chrome，火狐的Firefox等，瀏覽器向服務器發送http請求對象，並將對象顯示在你的屏幕上

 

二、資源

web服務器是web資源的宿主，源頭；最簡單的web資源就是服務器文件系統中的靜態文件，其中可能包含不少內容：文本文件、HTML文件、word文件、圖片文件、Adobe的acrobat文件等

但資源不侷限於靜態文件，它還能夠根據須要生成軟件程序（好比照相機中活生生的照片、股票交易、房產交易的數據庫、在線商店中的禮物等等）

總之，全部類型的內容都來源於資源。。。

 

2.1 媒體類型

互聯網上有數千種不一樣的數據類型，http給每種須要經過http傳輸的對象都打上了MIME類型（MIME type）的數據格式標籤

MIME：多用途英特網郵件擴展

web瀏覽器每次從服務器取回一個對象時，會先查看其MIME類型，看看可否處理該類型；大多數瀏覽器均可以處理數百種常見的對象類型

MIME類型是一種文本標記，表示一種主要的對象類型和一個特定的子類型，中間由一條斜槓來分隔，例如

HTML格式的文本文檔：text/html

普通的ASCII文本文檔：text/plain

圖片類型：image/jpeg、image/gif

 

2.2 URI

每一個服務器資源都有一個名字，這樣客戶端就能夠說明它對什麼資源感興趣

服務器資源名稱被稱爲：統一資源標識符（Uniform Resource Identifier,URI）

URI就像因特網上的郵政地址同樣，在世界範圍內惟一標識而且定位信息資源

 

2.3 URL

URL：統一資源定位符是資源最多見的形式，它描述了一臺特定服務器上某資源的特定資源，明確說明了如何從一個精確、固定的位置獲取資源

上圖的URL說明了協議、服務器和本地資源

大部分URL遵循一種標準格式，該格式包含三個部分：

第一部分：方案；說明了訪問資源所使用的協議類型，一般爲http協議：hhtp://

第二部分：地址；好比：www.baidu.com

第三部分：指定服務器上某個資源，好比：specisal/saw-blade.gif

 

2.4 URN

URI的第二種方式就是URN：統一資源名；URN是做爲特定內容的惟一名稱使用的，與目前的資源所在地無關，使用URN，能夠將資源四處轉移，還可用同一個名字經過多種網絡協議來訪問資源

URN還處於試驗階段，由於其有效的工做須要一個支撐架構來解析資源的位置。而此類架構比較缺少，後面詳解介紹

 

三、事務

一個事務由一條請求命令和一條響應結果構成，這種通訊時經過http報文（HTTP message）的格式化數據塊進行的

事務也能夠理解爲從客戶端到服務器再到客戶端，一次完整通訊的過程

 

3.1方法

http支持八種不一樣的請求命令，被稱爲方法，每條請求報文都包含一個方法，告訴服務器要執行什麼動做，以前有專門介紹過這幾種方法；

傳送門：http://www.cnblogs.com/imyalost/p/5630940.html

 

3.2狀態碼

每條響應報文都會攜帶一個狀態碼，用以告知客戶端，請求結果，或是否須要其餘動做，以前也有介紹過這幾種狀態碼；

傳送門：http://www.cnblogs.com/imyalost/p/5688169.html

 

3.3一個web界面中能夠包含多個對象

一般並非單個資源，而是一組資源的集合（一個事務得到一種資源，不一樣的資源【甚至分佈在不一樣服務器上】組合構成一個界面）

 

四、報文

構成：一行行簡單的字符串組成

特色：純文本，方便讀寫

請求報文（request message）：從客戶端發往服務器

響應報文（response message）：從服務器發往客戶端

http報文包括如下三個部分：

起始行：報文第一行，用來講明要作什麼，出現了什麼狀況

首部字段：位於起始行後面，有零個或者多個，每一個首部字段都包含一個名字和一個值，便於解析，之間用冒號（：）隔開，以一個空行結束

主體：空行下面爲報文主體，其中包含了全部類型的數據

 

五、鏈接協議

5.1 TCP/IP

http協議是位於整個數據傳輸通訊的最上層應用層協議，不關注細節，負責通訊細節的協議爲傳輸層控制協議（Transmission Control Protocl,TCP）

TCP特色：1）無差錯的數據傳輸

        2）按序傳輸（按照數據發送順序到達服務器）

        3）未分段的數據流（任意時刻任何大小將數據發出去）

英特網是全世界計算機和網絡設備最經常使用的層次化分組交換網絡協議集，其隱藏了網絡和硬件的特色和弱點，使各種型的計算機和網絡都能進行可靠的通訊

下面是互聯網協議的五層協議棧

 

 

5.2 鏈接、IP地址及端口號

客戶端向服務器發送請求報文以前，須要用網際協議（Internet Protocol，IP）地址和端口號在客戶端和服務器之間創建一條TCP/IP鏈接通道

URL是資源的地址，天然可以爲咱們提供儲存資源的機器的地址，看下面幾個URL：

http://207.200.83.29:80/index.html

http://www.netscape.com:80/index.html

http://www.netscape.com/index.html

第一個使用了機器的IP地址207.200.83.29，以及端口號80

第二個使用了文本形式的域名（主機名：IP地址比較人性化的別稱）。經過域名服務（Domain Name Service，DNS）機制對主機名進行轉換，後面詳細介紹這一部分

第三個沒有端口號，這種狀況通常默認端口號爲80。

下圖爲瀏覽器經過http顯示服務器中某個簡單HTML資源的流程導圖

 步驟以下:

1)瀏覽器從URL中解析出服務器主機名；

2）瀏覽器將主機名轉換爲服務器的IP地址；

3）瀏覽器將端口號（若是有）從URL中解析出來；

4）瀏覽器創建一條與服務器的鏈接TCP鏈接通道；

5）瀏覽器向服務器發送一條http請求報文；

6）服務器向瀏覽器發送一條http響應報文；

7）結束通訊，關閉鏈接，瀏覽器顯示具體資源；

說到這裏，我很想寫寫關於數據通訊時候所謂的「三次握手」，但以前的http協議基礎中已經介紹過，還不懂的能夠去裏面找找，其實就是數據的封裝

 

六、協議版本

目前咱們使用的http協議版本是http1.1，其重點關注的是校訂http設計中的結構性缺陷，明確語義，引入重要的性能優化措施，並刪除一些很差的特性

HTTP-NG（http2.0）：是http1.1後繼結構的原型建議，重點關注性能的大幅優化，以及更強大的服務邏輯遠程執行框架

                   目前http2.0還在不斷商議中，可能被應用到的新技術預計有如下7種，不排除有重大更改的可能性

                   

 

七、web的結構組件

web的應用程序，除了瀏覽器和服務器以外，還有其餘幾個很重要的組件（之前的博客中有介紹，因此這裏就大體說下，後面具體解釋他們的功能用處）

7.1 代理：位於客戶端和服務器之間的http中間實體

web安全、應用集成以及性能優化的重要組成模塊

出於通訊安全考慮，會將代理作爲轉發全部web數據流的可信任中間節點使用，還可對請求響應進行過濾，後面詳細介紹

 

7.2 緩存：http倉庫，使經常使用頁面資源能夠保存在離客戶端更近的地方

web緩存或者代理緩存，能夠將通過代理傳送的經常使用的容許緩存的資源保存下來，下一個請求如有相同的資源，可直接享受該資源

http對緩存定義了不少功能，使緩存更高效，並規範了緩存資源的有效期和隱私性，後面詳細介紹

 

7.3 網關：鏈接其餘應用程序的特殊web服務器

網關一般將http數據流轉換成其餘的協議，接受請求時就好像本身是資源的源服務器，例如

一個http/ftp網關會http請求接受對ftp-URL的請求，但經過ftp協議來獲取資源，獲得的資源被封裝成一條http報文，發送給客戶端

關於具體的網關的內容，後面詳細介紹

 

7.4 隧道：對http通訊報文進行盲轉發的特殊http應用程序

隧道經常使用的方式是經過http鏈接承載加密的安全套接層（Secure Scokets Layer,SSL）數據流，這樣SSL數據流能夠穿過只容許web數據流經過的防火牆

隧道能夠在非http網絡上轉發數據（顯示的是HTTP/SSL隧道）

 

7.5 Agent代理：表明用戶發起自動http請求的半智能web客戶端程序

其餘類型：對web上閒逛的自動用戶採用Agent代理，無人監視下發布http事務並獲取內容，好比：「網絡蜘蛛」、「網絡機器人」等

自動搜索引擎「網絡蜘蛛」就是Agent代理，能夠全世界範圍內獲取web頁面

 

(十三)URL與資源

1、URL的語法 

URL是互聯網資源的標準化名稱

URL提供了一種定位互聯網上任意資源的手段，但這些資源要經過不一樣方案（協議：好比http、ftp、smtp）來訪問，所以URL語法會略有差別

大部分URL都遵循通用的語法，並且不一樣URL方案風格和語法都有重疊

大多數URL協的語法都創建在下面9個部分構成的通用格式上：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

其中最重要的3個部分是：方案（scheme）、主機（host）和路徑（path）

通用URL組件：

 

一、方案-使用什麼協議

方案：實際上規定了如何訪問指定資源的主要標識符，它告訴負責解析URL的應用程序應該是用什麼協議

方案組件必須以一個字母符號開始，由第一個「：」符號將其與URL其他部分分隔開來。（方案名大小寫不敏感）

 

二、主機與端口

想要在往上尋找到資源，應用程序須要知道哪臺機器裝載了資源，以及在機器的什麼地方能夠找到對目標資源進行訪問的服務器，URL的主機和端口提供這2點信息

主機組件標識了往上能訪問資源的宿主機器。可用主機名或者IP地址來表示主機名。好比下面2個URL就是指向同一個資源

主機名指向：http://joes-hardware.com:80/index.html

IP指向：161.58.228.45:80/index.html

端口組件標識了服務器正在監聽的網絡端口。對下層使用TCP協議的http協議來講，默認端口爲80

 

三、用戶名和密碼

有些服務器都要求輸入用戶名和密碼才容許用戶訪問數據，好比FTP（文件傳輸協議），以下面幾個例子

ftp://ftp.prep.ai.mit.edu/pub/gnu

沒有用戶名和密碼，只有標準的協議、主機和路徑；若是某個應用程序使用的URL協議要求輸入用戶名密碼，但用戶沒有提供，一般會插入一個默認的用戶名和密碼，好比FTP

ftp://anonymous@ftp://ftp.prep.ai.mit.edu/pub/gnu

指定了一個用戶名anonymous，與主機組合在一塊兒，看起來像一個email地址同樣；字符「@」將用戶名和密碼組件與其餘部分分隔開來

ftp://anonymous:my_password@ftp://ftp.prep.ai.mit.edu/pub/gnu

指定了用戶名和密碼，二者之間由字符「：」隔開

 

四、路徑

路徑說明了請求的資源位於服務器的什麼地方，一般是一個分級的文件系統路徑；好比：

http://joes-hardware.com:80/seasona/index-fall.html

這個URL中的資源路徑就是seasona/index-fall.html，很像Unix文件系統中的文件系統路徑

路徑是服務器定位資源所需的信息，能夠用「/」將http URL中的路徑組件劃分爲一些路徑段（path segment），每一個路徑段都有本身的參數字段

 

五、參數

對不少協議來講，只有簡單的主機名和到達對象路徑的是不夠的，除了端口和用戶名密碼，還須要更多的內容才能夠訪問

有些負責解析URL的應用程序須要協議參數才能工做；不然服務器不會提供服務，或者提供錯誤的服務，好比

ftp協議有兩種傳輸方式：二進制和文本。若是用文本形式傳送二進制圖片，結果很難預料有多糟糕

參數組件是URL中的名值隊列表，由「/」將其與其餘部分分隔開，好比

ftp://ftp.prep.ai.mit.edu/pub/gnu;type=d      

參數爲type=d，其中參數名爲type，值爲d

 

六、查詢字符串

在咱們發送請求時，不少的資源，好比數據庫服務，均可以經過查詢來縮小請求資源的類型範圍，例如

http://www.joes-hardware.com/inventoty-check.cgi?itcm-12731

問號（？）右邊的內容就是這個URL的查詢組件。URL的查詢組件和標識網關資源的URL路徑組件一塊兒被髮送給網關資源。能夠將網關當作訪問其餘應用程序的訪問點

以下圖：查詢目的是檢查清單中是否size爲large、color爲blue的條目

網關基本都是但願查詢字符串以一系列「名/值」對的形式出現，名值對之間用「&」分隔

上面的例子，查詢組件有2個名/值對：item=12731和color=blue

 

七、片斷

有些資源類型，好比HTML，除了資源級意外，還能夠進一步劃分，好比一個帶有章節的大型文本文檔，資源的URL會指向整個文檔，但理想狀況，能夠指向資源中的章節

爲了方便引用，URL容許使用片斷（frag）組件來表示資源內的一個片斷，片斷掛在URL右邊，最前面有一個字符「#」，好比：

http://www.joes-hardware.comtools.html#drills

這個例子中，片斷引用了joes-hardwareweb服務器上頁面/tools.html中的一個部分，這部分名字叫drills

服務器處理的是整個對象，URL片斷僅由客戶端使用並展現

 

2、URL快捷方式

web能夠理解並使用URL的快捷方式，好比縮略，自動擴展（用戶輸入關鍵部分，瀏覽器負責填充）

 

一、相對URL

URL有2種方式：絕對的和相對的。目前爲止，咱們使用的URL基本都是絕對的，它包含了訪問資源所需的所有信息

相對URL是不完整的，要從相對URL中獲取訪問資源的所有信息，就必須相對於另外一個基礎（base）的URL進行解析

相對URL是URL的一種便捷縮略記法，下面是一個嵌入了相對URL的HTML文檔實例

<html>
<head><title>joe's tools</title></head>
<body>
<h1>tools page</h1>
<h2>hammers<h2>
<p>joe's hardware online has the largest selection of<a herp="./
hammers.html">hammers
<a/>on earth
</body>
</html>

上面的例子是資源http://www.joes-hardware.com/tools.html的HTML文檔，在這個文檔中包含了URL./hammers.html的超連接

雖然看起來不完整，但其實是合法的相對URL，這個URL能夠相對於它所在的文檔中的URL對其進行解釋

使用縮略形式的相對URL語法，寫HTML時就能夠省略URL中的方案、主機和其餘一些組件，這些組件能夠從所屬資源的基礎URL中推導出來，其餘資源的URL也能夠用這種縮略形式來表示

下圖說明了如何從基礎URL中推導出缺失的組件信息

相對URL只是URL的片斷或一小部分，處理URL的應用程序須要在相對和決定URL之間進行轉換

PS：相對URL爲了保持一組資源（HTML頁面）的便捷性提供了一種便捷方式，若是使用相對URL，能夠在搬移一組文檔時，仍保持連接的有效性；

    由於相對URL是相對於新基礎進行解釋的，相似於在其餘服務器提供鏡像內容等功能

 

1.1 基礎URL

基礎URL是做爲相對URL的參考點來使用的，能夠來自如下不一樣的地方：

在資源中顯式提供：有些資源會顯式指定基礎URL

好比：HTML文檔中可能會包含一個定義了基礎URL的HTML標記<BASE>，經過它來轉換HTML文檔中的全部相對URL

封裝資源的基礎URL：若是在一個沒有顯式指定基礎URL的資源中發現一個相對URL，如上面的HTML文檔所示，可將其所屬資源的URL做爲基礎

沒有基礎URL:某些狀況沒有基礎URL，通常意味着你有一個相對URL，但有時可能只是一個不完整或者損壞的URL

 

1.2 解析相對引用

解析：要將相對URL轉換爲一個決定URL，須要將相對URL和決定URL劃分紅組件段，這樣，實際上只是在解析URL，但這種作法會將其劃分爲一個個組件，能夠稱之爲解析/分解URL

將基礎和相對URL劃分紅組件，能夠下用下圖的算法來完成轉換

這個算法將一個相對URL轉換成了其絕對模式，以後，就能夠用其引用資源

 

二、自動擴展URL

不少瀏覽器會在用戶提交URL/輸入URL時嘗試自動擴展URL，這樣爲用戶提供便捷，用戶不須要輸入完整的URL，瀏覽器自動擴展

自動擴展特性有如下2種方式：

2.1 主機名擴展

只要有些小提示，瀏覽器就能夠幫你將輸入的主機名擴展爲完整的主機名，好比：輸入baidu，構建出www.baidu.com；弊端在於有時候會爲其餘http應用程序帶來問題，好比代理，後面詳細解釋

2.2 歷史擴展

將之前用戶訪問過的URL記錄儲存起來，當用戶輸入URL時將其與歷史記錄中的URL前綴進行匹配，並提供一些完整的選項供用戶選擇

PS：與代理一塊兒使用時，URL自動擴展的行爲可能有所不一樣，後面詳細解釋

 

3、URL字符集

URL是可移植的：它命名了互聯網上全部的資源，須要經過各類不一樣協議來傳輸資源，資源在傳輸時採起了不一樣的機制，所以，信息的安全傳輸就很重要

安全傳輸意味着URL傳輸不能丟失信息，但有些協議，好比SMTP（簡單郵件傳輸協議），傳輸方法就是剝去一些特色的字符

URL是可讀的：所以，即便不可見、不可打印的字符能穿過郵件程序，從而成爲可移植的，也不能在URL中使用

URL是完整的：有人但願URL中包含初通用的安全字母表以外的二進制數據或字符，所以須要一種轉義機制，將不安全的字符編碼爲安全字符再傳輸

 

一、URL字符集

1.1 不少計算機應用程序使用的都是ASCII字符集，ASCII使用7位二進制碼來表示大多數按鍵和少數不可控字符，其移植性也很好，但考慮到全球用戶太多，以及有時候URL中會包含任意二進制數據

就須要將轉義序列集成進來，經過轉義序列將ASCII字符集的有限子集對任意字符值或數據進行編碼，這樣就實現了可移植和完整性

1.2 編碼機制

爲了避開安全字符集帶來的限制，人們設計了「轉義」表示法來表示不安全字符，其中包含一個百分號（%），後面跟2個表示字符ASCII碼的十六進制數，下面是幾個例子

1.3 字符限制

URL中，有幾個字符被保留起來，有着特殊含義。有些字符不在定義的ASCII字符集中，還有些字符會和某些協議網關產生混淆，所以不同意使用

 

4、常見協議

下面附錄一個關於經常使用常見的協議列表

 

5、URL將來發展

URL可用來命名全部現存對象，其還提供一種可在各類協議間共享的統一命名機制，但並不完美；由於URL只表示實際地址，而不是準確的名字，意味着若是資源地址有變化，URL就沒法對其進行定位

永久統一資源定位符（PURL），其本質是搜索資源過程當中引入一箇中間層，經過一箇中間資源定位符（resource locator）服務器對資源的實際URL進行登記和追蹤

客戶端能夠向定位符請求一個永久的URL，定位符能夠以一個資源爲響應，將客戶端重定向到資源當前的URL去

 

(十四)TCP/IP協議

下面是協議層從底層至頂層的一個模型圖：

 

1、計算機網絡的背景

1.1 計算機的發展

有人說：「20世紀最偉大的發明就是計算機」，自誕生伊始，計算機經歷了一系列發展，從大型通用計算機、超級計算機、小型機、我的電腦、工做站以及現現在筆記本、平板、智能手機等，

計算機已經完全融入了咱們的生活

 

1.2 計算機的發展模式

起初，計算機只是以單機模式（獨立模式）被普遍應用，隨着發展，計算機被一個個的鏈接起來，造成了一個計算機網路，從而實現了信息共享，遠距離傳遞信息等工做

計算機網絡，根據規模可分爲2種：

WAN：Wide Area Network（廣域網）

LAN：Local Area Nerwork（局域網）

 

2、計算機與網絡發展的七個階段

1.1 批處理

Batch Processing：事先將用戶程序和數據裝入卡帶或磁帶，由計算機按必定順序讀取，使用戶要執行的程序和數據可以一併批量獲得處理的方式

 

1.2 分時系統TSS

Time Sharing System：多個終端和同一個計算機相連，容許多個用戶同時使用一臺計算機系統

特性：多路性、獨佔性、交互性、及時性

 

1.3 計算機間的通訊

計算機之間以通訊線路鏈接，加快了數據讀取時間，極大地縮短了傳輸數據時間，多臺計算機分佈式處理，架構變得更加靈活，操做更加人性化

 

1.4 計算機網絡

窗口系統的產生，方便了用戶操做，用戶不只能夠同時執行多個程序，還能自由切換做業

窗口系統：在計算機上能夠打開多個圖形窗口進行處理的系統。表明性的有經常使用於Unix上的 X Window System、微軟的Windows、蘋果的Mac OS X等

 

1.5 互聯網的出現

異構型計算機鏈接和電子郵件、萬維網等信息傳播方式促使互聯網開始從大到整個公司小到一個家庭內部開始普及互聯網，實現了世界各地用戶經過接入互聯網而即時溝通與交流

 

1.6 互聯網技術爲中心的時代

表明性事件：做爲通訊基礎設施、支撐通訊網絡的電話網，被IP網所替代

 

1.7 「單純創建鏈接」到「安全創建鏈接」

互聯網時代給人帶來了高度便捷的信息網絡環境，但也帶來了負面的問題：計算機病毒、信息泄露、網絡欺詐等，出於我的信息安全以及數據通訊更加安全便捷，安全創建鏈接天然而然的出現了

 

3、協議

1.1 隨處可見的協議

互聯網中經常使用的表明性的協議有IP、TCP、HTTP等，LAN中經常使用協議有IPX、SPX等

「計算機網絡體系結構」將這些網絡協議進行了系統的概括；TCP/IP就是這些協議的集合

其中，還有Novell公司的IPX/SPX、蘋果公司的AppleTalk（僅限蘋果公司計算機使用）、IBM開發的用於構件大規模網絡的SNA以及前DEC公司開發的DECnet等

 

1.2 協議的必要性

簡單來講，協議就是計算機之間經過網絡實現通訊時事先達成的一種「約定」；這種「約定」使那些由不一樣廠商的設備，不一樣CPU及不一樣操做系統組成的計算機之間，只要遵循相同的協議就能夠實現通訊

協議能夠分不少種，每一種協議都明確界定了它的行爲規範：2臺計算機之間必須可以支持相同的協議，而且遵循相同的協議進行處理，才能實現相互通訊

 

1.3 分組交換協議

定義：將大數據分割爲一個個叫作包（Packet）的較小單位進行傳輸的方法（以前的http協議學習隨筆中有講到數據通訊過程）；如圖

計算機通訊會在每個分組中附加上源主機地址和目標主機地址送給通訊線路；這些發送端地址、接收端地址以及分組序號寫入的部分就是「報文首部」

一個較大的數據被分爲不少個分組，爲了標明原始數據的歸屬，有必要將分組序號寫入包中，接收端會根據序號，分組按序從新裝配爲原始數據

協議中，一般會規定報文首部應寫入哪些信息，如何處理；相互通訊的每臺計算機則根據協議構造報文首部，讀取首部等內容，發送和接收方必須對報文首部和主體保持一致的定義和解釋

 

4、協議的標準化

計算機通訊誕生之初，系統化與標準化未收到重視，不一樣廠商只出產各自的網絡來實現通訊，這樣就形成了對用戶使用計算機網絡形成了很大障礙，缺少靈活性和可擴展性

爲解決該問題，ISO（國際標準化組織）制定了一個國際標準OSI（開放式通訊系統互聯參考模型）

TCP/IP並不是ISO指定，是由IETF（國際互聯網工程任務組）建議、致力推動標準化的一種協議，其中，大學等研究機構和計算機行業是推進標準化的核心力量，現已成爲業界標準協議

協議的標準化也推進了計算機網絡的普及

 

5、協議分層和OSI參考模型

1.1 協議的分層

概念：ISO在指定標準的OSI以前，提出了做爲通訊協議設計指標的OSI參考模型，將協議分爲七層，使得原來複雜的網絡協議更加簡單化

定義：在七層模型中，每一個分層都接受由它下一層所提供的特定服務，而且負責爲本身的上一層提供特定的服務，上下層之間進行交互所遵循的約定叫作「接口」，同一層之間的交互所遵循的約定叫作「協議」

協議分層的優勢：

每一個分層能夠獨立使用，其實系統中某些分層發生變化，也不會影響整個系統，所以能夠構造一個擴展性和靈活性都比較強的系統；

此外，經過分層能夠細分通訊功能，更易於單獨實現每一個分層的協議，界定各個分層的具體責任和義務 

協議分層的劣勢：

過度模塊化，處理變得更加沉重，以及每一個模塊都不得不事先類似的處理邏輯等

 

1.2 OSI參考模型

實際上，分組通訊協議很複雜，OSI參考模型將其分爲了易於理解的七個分層，以下圖：

不過，OSI參考模型只是一個模型，對各層只作了粗略的定義，並無對接口和協議作詳細的定義，想深刻了解還須要學習具體的協議規範

 

1.3 OSI參考模型中每一個分層的做用

下圖表述了簡單的每一個分層的做用：

1.3.1 應用層：爲應用程序提供服務並規定應用程序中通訊相關的細節；包括的協議以下：

①：超文本傳輸協議HTTP：這是一種最基本的客戶機/服務器的訪問協議；瀏覽器向服務器發送請求，而服務器迴應相應的網頁

②：文件傳送協議FTP：提供交互式的訪問，基於客戶服務器模式，面向鏈接 使用TCP可靠的運輸服務

   主要功能:減小/消除不一樣操做系統下文件的不兼容性 

③：遠程登陸協議TELNET：客戶服務器模式，能適應許多計算機和操做系統的差別，網絡虛擬終端NVT的意義

④：簡單郵件傳送協議SMTP：Client/Server模式，面向鏈接 

   基本功能：寫信、傳送、報告傳送狀況、顯示信件、接收方處理信件 

⑤：DNS域名解析協議：DNS是一種用以將域名轉換爲IP地址的Internet服務

⑥：簡單文件傳送協議TFTP：客戶服務器模式，使用UDP數據報，只支持文件傳輸，不支持交互，TFTP代碼佔內存小 

⑦：簡單網絡管理協議（SNMP）: SNMP模型的4個組件：被管理結點、管理站、管理信息、管理協議

   SNMP代理：運行SNMP管理進程的被管理結點

   對象：描述設備的變量

   管理信息庫（MIB）：保存全部對象的數據結構

⑧DHCP動態主機配置協議: 發現協議中的引導文件名、空終止符、屬名或者空,DHCP供應協議中的受限目錄路徑名 Options –可選參數字段，參考定義選擇列表中的選擇文件

 

1.3.2 表示層：將應用處理的信息轉換爲適合網絡傳輸的格式，或未來自下一層的數據轉換爲上層可以處理的格式；主要負責數據格式的轉換，確保一個系統的應用層信息可被另外一個系統應用層讀取

具體來講，就是將設備固有的數據格式轉換爲網絡標準傳輸格式，不一樣設備對同一比特流解釋的結果可能會不一樣；所以，主要負責使它們保持一致

 

1.3.3 會話層：負責創建和斷開通訊鏈接（數據流動的邏輯通路），記憶數據的分隔等數據傳輸相關的管理

 

PS：其實在應用層、表示層、會話層這三層，協議能夠共用：

 

1.3.4 傳輸層：只在通訊雙方的節點上（好比計算機終端）進行處理，而無需在路由器上處理，傳輸層是OSI中最重要、最關鍵的一層,是惟一負責整體的數據傳輸和數據控制的一層；

傳輸層提供端到端的交換數據的機制，檢查分組編號與次序，傳輸層對其上三層如會話層等，提供可靠的傳輸服務,對網絡層提供可靠的目的地站點信息主要功能

在這一層，數據的單位稱爲數據段（segment）

主要功能：

①：爲端到端鏈接提供傳輸服務

②：這種傳輸服務分爲可靠和不可靠的,其中Tcp是典型的可靠傳輸,而Udp則是不可靠傳輸

③：爲端到端鏈接提供流量控制,差錯控制,服務質量(Quality of Service,QoS)等管理服務

包括的協議以下：

TCP：傳輸控制協議，傳輸效率低，可靠性強

UDP：用戶數據報協議，適用於傳輸可靠性要求不高，數據量小的數據（好比QQ）

DCCP、SCTP、RTP、RSVP、PPTP等協議

具體的內容可參考這篇文章：http://book.51cto.com/art/200807/81191.htm

 

1.3.5 網絡層：將數據傳輸到目標地址；目標地址能夠使多個網絡經過路由器鏈接而成的某一個地址，主要負責尋找地址和路由選擇，網絡層還能夠實現擁塞控制、網際互連等功能

在這一層，數據的單位稱爲數據包（packet）

網絡層協議的表明包括：IP、IPX、RIP、OSPF等

 

1.3.6 數據鏈路層：負責物理層面上的互聯的、節點間的通訊傳輸（例如一個以太網項鍊的2個節點之間的通訊）；該層的做用包括：物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。

在這一層，數據的單位稱爲幀（frame）

數據鏈路層協議的表明包括：ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼等

 

1.3.7 物理層：負責0、1 比特流（0/1序列）與電壓的高低、逛的閃滅之間的轉換

規定了激活、維持、關閉通訊端點之間的機械特性、電氣特性、功能特性以及過程特性；該層爲上層協議提供了一個傳輸數據的物理媒體。只是說明標準

在這一層，數據的單位稱爲比特（bit）

屬於物理層定義的典型規範表明包括：EIA/TIA RS-23二、EIA/TIA RS-44九、V.3五、RJ-4五、fddi令牌環網等

 

關於七層協議具體的協議以及定義規範，後面隨筆會慢慢介紹，推薦一篇博客，有關七層協議的介紹：http://blog.csdn.net/lisa890608/article/details/8231666

 

6、傳輸方式的分類

網絡通訊科根據數據發送方法進行多種分類，分類方法不少，下面列舉幾種常見的：

1. 面向有鏈接型和麪向無鏈接型

1.1 面向有鏈接型

發送數據以前，須要在收發主機之間創建一條通訊線路，在通訊傳輸先後，專門進行創建和斷開鏈接的處理，若是與對端之間沒法通訊，可避免發送無謂的數據

 

1.2面向無鏈接型

這種類型不要求創建和斷開鏈接，發送端可任什麼時候候發送數據，接收端也不知道本身什麼時候從哪裏接受數據，這種狀況下，接收端須要時常確認是否收到數據，彼此也不須要確認對方是否存在

 

2. 電路交換和分組交換

軟件通訊方式大體分爲2種：電路交換和分組交換，TCP/IP協議組，採用的就是分組交換

2.1 電路交換

電路交換中，交換機主要負責數據的中轉處理；計算機與交換機相鏈接，交換機之間由衆多通訊線路鏈接，計算機發送數據時，須要先鏈接電路，創建鏈接，便可進行通訊，直到鏈接被斷開

 

2.2 分組交換

最初，一臺計算機收發信息時會獨佔整個電路，其餘計算機只能等待，且沒法預測什麼時候結束通訊，爲解決這個問題，將發送的數據分爲多個數據包，按必定的順序排列後發送，這就是分組交換

分組交換中，由分組交互機（路由器）鏈接通訊線路；在每一個分組首部寫入發送端與接收端地址（即同一條線路同時爲多個用戶服務），也能夠確認區分每一個分組的數據目的地，以及它與哪臺計算機通訊

分組交換的大體處理過程：發送端將數據分組分給路由器，路由器收到後緩存到本身的緩衝區，而後再轉發給目標計算機；所以，分組交換也稱爲：蓄積交換

路由器收到收據會按照順序進行緩存至相應隊列，而後以先進先出順序將其逐一發送（有時會優先發送目標地址較特殊的數據）

分組交換的缺陷：分組交換中，通訊線路共享，所以，通訊傳輸速度可能有差別，根據網絡擁堵狀況，數據到達目標地址時間長短不一樣；另外，路由器緩存飽和或溢出時，可能發生數據丟失，沒法發送到接收端的狀況

電路交換和分組交換的特色：

 

3. 根據接收端數據分類

3.1 單播

簡單來講就是一對一通訊，最先的固定電話就是單播通訊的一個典型例子

 

3.2 廣播

將消息從一臺主機發送給與之相連的其餘全部主機；典型例子就是電視播放（將電視信號一齊發送給非特定的多個鏈接對象）

 

3.3 多播

與廣播相似，也是將消息發送給多個相鏈接的接收主機；不一樣之處在於多播要限定某一組主機做爲接收端

 

3.4 任播

在特定的多臺主機中選擇一臺做爲接收端的一種通訊方式（從目標主機羣中選擇一臺最符合的主機做爲目標主機發送消息，通常被選中的主機將返回一個單播信號，隨後發送端只會和這臺主機通訊）

在實際的應用中有DNS根域名解析服務器

 

PS：幾種不一樣方式的思惟邏輯圖：

 

7、地址

通訊傳輸中，發送端和接收端能夠被視爲通訊主體，它們由「地址」加以標識，在計算機通訊中，每一層協議的地址都不一樣

1. 地址的惟一性

通訊地址必須明確的表示一個主體對象，以便確認通訊主體，同一個網絡中不容許有2個相同的通訊主體存在，這就是地址的惟一性

 

2. 地址的層次性

地址總數很少的狀況下，有了惟一地址就能夠定位相互通訊的主體；若是地址總數比較多，那麼想要高效的定位通訊主體，就須要讓地址具備層次性

好比：MAC和IP地址在標識一個通訊主體時都具備惟一性，但只有IP地址具備層次性

MAC地址由製造商製造的網卡，經過識別製造商號，製造商內部產品編號以及產品通用編號來確保MAC地址的惟一性

IP地址由網絡號和主機號2部分組成，即通訊主體IP地址不一樣，若主機號不一樣，網絡號相同，說明其處於同一個網段

網絡通訊中，每一個節點都會根據分組數據的地址信息，參考一個發出接口列表，來判斷報文應該由哪一個網卡發送出去，其中，MAC和IP的區別在於：

MAC：尋址參考的表叫作地址轉發表，其中所記錄的實際上MAC地址自己

IP：尋址參考的表叫作路由控制表，其中所記錄的IP地址是集中了以後的網絡號（網絡號與子網掩碼）

 

8、網絡的構成要素

搭建一套網絡環境須要涉及到不少電纜和網絡設備，下面只介紹下鏈接計算機和計算機的硬件設備：

搭建網絡的主要設備及其做用：

 

1. 通訊媒介與數據鏈路

計算機之間經過電纜相互鏈接，電纜能夠分爲不少種，根據數據鏈路不一樣，選用的電纜類型也不一樣，而媒介自己也可被劃分爲電波、微波等不一樣類型

各類數據鏈路一覽：

傳輸速率：數據傳輸過程當中，兩個設備之間數據流動的物理速度稱爲傳輸速率，單位爲bps（Bits Per Second，每秒比特數），即單位時間內傳輸的數據量多少

              傳輸速率又稱爲帶寬，帶寬越大網絡傳輸能力就越強

吞吐量：主機之間實際的傳輸速率稱爲吞吐量，單位爲bps

           吞吐量不只衡量帶寬，同時還有主機的CPU處理能力、網絡擁堵程度、報文中數據字段的佔有份額（不含報文首部，只計算數據字段自己）等信息

 

2. 網卡

任何計算機鏈接網絡時，必須使用網卡（全稱網絡接口卡，也稱爲網絡適配器、網卡、LAN卡）

 

3. 中繼器

OSI模型中第一層——物理層面上延長網絡的設備；由電纜傳過來的波信號或光信號，經由中繼器波形調整和放大再傳給兩一個電纜

通常狀況下，中繼器兩端鏈接的是相同的通訊媒介（有些中繼器也可完成不一樣通訊媒介之間的轉接工做）

有些中繼器可提供多個端口服務，被稱爲中繼集線器（Hub）或者集線器，每一個端口均可稱爲一箇中繼器

 

4. 網橋/2層交換機

網橋是在OSI模型第二層——數據鏈路層面上鏈接2個網絡的設備；它能夠識別數據鏈路層中的數據幀，並將數據幀臨時存儲於內存，再從新生成一個全新幀轉發給相連的另外一個網段

網橋可以鏈接不一樣傳輸速率的數據鏈路，而且不限制鏈接網段的個數

數據鏈路中有個數據幀叫作FCS，用以校驗數據是否正確送達目的地；網橋經過檢查該域中的值，將損壞的數據丟棄，此外，還能經過地址自學機制和過濾功能控制網絡流量

地址：MAC地址、硬件地址、物理地址及適配器地址，也就是網絡上針對NIC分配的具體地址

自學式網橋：自行判斷是否將數據報文發送給相鄰的網段的網橋（記住曾經過本身轉發的全部數據幀的MAC地址，並存儲到本身的內存表中）

 

以太網等網絡中常用交換集線器（Hub），也屬於網橋的一種；交換集線器中鏈接電纜的端口都能提供相似網橋的功能

 

5. 路由器/3層交換機

路由器：OSI模型第三層——網絡層面上鍊接2個網絡、並對分組報文進行轉發的設備，根據IP地址進行處理；TCP/IP中網絡層地址就成爲了IP地址

           路由器能夠鏈接不一樣的數據鏈路，它還有分擔網絡負荷的做用（某些路由器具有必定的網絡安全功能）

 

 

6. 4~7層交換機

4~7層交換機負責處理OSI模型中從傳輸層至應用層的數據；即以TCP等協議的傳輸層及其上面的應用層爲基礎，分析收發數據，並對其進行特定的處理（例如：負載均衡器）

應用場景：帶寬控制、廣域網加速器、特殊應用訪問、防火牆等

 

7. 網關

網關：OSI模型中負責將從傳輸層到應用層的數據進行轉換和轉發的設備；處理傳輸層及以上的數據

         網關不只轉發數據還對其進行轉換，一般會使用一個表示層或應用層網關，在不能直接通訊的協議間進行翻譯，最終實現通訊

 

代理服務器：

使用萬維網（www）時，爲控制網絡流量和處於安全考慮，使用代理服務器（也是網關的一種，稱爲應用網關）

使用代理服務器，客戶端與服務器之間不須要直接通訊，而是從傳輸層到應用層對數據和訪問進行各類控制處理，防火牆就是一種經過網關通訊，針對不一樣應用提升安全性的產品

代理服務以下圖：

 

各類設備及其對應網絡分層預覽圖：

 

9、現代網絡

1. 網絡的構成

核心網（數據傳輸核心）+邊緣網絡（傳輸節點）+接入層（匯聚層：鏈接邊緣網絡的部分）

 

2. 互聯網通訊

實際的網絡構成圖：

 

3. 移動通訊

移動通訊示意圖：

 

4. 信息發佈以及數據中心

數據中心由大型服務器、存儲以及計算機網絡構成（某些大型數據中心甚至鏈接到「主幹網」）

數據中心結構圖：

 

(十五)TCP/IP協議

1、TCP/IP的標準化

一、TCP/IP的含義

通常來講，TCP/IP是利用IP進行通訊時所必須用到的協議羣的統稱。

具體點，IP或ICMP、TCP或UDP、TELENT或FTP、以及HTTP等都屬於TCP/IP協議，而TCP/IP一詞泛指這些協議，有時稱它們爲TCP/IP爲網際協議族/TCP/IP協議族

以下圖所示：

 

二、標準化的精髓

特性：開放性、注重實用性（被標準化的協議可否被實際運用）

TCP/IP協議由IETF（國際互聯網工程任務組）討論制定；即將協議的大體規範定下來，而後進行通訊試驗，及時修訂

 

三、規範——RFC

RFC：request for comment，即徵求意見表；那些須要標準化的協議，會被計入RFC並在互聯網上公佈；RFC不只包含協議規範內容，還包括協議實現和運用的相關信息，以及實驗方面的信息

RFC經過編號組織每一個協議的標準化請求；其編碼是既定的，一旦成爲某個RFC的內容，就不能再對其進行修改；若要修改已有某個協議內容，則須要從新發行一個新的RFC文檔，同時，老的RFC文檔做廢

新的RFC文檔會明確規定是擴展了哪一個已有RFC以及要做廢哪一個已有RFC

基於每次修改RFC時都會產生新的RFC編號太麻煩，爲此，採用了STD（standard）方式管理編號，其做用是：用來記錄哪一個編號制定哪一個協議

 

四、TCP/IP的標準化流程

TCP/IP的標準化流程大概分爲如下幾個階段：

①.互聯網草案階段：從提出開始不斷進行討論實驗，有了必定成熟度，以爲實際可行，認爲其能夠進行標準化，可進入下一階段

②.提議標準階段：計入RFC，開始進入衆多設備廠商生產環節，投入試驗使用，通常爲6個月，當全部參與協議的人以爲其「實用性強，不存在太多問題」，則進入下一階段

③.草案標準階段：通常爲期4個月，在通過不斷的使用和討論改進後，被大衆所使用接受，那麼這個草案標準就進入下一個階段

④.標準階段：到這個階段，意味着該標準已普遍被使用且具備很強的實用性

 

五、RFC獲取方法

①.網址：http://www.rfc-editor.org/rfc/

        ftp://ftp.rfc-editor.org/in-notes/

這兩個網址保存着全部的RFC文件，網站中有一個名爲rfc-index.txt的文件，包含全部RFC概覽；RFC網站除了發佈RFC相關信息，還提供RFC檢索功能

 

②.STD或FYI以及ID獲取地址

關於STD、FYI、ID也能夠從如下網站獲取，其概覽一分別記錄在std-index.txt、fyi-index.txt等文件中

STD獲取地址：http://www.rfc-edctor.org/in-notes/std/

FYI獲取地址：http://www.rfc-edctor.org/in-notes/fyi/

ID獲取地址：http://www.rfc-edctor.org/Internet-drafts/

JPNIC的ftp服務器中的目錄:

STD獲取網址：ftp://ftp.nic.ad.jp/rfc/std/

FYI獲取網址：ftp://ftp.nic.ad.jp/rfc/fyi/

ID獲取網址：ftp://ftp.nic.ad.jp/internet-drafts/

 

2、互聯網基礎知識

一、互聯網定義

互聯網，英文單詞爲Internet；Internet指的是將多個網絡鏈接使其構成一個更大的網絡，因此Internet本意爲網際網

「互聯網」是指由ARPANET發展而來、互聯全世界的計算機網絡；互聯全世界的計算機網絡，如今「互聯網」對應的英文單詞爲「The Internet」

與Internet對應的另外一種網絡叫作intranet，該網絡指使用Internet技術將企業內部組織機構鏈接起來造成一個企業範圍的內部網絡，提供面向企業內部的通訊服務

 

二、互聯網與TCP/IP關係

互聯網進行通訊時，須要相應的網絡協議，TCP/IP是爲使用互聯網而開發定製的協議族；所以，互聯網的協議就是TCP/IP

 

三、互聯網的結構

小範圍內的網絡鏈接造成機構內部網絡，機構內部網絡鏈接造成區域網絡，各個區域相互鏈接，則造成鏈接全是的互聯網；互聯網是一個有層次的網絡

互聯網中每一個網絡都是由骨幹網（BackBone）和末端網（Stub）組成；每一個網絡之間經過NOC相連；若是運營商不一樣，則網絡鏈接方式和使用方法也不一樣。異構網絡須要有IX支持

互聯網就是衆多異構網絡經過IX互聯的一個巨型網絡

△ NOC:Network Operation Center（網絡操做中心）

△ IX：Internet Exchange：網絡交換中心

 

四、ISP和區域網

鏈接互聯網須要向ISP（internet service provider：互聯網服務提供商）或區域網提出申請，不一樣的ISP提供的互聯網接入服務也不一樣

區域網指的是特定區域內由團體或志願者提供的網絡服務，一般價格比較便宜，但有時會出現鏈接方式複雜或者使用有限制的狀況

當申請網絡服務時，建議確認瞭解一下提供的具體服務條目、服務的細則（接入方式、條件、費用）等，再決定

 

3、TCP/IP協議分層模型

一、TCP/IP與OSI參考模型

TCP/IP與OSI在分層模塊上的區別：

OSI：注重通訊協議必要的功能是什麼

TCP/IP：在計算機上實現協議應該開發哪一種程序

 

二、硬件（物理層）

TCP/IP的最底層是負責數據傳輸的硬件。這種硬件就至關於以太網或電話線路等物理層的設備，TCP/IP是在網絡互連的設備之間可以通訊的前提下才被提出的協議。

 

三、網絡接口層（數據鏈路層）

利用以太網中的數據鏈路進行通訊，屬於接口層；將其當作「驅動程序」也能夠（驅動程序是在操做系統與硬件以前起橋樑做用的軟件）

PS：有時也將硬件層和網絡接口層合併起來，稱爲「網絡通訊層」

 

四、互聯網層（網絡層）

互聯網層使用IP協議，至關於OSI中的第三層模型；IP協議基於IP地址轉發分包數據

IP協議的做用：將分組數據包發送到目的主機

TCP/IP分層中的互聯網層與傳輸層的功能一般由操做系統提供，尤爲是路由器，它必須得實現經過互聯網層轉發分組數據包的功能

鏈接互聯網的全部主機跟路由器必須都實現IP功能，其餘連接互聯網的網絡設備（網橋、中繼器）則不是必須

IP：跨越網絡傳送數據包，使整個互聯網都能收到數據的協議；傳送數據時，IP地址做爲主機的標識

      IP還隱含數據鏈路層的功能：經過IP，相互通訊的主機之間不論通過怎樣的數據鏈路，均可以實現通訊

      IP是分組交換的一種協議，可是不具備重發機制；即便分組數據包未到達對端主機也不會重發；屬於非可靠性傳輸協議

ICMP:IP數據包發送過程當中一旦發生異常致使沒法到達對端目標地址時，須要給發送端一個發生異常的通知，ICMP就是爲了該功能而定製；有時可用來診斷網絡健康情況

ARP：從分組數據包的IP地址解析出物理地址（MAC地址）的一種協議

 

五、傳輸層

TCP/IP傳輸層有TCP和UDP兩個具備表明性的協議，主要功能是讓應用程序之間實現通訊；其通訊邏輯以下圖：

 

TCP：面向有鏈接的傳輸層協議，能夠保證通訊兩端主機之間的通訊可達；能夠正確的處理傳輸過程當中丟包、傳輸亂序等異常狀況；還能有效利用帶寬，緩解網絡擁堵。

UDP：面向無鏈接的傳輸層協議，不關注對端是否真的收到傳送的數據；如需檢查對端是否收到分組數據包，或對端是否鏈接到網絡，須要在應用程序中實現經常使用於分組數據較少或多播。廣播通訊及視頻通訊等領域。

 

六、應用層（會話層以上的分層）

TCP/IP分層中，將OSI中的會話層、表示層、應用層都集中到了應用程序中實現

 

TCP/IP應用的架構絕大多數術語客戶端/服務端模型；提供服務的程序叫服務端，接受服務的程序叫客戶端，服務器會預先部署到主機上，等待接收任什麼時候刻客戶端發送的請求

常見的應用層協議：

HTTP協議：（HyperText Transfer Protocol）

瀏覽器與客戶端通訊所使用的協議，傳輸數據主要格式爲HTML，http協議OSI應用層協議，而HTML屬於表示層的協議

文件傳輸協議：FTP（File Transfer Protocol）

傳輸過程能夠選擇用二進制仍是文本方式，傳輸時會創建兩個TCP鏈接：發送傳輸請求時用到的控制鏈接和實際傳輸時用到的數據鏈接

電子郵件協議：SMTP（Simple Mail Transfer Protocol）

能夠發送聲音圖像文字，甚至改變文字大小、顏色等

遠程登陸（TELNET與SSH）：

常見的還有其餘遠程登陸協議，好比：BSD UNIX系中的rlogin的r命令和X Window System中的X協議

網絡管理協議：SNMP（Simple Newwork Management Protocol）

在TCP/IP進行網絡管理時，採用該協議，其中使用SNMP管理的主機。網橋、路由器等稱做SNMP代理（Agent），進行管理的那一段叫作管理器（Manager）

在SNMP代理端，保存着網絡接口信息、通訊數據量、異常數據量以及設備溫度等信息，這些信息經過MIB訪問，在TCP/IP中，SNMP屬於應用協議，MIB屬於表示層協議

MIB（Management Information Base）:可透過網絡的結構變量

 

4、TCP/IP分層模型

一、數據包首部

每一個分層都會對所發送的數據附加一個首部，首部中包含該層必要的信息；一般爲協議提供的信息爲包首部，所要發送的內容爲數據

關於包、幀、數據報、段、消息的概述：

包：一個歸納性術語，指數據總體

幀：數據鏈路層中包的單位

數據報：IP和UDP等網絡層以上分層中包的單位

段：TCP數據流中的信息

消息：應用協議中數據的單位

 

二、發送數據包

假設A發送郵件「早上好」給B，那麼它的通訊過程大概以下：

①.應用程序處理

應用程序啓動，新建郵件及內容，點擊發送，應用程序對郵件進行編碼處理，而後發送給下一層TCP

②.TCP模塊的處理

根據上層應用發來的指示，創建負責創建鏈接、發送鏈接及斷開鏈接；TCP提供將應用層發來的數據順利發送至對端的可靠傳輸

爲了實現該功能，會在應用層數據前端加一個TCP首部，首部包括源端口號和目標端口號。序號以及校驗，隨後將附加了TCP首部的包發送給IP

③.IP模塊的處理

IP將TCP傳遞的首部和數據合併，並在首部以前加上本身的IP，IP包生成後，參考路由控制表決定接受此IP包的路由或者主機，隨後，IP包將被髮送給鏈接這些路由或主機網絡接口的驅動程序，實現發送數據

④.網絡接口（以太網驅動）的處理

以太網接受到的IP包，對其來講就是數據，會給其加上以太網首部並進行發送處理，首部中包含接收端MAC地址，發送端MAC地址以及標誌以太網類型的以太網數據協議

 

三、數據包接收處理

①.網絡接口（以太網驅動）的處理

主機收到以太網包，首先找到MAC地址判斷是否爲發送給本身的，若是不是則丟棄數據

若是是，則確認數據類型，而後將數據包發送給對應的類型處理程序處理

②.IP模塊的處理

收到數據包先進行判斷處理，若是包首部IP地址與本身匹配則接受數據並尋找到上一層協議，並轉發給上一層進行處理

③.TCP模塊的處理

接收到數據包首先計算校驗和，判斷數據包是否被破壞，而後檢查是否按序接受數據，最後檢查端口號，肯定具體應用程序

數據接受完畢，接收端發送一個「確認回執」個發送端

④.應用程序的處理

接收端應用程序會直接接收發送端的數據，並進行解析處理

 

轉載：https://www.cnblogs.com/imyalost