關於網絡協議

網絡

網絡是信息傳輸，接收，共享的虛擬平臺
經過它把各個點，面，體的信息聯繫到一塊兒，從而實現這些資源的共享
網絡傳輸數據有必定的規則，這些規則咱們稱爲協議
HTTP協議就是其中的一種，並且使用最爲頻繁

計算機網絡的七層協議

應用層
表示層
會話層
傳輸層
網絡層
數據鏈路層
物理層

DNS解析

域名解析（主機名解析）：經過主機名，最終獲得該主機名對應的IP地址的過程
每一臺計算機都有一個惟一的IP地址，計算機根據IP實現相互通訊
而咱們一般使用的域名更多的是爲了方便記憶以及個性化須要，它並不能直接對應到的服務器IP，咱們須要通過DNS服務器去查找IP，這個根據域名找到IP地址的過程就是DNS解析

HTTP簡介

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫
是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議
HTTP是基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）
HTTP採用的是 請求/應答 方式來傳遞數據
HTTP協議的默認端口號爲80
HTTPS協議的默認端口號爲443
HTTP是應用層協議，主要解決如何包裝數據

HTTP協議的約束

約束了瀏覽器以何種格式向服務端發送數據
約束了服務器應該以何種格式來接受客戶端發送的數據
約束了服務器應該以何種格式來反饋數據給瀏覽器
約束了瀏覽器應該以何種格式來接收服務器反饋的數據

HTTP交互特色

瀏覽器給服務器發送數據（一次請求）
服務器給瀏覽器反饋數據（一次響應）
一次請求對應一次響應，屢次請求對應屢次響應

HTTP工做原理

HTTP協議工做於客戶端-服務端架構上。
瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求
Web服務器根據接收到的請求後，向客戶端發送響應信息

網絡請求與響應服務的過程

HTTP通訊機制

HTTP通訊機制是在一次完整的HTTP通訊過程當中，Web瀏覽器與Web服務器之間將完成下列7個步驟：
1. 創建TCP鏈接
   在HTTP工做開始以前，Web瀏覽器首先要經過網絡與Web服務器創建TCP鏈接，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，所以Internet又被稱做TCP/IP網絡。
   HTTP是比TCP更高層次的應用層協議，根據規則，低層協議創建以後才能進行更層協議的鏈接，所以，首先要創建TCP鏈接
   通常TCP鏈接的端口號是80
2. Web瀏覽器向Web服務器發送請求命令
   一旦創建了TCP鏈接，Web瀏覽器就會向Web服務器發送請求命令
   例如：GET/sample/hello.jsp HTTP/1.1
3. Web瀏覽器發送請求頭信息
   瀏覽器發送其請求命令以後，還要以頭信息的形式向Web服務器發送一些別的信息，以後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。
4. Web服務器應答
   客戶機向服務器發出請求後，服務器會向客戶機回送應答，HTTP/1.1 200 OK
   應答的第一部分是協議的版本號和應答狀態碼
5. Web服務器發送應答頭信息
   服務器隨同應答向用戶發送關於它本身的數據及被請求的文檔。
6. Web服務器向瀏覽器發送數據
   以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據
7. Web服務器關閉TCP鏈接
   通常狀況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP鏈接，而後若是瀏覽器或者服務器在其頭信息加入了這行代碼Connection:keep-alive
   TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。
   保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

HTTP三個特色

1. HTTP是無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間
2. HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據均可以經過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型（該資源的媒體類型）
3. HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快

HTTP消息結構

一個HTTP"客戶端"是一個應用程序（Web瀏覽器或其餘任何客戶端），經過鏈接到服務器達到向服務器發送一個或多個HTTP的請求的目的
一個HTTP"服務器"一樣也是一個應用程序（一般是一個Web服務，如Apache Web服務器或IIS服務器等），經過接收客戶端的請求並向客戶端發送HTTP響應數據
HTTP使用統一資源標識符（URI）來傳輸數據和創建鏈接

客戶端請求消息：
客戶端發送一個HTTP請求到服務器的請求消息包括如下四個部分：
請求行（request line）
請求頭部（header）
空行
請求數據

服務器響應消息:
HTTP響應也由四個部分組成：
狀態行
消息報頭
空行
響應正文

HTTP的九種請求類型

HTTP1.0 定義了三種請求方法：GET, POST 和 HEAD方法
HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法

