web基礎--Http基礎

Http基礎

    Http基礎網絡及Web網絡模型分層Protocol網絡基礎TCP/IP協議族各協議與HTTP協議的關係IP協議--負責傳輸TCP--可靠性服務DNS--域名解析服務URI和URLHTTP協議用於客服端和服務器之間的通信GET ：獲取資源POST：傳輸實體主體PUT：傳輸文件HEAD：得到報文首部DELETE：刪除文件GET與POST的區別Cookie--確認過眼神Http是一種無狀態的協議

網絡及Web

   ​ 在現在咱們訪問網頁都是經過網頁瀏覽器（web browser）。但你知道如何定位你要訪問的網頁，web頁面又是如何呈現的嗎？一個簡單的web網頁又是如何知足千千萬萬不一樣用戶的需求的？

​ 

 

​ 計算機與網絡設備要相互通訊，雙方就必須基於相同的方法。

​ 好比，如何探測到通訊目標、由哪一邊先發起通訊、使用哪一種語言進行通訊、怎樣結束通訊，怎樣選擇通訊線路，訪問失效怎麼處理，等規則都須要事先肯定。

不一樣的硬件、操做系統之間的通訊，全部的這一切都須要一種規則。而這種規則就是咱們常說的協議（Protocol），或者說接口（interface）

​

​

網絡模型分層

（7） 應用層：直接爲用戶的應用進程服務，協議有萬維網應用協議HTTP、電子郵件協議SMTP、文件傳輸協議FTP等

（6） 表示層：負責兩個通訊系統之間所交換信息的表示方式，使得兩臺數據表示結構徹底不一樣的設備可以自由地通訊

（5） 會話層：爲彼此合做的表示層實體創建、維護和結束他們之間的通訊會話（Session），提提供會話管理，但不參與具體的傳輸。

（4） 傳輸層：爲會話層實體提供透明、可靠的數據傳輸服務，保證端到端的數據完整性，實現端到端的應答、分組排序和流量控制等功能。

​ 信息的傳送單位是報文。

（3） 網絡層：爲傳輸層實體提供端到端的數據傳送功能，使得傳輸層擺脫路由選擇，把上層產生的報文或用戶數據包封裝成分組或包進行傳送，也叫IP數據報。其次要選擇適合的路由，使分組可以經過網絡中的路由器找到目的主機。

（2） 數據鏈路層：負責兩個相鄰節點間的線路上的數據傳輸，創建、維持和釋放兩個相鄰節點間的數據鏈路，將網絡層交下來的IP數據報組裝成幀（framing），

（1） 物理層：爲它的上一層提供一個物理鏈接，傳輸單位爲比特。

 

 

 

 

Protocol

​ 咱們前面講到了協議（Protocol）：協議的本質是一種規則，是在通訊中交換信息的雙方所要遵循的一套規則或則說約束。

（PS：請小夥伴們自行回憶一下接口的定義，並類比一下。）

​ 協議中存在各式各樣的內容。從電纜的規格到 IP 地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序，以及 Web 頁面顯示須要處理的步驟，等等。 像這樣把與互聯網相關聯的協議集合起來總稱爲 TCP/IP。

 

網絡基礎TCP/IP協議族

​ TCP/IP 協議族裏重要的一點就是分層。 把 TCP/IP 層次化是有好處的。好比，若是互聯網只由一個協議統籌，某個地方須要改變設計時，就必須把全部部分總體替換掉。而分層以後只需把變更的層替換掉便可。把各層之間的接口部分規劃好以後，每一個層次內部的設計就可以自由改動了。 值得一提的是，層次化以後，設計也變得相對簡單了。處於應用層上的應用能夠只考慮分派給本身的任務，而不須要弄清對方在地球上哪一個地方、對方的傳輸路線是怎樣的、是否能確保傳輸送達等問題。

題外話：

​ 人類的學習中有一種方式叫作類比學習，分層的機率不只僅是在通信中有着應用，分層（或者咱們換種不太恰當的說法叫分治：將大的問題分解爲明確的小的問題來解決）在計算機領域中是很是有用的一種思想，例如軟件開發，算法研究，數據結構等等不少領域都有應用。

 

各協議與HTTP協議的關係

​ 對在 TCP/IP 協議族中與 HTTP 密不可分的 3 個協議（IP、TCP 和 DNS）

IP協議--負責傳輸

​ IP（Internet Protocol）：網際協議位於網絡層。InternetProtocol 這個名稱可能聽起來有點誇張，但事實正是如此，由於幾乎全部使用網絡的系統都會用到 IP 協議。

​ IP 協議的做用是把各類數據包傳送給對方。而要保證確實傳送到對方那裏，則須要知足各種條件。其中兩個重要的條件是 IP 地址和 MAC地址（Media Access Control Address，也就是你的網卡地址）。

根據通訊方的 IP 地址就能夠反查出對應的 MAC 地址。

​ 沒有人可以全面掌握互聯網中的傳輸情況在到達通訊目標前的中轉過程當中，那些計算機和路由器等網絡設備只能獲悉很粗略的傳輸路線。這種機制稱爲路由選擇（routing）

TCP--可靠性服務

​ TCP 位於傳輸層，提供可靠的字節流服務。

​ 字節流服務（Byte Stream Service）：爲了方便傳輸，將大塊數據分割成以報文段（segment）爲單位的數據包進行管理。

​ 而可靠的傳輸服務是指，可以把數據準確可靠地傳給對方。爲了準確無誤地將數據送達目標處，TCP 協議採用了三次握手（three-way handshaking）策略。用 TCP 協議把數據包送出去後，TCP不會對傳送後的狀況置之不理，它必定會向對方確認是否成功送達。

