[A Top-Down Approach][第二章 應用層]

時間  2019-12-06
標籤 approach 第二 應用層 简体版
原文   原文鏈接

[A Top-Down Approach][第二章 應用層]

標籤（空格分隔）： 未分類html

  • 網絡應用是計算機網絡存在的理由web

  • 首先從定義幾個關鍵的應用層概念開始
    • 應用程序所須要的網絡服務,客戶和服務器,進程和運輸層接口.
  • 而後詳細考察幾種網絡應用程序.
    • Web,電子郵件,DNS,和對等文件分發.
  • 涉及開發運行在TCP和UDP上的應用程序.
    • 學習套接字 API
    • 浮光掠影的用Python寫一些簡單的客戶-服務器應用程序.

2.1 應用層協議原理

2.1.1 網絡應用程序體系結構

  • 應用程序體系結構(application architecture): 由應用程序研發者設計,規定了如何在各類端系統上組織該應用程序.
    • 兩大主流體系:
      • 客戶-服務端體系結構(client-server architecture)
      • 對等(P2P)體系結構(P2P architecture)

客戶-服務端體系結構

  • 服務器:有一個老是打開的主機稱爲服務器,它服務於來自許多其餘稱爲客戶的主機.
    • 對於某些大型的公司,例如google,facebook,甚至要組建數據中心來處理.

  • 客戶互相之間不通訊.算法

  • 經常使用應用: 典型的有Web,Telent和電子郵件.數據庫

P2P體系結構

  • 對位於數據中心的專用服務器有最小(甚至沒有)的依賴.編程

  • 在主機對之間使用直接通訊,這些主機被稱爲對等方後端

  • 經常使用應用:
    • 文件共享:BitTorrent
    • 對等方協助下載加速器 : 迅雷
    • 因特網電話 :Skype
    • IPTV : PPStream

  • 將來P2P應用面臨三個主要問題api

    • ISP友好:大多數住宅ISP受制於"非對稱的" 帶寬應用
    • 安全性: 高度分佈和開放特性,會對安全帶來挑戰
    • 激勵: 將來P2P應用的成功也取決於說服用戶自願嚮應用提供寬帶,存儲和計算資源.

2.1.2 進程通訊

  • 進行通訊的實質是進程(process)

1. 客戶和服務進程

在給定的一對進程之間的通訊會話場景中,發起通訊(即在該會話開始時發起與其餘進程聯繫)的進程被標識爲客戶,另外一方等待鏈接的是服務器.瀏覽器

2. 進程與計算機網絡之間的接口

image_1b230040c1fnl15sg1umm1f0k13cp9.png-190.1kB

  • 套接字(socket):進程經過一個稱爲套接字的軟件接口向網絡發送電報和從網絡接收電報.
    • 套接字也稱爲應用層和運輸層的應用程序編程接口(Application Programming Interface ,API).
  • 應用程序開發者能夠控制套接字在應用層端的一切,可是對運輸層幾乎沒有控制,僅限於
    • 選擇運輸層協議
    • 設定幾個運輸層參數(如:最大緩存,最大報文段長度)
  • 在2.7節對套接字進行更爲詳細的探討.

3. 進程尋址

  • 目的主機的地址:IP地址(IP address)
    • 第四章詳細討論.
  • 目的主機中的接收進程的標識符:端口號(port number)
    • 第三章學習端口號.

2.1.3 應用程序所須要的運輸服務特性

從四個方面對運輸服務分類: 可靠數據傳輸,吞吐量,定時和安全性緩存

可靠數據運輸

  • 就是所謂的丟包安全

  • 可靠運輸傳輸(reliable data transfer):提供這種服務,確信數據能無差錯到達接收進程.
    • 電子郵件,文件傳輸,遠程主機訪問,Web文檔等應用,數據丟失將會形成嚴重後果.
    • 而有些多媒體等應用是允許丟失的應用(loss-tolerant application)

吞吐量

  • 就是所謂的下載速度

  • 帶寬敏感的應用(bandwidth-sensitive application)
    • 當前許多多媒體應用都是帶寬敏感的,儘管儘量採用自適應編碼技術.
  • 彈性應用(elastic application):根據狀況利用帶寬.
    • 電子郵件,文件傳輸和Web.

