TCP/IP詳解學習筆記(1)-基本概念

為什么會有TCP/IP協議

在世界上各地，各種各樣的電腦運行著各自不同的操作系統為大家服務，這些電腦在表達同一種信息的時候所使用的方法是千差萬別。就好像圣經中上帝打亂了各地人的口音，讓他們無法合作一樣。計算機使用者意識到，計算機只是單兵作戰并不會發揮太大的作用。只有把它們聯合起來，電腦才會發揮出它最大的潛力。于是人們就想方設法的用電線把電腦連接到了一起。

但是簡單的連到一起是遠遠不夠的，就好像語言不同的兩個人互相見了面，完全不能交流信息。因而他們需要定義一些共通的東西來進行交流，TCP/IP就是為此而生。TCP/IP不是一個協議，而是一個協議族的統稱。里面包括了IP協議，IMCP協議，TCP協議，以及我們更加熟悉的http、ftp、pop3協議等等。電腦有了這些，就好像學會了外語一樣，就可以和其他的計算機終端做自由的交流了。

TCP/IP協議分層

提到協議分層，我們很容易聯想到ISO-OSI的七層協議經典架構，但是TCP/IP協議族的結構則稍有不同。如圖所示

TCP/IP協議族按照層次由上到下，層層包裝。最上面的就是應用層了，這里面有http，ftp,等等我們熟悉的協議。而第二層則是傳輸層，著名的TCP和UDP協議就在這個層次（不要告訴我你沒用過udp玩星際）。第三層是網絡層，IP協議就在這里，它負責對數據加上IP地址和其他的數據（后面會講到）以確定傳輸的目標。第四層是叫數據鏈路層，這個層次為待傳送的數據加入一個以太網協議頭，并進行CRC編碼，為最后的數據傳輸做準備。再往下則是硬件層次了，負責網絡的傳輸，這個層次的定義包括網線的制式，網卡的定義等等（這些我們就不用關心了，我們也不做網卡），所以有些書并不把這個層次放在tcp/ip協議族里面，因為它幾乎和tcp/ip協議的編寫者沒有任何的關系。發送協議的主機從上自下將數據按照協議封裝，而接收數據的主機則按照協議從得到的數據包解開，最后拿到需要的數據。這種結構非常有棧的味道，所以某些文章也把tcp/ip協議族稱為tcp/ip協議棧。

一些基本的常識

在學習協議之前，我們應該具備一些基本知識。

· ? ? ? ? ? ?互聯網地址(ip地址)

網絡上每一個節點都必須有一個獨立的Internet地址（也叫做IP地址）。現在，通常使用的IP地址是一個32bit的數字，也就是我們常說的IPv4標準，這32bit的數字分成四組，也就是常見的255.255.255.255的樣式。IPv4標準上，地址被分為五類，我們常用的是B類地址。具體的分類請參考其他文檔。需要注意的是IP地址是網絡號+主機號的組合，這非常重要。

· ? ? ? ? ? ?域名系統

域名系統是一個分布的數據庫，它提供將主機名（就是網址啦）轉換成IP地址的服務。

· ? ? ? ? ? ?RFC

RFC是什么？RFC就是tcp/ip協議的標準文檔，在這里我們可以看到RFC那長長的定義列表，現在它一共有4000多個協議的定義，當然，我們所要學習的，也就是那么十幾個協議而已。

· ? ? ? ? ? ?端口號(port)

注意，這個號碼是用在TCP，UDP上的一個邏輯號碼，并不是一個硬件端口，我們平時說把某某端口封掉了，也只是在IP層次把帶有這個號碼的IP包給過濾掉了而已。

· ? ? ? ? ? ?應用編程接口

現在常用的編程接口有socket和TLI。而前面的有時候也叫做“Berkeley socket”，可見Berkeley對于網絡的發展有多大的貢獻。
?

TCP/IP詳解學習筆記(2)-數據鏈路層

數據鏈路層有三個目的：

· ? ? ? ? ? ?為IP模塊發送和 接收IP數據報。
· ? ? ? ? ? ?為ARP模塊發送ARP請求和接收ARP應答。
· ? ? ? ? ? ?為RARP發送RARP請 求和接收RARP應答

ip大家都聽說過。至于ARP和RARP，ARP叫做地址解析協議，是用IP地址換MAC地址的一種協議，而RARP則叫做逆地址解析協議，在tcp/ip協議的后面章節會介紹它們（在局域網里面用ARP協議可以很容易的搞癱瘓網絡哦）

數據鏈路層的協議還是很多的，有我們最常用的以太網（就是平時我們用的網卡）協議，也有不太常見的令牌環，還有FDDI，當然，還有國內現在相當普及的PPP協議（就是adsl寬帶），以及一個loopback協議。

聯系linux里面的ifconfig -a命令，這個命令通常會得到如下的結果

