簡述HTTP

簡述HTTP(該文章並不完整，會持續更新)

內容來着HTTP 圖解

本文主要內容：

• 瞭解web及網絡基礎
• 簡單的http協議

瞭解web及網絡基礎

一、使用http協議訪問web

當咱們用網頁瀏覽器（web browser）的地址欄中輸入URL時，Web頁面的呈現過程：

• 輸入URL時，能夠看到web頁面，即便不瞭解運做原理，也能看到頁面
• 輸入URL後，信息會被送往某處

而後從某處得到的回覆，內容就會顯示在web頁面上

web頁面不可能憑空顯示出來，根據web瀏覽器地址欄中指定的URL，web瀏覽器會從服務器端獲取文件資源等信息，從而顯示web頁面。

像這一套流程就能夠稱做是客戶端（client）向服務端（server）獲取服務器資源

web使用一種名爲HTTP（HyperText Transfer Protocol），超文本傳輸協議做爲規範，完成從客戶端到服務端等一系列運做過程。而協議是指規則的約定。能夠理解成，web是創建在HTTP協議上通訊的。

二、網絡基礎TCP/IP

爲了瞭解HTTP，必須的瞭解TCP/IP協議族。

一般使用的網絡實在TCP/IP協議族的基礎上運做的。而HTTP就屬於他的一個子集。

2.一、TCP/IP 協議族

計算機與網絡設備要相互通訊，雙方就必須基於相同的方法。好比：如何探測到通訊目標、由哪一方先發起通訊、使用哪一種語言等等好多規則。然而這種規則就是所謂的協議（protocol），你要用我就按照我協議的規則來。經常使用協議有：tcp，http，ftp，dhcp，dns，ip，pppoe，udp，snmp，icmp等等。

像這樣把與互聯網關聯的協議集合起來總稱TCP/IP，TCP/IP實在IP協議通訊過程當中，使用到的協議族的統稱

2.二、TCP/ip的分層管理

TCP/IP協議族重要的一點就是分層。TCP/IP協議族按層次劃分分別是：應用層、傳輸層、網絡層和數據鏈路層。把塔層次化是有好處的。好比：當某個地方需求變動時，就必須吧全部的總體替換掉。而分層以後只須要把變更的層替換掉便可。下面介紹一下每一個層次的做用

應用層

應用層決定了向用戶提供應用服務時通訊的活動。好比：ftp，dns服務就是其中的兩類。HTTP協議也處於該層。

傳輸層

傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。在傳輸層有兩個性質不一樣的協議：TCP和UDP。

網絡層

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

鏈路層

用來處理連接網絡的硬件部分。包括操做系統、硬件的設備驅動、網卡及光纖等物理可見部分

2.三、TCP/IP通訊傳輸流

好比說我想看百度網頁：流程以下：

• 客戶端在應用層發出一個想看某個WEB頁面的HTTP請求的時候；
• 接着爲了傳輸方便，在傳輸層把應用層收到的數據進行分割，並在各個報文上打上標記序號及端口- - 號後轉發給網絡層；
• 在網絡層增長做爲通訊目的的MAC地址後轉發給鏈路層，這樣一來發送網絡的通訊請求就準備齊全了；
• 接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層；
• 當傳輸到應用層，才能算真正接收到由客戶端發送過來的HTTP請求了。

發送端在層與層之間傳輸數據時，每通過一層時一定會打上一個該層的首部信息。接收端沒通過一層，會把消去。這種數據信心包裝叫作封裝。

TCP/IP傳輸是三次握手，四次斷開。一張圖搞定一切。

三、URI和URL

URI用字符串標示某一互聯網資源，而URL表示資源的地點。可見URL是URI的子集。

URI要使用涵蓋所有必要信息的URI、絕對URL以及相對URL。相對URL是指從瀏覽器中基本URI處理的URL，來先看下URI的格式

簡單的HTTP協議

一、通訊過程

HTTP協議規定，請求從客戶端發出，最後服務器端相應該請求並返回。換個意思就是客戶端創建通訊的，服務器端在沒有接收到請求以前不會發送響應。來一個示例：

