全面瞭解TCP/IP到HTTP

1、OSI參考模型

OSI（Open System Interconnect），即開放式系統互聯。通常都叫OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網絡互聯模型。該體系結構標準定義了網絡互連的七層框架（物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層），即ISO開放系統互連參考模型。在這一框架下進一步詳細規定了每一層的功能，以實現開放系統環境中的互連性、互操做性和應用的可移植性。

2、TCP/IP四層協議系統

TCP/IP是一組不一樣層次上的多個協議的組合,一般被認爲是一個四層協議系統。

• 鏈路層，有時也稱做數據鏈路層或網絡接口層，一般包括操做系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一塊兒處理與電纜（或其餘任何傳輸媒介）的物理接口細節。
• 網絡層，有時也稱做互聯網層，處理分組在網絡中的活動，例如分組的選路。在TCP/IP協議族中，網絡層協議包括IP網際協議，ICMP互聯網控制報文協議，以及IGMP組管理協議。
• 傳輸層，主要爲兩臺主機上的應用程序提供端到端的通訊。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。TCP爲兩臺主機提供高可靠性的數據通訊。它所作的工做包括把應用程序交給它的數據分 成合適的小塊交給下面的網絡層，確認接收到的分組，設置發送最後確認分組的超時時鐘等。因爲傳輸層提供了高可靠性的端到端的通訊，所以應用層能夠忽略全部這些細節。而另外一方面，UDP則爲應用層提供一種很是簡單的服務。它只是把稱做數據報的分組從一臺主機發送到另外一臺主機，但並不保證該數據報能到達另外一端。任何須需的可靠性必須由應用層來提供。這兩種運輸層協議分別在不一樣的應用程序中有不一樣的用途。
• 應用層負責處理特定的應用程序細節。幾乎各類不一樣的TCP/IP實現都會提供這些通用的應用程序：Telnet遠程登陸、FTP文件傳輸協議、SMTP簡單郵件傳送協議、SNMP簡單網絡管理協議。

咱們須要知道TCP在不可靠的IP層上提供了一個可靠的運輸層，這樣就不會在後面介紹IP協議的時候出現模糊，TCP採用了超時重傳、發送和接收端到端的確認分組等機制。

鏈路層

鏈路層協議是Internet協議族中的最底層協議。在TCP/IP協議中，鏈路層主要有三個做用：（1）發送和接收IP數據報（2）發送APR請求和接收APR應答（3）發送RAPR請求和接收RAPR應答。在這裏咱們還須要知道以太網和802封裝，以太網是指數字設備公司在1 9 8 2年聯合公佈的一個標準也是當今 T C P / I P採用的主要的局域網技術，802標準指的是IEEE（電子電氣工程師協會）802委員會公佈的一個稍有不一樣的標準集，802.3標準定義了幀和以太網的幀都有最小長度要求。

1. 串行線路IP（SLIP）

這是一種在串行線路上對IP數據報進行封裝的一種形式，這個協議定義了固定的數據幀格式，規定IP數據報以一個稱做END(0XC0)的特殊字符結束，爲了防止線路噪聲也被當成數據報內容，因此通常在數據報開始的時候也傳入一個END字符；若是IP報文中的某個字符爲END那麼須要連續傳輸兩個字符0xdb和0xdc來取代它，0xdb這個字符被稱做SLIP的ESC字符。SLIP是一種簡單的封裝，它有一些缺陷：每一端必須知道對方的IP地址；一條串行線路若是使用了SLIP協議那麼它將不能同時使用其餘協議；並且SLIP沒用在數據幀加上檢驗，因此說報文因受到影響而發生錯誤只能經過上層協議來發現。在目前SLIP是一種普遍使用的協議。因爲串行線路的速率較低，而且SLIP在性能上也有一些缺陷，後期提出了一個CSLIP（壓縮SLIP）新協議參考RFC 1144。

2. 點對點協議PPP

點對點協議修改了SLIP中的缺陷，PPP既支持數據爲 8位和無奇偶檢驗的異步模式 （如大多數計算機上都廣泛存在的串行接口），還支持面向比特的同步連接；它容許通訊雙方進行協商，以肯定不一樣的選項；容許雙方商定是否對報文首部進行壓縮。PPP協議要比SLIP協議有更多的優勢，可是目前SLIP的用戶仍然要多於PPP用戶。

3. 環回接口

