在线视频91,精品无码中文字幕,出租屋勾搭老熟妇啪啪

張靖笙:對(duì)互聯(lián)網(wǎng)協(xié)議標(biāo)準(zhǔn)的分析

精細(xì)化管理

2016-01-20 50519

Internet協(xié)議的分析方法

張靖笙舊作

摘要:本文介紹了Internet的標(biāo)準(zhǔn)協(xié)議和分析方法。介紹Internet協(xié)議文件RFC,并作為舉例分析了FTP協(xié)議

關(guān)鍵字:RFC Internet協(xié)議

前言

近年來,Internet正以令人眩目的速度增長，這個(gè)增長包括Internet這個(gè)網(wǎng)絡(luò)規(guī)模和與之相關(guān)的技術(shù)，規(guī)模的增長帶來Internet技術(shù)的廣泛普及，使其中的如IP,TCP,HTTP,FTP,TELNET,HTML,NNTP等等毫無爭(zhēng)議地成為事實(shí)的標(biāo)準(zhǔn)，同時(shí)又給以上技術(shù)提出新的要求和為其發(fā)展帶來了直接的動(dòng)力；技術(shù)的不斷提高又克服了一個(gè)又一個(gè)網(wǎng)絡(luò)相聯(lián)出現(xiàn)的難題和障礙,技術(shù)和應(yīng)用的相互促進(jìn)，使人類文明能在事實(shí)上的邁入類信息社會(huì)。

隨著Internet的不斷擴(kuò)大，發(fā)展的無序化日益嚴(yán)重，Internet的標(biāo)準(zhǔn)化無疑對(duì)保證Internet及相關(guān)技術(shù)健康發(fā)展起了決定性作用。

在這里作者對(duì)Internet標(biāo)準(zhǔn)組織，Internet標(biāo)準(zhǔn)化過程，Internet標(biāo)準(zhǔn)文件等做個(gè)簡單的介紹，希望能提供給讀者一個(gè)直接快速地深入了解Internet的方法，同時(shí)鼓吹一種深入核心技術(shù)和融入世界規(guī)范的思想。

1 描述Internet協(xié)議的官方文件 RFC(Request For Comment)

1.1 什么是RFC

在Internet的開發(fā)和研究中，產(chǎn)生了一系列技術(shù)協(xié)議(protocol)，而其中一些被Internet的標(biāo)準(zhǔn)化機(jī)構(gòu)采用，解析這些協(xié)議的文件被稱為RFC(request forcomments),中文意思是請(qǐng)求評(píng)注。由于RFC包含了一系列文件，所以下文用RFCs表示這一系列的文件。這些文件是關(guān)于Internet標(biāo)準(zhǔn)的最權(quán)威的定義，是INTERNET OFFICIAL PROTOCOL STANDARDS,參見RFC-2400。

RFCs原本是Internet研究和開發(fā)社團(tuán)--"網(wǎng)絡(luò)工作組"(Network Working Group)的工作筆記，一篇文件可能是關(guān)于計(jì)算機(jī)通訊技術(shù)的一些話題的論文，也可能是關(guān)于確定一個(gè)標(biāo)準(zhǔn)的會(huì)議的報(bào)告。雖然所有標(biāo)準(zhǔn)以RFC的形式公布，但并不是說，所有的RFC文件所描述的協(xié)議都是已經(jīng)確定的Internet標(biāo)準(zhǔn)。下文會(huì)討論到協(xié)議的不同分類。

由于許多RFC文件本身就是技術(shù)文檔，所以它們的技術(shù)參考價(jià)值非常高，而且由于用語規(guī)范，可讀性也非常強(qiáng)。

RFCs是按編寫的時(shí)間順序編號(hào)的，當(dāng)一篇文件成為RFC后，被分配一個(gè)RFC編號(hào)后，這個(gè)編號(hào)不會(huì)被其他文件使用,即使文件修改和重新發(fā)表也不會(huì)使用同一個(gè)RFC編號(hào),所以當(dāng)一個(gè)Internet協(xié)議(如FTP)被改進(jìn)后，可能因而產(chǎn)生RFCs中的許多不同版本的文件，所以當(dāng)您研究一個(gè)協(xié)議時(shí)，注意它在RFCs中的最新版本。