下面的內容是客戶端想服務端發的求求內容

GET / HTTP/1.1
HOST: HACKR.JP
起始行的get表示請求訪問服務器的類型，成爲方法。隨後的字符串指明瞭請求訪問的資源對象，也叫請求URL，後面是版本號，用來提示客戶端使用的HTTP協議功能

總結：請求報文是由請求方法、請求URL、協議版本、可選的氣你去頭和內容實體構成的。

接下來服務器端接收到請求，會將請求內容的處理結果以相應的形式返回。

HTTP /1.1 200 OK
Date：Tue，10 JUL 2016 10:50:20 GMT
Content-length：398
Content-Type：text/html
來用圖片詳細講解一下：

二、HTTP是不保存狀態的協議

HTTP是一種不報錯狀態，即無狀態協議。http協議自身不對請求和相應之間的通訊狀態進行保存，也就是說在HTTP這個級別，協議對於發送過得請求和響應不作持久化處理。

使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。協議本事並不保留以前的請求或響應報文的信息。這是爲了處理大量事務，確保協議的課伸縮性，而特地吧HTTP協議設計成如此簡單的。可是也存在弊端，當業務處理變得棘手的狀況多了,好比用戶登陸一家網站，即便他跳轉到別的頁面後，也須要保持登陸狀態，然而cookie就誕生了。有了cookie再用http協議通訊，就能夠管理狀態了。

三、HTTP方法

3.一、GET獲取資源

get方法是用來請求訪問已被URL識別的資源。指定的資源經服務端解析後返回響應內容。也就是說，請求的資源是文本，那就保持原樣返回；若是像cgi那樣的程序，則返回通過執行後的輸出結果

使用get方法的請求響應的例子：

3.二、POST傳輸實體主體

post方法用來傳輸實體的主體。雖然用get方法也能夠傳輸實體的主體，可是通常不用get方法進行傳輸，而是用post方法。雖然說post的功能與get很類似，可是post的主要目的並非獲取相應的主體內容。

使用post方法請求的例子：

3.三、PUT傳輸文件

put方法用來傳輸文件，就像FTP協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求url指定的位置。因爲put的方法不帶驗證機制，任何人均可以上傳文件，存在安全性問題，所以通常的web網站不適用該方法。

使用put方法請求的例子：

3.四、head獲取報文首部

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

使用head方法請求的例子：

3.五、DELETE刪除文件

delete方法用來刪除文件，是與put相反的方法，delete方法按照請求url刪除指定的資源。其本質和put方法同樣不帶驗證機制，因此不適用delete方法。

使用delete方法請求的例子：

下面列舉一些方法：其中link和unlink已被HTTP/1.1廢棄 ，不在支持

四、持久化

當頻繁訪問web網頁的時候，每次都要進行TCP/IP通訊，tcp/ip通訊三次握手四次斷開，代價是很昂貴的，增長了通訊量的開銷，爲解決上述TCP鏈接的問題，HTTP就誕生了持久鏈接的方法。特色是隻要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態

持久化鏈接減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務端的負載。另外，減小開銷的那部分時間，使HTTP請求和響應可以更早的結束，這樣web頁面的顯示速度也就相應的提升了。

五、使用cookie的狀態管理

cookie技術經過在請求和相應報文中寫入cookie信息來控制客戶端的狀態。cookie會根據從服務端發送的相應報文內的一個叫作set-cookie的首部字段信息，通知客戶端保存cookie。當下次客戶端再往服務器發送請求的時候，客戶端會自動在請求頭加入cookie值後發送出去。下面帶圖分析下過程

• 沒有cookie狀態下的請求

• 第二次之後（存有cookie信息狀態）的請求

注：百度雲連接：HTTP圖解

HTTP 狀態碼（HTTP Status Code）

一些常見的狀態碼爲：

200     //服務器成功返回網頁
404     //請求的網頁不存在
503     //服務器不可用

1xx（臨時響應）

表示臨時響應並須要請求者繼續執行操做的狀態碼。
代碼說明

