以前對於http和ftp也是有所了解的，看了一遍英文版的rfc文件，雖然很痛苦，但是感覺是有所不同的。
1，http所表達的控制以及描述性相關的資訊都包含在了http的起始行和首部之中。bnf的使用使得自己能夠清晰的梳理出起始行和首部中所有類別的元資訊。對於每一類的元資訊具體包含哪些內容也能夠有所了解。這一抽象的方法不僅http協議定義的時候比較嚴謹之外，在實現http解析器（瀏覽器）的時候參照bnf寫**是非常容易實現的。這也提醒了我們在編寫相關的系統設計方案的時候是可以借鑑類似的方法的。畢竟使用文字表述的設計方案存在這問題遺漏，表述不夠清晰，不同人理解有所差異等方面的問題。（我們會看到在ftp之中也有類似的方法，狀態圖）。http被設計成為一種非常容易擴充套件的協議，因此協議時鬆散的。頭域可以加入需要的頭部名和指定的值，儘管有的頭部沒有加入rfc標準，但是可能成為約定成俗的標準(雖然這會給http的安全性帶來了挑戰)，由此可以看出良好的設計方案在一開始的時候就考慮到其以擴充套件性，這也是http能夠長期存在，不斷發展的原因。
2，ftp採用的是控制和資料相分離的模式實現檔案的傳送。首先這一設計思想在程式的設計之中本身就很常見。ftp採用的是命令+響應碼的形式來控制檔案傳輸的功能，若干條命令+不同類別的響應碼會導致不同的結果，其組合方式多種多樣，但是ftp的rfc文件給出了這些組合的狀態圖。六種型別的狀態圖覆蓋了ftp可能的所有情況。前面我們提到http的bnf表示方法利於編寫程式，這裡的狀態圖同樣給出了編寫完備ftp軟體的指導性方法。當然狀態圖也可以看出有的命令是有先後順序的，但是大多數的命令是沒有此要求的。
3，rtsp可以說基本復用了http的設計思路，從請求和響應的訊息組成可以清晰的看出。但是其也借鑑了ftp中相關的優秀思想。比如資料和控制的分離，rtsp的資料傳輸就是由rtp/rtcp等協議去實現的。在http中，請求響應模式採用的是cs的模式，即客戶端發起請求，伺服器應答響應。ftp的就發生了變化，首先在ftp的架構之中存在這乙個客戶端控制這兩個伺服器的通訊。兩個server的通訊以及在ftp中的port模式下（資料連線是由伺服器發起的），這兩種情況跟http就很不相同。至於到了rtsp請求是雙向的。
總的來說三種協議都是基於文字的應用層協議，基於文字的協議在需要某些屬性、方法或者命令的時候能夠比較方便的新增。相對與傳輸層以及網路層（雖然也有擴充套件）來說，固定的位置表達的含義是確定的，基於文字的協議比較靈活多變。當然協議最基本的分層原則也在http，ftp以及rtsp中有所體現，即應用層協議應儘量減少其與下層之間的耦合性。雖然常見的http都是基於tcp協議的，但是http並不關心整個http訊息在傳輸層如何使用的。
以上便是看完這幾篇rfc之後個人的一點拙見，有說的不對的地方，也請大家指正和吐槽。
RTSP協議閱讀 rfc2326
rtsp協議和http比較像，不同的是，http只能承載在tcp之上，並且只能是客戶端發訊息給伺服器，rtsp的話，沒有規定傳輸層，可以是tcp，也可以是udp，如果是tcp，伺服器也可以主動傳送request訊息給客戶端。rtsp採用主從 數字形式來表示版本，abnf語法是rtsp version...
HTTP 1 1協議更新 RFC 2616遭廢棄
近日，ietf更新了http 1.1協議，這是10多年來http 1.1協議的首次重大更新。組織者將原來的rfc 2616拆分為六個單獨的協議說明，並重點對原來語義模糊的部分進行了解釋，新的協議說明更易懂 易讀。新的協議說明包括以下六部分 早在2007年，ietf內部就成立了名為httpbis的工作...
HTTP和tcp，udp，ip等網路協議學習
前言，計算機網路的分層，按照osi標準，分為物理層 硬體 資料鏈路層 雙工等這一些 網路層 乙太網協議等 傳輸層 可以理解為計算機裡面的傳輸 會話層 建立乙個會話 表示層，應用層，看到狹義來說，可以把最後的會話，表示，應用層都統一為應用層 1，在資料鏈結層上的乙太網協議，分為head和data，he...