HTTP基本內容

*********************HTTP基本交互***************************

HTTP請求格式：
HTTP 請求由三部分組成：請求行、請求頭和請求正文
請求行： 請求方法 URL 協議/版本

例如：GET /books/?sex=man&name=Professional  HTTP/1.1
請求方法有不少，例如：GET Post HEAD PUT DELETE 等等

GET與Post的區別：
一、在客戶端，GET方式在經過URL提交數據，數據在URL中能夠看到；POST方式，數據放在HTTP包的body中。
二、GET方式提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST則沒有此限制。
三、安全性問題。正如在（1）中提到，使用 GET 的時候，參數會顯示在地址欄上，而 Post 不會。因此，
若是這些數據是中文數據並且是非敏感數據，
那麼使用 GET；若是用戶輸入的數據不是中文字符並且包含敏感數據，那麼仍是使用 post爲好。
4.、服務器取值方式不同。GET方式取值，如php可使用$_GET來取得變量的值，而POST方式經過$_POST
來獲取變量的值
5. 安全的和冪等的。所謂安全的意味着該操做用於獲取信息而非修改信息。冪等的意味着對同一 URL 的多
個請求應該返回一樣的結果Get操做通常不會產生反作用。POST 表示可能改變服務器上的資源的請求。
仍然以新聞站點爲例，讀者對文章的註解應該經過 POST 請求實現，由於在註解提交以後站點已經不一樣了

HEAD方法跟GET方法相同，只不過服務器響應時不會返回消息體。一個HEAD請求的響應中，HTTP頭中包含的元信
息應該和一個GET請求的響應消息相同。
這種方法能夠用來獲取請求中隱含的元信息，而不用傳輸實體自己。也常常用來測試超連接的有效性、可用性
和最近的修改。欲判斷某個資源是否存在，咱們一般使用GET，但這裏用HEAD則意義更加明確。

put 和post的區別：這兩個方法都有更新或者建立資源的意思
可是put和post有什麼區別呢：
在HTTP中，PUT被定義爲idempotent的方法，POST則不是，這是一個很重要的區別。
idempotent的意思就是說一個方法重複執行屢次，產生的效果是同樣，就是idempotent的
假如咱們發送兩個http://superblogging/blogs/post/Sample請求，服務器端是什麼樣的行爲？若是產生了
兩個博客帖子，那就說明這個服務不是idempotent的，
由於屢次使用產生了反作用了嘛；若是後一個請求把第一個請求覆蓋掉了，那這個服務就是idempotent的。
前一種狀況，應該使用POST方法，後一種狀況，應該使用PUT方法。

請求頭：
每一個頭域由一個域名，冒號（:）和域值三部分組成。
常見的請求頭以下：
Transport頭域：
Connection:Keep-Alive 表示是否須要持久鏈接，HTTP1.1版本還引入了管道機制(pipelining)
即在同一個TCP鏈接裏面，客戶端能夠同時發送多個請求。這樣就進一步改進了HTTP協議的效率

