HTTP請求響應機制及https創建通訊機制

1.HTTP協議

Internate的基本協議是TCP/IP（傳輸控制協議和網際協議）。而目前使用的FTP，HTTP都是創建在TCP/IP上的應用層協議。不一樣的協議對應不一樣的應用。而HTTP協議是Web應用所使用的主要協議。

HTTP協議基於請求響應模式，客戶端向服務器發送一個請求，請求頭包含請求的方法，URI，協議版本以及包含請求修飾符，客戶端信息和內容的相似MIME的消息結果。服務器則以一個狀態行爲做爲響應，相應的內容包括消息協議的版本，成功或錯誤編碼加上包含服務器信息，實體元信息以及可能的實體內容。

HTTP協議是無狀態協議，依賴瞬間或者近乎瞬間的請求處理。請求信息被當即發送，理想的狀況是沒有延遲地進行處理；不過，延遲仍是客觀存在的。HTTP協議有一種內置機制，在消息的傳遞時間上有必定的靈活性：超時機制。一個超時就是客戶端等待請求消息返回信息的最長時間。
HTTP協議的請求和響應消息若是沒有發送並傳遞成功的話，不保存任何已傳遞的信息。好比，單擊「提交」按牛，若是表單沒有發出去，則瀏覽器將會顯示錯誤信息頁，而且返回空白表單。雖然沒有提交成功，可是HTTP不保存任何表單信息。

因爲HTTP協議的上述特色，一般，客戶端每次須要更新信息都必須從新向服務器發起請求，客戶端接受到服務器端返回的信息後再刷新屏幕內容。
基於HTTP協議的客戶端/服務器請求響應 機制的信息交換過程包含下面幾個步驟：

1.創建鏈接：客戶端與服務器創建TCP鏈接
2.發送請求：打開一個鏈接後，客戶端把請求信息發送到服務器的相應端口上，完成請求動做提交。
3.發送響應：服務器在處理完客戶端請求以後，要向客戶端發送響應消息。
4.關閉鏈接：客戶端和服務器端均可以關閉套接字來結束TCP/IP對話。

HTTP的工做機制就是請求消息和響應消息。嘴尖但的狀況是一個擁護輸入一個站點地址，發送一個請求。以後，瀏覽器返回所請求的頁面，這個頁面多是最簡單的HTML頁面，也多是動態編譯後的頁面。若是這個頁面有錯或者不存在，則WEB服務器則將發送一個錯誤的信息頁面。

WEB服務器發送錯誤信息頁是由於HTTP沒有內置的處理機制，是無狀態的，傳輸協議不記憶從一個請求消息到另外一個請求消息的任何信息（備註：意思是說，當發送一個請求消息發生錯誤，因爲HTTP是無狀態的，因此不能將這個發生錯誤的請求消息傳遞給另外一個請求消息進行處理，也是請求消息不能轉彎，必須一次傳到並獲得處理） 這個特色能夠保證WEB的一致性。可是，用戶經常須要記憶一些設置內容或者瀏覽過程，這就須要在web頁面或者URL中攜帶各類參數及值。HTTP請求有多種樣式。其中經常使用的有GET，POST，HEAD請求。

//這3個請求暫時不提了

5.狀態管理

正如前面所提到的，HTTP協議是無狀態的，不能保存每次提交的信息，即當服務器返回與請求相對應的應答以後，此次事務的全部信息就都丟掉了。若是用戶發來一個新的請求，服務器也沒法知道它是否與上次的請求有聯繫。

對於簡單的靜態HTML文件來講，這種特性是很適用，可是對於那些須要屢次提交請求才能完成的WEB操做好比購物車來講，就成了問題了。服務器端的WEB應用程序必須容許用戶經過多個步驟才能完成所有的物品採購。在這種狀況下，應用程序必須跟蹤由同一個瀏覽器發送的多哥請求所提供的信息，即記住用戶的交易狀態。

一般，採用兩種方法來解決這個問題。一個是每次應答都返回完整的狀態，讓瀏覽器把它做爲下次請求的一部分再發送過來。二是把狀態保存在服務器的某個地方，只發送回一個標識符，瀏覽器在下次提交中把這個標識符發送過來；這樣，就能夠定位存貯在服務器上的狀態信息了。

在這兩種方法中，信息能夠經過下列三種方法中的一種發送給瀏覽器：
1.做爲COOKIE； 可是不是全部瀏覽器都支持，並且用戶也能夠禁用COOKIE
2.附加在主體的URL中
2.做爲隱藏域嵌入HTML表單中；

當表但提交時，瀏覽器將做爲常規HTTP參數的方式將這些信息返回服務器，當狀態信息被注入時，它將做爲請求URL的一部分傳誦到服務器，可是這在瀏覽器和服務器之間來回傳遞信息的效率較低，因此通常仍是選擇把信息保存在服務器中，即上面兩種方法中的第二種。在瀏覽器和服務器之間來回傳遞一個標識符，這就是所謂的會話（session）跟蹤。來自瀏覽器的全部包含同一個標識符（這裏是SESSIONID）的請求同屬於一個會話。