eth0 Link encap:Ethernet HWaddr 00:01:4A:03:5B:ED
inet addr:192.168.11.2 Bcast:192.168.11.255 Mask:255.255.255.0
inet6 addr: fe80::201:4aff:fe03:5bed/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2819 errors:0 dropped:0 overruns:0 frame:0
TX packets:76 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:241609 (235.9 KiB) TX bytes:9596 (9.3 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2713 errors:0 dropped:0 overruns:0 frame:0
TX packets:2713 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3516032 (3.3 MiB) TX bytes:3516032 (3.3 MiB)

其中，eth0就是以太網接口，而lo則是loopback接口。這也說明這個主機在網絡鏈路層上至少支持loopback協議和以太網協議。

以太網（Ether-net）的定是指數字設備公司（ Digital Equipment Corp.）、英特爾公司（Intel Corp.）和Xerox公司在1982年聯合公布的一個標準，這個標準里面使用了一種稱作CSMA/CD的接入方法。而IEEE802提供的標準集802.3(還有一部分定義到了802.2中)也提供了一個CSMA/CD的標準。這兩個標準稍有不同，TCP/IP協議對這種情況的處理方式如下:

· ? ? ? ? ? ?以太網的IP數據報封裝在RFC894中定義，而IEEE802網絡的IP數據報封裝在RFC1042中定義。

· ? ? ? ? ? ?一臺主機一定要能發送和接收RFC894定義的數據報。

· ? ? ? ? ? ?一臺主機可以接收RFC894和RFC1042的封裝格式的混合數據報。

· ? ? ? ? ? ?一臺主機也許能夠發送RFC1042數據報。。如果主機能同時發送兩種類型的分組數 據，那么發送的分組必須是可以設置的，而且默認條件下必須是RFC 894分組。

可見，RFC1042在TCP/IP里面處于一個配角的地位。這兩種不同的數據報格式請參考教材。

ppp(點對點協議)是從SLIP的替代品。他們都提供了一種低速接入的解決方案。而每一種數據鏈路層協議，都有一個MTU（最大傳輸單元）定義，在這個定義下面，如果IP數據報過大，則要進行分片(fragmentation)，使得每片都小于MTU，注意PPP的MTU并不是一個物理定義，而是指一個邏輯定義（個人認為就是用程序控制）。可以用netstat來打印出MTU的結果，比如鍵入netstat -in

Kernel Interface table
Iface ? ? ? MTU Met ? ?RX-OK RX-ERR RX-DRP RX-OVR ? ?TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 ? ? ? 1500 ? 0 ? ? 1774 ? ? ?0 ? ? ?0 ? ? ?0 ? ? ?587 ? ? ?0 ? ? ?0 ? ? ?0 BMRU
lo ? ? ? ?16436 ? 0 ? ? 2667 ? ? ?0 ? ? ?0 ? ? ?0 ? ? 2667 ? ? ?0 ? ? ?0 ? ? ?0 LRU

就可以觀察到eth0的MTU是1500。而lo（環回接口）的MTU則是16436。

最后說說那個環回接口（loopback）。平時我們用127.0.0.1來嘗試自己的機器服務器好使不好使。走的就是這個loopback接口。對于環回接口，有如下三點值得注意:

· ? ? ? ? ? ?傳給環回地址（一般是127.0.0.1）的任何數據均作為I P輸入。
· ? ? ? ? ? ?傳給廣播地址或多播地址的數據報復制一份傳給環回接口，然后送到以太網上。這是 因為廣播傳送和多播傳送的定義包含主機本身。
· ? ? ? ? ? ?任何傳給該主機IP地址的數據均送到環回接口。
這一章還是很簡單的，一般作為了解知識也就足夠了，沒必要摳的那么詳細。

TCP/IP詳解之IP協議ARP協議和RARP協議

　　把這三個協議放到一起學習是因為這三個協議處于同一層，ARP協議用來找到目標主機的Ethernet網卡Mac地址，IP則承載要發送的消息。數據鏈路層可以從ARP得到數據的傳送信息，而從IP得到要傳輸的數據信息。

　　1.IP協議

　　IP協議是TCP/IP協議的核心，所有的TCP，UDP，IMCP，IGCP的數據都以IP數據格式傳輸。要注意的是，IP不是可靠的協議，這是說，IP協議沒有提供一種數據未傳達以后的處理機制--這被認為是上層協議--TCP或UDP要做的事情。所以這也就出現了TCP是一個可靠的協議，而UDP就沒有那么可靠的區別。這是后話，暫且不提

　　1.1.IP協議頭

　　如圖所示

　　挨個解釋它是教科書的活計，我感興趣的只是那八位的TTL字段，還記得這個字段是做什么的么?這個字段規定該數據包在穿過多少個路由之后才會被拋棄(這里就體現出來IP協議包的不可靠性，它不保證數據被送達)，某個ip數據包每穿過一個路由器，該數據包的TTL數值就會減少1，當該數據包的TTL成為零，它就會被自動拋棄。這個字段的最大值也就是255，也就是說一個協議包也就在路由器里面穿行255次就會被拋棄了，根據系統的不同，這個數字也不一樣，一般是32或者是64，Tracerouter這個工具就是用這個原理工作的，tranceroute的-m選項要求最大值是255，也就是因為這個TTL在IP協議里面只有8bit。


　　現在的ip版本號是4，所以也稱作IPv4。現在還有IPv6，而且運用也越來越廣泛了。


　　1.2.IP路由選擇


　　當一個IP數據包準備好了的時候，IP數據包(或者說是路由器)是如何將數據包送到目的地的呢?它是怎么選擇一個合適的路徑來"送貨"的呢?

　　最特殊的情況是目的主機和主機直連，那么主機根本不用尋找路由，直接把數據傳遞過去就可以了。至于是怎么直接傳遞的，這就要靠ARP協議了，后面會講到。


　　稍微一般一點的情況是，主機通過若干個路由器(router)和目的主機連接。那么路由器就要通過ip包的信息來為ip包尋找到一個合適的目標來進行傳遞，比如合適的主機，或者合適的路由。路由器或者主機將會用如下的方式來處理某一個IP數據包


　　如果IP數據包的TTL(生命周期)以到，則該IP數據包就被拋棄。


　　搜索路由表，優先搜索匹配主機，如果能找到和IP地址完全一致的目標主機，則將該包發向目標主機


　　搜索路由表，如果匹配主機失敗，則匹配同子網的路由器，這需要“子網掩碼(1.3.)”的協助。如果找到路由器，則將該包發向路由器。


　　搜索路由表，如果匹配同子網路由器失敗，則匹配同網號(第一章有講解)路由器，如果找到路由器，則將該包發向路由器。


　　搜索陸游表，如果以上都失敗了，就搜索默認路由，如果默認路由存在，則發包


　　如果都失敗了，就丟掉這個包。


　　這再一次證明了，ip包是不可靠的。因為它不保證送達。


　　1.3.子網尋址


　　IP地址的定義是網絡號+主機號。但是現在所有的主機都要求子網編址，也就是說，把主機號在細分成子網號+主機號。最終一個IP地址就成為 網絡號碼+子網號+主機號。例如一個B類地址：210.30.109.134。一般情況下，這個IP地址的紅色部分就是網絡號，而藍色部分就是子網號，綠色部分就是主機號。至于有多少位代表子網號這個問題上，這沒有一個硬性的規定，取而代之的則是子網掩碼，校園網相信大多數人都用過，在校園網的設定里面有一個255.255.255.0的東西，這就是子網掩碼。子網掩碼是由32bit的二進制數字序列,形式為是一連串的1和一連串的0，例如：255.255.255.0(二進制就是11111111.11111111.11111111.00000000)對于剛才的那個B類地址，因為210.30是網絡號，那么后面的109.134就是子網號和主機號的組合，又因為子網掩碼只有后八bit為0，所以主機號就是IP地址的后八個bit，就是134，而剩下的就是子網號碼--109。

　　2. ARP協議

　　還記得數據鏈路層的以太網的協議中，每一個數據包都有一個MAC地址頭么?我們知道每一塊以太網卡都有一個MAC地址，這個地址是唯一的，那么IP包是如何知道這個MAC地址的?這就是ARP協議的工作。

　　ARP(地址解析)協議是一種解析協議，本來主機是完全不知道這個IP對應的是哪個主機的哪個接口，當主機要發送一個IP包的時候，會首先查一下自己的ARP高速緩存(就是一個IP-MAC地址對應表緩存)，如果查詢的IP-MAC值對不存在，那么主機就向網絡發送一個ARP協議廣播包，這個廣播包里面就有待查詢的IP地址，而直接收到這份廣播的包的所有主機都會查詢自己的IP地址，如果收到廣播包的某一個主機發現自己符合條件，那么就準備好一個包含自己的MAC地址的ARP包傳送給發送ARP廣播的主機，而廣播主機拿到ARP包后會更新自己的ARP緩存(就是存放IP-MAC對應表的地方)。發送廣播的主機就會用新的ARP緩存數據準備好數據鏈路層的的數據包發送工作。

　　一個典型的arp緩存信息如下，在任意一個系統里面用“arp -a”命令:

　　Interface: 192.168.11.3 --- 0x2

　　Internet Address Physical Address Type

　　192.168.11.1 00-0d-0b-43-a0-2e dynamic

　　192.168.11.2 00-01-4a-03-5b-ed dynamic

　　都會得到這樣的結果。

　　這樣的高速緩存是有時限的，一般是20分鐘(伯克利系統的衍生系統)。

?TCP/IP詳解學習筆記(4)-ICMP協議，ping和Traceroute

1.IMCP協議介紹

前面講到了，IP協議并不是一個可靠的協議，它不保證數據被送達，那么，自然的，保證數據送達的工作應該由其他的模塊來完成。其中一個重要的模塊就是ICMP(網絡控制報文)協議。

當傳送IP數據包發生錯誤－－比如主機不可達，路由不可達等等，ICMP協議將會把錯誤信息封包，然后傳送回給主機。給主機一個處理錯誤的機會，這 也就是為什么說建立在IP層以上的協議是可能做到安全的原因。ICMP數據包由8bit的錯誤類型和8bit的代碼和16bit的校驗和組成。而前 16bit就組成了ICMP所要傳遞的信息。書上的圖6－3清楚的給出了錯誤類型和代碼的組合代表的意思。

盡管在大多數情況下，錯誤的包傳送應該給出ICMP報文，但是在特殊情況下，是不產生ICMP錯誤報文的。如下

1. ? ? ? ? ICMP差錯報文不會產生ICMP差錯報文（出IMCP查詢報文）（防止IMCP的無限產生和傳送）
2. ? ? ? ? 目的地址是廣播地址或多播地址的IP數據報。
3. ? ? ? ? 作為鏈路層廣播的數據報。
4. ? ? ? ? 不是IP分片的第一片。
5. ? ? ? ? 源地址不是單個主機的數據報。這就是說，源地址不能為零地址、環回地址、廣播地 址或多播地址。

雖然里面的一些規定現在還不是很明白，但是所有的這一切規定，都是為了防止產生ICMP報文的無限傳播而定義的。

ICMP協議大致分為兩類，一種是查詢報文，一種是差錯報文。其中查詢報文有以下幾種用途:
1. ? ? ? ? ping查詢（不要告訴我你不知道ping程序）
2. ? ? ? ? 子網掩碼查詢（用于無盤工作站在初始化自身的時候初始化子網掩碼）
3. ? ? ? ? 時間戳查詢（可以用來同步時間）

而差錯報文則產生在數據傳送發生錯誤的時候。就不贅述了。

2.ICMP的應用--ping

ping可以說是ICMP的最著名的應用，當我們某一個網站上不去的時候。通常會ping一下這個網站。ping會回顯出一些有用的信息。一般的信息如下:

Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255

Ping statistics for 10.4.24.1:
? ? Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
? ? Minimum = 0ms, Maximum = 0ms, Average = 0ms

ping這個單詞源自聲納定位，而這個程序的作用也確實如此，它利用ICMP協議包來偵測另一個主機是否可達。原理是用類型碼為0的ICMP發請 求，受到請求的主機則用類型碼為8的ICMP回應。ping程序來計算間隔時間，并計算有多少個包被送達。用戶就可以判斷網絡大致的情況。我們可以看到， ping給出來了傳送的時間和TTL的數據。我給的例子不太好，因為走的路由少，有興趣地可以ping一下國外的網站比如sf.net，就可以觀察到一些 丟包的現象，而程序運行的時間也會更加的長。
ping還給我們一個看主機到目的主機的路由的機會。這是因為，ICMP的ping請求數據報在每經過一個路由器的時候，路由器都會把自己的ip放到該數 據報中。而目的主機則會把這個ip列表復制到回應icmp數據包中發回給主機。但是，無論如何，ip頭所能紀錄的路由列表是非常的有限。如果要觀察路由， 我們還是需要使用更好的工具，就是要講到的Traceroute(windows下面的名字叫做tracert)。

3.ICMP的應用--Traceroute

Traceroute是用來偵測主機到目的主機之間所經路由情況的重要工具，也是最便利的工具。前面說到，盡管ping工具也可以進行偵測，但是，因為ip頭的限制，ping不能完全的記錄下所經過的路由器。所以Traceroute正好就填補了這個缺憾。

Traceroute的原理是非常非常的有意思，它受到目的主機的IP后，首先給目的主機發送一個TTL=1（還記得TTL是什么嗎？）的UDP(后面就 知道UDP是什么了)數據包，而經過的第一個路由器收到這個數據包以后，就自動把TTL減1，而TTL變為0以后，路由器就把這個包給拋棄了，并同時產生 一個主機不可達的ICMP數據報給主機。主機收到這個數據報以后再發一個TTL=2的UDP數據報給目的主機，然后刺激第二個路由器給主機發ICMP數據 報。如此往復直到到達目的主機。這樣，traceroute就拿到了所有的路由器ip。從而避開了ip頭只能記錄有限路由IP的問題。

有人要問，我怎么知道UDP到沒到達目的主機呢？這就涉及一個技巧的問題，TCP和UDP協議有一個端口號定義，而普通的網絡程序只監控少數的幾個號碼較 小的端口，比如說80,比如說23,等等。而traceroute發送的是端口號>30000(真變態)的UDP報，所以到達目的主機的時候，目的 主機只能發送一個端口不可達的ICMP數據報給主機。主機接到這個報告以后就知道，主機到了，所以，說Traceroute是一個騙子一點也不為過:)