環回接口用來容許運行在同一臺主機上的客戶程序和服務器程序經過TCP/IP進行通訊，A類網絡號127就是爲環回接口預留的。根據慣例，大多數系統把IP地址127.0.0.1分配給這個接口，並命名爲localhost。一個傳給環回接口的IP數據報不能在任何網絡上出現。傳給環回地址（通常是127.0.0.1）的任何數據均做爲IP輸入

4. 最大傳輸單元MTU

咱們知道以太網對數據幀的長度都有一個限制，鏈路層的這個特性被稱爲MTU，不一樣類型的網絡都有一個上限，若是IP層有一個數據報要傳，並且數據的長度比鏈路層的MTU還大，那麼IP層就須要進行分片，把數據報分紅若干片，這樣每一片都小於MTU。當在同一個網絡上的兩臺主機互相進行通訊時，該網絡的MTU是很是重要的。可是若是兩臺主機之間的通訊要經過多個網絡，那麼每一個網絡的鏈路層就可能有不一樣的MTU。重要的不是兩臺主機所在網絡的MTU的值，重要的是兩臺通訊主機路徑中的最小MTU。它被稱做路徑MTU，它取決於所選擇的路由。

---

IP網際協議

IP是網絡層上的主要協議，同時被TCP和UDP使用。TCP和UDP的每組數據都經過端系統和每一箇中間路由器中的IP層在互聯網中進行傳輸。IP協議是TCP/IP協議族中最核心的協議。它是一個不可靠的、無鏈接的協議，TCP、UDP、ICMP以及ICGP都以IP數據報格式傳輸。不可靠的意思是IP僅僅提供最好的傳輸服務，不能保證數據報能成功到達目的地。無鏈接的意思是並不維護任何關於後續數據報的狀態信息，每一個數據報的處理都是相互獨立的，能夠不按發送順序接收。這裏我主要解釋下IP首部各個字段，這也是一個前端須要瞭解的。

1. IP首部

普通的IP首部長爲20個字節（不含選項字段）

首部最高位在左邊，記爲0bit；最低位在右邊，記爲31bit。4個字節的32bit值的傳輸：首先是 0～7 bit，其次8～15bit，而後16～23bit，最後是24~31bit。這種傳輸次序稱做網絡字節序，TCP/IP首部中全部的二進制整數在網絡中傳輸時都要求以這種次序，以其餘形式存儲二進制整數的機器，必須在傳輸數據以前把首部轉換成網絡字節序。目前的協議版本號是4，這也就是咱們常說的IPv4。IP數據報的長度稱爲總長度字段，利用首部長度字段和總長度字段，就能夠知道IP數據報中數據內容的起始位置和長度，通常主機主機要求不能接收超過576字節的數據報，這個限制不會影響到TCP，由於它會把用戶數據分片，總長度字段是IP首部中必要的內容。標識字段惟一地標識主機發送的每一份數據報。一般每發送一份報文它的值就會加1。TTL生存時間字段設置了數據報能夠通過的最多路由器數，初始值由源主機設定，每通過一個處理的路由器它就會減1，該字段爲0時數據報就被丟棄。每一份IP數據報都包含源IP地址和目標IP地址。最後一個字段是任選項，是數據報中的一個可選信息並且長度可變，包括時間戳、寬鬆的源站選路等等。

2. 子網尋址和子網掩碼

目前全部的主機都支持子網編址，不是把IP地址當作由單純的一個網絡號和一個主機號組成，而是把主機號再分紅一個子網號和一個主機號。除了IP地址之外，主機還須要知道有多少比特用於子網號及多少比特用於主機號。這是在引導過程當中經過子網掩碼來肯定的，這個掩碼是一個32bit的值，其中值爲1的比特留給網絡號和子網號，爲0的比特留給主機號，給定IP地址和子網掩碼之後，主機就能夠肯定IP數據報的目標地址，根據子網掩碼可知道子網號與主機號之間的分界線。

ICMP控制報文協議

ICMP常常被認爲是IP層的一個組成部分。它傳遞差錯報文以及其餘須要注意的信息。 ICMP報文一般被IP層或更高層協議（TCP或UDP）使用。全部報文的前4個字節都是同樣的，可是剩下的其餘字節則互不相同，ICMP報文格式(見圖ICMP報文3-1)。不的類型由報文中的類型字段和代碼字段來共同決定。ICMP報文須要區分時候查詢報文仍是差錯報文，並且有時差錯報文須要作特殊處理。

IGMP組管理協議

