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

目錄

• 哈工大計算機網絡Week1-網絡應用
• 2.1網絡應用的體系結構
  • 特色
  • 應採起什麼結構
    • C/S結構 客戶機/服務器
    • P2P
    • CS vs P2P
    • 混合結構
  • 思考題目
• 2.2網絡應用的基本原理
• 網絡應用進程通訊
  • 進程間通訊
  • 套接字: Socket
  • 尋址
  • 應用層協議
    • 應用層協議的內容
• 網絡應用的需求與傳輸層服務
  • 網絡應用對傳輸服務的需求
  • Internet提供的傳輸服務
  • 課後練習
• 2.3Web應用
• web應用概述
  • Web與HTTP
  • HTTP協議概述
• HTTP鏈接
  • HTTP鏈接的兩種類型
    • 非持久性鏈接
    • 持久性HTTP
• HTTP消息格式
  • HTTP請求消息
    • 上傳附加輸入信息的方法
    • 方法的類型
  • HTTP響應消息
    • HTTP響應狀態代碼
• Cookie技術
  • 爲何須要Cookie？
  • Cookie技術
  • Cookie的原理
  • Cookie的做用
  • 思考題
• Web緩存/代理服務器技術
  • 功能
  • 爲何要發明這種技術？
  • Web緩存/代理服務器
  • Web緩存示例
  • 條件性GET方法
  • 課後做業
• 2.4Email應用
• Email應用
  • Email應用的構成
  • SMTP協議: RFC 2821
    • 與HTTP對比
  • 動手嘗試SMTP交互
  • 思考題
• Email消息格式與POP3協議
  • Email消息格式
  • Email消息格式：多媒體擴展
  • 郵件訪問協議（不一樣與STMP協議）
  • POP3協議
  • IMAP協議
  • Email流程示例
  • 課後練習
• 2.5DNS服務
• DNS概述
  • DNS：Domain Name System
  • 分佈式層次式數據庫
  • DNS根域名服務器
  • TLD和權威域名解析服務器
  • 本地域名解析服務器
  • DNS查詢示例
  • DNS記錄緩存和更新
  • 思考題
• DNS記錄和消息格式
  • DNS記錄
  • DNS協議與消息
  • 如何註冊域名？
  • TCP？UDP？？
  • 思考題

哈工大計算機網絡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)
  • URL(Uniform Resoure Locator)：統一資源定位器 RFC1738
    • 格式： Scheme://host:port/path
    • 例如：http://www.hit.edu.cn/header/article.txt

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協議的支持狀況。

一、IMAP提供Webmail 與電子郵件客戶端之間的雙向通訊，客戶端收取的郵件仍然保留在服務器上，同時在客戶端上的操做都會反饋到服務器上（如：刪除郵件，標記已讀等，服務器上的郵件也會作相應的動做。因此不管從瀏覽器登陸郵箱或者客戶端軟件登陸郵箱，看到的郵件以及狀態都是一致的。）。而POP3在客戶端的操做不會反饋到服務器上。

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

三、IMAP提供的摘要瀏覽功能可讓你在閱讀完全部的郵件到達時間、主題、發件人、大小等信息後才做出是否下載的決定。

四、POP3須要下載未閱讀的郵件，IMAP能夠不用把全部的郵件所有下載，而是經過客戶端直接對服務器上的郵件進行操做。全部經過IMAP傳輸的數據都會被加密，從而保證通訊的安全性。

五、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/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9Cspoc/W1
本文做者： ArrogantL (arrogant262@gmail.com) ： 本博客全部文章除特別聲明外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明出處！