哈工大計算機網絡Week1-網絡應用


哈工大計算機網絡Week1-網絡應用

目錄

2.1網絡應用的體系結構

特點

由不同的部分構成,由網絡連接組合應用場景

應采取什么結構

C/S結構 客戶機/服務器

P2P

混合結構

C/S結構 客戶機/服務器

  • 服務器
    • 持續提供服務
    • 永久性訪問地址/域
    • 利用大量服務器實現可擴展性
  • 客戶機
    • 與服務器通信,使用服務器提供的服務
    • 間歇性接入網絡
    • 可能使用動態IP地址
    • 客戶機之間無通信能力

P2P

點對點服務,去中心化體系結構。純P2P中,資源索引是維護在每個節點上的,查找信息時需要在網絡中進行廣播,查詢被一層層節點擴散,直到查找到有效信息。

  • 描述
    • 沒有永遠在線的服務器
    • 任意端系統/節點之間可以直接通訊
    • 節點間歇性接入網絡
    • 節點可能改變IP地址

CS vs P2P

從服務及時、傳輸質量穩定、資源查找速度、管理成本、網絡安全、客戶端節點間交流能力、網絡閑散資源利用率

  • CS>P2P
    • CS更安全,隱私不容易泄露,因為客戶機間不可見,客戶機只能訪問由服務器暴露的經其他客戶機允許的其他客戶機的信息,服務器能輕松的設置安全機制。P2P則不能,個人計算機安全等級較服務器來說低很多。可能帶來垃圾信息或者匿名失效。
    • CS服務隨時支持,P2P則需要提供服務的節點在線才行。
    • CS服務穩定,因為服務器通常是性能強大的設備群。而P2P受制於服務器節點,穩定性不可預見。
    • CS中心式結構便於集中管理資源以及客戶端,P2P結構松散不便於管理資源。
    • CS文件查找速度快,P2P需要將查找命令在P2P網絡中層層傳播,比較慢
  • P2P>CS
    • P2P能充分利用節點資源,提高限制資源利用率。CS無法充分利用客戶機的能力。使得整個網絡負擔過多集中在服務器,客戶機性能冗余。
    • P2P管理成本低,雖然難以有效管理但是去中心化的結構使得管理成本低。CS則要求中心服務器的管理軟硬件要求高。
    • 結構自由。CS結構限制較大。
    • P2P網絡分布廣泛,能夠大范圍提供服務。C-S距離太遠延遲高,每個服務器輻射的范圍有限,需要采用分布式多服務器來提供服務。

混合結構

能否將兩種結構混合在一起使用?
混合能夠利用兩者的優點同時規避兩者的缺點嗎?

目前的混合結構主要有2種:

  • 中心化拓撲P2P(例如Napster)
    • 文件傳輸使用P2P結構
    • 文件的搜索采用C/S結構——集中式
      • 每個節點向中央服務器登記自己的內容
      • 每個節點向中央服務器提交查詢請求,查找感興趣的內容
  • 半分布式拓撲結構P2P
    • 節點分成索引節點和普通節點,索引節點負責為臨近普通節點提供服務。
    • 各個索引節點之間采用去中心化結構
  • 全分布式結構化拓撲的P2P網絡主要是采用分布式散列表(Distributed Hash Table, 簡寫成DHT)技術來組織網絡中的結點。DHT是一個由廣域范圍大量結點共同維護的巨大散列表。散列表被分割成不連續的塊,每個結點被分配給一個屬於自己的散列塊,並成為這個散列塊的管理者。通過加密散列函數,一個對象的名字或關鍵詞被映射為128位或160位的散列值。
    • 即對目錄進行了分割,使得目錄被結構化組織

思考題目

為每種體系結構找出5種以上的網絡應用:

從多個方面/角度對比三種體系結構的優缺點

2.2網絡應用的基本原理

網絡應用進程通信

進程間通信

  • 進程
    • 主機上運行的程序
    • 客戶機進程: 發起通信的進程
    • 服務器進程: 等待通信請求的進程
  • 同一主機上運行的進程之間如何通信?
    • 進程間通信機制
    • 操作系統提供
  • 不同主機上運行的進程間如何通信?
    • 消息交換

采用P2P架構的應用是否存在客戶機進程/服務器進程之分?

也是有的,只是角色轉換非常自由。