Traceroute程序里面提供了一些很有用的選項，甚至包含了IP選路的選項，請察看man文檔來了解這些，這里就不贅述了。

TCP/IP詳解學習筆記(5)-IP選路，動態選路，和一些細節

1.靜態IP選路

1.1.一個簡單的路由表

選路是IP層最重要的一個功能之一。前面的部分已經簡單的講過路由器是通過何種規則來根據IP數據包的IP地址來選擇路由。這里就不重復了。首先來看看一個簡單的系統路由表。

Destination ? ? Gateway ? ? ? ? Genmask ? ? ? ? Flags Metric Ref ? ?Use Iface
192.168.11.0 ? ?* ? ? ? ? ? ? ? 255.255.255.0 ? U ? ? 0 ? ? ?0 ? ? ? ?0 eth0
169.254.0.0 ? ? * ? ? ? ? ? ? ? 255.255.0.0 ? ? U ? ? 0 ? ? ?0 ? ? ? ?0 eth0
default ? ? ? ? 192.168.11.1 ? ?0.0.0.0 ? ? ? ? UG ? ?0 ? ? ?0 ? ? ? ?0 eth0

對于一個給定的路由器，可以打印出五種不同的flag。

1. ? ? ? ? U表明該路由可用。
2. ? ? ? ? G表明該路由是到一個網關。如果沒有這個標志，說明和Destination是直連的，而相應的Gateway應該直接給出Destination的地址。
3. ? ? ? ? H表明該路由是到一個主機，如果沒有該標志，說明Destination是一個網絡，換句話說Destination就應該寫成一個網絡號和子網號的組合，而不包括主機號(主機號碼處為0)，例如 192.168.11.0
4. ? ? ? ? D表明該路由是為重定向報文創建的
5. ? ? ? ? M該路由已經被重定向報文修改

U沒啥可說的，G說明這是一個網關，如果你要發數據給Destination，IP頭應該寫Destination的IP地址，而數據鏈路層的MAC地址就應該是GateWay的Mac地址了；反之，如果沒有G標志，那么數據鏈路層和IP層的地址應該是對應的。H說明了Destination的性質，如果是H的，則說明該地址是一個完整的地址，既有網絡號又有主機號，那么再匹配的時候就既要匹配網絡號，又要匹配主機號；反之，Destination就代表一個網絡，在匹配的時候只要匹配一下網絡號就可以了。

這樣，IP選路的方式就可以更加具體化了。如下
1. ? ? ? ? 首先用IP地址來匹配那些帶H標志的DestinationIP地址。
2. ? ? ? ? 如果1失敗就匹配那些網絡地址。
3. ? ? ? ? 如果2失敗就發送到Default網關

順便提一下那個GenMask（還記得子網掩碼么），它指定了目的地址的子網號，例如第一條的子網就是11。

1.2.其他有關路由表的知識
一般，我們在配置好一個網絡接口的時候，一個路由就被直接創建好了。當然我們也可以手動添加路由。用route add命令就可以了。
而當一個IP包在某一個路由器的時候發現沒有路由可走，那么該路由器就會給源主機發送“主機不可達”或者“網絡不可達”的ICMP包來報錯。
注意，一般的操作系統默認是沒有路由功能的，這需要自己配置。這些歷史原因就不細說了，

1.3.ICMP的IP重定向報文和路由發現報文
當IP包在某一個地方轉向的時候，都回給發送IP報的源主機一個ICMP重定向報文，而源主機就可以利用這個信息來更新自己的路由表，這樣，隨著網絡通信的逐漸增多，路由表也就越來越完備，數據轉發的速度也會越來越快。我們需要注意的是：
1. ? ? ? ? 重定向報文只能由路由器發出。
2. ? ? ? ? 重定向報文為主機所用，而不是為路由器所用。

在主機引導的時候，一般會發送在網內廣播一個路由請求的ICMP報文，而多個路由器則會回應一個路由通告報文。而且，路由其本身不定期的在網絡內發布路由通告報文，這樣，根據這些報文，每一個主機都會有機會建立自己的路由表而實現網絡通信。路由器在一份通告報文中可以通告多個地址，并且給出每一個地址的優先等級，這個優先等級是該IP作為默認路由的等級，至于怎么算的就不深究了。

路由器一般會在450-600秒的時間間隔內發布一次通告，而一個給定的通告報文的壽命是30分鐘。而主機在引導的時候會每三秒發送一次請求報文，一旦接受到一個有效的通告報文，就停止發送請求報文。

在TCP/IP詳解編寫的時候，只有Solaris2.x支持這兩種報文，大多數系統還不支持這兩種報文。（后面還會講到一些有用的路由報文）

動態選路協議

前面的選路方法叫做靜態選路，簡要地說就是在配置接口的時候，以默認的方式生成路由表項。并通過route來增加表項，或者通過ICMP報文來更新表項（通常在默認方式出錯的情況下）。 而如果上訴三種方法都不能滿足，那么我們就使用動態選路。

動態選路協議是用于動態選路的重要組成部分，但是他們只是使用在路由器之間，相鄰路由器之間互相通信。系統（路有選擇程序）選擇比較合適的路有放到核心路由表中，然后系統就可以根據這個核心路有表找到最合適的網路。也就是說，動態選路是在系統核心網絡外部進行的，它只是用一些選路的策略影響路由表，而不會影響到最后通過路由表選擇路由的那一部分。選路協議有一大類常用的叫做內部網關協議(IGP)，而在IGP中，RIP就是其中最重要的協議。一種新的IGP協議叫做開放最短路經優先(OSPF)協議，其意在取代RIP。另一種最早用在網路骨干網上的IGP協議--HELLO，現在已經不用了。

