HTTP,即超文本傳輸協議(HyperText Transfer Protocal),是一個可靠的數據傳輸協議,依賴於傳輸層的TCP協議實現,也就是說HTTP的可靠性依靠TCP協議,主要功能是進行瀏覽器和服務器之間的「溝通」算法
其中超文本即「超級文本」,能夠理解成一種帶有超連接的文本瀏覽器
HTTP運行在CS架構上,即客戶端/服務端模式,這裏的客戶端通常是計算機、手機等,經過瀏覽器造成網站客戶端,服務端就是Web瀏覽器,HTTP協議就在客戶端和服務端之間運行緩存
Web服務器能夠分爲硬件部分和軟件部分,硬件部分主要是裸金屬的設備,例如計算機,軟件部分會運行一些軟件,提供HTTP服務,例如Apache安全
整個過程以下(服務器視角):服務器
客戶端經過HTTP協議發送請求的經常使用方法包括GET、POST、DELETE、UPDATE網絡
get:獲取指定的服務端資源,也能夠提交數據到服務端,在地址(url)中以文件名/查詢字符串的形式進行指定架構
post:提交數據到服務端,在請求數據中指定發送的數據併發
delete:刪除指定服務端資源post
update:更新指定的服務端資源網站
其餘方法還有PUT、HEAD、TRACE、OPTIONS
put:把消息本體中的消息發送到一個url,跟post相似,但不經常使用,不過相比於post是不冪等的
head:相似於get請求,只不過返回的響應中沒有具體的內容,用戶獲取報頭
一、GET參數經過URL傳遞,POST放在Request body(請求體)中,而url是能夠被爬蟲獲取的,所以不安全
二、GET請求會被瀏覽器主動cache(緩存),而POST不會,除非手動設置。
三、GET請求參數會被完整保留在瀏覽器歷史記錄裏,而POST中的參數不會被保留(參考1)
四、GET請求中有非 ASCII 字符,會在請求以前進行轉碼,POST不用,由於POST在Request body(請求體)中,經過 MIME,也就能夠傳輸非 ASCII 字符。
五、 通常咱們在瀏覽器輸入一個網址訪問網站都是GET請求
六、HTTP的底層是TCP/IP。HTTP只是個行爲準則,而TCP纔是GET和POST怎麼實現的基本。
GET/POST都是TCP連接。GET和POST能作的事情是同樣同樣的。可是請求的數據量太大對瀏覽器和服務器都是很大負擔。因此業界有了不成文規定,(大多數)瀏覽器一般都會限制url長度在2K個字節,而(大多數)服務器最多處理64K大小的url。
七、GET產生一個TCP數據包,POST產生兩個TCP數據包。
對於GET方式的請求,瀏覽器會把http header和data一併發送出去,服務器響應200(返回數據)
而對於POST,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)。
八、在網絡環境好的狀況下,發一次包的時間和發兩次包的時間差異基本能夠無視。而在網絡環境差的狀況下,兩次包的TCP在驗證數據包完整性上,有很是大的優勢。但並非全部瀏覽器都會在POST中發送兩次包,Firefox就只發送一次。
(轉載自CSDN田園園野,原文連接:http://www.javashuo.com/article/p-gmvfmndu-gp.html)
簡化一下就是:
1.GET把參數放在url裏,而POST把參數放在請求體request body中,url會被瀏覽器cache,同時也保存在了歷史記錄裏,所以有安全性問題,而咱們通常用的是GET方法
2.GET因爲瀏覽器限制url的長度,所以通常認爲GET方法發送數據的長度有限制(看瀏覽器以及服務器的限制)
3.GET發送時候是一個數據包,把http頭和數據一同發送,成功的話服務器響應200,而POST發送兩個數據包(先http頭後數據),先返回100(繼續發送)再返回200(成功發送),不過有的瀏覽器POST中就發一次包(firefox)
包括三部分:(請求方法、請求地址、HTTP版本)、請求頭、請求內容
以下所示,其中請求內容以JSON格式保存
包括三部分:(HTTP版本、狀態碼、狀態解釋)、應答頭、應答內容
其中核心是狀態碼,不一樣的狀態碼有不一樣的含義
100:繼續,客戶端應該繼續請求(例如POST請求發送第一個包之後)
200:請求成功(例如POST請求發送第二個包之後,GET請求發送成功之後)
201:Created,已建立。成功請求並建立了新的資源
202:Accepted,已接受。已經接受請求,但未處理完成
304:未修改,所請求的資源未修改,服務器返回此狀態碼時,不會返回任何資源。客戶端一般會緩存訪問過的資源,經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源
400:請求無效,多是①傳輸的數據和後臺的字段不一致②發送的不是一個JSON字符串(沒有用JSON.stringify方法)
401:當前請求須要用戶驗證
403:服務器已經獲得請求,可是拒絕執行
404:服務器沒法根據客戶端的請求找到資源(網頁),也就是最多見的404 not found
500:服務器內部錯誤,沒法完成請求
502:Bad Gateway,做爲網關或者代理工做的服務器嘗試執行請求時,從遠程服務器接收到了一個無效的響應
把一些常訪問的內容放到Web緩存中,以提升訪問的效率
設置在客戶端/服務端之間,在如下幾種場景中使用
1.須要屏蔽服務端的部署結構
2.服務端部署在敏感地方,須要保證服務端的安全(防火牆)
包括正向代理/反向代理(客戶端視角)
即內容分發網絡(Content Delivery Network),可進行多媒體內容加速,能夠說是爲了加速而存在的
例如在遠距離的訪問中,能夠把一部分常訪問的內容備份在一個近一些的地方,以提升這部份內容的訪問速度
HTTP的問題在於,其信息是明文傳輸的,會形成不安全,所以使用HTTPS協議
相比於HTTP協議,訪問網站時,協議變化,端口變化成443
分爲對稱加密(加密和解密階段用的同一個祕鑰)和非對稱加密(祕鑰不一致,但兩者之間有必定的數學關係,包括公鑰和私鑰)
可信任組織頒發給特定對象的認證,這裏必須客戶端和服務端都認爲其可信任才行
通常包括證書格式、版本號、證書序列號、簽名算法、有效期、對象名稱、對象公開祕鑰幾個部分
即安全套接層(Secure Sockets Layer),位於應用層和傳輸層之間的子層,用來保障數據安全和數據完整,並對傳輸層數據進行加密並傳輸
整個HTTPS鏈接過程以下:
1.443端口的TCP鏈接
2.SSL安全參數握手,以後就能夠進行數據的加密和解密
3.客戶端能夠發送數據,發送前加密,到了服務端再解密,一樣地服務端也能夠發送數據,發送前加密,到了客戶端再解密
SSL的安全參數握手由分爲如下幾步:
1.客戶端生成隨機數1,把隨機數、協議版本、加密算法發送給客戶端
2.服務端隨即生成一個隨機數2,並把隨機數2和數字證書發給客戶端,確認下加密算法
3.以後客戶端先確認數字證書是否有效,而後生成一個隨機數3,並使用服務器的公鑰(從數字證書中取出)加密隨機數3,把這個加密後的隨機數3發給服務端
4.雙方根據隨機數一、二、3生成對稱祕鑰,以後就能夠用對稱祕鑰進行加密通訊
整個過程綜合用了對稱和非對稱加密,並且祕鑰沒有傳輸,所以大大下降了祕鑰泄漏的風險