RFC简介
原文地址：http://blog.csdn.net/doupei2006/article/details/7252214
1 RFC的簡(jiǎn)介
1.1 RFC歷史及概況
RFC文檔也稱請(qǐng)求注解文檔（Requests for Comments，RFC），這是用于發(fā)布Internet標(biāo)準(zhǔn)和Internet其他正式出版物的一種網(wǎng)絡(luò)文件或工作報(bào)告。RFC文檔初創(chuàng)于1969年，RFC出版物由RFC編輯（RFC Editor）直接負(fù)責(zé)，并接受IAB的一般性指導(dǎo)。現(xiàn)在已經(jīng)有3000多個(gè)RFC系列文件，并且這個(gè)數(shù)目還在不斷增加, 內(nèi)容和Internet (開始叫做為ARPANET)相關(guān)。草案討論了計(jì)算機(jī)通訊的方方面面，重點(diǎn)在網(wǎng)絡(luò)協(xié)議，過程，程序，以及一些會(huì)議注解，意見，風(fēng)格方面的概念。RFC編輯者負(fù)責(zé)RFCs 以及RFCs的整體結(jié)構(gòu)文檔，并維護(hù)RFCs的索引。Internet協(xié)議族的文檔部分（由Internet工程委員會(huì)IETF以及IETF下屬的管理組IESG 定義），也做為RFC文檔出版。因此，RFC在Internet相關(guān)標(biāo)準(zhǔn)中有著重要的地位。
RFC編輯者的職責(zé)是由Internet 中的大家提議形成的，所出版的語(yǔ)言也就和Internet一樣。IETF and the ISOC是代表了世界各地的國(guó)際性組織，英語(yǔ)是IETF的第一工作語(yǔ)言，也是IETF的正式出版語(yǔ)言。RFC 2026 "The Internet Standards Process -- Revision 3" 允許RFCs翻譯成其他不同的語(yǔ)言。但是不能保證其翻譯版本是否正確。因此，RFC編輯不對(duì)非英語(yǔ)的版本負(fù)責(zé)，而只是指明了哪里有非英語(yǔ)的版本，將這些信息列在WEB頁(yè)上。
1.2 RFC處理過程
一個(gè)RFC文件在成為官方標(biāo)準(zhǔn)前一般至少要經(jīng)歷三個(gè)階段：建議標(biāo)準(zhǔn)、草案標(biāo)準(zhǔn)、因特網(wǎng)標(biāo)準(zhǔn)。在Internet上，任何一個(gè)用戶都可以對(duì)Internet某一領(lǐng)域的問題提出自己的解決方案或規(guī)范，作為Internet草案（Internet Draffs，ID）提交給Internet工程任務(wù)組（IETF）。草案存放在美國(guó)、歐洲和亞太地區(qū)的工作文件站點(diǎn)上，供世界多國(guó)自愿參加的IETF成員進(jìn)行討論、測(cè)試和審查。最后，由Internet工程指導(dǎo)組（IESG）確定該草案是否能成為Internet的標(biāo)準(zhǔn)。
如果一個(gè)Internet草案在IETF的相關(guān)站點(diǎn)上存在6個(gè)月后仍未被IESG建議作為標(biāo)準(zhǔn)發(fā)布，則它將被從上述站點(diǎn)中刪除。事實(shí)上，在任何時(shí)候，一個(gè)Internet 草案都有可能被新的草案版本所替換掉，并重新開始6個(gè)月的存放期。
如果一個(gè)Internet草案被IESG確定為Internet的正式工作文件，則被提交給Internet體系結(jié)構(gòu)委員會(huì)（IAB），并形成具有順序編號(hào)的RFC文檔，由Internet協(xié)會(huì)（ISOC）通過Internet向全世界頒布。每個(gè)Internet標(biāo)準(zhǔn)文件在被批準(zhǔn)后都會(huì)分配一個(gè)獨(dú)立于RFC的永久編號(hào)，這就是STD編號(hào)。有一個(gè)不斷被更新的文件RFC-INDEX.TXT按照RFC的編號(hào)來索引所有的文件，對(duì)于因特網(wǎng)標(biāo)準(zhǔn)文件還列出了其相應(yīng)的STD編號(hào)。
RFC文檔必須被分配RFC編號(hào)后才能在網(wǎng)絡(luò)上發(fā)布。例如，RFC2026的內(nèi)容是“Internet標(biāo)準(zhǔn)進(jìn)程-修訂版3”、RFC1543的內(nèi)容為“RFC作者指導(dǎo)”等等。需要時(shí)，可以復(fù)制或打印這些聯(lián)機(jī)文檔。用戶也可以通過遍布全世界的數(shù)個(gè)聯(lián)機(jī)資料數(shù)據(jù)庫(kù)中獲得RFC文檔。例如，可以使用路徑名RFC/RFCnnnn.TXT通過FTP的方式從ds.internic.net站點(diǎn)獲得RFC，其中“nnnn”指的是RFC的編號(hào)。在這里，使用FTP登錄時(shí)，所用的用戶名和口令分別為“anonymous”和你的電子郵件地址。此外，用戶還可以通過Internet網(wǎng)絡(luò)信息中心（InterNIC）的目錄服務(wù)功能、電子郵件、WWW等方式獲得RFC文檔.
????作為標(biāo)準(zhǔn)的RFC又分為幾種，第一種是提議性的，就是說建議采用這個(gè)作為一個(gè)方案擺出來，Draft是已經(jīng)有一部分在用了，希望被采用為正式的標(biāo)準(zhǔn)，還有一種就是完全被認(rèn)可的標(biāo)準(zhǔn)，這種是大家都在用，而且是不應(yīng)該改變的。還有一種就是現(xiàn)在的最佳實(shí)踐法，它相當(dāng)于一種介紹。這些文件產(chǎn)生的過程是一種從下往上的過程，而不是從上往下，也就是說不是一個(gè)由主席，或者由工作組負(fù)責(zé)人的給一個(gè)指令，說是要做什么，要做什么，而是有下邊自發(fā)的提出，然后在工作組里邊討論，討論了以后再交給剛才說的工程指導(dǎo)委員會(huì)進(jìn)行審查。但是工程指導(dǎo)委員會(huì)只做審查不做修改，修改還是要打回到工作組來做。IETF工作組文件的產(chǎn)生就是任何人都可以來參加會(huì)議，任何人都可以提議，然后他和別人進(jìn)行討論，大家形成了一個(gè)共識(shí)就可以產(chǎn)出這樣的文件。
2 RFC的內(nèi)容
2.1 RFC的分類
根據(jù)RFC被公布時(shí)的狀態(tài)可以把RFC索引劃分成幾類：Standards(標(biāo)準(zhǔn))；Draft Standards(草案標(biāo)準(zhǔn))；Proposed Standards(提案標(biāo)準(zhǔn))。每個(gè)分類具體的內(nèi)容見： www.rfc-editor.org。
2.2 與計(jì)算機(jī)網(wǎng)絡(luò)有關(guān)的RFC
2.2.1 應(yīng)用層協(xié)議 FTP (RFC 959)
??文件傳送協(xié)議FTP（File Transfer Protocol）是Internet文件傳送的基礎(chǔ)。通過該協(xié)議，用戶可以從一個(gè)Internet主機(jī)向另一個(gè)Internet主機(jī)拷貝文件。與大多數(shù)Internet服務(wù)一樣，FTP也是一個(gè)客戶機(jī)/服務(wù)器系統(tǒng)。用戶通過一個(gè)支持FTP協(xié)議的客戶機(jī)程序，連接到在遠(yuǎn)程主機(jī)上的FTP服務(wù)器程序。用戶通過客戶機(jī)程序向服務(wù)器程序發(fā)出命令，服務(wù)器程序執(zhí)行用戶所發(fā)出的命令，并將執(zhí)行的結(jié)果返回到客戶機(jī)。比如說，用戶發(fā)出一條命令，要求服務(wù)器向用戶傳送某一個(gè)文件的一份拷貝，服務(wù)器會(huì)響應(yīng)這條命令，將指定文件送至用戶的機(jī)器上?？蛻魴C(jī)程序代表用戶接收到這個(gè)文件，將其存放在用戶目錄中。
HTTP (RFC 1945)
???HTTP協(xié)議（Hypertext Transfer Protocol，中文稱“超文本傳輸協(xié)議”）是用來在Internet上傳送超文本的傳送協(xié)議。它是運(yùn)行在TCP/IP協(xié)議族之上的HTTP應(yīng)用協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。任何服務(wù)器除了包括HTML文件以外，還有一個(gè)HTTP駐留程序，用于響應(yīng)用戶請(qǐng)求。瀏覽器是HTTP客戶，向服務(wù)器發(fā)送請(qǐng)求，當(dāng)瀏覽器中輸入了一個(gè)開始文件或點(diǎn)擊了一個(gè)超級(jí)鏈接時(shí)，瀏覽器就向服務(wù)器發(fā)送了HTTP請(qǐng)求，此請(qǐng)求被送往由IP地址指定的URL。駐留程序接收到請(qǐng)求，在進(jìn)行必要的操作后回送所要求的文件。
SMTP (RFC 821/822)
????SMTP(Simple Mail Transfer Protocol)是一組規(guī)則，用于由源地址至目的地址傳送電子郵件。每一個(gè)想接收電子郵件的主機(jī)都安裝了SMTP服務(wù)器。當(dāng)主機(jī)由用戶接收了電子郵件并想傳遞到另外一臺(tái)服務(wù)器，則它聯(lián)絡(luò)SMTP服務(wù)器。SMTP服務(wù)器會(huì)作出反應(yīng)，顯示確認(rèn)、錯(cuò)誤消息或特定的請(qǐng)求信息。其中RFC821定義了SMTP標(biāo)準(zhǔn)，RFC822定義了SMTP消息格式。
POP3 (RFC 1081)
??? POP3(Post Office Protocol 3)協(xié)議通常被用來接收電子郵件。這個(gè)協(xié)議很簡(jiǎn)單，因?yàn)樗话?2個(gè)命令。這些命令被客戶端計(jì)算機(jī)用來發(fā)送給遠(yuǎn)程服務(wù)器。反過來，服務(wù)器返回給客戶端計(jì)算機(jī)兩個(gè)回應(yīng)代碼。
Telnet (RFC854)
????TELNET Protocol的目的是提供一個(gè)相對(duì)通用的，雙向的，面向八位字節(jié)的通信方法。它主要的目標(biāo)是允許接口終端設(shè)備的標(biāo)準(zhǔn)方法和面向終端的相互作用。
2.2.2 傳輸層協(xié)議
TCP (RFC 793)
????傳輸控制協(xié)議（Transmission Control Protocol）是為了在主機(jī)間實(shí)現(xiàn)高可靠性的包交換傳輸協(xié)議。TCP協(xié)議主要在網(wǎng)絡(luò)不可靠的時(shí)候完成通信。它支持多種網(wǎng)絡(luò)應(yīng)用程序。TCP對(duì)下層服務(wù)沒有多少要求，它假定下層只能提供不可靠的數(shù)據(jù)報(bào)服務(wù)，它可以在多種硬件構(gòu)成的網(wǎng)絡(luò)上運(yùn)行。TCP可以根據(jù)IP協(xié)議提供的服務(wù)傳送大小不定的數(shù)據(jù)，IP協(xié)議負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行分段，重組，在多種網(wǎng)絡(luò)中傳送，因此TCP協(xié)議則提供了一個(gè)可靠的、可流控的、全雙工的信息流傳輸服務(wù)。
UDP （RFC 786）
????UDP（用戶數(shù)據(jù)報(bào)協(xié)議--User Datagram Protocol）是TCP/IP協(xié)議集中等同于TCP的通信協(xié)議。UDP直接利用IP協(xié)議進(jìn)行UDP數(shù)據(jù)報(bào)的傳輸，因此UDP提供的是無連接、不可靠的數(shù)據(jù)報(bào)投遞服務(wù)。UDP常用于數(shù)據(jù)量較少的數(shù)據(jù)傳輸，例如：域名系統(tǒng)中域名地址/IP地址的映射請(qǐng)求和應(yīng)答（Named)，Ping 、BOOTP、TFTP等應(yīng)用。在少量數(shù)據(jù)的傳輸時(shí)，使用UDP協(xié)議傳輸信息流，可以減少TCP連接的過程，提高工作效率。當(dāng)使用UDP協(xié)議傳輸信息流時(shí)，用戶應(yīng)用程序必須負(fù)責(zé)解決數(shù)據(jù)報(bào)排序，差錯(cuò)確認(rèn)等問題。
2.2.3 網(wǎng)絡(luò)層協(xié)議
IP （RFC 791）
????Internet 上使用的一個(gè)關(guān)鍵的低層協(xié)議是網(wǎng)際協(xié)議，通常稱IP協(xié)議。我們利用一個(gè)共同遵守的IP協(xié)議，從而使 Internet 成為一個(gè)允許連接不同類型的計(jì)算機(jī)和不同操作系統(tǒng)的網(wǎng)絡(luò)。網(wǎng)際協(xié)議IP協(xié)議提供了能適應(yīng)各種各樣網(wǎng)絡(luò)硬件的靈活性，對(duì)底層網(wǎng)絡(luò)硬件幾乎沒有任何要求，任何一個(gè)網(wǎng)絡(luò)只要可以從一個(gè)地點(diǎn)向另一個(gè)地點(diǎn)傳送二進(jìn)制數(shù)據(jù)，就可以使用IP協(xié)議加入 Internet 了。IP協(xié)議對(duì)于網(wǎng)絡(luò)通信有著重要的意義：網(wǎng)絡(luò)中的計(jì)算機(jī)通過安裝IP軟件，使許許多多的局域網(wǎng)絡(luò)構(gòu)成了一個(gè)龐大而又嚴(yán)密的通信系統(tǒng)。從而使 Internet 看起來好像是真實(shí)存在的，但實(shí)際上它是一種并不存在的虛擬網(wǎng)絡(luò)，只不過是利用IP協(xié)議把全世界上所有愿意接入 Internet 的計(jì)算機(jī)局域網(wǎng)絡(luò)連接起來，使得它們彼此之間都能夠通信。??????????
ICMP （RFC2236）
????ICMP（Internet Control Message Protocol”，Internet控制消息協(xié)議）是TCP/IP協(xié)議族的一個(gè)子協(xié)議，用于在IP主機(jī)、路由器之間傳遞控制消息?？刂葡⑹侵妇W(wǎng)絡(luò)通不通、主機(jī)是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息。這些控制消息雖然并不傳輸用戶數(shù)據(jù)，但是對(duì)于用戶數(shù)據(jù)的傳遞起著重要的作用。
ARP(RFC 826)
在TCP/IP網(wǎng)絡(luò)環(huán)境下，每個(gè)主機(jī)都分配了一個(gè)32位的IP地址，這種互連網(wǎng)地址是在國(guó)際范圍標(biāo)識(shí)主機(jī)的一種邏輯地址。為了讓報(bào)文在物理網(wǎng)上傳送，必須知道彼此的物理地址。這樣就存在把互連網(wǎng)地址變換為物理地址的地址轉(zhuǎn)換問題。以以太網(wǎng)(Ethernet)環(huán)境為例，為了正確地向目的站傳送報(bào)文，必須把目的站的32位IP地址轉(zhuǎn)換成48位以太網(wǎng)目的地址DA。這就需要在網(wǎng)絡(luò)層有一組服務(wù)將IP地址轉(zhuǎn)換為相應(yīng)物理網(wǎng)絡(luò)地址，這組協(xié)議即是ARP。
在進(jìn)行報(bào)文發(fā)送時(shí)，如果源網(wǎng)絡(luò)層給的報(bào)文只有IP地址，而沒有對(duì)應(yīng)的以太網(wǎng)地址，則網(wǎng)絡(luò)層廣播ARP請(qǐng)求以獲取目的站信息，而目的站必須回答該ARP請(qǐng)求。這樣源站點(diǎn)可以收到以太網(wǎng)48位地址，并將地址放入相應(yīng)的高速緩存(cache)。下一次源站點(diǎn)對(duì)同一目的站點(diǎn)的地址轉(zhuǎn)換可直接引用高速緩存中的地址內(nèi)容。地址轉(zhuǎn)換協(xié)議ARP使主機(jī)可以找出同一物理網(wǎng)絡(luò)中任一個(gè)物理主機(jī)的物理地址，只需給出目的主機(jī)的IP地址即可。這樣，網(wǎng)絡(luò)的物理編址可以對(duì)網(wǎng)絡(luò)層服務(wù)透明?！?/p>
RARP(RFC 903)
????RARP(反向地址轉(zhuǎn)換協(xié)議)用于一種特殊情況，如果站點(diǎn)初始化以后，只有自己的物理地址而沒有IP地址，則它可以通過RARP協(xié)議，發(fā)出廣播請(qǐng)求，征求自己的IP地址，而RARP服務(wù)器則負(fù)責(zé)回答。這樣，無IP地址的站點(diǎn)可以通過RARP協(xié)議取得自己的IP地址，這個(gè)地址在下一次系統(tǒng)重新開始以前都有效，不用連續(xù)廣播請(qǐng)求。RARP廣泛用于獲取無盤工作站的IP地址。
2.2.4鏈路層協(xié)議
PPP協(xié)議（RFC1661）
PPP協(xié)議是一種有效的點(diǎn)一點(diǎn)通信協(xié)議，它由串行通信線路上的組幀方式，用于建立、配制、測(cè)試和拆除數(shù)據(jù)鏈路的鏈路控制協(xié)議LCP及一組用以支持不同網(wǎng)絡(luò)層協(xié)議的網(wǎng)絡(luò)控制協(xié)議NCPs三部分組成。
由于PPP幀中設(shè)置了校驗(yàn)字段，因而PPP在鏈路層上具有差錯(cuò)檢驗(yàn)的功能。PPP中的LCP協(xié)議提供了通信雙方進(jìn)行參數(shù)協(xié)商的手段，并且提供了一組NCPs協(xié)議，使得PPP可以支持多種網(wǎng)絡(luò)層協(xié)議，如IP、IPX、OSI等。另外，支持IP的NCP提供了在建立連接時(shí)動(dòng)態(tài)分配IP地址的功能，解決了個(gè)人用戶上Internet的問題。
SLIP協(xié)議（RFC1055）
SLIP提供在串行通信線路上封裝IP分組的簡(jiǎn)單方法，用以使用遠(yuǎn)程用戶通過電話線和MODEM能方便地接入TCP/IP網(wǎng)絡(luò)。
SLIP是一種簡(jiǎn)單的組幀方式，使用時(shí)還存在一些問題。首先，SLIP不支持在連接過程中的動(dòng)態(tài)IP地址分配，通信雙方必須事先告知對(duì)方IP地址，這給沒有固定IP地址的個(gè)人用戶上Internet網(wǎng)帶來了很大的不便：其次，SLIP幀中無協(xié)議類型字段，因此它只能支持IP協(xié)議；再有，SLIP幀中列校驗(yàn)字段，因此鏈路層上無法檢測(cè)出傳輸差錯(cuò)，必須由上層實(shí)體或具有糾錯(cuò)能力的MODEM來解決傳輸差錯(cuò)問題。
3?相關(guān)資源
http://www.rfc.net?RFC的官方站點(diǎn)，可以檢查RFC最及時(shí)的更新情況
http://www.ietf.org?最重要的Internet組織之一
http://sunsite.dk?RFC查詢非常強(qiáng)大(可以以FTP登錄下載全部RFC文檔)
http://www.iso.ch?ISO-國(guó)際標(biāo)準(zhǔn)化組織
http://standards.ieee.org?IEEE-電氣與電子工程師協(xié)會(huì)
http://web.ansi.org?ANSI-美國(guó)國(guó)家標(biāo)準(zhǔn)化組織
http://www.itu.int?ITU-國(guó)際電信聯(lián)盟
總結(jié)
- 上一篇： 软件生命周期模型优缺点及适用范围
- 下一篇： STM32通过SD卡IAP