如今，任何支持動態選路的路由器都必須同時支持OSPF和RIP，還可以選擇性的支持其他的IGP協議。

2.1.Unix選路程序

Unix系統上面通常都有路由守護程序－－routed。還有一個叫做gate。gate所支持的協議要比routed多，routed只是支持RIPv1版本。而gate則支持RIPv1、v2，BGPv1 等等。

2.1.RIP：選路信息協議

它的定義可以在RFC1058內找到，這種協議使用UDP作為載體（也就是UDP的上層協議）。我們最關心的就是RIP其中的一個段，叫做度量的段，這是一個以hop作為計數器（就是以走過多少路由為計數器）的段（IP協議里面也有一個TTL不是么）。這個度量段將最終影響到路由表的建立。參考圖:

一般說來routed要承擔如下的工作：
1. ? ? ? ? 給每一個已知的路由器發送rip請求報文，要求其他路由器給出完整的路由表。這種報文的命令字段為1，地址字段為0，度量地段為16（相當于無窮大）。
2. ? ? ? ? 接受請求，如果接收到剛才的那個請求，就把自己的完整的路由表交給請求者。如果沒有，就處理IP請求表項，把表項中自己有的部分添上跳數，沒有的部分添上16。然后發給請求者。
3. ? ? ? ? 接受回應。更新自己的路由表。使用hop數小的規則。
4. ? ? ? ? 定期更新路由表，一般是30s(真頻繁)給相鄰的路有啟發一次自己的路由表。這種形式可以使廣播形式的。

這個協議看起來會工作的很好，但是，這里面其實有很多隱藏的憂患，比如說RIP沒有子網的概念，比如說環路的危險。而且hop數的上限也限制了網絡的大小。
因此，出現了很多RIPv1的替代品，比如說RIPv2,比如說OSPF。他們都是通過某種策略來影響路由表，所以就不說了。

TCP/IP詳解學習筆記(6)-UDP協議

1.UDP簡要介紹

UDP是傳輸層協議，和TCP協議處于一個分層中，但是與TCP協議不同，UDP協議并不提供超時重傳，出錯重傳等功能，也就是說其是不可靠的協議。

2.UDP協議頭

2.1.UDP端口號

由于很多軟件需要用到UDP協議，所以UDP協議必須通過某個標志用以區分不同的程序所需要的數據包。端口號的功能就在于此，例如某一個UDP程序A在系統中注冊了3000端口，那么，以后從外面傳進來的目的端口號為3000的UDP包都會交給該程序。端口號理論上可以有2^16這么多。因為它的長度是16個bit

2.2.UDP檢驗和

這是一個可選的選項，并不是所有的系統都對UDP數據包加以檢驗和數據(相對TCP協議的必須來說)，但是RFC中標準要求，發送端應該計算檢驗和。

UDP檢驗和覆蓋UDP協議頭和數據，這和IP的檢驗和是不同的，IP協議的檢驗和只是覆蓋IP數據頭，并不覆蓋所有的數據。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而攝制的。偽首部甚至還包含IP地址這樣的IP協議里面都有的信息，目的是讓UDP兩次檢查數據是否已經正確到達目的地。如果發送端沒有打開檢驗和選項，而接收端計算檢驗和有差錯，那么UDP數據將會被悄悄的丟掉（不保證送達），而不產生任何差錯報文。

2.3.UDP長度

UDP可以很長很長，可以有65535字節那么長。但是一般網絡在傳送的時候，一次一般傳送不了那么長的協議（涉及到MTU的問題），就只好對數據分片，當然，這些是對UDP等上級協議透明的，UDP不需要關心IP協議層對數據如何分片，下一個章節將會稍微討論一些分片的策略。

3.IP分片

IP在從上層接到數據以后，要根據IP地址來判斷從那個接口發送數據（通過選路），并進行MTU的查詢，如果數據大小超過MTU就進行數據分片。數據的分片是對上層和下層透明，而數據也只是到達目的地還會被重新組裝，不過不用擔心，IP層提供了足夠的信息進行數據的再組裝。

在IP頭里面，16bit識別號唯一記錄了一個IP包的ID,具有同一個ID的IP片將會被重新組裝；而13位片偏移則記錄了某IP片相對整個包的位置；而這兩個表示中間的3bit標志則標示著該分片后面是否還有新的分片。這三個標示就組成了IP分片的所有信息，接受方就可以利用這些信息對IP數據進行重新組織（就算是后面的分片比前面的分片先到，這些信息也是足夠了）。

因為分片技術在網絡上被經常的使用，所以偽造IP分片包進行流氓攻擊的軟件和人也就層出不窮。

可以用Trancdroute程序來進行簡單的MTU偵測。請參看教材。

3.UDP和ARP之間的交互式用

這是不常被人注意到的一個細節，這是針對一些系統地實現來說的。當ARP緩存還是空的時候。UDP在被發送之前一定要發送一個ARP請求來獲得目的主機的MAC地址，如果這個UDP的數據包足夠大，大到IP層一定要對其進行分片的時候，想象中，該UDP數據包的第一個分片會發出一個ARP查詢請求，所有的分片都輝等到這個查詢完成以后再發送。事實上是這樣嗎？


結果是，某些系統會讓每一個分片都發送一個ARP查詢，所有的分片都在等待，但是接受到第一個回應的時候，主機卻只發送了最后一個數據片而拋棄了其他，這實在是讓人匪夷所思。這樣，因為分片的數據不能被及時組裝，接受主機將會在一段時間內將永遠無法組裝的IP數據包拋棄，并且發送組裝超時的ICMP報文（其實很多系統不產生這個差錯），以保證接受主機自己的接收端緩存不被那些永遠得不到組裝的分片充滿。

4.ICMP源站抑制差錯

當目標主機的處理速度趕不上數據接收的速度，因為接受主機的IP層緩存會被占滿，所以主機就會發出一個“我受不了”的一個ICMP報文。

5.UDP服務器設計

UDP協議的某些特性將會影響我們的服務器程序設計，大致總結如下：
1. ? ? ? ? 關于客戶IP和地址：服務器必須有根據客戶IP地址和端口號判斷數據包是否合法的能力（這似乎要求每一個服務器都要具備）
2. ? ? ? ? 關于目的地址：服務器必須要有過濾廣播地址的能力。
3. ? ? ? ? 關于數據輸入：通常服務器系統的每一個端口號都會和一塊輸入緩沖區對應，進來的輸入根據先來后到的原則等待服務器的處理，所以難免會出現緩沖區溢出的問題，這種情況下，UDP數據包可能會被丟棄，而應用服務器程序本身并不知道這個問題。
4. ? ? ? ? 服務器應該限制本地IP地址，就是說它應該可以把自己綁定到某一個網絡接口的某一個端口上。

TCP/IP詳解學習筆記(7)-廣播和多播，IGMP協議

1.單播，多播，廣播的介紹

1.1.單播(unicast)

單播是說，對特定的主機進行數據傳送。例如給某一個主機發送IP數據包。這時候，數據鏈路層給出的數據頭里面是非常具體的目的地址，對于以太網來 說，就是網卡的MAC地址（不是FF-FF-FF-FF-FF-FF這樣的地址）。現在的具有路由功能的主機應該可以將單播數據定向轉發，而目的主機的網 絡接口則可以過濾掉和自己MAC地址不一致的數據。

1.2.廣播(unicast)

廣播是主機針對某一個網絡上的所有主機發送數據包。這個網絡可能是網絡，可能是子網，還可能是所有的子網。如果是網絡，例如A類網址的廣播就是 netid.255.255.255，如果是子網，則是netid.netid.subnetid.255；如果是所有的子網（B類IP）則是則是 netid.netid.255.255。廣播所用的MAC地址FF-FF-FF-FF-FF-FF。網絡內所有的主機都會收到這個廣播數據，網卡只要把 MAC地址為FF-FF-FF-FF-FF-FF的數據交給內核就可以了。一般說來ARP，或者路由協議RIP應該是以廣播的形式播發的。

1.3.多播(multicast)