服務器也能夠傳送多個迴應，因此須要一種機制區分數據報是屬於哪種迴應，這就是Content-length
這個字段所起的做用，好比本次迴應的長度是100個字節，後面的字節就屬於下一個迴應了
Host頭域：
Host請求報頭域主要用於指定被請求資源的Internet主機和端口號
Client頭域：
Accept:瀏覽器能夠接受的媒體類型，例如text,html,image等等，若是是*/*則表示瀏覽器能夠接受全部類型
Accept-Encoding：瀏覽器申明本身接收的編碼方法，一般指定壓縮方法
Accept-Language： 瀏覽器聲明本身接受的語言
User-Agent:告訴HTTP服務器，客戶端使用的操做系統和瀏覽器的名稱和版本
Accept-Charset：瀏覽器聲明本身接受的字符集
Cookie/Login 頭域：
Cookie: 將Cookie的值發送給HTTP 服務器
Entity頭域：
Content-Length：發送給HTTP服務器數據的長度。
Content-Type：表示數據類型和使用的字符集 例如：text/html;charset=utf-8
Miscellaneous 頭域
Referer: 提供了Request的上下文信息的服務器，告訴服務器我是從哪一個連接過來的
Cache 頭域
If-Modified-Since：
把瀏覽器端緩存頁面的最後修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最後修改時間進行對比。
若是時間一致，那麼返回304，客戶端就直接使用本地緩存文件。若是時間不一致，就會返回200和新的文件內容。
客戶端接到以後，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中
Cache-Control：指定緩存機制的規則 有如下選項：Public(能夠被任何緩存所緩存),private(內容只緩存到私有緩存中),
no-cache(全部內容都不會被緩存)

HTTP響應格式：
HTTP 響應也是由三個部分組成，分別是：狀態行、消息報頭和響應正文
1.狀態行： 狀態行由協議版本、數字形式的狀態代碼，及相應的狀態描述組成
200 OK //客戶端請求成功
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
2.消息包頭：
Cache頭域
Date：做用：生成消息的具體時間和日期，即當前的GMT時間。
Expires：做用: 瀏覽器會在指定過時時間內使用本地緩存，指明應該在何時認爲文檔已通過期，從而再也不緩存它。
Vary：例如: Vary: Accept-Encoding
Cookie/Login 頭域
P3P：做用: 用於跨域設置Cookie, 這樣能夠解決iframe跨域訪問Cookie的問題
Set-Cookie
做用： 很是重要的header, 用於把Cookie 發送到客戶端瀏覽器， 每個寫入Cookie都會生成一個Set-Cookie.
例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Entity實體頭域：
實體內容的屬性，包括實體信息類型，長度，壓縮方法，最後一次修改時間，數據有效性等。
ETag：
做用: 和If-None-Match 配合使用。 （實例請看上節中If-None-Match的實例）
Last-Modified
做用： 用於指示資源的最後修改日期和時間。（實例請看上節的If-Modified-Since的實例）
Content-Type：
做用：WEB服務器告訴瀏覽器本身響應的對象的類型和字符集,
Content-Length：
指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程當中，Content-Length的方式要預
先在服務器中緩存全部數據，而後全部數據再一古腦兒地發給客戶端。
Content-Encoding：
做用：文檔的編碼（Encode）方法。通常是壓縮方式。
Content-Language：
做用： WEB服務器告訴瀏覽器本身響應的對象的語言

Miscellaneous 頭域
Server：做用：指明HTTP服務器的軟件信息 例如:Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By：做用：表示網站是用什麼技術開發的。例如： X-Powered-By: PHP/5.2.5

Transport頭域
Connection 　例如Connection: keep-alive 當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的
TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接

Location：做用： 用於重定向一個新的位置， 包含新的URL地址
3.響應正文：
響應正文就是服務器返回的資源的內容，響應頭和正文之間也必須用空行分隔

*********************HTTPS內容***********************
session和 Cookie
對稱祕鑰：即發送和接收數據的雙方必使用相同的密鑰對明文進行加密和解密運算
SSL TLS:
SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）
是爲網絡通訊提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層對網絡鏈接進行加密

SSL/TLS協議的基本過程：
（1） 客戶端向服務器端索要並驗證公鑰。
（2） 雙方協商生成"對話密鑰"。
（3） 雙方採用"對話密鑰"進行加密通訊。

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密。

前兩步又稱握手階段
1.首先客戶端發出請求 --> ClientHello
好比：客戶端支持的TLS版本 ; 支持的加密方法 ; 支持的壓縮方法 ; 一個客戶端生成的隨機數
2.服務器迴應 --> SeverHello
確認使用的加密通訊協議版本，好比TLS 1.0 若是客戶端和服務器版本不一致，服務器就會關閉加密服務
確認使用的加密方法；一個服務器生成的隨機數; 服務器證書
3. 客戶端迴應：首先會驗證服務器發過來的證書。若是證書不是可信機構頒佈、或者證書中的域名與
實際域名不一致、或者證書已通過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。
而後客戶端從證書中取出服務器的公鑰，並向服務器發送下面的信息：
一個隨機數，這個隨機數用公鑰加密，防止被竊聽；
編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密碼發送;
客戶端握手結束通知。
4. 服務器收到就利用私鑰解密消息獲得第三個隨機數，而後計算本次會話所用的「會話祕鑰」
(至此，服務器和客戶端已經有三個隨機數，而後雙方就使用以前約定好的加密方法生成同一把
「會話祕鑰」，這就是後面使用的對稱加密的祕鑰)，而後服務器就會客戶端發送如下消息：
編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送；
服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，
用來供客戶端校驗。

等握手階段結束之後，客戶端與服務器進入加密通訊，就徹底是使用普通的HTTP協議，
只不過用"會話密鑰"加密內容。

握手階段中須要注意的三點：
（1）生成對話密鑰一共須要三個隨機數。
（2）握手以後的對話使用"對話密鑰"加密（對稱加密），服務器的公鑰和私鑰只用於加密和解密"對話密鑰"（非對稱加密），
無其餘做用。
（3）服務器公鑰放在服務器的數字證書之中。

************HTTP1.0與HTTP1.1的區別*******************
HTTP 1.1在繼承了HTTP 1.0優勢的基礎上，也克服了HTTP 1.0的性能問題
1.HTTP1.1支持了持久鏈接Persistent Connection，並默認使用持久鏈接。爲此也增長了新的請求頭：
Connection請求頭的值爲Keep-Alive時，客戶端通知服務器返回本次請求結果後保持鏈接；
Connection請求頭的值爲close時，客戶端通知服務器返回本次請求結果後關閉鏈接
2.HTTP1.1新增了請求的流水線（Pipelining）機制，或者叫管道機制。即在同一個TCP鏈接裏面，
客戶端能夠同時發送多個請求.管道機制則是容許瀏覽器同時多個請求，可是服務器仍是按照請
求順序迴應各個請求。爲此也新增了字段Content-Length
3.分塊傳輸編碼
使用Content-Length字段的前提條件是，服務器發送迴應以前，必須知道迴應的數據長度。
對於一些很耗時的動態操做來講，這意味着，服務器要等到全部操做完成，才能發送數據，顯然這樣的效率不高。
更好的處理方法是，產生一塊數據，就發送一塊，採用"流模式"（stream）取代"緩存模式"（buffer）。
只要請求或迴應的頭信息有Transfer-Encoding字段，就代表迴應將由數量未定的數據塊組成.
每一個非空的數據塊以前，會有一個16進制的數值，表示這個塊的長度。最後是一個大小爲0的塊，
就表示本次迴應的數據發送完了.
4.新增了HOST域
在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。
但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且
它們共享一個IP地址。在HTTP 1.1中增長Host請求頭字段後，WEB瀏覽器可使用主機頭名來明確表示要訪問
服務器上的哪一個WEB站點，這才實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來
建立多個虛擬WEB站點
5.新增了請求方法
好比OPTIONS,PUT, DELETE, TRACE, CONNECT等方法
6.新增了支持傳遞部份內容的功能
HTTP1.1支持傳送內容的一部分。比方說，當客戶端已經有內容的一部分，爲了節省帶寬，能夠只向服務器請求一部分
HTTP/1.1中在請求消息中引入了range頭域，它容許只請求資源的某個部分。在響應消息中Content-Range頭
域聲明瞭返回的這部分對象的偏移值和長度。若是服務器相應地返回了對象所請求範圍的內容，則響應碼爲206
（Partial Content），它能夠防止Cache
將響應誤覺得是完整的一個對象
7.節約寬帶
另一種浪費帶寬的狀況是請求消息中若是包含比較大的實體內容，但不肯定服務器是否可以接收該請求（如是否有權限），
此時若貿然發出帶實體的請求，若是被拒絕也會浪費帶寬。
HTTP/1.1加入了一個新的狀態碼100（Continue）。客戶端事先發送一個只帶頭域的請求，若是服務器由於權限拒絕了請求，
就回送響應碼401（Unauthorized）；若是服務器接收此請求就回送響應碼100，客戶端就能夠繼續發送帶實體的完整請求了。
注意，HTTP/1.0的客戶端不支持100響應碼。但可讓客戶端在請求消息中加入Expect頭域，並將它的值設置爲100-continue
8.新增了一些狀態碼

***********************session與Cookie******************
google瀏覽器網址輸入欄左邊有個 圓圈i，點開後就有Cookie這個文件夾
Cookie(甜餅)
Cookie機制是幹什麼的，有什麼用，怎麼用
1.Http是無狀態的協議，也就是說同一客戶端這一次與下一次發送的請求沒有對應關係，若是說相似於用戶購買東西
先後買的東西都要放在同一個帳號上的購物車裏，就須要一種機制確保服務器知道每次客戶身份，這樣就能夠先後客
戶是什麼關係，是否是同一個用戶了。
2.Cookie其實是一小段的文本信息。客戶端請求服務器，若是服務器須要記錄該用戶狀態，就使用response向客戶
端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同
該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還能夠根據須要修改Cookie的內容。
Cookie對象使用key-value屬性對的形式保存用戶狀態，
一個Cookie對象保存一個屬性對，一個request或者response同時使用多個Cookie
3.如何查看Cookie內容
兩種方式 第一種方式利用F12 第二種方式在網址左側能夠查看，後續圖片補上
4.Cookie的幾個特色：
①：Cookie的不可跨域名性
對於不一樣的域名會有對應的Cookie，Cookie是保存在客戶端上由瀏覽器來管理，瀏覽器能保存只處理指定域名的Cookie，
從而保證用戶的隱私安全。
②：Cookie的有效性
Cookie的maxAge決定着Cookie的有效期，單位爲秒。
客戶端能夠採用兩種方式來保存這個 Cookie 對象，一種方式是保存在客戶端內存中，稱爲臨時 Cookie，瀏覽器關閉後
這個 Cookie 對象將消失。 另一種方式是保存在客戶機的磁盤上，稱爲永久 Cookie。之後客戶端只要訪問該網站，
就會將這個 Cookie 再次發送到服務器上，前提是這個 Cookie 在有效期內，這樣就實現了對客戶的跟蹤。

Session機制：
除了使用Cookie，Web應用程序中還常用Session來記錄客戶端狀態。Session是服務器端使用的一種記錄客戶端狀態
的機制，使用上比Cookie簡單一些，相應的也增長了服務器的存儲壓力。Session是另外一種記錄客戶狀態的機制，不一樣的
是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以
某種形式記錄在服務器上。客戶端瀏覽器再次訪問時只須要從該Session中查找該客戶的狀態就能夠了。若是說Cookie機
制是經過檢查客戶身上的「通行證」來肯定客戶身份的話，那麼Session機制就是經過檢查服務器上的「客戶明細表」來確認
客戶身份。Session至關於程序在服務器上創建的一份客戶檔案，客戶來訪的時候只須要查詢客戶檔案表就能夠了。
Session如何實現？
1.利用Cookie
sessionid是一個會話的key，瀏覽器第一次訪問服務器會在服務器端生成一個session，有一個sessionid和它對應。
tomcat生成的sessionid叫作jsessionid。而後服務器經過Cookie發送給客戶端。當客戶端再發起請求的時候，
將在Cookie頭中攜帶這個sessionid。這樣服務器可以找到這個
客戶端對應的Session。沒有找到則會新建Session.
2.若是客戶端瀏覽器不支持Cookie或者將Cookie禁止了，能夠利用URL重寫的辦法來讓服務器獲取到session id。
URL地址重寫是對客戶端不支持Cookie的解決方案。URL地址重寫的原理是將該用戶Session的id信息重寫到URL地址中。
服務器可以解析重寫後的URL獲取Session的id。這樣即便客戶端不支持Cookie，也可使用Session來記錄用戶狀態。

Cookie和Session有如下明顯的不一樣點：1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；2）Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器。Cookie最先在RFC2109中實現，後續RFC2965作了加強。網絡服務器用HTTP頭向客戶端發送Cookies，在客戶終端，瀏覽器解析這些Cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些Cookies。Session並無在HTTP的協議中定義；3）Session是針對每個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪一個用戶session變量,這個值是經過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用Cookie時，這個值也可能設置爲由get來返回給服務器；4）就安全性來講：當你訪問一個使用session 的站點，同時在本身機子上創建一個Cookie，建議在服務器端的SESSION機制更安全些.由於它不會任意讀取客戶存儲的信息。5 )Cookie不是很安全，別人能夠分析存放在本地的Cookie並進行Cookie欺騙，考慮到安全應當使用session；6 )session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能。考慮到減輕服務器性能方面，應當使用Cookie；