西宁做网站是什么,软件定制网站建设,如何对网站进行维护,郑州网站建站模板文章目录 前言一 、电子邮件#xff08;Email#xff09;1.邮件服务器2.SMTP[RFC 2821]3.邮件报文格式4.邮件访问协议 二、DNS#xff08;域名系统#xff09;1.DNS的历史2.DNS总体思路和目标#xff08;1#xff09;问题1#xff1a;DNS名字空间#xff08;2#xff… 文章目录 前言一 、电子邮件Email1.邮件服务器2.SMTP[RFC 2821]3.邮件报文格式4.邮件访问协议 二、DNS域名系统1.DNS的历史2.DNS总体思路和目标1问题1DNS名字空间2问题2解析问题-名字服务器3问题3:维护问题-新增一个域 三、P2P应用1. 纯P2P架构2.文件分发P2P文件共享非结构化P2P结构化DHT 三、CDNContent Distribution Network1.多媒体视频2.多媒体流化服务3.CDN内容分发网络 总结 前言
SMTP、DNS、P2P应用、CDN视频流化服务。 一 、电子邮件Email 3个主要组成部分: 用户代理邮件服务器简单邮件传输协议:SMTP 用户代理 又名“邮件阅读器”撰写、编辑和阅读邮件如Outlook、Foxmail输出和输入邮件保存在服务器上 1.邮件服务器
邮件服务器 邮箱中管理和维护发送给用户的邮件输出报文队列保持待发送邮件报文邮件服务器之间的SMTP协议:发送email报文 客户:发送方邮件服务器服务器:接收端邮件服务器
2.SMTP[RFC 2821]
使用TCP在客户端和服务器之间传送报文端口号为25直接传输:从发送方服务器到接收方服务器传输的3个阶段 握手传输报文关闭 命令/响应交互 命令:ASCII文本响应:状态码和状态信息 报文必须为7位ASCII码
例子
简单SMTP交互
总结
SMTP使用持久连接SMTP要求报文首部和主体为7位ASCII编码SMTP服务器使用CRLF.CRLF决定报文的尾部
HTTP比较:
HTTP:拉(pull)SMTP:推( push)二者都是ASCII形式的命令/响应交互、状态码HTTP:每个对象封装在各自的响应报文中SMTP:多个对象包含在一个报文中
3.邮件报文格式
SMTP:交换email报文的协议 RFC 822:文本报文的标准:首部行:如, To:From:Subject:与SMTP命令不同! 主体 报文只能是ASCII码字符
报文格式多媒体扩展
MIME:多媒体邮件扩展(multimedia mail extension) ,RFC 2045,2056在报文首部用额外的行申明MIME内容类型它扩展了电子邮件标准使其能够支持非ASCII字符文本、非文本格式附件二进位制、声音、图片等等。 4.邮件访问协议 SMTP:传送到接收方的邮件服务器邮件访问协议:从服务器访问邮件 POP:邮局访问协议Post Office Protocol)[RFC 1939] 用户身份确认(代理–服务器)并下载 IMAP: Internet邮件访问协议Internet Mail Access Protocol[RFC 1730] 更多特性(更复杂)在服务器上处理存储的报文 HTTP: Hotmail , yahoo! Mail等 方便
POP3协议
用户确认阶段客户端命令: user:申明用户名pass:口令 服务器响应 OK-ERR 事物处理阶段,客户端: list:报文号列表retr:根据报文号检索报文dele:删除quit “下载并删除”模式 如果改变客户机Bob不能阅读邮件 “下载并保留”:不同客户机上为报文的拷贝POP3在会话中是无状态的
IMAP
IMAP服务器将每个报文与一个文件夹联系起来允许用户用目录来组织报文允许用户读取报文组件IMAP在会话过程中保留用户状态: 目录名、报文ID与目录名之间映射 Bob用户不能使用SMTP得到报文因为取报文是一个拉操作而SMTP是一个推协议。Bob从邮件服务器取回邮件有两种常用方式一种是使用基于web的电子邮件或智能手机上的客户端则用户代理将使用HTTP接口和SMTP接口与Alice的邮件服务器通信另一种讲就是使用IMAP协议这通常用于微软的outLook等。HTTP和IMAP都支持BOb管理自己邮件服务器中的文件夹包括将邮件移动到他创建的文件夹中删除邮件标记为重要邮件。 二、DNS域名系统 DNS的必要性 IP地址标识主机、路由器但IP地址不好记忆不便人类使用(没有意义)人类一般倾向于使用一些有意义的字符串来标识Internet上的设备例如: qzhengustc.edu.cn所在的邮件服务器、www.ustc.edu.cn所在的web服务器存在着“字符串”一IP地址的转换的必要性人类用户提供要访问机器的“字符串”名称由DNS负责转换成为二进制的网络地址 DNS系统需要解决的问题 问题1:如何命名设备 用有意义的字符串:好记便于人类用使用解决一个平面命名的重名问题:层次化命名 问题2:如何完成名字到IP地址的转换 分布式的数据库维护和响应名字查询 问题3:如何维护:增加或者删除一个域需要在域名系统中做哪些工作 1.DNS的历史
ARPANET的名字解析解决方案 主机名:没有层次的一个字符串一个平面存在着一个(集中)维护站:维护着一张主机名-IP地址的映射文件: Hosts.txt每台主机定时从维护站取文件 ARPANET解决方案的问题 网络中主机数量很大时 没有层次的主机名称很难分配文件的管理、发布、查找都很麻烦
2.DNS总体思路和目标
DNS的主要思路 分层的、基于域的命名机制若干分布式的数据库完成名字到IP地址的转换运行在UDP之上端口号为53的应用服务核心的Internet功能但以应用层协议实现 在网络边缘处理复杂性 DNS主要目的: 实现主机名-IP地址的转换(name/IP translate)其它目的 主机别名到规范名字的转换: Host aliasing邮件服务器别名到邮件服务器的正规名字的转换:Mail serveraliasing负载均衡: Load Distribution 负载均衡load distributionDNS也用于在冗余的服务器如冗余的Web服务器等之间进行负载分配。繁忙的站点如cnn. com被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上每个都有着不同的P地址。由于这些冗余的Web服务器一个P地址集合因此与同一个规范主机名相联系。DNS数据库中存储着这些IP地址集合。当客户对映射到某地址集合的名字发出一个 DNS请求时该服务器用IP地址的整个集合进行响应但在每个回答中循环这些地址次序。因为客户通常总是向IP地址排在最前面的服务器发送HTTP请求报文所以DNS就在所有这些冗余的Web服务器之间循环分配了负载。DNS的循环同样可以用于邮件服务器因此多个邮件服务器可以具有相同的别名。一些内容分发公 1问题1DNS名字空间
DNS域名结构 一个层面命名设备会有很多重名NDS采用层次树状结构的命名方法Internet根被划为几百个顶级域(top lever domains) 通用的(generic) .com; .edu ; .gov ; .int ; .mil ; .net ;.org.firm ; .hsop : .web ; .arts ;.rec ;国家的(countries) .cn ; .us ;.nl ; .jp 每个(子)域下面可划分为若干子域(subdomains)树叶是主机 域名(Domain Name) 从本域往上直到树根中间使用“.”间隔不同的级别例如: ustc.edu.cn auto.ustc.edu.cn www.auto.ustc.edu.cn域的域名:可以用于表示一个域主机的域名:一个域上的一个主机 域名的管理 一个域管理其下的子域 .jp被划分为ac.jp co.jp .cn被划分为edu.cn com.cn创建一个新的域必须征得它所属域的同意 域与物理网络无关 域遵从组织界限而不是物理网络 一个域的主机可以不在一个网络一个网络的主机不一定在一个域 域的划分是逻辑的而不是物理的
2问题2解析问题-名字服务器
单一名字服务器的问题一个DNS服务器存在的问题 可靠性问题:单点故障如果该DNS服务器崩溃整个因特网随之瘫痪扩展性问题:通信容量单个服务器不得不处理所有的DNS查询用于为上亿台主机产生的所有HTTP请求报文和电子用邮件报文服务维护问题:远距离的集中式数据库单个 DNS服务器将不得不为所有的因特网主机保留记录。这不仅将使这个中央数据库非常庞大而且它还不得不为解决每个新添加的主机而频繁更新。 区域(zone) 区域的划分有区域管理者自己决定将DNS名字空间划分为互不相交的区域每个区域都是树的一部分名字服务器: 每个区域都有一个名字服务器:维护着它所管辖区域的权威信息(authoritative record)名字服务器允许被放置在区域之外以保障可靠性 TLD服务器
顶级域(TLD)服务器:负责顶级域名如com, org, net,edu和gov和所有国家级的顶级域名如cn, uk,fr , ca,jp Network solutions公司维护com TLD服务器Educause公司维护edu TLD服务器
区域名字服务器维护
资源记录(resource records) 作用维护域名-IP地址(其它)的映射关系位置Name Server的分布式数据库中 资源记录RR是一个包含了四个字段的4元组:(NameValueTypeTTL) Domain_name:域名TTL: time to live ,是该记录的生存时间它决定了资源记录应当从缓存中删除的时间。Class类别对于Internet值为INValue值可以是数字ip地址域名或ASCII串Type类别资源记录的类型见下面
DNS记录
DNS大致工作过程
应用调用解析器(resolver)解析器作为客户向Name Server发出查询报文(封装在UDP段中)Name Server返回响应报文(name/ip) 本地名字服务器
并不严格属于层次结构每个ISP居民区的ISP、公司、大学都有一个本地DNS服务器 也称为“默认名字服务器” 当一个主机发起一个DNS查询时查询被送到其本地DNS服务器 起着代理的作用将查询转发到层次结构中
名字服务器
名字解析过程 目标名字在Local Name Server中 情况1:查询的名字在该区域内部情况2:缓存(cashing) 当与本地名字服务器不能解析名字时联系根名字服务器顺着根-TLD一直找到权威名字服务器 查找权威名字服务器有两种查询方式 递归查询
顺着根服务器到子服务器找递归查询:名字解析负担都放在当前联络的名字服务器上问题:根服务器的负担太重解决:迭代查询(iteratedqueries) 迭代查询
主机cis.poly.edu想知道主机 gaia.cs.umass.edu的IP地址根及各级域名服务器返回的不是查询结果而是根的下一层名字服务器的地址然后本地服务器去这个名字服务器找这个个名字服务器不知道也返回一个线索它的下一层名字服务器的地址然后本地服务请器再去告知的服务器…直到找到权威服务器最后由权威名字服务器给出解析结果当前联络的服务器给出可以联系的服务器的名字“我不知道这个名字但可以向这个服务器请求”找到后还会缓存地址方便一定失效时期内再次访问 DNS协议、报文
提高性能缓存
一旦名字服务器学到了一个映射就将该映射缓存起来根服务器通常都在本地服务器中缓存着 使得根服务器不用经常被访问 目的:提高效率可能存在的问题:如果情况变化缓存结果和权威资源记录不一致解决方案:TTL默认2天
3问题3:维护问题-新增一个域
在上级域的名字服务器中增加两条记录指向这个新增的子域的域名和域名服务器的地址在新增子域的名字服务器上运行名字服务器负责本域的名字解析:名字-IP地址
例子:在com域中建立一个“Network Utopia”
到注册登记机构注册域名networkutopia.com 需要向该机构提供权威DNS服务器基本的、和辅助的的名字和IP地址登记机构在com TLD服务器中插入两条RR记录: (networkutopia.com,dns1.networkutopia.com,NS)域名和该域名的权威服务器域名 (dns1.networkutopia.com212.212.212.1,A)主机ip地址 在networkutopia.com的权威服务器中确保有 用于Web服务器的www.networkuptopia.com的类型为A的记录用于邮件服务器mail.networkutopia.com的类型为MX的记录
攻击DNS
DDoS攻击 对根服务器进行流量轰炸攻击:发送大量ping 没有成功原因1:根目录服务器配置了流量过滤器防火墙原因2: Local DNS服务器缓存了TLD服务器的IP地址因此无需查询根服务器 向TLD服务器流量轰炸攻击:发送大量查询 可能更危险效果一般大部分DNS缓存了TLD 重定向攻击 中间人攻击 截获查询伪造回答从而攻击某个DNS回答指定的IP站点 DNS中毒发送伪造的应答给DNS服务器希望它能够缓存这个虚假的结果技术上较困难:分布式截获和伪造 利用DNS基础设施进行DDoS 伪造某个IP进行查询攻击这个目标IP查询放大响应报文比查询报文大效果有限 总的来说DNS比较健壮
三、P2P应用
1. 纯P2P架构
没有或极少一直运行的服务器任意端系统都可以直接通信利用peer的服务能力Peer节点间歇上网每次IP地址都有可能变化
例子:
文件分发(BitTorrent)流媒体(KanKan)VoIP (Skype)
2.文件分发 C/S模式
P2P模式
比较
P2P文件共享 例子 Alice在其笔记本电脑上运行P2P客户端程序间歇性地连接到Internet每次从其ISP得到新的IP地址请求“双截棍.MP3”应用程序显示其他有“双截棍.MP3”拷贝的对等方Alice选择其中一个对等方如Bob.文件从Bob’sPC传送到Alice的笔记本上: HTTP当Alice下载时其他用户也可以从Alice处下载Alice的对等方既是一个Web客户端也是一个瞬时Web服务器所有的对等方都是服务器 可扩展性好 两大问题: 如何定位所需资源如何处理对等方的加入与离开 可能的方案 集中分散 半分散 非结构化P2P
P2P集中式目录 最初的“Napster”设计
1当对等方连接时它告知中心服务器: IP地址内容 2Alice查询“双截棍.MP3”3Alice从Bob处请求文件文件传输是分散的,而定位内容则是高度集中的 存在的问题
单点故障性能瓶颈侵犯版权
P2P完全分布式 Gnutella协议
在已有的TCP连接上发送查询报文对等方转发查询报文以反方向返回查询命中报文以反方向返回查询命中报文 P2P混合体 P2P文件分发BitTorrent
BitTorrent是一种用于文件分发的流行P2P协议文件被分为一个个块256KB网络中的这些peers发送接收文件块相互服务 Peer加入torrent洪流 : 一开始没有块但是将会通过其他节点处累积文件块向跟踪服务器注册获得peer节点列表和部分peer节点构成邻居关系“连接” 当peer下载时该peer可以同时向其他节点提供上载服务Peer可能会变换用于交换块的peer节点扰动churn: peer节点可能会上线或者下线一旦一个peer拥有整个文件它会自私的离开或者保留利他主义在torrent中
BitTorrent请求发送文件块
请求块: 在任何给定时间不同peer节点拥有一个文件块的子集周期性的Alice节点向邻居询问他们拥有哪些块的信息获得四个文件块Alice再向peer节点请求它希望的块稀缺的块在这期间其他peer可以向他请求块先随机获取四块是因为如果获取稀缺块等待时间过长而且此时获取时还可以向其他peer发送块再获取稀缺块是因为稀缺块少防止持有稀缺块的peer下线获取后稀缺块又多了peer能更好的提供服务再获取其他块有一个文件全部的peer他就是种子啥都没有就是吸血鬼了。 发送块:一报还一报tit-for-tat Alice向4个peer发送块这些块以后就会向它自己提供最大带宽的服务 其他peer被Alice阻塞(将不会从Alice处获得服务)每10秒重新评估一次前4位 每个30秒:随机选择其他peer节点向这个节点发送块 ‘优化疏通”这个节点、新选择的节点可以加入这个top4 结构化DHT 按照ID号大小围成一圈当前对等方的IP地址标识符等信息其紧挨着后面的一个对等方知道8知道5假设使用该环形覆盖网络,初始对等方对等方3生成一个报文,问“谁负责键11?”并绕环顺时针发送该报文。无论何时某对等方接收到该报文,因为它知道其后继和前任的标识符,它能够确定是否由它负责即最邻近查询中的键。如果某对等方不负责该键,它只需将该报文发送给它的后继。因此例如当对等方4接收到询问键11的报文,它确定自己不负责该键因为其后继更邻近该键)故它只需将该报文传递给对等方5。这个过程直到该报文到达对等方12才终止对等方12确定自己是最邻近键11的对等方。此时对等方12能够向查询的对等方即对等方3回送一个报文指出自己负责键11。为减少每个对等方必须管理的覆盖信息的数量,环形 DHT 提供了一种非常精确有效的解决方案。特别是每个对等方只需要知道两个对等方即它的直接后继和直接前任。但该解决方案也引入了一个新问题。尽管每个对等方仅知道两个邻居对等方但为了找到负责的键在最差的情况下)DHT中的所有N个结点将必须绕环转发该报文;平均发送N/2条报文。细化方案设置一个捷径的DHT上图b 以环形覆盖网络为基础但增加“捷径”,使每个对等方不仅联系它的直接后继和直接前任而且联系分布在环上的数量相对少的捷径对等方。使用捷径来加速查询报文的路由选择。具体来说当某对等方接收到一条查询一个键的报文时,它向最接近该键的邻居后继邻居或捷径邻居之一)转发该报文。所以当对等方4接收到请求键11的报文,它确定在它的邻居中对该键最邻近的对等方是它的捷径邻居10并且直接向对等方10转发该报文。显然捷径能够大大减少用于处理查询的报文数量。 三、CDNContent Distribution Network
1.多媒体视频
视频:固定速度显示的图像序列 e.g. 24images/sec 网络视频特点: 高码率:10x于音频,高的网络宽需求可以被压缩90%以上的网络流量是视频 数字化图像:像素的阵列。 每个像素被若干bits表示 编码:使用图像内和图像间的冗余来降低编码的比特数 空间冗余(图像内)发送视频的某一帧图片时其背景是紫色不发送N个相同的颜色全部是紫色值仅发送2个值颜色紫色和重复个数N时间冗余(相邻的图像间)不发生第i1帧的全部编码而仅仅发送和帧i差别的地方。 CBR:(constant bitrate):以固定速率编码VBR:(variable bitrate):视频编码速率随时间的变化而变化 例子: MPEG 1 (CD-ROM)1.5MbpsMPEG2 (DVD)3-6 MbpsMPEG4 (often used inlnternet, 1 Mbps)
2.多媒体流化服务
DASH: Dynamic,Adaptive Streaming over HTTP服务器: 将视频文件分割成多个块每个块独立存储编码于不同码率(8-10种)告示文件(manifest file) :提供不同块的URL 客户端: 先获取告示文件周期性地测量服务器到客户端的带宽查询告示文件,在一个时刻请求一个块HTTP头部指定字节范围 如果带宽足够选择最大码率的视频块会话中的不同时刻可以切换请求不同的编码块(取决于当时的可用带宽) “智能”客户端:客户端自适应决定 什么时候去请求块(不至于缓存挨饿或者溢出)请求什么编码速率的视频块(当带宽够用时请求高质量的视频块)哪里去请求块(可以向离自己近的服务器发送URL或者向高可用带宽的服务器请求)
3.CDN内容分发网络
挑战:服务器如何通过网络向上百万用户同时流化视频内容(上百万视频内容)?选择1:单个的、大的超级服务中心“mega-server” 服务器到客户端路径上跳数较多瓶颈链路的带宽小导致停顿“二八规律”决定了网络同时充斥着同一个视频的多个拷贝效率低付费高、带宽浪费、效果差单点故障点性能瓶颈周边网络的拥塞
评述:相当简单但是这个方法不可扩展
选项2:通过CDN全网部署缓存节点存储服务内容就近为用户提供服务提高用户体验 enter deep:将CDN服务器深入到许多接入网部署到local ISP附近 更接近用户数量多离用户近管理困难如Akamai部署了1700个位置 bring home:部署在少数(10个左右)关键位置如将服务器簇安装于POP高层ISP面向客户网络的接入点 附近离若干first ISP POP较近 采用租用线路将服务器簇连接起来Limelight CDN:在CDN节点中存储内容的多个拷贝 e.g. Netflix stores copies of MadMen 用户从CDN中请求内容 重定向到最近的拷贝请求内容如果网络路径拥塞可能选择不同的拷贝 总结
以上就是应用层SMTP、DNS、CDN等讲解。