可以說廣播是多播的特例，多播就是給一組特定的主機（多播組）發送數據，這樣，數據的播發范圍會小一些(實際上播發的范圍一點也沒有變小)，多播的MAC地址是最高字節的低位為一，例 如01-00-00-00-00-00。多播組的地址是D類IP，規定是224.0.0.0-239.255.255.255。

雖然多播比較特殊，但是究其原理，多播的數據還是要通過數據鏈路層進行MAC地址綁定然后進行發送。所以一個以太網卡在綁定了一個多播IP地址之后，必 定還要綁定一個多播的MAC地址，才能使得其可以像單播那樣工作。這個多播的IP和多播MAC地址有一個對應的算法，在書的p133到p134之間。可以看到 這個對應不是一一對應的，主機還是要對多播數據進行過濾。

個人的看法：廣播和多播的性質是一樣的，路由器會把數據放到局域網里面，然后網卡對這些數據進行過濾，只拿到自己打算要的數據，比如自己感興趣的多 播數據，自己感興趣的組播數據。當一個主機運行了一個處理某一個多播IP的進程的時候，這個進程會給網卡綁定一個虛擬的多播mac地址，并做出來一個多播 ip。這樣，網卡就會讓帶有這個多播mac地址的數據進來，從而實現通信，而那些沒有監聽這些數據的主機就會把這些數據過濾掉，換句話說，多播，是讓主機 的內核輕松了，而網卡，對不起，您就累點吧。

一些文章也印證了這種想法，最明顯的就是局域網監聽的原理、實現與防范

2.一些驗證性實驗

這些實驗并不是很復雜，我們只是要ping一下一般的ip和一個廣播地址。首先我ping一下自己所在的子網的某一臺主機:

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time=1ms TTL=255

可以看到，機器返回的是一臺主機的回應結果，進而推測，如果我ping一個廣播地址呢？結果如下

Reply from 192.168.11.9: bytes=32 time=1ms TTL=255
Reply from 192.168.11.174: bytes=32 time<1ms TTL=64
Reply from 192.168.11.174: bytes=32 time<1ms TTL=64
Reply from 192.168.11.174: bytes=32 time<1ms TTL=64
Reply from 192.168.11.218: bytes=32 time<1ms TTL=64
Reply from 192.168.11.174: bytes=32 time<1ms TTL=64

可以看到，ping返回了一些隨機的ip的結果，這些ip都是與主機在同一子網內的ip。我們可以看到，廣播實際上是給處于子網內的所有ip發信。

再來一個多播的例子，但是要實現這個多播并不容易，因為我不知道網絡內有多少個多播組，就只好利用幾個特殊的多播地址來驗證了。

對于多播地址，有幾個特殊的多播地址被占用，他們是

1. ? ? ? ? 224.0.0.1--該子網內所有的系統組。
2. ? ? ? ? 224.0.0.2--該子網內所有的路由器。
3. ? ? ? ? 224.0.1.1--網絡實現協議NTP專用IP。
4. ? ? ? ? 224.0.0.9--RIPv2專用IP

所以只要ping這幾個IP，就應該能得到一些結果，比如說我ping 224.0.0.2。

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255
Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

我們可以看到，這回ping只返回了一個ip的回應。而這個就是我的網關的地址，這也驗證了224.0.0.2是所有路由器的多播(組播)地址

3.IGMP協議

IGMP的作用在于，讓其他所有需要知道自己處于哪個多播組的主機和路由器知道自己的狀態。一般多播路由器根本不需要知道某一個多播組里面有多少個主機，而只要知道自己的子網內還有沒有處于某個多播組的主機就可以了。只要某一個多播組還有一臺主機，多播路由器就會把數據傳輸出去，這樣，接受方就會通過網卡過濾功能來得到自己想要的數據。為了知道多播組的信息，多播路由器需要定時的發送IGMP查詢，IGMP的格式可以看書，各個多播組里面的主機要根據查詢來回復自己的狀態。路由器來決定有幾個多播組，自己要對某一個多播組發送什么樣的數據。

這種查詢回應數據報的TTL一般是1，而且就算是出錯也不產生ICMP差錯（沒必要）。

TCP/IP詳解學習筆記(9)-TCP協議概述

終于看到了TCP協議，這是TCP/IP詳解里面最重要也是最精彩的部分，要花大力氣來讀。前面的TFTP和BOOTP都是一些簡單的協議，就不寫筆記了，寫起來也沒啥東西。

TCP和UDP處在同一層---運輸層，但是TCP和UDP最不同的地方是，TCP提供了一種可靠的數據傳輸服務，TCP是面向連接的，也就是說，利用TCP通信的兩臺主機首先要經歷一個“撥打電話”的過程，等到通信準備結束才開始傳輸數據，最后結束通話。所以TCP要比UDP可靠的多，UDP是把數據直接發出去，而不管對方是不是在收信，就算是UDP無法送達，也不會產生ICMP差錯報文，這一經時重申了很多遍了。

把TCP保證可靠性的簡單工作原理摘抄如下

· ? ? ? ? ? ?應用數據被分割成TCP認為最適合發送的數據塊。這和UDP完全不同，應用程序產生的 數據報長度將保持不變。由TCP傳遞給IP的信息單位稱為報文段或段（ segment）（參見圖1 - 7）。在1 8.4節我們將看到TCP如何確定報文段的長度。


· ? ? ? ? ? ?當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能 及時收到一個確認，將重發這個報文段。在第21章我們將了解TCP協議中自適應的超時 及重傳策略。

· ? ? ? ? ? ?當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒，這將在1 9.3節討論。

· ? ? ? ? ? ?TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸 過程中的任何變化。如果收到段的檢驗和有差錯， T P將丟棄這個報文段和不確認收到此報文段（希望發端超時并重發）。

· ? ? ? ? ? ?既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段 的到達也可能會失序。如果必要， TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。

· ? ? ? ? ? ?TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。

從這段話中可以看到，TCP中保持可靠性的方式就是超時重發，這是有道理的，雖然TCP也可以用各種各樣的ICMP報文來處理這些，但是這也不是可靠的，最可靠的方式就是只要不得到確認，就重新發送數據報，直到得到對方的確認為止。

TCP的首部和UDP首部一樣，都有發送端口號和接收端口號。但是顯然，TCP的首部信息要比UDP的多，可以看到，TCP協議提供了發送和確認所需要的所有必要的信息。這在P171-173有詳細地介紹。可以想象一個TCP數據的發送應該是如下的一個過程。

· ? ? ? ? ? ?雙方建立連接

· ? ? ? ? ? ?發送方給接受方TCP數據報，然后等待對方的確認TCP數據報，如果沒有，就重新發，如果有，就發送下一個數據報。

· ? ? ? ? ? ?接受方等待發送方的數據報，如果得到數據報并檢驗無誤，就發送ACK(確認)數據報，并等待下一個TCP數據報的到來。直到接收到FIN(發送完成數據報)

· ? ? ? ? ? ?中止連接

可以想見，為了建立一個TCP連接，系統可能會建立一個新的進程（最差也是一個線程），來進行數據的傳送

TCP/IP詳解學習筆記(8)-DNS域名系統

前面已經提到了訪問一臺機器要靠IP地址和MAC地址，其中，MAC地址可以通過ARP協議得到，所以這對用戶是透明的，但是IP地址就不行，無論如何用戶都需要用一個指定的IP來訪問一臺計算機，而IP地址又非常不好記，于是就出現了DNS系統

1.DNS系統介紹

DNS的全稱是Domain Name System。它負責把FQDN(就是以"."分隔結尾的名字)翻譯成一個IP。最初的DNS系統使用的是一個巨大的hosts.txt文件（很吃驚，用 這個就好使了？），可是一段時間以后，開發這就不得不用數據庫來代替hosts.txt文件，最終發展到了現在的分布式數據庫。

從書中的143頁可以看到，DNS系統是一個巨大的樹，最上方有一個無名樹根，下一層是arpa,com,edu,gov,int,mil，us, cn。等等，其中arpa，是域名反解析樹的頂端；而com，edu，等域名本來只用在美國（這就是技術特權啊），但是現在幾乎全世界通用；而us， cn，等叫做國家域。這個樹里面的域名并不是統一管理的，網絡信息中心（NIS）負責分配頂級域合委派其他制定地區域的授權機構。

