📄 287.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://apue.dhs.org"><font face="黑体"><big><big>apue</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> ● UNIX网络编程 (BM: clown) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="index.htm">回到开始</a>][<a href="193.htm">上一层</a>][<a href="288.htm">下一篇</a>]
<hr><p align="left"><small> SOCKS: A protocol for TCP proxy across firewalls <br>
<br>
Ying-Da Lee <br>
Principal Member Technical Staff <br>
NEC Systems Laboratory, CSTC <br>
ylee@syl.dl.nec.com <br>
<br>
SOCKS was originally developed by David Koblas and subsequently modified <br>
and extended by me to its current running version -- version 4. It is a <br>
protocol that relays TCP sessions at a firewall host to allow application <br>
users transparent access across the firewall. Because the protocol is <br>
independent of application protocols, it can be (and has been) used for <br>
many different services, such as telnet, ftp, finger, whois, gopher, WWW, <br>
etc. Access control can be applied at the beginning of each TCP session; <br>
thereafter the server simply relays the data between the client and the <br>
application server, incurring minimum processing overhead. Since SOCKS <br>
never has to know anything about the application protocol, it should also <br>
be easy for it to accommodate applications which use encryption to protect <br>
their traffic from nosey snoopers. <br>
<br>
Two operations are defined: CONNECT and BIND. <br>
<br>
1) CONNECT <br>
1) CONNECT <br>
<br>
The client connects to the SOCKS server and sends a CONNECT request when <br>
it wants to establish a connection to an application server. The client <br>
includes in the request packet the IP address and the port number of the <br>
destination host, and userid, in the following format. <br>
<br>
+----+----+----+----+----+----+----+----+----+----+....+----+ <br>
| VN | CD | DSTPORT | DSTIP | USERID |NULL| <br>
+----+----+----+----+----+----+----+----+----+----+....+----+ <br>
# bytes: 1 1 2 4 variable 1 <br>
<br>
VN is the SOCKS protocol version number and should be 4. CD is the <br>
SOCKS command code and should be 1 for CONNECT request. NULL is a byte <br>
of all zero bits. <br>
<br>
The SOCKS server checks to see whether such a request should be granted <br>
based on any combination of source IP address, destination IP address, <br>
destination port number, the userid, and information it may obtain by <br>
consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS <br>
server makes a connection to the specified port of the destination host. <br>
A reply packet is sent to the client when this connection is established, <br>
or when the request is rejected or the operation fails. <br>
<br>
+----+----+----+----+----+----+----+----+ <br>
| VN | CD | DSTPORT | DSTIP | <br>
+----+----+----+----+----+----+----+----+ <br>
# of bytes: 1 1 2 4 <br>
<br>
VN is the version of the reply code and should be 0. CD is the result <br>
code with one of the following values: <br>
<br>
90: request granted <br>
91: request rejected or failed <br>
92: request rejected becasue SOCKS server cannot connect to <br>
identd on the client <br>
93: request rejected because the client program and identd <br>
report different user-ids <br>
<br>
The remaining fields are ignored. <br>
<br>
The SOCKS server closes its connection immediately after notifying <br>
the client of a failed or rejected request. For a successful request, <br>
the SOCKS server gets ready to relay traffic on both directions. This <br>
enables the client to do I/O on its connection as if it were directly <br>
connected to the application server. <br>
<br>
<br>
2) BIND <br>
<br>
The client connects to the SOCKS server and sends a BIND request when <br>
it wants to prepare for an inbound connection from an application server. <br>
This should only happen after a primary connection to the application <br>
server has been established with a CONNECT. Typically, this is part of <br>
the sequence of actions: <br>
<br>
-bind(): obtain a socket <br>
-getsockname(): get the IP address and port number of the socket <br>
-listen(): ready to accept call from the application server <br>
-use the primary connection to inform the application server of <br>
the IP address and the port number that it should connect to. <br>
-accept(): accept a connection from the application server <br>
<br>
The purpose of SOCKS BIND operation is to support such a sequence <br>
but using a socket on the SOCKS server rather than on the client. <br>
<br>
The client includes in the request packet the IP address of the <br>
application server, the destination port used in the primary connection, <br>
and the userid. <br>
<br>
+----+----+----+----+----+----+----+----+----+----+....+----+ <br>
| VN | CD | DSTPORT | DSTIP | USERID |NULL| <br>
+----+----+----+----+----+----+----+----+----+----+....+----+ <br>
# bytes: 1 1 2 4 variable 1 <br>
<br>
VN is again 4 for the SOCKS protocol version number. CD must be 2 to <br>
indicate BIND request. <br>
<br>
The SOCKS server uses the client information to decide whether the <br>
request is to be granted. The reply it sends back to the client has <br>
the same format as the reply for CONNECT request, i.e., <br>
<br>
+----+----+----+----+----+----+----+----+ <br>
| VN | CD | DSTPORT | DSTIP | <br>
+----+----+----+----+----+----+----+----+ <br>
# of bytes: 1 1 2 4 <br>
<br>
VN is the version of the reply code and should be 0. CD is the result <br>
code with one of the following values: <br>
<br>
90: request granted <br>
91: request rejected or failed <br>
92: request rejected becasue SOCKS server cannot connect to <br>
identd on the client <br>
93: request rejected because the client program and identd <br>
report different user-ids. <br>
<br>
However, for a granted request (CD is 90), the DSTPORT and DSTIP fields <br>
are meaningful. In that case, the SOCKS server obtains a socket to wait <br>
for an incoming connection and sends the port number and the IP address <br>
of that socket to the client in DSTPORT and DSTIP, respectively. If the <br>
DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the <br>
client should replace it by the IP address of the SOCKS server to which <br>
the cleint is connected. (This happens if the SOCKS server is not a <br>
multi-homed host.) In the typical scenario, these two numbers are <br>
made available to the application client prgram via the result of the <br>
subsequent getsockname() call. The application protocol must provide a <br>
way for these two pieces of information to be sent from the client to <br>
the application server so that it can initiate the connection, which <br>
connects it to the SOCKS server rather than directly to the application <br>
<br>
client as it normally would. <br>
<br>
The SOCKS server sends a second reply packet to the client when the <br>
anticipated connection from the application server is established. <br>
The SOCKS server checks the IP address of the originating host against <br>
the value of DSTIP specified in the client's BIND request. If a mismatch <br>
is found, the CD field in the second reply is set to 91 and the SOCKS <br>
server closes both connections. If the two match, CD in the second <br>
reply is set to 90 and the SOCKS server gets ready to relay the traffic <br>
on its two connections. From then on the client does I/O on its connection <br>
to the SOCKS server as if it were directly connected to the application <br>
server. <br>
<br>
<br>
<br>
For both CONNECT and BIND operations, the server sets a time limit <br>
(2 minutes in current CSTC implementation) for the establishment of its <br>
connection with the application server. If the connection is still not <br>
establiched when the time limit expires, the server closes its connection <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="193.htm">上一层</a>][<a href="288.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -