如果沒有夢想，那跟鹹魚有什麼分別
簡介：
HTTP協議是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫，是一個基於TCP/IP通訊協議來傳遞資料（HTML 檔案, 圖片檔案, 查詢結果等）的協議。
HTTP協議工作於客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB伺服器傳送所有請求。Web伺服器根據接收到的請求後，向客戶端傳送響應資訊。
主要特點:
1. 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
2. 靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
3. 無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。隨著時間的推移，網頁變得越來越複雜，裡面可能嵌入了很多圖片，這時候每次訪問圖片都需要建立一次 TCP 連線就顯得很低效.
Keep-Alive 功能使客戶端到伺服器端的連線持續有效，當出現對伺服器的後繼請求時，Keep-Alive 功能避免了建立或者重新建立連線
4. 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。 5. 支援B/S及C/S模式。
URI
HTTP使用統一資源識別符號（Uniform Resource Identifiers, URI）來傳輸資料和建立連線。
Web上可用的每種資源如HTML文件、影象、視訊片段、程式等都是一個URI來定位的. URI一般由三部組成： ①訪問資源的命名機制 ②存放資源的主機名 ③資源自身的名稱，由路徑表示，著重強調於資源。
URL
URL全稱是UniformResourceLocator, 中文叫統一資源定位符。是一種特殊型別的URI，包含了用於查詢某個資源的足夠的資訊。網際網路上用URL來標識某一處資源的地址,主要用在各種WWW客戶程式和伺服器程式上.
採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。URL一般由三部組成： ①協議(或稱為服務方式) ②存有該資源的主機IP地址(有時也包括埠號) ③主機資源的具體地址。如目錄和檔名等
URN
URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:[email protected]。
三者關係
URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL.
URL的組成部分及其含義:
以下面這個URL為例 http://www.itesting.com:8080/profile/index.aspx?id=5&page=1#name
一個完整的URL包括以下幾部分： 1.協議部分：該URL的協議部分為“http：”，這代表網頁使用的是HTTP協議。在"HTTP"後面的“//”為分隔符。
2.域名部分：該URL的域名部分為“www.itesting.com”。一個URL中，也可以使用IP地址作為域名使用
3.埠部分：跟在域名後面的是埠，域名和埠之間使用“:”作為分隔符。埠不是一個URL必須的部分，如果省略埠部分，將採用預設埠
4.虛擬目錄部分：從域名後的第一個“/”開始到最後一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/profile/”
5.檔名部分：從域名後的最後一個“/”開始到“？”為止，是檔名部分，如果沒有“?”,則是從域名後的最後一個“/”開始到“#”為止，是檔案部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是檔名部分。本例中的檔名是“index.aspx”。檔名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的檔名
6.錨部分：從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
7.引數部分：從“？”開始到“#”為止之間的部分為引數部分，又稱搜尋部分、查詢部分。本例中的引數部分為“id=5&page=1”。引數可以允許有多個引數，引數與引數之間用“&”作為分隔符。
HTTP請求方法
http請求由三部分組成，分別是：請求行、訊息報頭、請求正文
請求行以一個方法符號開頭，以空格分開，後面跟著請求的URI和協議的版本
格式：Method Request-URI HTTP-Version CRLF
Method表示請求方法；
Request-URI是一個統一資源識別符號；
HTTP-Version表示請求的HTTP協議版本；
CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF符）。
舉例：
GET方法：在瀏覽器的位址列中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向伺服器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF)。
HTTP請求方法（所有方法全為大寫）有多種，各個方法的解釋如下：
GET 請求獲取Request-URI所標識的資源
POST 在Request-URI所標識的資源後附加新的資料
HEAD 請求獲取由Request-URI所標識的資源的響應訊息報頭
PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識
DELETE 請求伺服器刪除Request-URI所標識的資源
TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢伺服器的效能，或者查詢與資源相關的選項和需求
常用的是GET， POST， PUT， DELETE
那這四種方法除語義外有什麼其他區別呢？
首先介紹兩個概念：安全性和冪等性。如果針對一個URL的方法不改變URL所指資源的狀態，就稱其為安全的，顯然在這四種方法裡，只有GET方法是安全的。冪等性，來源於數學上的術語，即對同一運算元的多次操作與一次操作效果是一樣的操作符即稱冪等操作符，比如取絕對值操作符。類比到網路操作中就是指一方法對同一URL的請求，多次和一次的效果是一致的，就稱該方法是冪等的，顯然除POST外其他三種方法都是冪等的。
另外在具體技術實現上，這四種方法也有一些區別，那麼POST與GET有什麼區別呢？
1. 使用目標不同：
POST與GET都用於獲取資訊，但是GET方式僅僅是查詢，並不對伺服器上的內容產生任何作用結果；每次GET的內容都是相同的。
POST則常用於傳送一定的內容進行某些修改操作。
2. 大小不同：
由於不同的瀏覽器對URL的長度大小有一定的字元限制，因此由於GET方式放在URL的首部中，自然也跟著首先，但是具體的大小要依瀏覽器而定。
POST方式則是把內容放在報文內容中，因此只要報文的內容沒有限制，它的大小就沒有限制。
3. 安全性不同：
GET是直接新增到URL後面的，直接就可以在URL中看到內容。
而POST是放在報文內部的，使用者無法直接看到。
HTTP報文常見屬性
chrome開啟上面的link，按F12
1. URL, 即http訪問的地址
2. request method, 報文的請求方式
3. status code, 狀態碼以及狀態短語
4. Accept Encoding, 內容編碼
5. Connection, 連線方式
6. Cookie, 新增的cookie內容
7. Host, 目標主機
8. User-Agent, 客戶端瀏覽器的相關資訊
9. Set-Cookie, 指定想要在Cookie中儲存的內容
HTTP是無狀態的，如何儲存狀態？
由於http是一種無狀態的協議，因此無論是客戶端還是伺服器都不記錄http的相關資訊。這樣設計一方面減輕了伺服器端的負載，另一方面減小了http請求的開銷。
但是針對某些特殊的場景，需要時刻記錄使用者的相關資訊，這該如何處理呢?
cookie
客戶端第一次訪問，伺服器在http響應頭中新增Set-Cookie資訊，其值的格式通常是name = value的格式。瀏覽器收到響應後會根據頭中的欄位儲存cookie，下一次訪問時在請求頭中附帶cookie內容，供伺服器根據cookie值進行後續處理。
cookie的內容主要包括：名字，值，過期時間，路徑和域。
cookie機制採用的是在客戶端保持狀態的方案。
與 cookie 相對的一個解決方案是 session:
session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構（也可能就是使用散列表）來儲存資訊。
當程式需要為某個客戶端的請求建立一個session的時候，伺服器首先檢查這個客戶端的請求裡是否已包含了一個session標識- 稱為session id，如果已包含一個session id則說明以前已經為此客戶端建立過session，伺服器就按照session id把這個session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端建立一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字串，這個session id將被在本次響應中返回給客戶端儲存。 儲存這個session id的方式可以採用cookie（一般這個cookie的名字都是類似於SEEESIONID），這樣瀏覽器下次發請求的時候，這個session id會被放置在請求頭中，和cookie一起傳送回來。伺服器再通過記憶體中儲存的session id跟cookie中儲存的ssession id進行比較，並根據id在記憶體中找到之前建立的session物件，提供給請求使用，也就是伺服器會通過session儲存一個狀態記錄，瀏覽器會通過cookie儲存狀態記錄，伺服器通過兩者的對比實現跟蹤狀態，這樣的做，也極大的避免了cookie被篡改而帶來的安全性問題。
URL重寫
由於cookie可以被人為的禁止，必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴伺服器。經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的後面。
附加方式：
1.作為URL路徑的附加資訊，表現形式為：
http://...../xxx;jsessionid=ByOK ... 99zWpBng!-1457887642.作為查詢字串附加在URL後面，表現形式為：
http://...../xxx?jsessionid=ByOK ... 99zWpBng!-145788764
這兩種方式對於使用者來說是沒有區別的，只是伺服器在解析的時候處理的方式不同，採用第一種方式也有利於把session id的資訊和正常程式引數區分開來。 為了在整個互動過程中始終保持狀態，就必須在每個客戶端可能請求的路徑後面都包含這個session id。
cookie和session的區別：
1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能
考慮到減輕伺服器效能方面，應當使用COOKIE。
4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。
5、所以個人建議：
將登陸資訊等重要資訊存放為SESSION
其他資訊如果需要保留，可以放在COOKIE中
HTTP狀態碼
狀態程式碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:
1xx：指示資訊--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：伺服器端錯誤--伺服器未能實現合法的請求
常見狀態碼：
200 OK //客戶端請求成功 400 Bad Request //客戶端請求有語法錯誤，不能被伺服器所理解 401 Unauthorized //請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用 403 Forbidden //伺服器收到請求，但是拒絕提供服務 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL 500 Internal Server Error //伺服器發生不可預期的錯誤 503 Server Unavailable //伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常