經常使用：
1. GET：向特定的資源發出請求。（從服務器中獲取一份文檔）
2. POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的建立和/或已有資源的修改。（向服務器發送須要處理的數據）
3. PUT：向指定資源位置上傳其最新內容。（將請求的主題部分存儲在服務器中）
4. PATCH：是對 PUT 方法的補充，用來對已知資源進行局部更新。
5. DELETE：請求服務器刪除 Request-URI 所標識的資源。（從服務器中刪除一份文檔）
6. CONNECT：HTTP/1.1 協議中預留給可以將鏈接改成管道方式的代理服務器。

不經常使用：
1. OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法。也能夠利用向Web服務器發送'*'的請求來測試服務器的功能性。（決定能夠在服務器上執行的方法）
2. HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息。（只從服務器獲取頭文檔的首部）
3. TRACE：回顯服務器收到的請求，主要用於測試或診斷。（對可能通過代理服務器傳送到服務器上的報文進行追蹤）

其實在實際應用中經常使用的是get和post
其餘請求方式也均可以經過這兩種方式間接的來實現

關於get請求的注意事項：
get請求可被緩存
get請求保留在瀏覽器歷史記錄中
get請求可被收藏爲書籤
get請求不該在處理敏感數據時使用
get請求有長度限制
get請求只應當用於取回數據

關於post請求的注意事項：
post請求不會被緩存
post請求不會保留在瀏覽器歷史記錄中
post請求不可被收藏爲書籤
post請求對數據長度沒有要求

比較get請求和post請求：

HTTP響應頭的信息

HTTP狀態碼

常見的狀態碼：
200 - 請求成功（通常用於get和post方法）（描述：OK）
301 - 資源（網頁等）被永久轉移到其它URL，瀏覽器自動跳轉到新的URL（描述：Moved Permanently）
304 - 所請求資源未修改，瀏覽器讀取緩存信息（描述：Not Modified）
400 - 請求語法錯誤，服務器沒法解析（描述：Bad Request）
404 - 請求的資源（網頁等）不存在，未找到資源（描述：Not Found）
500 - 內部服務器錯誤（描述：Internal Server Error）


HTTP狀態碼分類：

HTTP狀態碼列表：

關於HTTP的Content-type

Content-Type用於定義網絡文件的類型和網頁的編碼。決定瀏覽器將以什麼形式、什麼編碼讀取這個文件
Content-Type標頭告訴客戶端實際返回的內容的內容類型

語法格式：

一些媒體格式類型：

HTTP---Cookie

HTTP Cookie（也叫Web cookie或者瀏覽器Cookie）是服務器發送到用戶瀏覽器並保存在瀏覽器上的一塊數據，它會在瀏覽器下一次發起請求時被攜帶併發送到服務器上。
比較經典的，能夠用它來肯定兩次請求是否來自於同一個瀏覽器，從而可以確認和保持用戶的登陸狀態。
Cookie的使用使得基於無狀態的HTTP協議上記錄穩定的狀態信息成爲了可能。

cookie的屬性：
1. key-value：cookie經過key-value的方式存儲屬性名和值。
2. domain：規定了須要發送Cookie的主機名。若是沒有指定，默認爲當前的文檔地址上的主機名（可是不包含子域名）。若是指定了Domain，則通常包含子域名。
3. path:Path指令代表須要發送Cookie的URL路徑。字符%x2F (即"/")用作文件夾分隔符，子文件夾也會被匹配到。
4. hostOnly：布爾型的值，true表示cookie只能匹配domain中指定好的請求路徑。反之則不。
5. httpOnly：HTTP-only類型的Cookie不能使用Javascript經過Document.cookie屬性來訪問，從而可以在必定程度上阻止跨域腳本攻擊（XSS）。
6. secure：布爾型的值，true表示cookie只在安全的狀況下有效。通常是在https狀況下。即在使用SLL和HTTPS協議向服務器發起請求時，才能確保Cookie被安全地發送到服務器。
7. expirationDate：指明cookie的過時的時間。
8. Max-Age：指明cookie的有效期。
9. session：布爾值，true表示cookie是session cookie。false的話表示持續的cookie且不過時。
10. storeId：表明存放cookie的id的字符串。

關於HTTPS協議

HTTPS是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。
https協議須要到ca申請證書，通常免費證書不多，須要交費。http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議http和https使用的是徹底不一樣的鏈接方式用的端口也不同,http是80,https是443。
客戶端產生一個對稱的密鑰,經過server的證書來交換密鑰。通常意義上的握手過程，加下來全部的信息往來就都是加密的。第三方即便截獲，也沒有任何意義，由於他沒有密鑰
HTTPS協議是在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密，安全性會更高。

關於HTTP2.0

HTTP 2.0是1999年HTTP/1.1發佈後的下一代HTTP協議，在開放互聯網上HTTP 2.0將只用於https://網址，而http://網址將繼續使用HTTP/1

