HTTP總結
網絡結構分層
1.OSI七層模型
OSI七層模型(OSI是指Open System Interconnect,開放式系統互聯)
OSI七層模型 | 模型描述 |
---|---|
應用層 | 應用程序(電子郵件、文件服務)、用戶接口 |
表示層 | 數據的表示,壓縮和加密(數據格式化、代碼轉換、數據加密) |
會話層 | 建立、管理和終止回話 |
傳輸層 | 提供端到端可靠報文段傳遞和錯誤恢復 |
網絡層 | 提供數據報從源到宿的傳遞和網際交互 |
鏈路層 | 將比特組裝成幀和點到點的傳遞 |
物理層 | 傳輸比特流,以二進制數據形式在物理媒體上傳輸數據 |
2.TCP/IP四層模型
TCP/IP四層模型(傳輸控制協議/網間協議)
TCP/IP四層模型 | 模型描述 |
---|---|
應用層 | 負責處理特定的應用程序細節 |
傳輸層 | 主要爲兩臺主機上的應用提供端到端的通信 |
網絡互聯層 | 處理分組在網絡中的活動,比如分組的選路 |
鏈路層 | 包括操作系統中的設備驅動程序、計算機中對應的網絡接口卡 |
七層模型和四層模型的區別
1.OSI採用七層模型,TCP/IP是四層模型;
2.TCP/IP網絡接口層沒有真正的定義,只是概念性的描述。OSI把它分爲2層,每一層功能詳盡;
3.協議開發之前就有了OSI模型,所以OSI模型具有共通性,TCP/IP是基於協議建立的模型,不適用於非TCP/IP的網絡;
4.實際應用中,OSI是理論上的模型,沒有成熟的產品;TCP/IP已經成爲國際標準;
HTTP協議
Http是基於TCP/IP協議的應用程序協議,不包括數據包的額傳輸,主要規定了客戶端和服務器的通信格式,默認使用80端口;
1991年發佈Http/0.9版本,只有Get命令,且服務端直返HTML格式字符串,服務器響應完畢就關閉TCP連接;
1996年發佈Http/1.0版本,
優點:可以發送任何格式內容,包括文字、圖像、視頻、二進制。也豐富了命令Get、Post、Head。請求和響應的格式加入頭信息;
缺點:每個TCP連接只能發送一個請求,而新建TCP連接的成本很高,導致Http/1.0性能很差;
1997年發佈Http/1.1版本,完善了Http協議,直至今天也是最流行的版本;
優點:引入持久連接,TCP默認不關閉,可被多個請求複用,對於一個域名,多數瀏覽器允許同時建立6個持久連接;
引入管道機制,在同一個TCP連接中,可以同時發送多個請求,不過服務器還是按順序響應;
在頭部加入Content-Length字段,一個TCP可以同時傳送多個響應,所以就需要該字段來區分哪些內容屬於哪個響應;
分塊傳輸編碼,對於耗時的動態操作,用流模式取代緩存模式,即產生一塊數據,就發送一塊數據;
增加了許多命令,頭信息增加Host來指定服務器域名,可以訪問一臺服務器上的不同網站;
缺點:TCP連接中的響應有順序,服務器處理完一個迴應才能處理下一個迴應,如果某個迴應特別慢,後面的額請求就會排隊等着(對頭阻塞);
2015年發佈Http/2版本,它有幾個特性:二進制協議、多工、數據流、頭信息壓縮、服務器推送;
HTTP請求和響應格式
1.Request
GET /barite/account/stock/groups HTTP/1.1
QUARTZ-SESSION: MC4xMDQ0NjA3NTI0Mzc0MjAyNg.VPXuA8rxTghcZlRCfiAwZlAIdCA
DEVICE-TYPE: ANDROID
API-VERSION: 15
Host: shitouji.bluestonehk.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/3.10.0
2.Response
HTTP/1.1 200 OK
Server: nginx/1.6.3
Date: Mon, 15 Oct 2018 03:30:28 GMT
Content-Type: application/json;charset=UTF-8
Pragma: no-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Encoding: gzip
Transfer-Encoding: chunked
Proxy-Connection: Keep-alive
字段 | 字段描述 |
---|---|
Host | 指定服務器域名,可用來區分訪問一個服務器上的不同服務; |
Connection | keep-alive表示要求服務器不要關閉TCP連接,close表示明確要求關閉連接,默認值是keep-alive; |
Accept-Encoding | 說明自己可以接收的壓縮方式; |
User-Agent | 用戶代理,是服務器能識別客戶端的操作系統及相關信息。作用是幫助服務器區分客戶端,並且針對不同客戶端讓用戶看到不同數據,做不同操作; |
Content-Type | 服務器告訴客戶端數據的格式,常見的值有text/plain,image/jpeg,image/png,video/mp4,application/json,application/zip;這些數據類型總稱爲MIME TYPE; |
Content-Encoding | 服務器數據壓縮方式; |
Transfer-Encoding | chunked表示採用分塊傳輸編碼,有該字段則無需使用Content-Length字段; |
Content-Length | 聲明數據的長度,請求和迴應頭部都可以使用該字段; |
TCP三次握手與四次揮手
Http和Https協議請求時同會通過Tcp三次握手建立Tcp連接。通過三次握手,Client和Server都能確認自己和對方的收發信能力,相當於建立了相互的信任,就可以開始通信了。;
當數據傳輸完畢,需要斷開連接,斷開連接經歷了四次揮手;
字段 | 字段描述 |
---|---|
ACK | 響應標識,1表示響應,連接建立成功之後,所有報文段ACK的值都爲1; |
SYN | 連接標識,1表示建立連接,連接請求和連接接受報文段SYN=1,其他情況都是0; |
FIN | 關閉連接標識,1表示關閉連接,關閉請求和關閉接受報文段FIN=1,其他情況都是0,跟SYN類似; |
seq number | 序號,一個隨機數X,請求報文段中會有該字段,響應報文段沒有; |
ack number | 應答號,值爲請求seq+1,即X+1,除了連接請求和連接接受響應報文段沒有該字段,其他的報文段都有該字段; |
1.TCP的三次握手
第一次握手:Client向Server發送信息後,Server收到信息。Server可確認Client的發信能力和Server的收信能力;
第二次握手:Server向Client發消息,Client收到消息。Server可確認Client的發信能力和收信能力,Client也可確認B的收信能力和發信能力;
第三次握手:Client向Server發送信息,Server接收到消息。Server可確認Client的收信能力和Server的發信能力;
2.三次握手的具體流程
第一次握手:建立連接請求。客戶端發送連接請求報文段,將SYN置1,seq爲隨機數x。然後,客戶端進入SYN_SEND狀態,等待服務器確認;
第二次握手:確認連接請求。服務器收到客戶端的SYN報文段,需要對該請求進行確認,設置ack = x + 1(即客戶端seq+1)。同時自己也要發送SYN請求信息,即SYN置位1,seq=y。服務器將SYN和ACK信息放在一個報文段中,一併發送給客戶端,服務器進入SYN_RECV狀態;
第三次握手:客戶端收到SYN+ACK報文段,將ack設置爲y+1,向服務器發送ACK報文段,這個報文段發送完畢,客戶端和服務券進入ESTABLISHED狀態,完成Tcp三次握手。
3.TCP的四次揮手
第一次揮手:主機1(可以是客戶端或服務器),設置seq和ack向主機2發送一個FIN報文段,此時主機1進入FIN_WAIT_1裝填,表示沒有數據要發送給主機2了;
第二次揮手:主機2收到主機1的FIN報文段,向主機1迴應一個ACK報文段,表示同意關閉請求,主機1進入FIN_WAIT_2狀態;
第三次揮手:主機2向主機1發送FIN報文段,請求關閉連接,主機2進入LAST_ACK狀態;
第四次揮手:主機1收到主機2的FIN報文段,想主機2迴應ACK報文段,然後主機1進入TIME_WAIT狀態;主機2收到主機1的ACK報文段後,關閉連接。此時主機1等待主機2一段時間後,沒有收到回覆,證明主機2已經正常關閉,主機1也關閉連接;
SSL發展史(互聯網加密通信)
1994年NetSpace公司設計SSL協議(Secure Sockets Layout)1.0版本,未發佈;
1995年NetSpace發佈SSL/2.0版本,很快發現有嚴重漏洞;
1996年發佈SSL/3.0版本,得到大規模應用;
1999年,發佈了SSL升級版TLS/1.0版本,目前應用最廣泛的版本;
2006年和2008年,發佈了TLS/1.1版本和TLS/1.2版本;
SSL原理及運行過程
1.SSL原理
SSL/TLS協議基本思路是採用公鑰加密法(最有名的的是RSA加密算法);
大概流程是,客戶端向服務器索要公鑰,然後用公鑰加密信息,服務器收到密文,用自己的私鑰解密;
爲了防止公鑰被篡改,把公鑰放在數字證書中,證書可信則公鑰可信。公鑰加密計算量很大,爲了提高效率,服務端和客戶端都生成對話祕鑰,用它加密信息,而對話祕鑰是對稱加密,速度非常快。公鑰用來機密對話祕鑰。
2.運行過程
1.客戶端給出協議版本號、一個客戶端隨機數A(Client random)以及客戶端支持的加密方式;
2.服務端確認雙方使用的加密方式,並給出數字證書、一個服務器生成的隨機數B(Server random);
3.客戶端確認數字證書有效,生成一個新的隨機數C(Pre-master-secret),使用整數中的公鑰對C加密,發送給服務端;
4.服務端使用自己的私鑰解密出C;
5.客戶端和服務器根據約定的加密方法,使用三個隨機數ABC,生成對話祕鑰,之後的通信都用這個對話祕鑰進行加密;
SSL證書
1.認證級別分類
SSL證書是一個二進制文件,裏面包含經過認證的網站公鑰和一些元數據,需要從經銷商購買。整數有很多樂行,按認證級別分類:
認證級別分類 | 類型描述 |
---|---|
域名認證(DV=Domain Validation) | 最低級別的認證,可以確認申請人擁有這個域名; |
公司認證(OV=Organization Validation) | 確認域名所有人是哪家公司,證書裏面包含公司的信息; |
擴展認證(EV=Extended Validation) | 最高級別認證,瀏覽器地址欄會顯示公司名稱; |
2.覆蓋範圍分類
覆蓋範圍分類 | 類型描述 |
---|---|
單域名證書 | 只能用於單域名,foo.com整數不能用於 www . foo . com; |
通配符證書 | 可用於某個域名及所有一級子域名,比如*.foo.com的整數可用於foo.com,也可用於www . foo . com; |
多域名證書 | 可用於多個域名,比如foo . com和bar . com; |
認證級別越高,覆蓋範圍越廣的證書,價格越貴。也有免費的整數,爲了推廣Https,電子前哨基金會成立了Let’s Encrypt提供免費整數。證書的經銷商也很多,知名度比較高的有亞洲誠信(Trust Asia)。
Https協議/SSL協議
Https協議是以安全爲目標的Http通道,就是安全版的Http;
Http下加入SSL層(現在主流的是SLL/TLS),SSL是Https協議的安全基礎。Https默認端口號爲443.
Http存在的風險
風險種類 | 風險描述 |
---|---|
竊聽風險 | Http採用明文傳輸數據,第三方可以獲知通信內容; |
篡改風險 | 第三方可以修改通信內容; |
冒充風險 | 第三方可以冒充他人身份進行通信; |
SSL/TLS協議是爲了解決這些風險而設計,希望達到:
1.所有信息加密傳輸,三方竊聽通信內容;
2.具有校驗機制,內容一旦被篡改,通信雙方立刻會發現;
3.具備身份整數,防止身份被冒充;
Http和Https的對比
1.Https協議需要到CA申請證書,大多數情況下需要一定費用;
2.Http是超文本傳輸協議,信息採用明文傳輸,Https則是具有安全性SSL加密傳輸協議;
3.Http和Https端口號不一樣,Http是80端口,Https是443端口;
4.Http連接是無狀態的,Https採用Http + SSL構建可進行加密傳輸、身份認證的網絡協議,更安全;
5.Http協議建立連接的過程比Https協議快。因爲Https除了Tcp三次握手,還要經過SSL握手。連接建立之後數據傳輸速度,二者無明顯區別;