ip面向無連接？TCP面向連接？HTTP連接方式？

ip協議：網絡層，這一層容易和數據鏈路層混淆，在這里可以把網絡層理解成傳輸的節點，點到點的數據網絡控制。ip是網絡層協議（bai倒數第二層，du最下面一層是數據鏈路層，zhi通過mac地址區分一個鏈路內的不同主機，進行dao送達），作用是通過ip地址（ipv4、ipv6）為傳輸層尋找目標主機並進行數據傳輸，ip就像快遞員，僅僅負責將數據傳遞給全網內的目標地址，其本身並不保持連接狀態。

 

TCP協議：傳輸層，傳輸層的作用是為上層協議提供端到端的可靠和透明的數據傳輸服務。tcp（傳輸控制協議）是一種面向連接的、可靠的傳輸層通信協議，通過檢驗和、序列號、確認應答、重發控制、連接管理以及窗口控制等機制實現可靠性傳輸。tcp的連接管理：在數據通信之前，通過tcp首部發送一個SYN包作為簡歷連接的請求等待確認應答。如果對端發來確認應答，則認為可以進行數據通信。如果對端的確認應答未能到達，就不會進行數據通信。此外，在通信結束時會進行斷開連接的處理（FIN包）。 可以使用TCp首部用於控制的字段管理TCP連接，一個連接的建立與斷開，正常過程至少需要來回發送7個包才能完成。

 

HTTP協議：應用層，其實HTTP再細分，我覺得就是會話層，用會話來理解HTTP的傳輸會更合適。

 

HTTP/0.9時代：短連接
每個HTTP請求都要經歷一次DNS解析、三次握手、傳輸和四次揮手。反復創建和斷開TCP連接的開銷巨大，在現在看來，這種傳輸方式簡直是糟糕透頂。

HTTP/1.0時代：持久連接概念提出
人們認識到短連接的弊端，提出了持久連接的概念，在HTTP/1.0中得到了初步的支持。
持久連接，即一個TCP連接服務多次請求：
客戶端在請求header中攜帶Connection:
Keep-Alive，即是在向服務端請求持久連接。如果服務端接受持久連接，則會在響應header中同樣攜帶Connection:
Keep-Alive，這樣客戶端便會繼續使用同一個TCP連接發送接下來的若干請求。（Keep-Alive的默認參數是[timout=5,
max=100]，即一個TCP連接可以服務至多5秒內的100次請求）

當服務端主動切斷一個持久連接時（或服務端不支持持久連接），則會在header中攜帶Connection: Close，要求客戶端停止使用這一連接。

HTTP/1.1時代：持久連接成為默認的連接方式；提出pipelining概念
HTTP/1.1開始，即使請求header中沒有攜帶Connection: Keep-Alive，傳輸也會默認以持久連接的方式進行。
目前所有的瀏覽器都默認請求持久連接，幾乎所有的HTTP服務端也都默認開啟對持久連接的支持，短連接正式成為過去式。（HTTP/1.1的發布時間是1997年，最后一次對協議的補充是在1999年，我們可以誇張地說：HTTP短連接這個概念已經過時了近20年了。）
同時，持久連接的弊端被提出 —— HOLB（Head of Line Blocking）
即持久連接下一個連接中的請求仍然是串行的，如果某個請求出現網絡阻塞等問題，會導致同一條連接上的后續請求被阻塞。


所以HTTP/1.1中提出了pipelining概念，即客戶端可以在一個請求發送完成后不等待響應便直接發起第二個請求，服務端在返回響應時會按請求到達的順序依次返回，這樣就極大地降低了延遲。

然而pipelining並沒有徹底解決HOLB，為了讓同一個連接中的多個響應能夠和多個請求匹配上，響應仍然是按請求的順序串行返回的。所以pipelining並沒有被廣泛接受，幾乎所有代理服務都不支持pipelining，部分瀏覽器不支持pipelining，支持的大部分也會將其默認關閉。

SPDY和HTTP/2：multiplexing
multiplexing即多路復用，在SPDY中提出，同時也在HTTP/2中實現。
multiplexing技術能夠讓多個請求和響應的傳輸完全混雜在一起進行，通過streamId來互相區別。這徹底解決了holb問題，同時還允許給每個請求設置優先級，服務端會先響應優先級高的請求。

現在Chrome、FireFox、Opera、IE、Safari的最新版本都支持SPDY，Nginx/Apache HTTPD/Jetty/Tomcat等服務端也都提供了對SPDY的支持。
另外，谷歌已經關閉SPDY項目，正式為HTTP/2讓路。可以認為SPDY是HTTP/2的前身和探路者。