點擊我的GIT
返回主頁
Kyrie lrving
Life is so short,do something to make yourself happy, such as coding.
新隨筆管理
TCP/IP原理淺析
TCP/IP概述
TCP/IP起源於1969年美國國防部（DOD：The United States Department Of Defense）高級研究項目管理局（APRA:AdvancedResearch Projects Agency）對有關分組交換的廣域網（Packet-Switched wide-area network）科研項目，因此起初的網絡稱爲ARPANET。
1973年TCP（傳輸控制協議）正式投入使用，1981年IP（網際協議）協議投入使用，1983年TCP/IP協議正式被集成到美國加州大學伯克利分校的UNIX版本中，該“網絡版”操作系統適應了當時各大學、機關、企業旺盛的連網需求，因而隨着該免費分發的操作系統的廣泛使用，TCP/IP協議得到了流傳。
TCP/IP技術得到了衆多廠商的支持，不久就有了很多分散的網絡。所有這些單個的TCP/IP網絡都互聯起來稱爲INTERNET。基於TCP/IP協議的Internet已逐步發展成爲當今世界上規模最大、擁有用戶和資源最多的一個超大型計算機網絡，TCP/IP協議也因此成爲事實上的工業標準。IP網絡正逐步成爲當代乃至未來計算機網絡的主流。
TCP/IP概述.png
早在TCP/IP協議出現之前，國際標準化組織（ISO）就提出了開放系統互連（OSI）網絡模型，爲網絡的設計、開發、編程、維護提供了便利的分而治之的思想，其先進性、科學性、實用性是不言而喻的。
TCP/IP協議不是單純的兩個協議，是一組不同層次上的多個協議的組合，常稱爲TCP/IP協議簇或者互聯網協議簇。TCP/IP也是互聯網的事實上的標準，爲實現整個網絡的互聯提供指導。TCP/IP層次組合很難用OSI的七層模型來套用，它是OSI模型的濃縮，將原來的七層模型合併爲四層協議的體系結構，自頂向下分別是應用層、傳輸層、網絡層和網絡接口層，沒有OSI參考模型的會話層和表示層，一般認爲TCP/IP的會話和表示功能是在傳輸層或應用層上完成的。
TCP/IP與OSI模型比較.png
TCP/IP不是一個單獨的協議，而是一個協議簇，是一組不同層次上的多個協議的組合。上面給出了OSI與TCP/IP模型對比、TCP/IP不同層次的協議。
網絡接口層：有時也稱作數據鏈路層或鏈路層，通常包括操作系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節。在TCP/IP協議簇中，鏈路層的協議比較多，它決定了網絡形態，但很多都不是專門爲TCP/IP設計的。常用的鏈路層協議包括：以太網協議、PPP協議、幀中繼協議、ATM等。
網絡層：IP層有時也稱作互連網層，處理分組在網絡中的活動，在底層通信網絡的基礎上，完成路由、尋徑功能，提供主機到主機的連接。IP是盡力傳送的、不可靠的協議。在TCP/IP協議簇中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互連網控制報文協議），ARP/RARP（地址解析/反向地址解析協議），以及IGMP協議（Internet組管理協議）。
傳輸層：主要爲兩臺主機上的應用程序提供端到端的通信。在TCP/IP協議簇中，有兩個不同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議），它們分別承載不同的應用。TCP協議提供可靠的服務，UDP協議提供不可靠但是高效的服務。
應用層：這一層負責具體的應用，比如HTTP訪問、FTP文件傳輸、SMTP/POP3郵件處理等等。幾乎各種不同的TCP/IP實現都會提供下面這些通用的應用程序：遠程登錄（Telnet）、文件傳輸協議（FTP）、簡單郵件傳輸協議（SMTP）、簡單網絡管理協議（SNMP）。
嚴格來講，分層模型的動機就是將各層的功能儘量獨立，每層的功能對另一層來說是透明的，只對通信的另一端負責，爲編程和診斷提供良好的層次隔離，然而實際情況並非如此，首先軟件編程上完全按照分層模型來做編程效率會降低，與其分層，不如按功能實現來模塊化。其次，對於許多功能實現來說，必須實現兩層子間的交互，這又違背了當初的出發點，比如鏈路層在成幀時需要接收端的物理地址，該地址必須由網絡層處理ARP地址解析才行，簡單地將ARP放在那一層都有些牽強。所以說，分層模型對於理解網絡的抽象性是有益處的，它有助於指導網絡入門，但並不是網絡的精髓，只有結合具體的系統分析纔有實際意義。
TCP/IP協議棧.png
在發送端，數據由應用產生，它被封裝在傳輸層的段中，該段再封裝到網絡層報文包中，網絡層報文包再封裝到數據鏈路幀，以便在所選的介質上傳送。當接收端系統接收到數據時，是解封裝過程。當數據沿着協議棧向上傳遞時，首先檢查幀的格式，決定網絡類型，去掉幀的格式，檢查內含的報文包，決定傳輸協議。數據由某個傳輸層處理，最後數據遞交給正確的應用程序。
數據封裝和解封裝過程.png
應用層
在應用層包含了不同類型的應用進程，如：telnet遠程登錄、FTP文件傳輸等。
應用層.png
傳輸層
傳輸層主要爲兩臺主機上的應用程序提供端到端的通信服務。在TCP/IP協議族中，有兩個不同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。
TCP爲兩臺主機提供高可靠性的數據通信。它所做的工作包括把應用程序交給它的數據分成合適的小數據塊（數據段）交給下面的網絡層，確認接收到的分組，設置發送最後確認分組的超時時間等。由於傳輸層提供了高可靠性的端到端的通信服務，因此應用層可以忽略掉所有這些細節。
而另一方面，UDP則爲應用層提供一種非常簡單的服務。它只是把稱作數據報的分組從一臺主機發送到另一臺主機，但並不保證該數據報能到達另一端。任何必需的可靠性必須由應用層來提供。
這兩種傳輸層協議分別在不同的網絡環境與應用場合中有不同的用途。
傳輸層的功能.png
TCP和UDP採用16 bit的端口號來識別不同的應用程序。
網絡服務一般都是通過知名端口號來識別的。例如，對於每個TCP/IP實現來說，FTP服務的TCP端口號都是21，每個Telnet服務的TCP端口號都是23，每個TFTP(簡單文件傳送協議)服務的UDP端口號都是69。任何TCP/IP實現所提供的服務都使用知名的1～1023之間的端口號。這些知名端口號由Internet號碼分配機構（Internet Assigned Numbers Authority, IANA）來管理。現在IANA管理1～1023之間所有的端口號。
大多數TCP/IP實現給臨時端口分配1024～5000之間的端口號。大於5000的端口號是爲其他服務（Internet上並不常用的服務）預留的。
如果仔細檢查這些標準的簡單服務以及其他標準的TCP/IP服務（如Telnet、FTP、SMTP等）的端口號時，我們發現它們都是奇數。這是因爲這些端口號都是從NCP端口號派生出來的（NCP，即網絡控制協議，是ARPANET的傳輸層協議，是TCP的前身）。NCP是單工的，不是全雙工的，因此每個應用程序需要兩個連接，需預留一對奇數和偶數端口號。當TCP和UDP成爲標準的傳輸層協議時，每個應用程序只需要一個端口號，因此就使用了NCP中的奇數。
端口號.png
TCP首部的數據格式，如果不計任選字段，它通常是20個字節。
每個TCP段都包含源端和目的端的端口號，用於尋找發端和收端應用進程。這兩個值加上IP首部中的源端IP地址和目的端IP地址唯一確定一個TCP連接。
序號用來標識從TCP發端向TCP收端發送的數據字節流，它表示在這個報文段中的的第一個數據字節。如果將字節流看作在兩個應用程序間的單向流動，則TCP用序號對每個字節進行計數。序號是32 bit的無符號數。
當建立一個新的連接時，SYN標誌變1。序號字段包含由這個主機選擇的該連接的初始序號ISN（Initial Sequence Number）。因爲SYN標誌消耗了一個序號，該主機要發送數據的第一個字節序號爲這個ISN加1。
確認序號包含發送確認的一端所期望收到的下一個序號。確認序號應當是上次已成功收到數據字節序號加1。只有ACK標誌爲1時確認序號字段纔有效。
發送ACK無需任何額外代價，因爲32 bit的確認序號字段和ACK標誌一樣，總是TCP首部的一部分。因此，我們看到一旦一個連接建立起來，這個字段總是被設置，ACK標誌也總是被設置爲1。
TCP爲應用層提供全雙工服務。這意味數據能在兩個方向上獨立地進行傳輸。因此，連接的每一端必須保持每個方向上的傳輸數據序號。
在TCP首部中有6個code bits 中的多個可同時被設置爲1。含義如下：
URG緊急指針（urgent pointer）有效. ACK確認序號有效。 PSH接收方應該儘快將這個報文段交給應用層。 RST重建連接。 SYN同步序號用來發起一個連接。 FIN發端完成發送任務。
TCP的流量控制由連接的每一端通過聲明的窗口大小來提供。窗口大小爲字節數，窗口大小是一個16 bit字段，因而窗口大小最大爲65535字節。
檢驗和覆蓋了整個的TCP報文段：包括了TCP首部和TCP數據。這是一個強制性的字段，一定是由發端計算和存儲，並由收端進行驗證。
只有當URG標誌置1時緊急指針纔有效。緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。TCP的緊急方式是發送端向另一端發送緊急數據的一種方式。
最常見的可選字段是最長報文大小，又稱爲MSS (Maximum Segment Size)。每個連接方通常都在通信的第一個報文段（爲建立連接而設置SYN標誌的那個段）中指明這個選項。它指明本端所能接收的最大長度的報文段。
TCP報文段中的數據部分是可選的。在一個連接建立和一個連接終止時，雙方交換的報文段僅有TCP首部。如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中，也會發送不帶任何數據的報文段。
TCP傳輸控制協議.png
TCP端口號.png
HOSTA對HOSTZ進行TELNET遠程連接，其中目的端口號爲知名端口號23，源端口號爲1028。源端口號沒有特別的要求，只需保證該端口號在本機上是唯一的就可以了。一般從1023以上找出空閒端口號進行分配。源端端口號又稱作臨時端口號，這是因爲源端口號存在時間很短暫。
多個連接時端口號的使用.png
這是同一主機上多個應用進程同時訪問一個服務的示例。HOST A上具有兩個連接同時訪問HOST Z的TELNET服務，HOST A使用不同的源端口號來區分本機上的不同的應用程序進程。
IP地址和端口號用來唯一地確定數據通訊的連接。
序列號的作用：一方面用於標識數據順序，以便接收者在將其遞交給應用程序前按正確的順序進行裝配；另一方面是消除網絡中的重複報文包，這種現象在網絡擁塞時會出現。
確認號的作用：接收者告訴發送者哪個數據段已經成功接收，並告訴發送者接收者希望接收的下一個字節。
TCP 序號和確認號綜述.png
TCP三次握手/建立連接
TCP是面向連接的傳輸層協議，所謂面向連接就是在真正的數據傳輸開始前要完成連接建立的過程，否則不會進入真正的數據傳輸階段。
TCP的連接建立過程通常被稱爲三次握手（three-way handshake），過程如下：請求端（通常稱爲客戶）發送一個SYN段指明客戶打算連接的服務器的端口，以及初始序號（ISN）。這個SYN段爲報文段1。 服務器發回包含服務器的初始序號的SYN報文段（報文段2）作爲應答。同時，將確認序號設置爲客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將佔用一個序號。 客戶必須將確認序號設置爲服務器的ISN加1以對服務器的SYN報文段進行確認（報文段3）。 這三個報文段完成連接的建立。
發送第一個SYN的一端將執行主動打開（active open）。接收這個SYN併發回下一個SYN的另一端執行被動打開（passive open）
當一端爲建立連接而發送它的SYN時，它爲連接選擇一個初始序號。ISN隨時間而變化，因此每個連接都將具有不同的ISN。RFC 793 [Postel1981c]指出ISN可看作是一個32比特的計數器，每4 ms加1。這樣選擇序號的目的在於防止在網絡中被延遲的分組在以後又被傳送，而導致某個連接的一方對它作錯誤的解釋。
如何進行序號選擇? 在4.4 BSD（和多數的伯克利的實現版）中，系統初始化時初始的發送序號被初始化爲1。這個變量每0.5秒增加64000，並每隔9.5小時又回到0。另外，每次建立一個連接後，這個變量將增加64000。
TCP三次握手.png
TCP四次握手/終止連接
一個TCP連接是全雙工（即數據在兩個方向上能同時傳遞），因此每個方向必須單獨進行關閉。當一方完成它的數據發送任務後就發送一個FIN來終止這個方向連接。當一端收到一個FIN，它必須通知應用層另一端已經終止了那個方向的數據傳送。所以TCP終止連接的過程需要四個過程，稱之爲四次握手過程。
TCP四次握手.png
窗口實際上是一種流量控制的機制。
窗口控制.png
當窗口尺寸是1時，發送一個數據段後必須等待確認纔可以發送下一個數據段，好處是在接收端接收的數據段順序不會出錯，缺點是傳輸速度慢，效率低。
利用大於1的窗口，可以同時發送幾個數據包。當確認返回時，則發送新數據段。在這種方式下，可以提高傳輸效率。一個經過仔細調整的滑動窗口協議可以保持網絡始終充滿數據包，並且可以得到較高的吞吐量。
其優點是傳輸速度快，效率高；缺點是由於TCP靠IP傳輸數據，而IP在傳輸過程中可能會選擇不同的路徑而導致在接收端接收的數據段順序混亂。
UDP用戶報文協議
UDP是一個簡單的面向數據報的傳輸層協議，UDP不提供可靠性，它把應用程序傳給IP層的數據發送出去，但是並不保證它們能到達目的地。UDP和TCP在首部中都有覆蓋它們首部和數據的檢驗和。UDP的檢驗和是可選的，而TCP的檢驗和是必需的。
UDP用戶報文協議.png
兩個傳輸層協議TCP與UDP具有不同的特點，適合在不同的網絡環境及不同的應用需求中使用。
TCP/UDP比較.png
網絡層
網際協議(IP)在RFC 971中定義，它同時被TCP和UDP使用，處於OSI參考模型的網絡層。IP可以被認爲是將數據包從一個主機移動到另一個主機的傳遞機制。因爲它處理傳遞，它必須提供尋址功能。IP提供3種主要的功能：
無連接的，不可靠的傳遞服務
數據包分段和重組
路由功能
ICMP（Internet互連網控制報文協議）是IP協議的附屬協議，主要被用來與其他主機或路由器交換錯誤報文和其他重要信息。儘管ICMP主要被IP使用，但應用程序也可以訪問它，例如我們常用的兩個診斷工具ping和traceroute，都使用了ICMP協議。
ARP（地址解析協議）和RARP（反向地址解析協議）是某些網絡接口（如以太網和令牌環網）使用的特殊協議，用來轉換IP層和網絡接口層使用的地址。
網絡層.png
IP數據包中包含的主要部分如下：
版本：目前的協議版本號是4，因此IP有時也稱作I P v 4。- iOS現已支持IPV6
首部長度：首部長度指的是IP包頭中32 bit的數量，包括任何選項。由於它是一個4比特字段，因此首部最長爲60個字節。普通IP數據報（沒有任何選擇項）字段的值是5，即長度20個字節。
服務類型（TOS）字段：包括一個3 bit的優先權子字段，4 bit的TOS子字段和1 bit未用位但必須置0的子字段。4 bit的TOS分別代表：最小時延、最大吞吐量、最高可靠性和最小費用。4 bit中只能置其中1 bit。如果所有4 bit均爲0，那麼就意味着是一般服務。現在大多數的TCP/IP實現都不支持TOS特性，但是自4.3BSD Reno以後的新版系統都對它進行了設置。另外，新的路由協議如OSPF和IS-IS都能根據這些字段的值進行路由決策。
總長度字段：指整個IP數據包的長度，以字節爲單位。利用首部長度字段和總長度字段，就可以知道IP數據報中數據內容的起始位置和長度。由於該字段長16比特，所以IP數據報最長可達65535字節歡迎使用CSDN-markdown編輯器。儘管可以傳送一個長達65535字節的IP數據包，但是大多數的鏈路層都會對它進行分片。總長度字段是IP首部中必要的內容，因爲一些數據鏈路（如以太網）需要填充一些數據以達到最小長度。儘管以太網的最小幀長爲46字節，但是IP數據可能會更短。如果沒有總長度字段，那麼IP層就不知道46字節中有多少是IP數據包的內容。
標識字段：唯一地標識主機發送的每一份數據包。通常每發送一份報文它的值就會加1樣，物理網絡層一般要限制每次發送數據幀的最大長度。IP把MTU與數據包長度進行比較，如果需要則進行分片。分片可以發生在原始發送端主機上，也可以發生在中間路由器上。把一份IP數據包分片以後，只有到達目的地才進行重新組裝。重新組裝由目的端的IP層來完成，其目的是使分片和重新組裝過程對傳輸層（TCP和UDP）是透明的，即使只丟失一片數據也要重傳整個數據包。
已經分片過的數據包有可能會再次進行分片（可能不止一次）。IP首部中包含的數據爲分片和重新組裝提供了足夠的信息。
對於發送端發送的每份IP數據包來說，其標識字段都包含一個唯一值。該值在數據包分片時被複制到每個片中。標誌字段用其中一個比特來表示“更多的片”除了最後一片外，其他每片都要把該比特置1。
片偏移字段指的是該片偏移原始數據包開始處的位置。當數據包被分片後，每個片的總長度值要改爲該片的長度值。標誌字段中有一個比特稱作“不分片”位。如果將這一比特置1，IP將不對數據報進行分片，在網絡傳輸過程中如果遇到鏈路層的MTU小於數據包的長度時將數據包丟棄併發送一個ICMP差錯報文。
TTL（time-to-live）生存時間：該字段設置了數據包可以經過的最多路由器數。它指定了數據報的生存時間。TTL的初始值由源主機設置（通常爲32或64），一旦經過一個處理它的路由器，它的值就減去1。當該字段的值爲0時，數據報就被丟棄，併發送ICMP報文通知源主機。
協議字段：根據它可以識別是哪個協議向IP傳送數據。
首部檢驗和字段：根據IP首部計算的檢驗和碼。它不對首部後面的數據進行計算。因爲ICMP、IGMP、UDP和TCP在它們各自的首部中均含有同時覆蓋首部和數據效驗和碼。
每一份IP數據報都包含32 bit的源IP地址和目的IP地址。
最後一個字段是任選項，是數據包中的一個可變長的可選信息。這些任選項定義如下：
安全和處理限制（用於軍事領域，詳細內容參見RFC 1108[Kent 1991]）
記錄路徑（讓每個路由器都記下它的IP地址）
時間戳（讓每個路由器都記下它的IP地址和時間）
寬鬆的源站選路（爲數據報指定一系列必須經過的IP地址）
嚴格的源站選路（與寬鬆的源站選路類似，但是要求只能經過指定的這些地址，不能經過其他的地址）。
這些選項很少被使用，並非所有的主機和路由器都支持這些選項。選項字段一直都是以32 bit作爲界限，在必要的時候插入值爲0的填充字節。這樣就保證IP首部始終是32 bit的整數倍。
最後是上層的數據，比如TCP或UDP的數據段。
IP數據包格式.png
由於TCP、UDP、ICMP和IGMP及一些其他的協議都要利用IP傳送數據，因此IP必須在生成的IP首部中加入某種標識，以表明其承載的數據屬於哪一類。爲此，IP在首部中存入一個長度爲8 bit的數值，稱作協議域。
其中1表示爲ICMP協議，2表示爲IGMP協議，6表示爲TCP協議，17表示爲UDP協議。
協議類型字段.png
ICMP是一種集差錯報告與控制於一身的協議。在所有TCP/IP主機上都可實現ICMP。ICMP消息被封裝在IP數據報裏，ICMP經常被認爲是IP層的一個組成部分。它傳遞差錯報文以及其他需要注意的信息。ICMP報文通常被IP層或更高層協議（TCP或UDP）使用。一些ICMP報文把差錯報文返回給用戶進程。
常用的“ping”就是使用的ICMP協議。“ping”這個名字源於聲納定位操作，目的是爲了測試另一臺主機是否可達。該程序發送一份ICMP迴應請求報文給主機，並等待返回ICMP迴應應答。一般來說，如果不能Ping到某臺主機，那麼就不能Telnet或者FTP到那臺主機。反過來，如果不能Telnet到某臺主機，那麼通常可以用Ping程序來確定問題出在哪裏。Ping程序還能測出到這臺主機的往返時間，以表明該主機離我們有“多遠”。
然而隨着Internet安全意識的增強，出現了提供訪問控制列表的路由器和防火牆，那麼像這樣沒有限定的斷言就不再成立了。一臺主機的可達性可能不只取決於IP層是否可達，還取決於使用何種協議以及端口號。
ICMP.png
數據鏈路層協議如以太網或令牌環網都有自己的尋址機制（常常爲48 bit地址），這是使用數據鏈路的任何網絡層都必須遵從的。當一臺主機把以太網數據幀發送到位於同一局域網上的另一臺主機時，是根據48 bit的以太網地址來確定目的接口的。設備驅動程序從不檢查IP數據報中的目的IP地址。
ARP協議需要爲IP地址和MAC地址這兩種不同的地址形式提供對應關係。
ARP過程如下：ARP發送一份稱作ARP請求的以太網數據幀給以太網上的每個主機。這個過程稱作廣播，ARP請求數據幀中包含目的主機的IP地址，其意思是“如果你是這個IP地址的擁有者，請回答你的硬件地址。
連接到同一LAN的所有主機都接收並處理ARP廣播，目的主機的ARP層收到這份廣播報文後，根據目的IP地址判斷出這是發送端在尋問它的MAC地址。於是發送一個單播ARP應答。這個ARP應答包含IP地址及對應的硬件地址。收到ARP應答後，發送端就知道接收端的MAC地址了。
ARP高效運行的關鍵是由於每個主機上都有一個ARP高速緩存。這個高速緩存存放了最近IP地址到硬件地址之間的映射記錄。當主機查找某個IP地址與MAC地址的對應關係時首先在本機的ARP緩存表中查找，只有在找不到時才進行ARP廣播。
ARP工作機制.png
具有本地磁盤的系統引導時，一般是從磁盤上的配置文件中讀取IP地址。但是無盤工作站或被配置爲動態獲取IP地址的主機則需要採用其他方法來獲得IP地址。
RARP實現過程是主機從接口卡上讀取唯一的硬件地址，然後發送一份RARP請求（一幀在網絡上廣播的數據），請求某個主機（如DHCP服務器或BOOTP服務器）響應該主機系統的IP地址。
DHCP服務器或BOOTP服務器接收到了RARP的請求，爲其分配IP地址等配置信息，並通過RARP迴應發送給源主機。
RARP工作機制.png