1.2 RFCs是如何產(chǎn)生的

RFCs文檔由Internet中的標(biāo)準(zhǔn)化機(jī)構(gòu)-因特網(wǎng)活動(dòng)委員會(huì)IAB(InternetActivities Board) 負(fù)責(zé)編輯管理和發(fā)表。這里不對(duì)IAB做詳細(xì)介紹，有興趣請(qǐng)參閱RFC-1160 "TheInternet Activities Board"和RFC-1601 "Charter of theInternet Architecture Board (IAB)"。 IAB下屬有因特網(wǎng)工程特別任務(wù)組IETF(Internet Engineering Task Force)和因特網(wǎng)研究特別任務(wù)組IRTF(Internet ResearchTask Force),這兩個(gè)任務(wù)組各有一個(gè)領(lǐng)導(dǎo)組被稱做IESG (Internet EngineeringSteering Group)和IRSG(Internet Research SteeringGroup)。大部分的Internet協(xié)議的開發(fā)和標(biāo)準(zhǔn)化活動(dòng)在IETF的工作組中進(jìn)行。

一篇RFC的發(fā)表必須得到IESG的同意，對(duì)于一些記錄實(shí)驗(yàn)工作的文章，編輯者在發(fā)表前通知了IESG,由相關(guān)的IETF工作組或IRTF研究組檢討并向作者提供評(píng)價(jià)意見。

2 協(xié)議的分類(categorization)

這里有兩個(gè)Internet協(xié)議的分類依據(jù),其中一個(gè)根據(jù)是協(xié)議的成熟程度(maturity level)或在標(biāo)準(zhǔn)化程序中的階段(STATE ofstandardization),分為標(biāo)準(zhǔn)(standard),草案標(biāo)準(zhǔn)(draft standard),被提議的標(biāo)準(zhǔn)(proposed standard),實(shí)驗(yàn)(experimental),情報(bào)(informational),歷史(historic)。另外一個(gè)根據(jù)協(xié)議的需求程度(requirement level)或協(xié)議的地位(STATUS)，分為必需(required),推薦(recommended),可選(elective)，限制使用(limited use)，不推薦(not recommanded)。

在所有情況中，一個(gè)協(xié)議處于以下組合中的一種情況，表格中的X個(gè)數(shù)表示一種組合的可能性大小。一個(gè)新的協(xié)議一般從提議標(biāo)準(zhǔn),可選(proposedstandard,elective)或?qū)嶒?yàn),限制使用(experimental, limited use)開始。

	Required	Recommended	Elective	Limited	Not
Standard	X	XXX	XXX
Draft standard	X	X	XXX
Proposed std		X	XXX
Experimental				XXX
Informational
Historic					XXX

2.1協(xié)議STATE的定義

1)標(biāo)準(zhǔn)協(xié)議(StandardProtocol)

IESG同意這些協(xié)議作為Internet中正式標(biāo)準(zhǔn)協(xié)議，具體包括兩組(1)IP協(xié)議和通用于整個(gè)Internet的其他協(xié)議。(2)特定網(wǎng)絡(luò)協(xié)議(network-specific protocol),一般是如何在特定網(wǎng)絡(luò)實(shí)現(xiàn)IP的說明書。

2)草案標(biāo)準(zhǔn)協(xié)議(DraftStandard Protocol)

IESG正積極地考慮把這些協(xié)議提升為標(biāo)準(zhǔn)協(xié)議(Standard Protocol)。這些協(xié)議還需要嚴(yán)格和廣泛的測(cè)試和評(píng)價(jià),評(píng)價(jià)和測(cè)試結(jié)果會(huì)被提交給IESG，協(xié)議在成為標(biāo)準(zhǔn)協(xié)議時(shí)可能需要修改。

3)被提議標(biāo)準(zhǔn)化的協(xié)議(ProposedStandard Protocol)

這是一些被IESG考慮納入標(biāo)準(zhǔn)化程序的協(xié)議。

