汇总RFC翻译

于 2024-02-01 20:56:01 发布
阅读量1k 收藏 27
点赞数 14
分类专栏： RFC 文章标签： 网络
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_36174006/article/details/135981934
版权

准备慢慢的自己将相关的RFC文档翻译一遍。这是一个汇总的列表，后面还会根据自己的需要不断添加需要翻译的文档，以及修改对每个文档的备注。

只是个人的学习，不足和错误还请多指教。

一.TCP/IP协议簇

TCP/IP协议簇是一组构成互联网基础的通信协议。各个协议都有相应的RFC（Request for Comments）文档来定义它们的标准和行为。下面列举一些TCP/IP协议簇中核心协议及其对应的RFC文档：

  1. Transmission Control Protocol (TCP):

    • RFC 793: 定义了最初的TCP规范。

  2. User Datagram Protocol (UDP):

    • RFC 768: 规定了UDP的运作方式。

  3. Internet Protocol (IP):

    • RFC 791: 描述了IPv4协议标准。

    • RFC 2460: 定义了IPv6协议。

  4. Internet Control Message Protocol (ICMP):

    • RFC 792: 针对IPv4环境下的ICMP。

    • RFC 4443: 针对IPv6环境下的ICMPv6。

  5. Address Resolution Protocol (ARP):

    • RFC 826: ARP协议规范。

  6. Reverse Address Resolution Protocol (RARP):

    • RFC 903: RARP协议规范。

  7. Point-to-Point Protocol (PPP):

    • RFC 1661: PPP协议规范。

    • RFC 1662: PPP在HDLC-like framing中的实现。

  8. Border Gateway Protocol (BGP):

    • RFC 4271: BGP-4协议规范。

  9. Dynamic Host Configuration Protocol (DHCP):

    • RFC 2131: DHCP服务的基础规范。

  10. Domain Name System (DNS):

    • RFC 1034: DNS的概念和技术规范。

    • RFC 1035: DNS的具体协议细节。

以上仅为部分重要协议及其RFC文档，实际上TCP/IP协议簇内含众多子协议和扩展，每个都有详细的RFC文档记录其设计、功能和实现细节。若需要最新的RFC列表或详细了解某个特定协议，请访问IETF（Internet Engineering Task Force）官方网站的RFC索引页获取最新信息。

二、HTTP

HTTP（Hypertext Transfer Protocol）也有多个相关的RFC文档，下面是几个关键版本：

  1. HTTP/1.0:

    • RFC 1945: 定义了原始的HTTP 1.0版本。

  2. HTTP/1.1:

    • RFC 2616: 这是HTTP 1.1早期的一个综合RFC，虽然现在已经被细化成多个RFC替代，但仍然经常被引用。

    • 后续细化的RFCs：

      • RFC 7230: HTTP/1.1: Message Syntax and Routing

      • RFC 7231: HTTP/1.1: Semantics and Content

      • RFC 7232: HTTP/1.1: Conditional Requests

      • RFC 7233: HTTP/1.1: Range Requests

      • RFC 7234: HTTP/1.1: Caching

      • RFC 7235: HTTP/1.1: Authentication

  3. HTTP/2:

    • RFC 7540: 定义了HTTP/2协议，该版本显著提高了性能，引入了多路复用、头部压缩等新特性。

  4. HTTP/3:

    • RFC 9114 (QUIC transport): QUIC传输层协议，HTTP/3基于此构建。

    • HTTP/3 over QUIC:

      • 目前HTTP/3尚未正式通过一个单一RFC发布，但它基于IETF QUIC工作组的工作，并参考了多个草案文档。最终规范可能会在未来形成RFC。

请注意，随着时间的推移和技术的发展，上述RFC可能会有更新或者修订版出现。为了获取最准确和最新的HTTP协议标准，请查阅IETF官方发布的RFC文档。

三、POP3

POP3（Post Office Protocol version 3）是用来从邮件服务器下载电子邮件的古老且广泛应用的协议。它的RFC文档详细描述了其工作原理和实现细节。

