组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-<br />
pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：Radeon（Radeon&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bise@cmmail.com）<br />
译文发布时间：2001-6-18<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，<br />
但必须保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group	M.&nbsp;Leech<br />
Request&nbsp;for&nbsp;Comments:1929	Bell-Northern&nbsp;Research&nbsp;Ltd<br />
Category:&nbsp;Standard&nbsp;Track	M.&nbsp;Ganis<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&nbsp;International&nbsp;Business&nbsp;Machines<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Lee<br />
	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;NEC&nbsp;Systems&nbsp;Laboratory<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;Kuris<br />
	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Unify&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D.&nbsp;Koblas<br />
	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Independent&nbsp;Consultant<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Jones<br />
	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hewlett-Packard&nbsp;Company<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	March&nbsp;1996<br />
<br />
SOCKS&nbsp;V5<br />
<br />
本备忘录状态：<br />
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以<br />
得到改进。请参考最新版的“Internet正式协议标准”&nbsp;(STD1)来获得本协议的标准化程度和状<br />
态。本备忘录的发布不受任何限制。<br />
知识背景<br />
这个备忘录描述了从同一协议的前一版本(版本4[1])发展而来的一个协议。这个新的协议起<br />
源于当前的一些讨论和原型的实现(active&nbsp;discussions&nbsp;and&nbsp;prototype&nbsp;implementations)。关键的贡<br />
献人有：Marcus&nbsp;Leech:&nbsp;Bell-Northern&nbsp;Research,&nbsp;David&nbsp;Koblas:&nbsp;Independent&nbsp;Consultant,&nbsp;Ying-Da&nbsp;<br />
Lee:&nbsp;NEC&nbsp;Systems&nbsp;Laboratory,&nbsp;LaMont&nbsp;Jones:&nbsp;Hewlett-Packard&nbsp;Company,&nbsp;Ron&nbsp;Kuris:&nbsp;Unify&nbsp;<br />
Corporation,&nbsp;Matt&nbsp;Ganis:&nbsp;International&nbsp;Business&nbsp;Machines。<br />
<br />
目录<br />
<br />
1.介绍	2<br />
2．现有的协议	2<br />
3．基于TCP协议的客户	3<br />
4．请求	3<br />
5．地址	4<br />
6．应答	4<br />
7．基于UDP协议的客户	6<br />
8.&nbsp;&nbsp;安全性考虑	7<br />
9.&nbsp;&nbsp;参考书目	7<br />
<br />
1.介绍<br />
利用网络防火墙可以将组织内部的网络结构从外部网络如INTERNET中有效地隔离，这种方法<br />
在许多网络系统中正变得流行起来。这种防火墙系统通常以应用层网关的形式工作在两个网络之<br />
间，提供TELNET、FTP、SMTP等的接入。随着越来越多的使全球信息查找更容易的复杂的应用层协<br />
议的出现，有必要提供一个通用框架来使这些协议安全透明地穿过防火墙。而且在实际应用中还需<br />
要一种安全的认证方式用以穿越防火墙。这个要求起源于两个组织的网络中客户/服务器关系的出<br />
现，这个关系需要得到控制并要求有安全的认证。<br />
在这儿所描述的协议框架是为了让使用TCP和UDP的客户/服务器应用程序更方便安全地使用<br />
网络防火墙所提供的服务所设计的。这个协议从概念上来讲是介于应用层和传输层之间的“中介层<br />
(shim-layer)”，因而不提供如传递ICMP信息之类由网络层网关的所提供的服务。<br />
<br />
<br />
2．现有的协议<br />
当前存在一个协议SOCKS&nbsp;4，它为TELNET、FTP、HTTP、WAIS和GOPHER等基于TCP协议的客<br />
户/服务器程序提供了一个不安全的防火墙。而这个新的协议扩展了SOCKS&nbsp;V4，以使其支持UDP、<br />
框架规定的安全认证方案、地址解析方案(addressing&nbsp;scheme)中所规定的域名和IPV6。为了实现<br />
这个SOCKS协议，通常需要重新编译或者重新链接基于TCP的客户端应用程序以使用SOCKS库中相<br />
应的加密函数。<br />
注意：<br />
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如<br />
果某域需要给定一个字节的值，用X'hh'来表示这个字节中的值。如果某域中用到单<br />
词'Variable'，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1&nbsp;–&nbsp;2<br />
个字节）的域中，或一个数据类型域中。<br />
<br />
<br />
3．基于TCP协议的客户<br />
当一个基于TCP协议的客户端希望与一个只能通过防火墙可以到达的目标(这是由实现所决定<br />
的)建立连接，它必须先建立一个与SOCKS服务器上SOCKS端口的TCP连接。通常这个TCP端口是<br />
1080。当连接建立后，客户端进入协议的“握手(negotiation)”过程：认证方式的选择，根据选<br />
中的方式进行认证，然后发送转发的要求。SOCKS服务器检查这个要求，根据结果，或建立合适的<br />
连接，或拒绝。<br />
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如果某<br />
域需要给定一个字节的值，用X'hh'来表示这个字节中的值。如果某域中用到单<br />
词'Variable'，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1&nbsp;–&nbsp;2个<br />
字节）的域中，或一个数据类型域中。<br />
客户端连到服务器后，然后就发送请求来协商版本和认证方法：<br />
<br />
VER<br />
NMETHODS<br />
METHODS<br />
1<br />
1<br />
1&nbsp;to&nbsp;255<br />
这个版本的SOCKS协议中，VER字段被设置成X'05'。NMETHODS字段包含了在METHODS字段中<br />
出现的方法标示的数目（以字节为单位）。<br />
服务器从这些给定的方法中选择一个并发送一个方法选中的消息回客户端：<br />
VER<br />
METHOD<br />
1<br />
1<br />
如果选中的消息是X'FF'，这表示客户端所列出的方法列表中没有一个方法被选中，客户端<br />
必须关闭连接。<br />
当前定义的方法有：<br />
?	X'00'		不需要认证<br />
?	X'01'&nbsp;&nbsp;&nbsp;		GSSAPI<br />
?	X'02'&nbsp;&nbsp;&nbsp;		用户名/密码<br />
?	X'03'&nbsp;--&nbsp;X'7F'&nbsp;&nbsp;	由IANA分配<br />
?	X'80'&nbsp;--&nbsp;X'FE'&nbsp;	为私人方法所保留的<br />
?	X'FF'&nbsp;&nbsp;&nbsp;	&nbsp;	没有可以接受的方法<br />
然后客户和服务器进入由选定认证方法所决定的子协商过程(sub-negotiation)。各种不同的<br />
方法的子协商过程的描述请参考各自的备忘录。<br />
开发者如果要为自己的方法得到一个方法号，可以联系IANA。可以参考关于已经被分配号码<br />
的文档以得到当前所有方法的列表和相应的协议。<br />
符合本文档的SOCKS&nbsp;V5实现必须支持GSSAPI，并且在将来支持用户名/密码认证方式。<br />
<br />
<br />
4．请求<br />
一旦子协商过程结束后，客户端就发送详细的请求信息。如果协商的方法中有以完整性检查和<br />
/或安全性为目的的封装，这些请求必须按照该方法所定义的方式进行封装。<br />
SOCKS请求的格式如下：<br />
VER<br />
CMD<br />
RSV&nbsp;&nbsp;<br />
ATYP<br />
DST.ADDR<br />
DST.PORT<br />
1<br />
1<br />
X'00'<br />
1<br />
Variable<br />
2<br />
	其中<br />