握手過程當中使用了 TCP 的標誌（flag） —— SYN（synchronize） 和ACK（acknowledgement）。發送端首先發送一個帶 SYN 標誌的數據包給對方。接收端收到後，回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶 ACK 標誌的數據包，表明「握手」結束。若在握手過程當中某個階段莫名中斷，TCP 協議會再次以相同的順序發送相同的數據包。

 

DNS--域名解析服務

​ DNS（Domain Name System）服務是和 HTTP 協議同樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。計算機既能夠被賦予 IP 地址，也能夠被賦予主機名和域名。由於與 IP 地址的一組純數字相比，用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。

 

URI和URL

​ URL（Uniform Resource Locator，統一資源定位符）。URL正是使用 Web 瀏覽器等訪問 Web 頁面時須要輸入的網頁地址。

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

一個完整的URL包括如下幾部分：

• 協議部分：該URL的協議部分爲「http：」，這表明網頁使用的是HTTP協議。在Internet中可使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的「//」爲分隔符

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

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

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

• 文件名部分：從域名後的最後一個「/」開始到「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。本例中的文件名是「index.asp」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名

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

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

HTTP協議用於客服端和服務器之間的通信

​ 兩臺計算機做爲客戶端和服務器端的角色有可能會互換。但就僅從一條通訊路線來講，服務器端和客戶端的角色是肯定的，而用 HTTP 協議可以明確區分哪端是客戶端，哪端是服務器端。

​ HTTP 協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。

• 2XX 成功 61

• 3XX 重定向 62

• 4XX 客戶端錯誤 65

• 5XX 服務器錯誤

GET ：獲取資源

​ GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，若是請求的資源是文本，那就保持原樣返回；若是是像 CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。

POST：傳輸實體主體

​ POST 方法用來傳輸實體的主體。雖然用 GET 方法也能夠傳輸實體的主體，但通常不用 GET 方法進行傳輸，而是用 POST 方法。雖然說 POST 的功能與 GET 很類似，但POST 的主要目的並非獲取響應的主體內容。使用 POST 方法的請求·響應的例子

PUT：傳輸文件

​ PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求 URI 指定的位置。

​ 

​ 可是，鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件 , 存在安全性問題，所以通常的 Web 網站不使用該方法。若配合 Web 應用程序的驗證機制，或架構設計採用REST（REpresentational State Transfer，表徵狀態轉移）標準的同類Web 網站，就可能會開放使用 PUT 方法。

HEAD：得到報文首部

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

DELETE：刪除文件

​ DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。

​ 可是，HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法。當配合 Web 應用程序的驗證機制，或遵照 REST 標準時仍是有可能會開放使用的。

GET與POST的區別

​ 對於程序員來講，GET 和POST 基本能夠解決大部分的請求，但根據Http協議的初衷其中每一個請求方法對應着不一樣的請求方式， 對於歸納的增刪改查來說 大體對應以下。

GET 對應查 POST 對應增 PUT 對應改 DELETE 對應刪

​ 雖然GET和POST 能夠實現基本請求，但爲了規範咱們能夠試着使用其餘的，對於不少地方，可能只支持GET 和 POST 咱們要視狀況而定

 

使用GET方法時，查詢字符串（鍵值對）被附加在URL地址後面一塊兒發送到服務器：

/test/demo_form.jsp?name1=value1&name2=value2

特色：

• GET請求可以被緩存

• GET請求會保存在瀏覽器的瀏覽記錄中

• 以GET請求的URL可以保存爲瀏覽器書籤

• GET請求有長度限制

• GET請求主要用以獲取數據

使用POST方法時，查詢字符串在POST信息中單獨存在，和HTTP請求一塊兒發送到服務器：

POST /test/demo_form.jsp HTTP/1.1

Host: w3schools.com

name1=value1&name2=value2

特色：

• POST請求不能被緩存下來

• POST請求不會保存在瀏覽器瀏覽記錄中

• 以POST請求的URL沒法保存爲瀏覽器書籤

• POST請求沒有長度限制

• 區別一（使用場景）：

  get重點在從服務器上獲取資源，post重點在向服務器發送數據；

• 區別二（請求數據位置）：

  get傳輸數據是經過URL請求，以field（字段）= value的形式，置於URL後，並用"?"鏈接，多個請求數據間用"&"鏈接

  如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；

  post傳輸數據經過Http的post機制，將字段與對應值封存在請求實體中發送給服務器，這個過程對用戶是不可見的；

• 區別三（請求數據大小）：

  Get傳輸的數據量小，由於受URL長度限制，但效率較高；Post能夠傳輸大量數據，因此上傳文件時只能用Post方式；

• 區別四（安全性）：

  get是不安全的，由於URL是可見的，可能會泄露私密信息，如密碼等；post較get安全性較高；

• 區別五（編碼集合）：

  get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼。post支持標準字符集，能夠正確傳遞中文字符。

• 區別六（共享性）：

  get請求的請求數據在url中，便於分享鏈接，能夠添加到書籤，而post請求不能夠。。

• 區別七（緩存）：

  get請求能被緩存，而post請求不行。

• 區別八（表單重複提交）：

  點擊返回/刷新按鈕，對get請求沒有影響，對於post請求可能會致使數據重發（瀏覽器會提示）。

Cookie--確認過眼神

​ Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。

Http是一種無狀態的協議

​ HTTP 是無狀態協議，它不對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理（不記錄已登陸的狀態），那麼每次跳轉新頁面不是要再次登陸，就是要在每次請求報文中附加參數來管理登陸狀態。不能否認，無狀態協議固然也有它的優勢。因爲沒必要保存狀態，天然可減小服務器的 CPU 及內存資源的消耗。

​ 保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了 Cookie 技術。 Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。 服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。