套接字: Socket

  • Socket(套接字、插座)並不是一種協議,而是一種抽象API,將傳輸層TCP/UDP協議封裝,作為一種門面模式提供應用層抽象的連接服務。Socket實質上提供了進程通信的端點。
  • Socket=(所用協議,本地IP地址,本地進程端口號),唯一,由本地操作系統分配
  • Socket面向C/S設計。
  • C/S連接建立過程
    • 服務器監聽:是服務器端套接字並不定位具體的客戶端套接字,而是處於等待連接的狀態,實時監控網絡狀態。
    • 客戶端請求:是指由客戶端的套接字提出連接請求,要連接的目標是服務器端的套接字。為此,客戶端的套接字必須首先描述它要連接的服務器的套接字,指出服務器端套接字的地址和端口號,然后就向服務器端套接字提出連接請求。
    • 連接確認:是指當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求,它就響應客戶端套接字的請求,建立一個新的線程,把服務器端套接字的描述發給客戶端,一旦客戶端確認了此描述,連接就建立好了。而服務器端套接字繼續處於監聽狀態,繼續接收其他客戶端套接字的連接請求。

尋址

不同主機上的進程間通信,那么每個進程必須擁有標識符

  • 如何尋址主機?——IP地址
    • Q: 主機有了IP地址后,是否足以定位進程?
    • A: 否。IP地址只能定位主機,同一主機上可能同時有多個進程需要通信。
  • 端口號/Port number
    • 為主機上每個需要通信的進程分配一個端口號
    • HTTP Server: 80
    • Mail Server:25
  • 進程的標識符
    • IP地址+端口號

應用層協議

網絡應用需遵循應用層協議,但是不僅僅有應用層協議

  • 公開協議(由RFC定義)
    • DNS
    • FTP
    • SMTP
    • HTTP
    • Telnet(遠程登陸服務)
  • 私有協議
    • 多數P2P文件共享應用
  • 應用層數據傳輸依賴傳輸層協議:
    • tcp
    • udp

應用層協議的內容

信息類型、信息語法、信息語義、信息規則

  • 消息的類型(type)
    • 請求消息
    • 響應消息
  • 消息的語法(syntax)/格式
    • 消息中有哪些字段(field)?
    • 每個字段如何描述
  • 字段的語義(semantics)
    • 字段中信息的含義
  • 規則(rules)
    • 進程何時發送/響應消息
    • 進程如何發送/響應消息

網絡應用的需求與傳輸層服務

網絡應用對傳輸服務的需求

  • 數據丟失(data loss)/可靠性(reliability)
    • 某些網絡應用能夠容忍一定的數據丟失:網絡電話
    • 某些網絡應用要求100%可靠的數據傳輸:文件傳輸,telnet
  • 時間(timing)/延遲(delay)
    • 有些應用只有在延遲足夠低時才“有效”
    • 網絡電話/網絡游戲
  • 帶寬(bandwidth)
    • 某些應用只有在帶寬達到最低要求時才“有效”:網絡視頻
    • 某些應用能夠適應任何帶寬——彈性應用:email
  • 延遲和帶寬的不同
    • 帶寬是bps,是單位時間交換數據量,延遲是數據發送到接受所用時間,和帶寬不是一個概念。
    • 帶寬小於發送量會導致延遲上升。帶寬小於發送量仍然有延遲,此時延遲是數據從源發送到目的所需時間

