1. 計算機網絡體系結構
2. http
3. HTTP的緩存機制
4. Https
5. TCP
1. 計算機網絡體系結構
計算機網絡體系是指計算機網絡的各個層級+協議的組合，定義了計算機網絡所能完成的功能。主要分爲三種：
- OSI體系結構
- TCP/IP體系結構
- 五層體系結構
其中五層體系結構融合了TCP/IP和OST體系，更好理解。下面說的就是五層體系結構。
1.1 分層
五層體系從上往下分爲以下幾個層，最終實現端對端的數據傳輸與通信
-
應用層（Http，FTP，DNS,SMTP等）
應用層包含很多協議，定義瞭如何包裝和解析數據，其中最常用的就是Http
-
運輸層（TCP,UDP等）
運輸層有TCP和UDP兩種協議，分別對應可靠和不可靠的運輸，如TCP要提供可靠的傳輸，所以內部要解決如何連接、保證傳輸可靠不丟失數據，調節流量和擁塞控制等。這一層我們一般是和Socket打交道。Socket是一組封裝好的編程調用接口，通過它，能夠直接操作TCP、UDP進行連接的建立等，建立連接時需要指定端口號，這一層指定了數據發送到哪個端口。
-
網絡層（IP等）
這一層主要是ip協議以及一些路由選擇協議等等，這一層指定了數據傳輸到哪個IP地址，中間涉及到一些最優線路、路由選擇算法等等。
-
數據鏈路層（ARP等）
這一層主要了解的就是ARP，它負責把IP地址解析成MAC地址即硬件地址，這樣就找到了對應的唯一的機器。
-
物理層
這一層就是最底層了，提供二進制流傳輸服務，也就是真正通過傳輸介質（有線、無線）傳輸數據
2. HTTP
默認使用80端口
2.1 無連接無狀態
-
無連接
無連接並不是說不需要連接，而是指每次連接只處理一個請求，一次請求處理完成後斷開連接，這個設計主要是爲了減緩服務器壓力，減少連接對服務器資源的佔用。
-
無狀態
每個請求之間是獨立的，也就是說對於之前的請求是沒有記憶的，因此就出現了Cookie，用來保存請求狀態。
2.2 請求報文和響應報文
主要總結一下報文格式
-
請求報文包含幾個部分
- 請求行：請求方法（POST/GET）,請求路徑Url，協議版本等信息
- 請求頭：就是header，裏面都是key-value的組合
- 請求體（GET無請求體）
-
響應報文包含：
- 狀態行：狀態碼、協議版本等
- 響應頭即返回的header
- 響應體：返回的數據
其中GET和POST的區別是，GET沒有請求體，會把請求參數拼接在url後面，而POST則是把請求參數放到body中
3. HTTP的緩存機制
請求靜態資源和H5頁面交互時用的比較多，HTTP的緩存主要由header中的兩個字段來控制的
3.1 Cache-control
- private：只有客戶端可以緩存
- public：客戶端和代理服務器都可以緩存
- max-age：緩存過期時間
- no-cache：需要使用對比緩存來驗證緩存數據
- no-store：不緩存
其中需要着重說一下的：
max-age：只要沒有超過緩存失效的時間則直接使用緩存
no-cache:表示需要使用對比緩存來驗證緩存數據，如果該字段打開，那麼就算緩存沒有失效，也需要發起請求向服務器確認緩存是否更新，是否需要重新請求數據。這裏需要和ETag配合使用，如果服務器資源沒有更新返回304.直接使用本地緩存，如果有更新直接返回結果。
3.2 ETag
用來對比緩存的header字段
當客戶端發送第一次請求時，服務端會下發當前請求資源的識別碼ETag，下次再請求時，客戶端會通過header裏的If-None-Match將這個標識ETag帶上，服務端將客戶端傳來的ETag與最新的ETag進行對比，如果一樣則表示資源沒有更新，直接返回304.
4. Https
衆所周知，Http是明文傳輸，而Https則是加密傳輸的，Https可以簡單的理解爲Http + ssl，默認使用443端口
-
非對稱加密
Https使用了ssl證書進行數據的非對稱加密，客戶端的請求使用ssl公鑰加密，只有服務器端的私鑰才能解開；而服務器使用私鑰加密的數據只有客戶端的公鑰才能解開。 -
客戶端校驗服務器端證書的合法性
-
普通的http請求
這裏需要手動實現X509TrustManager，客戶端進行強校驗，避免中間人攻擊（僞造服務器證書的中間人充當了客戶端的服務器，在中間抓取數據）
-
webview中的http請求
webview中提供了一個回調處理ssl證書，由於一個app加載的內容可能來自很多廠商服務器，所以看情況處理最好，但不應該直接忽略證書校驗。
-
5. TCP
TCP面向連接，提供可靠的數據傳輸，主要通過Socket的api來操作。
5.1 三次握手建立連接
圖後補
-
第一次
客戶端向服務器發送報文，發出請求SYN包(SYN=j),這時客戶端狀態改爲SYN_SEND,等待服務器確認
-
第二次
服務器收到SYN包，服務器端狀態從LISTEN變爲SYNC_SEVD，必須確認客戶端的SYN（ACK=j+1），同時自己也發送一個SYN給客戶端SYN=k
-
第三次
在客戶端收到服務端發送的SYN和ACK包後，客戶端向服務器發送確認包ACK=k+1,該ACK包發送完畢後，，客戶端和服務器都進入ESTABLISHED狀態，完成三次握手
疑問：爲什麼要三次握手，兩次不就好了麼？
- 首先，兩個握手是最基本的，C端發起建立連接請求，S端收到後給C端反饋，這樣C端和S端是可以互相連接成功的。
- 第三次握手主要是爲了防止已經失效的連接請求報文段突然發送到服務器，導致處理失敗。
5.2 四次握手斷開連接
圖後補，四次揮手和三次握手其實流程上是一樣的，只不過，第二步分成了兩步來完成。
由於TCP連接是全雙工的，因此每個方向必須進行單獨關閉：當一方完成它的數據發送任務後就發送一個FIN來終止這個方向的連接，當收到一個FIN就意味着上游不會再有數據發送，一個TCP連接在收到FIN後仍能發送數據，首先關閉的一方執行主動關閉，而另一方執行被動關閉。
- 客戶端發送一個FIN，用來關閉客戶端到服務器的數據傳送
- 服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號+1，和SYN一樣，一個FIN佔一個序號
- 服務器關閉和客戶端的連接，發送一個FIN給客戶端
- 客戶端發回ACK報文確認，並將確認序號+1