應用層

{

\"code\": 200,

\"title\": \"\",

\"content\": \"應用層也稱為應用實體（AE），它由若乾個特定應用服務元素（SASE）和一個或多個公用應用服務元素（CASE）組成。每個SASE提供特定的應用服務，例如檔案運輸訪問和管理（FTAM）、電子文電處理（MHS）、虛擬終端協議（VAP）等。CASE提供一組公用的應用服務，例如聯絡控製服務元素（ACSE）、可靠運輸服務元素（RTSE）和遠程操作服務元素（ROSE）等。\\n\\n應用層（Applicationlayer）是七層OSI模型的第七層。應用層直接和應用程式介麵並提供常見的網絡應用\\n\\n應用層\\n\\n服務。應用層也向表示層發出請求。\\n\\n應用層應用層是開放係統的最高層,是直接為應\\n\\n用進程提供服務的。其作用是在實現多個係統應用進程相互通訊的同時,完成一係列業務處理所需的服務.其服務元素分為兩類:公共應用服務元素CASE和特定應用服務元素SASE.\\n\\nCASE提供最基本的服務,它成為應用層中任何用戶和任何服務元素的用戶，主要為應用進程通訊,分佈係統實現提供基本的控製機製；特定服務SASE則要滿足一些特定服務,如文卷傳送,訪問管理,作業傳送,銀行事務,訂單輸入等。這些將涉及到虛擬終端,作業傳送與操作,文卷傳送及訪問管理,遠程數據庫訪問,圖形核心繫統,開放係統互連管理等等。\\n\\n主要功能和特點\\n\\n屬於應用的概念和協議發展得很快，使用麵又很廣泛，這給應用功能的標準化帶來了複雜性和困難性。比起其它層來說，應用層需要的標準最多，但也是最不成熟的一層。但隨著應用層的發展，各種特定應用服務的增多，應用服務的標準化開展了許多研究工作，ISO已製定了一些國際標準（IS）和國際標準草案（DIS）。因此，通過介紹一些具有通用性的協議標準，來描述應用層的主要功能及其特點。\\n\\n主要是提供網絡任意端上應用程式之間的介麵。\\n\\n檔案運輸、訪問和管理功能\\n\\n檔案運輸與遠程檔案訪問是任何計算機網絡最常用的兩種應用。檔案運輸與遠程訪問所使用的技術是類似的，都可以假定檔案位於檔案服務器機器上，而用戶是在顧客機器上並想讀、寫而整個或部分地運輸這些檔案，支援大多數現代檔案服務器的關鍵技術是虛擬檔案存儲器，這是一個抽象的檔案服務器。虛擬檔案存儲給顧客提供一個標準化的介麵和一套可執行的標準化操作。隱去了實際檔案服務器的不同內部介麵，使顧客隻看到虛擬檔案存儲器的標準介麵，訪問和運輸遠地檔案的應用程式，有可能不必知道各種各樣不相容的檔案服務器的所有細節。\\n\\n電子郵件功能\\n\\n計算機網絡上電子郵件的實現開始了人們通訊方式的一場革命。電子郵件的吸引力，在於象電話一樣，速度快，不要求雙方都同時在場，而且還留下可供處理或多處投遞的書寫文電拷貝。\\n\\n雖然電子郵件被認為隻是檔案運輸的一個特例，但它有一些不為所有檔案運輸所共有的特殊性質。因為，電子郵件係統首先需考慮一個完善的人機介麵，例如寫作，編輯和讀取電子郵件的介麵，其次要提供一個運輸郵件所需的郵政管理功能，例如管理郵件表和遞交通知等。此外，電子郵件與通用檔案運輸的另一個差彆是，郵件文電是最高度結構化的文字。在許多係統中，每個文電除了它的內容外，還有大量的附加資訊域，這些資訊域包括髮送方名和地址、接收方名和地址、投寄的日期和時刻、接收複寫副本的人員表、失效日期、重要性等級、安全\\n\\nISO標誌\\n\\n許可性以及其它許多附加資訊。\\n\\nISO標誌1984年CCITT製定了叫做MHS（文電處理係\\n\\n統）的X．400建議的一係列協議。ISO試圖把它們收進OSI的應用層，並叫做MOTIS（麵向文電的正交換係統）。由於X．400結構的缺少，這種吸收不是很簡單。1988年又修改了X.400，力爭與MOTIS會聚。本章我們將介紹MHS。\\n\\n虛擬終端功能\\n\\n由於種種原因，可以說終端標準化的工作已完全失敗了。解決這一問題的OSI方法是，定義一種虛擬終端，它實際上隻是代有實際終端的抽象狀態的一種抽象數據結構。這種抽象數據結構可由鍵盤和計算機兩者操作，並把數據結構的當前狀態反映在顯示器上。計算機能夠查詢此抽象數據結構，並能改變此抽象數據結構以使得螢幕上出現輸出。\\n\\n其它應用功能\\n\\n其它應用已經或正在標準化。在此，要介紹的是目錄服務、遠程作業錄入、圖形和資訊通訊。\\n\\n（1）目錄服務：它類似於電子電話本，提供了在網絡上找人或查到可用服務地址的方法。\\n\\n（2）遠程作業錄入：允許在一台計算機上工作的用戶把作業提交到另一台計算機上去執行。\\n\\n（3）圖形：具有發送如工程圖在遠地顯示和標繪的功能。\\n\\n（4）資訊通訊：用於家庭或辦公室的公用資訊服務。例如智慧用戶電報、電視圖文等。\\n\\n協議舉例\\n\\nDNS\\n\\nDNS最早於1893由保羅.莫卡派喬斯（PaulMockapetris）發明；原始的技術規範在882號因特網標準草案（RFC882）中釋出。1987年釋出的第1034和1035號草案修正了DNS技術規範，並廢除了之前的第882和883號草案。在此之後對因特網標準草案的修改基本上冇有涉及到DNS技術規範部分的改動。\\n\\n早期的域名必須以英文句號“.”結尾,，這樣DNS才能夠進行域名解析。如今DNS服務器已經可以自動補上結尾的句號。\\n\\n當前，對於域名長度的限製是63個字元，包括www.和.com或者其他的擴展名。域名同時也僅限於ASCII字元的一個子集，這使得很多其他語言無法正確表示他們的名字和單詞。基於Punycode碼的IDNA係統，可以將Unicode字串對映為有效的DNS字元集，這已經通過了驗證並被一些註冊機構作為一種變通的方法所采納。\\n\\nHTTP\\n\\nHTTP的發展是萬維網協會（WorldWideWebConsortium）和Internet工作小組（InternetEngineeringTaskForce）合作的結果，（他們）最終釋出了一係列的RFC，其中最著名的就是RFC2616。RFC2616定義了HTTP協議中一個現今被廣泛使用的版本——HTTP1.1。\\n\\nHTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定（默認為80）的HTTP請求。（我們稱這個客戶端）調用戶代理（useragent）。應答的服務器上存儲著（一些）資源，比如HTML檔案和圖像。（我們稱）這個應答服務器為源服務器（originserver）。在用戶代理和源服務器中間可能存在多箇中間層，比如代理，網關，或者隧道（tunnel）。儘管TCP\\/IP協議是互聯網上最流行的應用，HTTP協議並冇有規定必須使用它和（基於）它支援的層。事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。\\n\\n電子郵件\\n\\nHTTP隻假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。\\n\\n電子郵件通常，由HTTP客\\n\\n戶端發起一個請求，建立一個到服務器指定（默認是80）的TCP連接。HTTP服務器則在那個監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，比如\\\"HTTP\\/1.1200OK\\\"，和（響應的）訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些資訊。\\n\\nHTTP使用TCP而不是UDP的原因在於（打開一個）一個網頁必須傳送很多數據，而TCP協議提供傳輸控製，按順序組織數據，和錯誤糾正。具體細節請參考‘TCP和UDP的不同’。\\n\\n通過HTTP或者HTTPS協議請求的資源由統一資源定位器（UniformResourceIdentifiers，或者，更準確一些，URI）來標識。\\n\\nFTP\\n\\nFTP服務一般運行在20和21兩個。20用於在客戶端和服務器之間傳輸數據流，而21用於傳輸控製流，並且是命令通向ftp服務器的進口。當數據通過數據流傳輸時，控製流處於空閒狀態。而當控製流，空閒很長時間後，客戶端的防火牆，會將其會話置為超時，這樣當大量數據通過防火牆時，會產生一些問題。此時，雖然檔案可以成功的傳輸，但因為控製會話，會被防火牆斷開；傳輸會產生一些錯誤。\\n\\nFTP實現的目標：\\n\\n促進檔案的共享（計算機程式或數據）鼓勵間接或者隱式的使用遠程計算機向用戶遮蔽不同主機中各種檔案存儲係統（Filesystem）的細節可靠和高效的傳輸數據缺點：\\n\\n密碼和檔案內容都使用明文傳輸，可能產生不希望發生的竊聽。因為必須開放一個隨機的以建立連接，當防火牆存在時，客戶端很難過濾處於主動模式下的FTP流量。這個問題，通過使用被動模式的FTP，得到了很大解決。服務器可能會被告知連接一個第三方計算機的保留。此方式在需要傳輸檔案數量很多的小檔案時，效能不好FTP雖然可以被終端用戶直接使用，但是它是設計成被FTP客戶端程式所控製。\\n\\n運行FTP服務的許多站點都開放匿名服務，在這種設置下，用戶不需要帳號就可以登錄服務器，默認情況下，匿名用戶的用戶名是：“anonymous”。這個帳號不需要密碼，雖然通常要求輸入用戶的郵件地址作為認證密碼，但這隻是一些細節或者此郵件地址根本不被確定，而是依賴於FTP服務器的配置情況。\\n\\n\"

}