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字節。儘管能夠傳送一個長達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