100     //繼續  請求者應當繼續提出請求。服務器返回此代碼表示已收到請求的第一部分，正在等待其他部分。
101     //切換協議  請求者已要求服務器切換協議，服務器已確認並準備切換。

2xx（成功）

表示成功處理了請求的狀態碼。
代碼說明

200     //成功  服務器已經成功處理了請求。一般，這表示服務器提供了請求的網頁。
201     //已建立  請求成功而且服務器建立了新的資源
202     //已接受  服務器已接受請求，但還沒有處理
203     //非受權信息  服務器已經成功處理了請求，但返回的信息可能來自另外一來源
204     //無內容  服務器成功處理了請求，但沒有返回任何內容
205     //重置內容  服務器成功處理了請求，但沒有返回任何內容
206     //部份內容  服務器成功處理了部分GET請求

3xx（重定向）

表示要完成請求，須要進一步操做。一般，這些狀態代碼用來重定向。
代碼說明

300     //多種選擇  針對請求，服務器可執行多種操做。服務器可根據請求者（user agent）選擇一項操做，或提供操做列表供請求者選擇。
301     //永久移動  請求的網頁已永久移動到新位置。服務器返回此響應（對GET或HEAD請求的響應）時，會自動將請求者轉到新位置。
302     //臨時移動  服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求
303     //查看其它位置  請求者應當對不一樣的位置使用單獨的GET請求來檢索響應時，服務器返回此代碼
304     //未修改  自動上次請求後，請求的網頁未修改過。服務器返回此響應，不會返回網頁的內容
305     //使用代理  請求者只能使用代理訪問請求的網頁。若是服務器返回此響應，還表示請求者應使用代理
307     //臨時性重定向  服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有的位置來進行之後的請求

4xx（請求錯誤）

這些狀態碼錶示請求可能出錯，妨礙了服務器的處理。

代碼說明

400     //錯誤請求  服務器不理解請求的語法
401     //未受權  請求要求身份驗證。對於須要登陸的網頁，服務器可能返回此響應
403     //禁止  服務器拒絕請求
404     //未找到  服務器找不到請求的網頁
405     //方法禁用  禁用請求中指定的方法
406     //不接受  沒法使用請求的內容特性響應請求的網頁
407     //須要代理受權  此狀態碼與401（未受權）相似，但指定請求者應當受權使用代理
408     //請求超時  服務器等候請求時發生超時
409     //衝突  服務器在完成請求時發生衝突。服務器必須在響應中包含有關衝突的信息。
410     //已刪除  若是請求的資源已永久刪除，服務器就會返回此響應
411     //須要有效長度  服務器不接受不含有效內容長度標頭字段的請求
412     //未知足前提條件  服務器未知足請求者在請求者設置的其中一個前提條件
413     //請求實體過大  服務器沒法處理請求，由於請求實體過大，超出了服務器的處理能力
414     //請求的URI過長  請求的URI（一般爲網址）過長，服務器沒法處理
415     //不支持媒體類型  請求的格式不受請求頁面的支持
416     //請求範圍不符合要求  若是頁面沒法提供請求的範圍，則服務器會返回此狀態碼
417     //未知足指望值  服務器未知足「指望」請求標頭字段的要求

5xx（服務器錯誤）

這些狀態碼錶示服務器在嘗試處理請求時發生內部錯誤。這些錯誤多是服務器自己的錯誤，而不是請求出錯。

代碼說明

500     //服務器內部錯誤  服務器遇到錯誤，沒法完成請求
501     //還沒有實施  服務器不具有完成請求的功能。例如，服務器沒法識別請求方法時可能會返回此代碼
502     //錯誤網關  服務器做爲網關或代理，從上游服務器沒法收到無效響應
503     //服務器不可用  服務器目前沒法使用（因爲超載或者停機維護）。一般，這只是暫時狀態
504     //網關超時  服務器做爲網關代理，可是沒有及時從上游服務器收到請求
505     //HTTP版本不受支持  服務器不支持請求中所用的HTTP協議版本