POP3的主要RFC文档是：

  • RFC 1939: 这是原始的POP3协议规范，定义了基本的邮件获取操作。它发布于1996年。

随着时间推移，为了增强安全性，对POP3进行了扩展以支持加密传输，相关的RFC包括：

  • RFC 2595: 它引入了使用STARTTLS扩展在不安全的网络上传输POP3时进行安全层升级的方法，通常基于SSL/TLS协议。

  • RFC 4978: POP3的更新版，即“IMAP4 COMPATIBILITY WITH THE POST OFFICE PROTOCOL (POP3)”，提供了与IMAP4更好的兼容性建议。

当前推荐使用的POP3版本，结合安全传输，主要参照的是RFC 1939以及关于安全传输的RFC扩展文档。如果您想要详细了解POP3协议，可以查阅这些RFC文档。随着技术的发展，现代邮件服务更多地倾向于使用更安全且功能更丰富的IMAP协议（RFC 3501及后续相关RFC）。

四、IMAP

RFC 3501

RFC4314

RFC 4551

RFC 3502

RFC3516

RFC3501(取代了RFC2060)

RFC8314

IMAP（Internet Message Access Protocol）是一种用于访问和管理远程邮件服务器上存储的邮件的标准协议。相比于POP3（主要用于下载并删除邮件），IMAP允许用户在客户端和服务器之间保持邮件的同步，并提供更为灵活的邮件管理功能。

以下是IMAP协议的关键RFC文档：

  1. RFC 3501: 这是最基础且核心的IMAP4rev1协议规范，它详细描述了IMAP协议的工作机制、命令集、响应格式以及如何处理邮件和邮件箱等。

    RFC 3501: Internet Message Access Protocol - Version 4rev1

  2. RFC 4314: 关于IMAP邮箱的访问控制列表（ACLs）。

  3. RFC 4551: 引入了SORT和THREAD命令，增强了IMAP协议对于邮件排序和线程化显示的支持。

  4. RFC 3502: 对IMAP中的多部分消息处理进行了说明。

  5. RFC 3516: IMAP扩展——关键词搜索（SEARCH=KEYWORD）。

  6. RFC 2060（已由RFC 3501取代）：最初的IMAP4协议规范。

此外，还有许多其他RFC文档扩展了IMAP协议以支持安全连接（如使用TLS/SSL）和其他功能改进。例如：

  • RFC 8314: 要求IMAP和POP3服务器默认启用并强制使用STARTTLS来加密非安全连接。

要详细了解IMAP协议，请直接查阅上述RFC文档。IMAP协议因其强大的灵活性和实时同步能力而被广泛应用于现代邮件系统中。

五、SSH

RFC 4251

RFC 4252

RFC 4253

RFC 4254

RFC 4716

RFC 6668

SSH（Secure Shell）是一种网络协议，用于在不安全的网络上安全地执行远程登录和其他网络服务。SSH协议的设计目的是提供数据机密性、完整性以及用户身份验证。以下是一些与SSH相关的RFC文档：

  1. RFC 4251: 定义了SSH协议框架，包括总体架构、基本的数据类型、编码规则、以及协议版本号。

  2. RFC 4252: 描述了SSH的身份验证协议，包括公钥认证、口令认证及其他认证方式。

  3. RFC 4253: 规定了SSH传输层协议，它负责数据加密、压缩、MAC计算以及其他传输层相关功能。

  4. RFC 4254: 定义了SSH连接协议，用于建立多个安全通道（secure channels），比如一个用于命令执行的会话通道（session channel）或其他类型的交互。

  5. RFC 4716: 规范了OpenSSH公钥证书的格式，这种证书用于SSH公钥认证体系中。

  6. RFC 6668: 取消了旧版SSH-1协议，推荐使用SSH-2协议。

这些RFC共同构成了SSH协议的核心标准，并不断随着安全需求和技术发展而更新。SSH在实际应用中广泛用于远程登录、文件传输（SFTP基于SSH）、端口转发等多种场景。

六、PPP

1.RFC 1661

2.RFC 1662

