網絡結構分層

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握手。連接建立之後數據傳輸速度，二者無明顯區別；

HTTP總結