TCP/IP協議族

TCP/IP協議是Internet最基本的協議。由傳輸層的TCP協議和網絡層的IP協議組成。

TCP負責發現傳輸的問題，一有問題就發出信號，要求從新傳輸，直到全部數據安全正確地傳輸到目的地。而IP是給因特網的每一臺聯網設備規定一個地址。

TCP/IP協議族的分層管理

TCP/IP協議族按層次分別分爲如下4層：應用層、傳輸層、網絡層和數據鏈路層。

應用層

應用層決定了向用戶提供應該服務時通訊的活動。

TCP/IP協議族內預存了各種通用的應用服務。好比，FTP（File Transfer Protocol，文件傳輸協議）和DNS（Domain Name System，域名系統）服務就是其中的兩類。HTTP協議也處於該層。

傳輸層

傳輸層對上層應用層，提供處於網絡鏈接中兩臺計算機之間的數據傳輸。

在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，用戶數據報協議）。

網絡層（又名網絡互連層）

網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（所謂的傳輸路線）到達對方計算機，並把數據包傳送給對方。

與對方計算機之間經過多臺計算機或網絡設備進行傳輸時，網絡層所起的所用就是在衆多的選項內選擇一條傳輸路線。

鏈路層（又名數據鏈路層，網絡接口層）

用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、NIC（Network Interface Card，網絡適配器，即網卡），及光纖等物理可見部分（還包括鏈接器等一切傳輸媒介）。硬件上的範疇均在鏈路層的做用範圍以內。

簡單概括下各層的協議：

 

 

TCP/IP通訊傳輸

 

 

UDP協議：

詳見維基百科：https://zh.wikipedia.org/wiki/用戶數據報協議

UDP(User Datagram Protocol)即用戶數據報協議，，是一個簡單的面向數據報的傳輸層協議，正式規範爲RFC 768。

在TCP/IP模型中，UDP爲網絡層以上和應用層如下提供了一個簡單的接口。UDP只提供數據的不可靠傳遞，它一旦把應用程序發給網絡層的數據發送出去，不保留數據備份。

 

UDP報文結構：　　

優勢——快。 缺點——不可靠、不穩定。

UDP：無鏈接，發送數據以前不須要創建鏈接(TCP須要)。減小了開銷和延時。

UDP：面向報文，對IP數據報只作簡單封裝(8字節UDP報頭)。減小報頭開銷。

UDP：沒有阻塞機制，寧願阻塞時丟棄數據不傳，也不阻塞形成延時。

UDP支持一對1、一對多、多對1、多對多通訊。

 

　　UDP與TCP位於同一層，但它無論數據包的順序、錯誤或重發。所以，UDP不被應用於那些使用虛電路的面向鏈接的服務，UDP主要用於那些面向查詢---應答的服務，例如NFS。相對於FTP或Telnet，這些服務須要交換的信息量較小。

　　UDP協議包括：TFTP（簡單文件傳輸協議）、SNMP（簡單網絡管理協議）、DNS（域名解析協議）、NFS、BOOTP。

 

TCP協議：

詳見維基百科：https://zh.wikipedia.org/wiki/傳輸控制協議

TCP(Transmission Control Protocol)傳輸控制協議，相對於UDP，TCP是面向鏈接的、提供可靠的數據傳輸服務。同時也是較UDP開銷較大的、傳輸速度較慢的。

 

區別：

UDP：單個數據報，不用創建鏈接，簡單，不可靠，會丟包，會亂序；

TCP：流式，須要創建鏈接，複雜，可靠 ，有序。

 

TCP報文結構：

 

TCP是點對點的鏈接。一條TCP鏈接只能鏈接兩個端點。

TCP 提供可靠傳輸，無差錯、不丟失、不重複、按順序。

TCP 提供全雙工通訊，容許通訊雙方任什麼時候候都能發送數據，發送方設有發送緩存，接收方設有接收緩存。

TCP 面向字節流 。TCP 並不知道所傳輸的數據的含義，僅把數據看做一連串的字節序列，它也不保證接收方收到的數據塊和發送方發出的數據塊具備大小對應關係。

　

TCP的協議：FTP（文件傳輸協議）、Telnet（遠程登陸協議）、SMTP（簡單郵件傳輸協議）、POP3（和SMTP相對，用於接收郵件）、HTTP協議等。

TCP提供可靠的、面向鏈接的數據傳輸服務。使用TCP通訊以前，須要進行「三次握手」創建鏈接，通訊結束後還要使用「四次揮手」斷開鏈接。

 

TCP協議的三次握手和四次揮手：

 

注：seq:(Sequence Number)：本報文段數據的第一個字節的序號

ack:(Acknowledgment Number)：確認號——指望收到對方下個報文段的第一個數據字節的序號

