收藏 分销(赏)

电子邮件外文翻译.doc

上传人:精**** 文档编号:1629621 上传时间:2024-05-06 格式:DOC 页数:14 大小:681KB
下载 相关 举报
电子邮件外文翻译.doc_第1页
第1页 / 共14页
电子邮件外文翻译.doc_第2页
第2页 / 共14页
电子邮件外文翻译.doc_第3页
第3页 / 共14页
电子邮件外文翻译.doc_第4页
第4页 / 共14页
电子邮件外文翻译.doc_第5页
第5页 / 共14页
点击查看更多>>
资源描述

1、对简单邮件传输协议(SMTP),邮局协议(POP)和X.400电子邮件协议的比较学习P. Tzerefos, C. Smythe, I. Stergiou and S. CvetlkovicDepartment of Computer ScienceThe University of Sheffield21 1 Portobello St., Sheffield S1 4DP, UK摘要我们呈现了三个最广泛使用的消息传输协议的主要特点及功能,我们学习了实际的实现细节以及确定我们的分析是基于标记的。这个协议的表现体现在端到端的延迟上,流量的大小以及在物理传输层产生的框架数目和框架长度的分布上。一

2、个分析上的模型提出了由SMTP产生的量近似的上限和下限,这同样可以很容易的扩展到POP3上,这个模型在TCP层同时考虑到了明确的一面和潜在的一面。1 介绍电子消息传输早在1960年代就作为了一个计算机应用程序为我们所用,甚至早在因特网被创建之前,首次尝试为电子邮件在不同的平台传送提供一个协议的举动就得到了ARPA(提出了简单邮件传输协议SMTP)的支持。自那开始,电子邮件就已经成为了最为计算机网络所用的应用程序,SMTP协议被开发出来了,它的主要应用在于从一台主机发送邮件到另一台主机的过程,接受者此时则可以通过文件系统获取消息。这个方法的高效是假设用户是通过终端登录站点的基础上的。然而,SMT

3、P并没有提供功能来允许用户从一个远程地址或一个访问不到服务器主机的文件系统的客户端来获取邮件,这让文件传输协议(FTP)成为了唯一的获取邮件的方式,因此,邮局协议(POP)就被开发出来了并且现在已经有第三版本(POP3)了。由于保证交付可能需要的地方和 ITU-T(原CCITT)于1982年发表的X.400一系列建议让人们很快就意识到SMTP在商业和安全关键应用程序上的效率低下。这个建议最新的版本和推荐的版本都是在1992年发行的,X.400协议是用来加强安全措施的,比SMTP更安全更强健,因此X.400也是一个非常复杂的协议,尤其是它要求从中间消息处理主机确保高质量的服务的寻址模式。这其中有

4、一项很重要的网络设计和分析阶段是对需实现的应用产生的通信量的预报和特征描述。本论文研究了通信量的特征描述和其中三个最为广泛使用的电子邮件协议的功能。在第二节我们陈述了三个协议在功能性上的,还有大纲级别的区别不同,在第三节,我们检测了它们的延迟特征,第四节中描述了为SMTP所产生的大概的通信量所推荐的分析模型,最后,我们总结了以上陈述。2 协议的特征SMTP和POP3都是对方的互补,SMTP用于从一个主机寄发消息到另一个,而POP3用于获取发出的消息。它们有个特别简单的结构,直接在传输控制协议和因特网协议(TCP/IP)顶层进行操作,还有通过简单的ASCII命令进行沟通。SMTP和POP3的命令

5、如下:表1表2在14个SMTP命令中只有4个:MAIL,RCPT,DATA和QUIT是在邮件发送的时候有用的。其他的命令像SEND,SOML,SAML是用来消息重定向直接到接受者的主机,因此其他命令基本废弃了。这些消息的头部,比如主题,答复,地址等都是消息的一部分并且被客户端软件所处理,但并不是协议的一部分。如果这些消息需要以同一个域名发送到多个接收者则 消息只会传输一次以确保节约带宽资源。SMTP是不安全的,并且不提供发送者认证。它允许发送者通过VRFY命令核实接收者在发送者的域中是存在的。即使接收方主机为了获取发送方的地址需要响应带有VRFY命令的消息到发送方的主机,仍然没有方法来确保发送

