IP,TCP和HTTP
? 可以參考OSI模型定義了七層結構。
? 著重探討特殊的混合模式：基于IP的TCP，以及基于TCP實現的HTTP。這個是我們每天app的基本網絡配置。
? 其實在互聯網上傳遞數據的方式并不只 HTTP 一種。HTTP 之所以被廣泛使用的原因是其非常穩定、易用，即便是防火墻一般也是允許 HTTP 協議穿透的
IP Header
一個IP數據包通常包含header（報頭信息）和payload（有效載荷）。
payload中的內容既是要傳輸的真正的信息，而header承載的是與傳輸數據有關的元數據（metadata）。
Header長度為20字節
header信息中最關鍵的是源和目標IP地址。
Fragmentation（數據分片）
由于底部鏈路層對所傳輸的數據幀有最大長度的限制，所以有時候我們需要對數據進行分片。假如數據超出了數據的長度而數據源沒有啟用對傳輸數據包進行分片，就會收到ICMP(Internet Control Message Protocol，Internet報文控制協議) 的數據幀超長報告信息。
在IPv6中，如果數據包超限制，路由會直接丟棄數據包并且向發送源回傳ICMP6的數據幀超長報告信息。源和目標兩端會基于這個特性來路徑MTU（maximum transfer unit）發現,以此尋找兩端之間最大傳輸單元所在的路由。找到MTU路由后，僅當上層數據包的最小pauload（負載）確實超過了MTU，IPv6才會進行分片傳輸。對于IPv6下的TCP，這bu不會造成什么問題。
TCP
TCP是基于IP層的協議，但是TCP是可靠的，有序的，有錯誤檢查機制的基于字節流傳輸的協議。
TCP建立的是雙向的連接，通信雙方可以同時進行數據的傳輸。
TCP用不同的端口號來區分應用。（IP地址和端口號）
TCP Segments（TCP報文段）
? 主機之間傳輸的數據流一般先會被分塊，再轉化成 TCP 的報文段，最終會生成 IP 數據包中的 payload 載荷數據。
? 每個 TCP 報文段都有 header 信息和對應的載荷 payload。payload 信息就是待傳輸的數據塊。TCP 報文段的 header 信息中主要包含的是源和目標端口號，至于說源和目標的 IP 地址信息則已經包含在 IP header 信息中了。
TCP連接
三次握手
數據傳輸
? TCP 將流量控制和其他一系列復雜機制結合起來進行擁塞控 制。需要處理以下問題：針對丟失的報文采用重發機制，同時還需要動態的調整發送報文的頻率
終止連接
最終連接會終止（或結束）。連接的每一端都會發送 FIN 標識給另一端來聲明結束傳輸，接著另一端會對收到 FIN 進行確認。當連接兩端均發送完各自 FIN 和做出相應的確認后，連接將會徹底關閉。
HTTPS
Transport Layer Security (安全傳輸層協議，TLS) 是一種基于 TCP 的加密協議。它支持兩件事：
傳輸的兩端可以互相驗證對方的身份，以及加密所傳輸的數據
基于 TLS 的 HTTP 請求就是 HTTPS。
基于HTTPS的請求，在網絡安全方面有顯著的提升。但是請求會比較耗時。
綜合結論
有效的適應連接
TCP連接容易在兩個時點出現問題：初始設置，以及通過傳輸的最后一部分報文。
建立連接
連接設置可能會比較耗時。TCP建立連接的過程中需要進行三次握手。這個過程中本身沒有太多的數據需要傳遞。但是，對于移動網絡來說，從手機端向服務器端發送一個數據包普遍需要 250ms，也就是四分之一秒。推及到三次握手，也就是說在還沒有傳送任何數據之前，光建立連接就要花費 750ms。
HTTPS 的情況更夸張，由于 HTTPS 是基于 TLS 的 HTTP，而 HTTP 又基于 TCP。TCP 連接就要執行三次握手，然后到了 TLS 層還會再握手三次。估算一下，建立一個 HTTPS 連接的耗時至少是創建一個 HTTP 連接的兩倍。如果 RTT 時間是 500ms（假設單程 250ms），HTTPS 建立連接累計總耗時將達1.5秒。
長連接和管線化
HTTP有兩種策略來解決這些問題。最簡單的是HTTP持久連接，也被稱為長連接。具體就是，每當HTTP完成一組請求相應之后，還會復用相同的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) 處理，即允許客戶端利用同樣的連接并行發送多個請求，也就是說無需等待上一個請求的響應完成可以發下一個請求。這表示能同時處理請求和響應，請求處理的順序采用先進先出原則，響應結果會按照請求發出的順序依次返還給客戶端。
稍微簡化一下，看起來會是這樣：
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
注意：服務器發出的相應是實時的，不會等到接受全部請求才處理。
可以利用這個特點來提升 TCP 的效率。只需要在建立連接初始階段執行握手，而后一直復用同樣的連接，這樣 TCP 就可以最大限度的利用帶寬。此種情況下，擁塞控制也會隨之提升。因為快速重發機制無法處理的最末四個報文丟失情況只會發生在使用本連接的最后一個請求－響應中，而不是像之前那樣每一個請求－響應都需要建立自己的連接，每個連接中都可能出現最后四個報文丟失的問題。
本文來源：鏈接
