《圖解TCP/IP》閱讀筆記-8應用協議

8.1應用層協議概要

  • TCP和IP等下層協議是不依賴與上層應用類型、適用性非常廣的協議。而應用協議是為了實現某種應用而設計和創造的協議。
  • TCP/IP的應用層涵蓋了OSI參考模型中的第5、6、7層的所有功能,不僅包含了管理通信連接的會話層功能、轉換數據格式的表示層功能,還包含與對端主機交互的應用層功能在內的所有功能。

8.2遠程登錄

實現從自己的本地計算機登錄到網絡另一端計算功能的應用就叫做遠程登錄。遠程登錄主要使用TELNET和SSH兩種協議。

TELNET

  • TELNET利用TCP的一條連接向主機發送文字命令并在主機上執行。TELNET提供兩類服務:仿真終端功能、協商選項機制。
  • Shell是操作系統提供給用戶的,便于使用該系統中各種功能的一種用戶接口。
仿真終端功能
選項功能實現的行模式或透明模式的設置
  • TELNET客戶端通常與目標主機的23號端口建立連接,并與監聽這個端口的服務端程序telnetd進行交互,也可與其他TCP端口號連接,只要該端口上有監聽程序能夠處理telnet請求即可。如:“ftp 主機名” 與“telnet 主機名 21”可視為相同的。

SSH

  • SSH是加密的遠程登錄系統。
  • 端口轉發是指特定端口號所收到的消息轉發到特定IP地址和端口號碼的一種機制。由于經過SSH連接的部分內容被加密,確保了信息安全提供了靈活的通信,可用來實現VPN。


    SSH的端口轉發

8.3文件傳輸

  • FTP是在兩個相連的計算機之間進行文件傳輸時使用的協議,它使用兩條TCP連接:一條用來控制,另一條用于數據傳輸。
  • FTP中請求命令使用“RETR”等ASCII碼字符串,而針對這些命令的應答則使用“200”等3位數字的ASCII碼字符串。

8.4電子郵件

早期電子郵件發送過程
現在互聯網中電子郵件發送過程

電子郵件的機制由3部分構成:郵件地址、數據格式及發送協議。

郵件地址

名稱@通信地址
電子郵件的發送地址有DNS進行管理,DNS中注冊有郵件地址及其作為發送地址時對應的郵件服務器的域名。這些映射信息被稱作MX記錄。

MIME

早期的電子郵件只能處理文本格式,現在其所能發送的數據類型已經擴展到MIME(Multipurpose Internet Mail Extensions),可以發送靜態圖像、動畫、聲音、程序等各種形式的數據。鑒于MIME規定了應用消息的格式,因此在OSI參考模型中它相當于第6層表示層。

SMTP

SMTP是發送電子郵件的協議,它使用的是TCP的25號端口。SMTP建立一個TCP連接以后,在這個連接上進行控制和應答以及數據的發送,客戶端以文本的形式發出請求,服務端返回一個3位數字的應答。

SMTP本身沒有驗證發送者的功能,不過現在的“POP before SMTP”以及“SMTP認證”等功能可以進行驗證,并且很多供應商已將網絡設置為除自己本域的郵件服務器外不與其他網絡的25號端口進行通信。
當允許使用TELNET登錄SMTP服務器時,可使用如下命令:
telnet 服務器名或其IP地址 25

POP

SMTP的缺點在于它支持的是發送端主機的行為,而不是根據接收端的請求發送郵件。
POP是用于接收電子郵件的協議,發送端的郵件根據SMTP協議將被轉發給一直處于插電狀態的POP服務器,客戶端再更具POP協議從POP服務器接收對方發來的郵件,在這個過程中,還要進行用戶驗證。


POP與SMTP一樣也是建立一個TCP連接完成操作。其命令都是較短的ASCII碼字符串,應答只有“+OK”和“ERR”兩種。
當允許使用TELNET登錄POP服務器時,可使用如下命令:
telnet 服務器名或其IP地址 110

IMAP

IMAP(Internet Message Access Protocol)與POP類似也是接收電子郵件的協議,在POP中郵件由客戶端進行管理,而在IMAP中則由服務器進行管理,它可以不用從服務器下載所有的郵件也可以閱讀,即在服務器上保存和管理郵件信息。

8.5WWW

萬維網(WWW,World Wide Web)是將互聯網中的信息以超文本形式展現的系統,也叫做Web。WWW定義了3個重要的概念:

  • URI(Uniform Resource Identifier)訪問信息的手段和位置
  • HTML(HyperText Markup Language)信息的表現形式
  • HTTP(HyperText Transfer Protocol)信息轉發

URI

URI(Uniform Resource Identifier)是一種除WWW之外的用于標識資源的高效識別碼,URL常被人們用來表示互聯網中資源文件的具體位置,但是URI不局限于標識互聯網資源,它可以作為所有資源的識別碼。
URI的http方案的具體格式如下:
http: //主機名/路徑
http: //主機名:端口號/路徑
http: //主機名:端口號/路徑?訪問內容#部分信息
省略端口號時,則采用http的默認端口80。

HTML

HTML是記述Web頁的一種語言(數據格式),它可以指定瀏覽器中顯示的文字、文字顏色、大小等,還可以對圖像或動畫、音視頻內容進行設置。
HTML具有純文本的功能,可以說是WWW通用的數據表現協議,對應到OSI參考模型,可以認為HTML屬于WWW的表示層。