4)實(shí)驗(yàn)協(xié)議(ExperimentalProtocol)

一般地，實(shí)驗(yàn)協(xié)議指那些作為一個(gè)研究中項(xiàng)目的一部分，除了一些與該研究有關(guān)的場(chǎng)合，一般不提倡使用，如果后來它們被提議標(biāo)準(zhǔn)化,才進(jìn)入標(biāo)準(zhǔn)化程序。

5)情報(bào)性協(xié)議(InformationalProtocol)

這是一些由其他標(biāo)準(zhǔn)化組織或廠商制定，或由于某種原因協(xié)議的內(nèi)容超出IESG權(quán)限(purview),以RFC的形式發(fā)表只是為了Internet團(tuán)體的檢索方便。

6)歷史協(xié)議(HistoricProtocol)

這是一些因?yàn)楸恍录夹g(shù)淘汰或缺乏興趣發(fā)展而不能成為標(biāo)準(zhǔn)的協(xié)議，保留在RFC中只是作為歷史的見證。

2.2 協(xié)議Status的定義

1)必需協(xié)議(RequiredProtocol)

一個(gè)Internet上的系統(tǒng)(主機(jī)或網(wǎng)關(guān))必需實(shí)現(xiàn)的協(xié)議。

2)推薦協(xié)議(RecommendedProtocol)

一個(gè)Internet上的系統(tǒng)最好能實(shí)現(xiàn)推薦協(xié)議

3)可選協(xié)議(ElectiveProtocol)

一個(gè)Internet上的系統(tǒng)可以實(shí)現(xiàn)也可以不實(shí)現(xiàn)可選協(xié)議，取決于你自己是否愿意實(shí)現(xiàn)。這里可能有幾個(gè)可選協(xié)議在同一個(gè)普通領(lǐng)域，如幾個(gè)電子郵件協(xié)議和幾個(gè)路由協(xié)議。

4)限制使用協(xié)議(LimitedUse Protocol)

這些協(xié)議只在一些限定的環(huán)境內(nèi)應(yīng)用，可能由于他們屬于實(shí)驗(yàn)階段，或只適用在特殊的自然環(huán)境下，或因?yàn)槠涔δ苡邢?，或已?jīng)被淘汰，如歷史協(xié)議。

5)不推薦使用協(xié)議(NotRecommanded Protocol)

這些協(xié)議不被推薦使用。

3 協(xié)議的標(biāo)準(zhǔn)化過程

+<----------------------------------------------+

V 0 | 4

+-----------+ +===========+

| enter |-->----------------+-------------->|experiment |

+-----------+ | +=====+=====+

V 1 |

+-----------+ V

| proposed |-------------->+

+--->+-----+-----+ |

| V 2 |

+<---+-----+-----+ V

| draft std|-------------->+

+--->+-----+-----+ |

| V 3 |

+<---+=====+=====+ V

| standard |-------------->+

+=====+=====+ |

V 5

+=====+=====+

| historic |

+===========+

一個(gè)協(xié)議是否進(jìn)入標(biāo)準(zhǔn)化程序或在標(biāo)準(zhǔn)化程序中由一個(gè)階段(STATE)提升到另一個(gè)階段取決于IESG的推薦。圖中的單線框表示臨時(shí)過渡階段，雙線框表示長期階段，一個(gè)協(xié)議一般保留在一個(gè)臨時(shí)階段數(shù)個(gè)月時(shí)間，proposed standard最少六個(gè)月，draft standard最少四個(gè)月，如果是長期階段則可能保持?jǐn)?shù)年。

圖中從(1)proposed standard階段到(2)draft standard階段，這行動(dòng)只能由IESG決定并且協(xié)議成為proposed standard至少六個(gè)月。

從(2)draft standard到(3)standard也是只能由IESG決定并且協(xié)議成為draft standard至少四個(gè)月。

如果協(xié)議不打算進(jìn)行標(biāo)準(zhǔn)化就會(huì)被放置到(4)experimental階段，該協(xié)議將脫離標(biāo)準(zhǔn)化程序，協(xié)議經(jīng)過進(jìn)一步完善后，需要重新提交加入標(biāo)準(zhǔn)化程序的申請(qǐng)。

