TCP/IP網絡協議

OSI七層模型 

OSI採用了分層的結構化技術，共分七層，物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。 

TCP/IP模型 

OSI模型比較複雜且學術化，因此咱們實際使用的TCP/IP模型，共分4層，鏈路層、網絡層、傳輸層、應用層。兩個模型之間的對應關係如圖所示：

 

 

TCP/IP協議族 

Transmission Control Protocol/Internet Protocol的簡寫，中譯名爲傳輸控制協議/因特網互聯協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。協議採用了4層的層級結構。然而在不少狀況下，它是利用 IP 進行通訊時所必須用到的協議羣的統稱。也就是說，它實際上是個協議家族，由不少個協議組成，而且是在不一樣的層， 是互聯網的基礎通訊架構。 

                      

 

ICMP  控制報文協議  

IGMP  internet組管理協議  

ARP   地址解析協議  

RARP 反向地址轉化協議  

 

TCP/IP 

TCP是面向鏈接的通訊協議，經過三次握手創建鏈接，通信完成時要拆除鏈接，因爲TCP是面向鏈接的因此只能用於端到端的通信。 

TCP提供的是一種可靠的數據流服務，採用「帶重傳的確定確認」技術來實現傳輸的可靠性。TCP還採用一種稱爲「滑動窗口」的方式進行流量控制，所謂窗口實際表示接收能力，用以限制發送方的發送速度。 

若是IP數據包中有已經封好的TCP數據包，那麼IP將把它們向‘上’傳送到TCP層。TCP將包排序並進行錯誤檢查，同時實現虛電路間的鏈接。TCP數據包中包括序號和確認，因此未按照順序收到的包能夠被排序，而損壞的包能夠被重傳。 

TCP將它的信息送到更高層的應用程序，例如Telnet的服務程序和客戶程序。應用程序輪流將信息送回TCP層，TCP層便將它們向下傳送到IP層，設備驅動程序和物理介質，最後到接收方。 

面向鏈接的服務（例如Telnet、FTP、rlogin、X Windows和SMTP）須要高度的可靠性，因此它們使用了TCP。DNS在某些狀況下使用TCP（發送和接收域名數據庫），但使用UDP傳送有關單個主機的信息。 

TCP三次握手 

TCP 提供面向有鏈接的通訊傳輸。面向有鏈接是指在數據通訊開始以前先作好兩端之間的準備工做。 

所謂三次握手是指創建一個 TCP 鏈接時須要客戶端和服務器端總共發送三個包以確認鏈接的創建。在socket編程中，這一過程由客戶端執行connect來觸發。 

第一次握手：客戶端將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給服務器端，客戶端進入SYN_SENT狀態，等待服務器端確認。 

第二次握手：服務器端收到數據包後由標誌位SYN=1知道客戶端請求創建鏈接，服務器端將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給客戶端以確認鏈接請求，服務器端進入SYN_RCVD狀態。 

第三次握手：客戶端收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給服務器端，服務器端檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨後客戶端與服務器端之間能夠開始傳輸數據了。 

 

TCP四次揮手（分手） 

四次揮手即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。 

因爲TCP鏈接是全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉。 

1. 客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。 

2. 服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。 

3. 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。 

4. 服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。 

5. 客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。 

服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。 

 

•   包是全能性術語；​

•   幀用於表示數據鏈路層中包的單位；​

•   片是 IP中數據的單位；​

•   段則表示 TCP 數據流中的信息；​

•   消息是指應用協議中數據的單位

 

 

數據在各層之間的流轉

 

TCP 的可靠性 

在 TCP 中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫作確認應答（ACK）。當發送端將數據發出以後會等待對端的確認應答。若是有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。 

在必定時間內沒有等待到確認應答，發送端就能夠認爲數據已經丟失，並進行重發。由此，即便產生了丟包，仍然可以保證數據可以到達對端，實現可靠傳輸。 

未收到確認應答並不意味着數據必定丟失。也有多是數據對方已經收到，只是返回的確認應答在途中丟失。這種狀況也會致使發送端誤覺得數據沒有到達目的地而重發數據。 

此外，也有可能由於一些其餘緣由致使確認應答延遲到達，在源主機重發數據之後纔到達的狀況也家常便飯。此時，源主機只要按照機制重發數據便可。 

對於目標主機來講，反覆收到相同的數據是不可取的。爲了對上層應用提供可靠的傳輸，目標主機必須放棄重複的數據包。爲此咱們引入了序列號。 

序列號是按照順序給發送數據的每個字節（8位字節）都標上號碼的編號。接收端查詢接收數據 TCP 首部中的序列號和數據的長度，將本身下一步應該接收的序列號做爲確認應答返送回去。經過序列號和確認應答號，TCP 可以識別是否已經接收數據，又可以判斷是否須要接收，從而實現可靠傳輸。 

 

 

 

TCP中的滑動窗口 

發送方和接收方都會維護一個數據幀的序列，這個序列被稱做窗口。發送方的窗口大小由接收方確認，目的是控制發送速度，以避免接收方的緩存不夠大致使溢出，同時控制流量也能夠避免網絡擁塞。 

