IP,TCP和HTTP
? 可以參考OSI模型定義了七層結(jié)構(gòu)。
? 著重探討特殊的混合模式：基于IP的TCP器腋，以及基于TCP實現(xiàn)的HTTP溪猿。這個是我們每天app的基本網(wǎng)絡(luò)配置。
? 其實在互聯(lián)網(wǎng)上傳遞數(shù)據(jù)的方式并不只 HTTP 一種纫塌。HTTP 之所以被廣泛使用的原因是其非常穩(wěn)定诊县、易用，即便是防火墻一般也是允許 HTTP 協(xié)議穿透的
IP Header
一個IP數(shù)據(jù)包通常包含header（報頭信息）和payload（有效載荷）措左。
payload中的內(nèi)容既是要傳輸?shù)恼嬲男畔⒁廊鴋eader承載的是與傳輸數(shù)據(jù)有關(guān)的元數(shù)據(jù)（metadata）。
Header長度為20字節(jié)
header信息中最關(guān)鍵的是源和目標IP地址怎披。
Fragmentation（數(shù)據(jù)分片）
由于底部鏈路層對所傳輸?shù)臄?shù)據(jù)幀有最大長度的限制胸嘁，所以有時候我們需要對數(shù)據(jù)進行分片。假如數(shù)據(jù)超出了數(shù)據(jù)的長度而數(shù)據(jù)源沒有啟用對傳輸數(shù)據(jù)包進行分片凉逛，就會收到ICMP(Internet Control Message Protocol性宏，Internet報文控制協(xié)議) 的數(shù)據(jù)幀超長報告信息。
在IPv6中鱼炒，如果數(shù)據(jù)包超限制衔沼，路由會直接丟棄數(shù)據(jù)包并且向發(fā)送源回傳ICMP6的數(shù)據(jù)幀超長報告信息蝌借。源和目標兩端會基于這個特性來路徑MTU（maximum transfer unit）發(fā)現(xiàn),以此尋找兩端之間最大傳輸單元所在的路由昔瞧。找到MTU路由后，僅當上層數(shù)據(jù)包的最小pauload（負載）確實超過了MTU菩佑，IPv6才會進行分片傳輸自晰。對于IPv6下的TCP，這bu不會造成什么問題稍坯。
TCP
TCP是基于IP層的協(xié)議酬荞，但是TCP是可靠的，有序的瞧哟，有錯誤檢查機制的基于字節(jié)流傳輸?shù)膮f(xié)議混巧。
TCP建立的是雙向的連接，通信雙方可以同時進行數(shù)據(jù)的傳輸勤揩。
TCP用不同的端口號來區(qū)分應(yīng)用咧党。（IP地址和端口號）
TCP Segments（TCP報文段）
? 主機之間傳輸?shù)臄?shù)據(jù)流一般先會被分塊，再轉(zhuǎn)化成 TCP 的報文段陨亡，最終會生成 IP 數(shù)據(jù)包中的 payload 載荷數(shù)據(jù)傍衡。
? 每個 TCP 報文段都有 header 信息和對應(yīng)的載荷 payload深员。payload 信息就是待傳輸?shù)臄?shù)據(jù)塊。TCP 報文段的 header 信息中主要包含的是源和目標端口號蛙埂，至于說源和目標的 IP 地址信息則已經(jīng)包含在 IP header 信息中了倦畅。
TCP連接
三次握手
數(shù)據(jù)傳輸
? TCP 將流量控制和其他一系列復雜機制結(jié)合起來進行擁塞控 制。需要處理以下問題：針對丟失的報文采用重發(fā)機制绣的，同時還需要動態(tài)的調(diào)整發(fā)送報文的頻率
終止連接
最終連接會終止（或結(jié)束）叠赐。連接的每一端都會發(fā)送 FIN 標識給另一端來聲明結(jié)束傳輸，接著另一端會對收到 FIN 進行確認屡江。當連接兩端均發(fā)送完各自 FIN 和做出相應(yīng)的確認后燎悍，連接將會徹底關(guān)閉。
HTTPS
Transport Layer Security (安全傳輸層協(xié)議盼理，TLS) 是一種基于 TCP 的加密協(xié)議谈山。它支持兩件事：
傳輸?shù)膬啥丝梢曰ハ囹炞C對方的身份，以及加密所傳輸?shù)臄?shù)據(jù)
基于 TLS 的 HTTP 請求就是 HTTPS宏怔。
基于HTTPS的請求奏路，在網(wǎng)絡(luò)安全方面有顯著的提升。但是請求會比較耗時臊诊。
綜合結(jié)論
有效的適應(yīng)連接
TCP連接容易在兩個時點出現(xiàn)問題：初始設(shè)置鸽粉，以及通過傳輸?shù)淖詈笠徊糠謭笪摹?/p>
建立連接
連接設(shè)置可能會比較耗時。TCP建立連接的過程中需要進行三次握手抓艳。這個過程中本身沒有太多的數(shù)據(jù)需要傳遞触机。但是，對于移動網(wǎng)絡(luò)來說玷或，從手機端向服務(wù)器端發(fā)送一個數(shù)據(jù)包普遍需要 250ms儡首，也就是四分之一秒。推及到三次握手偏友，也就是說在還沒有傳送任何數(shù)據(jù)之前蔬胯，光建立連接就要花費 750ms。
HTTPS 的情況更夸張位他，由于 HTTPS 是基于 TLS 的 HTTP氛濒，而 HTTP 又基于 TCP。TCP 連接就要執(zhí)行三次握手鹅髓，然后到了 TLS 層還會再握手三次舞竿。估算一下，建立一個 HTTPS 連接的耗時至少是創(chuàng)建一個 HTTP 連接的兩倍窿冯。如果 RTT 時間是 500ms（假設(shè)單程 250ms）骗奖，HTTPS 建立連接累計總耗時將達1.5秒。
長連接和管線化
HTTP有兩種策略來解決這些問題。最簡單的是HTTP持久連接重归，也被稱為長連接米愿。具體就是，每當HTTP完成一組請求相應(yīng)之后鼻吮，還會復用相同的TCP連接育苟。而HTTPS會復用同樣的TLS連接：
client sends HTTP request 1 ->
<- server sends HTTP response 1
client sends HTTP request 2 ->
<- server sends HTTP response 2
client sends HTTP request 3 ->
<- server sends HTTP response 3
close connection
第二步就利用了 HTTP 管線 (pipelining) 處理，即允許客戶端利用同樣的連接并行發(fā)送多個請求椎木，也就是說無需等待上一個請求的響應(yīng)完成可以發(fā)下一個請求违柏。這表示能同時處理請求和響應(yīng)，請求處理的順序采用先進先出原則香椎，響應(yīng)結(jié)果會按照請求發(fā)出的順序依次返還給客戶端漱竖。
稍微簡化一下，看起來會是這樣：
open connection
client sends HTTP request 1 ->
client sends HTTP request 2 ->
client sends HTTP request 3 ->
client sends HTTP request 4 ->
<- server sends HTTP response 1
<- server sends HTTP response 2
<- server sends HTTP response 3
<- server sends HTTP response 4
close connection
注意：服務(wù)器發(fā)出的相應(yīng)是實時的畜伐，不會等到接受全部請求才處理馍惹。
可以利用這個特點來提升 TCP 的效率。只需要在建立連接初始階段執(zhí)行握手玛界，而后一直復用同樣的連接万矾，這樣 TCP 就可以最大限度的利用帶寬。此種情況下慎框，擁塞控制也會隨之提升良狈。因為快速重發(fā)機制無法處理的最末四個報文丟失情況只會發(fā)生在使用本連接的最后一個請求－響應(yīng)中，而不是像之前那樣每一個請求－響應(yīng)都需要建立自己的連接笨枯，每個連接中都可能出現(xiàn)最后四個報文丟失的問題薪丁。
本文來源：鏈接