有時(shí)一個(gè)協(xié)議被其他協(xié)議取代，或感覺到將要被其他協(xié)議替代，于是成為(5)historic。

4 Internet協(xié)議的分析方法

第一,尋找可以找到RFCs文件的地方

有關(guān)Internet的問題當(dāng)然最好在Internet中找答案,RFCs文件在Internet的許多地方可以找到，根據(jù)本人實(shí)踐，我發(fā)現(xiàn)以下站點(diǎn)對(duì)此組織得不錯(cuò)，資料查找起來非常方便。

https://www.cis.ohio-state.edu/hypertext/information/rfc.html

第二,確定您所研究的協(xié)議的最新版本的RFC文件。

如前文所述，在RFC-2400中有協(xié)議的完整清單，按照清單找到的RFC一般是協(xié)議的最新版本，如果協(xié)議的STATE是Standard就更好了。如下文所分析的FTP協(xié)議的RFC文件是RFC-959。

第三，獲取RFC文件

根據(jù)RFC文件編號(hào)查看以上站點(diǎn)的RFCs文件索引

https://www.cis.ohio-state.edu/htbin/rfc/INDEX.rfc.html

在里面您可以很快地找到您要找的RFC文件。

第四,閱讀描述協(xié)議的RFC文件全文

這不用說了。

第五，實(shí)踐

實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)，雖然Internet協(xié)議不是什么真理，但如果能實(shí)踐一下對(duì)理解和掌握都有好處，許多Internet應(yīng)用層的協(xié)議可視程度非常高，協(xié)議中許多控制和參數(shù)用英文短語來表示，所傳輸?shù)臄?shù)據(jù)如文本也是ASCII碼，如HTTP,FTP等,這類協(xié)議單純用Telnet就可以模擬一下客戶端程序的運(yùn)作，當(dāng)然，編程實(shí)現(xiàn)是最好的鍛煉。

第六,總結(jié)

總結(jié)確實(shí)是不錯(cuò)的學(xué)習(xí)方法，自己的文章是一面鏡子。

5.舉例:FTP協(xié)議分析

FTP協(xié)議的定義在 RFC-959 "FILE TRANSFERPROTOCOL"(Standard, Recommended)。

5.1介紹

FTP 文件傳輸協(xié)議 (FileTransfer Protocol)

FTP協(xié)議是一個(gè)應(yīng)用層協(xié)議，在TCP上實(shí)現(xiàn)的。

開發(fā)FTP的目的是

1)促進(jìn)文件(計(jì)算機(jī)程序和/或數(shù)據(jù))的共享。

2)鼓勵(lì)對(duì)遠(yuǎn)程計(jì)算機(jī)間接或隱式(implicit)(通過程序)的使用。

3)對(duì)用戶屏蔽不同主機(jī)系統(tǒng)中的文件儲(chǔ)存的細(xì)節(jié)。

4)可靠和高效率地實(shí)現(xiàn)文件的傳送。

用戶雖然可以直接通過一個(gè)終端使用FTP協(xié)議,但FTP協(xié)議的設(shè)計(jì)主要是給程序使用的。

5.2 FTP模型圖

-------------

|/---------\|

|| User || --------

||Interface|<--->| User |

|\----^----/| --------

---------- | | |

|/------\| FTP Commands |/----V----\|

||Server|<---------------->| User ||

|| PI || FTP Replies || PI ||

|\--^---/| |\----^----/|

| | | | | |

-------- |/--V---\| Data |/----V----\| --------

| File |<--->|Server|<---------------->| User |<--->| File |

|System| || DTP || Connection || DTP || |System|

-------- |\------/| |\---------/| --------

---------- -------------

Server-FTP USER-FTP

注: 1. 圖中的 data connection 可以被雙向使用。

2. data connection不需要任何時(shí)間都存在。

5.3 術(shù)語解析