IGMP組管理協議主要用於用於支持主機和路由器進行多播。IGMP也被看成IP層的一部分，IGMP報文經過IP數據報進行傳輸，有固定的報文長度，沒有可選數據(圖IGMP報文字段)。多播路由器使IGMP報文來記錄與該路由器相連網絡中組成員的變化狀況。

---

UDP用戶數據報協議

UDP是一個簡單的面向數據報的傳輸層協議，進程的每一個輸出操做都正好產生一個 UDP數據報，並組裝成一份待發送的IP數據報。UDP不提供可靠性，它把應用程序傳給 IP層的數據發送出去，可是並不保證它們能到達目的地。

1. UDP首部

端口號表示發送進程和接收進程，UDP長度字段指的是UDP首部和UDP數據的字節長度，UDP檢驗和(可選的)覆蓋UDP首部和UDP數據，如圖所示：

2. UDP數據報最大長度

去除20字節的IP首部和8個字節的UDP首部，UDP數據報中用戶數據的最長長度爲 65507字節。可是，大多數實現所提供的長度比這個最大值小。

TCP傳輸控制協議

TCP提供一種面向鏈接的、可靠的字節流服務。面向鏈接意味着兩個應用在彼此交換數據以前必須先創建一個TCP鏈接。TCP爲應用層提供全雙工服務。

TCP經過下列方式來提供可靠性：應用數據被分割成TCP認爲最適合發送的數據塊；當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段；當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認，這個確認會有一點延遲；TCP將保持它首部和數據的檢驗和；TCP將對收到的數據進行從新排序，將收到的數據以正確的順序交給應用層；TCP還能提供流量控制。

1. TCP首部

TCP數據被封裝在一個IP數據報中(如圖TCP1-1所示)

TCP首部(如圖TCP1-2所示)，若是不計任選字段一般是20個字節。每一個TCP段都包含源端和目的端的端口號，用於尋找發端和收端應用進程。這兩個值加上IP首部中的源端IP地址和目的端IP地址惟一肯定一個TCP鏈接。32位序號用來標識從TCP發送端向TCP接收端發送的數據字節流，它表示在這個報文段中的的第一個數據字節。在TCP首部中有6個標誌比特：URG(緊急指針有效) ACK(確認序號有效) PSH(接收方應該儘快將這個報文段交給應用層) RST(重建鏈接) SYN(同步序號用來發起一個鏈接) FIN(發端完成發送任務)。

檢驗和覆蓋了整個的TCP報文段：TCP首部和TCP數據。這是一個強制性的字段，必定是由發送端計算和存儲，並由接收端進行驗證。只有當URG標誌置1時緊急指針纔有效。

最多見的可選字段是最長報文大小，每一個鏈接方一般都在通訊的第一個報文段中指明這個選項。TCP報文段中的數據部分是可選的，一個鏈接創建和一個鏈接終止時，雙方交換的報文段僅有TCP首部。

2. TCP的三次握手與四次揮手

當創建一個TCP鏈接的時候，經過三個報文段來完成鏈接的創建，這個過程稱爲三次握手。(見圖TCP2-1)

(1)請求端（一般稱爲客戶端）發送一個SYN段指明客戶打算鏈接的服務器的端口，以及初始序號。

(2)服務器發回包含服務器的初始序號的SYN報文段做爲應答。同時，將確認序號設置爲客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將佔用一個序號。

(3)客戶必須將確認序號設置爲服務器的ISN加1以對服務器的SYN報文段進行確認

因爲TCP的半關閉，終止一個鏈接要通過4次握手也就是咱們常說的四次揮手。當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向鏈接。當一端收到一個 FIN，它必須通知應用層另外一端幾經終止了那個方向的數據傳送。發送FIN一般是應用層進行關閉的結果。當客戶端關閉鏈接時將會發送一個FIN，用來關閉從客戶到服務器的數據傳送當服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加 1,同時TCP服務器還向應用程序傳送一個文件結束符,接着這個服務器程序就關閉它的鏈接，致使它的TCP端發送一個FIN，客戶必須發回一個確認，並將確認序號設置爲收到序號加1(見圖TCP2-2)

3. TCP的超時與重傳

TCP提供可靠的運輸層。它使用的方法之一就是確認從另外一端收到的數據。但數據和確認都有可能會丟失。TCP經過在發送時設置一個定時器來解決這種問題。若是當定時器溢出時尚未收到確認，它就重傳該數據。