定時

  • 有的運輸層協議也能提供定時保證.

  • 就是所謂的延遲
    • 在遊戲和因特網電話中有較高的要求.

安全性

  • 運輸層協議提供一種或多種安全服務.

2.1.4 因特網提供的運輸服務

1.TCP服務

  • TCP服務模型包括面向鏈接服務和可靠數據傳輸服務.
    • 面向鏈接服務: 在應用層數據報文開始流動以前,TCP讓客戶和服務器互相交換運輸層控制信息.
      • 握手階段: 提示服務器和客戶端.
      • 創建一個全雙工的TCP 鏈接(TCP connection)
      • 拆除鏈接.
    • 可靠的數據傳送服務:通訊進程可以依靠TCP,無差錯,按適當順序交付全部發送的數據.
  • TCP協議還具備擁塞控制階段
    • 這種服務不必定能爲通訊進程帶來直接好處,給因特網帶來總體好處
    • 出現網絡擁堵時,TCP的擁塞控制機制會抑制發送進程.

  • 安全套接字層(Secure Sockets Layer,SSL:爲了提高安全性,提供了一種TCP的增強版本SSL

    • 這種強化是在應用層上的,SSL並非跟TCP/UDP並列的協議

2.UDP服務

  • UDP是一種不提供沒必要要服務的輕量級運輸協議,它僅提供最小服務.
    • 無鏈接的.
    • 不可靠數據傳送服務

    • 沒有擁塞控制

      3.運輸協議所不能提供的服務

  • 吞吐量和定時方面不能保證,幸虧帶寬再不斷地擴大,也暫時不須要關注.

image_1b23jd7ktrhh81m1ec47g218v613.png-142.8kB

2.1.5 應用層協議

  • 應用層協議(application-layer protocal): 定義了運行在不一樣端系統上的應用程序如何相互傳遞報文.

    • 交換的報文類型
      • 請求報文和響應報文
    • 各類報文類型的語法
      • 報文的各個字段和這些字段是如何描述的.
    • 字段的語義
      • 即這些字段包含的信息的含義
    • 一個進程什麼時候發送報文,對報文的響應規則

2.1.6 本書設計的應用協議

  • HTTP,FTP,STMP,DNS,P2P

2.2 Web 和 HTTP

  • 誕生於 90年代後

2.2.1 HTTP概述

  • 超文本傳輸協議(HyperText Transfer Protocal,HTTP):Web的應用層協議,Web的核心.

image_1b23ohi7v8rj1fcvh3v18pb1sai1g.png-99.8kB

  • HTTP使用TCP做爲它的支撐運輸協議.
    • HTTP客戶向服務器發起一個與服務器的TCP連接,連接創建後,經過套接字接口訪問TCP
  • HTTP是一個無狀態協議(stateless protocal)
    • HTTP不保存客戶的任何信息
    • 因此須要cookie,session
  • 對象(object): Web頁面由對象組成,一個對象是一個文件

    • 一個HTML頁面,JPEG圖形,CSS文件..........

      2.2.2 非持續鏈接和持續鏈接

  • 非持續鏈接(non-persistent connection)
    • 每一個請求/響應對通過一個單獨的TCP鏈接發送.
  • 持續鏈接(persistent connection)
    • 全部請求/響應對通過相同的TCP鏈接發送.
    • 默認狀況使用持續鏈接.

image_1b23qbeeqg20e4k1ma4i9lt7p1t.png-183.9kB

  • 往返時間(Round-Trip Time,RTT):一個短分組從客戶到服務端,再從服務端到客戶端說花的時間
    • 包括了以前討論的各類時延.
  • 創建TCP鏈接傳輸一個對象須要的時間爲 2個RTT+接受文件時間

1. 採用非持續鏈接的HTTP

  • 每一個TCP鏈接在服務器發送完一個對象後就關閉
    • 即每一個TCP鏈接只傳輸一個請求報文和一個響應報文

  • 相對於持續鏈接,每次請求對象,須要多花一個RTT的時間.

  • 優勢
    • 能夠並行
  • 缺點:
    • 每次創建TCP鏈接都要佔據客戶端和服務端的資源.
    • 須要多一個RTT的時間來握手.

2. 採用持續鏈接的HTTP

  • 若是一個鏈接通過必定時間間隔未被使用,HTTP就會關閉該鏈接.

2.2.3 HTTP 報文格式

  • HTTP報文分兩種:請求報文和響應報文.

1. HTTP請求報文

給出一個典型的HTTP請求報文

GET /somedir/page.html HTTP/1.1
Host:wwww.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
  • 請求行(request line):HTTP請求報文的第一行
    • 有3個字段,方法字段,URL字段,HTTP版本字段
      • 方法字段:GET,POST,HEAD,PUT和DELETE
        • 經常使用GET,POST
  • 首部行(header line): 其後繼的行
    • Host :指明對象在的主機
    • Connection : 指明是否持續鏈接
    • User-agent: 指明客戶瀏覽器
    • Accept-language: 指望獲得的對象版本.

image_1b23rrmf755l15rocdg18qb2j2a.png-165.5kB

  • 實體主體 : 當方法字段爲POST時使用

  • 詳細解說方法字段
    • HEAD:相似GET,但只要求返回響應報文,不須要對象
      • 用於調試跟蹤.
    • PUT: 容許用戶上傳對象到指定的Web服務器上的指定路徑.
    • DELETE:容許用戶刪除

2.HTTP響應報文

HTTP/1.1 200 OK
Connection: close
Date:Tue , 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified:09 Aug 2011 15:11:04 GMT
Content-Length: 6821
Content-Type:text/html

(data data.............)
  • 狀態行(status line): 協議版本字段,狀態碼,相應的狀態信息
  • 首部行(header line)
    • Last-Modified: 請求對象的最後修改時間
      • 對本地緩存很是重要.
    • 實體主體(entity body): 報文主要部分,即所請求的對象

image_1b23t6464jo4k73btl50714h22n.png-181.2kB

image_1b23tcikeg611fc9for1uhc1nlh34.png-74.8kB
image_1b23tcviastjbivj8l1qe7e933h.png-40.1kB

  • cookie: 容許站點對用戶進行追蹤

  • cookie技術有四個組件:
    • HTTP響應報文的一個cookie首部行
    • HTTP請求報文的一個cookie首部行
    • 用戶端系統保留一個cookie文件,由瀏覽器進行管理.
    • 位於Web站點的一個後端數據庫

  • 對用戶的隱私有侵害.

2.2.5 Web緩存

image_1b251p89p1jsc1p9t1bdt1527k2e9.png-121.2kB

  • Web 緩存器(Web cache)也叫代理服務器(proxy server),它是可以表明初始Web服務器知足HTTP請求的網絡實體.
    • Web緩存器有本身的磁盤存儲空間,並在存儲空間中保存最近請求過的對象的副本
    • 一般由ISP購買並安裝.
  • 部署Web緩存器有兩大緣由.
    • Web緩存器能夠大大減小客戶請求的響應時間
    • Web緩存器能夠大大減小一個機構的接入鏈路到因特網的通訊量
    • 緩存命中率在0.2~0.7之間

CDN

  • 內容分發網絡(Content Distribution NetWork,CND):地理上分散的緩存器,使大量流量本地化.
    • 百度CDN,阿里巴巴CDN.

CDN是構建在網絡之上的內容分發網絡，依靠部署在各地的邊緣服務器，經過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。
CDN的基本原理是普遍採用各類緩存服務器，將這些緩存服務器分佈到用戶訪問相對集中的地區或網絡中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求。

image_1b252c8k0lmvla61nvp1c701h2bm.png-92.1kB

2.2.6 條件 GET 方法

  • 條件GET(conditional GET)方法: HTTP協議有一種機制,容許緩存器證明它的對象是最新的,這種機制就是條件GET方法.
    • 條件GET 包含
      • 請求報文使用GET
      • 請求報文含一個If-Modified-Since: 首部行

  • 請求報文
    GET /fruit/kiwi.gif HTTP/1.1 Host: www.exotiquecuisine.com If-Modified-Since: wed, 7 Sep 2011 09:23:24

  • 若是證明是最新的的響應報文304
    ```
    HTTP/1.1 304 Not Modified
    Date:Sat, 15 Oct 2011 15:39:29
    Server: Apache/1.3.0 (Unix)

    (empty entity body)
    ```

2.3 文件傳輸協議: FTP

  • FTP使用並行的TCP鏈接來傳輸文件,一個是控制鏈接(control connection),一個是數據鏈接(data connection).
    • 控制連接用於在兩主機之間傳輸控制信息.
      • 如:用戶標識,口令,改變遠程目錄的命令以及存放(put)和獲取(get)文件的命令.
      • 控制連接是持續的
    • 數據鏈接用於實際發送一個文件.
      • 數據鏈接是非持續的
    • 帶外傳送(out-of-band):由於FTP有個獨立的控制連接
      • HTTP就是 帶內傳送.

image_1b254sesv144u18olfpt1ok14vu13.png-39.2kB

  • FTP服務器必須在整個會話期間保留用戶的狀態(state).
    • 大大限制了FTP同時維持的會話總數.
    • 因此也是HTTP的優點.

2.3.1 FTP 命令與回答

  • 每一個命令由4個大寫字母組成,有些還有可選參數

    USER username :傳遞用戶標識
PASS password :用於向服務器發送用戶口令
LIST: 用戶請求服務器回送當前遠程目錄中的全部文件列表.該文件列表是經一個數據傳送
RETR filename: get 文件
STOR filename: put 文件

  • 回答老是3位數字,後面跟一個可選信息

    331 Username OK,Password required 
125 Data connection already open;transfer starting
425 Can't open data connection
452 Error writing file

  • 詳細學習請閱讀RFC 959

2.4 因特網的電子郵件

image_1b25g0os4p0e1ughuq1hp8198o9.png-231.6kB

  • 用戶代理(user agent)
    • 用戶代理容許用戶閱讀,回覆,轉發,保存和攢寫報文.
    • 微軟的Outlook,Apple Mail,QQ mail
  • 郵件服務器(mail server)
    • 外出報文隊列: 等待發送.
    • 報文隊列: 沒法發送出去的在這裏每30分鐘發一次.
    • 郵箱(mailbox): 管理和維護髮送給郵箱主人的報文.
  • 簡單郵件傳輸協議(Simple Mail Transfer Protocol,SMTP)
    • SMTP 是因特網電子郵件中主要的應用層協議.
    • 使用TCP協議.
    • 也分爲SMTP客戶端和SMTP服務端.

2.4.1 SMTP

  • 報文的體部分只能使用 7 比特ASCII
    • 即多媒體的2進制文件編碼爲ASCII再傳遞,以後再解碼.
    • HTTP並不須要
  • SMTP通常不使用中間郵件服務器發送郵件,即便這兩個郵件服務器位於地球的兩端也是這樣.

image_1b25hqv1c1d556vtpj81fmgfvqm.png-84.3kB

  • 報文以CRLF.CRLF結束
    • CR:回車
    • LF:換行
  • 是可持續的鏈接,發送完一個報文,能夠繼續發送第二個.
    • 以 QUIT做爲斷開鏈接的命令.

2.4.2 與 HTTP 對比

關於推拉

  • SMTP是一種推格式,因此在取報文時,不用SMTP協議.
  • HTTP 主要是拉格式

對於報文的格式

  • SMTP 強制要求7比特ASCII碼
  • HTTP 不要求

既包含文本又包含圖片的文檔

  • HTTP : 一個對象一個響應報文.
  • SMTP : 所有賽一塊兒.

2.4.3 郵件報文格式 和 MIME

  • 郵件報文格式區別於SMTP協議格式,注意注意
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life

This is main text.
  • 首部行:
    • 必須包含 From,To 首部行
    • 可能包含Subject等首部行.

  • 報文體: 用一個空行相隔

  • RFC 5322定義.

2.4.4 郵件訪問協議

郵件訪問協議誕生的緣由

  • 用戶代理不能使用SMTP 取回報文.
    • 由於SMTP只能進行拉操做.
  • 因此產生了一些流行的郵件訪問協議
    • 第三版的郵局協議(Post Office Protocol--Version 3,POP3)
    • 因特網郵件訪問協議(Internet Mail Access Protocol,IMAP)
    • HTTP

image_1b25jfr73vdq2e16c5lukkb13.png-137.3kB

1.POP3

  • POP3是一個極爲簡單的郵件訪問協議.
    • 由於協議很是簡單,因此功能也有限
  • 當用戶代理打開了一個到郵件服務器端口 110的TCP鏈接後,開始工做.
    • 特許(authorization)階段:用戶代理(以明文形式)發送用戶名和口令鑑別用戶
      • user <user name>
      • pass <password>
    • 事務處理階段:
      • 用戶代理取回報文
        • list: 展開列表
        • retr <mailname>: 打開指定郵件
      • 對報文作刪除標記.
        • dele <mailname>:
      • 取消報文刪除標記.
      • 獲取郵件的統計信息.
      • quit:進入更新階段
    • 更新階段:郵件服務器刪除那些被標記爲刪除的報文.

  • 服務器的回答只有兩種: +OK,-ERR

  • POP3 沒有給用戶提供任何建立遠程文件夾並未報文指派文件夾的方法.

    2.IMAP

如上所說,POP3 沒有給用戶提供任何建立遠程文件夾並未報文指派文件夾的方法.因此IMAP應運而生.

  • IMAP也是一個郵件訪問協議,比POP3更加複雜和功能齊全.
    • 第一個是文件夾功能.
    • 第二個是容許用戶取出報文組件的功能.
      • 有時可能只想取出一個報文頭.

3. 基於Web的電子郵件

  • 用戶代理就是普通的瀏覽器.
  • 接收的時候使用的是HTTP而不是其他POP3,IMAP.
  • 發送的時候也是HTTP,而不是SMTP.
  • 服務器傳送的時候依舊是SMTP

2.5 DNS: 因特網的目錄服務

2.5.1 DNS提供的服務

  • 域名系統(Domain Name System): 主機名到IP地址轉換的目錄服務.
    • 一個由分層的DNS服務器實現的分佈式數據庫.
    • 一個使得主機可以查詢分佈式數據庫的應用層協議.
  • DNS使用的運輸層協議是UDP,使用 53 號端口

其他服務

  • 主機別名(host aliasing)
  • 郵件服務器別名(mail server aliasing)
  • 負載分配(load distribution)
    • 應用情形: 一個域名分配了多個IP,循環的使同一個域名下每一個主機負載均衡.

2.5.2 DNS 工做機概述

DNS 工做過程

  • 不少基於UNIX的系統可使用gethostbyname()這樣的API調用DNS.
  • 主機上的DNS向網絡發送一個DNS查詢報文.
    • 全部DNS報文接受和發送都是經過UDP經端口53發送.
  • 用戶收到DNS回答報文,包含了所須要的IP.

DNS 實現- 分佈式數據庫

  • DNS是因特網上實現分佈式數據庫的精彩典範

    image_1b25q52c8me1t2f1b531o081qar1g.png-146.3kB

1.分佈式層次數據庫

假定一個客戶須要知道www.amazon.com的IP地址

  • 首先與根服務器聯繫,返回頂級域名com的TLD服務器的IP地址.
  • 而後與TLD服務器之一練習,將返回amazon.com的權威服務器地址.
  • 最後,與權威服務器地址聯繫,返回www.amazon.con 的IP地址.
  • 根 DNS 服務器: 在因特網上當前有且只能有13個根DNS服務器 (標號爲A-M)
    • 要讓全部的根服務器數據能包含在一個512字節的UDP包中
      • 根服務器只能限制在13個
      • 並且每一個服務器要使用字母表中的單個字母命名
  • 頂級域服務器(TLD): 這些服務器負責頂級域名如com,org,net,edu和gov,以及全部國家的頂級域名如uk,fr,ca和jp.
  • 權威 DNS 服務器:
    • 一個組織機構本身搭建的權威DNS服務器
    • 租借服務提供商的一個權威DNS服務器
  • 本地DNS服務器: 不屬於DNS的層次結構.
    • 起着代理的做用.

image_1b2a4q4ss1jv17ktndc1efp6639.png-89.6kB

  • 遞歸查詢: 請求主機到本地DNS服務器是遞歸查詢
  • 迭代查詢: 本地DNS服務器與其他服務器的回話是迭代查詢

2.DNS緩存

  • 通常保存兩天.

2.5.3 DNS記錄和報文

  • 資源記錄(Resource Record,RR):RR提供了主機名到IP地址的映射.
    • 四元組:(Name,Value,Type,TTL)
      • TTL: 資源記錄應當在緩存中刪除的時間.
      • NAME和VALUE的值取決於Type
    • Type
      • Type = A
        • Name是主機名
        • Value是對應的IP地址.
        • 好比:(relay1.bar.foo.com,145.37.93.126,A)
      • Type = NS
        • 則 Name是個域 如:(foo.com)
        • Value是得到該域中主機IP地址的權威DNS服務器主機名.
        • 好比:(foo.com,dns.foo.com,NS)
      • Type = CNAME
        • Value是別名爲Name的規範主機名.
        • 好比:(foo.com,relay1.bar.foo.com,CNAME)
      • Type = MX
        • Value是別名爲Name的郵件服務器的規範主機名.
        • 好比:(foo.com,mail.bar.foo.com,MX)
  • DNS回答報文: 通常包含了一條或多條資源記錄.

1.DNS報文

  • 查詢和回答報文都是下面的格式

image_1b2a6367s1j18cmb13b4rav7tom.png-120.6kB

  • 首部區域:前12個字節,各有2字節
    • 標識符: 用於標識該查詢
      • 這個標識符會被複制到對查詢的回答報文.
      • 用於匹配發送的請求和接受到的回答.
    • 標誌 : 有若干標誌位.
      • image_1b2a707rc14r2nui1g67182b1ndg13.png-4.4kB
        • QR:1 比特 的 查詢/回答 指出是查詢報文(0)仍是回答報文(1).
    • 還有首部後的四類數據區域的數量.
  • 問題區域: 包含正在查詢的信息
    • 名字字段
    • 類型字段
  • 回答區域: 包含了最初請求的名字的資源記錄
    • 能夠包含多條RR,因此一個主機名能夠對應多個IP.
  • 權威區域: 包含了其餘權威服務器的記錄.
  • 附加區域: 包含了其餘有幫助的記錄.
    • 對於MX請求,回答區域是一個類型MX的RR,附加區域是個A的RR

總結

  • 可使用nslookup直接向某些DNS服務器發送一個DNS查詢報文.

在DNS數據庫插入記錄

有如下記錄須要插入

  • 你的DNS服務器的名字和IP地址

    (network.com,dns.network.com,NS)
(dns,network.com,212,212,212,1,A)

  • 你的WEB服務器的IP地址

    (www.network.com,212,212,71.4,A)

  • 用於郵件的MX類型.

2.6 P2P應用

討論兩種P2P應用

  • 文件分發: BitTorrent 協議
  • 分佈式散列表 : 大型對等數據庫.

2.6.1 P2P 文件分發

1.P2P 體系結構的擴展性

  • C-S模式下載一個文件所須要的時間

    image_1b2as4a5gfc51ugvilcolo1jsq9.png-10kB
    • N: 下載人數
    • F: 文件大小
    • Us: 服務器上傳速度
    • dmin: 最小下載速度

  • P2P模式下下載一個文件所須要的時間

    image_1b2as7r0alngg2783d1jk590hm.png-19.3kB

image_1b2as90rhivp1vqm15i8129f1tc913.png-151.9kB

2. BitTorrent

  • BitTorrent: 用於文件分發的流行 P2P 協議.

  • 洪流(torrent):參與一個特定文件分發的全部對等方的集合被稱爲一個洪流

  • 文件塊(chunk): 一個洪流中的對等方彼此下載等長度的文件塊(chunk)
    • 典型的塊長度爲256KB
  • 實際運行大概:
    • 一個對等方加入洪流,不斷地下載塊,也爲其餘對等方上載了不少塊.
    • 能夠在任什麼時候候離開洪流,也能下載完後繼續(大公無私)的上傳.





咱們更爲仔細的觀察BitTorrent運行的過程

  • 追蹤器(tracker): 每一個洪流具備一個的基礎設施結點,跟蹤洪流對等方.
    • 當一個對等方加入洪流時,它向追蹤器註冊本身
    • 並週期性通知洪流本身還在洪流中.


一步一步詳細介紹

image_1b2atb86r130obbl1b6gt2e1grs1g.png-182.4kB

  • Alice加入洪流,追蹤器隨機選擇一個對等方子集的IP發給Alice.

  • Alice 試圖與列表全部對等方建立並行的TCP鏈接.
    • 領近對等方: 成功創建鏈接的對等方(此圖只有三個)
    • 鄰近對等方隨時間而變化.
  • Alice 週期性的詢問每一個鄰近對等方他們具備的塊列表.
  • Alice 對他尚未的塊發出請求(TCP鏈接).
  • 所以在任什麼時候刻,Alice擁有塊,並知道鄰居有哪些塊,有兩個任務要作.
    • 請求哪些塊?
      • 稀缺優先技術: 針對鄰居最稀缺的塊進行請求.
    • 給哪些鄰居發送塊?
      • 對換算法:
        • 基本想法: 根據當前可以以最高速率向她提供數據的鄰居提供最高優先權.
        • 疏通:根據下載速度肯定k個鄰居,還有一個待試探稱爲疏通.
          • 每 10s 會從新計算下載速度.
          • 每 30s 會隨機給鄰居B發送塊,使得本身可能成爲B的疏通.
        • 阻塞:其他除疏通外的對等方.

  • 還有片,流水線,隨機優先選擇,殘局模型,反怠慢等有趣的機制.

  • 這樣一報還一報的機制提升用戶的積極性..

2.6.2 分佈式散列表

  • 分佈式散列表(Distributed Hash Table,DHT)
    • 每一個對等方擁有整體的一個小子集.
    • 容許任何對等方用一個特別的key來查詢該分佈式數據庫.
    • 分佈式數據庫定位擁有該key-value的對等方,向查詢返回key-value.
    • 任何對等方也能插入key-value.
  • 散列的由來
    • 每一個對等方式取 [0,2^n-1]散列表上的id.
    • 最近原則: 對每一個key哈希一下獲得一個id,並 mod 2^n,存入跟這個id最接近的散列表中.
    • 而後利用二分查找的思想.

環形DHT

image_1b2b1qoecvia1ktqfoo1pkf10pr1t.png-28.5kB

  • 其實就是一種二分查找的思想而已.
  • 每一個節點擁有Logn個捷徑.

對等方干擾

  • 即插入,刪除一個對等方所作的操做.
  • 之後須要的話,再仔細讀相關論文.

2.7 TCP套接字編程

經過一個簡單的UDP程序和一個簡單的TCP程序來介紹 UDP和TCP套接字編程.

  • 咱們用Python呈現這些程序.

2.7.1 UDP套接字編程.

image_1b2kpobap30jr3umv31seg9olc.png-216.3kB

  • UDPClient

    from socket import *
serverName = 'localhost'
serverPort = 12000
clientSocket = socket(AF_INET,SOCK_DGRAM)
message = bytes(input('Input lowercase sentence:'),encoding="UTF-8")
clientSocket.sendto(message,(serverName,serverPort))
modifiedMessage,serverAddress = clientSocket.recvfrom(2048)
modifiedMessage = modifiedMessage.decode()
print(serverAddress)
print (modifiedMessage)
clientSocket.close();
    • socket.AF_INET:指示了底層網絡使用 IPv4
    • socket.DGRAM : 意味着是一個UDP套接字
    • recvfrom : 表明緩存長度

  • UDPServer

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_DGRAM)
serverSocket.bind(('',serverPort))
print("The server si ready to receive")
while True:
    message,clientAddress = serverSocket.recvfrom(2048)
    modifiedMessage = message.upper()
    serverSocket.sendto(modifiedMessage,clientAddress)

2.7.2 TCP套接字編程

  • 歡迎套接字
  • 鏈接套接字

image_1b2ku4s9s14la1tqv1cspheb1togp.png-124.9kB

image_1b2ku5qd5af39aepo934f16ua16.png-180.5kB

  • TCPClient.py

    from socket import *
serverName = 'localhost'
serverPort = 12000
clientSocket  = socket(AF_INET,SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = bytes(input('Input lowercase sentence'),encoding='UTF-8')
clientSocket.sendto(sentence)
modifiedSentence = clientSocket.recv(2048)
modifiedSentence.decode()
print('From Server:'+modifiedSentence)
clientSocket.close();

  • TCPServer

    from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind(('',serverPort))
serverSocket.listen(1)
print('The server is ready to receive')
while 1:
connectionSocket,addr = serverSocket.accept()
sentence = connectionSocket.recv(1024)
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence)
connectionSocket.close()
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程