6、方是它所要求的。如果初始源主机没有一个域名系统(DNS)的入口则对发送方的确认将成为了不可能的事,这将允许不存在的地址或者更糟糕的是假地址的使用。此外,SMTP并没有提供可靠的传输,如果因为某些原因消息没有发送到接收方则它会返回到发送方,这将需要发送方重新提交待发送的消息进行传输。SMTP原本开发出来是处理文本消息的,直到最近带有多媒体内容的消息需要通过额外的设备如转换器来编码进行传输,但现在可以附带多媒体功能的多用途因特网邮件扩展(MIME)已经可用了,然后这些扩展是在客户端软件里实现的,并不是SMTP的一部分。POP3协议的规格也是相对简单并且定义了12条基本的指令,其中4条指令在获取消息

7、时有效,它们是USER,PASS,RETR和QUIT。尽管POP3在以ASCII文件字符串的形式于单个TCP协议数据单元传输(PDU)的密码未加密,用户认证仍然是需要的。在大多数实现中,这些被用来从POP3服务器获取消息的密码也是用户的登录密码,这也增加了安全顾虑。X.400符合七层开放系统Interconnection/reference模型(OSI / RM)和运营在ISO-Development环境(DE)。传输会聚协议在RFC 1006 TCP/IP之上是必需的。协议栈和X.400实现的TCP / IP如图1所示。建筑组件的一个X.400系统是用户代理(UAs)和消息传输代理(MTAs

8、),消息存储(MSs)。消息传播由发送方的主机到收件人的UAs通过MTA(s)。消息存储在MS,这可能与MTA共存在相同的主机如果收件人不能接收消息。图1 X.400协议栈X.400是一个更安全的和健壮的协议。在MTAs方法之间的消息交换是存储和转发。不是直接发送消息到收件人的消息传递服务器,如SMTP, 各个中间MTA使某些消息确认传递给下一个内联MTA要求。每个消息存储在MS直到它被识别。如果交付失败则从MS检索和重新提交。因此, 用户能确保消息最终会到达接收方。不同的消息内容是允许存在一个香甜的消息中的,这让X.400在传输多媒体内容上更加灵活。相比网络类型的userdomain.dom

9、ain,X.400的解决方案要复杂的多。X.400的样例地址可能是/ G = Polychronis / S = Tzerefos / P = dcs /A=Sheffield / C =UK,其中 G为给定的名称、S为姓名,P为私营管理域(PRMD)管理,A为管理员管理域(ADMD),C为国家,这样的地址很难记住所以X.500目录服务被建议开发(我们不讨论X.500协议)。3 技术性能分析分析SMTP、POP3和X.400的协议是基于基准测试的。系统测试的配置是显示在图2.A P90 PC运行网景的邮件SMTP/POP和NEXOR消息X.400是连接到一个SPARCstation 4运行SM

