RFC793翻译文档
RFC791(ip协议)中文文档
+------+ +-----+ +-----+ +-----+
||
|
|
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
|
|
|
+--------------------------+----+
| Internet Protocol & ICMP |
3. 规范 ................................................... 11
3.1 Internet 头部格式 ....................................... 11 3.2 讨论 .................................................. 23
1.4 操作(operation) internet 协议执行两个基本功能:寻址(addressing)和分片(fragmentation).
internet 模块使用在 internet 头部中携带的地址来给目的地址传送 internet 数据报.传输路径的选择被称作选路(routing).
internet 模块使用 internet 头部中的域来分片和重组 internet 数据报,这在通 过"小包"网络传输的情况下是必要的.
词汇............................................................ 41
外文翻译--拥塞控制中的算法
外文翻译--拥塞控制中的算法译文2 The Algorithm of Congestion Control 1.Tahoe TCPModern TCP implementations contain a number of algorithms aimed at controlling network congestion while maintaining good user throughput. Early TCP implementations followed a go-back-n.model using cumulative positive acknowledgment and requiring a retransmit timer expiration to re-send data lost during transport. These TCPs did little to minimize network congestion.The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations. The new algorithms include Slow-Start, Congestion Avoidance, and Fast Retransmit. The refinements include a modification to the round-trip time estimator used to set retransmission timeout values. All modifications have been described elsewhere.The Fast Retransmit algorithm is of special interest in this paper because it is modified subsequent versions of TCP. With Fast Retransmit, after receiving a small number of duplicate acknowledgments for the same TCP segment (dup ACKs), the data sender infers that a packet has been lost and retransmits the packet without waiting for a retransmission timer to expire, leading to higher channel utilization and connection throughput.2.Reno TCPThe Reno TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operation to include Fast Recovery. The new algorithm prevents the communication path (“pipe”) from going empty after Fast Retransmit, thereby avoiding the need to Slow-Start to refill it after a single packet loss. Fast Recovery operates by assuming each dup ACK received represents a single packet having left the pipe. Thus, during Fast Recovery the TCP sender is able to make intelligent estimates of the amount of outstanding data.In Reno, the sender's usable window becomes other gateways that fail tomonitor the average queue size) until the number of dup ACKs reaches tcprexmtthresh, and thereafter tracks the number of duplicate ACKs. Thus, during Fast Recovery the sender “inflate” its window by the number of dup ACKs it has received, according to the observation that each dup ACK indicates some packet has been removed from the network and is now cached at the receiver. After entering Fast Recovery and retransmitting a single packet, the sender effectively waits until half a window of dup ACKs have been received, and then sends a new packet for each additional dup ACK that is received.3.New-Reno TCPWe include New-Reno TCP in this paper to show how a simple change to TCP makes it possible to avoid some of the performance problems of Reno TCP without the addition of SACK. At the same time, we use New-Reno TCP to explore the fundamental limitations of TCP performance in the absence of SACK.The New-Reno TCP in this paper includes a small change to the Reno algorithm at the sender that eliminates Reno's wait for a retransmit timer when multiple packets are lost from a window. The change concerns the sender's behavior during Fast Recovery when a partial ACK is received that acknowledges some but not all of the packets that were out-standing at the start of that Fast Recovery period. In Reno, partial ACKs take TCP out of Fast Recovery by “deflating” the usa ble window back to the size of the congestion window. In New-Reno, partial ACKs do not take TCP out of Fast Recovery. Instead, partial ACKs received during Fast Recovery are treated as an indication that the packet immediately following the acknowledged packet in the sequence space has been lost, and should be retransmitted. Thus, when multiple packets are lost from a single window of data, New-Reno can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the lost packets from that window have been retransmitted. New-Reno remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged.The implementations of New-Reno and SACK TCP in our simulator also use a “maxburst” parameter. In our SACK TCP implementation, the “maxburst” parameter limits to four the number of packets that can be sent in response to a single incoming ACK, even if the sender's congestion window would allow more packets to be sent. In New-Reno, the “maxburst” parameter is set to four packets outside of Fast Recovery, and to two packets during Fast Recovery, to more closely reproduce the behavior of Reno TCP during Fast Recovery. The “maxburst” parameter is really only needed for the first w indow of packets that are sent after leaving Fast Recovery. If the sender had been prevented by the receiver's advertised window from sending packets during Fast Recovery, then, without “maxburst” , it is possible for the sender to send a large burst of packets upon exiting Fast Recovery. This applies to Reno and New-Reno TCP, and to a lesser extent, to SACK TCP. In Tahoe TCP the Slow-Start algorithm prevents bursts after recovering from a packet loss. The bursts of packets upon exiting Fast Recovery with New-Reno TCP are illustrated in Section 6 in the simulations with three and four packet drops. Bursts of packets upon exiting Fast Recovery with Reno TCP are illustrated in.4.SACK TCPThe SACK option follows the format in [MMFR96]. From [MMFR96], the SACK option field contains a number of SACK blocks, where each SACK block reports a non-contiguous set of data that has been received and queued. The first block in a SACK option is required to report the data receiver's most recently received segment, and the additional SACK blocks repeat the most recently reported SACK blocks [MMFR96]. In these simulations each SACK option is assumed to have room for three SACK blocks. When the SACK option is used with the Timestamp option specified for TCP Extensions for High Performance, then the SACK option has room for only three SACK blocks [MMFR96]. If the SACK option were to be used with both the Timestamp option and with T/TCP (TCP Extensions for Transactions), the TCP option space would have room for only two SACK blocks.The 1990 “Sack” TCP implementation on our previous simulator is from Steven McCanne and Sally Floyd, and does not conform to the formats in [MMFR96]. The new “Sack1”implementation contains major contributions from Kevin Fall, Jamshid Mahdavi, and Matt Mathis.The congestion control algorithms implemented in our SACK TCP are a conservative extension of Reno's congestion control, in that they use the same algorithms for increasing and decreasing the congestion window, The SACK TCP implementation in thi s paper, called “Sack1”in our simulator, is also discussed in. and make minimal changes to the other congestion con-trol algorithms. Adding SACK to TCP does not change the basic underlying congestion control algorithms. The SACK TCP implementation preserves the properties of Tahoe and Reno TCP of being robust in the presence of out-of-order packets, and uses retransmit timeouts as the recovery method of last resort. The main difference between the SACK TCP implementation and the Reno TCP implementation is in the behavior when multiple packets are dropped from one window of data.拥塞控制中的算法1.Tahoe TCPTCP Tahoe指的是1988年加入Van Jacobson提出的慢启动、拥塞避免和快速重传算法之后的4.3BSD或类似的TCP实现版本。
序列号算法——精选推荐
序列号算法(RFC1982——Serial Number Arithmetic)本备忘录状态本文档描述了一个用于Internet社团的Internet标准跟踪协议,希望得到有关进一步改进的讨论及建议。
有关本协议的标准状态及状态,请参照“Internet正式协议标准”(STD1)的当前版本。
本备忘录的发布不受任何限制。
摘要本备忘录定义了用于DNS的序列号算法。
域名系统长期依赖于序列号算法,尽管序列号算法已经得到了广泛地理解,但它是一个从未被真正定义过的概念,当然在IETF的文档中也一样。
本备忘录提供这份被遗忘的定义,它将用于更新RFC1034和RFC1035两份文档。
1.介绍在RFC1035中定义SOA资源档案的序列号领域如下:序列号在存储区中原份拷贝的32位无符号数码。
传送拷贝时保留这个数据。
这个数据被封装并通过空间序列算法来进行比较。
当对副服务器存储区连接程序进行定义时,RFC1034使用相同的术语。
但是“空间序列算法”这个术语不仅没有在RFC1034或RFC1035中进行定义,也没有在它们的参考文献中提供更多的信息。
这个术语似乎一直试图在TCP序列号[RFC793]中指定算法并在[IEN-74]中进行定义。
不幸的是,在[IEN-74]中定义的这个算法并不适合DNS的需要,因为它没有定义通用的比较运算符。
为了避免在这个单一领域中出现更多的问题,这份文件将对这个领域及相关可能的操作进行定义。
这份定义仅仅是试图澄清RFC1034和RFC1035中的有关意图而且将主要遵循当前已经生效的声明。
然而,某些旧的、淘汰的声明将序列号看成是一个简单的无符号整数,并不试图实现任何形式的“空间序列算法”。
虽然它们已经被解释过,但却忽略了数据封装的要求。
只有放弃这些声明,否则用它们什么都干不成。
2.序列号算法序列号是由非负整数组成的,它是所有整数列的一个有限子集。
用于这个目的的每个子集中最小的整数是零,最大的总是比2的乘方小1。
英文翻译基于数据融合的网络连接故障检测
基于数据融合的网络连接故障检测摘要:为了及时发现网络连接故障,以及关机和网络连接之间的区别故障,本文提出了一种基于数据融合技术的建模网络连接故障检测.根据本模型,我们设计了一个基于网络连接故障检测工具(NCFDT)的指纹考勤系统。
假设打开或关闭它后,它的用户拥有对这台电脑刷指纹的权利,那么NCFDT将增加它的IP到扫描列表,它的扫描列表的IP地址会在关机后清除。
该NCFDT采用数据融合技术来检测机器的连接是否良好。
如果检测到连接故障,一个SMS报警信号将会发送到管理员,以便管理员可以快速的解决。
实验结果表明,在局域网中该模型能有效和及时的检测到任何连接故障,并且也能发送警报短信给管理员,监控主机(主机A)也可以连接到该局域网中。
此外,我们提高的心跳系统可以有效的监控主机A 的网络状态。
关键词:网络故障;网络连接故障;短信报警;定时关机;心跳系统1 引言如今,在我们的工作和学习中受欢迎的网络正发挥着越来越重要的作用,并且这种作用正在补款的攀升。
然而,网络的设计是有缺陷的,并且无法保证网络的无故障运行。
因此如何快速的检测网络的故障和效率是有非常重要的意义。
网络连接故障是网络中最常见的故障发生最频繁的类型。
有各种各样的方法可以检测一台机器是否在线。
你可以利用现有的工具进行检测,例如简单的平指令,功能更强大的nmap指令等。
但是区分关机脱机之间的方法而造成网络故障下线时罕见的。
为了及时检测上网冲浪的故障,本文提出了区分关机和网络连接故障的新方法。
在C语言编程在Ubuntu系统的指纹考勤系统(NCFDT)中,我们实现设计了一个基于使用函数库来检测网络连接故障的工具。
该NCFDT采用三种方式来扫描计算机是否启动,并且能准确分析被扫描主机的网络连接状态。
此外,检测到网络故障时,该NCDFT会通过发送报警短信息通知管理员。
该NCFDT部署在管理机主机A中。
此外,辅助管理主机主机B的网络状态时稳定的部分,主机A会在每个固定的时间间隔发送给主机B一个心跳信号,一显示是否稳定。
RFC793中文
计算机通信网络的宿主主机中的进程对间的可靠进程间通讯。在TCP层之下,
很少考虑到通信协议的可靠性。TCP假定它可以从底层协议获得一个简单的、
潜在的不可靠数据报。原理上,TCP必须能够在一个从有线连接到包交换或者
回路交换网络的比较大范围的通讯系统上工作。TCP基于Cerf和Kahn在[1]中
Figure 1
1.2范围(Scope)
TCP用来在多网络环境下提供一个可靠的进程到进程通讯服务。TCP用来作为
在多网络条件下的通用的主机到主机协议。
1.3关于这个文档
本文档提出了任何TCP实现所要求的行为的规范,包括同高层协议的交互以及同
隶属于众所皆知的socket被证明是有用的。这些服务就可以通过已知的地址获取到。
建立和学习其它进程的端口地址可能包括更加动态的机制。
连接(Connections)
上面描述的可靠性和流量控制机制要求所有的TCPs为每个数据流发起和维护某些状态
信息。这些信息的结合体,包括sockets,系列号,和窗口大小,被称为一个连接。每个
为了允许在一个单独的主机里多个进程同时使用TCP通信机制,TCP提供了一套地址和
端口。从internet通信层同网络和宿主地址连接,这形成了一个socket。一对socket标识
了一个连接。也就是说,一个socket可能同时被使用在多个连接中。
绑定端口到进程被每个主机单独处理。但是,将常用的进程(如“logger”或者时间服务)
这些网络,以及提供可用的支持大量应用程序的标准进程间通信协议是必要的。
预料到该标准的需要,国防研究和工程副部长宣告了这里描述的TCP协议,来
作为DoD范围的互联协议标准的基础。
FTP协议RFC中英文文文档
FTP协议概念:FTP 是 TCP/IP 协议组中的协议之一,是英文File Transfer Protocol的缩写。
该协议是Internet文件传送的基础,它由一系列规格说明文档组成,目标是提高文件的共享性,提供非直接使用远程计算机,使存储介质对用户透明和可靠高效地传送数据。
简单的说,FTP就是完成两台计算机之间的拷贝,从远程计算机拷贝文件至自己的计算机上,称之为“下载(download)”文件。
若将文件从自己计算机中拷贝至远程计算机上,则称之为“上载(upload)”文件。
在TCP/IP协议中,FTP标准命令TCP端口号为21,Port方式数据端口为20。
FTP 的目标是:1)促进程序/数据文件的共享;2)鼓励(通过程序)使用远程计算机3)使用户不必面对不同主机上不同文件系统的差异;4)对数据进行高效可靠的传输。
FTP 尽管可以直接在终端上应用,但它主要被设计通过程序来使用。
数据由发送端主机存储设备传输到接收端主机的存储设备上。
由于两个系统的数据存储形式不同,经常需要将数据转换形式。
例如,NVT-ASCII 在不同的系统中有不同的存储表示。
DEC TOP-20 一般用5 个7 位的ASCII 字符存储NVT-ASCII,左对齐成36 位的字。
IBMMainframe 用8 位EBCDIC 编码存储NVT-ASCII。
Multics 将NVT-ASCII 存储成4 个9 位字符组成的字。
当在不同的系统中传输字符时理应将其转换成标准的NVT-ASCII 表示。
发送和接收端则应相应地在标准表示法和内部表示法间转换。
当传输二进制数据时表示法的另一个问题就是不同主机有不同的字长度。
并不总是明确发送端怎样发送数据以及接收端怎样接收数据。
例如,当从一个32 位字长的系统传输32 位字节到一个36 位字长的系统时,应该(为了高效和实用)在后一个系统中将32 位字节在36 位字中右对齐。
无论哪种情况,用户都应该可以选择数据表示形式和传输功能。
中文RFC文档阅读 701-1000
中文RFC文档阅读701-1000RFC763 角色邮箱RFC775_面向目录的FTP 命令RFC779_Telnet发送-位置选项RFC792_Internet 控制信息协议RFC797 位图文件格式RFC821_简单邮件传输协议RFC826_以太网地址转换协议或转换网络协议地址RFC827_Exterior 网关协议(EGP)RFC854_Telnet协议说明书RFC855_Telnet选项说明书RFC856_Telnet二进制传输RFC857_Telnet回声选项RFC858_Telnet抑制前进选项RFC859_Telnet状态选项RFC860_Telnet定时标记选项RFC861_Telnet扩展选项列表选项RFC862_回声协议RFC863 废除协议RFC864 字符产生协议RFC865 白天协议的引用RFC866 激活用户RFC867 白天协议RFC868_时间协议RFC872_局域网上的TCP协议RFC877_IP 数据包通过公共数据网络的传输标准RFC888_STUB Exterior Gateway ProtocolRFC890_外部网关协议执行表RFC894_IP 数据包通过以太网网络传输标准RFC895_IP 数据包通过试验性以太网网络的传输标准RFC896_在IPTCP internet网络中的拥塞控制RFC903_反向地址转换协议RFC911 BERKELEY UNIX 4.2下的EGP网关RFC917_因特网子网RFC918 邮局协议RFC925_多局域网地址解决RFC930_Telnet终端类型选项RFC932_子网地址分配方案RFC937_邮局协议( 版本2)RFC948_IP 数据包通过IEEE 802.3 网络传输的两种方法RFC949_FTP 未公开的独特命令RFC951_引导协议(BOOTP)RFC955_朝向一个处理过程应用的传输服务RFC962_TCP-4 的最初RFC968 “这是开动前的黑暗”RFC974_邮件路由与域名系统RFC975_自治联邦RFC976 UUCP 邮件互换格式标准RFC985 Internet 网关要求- 起草RFC988 主机扩展用于IP多点传送。
学习网络常用的RFC文档的名称
学习网络常用的RFC文档的名称双语RFC --RFC中英文对照版rfc1050中文版-远程过程调用协议规范rfc1055中文版-在串行线路上传输IP数据报的非标准协议rfc1057中文版-RFC:远程过程调用协议说明第二版rfc1058中文版-路由信息协议(Routing Information Protocol)rfc1073中文版-RFC1073 Telnet窗口尺寸选项rfc1075中文版-远距离矢量多播选路协议rfc1088中文版-在NetBIOS网络上传输IP数据报的标准rfc1090中文版-SMTP在X.25上rfc1091中文版-TELNET终端类型选项rfc1094中文版-RFC1094 网络文件系统协议rfc1096中文版-Telnet X显示定位选项rfc1097中文版-Telnet潜意识-信息选项rfc1112中文版-主机扩展用于IP多点传送rfc1113中文版-Internet电子邮件保密增强:Part1-消息编码和鉴别过程rfc1132中文版-802.2分组在IPX网络上传输的标准rfc1144中文版-低速串行链路上的TCP/IP头部压缩rfc1155中文版-基于TCP/IP网络的管理结构和标记rfc1191中文版-RFC1191 路径MTU发现rfc1332中文版-RFC1332 端对端协议网间协议控制协议(IPCP)rfc1333中文版-PPP 链路质量监控rfc1334中文版-PPP 身份验证协议rfc1387中文版-RIP(版本2)协议分析rfc1388中文版-RIP协议版本2rfc1433中文版-直接ARPrfc1445中文版-SNMPv2的管理模型rfc1582中文版-扩展RIP以支持按需链路rfc1618中文版-ISDN上的PPP(点对点)协议rfc1661中文版-RFC1661 PPP协议rfc1723中文版-路由信息协议(版本2)rfc1738中文版-统一资源定位器(URL)rfc1769中文版-简单网络时间协议( SNTP)rfc1771中文版-边界网关协议版本4(BGP-4)rfc1827中文版-IP封装安全载荷(ESP)rfc1883中文版-Internet协议,版本6(IPv6)说明书rfc1939中文版-POP3协议rfc1945中文版-超文本传输协议 -- HTTP/1.0rfc1994中文版-PPP挑战握手认证协议(CHAP)rfc1997中文版-RFC1997 BGP团体属性rfc2002中文版-IP移动性支持rfc204中文版-利用报路rfc2105中文版-Cisco 系统的标签交换体系结构纵览rfc2281中文版-Cisco热备份路由协议()rfc2283中文版-BGP-4的多协议扩展rfc2326中文版-实时流协议(RTSP)rfc2328中文版-OSPF版本2rfc2516中文版-在以太网上传输PPP的方法(PPPoE)rfc2526中文版-IPv6保留的子网任意传送地址rfc2547中文版-BGP/MPLS VPNsrfc2616中文版-超文本传输协议——HTTP/1.1rfc2702中文版-基于MPLS的流量工程要求rfc2706中文版-RFC2706—电子商务域名标准rfc2756中文版-超文本缓存协议(HTCP/0.0)rfc2764中文版-IP VPN的框架体系rfc2773中文版-使用KEA和SKIPJACK加密rfc2774中文版-HTTP扩展框架rfc2781中文版-UTF-16, 一种ISO 10646的编码方式rfc2784中文版-通用路由封装rfc2793中文版-用于文本交谈的RTP负载rfc2796中文版-BGP路由反射rfc2917中文版-核心 MPLSIP VPN 体系结构rfc2918中文版-BGP-4(边界网关协议)的路由刷新功能rfc2923中文版-TCP的路径MTU发现问题rfc3003中文版-Audio/mpeg 媒体类型rfc3005中文版-IETF 讨论列表许可证rfc3007中文版-安全的域名系统动态更新rfc3018中文版-统一内存空间协议规范rfc3022中文版-传统IP网络地址转换(传统NAT)rfc3032中文版-RFC3032 MPLS标记栈编码rfc3033中文版-用于Internet协议的信息域和协议标识符在Q.2941类属标识符和Q.2957 User-to-user信令中的分配rfc3034中文版-标签转换在帧中继网络说明书中的使用rfc3037中文版-RFC3037 标记分配协议的适用范围(RFC3037 LDP Applicability)rfc3058中文版-IDEA加密算法在CMS上的使用rfc3059中文版-服务定位协议的属性列表扩展rfc3061中文版-对象标识符的一种URN姓名空间rfc3062中文版-LDAP口令修改扩展操作rfc3063中文版-MPLS(多协议标签交换)环路预防机制rfc3066中文版-语言鉴定标签rfc3067中文版-事件对象描述和转换格式要求rfc3069中文版-VLAN聚合实现IP地址有效分配rfc3070中文版-基于帧中继的第二层隧道协议rfc3072中文版-结构化数据交换格式rfc3074中文版-DHCP 负载平衡算法rfc3078中文版-RFC3078微软点到点加密(MPPE)协议rfc3081中文版-将区块扩展交换协议(BEEP)核心映射到传输控制协议(TCP)rfc3083中文版-遵循DOCSIS的Cable Modem和CMTS的PBI 的管理信息数据库rfc3085中文版-新闻型标记语言(NewsML)资源的URN名字空间rfc3090中文版-域名系统在区域状况下的安全扩展声明rfc3091中文版-Pi数字生成协议rfc3093中文版-防火墙增强协议rfc3550中文版-RTP:实时应用程序传输协议rfc457中文版-TIPUGrfc697中文版-FTP的CWD命令rfc698中文版-TELNET扩展ASCII选项rfc775中文版-面向目录的 FTP 命令rfc779中文版-TELNET的SEND-LOCATION选项rfc792中文版-RFC792- Internet控制信息协议(ICMP)rfc821中文版-RFC821 简单邮件传输协议(SMTP)rfc826中文版-以太网地址转换协议或转换网络协议地址为48比特以太网地址用于在以太网硬件上传输rfc854中文版-TELNET协议规范rfc855中文版-TELNET选项规范rfc856中文版-RFC856 TELNET二进制传输rfc857中文版-RFC 857 TELNET ECHO选项rfc858中文版-RFC 858 TELNET SUPPRESS GO AHEAD选项rfc859中文版-RFC 859 TELNET的STATUS选项rfc860中文版-RFC 860 TELNET TIMING MARK选项rfc861中文版-RFC 861 TELNET扩展选项-LISTrfc862中文版-RFC 862 Echo 协议rfc868中文版-RFC868 时间协议rfc894中文版-IP 数据包通过以太网网络传输标准rfc903中文版-反向地址转换协议rfc930中文版-Telnet终端类型选项(RFC930——T elnet Terminal Type Option)rfc932中文版-子网地址分配方案rfc937中文版-邮局协议 (版本2)rfc948中文版-IP数据报通过IEEE802.3网络传输的两种方法rfc949中文版-FTP 未公开的独特命令rfc951中文版-引导协议(BOOTP)rfc962中文版-TCP-4 的最初rfc974中文版-邮件路由与域名系统rfc975中文版-自治联邦。
RFC792IPMC协议中文版
VRF就是指VPN,即VPN路由转发实例 vrf是这个意思组织:中国互动出版网(/)RFC文档中文翻译计划(/compters/emook/aboutemook.htm)E-mail:译者:顾国飞(ggfei )译文发布时间:2001-3-30版权:本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。
Network Working Group J. Postel Request for Comments: 792 ISISeptember 1981 Updates: RFCs 777, 760Updates: IENs 109, 128RFC792- Internet控制信息协议(ICMP)(RFC792 INTERNET CONTROL MESSAGE PROTOCOL)目录1.介绍 22.消息格式 23.目的不可达信息 34.超时信息 35.参数问题消息 46.源拥塞消息 57.重定向消息 68.回送或回送响应消息79.时间戳和时间戳响应消息810.消息类型总结 911.参考资料101.介绍在被称为Catenet的系统中,IP协议被用作主机到主机的数据报服务。
网络连接设备称为网关。
这些网关通过网关到网关协议(GGP)相互交换用于控制的信息。
通常,网关或目的主机将和源主机通信,例如,为报告在数据报过程中的错误。
为了这个目的才使用了ICMP,它使用IP做为底层支持,好象它是一个高层协议,而实际上它是IP的一部分,每一种IP模块必须实现ICMP。
ICMP消息在以下几种情况下发送:当数据报不能到达目的地时,当网关的已经失去缓存功能,当网关能够引导主机在更短路由上发送。
IP并非设计为绝对可靠,这个协议的目的是为了当网络出现问题的时候返回控制信息,而不是使IP协议变得绝对可靠,并不保证数据报或控制信息能够返回。
一些数据报仍将在没有任何报告的情况下丢失。
上层协议必须使用自己的差错控制程序来判断通信是否正确。
MAX793T中文资料
Voltage Can Exceed VCC o On-Board Gating of Chip-Enable Signals—7ns
Max Propagation Delay
元器件交易网
19-0366; Rev 1; 1/96
MAX793/MAX794/MAX795
3.0V/3.3V Adjustable Microprocessor Supervisory Circuits
_______________General Description
MAX793
WDO
CE IN
MR
WDI
PFO
LOWLINE
ADDRESS DECODER
VCC
VCC A0-A15
I/O NMI
µP
PFI
RESET
BATT OK
GND
RESET
________________________________________________________________ Maxim Integrated Products 1
Output Current VOUT................................................................................200mA All Other Outputs ..............................................................20mA
Pin Configurations appear at end of data sheet.
rfc规范
rfc规范RFC(Request for Comments)是Internet Engineering Task Force(IETF)发布的一系列文档,用于描述互联网协议、标准、方法和相关问题。
这些文档是由技术专家和社区成员合作编写和审查的。
RFC规范主要包含以下几个方面:1. 协议描述:RFC规范详细描述了协议的功能、结构和通信流程。
例如,RFC 793描述了TCP协议,RFC 2616描述了HTTP协议。
2. 标准化过程:RFC规范提供了标准化过程的指南和规则。
它们定义了制定、审查和发布新的互联网标准的程序。
3. 网络安全:RFC规范涵盖了互联网安全的各个方面,例如认证、授权、加密和网络攻击防御。
4. 网络管理和运营:RFC规范提供了网络管理和运营的最佳实践指南,包括IP地址分配、路由选择、流量管理和网络拓扑设计等。
5. 互联网发展和新技术:RFC规范跟踪和记录了互联网发展的历程,并为新技术的标准化提供支持。
例如,RFC 2460定义了IPv6协议。
6. 协议扩展和修改:RFC规范提供了对现有协议进行扩展和修改的方法和原则。
这使得网络协议能够不断适应新的需求和技术发展。
RFC规范的编写和更新是一个公开的过程,任何人都可以参与和发表评论。
它们经过严格的审核和审查,最终成为全球互联网的标准参考。
RFC规范的重要性在于它们为互联网的发展提供了一个共享的知识库和协作平台。
通过RFC文档,技术专家能够共同制定和改进互联网的基础协议,使得网络能够更加稳定、安全和高效地运行。
总之,RFC规范是互联网技术发展的重要组成部分,它们定义了互联网的基础协议和标准,为网络的设计、实施和管理提供了指导,推动了互联网的持续发展和进步。
rfc文档的类别
rfc文档的类别1. RFC 791 - 网际协议网际协议(Internet Protocol,简称IP)是一种在计算机网络中广泛使用的网络协议,用于将数据包从源地址传递到目标地址。
IP协议定义了数据包的格式、路由选择和错误处理等方面的规范。
RFC 791是一篇关于IP协议的RFC文档。
在RFC 791中,首先介绍了IP协议的基本概念和目标。
IP协议的主要目标是提供一种无连接、尽力而为的数据传输服务,它将数据包分割成一系列的片段,并通过网络逐个传输。
IP协议还定义了数据包的格式,包括首部和数据部分。
首部包含了源地址、目标地址、生存时间等信息,用于路由选择和错误处理。
数据部分则是传输的实际数据。
RFC 791还详细描述了IP协议的工作流程。
当发送方要发送数据时,它会将数据分割成多个数据包,并为每个数据包添加IP首部。
然后,发送方将数据包发送到网络中的下一跳路由器。
路由器收到数据包后,根据目标地址选择下一跳路由器,并将数据包转发给它。
这样,数据包就会通过一系列的路由器传递,最终到达目标地址。
此外,RFC 791还介绍了IP协议的一些特性和机制。
例如,IP 协议支持不同的服务质量,可以根据应用的需求选择不同的服务类型。
IP协议还支持分片和重组机制,当数据包太大无法一次传输时,可以将其分割成多个片段,并在目标地址处重新组装。
此外,IP协议还定义了一些错误处理机制,如时间超时、差错报告等。
总体而言,RFC 791对IP协议进行了全面而详细的描述,明确了其基本概念、工作流程和特性。
它为网络中的数据传输提供了重要的基础,并成为了互联网的核心协议之一。
2. RFC 793 - 传输控制协议传输控制协议(Transmission Control Protocol,简称TCP)是一种面向连接的、可靠的传输协议,用于在计算机网络中传输数据。
RFC 793是一篇关于TCP协议的RFC文档。
在RFC 793中,首先介绍了TCP协议的基本概念和目标。
TCP协议rfc793
图1
本文大部分是描写 TCP 实现的内容,它将与上层协议共同驻住在主机计算机中。某些计 算机系统将通过掩盖 TCP 和网际协议层及网络特定软件的前端计算机连接到网络。TCP 规范 描述对上层协议的接口,它似乎是可实现的,即使在前端情况下,只要实现一个适当的主机 与前端协议。
1.2 范围
TCP 打算提供在多网络环境中的可靠进程对进程通迅服务。TCP 打算成为多个网络中的 通用主机对主机协议。
TCP 和下层协议间的接口根本没有规定,除了假设存在某种机制使 2 层间相互可以异步
标准
5
RFC793
传输控制协议
1981 年 9 月
传递信息。通常,人们希望下层协议规定该接口。TCP 被设计来工作在非常普通的互连网络 环境中。本文通篇假设下层协议是网际协议[2]。
1.5 操作
如上所述,TCP 的主要用途是在进程对间提供可靠、安全的逻辑线路或连接服务。为在 缺少可靠性的互联网通迅系统上提供这种服务要求如下方面的机构:
3 功能性规范 ................................................................12
3.1 头部格式 ............................................................12 3.2 术语 ................................................................16 3.3 序列号 ..............................................................19 3.4 建立连接 ............................................................23 3.5 关闭连接 ............................................................28 3.6 优先级和安全性 ......................................................30 3.7 数据通迅 ............................................................31 3.8 接口 ................................................................33 3.9 事件处理 ............................................................38
移动网络专用术语
General Purpose Input Output (通用输入/输出)简称为GPIO,或总线扩展器,利用工业标准I2C、SMBus或SPI接口简化了I/O口的扩展。
当微控制器或芯片组没有足够的I/O端口,或当系统需要采用远端串行通信或控制时,GPIO产品能够提供额外的控制和监视功能。
TCP:Transmission Control Protocol 传输控制协议TCP是一种面向连接(连接导向)的、可靠的、基于字节流的运输层(Transport layer)通信协议,由IETF 的RFC 793说明(specified)。
在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能,UDP是同一层内另一个重要的传输协议。
PPPoE是point-to-point protocol over ethernet的简称,可以使以太网的主机通过一个简单的桥接设备连到一个远端的接入集中器上。
通过pppoe协议,远端接入设备能够实现对每个接入用户的控制和计费。
PPPoE协议发表于RFC 2516[1]。
DDNS(Dynamic Domain Name Server)是动态域名服务的缩写!DDNS是将用户的动态IP地址映射到一个固定的域名解析服务上,用户每次连接网络的时候客户端程序就会通过信息传递把该主机的动态IP地址传送给位于服务商主机上的服务器程序,服务器程序负责提供DNS服务并实现动态域名解析。
BNC接头,是一种用于同轴电缆的连接器,全称是Bayonet Nut Connector(刺刀螺母连接器,这个名称形象地描述了这种接头外形),又称为British Naval Connector(英国海军连接器,可能是英国海军最早使用这种接头)或Bayonet Neill Conselman(Neill Conselman刺刀,这种接头是一个名叫Neill Conselman直译为“尼尔-康塞曼”的人发明的)是一种很常见的RF端子同轴电缆终结器。
RFC792------IPMC协议中文版
·说明:
网关在下面情况下发送重定向消息。网关(G1)从网关相连的网络上接收到数据报,它检查路由表获得下一个网关(G2)的地址(X)。如果G2和指定的接收主机在同一网络上,重定向消息发出,此消息建议发送主机直接将数据报发向网关G2,因为这更近,同时网关G1向前继续发送此数据报。
另外一种情况是当数据报必须被分段传送,而"不可分段"位打开,在这种情况下,网关必须抛弃此数据报,并向发送源数据的主机发送不可达信息。
代码0,1,4和5由网关发送,而代码2和3由主机发送。
4.超时信息
图2
IP域:
目的地址:从源数据报数据中得到。
ICMP域:
·类型:11
·代码:
0 = 传送超时;
1 = 分段级装超时。
2 = 重定向网络和服务类型的数据报;
3 = 重定向网络和主机类型的数据报。
·校验码:
16位数据(从ICMP类型开始)的反码和再取反而得。为计算校验码,校验码域应该为零。这些零在以后会被校验码取代。
·网关Internet地址:
应该发送网关地址(其在源数据报数据的internet目的网络域中指定)。
·Internet包头+64位源数据报数据:
代码0可能会从主机或网关接收到。
信息请求或信息响应消息
图8
IP域:
地址:
信息请求消息的源地址是信息响应消息的目的地址。若要形成一个信息响应消息,应该将源和目的地址交换,将类型代码更改为16,重新计算机校验码。
ICMP域:
·类型:
15代表信息请求消息;
rfc793.txt- TRANSMISSION CONTROL PROTOCOL_CHN
TRANSMISSION CONTROL PROTOCOLDARPA INTERNET PROGRAMPROTOCOL SPECIFICATION1.引言传输控制协议(TCP)旨在用作高级应用分组交换计算机中主机之间的可靠主机到主机协议通信网络以及这些网络的互连系统中。
本文档描述了传输控制协议,实现它的程序以及与需要其服务的程序或用户的接口所要执行的功能。
1.1动机计算机通信系统日益重要在军事,政府和平民环境中的作用。
本文件主要关注军事计算机通信需求,特别是在通信不稳定和存在拥塞情况下的可用性方面的稳健性,但这些问题中的许多问题也发生在民间和政府部门。
随着战略和战术计算机通信网络的开发和部署,必须提供相互连接的手段,并提供标准的进程间通信协议,以支持广泛的应用。
预计需要这样的标准,副国防研究和工程副国防部长已经宣布此处描述的传输控制协议(TCP)成为国防部范围内的进程间通信协议的基础标准化。
TCP是一种面向连接的,端到端的可靠协议适合支持多网络的分层协议应用。
TCP为附属于不同但相互连接的计算机通信网络的主机中的成对进程提供可靠的进程间通信。
关于TCP层以下的通信协议的可靠性,很少有假设。
TCP假定它可以从较底层别的协议获得简单的,可能不可靠的数据报服务。
原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统上运行。
TCP基于Cerf和Kahn在[1]中首次描述的概念。
TCP适用于基本互联网协议[2]之上的分层协议体系结构,该体系结构为TCP发送和接收封装在互联网数据报“信封”中的可变长度的信息段提供了一种方式。
互联网数据报提供了一种解决不同网络中的源和目标TCP的手段。
互联网协议还涉及通过多个网络和互连网关实现传输和传输所需的TCP段的分段或重新组合。
互联网协议还包含有关TCP段的优先级,安全性分类和分段的信息,因此可以在多个网络中端到端传输此信息。
本文档中的大部分内容都是在与主机中的更高级协议共存的TCP实现的上下文中编写的。
(完整版)IP协议-RFC791中文版
(完整版)IP协议-RFC791中文版INTERNET PROTOCOLDARPA INTERNET PROGRAMPROTOCOL SPECIFICATIONSeptember 1981prepared forDefense Advanced Research Projects Agency Information Processing Techniques Office1400 Wilson BoulevardArlington, Virginia 22209byInformation Sciences InstituteUniversity of Southern California4676 Admiralty WayMarina del Rey, California 90291索引前言 (iii)1.介绍------------------- 11.1 ~动机----------------- 11.2 ~范围----------------- 11.3 接口------------------11.4 操作-------------------22. 概述2.1 与其他协议的关系----------------- 92.2 操作模型------------------ 52.3 函数说明----------------- 72.4 ~网关----------------------- 93. 规范3.1 ~网际(Internet)头部格式---------------------- 113.2 讨论----------------- 233.3 接口------------------ 31附录A:例子& 场景附录B:数据传输顺序词汇表--------------------- 41引用---------- --------- 45前言这个文档规定了DoD 标准网际协议。
这个文档基于早期六个版本的ARPA 网际协议规范所以本文的大部分内容来自于他们。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Network Working Group J. Postel Request for Comments: 792 ISISeptember 1981Updates: RFCs 777, 760Updates: IENs 109, 128INTERNET CONTROL MESSAGE PROTOCOLDARPA INTERNET PROGRAMPROTOCOL SPECIFICATION网络工作组J.PostelRFC792科学信息研究所(ISI)1981年9月撰更新:RFCs 777,760更新:IENs 109,128网际消息控制协议(ICMP)DARPA的网络程序(DARPA美国国防部高等研究计划局)协议草案IntroductionThe Internet Protocol (IP) [1] is used for host-to-host datagramservice in a system of interconnected networks called theCatenet [2]. The network connecting devices are called Gateways.These gateways communicate between themselves for control purposesvia a Gateway to Gateway Protocol (GGP) [3,4]. Occasionally agateway or destination host will communicate with a source host, forexample, to report an error in datagram processing. For suchpurposes this protocol, the Internet Control Message Protocol (ICMP),is used. ICMP, uses the basic support of IP as if it were a higherlevel protocol, however, ICMP is actually an integral part of IP, andmust be implemented by every IP module.简介IP协议[1]被用于一个被叫做Catenet[2]的互联网络系统中的点对点数据报(datagram)服务。
网络的连接设备被叫做网关(Gateways)。
这些网关之间通过GGP协议[3,4]进行通信以达到控制的目的。
偶尔一个网关或者目的主机要与源主机进行通信,比如像源主机报告一个处理数据报过程中产生的错误。
为了达到这样的目的,网际消息控制(ICMP)协议被应用。
ICMP以IP协议作为底层支持,看上去就想ICMP 是在 IP协议的上层,但实际上,ICMP是IP协议整体的一部分,而且必须被每个IP模块实现。
ICMP messages are sent in several situations: for example, when adatagram cannot reach its destination, when the gateway does not havethe buffering capacity to forward a datagram, and when the gatewaycan direct the host to send traffic on a shorter route.ICMP消息在一些情况下被发送:1.当一个数据报不能到达目的地时;2.当网关失去缓冲能力时;3.当网关能够引导主机在更短路由上发送时。
The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback aboutproblems in the communication environment, not to make IP reliable.There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still beundelivered without any report of their loss. The higher levelprotocols that use IP must implement their own reliability procedures if reliable communication is required.IP协议并不绝对可靠,控制消息也只是对通信环境的问题反馈而已,不能使IP协议可靠。
而且不能保证一条数据报能够被交付或者一条控制消息被返回。
一些数据报可能仍然在没有任何的丢失报告情况下未被交付。
如果需要可靠通信的话,就要求那些使用IP协议的高层协议自己来实现他们自己的可靠性步骤(reliability procedures)。
The ICMP messages typically report errors in the processing ofdatagrams. To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages. Also ICMPmessages are only sent about errors in handling fragment zero offragemented datagrams. (Fragment zero has the fragment offeset equal zero).ICMP消息一般是用来报告数据报处理过程中的错误的。
为了避免消息无休止的返回(消息递归),对于ICMP消息的错误就不再返回ICMP消息了。
而且ICMP消息只在处理数据报偏移量为0时发送。
Message FormatsICMP messages are sent using the basic IP header. The first octet of the data portion of the datagram is a ICMP type field; the value of this field determines the format of the remaining data. Any fieldlabeled "unused" is reserved for later extensions and must be zerowhen sent, but receivers should not use these fields (except toinclude them in the checksum). Unless otherwise noted under theindividual format descriptions, the values of the internet headerfields are as follows:Version4IHLInternet header length in 32-bit words.Type of ServiceTotal LengthLength of internet header and data in octets.Identification, Flags, Fragment OffsetUsed in fragmentation, see [1].Time to LiveTime to live in seconds; as this field is decremented at eachmachine in which the datagram is processed, the value in thisfield should be at least as great as the number of gateways whichthis datagram will traverse.ProtocolICMP = 1Header ChecksumThe 16 bit one's complement of the one's complement sum of all 16bit words in the header. For computing the checksum, the checksumfield should be zero. This checksum may be replaced in thefuture.Source AddressThe address of the gateway or host that composes the ICMP message.Unless otherwise noted, this can be any of a gateway's addresses.Destination AddressThe address of the gateway or host to which the message should besent.消息格式ICMP消息基于IP报头发送,数据报的数据部分的第一个字节是ICMP类型字段;这个字段的值决定了剩余数据的格式。
任何标示为“unused”的字段为保留以后扩展,并且发送前必须置零,但是接受者不必使用这些字段(除了校验时)。
除非另有个别格式说明,IP头部字段的值如下:version(4bit)4IHLIP报头长度(以32bit为单位)Type of ServiceTotal LengthIP报头和数据总长度(以字节为单位)Identification,Flags,Fragment Offset用于碎片,详看【1】Time to Live存活时间(按秒计) ;这个字段在处理数据报的机器上被减小,这个字段的值应该不小于该数据报要通过的网关数目。
Protocol协议字段,标示封装的数据部分的协议类型,ICMP=1;Header Checksum校验和(计算方法:报头的所有16位二进制数的反码的和的反码)。