相比 HTTP/1.x，HTTP 2.0有不少新特性：
1. 二進制分幀層：HTTP 2.0增長了一個二進制分幀層，改進了傳輸性能，實現了低延遲和高吞吐量。
2. 壓縮頭部：對請求頭進行了壓縮，相同的請求不會在頭部帶上未改變的屬性。
3. 多路複用：能夠鏈接發起多重的請求，HTTP1中的keep-alive用於長鏈接而沒必要從新創建鏈接，然而keep-alive必須等本次請求完全完成後才能發送下一個請求，而HTTP2的請求與響應以二進制幀的形式交錯進行，大大提升了效率。
4. 請求優先：能夠對資源的下載順序進行排序。
5. 服務端推送：能夠將資源主動推送給客戶端。

關於TCP/IP協議

TPC/IP協議是傳輸層協議，主要解決數據如何在網絡中傳輸
TCP/IP 是用於因特網(Internet)的通訊協議

在 TCP/IP 中包含一系列用於處理數據通訊的協議：
1. TCP (傳輸控制協議) - 應用程序之間通訊
2. UDP (用戶數據報協議) - 應用程序之間的簡單通訊
3. IP (網際協議) - 計算機之間的通訊
4. ICMP (因特網消息控制協議) - 針對錯誤和狀態
5. DHCP (動態主機配置協議) - 針對動態尋址

TCP 使用固定的鏈接：
TCP 用於應用程序之間的通訊。
當應用程序但願經過 TCP 與另外一個應用程序通訊時，它會發送一個通訊請求
這個請求必須被送到一個確切的地址。在雙方"握手"以後，TCP 將在兩個應用程序之間創建一個全雙工的通訊
這個全雙工的通訊將佔用兩個計算機之間的通訊線路，直到它被一方或雙方關閉爲止
UDP 和 TCP 很類似，可是UDP更簡單，同時可靠性低於 TCP

IP 是無鏈接的：
IP 用於計算機之間的通訊
IP 是無鏈接的通訊協議。它不會佔用兩個正在通訊的計算機之間的通訊線路。這樣，IP 就下降了對網絡線路的需求。每條線能夠同時知足許多不一樣的計算機之間的通訊須要
經過 IP，消息（或者其餘數據）被分割爲小的獨立的包，並經過因特網在計算機之間傳送
IP 負責將每一個包路由至它的目的地
當一個 IP 包從一臺計算機被髮送，它會到達一個 IP 路由器
IP 路由器負責將這個包路由至它的目的地，直接地或者經過其餘的路由器
在一個相同的通訊中，一個包所經由的路徑可能會和其餘的包不一樣。而路由器負責根據通訊量、網絡中的錯誤或者其餘參數來進行正確地尋址

TCP/IP 意味着 TCP 和 IP 在一塊兒協同工做
TCP 負責應用軟件（好比您的瀏覽器）和網絡軟件之間的通訊
IP 負責計算機之間的通訊
TCP 負責將數據分割並裝入 IP 包，而後在它們到達的時候從新組合它們
IP 負責將包發送至接受者

TCP/IP尋址

TCP/IP 使用32個比特（4字節）或者4組0到255之間的數字來爲計算機編址

IP 地址包含4組數字：
TCP/IP 使用4組數字來爲計算機編址。每一個計算機必須有一個惟一的 4 組數字的地址
每組數字必須在0到255之間，並由點號隔開，好比：192.168.1.60

IP V6

稱做：下一代互聯網協議
由IETF小組設計的用來替代現行的IPv4協議的一種新的IP協議
IP地址用一個32位二進制的數表示一個主機號碼，但32位地址資源有限，已經不能知足用戶的需求了，所以Internet研究組織發佈新的主機標識方法，即IPv6
在RFC1884中，規定的標準語法建議把 IPv6 地址的 128 位（16 個字節）寫成 8 個 16 位的無符號整數，每一個整數用 4 個十六進制位表示，這些數之間用冒號（:）分開
例如：686E：8C64：FFFF：FFFF：0：1180：96A：FFFF
冒號十六進制記法容許零壓縮，即一串連續的0能夠用一對冒號取代
爲了保證零壓縮有一個清晰的解釋，建議中規定，在任一地址中，只能使用一次零壓縮

TCP/IP包括的協議

TCP/IP是基於TCP和IP這兩個最初的協議之上的不一樣的通訊協議的大集合
包括如下協議：

TCP/IP---郵件

電子郵件程序使用不一樣的TCP/IP協議：
使用SMTP來發送郵件
使用POP從郵件服務器下載郵件
使用IMAP鏈接到郵件服務器

TCP/IP和其餘的協議在最初OSI模型中的位置