3.RFC 1332

4.RFC 2516

PPP（Point-to-Point Protocol）即点对点协议，是一种在点对点链路上封装多种网络层协议的数据链路层协议。PPP协议主要用于拨号上网、DSL连接和两台计算机之间直接的串行通信等场景。以下是与PPP相关的几个关键RFC文档：

  1. RFC 1661：

    • 标题：The Point-to-Point Protocol (PPP)

    • 链接：RFC 1661 - The Point-to-Point Protocol (PPP)

    • 描述：定义了PPP的基本操作、帧格式、LCP（Link Control Protocol）控制协议，以及如何封装其他网络层协议。

  2. RFC 1662：

  3. RFC 1332：

  4. RFC 2516：

除此之外，还有关于PPP认证协议如PAP（Password Authentication Protocol）和CHAP（Challenge Handshake Authentication Protocol）的RFC文档：

以上RFC共同构建了PPP协议的标准基础，并指导其在不同应用场景中的实施。

七、WebSocket

RFC6455

WebSocket是一种在单个TCP连接上进行全双工通信的协议，旨在提供低延迟的双向通信，特别适合实时应用，如网页聊天、实时游戏、股票报价系统等。WebSocket协议的标准规范是由IETF制定的，对应的RFC文档是RFC 6455，发布于2011年12月。

RFC 6455 - The WebSocket Protocol 定义了WebSocket如何通过握手升级HTTP连接为WebSocket连接，之后客户端和服务端就可以在这个持久连接上自由地发送和接收数据帧，而无需像传统的HTTP那样每次请求都需要建立新的连接。

WebSocket协议的特点包括：

  • 使用HTTP Upgrade机制来初始化WebSocket连接。

  • 使用Sec-WebSocket-Key等头部字段进行安全握手。

  • 提供了一种轻量级的二进制编码框架，支持文本和二进制数据的传输。

  • 允许客户端和服务端互相推送消息，而非仅仅是客户端向服务器发起请求。

八、TLS/SSL

TLS（Transport Layer Security）及其前身SSL（Secure Sockets Layer）的安全协议标准是由一系列RFC文档定义的。以下是主要的RFC版本：

  1. SSL 1.0, 2.0, 和 3.0:

    • SSL 1.0从未公开发布过，存在安全问题。

    • SSL 2.0: 定义于 RFC 6101，但由于存在多个安全缺陷，已被废弃并强烈不建议使用。

    • SSL 3.0: 定义于 RFC 6103，同样由于安全漏洞已不再安全，且在2015年因POODLE攻击而被宣布废弃。

  2. TLS 1.0 - TLS 1.3:

    • TLS 1.0 基于SSL 3.0，并在RFC 2246中定义，后来因为安全性原因逐渐被淘汰。

    • TLS 1.1 在RFC 4346中定义，对TLS 1.0做了一些改进，但如今也被视为过时。

    • TLS 1.2 在RFC 5246中定义，广泛采用并且相对安全，支持当前许多加密套件和算法。

    • TLS 1.3 是目前最新和推荐使用的版本，在RFC 8446中定义，它带来了大幅度的性能提升和安全性改进，比如减少了握手消息的数量以及弃用了弱加密套件。

综上所述，当前推荐使用的TLS协议版本是TLS 1.3，其RFC文档为 RFC 8446。对于TLS 1.2及更早版本，除非出于兼容性考虑，否则应该避免使用。

九、DNS