為了描述上的準(zhǔn)確，有關(guān)FTP術(shù)語出現(xiàn)的地方基本引用其英文原文，這里給出相應(yīng)的中文解釋，僅僅為了方便讀者的理解。為了檢索方便，這里的術(shù)語是按照其原英文順序排列，一些前面沒有解析的術(shù)語請(qǐng)?jiān)诤竺嬲摇?/p>

control connection 控制(信息)連接

USER-PI和SERVER-PI之間交換FTP命令和回應(yīng)的通信通道，連接中傳送的信息符合Telnet協(xié)議(RFC-854)中的約定，在整個(gè)FTP使用過程中，控制連接是一直保持的。

data connection 數(shù)據(jù)連接

數(shù)據(jù)傳送中使用的全雙工連接，數(shù)據(jù)傳送有特定模式(mode)和類型(type)。這里所說的數(shù)據(jù)可能是一個(gè)文件的一部分，或一整個(gè)文件或多個(gè)文件。連接可能是Server-DTP和User-DTP之間，或兩個(gè)Server-DTPs之間，數(shù)據(jù)連接在需要傳送數(shù)據(jù)時(shí)才需要建立。

data port 數(shù)據(jù)端口

當(dāng)有一個(gè)數(shù)據(jù)傳送的要求時(shí)，DTP在數(shù)據(jù)端口監(jiān)聽，等待對(duì)方發(fā)來的連接請(qǐng)求以建立連接。

data structures 數(shù)據(jù)結(jié)構(gòu)

除了數(shù)據(jù)類型(TYPE)外，FTP允許指定一個(gè)傳送中文件的結(jié)構(gòu)，以便決定Server-FTP對(duì)文件的處理方式。在FTP中定義有三種文件結(jié)構(gòu)。

file structure:文件沒有內(nèi)部結(jié)構(gòu)，是一個(gè)連續(xù)的數(shù)據(jù)字節(jié)序列。

record structure:文件數(shù)據(jù)按記錄形式組織，文件由連續(xù)的記錄組成。

page structure:文件由獨(dú)立的含索引的數(shù)據(jù)頁組成。

DTP （data transfer process) 數(shù)據(jù)傳送進(jìn)程

數(shù)據(jù)傳送進(jìn)程建立數(shù)據(jù)連接(data connection)和進(jìn)行文件數(shù)據(jù)的傳送。

FTP commands FTP命令集

FTP命令集是由User-FTP發(fā)給Server-FTP的請(qǐng)求命令組成的集合。

mode(傳輸)模式

數(shù)據(jù)通過數(shù)據(jù)連接(data connection)傳輸數(shù)據(jù)的模式,模式定義了數(shù)據(jù)在傳輸中的格式，有以下三種。

stream mode 流模式

文件以字符流的形式傳輸，數(shù)據(jù)在表示類型上沒有限制。

block mode 塊模式

文件以數(shù)據(jù)塊的模式按順序傳輸，每個(gè)塊的開頭的含表達(dá)控制信息的字節(jié)。

compressed mode 壓縮模式

傳輸?shù)臄?shù)據(jù)按照一定的格式被壓縮。

模式用MODE命令設(shè)置，一般缺省情況是stream。

PI (protocolinterpreter)協(xié)議解釋器

如上圖所示，PI是用戶端和服務(wù)器端實(shí)現(xiàn)和解釋FTP協(xié)議的部分，具體在用戶端(User-PI)實(shí)現(xiàn)FTP命令(FTP command)的發(fā)送和回應(yīng)的解釋，在服務(wù)器端實(shí)現(xiàn)FTP命令的解釋執(zhí)行和回應(yīng)(reply)的返回。一般的常見FTP客戶端軟件(User-PI)上還有用戶界面(User-Interface)，普通用戶不用直接面對(duì)FTP命令和回應(yīng)。實(shí)際例子中，簡單的用戶界面如現(xiàn)在各種操作系統(tǒng)提供的ftp程序的命令交互,復(fù)雜如諸如Bullet FTP,Cute FTP等產(chǎn)品的圖形界面。最簡單的情況可用Telnet程序來使用，但缺點(diǎn)是沒法產(chǎn)生User-DTP,所以實(shí)際上無法直接實(shí)現(xiàn)數(shù)據(jù)的傳送。