一個獨立管理的DNS子樹叫做zone，最常見的區域就是二級域名，比如說.com.cn。我們還可以把這個二級域名給劃分成更小的區域，比如說sina.com.cn。

DNS系統是一個分布式的數據庫，當一個數據庫發現自己并沒有某查詢所需要的數據的時候，它將把查詢轉發出去，而轉發的目的地通常是根服務器，根服 務器從上至下層層轉發查詢，直到找到目標為止。DNS還有一個特點就是使用高速緩存，DNS把查詢過的數據緩存在某處，以便于下次查詢時使用。

2.DNS協議

DNS報文定義了一個既可以查詢也可以響應的報文格式。具體格式可以看P145頁。對各個字段簡單解釋如下

1. ? ? ? ? 最前面的16個bit唯一的標示了問題號碼，用于查詢端區別自己的查詢。
2. ? ? ? ? 緊接著的16個bit又可以做進一步的細分，標示了報文的性質和一些細節，比如說是查詢報文還是響應報文，需要遞歸查詢與否（一般服務器都支持遞歸查詢，而且不需要任何設置，BIND就是這樣）
3. ? ? ? ? 查詢問題后面有查詢類型，包括A，NS，CNAME，PTR，HINFO，MX，如果熟悉BIND的話，就知道在zong的配置文件里面，每一條記錄都記載了各自的類型，比如A就是IP地址，NS就是名字服務器。
4. ? ? ? ? 響應報文可以回復多個IP，也就是說，域名可以和多個IP地址對應，并且有很多CNAME。

3.反向查詢

正向查詢指的是通過域名得到IP的查詢，而反向查詢就是通過IP得到域名。例如用host命令，host ip就可以得到服務器的域名，host domainName 就得到IP。

稍微知道一點數據結構的人都能意識到，在正向查詢的域里面做反向查詢，其做法只有遍歷整個數據集合----對于DNS來說，那就是遍歷整個數據庫， 這將帶來巨大的負擔，所以DNS采取了另一種方法，使用另一棵子樹來維護IP-〉域名的對應表。這個子樹的根節點是in-addr.arpa,而一個IP 例如192.168.11.2)所具有的DNS地址就是 2.11.168.192.in-addr.arpa（ip倒置）。在DNS系統里面，一個反向地址對應一個PTR紀錄（對應A紀錄），所以反向查詢又叫 做指針(PTR)查詢。

4.其他問題的討論

4.1.DNS服務器高速緩存

BIND9默認是作為一個高速緩存服務器，其將所有的查詢都轉交到根服務器去，然后得到結果并放在本地的緩沖區，以加快查詢速度。如果有興趣可以安裝一個BIND9來嘗試一下。而自己定義的zone則可以規定其在緩存中的時間，一般是1天（就是配置文件中的1D）。

4.2.用UDP還是TCP

DNS服務器支持TCP和UDP兩種協議的查詢方式，而且端口都是53。而大多數的查詢都是UDP查詢的，一般需要TCP查詢的有兩種情況：

1. ? ? ? ? 當查詢數據多大以至于產生了數據截斷(TC標志為1)，這時，需要利用TCP的分片能力來進行數據傳輸（看TCP的相關章節）。
2. ? ? ? ? 當主（master）服務器和輔（slave）服務器之間通信，輔服務器要拿到主服務器的zone信息的時候。
完

TCP/IP詳解學習筆記(10)-TCP連接的建立與中止

TCP是一個面向連接的協議，所以在連接雙方發送數據之前，都需要首先建立一條連接。這和前面講到的協議完全不同。前面講的所有協議都只是發送數據而已，大多數都不關心發送的數據是不是送到，UDP尤其明顯，從編程的角度來說，UDP編程也要簡單的多----UDP都不用考慮數據分片。

書中用telnet登陸退出來解釋TCP協議連接的建立和中止的過程，可以看到，TCP連接的建立可以簡單的稱為三次握手，而連接的中止則可以叫做四次握手。

1.連接的建立

在建立連接的時候，客戶端首先向服務器申請打開某一個端口(用SYN段等于1的TCP報文)，然后服務器端發回一個ACK報文通知客戶端請求報文收到，客戶端收到確認報文以后再次發出確認報文確認剛才服務器端發出的確認報文（繞口么），至此，連接的建立完成。這就叫做三次握手。如果打算讓雙方都做好準備的話，一定要發送三次報文，而且只需要三次報文就可以了。

可以想見，如果再加上TCP的超時重傳機制，那么TCP就完全可以保證一個數據包被送到目的地。

2.結束連接

TCP有一個特別的概念叫做half-close，這個概念是說，TCP的連接是全雙工（可以同時發送和接收）連接，因此在關閉連接的時候，必須關閉傳和送兩個方向上的連接。客戶機給服務器一個FIN為1的TCP報文，然后服務器返回給客戶端一個確認ACK報文，并且發送一個FIN報文，當客戶機回復ACK報文后（四次握手），連接就結束了。

3.最大報文長度

在建立連接的時候，通信的雙方要互相確認對方的最大報文長度(MSS)，以便通信。一般這個SYN長度是MTU減去固定IP首部和TCP首部長度。對于一個以太網，一般可以達到1460字節。當然如果對于非本地的IP，這個MSS可能就只有536字節，而且，如果中間的傳輸網絡的MSS更佳的小的話，這個值還會變得更小。

4.TCP的狀態遷移圖

書P182頁給出了TCP的狀態圖，這是一個看起來比較復雜的狀態遷移圖，因為它包含了兩個部分---服務器的狀態遷移和客戶端的狀態遷移，如果從某一個角度出發來看這個圖，就會清晰許多，這里面的服務器和客戶端都不是絕對的，發送數據的就是客戶端，接受數據的就是服務器。

4.1.客戶端應用程序的狀態遷移圖


客戶端的狀態可以用如下的流程來表示：


CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED


以上流程是在程序正常的情況下應該有的流程，從書中的圖中可以看到，在建立連接時，當客戶端收到SYN報文的ACK以后，客戶端就打開了數據交互地連接。而結束連接則通常是客戶端主動結束的，客戶端結束應用程序以后，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連接的四次握手。


4.2.服務器的狀態遷移圖


服務器的狀態可以用如下的流程來表示：


CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED


在建立連接的時候，服務器端是在第三次握手之后才進入數據交互狀態，而關閉連接則是在關閉連接的第二次握手以后（注意不是第四次）。而關閉以后還要等待客戶端給出最后的ACK包才能進入初始的狀態。


4.3.其他狀態遷移


書中的圖還有一些其他的狀態遷移，這些狀態遷移針對服務器和客戶端兩方面的總結如下

1. ? ? ? ? LISTEN->SYN_SENT，對于這個解釋就很簡單了，服務器有時候也要打開連接的嘛。

2. ? ? ? ? SYN_SENT->SYN收到，服務器和客戶端在SYN_SENT狀態下如果收到SYN數據報，則都需要發送SYN的ACK數據報并把自己的狀態調整到SYN收到狀態，準備進入ESTABLISHED

3. ? ? ? ? SYN_SENT->CLOSED，在發送超時的情況下，會返回到CLOSED狀態。
4. ? ? ? ? SYN_收到->LISTEN，如果受到RST包，會返回到LISTEN狀態。
5. ? ? ? ? SYN_收到->FIN_WAIT_1，這個遷移是說，可以不用到ESTABLISHED狀態，而可以直接跳轉到FIN_WAIT_1狀態并等待關閉。


4.4.2MSL等待狀態
書中給的圖里面，有一個TIME_WAIT等待狀態，這個狀態又叫做2MSL狀態，說的是在TIME_WAIT2發送了最后一個ACK數據報以后，要進入TIME_WAIT狀態，這個狀態是防止最后一次握手的數據報沒有傳送到對方那里而準備的（注意這不是四次握手，這是第四次握手的保險狀態）。這個狀態在很大程度上保證了雙方都可以正常結束，但是，問題也來了。
由于插口的2MSL狀態（插口是IP和端口對的意思，socket），使得應用程序在2MSL時間內是無法再次使用同一個插口的，對于客戶程序還好一些，但是對于服務程序，例如httpd，它總是要使用同一個端口來進行服務，而在2MSL時間內，啟動httpd就會出現錯誤（插口被使用）。為了避免這個錯誤，服務器給出了一個平靜時間的概念，這是說在2MSL時間內，雖然可以重新啟動服務器，但是這個服務器還是要平靜的等待2MSL時間的過去才能進行下一次連接。