DNS（Domain Name System）的相关规范由一系列RFC（Request for Comments）文档定义。以下是DNS协议及其扩展的主要RFC列表：

  1. DNS基础协议：

    • RFC 1034: Domain Names - Concepts and Facilities，定义了域名系统的基本概念和机制。

    • RFC 1035: Domain Names - Implementation and Specification，详细描述了DNS的协议细节，包括各种资源记录类型和查询格式。

  2. DNSSEC（DNS Security Extensions）安全扩展：

    • RFC 4033: DNS Security Introduction and Requirements，介绍了DNSSEC的需求与概述。

    • RFC 4034: Resource Records for the DNS Security Extensions，定义了DNSSEC所需的资源记录类型和操作。

    • RFC 4035: Protocol Modifications for the DNS Security Extensions，说明了DNS协议如何修改以支持DNSSEC。

  3. EDNS（Extension Mechanisms for DNS）：

    • RFC 6891: Extension Mechanisms for DNS (EDNS(0))，引入了扩大DNS消息大小和增加DNS功能扩展的方法。

  4. DNS其它重要RFC：

    • RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)，定义了DNS动态更新的协议。

    • RFC 6761: Special-Use Domain Names，指定了某些具有特殊用途的域名如.onion、.arpa等。

    • RFC 8499: DNS Terminology，提供了DNS术语的标准定义。

以上仅为部分关键RFC文档，随着技术发展，还有更多RFC涉及到DNS的具体实现、最佳实践以及其他增强功能。

十、SMTP

SMTP（Simple Mail Transfer Protocol）即简单邮件传输协议，其标准主要由以下几个RFC文档定义：

  1. SMTP基础协议：

    • RFC 5321: Simple Mail Transfer Protocol (SMTP)，这是当前SMTP的核心规范，取代了早期的RFC 821，并详细描述了SMTP的操作规则和消息格式。

  2. ESMTP（Extended SMTP）扩展：

    • RFC 1869: SMTP Service Extension for Command Pipelining，引入了命令管道的概念，允许在SMTP会话中连续发送多个命令而不必等待每个命令的响应。

    • RFC 1870: SMTP Service Extension for Message Size Declaration，定义了SIZE命令，允许在投递邮件前预先声明邮件大小。

    • 其他RFC定义了众多ESMTP扩展，例如认证（AUTH）、八位编码传输（8BITMIME）、优先级标记（MAIL PRIORITY 或已废弃的 RFC 2156）等。

  3. SMTP TLS 加密传输：

    • RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security，定义了如何通过TLS（Transport Layer Security）对SMTP会话进行加密。

  4. 邮件地址国际化：

    • RFC 6531: SMTP Extension for Internationalized Email，用于支持非ASCII字符的电子邮件地址。

    • RFC 6532: Internationalized Email Headers，支持邮件头部字段使用Unicode字符。

  5. 相关邮件处理标准：

    • RFC 5322: Internet Message Format，定义了邮件消息的内容格式，包括邮件头和正文结构。

要详细了解SMTP及其所有相关扩展，建议查阅上述RFC文档以及后续针对特定功能发布的RFC。

十一、FTP

FTP（File Transfer Protocol）文件传输协议的标准同样是由一系列RFC文档定义的，主要包括：

  1. FTP基础协议：

    • RFC 959: 文件传输协议（FTP），这是FTP的基本规范，最初定义了FTP的所有核心操作，包括登录、目录导航、文件上传与下载、断开连接等。

  2. 安全性增强：

    • RFC 2228: FTP Security Extensions，定义了FTP扩展命令集以提供数据保护和用户身份验证的安全控制机制，如数据通道加密（CCC, PBSZ, PROT）和安全认证（AUTH）等。

    • RFC 4217: FTP over TLS，规定了如何在FTP中使用Transport Layer Security (TLS) 来加密控制和数据连接，通常称为FTPS。

  3. PASV模式和EPSV扩展：

    • RFC 1579: FTP Passive Mode Extensions，介绍了被动模式FTP（PASV）的工作原理，解决了FTP在NAT环境下的问题。

    • RFC 2428: Extensions for FTP, including IPv6 and Extensions for NATs,定义了扩展 passive 模式的 EPSV 命令，以适应IPv6和更复杂的网络地址转换环境。

  4. FTP其他扩展：

    • RFC 3659:Extensions to FTP,包括了一些新的命令和功能扩展，比如MLST/MLSD命令用来标准化列出目录信息的方式。

为了全面了解FTP协议及其所有相关扩展，需要查阅这些RFC以及其他可能的更新和补充RFC文档。随着技术的发展，一些更现代的替代方案如SFTP（基于SSH的文件传输协议）和HTTPS文件传输逐渐被更多地采用以提供更强的安全保障。