reply回應(yīng)

一個(gè)回應(yīng)是一個(gè)從服務(wù)器傳送到客戶端的對(duì)FTP命令執(zhí)行情況的反饋(肯定或否定)?；貞?yīng)的一般格式是一個(gè)3位數(shù)字編碼后面跟著一句文字串。

server-DTP

服務(wù)器端的數(shù)據(jù)傳送進(jìn)程,User-FTP和Server-FTP之間數(shù)據(jù)連接建立過程中，Server-DTP一般充當(dāng)請(qǐng)求連接的一方。在兩個(gè)Server-FTP之間則其中一個(gè)充當(dāng)被動(dòng)監(jiān)聽，另外一個(gè)充當(dāng)主動(dòng)請(qǐng)求連接。具體由與它們相連的User-FTP發(fā)來的FTP命令決定。

server-PI

服務(wù)端的協(xié)議解釋器，在端口21監(jiān)聽等待User-PI請(qǐng)求建立控制連接(control connection)。和User-PI建立連接后，Server-PI接收user-PI發(fā)來的FTP命令,解析執(zhí)行命令,發(fā)送回應(yīng),和有數(shù)據(jù)傳送要求時(shí)管理server-DTP。

type類型

由于不同類型的主機(jī)的數(shù)據(jù)表達(dá)方式不同，如IBM S390用EBCDIC碼，普通PC用ASCII碼，為了使不同類型的主機(jī)能實(shí)現(xiàn)文件的交換，在傳送過程中的數(shù)據(jù)類型應(yīng)該是確定的，類型的設(shè)置暗示了數(shù)據(jù)由儲(chǔ)存中到傳送的轉(zhuǎn)換規(guī)則(transformation)。FTP中有以下類型。

ASCII TYPE

這是比較通用的類型，表示發(fā)送的是字符文件，且在文件傳送過程中數(shù)據(jù)使用ASCII碼表示。發(fā)送者會(huì)把按內(nèi)部字符表表示的數(shù)據(jù)轉(zhuǎn)換成標(biāo)準(zhǔn)的八位NVT-ASCII碼。

EBCDIC TYPE

文件傳送過程中使用EBCDIC碼。

IMAGE TYPE

傳送的數(shù)據(jù)按照連續(xù)的位流傳送，為了傳輸上的方便，數(shù)據(jù)被封裝為八位的字節(jié)單位，不足8位的補(bǔ)零。比較常見的稱呼是二進(jìn)制數(shù)據(jù)(binary data)。

LOCAL TYPE

傳送的數(shù)據(jù)按照發(fā)送方所在主機(jī)的字符表示傳送，在一些主機(jī)中一個(gè)字可能是大于8位的，則對(duì)齊成8的倍數(shù),如一個(gè)36位字符轉(zhuǎn)換64位，即8個(gè)字節(jié)，兩個(gè)36位字符轉(zhuǎn)換成72位，即9個(gè)字節(jié)。

user-DTP

當(dāng)有數(shù)據(jù)傳送要求時(shí)，用戶端的數(shù)據(jù)傳送進(jìn)程在數(shù)據(jù)端口監(jiān)聽，等待服務(wù)器端DTP的連接請(qǐng)求。

user-PI

用戶端的協(xié)議解釋器,負(fù)責(zé)向Server-PI請(qǐng)求建立控制連接，發(fā)送FTP命令，在文件傳輸過程中管理user-DTP。

5.4常用的FTP命令解釋

由于篇幅所限，這里不對(duì)以上每個(gè)FTP命令做解釋，這里僅解釋一下作者認(rèn)為比較重要或常用的FTP命令，如果讀者需要深入了解請(qǐng)參閱 RFC-959 "FILETRANSFER PROTOCOL"。

USER NAME(USER〈sp〉〈username〉)

