﻿<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>

<channel>
	<title>Tcp/ip协议-Ip-网络协议分析-Toad的博客</title>
	<atom:link href="http://tcpip.info-weblog.org/index.php/feed" rel="self" type="application/rss+xml" />
	<link>http://tcpip.info-weblog.org</link>
	<description>Tcp/ip协议-Ip-网络协议分析</description>
	<pubDate>Mon, 31 May 2010 16:43:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>ip协议的作用</title>
		<link>http://tcpip.info-weblog.org/ip-protocol-521</link>
		<comments>http://tcpip.info-weblog.org/ip-protocol-521#comments</comments>
		<pubDate>Mon, 31 May 2010 16:42:14 +0000</pubDate>
		<dc:creator>toadadmin2</dc:creator>
		
		<category><![CDATA[IP协议]]></category>

		<category><![CDATA[IP]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-521</guid>
		<description><![CDATA[ 
大家试想一下，A、B两台电脑。A机在中国，B机在美国，现在A机需发送20个数据包给B机，然而网络上有成千上万的其他电脑和网络终端。A机如何保证这20个数据包准确无误的到达B机？让我们再回想一下“写信”这个行为，只有在信封上抒写正确的目的地址，邮递员才可能把信件正确无误的送到目的地。同样的道理，网络数据包必须有一个目的地址。赋予网络数据包目的地址的这个行为，正是IP协议的作用之一。网络数据包不仅有目的地址，还有源地址，即发送这个数据包的电脑的地址。这个地址有一个专业的术语：IP地址，他的形式如：192.168.0.1，点分十进制的字符串。
IP地址的详细讲解请看《TCP/IP详解 卷1：协议》第一章 1.4节 互联网地址。数据包的地址是有了，那谁来“投递”呢？这还是IP协议的作用。A机向B机发送数据有一个前提，二者之间必须有一条可用的物理链路（通俗不准确的说就是网线）。这里有个现实问题，A机和B机要通信，就要相连，OK，从中国直接牵一条链路到美国。如果，此时A机要跟英国的C机进行通信，又要牵一条专用链路过去，这是一个很简单的逻辑，不可能！成千上网的电脑，那得牵多少专用线路，暂且不说所需的金费，成千上网的链路如何过海？那得多粗一捆？请允许我稍微跑一下题，说下物理层的复用技术。复用技术简单的说，就是在一条物理链路上传输多台网络终端的数据。正是因为复用技术的诞生，“互联网”才可能跟着诞生。既然，成千上万的网络终端是相连的，那么A机的数据包，是如何通过网络正确的传到B机，而不传给其他网络终端呢？这就是IP协议的第二个作用：路由！
所以IP协议有两个作用：
1、写地址（把IP地址写入数据包的IP首部中）
2、投递（路由的过程）
这篇文章只是明确IP协议的作用，IP协议的工作原理将在以后的IP协议分析章节中给出！
相关文章

2009年09月13号 &#8212; RFC821:简单邮件传输协议 (0)
2009年10月14号 &#8212; RFC930:Telnet终端类型选项 (0)
2009年04月27号 &#8212; 链路层-串行线路吞吐量计算 (0)
2009年09月22号 &#8212; RFC861:Telnet扩展选项列表选项 (0)
2009年04月16号 &#8212; HTTP和HTML概述 (0)
2009年04月13号 &#8212; 链路层-已废弃的封装格式：尾部封装 (0)
2009年05月1号 &#8212; 网络层-IP首部 (0)
2009年11月12号 &#8212; RFC1075_远距离矢量多播选路协议 (0)
2009年09月17号 &#8212; RFC856:TELNET二进制传输 (0)
2009年11月5号 &#8212; RFC1057_RPC远程步骤呼叫协议说明书版本 2 (0)

]]></description>
			<content:encoded><![CDATA[<p> </p>
<p>大家试想一下，A、B两台电脑。A机在中国，B机在美国，现在A机需发送20个数据包给B机，然而网络上有成千上万的其他电脑和网络终端。A机如何保证这20个数据包准确无误的到达B机？让我们再回想一下“写信”这个行为，只有在信封上抒写正确的目的地址，邮递员才可能把信件正确无误的送到目的地。同样的道理，网络数据包必须有一个目的地址。赋予网络数据包目的地址的这个行为，正是IP协议的作用之一。网络数据包不仅有目的地址，还有源地址，即发送这个数据包的电脑的地址。这个地址有一个专业的术语：IP地址，他的形式如：192.168.0.1，点分十进制的字符串。</p>
<p>IP地址的详细讲解请看《TCP/IP详解 卷1：协议》第一章 1.4节 互联网地址。数据包的地址是有了，那谁来“投递”呢？这还是IP协议的作用。A机向B机发送数据有一个前提，二者之间必须有一条可用的物理链路（通俗不准确的说就是网线）。这里有个现实问题，A机和B机要通信，就要相连，OK，从中国直接牵一条链路到美国。如果，此时A机要跟英国的C机进行通信，又要牵一条专用链路过去，这是一个很简单的逻辑，不可能！成千上网的电脑，那得牵多少专用线路，暂且不说所需的金费，成千上网的链路如何过海？那得多粗一捆？请允许我稍微跑一下题，说下物理层的复用技术。复用技术简单的说，就是在一条物理链路上传输多台网络终端的数据。正是因为复用技术的诞生，“互联网”才可能跟着诞生。既然，成千上万的网络终端是相连的，那么A机的数据包，是如何通过网络正确的传到B机，而不传给其他网络终端呢？这就是IP协议的第二个作用：路由！</p>
<p>所以IP协议有两个作用：</p>
<p>1、写地址（把IP地址写入数据包的IP首部中）</p>
<p>2、投递（路由的过程）</p>
<p>这篇文章只是明确IP协议的作用，IP协议的工作原理将在以后的IP协议分析章节中给出！<br />
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年02月19号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-150" title="什么是TCP/IP协议">什么是TCP/IP协议 (0)</a></li>
<li>2009年02月26号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-195" title="TCP/IP协议的分层(3)">TCP/IP协议的分层(3) (0)</a></li>
<li>2009年05月10号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-404" title="RFC 894：IP 数据包通过以太网网络传输标准">RFC 894：IP 数据包通过以太网网络传输标准 (0)</a></li>
<li>2009年09月15号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-463" title="RFC854:Telnet协议说明书">RFC854:Telnet协议说明书 (0)</a></li>
<li>2009年10月30号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-492" title="RFC974_邮件路由与域名系统">RFC974_邮件路由与域名系统 (0)</a></li>
<li>2009年04月29号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-363" title="什么是ARP攻击(2)？">什么是ARP攻击(2)？ (0)</a></li>
<li>2009年10月25号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-488" title="RFC949_FTP 未公开的独特命令">RFC949_FTP 未公开的独特命令 (0)</a></li>
<li>2009年04月7号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-233" title="TCP/IP协议的分层(4)">TCP/IP协议的分层(4) (1)</a></li>
<li>2009年11月18号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-507" title="RFC1094_NFS网络文件系统协议说明书">RFC1094_NFS网络文件系统协议说明书 (0)</a></li>
<li>2009年04月18号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-300" title="链路层-PPP：点对点协议（2）">链路层-PPP：点对点协议（2） (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/ip-protocol-521/feed</wfw:commentRss>
		</item>
		<item>
		<title>什么是免费ARP</title>
		<link>http://tcpip.info-weblog.org/protocol-basic-519</link>
		<comments>http://tcpip.info-weblog.org/protocol-basic-519#comments</comments>
		<pubDate>Mon, 17 May 2010 08:10:00 +0000</pubDate>
		<dc:creator>toadadmin2</dc:creator>
		
		<category><![CDATA[协议基础]]></category>

		<category><![CDATA[ARP]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-519</guid>
		<description><![CDATA[ 
免费ARP包是标准ARP请求包的特例，目的MAC地址仍是二层广播地址FFFF-FFFF-FFFF，源MAC地址是发送ARP请求主机的MAC地址，然而，源IP和目的IP都是发送主机的IP。这就是免费ARP包和标准ARP请求包的区别。
如果大家，看到一个ARP请求包的目的MAC是一个单播地址，那么就要引起警觉了！当然，不排除一些二层安全技术使用这种不标准的ARP请求包用于维护网关上的映射表，谁叫ARP机制没认证机制，想怎么做都行。
免费ARP包一般产生于系统引导时，网络模块用于确定当前使用的IP地址，同段内是否还有其他人在使用。当主机发送一个免费ARP包后，未收到应答，说明IP无冲突，反之则报错。
免费ARP还有另外一个作用，如果发送免费ARP请求的主机更换了网卡，这个包正好用于修改其他主机MAC缓冲池中的映射关系。通过这个功能，足可看出ARP机制的脆弱性。《TCP/IP详解 卷1：协议》第45页23行有这么一句话：“主机接收到任何ARP请求都要完成这个操作”，唉，这就是ARP攻击泛滥的根本原因。不知何时才能得到纠正，全世界统一升级二层ARP协议是个难题！再次郁闷！
以下是免费ARP的抓包结果图：

相关文章

2009年05月4号 &#8212; 案例分析-ARP欺骗攻击(3) (0)
2009年05月2号 &#8212; 案例分析-ARP欺骗攻击(2) (0)
2009年05月1号 &#8212; 案例分析-ARP欺骗攻击 (0)
2009年04月29号 &#8212; 什么是ARP攻击(2)？ (0)
2009年04月28号 &#8212; 什么是ARP攻击？ (0)

]]></description>
			<content:encoded><![CDATA[<p> </p>
<p>免费ARP包是标准ARP请求包的特例，目的MAC地址仍是二层广播地址FFFF-FFFF-FFFF，源MAC地址是发送ARP请求主机的MAC地址，然而，源IP和目的IP都是发送主机的IP。这就是免费ARP包和标准ARP请求包的区别。</p>
<p>如果大家，看到一个ARP请求包的目的MAC是一个单播地址，那么就要引起警觉了！当然，不排除一些二层安全技术使用这种不标准的ARP请求包用于维护网关上的映射表，谁叫ARP机制没认证机制，想怎么做都行。</p>
<p>免费ARP包一般产生于系统引导时，网络模块用于确定当前使用的IP地址，同段内是否还有其他人在使用。当主机发送一个免费ARP包后，未收到应答，说明IP无冲突，反之则报错。</p>
<p>免费ARP还有另外一个作用，如果发送免费ARP请求的主机更换了网卡，这个包正好用于修改其他主机MAC缓冲池中的映射关系。通过这个功能，足可看出ARP机制的脆弱性。《TCP/IP详解 卷1：协议》第45页23行有这么一句话：“主机接收到任何ARP请求都要完成这个操作”，唉，这就是ARP攻击泛滥的根本原因。不知何时才能得到纠正，全世界统一升级二层ARP协议是个难题！再次郁闷！</p>
<p>以下是免费ARP的抓包结果图：</p>
<p align="center"><a href="http://tcpip.info-weblog.org/images/ARP_E2A5/123.jpg"><img style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; DISPLAY: block; FLOAT: none; MARGIN-LEFT: auto; BORDER-TOP: 0px; MARGIN-RIGHT: auto; BORDER-RIGHT: 0px" title="免费ARP抓包截图" src="http://tcpip.info-weblog.org/images/ARP_E2A5/123_thumb.jpg" border="0" alt="免费ARP抓包截图" width="604" height="310" /></a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年05月4号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-387" title="案例分析-ARP欺骗攻击(3)">案例分析-ARP欺骗攻击(3) (0)</a></li>
<li>2009年05月2号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-379" title="案例分析-ARP欺骗攻击(2)">案例分析-ARP欺骗攻击(2) (0)</a></li>
<li>2009年05月1号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-377" title="案例分析-ARP欺骗攻击">案例分析-ARP欺骗攻击 (0)</a></li>
<li>2009年04月29号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-363" title="什么是ARP攻击(2)？">什么是ARP攻击(2)？ (0)</a></li>
<li>2009年04月28号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-355" title="什么是ARP攻击？">什么是ARP攻击？ (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/protocol-basic-519/feed</wfw:commentRss>
		</item>
		<item>
		<title>【转】IIS 错误代码大汇总</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-518</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-518#comments</comments>
		<pubDate>Tue, 22 Dec 2009 15:43:26 +0000</pubDate>
		<dc:creator>toadadmin2</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-518</guid>
		<description><![CDATA[400 无法解析此请求。    &#160;&#160;&#160; 401.1 未经授权：访问由于凭据无效被拒绝。 
&#160;&#160;&#160; 401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。 
&#160;&#160;&#160; 401.3 未经授权：访问由于 ACL 对所请求资源的设置被拒绝。 
&#160;&#160;&#160; 401.4 未经授权：Web 服务器上安装的筛选器授权失败。 
&#160;&#160;&#160; 401.5 未经授权：ISAPI/CGI 应用程序授权失败。 
&#160;&#160;&#160; 401.7 未经授权：由于 Web 服务器上的 URL 授权策略而拒绝访问。 
&#160;&#160;&#160; 403 禁止访问：访问被拒绝。 
&#160;&#160;&#160; 403.1 禁止访问：执行访问被拒绝。 
&#160;&#160;&#160; 403.2 禁止访问：读取访问被拒绝。 
&#160;&#160;&#160; 403.3 禁止访问：写入访问被拒绝。 
&#160;&#160;&#160; 403.4 禁止访问：需要使用 SSL 查看该资源。 
&#160;&#160;&#160; 403.5 禁止访问：需要使用 SSL 128 查看该资源。 [...]]]></description>
			<content:encoded><![CDATA[<p>400 无法解析此请求。    <br />&#160;&#160;&#160; 401.1 未经授权：访问由于凭据无效被拒绝。 </p>
<p>&#160;&#160;&#160; 401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。 </p>
<p>&#160;&#160;&#160; 401.3 未经授权：访问由于 ACL 对所请求资源的设置被拒绝。 </p>
<p>&#160;&#160;&#160; 401.4 未经授权：Web 服务器上安装的筛选器授权失败。 </p>
<p>&#160;&#160;&#160; 401.5 未经授权：ISAPI/CGI 应用程序授权失败。 </p>
<p>&#160;&#160;&#160; 401.7 未经授权：由于 Web 服务器上的 URL 授权策略而拒绝访问。 </p>
<p>&#160;&#160;&#160; 403 禁止访问：访问被拒绝。 </p>
<p>&#160;&#160;&#160; 403.1 禁止访问：执行访问被拒绝。 </p>
<p>&#160;&#160;&#160; 403.2 禁止访问：读取访问被拒绝。 </p>
<p>&#160;&#160;&#160; 403.3 禁止访问：写入访问被拒绝。 </p>
<p>&#160;&#160;&#160; 403.4 禁止访问：需要使用 SSL 查看该资源。 </p>
<p>&#160;&#160;&#160; 403.5 禁止访问：需要使用 SSL 128 查看该资源。 </p>
<p>&#160;&#160;&#160; 403.6 禁止访问：客户端的 IP 地址被拒绝。 </p>
<p>&#160;&#160;&#160; 403.7 禁止访问：需要 SSL 客户端证书。 </p>
<p>&#160;&#160;&#160; 403.8 禁止访问：客户端的 DNS 名称被拒绝。 </p>
<p>&#160;&#160;&#160; 403.9 禁止访问：太多客户端试图连接到 Web 服务器。 </p>
<p>&#160;&#160;&#160; 403.10 禁止访问：Web 服务器配置为拒绝执行访问。 </p>
<p>&#160;&#160;&#160; 403.11 禁止访问：密码已更改。 </p>
<p>&#160;&#160;&#160; 403.12 禁止访问：服务器证书映射器拒绝了客户端证书访问。 </p>
<p>&#160;&#160;&#160; 403.13 禁止访问：客户端证书已在 Web 服务器上吊销。 </p>
<p>&#160;&#160;&#160; 403.14 禁止访问：在 Web 服务器上已拒绝目录列表。 </p>
<p>&#160;&#160;&#160; 403.15 禁止访问：Web 服务器已超过客户端访问许可证限制。 </p>
<p>&#160;&#160;&#160; 403.16 禁止访问：客户端证书格式错误或未被 Web 服务器信任。 </p>
<p>&#160;&#160;&#160; 403.17 禁止访问：客户端证书已经到期或者尚未生效。 </p>
<p>&#160;&#160;&#160; 403.18 禁止访问：无法在当前应用程序池中执行请求的 URL。 </p>
<p>&#160;&#160;&#160; 403.19 禁止访问：无法在该应用程序池中为客户端执行 CGI。 </p>
<p>&#160;&#160;&#160; 403.20 禁止访问：Passport 登录失败。 </p>
<p>&#160;&#160;&#160; 404 找不到文件或目录。 </p>
<p>&#160;&#160;&#160; 404.1 文件或目录未找到：网站无法在所请求的端口访问。 </p>
<p>&#160;&#160;&#160; 注意 404.1 错误只会出现在具有多个 IP 地址的计算机上。如果在特定 IP 地址/端口组合上收到客户端请求，而且没有将 IP 地址配置为在该特定的端口上侦听，则 IIS 返回 404.1 HTTP 错误。例如，如果一台计算机有两个 IP 地址，而只将其中一个 IP 地址配置为在端口 80 上侦听，则另一个 IP 地址从端口 80 收到的任何请求都将导致 IIS 返回 404.1 错误。只应在此服务级别设置该错误，因为只有当服务器上使用多个 IP 地址时才会将它返回给客户端。    <br />&#160;&#160; 404.2 文件或目录无法找到：锁定策略禁止该请求。 </p>
<p>&#160;&#160;&#160; 404.3 文件或目录无法找到：MIME 映射策略禁止该请求。 </p>
<p>&#160;&#160;&#160; 405 用于访问该页的 HTTP 动作未被许可。 </p>
<p>&#160;&#160;&#160; 406 客户端浏览器不接受所请求页面的 MIME 类型。 </p>
<p>&#160;&#160;&#160; 407 Web 服务器需要初始的代理验证。 </p>
<p>&#160;&#160;&#160; 410 文件已删除。 </p>
<p>&#160;&#160;&#160; 412 客户端设置的前提条件在 Web 服务器上评估时失败。 </p>
<p>&#160;&#160;&#160; 414 请求 URL 太大，因此在 Web 服务器上不接受该 URL。 </p>
<p>&#160;&#160;&#160; 500 服务器内部错误。 </p>
<p>&#160;&#160;&#160; 500.11 服务器错误：Web 服务器上的应用程序正在关闭。 </p>
<p>&#160;&#160;&#160; 500.12 服务器错误：Web 服务器上的应用程序正在重新启动。 </p>
<p>&#160;&#160;&#160; 500.13 服务器错误：Web 服务器太忙。 </p>
<p>&#160;&#160;&#160; 500.14 服务器错误：服务器上的无效应用程序配置。 </p>
<p>&#160;&#160;&#160; 500.15 服务器错误：不允许直接请求 GLOBAL.ASA。 </p>
<p>&#160;&#160;&#160; 500.16 服务器错误：UNC 授权凭据不正确。 </p>
<p>&#160;&#160;&#160; 500.17 服务器错误：URL 授权存储无法找到。 </p>
<p>&#160;&#160;&#160; 500.18 服务器错误：URL 授权存储无法打开。 </p>
<p>&#160;&#160;&#160; 500.19 服务器错误：该文件的数据在配置数据库中配置不正确。 </p>
<p>&#160;&#160;&#160; 500.20 服务器错误：URL 授权域无法找到。 </p>
<p>&#160;&#160;&#160; 500 100 内部服务器错误：ASP 错误。 </p>
<p>&#160;&#160;&#160; 501 标题值指定的配置没有执行。 </p>
<p>&#160;&#160;&#160; 502 Web 服务器作为网关或代理服务器时收到无效的响应。 </p>
<p>&#160;&#160;&#160; WIN2003 SERVER IIS6.0 ASP 错误解析 </p>
<p>&#160;&#160;&#160; 事件 ID 描述 </p>
<p>&#160;&#160;&#160; 0100 内存不足。无法分配所需的内存。 </p>
<p>&#160;&#160;&#160; 0101 意外错误。函数返回 |。 </p>
<p>&#160;&#160;&#160; 0102 要求字符串输入。函数需要字符串输入。 </p>
<p>&#160;&#160;&#160; 0103 要求数字输入。函数需要数字输入。 </p>
<p>&#160;&#160;&#160; 0104 不允许操作。 </p>
<p>&#160;&#160;&#160; 0105 索引超出范围。数组索引超出范围。 </p>
<p>&#160;&#160;&#160; 0106 类型不匹配。遇到未处理的数据类型。 </p>
<p>&#160;&#160;&#160; 0107 数据大小太大。请求中发送的数据大小超出允许的限制。 </p>
<p>&#160;&#160;&#160; 0108 创建对象失败。创建对象 &#8216;%s&#8217; 时出错。 </p>
<p>&#160;&#160;&#160; 0109 成员未找到。 </p>
<p>&#160;&#160;&#160; 0110 未知的名称。 </p>
<p>&#160;&#160;&#160; 0111 未知的界面。 </p>
<p>&#160;&#160;&#160; 0112 参数丢失。 </p>
<p>&#160;&#160;&#160; 0113 脚本超时。超过了脚本运行的最长时间。可以通过为 Server.ScriptTimeout 属性指定一个新值或在 IIS 管理工具中修改值来更改此限制。 </p>
<p>&#160;&#160;&#160; 0114 对象不可用于自由线程。应用程序对象仅接受自由线程对象；而对象 &#8216;%s&#8217; 不可用于自由线程。 </p>
<p>&#160;&#160;&#160; 0115 意外错误。外部对象中发生一个可捕捉的错误 (%X)。脚本无法继续运行。 </p>
<p>&#160;&#160;&#160; 0116 脚本分隔符结束标记丢失。脚本块缺少脚本结束标记 (%&gt;)。 </p>
<p>&#160;&#160;&#160; 0117 脚本结束标记丢失。脚本块缺少脚本结束标记 (&lt;/SCRIPT&gt;) 或标记结束符号 (&gt;)。 </p>
<p>&#160;&#160;&#160; 0118 对象的结束标记丢失。对象块缺少对象结束标记 (&lt;/OBJECT&gt;) 或标记结束符号 (&gt;)。 </p>
<p>&#160;&#160;&#160; 0119 Classid 或 Progid 属性丢失。对象实例 &#8216;|&#8217; 在对象标记中需要有效的 Classid 或 Progid。 </p>
<p>&#160;&#160;&#160; 0120 Runat 属性无效。脚本标记或对象标记的 Runat 属性只能有 &#8216;Server&#8217; 值。 </p>
<p>&#160;&#160;&#160; 0121 对象标记中的范围无效。对象实例 &#8216;|&#8217; 的作用范围不能是 Application 或 Session。要创建有 Session 或 Application 作用范围的对象实例，请将在 Global.asa 文件中加入 Object 标记。 </p>
<p>&#160;&#160;&#160; 0122 对象标记中的范围无效。对象实例 &#8216;|&#8217; 必须有 Application 或 Session 作用范围。这将应用于所有在 Global.asa 文件内创建的对象。 </p>
<p>&#160;&#160;&#160; 0123 缺少 Id 属性。缺少 Object 标记所需的 Id 属性。 </p>
<p>&#160;&#160;&#160; 0124 Language 属性丢失。缺少 Object 标记所需的 Language 属性。 </p>
<p>&#160;&#160;&#160; 0125 属性结束标记丢失。&#8217;|&#8217; 属性的值没有结束分隔符。 </p>
<p>&#160;&#160;&#160; 0126 未找到 Include 文件。未找到 Include 文件 &#8216;|&#8217;。 </p>
<p>&#160;&#160;&#160; 0127 HTML 注释的结束标记丢失。HTML 注释或在服务器端的包含文件缺少结束标记 (&#8211;&gt;)。 </p>
<p>&#160;&#160;&#160; 0128 File 或 Virtual 属性丢失。Include 文件名必须用 File 或 Virtual 属性指定。 </p>
<p>&#160;&#160;&#160; 0129 未知的脚本语言。服务器上找不到脚本语言 &#8216;|&#8217;。 </p>
<p>&#160;&#160;&#160; 0130 File 属性无效。File 属性 &#8216;|&#8217; 不能以斜杠或反斜杠开始。 </p>
<p>&#160;&#160;&#160; 0131 不允许的父路径。Include 文件 &#8216;|&#8217; 不能包含 &#8216;..&#8217; 来表示父目录。 </p>
<p>&#160;&#160;&#160; 0132 编译错误。无法处理 Active Server Page &#8216;|&#8217;。 </p>
<p>&#160;&#160;&#160; 0133 ClassID 属性无效。对象标记有一个无效的 ClassID &#8216;|&#8217;。 </p>
<p>&#160;&#160;&#160; 0134 ProgID 属性无效。对象有一个无效的 ProgID &#8216;|&#8217;。 </p>
<p>&#160;&#160;&#160; 0135 循环包含。文件 &#8216;|&#8217; 包含它本身（可能是非直接地包含）。请检查包含文件中的其他 Include 语句。 </p>
<p>&#160;&#160;&#160; 0136 对象实例名无效。对象实例 &#8216;|&#8217; 试图使用一个保留名称。这个名称被 Active Server Pages 的内部对象使用。    <br />&#160;&#160;&#160; 0137 全局脚本无效。脚本块必须是允许的 Global.asa 过程之一。Global.asa 文件中不允许在 &lt;% &#8230; %&gt; 内使用脚本指令。允许的过程名称是 Application_OnStart、Application_OnEnd、Session_OnStart 或 Session_OnEnd。 </p>
<p>&#160;&#160;&#160; 0138 脚本块嵌套。脚本块不可放在另一个脚本块内。 </p>
<p>&#160;&#160;&#160; 0139 嵌套对象。对象标记不能放在另一个对象标记内。 </p>
<p>&#160;&#160;&#160; 0140 页命令次序有误。@ 命令必须是 Active Server Page 中的第一个命令。 </p>
<p>&#160;&#160;&#160; 0141 页命令重复。@ 命令只可以在 Active Server Page 中使用一次。 </p>
<p>&#160;&#160;&#160; 0142 线程令牌错误。无法打开线程令牌。 </p>
<p>&#160;&#160;&#160; 0143 应用程序名无效。未找到有效的应用程序名称。 </p>
<p>&#160;&#160;&#160; 0144 初始化错误。初始化时页级别的对象列表失败。 </p>
<p>&#160;&#160;&#160; 0145 新应用程序失败。无法添加新的应用程序。 </p>
<p>&#160;&#160;&#160; 0146 新会话失败。无法添加新的会话。 </p>
<p>&#160;&#160;&#160; 0147 500 服务器错误。 </p>
<p>&#160;&#160;&#160; 0148 服务器太忙。 </p>
<p>&#160;&#160;&#160; 0149 正在重新启动应用程序。重启动应用程序期间无法处理请求。 </p>
<p>&#160;&#160;&#160; 0150 应用程序目录错误。无法打开应用程序目录。 </p>
<p>&#160;&#160;&#160; 0151 更改通知错误。无法创建更改通知事件。 </p>
<p>&#160;&#160;&#160; 0152 安全错误。处理用户安全凭据时发生错误。 </p>
<p>&#160;&#160;&#160; 0153 线程错误。新线程请求已失败。 </p>
<p>&#160;&#160;&#160; 0154 HTTP 头写入错误。HTTP 头无法写入客户端浏览器。 </p>
<p>&#160;&#160;&#160; 0155 页内容写入错误。页内容无法写入客户端浏览器。 </p>
<p>&#160;&#160;&#160; 0156 头错误。HTTP 头已经写入到客户端浏览器。任何 HTTP 头必须在写入页内容之前修改。 </p>
<p>&#160;&#160;&#160; 0157 启用缓冲。缓冲启用后不能关闭。 </p>
<p>&#160;&#160;&#160; 0158 URL 丢失。URL 是必需的。 </p>
<p>&#160;&#160;&#160; 0159 缓冲已关闭。缓冲必须启用。 </p>
<p>&#160;&#160;&#160; 0160 日志记录错误。将条目写入日志失败。 </p>
<p>&#160;&#160;&#160; 0161 数据类型错误。将 Variant 转换为 String 变量失败。 </p>
<p>&#160;&#160;&#160; 0162 不能修改 Cookie。不能修改 Cookie &#8216;ASPSessionID&#8217;。它是一个保留的 Cookie 名。 </p>
<p>&#160;&#160;&#160; 0163 逗号用法无效。日志条目内不可使用逗号。请选择另一个分隔符。 </p>
<p>&#160;&#160;&#160; 0164 TimeOut 值无效。指定的 TimeOut 值无效。 </p>
<p>&#160;&#160;&#160; 0165 SessionID 错误。无法创建 SessionID 字符串。 </p>
<p>&#160;&#160;&#160; 0166 对象未初始化。试图访问未初始化的对象。 </p>
<p>&#160;&#160;&#160; 0167 会话初始化错误。初始化 Session 对象时发生错误。    <br />&#160;&#160;&#160; 0168 禁止的对象使用。Session 对象中不能保存内部对象。 </p>
<p>&#160;&#160;&#160; 0169 缺少对象信息。Session 对象中不能保存信息不全的对象。需要对象的线程模型信息。 </p>
<p>&#160;&#160;&#160; 0170 删除会话错误。无法正确删除 Session。 </p>
<p>&#160;&#160;&#160; 0171 路径丢失。必须为 MapPath 方法指定 Path 参数。 </p>
<p>&#160;&#160;&#160; 0172 路径无效。MapPath 方法的路径必须是虚拟路径。使用了一个实际的路径。 </p>
<p>&#160;&#160;&#160; 0173 路径字符无效。MapPath 方法的 Path 参数中指定了一个无效字符。 </p>
<p>&#160;&#160;&#160; 0174 多个路径字符无效。MapPath 方法的 Path 参数中指定了无效的 &#8216;/&#8217; 或 &#8216;\\&#8217;。 </p>
<p>&#160;&#160;&#160; 0175 不允许的路径字符。MapPath 方法的 Path 参数中不允许使用 &#8216;..&#8217; 字符。 </p>
<p>&#160;&#160;&#160; 0176 未找到路径。MapPath 方法的 Path 参数与已知路径不符。 </p>
<p>&#160;&#160;&#160; 0177 Server.CreateObject 失败。%s </p>
<p>&#160;&#160;&#160; 0178 Server.CreateObject 访问错误。检查权限时调用 Server.CreateObject 失败。对此对象的访问被拒绝。 </p>
<p>&#160;&#160;&#160; 0179 应用程序初始化错误。初始化 Application 对象时发生错误。 </p>
<p>&#160;&#160;&#160; 0180 禁止的对象使用。Application 对象中不能保存内部对象。 </p>
<p>&#160;&#160;&#160; 0181 线程模型无效。使用单元线程模型的对象不能存储在 Application 对象中。 </p>
<p>&#160;&#160;&#160; 0182 对象信息丢失。Application 对象中不能保存信息不全的对象。需要此对象的线程模型信息。 </p>
<p>&#160;&#160;&#160; 0183 空 Cookie 项。不能保存空项 Cookie。 </p>
<p>&#160;&#160;&#160; 0184 Cookie 名称丢失。必须为 Cookie 指定名称。 </p>
<p>&#160;&#160;&#160; 0185 默认属性丢失。未找到对象的默认属性。 </p>
<p>&#160;&#160;&#160; 0186 证书分析错误。 </p>
<p>&#160;&#160;&#160; 0187 对象添加冲突。无法将对象添加到应用程序。应用程序被另一个要求添加对象的请求锁定。 </p>
<p>&#160;&#160;&#160; 0188 禁止的对象使用。无法将用对象标记创建的对象添加到会话内部。 </p>
<p>&#160;&#160;&#160; 0189 禁止的对象使用。无法将用对象标记创建的对象添加到应用程序内部。 </p>
<p>&#160;&#160;&#160; 0190 意外错误。释放外部对象时发生可捕获错误。 </p>
<p>&#160;&#160;&#160; 0191 意外错误。外部对象的 OnStartPage 方法中发生可捕获错误。 </p>
<p>&#160;&#160;&#160; 0192 意外错误。外部对象的 OnEndPage 方法中发生可捕获错误。 </p>
<p>&#160;&#160;&#160; 0193 OnStartPage 失败。外部对象的 OnStartPage 方法中出错。 </p>
<p>&#160;&#160;&#160; 0194 OnEndPage 失败。外部对象的 OnEndPage 方法中出错。 </p>
<p>&#160;&#160;&#160; 0195 无效的服务器方法调用。Session_OnEnd 和 Application_OnEnd 期间不能调用 Server 对象的此方法。 </p>
<p>&#160;&#160;&#160; 0196 无法启动进程外组件。只能使用 InProc 服务器组件。若要使用 LocalServer 组件，必须设置 AspAllowOutOfProcComponents 配置数据库设置。请参阅帮助文件，了解重要注意事项。 </p>
<p>&#160;&#160;&#160; 0197 禁止的对象使用。不能将有单元模型行为的对象添加到应用程序内部对象。 </p>
<p>&#160;&#160;&#160; 0198 服务器正在关闭。不能处理请求。 </p>
<p>&#160;&#160;&#160; 0199 禁止的对象使用。不能将 JScript 对象添加到会话。 </p>
<p>&#160;&#160;&#160; 0200 超出 &#8216;Expires&#8217; 属性范围。为 &#8216;Expires&#8217; 指定的日期和时间在 1980 年 1 月 1 日之前或在 2038 年 1 月 19 日 3:14:07 GMT 之后。 </p>
<p>&#160;&#160;&#160; 0201 默认脚本语言无效。为此应用程序指定的默认脚本语言无效。 </p>
<p>&#160;&#160;&#160; 0202 代码页丢失。代码页属性丢失。 </p>
<p>&#160;&#160;&#160; 0203 代码页无效。指定的代码页属性无效。 </p>
<p>&#160;&#160;&#160; 0204 CodePage 值无效。指定的 CodePage 值无效。 </p>
<p>&#160;&#160;&#160; 0205 更改通知。创建更改通知事件失败。 </p>
<p>&#160;&#160;&#160; 0206 不能调用 BinaryRead。使用 Request.Form 集合后不能调用 BinaryRead。 </p>
<p>&#160;&#160;&#160; 0207 不能使用 Request.Form。调用 BinaryRead 后不能使用 Request.Form 集合。 </p>
<p>&#160;&#160;&#160; 0208 不能使用通用 Request 集合。调用 BinaryRead 后不能使用通用 Request 集合。 </p>
<p>&#160;&#160;&#160; 0209 TRANSACTION 属性的值非法。TRANSACTION 属性只能是 REQUIRED、REQUIRES_NEW、SUPPORTED 或 NOT_SUPPORTED。 </p>
<p>&#160;&#160;&#160; 0210 方法未实施。此方法尚未实施。 </p>
<p>&#160;&#160;&#160; 0211 对象超出范围。引用内置的 ASP 对象，此操作已不再有效。 </p>
<p>&#160;&#160;&#160; 0212 无法清除缓冲区。客户端调试启用时，Response.Flush 之后不能有 Response.Clear。 </p>
<p>&#160;&#160;&#160; 0214 路径参数无效。Path 参数超出允许的最大长度。 </p>
<p>&#160;&#160;&#160; 0215 ENABLESESSIONSTATE 属性的值非法。ENABLESESSIONSTATE 属性的值只能是 TRUE 或 FALSE。 </p>
<p>&#160;&#160;&#160; 0216 MSDTC 服务未运行。如果未运行 MSDTC 服务，则不能运行事务性网页。 </p>
<p>&#160;&#160;&#160; 0217 对象标记中的范围无效。对象的作用范围必须是 Page、Session 或 Application。 </p>
<p>&#160;&#160;&#160; 0218 LCID 丢失。LCID 属性丢失。 </p>
<p>&#160;&#160;&#160; 0219 LCID 无效。指定的 LCID 不可用。 </p>
<p>&#160;&#160;&#160; 0220 不允许请求 GLOBAL.ASA。不允许请求指向 GLOBAL.ASA 的 URL。 </p>
<p>&#160;&#160;&#160; 0221 @ 命令指令无效。指定的 &#8216;|&#8217; 选项未知或无效。 </p>
<p>&#160;&#160;&#160; 0222 TypeLib 规范无效。METADATA 标记包含无效的类型库规范。 </p>
<p>&#160;&#160;&#160; 0223 未找到 TypeLib。METADATA 标签含有的类型库规范和注册表项不符。 </p>
<p>&#160;&#160;&#160; 0224 无法加载 TypeLib。无法加载 METADATA 标记中指定的类型库。 </p>
<p>&#160;&#160;&#160; 0225 无法包装 TypeLib。不能通过 METADATA 标记中指定的类型库创建类型库包装对象。 </p>
<p>&#160;&#160;&#160; 0226 无法修改 StaticObjects。运行时无法修改 StaticObjects 集合。 </p>
<p>&#160;&#160;&#160; 0227 Server.Execute 失败。调用 Server.Execute 失败。 </p>
<p>&#160;&#160;&#160; 0228 Server.Execute 错误。加载此页时调用 Server.Execute 失败。 </p>
<p>&#160;&#160;&#160; 0229 Server.Transfer 失败。调用 Server.Transfer 失败。 </p>
<p>&#160;&#160;&#160; 0230 Server.Transfer 错误。加载此页时调用 Server.Transfer 失败。 </p>
<p>&#160;&#160;&#160; 0231 Server.Execute 错误。使用的 URL 格式无效，或者使用了完全限定的绝对 URL。请使用相对 URL。 </p>
<p>&#160;&#160;&#160; 0232 Cookie 规范无效。METADATA 标记包含无效的 Cookie 规范。 </p>
<p>&#160;&#160;&#160; 0233 无法加载 Cookie 脚本源。无法加载 METADATA 标记中指定的 Cookie 脚本源文件。 </p>
<p>&#160;&#160;&#160; 0234 包含指令无效。脚本块中可能没有服务器端包含文件指令。请使用 &lt;SCRIPT&gt; 标签的 SRC= 属性。 </p>
<p>&#160;&#160;&#160; 0235 Server.Transfer 错误。使用的 URL 格式无效，或者使用了完全限定的绝对 URL。请使用相对 URL。 </p>
<p>&#160;&#160;&#160; 0236 Cookie 规范无效。METADATA 标记包含无效的 SRC 参数或缺少该参数。 </p>
<p>&#160;&#160;&#160; 0237 Cookie 规范无效。METADATA 标记包含无效的 NAME 参数或缺少该参数。 </p>
<p>&#160;&#160;&#160; 0238 属性值丢失。没有为 &#8216;|&#8217; 属性指定值。 </p>
<p>&#160;&#160;&#160; 0239 无法处理文件。不支持 UNICODE ASP 文件。 </p>
<p>&#160;&#160;&#160; 0240 脚本引擎异常。ScriptEngine 在 &#8216;%s&#8217; 中从 &#8216;%s&#8217; 引发 &#8216;%X&#8217; 异常。 </p>
<p>&#160;&#160;&#160; 0241 CreateObject 异常。&#8217;%s&#8217; 的 CreateObject 引发 %X 异常。 </p>
<p>&#160;&#160;&#160; 0242 查询 OnStartPage 接口异常。查询的 &#8216;%s&#8217; 对象的 OnStartPage 或 OnEndPage 方法引发 %X 异常。 </p>
<p>&#160;&#160;&#160; 0243 Global.asa 中的 METADATA 标记无效。Global.asa 中只能使用 METADATA TYPE=&quot;TypeLib&quot;。 </p>
<p>&#160;&#160;&#160; 0244 无法启用会话状态。应用程序中禁用会话时，无法启用会话状态。 </p>
<p>&#160;&#160;&#160; 0245 代码页值混合使用。指定的 @CODEPAGE 值与包含文件的 CODEPAGE 或文件的已保存格式的值不同。 </p>
<p>&#160;&#160;&#160; 0246 并发用户太多。请稍后再试.. </p>
<p>&#160;&#160;&#160; 0247 BinaryRead 的参数无效。BinaryRead 的参数必须为非负值。 </p>
<p>&#160;&#160;&#160; 0248 未处理脚本。必须处理此 ASP 文件才能使用 ObjectContext 对象。 </p>
<p>&#160;&#160;&#160; 0249 无法在 Request 上使用 IStream。使用 Request.Form 集合或 Request.BinaryRead 后无法在 Request 对象上使用 IStream。 </p>
<p>&#160;&#160;&#160; 0250 默认代码页无效。为此应用程序指定的默认代码页无效。 </p>
<p>&#160;&#160;&#160; 0251 超出响应缓冲区限制。ASP 页的执行引起响应缓冲区超出其配置限制。 </p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年04月15号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-281" title="链路层-PPP：点对点协议">链路层-PPP：点对点协议 (1)</a></li>
<li>2009年10月11号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-480" title="RFC903:反向地址转换协议">RFC903:反向地址转换协议 (0)</a></li>
<li>2009年09月12号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-460" title="RFC792:Internet 控制信息协议">RFC792:Internet 控制信息协议 (0)</a></li>
<li>2009年04月8号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-251" title="链路层-入门篇">链路层-入门篇 (0)</a></li>
<li>2009年04月17号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-294" title="DDOS案列分析">DDOS案列分析 (0)</a></li>
<li>2009年09月22号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-470" title="RFC861:Telnet扩展选项列表选项">RFC861:Telnet扩展选项列表选项 (0)</a></li>
<li>2009年05月4号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-389" title="RFC 2198：用于冗余音频数据的RTP负载格式">RFC 2198：用于冗余音频数据的RTP负载格式 (0)</a></li>
<li>2009年11月17号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-506" title="RFC1091_TELNET终端类型选项">RFC1091_TELNET终端类型选项 (0)</a></li>
<li>2009年10月22号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-484" title="RFC932:子网地址分配方案">RFC932:子网地址分配方案 (0)</a></li>
<li>2009年04月14号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-276" title="链路层-SLIP：串行线路IP">链路层-SLIP：串行线路IP (1)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-518/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1144_低速串行链路上的TCPIP头部压缩</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-517</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-517#comments</comments>
		<pubDate>Wed, 16 Dec 2009 15:40:55 +0000</pubDate>
		<dc:creator>toadadmin2</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-517</guid>
		<description><![CDATA[
简介
随着功能日益强大的计算机进入人们家庭，扩展这些计算机的功能使之与Internet连接成为日益迫切的要求。不幸的是，这个扩展在链路层帧（link level framing）、地址分配(address assignment)、路由选择、认证以及性能等方面暴露出很多很复杂的问题。在写本文档时所有这些领域的工作还在进行。本文档描述一种方法，这种方法已经被用来提高低速（300-900bps）串行链路上的TCP/IP的性能。
这里推荐的压缩方法与Thinwire-II协议（参考文献[5]）描述的思想是相似的。但是本协议压缩的效率更高(压缩后TCP/IP头部为3个字节，而Thinwire-II为13个字节)，并且实现起来既高效又简单(Unix 实现需要250行C代码，在20MHz MC68020中压缩或者解压一个数据包平均需要90µs(_170指令集)。
该压缩专门针对TCP/IP数据包（注1），作者研究了UDP/IP数据包的压缩但发现这种情况极少出现，并且没有足够的datagram-to-datagram一致性来进行很好的压缩（例如，名字服务器查询）或者高层协议头部淹没了UDP/IP头部的开销（例如，Sun’s RPC/NFS）。作者还研究了分开压缩数据报的IP和TCP部分，但因为压缩后头部平均大小比原来增加50%，并且压缩和解压缩的代码加倍，因而被否决了。
&#160;问题
人们可能期望通过串行IP链路从家中访问从“终端”击键（type）类型连接(如telnet, rlogin, xterm)到批量数据传输（例如ftp, smtp, nntp）的Internet服务。头部压缩的动机就是出于对良好的交互响应的需要求。也就是说协议的链路效率（line efficiency）为数据报中header占header+data的百分比。如果高效的批量数据传输是我们的目标，,通过把数据报的尺寸扩大到足够大总是可以使链路效率接近100%。
对人的因素（Human-factor）的研究（参考文献[15]）结果表明交互操作在低层反馈(feed-back)（字符回显,character echo）花费超过100-200ms时被认为是“差的”。协议头部从以下几方面与这个极端交互：
（1）如果链路速度太慢，也许不可能把头部和数据都放在一个200ms的窗口中：每敲击一个键产生一个字符就要导致发送一个41字节的TCP/IP数据包和接收一个41字节的反馈(echo)。链路速度至少达到 4000 bps 以便在200ms内能够处理这82 个字节的数据包。
点击下载：[PDF]RFC1144_低速串行链路上的TCPIP头部压缩_中文版
相关文章

2009年10月13号 &#8212; RFC925:多局域网地址解决 (0)
2009年04月29号 &#8212; 什么是ARP攻击(2)？ (0)
2010年05月17号 &#8212; 什么是免费ARP (0)
2009年02月26号 &#8212; TCP/IP协议的分层(3) (0)
2009年04月21号 &#8212; TCP/IP协议的缩略语解释（1） (0)
2009年11月12号 &#8212; RFC1075_远距离矢量多播选路协议 (0)
2009年10月30号 &#8212; RFC974_邮件路由与域名系统 (0)
2009年05月4号 &#8212; 案例分析-ARP欺骗攻击(3) (0)
2009年04月17号 &#8212; DDOS案列分析 (0)
2009年11月26号 &#8212; RFC1112_主机扩展用于IP多点传送 (0)

]]></description>
			<content:encoded><![CDATA[<p><b></b></p>
<p><b>简介</b><b></b></p>
<p>随着功能日益强大的计算机进入人们家庭，扩展这些计算机的功能使之与Internet连接成为日益迫切的要求。不幸的是，这个扩展在链路层帧（link level framing）、地址分配(address assignment)、路由选择、认证以及性能等方面暴露出很多很复杂的问题。在写本文档时所有这些领域的工作还在进行。本文档描述一种方法，这种方法已经被用来提高低速（300-900bps）串行链路上的TCP/IP的性能。</p>
<p>这里推荐的压缩方法与<i>Thinwire-II</i>协议（参考文献[5]）描述的思想是相似的。但是本协议压缩的效率更高(压缩后TCP/IP头部为3个字节，而Thinwire-II为13个字节)，并且实现起来既高效又简单(Unix 实现需要250行C代码，在20MHz MC68020中压缩或者解压一个数据包平均需要90µs(_170指令集)。</p>
<p>该压缩专门针对TCP/IP数据包（<b>注</b><b>1</b>），作者研究了UDP/IP数据包的压缩但发现这种情况极少出现，并且没有足够的datagram-to-datagram一致性来进行很好的压缩（例如，名字服务器查询）或者高层协议头部淹没了UDP/IP头部的开销（例如，Sun’s RPC/NFS）。作者还研究了分开压缩数据报的IP和TCP部分，但因为压缩后头部平均大小比原来增加50%，并且压缩和解压缩的代码加倍，因而被否决了。</p>
<p><b>&#160;</b><b>问题</b><b></b></p>
<p>人们可能期望通过串行IP链路从家中访问从“终端”击键（type）类型连接(如telnet, rlogin, xterm)到批量数据传输（例如ftp, smtp, nntp）的Internet服务。头部压缩的动机就是出于对良好的交互响应的需要求。也就是说协议的链路效率（<i>line efficiency</i>）为数据报中header占header+data的百分比。如果高效的批量数据传输是我们的目标，,通过把数据报的尺寸扩大到足够大总是可以使链路效率接近100%。</p>
<p>对人的因素（Human-factor）的研究（参考文献[15]）结果表明交互操作在低层反馈(feed-back)（字符回显,character echo）花费超过100-200ms时被认为是“差的”。协议头部从以下几方面与这个极端交互：</p>
<p>（1）如果链路速度太慢，也许不可能把头部和数据都放在一个200ms的窗口中：每敲击一个键产生一个字符就要导致发送一个41字节的TCP/IP数据包和接收一个41字节的反馈(echo)。链路速度至少达到 4000 bps 以便在200ms内能够处理这82 个字节的数据包。</p>
<p>点击下载：<a title="点击下载RFC1144_低速串行链路上的TCPIP头部压缩_中文版" href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1144-chinese.pdf">[PDF]RFC1144_低速串行链路上的TCPIP头部压缩_中文版</a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年10月4号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-473" title="RFC872:局域网上的TCP协议">RFC872:局域网上的TCP协议 (0)</a></li>
<li>2009年10月7号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-476" title="RFC890:外部网关协议执行表">RFC890:外部网关协议执行表 (0)</a></li>
<li>2009年09月15号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-463" title="RFC854:Telnet协议说明书">RFC854:Telnet协议说明书 (0)</a></li>
<li>2009年04月27号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-352" title="链路层-串行线路吞吐量计算">链路层-串行线路吞吐量计算 (0)</a></li>
<li>2009年05月9号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-399" title="RFC 2281：Cisco热备份路由协议（HSRP）">RFC 2281：Cisco热备份路由协议（HSRP） (0)</a></li>
<li>2009年04月27号 &#8212; <a href="http://tcpip.info-weblog.org/ip-protocol-353" title="网络层-入门篇">网络层-入门篇 (0)</a></li>
<li>2009年10月5号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-474" title="RFC877:IP 数据包通过公共数据网络的传输标准">RFC877:IP 数据包通过公共数据网络的传输标准 (0)</a></li>
<li>2009年11月17号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-506" title="RFC1091_TELNET终端类型选项">RFC1091_TELNET终端类型选项 (0)</a></li>
<li>2009年11月27号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-511" title="RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤">RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤 (0)</a></li>
<li>2009年11月4号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-495" title="RFC1055_在串行线路上传输IP数据报的非标准协议">RFC1055_在串行线路上传输IP数据报的非标准协议 (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-517/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-515</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-515#comments</comments>
		<pubDate>Sun, 13 Dec 2009 15:33:22 +0000</pubDate>
		<dc:creator>toadadmin2</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-515</guid>
		<description><![CDATA[&#160;
摘要
点到点协议（the Point-to-Point Protocol）提供了一种在点到点链路上封装网络层协议信息的标准方法。PPP 也定义了可扩展的链路控制协议(Link Control Protocol)，它（Link Control Protocol）使用验证协议磋商在链路上传输网络层协议前验证链路的对端。
这个文档定义了两种验证协议：密码验证协议（the Password Authentication Protocol）和挑战－握手验证协议（the Challenge-Handshake Authentication Protocol）。此RFC是IETF(the Internet Engineering Task Force)的PPP协议工作组的成果。
&#160;
介绍
PPP 有三个主要的组成部分：
1．在串行链路上封装数据报（datagrams）的方法。
2．建立，配置和测试数据链路链接（the data-link connection）的LCP协议（Link Control Protocol）。
3．建立和配置不同网络层协议的一组NCP协议（Network Control Protocol）。
为了在点到点链路（point-to-point link）上建立通信，PPP链路的一端必须在建立阶段（Establishment phase）首先发送LCP包（packets）配置数据链路。在链路建立后，在进入到网络层协议阶段前，PPP提供一个可选择的验证阶段。
默认的，身份验证不是强制的。如果希望进行链路的身份验证，则实现者必须在建立阶段指明身份验证－协议配置选项。
这些协议主要是为通过交换网（switched circuits）或者拨号线(dial-up lines)连接到PPP网络服务器的主机和路由器服务的，但是也可以被用到专用链路（dedicated links）中。服务器在为网络层磋商选择选项时可以对连接的主机或路由器进行身份验证。
此文档定义了PPP身份验证协议。链路建立和验证阶段，和验证协议配置选项定义在PPP协议中[1]。
要求说明书
在本文档中，用以下几个词来表示说明书的要求，这些词一般以大写字体书写。
MUST
这个词表示在此说明书中是绝对要求的。
MUST NOT
这个词组表示在此说明书中是绝对禁止的。
SHOULD
此词表示在此说明书中是推荐的。
MAY
此词表示在此说明书中是可选的。
术语
本文档中，频繁使用以下术语：
authenticator――验证者：
要求验证的链路端点。验证者说明了在链路建立阶段使用的验证协议。
Peer――点到点链路的另一端：
正在被验证者验证的一端。
Silently discard――静静地丢弃
丢弃packet而不进行进一步的处理。执行（这个动作）应该提供记录错误，包括丢弃packet的内容，的容量，并且应该在一个统计计数器中记录这一事件。
点击下载：[PDF]RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议_中文版
相关文章

2009年10月5号 &#8212; RFC877:IP 数据包通过公共数据网络的传输标准 (0)
2009年05月28号 &#8212; RFC 23：多重传送的调节信息 (0)
2009年04月7号 &#8212; TCP/IP协议的分层(4) (1)
2009年10月7号 &#8212; RFC890:外部网关协议执行表 (0)
2009年04月17号 &#8212; DDOS案列分析 (0)
2009年11月26号 &#8212; RFC1112_主机扩展用于IP多点传送 (0)
2009年04月23号 &#8212; tcp协议与 udp协议的区别 [...]]]></description>
			<content:encoded><![CDATA[<p>&#160;</p>
<p><b>摘要</b><b></b></p>
<p>点到点协议（the Point-to-Point Protocol）提供了一种在点到点链路上封装网络层协议信息的标准方法。PPP 也定义了可扩展的链路控制协议(Link Control Protocol)，它（Link Control Protocol）使用验证协议磋商在链路上传输网络层协议前验证链路的对端。</p>
<p>这个文档定义了两种验证协议：密码验证协议（the Password Authentication Protocol）和挑战－握手验证协议（the Challenge-Handshake Authentication Protocol）。此RFC是IETF(the Internet Engineering Task Force)的PPP协议工作组的成果。</p>
<p>&#160;</p>
<h4>介绍</h4>
<p>PPP 有三个主要的组成部分：</p>
<p>1．在串行链路上封装数据报（datagrams）的方法。</p>
<p>2．建立，配置和测试数据链路链接（the data-link connection）的LCP协议（Link Control Protocol）。</p>
<p>3．建立和配置不同网络层协议的一组NCP协议（Network Control Protocol）。</p>
<p>为了在点到点链路（point-to-point link）上建立通信，PPP链路的一端必须在建立阶段（Establishment phase）首先发送LCP包（packets）配置数据链路。在链路建立后，在进入到网络层协议阶段前，PPP提供一个可选择的验证阶段。</p>
<p>默认的，身份验证不是强制的。如果希望进行链路的身份验证，则实现者必须在建立阶段指明身份验证－协议配置选项。</p>
<p>这些协议主要是为通过交换网（switched circuits）或者拨号线(dial-up lines)连接到PPP网络服务器的主机和路由器服务的，但是也可以被用到专用链路（dedicated links）中。服务器在为网络层磋商选择选项时可以对连接的主机或路由器进行身份验证。</p>
<p>此文档定义了PPP身份验证协议。链路建立和验证阶段，和验证协议配置选项定义在PPP协议中[1]。</p>
<h5>要求说明书</h5>
<p>在本文档中，用以下几个词来表示说明书的要求，这些词一般以大写字体书写。</p>
<p>MUST</p>
<p>这个词表示在此说明书中是绝对要求的。</p>
<p>MUST NOT</p>
<p>这个词组表示在此说明书中是绝对禁止的。</p>
<p>SHOULD</p>
<p>此词表示在此说明书中是推荐的。</p>
<p>MAY</p>
<p>此词表示在此说明书中是可选的。</p>
<h5>术语</h5>
<p>本文档中，频繁使用以下术语：</p>
<p>authenticator――验证者：</p>
<p>要求验证的链路端点。验证者说明了在链路建立阶段使用的验证协议。</p>
<p>Peer――点到点链路的另一端：</p>
<p>正在被验证者验证的一端。</p>
<p>Silently discard――静静地丢弃</p>
<p>丢弃packet而不进行进一步的处理。执行（这个动作）应该提供记录错误，包括丢弃packet的内容，的容量，并且应该在一个统计计数器中记录这一事件。</p>
<p>点击下载：<a title="点击下载RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议_中文版" href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1134-chinese.pdf">[PDF]RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议_中文版</a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年10月12号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-481" title="RFC917:因特网子网">RFC917:因特网子网 (0)</a></li>
<li>2009年10月22号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-484" title="RFC932:子网地址分配方案">RFC932:子网地址分配方案 (0)</a></li>
<li>2009年11月26号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-510" title="RFC1112_主机扩展用于IP多点传送">RFC1112_主机扩展用于IP多点传送 (0)</a></li>
<li>2009年04月15号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-280" title="链路层-压缩的SLIP">链路层-压缩的SLIP (0)</a></li>
<li>2009年05月9号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-401" title="RFC 2764：IP VPN的框架体系">RFC 2764：IP VPN的框架体系 (2)</a></li>
<li>2009年10月2号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-471" title="RFC862:回声协议">RFC862:回声协议 (0)</a></li>
<li>2009年10月24号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-486" title="RFC948_IP 数据包通过IEEE 802.3 网络传输的两种方法">RFC948_IP 数据包通过IEEE 802.3 网络传输的两种方法 (0)</a></li>
<li>2009年02月21号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-168" title="TCP/IP协议的分层">TCP/IP协议的分层 (0)</a></li>
<li>2009年09月12号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-460" title="RFC792:Internet 控制信息协议">RFC792:Internet 控制信息协议 (0)</a></li>
<li>2009年04月24号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-349" title="链路层-路径MTU">链路层-路径MTU (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-515/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1132_802．2分组在IPX网络上传输的标准</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-514</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-514#comments</comments>
		<pubDate>Fri, 11 Dec 2009 14:20:45 +0000</pubDate>
		<dc:creator>toadadmin2</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-514</guid>
		<description><![CDATA[&#160;
简介
本规范的目的在于在IPX网络上实现兼容和共用的Internet分组传输，如Internet协议[3]（IP）、地址解析协议[4]（ARP）以及无连接方式的网络协议[5]（CLNP）。
IPX是Novell继承Xerox的Internet数据报协议[6]（IDP）而开发的私有标准。按照RFC 1042[7]的描述，以另外的802.X物理层标准为基础，通过定义在IPX上IEEE802.2数据链路层标准的封装可以传输IP数据报。本文档主要讨论这一RFC在IPX网络上的实现。
描述
一般而言，本规范使IPX网络可以支持任何能够使用IEEE802.2数据链路层规范的网络协议。
更明确地讲，IPX网络可以用于支持IP网络和任何类型的子网。通过把IP数据报封装进IPX数据报，并且为IPX网络上的主机分配IP号，这些主机也可以支持基于IP的应用。具有在802.IPX数据报内封装IP分组能力的IP网关允许IPX网络上的这些主机与Internet通讯。
点击下载：[PDF]RFC1132_802．2分组在IPX网络上传输的标准_中文版
相关文章

2009年10月13号 &#8212; RFC925:多局域网地址解决 (0)
2009年04月7号 &#8212; TCP/IP协议的分层(4) (1)
2009年11月7号 &#8212; 简单网络，智能边缘 (0)
2009年06月5号 &#8212; RFC 697：FTP的CWD命令 (1)
2009年09月14号 &#8212; RFC826:以太网地址转换协议或转换网络协议地址 (0)
2009年04月20号 &#8212; 链路层-环回接口 (0)
2009年04月17号 &#8212; DDOS案列分析 (0)
2009年10月29号 &#8212; RFC962_TCP-4 的最初 (0)
2010年06月1号 &#8212; ip协议的作用 (0)
2009年05月8号 &#8212; RFC 2105：Cisco 系统的标签交换体系结构纵览 (0)

]]></description>
			<content:encoded><![CDATA[<p>&#160;</p>
<h2>简介</h2>
<p>本规范的目的在于在IPX网络上实现兼容和共用的Internet分组传输，如Internet协议[3]（IP）、地址解析协议[4]（ARP）以及无连接方式的网络协议[5]（CLNP）。</p>
<p>IPX是Novell继承Xerox的Internet数据报协议[6]（IDP）而开发的私有标准。按照RFC 1042[7]的描述，以另外的802.X物理层标准为基础，通过定义在IPX上IEEE802.2数据链路层标准的封装可以传输IP数据报。本文档主要讨论这一RFC在IPX网络上的实现。</p>
<h2>描述</h2>
<p>一般而言，本规范使IPX网络可以支持任何能够使用IEEE802.2数据链路层规范的网络协议。</p>
<p>更明确地讲，IPX网络可以用于支持IP网络和任何类型的子网。通过把IP数据报封装进IPX数据报，并且为IPX网络上的主机分配IP号，这些主机也可以支持基于IP的应用。具有在802.IPX数据报内封装IP分组能力的IP网关允许IPX网络上的这些主机与Internet通讯。</p>
<p>点击下载：<a href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1132-chinese.pdf">[PDF]RFC1132_802．2分组在IPX网络上传输的标准_中文版</a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年06月1号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-426" title="RFC 348：放弃过程">RFC 348：放弃过程 (2)</a></li>
<li>2009年10月27号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-490" title="RFC955_朝向一个处理过程应用的传输服务">RFC955_朝向一个处理过程应用的传输服务 (0)</a></li>
<li>2009年11月5号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-497" title="今天的Internet">今天的Internet (0)</a></li>
<li>2009年05月13号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-408" title="RFC 3032： MPLS标记栈编码">RFC 3032： MPLS标记栈编码 (1)</a></li>
<li>2009年05月4号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-381" title="RFC 2003：在IP内封装IP">RFC 2003：在IP内封装IP (0)</a></li>
<li>2009年09月21号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-468" title="RFC859:Telnet状态选项">RFC859:Telnet状态选项 (0)</a></li>
<li>2009年02月19号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-150" title="什么是TCP/IP协议">什么是TCP/IP协议 (0)</a></li>
<li>2009年05月13号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-414" title="QQ通信原理逐步解析日记">QQ通信原理逐步解析日记 (2)</a></li>
<li>2009年04月29号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-363" title="什么是ARP攻击(2)？">什么是ARP攻击(2)？ (0)</a></li>
<li>2009年04月18号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-300" title="链路层-PPP：点对点协议（2）">链路层-PPP：点对点协议（2） (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-514/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1131_OSPF规范</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-512</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-512#comments</comments>
		<pubDate>Thu, 03 Dec 2009 14:02:29 +0000</pubDate>
		<dc:creator>toad</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-512</guid>
		<description><![CDATA[介绍
本文档是关于最短路径优先（OSPF）互联网路由协议的规范。OSPF归为内部网关协议（IGP），意味着它在单个自治系统内的路由间分发路由信息。OSPF协议基于SPF或链接状态技术，这与基于Bellman-Ford的传统路由协议（距离向量）是不同的。
OSPF协议是由Internet工程任务组的OSPF工作组开发，它专为互联网环境设计，明确支持IP子网，基于TOS（服务类型）的路由和由外部驱动触发的路由信息。OSPF提供路由更新身份确认，利用IP组播传送/接收更新。另外，大量的工作是实现用最少的路由协议传送，达到在网络拓朴改变时快速响应的协议。
作者感谢Rob Coltun，Milo Medin，Mike Petry 和其它为OSPF工作组提供建议和对这个项目提供支持的人们。
&#160;协议概述
OSPF路由IP包只基于IP包头中的目的IP地址和IP服务类别。IP包被路由，即当包在自治系统内传输时不封闭任何更多的协议头。OSPF是一个动态路由协议，它可以快速确定在自治系统内的拓朴改变及在一个收敛周期内计算出新的无回路路由。这个收敛周期很短，只有少量的路由通信。
在一个基于SPF路由协议中，每一个路由器管理一个描述自治系统拓朴的数据库。每个参于的路由器有相同的数据库，数据库中的每条是一个路由器详细的本地状态（如路由器使用的接口和可以到达的邻居）。路由器使用洪泛通过自治系统分发它的本地状态。
所有的路由器并行执行同样的算法，每个路由器通过拓朴数据库以自己为根构造一个最短路径树，这个最短路径树给出在自治系统内到每个目的地的路由。外部驱动的路由信息的为树的叶结点。
OSPF对每一种服务类型（TOS）单独计算路由，当到一个目的地存在多条相等代价的路由时，通信将在他们之间平分。路由的代价是用一种简单的无尺寸度量的。
OSPF允许多个网络组成一个组，这个组叫做区域，一个区域中的拓朴信息对自治系统的其它区域是不可见的。这种信息隐藏能够减少相当多的路由通信。另外，在一个区域内部路由的确定仅需要区域本身的拓朴信息，主要保护区域内不受坏的路由数据影响。一个区域是一个普通的IP子网网络。
OSPF使用灵活的IP子网配置，OSPF分发的每条路由都含有目的地址和子网掩码。使用同一IP网络号的两个不同子网会有不同的网络尺寸（如不同的掩码）。通常称为可变长子网。包在路由时做最优匹配（使用最长子网掩码）。单机路由可考虑为子网掩码全为1（即0XFFFFFFFF）。
所有的OSPF协议交换是有认证的，即只有信任的路由器能参与自治系统的路由交换，可以使用多种认证方案，一个区域只有使用一种认证方案，这可使一些区域使用比其它区域更严格的认证。
外部驱动的路由信息（如从外部网关协议（EGP）学习的路由）透明地穿过自治系统。这些外部分驱动的路由信息和OSPF协议的链接状态数据是保持分离的。每条外部分路由都被公告路由标记，并在自治系统的边界路由器间传递附加的信息。
点击下载：[PDF]RFC1131_OSPF规范_中文版
相关文章

2009年05月4号 &#8212; RFC 2198：用于冗余音频数据的RTP负载格式 (0)
2010年06月1号 &#8212; ip协议的作用 (0)
2009年05月4号 &#8212; 案例分析-ARP欺骗攻击(3) (0)
2009年02月19号 &#8212; 什么是TCP/IP协议 (0)
2009年09月19号 &#8212; RFC858:Telnet抑制前进选项 (0)
2009年04月21号 &#8212; TCP/IP协议的缩略语解释（1） (0)
2009年04月16号 &#8212; HTTP和HTML概述 (0)
2009年04月14号 &#8212; 链路层-SLIP：串行线路IP (1)
2009年10月30号 &#8212; RFC974_邮件路由与域名系统 (0)
2009年05月9号 &#8212; RFC 2281：Cisco热备份路由协议（HSRP） (0)

]]></description>
			<content:encoded><![CDATA[<p><strong>介绍</strong></p>
<p>本文档是关于最短路径优先（OSPF）互联网路由协议的规范。OSPF归为内部网关协议（IGP），意味着它在单个自治系统内的路由间分发路由信息。OSPF协议基于SPF或链接状态技术，这与基于Bellman-Ford的传统路由协议（距离向量）是不同的。</p>
<p>OSPF协议是由Internet工程任务组的OSPF工作组开发，它专为互联网环境设计，明确支持IP子网，基于TOS（服务类型）的路由和由外部驱动触发的路由信息。OSPF提供路由更新身份确认，利用IP组播传送/接收更新。另外，大量的工作是实现用最少的路由协议传送，达到在网络拓朴改变时快速响应的协议。</p>
<p>作者感谢Rob Coltun，Milo Medin，Mike Petry 和其它为OSPF工作组提供建议和对这个项目提供支持的人们。</p>
<p>&#160;<strong>协议概述</strong></p>
<p>OSPF路由IP包只基于IP包头中的目的IP地址和IP服务类别。IP包被路由，即当包在自治系统内传输时不封闭任何更多的协议头。OSPF是一个动态路由协议，它可以快速确定在自治系统内的拓朴改变及在一个收敛周期内计算出新的无回路路由。这个收敛周期很短，只有少量的路由通信。</p>
<p>在一个基于SPF路由协议中，每一个路由器管理一个描述自治系统拓朴的数据库。每个参于的路由器有相同的数据库，数据库中的每条是一个路由器详细的本地状态（如路由器使用的接口和可以到达的邻居）。路由器使用洪泛通过自治系统分发它的本地状态。</p>
<p>所有的路由器并行执行同样的算法，每个路由器通过拓朴数据库以自己为根构造一个最短路径树，这个最短路径树给出在自治系统内到每个目的地的路由。外部驱动的路由信息的为树的叶结点。</p>
<p>OSPF对每一种服务类型（TOS）单独计算路由，当到一个目的地存在多条相等代价的路由时，通信将在他们之间平分。路由的代价是用一种简单的无尺寸度量的。</p>
<p>OSPF允许多个网络组成一个组，这个组叫做区域，一个区域中的拓朴信息对自治系统的其它区域是不可见的。这种信息隐藏能够减少相当多的路由通信。另外，在一个区域内部路由的确定仅需要区域本身的拓朴信息，主要保护区域内不受坏的路由数据影响。一个区域是一个普通的IP子网网络。</p>
<p>OSPF使用灵活的IP子网配置，OSPF分发的每条路由都含有目的地址和子网掩码。使用同一IP网络号的两个不同子网会有不同的网络尺寸（如不同的掩码）。通常称为可变长子网。包在路由时做最优匹配（使用最长子网掩码）。单机路由可考虑为子网掩码全为1（即0XFFFFFFFF）。</p>
<p>所有的OSPF协议交换是有认证的，即只有信任的路由器能参与自治系统的路由交换，可以使用多种认证方案，一个区域只有使用一种认证方案，这可使一些区域使用比其它区域更严格的认证。</p>
<p>外部驱动的路由信息（如从外部网关协议（EGP）学习的路由）透明地穿过自治系统。这些外部分驱动的路由信息和OSPF协议的链接状态数据是保持分离的。每条外部分路由都被公告路由标记，并在自治系统的边界路由器间传递附加的信息。</p>
<p>点击下载：<a title="点击下载RFC1131_OSPF规范_中文版" href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1131-chinese.pdf" target="_blank">[PDF]RFC1131_OSPF规范_中文版</a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年05月1号 &#8212; <a href="http://tcpip.info-weblog.org/ip-protocol-371" title="网络层-IP首部">网络层-IP首部 (0)</a></li>
<li>2009年02月23号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-185" title="TCP/IP协议的分层(2)">TCP/IP协议的分层(2) (0)</a></li>
<li>2009年04月19号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-305" title="链路层-PPP：点对点协议（3）">链路层-PPP：点对点协议（3） (2)</a></li>
<li>2009年04月23号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-329" title="TCP/IP协议的缩略语解释（2）">TCP/IP协议的缩略语解释（2） (0)</a></li>
<li>2009年05月13号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-414" title="QQ通信原理逐步解析日记">QQ通信原理逐步解析日记 (2)</a></li>
<li>2009年11月23号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-508" title="RFC1096_Telnet X 显示定位选项">RFC1096_Telnet X 显示定位选项 (0)</a></li>
<li>2009年04月21号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-320" title="【转自CSDN】PPPoE协议（RFC+2516）中文版">【转自CSDN】PPPoE协议（RFC+2516）中文版 (1)</a></li>
<li>2009年10月3号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-472" title="RFC868:时间协议">RFC868:时间协议 (0)</a></li>
<li>2009年10月6号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-475" title="RFC888：&ldquo;烟头&rdquo;外部网关协议">RFC888：&ldquo;烟头&rdquo;外部网关协议 (0)</a></li>
<li>2009年10月27号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-490" title="RFC955_朝向一个处理过程应用的传输服务">RFC955_朝向一个处理过程应用的传输服务 (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-512/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-511</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-511#comments</comments>
		<pubDate>Fri, 27 Nov 2009 14:32:52 +0000</pubDate>
		<dc:creator>toad</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-511</guid>
		<description><![CDATA[&#160;
介绍
本文档定义了为在internet上传输的电子邮件提供保密增强服务的消息编码和鉴别的过程。是四个相关文档中的一篇。在当前的RFC中定义的步骤试图与各种密钥管理方法保持兼容，包括加密密钥的数据加密的对称（秘钥）和非对称（公钥）方法。并预见了消息文本加密的对称密码系统的使用和／或完整性检查计算。RFC-1114规定了支持基于公钥证书使用的密钥管理机制。RFC-1115规定了算法和与当前文档和RFC-1114相关的信息。后续的RFC将提供被建立的密钥基础设施的详细的报告和电子格式和过程以支持这些服务。
保密增强服务（机密性、可鉴别性、消息完整性保证）是通过发送者和接受者用户进程之间的端对端的加密系统提供的，没有特殊的处理要求强加于端点的消息传输系统或中继站。这种方法容许保密增强功能被结合到一个站对站或用户对用户的基础之上，不会影响其他的网络实体。支持不同种类的的组件和邮件传输工具之间的互操作性。
2. 术语
为了描述的目的，本RFC文档使用了定义在OSI X.400消息处理系统（1984年经CCITT推荐）模型里的术语。这部分复制了X.400 2.2.1小节的部分内容，“MHS模型的描述：总览”为了使不熟悉OSI MHS模型的的读者清楚的理解这个术语。
在MHS模型中，一个用户是一个人或一个计算机应用。一个用户要么作为发送者要么作为接收者（当正在接收）。MH服务元素定义了一组消息类型和一个发送者传送这些类型消息给一个或多个接收者的能力。
一个发送者在他或她的用户代理的帮助下准备消息。一个用户代理（UA）是一个和传送消息的消息传输系统（MTS）相互影响的应用进程。这个MTS向一个或多个接受者的用户代理传送消息。只是被用户代理操作而没有标准化为一个MH服务元素的一部分的功能被称为本地用户代理功能。
MTS有大量的消息传送代理（MTAs）组成。在一起操作，MTAs转送消息将它们传送给目的接收用户代理，通过这些代理使消息对于目的接受者可用。
UAs和MTAs总称为消息处理系统（MHS）。MHS和它的所有用户作为消息处理环境。
3. 服务、约束和暗示
本文档定义了增强电子邮件在网络上保密传送的机制。在本文档中讨论的功能提供了基于发送者和接收者用户代理的端对端的系统保密增强服务。没有保密增强被提供给通过中间节点转发和增加的消息域。
鉴别和完整性功能总是应用到整个消息文本，没有不通过鉴别的机密性功能，加密功能可以有选择的应用到消息的内容部分；这允许在接收者的个人密钥缺失的情况下消息不太敏感的部分（例如，描述域）被接收者的代理处理。在有些情况下，消息整体被排除在加密之外，这一特色可以用于不含机密性的鉴别和完整性服务的有效组合。
为了和internet的不同支持者和使用模式保持一致，定义在文档中的各种方法可以应用到internet主机和使用范例的广泛的范围。特别下面的属性值得注意：
1． 定义在文档中的机制没有限制针对特殊的主机或操作系统，但是允许在大量系统间的互操作性。所有的保密增强在应用层实现，不依赖于底层协议的任何保密特色。
2． 被定义的机制和非增强的网络组件相兼容。保密增强在端到端的风格中中间转发的主机不影响邮件的处理，中间的主机没有加入保密增强功能。然而消息的发送者识别接收者是否实现保密增强，为了编码。可能加密不会被用于没有对应转换的消息的目的地。
3． 定义的机制是和一些的邮件传输功能相兼容的。在Internet内，电子邮件传输受各种SMTP的实现影响。一定的站点凭借SMTP可获取，传送邮件到其他的邮件处理环境（例如 USENET，CSNET，BITNET）。 保密增强必须能通过SMTP领域操作；也要求与在SMTP环境和其他连接环境的电子邮件发送保护相一致。
4． 定义的机制和大范围的电子邮件用户代理相一致。各种各样的被用在internet电子邮件用户代理程序，和相应范围的用户接口范例。为了使电子邮件保密性增强最大可能的应用于用户交互，所选择的机制应该对于最大可能的各种存在UA程序可用。对于引导实现的目的，要求保密增强处理被组合成一个单独的程序，对于大多数的UAs可用，而不是去修改每一个提供保密增强服务的每个UA。
5． 定义的机制允许电子邮件保密增强处理被操作在个人电脑上独立于不同的UA功能被实现的系统。给定PCs扩展的使用和被放置在许多多用户系统的UA实现的信任程度，这个属性能允许许多用户以比一个严格基于UA的方法所能允许保证级高的级别来处理保密增强邮件。
6． 定义的机制支持电子邮件定位的邮件列表保密保护（分发列表，ISO用语）。
7． 定义在本文档中的机制和各种支持的密钥管理方法相兼容，包括（未限制）手工的预分发，基于对称密码的密钥分发，和公钥证书的使用。不同的密钥管理机制可以被用于一个广播消息的不同接收者。而为了与本文档的兼容性支持一个特殊的密钥管理机制不是最小的必要的要求，强烈推荐采用定义在RFC-1114中的公钥证书方法。
为了获得对于最大可能范围的网络主机和邮件系统的适用性，便利引导实现和测试而无须预先修改整个网络，在本文挡中考虑了影响一组方法的三个基本的限制：
1．方法将被限制于在端点的实现并将受用户代理级等完整性的影响，而不必集成到消息传输系统（例如，SMTP服务）。
2．被支持的方法增强而不是限制用户的能力。被信任的实现，包含完整性特色保护软件不被本地用户颠覆，不能做一般的假设。在这样的特色缺少的情况下，提供增强对用户服务的便利（例如，通过保护和鉴别中间用户交互）显然比增强对用户行为限制（内部用户获取控制）更加可行。
3．被支持的一组方法集中于一组被选择提供广大用户社区重要的和切实的利益的功能。通过集中最关键的服务组，我们旨在通过普通的实现努力最大化被增加的保密值。
由于这些限制，能提供下面的功能：
1．解密保护，
2．发送者鉴别，
3．消息完整性方法，
4．（如果使用非对称密钥管理）来源不可否认，
但是下面的与保密相关的影响未提到：
1．获取控制，
2．通信流机密性，
3．地址列表的正确性，
4．路由控制，
5．发布关于被多个用户偶尔连续重用的PC机，
6．消息和他们所要访问的的内容的自动确认，
7．消息复制检测，重放阻止，或其它的面向流的服务。
消息的发送者将决定是否对特定的消息进行保密增强服务。因此，一个发送者必须能决定是否接收者具有处理保密增强邮件的能力。在一个一般的结构中，这些机制将基于服务器的查询；因此，查询功能能被集成到一个UA避免增加电子邮件使用者的负担或不便。
 点击下载：[PDF]RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤_中文版
相关文章

2009年10月10号 &#8212; RFC895：IP 数据包通过试验性以太网网络的传输标准 (0)
2009年04月11号 &#8212; 链路层-协议首部（1） (1)
2009年09月17号 &#8212; RFC855:Telnet选项说明书 (0)
2009年10月26号 &#8212; RFC951_引导协议(BOOTP) (0)
2009年04月29号 &#8212; 什么是ARP攻击(2)？ (0)
2009年02月23号 &#8212; TCP/IP协议的分层(2) (0)
2009年10月12号 &#8212; RFC917:因特网子网 (0)
2009年10月25号 &#8212; RFC949_FTP 未公开的独特命令 (0)
2009年11月25号 &#8212; RFC1097_Telnet潜意识-信息选项 (0)
2009年11月14号 &#8212; RFC1088_IP 数据包传输通过NetBIOS网络的标准 (0)

]]></description>
			<content:encoded><![CDATA[<p>&#160;</p>
<h4>介绍</h4>
<p>本文档定义了为在internet上传输的电子邮件提供保密增强服务的消息编码和鉴别的过程。是四个相关文档中的一篇。在当前的RFC中定义的步骤试图与各种密钥管理方法保持兼容，包括加密密钥的数据加密的对称（秘钥）和非对称（公钥）方法。并预见了消息文本加密的对称密码系统的使用和／或完整性检查计算。RFC-1114规定了支持基于公钥证书使用的密钥管理机制。RFC-1115规定了算法和与当前文档和RFC-1114相关的信息。后续的RFC将提供被建立的密钥基础设施的详细的报告和电子格式和过程以支持这些服务。</p>
<p>保密增强服务（机密性、可鉴别性、消息完整性保证）是通过发送者和接受者用户进程之间的端对端的加密系统提供的，没有特殊的处理要求强加于端点的消息传输系统或中继站。这种方法容许保密增强功能被结合到一个站对站或用户对用户的基础之上，不会影响其他的网络实体。支持不同种类的的组件和邮件传输工具之间的互操作性。</p>
<h4><a name="_Toc497363507"></a><a name="_Toc510341602"></a><a name="_2._术语"></a>2. 术语</h4>
<p>为了描述的目的，本RFC文档使用了定义在OSI X.400消息处理系统（1984年经CCITT推荐）模型里的术语。这部分复制了X.400 2.2.1小节的部分内容，“MHS模型的描述：总览”为了使不熟悉OSI MHS模型的的读者清楚的理解这个术语。</p>
<p>在MHS模型中，一个用户是一个人或一个计算机应用。一个用户要么作为发送者要么作为接收者（当正在接收）。MH服务元素定义了一组消息类型和一个发送者传送这些类型消息给一个或多个接收者的能力。</p>
<p>一个发送者在他或她的用户代理的帮助下准备消息。一个用户代理（UA）是一个和传送消息的消息传输系统（MTS）相互影响的应用进程。这个MTS向一个或多个接受者的用户代理传送消息。只是被用户代理操作而没有标准化为一个MH服务元素的一部分的功能被称为本地用户代理功能。</p>
<p>MTS有大量的消息传送代理（MTAs）组成。在一起操作，MTAs转送消息将它们传送给目的接收用户代理，通过这些代理使消息对于目的接受者可用。</p>
<p>UAs和MTAs总称为消息处理系统（MHS）。MHS和它的所有用户作为消息处理环境。</p>
<h4><a name="_Toc497363508"></a><a name="_Toc510341603"></a><a name="_3.__服务、约束和暗示"></a>3. 服务、约束和暗示</h4>
<p>本文档定义了增强电子邮件在网络上保密传送的机制。在本文档中讨论的功能提供了基于发送者和接收者用户代理的端对端的系统保密增强服务。没有保密增强被提供给通过中间节点转发和增加的消息域。</p>
<p>鉴别和完整性功能总是应用到整个消息文本，没有不通过鉴别的机密性功能，加密功能可以有选择的应用到消息的内容部分；这允许在接收者的个人密钥缺失的情况下消息不太敏感的部分（例如，描述域）被接收者的代理处理。在有些情况下，消息整体被排除在加密之外，这一特色可以用于不含机密性的鉴别和完整性服务的有效组合。</p>
<p>为了和internet的不同支持者和使用模式保持一致，定义在文档中的各种方法可以应用到internet主机和使用范例的广泛的范围。特别下面的属性值得注意：</p>
<p>1． 定义在文档中的机制没有限制针对特殊的主机或操作系统，但是允许在大量系统间的互操作性。所有的保密增强在应用层实现，不依赖于底层协议的任何保密特色。</p>
<p>2． 被定义的机制和非增强的网络组件相兼容。保密增强在端到端的风格中中间转发的主机不影响邮件的处理，中间的主机没有加入保密增强功能。然而消息的发送者识别接收者是否实现保密增强，为了编码。可能加密不会被用于没有对应转换的消息的目的地。</p>
<p>3． 定义的机制是和一些的邮件传输功能相兼容的。在Internet内，电子邮件传输受各种SMTP的实现影响。一定的站点凭借SMTP可获取，传送邮件到其他的邮件处理环境（例如 USENET，CSNET，BITNET）。 保密增强必须能通过SMTP领域操作；也要求与在SMTP环境和其他连接环境的电子邮件发送保护相一致。</p>
<p>4． 定义的机制和大范围的电子邮件用户代理相一致。各种各样的被用在internet电子邮件用户代理程序，和相应范围的用户接口范例。为了使电子邮件保密性增强最大可能的应用于用户交互，所选择的机制应该对于最大可能的各种存在UA程序可用。对于引导实现的目的，要求保密增强处理被组合成一个单独的程序，对于大多数的UAs可用，而不是去修改每一个提供保密增强服务的每个UA。</p>
<p>5． 定义的机制允许电子邮件保密增强处理被操作在个人电脑上独立于不同的UA功能被实现的系统。给定PCs扩展的使用和被放置在许多多用户系统的UA实现的信任程度，这个属性能允许许多用户以比一个严格基于UA的方法所能允许保证级高的级别来处理保密增强邮件。</p>
<p>6． 定义的机制支持电子邮件定位的邮件列表保密保护（分发列表，ISO用语）。</p>
<p>7． 定义在本文档中的机制和各种支持的密钥管理方法相兼容，包括（未限制）手工的预分发，基于对称密码的密钥分发，和公钥证书的使用。不同的密钥管理机制可以被用于一个广播消息的不同接收者。而为了与本文档的兼容性支持一个特殊的密钥管理机制不是最小的必要的要求，强烈推荐采用定义在RFC-1114中的公钥证书方法。</p>
<p>为了获得对于最大可能范围的网络主机和邮件系统的适用性，便利引导实现和测试而无须预先修改整个网络，在本文挡中考虑了影响一组方法的三个基本的限制：</p>
<p>1．方法将被限制于在端点的实现并将受用户代理级等完整性的影响，而不必集成到消息传输系统（例如，SMTP服务）。</p>
<p>2．被支持的方法增强而不是限制用户的能力。被信任的实现，包含完整性特色保护软件不被本地用户颠覆，不能做一般的假设。在这样的特色缺少的情况下，提供增强对用户服务的便利（例如，通过保护和鉴别中间用户交互）显然比增强对用户行为限制（内部用户获取控制）更加可行。</p>
<p>3．被支持的一组方法集中于一组被选择提供广大用户社区重要的和切实的利益的功能。通过集中最关键的服务组，我们旨在通过普通的实现努力最大化被增加的保密值。</p>
<p>由于这些限制，能提供下面的功能：</p>
<p>1．解密保护，</p>
<p>2．发送者鉴别，</p>
<p>3．消息完整性方法，</p>
<p>4．（如果使用非对称密钥管理）来源不可否认，</p>
<p>但是下面的与保密相关的影响未提到：</p>
<p>1．获取控制，</p>
<p>2．通信流机密性，</p>
<p>3．地址列表的正确性，</p>
<p>4．路由控制，</p>
<p>5．发布关于被多个用户偶尔连续重用的PC机，</p>
<p>6．消息和他们所要访问的的内容的自动确认，</p>
<p>7．消息复制检测，重放阻止，或其它的面向流的服务。</p>
<p>消息的发送者将决定是否对特定的消息进行保密增强服务。因此，一个发送者必须能决定是否接收者具有处理保密增强邮件的能力。在一个一般的结构中，这些机制将基于服务器的查询；因此，查询功能能被集成到一个UA避免增加电子邮件使用者的负担或不便。</p>
<p> 点击下载：<a title="点击下载RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤_中文版" href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1113-chinese.pdf" target="_blank">[PDF]RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤_中文版</a><br />
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年09月19号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-467" title="RFC858:Telnet抑制前进选项">RFC858:Telnet抑制前进选项 (0)</a></li>
<li>2009年11月10号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-501" title="RFC1073_Telnet窗口大小选项">RFC1073_Telnet窗口大小选项 (0)</a></li>
<li>2009年10月30号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-492" title="RFC974_邮件路由与域名系统">RFC974_邮件路由与域名系统 (0)</a></li>
<li>2009年04月16号 &#8212; <a href="http://tcpip.info-weblog.org/http-protocol-284" title="HTTP和HTML概述">HTTP和HTML概述 (0)</a></li>
<li>2009年05月7号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-395" title="RFC 1997：BGP团体属性">RFC 1997：BGP团体属性 (0)</a></li>
<li>2009年11月15号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-505" title="RFC1090_SMTP在X.25">RFC1090_SMTP在X.25 (0)</a></li>
<li>2009年09月14号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-462" title="RFC826:以太网地址转换协议或转换网络协议地址">RFC826:以太网地址转换协议或转换网络协议地址 (0)</a></li>
<li>2009年10月25号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-488" title="RFC949_FTP 未公开的独特命令">RFC949_FTP 未公开的独特命令 (0)</a></li>
<li>2009年10月9号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-477" title="RFC894:IP 数据包通过以太网网络传输标准">RFC894:IP 数据包通过以太网网络传输标准 (0)</a></li>
<li>2009年09月22号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-470" title="RFC861:Telnet扩展选项列表选项">RFC861:Telnet扩展选项列表选项 (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-511/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1112_主机扩展用于IP多点传送</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-510</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-510#comments</comments>
		<pubDate>Thu, 26 Nov 2009 13:51:01 +0000</pubDate>
		<dc:creator>toad</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-510</guid>
		<description><![CDATA[&#160;
简介
IP多播是指一个IP数据报向一个主机组的传送，该主机组是由一个单独的IP目的地址标记的多个或零个主机。一个多播数据报被尽可能地传递给它的目的主机组的所有成员，就像常规的单播IP数据报一样。也就是说，不能保证数据报能完好无损的到达目的组所有成员，也不能保证它以相对于其它数据报同样的顺序到达。
主机组的成员是动态变化的；也就是说，主机可以随意加入和离开组。对一个主机组的位置和组成员的数量并没有限制。一个主机可以同时是一个或多个组的成员。不是某一组的成员的主机也能向该组发送数据报。
主机组可以是永久的或是暂时的。永久组是一个众所周知的，由Internet管理机构分配的IP地址，它的地址是永久的，而该组的成员是可以改变的。在任意时刻，一个永久组可以有任意数量的成员，甚至没有成员。另外一些不是为永久组保留的IP多播地址是为暂时组动态分配的地址，这些暂时组只有当它们有成员时才存在。
IP多播数据报的网间传递是通过“多播路由器”实现的，多播路由器可以驻留在互联网网关上，也可以与互联网网关分离。主机以本地网络多播的方式传送IP多播数据报，这些数据报只到达目的主机组中所有与该主机直接邻近的成员。如果数据报的IP首部中的生存时间(TTL)字段大于1，则在本地网络上的一个或多个多播路由器负责将它传递到有目的主机组的成员的其他网络上。在那些可以在IP生存时间为零以前到达的其它成员网络里，当地一个多播路由器以本地多播的方式传递该数据报来完成传送。
该备忘录说明了为了支持IP多播而对主机的IP实现的扩展，这里的“主机”是除了用作多播路由器以外的任何互联网主机和网关。用在多播路由器内和之间的算法和协议对主机是透明的，将在独立的文档中说明。该备忘录也不说明本地网络多播是如何在所有不同类型的网络中实现的，尽管它说明了任意的本地网络所需的服务界面，并给出了一个以太网技术要求说明作为例子。其他类型的网络技术说明将会在将来的备忘录中说明。
&#160;
点击下载：[PDF]RFC1112_主机扩展用于IP多点传送_中文版
相关文章

2009年02月19号 &#8212; 什么是TCP/IP协议 (0)
2009年05月10号 &#8212; RFC 894：IP 数据包通过以太网网络传输标准 (0)
2009年11月1号 &#8212; RFC975_自治联邦 (0)
2009年10月7号 &#8212; RFC890:外部网关协议执行表 (0)
2009年10月4号 &#8212; RFC872:局域网上的TCP协议 (0)
2009年05月4号 &#8212; RFC 2198：用于冗余音频数据的RTP负载格式 (0)
2009年04月28号 &#8212; 什么是ARP攻击？ (0)
2009年05月16号 &#8212; 【转帖】QQ协议分析之TCPF包结构 (2)
2009年04月8号 &#8212; 链路层-入门篇 (0)
2009年11月18号 &#8212; RFC1094_NFS网络文件系统协议说明书 (0)

]]></description>
			<content:encoded><![CDATA[<p>&#160;</p>
<h4>简介</h4>
<p>IP多播是指一个IP数据报向一个主机组的传送，该主机组是由一个单独的IP目的地址标记的多个或零个主机。一个多播数据报被尽可能地传递给它的目的主机组的所有成员，就像常规的单播IP数据报一样。也就是说，不能保证数据报能完好无损的到达目的组所有成员，也不能保证它以相对于其它数据报同样的顺序到达。</p>
<p>主机组的成员是动态变化的；也就是说，主机可以随意加入和离开组。对一个主机组的位置和组成员的数量并没有限制。一个主机可以同时是一个或多个组的成员。不是某一组的成员的主机也能向该组发送数据报。</p>
<p>主机组可以是永久的或是暂时的。永久组是一个众所周知的，由Internet管理机构分配的IP地址，它的地址是永久的，而该组的成员是可以改变的。在任意时刻，一个永久组可以有任意数量的成员，甚至没有成员。另外一些不是为永久组保留的IP多播地址是为暂时组动态分配的地址，这些暂时组只有当它们有成员时才存在。</p>
<p>IP多播数据报的网间传递是通过“多播路由器”实现的，多播路由器可以驻留在互联网网关上，也可以与互联网网关分离。主机以本地网络多播的方式传送IP多播数据报，这些数据报只到达目的主机组中所有与该主机直接邻近的成员。如果数据报的IP首部中的生存时间(TTL)字段大于1，则在本地网络上的一个或多个多播路由器负责将它传递到有目的主机组的成员的其他网络上。在那些可以在IP生存时间为零以前到达的其它成员网络里，当地一个多播路由器以本地多播的方式传递该数据报来完成传送。</p>
<p>该备忘录说明了为了支持IP多播而对主机的IP实现的扩展，这里的“主机”是除了用作多播路由器以外的任何互联网主机和网关。用在多播路由器内和之间的算法和协议对主机是透明的，将在独立的文档中说明。该备忘录也不说明本地网络多播是如何在所有不同类型的网络中实现的，尽管它说明了任意的本地网络所需的服务界面，并给出了一个以太网技术要求说明作为例子。其他类型的网络技术说明将会在将来的备忘录中说明。</p>
<p>&#160;</p>
<p>点击下载：<a title="点击下载RFC1112_主机扩展用于IP多点传送_中文版" href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1112-chinese.pdf" target="_blank">[PDF]RFC1112_主机扩展用于IP多点传送_中文版</a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年11月25号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-509" title="RFC1097_Telnet潜意识-信息选项">RFC1097_Telnet潜意识-信息选项 (0)</a></li>
<li>2009年05月1号 &#8212; <a href="http://tcpip.info-weblog.org/case-analysis-377" title="案例分析-ARP欺骗攻击">案例分析-ARP欺骗攻击 (0)</a></li>
<li>2009年12月16号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-517" title="RFC1144_低速串行链路上的TCPIP头部压缩">RFC1144_低速串行链路上的TCPIP头部压缩 (0)</a></li>
<li>2009年09月15号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-463" title="RFC854:Telnet协议说明书">RFC854:Telnet协议说明书 (0)</a></li>
<li>2009年09月17号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-464" title="RFC855:Telnet选项说明书">RFC855:Telnet选项说明书 (0)</a></li>
<li>2009年12月13号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-515" title="RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议">RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议 (0)</a></li>
<li>2009年10月30号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-492" title="RFC974_邮件路由与域名系统">RFC974_邮件路由与域名系统 (0)</a></li>
<li>2009年11月17号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-506" title="RFC1091_TELNET终端类型选项">RFC1091_TELNET终端类型选项 (0)</a></li>
<li>2009年05月9号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-401" title="RFC 2764：IP VPN的框架体系">RFC 2764：IP VPN的框架体系 (2)</a></li>
<li>2009年02月23号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-185" title="TCP/IP协议的分层(2)">TCP/IP协议的分层(2) (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-510/feed</wfw:commentRss>
		</item>
		<item>
		<title>RFC1097_Telnet潜意识-信息选项</title>
		<link>http://tcpip.info-weblog.org/chinese-rfc-509</link>
		<comments>http://tcpip.info-weblog.org/chinese-rfc-509#comments</comments>
		<pubDate>Wed, 25 Nov 2009 14:05:42 +0000</pubDate>
		<dc:creator>toad</dc:creator>
		
		<category><![CDATA[中文RFC]]></category>

		<guid isPermaLink="false">http://tcpip.info-weblog.org/chinese-rfc-509</guid>
		<description><![CDATA[&#160;
命令名和代码
SUBLIMINAL-MESSAGE 257
命令含义
IAC WILL SUBLIMINAL-MESSAGE
这个命令的发送者需要允许来，或是确认它将显示潜意识信息。
IAC WONT SUBLIMINAL-MESSAGE
命令的发送者拒绝显示潜意识信息。
IAC DO SUBLIMINAL-MESSAGE
命令的发送者需要接收者，或是承认接受者的允许来显示潜意识信息。
IAC DONT SUBLIMINAL-MESSAGE
命令的发送者要求接收者不显示潜意识信息。
IAC SB SUBLIMINAL-MESSAGE &#60;16-bit value&#62; &#60;16-bit value&#62; &#60;string&#62; IAC SE
发送者定义了一条通过远程的服务器潜意识地显示的信息。如果客户端已经同意（通过标准WILL WONT DO DONT机制）来显示潜意识信息，它必须接受这个潜在的商议并尝试在定义持续时间的用户控制台上显示信息字符串，而且不需在固定间隔内持续地显示，直到接收到另一个潜意识-信息潜在商议。执行信息的位置和描述具有依赖性。
第一个16-bit值定义了毫秒级的信息持续时间。它是先发送MSB。第二个16-bit值定义了信息显示所伴随的频率。它描述了在现实之间的秒数，而且也是先发送MSB。最后的参数是信息本身。
这个潜在商定的语法是：
IAC SB SUBLIMINAL-MESSAGE
DURATION[1] DURATION[0]
FREQUENCY[1] FREQUENCY[0]
MESSAGE_STRING
IAC SE
就像按照Telnet协议需求一样，任何在潜在商议中的255的出现必须加倍以便与IAC字符（值是255）区别开。
&#160;
点击下载：[PDF]RFC1097_Telnet潜意识-信息选项_中文版
相关文章

2009年05月9号 &#8212; RFC 2281：Cisco热备份路由协议（HSRP） (0)
2009年12月11号 &#8212; RFC1132_802．2分组在IPX网络上传输的标准 (0)
2009年05月2号 &#8212; 案例分析-ARP欺骗攻击(2) (0)
2009年04月17号 &#8212; DDOS案列分析 (0)
2009年05月4号 &#8212; RFC 2198：用于冗余音频数据的RTP负载格式 (0)
2009年05月27号 &#8212; RFC 20：用于网络交换的 ASCII 格式 (2)
2009年10月13号 &#8212; RFC925:多局域网地址解决 (0)
2009年10月7号 &#8212; RFC890:外部网关协议执行表 [...]]]></description>
			<content:encoded><![CDATA[<p>&#160;</p>
<h4><a name="_Toc499730461">命令名和代码</a></h4>
<p>SUBLIMINAL-MESSAGE 257</p>
<h4><a name="_Toc499730462">命令含义</a></h4>
<p>IAC WILL SUBLIMINAL-MESSAGE</p>
<p>这个命令的发送者需要允许来，或是确认它将显示潜意识信息。</p>
<p>IAC WONT SUBLIMINAL-MESSAGE</p>
<p>命令的发送者拒绝显示潜意识信息。</p>
<p>IAC DO SUBLIMINAL-MESSAGE</p>
<p>命令的发送者需要接收者，或是承认接受者的允许来显示潜意识信息。</p>
<p>IAC DONT SUBLIMINAL-MESSAGE</p>
<p>命令的发送者要求接收者不显示潜意识信息。</p>
<p>IAC SB SUBLIMINAL-MESSAGE &lt;16-bit value&gt; &lt;16-bit value&gt; &lt;string&gt; IAC SE</p>
<p>发送者定义了一条通过远程的服务器潜意识地显示的信息。如果客户端已经同意（通过标准WILL WONT DO DONT机制）来显示潜意识信息，它必须接受这个潜在的商议并尝试在定义持续时间的用户控制台上显示信息字符串，而且不需在固定间隔内持续地显示，直到接收到另一个潜意识-信息潜在商议。执行信息的位置和描述具有依赖性。</p>
<p>第一个16-bit值定义了毫秒级的信息持续时间。它是先发送MSB。第二个16-bit值定义了信息显示所伴随的频率。它描述了在现实之间的秒数，而且也是先发送MSB。最后的参数是信息本身。</p>
<p>这个潜在商定的语法是：</p>
<p>IAC SB SUBLIMINAL-MESSAGE</p>
<p>DURATION[1] DURATION[0]</p>
<p>FREQUENCY[1] FREQUENCY[0]</p>
<p>MESSAGE_STRING</p>
<p>IAC SE</p>
<p>就像按照Telnet协议需求一样，任何在潜在商议中的255的出现必须加倍以便与IAC字符（值是255）区别开。</p>
<p>&#160;</p>
<p>点击下载：<a title="点击下载RFC1097_Telnet潜意识-信息选项_中文版" href="http://tcpip.info-weblog.org/pdf-download/chinese/RFC1097-chinese.pdf" target="_blank">[PDF]RFC1097_Telnet潜意识-信息选项_中文版</a></p>
<h3>相关文章</h3>
<ul class="related_post">
<li>2009年11月12号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-502" title="RFC1075_远距离矢量多播选路协议">RFC1075_远距离矢量多播选路协议 (0)</a></li>
<li>2009年11月17号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-506" title="RFC1091_TELNET终端类型选项">RFC1091_TELNET终端类型选项 (0)</a></li>
<li>2009年04月20号 &#8212; <a href="http://tcpip.info-weblog.org/protocol-basic-309" title="链路层-环回接口">链路层-环回接口 (0)</a></li>
<li>2009年10月12号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-481" title="RFC917:因特网子网">RFC917:因特网子网 (0)</a></li>
<li>2009年10月29号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-491" title="RFC962_TCP-4 的最初">RFC962_TCP-4 的最初 (0)</a></li>
<li>2009年11月1号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-493" title="RFC975_自治联邦">RFC975_自治联邦 (0)</a></li>
<li>2009年10月3号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-472" title="RFC868:时间协议">RFC868:时间协议 (0)</a></li>
<li>2009年09月17号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-464" title="RFC855:Telnet选项说明书">RFC855:Telnet选项说明书 (0)</a></li>
<li>2009年05月4号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-389" title="RFC 2198：用于冗余音频数据的RTP负载格式">RFC 2198：用于冗余音频数据的RTP负载格式 (0)</a></li>
<li>2009年09月15号 &#8212; <a href="http://tcpip.info-weblog.org/chinese-rfc-463" title="RFC854:Telnet协议说明书">RFC854:Telnet协议说明书 (0)</a></li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://tcpip.info-weblog.org/chinese-rfc-509/feed</wfw:commentRss>
		</item>
	</channel>
</rss>

