【正文】 該是分配給 注冊(cè)應(yīng)用使用的注冊(cè)端口 卻被沒(méi)有注冊(cè)應(yīng)用給用 做 成了臨時(shí) 的端口。 ftp 與 tcp 分析 ftp 分析 ① FTP（ File Transfer Protocal） ，是文件傳輸協(xié)議的簡(jiǎn)稱。 ② FTP 的作用 ： FTP 的主要作用，就是讓用戶連接上一個(gè)遠(yuǎn)程 主機(jī)，把遠(yuǎn)程主機(jī)上的文件下載到 本地。 ③ FTP 工作原理 4 圖 ftp 協(xié)議圖 上圖是 ftp 協(xié)議的官方協(xié)議圖： 可以看出它主要是由兩個(gè) socket 組成的。 1，控制連接，主要是用于發(fā)送控制命令 2，數(shù)據(jù)連接，主要用于文件上傳和下載時(shí)文件數(shù)據(jù)的傳輸 . ftp 協(xié)議的建立流程： 首先，客戶端建立一個(gè)套接字 1，套接字綁定的 IP 和端口為 ftp 服務(wù)器的 ip 和著名端口 1 建立時(shí)應(yīng)該是面向連接的。這時(shí)客戶端就和服 務(wù)器建立了控制連接。然后，客戶端就可以發(fā)送相關(guān)命令了 以 傳 輸 文件為例 ， 傳輸文件的一般步驟如下 : a) 在本地電腦上登陸到國(guó)際互聯(lián)網(wǎng) 。 b) 搜索有文件共享主機(jī)或者個(gè)人電腦 。 c) 當(dāng)與遠(yuǎn)程主機(jī)或者對(duì)方的個(gè)人電腦建立連接后 ,用對(duì)方提供的用戶名和口令登陸到該主機(jī)或?qū)Ψ降膫€(gè)人電腦 。 d) 在遠(yuǎn)程主機(jī)或?qū)Ψ降膫€(gè)人電腦登陸成功后 ,就可以上傳你想跟別人分享的東東或者下載別人授權(quán)共享的 資料 。 e) 完成工作后關(guān)閉 FTP 下載軟件 ,切斷連接 。 為了實(shí)現(xiàn)文件傳輸 ,用戶還要運(yùn)行專門的文件傳輸程序 ,比如網(wǎng)際快車就有這方面的功能 ,其它還有很多專門的 FTP 傳輸軟 件 ,各有各的特色 。 tcp 分析 ① TCP（ Transmission Control Protocol） ： 中文全稱 傳輸控制協(xié)議 。 TCP 是一種面向連接5 的、可靠的、基于字節(jié)流的運(yùn)輸層（ Transport layer）通信協(xié)議 。 ② TCP 的作用 : tcp 的作用 ,主要用于在主機(jī)間建立一個(gè)虛擬連接，以實(shí)現(xiàn)高可靠性的數(shù)據(jù)包交換。 該協(xié)議傳輸模式中在將數(shù)據(jù)包成功發(fā)送給目標(biāo)計(jì)算機(jī)后， TCP 會(huì)要求發(fā)送一個(gè)確認(rèn)；如果在某個(gè)時(shí)限內(nèi)沒(méi)有收到確認(rèn)，那么 TCP 將重新發(fā)送數(shù)據(jù)包。另 外，在傳輸?shù)倪^(guò)程中，如果接收到無(wú)序、丟失以及被破壞的數(shù)據(jù)包， TCP 還可以負(fù)責(zé)恢復(fù)。 這是 IP 協(xié)議做不到的。 ③ TCP 工作原理： TCP/IP 協(xié)議 參照 OSI的七層參考模型 ， 經(jīng)過(guò)創(chuàng)造性的結(jié)合發(fā)展出 了4 層的層級(jí)結(jié)構(gòu)，每一層都呼叫它的下一層所提供的網(wǎng)絡(luò)來(lái)完成自己的需求。這 4層分別為： 應(yīng)用層 、 傳輸層 、 互連網(wǎng)絡(luò)層 、 網(wǎng)絡(luò)接口層 。 a)應(yīng)用層：應(yīng)用程序間溝通的層，如電子郵件傳輸（ SMTP）、文件傳輸協(xié)議（ FTP）、網(wǎng)絡(luò)遠(yuǎn)程訪問(wèn)協(xié)議（ Tel）等。 b)傳輸層：在此層中，它提供了節(jié)點(diǎn)間的數(shù)據(jù) 傳送服務(wù)，如傳輸控制協(xié)議（ TCP）、用戶數(shù)據(jù)報(bào)協(xié)議（ UDP）等， TCP和 UDP 給數(shù)據(jù)包加入傳輸數(shù)據(jù)并把它傳輸?shù)较乱粚又校@一層負(fù)責(zé)傳送數(shù)據(jù)，并且確定數(shù)據(jù)已被送達(dá)并接收。 c)互連網(wǎng)絡(luò)層：負(fù)責(zé)提供基本的數(shù)據(jù)封包傳送功能，讓每一塊數(shù)據(jù)包都能夠到達(dá)目的主機(jī)（但不檢查是否被正確接收），如網(wǎng)際協(xié)議（ IP）。 d)網(wǎng)絡(luò)接口層：對(duì)實(shí)際的網(wǎng)絡(luò)媒體的管理，定義如何使用實(shí)際網(wǎng)絡(luò)（如 Ether、Serial Line 等）來(lái)傳送數(shù)據(jù)。 ftp 與 tftp 分析 TFTP（ Trivial File Transfer Protocol,簡(jiǎn)單文件傳輸協(xié)議）是 TCP/IP協(xié)議 族中的一個(gè)用來(lái)在客戶機(jī)與服務(wù)器之間進(jìn)行簡(jiǎn)單文件傳輸?shù)膮f(xié)議，提供不復(fù)雜、開(kāi)銷不大的文件傳輸服務(wù)。端口號(hào)為 69。 目的 TFTP 是一個(gè)傳輸文件的簡(jiǎn)單協(xié)議，它基于 UDP 協(xié)議而實(shí)現(xiàn)，但是我們也不能確定有些 TFTP 協(xié)議是基于其它傳輸協(xié)議完成的。此協(xié)議設(shè)計(jì)的時(shí)候是進(jìn)行小文件傳輸?shù)摹Ｒ虼怂痪邆渫ǔ５?FTP 的許多功能，它只能從文件服務(wù)器上獲得或?qū)懭胛募荒芰谐瞿夸?，不進(jìn)行認(rèn)證，它傳輸 8 位數(shù)據(jù)。傳輸中有三種模式： ascii，這是8 位的 ASCII 碼形式，另一種 是 octet，這是 8 位源數(shù)據(jù)類型；最后一種 mail 已經(jīng)不再支持，它將返回的數(shù)據(jù)直接返回給用戶而不是保存為文件。 概況 任何傳輸起自一個(gè)讀取或?qū)懭胛募恼?qǐng)求，這個(gè)請(qǐng)求也是連接請(qǐng)求。如果服務(wù)器批準(zhǔn)此請(qǐng)求，則服務(wù)器打開(kāi)連接，數(shù)據(jù)以定長(zhǎng) 512 字節(jié)傳輸。每個(gè)數(shù)據(jù)包包括一塊數(shù)據(jù)，服務(wù)器發(fā)出下一個(gè)數(shù)據(jù)包以前必須得到客戶對(duì)上一個(gè)數(shù)據(jù)包的確認(rèn)。如果一個(gè)數(shù)據(jù)包的大小小于 512字節(jié)，則表示傳輸結(jié)構(gòu)。如果數(shù)據(jù)包在傳輸過(guò)程中丟失，發(fā)出方6 會(huì)在超時(shí)后重新傳輸最后一個(gè)未被確認(rèn)的數(shù)據(jù)包。通信的雙方都是數(shù)據(jù)的發(fā)出者與接收者，一方傳輸數(shù) 據(jù)接收應(yīng)答，另一方發(fā)出應(yīng)答接收數(shù)據(jù)。大部分的錯(cuò)誤會(huì)導(dǎo)致連接中斷，錯(cuò)誤由一個(gè)錯(cuò)誤的數(shù)據(jù)包引起。這個(gè)包不會(huì)被確認(rèn)，也不會(huì)被重新發(fā)送，因此另一方無(wú)法接收到。如果錯(cuò)誤包丟失，則使用超時(shí)機(jī)制。錯(cuò)誤主要是由下面三種情況引起的：不能滿足請(qǐng)求，收到的數(shù)據(jù)包內(nèi)容錯(cuò)誤，而這種錯(cuò)誤不能由延時(shí)或重發(fā)解釋，對(duì)需要資源的訪問(wèn)丟失（如硬盤(pán)滿）。 TFTP 只在一種情況下不中斷連接，這種情況是源端口不正確，在這種情況下，指示錯(cuò)誤的包會(huì)被發(fā)送到源機(jī)。這個(gè)協(xié)議限制很多，這是都是為了實(shí)現(xiàn)起來(lái)比較方便而進(jìn)行的。 與其它協(xié)議的聯(lián)系 因?yàn)?TFTP 使用 UDP，而 UDP 使用 IP， IP可以還使用其它本地通信方法。因此一個(gè) TFTP 包中會(huì)有以下幾段：本地媒介頭， IP 頭，數(shù)據(jù)報(bào)頭， TFTP 頭，剩下的就是TFTP 數(shù)據(jù)了。 TFTP 在 IP頭中不指定任何數(shù)據(jù)，但是它使用 UDP 中的源和目標(biāo)端口以及包長(zhǎng)度域。由 TFTP 使用的包標(biāo)記（ TID）在這里被用做端口，因此 TID必須介于 0到 65,535 之間。對(duì)它的初始化我們?cè)诤竺嬗懻摗?TFTP 頭中包括兩上字節(jié)的操作碼，這個(gè)碼指出了包的類型 ， 下面 是 大體上的 TFTP 包格式 。 | Local Medium | Inter | Datagram | TFTP | 初始連接 初始連接時(shí)候需要發(fā)出 WRQ（請(qǐng)求寫(xiě)入遠(yuǎn)程系統(tǒng)）或 RRQ（請(qǐng)求讀取遠(yuǎn)程系統(tǒng)），收到一個(gè)確定應(yīng)答，一個(gè)確定可以寫(xiě)出的包或應(yīng)該讀取的第一塊數(shù)據(jù)。通常確認(rèn)包包括要確認(rèn)的包的包號(hào)，每個(gè)數(shù)據(jù)包都與一個(gè)塊號(hào)相對(duì)應(yīng)，塊號(hào)從 1開(kāi)始而且是連續(xù)的。因此對(duì)于寫(xiě)入請(qǐng)求的確 定是一個(gè)比較特殊的情況，因此它的包的包號(hào)是 0。如果收到的包是一個(gè)錯(cuò)誤的包，則這個(gè)請(qǐng)求被拒絕。創(chuàng)建連接時(shí)，通信雙方隨機(jī)選擇一個(gè) TID，因此是隨機(jī)選擇的，因此兩次選擇同一個(gè) ID的可能性就很小了。每個(gè)包包括兩個(gè) TID，發(fā)送者 ID和接收者 ID。這些 ID用于在 UDP 通信時(shí)選擇端口，請(qǐng)求主機(jī)選擇 ID的方法上面已經(jīng)說(shuō)過(guò)了，在第一次請(qǐng)求的時(shí)候它會(huì)將請(qǐng)求發(fā)到 TID 69，也就是服務(wù)器的69 端口上。應(yīng)答時(shí)，服務(wù)器使用一個(gè)選擇好的 TID 作為源 TID，并用上一個(gè)包中的TID作為目的 ID進(jìn)行發(fā)送。這兩個(gè)被選擇的 ID在隨后的通信中會(huì)被 一直使用。下例是一個(gè)寫(xiě)入的例子，其中 WRQ， ACK 和 DATA 代表寫(xiě)入請(qǐng)求，確認(rèn)和數(shù)據(jù)。 TFTP 相關(guān)應(yīng)用 1. 主機(jī) A 向主機(jī) B 發(fā)出 WRQ，其中端口為 69 2. B 機(jī)向 A 機(jī)發(fā)出 ACK，塊號(hào)為 0，包括 B 和 A 的 TID 此時(shí)連接建立，第一個(gè)數(shù)據(jù)包以序列號(hào) 1 從主機(jī)開(kāi)始發(fā)出。以后兩臺(tái)主機(jī)要保證以開(kāi)始時(shí)確定的 TID 進(jìn)行通信。如果源 ID 與原來(lái)確定的 ID 不一樣，這個(gè)包會(huì)被7 認(rèn)識(shí)為發(fā)送到了錯(cuò)誤的地址而被拋棄。錯(cuò)誤的包是被發(fā)送到正確端口的，但是包本身有錯(cuò)誤。設(shè)想發(fā)送方發(fā)出一個(gè)請(qǐng)求，這個(gè)請(qǐng)求在網(wǎng)絡(luò)的那個(gè)設(shè)備中被復(fù)制 成兩個(gè)包，接收方先后接收到兩個(gè)包。接收方會(huì)認(rèn)為為這是兩個(gè)獨(dú)立的請(qǐng)求，會(huì)返回兩個(gè)應(yīng)答。當(dāng)這兩個(gè)應(yīng)答其中之一被接收到時(shí)，連接已經(jīng)建立。第二個(gè)應(yīng)答再到達(dá)時(shí)，這個(gè)包會(huì)被拋棄，而不會(huì)因?yàn)榻邮盏降诙€(gè)應(yīng)答包而導(dǎo)致第一個(gè)建立的連接失敗。 3 TFTP 包 TFTP 支持五種類型的包，我們?cè)谝陨弦呀?jīng)說(shuō)明這五種類型的包： opcode operation 1 Read request (RRQ) 2 Write request (WRQ) 3 Data (DATA) 4 Acknowledgment (ACK) 5 Error (ERROR) 包頭中包括了這個(gè)包所指定的操作碼。 2 bytes string 1 byte string 1 byte | Opcode | Filename | 0 | Mode | 0 | Figure 51: RRQ/WRQ 包 RRQ 和 WRQ 包（代碼分別為 1 和 2）的格式如上所示。文件名是 NETASCII碼字符，以 0 結(jié)束。 而 MODE 域包括了字符串 ascii， octet或 mail，名稱不分大小寫(xiě)。接收到 NETASCII 格式數(shù)據(jù)的主機(jī)必須將數(shù)據(jù)轉(zhuǎn)換為本地格式。 OCTET模式用于傳輸文件，這種文件在源機(jī)上以 8 位格式存儲(chǔ)。假設(shè)每個(gè)機(jī)器都存在一個(gè) 8位的格式，這樣的假設(shè)是最一般的。比如 DEC20，這是一種 36 位機(jī)，我們可以假設(shè)它是 4 個(gè) 8 位外加另外 4 位而構(gòu)成。如果機(jī)器收到 OCTET 格式文件，返回時(shí)必須與原來(lái)文件 完全一樣。在使用 MAIL 模式時(shí)，用戶可以在 FILE 處使用接收人地址，這個(gè)地址可以是用戶名或用戶名 @主機(jī)的形式，如果是后一種形式，允許主機(jī)使用電子郵件傳輸此文件。如果使用 MAIL 類型，包必須以 WRQ 開(kāi)始，否則它與 NETASCII完全一樣。我們的討論建立在發(fā)送方和接收方都在相同模式的情況下，但是雙方可以以不同的模式進(jìn)行傳輸。例如一個(gè)機(jī)器可以是一臺(tái)存儲(chǔ)服務(wù)器，這樣一臺(tái)服務(wù)器需要將 NETASCII 格式轉(zhuǎn)換為自己的格式。另外，我們可以設(shè)想 DEC20 這種機(jī)器，它使用 36 位字長(zhǎng)，用戶這邊可以使用特殊的機(jī)制一次讀取 36 位 ，而服務(wù)器卻可以仍然使用 8 位格式。在這兩種情況下，我們看到了兩臺(tái)機(jī)器使用不同格式的情況?？梢栽趦膳_(tái)主機(jī)間定義其它的傳輸方式，但是定義要小心，因?yàn)檫@種傳輸方式不為人知，而且也沒(méi)有權(quán)威機(jī)構(gòu)為其指定名稱或定義它的模式。 8 2 bytes 2 bytes n bytes | Opcode | Block | Data | Figure 52: DATA 包 數(shù)據(jù)在數(shù)據(jù)包中傳輸，其格式如上圖所示。數(shù)據(jù)包的 OP 碼為 3，它還包括有一個(gè)數(shù)據(jù)塊號(hào)和數(shù)據(jù)。數(shù)據(jù)塊號(hào)域從 1 開(kāi)始編碼，每個(gè)數(shù)據(jù)塊加 1，這樣接收方可以確定這個(gè)包是新數(shù)據(jù)還是已經(jīng)接收過(guò)的數(shù)據(jù)。數(shù)據(jù)域從 0 字節(jié)到 512 字節(jié)。如果數(shù)據(jù)域是 512 字節(jié)則它不是最后一個(gè)包，如果小于 512 字節(jié)則表示這個(gè)包是最后一個(gè)包。除了 ACK 和用于中斷的包外，其它的包均得到確認(rèn)。發(fā)出新的數(shù)據(jù)包等于確認(rèn)上次的包。 WRQ 和 DATA 包由 ACK 或 ERROR 數(shù)據(jù)包確認(rèn)，而 RRQ 數(shù)據(jù)包由 DATA或 ERROR 數(shù)據(jù)包確認(rèn)。下圖即是一個(gè) ACK 包 ，操作碼為 4。其中的包號(hào)為要確認(rèn)的數(shù)據(jù)包的包號(hào)。 2 bytes 2 bytes | Opcode | Block | Figure 53: ACK 包 WRQ 數(shù)據(jù)包被 ACK 數(shù)據(jù)包確認(rèn)， WRQ 數(shù)據(jù)包的包號(hào)為 0。 2 bytes 2 bytes string 1