十二、Telnet(Teletype Network)

Telnet是一个用于远程登录和命令行通信的应用层协议，其标准由一系列Request for Comments (RFCs) 文档定义。以下是关于Telnet协议关键RFC文档的概述：

  1. RFC 854: Telnet Protocol Specification - 这是最早的Telnet协议规范，定义了基本的Telnet命令和选项以及终端类型协商机制。

  2. RFC 855: Telnet Option Specifications - 描述了初始的一系列Telnet选项，例如Echo、Suppress Go Ahead等。

  3. RFC 1143: Telnet Linemode Option - 定义了Linemode选项，允许客户端和服务器之间以更高效的方式处理行编辑和本地回显等功能。

  4. RFC 2217: Telnet Com Port Control Option - 为通过Telnet访问串口设备提供了扩展功能。

  5. RFC 2328: Telnet Authentication Option - 提出了Telnet的身份验证机制。

  6. RFC 4248: Telnet Binary Transmission - 关于二进制数据传输的选项。

随着时间的推移，Telnet由于其明文传输和安全性较低的问题，在很多场景下已被SSH（Secure Shell）协议所取代，SSH提供了加密的数据传输和更强的身份验证能力。尽管如此，Telnet仍然是理解和学习网络协议栈、进行简单远程访问测试时的重要工具。