4.5.FIN_WAIT_2狀態

這就是著名的半關閉的狀態了，這是在關閉連接時，客戶端和服務器兩次握手之后的狀態。在這個狀態下，應用程序還有接受數據的能力，但是已經無法發送數據，但是也有一種可能是，客戶端一直處于FIN_WAIT_2狀態，而服務器則一直處于WAIT_CLOSE狀態，而直到應用層來決定關閉這個狀態。

5.RST，同時打開和同時關閉

RST是另一種關閉連接的方式，應用程序應該可以判斷RST包的真實性，即是否為異常中止。而同時打開和同時關閉則是兩種特殊的TCP狀態，發生的概率很小。

6.TCP服務器設計

前面曾經講述過UDP的服務器設計，可以發現UDP的服務器完全不需要所謂的并發機制，它只要建立一個數據輸入隊列就可以。但是TCP不同，TCP服務器對于每一個連接都需要建立一個獨立的進程（或者是輕量級的，線程），來保證對話的獨立性。所以TCP服務器是并發的。而且TCP還需要配備一個呼入連接請求隊列（UDP服務器也同樣不需要），來為每一個連接請求建立對話進程，這也就是為什么各種TCP服務器都有一個最大連接數的原因。而根據源主機的IP和端口號碼，服務器可以很輕松的區別出不同的會話，來進行數據的分發。

掌握本章的狀態遷移圖才是學習本章的關鍵。

TCP/IP詳解學習筆記(11)-TCP交互數據流，成塊數據流

目前建立在TCP協議上的網絡協議特別多，有telnet，ssh，有ftp，有http等等。這些協議又可以根據數據吞吐量來大致分成兩大類：(1)交互數據類型，例如telnet，ssh，這種類型的協議在大多數情況下只是做小流量的數據交換，比如說按一下鍵盤，回顯一些文字等等。(2)數據成塊類型，例如ftp，這種類型的協議要求TCP能盡量的運載數據，把數據的吞吐量做到最大，并盡可能的提高效率。針對這兩種情況，TCP給出了兩種不同的策略來進行數據傳輸。

1.TCP的交互數據流

對于交互性要求比較高的應用，TCP給出兩個策略來提高發送效率和減低網絡負擔：（1）捎帶ACK。(2)Nagle算法（一次盡量多的發數據）。通常，在網絡速度很快的情況下，比如用lo接口進行telnet通信，當按下字母鍵并要求回顯的時候，客戶端和服務器將經歷 發送按鍵數據->服務器發送按鍵數據的ack -> 服務器端發送回顯數據->客戶端發送回顯數據的ACK的過程，而其中的數據流量將是40bit + 41bit+41bit+40bit = 162bit，如果在廣域網里面，這種小分組的TCP流量將會造成很大的網絡負擔。

1.1.捎帶ACK的發送方式
這個策略是說，當主機收到遠程主機的TCP數據報之后，通常不馬上發送ACK數據報，而是等上一個短暫的時間，如果這段時間里面主機還有發送到遠程主機的TCP數據報，那么就把這個ACK數據報“捎帶”著發送出去，把本來兩個TCP數據報整合成一個發送。一般的，這個時間是200ms。可以明顯地看到這個策略可以把TCP數據報的利用率提高很多。

1.2.Nagle算法
上過bbs的人應該都會有感受，就是在網絡慢的時候發貼，有時鍵入一串字符串以后，經過一段時間，客戶端“發瘋”一樣突然回顯出很多內容，就好像數據一下子傳過來了一樣，這就是Nagle算法的作用。

Nagle算法是說，當主機A給主機B發送了一個TCP數據報并進入等待主機B的ACK數據報的狀態時，TCP的輸出緩沖區里面只能有一個TCP數據報，并且，這個數據報不斷地收集后來的數據，整合成一個大的數據報，等到B主機的ACK包一到，就把這些數據“一股腦”的發送出去。雖然這樣的描述有些不準確，但還算形象和易于理解，我們同樣可以體會到這個策略對于低減網絡負擔的好處。

在編寫插口程序的時候，可以通過TCP_NODELAY來關閉這個算法。并且，使用這個算法看情況的，比如基于TCP的X窗口協議，如果處理鼠標事件時還是用這個算法，那么“延遲”可就非常大了。

2.TCP的成塊數據流

對于FTP這樣對于數據吞吐量有較高要求的要求，將總是希望每次盡量多的發送數據到對方主機，就算是有點“延遲”也無所謂。TCP也提供了一整套的策略來支持這樣的需求。TCP協議中有16個bit表示“窗口”的大小，這是這些策略的核心。

2.1.傳輸數據時ACK的問題

在解釋滑動窗口前，需要看看ACK的應答策略，一般來說，發送端發送一個TCP數據報，那么接收端就應該發送一個ACK數據報。但是事實上卻不是這樣，發送端將會連續發送數據盡量填滿接受方的緩沖區，而接受方對這些數據只要發送一個ACK報文來回應就可以了，這就是ACK的累積特性，這個特性大大減少了發送端和接收端的負擔。

2.2.滑動窗口

滑動窗口本質上是描述接受方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報，那么發送方將停止發送數據，等到接受方發送窗口大小不為0的數據報的到來。書中的P211和P212很好的解釋了這一點。

關于滑動窗口協議，書上還介紹了三個術語，分別是：

1. ? ? ? ? 窗口合攏：當窗口從左邊向右邊靠近的時候，這種現象發生在數據被發送和確認的時候。
2. ? ? ? ? 窗口張開：當窗口的右邊沿向右邊移動的時候，這種現象發生在接受端處理了數據以后。
3. ? ? ? ? 窗口收縮：當窗口的右邊沿向左邊移動的時候，這種現象不常發生。

TCP就是用這個窗口，慢慢的從數據的左邊移動到右邊，把處于窗口范圍內的數據發送出去（但不用發送所有，只是處于窗口內的數據可以發送。）。這就是窗口的意義。圖20-6解釋了這一點。窗口的大小是可以通過socket來制定的，4096并不是最理想的窗口大小，而16384則可以使吞吐量大大的增加。

2.3.數據擁塞

上面的策略用于局域網內傳輸還可以，但是用在廣域網中就可能會出現問題，最大的問題就是當傳輸時出現了瓶頸（比如說一定要經過一個slip低速鏈路）所產生的大量數據堵塞問題（擁塞），為了解決這個問題，TCP發送方需要確認連接雙方的線路的數據最大吞吐量是多少。這，就是所謂的擁塞窗口。

擁塞窗口的原理很簡單，TCP發送方首先發送一個數據報，然后等待對方的回應，得到回應后就把這個窗口的大小加倍，然后連續發送兩個數據報，等到對方回應以后，再把這個窗口加倍（先是2的指數倍，到一定程度后就變成現行增長，這就是所謂的慢啟動），發送更多的數據報，直到出現超時錯誤，這樣，發送端就了解到了通信雙方的線路承載能力，也就確定了擁塞窗口的大小，發送方就用這個擁塞窗口的大小發送數據。要觀察這個現象是非常容易的，我們一般在下載數據的時候，速度都是慢慢“沖起來的”

以上就是TCP數據傳輸的大致流程，雖然并不細致，但是足以描述TCP的工作原理，重點是TCP的流量控制原理，滑動窗口，擁塞窗口，ACK累計確認等知識點。

TCP/IP詳解學習筆記(12)-TCP的超時與重傳

超時重傳是TCP協議保證數據可靠性的另一個重要機制，其原理是在發送某一個數據以后就開啟一個計時器，在一定時間內如果沒有得到發送的數據報的ACK報文，那么就重新發送數據，直到發送成功為止。

1.超時

超時時間的計算是超時的核心部分，TCP要求這個算法能大致估計出當前的網絡狀況，雖然這確實很困難。要求精確的原因有兩個：(1)定時長久會造成網絡利用率不高。(2)定時太短會造成多次重傳，使得網絡阻塞。所以，書中給出了一套經驗公式，和其他的保證計時器準確的措施。

