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協議的某些特性將會影響我們的伺服器程式設計,大致總結如下:
- 關於客戶IP和地址:伺服器必須有根據客戶IP地址和連接埠號碼判斷資料包是否合法的能力(這似乎要求每一個伺服器都要具備)
- 關於目的地址:伺服器必須要有過濾廣播位址的能力。
- 關於資料輸入:通常伺服器系統的每一個連接埠號碼都會和一塊輸入緩衝區對應,進來的輸入根據先來後到的原則等待伺服器的處理,所以難免會出現緩衝區溢位的問題,這種情況下,UDP資料包可能會被丟棄,而應用伺服器程式本身並不知道這個問題。
- 伺服器應該限制本地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發信。
再來一個多播的例子,但是要實現這個多播並不容易,因為我不知道網路內有多少個多播組,就只好利用幾個特殊的多播地址來驗證了。
對於多播地址,有幾個特殊的多播地址被佔用,他們是
- 224.0.0.1--該子網內所有的系統組。
- 224.0.0.2--該子網內所有的路由器。
- 224.0.1.1--網路實現協議NTP專用IP。
- 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)-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頁。對各個欄位簡單解釋如下
- 最前面的16個bit唯一的標示了問題號碼,用於查詢端區別自己的查詢。
- 緊接著的16個bit又可以做進一步的細分,標示了報文的性質和一些細節,比如說是查詢報文還是響應報文,需要遞迴查詢與否(一般伺服器都支援遞迴查詢,而且不需要任何設定,BIND就是這樣)
- 查詢問題後面有查詢類型,包括A,NS,CNAME,PTR,HINFO,MX,如果熟悉BIND的話,就知道在zong的設定檔裡面,每一條記錄都記載了各自的類型,比如A就是IP地址,NS就是名字伺服器。
- 響應報文可以回複多個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查詢的有兩種情況:
- 當查詢資料多大以至於產生了資料截斷(TC標誌為1),這時,需要利用TCP的分區能力來進行資料轉送(看TCP的相關章節)。
- 當主(master)伺服器和輔(slave)伺服器之間通訊,輔伺服器要拿到主伺服器的zone資訊的時候。
完