qq_36174006
关注
  • 14
    点赞
  • 踩
  • 27
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
RFC文档(中文翻译版本)
大明的博客
08-25 2万+
RFC文档目录 RFC1 主机软件 RFC2 主机软件 RFC3 文档规范 RFC4 网络时间表 RFC6 与 Bob Kahn 会话 RFC10 文档规范 RFC13 零文本长度的EOF信息 RFC16 M.I.T RFC18 IMP-IMP和主机-主机控制联接 RFC19_可用来降低有限交换节点阻塞的两条协议性的建议 RFC20_用于网络交换的 A
RFC文档中文翻译完整版(RFC1 ~~ RFC3093)
04-26
RFC文档中文翻译完整版 ，包括(RFC1 ~~ RFC3093)中的所有协议
有关RFC文档的翻译说明 (转)
circularr9834的博客
08-12 226
有关RFC文档的翻译说明 (转)[@more@]这些rfc是jebbthe和我共同翻译的,有些我们不是很肯定的地方,就保留了原句.RFC文档是网上编程的基础,希望我们的翻译能对大家有所帮助.欢迎加入我们的行列,如果有意见,请写信...
RFC中文完整版-china-pub-RFC文档中文翻译计划.zip
11-27
RFC中文完整版-china-pub-RFC文档中文翻译计划.zip
rfc文档（中文翻译）目前最全的
03-18
目前最全的rfc中文翻译（但仍没有英文版全，我另外上传了英文版的rfc0001-rfc5503），送给需要的朋友。
RFC2597中文翻译
02-17
"RFC2597中文翻译" RFC2597中文翻译是一份关于区分服务（DS）中的确保转发（Assured Forwarding，AF）PHB组的RFC文档。该文档定义了一个通用的AF PHB组，提供四个独立的AF类以供IP分组转发。在每个AF类中，IP分组...
rfc1305中文翻译.pdf
01-13
RFC-1305 网络时间协议（版本 3） 本文档介绍了网络时间协议（NTP）的版本 3。它取代了 1989 年 9 月 RFC-1119 中描述的 协议的版本 2。但是，它既没有以任何重大方式更改协议，也没有废弃旧版本或现有实现。 新...
EIGRP RFC翻译
07-12
对EIGRP RFC7868的翻译，关于该协议的许多具体机制和细节，没有太好的书籍，RFC是主要的学习资料了。
rfc2030中文翻译.pdf
01-13
当不需要或不需要 RFC-1305 中描述的完整 NTP 实能时，可以使用 SNTP。当使用当前和以前的 NTP 和 SNTP 版本时，SNTP 版本 4 不会范或已知的实现，而是会澄清 NTP 的某些设计功能，从而允许在简单的，无状态的用...
rfc中文翻译
11-21
包含了1-3093的rfc中文翻译。 组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者： 李超（licc_li licc_li@sina.com） 译文发布时间：2001-5-23 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。 Network Working Group S. Casner Request for Comments: 2508 Cisco Systems Category: Standards Track V. Jacobson Cisco Systems February 1999 低速串行链路下IP/UDP/RTP数据包头的压缩 （RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links） 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以 得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度 和状态。本备忘录的发布不受任何限制。 版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. 摘要 本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法，它可以降低在低速串行链路上 的网络开销。多数情况下，三个头可压缩到2-4字节。 请赐教并将您的建议发送到工作组邮件列表rem-conf@es.net或直接给作者。 本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”， “建议”，“或许”，“可选的”在 RFC 2119 中解释。 目录 本备忘录的状态 1 版权声明 1 摘要 1 1. 介绍 2 2. 设想和折中 2 2.1. 单工与全双工 3 2.2. 分片与分层 3 3.压缩算法 3 3.1.基本概念 3 3.2 RTP数据包头压缩 4 3.3协议 5 3.4. RTCP控制包压缩 12 3.5.非RTP UDP包压缩 13 4.与分片的交互 13 5.压缩协商 13 6.致谢 14 7.参考文献 14 8. 安全性考虑 14 9.作者地址 15 10.版权声明 15 1. 介绍 随着实时传输协议(RTP)成为正式的RFC[1]发行，人们对于利用RTP实现不同的网络音视 频应用程序间互操作的兴趣也日益增长。然而，我们也注意到，当使用低速链路如14.4Kb/s 或28.8Kb/s拨号时，12字节的RTP头对于仅有20字节的负载而言开销实在太大。（为了减少 头占用的字节，一些已经在类似环境下存在的应用通常使用自定义的协议，而这样做的代价 就是削减了RTP相关的功能。） 事实上，正如在TCP中已经取得巨大成功，也可通过压缩技术来令IP/UDP/RTP包头变小。 这时，压缩可以针对于RTP头（在端到端应用中），或者IP，UDP，RTP的组合头（在Link-by-Link 应用中）。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果，因为两 种情况下的结果大小均为约2-4字节。同时，由于延迟和丢失率都很低，对Link-by-Link应 用进行压缩性能上也更好。因此我们在这里定义的方法就是针对Link-by-link应用下 IP/UDP/RTP头进行组合压缩。 本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包。为了能同时在IPv6 和IPv4下使用，这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架。该框架把TCP 和非TCP定义为IP之上的两个传输类。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三 类。 2. 设想和折中 本压缩方案的目标是，在不发送UDP校验和的情况下，将大多数包的IP/UDP/RTP头压缩到 2个字节，在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和 28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信， 所以协议利用了这点，尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路 上往返时间(RTT)很低，从而实现性能最高。 为了降低低速链路下的延迟，除了在第四节中确定了分片和压缩中可能使用的一些交互 外，本规范并未提出大型数据包的分片和占先策略。分片方案可能会单独定义并与本压缩方 案配合使用。 应该注意到，实现的简单性是评价压缩方案的一个重要因素。通信服务器可能要用一个 处理器支持多达100个拨号调制解调器的数据压缩。因此，如下的考虑都是比较恰当的，即 在设计阶段为了实现简单而牺牲一些通用性，或者在设计上灵活通用但为了简单性可对设计 进行子集化。通过在压缩和解压器之间用更复杂的模型通信改变头字段还可以达成更好的压 缩效果，但其复杂性却是没必要的。下一节将讨论这里列出的一些折中方案。 2.1. 单工与全双工 在没有其它限制的情况下，单工链路上的压缩方案应成为首选。但为防止错误发生，单 工链路上的操作需要用一个含有压缩状态信息的未压缩包头进行周期性的刷新。如果明显的 错误信号可以返回，则恢复延迟也可以实质性地缩短，无错误情况的开销也会降低。为了实 现这些性能的优化，本规范包括了一个可逆向发送的明显错误指示。 在单工链路中，可以使用周期性刷新来取代。解压器一旦侦测到错误存在于某个特定的 流中，它可以简单地放弃该流中所有的包直到接收到一个未压缩的头为止，然后继续解压。 其致命弱点在于可能要在恢复解压前要放弃大量的包。周期性刷新的方法在[3]的3.3节中进 行描述，它应用于单工链路的IP/UDP/RTP压缩，或者应用于其它非TCP包流的高延迟链路。 2.2. 分片与分层 在低速链路上发送大型数据包所需时间而导致的延迟对于单向音频应用不算什么大问 题，因为接收方可以适应延迟变动。但对于交互式的交谈，最小端到端延迟是非常关键的。 对大的，非实时数据包进行分片以允许小的实时包在分片间隙进行传送可以降低这种延迟。 本规范只处理压缩，并且假定，如果包括分片，也将被处理为一个单独层。将分片和压 缩按这种方式进行集成并不可取，因为一旦如此，在没有必要或不可能进行分片的情况下， 连压缩都不能使用。类似地，应该避免预留协议的任何需求。除了要求链路层提供一些包类 型码，一个包长度指示和良好的错误检测外，该压缩方案可独立于任何其它机制而应用在本 地链路的两端。 相反，单独对IP/UDP和RTP层进行压缩丢失了太多的压缩效率，这些效率可以通过将它们 一起对待而得到。由于相同的函数可以应用于所有层，实现跨越这些协议层边界的方案是恰 当的。 3.压缩算法 本文定义的压缩算法主要利用了RFC 1144[2]描述的TCP/IP头压缩的设计。读者可以参考 该RFC获取更多的关于对包头进行压缩的基本动机和通用原理。
RFC协议详细解析，中文版
07-22
对RFC协议的详细解析，中文版，做网络服务推流必需的。
中文版RFC文档
06-11
来自以下组织：中国互动出版网（http://www.china-pub.com/）RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）E-mail：ouyang@china-pub.com译者：charliechen（charliechen charliecy@263.net）译文发布时间：2001-4-2版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
rfc中文翻译版本
04-18
rfc 的中文翻译版本，做网络开发，通讯协议都会用的到，你值得下载
HTTP协议(RFC2616)中文版
09-08
HTTP协议(RFC2616)中文版.docx
RFC917.rar_rfc 917 翻译
09-23
中文RFC文档，不用翻译，对大家学习很有帮助！
网络协议---MPL(2)：RFC 7731文档翻译
abatei的专栏
01-06 1868
7、信息库 7.1  本地接口集 本地接口集记录MPL传送者的本地接口。本地接口集由本地接口多元组组成，每个MPL接口对应一个AddressSet。 AddressSet --- 一系列分配给MPL接口的单播地址。 7.2  域集 域集记录了订阅了每个MPL域地址的MPL接口。域集由MPL域多元组组成。每个MPL域对应一个MPLInterfaceSet。
RFC中文翻译计划
如是我闻
02-03 785
藏锋者: http://www.cangfengzhe.com/cdrfc/list_67_2.html BSD爱好者乐园: http://www.bsdlover.cn/html/5/category-catid-5.html 中国协议分析网  http://www.cnpaf.net/Class/RFC/200411/1054.html
RFC简介
杨春建的博客
02-05 4241
原文地址：http://blog.csdn.net/doupei2006/article/details/7252214 1 RFC的简介 1.1 RFC历史及概况 RFC文档也称请求注解文档（Requests for Comments，RFC），这是用于发布Internet标准和Internet其他正式出版物的一种网络文件或工作报告。RFC文档初创于1969年，RFC出版物由RFC
rfc1305中文翻译
最新发布
07-04
这个协议的中文翻译是RFC1305同步网络时间协议。 RFC1305是由David Mills在1988年提出的，并且在之后的几个版本中进行了更新和改进。该协议的主要目的是确保计算机时钟与其他计算机和服务器之间的网络时间保持同步...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值