1.1.遞推公式概說
最早的TCP曾經用了一個非常簡單的公式來估計當前網絡的狀況，如下
R<-aR+(1-a)M
RTP=Rb
其中a是一個經驗系數為0.1，b通常為2。注意，這是經驗，沒有推導過程，這個數值是可以被修改的。這個公式是說用舊的RTT(R)和新的RTT(M)綜合到一起來考慮新的RTT(R)的大小。但是，我們又看到，這種估計在網絡變化很大的情況下完全不能做出“靈敏的反應”（Jacoboson說的，不是偶說的，呵呵），于是就有下面的修正公式：
Err=M-A
A<-A+gErr
D<-D+h(|Err|-D)
RTO=A+4D

具體的解釋請看書的228頁，這個遞推公式甚至把方差這種統計概念也使用了進來，使得偏差更加的小。而且，必須要指出的是，這兩組公式更新，都是在數據成功傳輸的情況下才進行，在發生數據重新傳輸的情況下，并不使用上面的公式進行網絡估計，理由很簡單，因為程序已經不在正常狀態下了，估計出來的數據也是沒有意義的。

1.2.RTO的初始化

RTO的初始化是由公式決定的，例如最初的公式，初始的值應該是1。而修正公式，初始RTO應該是A+4D。

1.3.RTO的更新

當數據正常傳輸的情況下，我們就會用上面的公式來更新各個數據，并重開定時器，來保證下一個數據被順利傳輸。要注意的是：重傳的情況下，RTO不用上面的公式計算，而采用一種叫做“指數退避”的方式。例如：當RTO為1S的情況下，發生了數據重傳，我們就用RTO=2S的定時器來重新傳輸數據，下一次用4S。一直增加到64S為止。

1.4.估計器的初始化

在這里，SYN用的估計器初始化似乎和傳輸用的估計器不一樣（我也沒有把握）造我的理解，在修正公式中，SYN的情況下，A初始化為0,D初始化為3S。

而在得到傳輸第一個數據的ACK的時候，應該按照下面的公式進行初始化：
A=M+0.5
D=A/2

1.5.估計器的更新
和上面的討論差不多，就是在正常情況下，用上面的公式計算，在重傳的情況下，不更新估計器的各種參數。原因還是因為估計不準確。

1.6.Karn算法
這不算是一個算法，這應該是一個策略，說的就是更新RTO和估計器的值的時機選擇問題，1.3.和1.5.所說得更新時機就是Karn算法。
1.7.計時器的使用
兩句話:
1. ? ? ? ? 一個連接中，有且僅有一個測量定時器被使用。也就是說，如果TCP連續發出3組數據，只有一組數據會被測量。
2. ? ? ? ? ACK數據報不會被測量，原因很簡單，沒有ACK的ACK回應可以供結束定時器測量。

2.重傳

有了超時就要有重傳，但是就算是重傳也是有策略的，而不是將數據簡單的發送。

2.1.重傳時發送數據的大小

前面曾經提到過，數據在傳輸的時候不能只使用一個窗口協議，我們還需要有一個擁塞窗口來控制數據的流量，使得數據不會一下子都跑到網路中引起“擁塞”。也曾經提到過，擁塞窗口最初使用指數增長的速度來增加自身的窗口，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免算法和慢啟動門限就是為此而生。

所謂的慢啟動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免算法，而在門限以內就采用慢啟動算法。所以這個標準才叫做門限，通常，擁塞窗口記做cwnd，慢啟動門限記做ssthresh。下面我們來看看擁塞避免和慢啟動是怎么一起工作的

算法概要(直接從書中拷貝)
1. ? ? ? ? 對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個字節。
2. ? ? ? ? TCP輸出例程的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用 的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網絡擁塞的估 計，而后者則與接收方在該連接上的可用緩存大小有關。
3. ? ? ? ? 當擁塞發生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置為1個報文段（這就是慢啟動）。
4. ? ? ? ? 當新的數據被對方確認時，就增加cwnd，但增加的方法依賴于我們是否正在進行慢啟 動或擁塞避免。如果cwnd小于或等于ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。 慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因為我們記錄了在步驟2 中給我們制造麻煩的窗口大小的一半），然后轉為執行擁塞避免。
補充上面的擁塞避免公式在P238頁。這整個的流程讓我聯想到開車換檔的過程。

2.2.快速重傳和快速恢復算法
這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之后，但是如果發送端接受到3個以上的重復ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，而重新傳遞以后，因為走的不是慢啟動而是擁塞避免算法，所以這又叫做快速恢復算法。流程如下：

1. ? ? ? ? 當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的 報文段。設置cwnd為ssthresh加上3倍的報文段大小。
2. ? ? ? ? 每次收到另一個重復的ACK時， cwnd增加1個報文段大小并發送1個分組（如果新的 cwnd允許發送）。
3. ? ? ? ? 當下一個確認新數據的ACK到達時，設置cwnd為ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳后的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該 是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段的確認。這一步采用的是擁 塞避免，因為當分組丟失時我們將當前的速率減半。

2.3.ICMP會引起重新傳遞么？

答案是：不會，TCP會堅持用自己的定時器，但是TCP會保留下ICMP的錯誤并且通知用戶。

2.4.重新分組

TCP為了提高自己的效率，允許再重新傳輸的時候，只要傳輸包含重傳數據報文的報文就可以，而不用只重傳需要傳輸的報文。
?

TCP/IP詳解學習筆記(13)-TCP堅持定時器，TCP保活定時器

TCP一共有四個主要的定時器，前面已經講到了一個－－超時定時器－－是TCP里面最復雜的一個，另外的三個是：

1. ? ? ? ? 堅持定時器
2. ? ? ? ? 保活定時器
3. ? ? ? ? 2MSL定時器

其中堅持定時器用于防止通告窗口為0以后雙方互相等待死鎖的情況；而保活定時器則用于處理半開放連接

1.堅持定時器

堅持定時器的原理是簡單的，當TCP服務器收到了客戶端的0滑動窗口報文的時候，就啟動一個定時器來計時，并在定時器溢出的時候向向客戶端查詢窗口是否已經增大，如果得到非零的窗口就重新開始發送數據，如果得到0窗口就再開一個新的定時器準備下一次查詢。通過觀察可以得知，TCP的堅持定時器使用1，2，4，8，16……64秒這樣的普通指數退避序列來作為每一次的溢出時間。

糊涂窗口綜合癥

TCP的窗口協議，會引起一種通常叫做糊涂窗口綜合癥的問題，具體表現為，當客戶端通告一個小的非零窗口時，服務器立刻發送小數據給客戶端并充滿其緩沖區，一來二去就會讓網絡中充滿小TCP數據報，從而影響網絡利用率。對于發送方和接收端的這種糊涂行為。TCP給出了一些建議（或者是規定）。

1. ? ? ? ? 接收方不通告小窗口。通常的算法是接收方不通告一個比當前窗口大的窗口（可以為0），
除非窗口可以增加一個報文段大小（也就是將要接收的MSS）或者可以增加接收方緩存空間
的一半，不論實際有多少。

2. ? ? ? ? 發送方避免出現糊涂窗口綜合癥的措施是只有以下條件之一滿足時才發送數據： ( a )可
以發送一個滿長度的報文段； ( b )可以發送至少是接收方通告窗口大小一半的報文段； ( c )可以
發送任何數據并且不希望接收ACK（也就是說，我們沒有還未被確認的數據）或者該連接上
不能使用Nagle算法。

ok，現在我們回憶一下，可以發現TCP的很多規定都是為了在一次傳送中發送盡量多的數據，例如捎帶ACK數據報文的策略，Nagle算法，重傳時發送包含原數據報文的策略，等等。

2.保活定時器

保活定時器更加的簡單，還記得FTP或者Http服務器都有Sesstion Time機制么？因為TCP是面向連接的，所以就會出現只連接不傳送數據的“半開放連接”，服務器當然要檢測到這種連接并且在某些情況下釋放這種連接，這就是保活定時器的作用。其時限根據服務器的實現不同而不通。另外要提到的是，當其中一端如果崩潰并重新啟動的情況下，如果收到該端“前生”的保活探察，則要發送一個RST數據報文幫助另一端結束連接。

鏈接

http://www.cnblogs.com/fengzanfeng/articles/1339347.html

總結

以上是生活随笔為你收集整理的TCP/IP协议学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。