❶ 計算機網路——TCP/UDP協議
計算機網路七層模型中，傳輸層有兩個重要的協議：
（1）用戶數據報協議UDP (User Datagram Protocol)
（2）傳輸控制協議TCP (Transmission Control Protocol)
UDP 在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP 報文後，不需要給出任何確認。雖然UDP 不提供可靠交付，但在某些情況下UDP 卻是一種最有效的工作方式。
TCP 則提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP 不提供廣播或多播服務。由於TCP 要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷，如確認、流量控制、計時器以及連接管理等。
UDP 的主要特點是：
首部手段很簡單，只有8 個位元組，由四個欄位組成，每個欄位的長度都是兩個位元組。
前面已經講過，每條TCP 連接有兩個端點，TCP 連接的端點叫做套接字（socket）或插口。套接字格式如下：
套接寧socket= (IP 地址：埠號』）
每一條TCP 連接唯一地被通信兩端的兩個端點（即兩個套接宇）所確定。即：
TCP 連接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}
3次握手鏈接
4次握手釋放鏈接
斷開連接請求可以由客戶端發出，也可以由伺服器端發出，在這里我們稱A端向B端請求斷開連接。
各個狀態節點解釋如下：
下面為了討論問題的萬便，我們僅考慮A發送數據而B 接收數據並發送確認。因此A 叫做發送方，而B 叫做接收方。
「停止等待」就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網路上實現可靠的通信。像上述的這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest）。意思是重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。
滑動窗口協議比較復雜，是TCP 協議的精髓所在。這里先給出連續ARQ 協議最基本的概念，但不涉提到許多細節問題。詳細的滑動窗口協議將在後面討論。
下圖表示發送方維持的發送窗口，它的意義是：位於發送窗口內的5 個分組都可連續發送出去，而不需要等待對方的確認。這樣，信道利用率就提高了。
連續ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
接收方一般都是採用 累積確認 的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組發送確認，這樣就表示：到這個分組為止的所有分組都己正確收到了。
累積確認 的優點是容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。
例如，如果發送方發送了前5 個分組，而中間的第3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來重傳己發送過的N 個分組。可見當通信線路質量不好時，連續ARQ 協議會帶來負面的影響。
TCP 的滑動窗口是以位元組為單位的。現假定A 收到了B 發來的確認報文段，其中窗口是20 （位元組），而確認號是31 （這表明B 期望收到的下一個序號是31 ，而序號30 為止的數據己經收到了）。根據這兩個數據， A 就構造出自己的發送窗口，其位置如圖所示。
發送窗口表示：在沒有收到B 的確認的情況下， A可以連續把窗口內的數據都發送出去。凡是己經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。
現在假定A 發送了序號為31 ～ 41 的數據。這時發送窗口位置並未改變，但發送窗口內靠後面有11個位元組（灰色小方框表示）表示己發送但未收到確認。而發送窗口內靠前面的9 個位元組（ 42 ～ 50 ）是允許發送但尚未發送的。】
再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 號為止的數據是已經發送過確認，並且己經交付給主機了。因此在B 可以不再保留這些數據。接收窗口內的序號（31～50）足允許接收的。B 收到了序號為32 和33 的數據，這些數據沒有按序到達，因為序號為31 的數據沒有收到（也許丟失了，也許滯留在網路中的某處）。 請注意， B 只能對按序收到的數據中的最高序號給出確認，因此B 發送的確認報文段中的確認號仍然是31 （即期望收到的序號）。
現在假定B 收到了序號為31 的數據，並把序號為31～33的數據交付給主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號，同時給A 發送確認，其中窗口值仍為20，但確認號是34，這表明B 已經收到了到序號33 為止的數據。我們注意到，B還收到了序號為37, 38 和40 的數據，但這些都沒有按序到達，只能先存在接收窗口。A收到B的確認後，就可以把發送窗口向前滑動3個序號，指針P2 不動。可以看出，現在A 的可用窗口增大了，可發送的序號范圍是42～53。整個過程如下圖：
A 在繼續發送完序號42-53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認。由於A 的發送窗口己滿，可用窗口己減小到0，因此必須停止發送。
上面已經講到， TCP 的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念是很簡單的，但重傳時間的選擇卻是TCP 最復雜的問題之一。
TCP採用了一種自適應演算法 ，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，TCP 保留了RTT的一個加權平均往返時間RTTs （這又稱為平滑的往返時間， S 表示Smoothed 。因為進行的是加權平均，因此得出的結果更加平滑）。每當第一次測量到RTT樣本時， RTTs值就取為所測量到的RTT樣本值。但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTs:
新的RTTs = (1 － α）×（舊的RTTs) ＋ α ×（新的RTT樣本）
α 越大表示新的RTTs受新的RTT樣本的影響越大。推薦的α 值為0.125，用這種方法得出的加權平均往返時間RTTs 就比測量出的RTT值更加平滑。
顯然，超時計時器設置的超時重傳時間RTO (RetransmissionTime-Out）應略大於上面得出的加權平均往返時間RTTs。RFC 2988 建議使用下式計算RTO:
RTO = RTTs + 4 × RTTd
RTTd是RTT 的偏差的加權平均值，它與RTTs和新的RTT樣本之差有關。計算公式如下：
新的RTTd= (1- β）×（舊的RTTd) + β × |RTTs－新的RTT樣本|
發現問題： 如圖所示，發送出一個報文段。設定的重傳時間到了，還沒有收到確認。於是重
傳報文段。經過了一段時間後，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？
若收到的確認是對重傳報文段的確認，但卻被源主機當成是對原來的報文段的確認，則這樣計算出的RTTs 和超時重傳時間RTO 就會偏大。若後面再發送的報文段又是經過重傳後才收到確認報文段，則按此方法得出的超時重傳時間RTO 就越來越長。
若收到的確認是對原來的報文段的確認，但被當成是對重傳報文段的確認，則由此計算出的RTTs 和RTO 都會偏小。這就必然導致報文段過多地重傳。這樣就有可能使RTO 越來越短。
Kam 提出了一個演算法：在計算加權平均RTTs 時，只要報文段重傳了就不採用其往返時間樣本。這樣得出的加權平均RTTs 和RTO 就較准確。
新問題： 設想出現這樣的情況：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據Kam 演算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。
解決方案： 對Kam 演算法進行修正，方法是z報文段每重傳一次，就把超時重傳時間RTO 增大一些。典型的做法是取新的重傳時間為2 倍的舊的重傳時間。當不再發生報文段的重傳時，才根據上面給出的公式計算超時重傳時間。
流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP 連接上實現對發送方的流量控制。
接收方的主機B 進行了三次流量控制。第一次把窗口減小到rwnd =300，第二次又減到rwnd = 100 ，最後減到rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B 重新發出一個新的窗口值為止。我們還應注意到，B 向A 發送的三個報文段都設置了ACK=1，只有在ACK=1 時確認號欄位才有意義。
發生死鎖： 現在我們考慮一種情況。上圖中， B 向A 發送了零窗口的報文段後不久， B 的接收緩存又有了一些存儲空間。於是B 向A 發送了rwnd = 400 的報文段。然而這個報文段在傳送過程中丟失了。A 一直等待收到B 發送的非零窗口的通知，而B 也一直等待A 發送的數據。如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。
解決方案： TCP 為每一個連接設有一個 持續計時器（persistence timer） 。只要TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個 零窗口探測報文段 （僅攜帶1 宇節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
1 TCP連接時是三次握手，那麼兩次握手可行嗎？
在《計算機網路》中是這樣解釋的：已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ACK包。這樣就會白白浪費資源。而經過三次握手，客戶端和伺服器都有應有答，這樣可以確保TCP正確連接。
2 為什麼TCP連接是三次，揮手確是四次？
在TCP連接中，伺服器端的SYN和ACK向客戶端發送是一次性發送的，而在斷開連接的過程中，B端向A端發送的ACK和FIN是是分兩次發送的。因為在B端接收到A端的FIN後，B端可能還有數據要傳輸，所以先發送ACK，等B端處理完自己的事情後就可以發送FIN斷開連接了。
3 為什麼在第四次揮手後會有2個MSL的延時？
MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。假定網路不可靠，那麼第四次發送的ACK可能丟失，即B端無法收到這個ACK，如果B端收不到這個確認ACK，B端會定時向A端重復發送FIN，直到B端收到A的確認ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。
1 文件傳送協議
文件傳送協議FTP (File Transfer Protocol) [RFC 959］是網際網路上使用得最廣泛的文件傳送協議，底層採用TCP協議。
盯P 使用客戶伺服器方式。一個FTP 伺服器進程可同時為多個客戶進程提供服務。FTP的伺服器進程由兩大部分組成：一個主進程，負責接受新的請求：另外有若干個從屬進程，負責處理單個請求。
在進行文件傳輸時，客戶和伺服器之間要建立兩個並行的TCP 連接：「控制連接」（21埠）和「數據連接」（22埠）。控制連接在整個會話期間一直保持打開， FTP 客戶所發出的傳送請求，通過控制連接發送給伺服器端的控制進程，但控制連接並不用來傳送文件。實際用於傳輸文件的是「數據連接」。伺服器端的控制進程在接收到FTP 客戶發送來的文件傳輸請求後就創建「數據傳送進程」和「數據連接」，用來連接客戶端和伺服器端的數據傳送進程。
2 簡單文件傳送協議TFTP
TCP/IP 協議族中還有一個簡單文件傳送協議TFfP (Trivial File Transfer Protocol），它是一個很小且易於實現的文件傳送協議，埠號69。
TFfP 也使用客戶伺服器方式，但它使用UDP 數據報，因此TFfP 需要有自己的差錯改正措施。TFfP 只支持文件傳輸而不支持交耳。
3 TELNET
TELNET 是一個簡單的遠程終端協議，底層採用TCP協議。TELNET 也使用客戶伺服器方式。在本地系統運行TELNET 客戶進程，而在遠地主機則運行TELNET 伺服器進程，佔用埠23。
4 郵件傳輸協議
一個電子郵件系統應具如圖所示的三個主要組成構件，這就是用戶代理、郵件伺服器，以及郵件發送協議（如SMTP ）和郵件讀取協議（如POP3)， POP3 是郵局協議（Post Office Protocol）的版本3 。
SMTP 和POP3 （或IMAP ）都是在TCP 連接的上面傳送郵件，使用TCP 的目的是為了使郵件的傳送成為可靠的。
❷ 簡要說明計算機網路術語RFC是什麼
RFC(遠程函數調用 Remote Function Call)是一個 SAP 的介面協議。它基於 CPI-C,很大程度上簡化了系統間通訊的編程工作。RFC 允許調用和執行一個遠程系統,或者是相同系統上的預定義函數。
❸ 誰能通俗的說一下網路中的RFC是什麼意思
RFC(Request
For
Comments)-意即「請求評議」
RFC是網際網路上一類文件的統稱：
通俗的說，某家機構或團體，開發出一套網路標准或對標準的構想，想征詢網際網路上的意見，就會在網上發一份RFC，對這一問題感興趣的人可以閱讀該RFC並提出自己的意見；絕大部分網路標準的指定都是以RFC的形式開始，經過大量的論證和修改過程，由主要的標准化組織所指定的。
❹ 計算機網路原理rfc是什麼意思
Request For Comments（RFC），是一系列以編號排定的文件。文件收集了有關互聯網相關信息，以及UNIX和互聯網社區的軟體文件。目前RFC文件是由Internet Society（ISOC）贊助發行。基本的互聯網通信協議都有在RFC文件內詳細說明。RFC文件還額外加入許多的論題在標准內，例如對於互聯網新開發的協議及發展中所有的記錄。因此幾乎所有的互聯網標准都有收錄在RFC文件之中。
❺ RFC是什麼
RFC是英文「RequestForComments」的縮寫，意思是指一系列以編號排定的文件。RFC文件是由InternetSociety（ISOC）贊助發行，收集了有關互聯網相關信息，以及UNIX和互聯網社區的軟體文件。RFC由一系列草案組成，起始於1969年。
RFC文檔是一系列關於Internet（早期為ARPANET）的技術資料匯編。這些文檔詳細討論了計算機網路的方方面面，重點在網路協議，進程，程序，概念以及一些會議紀要，意見，各種觀點等。
「RFC編輯者」是RFC文檔的出版者，它負責RFC最終文檔的編輯審判鍵租訂。「RFC編輯者」也掘兆保留有RFC的主文件，稱為RFC索引，用戶可以在線檢索。在RFC近30年的歷史中，「RFC編輯者」一直由約翰·普斯特爾（JonPostel）來擔任，而「RFC編輯者」則由一個工作小組來擔任，這個小組受到「互聯網協會」（InternetSociety）的支持和幫助。
RFC編輯者負亮喊責RFC以及RFC的整體結構文檔，並維護RFC的索引。Internet協議族的文檔部分（由Internet工程委員會「網際網路工程師任務組」IETF以及IETF下屬的「網際網路工程師指導組」IESG定義），也做為RFC文檔出版。因此，RFC在Internet相關標准中有著重要的地位。
❻ 什麼叫RFC哦``越詳細越好
RFC(Request For Comments)-意即「請求評議」，包含了關於Internet的幾乎所有重要的文字資料。如果你想成為網路方面的專家，那麼RFC無疑是最重要也是最經常需要用到的資料之一，所以RFC享有網路知識聖經之美譽。通常，當某家機構或團體開發出了一套標准或提出對某種標準的設想，想要征詢外界的意見時，就會在Internet上發放一份RFC，對這一問題感興趣的人可以閱讀該RFC並提出自己的意見；絕大部分網路標準的制定都是以RFC的形式開始，經過大量的論證和修改過程，由主要的標准化組織所制定的，但在RFC中所收錄的文件並不都是正在使用或為大家所公認的，也有很大一部分只在某個局部領域被使用或並沒有被採用，一份RFC具體處於什麼狀態都在文件中作了明確的標識。截至2001年中期，公布的RFC大約有3000餘篇，以下是幾個較為穩定的RFC鏈接，以及幾個重要的標准化組織的網站鏈接 >>> http://www.rfc.net RFC的官方站點，可以檢查RFC最及時的更新情況 http://www.ietf.org 最重要的Internet組織之一 http://sunsite.dk RFC查詢非常強大(可以以FTP登錄下載全部RFC文檔) http://www.iso.ch ISO-國際標准化組織 http://standards.ieee.org IEEE-電氣與電子工程師協會 http://web.ansi.org ANSI-美國國家標准化組織 http://www.itu.int ITU-國際電信同盟 中文網站: http://www.cnpaf.net/ 中國協議分析網 RFC發展歷程 1969年,S·Crocker首先建立了RFC機制,其目的是建立一種快速共享Internet網路研究思想的方式,最初RFC是以書面形式分發的,後來有了FTP、Email,RFC就以在線電子文本的形式提供,當然現在通過WWW在很多站點可以很方便地訪問RFC文檔。 RFC一直以來主要是用於Internet的標准化,RFC是Internet開放性的產物,任何人都可以訪問RFC,Internet這一致力於信息共享的網路首先共享的就是以RFC形式出現的涉及其自身研究、設計和使用的信息。這一獨特的方式對於Internet的發展、完善具有相當關鍵的作用。發展到現在,RFC文檔已不僅僅是關於差猜世Internet標準的文檔了,而且也不局限於TCP/IP范圍,它幾乎包含了與計算機通信有關的任何內容,全面反映Internet研究、發展的過程。 RFC主要是IAB、IETF、IESG、ISOC的工作成果,主要由IETF起草,由IAB指導下的RFC 編輯(Editor)直接負責RFC的發表。每一個RFC文檔有一個編號,這個編號永不重復,也就是說,由於技術進步等原因,即使是關於同一問題的RFC,也要使用新的編號,而不會使用原來的編號,時至今日,RFC編號已經排到2200多,在查找RFC時,一定要注意最新的RFC。 RFC的分類 RFC文檔大致可以分為以下幾類。 1.STD RFC 按照RFC1311的定義,STD RFC是指那些已經或者致力於成為Internet標準的RFC。只有經過完全Internet標准化過程的RFC才可以有STD編號,STD編號是不變的,而其涉及兆輪到的 RFC文檔可能不只一個,其RFC編號也會更新。如STD13(Domain Name System)就涉及RFC1 034和RFC1035。 STD的標准化過程要經過幾個步驟,首先由IETF起草標准(也可能是其他組織和個人, 但一般都是和IETF共同完成的),形成Internet Draft(ID),ID沒有RFC編號。如果ID在6個月內IESG沒有建議成為RFC,則取消此ID。成為RFC後,還要經過一系列的審查、修訂、測試等才能最終成為Internet標准。 2.BCP RFC 由於Internet應用領域廣泛,各種不同的組織有不同的使用目的和使用規則,IETF除了建議STD以外,也有必要對於Internet的使用和管理提供一虛肢些一般性的指導,同時也為I ETF、IAB、IESG提供一種渠道,以便推動某一方面的工作,反映其技術趨向,反映這些組織本身的工作進展。於是,1995年以RFC1818定義了BCP,即Best Current Practice。BCP同時有一個BCP編號和一個RFC編號,一旦約定了一個BCP編號,就不會再變,而其RFC編號則可能會經過修訂不斷更新。例如反映Internet標准化工作程序的BCP9的RFC編號就從RFC16 02上升到RFC2026,相應地就廢棄了RFC1602。 BCP在發表以前,以電子郵件的形式廣泛徵求IETF的意見,經過IESG的審查,通過後即正式發表。但是BCP本身不是Internet標准。 3.FYI RFC FYI是For Your Information的簡寫,1990年發表的RFC1150(FYI1)定義了FYI,FYI也同時有一個FYI編號和一個RFC編號,FYI編號是固定的。FYI主要是提供有關Internet的知識性內容。如FYI4(RFC1594),"Answers to Commonly asked New Internet User Quest ions"。所有的FYI在提交到RFC編輯以前,必須先經過IETF的User Services WorkingGro up審查。 4.其他RFC 除了STD、BCP、FYI以外還有其他一些RFC。從RFC899開始,所有以99結尾的RFC都是對此前99個RFC的一個概括。如RFC1999就是對RFC1900到RFC1999的一個簡單概括。除了上述分類以外,還有一些描述RFC的方法。與Internet標准化過程(Internet Standards Process)有關的規范可以分為兩類,即 Technical Specification(TS),Applicability Statement(AS)。TS是對協議、規則、格式、實用程序的描述。AS是描述在何種環境,以及怎樣在Internet中使用TS;AS所涉及的並不一定全是Internet標准,比如IEEE、ITU、ISO組織的一些標准,大家所熟悉的ASCII標准就是一例。AS應該對其涉及的TS規定相應的級別"Requirement Level",這些"Require ment Level"如下: ·Required(Req),相當於必須實現,如IP、ICMP; ·Recommended(Rec),鼓勵使用,如TELNET; ·Elective(Elc),可選擇的; ·Limited Use,只限於特定的用戶,一般說來用於對一些新的協議做試驗; ·Not Recommended,不要使用,很可能是過時的。 "Maturity Level"也是用來描述TS和AS的一種方式,它反映這些標準是否成熟。對於致力於成為STD的TS和AS有三種"Maturity Level"。·Proposed Standard,基本成熟,但還需要進一步的試驗證實其可行性。除非是用來驗證該協議的可行性,不要將其視為標准實現。 ·Draft Standard,需要兩個獨立的,而且具有相互操作性的實例驗證該協議的每一個方面。可以將其視為最終的標准草案; ·Internet Standard,最終的Internet標准,同時賦予一個STD編號。除此之外的TS和AS分為以下幾種"Maturity Level"。·Experimental,一般是反映一些研究和開發的成果,只應將此看作是一般性的信息。 ·Informational,反映與Internet標准有關的一般性信息。有些也是有關非Intern et組織開發的一些協議,但必須得到協議開發者的許可。 ·Historic,是一些被新的標准取代或者是已經過時廢棄不用的標准。 STD1(RFC2200)——Internet Official Protocol Standards,定期更新,反映最新的 Internet標准。另外,對於關注Internet的人來說,應該經常注意查閱BCP9的最新內容。
❼ 什麼是IETF什麼是RFC他們是什麼關系
國際互聯網工程任務組（，簡稱IETF）為一個公開性質的大型民間國際團體，匯集了與互聯網架構和互聯網順利運作相關的網路設計者、運營者、投資人和研究人員。
RFC，RequestForComments，文件收集了有關互聯網相關信息，以及UNIX和互聯網社群的軟體文件，以編號排定。
RFC由互聯網工程任務組（IETF）發布。
(7)計算機網路rfc擴展閱讀
IETF的主要任務為負責互聯網相關技術標準的研發和制定，是國際互聯網業界具有一定權威的網路相關技術研究團體。IETF大量的技術性工作均由其內部的各種工作組（WorkingGroup，簡稱WG）承擔和完成。這些工作組依據各項不數薯絕同類別的研究課題而組建。
在成立工作組之前，先由一些研究人員通過郵件組自發地對某個專題展開研究，當研究較為成熟後，可以向IETF申請成手汪立興趣小組（birdsofafeather，簡稱BOF）開展工作組籌備工作。籌備工作完成後，經過IETF上層研究認可後，即可成立工作組。
工作組在IETF框架中展開專項研究，如路由、傳輸、安全等專項工作組，任何對此技術感興趣的人都可以自由參加討論，並提出自己的觀點。各工作組有獨立的郵件組，工作組成員內部通過郵件互通信息。IETF每年舉行三次會議，規模均在千人以上。
RFC文件只有新增，不會有取消或中途停止發行的情形。但是對於同一主題而言，新的RFC文件可以聲明取代舊的RFC文件。RFC文件是純ASCII文字檔格式，可由計算機程序自動轉換成其他文件格式。RFC文件有封面、目錄及頁眉頁腳和頁碼。
RFC的章節為數字標示，但數字的小數點後不補零，例如4.9的順序就在4.10前面，但9的前面並不補零。RFC1000這份文件就是RFC的薯姿指南。
❽ 計算機網路第三章（數據鏈路層）
3.1、數據鏈路層概述
概述
鏈路 是從一個結點到相鄰結點的一段物理線路， 數據鏈路 則是在鏈路的基礎上增加了一些必要的硬體（如網路適配器）和軟體（如協議的實現）
網路中的主機、路由器等都必須實現數據鏈路層
區域網中的主機、交換機等都必須實現數據鏈路層
從層次上來看數據的流動
僅從數據鏈路層觀察幀的流動
主機H1 到主機H2 所經過的網路可以是多種不同類型的
注意：不同的鏈路層可能採用不同的數據鏈路層協議
數據鏈路層使用的信道
數據鏈路層屬於計算機網路的低層。 數據鏈路層使用的信道主要有以下兩種類型：
點對點信道
廣播信道
區域網屬於數據鏈路層
區域網雖然是個網路。但我們並不把區域網放在網路層中討論。這是因為在網路層要討論的是多個網路互連的問題，是討論分組怎麼從一個網路，通過路由器，轉發到另一個網路。
而在同一個區域網中，分組怎麼從一台主機傳送到另一台主機，但並不經過路由器轉發。從整個互聯網來看， 區域網仍屬於數據鏈路層 的范圍
三個重要問題
數據鏈路層傳送的協議數據單元是 幀
封裝成幀
封裝成幀 (framing) 就是在一段數據的前後分別添加首部和尾部，然後就構成了一個幀。
首部和尾部的一個重要作用就是進行 幀定界 。
差錯控制
在傳輸過程中可能會產生 比特差錯 ：1 可能會變成 0， 而 0 也可能變成 1。
可靠傳輸
接收方主機收到有誤碼的幀後，是不會接受該幀的，會將它丟棄
如果數據鏈路層向其上層提供的是不可靠服務，那麼丟棄就丟棄了，不會再有更多措施
如果數據鏈路層向其上層提供的是可靠服務，那就還需要其他措施，來確保接收方主機還可以重新收到被丟棄的這個幀的正確副本
以上三個問題都是使用 點對點信道的數據鏈路層 來舉例的
如果使用廣播信道的數據鏈路層除了包含上面三個問題外，還有一些問題要解決
如圖所示，主機A，B，C，D，E通過一根匯流排進行互連，主機A要給主機C發送數據，代表幀的信號會通過匯流排傳輸到匯流排上的其他各主機，那麼主機B，D，E如何知道所收到的幀不是發送給她們的，主機C如何知道發送的幀是發送給自己的
可以用編址（地址）的來解決
將幀的目的地址添加在幀中一起傳輸
還有數據碰撞問題
隨著技術的發展，交換技術的成熟，
在 有線（區域網）領域 使用 點對點鏈路 和 鏈路層交換機 的 交換式區域網 取代了 共享式區域網
在無線區域網中仍然使用的是共享信道技術
3.2、封裝成幀
介紹
封裝成幀是指數據鏈路層給上層交付的協議數據單元添加幀頭和幀尾使之成為幀
幀頭和幀尾中包含有重要的控制信息
發送方的數據鏈路層將上層交付下來的協議數據單元封裝成幀後，還要通過物理層，將構成幀的各比特，轉換成電信號交給傳輸媒體，那麼接收方的數據鏈路層如何從物理層交付的比特流中提取出一個個的幀？
答：需要幀頭和幀尾來做 幀定界
但比不是每一種數據鏈路層協議的幀都包含有幀定界標志，例如下面例子
前導碼
前同步碼：作用是使接收方的時鍾同步
幀開始定界符：表明其後面緊跟著的就是MAC幀
另外乙太網還規定了幀間間隔為96比特時間，因此，MAC幀不需要幀結束定界符
透明傳輸
透明
指某一個實際存在的事物看起來卻好像不存在一樣。
透明傳輸是指 數據鏈路層對上層交付的傳輸數據沒有任何限制 ，好像數據鏈路層不存在一樣
幀界定標志也就是個特定數據值，如果在上層交付的協議數據單元中， 恰好也包含這個特定數值，接收方就不能正確接收
所以數據鏈路層應該對上層交付的數據有限制，其內容不能包含幀定界符的值
解決透明傳輸問題
解決方法 ：面向位元組的物理鏈路使用 位元組填充 (byte stuffing) 或 字元填充 (character stuffing)，面向比特的物理鏈路使用比特填充的方法實現透明傳輸
發送端的數據鏈路層在數據中出現控制字元「SOH」或「EOT」的前面 插入一個轉義字元「ESC」 (其十六進制編碼是1B)。
接收端的數據鏈路層在將數據送往網路層之前刪除插入的轉義字元。
如果轉義字元也出現在數據當中，那麼應在轉義字元前面插入一個轉義字元 ESC。當接收端收到連續的兩個轉義字元時，就刪除其中前面的一個。
幀的數據部分長度
總結
3.3、差錯檢測
介紹
奇偶校驗
循環冗餘校驗CRC(Cyclic Rendancy Check)
例題
總結
循環冗餘校驗 CRC 是一種檢錯方法，而幀校驗序列 FCS 是添加在數據後面的冗餘碼
3.4、可靠傳輸
基本概念
下面是比特差錯
其他傳輸差錯
分組丟失
路由器輸入隊列快滿了，主動丟棄收到的分組
分組失序
數據並未按照發送順序依次到達接收端
分組重復
由於某些原因，有些分組在網路中滯留了，沒有及時到達接收端，這可能會造成發送端對該分組的重發，重發的分組到達接收端，但一段時間後，滯留在網路的分組也到達了接收端，這就造成 分組重復 的傳輸差錯
三種可靠協議
停止-等待協議SW
回退N幀協議GBN
選擇重傳協議SR
這三種可靠傳輸實現機制的基本原理並不僅限於數據鏈路層，可以應用到計算機網路體系結構的各層協議中
停止-等待協議
停止-等待協議可能遇到的四個問題
確認與否認
超時重傳
確認丟失
既然數據分組需要編號，確認分組是否需要編號？
要。如下圖所示
確認遲到
注意，圖中最下面那個數據分組與之前序號為0的那個數據分組不是同一個數據分組
注意事項
停止-等待協議的信道利用率
假設收發雙方之間是一條直通的信道
TD ：是發送方發送數據分組所耗費的發送時延
RTT ：是收發雙方之間的往返時間
TA ：是接收方發送確認分組所耗費的發送時延
TA一般都遠小於TD，可以忽略，當RTT遠大於TD時，信道利用率會非常低
像停止-等待協議這樣通過確認和重傳機制實現的可靠傳輸協議，常稱為自動請求重傳協議ARQ( A utomatic R epeat re Q uest)，意思是重傳的請求是自動進行，因為不需要接收方顯式地請求，發送方重傳某個發送的分組
回退N幀協議GBN
為什麼用回退N幀協議
在相同的時間內，使用停止-等待協議的發送方只能發送一個數據分組，而採用流水線傳輸的發送方，可以發送多個數據分組
回退N幀協議在流水線傳輸的基礎上，利用發送窗口來限制發送方可連續發送數據分組的個數
無差錯情況流程
發送方將序號落在發送窗口內的0~4號數據分組，依次連續發送出去
他們經過互聯網傳輸正確到達接收方，就是沒有亂序和誤碼，接收方按序接收它們，每接收一個，接收窗口就向前滑動一個位置，並給發送方發送針對所接收分組的確認分組，在通過互聯網的傳輸正確到達了發送方
發送方每接收一個、發送窗口就向前滑動一個位置，這樣就有新的序號落入發送窗口，發送方可以將收到確認的數據分組從緩存中刪除了，而接收方可以擇機將已接收的數據分組交付上層處理
累計確認
累計確認
優點:
即使確認分組丟失，發送方也可能不必重傳
減小接收方的開銷
減小對網路資源的佔用
缺點：
不能向發送方及時反映出接收方已經正確接收的數據分組信息
有差錯情況
例如
在傳輸數據分組時，5號數據分組出現誤碼，接收方通過數據分組中的檢錯碼發現了錯誤
於是丟棄該分組，而後續到達的這剩下四個分組與接收窗口的序號不匹配
接收同樣也不能接收它們，講它們丟棄，並對之前按序接收的最後一個數據分組進行確認，發送ACK4， 每丟棄一個數據分組，就發送一個ACK4
當收到重復的ACK4時，就知道之前所發送的數據分組出現了差錯，於是可以不等超時計時器超時就立刻開始重傳，具體收到幾個重復確認就立刻重傳，根據具體實現決定
如果收到這4個重復的確認並不會觸發發送立刻重傳，一段時間後。超時計時器超時，也會將發送窗口內以發送過的這些數據分組全部重傳
若WT超過取值范圍，例如WT=8，會出現什麼情況？
習題
總結
回退N幀協議在流水線傳輸的基礎上利用發送窗口來限制發送方連續發送數據分組的數量，是一種連續ARQ協議
在協議的工作過程中發送窗口和接收窗口不斷向前滑動，因此這類協議又稱為滑動窗口協議
由於回退N幀協議的特性，當通信線路質量不好時，其信道利用率並不比停止-等待協議高
選擇重傳協議SR
具體流程請看視頻
習題
總結
3.5、點對點協議PPP
點對點協議PPP（Point-to-Point Protocol）是目前使用最廣泛的點對點數據鏈路層協議
PPP協議是網際網路工程任務組IEIF在1992年制定的。經過1993年和1994年的修訂，現在的PPP協議已成為網際網路的正式標准[RFC1661，RFC1662]
數據鏈路層使用的一種協議，它的特點是：簡單；只檢測差錯，而不是糾正差錯；不使用序號，也不進行流量控制；可同時支持多種網路層協議
PPPoE 是為寬頻上網的主機使用的鏈路層協議
幀格式
必須規定特殊的字元作為幀定界符
透明傳輸
必須保證數據傳輸的透明性
實現透明傳輸的方法
面向位元組的非同步鏈路：位元組填充法（插入「轉義字元」）
面向比特的同步鏈路：比特填充法（插入「比特0」）
差錯檢測
能夠對接收端收到的幀進行檢測，並立即丟棄有差錯的幀。
工作狀態
當用戶撥號接入 ISP 時，路由器的數據機對撥號做出確認，並建立一條物理連接。
PC 機向路由器發送一系列的 LCP 分組（封裝成多個 PPP 幀）。
這些分組及其響應選擇一些 PPP 參數，並進行網路層配置，NCP 給新接入的 PC 機
分配一個臨時的 IP 地址，使 PC 機成為網際網路上的一個主機。
通信完畢時，NCP 釋放網路層連接，收回原來分配出去的 IP 地址。接著，LCP 釋放數據鏈路層連接。最後釋放的是物理層的連接。
可見，PPP 協議已不是純粹的數據鏈路層的協議，它還包含了物理層和網路層的內容。
3.6、媒體接入控制（介質訪問控制）——廣播信道
媒體接入控制（介質訪問控制）使用一對多的廣播通信方式
Medium Access Control 翻譯成媒體接入控制，有些翻譯成介質訪問控制
區域網的數據鏈路層
區域網最主要的 特點 是：
網路為一個單位所擁有；
地理范圍和站點數目均有限。
區域網具有如下 主要優點 ：
具有廣播功能，從一個站點可很方便地訪問全網。區域網上的主機可共享連接在區域網上的各種硬體和軟體資源。
便於系統的擴展和逐漸地演變，各設備的位置可靈活調整和改變。
提高了系統的可靠性、可用性和殘存性。
數據鏈路層的兩個子層
為了使數據鏈路層能更好地適應多種區域網標准，IEEE 802 委員會就將區域網的數據鏈路層拆成 兩個子層 ：
邏輯鏈路控制 LLC (Logical Link Control)子層；
媒體接入控制 MAC (Medium Access Control)子層。
與接入到傳輸媒體有關的內容都放在 MAC子層，而 LLC 子層則與傳輸媒體無關。 不管採用何種協議的區域網，對 LLC 子層來說都是透明的。
基本概念
為什麼要媒體接入控制（介質訪問控制）？
共享信道帶來的問題
若多個設備在共享信道上同時發送數據，則會造成彼此干擾，導致發送失敗。
隨著技術的發展，交換技術的成熟和成本的降低，具有更高性能的使用點對點鏈路和鏈路層交換機的交換式區域網在有線領域已完全取代了共享式區域網，但由於無線信道的廣播天性，無線區域網仍然使用的是共享媒體技術
靜態劃分信道
信道復用
頻分復用FDM (Frequency Division Multiplexing)
將整個帶寬分為多份，用戶在分配到一定的頻帶後，在通信過程中自始至終都佔用這個頻帶。
頻分復用 的所有用戶在同樣的時間 佔用不同的帶寬資源 （請注意，這里的「帶寬」是頻率帶寬而不是數據的發送速率）。
❾ 計算機網路協議有哪些
應用層
·DHCP(動態主機分配協議) · DNS (域名解析） · FTP（File Transfer Protocol）文件傳輸協議 · Gopher （英文原義：The Internet Gopher Protocol 中文釋義：（RFC-1436）網際Gopher協議） · HTTP （Hypertext Transfer Protocol）超文本傳輸協議 · IMAP4 (Internet Message Access Protocol 4) 即 Internet信息訪問協議的第4版本 · IRC （Internet Relay Chat ）網路聊天協議 · NNTP （Network News Transport Protocol）RFC-977）網路新聞傳輸協議 · XMPP 可擴展消息處理現場協議 · POP3 (Post Office Protocol 3)即郵局協議的第3個版本 · SIP 信令控制協議 · SMTP （Simple Mail Transfer Protocol）即簡單郵件傳輸協議 · SNMP (Simple Network Management Protocol,簡單網路管理協議) · SSH （Secure Shell）安全外殼協議 · TELNET 遠程登錄協議 · RPC （Remote Procere Call Protocol）（RFC-1831）遠程過程調用協議 · RTCP （RTP Control Protocol）RTP 控制協議 · RTSP （Real Time Streaming Protocol）實時流傳輸協議 · TLS （Transport Layer Security Protocol）安全傳輸層協議 · SDP( Session Description Protocol）會話描述協議 · SOAP （Simple Object Access Protocol）簡單對象訪問協議 · GTP 通用數據傳輸平台 · STUN （Simple Traversal of UDP over NATs，NAT 的UDP簡單穿越）是一種網路協議 · NTP （Network Time Protocol）網路校時協議
傳輸層
·TCP（Transmission Control Protocol） 傳輸控制協議 · UDP (User Datagram Protocol） 用戶數據報協議 · DCCP （Datagram Congestion Control Protocol）數據報擁塞控制協議 · SCTP（STREAM CONTROL TRANSMISSION PROTOCOL）流控制傳輸協議 · RTPReal-time Transport Protocol或簡寫RTP）實時傳送協議 · RSVP （Resource ReSer Vation Protocol）資源預留協議 · PPTP ( Point to Point Tunneling Protocol）點對點隧道協議
網路層
IP (IPv4 · IPv6) · ARP · RARP · ICMP · ICMPv6 · IGMP · RIP · OSPF · BGP · IS-IS · IPsec
數據鏈路層
802.11 · 802.16 · Wi-Fi · WiMAX · ATM · DTM · 令牌環 · 乙太網 · FDDI · 幀中繼 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN
物理層
乙太網物理層 · 數據機 · PLC · SONET/SDH · G.709 · 光導纖維 · 同軸電纜 · 雙絞線
❿ RFC規范標准
Request For Comments（RFC），是一系列以編號排定的文件。文件收集了有關互聯網相關信息，以及UNIX和互聯網社區的軟體文件。目前RFC文件是由Internet Society（ISOC）贊助發行。基本的互聯網通信協議都有在RFC文件內詳細說明。RFC文件還額外加入許多的論題在標准內，例如對於互聯網新開發的協議及發展中所有的記錄。因此幾乎所有的互聯網標准都有收錄在RFC文件之中。
Request For Comments (RFC），是一系列以編號排定的文件。文件收集了有關網際網路相關資訊，以及UNIX和網際網路社群的軟體文件。目前RFC文件是由Internet Society（ISOC）所贊助發行。
基本的網際網路通訊協定都有在RFC文件內詳細說明。RFC文件還在標准內額外加入了許多的論題，例如對於網際網路輪迅宴新開發的協定及發展中所有的記錄。因此幾乎所有的網際網路標准都收錄在RFC文件昌皮之中。
RFC(Request For Comments)-意即「請求協議」，包含了關於Internet的幾乎所有重要的文字資料。如果你想成為網路方面的專家，那麼RFC無疑是最重要也是最經常需要用到的資料之一，所以RFC享有網路知識聖經之美譽。通常，當某家機構或團體開發出了一套標准或提出對某種標準的設想，想要征詢外界的意見時，就會在Internet上發放一份RFC，對這一問題感興趣的人可以閱讀該RFC並提出自己的意見；絕大部分網路標準的指定都是以RFC的形式開始，經過大量的論證和修改過程，由主要的標准化組織所指定的，但在RFC中所收錄的文件並不都是正在使用或為大家所公認的，也有很大一部分只在某個局部領域被使用或並沒有被採用，一份RFC具體處於什麼狀態都在文件中作了明確的標識
RFC由一系列草案組成，起始於1969年（第一個RFC文檔發布於1969年4月7日，參見「RFC30年」，RFC2555」），RFC文檔是一系列關於Internet（早期為ARPANET）的技術資料匯編。這些文檔詳細討論了計算機網路的方方面面，重點在網路協議，進程，程序，概念以及一些會議紀要，意見，各種觀點等。
「RFC編輯者」是RFC文檔的出版者，它負責RFC最終文檔的編輯審訂。「RFC編輯者」也保留有RFC的主文件，稱為RFC索引，用戶可以在線檢索。在RFC近30年的 歷史 中，「RFC編輯者」一直由約翰·普斯特爾（Jon Postel）來擔任，而現在「RFC編輯者」則由一個工作小組來擔任，這個小組受到「互聯網協會」（Internet Society）的支持和幫助。
RFC編輯者負責RFC以及RFC的整體結構文檔，並維護RFC的索引。Internet協議族的文檔部分（由Internet工程委員會「網際網路工程師任務組」IETF以及IETF 下屬的「網際網路工程師指導組」IESG 定義），也做為RFC文檔出版。因此，RFC在Internet相關標准中有著重要的地位。
RFC編輯者的職責是由Internet 中的大家提議形成的，所出版的語言也就和Internet一樣。IETF和ISOC是代表了世界各地的國際性組織，英語是IETF的第一工作語言，也是IETF的正式出版語言。RFC 2026 "The Internet Standards Process -- Revision 3" 允許RFC翻譯成其他不同的語言。但是不能保證其翻譯版本是完全正確的。因此，RFC編輯不對非英語的版本負責，而只是指明了哪裡有非英語的版本，將這些信息列在WEB頁上。
一個RFC文件在成為官方標准前一般至少要經歷4個階段【RFC2026】：網際網路草案、建議標准、草案標准、網際網路標准。
第一步RFC的出版是作為一個Internet 草案發布，可以閱讀並對其進行注釋。准備一個RFC草案，我們要求作者先閱讀IETF的一個文檔"Considerations for Internet Drafts". 它包括了許多關於RFC以及Internet草案格式的有用信息。作者還應閱讀另外一個相關的文檔RFC 2223 "Instructions to Authors"。
一旦文檔有了一個ID號後，你就可以向rfc-editor @rfc-editor. org發送e-mail ，說你覺得這個文檔還臘銀可以，能夠作為一個有價值或有經驗的RFC文檔。RFC編輯將會向IESG請求查閱該文檔並給其加上評論和注釋。你可以通過RFC隊列來了解你的文檔的進度。一旦你的文檔獲得通過，RFC編輯就會將其編輯並出版。如果該文檔不能出版，則會有email通知作者不能出版的原因。作者有48個小時的時間來校對RFC編輯的意見。我們強烈建議作者要檢測拼寫錯誤和丟字的錯誤，應該確保有引用，聯系和更新相關的信息。如你的文檔是一個MIB，我們則要你對你的代碼作最後一次檢測。一旦RFC文檔出版，我們就不會對其進行更改，因此你應該對你的文檔仔細的檢查。
有時個別的文檔會被正從事同一個項目的IETF工作組收回，如是這種情況，則該作者會被要求和IETF進行該文檔的開發。在IETF中，Area Directors (ADs) 負責相關的幾個工作組。這些工作者所開發的文檔將由ADs 進行校閱，然後才作為RFC的出版物。
如要獲得關於如何寫RFC文檔和關於RFC的Internet標准制定過程的更多詳細信息，請各位參見：
RFC 2223 "Instructions to RFC Authors"。
RFC 2026 "The Internet Standards Process -- Revision 3"。
實際上，在Internet上，任何一個用戶都可以對Internet某一領域的問題提出自己的解決方案或規范，作為Internet草案（Internet Draffs，ID）提交給Internet工程任務組（IETF）。草案存放在美國、歐洲和亞太地區的工作文件站點上，供世界多國自願參加的IETF成員進行討論、測試和審查。最後，由Internet工程指導組（IESG）確定該草案是否能成為Internet的標准。
如果一個Internet草案在IETF的相關站點上存在6個月後仍未被IESG建議作為標准發布，則它將被從上述站點中刪除。事實上，在任何時候，一個Internet 草案都有可能被新的草案版本所替換掉，並重新開始6個月的存放期。
如果一個Internet草案被IESG確定為Internet的正式工作文件，則被提交給Internet體系結構委員會（IAB），並形成具有順序編號的RFC文檔，由Internet協會（ISOC）通過Internet向全世界頒布。每個Internet標准文件在被批准後都會分配一個獨立於RFC的永久編號，這就是STD編號。有一個不斷被更新的文件RFC-INDEX.TXT按照RFC的編號來索引所有的文件，對於網際網路標准文件還列出了其相應的STD編號。
RFC文檔必須被分配RFC編號後才能在網路上發布。例如，RFC2026的內容是「Internet標准進程-修訂版3」、RFC1543的內容為「RFC作者指導」等等。需要時，可以復制或列印這些聯機文檔。用戶也可以通過遍布全世界的數個聯機資料資料庫中獲得RFC文檔。
作為標準的RFC又分為幾種，第一種是提議性的，就是說建議採用這個作為一個方案擺出來，Draft是已經有一部分在用了，希望被採用為正式的標准，還有一種就是完全被認可的標准，這種是大家都在用，而且是不應該改變的。還有一種就是現在的最佳實踐法，它相當於一種介紹。這些文件產生的過程是一種從下往上的過程，而不是從上往下，也就是說不是一個由主席，或者由工作組負責人的給一個指令，說是要做什麼，要做什麼，而是有下邊自發的提出，然後在工作組里邊討論，討論了以後再交給剛才說的工程指導委員會進行審查。但是工程指導委員會只做審查不做修改，修改還是要打回到工作組來做。IETF工作組文件的產生就是任何人都可以來參加會議，任何人都可以提議，然後他和別人進行討論，大家形成了一個共識就可以產出這樣的文件。
RFC文件格式最初作為ARPA網計劃的基礎起源於1969年。如今，它已經成為IETF、Internet Architecture Board (IAB）還有其他一些主要的公共網路研究社區的正式出版物發布途徑。
最初的RFC作者使用打字機撰寫文檔，並在美國國防部國防前沿研究項目署（ARPA）研究成員之間傳閱。1969年12月，他們開始通過ARPANET途徑來發布新的RFC文檔。第一份RFC文檔由洛杉磯加利福尼亞大學（UCLA）的Steve Crocker撰寫，在1969年4月7日公開發表的RFC 1。當初Crocker為了避免打擾他的室友，是在浴室里完成這篇文檔的。
在1970年代，很多後來的RFC文檔同樣來自UCLA，這不僅得益於UCLA的學術質量，同時也因為UCLA是ARPANET第一批Interface Message Processors (IMPs）成員之一。
由Douglas Engelbart領導的，位於Stanford Research Institute的Augmentation Research Center (ARC）是四個最初的ARPANET結點之一，也是最初的Network Information Centre，同時被 社會 學家Thierry Bardini記錄為早期大量RFC文檔的發源地。
從1969年到1998年，Jon Postel一直擔任RFC文檔的編輯職務。隨著美國政府贊助合同的到期，Internet Society（代表IETF），和南加州大學（USC）Information Sciences Institute的網路部門合作，（在IAB領導下）負責RFT文檔的起草和發布工作。Jon Postel繼續擔任RFC編輯直到去世。隨後，由Bob Braden接任整個項目的領導職務，同時Joyce Reynolds繼續在團隊中的擔任職務。
慶祝RFC的30周年的RFC文件是RFC 2555。
RFC文件是由Internet Society審核後給定編號並發行。雖然經過審核，但RFC也並非全部嚴肅而生硬的技術文件，偶有惡搞之作出現，尤其是4月1日愚人節所發行的，例如RFC 1606: A Historical Perspective On The Usage Of IP Version 9 （參見IPv9）、RFC 2324: 「超文本咖啡壺控制協議」（Hyper Text Coffee Pot Control Protocol，乍有其事的寫了HTCPCP這樣看起來很專業的術語縮寫字）。以及如前面所提到紀念RFC的30周年慶的RFC文件。
在Internet從誕生到不斷發展壯大的過程中，出現過各種各樣的協議和思想討論，從最初的NCP協議到現代Internet的基石TCP/IP協議族，無一不閃耀著研究人員的智慧光芒，正是這些成百上千各種協議的發明、討論和完善，才使得人類 社會 逐步進入到互聯網時代。而這些閃耀著人類智慧結晶的思想成果大都以一種稱為RFC的文檔格式記錄起來。
1969年，S·Crocker首先建立了RFC機制，其目的是建立一種快速共享Internet網路研究思想的方式，最初RFC是以書面形式分發的，後來有了FTP、Email,RFC就以在線電子文本的形式提供，當然現在通過WWW在很多站點可以很方便地訪問RFC文檔。RFC一直以來主要是用於Internet的標准化，RFC是Internet開放性的產物，任何人都可以訪問RFC,Internet這一致力於信息共享的網路首先共享的就是以RFC形式出現的涉及其自身研究、設計和使用的信息。這一獨特的方式對於Internet的發展、完善具有相當關鍵的作用。發展到現在，RFC文檔已不僅僅是關於Internet標準的文檔了，而且也不局限於TCP/IP范圍，它幾乎包含了與計算機通信有關的任何內容，全面反映Internet研究、發展的過程。RFC主要是IAB、IETF、IESG、ISOC的工作成果，主要由IETF起草，由IAB指導下的RFC 編輯（Editor）直接負責RFC的發表。每一個RFC文檔有一個編號，這個編號永不重復，也就是說，由於技術進步等原因，即使是關於同一問題的RFC，也要使用新的編號，而不會使用原來的編號，時至今日[2015/2/2]，RFC編號已經排到7443，在查找RFC時，一定要注意最新的RFC。
RFC文檔大致可以分為以下幾類。
1.STD RFC
按照RFC1311的定義，STD RFC是指那些已經或者致力於成為Internet標準的RFC。只有經過完全Internet標准化過程的RFC才可以有STD編號，STD編號是不變的，而其涉及到的 RFC文檔可能不只一個，其RFC編號也會更新。如STD13(Domain Name System）就涉及RFC1 034和RFC1035。STD的標准化過程要經過幾個步驟，首先由IETF起草標准（也可能是其他組織和個人，但一般都是和IETF共同完成的），形成Internet Draft(ID),ID沒有RFC編號。如果ID在6個月內IESG沒有建議成為RFC，則取消此ID。成為RFC後，還要經過一系列的審查、修訂、測試等才能最終成為Internet標准。
2.BCP RFC
由於Internet應用領域廣泛，各種不同的組織有不同的使用目的和使用規則，IETF除了建議STD以外，也有必要對於Internet的使用和管理提供一些一般性的指導，同時也為I ETF、IAB、IESG提供一種渠道，以便推動某一方面的工作，反映其技術趨向，反映這些組織本身的工作進展。於是，1995年以RFC1818定義了BCP，即Best Current Practice。BCP同時有一個BCP編號和一個RFC編號，一旦約定了一個BCP編號，就不會再變，而其RFC編號則可能會經過修訂不斷更新。例如反映Internet標准化工作程序的BCP9的RFC編號就從RFC16 02上升到RFC2026，相應地就廢棄了RFC1602。BCP在發表以前，以電子郵件的形式廣泛徵求IETF的意見，經過IESG的審查，通過後即正式發表。但是BCP本身不是Internet標准。
3.FYI RFC
FYI是For Your Information的簡寫，1990年發表的RFC1150(FYI1）定義了FYI,FYI也同時有一個FYI編號和一個RFC編號，FYI編號是固定的。FYI主要是提供有關Internet的知識性內容。如FYI4(RFC1594),"Answers to Commonly asked New Internet User Quest ions"。所有的FYI在提交到RFC編輯以前，必須先經過IETF的User Services WorkingGro up審查。
4.其他RFC
除了STD、BCP、FYI以外還有其他一些RFC。從RFC899開始，所有以99結尾的RFC都是對此前99個RFC的一個概括。如RFC1999就是對RFC1900到RFC1999的一個簡單概括。除了上述分類以外，還有一些描述RFC的方法。與Internet標准化過程（Internet Standards Process）有關的規范可以分為兩類，即 Technical Specification(TS),Applicability Statement(AS）。TS是對協議、規則、格式、實用程序的描述。AS是描述在何種環境，以及怎樣在Internet中使用TS;AS所涉及的並不一定全是Internet標准，比如IEEE、ITU、ISO組織的一些標准，大家所熟悉的ASCII標准就是一例。AS應該對其涉及的TS規定相應的級別"Requirement Level",這些"Require ment Level"如下： ·Required(Req），相當於必須實現，如IP、ICMP; ·Recommended(Rec），鼓勵使用，如TELNET; ·Elective(Elc），可選擇的； ·Limited Use，只限於特定的用戶，一般說來用於對一些新的協議做試驗； ·Not Recommended，不要使用，很可能是過時的。"Maturity Level"也是用來描述TS和AS的一種方式，它反映這些標準是否成熟。對於致力於成為STD的TS和AS有三種"Maturity Level"。·Proposed Standard，基本成熟，但還需要進一步的試驗證實其可行性。除非是用來驗證該協議的可行性，不要將其視為標准實現。·Draft Standard，需要兩個獨立的，而且具有相互操作性的實例驗證該協議的每一個方面。可以將其視為最終的標准草案； ·Internet Standard，最終的Internet標准，同時賦予一個STD編號。除此之外的TS和AS分為以下幾種"Maturity Level"。·Experimental，一般是反映一些研究和開發的成果，只應將此看作是一般性的信息。·Informational，反映與Internet標准有關的一般性信息。有些也是有關非Intern et組織開發的一些協議，但必須得到協議開發者的許可。·Historic，是一些被新的標准取代或者是已經過時廢棄不用的標准。STD1(RFC2200）——Internet Official Protocol Standards，定期更新，反映最新的 Internet標准。另外，對於關注Internet的人來說，應該經常注意查閱BCP9的最新內容。
一是需要確定它是最新的文檔，二是需要注意RFC文檔的類別；
所有的RFC文檔都要經歷評論和反饋過程，並且在這一段時間內它們會被劃分為不同的類別；
RFC文檔一旦被提交，IETF和IAB組織將審查RFC文檔，通過後可以成為一項標准；
RFC文檔按照它發展與成熟的過程可以分為標准、草案標准、提案標准、實驗性的、信息性或 歷史 性的；
RFC文檔又可以分為被要求、被推薦、被選擇、受限制使用或不被推薦；
RFC文檔是什麼。