對每一個鏈接，TCP管理4個不一樣的定時器：(1)重傳定時器使用於當但願收到另外一端的確認。(2)persist定時器使窗口大小信息保持不斷流動，即便另外一端關閉了其接收窗口。(3)keeplive定時器可檢測到一個空閒鏈接的另外一端什麼時候崩潰或重啓。(4)2MSL定時器測量一個鏈接處於TIME_WAIT狀態的時間。

3、互聯網的地址及域名

互聯網上的每一個接口必須有一個惟一的Internet地址（也稱做IP地址）。IP地址長32 bit。Internet地址並不採用平面形式的地址空間，如一、二、3等。IP地址具備必定的結構，五類不一樣的互聯網地址格式以下圖所示。

儘管經過IP地址能夠識別主機上的網絡接口，進而訪問主機，可是人們最喜歡使用的仍是主機名。在TCP/IP領域中，域名系統（DNS）是一個分佈的數據庫，由它來提供IP地址和主機名之間的映射信息。

4、HTTP超文本傳輸協議

HTTP(超文本傳輸協議)是利用TCP在兩臺電腦(一般是Web服務器和客戶端)之間傳輸信息的協議，是一種無狀態的協議，使用URI(統一資源標識符)定位互聯網上的資源。在兩臺計算機之間使用HTTP協議通訊時，在一條通訊線路上一定有一端是客戶端，另外一端則是服務器端。HTTP協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。

HTTP/1.1中的方法

1. GET方法：獲取資源

來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，若是請求的資源是文本，那就保持原樣返回；若是是像CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。

2. POST方法：傳輸實體主體

用來傳輸實體的主體，雖然用GET方法也能夠傳輸實體的主體，但通常不用GET方法進行傳輸，而是用POST方法。雖然說POST的功能與GET很類似，但POST的主要目的並非獲取響應的主體內容。

3. PUT方法：傳輸文件

用來傳輸文件。就像FTP協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求URI指定的位置。存在安全性問題，所以通常的Web網站不使用該方法。

4. HEAD方法：得到報文首部

HEAD方法和GET方法同樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。

5. DELETE方法：刪除文件

用來刪除文件，是與PUT相反的方法。DELETE方法按請求URI刪除指定的資源。一樣存在安全性問題，所以通常的Web網站不使用該方法。

6. OPTIONS方法：詢問支持的方法

用來查詢針對請求 URI 指定的資源支持。

7. TRACE方法:追蹤路徑

讓Web服務器端將以前的請求通訊環回給客戶端。

8. CONNECT方法：要求用隧道協議鏈接代理

要求在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

---

Cookie

HTTP是無狀態協議，它不對以前發生過的請求和響應的狀態，保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了Cookie技術。Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。它會根據從服務器端發送的響應報文內的一個叫作Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。服務器端發現客戶端發送過來的Cookie後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

HTTP狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。藉助狀態碼，用戶能夠知道服務器端是正常處理了請求，仍是出現了錯誤。

狀態碼	類別	緣由
1XX	Informational（信息性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	須要進行附加操做以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	服務器沒法處理請求
5XX	Server Error（服務器錯誤狀態碼）	服務器處理請求出錯

HTTP首部字段

HTTP首部字段是構成HTTP報文的要素之一。在客戶端與服務器之間以HTTP協議進行通訊的過程當中，不管是請求仍是響應都會使用首部字段，它給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

HTTP首部字段是由首部字段名和字段值構成的，中間用冒號「:」分隔。HTTP首部字段根據實際用途被分爲如下 4 種類型:

1. 通用首部字段（General Header Fields）

請求報文和響應報文兩方都會使用的首部。

2. 請求首部字段（Request Header Fields）

從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

3. 響應首部字段（Response Header Fields）

從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

4. 實體首部字段（Entity Header Fields）

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

---

HTTP通用首部字段

---

HTTP請求首部字段

---

HTTP響應首部字段

---

HTTP實體首部字段

HTTP報文結構

用於HTTP協議交互的信息被稱爲HTTP報文。請求端（客戶端）的HTTP報文叫作請求報文，響應端（服務器端）的叫作響應報文。HTTP報文自己是由多行數據構成的字符串文本，大體可分爲報文首部和報文主體兩塊。

本文大體介紹了TCP/IP與HTTP，給前端開發人員瞭解，若有興趣可參考專業書籍進行深刻探索，有興趣的還能夠看看TCP服務器設計以及T/TCP還有HTTPS，同時歡迎各位指正、交流！