DNSDNS最早于1983由保羅.莫卡派喬斯(Paul Mockapetris)發(fā)明;原始的技術(shù)規(guī)范在882號因特網(wǎng)標(biāo)準(zhǔn)草案(RFC 882)中發(fā)布。1987年發(fā)布的第1034和1035號草案修正了DNS技術(shù)規(guī)范，并廢除了之前的第882和883號草案。在此之后對因特網(wǎng)標(biāo)準(zhǔn)草案的修改基本上沒有涉及到DNS技術(shù)規(guī)范部分的改動(dòng)。早期的域名必須以英文句號“.”結(jié)尾,，這樣DNS才能夠進(jìn)行域名解析。如今DNS服務(wù)器已經(jīng)可以自動(dòng)補(bǔ)上結(jié)尾的句號。當(dāng)前，對于域名長度的限制是63個(gè)字符，包括www.和.com或者其他的擴(kuò)展名。域名同時(shí)也僅限于ASCII字符的一個(gè)子集，這使得很多其他語言無法正確表示他們的名字和單詞?；赑unycode碼的IDNA系統(tǒng)，可以將Unicode字符串映射為有效的DNS字符集，這已經(jīng)通過了驗(yàn)證并被一些注冊機(jī)構(gòu)作為一種變通的方法所采納。

HTTPHTTP的發(fā)展是萬維網(wǎng)協(xié)會(huì)(World Wide Web Consortium)和Internet工作小組(Internet Engineering Task Force)合作的結(jié)果，(他們)最終發(fā)布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協(xié)議中一個(gè)現(xiàn)今被廣泛使用的版本——HTTP 1.1。

HTTP是一個(gè)客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)(TCP)?？蛻舳耸墙K端用戶，服務(wù)器端是網(wǎng)站。通過使用Web瀏覽器、網(wǎng)絡(luò)爬蟲或者其它的工具，客戶端發(fā)起一個(gè)到服務(wù)器上指定端口(默認(rèn)端口為80)的HTTP請求。(我們稱這個(gè)客戶端)調(diào)用戶代理(user agent)。應(yīng)答的服務(wù)器上存儲著(一些)資源，比如HTML文件和圖像。(我們稱)這個(gè)應(yīng)答服務(wù)器為源服務(wù)器(origin server)。在用戶代理和源服務(wù)器中間可能存在多個(gè)中間層，比如代理，網(wǎng)關(guān)，或者隧道(tunnel)。盡管TCP/IP協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP協(xié)議并沒有規(guī)定必須使用它和(基于)它支持的層。事實(shí)上，HTTP可以在任何其他互聯(lián)網(wǎng)協(xié)議上，或者在其他網(wǎng)絡(luò)上實(shí)現(xiàn)。HTTP只假定(其下層協(xié)議提供)可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用。通常，由HTTP客戶端發(fā)起一個(gè)請求，建立一個(gè)到服務(wù)器指定端口(默認(rèn)是80端口)的TCP連接。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽客戶端發(fā)送過來的請求。一旦收到請求，服務(wù)器(向客戶端)發(fā)回一個(gè)狀態(tài)行，比如"HTTP/1.1 200 OK"，和(響應(yīng)的)消息，消息的消息體可能是請求的文件、錯(cuò)誤消息、或者其它一些信息。HTTP使用TCP而不是UDP的原因在于(打開一個(gè))一個(gè)網(wǎng)頁必須傳送很多數(shù)據(jù)，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)，和錯(cuò)誤糾正。具體細(xì)節(jié)請參考‘TCP和UDP的不同’。通過HTTP或者HTTPS協(xié)議請求的資源由統(tǒng)一資源定位器(Uniform Resource Identifiers，或者，更準(zhǔn)確一些，URI)來標(biāo)識。

FTP服務(wù)一般運(yùn)行在20和21兩個(gè)端口。端口20用于在客戶端和服務(wù)器之間傳輸數(shù)據(jù)流，而端口21用于傳輸控制流，并且是命令通向ftp服務(wù)器的進(jìn)口。當(dāng)數(shù)據(jù)通過數(shù)據(jù)流傳輸時(shí)，控制流處于空閑狀態(tài)。而當(dāng)控制流，空閑很長時(shí)間后，客戶端的防火墻，會(huì)將其會(huì)話置為超時(shí)，這樣當(dāng)大量數(shù)據(jù)通過防火墻時(shí)，會(huì)產(chǎn)生一些問題。此時(shí)，雖然文件可以成功的傳輸，但因?yàn)榭刂茣?huì)話，會(huì)被防火墻斷開;傳輸會(huì)產(chǎn)生一些錯(cuò)誤。FTP實(shí)現(xiàn)的目標(biāo)：促進(jìn)文件的共享(計(jì)算機(jī)程序或數(shù)據(jù))鼓勵(lì)間接或者隱式的使用遠(yuǎn)程計(jì)算機(jī)向用戶屏蔽不同主機(jī)中各種文件存儲系統(tǒng)(File system)的細(xì)節(jié)可靠和高效的傳輸數(shù)據(jù)缺點(diǎn)：密碼和文件內(nèi)容都使用明文傳輸，可能產(chǎn)生不希望發(fā)生的竊聽。因?yàn)楸仨氶_放一個(gè)隨機(jī)的端口以建立連接，當(dāng)防火墻存在時(shí)，客戶端很難過濾處于主動(dòng)模式下的FTP流量。這個(gè)問題，通過使用被動(dòng)模式的FTP，得到了很大解決。服務(wù)器可能會(huì)被告知連接一個(gè)第三方計(jì)算機(jī)的保留端口。此方式在需要傳輸文件數(shù)量很多的小文件時(shí)，效能不好FTP雖然可以被終端用戶直接使用，但是它是設(shè)計(jì)成被FTP客戶端程序所控制。運(yùn)行FTP服務(wù)的許多站點(diǎn)都開放匿名服務(wù)，在這種設(shè)置下，用戶不需要帳號就可以登錄服務(wù)器，默認(rèn)情況下，匿名用戶的用戶名是：“anonymous”。這個(gè)帳號不需要密碼，雖然通常要求輸入用戶的郵件地址作為認(rèn)證密碼，但這只是一些細(xì)節(jié)或者此郵件地址根本不被確定，而是依賴于FTP服務(wù)器的配置情況。應(yīng)用層協(xié)議為應(yīng)用程序之間的通信提供規(guī)則，為確保通信暢通，源主機(jī)和目的主機(jī)上所實(shí)現(xiàn)的應(yīng)用層協(xié)議必須一致。