Internet提供的傳輸服務

  • TCP服務,傳輸控制協議(英語:Transmission Control Protocol,縮寫為TCP
    • 面向連接: 客戶機/服務器進程間需要建立連接。
    • 靠的數據傳輸:准確、完整、有序。注意沒有帶寬和延遲!
      • 准確:保證數據包沒有失真
        • 校驗碼
      • 完整:降低丟包率
        • 接受反饋:接受發接受到數據必須告知發送方,否則發送方會重發,保證分組完整
        • 流量控制: 發送方不會發送速度過快,超過接收方的處理能力
        • 擁塞控制: 當網絡負載過重時能夠限制發送方的發送速度
      • 有序:保證分組重組順序正確
        • 為分組標記序號。接收方使用序號,不重收,不亂序。
    • 不提供時間/延遲保障
    • 不提供最小帶寬保障
    • 握手三次
      • A申請建立
      • B回復批准
      • A回復收到批准
    • 揮手四次
      • A申請結束
      • B回復收到申請,並發送尚未傳輸完成的數據
      • B批准申請
      • A回復收到批准
  • UDP服務,用戶數據報協議(英語:User Datagram Protocol,縮寫為UDP),又稱使用者資料包協定
    • 無連接,單純的發送出去
    • 不可靠的數據傳輸(單純的發送出去,什么保障都沒有)
    • 不提供
      • 可靠性保障
      • 流量控制
      • 擁塞控制
      • 延遲保障
      • 帶寬保障
    • 正是由與udp如此低級,他只能支持最基本的功能,但是它提供了掌控數據傳輸的自由性。可以讓應用自由設置發揮
  • 應用場景:
    • 穩定>速度:tcp
      • HTTP、FTP、POP、SMTP
    • 速度>穩定:udp
      • 視頻、語音通話

課后練習

  • 盤點你計算機上的所有網絡應用,制作一個清單,包括網絡應用的名字、功能、協議等。
  • 基於上述清單,制作表格,分析這些網絡應用對傳輸服務的需求。分析這些網絡應用所使用的傳輸服務是TCP還是UDP。

2.3Web應用

web應用概述

Web與HTTP

  • web萬維網是基於HTTP的Inernet因特網網絡服務
  • Internet將資源組織起來形成網絡,web的功能是為用戶提供資源索引展示服務
  • web將資源以URL定位使用超文本和超鏈接將資源連接起來,是一個由許多互相鏈接的超文本組成的系統
  • 超文本是包含超鏈接的文本,允許從當前閱讀位置直接切換到超鏈接所指向的文本、圖像、音視頻、文件等等。超鏈接就是指向其他資源的連接。
  • 網頁:超文本(如html)經瀏覽器解析渲染展現為網頁
  • 網頁互相鏈接:(准確的說是網頁的源相互連接)
  • 網頁(Web Page)包含多個對象(objects)
    • 基本HTML文件:包含對其他對象引用的鏈接
    • 對象:HTML文件、JPEG圖片、視頻文件、動態腳本等
  • 對象的尋址(addressing)

HTTP協議概述

HTTP,原名超文本傳輸協議,HyperText Transfer Protocol,是web萬維網遵守的協議之一。功能是:建立web服務器和本地客戶端(通常是瀏覽器)之間的數據交換。

  • 端口號:80
  • http網絡結構:C/S結構
    • 客戶—Browser:請求、接收、展示Web對象
    • 服務器—Web Server:響應客戶的請求,發送對象
  • HTTP版本:
    • 1.0: RFC 1945
    • 1.1: RFC 2068
  • http傳輸層協議:TCP傳輸協議
    • 服務器在80端口等待客戶的請求
    • 三次握手后,客戶端瀏覽器建立起到服務器的TCP連接
    • 瀏覽器(HTTP客戶端)與Web服務器(HTTP服務器)交換HTTP消息
    • 四次握手,關閉TCP連接
  • 無狀態(stateless),即無記錄
    • 服務器不記錄任何有關客戶端過去所發請求的信息
      • 有狀態的協議更復雜:
        • 需維護狀態(歷史信息)
        • 如果客戶或服務器失效,會產生狀態的不一致,解決這種不一致代價高
    • web通過cookie、session技術來實現狀態存儲功能。

HTTP連接

HTTP連接的兩種類型

  • 非持久性連接(NonpersistentHTTP)
    • 每個TCP連接最多允許傳輸一個對象
    • HTTP 1.0版本(早期)使用非持久性連接
  • 持久性連接(Persistent HTTP)
    • 每個TCP連接允許傳輸多個對象
    • HTTP 1.1版本默認使用持久性連接

非持久性連接

流程

假定用戶在瀏覽器中輸入URLwww.someSchool.edu/someDepartment/home.index(包含文本和指向10個jpeg圖片的鏈接)

  1. 服務器等待TCP連接中
  2. 客戶端使用socket申請tcp連接。
  3. 三次握手完成建立,在第三次握手同時傳輸Http請求信息。
  4. HTTP服務器收到請求消息,解析,產生包含所需要對象的響應消息,並通過套接字發給客戶端。HTTP服務器通知tcp連接斷開。(不過客戶端收到響應后才真正斷開)
  5. 當客戶端收到響應,tcp連接斷開,解析html文件,顯示html文件,發現有10個指向jpeg對象的超連接。
  6. 為每個jpeg對象重復步驟1-5。而不能接着上次的TCP連接繼續交流。

時延

  • 單位:RTT(Round Trip Time)
    • 從客戶端發送一個很小的數據包到服務器並返回所經歷的時間
  • 響應時間(Response time)
    • tcp三次握手前兩次:1RTT
    • tcp三次握手第三次+發送HTTP請求消息:0.5RTT,這里之所以不是1RTT是因為tcp三次握手第三次+發送HTTP請求消息同時發送。而不是等但三次握手完成再發送請求。
    • HTTP接受請求--HTTP響應消息的前幾個字節到達:0.5個RTT
    • 響應消息中所含的文件/對象傳輸時間
    • Total=2RTT +文件發送時間

非持久性連接的問題

  • 每個對象需要2個RTT:1+0.5+0.5
  • 操作系統需要為每個TCP連接開銷資源(overhead),同時刻創建大量的連接。
  • 瀏覽器會怎么做?
    • 打開多個並行的TCP連接以獲取網頁所需對象
    • 給服務器端note造成惡劣的影響,高密度tcp請求耗盡資源

持久性HTTP

  • 持久性連接
    • 發送響應后,服務器保持TCP連接的打開
    • 后續的HTTP消息可以通過這個連接發送
  • 無流水(pipelining)的持久性連接
    • 客戶端只有收到前一個響應后才發送新的請求
    • 每個被引用的對象耗時1個RTT
  • 帶有流水機制的持久性連接
    • HTTP 1.1的默認選項
    • 客戶端只要遇到一個引用對象就盡快發出請求
    • 理想情況下,收到所有的引用對象只需耗時約1個RTT
  • 這里計算延遲都是忽略了連接建立時間的1RTT!!只考慮申請發送+響應的1RTT!

HTTP消息格式

  • HTTP協議有兩類消息
    • 請求消息(request)
    • 響應消息(response)

HTTP請求消息

請求消息
使用ASCII書寫:人直接可讀

GET /somedir/page.html HTTP/1.1 請求行: 方法+url+http版本

Host: www.someschool.edu 頭部行

User-agent: Mozilla/4.0 頭部行

Connection: close 頭部行

Accept-language:fr 頭部行

Cookies 頭部行

空行(非常重要,講請求頭和消息體分開)

消息體,一般包括要填的表單

上傳附加輸入信息的方法

  • POST方法
    • 網頁經常需要填寫表格(form)
    • 在請求消息的消息體(entity body)中上傳客戶端的輸入,entity body在上述的name:value部分之后
  • GET方法
    • 使用URL傳輸,在url后link信息
    • 輸入信息通過request行的URL字段上傳

方法的類型

  • HTTP/1.0
    • GET
    • POST
    • HEAD
      • 請Server不要將所請求的對象放入響應消息,常常用來做測試
  • HTTP/1.1
    • GET, POST, HEAD
    • PUT
      • 消息體中的文件上傳到URL字段所指定的路徑
    • DELETE
      • 刪除URL字段所指定的文件

HTTP響應消息

date是生成該響應消息的時間,last-modified是請求的服務器資源(比如某個文件)最后的修改時間。

響應頭下一個空行與響應正文分割,響應正文就是申請的內容

HTTP響應狀態代碼

響應消息的第一行

示例
200 OK
301 Moved Permanently(資源已被永久改變位置)
400 Bad Request
404 Not Found
505 HTTP Version Not Supported

Cookie技術

為什么需要Cookie?

  • HTTP協議無狀態,但是很多應用需要服務器掌握客戶端的狀態,如網上購物,如何實現?

Cookie技術

  • Cookie技術
    • 某些網站為了辨別用戶身份、進行session跟蹤儲存在用戶本地終端上的數據(通常經過加密)。
    • RFC6265
  • Cookie的組件
    • HTTP響應消息的cookie頭部行
    • HTTP請求消息的cookie頭部行
    • 保存在客戶端主機上的cookie文件,由瀏覽器管理
    • Web服務器端的后台數據庫
  • Cookie和session
    • cookie存儲在客戶端,持續時間較長
    • session在服務端,持續時間較短,一般只在會話期間和會話結束后一小段時間內存在。

Cookie的原理

//TODO ##############################

技術細節沒有涉及到,此處要補充,包括session技術,以及cookie驗證機制

Cookie的作用

  • Cookie能夠用於:
    • 身份認證
    • 購物車
    • 推薦
    • Web e-mail
  • 隱私問題
    • cookie雖然經加密但不是沒有破解可能,但是客戶端安全性不高,一旦cookie被惡意獲取,隱私很可能泄露
    • 網站獲應用要求用戶提打開cookie功能才能正常訪問,暗中記錄用戶訪問信息。

思考題

  1. Cookie能夠怎樣被用於收集隱私?
  2. 能夠收集哪些隱私?
  3. 你在上網的時候感覺到自己的隱私
  4. 被嚴重侵犯嗎?

Web緩存/代理服務器技術

功能

在不訪問服務器的前提下滿足客戶端的HTTP請求。

為什么要發明這種技術?

  • 縮短客戶請求的響應時間
  • 減少機構/組織的流量
  • 在大范圍內(Internet)實現有效的內容分發

Web緩存/代理服務器

  • 用戶設定瀏覽器通過緩存進行Web訪問
  • 瀏覽器向緩存/代理服務器發送所有的HTTP請求
    • 如果所請求對象在緩存中,緩存返回對象
    • 否則,緩存服務器向原始服務器發送HTTP請求,獲取對象,然后返回給客戶端並存該對象
  • 緩存既充當客戶端,也充當服務器
  • 一般由ISP(Internet服務提供商)架設

Web緩存示例

  • 假定:

    • 對象的平均大小=100,000比特
    • 機構網絡中的瀏覽器平均每秒有15個到原始服務器的請求
    • 從機構路由器到原始服務器的往返延遲=2秒
  • 網絡性能分析:

    • 局域網(LAN)的利用率=1.5M/10M=15%
    • 接入互聯網的鏈路的利用率=100%
    • 總的延遲=互聯網上的延遲+訪問延遲+局域網延遲=2秒+幾分鍾+幾微秒
  • 解決方案1:

    • 提升互聯網接入帶寬=10Mbps
  • 網絡性能分析:

    • 局域網(LAN)的利用率=15%
    • 接入互聯網的鏈路的利用率=15%
    • 總的延遲=互聯網上的延遲+訪問延遲+局域網延遲=2秒+幾微秒+幾微秒
  • 問題:

    • 成本太高
  • 解決方案2:

    • 安裝Web緩存
    • 假定緩存命中率是0.4
  • 網絡性能分析:

    • 40%的請求立刻得到滿足
    • 60%的請求通過原始服務器滿足
    • 接入互聯網的鏈路的利用率下降到60%,從而其延遲可以忽略不計,例如10微秒
    • 總的平均延遲=互聯網上的延遲+訪問延遲+局域網延遲=0.6×2.01秒+0.4×min微秒<1.4秒
  • 問題:

    • 緩存和遠端服務器資源是否一致?或者版本是否滿足用戶要求?

條件性GET方法

解決了緩存和遠端服務器資源是否一致?或者版本是否滿足用戶要求?的問題。

最重要:條件get是代理服務器向原始服務器發送!

  • 目標:
    • 代理服務器向遠端服務其的get請求進行設計,告知遠端服務器該代理所持資源版本,遠端服務器檢查后,若是最新版則不發送請求的對象。
  • 緩存:
    • 在HTTP請求消息中聲明所持有版本的日期
    • If-modified-since: (告訴遠端,如果在**日期之后遠端資源更改,則發送所請求對象)
  • 服務器:
    • 如果緩存的版本是最新的,則響應消息中不包含對象
    • HTTP/1.0 304 Not Modified

課后作業

檢索文獻,分析、總結Web技術近
年來有哪些新進展?其關鍵思想和
技術是什么?

2.4Email應用

Email應用

Email應用的構成

  • Email應用的構成組件
    • 郵件客戶端(user agent):外圍
      • 讀、寫Email消息
      • 與服務器交互,收、發Email消息
      • Outlook, Foxmail, Thunderbird
      • Web客戶端
    • 郵件服務器:核心
      • 郵箱:存儲發給該用戶的Email
      • 消息隊列(message queue):存儲等待發送的Email
    • SMTP協議(Simple Mail TransferProtocol),簡單郵件傳輸協議
      • 郵件服務器之間傳遞消息所使用的協議
      • 客戶端:發送消息的服務器
      • 服務器:接收消息的服務器

實現異步發送,自動重試,在線緩存,延時發送等等功能。

SMTP協議: RFC 2821

SMTP是一個“推”的協議,它不允許根據需要從遠程服務器上“拉”來消息。要做到這點,郵件客戶端必須使用POP3或IMAP。

  • 使用TCP進行email消息的可靠傳輸
  • 端口25
  • 傳輸過程的三個階段
    • tcp握手
    • 消息的傳輸
    • tcp揮手
  • 命令/響應交互模式
    • 命令(command): ASCII文本
    • 響應(response): 狀態代碼和語句
  • Email消息只能包含7位ASCII碼,因為email系統開發是非常早期的時代

與HTTP對比

  • HTTP: 拉式(pull)
  • SMTP: 推式(push)
  • 都使用命令/響應交互模式
  • 命令和狀態代碼都是ASCII碼
  • HTTP: 每個對象封裝在獨立的響應消息中
  • SMTP: 多個對象在由多個部分構成的消息中發送

動手嘗試SMTP交互

  • telnet servername 25
  • 服務器返回代碼220
  • 輸入以下命令與SMTP服務器交互
    • HELO
    • MAIL FROM
    • RCPT TO
    • DATA
    • QUIT

思考題

Email作為互聯網上的古老應用,從
出現至今經過了什么樣的演變過程?
站在今天的角度看,Email應用有哪
些缺點和不足?請查閱資料,給出你
的見解。

Email消息格式與POP3協議

Email消息格式

  • SMTP:email消息的傳輸/交換協議
  • RFC 822:文本消息格式標准
    • 頭部行(header)
      • To
      • From
      • Subject(主題)
    • 空行
    • 消息體(body)
      • 消息本身(只能是ASCII字符)

Email消息格式:多媒體擴展

  • MIME:多媒體郵件擴展 RFC 2045, 2056
    • 通過在郵件頭部增加額外的行以聲明MIME的內容類型

郵件訪問協議(不同與STMP協議)

郵件訪問協議:從服務器獲取郵件。Mail Access Protocol

EMAIL應用使用多個協議完成功能

  • POP3: Post Office Protocol [RFC 1939]
    • 認證/授權(客戶端<-->服務器)和下載
  • IMAP: Internet Mail Access Protocol [RFC 1730]
    • 更多功能
    • 更加復雜
    • 能夠操縱服務器上存儲的消息
    • 趨勢
  • HTTP:163, QQ Mail等。也可以當作一種郵件訪問協議

POP3協議

  • 認證過程(兩次握手)
    • 客戶端命令
      • User:聲明用戶名
      • ass: 聲明密碼
    • 服務器響應
      • +OK
      • -ERR
  • 事務階段
    • List:列出消息數量
    • Retr:用編號獲取消息
    • Dele: 刪除消息
    • Quit
  • “下載並刪除”模式,下載到本地,刪除服務器上的信息。POP協議僅支持該模式。
    • 用戶如果換了客戶端軟件,無法重讀該郵件
  • “下載並保持”模式:不同客戶端都可以保留消息的拷貝。POP3支持,POP不支持
  • POP3是無狀態的。客戶端的動作不能保存到服務器上。比如刪除、移動文件

IMAP協議

  • 有狀態協議,支持CS雙向通信
    • 所有消息統一保存在一個地方:服務器
    • 允許用戶利用文件夾組織消息,刪除移動文件服務器會同步
  • IMAP支持跨會話(Session)的用戶狀態:
    • 文件夾的名字
    • 文件夾與消息ID之間的映射等
  • IMAP更好地支持了從多個不同設備中隨時訪問新郵件。
  • IMAP提供的摘要瀏覽功能可以讓你在閱讀完所有的郵件到達時間、主題、發件人、大小等信息后才作出是否下載的決定。

Email流程示例

對host:a、b,a發SMTP送郵件m給a的郵件服務器A,A遵循STMP將m發送給b的郵件服務器B,b使用access protocol來獲取B上的信件

課后練習

請查閱資料,比較IMAP與POP3的
不同,並調研主流Email服務對
IMAP協議的支持情況。

1、IMAP提供Webmail 與電子郵件客戶端之間的雙向通信客戶端收取的郵件仍然保留在服務器上,同時在客戶端上的操作都會反饋到服務器上(如:刪除郵件,標記已讀等,服務器上的郵件也會做相應的動作。所以無論從瀏覽器登錄郵箱或者客戶端軟件登錄郵箱,看到的郵件以及狀態都是一致的。)。而POP3在客戶端的操作不會反饋到服務器上。

2、IMAP更好地支持了從多個不同設備中隨時訪問新郵件。

3、IMAP提供的摘要瀏覽功能可以讓你在閱讀完所有的郵件到達時間、主題、發件人、大小等信息后才作出是否下載的決定。

4、POP3需要下載未閱讀的郵件,IMAP可以不用把所有的郵件全部下載,而是通過客戶端直接對服務器上的郵件進行操作。所有通過IMAP傳輸的數據都會被加密,從而保證通信的安全性。

5、IMAP 整體上為用戶帶來更為便捷和可靠的體驗。POP3 更易丟失郵件或多次下載相同的郵件。

2.5DNS服務

DNS概述

DNS:Domain Name System

  • Internet上主機/路由器的識別問題
    • IP地址
    • 域名:www.hit.edu.cn。是為了方便記憶IP,是面向人類的,IP地址是面向計算機的。
  • 域名解析系統DNS:解決問題:域名和IP地址之間如何映射?
    • 多層命名服務器構成的分布式數據庫
    • DNS本身也是一個應用層協議
      • • DNS提供Internet核心功能,但是在應用層使用用應用層協議實現
      • • 網絡邊界復雜
  • DNS服務具體內容
    • 域名向IP地址的翻譯
    • 主機別名
    • 郵件服務器別名
    • 負載均衡:Web服務器,例如輪換web服務器排名
  • 問題:為什么不使用集中式的DNS?
    • 單點失敗問題
    • 流量問題
    • 距離問題
    • 維護性問題

分布式層次式數據庫

以迭代查詢為例:

  • 客戶端想要查詢www.amazon.com的IP
    • 先向本地DNS申請查詢
      • 本地dns查看緩存,有則返回無則繼續查詢
    • 本地dns查詢根服務器,找到com域名解析服務器
    • 本地dns查詢com域名解析服務器,找到amazon.com域名解析服務器
    • 本地dns查詢amazon.com域名解析服務器,獲得www.amazon.com的IP地址
    • 本地dns緩存www.amazon.com的IP,並發送結果給客戶端

DNS根域名服務器

  • 根域名服務器(root name server)是互聯網域名解析系統(DNS)中最高級別的域名服務器,負責返回頂級域的權威域名服務器地址

    在根域名服務器中雖然沒有每個域名的具體信息,但儲存了負責每個域(如.com,.xyz,.cn,.ren,.top等)的解析的域名服務器

  • 本地域名解析服務器無法解析域名時,有一個遞歸訪問過程,起點是根域名解析器

  • 全球由13個root dns,中國沒有。

    由於DNS和某些協議(未分片的用戶數據報協議(UDP)數據包在IPv4內的最大有效大小為512字節)的共同限制,根域名服務器地址的數量被限制為13個。幸運的是,采用任播技術架設鏡像服務器可解決該問題,並使得實際運行的根域名服務器數量大大增加。截至2017年11月,全球共有800台根域名服務器在運行。

TLD和權威域名解析服務器

  • 頂級域名服務器(TLD, top-level domain): 負責com, org, net,edu等頂級域名和國家頂級域名,例如cn, uk, fr等
    • Network Solutions維護com頂級域名服務器
    • Educause維護edu頂級域名服務器
  • 權威(Authoritative)域名服務器:權處於DNS服務端的一套系統,該系統保存了某個響應域名的權威信息。權威DNS即通俗上“這個域名我說了算”的服務器。
    • 域名所有者(通常不是個人而是一個組織)負責維護

本地域名解析服務器

  • 不嚴格屬於層級體系
  • 每個ISP有一個本地域名服務器
    • 默認域名解析服務器
  • 當主機進行DNS查詢時,查詢被發送到本地域名服務器,由本地域名服務器先查本地緩存再遞歸查詢
    • 作為代理(proxy),將查詢轉發給(層級式)域名解析服務器系統

DNS查詢示例

  • 完整的遞歸DNS查詢流程需要DNS服務器從根域名“.”服務器、頂級域名服務器“.com”、二級域名服務器“taobao.com”一級一級遞歸查下來最終找到權威服務器取得結果,並返回給客戶,同時將取得的結果根據域名設置的TTL時間緩存在自己的系統當中,以便下次使用。
  • 迭代查詢
    • 查詢失敗,則被查詢服務器返回域名解析服務器的名字
    • “我不認識這個域名,但是你可以問這服務器”
    • 重試工作由查詢者承擔
  • 遞歸查詢
    • 將域名解析的任務交給所聯系的服務器
    • 重試工作由被查詢者承擔,形成一個查詢鏈路,每個查詢者僅發送一次信息

DNS記錄緩存和更新

  • 只要域名解析服務器獲得域名—IP映射,即緩存這一映射
    • 一段時間過后,緩存條目失效(刪除)
    • 本地域名服務器一般會緩存頂級域名服務器的映射,因此根域名服務器不經常被訪問
  • 記錄的更新/通知機制
    • RFC 2136
    • Dynamic Updates in the Domain Name System (DNS UPDATE)

思考題

我國沒有根域名服務器,是否會影響我國的網絡安全,會有什么影響。請思考並查閱資料,回答該問題。

DNS記錄和消息格式

DNS記錄

  • 資源記錄(RR, resource records)
  • RR format:(name,value,type,ttl)
  • Type
    • Type=A(主機類)
      • Name: 主機域名
      • Value: IP地址
    • Type=NS(DNS):解析服務器記錄。用來表明由哪台服務器對該域名進行解析。這里的NS記錄只對子域名生效。
      • Name: 域
      • Value: 該域權威域名解析服務器的主機域名
    • Type=CNAME(別名類):別名記錄。這種記錄允許您將多個名字映射到另外一個域名。
      • Name: 某一真實域名的別名
      • Value: 真實域名
    • Type=MX(郵件服務類)
      • Value是與name相對應的郵件服務器

DNS協議與消息

  • DNS協議:
    • 查詢(query)和回復(reply消息)
    • 消息格式相同
  • 消息頭部
    • Identification: 16位查詢編號,回復使用相同的編號
  • flags:標志位
    • • 查詢或回復
    • • 期望遞歸
    • • 遞歸可用
    • • 權威回答

如何注冊域名?

  • 例子:你剛剛創建了一個公司 “Network Utopia”
  • 在域名管理機構(如Network Solutions)注冊域名networkutopia.com
    • 向域名管理機構提供你的權威域名解析服務器的名字和IP地址
    • 域名管理機構向com頂級域名解析服務器中插入兩條記錄
  • 在權威域名解析服務器中為www.networkuptopia.com加入Type A記錄,為networkutopia.com加入Type MX記錄

TCP?UDP??

DNS同時占用UDP和TCP端口53是公認的,這種單個應用協議同時使用兩種傳輸協議的情況在TCP/IP棧也算是個另類。但很少有人知道DNS分別在什么情況下使用這兩種協議。 先簡單介紹下TCP與UDP。
TCP是一種面向連接的協議,提供可靠的數據傳輸,一般服務質量要求比較高的情況,使用這個協議。UDP---用戶數據報協議,是一種無連接的傳輸層協議,提供面向事務的簡單不可靠信息傳送服務。 TCP與UDP的區別:
UDP和TCP協議的主要區別是兩者在如何實現信息的可靠傳遞方面不同。TCP協議中包含了專門的傳遞保證機制,當數據接收方收到發送方傳來的信息時,會自動向發送方發出確認消息;發送方只有在接收到該確認消息之后才繼續傳送其它信息,否則將一直等待直到收到確認信息為止。 與TCP不同,UDP協議並不提供數據傳送的保證機制。如果在從發送方到接收方的傳遞過程中出現數據報的丟失,協議本身並不能做出任何檢測或提示。因此,通常人們把UDP協議稱為不可靠的傳輸協議。。不同於TCP,UDP並不能確保數據的發送和接收順序。事實上,UDP協議的這種亂序性基本上很少出現,通常只會在網絡非常擁擠的情況下才有可能發生。
既然UDP是一種不可靠的網絡協議,那么還有什么使用價值或必要呢?其實不然,在有些情況下UDP協議可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優勢。雖然TCP協議中植入了各種安全保障功能,但是在實際執行的過程中會占用大量的系統開銷,無疑使速度受到嚴重的影響。反觀UDP由於排除了信息可靠傳遞機制,將安全和排序等功能移交給上層應用來完成,極大降低了執行時間,使速度得到了保證。

DNS在進行區域傳輸的時候使用TCP協議,其它時候則使用UDP協議;
DNS的規范規定了2種類型的DNS服務器,一個叫主DNS服務器,一個叫輔助DNS服務器。在一個區中主DNS服務器從自己本機的數據文件中讀取該區的DNS數據信息,而輔助DNS服務器則從區的主DNS服務器中讀取該區的DNS數據信息。當一個輔助DNS服務器啟動時,它需要與主DNS服務器通信,並加載數據信息,這就叫做區傳送(zone transfer)。

為什么既使用TCP又使用UDP?
首先了解一下TCP與UDP傳送字節的長度限制:
UDP報文的最大長度為512字節,而TCP則允許報文長度超過512字節。當DNS查詢超過512字節時,協議的TC標志出現刪除標志,這時則使用TCP發送。通常傳統的UDP報文一般不會大於512字節。

區域傳送時使用TCP,主要有一下兩點考慮:
1.輔域名服務器會定時(一般時3小時)向主域名服務器進行查詢以便了解數據是否有變動。如有變動,則會執行一次區域傳送,進行數據同步。區域傳送將使用TCP而不是UDP,因為數據同步傳送的數據量比一個請求和應答的數據量要多得多,不能亂序,或者丟包或者失真。

域名解析時使用UDP協議:
客戶端向DNS服務器查詢域名,一般返回的內容都不超過512字節,用UDP傳輸即可。不用經過TCP三次握手,這樣DNS服務器負載更低,響應更快。雖然從理論上說,客戶端也可以指定向DNS服務器查詢的時候使用TCP,但事實上,很多DNS服務器進行配置的時候,僅支持UDP查詢包。

思考題

請查閱有關資料,找出那些在應用層實現的Internet核心服務,調研它們的協議、消息格式。

Markdown文本https://github.com/ArrogantL/BlogData/tree/master/計算機網絡spoc/W1
本文作者: ArrogantL (arrogant262@gmail.com)
版權聲明: 本博客所有文章除特別聲明外,均采用 CC BY-NC-SA 4.0 許可協議。轉載請注明出處!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM