什么是 P2P FTP Email

Evrytos
70 阅读6分钟

FTP应用

  • 向远程主机上传输文件或者从远程主机接受文件

  • 客户/服务器模式

    • 客户：发起传输的一方
    • 服务器：远程主机

  • ftp：RFC959

  • ftp服务器：端口号为21

控制连接和数据连接分离

  • FTP客户端与FTP服务器通过21联系，使用TCP为传输协议
  • 客户端通过控制连接获得身份确认
  • 客户端通过控制连接发送命令浏览远程目录
  • 手打哦一个文件传输指令是，服务器打开一个到客户端你的数据连接
  • 一个文件传输完后关闭

FTP服务器维护用户的状态信息：路径，用户账户与控制连接对应

数据连接是服务器主动建立的

Email应用

组成部分

  • 用户代理
  • 邮件服务器
  • 简单邮件传输协议SMTP

用户代理

  • outlook Gmail 等邮箱软件就是邮箱代理

HTTP的用户代理就是浏览器

邮件服务器

  • 输出报文队列保持发送邮件

  • 邮件服务器之间的SMTP协议

    • 客户：发送方的邮件代理
    • 服务器：接受端邮件服务器

image.png

规定所有报文的请求和响应都是7位的ASCll码

  • POP: 邮局访问协议（Post Office Protocol)

    • 用户身份确认并下载

  • IMAP：Internel 邮件访问协议（Internet Mail Access Protocol)

    • 在服务器上处理存储的报文

  • HTTP: Hotmail ,Yahoo! Mail 等

比较

SMTP

  • 持久连接
  • 要求报文为7位的ASCII码
  • SMTP服务器决定CRLF，CRLF决定报文的尾部
  • 多个对象包含在一个报文中

HTTP

  • HTTP：拉取(pull)，SMTP：推(push)
  • 二者都是ASCII码
  • 每个对象封装在各自的响应报文中

POP3 （在会话中无状态）

  • 用户确认阶段

    • 客户端命令

      • user:申明用户名
      • pass：口令

    • 服务器响应

      • +OK
      • -ERR

  • 事物处理阶段

    • 客户端：
    • list 报文号列表
    • retr 根据报文号检索报文
    • dele：删除
    • quit

IMAP

  • 服务器将每个报文与一个文件夹联系起来

  • 允许用户用目录组织报文

  • 允许用户读取报文组件

  • IMAP在会话过程中保留用户状态

    • 包括：用户名，报文ID与目录之间的映射

拓展报文格式： MIME(multimedia mail extension)

  • 在报文首部用额外的行声明MIME内容类型

    • Content-Transfer-Encoding:base64
    • Content-Type: image/jpeg

  • base64 : 将不在ASCII码范围之内的字节转化为在ASCII码范围内的，更长一点的字符

纯P2P架构

  • 没有（极少）一直运行的服务器
  • 端系统之间可以互相通信
  • 利用peer的服务能力
  • Peer节点间歇上网，每次IP都可能有变化

文件分发 | 流媒体 | VoIP

对比文件分发时间

  • CS

  • 服务区传输：都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝

    • 发送一个copy：F ux (ux是服务器上载速率）
    • 发送N个copy：NF ux

  • 客户端：每个客户端必须下载一个文件拷贝

    • dmin客户端的最小下载速率
    • 下载带宽最小的客户端下载的时间：F/dmin

  • C-S方法将一个大小为F的文件发送给N个客户端的时间：T >= max{F/dmin,NF/ux}max\{F/dmin,NF/ux\}

  • P2P

  • 服务器传输：最少上传一份拷贝

    • F/ux

  • 客户端

    • 每个客户端必须下载一个拷贝

      • F/dmin

    • 所有客户端总体下载量NF

      • 最大的上载带宽ux + sum(ui)(i = 1 ....)
      • 除了服务器有上载，其他所有的peer都可以上载

  • P2P方法发送一个F大小的文件给N个客户端的耗时

    • D >= max{F/us,F/dmin,NF/(us+segama ui)}max\{F/us,F/dmin,NF/(us + segama\ ui)\}

image.png

P2P架构分类

  • 非结构化P2P：

    • 集中化目录
    • 完全分布式
    • 混合式

  • DHT 结构化P2P

集中式目录

最初的Napster设计

  • 对等方连接时告知中心服务器

    • IP
    • 内容

  • 查询时，中心服务器向查询者返回有目标的服务器

image.png

存在的问题：1:单点故障；2：性能瓶颈；3：侵犯版权

文件的传输是分散的，但是定位内容是高度集中的

全分布式

Gnutella

  • 没有中心服务器

  • 开放文件共享协议

  • 覆盖网络：图

    • X和Y之间存在TCP连接，则二者二者之间存在一条边
    • 所有活动的对等方和边就是覆盖网络
    • 边不是物理网络
    • 给定一个对等方，通常所连接的节点少于10

image.png

  • 泛洪：

    • 向所有的邻居发送请求，邻居再向其邻居发送请求ping，每个收到请求的peer都要返回报文给发出者pong

  • 限制泛洪

    • 使用ttl，标记请求失效跳数
    • 维护一个变量，记录是否已经被泛洪过，防止无限泛洪

  • peer加入

    • 对等方X加入后先发现覆盖网络中的其他对等方
    • 维护一张对等方列表
    • 联系列表中的节点，尝试建立TCP连接
    • X发送ping，接受pong，Y转发ping
    • X收到pong并建立其他TCP连接

  • peer离开

    • 通知建立连接的节点

混合式

KaZaA

  • 每个对等方要不是一个组长，要不隶属于一个组长
  • 组内使用集中式目录
  • 组间使用分布式管理
  • 组长追踪所有孩子的内容
  • 组长与组长之间联系

image.png

查询

  • 每个文件有一个散列标识码和一个描述符

  • 客户端向组长发送关键字查询

  • 组长匹配

    • 元数据，散列标识码，IP地址

  • 若组内没有，组长转发查询，其他组长也匹配

  • 客户端选择要下载的文件

BitTorrent

采用混合式p2p架构的文件分发系统

分发

  • 文件被分为一个个 256kb的块

    • 网络中的peers互相接受和发送文件快，互相服务

bitMap ：每个peer维护了一个包含所有的peer所包含的块的信息的bitMap

  • tracker：跟踪torrent中的参与节点
  • Torrent（洪流）：节点之间的组，之间交换文件块
请求块
  • 在任何给定时间，不同的peer节点拥有一个文件块子集
  • 周期性的，Alice节点向邻居询问他们拥有哪些块的信息
  • Alice向peer节点请求他希望的块，稀缺的块

请求稀缺的块可以防止稀缺块服务器退出后导致文件出问题

发送块

一报换一报 tit - for - tat

  • Alice选择4个peer发送块，这些块是向Alice自己提供最大带宽服务的块

    • 其他peer被阻塞
    • 每10s重新评估（一个周期）

  • 第3个周期（30s），随机选一个其他的peer发送块

    • 优化疏通
    • 新选择的节点如果带宽好也可加入top
peer加入洪流（torrent）

  • 一开始没有块，通过其他节点积累

    • 向跟踪服务器注册，获得peer节点列表，和部分peer节点构成邻居关系

  • peer下载时，peer可以同时向其他节点提供上载服务

  • peer可能会交换用于交换块的peer节点

  • 扰动churn：peer节点的 上线或者下线

一旦一个peer拥有整个文件，它可以（自私的）离开，或者（利他的）保留再torrent中

avatar
文章
阅读
粉丝