會話的有效期直到它被顯式地終止爲止，或者當擁護在異端時間內沒有動做，由服務器自動設置爲過時。目前沒有辦法通知服務器用戶已經關閉瀏覽器，由於在瀏覽器和服務器之間沒有一個持久的鏈接，而且瀏覽器關閉時也不向服務器發送信息。同時，關閉瀏覽器一般意味着會話ID丟失；COOKIE將國旗，或者注入了信息的URL將不能再使用。因此當用戶再次打開瀏覽器的時候，服務器沒法將心得請求與之前的會話聯繫起來，餓睿智能建立一個新的會話。然而，全部與前一個會話有關的數據依然存放在服務器上，直到會話過時被清除爲止。

---

學技術時，老是會問什麼？這裏也不例外，https爲何會存在，它有什麼優勢，又有什麼缺點？爲何網站有的用http，有的用https？若是不能很好的回答，就往下看吧。

http通訊存在的問題

容易被監聽
http通訊都是明文，數據在客戶端與服務器通訊過程當中，任何一點均可能被劫持。好比，發送了銀行卡號和密碼，hacker劫取到數據，就能看到卡號和密碼，這是很危險的
被假裝
http通訊時，沒法保證通行雙方是合法的，通訊方多是假裝的。好比你請求www.taobao.com,你怎麼知道返回的數據就是來自淘寶，中間人可能返回數據假裝成淘寶。
被篡改
hacker中間篡改數據後，接收方並不知道數據已經被更改
共享密鑰加密和公開密鑰加密

後續內容的須要，這裏插播一段共享密鑰加密和公開密鑰加密

共享密鑰加密
共享密鑰的加密密鑰和解密密鑰是相同的，因此又稱爲對稱密鑰
公開密鑰加密
加密算法是公開的，密鑰是保密的。公開密鑰分爲私有密鑰和公有密鑰，公有密鑰是公開的，任何人(客戶端)均可以獲取，客戶端使用公有密鑰加密數據，服務端用私有密鑰解密數據。
異同
共享密鑰加密與公開密鑰加密相比，加解密處理速度快，但公開密鑰更適應互聯網下使用
https解決的問題

https很好的解決了http的三個缺點（被監聽、被篡改、被假裝），https不是一種新的協議，它是http+SSL(TLS)的結合體，SSL是一種獨立協議，因此其它協議好比smtp等也能夠跟ssl結合。https改變了通訊方式，它由之前的http—–>tcp，改成http——>SSL—–>tcp；https採用了共享密鑰加密+公開密鑰加密的方式

防監聽
數據是加密的，因此監聽獲得的數據是密文，hacker看不懂。
防假裝
假裝分爲客戶端假裝和服務器假裝，通訊雙方攜帶證書，證書至關於身份證，有證書就認爲合法，沒有證書就認爲非法，證書由第三方頒佈，很難僞造
防篡改
https對數據作了摘要，篡改數據會被感知到。hacker即便從中改了數據也白搭。
https鏈接過程

服務器端須要認證的通訊過程

這裏寫圖片描述

客戶端發送請求到服務器端
服務器端返回證書和公開密鑰，公開密鑰做爲證書的一部分而存在
客戶端驗證證書和公開密鑰的有效性，若是有效，則生成共享密鑰並使用公開密鑰加密發送到服務器端
服務器端使用私有密鑰解密數據，並使用收到的共享密鑰加密數據，發送到客戶端
客戶端使用共享密鑰解密數據
SSL加密創建………
客戶端認證的通訊的過程

客戶端須要認證的過程跟服務器端須要認證的過程基本相同，而且少了最開始的兩步。這種狀況都是證書存儲在客戶端，而且應用場景比較少，通常金融才使用，好比支付寶、銀行客戶端都須要安裝證書
後續的問題

怎樣保證公開密鑰的有效性 你也許會想到，怎麼保證客戶端收到的公開密鑰是合法的，不是僞造的，證書很好的完成了這個任務。證書由權威的第三方機構頒發，而且對公開密鑰作了簽名。https的缺點 https保證了通訊的安全，但帶來了加密解密消耗計算機cpu資源的問題 ，不過，有專門的https加解密硬件服務器各大互聯網公司，百度、淘寶、支付寶、知乎都使用https協議，爲何？ 支付寶涉及到金融，因此出於安全考慮採用https這個，能夠理解，爲何百度、知乎等也採用這種方式？爲了防止運營商劫持！http通訊時，運營商在數據中插入各類廣告，用戶看到後，怒火發到互聯網公司，其實這些壞事都是運營商(移動、聯通、電信)乾的,用了https，運營商就無法插播廣告篡改數據了。