本命令的參數(shù)〈username〉標(biāo)識(shí)用戶名，服務(wù)器憑這個(gè)用戶的權(quán)限使用文件系統(tǒng)。這個(gè)命令一般是在控制連接后的第一個(gè)命令。這個(gè)命令成功執(zhí)行后，服務(wù)器會(huì)等待PASS命令，PASS也成功執(zhí)行后，用戶才算等錄成功，可以存取Server-FTP中的文件。

PASSWORD(PASS〈sp〉〈password〉)

這個(gè)命令是USER命令的補(bǔ)充，向Server-FTP發(fā)送由〈password〉所表示的密碼，該命令執(zhí)行成功，USER命令所指示的〈username〉才算成功登錄。這里的〈password〉是明文傳送。

CHANGE WORKING DIRECTORY(CWD〈SP〉〈pathname〉)

令Server-FTP改變當(dāng)前目錄到〈pathname〉。

LOGOUT(QUIT)

這個(gè)命令表示用戶停止使用FTP, Server-FTP會(huì)關(guān)閉控制連接。

DATA PORT(PORT 〈SP〉〈host-port〉)

User-FTP這個(gè)命令告訴Server-FTP，等待Server-DTP連接的DTP(可能是User-DTP或其他的Server-DTP）的地址,〈host-port〉所指示的就是這個(gè)地址，具體的PORT命令形式如下。

PORT h1,h2,h3,h4,p1,p2

以上六個(gè)參數(shù)都是小于256的數(shù)字。

h1,h2,h3,h4表示IP地址,如192,168,0,1 表示IP地址是192.168.0.1的主機(jī)。

p1,p2,表示端口號(hào)，注意p1和p2都是小于256，所以1000表示為3,232(1000=3*256+232)

RETRIEVE(RETR〈SP〉〈pathname〉)

這個(gè)命令請(qǐng)求Server-FTP通過數(shù)據(jù)連接向User-DTP傳送由〈pathname〉指示的文件的數(shù)據(jù)。

STOR(RETR 〈SP〉〈pathname〉)

這個(gè)命令請(qǐng)求Server-FTP通過數(shù)據(jù)連接接收User-DTP傳送的數(shù)據(jù)，數(shù)據(jù)保存在由〈pathname〉指示的文件中。注意〈pathname〉是在Server-FTP的主機(jī)上的。

PRINT WORKING DIRECTORY(PWD)

Server-FTP收到該命令后在回應(yīng)中返回當(dāng)前工作目錄名。

LIST(LIST [〈SP〉〈pathname〉])

Server-FTP收到該命令后向User-DTP發(fā)送目錄〈pathname〉的文件目錄信息。如果沒有〈pathname〉參數(shù)，則返回當(dāng)前目錄的文件目錄信息。

STATUS(STAT [〈SP〉〈pathname〉])

這個(gè)命令的回應(yīng)有兩種情況，沒有〈pathname〉參數(shù)和有〈pathname〉參數(shù)。

1)沒有參數(shù)，Server-FTP會(huì)在回應(yīng)中返回的一些狀態(tài)信息，如以下是我Linux上的Server-FTP返回的信息:

211-zfm.home FTP server status:

Versionwu-2.4.2-VR17(1) Mon Apr 19 09:21:53 EDT 1999

Connected to zfl_k6.home (192.168.0.1)

Logged in as fszfl

TYPE: ASCII, FORM: Nonprint; STRUcture:File; transfer MODE: Stream

No data connection

0data bytes received in 0 files

0 data bytes transmitted in 0 files

0 data bytes total in 0 files

145 traffic bytes received in 0 transfers

4306 traffic bytes transmitted in 0transfers

4501 traffic bytes total in 0 transfers

211 End of status

2)如果有〈pathname〉參數(shù)，則在回應(yīng)中返回〈pathname〉的目錄信息，如以下是我發(fā)送STAT . 的結(jié)果:

213-statusof .:

total 64

drwxrwxr-x 2 fszfl fszfl 1024 Nov 25 01:37.

drwx------ 12 fszfl fszfl 1024 Nov 29 00:35 ..

213 End of Status

這個(gè)功能好象和LIST有點(diǎn)相似，但LIST中的目錄信息在數(shù)據(jù)連接中返回的。

