原文的鏈接：非常感謝仁兄的作品，本文在此基礎上加上了一些參考
TCP/IP詳解學習筆記(1)-基本概念
在世界上各地，各種各樣的電腦運行着各自不同的操作系統爲大家服務，這些電腦在表達同一種信息的時候所使用的方法是千差萬別。就好像聖經中上帝打亂了各地人的口音，讓他們無法合作一樣。計算機使用者意識到，計算機只是單兵作戰並不會發揮太大的作用。只有把它們聯合起來，電腦纔會發揮出它最大的潛力。於是人們就想方設法的用電線把電腦連接到了一起。
但是簡單的連到一起是遠遠不夠的，就好像語言不同的兩個人互相見了面，完全不能交流信息。因而他們需要定義一些共通的東西來進行交流，TCP/IP就是爲此而生。TCP/IP不是一個協議，而是一個協議族的統稱。裏面包括了IP協議，IMCP協議，TCP協議，以及我們更加熟悉的http、ftp、pop3協議等等。電腦有了這些，就好像學會了外語一樣，就可以和其他的計算機終端做自由的交流了。
TCP/IP協議分層
提到協議分層，我們很容易聯想到ISO-OSI的七層協議經典架構（應用層HTTP/HTTPS，FTP，POP3,DNS；表示層主要是解釋通訊數據的意義，如代碼轉換、格式變換等，使不同的終端可以表示。
還包括加密與解密、壓縮與解壓縮等；會話層主要內容是通過會話進行身份驗證、會話管理和確定通訊方式。一旦建立連接，會話層的任務就是管理會話；傳輸層提供端到端的服務。可以實現流量控制、負載均衡。傳輸層信息包含端口、控制字和校驗和。傳輸層協議主要是TCP和UDP。傳輸層位於OSI的第四層，這層使用的設備是主機本身；網絡層管理連接方式和路由選擇。連接方式：虛電路(Virtual Circuits)和數據報(Datagram)服務。虛電路是面向連接的(Connection-Oriented)，數據通訊一次路由，通過會話建立的一條通路。數據報是非連接的(Connectionless-Oriented)，每個數據報都有路由能力。網絡層的數據單位是包，使用的是IP地址，典型設備是路由器Router。這一層可以進行流量控制，但流量控制更多的是使用第二層或第四層；鏈路層屏蔽傳輸介質的物理特徵，使數據可靠傳送。內容包括介質訪問控制、連接控制、順序控制、流量控制、差錯控制和仲裁協議等。鏈路層協議有：協議有面向字符的通訊協議(PPP)和麪向位的通訊協議(HDLC)。仲裁協議：802.3、802.4、802.5，即：CSMA/CD(Carrier
Sense Multiple Access with Collision Detection)、Token Bus、Token Ring鏈路層數據單位是幀，實現對MAC地址的訪問，典型設備是交換機Switch；物理層機械性能：接口的型狀，尺寸的大小，引腳的數目和排列方式等。電氣性能：接口規定信號的電壓、電流、阻抗、波形、速率及平衡特性等。工程規範：接口引腳的意義、特性、標準。工作方式：確定數據位流的傳輸方式，如：單工、半雙工或全雙工。
物理層協議有：美國電子工業協會(EIA)的RS232，RS422，RS423，RS485等；國際電報電話諮詢委員會(CCITT)的X.25、X.21等；物理層的數據單位是位(BIT)，典型設備是集線器HUB。這層主要和硬件有關，與軟件關係不大），但是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地址分爲A,B,C,D,E五類。
網絡號：用於識別主機所在的網絡；
主機號：用於識別該網絡中的主機。
其中A類分配給政府機關使用，B類地址給大中型企業使用，C類地址給個人使用。這三種是主要的。
IP地址分爲五類，A類保留給政府機構，B類分配給中等規模的公司，C類分配給任何需要的人，D類用於組播，E類用於實驗，各類可容納的地址數目不同。
其中A類、B類、和C類這三類地址用於TCP/IP節點，其它兩類D類和E類被用於特殊用途。
A、B、C三類IP地址的特徵：當將IP地址寫成二進制形式時，A類地址的第一位總是O，B類地址的前兩位總是10，C類地址的前三位總是110。
1. A類地址
⑴ A類地址第1字節爲網絡地址，其它3個字節爲主機地址。
⑵ A類地址範圍：1.0.0.1—126.155.255.254
⑶ A類地址中的私有地址和保留地址：
① 10.X.X.X是私有地址（所謂的私有地址就是在互聯網上不使用，而被用在局域網絡中的地址）。
② 127.X.X.X是保留地址，用做循環測試用的。
2. B類地址
⑴ B類地址第1字節和第2字節爲網絡地址，其它2個字節爲主機地址。
⑵ B類地址範圍：128.0.0.1—191.255.255.254。
⑶ B類地址的私有地址和保留地址
① 172.16.0.0—172.31.255.255是私有地址
② 169.254.X.X是保留地址。如果你的IP地址是自動獲取IP地址，而你在網絡上又沒有找到可用的DHCP服務器。就會得到其中一個IP。
3. C類地址
⑴ C類地址第1字節、第2字節和第3個字節爲網絡地址，第4個個字節爲主機地址。另外第1個字節的前三位固定爲110。
⑵ C類地址範圍：192.0.0.1—223.255.255.254。
⑶ C類地址中的私有地址：
192.168.X.X是私有地址。
4. D類地址
⑴ D類地址不分網絡地址和主機地址，它的第1個字節的前四位固定爲1110。
⑵ D類地址範圍：224.0.0.1—239.255.255.254
5. E類地址
⑴ E類地址也不分網絡地址和主機地址，它的第1個字節的前五位固定爲11110。
⑵ E類地址範圍：240.0.0.1—255.255.255.254
· 域名系統
域名系統是一個分佈的數據庫，它提供將主機名（就是網址啦）轉換成IP地址的服務。
· RFC
RFC是什麼？RFC就是tcp/ip協議的標準文檔，在這裏我們可以看到RFC那長長的定義列表，現在它一共有4000多個協議的定義，當然，我們所要學習的，也就是那麼十幾個協議而已。
· 端口號(port)
注意，這個號碼是用在TCP，UDP上的一個邏輯號碼，並不是一個硬件端口，我們平時說把某某端口封掉了，也只是在IP層次把帶有這個號碼的IP包給過濾掉了而已。
· 應用編程接口
現在常用的編程接口有socket和TLI。而前面的有時候也叫做“Berkeley socket”，可見Berkeley對於網絡的發展有多大的貢獻。
· 數據的封裝
當應用程序用TCP傳送數據時，數據被送入協議棧中，然後逐個通過每一層，直接到當作一串比特流送入網絡。其中每一層對收到的數據都要加一些首部信息（有時還要增加尾部信息）
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詳解學習筆記(3)-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)-Ping和TracerRouter
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詳解學習筆記(8)-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詳解學習筆記(9)-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協議保證數據可靠性的另一個重要機制，其原理是在發送某一個數據以後就開啓一個計時器，在一定時間內如果沒有得到發送的數據報的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數據報文幫助另一端結束連接。
小知識：
1.8根網線的作用
網線8根其中有用來傳輸數據的.有用來校驗數據的.有備用的.
並不是數據傳輸的時候8根線都在運做.
RJ45水晶頭是標準網線用.內含8條線爲5類4對雙絞線.正常情況下4條線工作.
另外4根是抗干擾設計，用8根交叉可以減少輻射干擾，
這也是網線爲什麼叫雙絞線的原因.
不是非要做8根，只做四根也可以，只要1236線是通的就可以了。
只要兩邊的顏色一致,都是可以用的。 不過還是建議用標準接線方法
3.爲啥我們有了RARP協議，還需要另外弄一個DHCP協議
RARP在功能上有點類似於DHCP協議，確切的說DHCP是BOOTP協議的升級，而BOOTP在某種意義上又是RARP協議的升級。BOOTP和RARP的區別在於RARP是在數據鏈路層實現的，而BOOTP實在應用層實現的，當然作爲BOOTP的升級版DHCP也是在應用層實現的。這種實現層面的差別也從RARP和BOOTP/DHCP的報文封裝格式的差別上體現出來了，RARP直接封裝在以太網幀中，協議類型置爲0x0800以標識這個報文是ARP/RARP報文，BOOTP/DHCP報文是直接封裝在UDP報文中，作爲UDP的數據段出現的。
從功能上說，RARP只能實現簡單的從MAC地址到IP地址的查詢工作，RARP server上的MAC地址和IP地址是必須事先靜態配置好的。但DHCP卻可以實現除靜態分配外的動態IP地址分配以及IP地址租期管理等等相對複雜的功能。
2：初期設想互聯網規模不會有那麼大，爲了儘可能的使每個網內終端都能獲得一個公有IP(可以自由的被外網訪問)，分出了A類地址那麼龐大的地址空間，其實A類地址分下去之後，這個網絡地址內肯定還會細分出更多的子網絡地址給路由器，因爲不可能有那麼大的交換機能夠連接所有終端，即使這樣，仍然有很多IP地址浪費。用來做網絡分段的使用的，早年沒有VLSM（可變長度子網掩碼）技術的時候，只有靠這種通用的標準來實現網段的區分~
在現在的網絡中，IP地址分爲公網IP和私有IP地址。公網IP是在Internet使用的IP地址，而私有IP地址是在局域網中使用的IP地址。私有IP地址是一段保留的IP地址。只是使用在局域網中，在Internet上是不使用的。
由於目前使用的IP V4協議的限制，現在IP地址的數量是有限的。不能爲網中的每一臺計算機分配一個公網IP。所以，在局域網中的每臺計算機就只能使用私有IP地址了，如常見的192.168.1.1，就是私有IP地址。
RFC 1918(Address Allocation for Private Internets，私有網絡地址分配)留出1個A類地址段，16個B類地址段，256個C類地址段：
A類10.0.0.0到10.255.255.255
B類172.16.0.0到172.31.255.255
C類192.168.0.0到192.168.255.255
在這個範圍內的IP地址不能被路由到Internet上；Internet路由器將丟棄該私有地址。
6.爲什麼FTP一個服務要佔用20和21兩個端口？
我們們進行FTP文件傳輸中，客戶端首先連接到FTP服務器的21端口，進行用戶的認證，認證成功後，當我們要傳輸文件時，服務器會開一個端口爲20來進行傳輸數據文件，也就是說，端口20纔是真正傳輸所用到的端口，端口21只用於FTP的登陸認證。我們平常下載文件時，會遇到下載到99%時，文件不完成，不能成功的下載。其實是因爲文件下載完畢後，還要在21端口再行進行用戶認證，而我們下載文件的時間如果過長，客戶機與服務器的21端口的連接會被服務器認爲是超時連接而中斷掉，就是這個原因。解決方法就是設置21端口的響應時間。