?	VER&nbsp;&nbsp;&nbsp;&nbsp;协议版本:&nbsp;X'05'<br />
?	CMD<br />
?	CONNECT：X'01'<br />
?	BIND：X'02'<br />
?	UDP&nbsp;ASSOCIATE：X'03'<br />
?	RSV&nbsp;&nbsp;&nbsp;&nbsp;保留<br />
?	ATYP&nbsp;&nbsp;&nbsp;后面的地址类型<br />
?	IPV4：X'01'<br />
?	域名：X'03'<br />
?	IPV6：X'04''<br />
?	DST.ADDR&nbsp;&nbsp;&nbsp;目的地址<br />
?	DST.PORT&nbsp;&nbsp;&nbsp;以网络字节顺序出现的端口号<br />
SOCKS服务器会根据源地址和目的地址来分析请求，然后根据请求类型返回一个或多个应答。<br />
<br />
5．地址<br />
ATYP字段中描述了地址字段(DST.ADDR，BND.ADDR)所包含的地址类型：<br />
?	X'01'<br />
基于IPV4的IP地址，4个字节长<br />
?	X'03'<br />
基于域名的地址，地址字段中的第一字节是以字节为单位的该域名的长度，没有结尾的NUL字<br />
节。<br />
?	X'04'<br />
基于IPV6的IP地址，16个字节长<br />
<br />
<br />
6．应答<br />
一旦建立了一个到SOCKS服务器的连接，并且完成了认证方式的协商过程，客户机将会发送一<br />
个SOCKS请求信息给服务器。服务器将会根据请求，以如下格式返回：<br />
VER<br />
REP<br />
RSV<br />
ATYP<br />
BND.ADDR<br />
BND.PORT<br />
1<br />
1<br />
X'00'<br />
1<br />
Variable<br />
2<br />
&nbsp;&nbsp;&nbsp;其中：<br />
?	VER&nbsp;&nbsp;&nbsp;&nbsp;协议版本:&nbsp;X'05'<br />
?	REP&nbsp;&nbsp;&nbsp;&nbsp;应答字段:<br />
?	X'00'&nbsp;	成功<br />
?	X'01'&nbsp;	普通的SOCKS服务器请求失败<br />
?	X'02'&nbsp;	现有的规则不允许的连接<br />
?	X'03'&nbsp;	网络不可达<br />
?	X'04'&nbsp;	主机不可达<br />
?	X'05'	连接被拒<br />
?	X'06'&nbsp;	TTL超时<br />
?	X'07'&nbsp;	不支持的命令<br />
?	X'08'&nbsp;	不支持的地址类型<br />
?	X'09'&nbsp;–&nbsp;X'FF'&nbsp;	未定义<br />
?	RSV&nbsp;&nbsp;&nbsp;&nbsp;保留<br />
?	ATYP&nbsp;&nbsp;&nbsp;后面的地址类型<br />
?	IPV4：X'01'<br />
?	域名：X'03'<br />
?	IPV6：X'04'<br />
?	BND.ADDR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;服务器绑定的地址<br />
?	BND.PORT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;以网络字节顺序表示的服务器绑定的段口<br />
标识为RSV的字段必须设为X'00'。<br />
如果选中的方法中有以完整性检查和/或安全性为目的的封装，这些应答必须按照该方法所定<br />
义的方式进行封装。<br />
<br />
CONNECT<br />
在对一个CONNECT命令的应答中，BND.PORT包含了服务器分配的用来连到目标机的端口号，<br />
BND.ADDR则是相应的IP地址。由于SOCKS服务器通常有多个IP，应答中的BND.ADDR常和客户端<br />
连到SOCKS服务器的那个IP不同。<br />
SOCKS服务器可以利用DST.ADDR和DST.PORT，以及客户端源地址和端口来对一个CONNECT请<br />
求进行分析。<br />
<br />
BIND<br />
BIND请求通常被用在那些要求客户端接受来自服务器的连接的协议上。FTP是一个典型的例<br />
子。它建立一个从客户端到服务器端的连接来执行命令以及接收状态的报告，而使用另一个从服务<br />
器到客户端的连接来接收传输数据的要求(如LS，GET，PUT)。<br />
建议只有在一个应用协议的客户端在使用CONNECT命令建立主连接后才可以使用BIND命令建<br />
立第二个连接。建议SOCKS服务器使用DST.ADDR和DST.PORT来评价BIND请求。<br />
在一个BIND请求的操作过程中，SOCKS服务器要发送两个应答给客户端。当服务器建立并绑<br />
定一个新的套接口时发送第一个应答。BND.PORT字段包含SOCKS服务器用来监听进入的连接的端<br />
口号，BAND.ADDR字段包含了对应的IP地址。客户端通常使用这些信息来告诉（通过主连接或控<br />
制连接）应用服务器连接的汇接点。第二个应答仅发生在所期望到来的连接成功或失败之后。在第<br />
二个应答中，BND.PORT和BND.ADDR字段包含了连上来的主机的IP地址和端口号。<br />
<br />
UDP&nbsp;ASSOCIATE<br />
UDP&nbsp;ASSOCIATE请求通常是要求建立一个UDP转发进程来控制到来的UDP数据报。DST.ADDR和<br />
DST.PORT&nbsp;字段包含客户端所希望的用来发送UDP数据报的IP地址和端口号。服务器可以使用这个<br />
信息来限制进入的连接。如果客户端在发送这个请求时没有地址和端口信息，客户端必须用全0来<br />
填充。<br />
当与UDP相应的TCP连接中断时，该UDP连接也必须中断。<br />
应答UDP&nbsp;ASSOCIATE请求时，BND.PORT&nbsp;和BND.ADDR字段指明了客户发送UDP消息至服务器的<br />
端口和地址。<br />
<br />
应答处理	<br />
当一个应答(REP值不等于00)指明出错时，SOCKS服务器必须在发送完应答消息后一小段时间<br />
内终止TCP连接。这段时间应该在发现错误后少于10秒。<br />
如果一个应答(REP值等于00)指明成功，并且请求是一个BIND或CONNECT时，客户端就可以<br />
开始发送数据了。如果协商的认证方法中有以完整性、认证和/或安全性为目的的封装，这些请求<br />
必须按照该方法所定义的方式进行封装。类似的，当以客户机为目的地的数据到达SOCKS服务器<br />
时，SOCKS服务器必须用正在使用的方法对这些数据进行封装。<br />
<br />
<br />
7．基于UDP协议的客户<br />
在UDP&nbsp;ASSOCIATE应答中由BND.PORT指明了服务器所使用的UDP端口，一个基于UDP协议的<br />
客户必须发送数据报至UDP转发服务器的该端口上。如果协商的认证方法中有以完整性、认证和/<br />
或安全性为目的的封装，这些数据报必须按照该方法所定义的方式进行封装。每个UDP数据报都有<br />
一个UDP请求头在其首部：<br />
RSV<br />
FRAG<br />
ATYP<br />
DST.ADDR<br />
DST.PORT<br />
DATA<br />
2<br />
1<br />
1<br />
Variable<br />
2<br />
Variable<br />
在UDP请求头中的字段是：<br />
<br />
?	RSV&nbsp;&nbsp;保留&nbsp;X'0000'<br />
?	FRAG&nbsp;&nbsp;&nbsp;&nbsp;当前的分段号<br />
?	ATYP&nbsp;&nbsp;&nbsp;后面的地址类型<br />
?	IPV4：X'01'<br />
?	域名：X'03'<br />
?	IPV6：X'04'<br />
?	DST.ADDR&nbsp;&nbsp;&nbsp;目的地址<br />
?	DST.PORT&nbsp;&nbsp;&nbsp;以网络字节顺序出现的端口号<br />
?	DATA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;用户数据<br />
当一个UDP转发服务器转发一个UDP数据报时，不会发送任何通知给客户端；同样，它也将丢<br />
弃任何它不能发至远端主机的数据报。当UDP转发服务器从远端服务器收到一个应答的数据报时，<br />
必须加上上述UDP请求头，并对数据报进行封装。<br />
UDP转发服务器必须从SOCKS服务器得到期望的客户端IP地址，并将数据报发送到UDP&nbsp;<br />
ASSOCIATE应答中给定的端口号。如果数据报从任何IP地址到来，而该IP地址与该特定连接中指<br />
定的IP地址不同，那么该数据报会被丢弃。<br />
FRAG字段指明数据报是否是一些分片中的一片。如果SOCKS服务器要实现这个功能，X'00'<br />
指明数据报是独立的；其他则越大越是数据报的尾端。介于1到127之间的值说明了该分片在分片<br />
序列里的位置。每个接收者都为这些分片提供一个重组队列和一个重组的计时器。这个重组队列必<br />
须在重组计时器超时后重新初始化，并丢弃相应的数据报。或者当一个新到达的数据报有一个比当<br />
前在处理的数据报序列中最大的FRAG值要小时，也必须重新初始化从组队列。重组计时器必须小<br />
于5秒。只要有可能，应用程序最好不要使用分片。<br />
分片的实现是可选的；如果某实现不支持分片，所有FRAG字段不为0的数据报都必须被丢<br />
弃。<br />
一个SOCKS的UDP编程界面(The&nbsp;programming&nbsp;interface&nbsp;for&nbsp;a&nbsp;SOCKS-aware&nbsp;UDP)必须报告<br />
当前可用UDP数据报缓存空间小于操作系统提供的实际空间。<br />
?	如果&nbsp;ATYP是&nbsp;X'01'&nbsp;-&nbsp;10+method_dependent&nbsp;octets&nbsp;smaller<br />
?	如果&nbsp;ATYP是X'03'&nbsp;-&nbsp;262+method_dependent&nbsp;octets&nbsp;smaller<br />
?	如果&nbsp;ATYP是X'04'&nbsp;-&nbsp;20+method_dependent&nbsp;octets&nbsp;smaller<br />
<br />
8.&nbsp;&nbsp;安全性考虑&nbsp;<br />
这篇文档描述了一个用来透过IP网络防火墙的应用层协议。这种传输的安全性在很大程度上<br />
依赖于特定实现所拥有以及在SOCKS客户与SOCKS服务器之间经协商所选定的特殊的认证和封装方<br />
式。<br />
系统管理员需要对用户认证方式的选择进行仔细考虑。<br />
<br />
<br />
9.&nbsp;&nbsp;参考书目<br />
<br />
&nbsp;&nbsp;&nbsp;[1]&nbsp;Koblas,&nbsp;D.,&nbsp;"SOCKS",&nbsp;Proceedings:&nbsp;1992&nbsp;Usenix&nbsp;Security&nbsp;Symposium.<br />
<br />
<br />
作者地址<br />
Marcus&nbsp;Leech<br />
Bell-Northern&nbsp;Research&nbsp;Ltd<br />
P.O.&nbsp;Box&nbsp;3511,&nbsp;Station&nbsp;C<br />
Ottawa,&nbsp;ON<br />
CANADA&nbsp;K1Y&nbsp;4H7<br />
Phone:&nbsp;(613)&nbsp;763&nbsp;-&nbsp;9145<br />
EMail:&nbsp;mleech@bnr.ca<br />
RFC1929——SOCKETS&nbsp;V5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SOCKETS&nbsp;V5<br />
RFC文档中文翻译计划<br />