标题中的“RFC中文文档（HTM带目录）”指的是包含有中文解释的互联网请求评论（Request for Comments）文档集合，这些文档通常以HTML格式呈现，并带有方便查阅的目录结构。RFC是互联网标准过程的重要组成部分，它详细记录了互联网协议、技术规范、建议和问题的解决方案。在本案例中，这些文档特别关注以太网相关的协议和规则。 以太网是一种广泛使用的局域网（LAN）技术，由Xerox公司开发，并在1980年代由Intel和DEC推动标准化。以太网定义了物理层（PHY）和数据链路层（MAC）的规范，属于TCP/IP模型的第二层，即链路层。以下是一些以太网的关键知识点： 1. **以太网类型**：以太网有多种类型，包括传统以太网（10BASE-T、100BASE-TX）、快速以太网（1000BASE-T）、吉比特以太网（10GBASE-T）以及更高速度的40G和100G以太网。 2. **帧结构**：以太网数据帧包含前导码、起始帧分界符、目的地址、源地址、类型/长度字段、数据部分和帧校验序列（FCS）。其中，前导码和起始帧分界符用于同步接收端，FCS用于错误检测。 3. **MAC地址**：每个以太网设备都有一个全球唯一的物理地址，即MAC地址，由6个字节组成，用于在局域网内标识设备。 4. **冲突检测**：早期的以太网采用载波监听多路访问/冲突检测（CSMA/CD）机制来避免数据冲突。当两个设备同时发送数据时，冲突检测会触发重传。 5. **虚拟局域网（VLAN）**：以太网支持VLAN，可以将物理网络划分为逻辑上的独立网络，提高管理和安全性。 6. **交换机**：以太网交换机取代了传统的共享介质，提供了全双工通信和更高的带宽，减少了冲突。 7. **IEEE 802.3标准**：这是以太网的正式标准，由电气和电子工程师协会（IEEE）制定，涵盖了以太网的物理层和数据链路层的MAC子层。 8. **以太网帧大小**：最小帧大小为64字节，最大为1518字节，这包括帧头和FCS。 9. **流量控制**：以太网协议支持流量控制，如PAUSE帧机制，以防止接收端因数据过快而无法处理。 10. **QoS（服务质量）**：通过优先级标记和队列管理，以太网可以提供不同级别的服务质量，确保关键应用的数据传输不受低优先级流量的影响。 中文版RFC文档可能包含了上述各个方面的详细信息，对于想要开发底层以太网项目、嵌入式以太网项目或深入研究以太网架构的人员来说，是非常宝贵的资源。这些文档不仅解释了协议的原理，还可能包含具体的实现细节、兼容性考虑和历史背景，有助于开发者理解并正确地应用以太网技术。

含有RFC所有文档，而且还是中文的！！！！！！！！！！！！！！！！！！

rfc中文翻译完整版打包 请使用UltraEdit或notepad++等打开，否则会出现换行错误(\n\r) 组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划完整打包 E-mail：ouyang@china-pub.com 完整网页版： http://www.net130.com/netbass/RFCs/1to100.htm http://www.net130.com/netbass/RFCs/101to700.htm http://www.net130.com/netbass/RFCs/701to1000.htm http://www.net130.com/netbass/RFCs/1001to1500.htm http://www.net130.com/netbass/RFCs/2001to2500.htm http://www.net130.com/netbass/RFCs/1501to2000.htm http://www.net130.com/netbass/RFCs/2501to3000.htm http://www.net130.com/netbass/RFCs/3001to3039.htm

RFC规范的中文文档，里面有大部分的规范，适合需要的人士。

SMTP协议的标准文档，IETF的RFC中文版

rfc中文文档.zip 从oss.org.cn上爬下来的，一共有四百多个文档

包含了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获取更多的关于对包头进行压缩的基本动机和通用原理。

MD5 报文摘要算法 rfc中文译文.doc

算是很全的RFC了，比看英文省事多了，希望对你有帮助