在TCP 的可靠性的圖中，咱們能夠看到，發送方每發送一個數據接收方就要給發送方一個ACK對這個數據進行確認。只有接收了這個確認數據之後發送方纔能傳輸下個數據。 

存在的問題：若是窗口太小，當傳輸比較大的數據的時候須要不停的對數據進行確認，這個時候就會形成很大的延遲。 

若是窗口過大，咱們假設發送方一次發送100個數據，但接收方只能處理50個數據，這樣每次都只對這50個數據進行確認。發送方下一次仍是發送100個數據，但接受方仍是隻能處理50個數據。這樣就避免了沒必要要的數據來擁塞咱們的鏈路。 

所以，咱們引入了滑動窗口。滑動窗口通俗來說就是一種流量控制技術。 

它本質上是描述接收方的TCP數據報緩衝區大小的數據，發送方根據這個數據來計算本身最多能發送多長的數據，若是發送方收到接收方的窗口大小爲0的TCP數據報，那麼發送方將中止發送數據，等到接收方發送窗口大小不爲0的數據報的到來。 

首先是第一次發送數據這個時候的窗口大小是根據鏈路帶寬的大小來決定的。咱們假設這個時候窗口的大小是3。這個時候接受方收到數據之後會對數據進行確認告訴發送方我下次但願手到的是數據是多少。這裏咱們看到接收方發送的ACK=3(這是發送方發送序列2的回答確認，下一次接收方指望接收到的是3序列信號)。這個時候發送方收到這個數據之後就知道我第一次發送的3個數據對方只收到了2個。就知道第3個數據對方沒有收到。下次在發送的時候就從第3個數據開始發。 

此時窗口大小變成了2 。 

因而發送方發送2個數據。看到接收方發送的ACK是5就表示他下一次但願收到的數據是5，發送方就知道我剛纔發送的2個數據對方收了這個時候開始發送第5個數據。  

這就是滑動窗口的工做機制，當鏈路變好了或者變差了這個窗口還會發生變話，並非第一次協商好了之後就永遠不變了。                  

因此滑動窗口協議，是TCP使用的一種流量控制方法。該協議容許發送方在中止並等待確認前能夠連續發送多個分組。因爲發送方沒必要每發一個分組就停下來等待確認，所以該協議能夠加速數據的傳輸。  

只有在接收窗口向前滑動時（與此同時也發送了確認），發送窗口才有可能向前滑動。     

收發兩端的窗口按照以上規律不斷地向前滑動，所以這種協議又稱爲滑動窗口協議。

 

 

一次完整http請求的過程 

首先進行DNS域名解析（本地瀏覽器緩存、操做系統緩存或者DNS服務器） 

創建 TCP 鏈接 

在HTTP工做開始以前，客戶端首先要經過網絡與服務器創建鏈接，該鏈接是經過 TCP 來完成的，該協議與 IP 協議共同構建 Internet，即著名的 TCP/IP 協議族，所以 Internet 又被稱做是 TCP/IP 網絡。HTTP 是比 TCP 更高層次的應用層協議，根據規則，只有低層協議創建以後，才能進行高層協議的鏈接，所以，首先要創建 TCP 鏈接，通常 TCP 鏈接的端口號是80；  

•  客戶端向服務器發送請求命令 

一旦創建了TCP鏈接，客戶端就會向服務器發送請求命令； 

例如：GET/sample/hello.jsp HTTP/1.1  

•  客戶端發送請求頭信息 

客戶端發送其請求命令以後，還要以頭信息的形式向服務器發送一些別的信息，以後客戶端發送了一空白行來通知服務器，它已經結束了該頭信息的發送；  

•  服務器應答 

客戶端向服務器發出請求後，服務器會客戶端返回響應； 

例如： HTTP/1.1 200 OK 

響應的第一部分是協議的版本號和響應狀態碼  

•  服務器返回響應頭信息 

正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同響應向用戶發送關於它本身的數據及被請求的文檔；  

•  服務器向客戶端發送數據 

服務器向客戶端發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以 Content-Type 響應頭信息所描述的格式發送用戶所請求的實際數據；  

•  服務器關閉 TCP 鏈接 

通常狀況下，一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 鏈接，而後若是客戶端或者服務器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 鏈接在發送後將仍然保持打開狀態，因而，客戶端能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。 

 

 

請求報文結構 

請求報文的首部內容由如下數據組成： 

請求行 —— 包含用於請求的方法、請求 URI 和 HTTP 版本。 

首部字段 —— 包含表示請求的各類條件和屬性的各種首部。（通用首部、請求首部、實體首部以及RFC裏未定義的首部如 Cookie 等） 

 

 

 

 

響應報文結構 

狀態行 —— 包含代表響應結果的狀態碼、緣由短語和 HTTP 版本。 

首部字段 —— 包含表示請求的各類條件和屬性的各種首部。（通用首部、響應首部、實體首部以及RFC裏未定義的首部如 Cookie 等）