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的三次握手

ClientServerSYN seq=xSYN seq=y,ACK=x+1ACK = y+1ClientServer

第一次握手: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主機2FIN seq= x + 2 ACK = y + 1ACK x + 3FIN seq = y + 1ACK = y + 2主機1主機2

第一次揮手:主機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握手。連接建立之後數據傳輸速度,二者無明顯區別;

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章