HTTP

它的工作機制是首先客戶端向服務器的80端口建立一個TCP連接,然后再這個TCP連接上進行請求和應答以及數據報文的發送


HTTP常用兩個版本:HTTP1.0與HTTP1.1,在HTTP1.0中每一個命令和應答都會觸發一次TCP連接的建立和斷開。而從HTTP1.1開始,允許在一個TCP連接上發送多個命令和應答,因此大量減少了TCP連接的建立和斷開操作,從而提高了效率。
當允許HTTP服務器和TELNET連接時,可以如下形式登陸HTTP服務器:
telnet 服務器名或其IP地址 80

JavaScript、CGI、Cookie

JavaScript是一種嵌入在HTML中的編程語言,作為客戶端程序可以運行于多種類型的瀏覽器中。Javascript還可以用于操作HTML或XML的邏輯結構(DOM,Document Object Model)以及動態顯示Web頁的內容和頁面風格上。
CGI(Common Gateway Interface)是Web服務器調用外部程序時所使用的一種服務端應用的規范,引入CGI后客戶端請求會觸發Web服務器運行另一個程序,客戶端所輸入的數據也會傳給這個外部程序。該程序運行結束后會將生成的HTML和其他數據再返回給客戶端。
Web應用中為了獲取用戶信息使用一個叫做Cookie的機制,Web服務器用Cookie在客戶端保存信息,通過檢查Cookie可以確認是否為同一對端的通信。

8.6網絡管理

SNMP

在TCP/IP的網絡管理中可以使用SNMP(Simple Network Management Protocol)收集必要的信息,它是一款基于UDP/IP的協議。
SNMP中管理端叫做管理器,被管理端叫做代理(路由器、交換機等)。


MIB

SNMP中交互的信息是MIB(Management Information Base)。MIB是在樹形結構的數據庫中為每個項目附加編號的一種信息結構。SNMP中可以將MIB值寫入代理,也可以從代理中讀取MIB值,通過這些操作可以收集沖突次數和流量統計等信息,可以修改IP地址,也可進行路由器的啟廳,設備啟動關閉等處理。

RMON

RMON是Remote Monitoring MIB的縮寫,MIB由監控網絡中某個設備接口的眾多參數構成,RMON則由監控網絡上線路的眾多參數構成,它將原來的監控信息從一個點擴展到了一條線上。

8.7其他應用層協議

多媒體通信實現技術

通過UDP來提高即時性,H.323與SIP協議提供呼叫控制、RTP協議(結合多媒體數據本身的特性進行傳輸的一種協議)和壓縮技術等眾多技術可以實現實時多媒體通信。

  • H.323是用于IP網上傳輸音頻、視頻的一種協議。
  • 與H.323相對的TCP/IP協議是SIP(Session Initiation Protocol)協議,終端之間進行多媒體通信時,需要具備事先解析對方地址,呼出對方號碼并對所要傳輸的媒體信息進行處理等功能,還有具備中斷對話和數據轉發的功能,這些功能都被統一于SIP協議中。


  • UDP不是一種可靠性傳輸協議,因此有可能發生丟包或亂序等現象,因此采用UDP實現實時的多媒體通信需要附加一個表示報文順序的序列號字段,還需對其發送時間進行管理,這些正是RTP(Real-Time Protocol)的主要職責。RTP為每個報文添加時間戳和序列號。

P2P

互聯網上的通信普遍屬于一臺服務器對應多個客戶端的C/S模式,與之不同的是網絡上的終端或主機不經服務器直接1對1相互通信的情況叫做P2P(Peer to Peer),它可以分散數據給網絡帶來的負荷,實現更高效的應用。

LDAP

LDAP(lightweight Directory Access Protocol)是訪問目錄服務的一種協議,就像DNS是為了更簡單的對網絡上的各個主機進行管理一樣,LDAP是為了更簡單的管理網絡上的各種資源。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,546評論 6 533
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,570評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,505評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,017評論 1 313
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,786評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,219評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,287評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,438評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,971評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,796評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,995評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,540評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,230評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,662評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,918評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,697評論 3 392
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,991評論 2 374

推薦閱讀更多精彩內容

  • 個人認為,Goodboy1881先生的TCP /IP 協議詳解學習博客系列博客是一部非常精彩的學習筆記,這雖然只是...
    貳零壹柒_fc10閱讀 5,083評論 0 8
  • 1.這篇文章不是本人原創的,只是個人為了對這部分知識做一個整理和系統的輸出而編輯成的,在此鄭重地向本文所引用文章的...
    SOMCENT閱讀 13,110評論 6 174
  • 名詞延伸 通俗的說,域名就相當于一個家庭的門牌號碼,別人通過這個號碼可以很容易的找到你。如果把IP地址比作一間房子...
    楊大蝦閱讀 20,618評論 2 56
  • 一、網絡基礎知識 1. OSI 參考模型 OSI 模型中,每個分層都接受由它下一層所提供的特定服務,并且負責為自己...
    SeanCST閱讀 1,675評論 0 6
  • 版本記錄 前言 在互聯網行業中,不管你是客戶端前端還是后臺,只要是與網絡相關,你就必須了解一些基礎知識,包括這里的...
    刀客傳奇閱讀 1,899評論 0 16