HELP [〈SP〉〈string〉]

這是幫助命令，如果沒有參數(shù)則返回FTP命令列表，如果有參數(shù)則返回〈string〉表示的命令的語法。

5.5 FTP回應(yīng)

5.5.1 回應(yīng)的格式

FTP回應(yīng)有3位數(shù)字編碼和有關(guān)信息的文本組成,編碼后一個(gè)分隔符，如果回應(yīng)中返回信息的長度大于一行，則編碼后跟減號(hào)(-),否則跟空格(〈sp〉)。多于一行的信息可以參考上面的例子。注意最后還有"213End of Status"表示信息的結(jié)束。FTP回應(yīng)使用的編碼是約定好的，信息文本可以由具體的Server-FTP設(shè)計(jì)。顯然，編碼為了方便程序設(shè)計(jì)，文本信息可以方便閱讀。

為了敘述方便，下文把這3位編碼稱為回應(yīng)碼。

5.5.2 回應(yīng)碼含義

3位回應(yīng)碼的每一位都有確定的含義。第一位表示命令的執(zhí)行結(jié)果，表示成功，失敗，或命令沒有完成。第二位表示回應(yīng)的類型，第三位一般指第二位的進(jìn)一步細(xì)化，預(yù)留給將來的發(fā)展。

第1位可能的取值：

1yz 初步確認(rèn) (Positive Preliminary reply)

表示請(qǐng)求的命令已經(jīng)開始，請(qǐng)等待進(jìn)一步的回應(yīng)，在此之前不要發(fā)送新的FTP命令。

2yz 完成確認(rèn) (Positive Completion reply)

表示請(qǐng)求的命令已經(jīng)成功完成，可以發(fā)送新的請(qǐng)求。

3yz 中間狀態(tài)確認(rèn)(Positive Intermediate reply)

請(qǐng)求的命令已經(jīng)被接受，等待下一條相關(guān)的命令提供進(jìn)一步的信息。這個(gè)回應(yīng)用于一些命令序列中，如USER和PASS，如果USER被接受則可以得到這個(gè)回應(yīng)，表明還需要密碼來完成用戶的登錄。

4yz 暫時(shí)否認(rèn) (Transient Negative Completionreply)

Server-FTP由于一些暫時(shí)的原因沒有接收命令，User-FTP最好重新請(qǐng)求這個(gè)命令。如果是命令序列，則需要從該序列的第一條指令開始。

5yz 命令有錯(cuò) (Permanent Negative Completionreply)

命令沒有被接收，具體的拒絕原因由回應(yīng)碼第二位指出。

第2位可能的取值，描述回應(yīng)的分類：

x0z 語法(Syntax) - 命令語法不正確，或Server-FTP沒有實(shí)現(xiàn)這個(gè)功能。

x1z 信息(Information) - 描述如STAT或HELP等命令要求Server-FTP信息的返回。

x2z 連接(Connections) - 描述有關(guān)控制和數(shù)據(jù)連接。

x3z 帳戶和認(rèn)證(Authentication and accounting)- 登錄過程的回應(yīng)。

x4z 現(xiàn)在還沒有指定。

x5z 文件系統(tǒng)(File system) - 這個(gè)回應(yīng)反映服務(wù)器的文件系統(tǒng)的狀態(tài)。

第3位的的含義需要根據(jù)第1,2位的值再細(xì)化。

5.5.3 回應(yīng)舉例

3位回應(yīng)碼的不同組合產(chǎn)生了許多不同的含義，篇幅所限不一一列舉，具體請(qǐng)查 RFC-959。下面是幾個(gè)例子：

200 Command okay.

500 Syntax error, command unrecognized.

501 Syntax error in parameters or arguments

5.6 FTP舉例

以下給出一個(gè)實(shí)際的例子，FTP客戶端用隨Windows98提供ftp,FTP服務(wù)器用Sco Unix 5.0.4,其中的'------〉'表示客戶端發(fā)給服務(wù)器的命令，'〈--------'表示服務(wù)器的回應(yīng)，〈CR〉表示回車，〈CRLF〉表示回車換行。