10、TP、POP3和X.400的服务器。一个网络专家嗅探器协议分析器被用于获取客户端和服务器之间的交换的帧。最后,一个Windows socket监视应用程序为了在TCP层监视和时间戳事件而用来在客户端使用。系统和协议效率的重要绩效指标如下,由协议栈产生的用户数据的大小,端到端的延迟,介质访问控制(MAC)的数量,帧创建和帧长度分布。最后两个重要因素指标是随机存取的MAC协议(如带有碰撞检测的载波监听多路访问 (CSMA/CD)、ALOHA等。在许多传输小帧数据在那里性能不佳。对于我们的测试我们生成十条从IKB-10KB的信息这被送到和检索服务器。比较端到端延迟的结果中,我们发现在物理层的延迟差异

11、, 协议分析器的痕迹,和TCP层, 源自于Winsock监控跟踪, 都无关紧要(端到端延迟总额的0.10%到0.36%的,平均为0.21%)。因此我们废弃了在客户端的监视应用程序以最小化管理费用和重复测试。3.1协议效率以在PDU头或连接建立的形式在通信的对等层被添加的协议开销可以降低一个确定文件的效率,下图描述了3个协议栈的学习过程。图2 试验台配置SMTP向用户信息添加最小的开销以消息发送方地址, 收件人地址,消息的提交时间,信息编码等信息的形式。邮件客户端软件高度实现添加额外的特性的特定字段,例如MIME扩展,如果他们不支持的客户端则收件人将忽略。我们的测试中的典型消息头是377字节。P

12、OP3不添加任何消息头。额外的SMTP和POP3协议的开销是在个人TCP PDUs上客户端和服务器之间进行的握手交换原语(命令) 。SMTP必须定义发送方、接收方并通过发送MAIL,RCPT和DATA命令指出消息传递的开始,这其中所有命令都能被SMTP服务器所明确的识别。结束的消息标识符是在一个单独的传播TCP PDU 的“.”的序列。POP3需要识别用户,发送密码和查询邮箱的状态通过分别使用USER,PASS和STAT命令。再次申明这些命令能够被明确识别在同样的POP3层。X.400协议的消息标题、用户身份验证和在客户机和服务器之间交换的服务定义原语和复杂的协议栈,过多的基础协议是协议开销的

13、主要来源。X.400协议栈的协议头部被定义在3中,ISO-TP,回话层,和表示层都是面向连接的,并且都需要一个连接的建立和脱离阶段。然而在表示层连接的请求和确认是封装在会话层连接/确认的PDUs的。TCP连接为了X.400和POP3会被建立一次而SMTP在每个消息成功发送后会断开连接。图3 协议效率(b) SMTP后台进程(d)端到端延迟(c)所占总延迟的百分比, 创建的帧数VS消息大小在此基础上我们希望X.400是在SMTP和POP3后面最有效的。然而,随着如图3所示SMTP是最不高效的,只有当消息大小超过8 kb,SMTP的效率才略高于X.400。我们发现SMTP表现不佳的原因是每个消息的

14、提交后TCP连接会被销毁。这个结果导致在随后的消息中一个额外的SMTP 客户端/服务器的握手。这是一个特定于实现缺点并取决于客户端软件。因此我们计算SMTP协议的高效性时是基于TCP连接被保持直到最后一条消息发送完毕。结果如图所示。SMTP的效率优化可以增加9.3%当消息长度为1 kb时。通过微调的TCP层的操作,确认是隐式的而不是显式地为每个TCP PDU创建,这三个协议可以进一步的提高效率。占SMTP,POP和X.400分别创造的明确的TCP确认总量是6.78%,3.52%和8.22% (1KB消息)。在缓慢和/或严重加载服务器的情况下,TCP慢启动算法只能是有益的。这将防止客户端SMTP

15、应用程序在收到确认之前发送会在服务器端废弃的数据包。高速网络和服务器性能的协议可以在隐式创建中受益。3.2端到端延迟我们测量第一个TCP同步(SYN)PDU捕获到最后TCP FIN确认的时间。这一次Winsock监控跟踪显示出在物理层上端到端的延迟并不显著并明显小于在TCP层端到端延迟。因此,我们禁用Winsock监视器的动作将增加在客户端额外开销。这三个协议端到端延迟测量的结果如图3所示。三个协议对消息大小的变化表现的延迟有显著的变化。不管怎么变化,POP3被证明在三个协议中是最快的,SMTP和X。400需要更多的时间传输他们的信息。尽管SMTP似乎产生了最高的延迟我们发现一个大部分的延迟由

16、inetd唤醒SMTP守护进程所需的时间。在SMTP基准测试中这重复了几次,并且在每一个新消息中重置了TCP连接。我们定义延迟d 为SMTP服务器虚拟光驱TCP建立之后做出反应所花费的时间。在图3中我们显示了整体端到端延迟。正如我们可以看到报警的延迟SMTP守护进程的范围在所有的延迟中从38.3%到-42.6%。很显然, 通过让TCP连接一直开启直到所有消息已提交,SMTP性能可以大大提高。端到端延迟还取决于具体的软件实现的协议,客户机和服务器的负载以及他们之间的中间联系。为了我们测试的持久性,后台装载在服务器,客户端和以他网lan最小的互连10Mbps。3.3 帧长度和帧长度分布协议性能的一

17、个重要指标是在物理层生成的帧的数量和他们的长度的分布。它证明了4,5随机存取的MAC协议的吞吐量(ALOHA、CSMA CSMA/CD)时在提供的负载是许多小的形式而不是更少但更大的框架时大大减少。这是由于增加了碰撞的概率也会增加的网络规模增加。这样的一个度量分析随机存取协议时重要的比如数据网络,跑几公里电缆电视(有线电视) 网络。图4 SMTP协议栈消息分层创建的帧的数量的结果是由三个协议提出的如图3(d)。再次相比POP3和X.400,SMTP发送邮件生成更多的帧。虽然最佳-SMTP减少了框架创建的数量,这个数字仍然是最大的。POP3和X.400对消息的大小的划分几乎是线性的大于消息大小是

18、3KB的,作为对比,SMTP和最佳-SMTP刻画了当从奇怪的甚至上千字节的消息长度中移动时帧所产生数目的增加。我们发现是由于实际的消息在TCP层交付机制。图5 (a)SMTP (b)POP3 (c)X.400 帧长度的分布对于消息大小当SMTP提交消息TCP的长度包没有充分利用(例如1460字节)。SMTP以2KB= 2024 字节提交数据块到TCP层,这分散并传输在两个TCP PDUs。因此在假设377字节SMTP开销的情况下一个2 kb和3 kb的消息将划分为三个MAC帧,如图4所示。然而一个4 kb消息将需要一个额外和相对的的MAC帧和消息的确认,因此突然增加了创建的帧的数量。相比之下P

19、OP3和X.400利用TCP PDU的全部长度,因此产生一个平滑线性的曲线。帧的长度分布的生成如图5(a),(b)和(c)中所示,我们发现多数的帧的数量的创建为大小少于100字节的帧。在X.400分层管理开销也造成了很大一部分在100 - 200字节帧。当在重加载或在MAC层长期使用多个网络的访问方法时,这一事实带来了严重的关于协议的性能。这些小帧被用来运载:协议命令TCP/ISO-TP/表示层/会话层连接请求,连接确认以及PDUs的连接TCP确认小帧的数目可以在TCP层通过强制的非明确化确认、延长在发出明确的确认之前TCP等待上层数据的时间(在测试中是500毫秒)来最小化。然而这个方法可能对

20、于通过广域网(WAN)连接时所带来的高延迟的主机是不可行的,在POP3和X.400中,由于两个协议早期使用了MAC全帧来解释,大帧(大于1000字节)和完整的帧的数目是值得注意的大。相对而言,SMTP会产生更多的短帧(小与100字节)并且很多都是半满的,而全满的帧是600-700字节大小。这又是SMTP降低性能的另一方面,然而,这也有可能在复杂的环境中成为SMTP的长处,由于小容量的包丢包的概率要小,并且就算丢包了或中断了也只有一小部分内容需要重新传输,故小容量的包可以提高生产力。4 源建模SMTP和POP3的简单结构和操作允许提出精准的源模型,我们为了定义数学上的流量源模型提出了方法论,此源

21、模型有由SMTP协议栈产生的流量(用户消息大小m)的近似值,只要TCP接受应答是明确的或是隐含的,则追溯准确的源模型是可能的。因此,我们将要分别给出当TCP确认是明确的和隐含的时候的模型的上限和下限,我们定义了如下信息量:n1: 用户数据的长度n2:客户端应用程序加上的消息头的长度m:n1+n2a:长度为60字节的明确的TCP确认应答的数目f:在客户端服务器间为了传输单个消息所发送的命令和响应的个数l1:从TCP传输的SMTP PDU的长度l2:TCP最大的开销h1:MAC头部的长度h2:IP头部的长度h3:TCP头部的长度T1:在TCP连接阶段和连接确认阶段中所产生的流量T2:在TCP断开连

22、接阶段所产生的流量在由SMTP协议所产生的高层中,我们定义如下所示信息量:(所有长度均为字节)s1:SMTP服务器打招呼s2:SMTP客户端HELO命令s3:SMTP服务器HELO响应s4:包含发送者地址的MAIL命令s5:服务器响应MAIL命令s6:包含接收者地址的RCPT命令s7:服务器响应RCPT命令s8:DATA命令s9:MAIL ACCEPTED 服务器的响应s10:开始识别命令的DATA消息s11:消息尾部的“.“识别所装载的一个单独的TCP PDUDATA和.创建了一个最小为60字节长的以太网帧,因此我们设置了S10=S11=60,并且不加上 TCP/IP/MAC 的头部信息。图

23、6 SMTP时间轴图图7 SMTP产生的流量与消息大小关系si(i=1.9)的值取决于具体实现、发送者和接收者地址的长度、客户端和主机地址的长度。基于实现上的,有一些命令可能一点也不会使用,比如HELO命令,为了产生一个更加精确的模型,我们需要检查在具体特定的实现中哪些命令是会用到的。而这很容易通过向SMTP服务器在端口为25(POP3为110)的时候初始化一个TELENT会话来获得。为了清晰,我们在图六中给出了SMTP的时间轴,最终,我们定义了作为长度为l1的消息分隔段的数目,我们首先乐观的计算了当TCP确实是隐含在SMTP响应中时SMTP所产生的流量,SMTP命令和响应,以及TCP的建立和

24、撤销所产生的流量由下给出:如果m是l1的模,则仅需要传输消息时所产生的流量由下给出:当消息大小不是l1的模时,产生的附加的流量如下给出:假定明确的应答确认a由下给出:基于上述,当假定明确的应答确认时上限是可以获得的,当所有应答确认都是隐含的时候,下限可以得到,因此,我们有:4个典型的实现的值已经在表3中给出,我们根据建议的模型来估算所产生流量的上限和下限,并且与协议分析中做了比较,如图7中所示。我们观察到了,理论上的上限和下限在观察的值都是小消息大小(最大3KB)时是非常好的近似值,当时大消息时,上限是很好的估算值,而下限甚至对于10KB的消息也只有96%的精确度。这是因为系统的检查,如果他从

25、同层中不到500ms获取到了PDU,则TCP将会隐含的应答接受。当两个节点是在一个高延迟的网络中互连的情况下,则上限的近似更适合系统。表3由于POP3也是类似的简单操作,所以一样的方法可以应用于POP3。X.400的初始考虑的分析模型被呈现在3中,由于X.400是一个很复杂的协议,故留在后续的工作中研究。5总结我们比较了最常用的电子消息传输协议,我们基于基准测试得到的结果证明了尽管X.400结构比较复杂,但其在就端到端延迟,创建的流量,以及帧长度分布而言,仍然匹配甚至比SMTP更加的高效。尽管POP3的功能是比较局限的,但其仍被证明是最高效的协议。客户机SMTP应用程序的操作显著提高性能(就端到端延迟而言多达42%)通过维护TCP连接直到所有消息被转发。分析源模型建议为SMTP提供精确的近似(从1KB消息的98%到10KB消息的96%)。相同的模型可以很容易地修改并应用于POP3。6 参考文献

展开阅读全文
相似文档                                   自信AI助手自信AI助手
猜你喜欢                                   自信AI导航自信AI导航
搜索标签

当前位置:首页 > 包罗万象 > 大杂烩

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服