SYN(synchronize)：請求同步標誌——用於創建和釋放鏈接，當SYN=1時，表示創建鏈接。

ACK(acknowledge)：確認標誌——僅當 ACK=1時確認號字段纔有效。創建 TCP 鏈接後，全部報文段都必須把 ACK 字段置爲 1。

FIN(Finally)：結束標誌——用於釋放鏈接，當 FIN=1，代表發送方已經發送完畢，要求釋放TCP鏈接。

三次握手流程　

1、第一次握手：客戶端向服務器端發送鏈接請求包SYN=1（seq=x），等待服務器迴應；

2、第二次握手：服務器端收到請求包後，將客戶端的請求包SYN=1（seq=x）放入到本身的未鏈接隊列，此時服務器須要發送兩個包給客戶端:

　　（1）向客戶端發送確認本身收到其鏈接請求的確認包ACK=1（ack=x+1），向客戶端代表已知道了其鏈接請求

　　（2）向客戶端發送鏈接詢問請求包SYN=1（seq=y），詢問客戶端是否已經準備好創建鏈接，進行數據通訊；

此時服務器進入SYN_RECV狀態。

3、第三次握手：客戶端收到服務器的包後，知道服務器贊成創建鏈接；向服務器發送鏈接創建的確認包ACK=1（ack=y+1），迴應服務器的SYN（seq=y）告訴服務器，咱們之間已經創建了鏈接，能夠進行數據通訊。

ACK=1（ack=y+1）包發送完畢，服務器收到後，此時服務器與客戶端進入ESTABLISHED狀態，開始進行數據傳送。 

 

爲何要三次握手？

握手的過程其實是在通知對方本身的初始化序號(Initial Sequence Number)，簡稱ISN，也就是上圖中的x和y。x和y會被看成以後傳輸數據的一個依據，以保證TCP報文在傳輸過程當中不會混亂。

解決兩個問題：

一、避免鏈接請求的數據包丟失

假設鏈接途中，客戶端網絡不穩定出現丟包，服務端根據seq=x來肯定客戶端請求到第幾個包。而後告訴客戶端你從第seq=x個包開始發送給我，以前的不用發送了，我這裏有記錄了。

 

2、數據傳輸過程由於網絡併發量很大在某結點被阻塞

傳輸過程由於網絡併發量很大在某結點被阻塞了，Server端將前後收到2次請求，並持續等待兩個Client請求向他發送數據，可是Cient端實際上只有一次請求，而Server端卻有2個響應，極端的狀況可能因爲Client端屢次從新發送請求數據而致使Server端最後創建了N多個響應在等待，於是形成極大的資源浪費！

三次握手的seq與ack肯定了包的順序。客戶端每次請求時，詢問服務端說這是第一號包，服務端收到後告訴客服端下次你給個人只能是二號包（別的都不要），同時給返回到客戶端的包做標記：這是我返回給你的一號包。這樣，出現阻塞時，根據包的序號就知道要響應的是幾號包。

 

四次揮手流程

　　(1)Client向Server發送斷開鏈接請求的報文段，seq=m(m爲Client最後一次向Server發送報文段的最後一個字節序號加1)，Client進入FIN-WAIT-1狀態。

　　(2)Server收到斷開報文段後，向Client發送確認報文段，seq=n(n爲Server最後一次向Client發送報文段的最後一個字節序號加1)，ack=m+1，Server進入CLOSE-WAIT狀態。此時這個TCP鏈接處於半開半閉狀態，Server發送數據的話，Client仍然能夠接收到。

　　(3)Server向Client發送斷開確認報文段，seq=u(u爲半開半閉狀態下Server最後一次向Client發送報文段的最後一個字節序號加1)，ack=m+1，Server進入LAST-ACK狀態。

　　(4)Client收到Server的斷開確認報文段後，向Server發送確認斷開報文，seq=m+1，ack=u+1，Client進入TIME-WAIT狀態。

　　(5)Server收到Client的確認斷開報文，進入CLOSED狀態，斷開了TCP鏈接。

　　(6)Client在TIME-WAIT狀態等待一段時間(時間爲2*MSL((Maximum Segment Life))，確認Client向Server發送的最後一次斷開確認到達(若是沒有到達，Server會重發步驟(3)中的斷開確認報文段給Client，告訴Client你的最後一次確認斷開沒有收到)。若是Client在TIME-WAIT過程當中沒有再次收到Server的報文段，就進入CLOSES狀態。TCP鏈接至此斷開。

 

爲何要四次揮手？

tcp關閉鏈接須要四次握手緣由：TCP鏈接是全雙工通道，須要雙向關閉。

client向server發送關閉請求，表示client再也不發送數據，server響應。此時server端仍然能夠向client發送數據，待server端發送數據結束後，就向client發送關閉請求，而後client確認。