【文章內(nèi)容簡介】 byte | Opcode | ErrorCode | ErrMsg | 0 | Figure 54: ERROR 包 一個(gè) ERROR 包，它的操作碼是 5，它的格式如上所示。此包可以被其它任何類型的包確認(rèn)。錯(cuò)誤碼指定錯(cuò)誤的類型。錯(cuò)誤的值和錯(cuò)誤的意義在附錄中。錯(cuò)誤信息是供程序員使用的。 正常終止 傳輸?shù)慕Y(jié)束由 DATA 數(shù)據(jù)標(biāo)記，其包括 0511 個(gè)字符。這個(gè)包可以被其它數(shù)據(jù)包確認(rèn)。接收方在發(fā)出對(duì)最后數(shù)據(jù)包的確認(rèn)后可以斷開連接， 當(dāng)然，適當(dāng)?shù)牡却潜容^好的，如果最后的確定包丟失可以再次傳輸。如果發(fā)出確認(rèn)后仍然收到最后數(shù)據(jù)包，可以確定最后的確認(rèn)丟失。發(fā)送最后一個(gè) DATA 包的主機(jī)必須等待對(duì)此包的確認(rèn)或超時(shí)。如果響應(yīng)是 ACK，傳輸完成。如果發(fā)送方超時(shí)并不準(zhǔn)備重新發(fā)送并且接收方有問題或網(wǎng)絡(luò)有問題時(shí)，發(fā)送也正常結(jié)束。當(dāng)然實(shí)現(xiàn)時(shí)也可以是非正常結(jié)束，但無論如何連接都將被關(guān)閉。 9 早終結(jié) 如果請(qǐng)求不能被滿足，或者在傳輸中發(fā)生錯(cuò)誤，需要發(fā)送 ERROR 包。這僅是一種傳輸友好的方式，這種包不會(huì)被確認(rèn)也不會(huì)被重新傳輸，因此這種包可能永遠(yuǎn)不會(huì)被接收到。因此 需要用超時(shí)來偵測錯(cuò)誤。 ftp 與 tftp 的區(qū)別 ① FTP 是完整、面向會(huì)話、常規(guī)用途文件傳輸協(xié)議。而 TFTP 用作 bones bare 特殊目的文件傳輸協(xié)議。 ② 交互使用 FTP。 TFTP 允許僅單向傳輸?shù)奈募? FTP 提供身份驗(yàn)證。而 TFTP 不。 ③ FTP 使用已知 TCP 端口號(hào)： 20 的數(shù)據(jù)和 21 用于連接對(duì)話框。 TFTP 用于 UDP 端口號(hào) 69 其文件傳輸活動(dòng)。 ④ 因?yàn)? TFTP 不支持驗(yàn)證 WindowsNT ，所以 FTP 服務(wù)器服務(wù)不支持 TFTP。 ⑤ FTP 依賴于 TCP，是面向連接并提供可靠的控件。 TFTP 依賴 UDP，需要減少開銷 , 幾乎不提供控件。 ⑥ 簡單文件傳送協(xié)議 TFTP(Trivial File Transfer Protocol)是一個(gè) TCP/IP 協(xié)議族中一個(gè)很小且易于實(shí)現(xiàn)的文件傳送協(xié)議。 TFTP 也是使用客戶服務(wù)器方式，但它使用 UDP數(shù)據(jù)報(bào) ，因此 TFTP 需要有自己的差錯(cuò)改正措施。 TFTP 的主要特點(diǎn)是： （ 1）每次傳送的數(shù)據(jù) PDU 中有 512 字節(jié)的數(shù)據(jù)，但最后一次可不足 512 字節(jié)。 （ 2）數(shù)據(jù) PDU 也稱為文件塊 (block)，每個(gè)塊按序編號(hào)，從 1開始。 （ 3）支持 ASCII 碼或二進(jìn)制傳送。 （ 4）可對(duì)文件進(jìn)行讀或?qū)憽? （ 5）使用很簡單的首部。 （ 6） TFTP 只支持文件傳輸而不支持交互； （ 7） TFTP 沒有一個(gè)龐大的命令集； （ 8）沒有列目錄的功能； （ 9）也不能對(duì)用戶 進(jìn)行身份鑒別。 TFTP 的工作很像停止等待協(xié)議。例如： （ 1）發(fā)送完一個(gè)文件塊后就等待對(duì)方的確認(rèn)，確認(rèn)時(shí)應(yīng)指明所確認(rèn)的塊編號(hào)。 （ 2）發(fā)完數(shù)據(jù)后在規(guī)定時(shí)間內(nèi)收不到確認(rèn)就要重發(fā)數(shù)據(jù) PDU。 （ 3）發(fā)送確認(rèn) PDU 的一方若在規(guī)定時(shí)間內(nèi)收不到下一個(gè)文件塊，也要重發(fā)確認(rèn) PDU。這樣就可保證文件的傳送不致因某一個(gè)數(shù)據(jù)報(bào)的丟失而告失敗。 TFTP 在一開始工作時(shí)，客戶進(jìn)程發(fā)送一個(gè)讀請(qǐng)求 PDU 或?qū)懻?qǐng)求 PDU 給 TFTP 服務(wù)器進(jìn)程，其熟知端口號(hào)碼為 69。 TFTP 服務(wù)器進(jìn)程要選擇一個(gè)新的端口和 TFTP客戶進(jìn)程進(jìn)行通信。若文件長度恰好為 512 字節(jié)的整數(shù)倍，則在文件傳送完畢后，還必須在最后發(fā)送一個(gè)只含首部而無數(shù)據(jù)的數(shù)據(jù) PDU；若文件長度不是 512 字節(jié)的整數(shù)倍，則最后傳送數(shù)據(jù) PDU的數(shù)據(jù)字段一定不滿 512 字節(jié)，這正好可作為文件結(jié)束的標(biāo)志。 FTP 模式分析 當(dāng) 對(duì)一個(gè) FTP 問題進(jìn)行排錯(cuò)時(shí)候， 首先要問的一個(gè)問題是使用的是 port 模式的還是passive 模式。因?yàn)檫@兩種行為迥異，所以這兩種模式引起的問題也不同；在過去，客戶10 端缺省為 active(port)模式；近來，由于 Port 模式的安全問題，許多客戶端的 FTP 應(yīng) 用缺省為 Passive 模式。 FTP 支持兩種模式。這兩種模式被稱為“標(biāo)準(zhǔn)”（或 PORT，或“主動(dòng)”）和“被動(dòng)”（或PASV）?！皹?biāo)準(zhǔn)”模式 FTP 客戶端會(huì)向 FTP 服務(wù)器發(fā)送 PORT 命令。“被動(dòng)”模式客戶端會(huì)向FTP 服務(wù)器發(fā)送 PASV 命令。這些命令是在建立 FTP 會(huì)話時(shí)通過 FTP 命令通道進(jìn)行發(fā)送的。2種模式 FTP 客戶端都要建立一個(gè)到 FTP 服務(wù)器上 TCP 端口 21的連接?？蛻暨x擇大于 1024的端口發(fā)起連接，此連接會(huì)建立 FTP 命令通道。不能列目錄是因?yàn)?FTP 使用不同的通道來傳遞數(shù)據(jù)，這也是 FTP 不同于 HTTP 服務(wù)的地方 ， HTTP 需要一條通道就可以了 。 servu默認(rèn)的方式就是 PORT 方式。 PORT 方式能連接、也能列目錄、能下載文件 ， PASV 方式能連接、不能列目錄下載文件 。 FTP 的主動(dòng)模式 (Port 模式 ) 主動(dòng)模式 在主動(dòng)模式中， FTP 服務(wù)器綁定了兩個(gè)端口： 21 和 20 （這兩個(gè)端口是默認(rèn)值，可以設(shè)成別的端口）。其中 21端口負(fù)責(zé)客戶端和服務(wù)器之間的命令傳送。一開始，由客戶端主動(dòng)連接服務(wù)端的 21 端口，并且向服務(wù)器發(fā)送相應(yīng)的 FTP 命令。另外一個(gè)端口 20 是負(fù)責(zé)客戶端和服務(wù)端的數(shù)據(jù)傳送。但要注意，并不是客 戶端主動(dòng)連接服務(wù)端的 20 端口，而是在客戶端創(chuàng)建一個(gè)使用匿名端口的服務(wù)端連接（在 Java 中就是創(chuàng)建一個(gè) ServerSocket 對(duì)象，并且綁定端口是 0）。然后客戶端通過 21 端口將這個(gè)匿名端口通知服務(wù)端。最后，服務(wù)端主動(dòng)連接客戶端的這個(gè) 匿名端口（所以這種模式叫主動(dòng)模式，就是服務(wù)器主動(dòng)連接客戶端）。 主動(dòng)模式的工作原理。 圖 主動(dòng)模式的工作原理 從上圖可以看出，在主動(dòng)模式中，在傳送命令和數(shù)據(jù)時(shí)，建立連接的過程是相反的。也就是說，在傳送命令時(shí)，由客戶端主動(dòng)連接服務(wù)器的 21 端口。而傳送數(shù)據(jù)時(shí)，由服務(wù)器主動(dòng)連接客 戶端的匿名端口。這種方式是 FTP 服務(wù)器最初的工作模式，但這種模式有很11 大的局限性。如客戶端通過代理上網(wǎng)，而且未做端口映射。在這種情況下，服務(wù)端是無法主動(dòng)和客戶端建立連接的。 Port 模式的 FTP 步驟 如下： 1) 客戶端發(fā)送一個(gè) TCP 2) SYN（ TCP 同步）包給服務(wù)器段眾所周知的 FTP 控制端口 21，客戶端使用暫時(shí)的端口作為它的源端口； 3) 服務(wù)器端發(fā)送 SYN 4) ACK（同步確認(rèn)）包給客戶端，源端口為 21，目的端口為客戶端上使用的暫時(shí)端口； 5) 客戶端發(fā)送一個(gè) ACK（確認(rèn)）包；客戶端使用這個(gè)連接來發(fā)送 FTP 命令， 服務(wù)器端使用這個(gè)連接來發(fā)送 FTP 應(yīng)答； 6) 當(dāng)用戶請(qǐng)求一個(gè)列表 (List)請(qǐng)求或者發(fā)起一個(gè)要求發(fā)送或者接受文件的請(qǐng)求，客戶端軟件使用 PORT 命令，這個(gè)命令包含了一個(gè)暫時(shí)的端口，客戶端希望服務(wù)器在打開一個(gè)數(shù)據(jù)連接時(shí)候使用這個(gè)暫時(shí)端口； PORT 命令也包含了一個(gè) IP 地址，這個(gè) IP 地址通常是客戶自己的 IP 地址，而且 FTP 也支持第三方（ thirdparty）模式，第三方模式是客戶端告訴服務(wù)器端打開與另臺(tái)主機(jī)的連接； 7) 服務(wù)器端發(fā)送一個(gè) SYN 包給客戶端的暫時(shí)端口，源端口為 20，暫時(shí)端口為客戶端在 PORT 命令中發(fā)送給服務(wù)器端 的暫時(shí)端口號(hào)； 8) 客戶端以源端口為暫時(shí)端口，目的端口為 20 發(fā)送一個(gè) SYN ACK 包； 9) 服務(wù)器端發(fā)送一個(gè) ACK 包； 10) 發(fā)送數(shù)據(jù)的主機(jī)以這個(gè)連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以 TCP 段 (注： segment，第 4層的 PDU)形式發(fā)送（一些命令，如 STOR 表示客戶端要發(fā)送數(shù)據(jù)， RETR 表示服務(wù)器段發(fā)送數(shù)據(jù)），這些 TCP 段都需要對(duì)方進(jìn)行 ACK 確認(rèn)（注：因?yàn)?TCP 協(xié)議是一個(gè)面向連接的協(xié)議） 11) 當(dāng)數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機(jī)以一個(gè) FIN 命令來結(jié)束數(shù)據(jù)連接，這個(gè)FIN 命令需要另一臺(tái)主機(jī)以 ACK 確認(rèn)，另一臺(tái)主機(jī)也發(fā)送一個(gè) FIN 命令，這個(gè) FIN 命令同樣需要發(fā)送數(shù)據(jù)的主機(jī)以 ACK 確認(rèn)； 12) 客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關(guān)閉另外的數(shù)據(jù)連接；有時(shí)候客戶端結(jié)束后，客戶端以 FIN 命令來關(guān)閉一個(gè)控制連接，服務(wù)器端以 ACK 包來確認(rèn)客戶端的 FIN，服務(wù)器同樣也發(fā)送它的 FIN，客戶端用 ACK 來確認(rèn)。 下圖圖示了 FTP PORT 模式前幾步步驟： 12 圖 FTP PORT 模式 FTP 的 被動(dòng)模式 (Passive 模式 ) 被動(dòng)模式 被動(dòng)模式和主動(dòng)模式在傳送命令的方式上是一樣的。它們的區(qū)別就在于數(shù)據(jù)的傳輸上。被動(dòng)模式在建立命令傳輸通道后，服 務(wù)端建立一個(gè)綁定到匿名端口的 ServerSocket對(duì)象。并通過命令傳輸通道將這個(gè)匿名端口通知客戶端，然后由客戶端主動(dòng)連接服務(wù)端的這 個(gè)匿名端口。這對(duì)于服務(wù)端就是被動(dòng)的，因此，這種模式叫被動(dòng)模式。如 下 圖 描述了被動(dòng)模式的工作原理。 圖 ftp 被動(dòng)工作原理 現(xiàn)在的大多數(shù) FTP 客戶端軟件的默認(rèn)工作模式都是被動(dòng)模式。因此，這種模式可以克服防火墻等的限制，并且客戶端不需要有固定 ，這就是在服13 務(wù)端要為客戶開大量的端口（大多數(shù) FTP 服務(wù)器開的端口范圍是 1024 ~ 5000，但有的服務(wù)器的范圍達(dá)到 1024 ~ 65535）。這對(duì)于服務(wù)器來說存在著一定的安全隱患。因此，如果可能的話，最好還是采用主動(dòng)模式。 II Passive 模式的 FTP 的步驟 1) 客戶端發(fā)送一個(gè) TCPSYN（ TCP 同步）包給服務(wù)器段眾所周知的 FTP 控制端口 21，客戶端使用暫時(shí)的端口作為它的源端口； 2) 服務(wù)器端發(fā)送 SYNACK（同步確認(rèn)）包給客戶端，源端口為 21，目的端口為客戶端上使用的暫時(shí)端口； 3) 客戶端發(fā)送一個(gè) ACK（確認(rèn)）包；客戶端使用這個(gè)連接來發(fā)送 FTP 命令，服務(wù)器端使用這個(gè)連接來發(fā)送 FTP 應(yīng)答； 4) 當(dāng)用戶請(qǐng)求一個(gè)列表 (List)或者發(fā)送或接收文件時(shí)候，客戶端軟件發(fā)送 PASV 命令給服務(wù)器端表明客戶端希望進(jìn)入 Passive 模式； 5) 服務(wù)器端進(jìn)行應(yīng)答，應(yīng)答包括服務(wù)器的 IP 地址和一個(gè)暫時(shí)的端口，這個(gè)暫時(shí)的端口是客戶端在打開數(shù)據(jù)傳輸連接時(shí)應(yīng)該使用的端口； 6) 客戶端發(fā)送一個(gè) SYN 包，源端口為客戶端自己選擇的一個(gè)暫時(shí)端口，目的端口為服務(wù)器在 PASV 應(yīng)答命令中指定的暫時(shí)端口號(hào)； 7) 服務(wù)器端發(fā)送 SYNACK 包給客戶端， 目的端口為客戶端自己選擇的暫時(shí)端口，源端口為PASV 應(yīng)答中指定的暫時(shí)端口號(hào)； 8) 客戶端發(fā)送一個(gè) ACK 包； 9) 發(fā)送數(shù)據(jù)的主機(jī)以這個(gè)連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以 TCP 段 (注： segment，第 4層的 PDU)形式發(fā)送（一些命令，如 STOR 表示客戶端要發(fā)送數(shù)據(jù)， RETR 表示服務(wù)器段發(fā)送數(shù)據(jù)），這些 TCP 段都需要對(duì)方進(jìn)行 ACK 確認(rèn)； 10) 當(dāng)數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機(jī)以一個(gè) FIN 命令來結(jié)束數(shù)據(jù)連接，這個(gè) FIN 命令需要另一臺(tái)主機(jī)以 ACK 確認(rèn)，另一臺(tái)主機(jī)也發(fā)送一個(gè) FIN 命令，這個(gè) FIN 命令同樣需要發(fā)送數(shù)據(jù)的主機(jī)以 ACK 確認(rèn)； 11) 客戶 端能在控制連接上發(fā)送更多的命令，這可以打開和關(guān)閉另外的數(shù)據(jù)連接；有時(shí)候客戶端結(jié)束后，客戶端以 FIN 命令來關(guān)閉一個(gè)控制連接，服務(wù)器端以 ACK 包來確認(rèn)客戶端的 FIN，服務(wù)器同樣也發(fā)送它的 FIN，客戶端用 ACK 來確認(rèn)。 ftp 的缺陷 在網(wǎng)絡(luò) 上 ,ftp 以明文的方式傳輸數(shù)據(jù) ,明文在網(wǎng)絡(luò)上傳輸是極不安全的 ,所以這就成了 ftp 非常重大的缺陷 .現(xiàn)在通過 sniffer 抓包軟件對(duì) ftp 通行進(jìn)行抓包 ,得到如下