java - 파일 전송

Development/Java 2013. 4. 4. 19:26


sender.java

#####################################################################

import java.io.File;

import java.io.FileInputStream;

import java.io.IOException;

import java.io.OutputStream

import java.net.ServerSocket;

import java.net.Socket;

 

public class sender {

public static void main(String[] args) throws IOException {

ServerSocket ss = new ServerSocket(8000);

Socket socket = ss.accept();

OutputStream os = socket.getOutputStream();

 

File file = new File("./sender.avi");

FileInputStream fis = new FileInputStream(file);

int readCount = 0;

byte[] buffer = new byte[4096];

 

while((readCount = fis.read(buffer))>0){

os.write(buffer, 0, readCount);

}

 

System.out.println(");

os.close();

fis.close();

 

 

}

}

[출처] 자바 파일전송|작성자 우왕귿


receive.java

#####################################################################

import java.io.File;

import java.io.FileOutputStream;

import java.io.IOException;

import java.io.InputStream;

import java.net.Socket;

import java.net.UnknownHostException;

 

public class receiver extends Thread {

Socket socket = null

File file = null

FileOutputStream fos = null

InputStream is = null

 

public receiver() throws UnknownHostException, IOException {

socket = new Socket("127.0.0.1", 8000);

file = new File("./receiver.avi");

fos = new FileOutputStream(file);

is = socket.getInputStream();

}

 

public static void main(String[] args) throwsUnknownHostException,

IOException {

receiver r = new receiver();

 

int readCount = 0;

byte[] buffer = new byte[4096];

r.start();

while ((readCount = r.is.read(buffer)) > 0) {

r.fos.write(buffer, 0, readCount);

}

System.out.println(");

r.is.close();

r.fos.close();

r.stop()

}

 

public void run() {

File file = new File("./receiver.avi");

long curr = 0;

long before = 0;

while (true) {

if (file.exists()) {

try {

Thread.sleep(1000);

curr = file.length();

System.out

.println((double) ((((curr - before) / 1024)) / 1024));

before = curr;

 

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}

}

}

[출처] 자바 파일전송|작성자 우왕귿



출처 - http://blog.naver.com/inganyoyo?Redirect=Log&logNo=90072811148





다음은 자바 파일 전송 예제이다.

서버가 파일을 전송하고 클라이언트는 파일을 수신한다.


import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.OutputStream;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Date;
import java.util.Properties;

public class FileSendingService {
 public static final int DEFAULT_PORT = 12346;

 private static final int DEFAULT_BUFFER_SIZE = 1024;

 private static final String CONFIGURATION_FILENAME = "conf/file_sending_service.properties";
 private static final String KEY_FILENAME_TO_SEND = "FILENAME_TO_SEND";

 private final int port;

 private boolean running = false;

 public FileSendingService() {
  this(DEFAULT_PORT);
 }

 public FileSendingService(int port) {
  this.port = port;
 }

 private String getFilenameToSendFromConfiguration() {
  Properties properties = new Properties();
  try {
   properties.load(new FileInputStream(CONFIGURATION_FILENAME));
   return properties.getProperty(KEY_FILENAME_TO_SEND);
  } catch (FileNotFoundException e) {
   e.printStackTrace();
  } catch (IOException e) {
   e.printStackTrace();
  }
  return null;
 }

 public void start() {
  running = true;

  ServerSocket serverSocket = null;
  try {
   serverSocket = new ServerSocket(port);
   System.out.println("This server is listening... (Port: " + port
     + ")");
   while (running) {
    Socket socket = null;
    FileInputStream fis = null;
    OutputStream os = null;
    try {
     socket = serverSocket.accept();

     long startTime = System.currentTimeMillis();
     System.out.println("Start time: " + new Date());

     String filenameToSend = getFilenameToSendFromConfiguration();
     System.out.println("Filename to send: " + filenameToSend
       + ")");

     File fileToSend = new File(filenameToSend);
     long fileSize = fileToSend.length();
     System.out.println("File size: " + (fileSize) + " Byte(s)");

     fis = new FileInputStream(fileToSend);

     InetSocketAddress clientIsa = (InetSocketAddress) socket
       .getRemoteSocketAddress();
     String clientIp = clientIsa.getAddress().getHostAddress();
     int clientPort = clientIsa.getPort();
     System.out.println("A client is connected. (" + clientIp
       + ":" + clientPort + ")");

     os = socket.getOutputStream();
     byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
     int totalReadBytes = 0;
     int readBytes;
     while ((readBytes = fis.read(buffer)) != -1) {
      os.write(buffer, 0, readBytes);

      totalReadBytes += readBytes;
      System.out.println("In progress: " + totalReadBytes
        + "/" + fileSize + " Byte(s) ("
        + (totalReadBytes * 100 / fileSize) + " %)");
     }

     long endTime = System.currentTimeMillis();
     System.out.println("End time: " + new Date());

     long diffTime = endTime - startTime;
     long diffTimeInSeconds = diffTime / 1000;
     System.out.println("Elapsed time: " + diffTimeInSeconds
       + " second(s)");

     System.out.println("Average transfer speed: "
       + (fileSize / diffTime) + " KB/s");
    } catch (IOException e) {
     e.printStackTrace();
    } finally {
     if (fis != null) {
      try {
       fis.close();
      } catch (IOException e) {
       e.printStackTrace();
      }
     }

     if (os != null) {
      try {
       os.close();
      } catch (IOException e) {
       e.printStackTrace();
      }
     }

     if (socket != null) {
      try {
       socket.close();
      } catch (IOException e) {
       e.printStackTrace();
      }
     }
    }
   }
  } catch (IOException e) {
   e.printStackTrace();
  } finally {
   if (serverSocket != null) {
    try {
     serverSocket.close();
    } catch (IOException e) {
     e.printStackTrace();
    }
   }
  }
 }

 public void stop() {
  running = false;
 }

 public static void main(String[] args) {
  FileSendingService fileSendingService = new FileSendingService();
  fileSendingService.start();
 }
}

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.Socket;
import java.net.UnknownHostException;

public class FileReceivingClient {
 private static final int DEFAULT_BUFFER_SIZE = 1024;

 private static final String DEFAULT_SERVER_IP = "localhost";

 private final String serverIp;
 private final int serverPort;
 private final String filenameToReceive;

 public FileReceivingClient(String serverIp, int serverPort,
   String filenameToReceive) {
  this.serverIp = serverIp;
  this.serverPort = serverPort;
  this.filenameToReceive = filenameToReceive;
 }

 public void start() {

  FileOutputStream fos = null;
  Socket socket = null;
  InputStream is = null;
  try {
   fos = new FileOutputStream(filenameToReceive);

   System.out.println("This client is connecting to " + serverIp + ":"
     + serverPort + "...");
   socket = new Socket(serverIp, serverPort);
   System.out.println("This client is Connected.");

   is = socket.getInputStream();
   byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
   int readBytes;
   while ((readBytes = is.read(buffer)) > 0) {
    fos.write(buffer, 0, readBytes);
   }
   System.out.println("File transfer completed.");

  } catch (UnknownHostException e) {
   e.printStackTrace();
  } catch (IOException e) {
   e.printStackTrace();
  } finally {
   if (fos != null) {
    try {
     fos.close();
    } catch (IOException e) {
     e.printStackTrace();
    }
   }

   if (is != null) {
    try {
     is.close();
    } catch (IOException e) {
     e.printStackTrace();
    }
   }

   if (socket != null) {
    try {
     socket.close();
    } catch (IOException e) {
     e.printStackTrace();
    }
   }
  }

 }

 public static void main(String[] args) {
  String serverIp = DEFAULT_SERVER_IP;
  int serverPort = FileSendingService.DEFAULT_PORT;
  String filenameToReceive = "received.txt";

  FileReceivingClient fileReceivingClient = new FileReceivingClient(
    serverIp, serverPort, filenameToReceive);
  fileReceivingClient.start();
 }
}


출처 - http://devday.tistory.com/entry/%EC%9E%90%EB%B0%94-Java-%ED%8C%8C%EC%9D%BC-%EC%A0%84%EC%86%A1-File-Transfer-%EC%98%88%EC%A0%9C-Example-Server-Sender-Client-Receiver




다음은 반대로 서버가 파일을 수신하고 클라이언트는 파일을 전송하는 예제이다


import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.net.Socket;

public class FileServer {

 public static void main(String[] args) {
  int port = 10000;

  try {
   ServerSocket ss = new ServerSocket(port);
   System.out.println("This server is listening... (Port: " + port
     + ")");
   Socket socket = ss.accept();
   InetSocketAddress isaClient = (InetSocketAddress) socket
     .getRemoteSocketAddress();
   String clientAddress = isaClient.getAddress().getHostAddress();
   int clientPort = isaClient.getPort();

   System.out.println("A client is connected. (" + clientAddress + ":"
     + clientPort + ")");

   // String filename = "test2.txt";
   String filename = "test2.avi";
   FileOutputStream fos = new FileOutputStream(filename);

   InputStream is = socket.getInputStream();

   // int c;
   // while ((c = is.read()) != -1) {
   // // System.out.println("readByte: " + readByte);
   //
   // fos.write(c);
   // }

   byte[] buffer = new byte[Constants.DEFAULT_BUFFER_SIZE];
   int readBytes;
   while ((readBytes = is.read(buffer)) != -1) {
    fos.write(buffer, 0, readBytes);
   }

   System.out.println("File transfer completed.");

   is.close();
   fos.close();

   socket.close();
   ss.close();
  } catch (IOException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
 }
}



클라이언트

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.net.Socket;
import java.net.UnknownHostException;
import java.util.Date;

public class FileClient {

 public static void main(String[] args) {
  String host = "localhost";
  int port = 10000;

  // String filename = "test.txt";
  String filename = "test.avi";
  File file = new File(filename);
  long fileSize = file.length();
  System.out.println("File size: " + (fileSize) + " Byte(s)");

  try {
   long startTime = System.currentTimeMillis();
   System.out.println("Start time: " + new Date());

   FileInputStream fis = new FileInputStream(file);

   System.out.println("This client is connecting to " + host + ":"
     + port + "...");
   Socket socket = new Socket(host, port);
   System.out.println("This client is Connected.");

   OutputStream os = socket.getOutputStream();

   // int c;
   // while ((c = fis.read()) != -1) {
   // os.write(c);
   // }

   long totalReadBytes = 0;

   byte[] buffer = new byte[Constants.DEFAULT_BUFFER_SIZE];
   int readBytes;
   while ((readBytes = fis.read(buffer)) > 0) {
    os.write(buffer, 0, readBytes);

    totalReadBytes += readBytes;
    System.out.println("In progress: " + totalReadBytes + "/"
      + fileSize + " Byte(s) ("
      + (totalReadBytes * 100 / fileSize) + " %)");
   }

   System.out.println("File transfer completed.");

   fis.close();

   os.close();
   socket.close();

   long endTime = System.currentTimeMillis();
   System.out.println("End time: " + new Date());

   long diffTime = endTime - startTime;
   long diffTimeInSeconds = diffTime / 1000;
   System.out.println("Elapsed time: " + diffTimeInSeconds
     + " second(s)");

   System.out.println("Average transfer speed: " + (fileSize / 1000)
     / diffTimeInSeconds + " KB/s");
  } catch (UnknownHostException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (IOException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
 }
}

출처 - http://devday.tistory.com/entry/%EC%9E%90%EB%B0%94-Java-%ED%8C%8C%EC%9D%BC-%EC%A0%84%EC%86%A1-File-Transfer-%EC%98%88%EC%A0%9C-Example-Server-Receiver-Client-Sender

저작자표시

'Development > Java' 카테고리의 다른 글

java - listener(callback) 만들기 2  (0) 2013.04.08
java - listener 만들기  (0) 2013.04.08
system.out 출력 포맷  (0) 2013.01.31
java - CRC32 클래스  (0) 2013.01.31
serialVersionUID  (0) 2013.01.01
Posted by linuxism
,

file transfer - proxy ip를 잘 못 설정 하는 경우

OpenSource/Openfire 2013. 4. 2. 16:37


FileTransferManager를 통해 파일 전송 시 proxy ip를 잘못 가져올 경우

admin console -> Server Manager -> System Properties 에서 다음 속성을 추가


Property Name : xmpp.proxy.externalip

Property Value : 서버 IP



참조 

http://community.igniterealtime.org/message/183283#183283

http://issues.igniterealtime.org/browse/OF-512

http://community.igniterealtime.org/message/220015

http://community.igniterealtime.org/thread/36064





IM File Transfer Made Easy

Feb 7, 2006
by Matt Tucker

Why do most instant messaging systems get file transfer so wrong? Typically, file transfers don't work reliably (especially when firewalls are involved) and the file transfer UI is non-intuitive with problems like pop-up dialogs and the tiresome hunt to find where a downloaded file disappeared to. For the 1.1 release of the Spark instant messaging client, we set out to end all the frustration.

We began our quest for better file transfer with two major goals:

  1. File transfer has to "just work", every time. Users should never have to worry about how their network is setup or firewall configurations.

  2. Put the "user" into file transfer usability. File transfer is integral to the IM experience, so why throw up pop-up dialogs for sending and receiving files? Drag and drop should work. Overall, the feature should be a pleasure to use.

A Better User Experience

We focused heavily on the file transfer user interface for the Spark 1.1 release. Some of the major areas of improvement over version 1.0 are:

  • All file transfer requests and progress dialogs are embedded into the chat window. After a file is downloaded, you can double click to open it, or browse to the download folder.
  • Dragging files into the chat window now automatically initiates a file transfer.
  • If the file is an image, a thumbnail of that image will be displayed. Otherwise the proper file icon is displayed.
  • Pasting an image into a chat now works (Windows users, try the [Print Screen] button on your keyboard and then [Ctrl-v] in a chat window).

The screen shots below demonstrate sending and receiving files.

Waiting to send a file   File sent   Receiving a file   Receiving a file

Making File Transfer Just Work

All too often (with other IM clients), we've had to give up on a file transfer that fails to connect and resort to sending the file by email. The usual culprit is a firewall or other network setting problems.

The combination of Spark 1.1 and the Openfire (formerly Wildfire) IM server works around file transfer connection issues with a three part file transfer approach. Each approach offers a different balance of speed and reliability -- but the key point is that the transfer method is always negotiated automatically. If one fails, the next approach is tried until the file transfer can proceed.

Each file transfer method is detailed below:

File Transfer Modes

Peer to Peer

Spark will always attempt to establish a peer to peer (p2p) file transfer first. Peer to peer connections are the fastest option and work great when both users are on the same network (such as when they're in the same office location). However, p2p transfers almost always fail when one user is behind a firewall or using NAT (network address translation). Peer to peer file transfers are shown in the top diagram on the right.

Proxy Server

If a peer to peer connection fails, Spark looks for a proxy server to complete the file transfer (the middle diagram on the right). A proxy server is efficient at transferring files, although not as fast as a peer to peer connection. The file transfer will work unless one of the users is behind a strict firewall. Proxy server support is available as an external component now, and will be built into the upcoming Openfire 2.5 release.

In-Band File Transfers

If one of the other two file transfer mechanisms fails, Spark will default to sending the file "in-band" through the IM server by breaking the file into chunks of data and sending them as encoded messages (bottom diagram on the right). This method will work regardless of either user's network configuration but is slower than the other two alternatives. 


출처 - http://www.igniterealtime.org/support/articles/filetransfer.jsp



저작자표시

'OpenSource > Openfire' 카테고리의 다른 글

smack - chat state notification  (0) 2014.11.04
openfire - hessian RMI example in plugin  (0) 2013.08.09
openfire - How to do HTTP binding for Openfire plugin  (0) 2013.08.08
Openfire Properties  (0) 2013.03.12
Posted by linuxism
,

SOCKet Secure (SOCKS)

Security/Common 2013. 4. 2. 14:33


SOCKet Secure (SOCKS) is an Internet protocol that routes network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server will proxy TCP connections to an arbitrary IP address as well as providing a means for UDP packets to be forwarded.

SOCKS performs at Layer 5 of the OSI model—the session layer (an intermediate layer between the presentation layer and the transport layer).

Contents

  [hide] 

[edit]History

The protocol was originally developed by David Koblas, a system administrator of MIPS Computer Systems. After MIPS was taken over by Silicon Graphics in 1992, Koblas presented a paper on SOCKS at that year's Usenix Security Symposium and SOCKS became publicly available.[1] The protocol was extended to version 4 by Ying-Da Lee of NEC.

The SOCKS reference architecture and client are owned by Permeo Technologies[2] a spin-off from NEC. (Blue Coat Systems bought out Permeo Technologies).[3][4]

The SOCKS5 protocol was originally a security protocol that made firewalls and other security products easier to administer. It was approved by the IETF in 1996.[5] The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia.[6]

[edit]Usage

SOCKS is a de facto standard for circuit-level gateways.

Another use of SOCKS is as a circumvention tool, allowing traffic to bypass Internet filtering to access content otherwise blocked by governments, workplaces, schools and country specific web services.[7]

Some SSH suites, such as OpenSSH, support dynamic port forwarding that allows the user to create a local SOCKS proxy.[8] This can free the user from the limitations of connecting only to a predefined remote port and server.

The Tor onion proxy software presents a SOCKS interface to its clients.

[edit]Comparison

SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make and then acts as transparently as possible, whereas an HTTP proxy works for HTTP protocol (at the requesting end, as it can typically do FTP as a retrieval protocol ...). This means that the http proxy interprets and rewrites headers and therefore is not transparent. HTTP is transported over the TCP connection only. HTTP proxies take an HTTP request and forward it to the HTTP server. Though HTTP proxying has a different usage model in mind, the CONNECT[9] method allows one to forward TCP connections, there is however no mechanism for UDP proxying. The following examples show the difference between the two methods:

[edit]SOCKS

Bill wishes to communicate with Jane over the internet, but a firewall exists on his network between them. Bill is not authorized to communicate through it himself. He connects to the SOCKS proxy on his network and sends through it information about the connection he wishes to make to Jane. The SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane. For more information on the technical specifics of the SOCKS protocol, see the sections below.

[edit]HTTP

Bill wishes to download a web page from Jane, who runs a web server. Bill cannot directly connect to Jane's server, as a firewall has been put in place on his network. In order to communicate with the server, Bill connects to his network's HTTP proxy. His web browser communicates with the proxy in exactly the same way it would with the target server—it sends a standard HTTP request header. The HTTP proxy reads the request and looks for the host header. It then connects to the server specified in the header and transmits any data the server replies with back to Bill.[10]

[edit]Interaction with firewalls

Many company and university network administrators set firewall rules that prevent users from connecting to any internet service apart from webpages. Both the SOCKS and HTTP proxy protocols can be used to pierce these firewalls. SOCKS is usually used to create a raw TCP connection, and the HTTP proxy protocol can do the same with the CONNECT method. In both cases a TCP connection is created from the client to the proxy server, and the IP address and port to which the client requests a connection is communicated over the connection. In both cases, the proxy server can grant, reject, redirect and alter connection requests as it likes. HTTP proxies are traditionally more HTTP protocol aware and do more high level filtering (even though that usually only applies to GET and POST methods, not CONNECT). SOCKS proxies can also forward UDP traffic and work in reverse: HTTP proxies cannot.

[edit]Protocol

[edit]SOCKS4

A typical SOCKS4 connection request looks like this:

SOCKS Client to SOCKS Server:

  • field 1: SOCKS version number, 1 byte, must be 0x04 for this version
  • field 2: command code, 1 byte:
    • 0x01 = establish a TCP/IP stream connection
    • 0x02 = establish a TCP/IP port binding
  • field 3: network byte order port number, 2 bytes
  • field 4: network byte order IP address, 4 bytes
  • field 5: the user ID string, variable length, terminated with a null (0x00)

SOCKS Server to SOCKS client:

  • field 1: null byte
  • field 2: status, 1 byte:
    • 0x5a = request granted
    • 0x5b = request rejected or failed
    • 0x5c = request failed because client is not running identd (or not reachable from the server)
    • 0x5d = request failed because client's identd could not confirm the user ID string in the request
  • field 3: 2 arbitrary bytes, that should be ignored
  • field 4: 4 arbitrary bytes, that should be ignored

This is a SOCKS4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK".

  • Client: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
    • The last field is 'Fred' in ASCII, followed by a null byte.
  • Server: 0x00 | 0x5a | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
    • 0xXX can be any byte value. The SOCKS4 protocol specifies the values of these bytes should be ignored.

From this point on any data sent from the SOCKS client to the SOCKS server will be relayed to 66.102.7.99 and vice versa.

The command field can be 0x01 for "connect" or 0x02 for "bind". "bind" allows incoming connections for protocols like active FTP.

[edit]SOCKS4a

SOCKS4a is a simple extension to SOCKS4 protocol that allows a client that cannot resolve the destination host's domain name to specify it.

The client should set the first three bytes of DSTIP to NULL and the last byte to a non-zero value. (This corresponds to IP address 0.0.0.x, with x nonzero, an inadmissible destination address and thus should never occur if the client can resolve the domain name.) Following the NULL byte terminating USERID, the client must send the destination domain name and terminate it with another NULL byte. This is used for both "connect" and "bind" requests.

Client to SOCKS server:

  • field 1: SOCKS version number, 1 byte, must be 0x04 for this version
  • field 2: command code, 1 byte:
    • 0x01 = establish a TCP/IP stream connection
    • 0x02 = establish a TCP/IP port binding
  • field 3: network byte order port number, 2 bytes
  • field 4: deliberate invalid IP address, 4 bytes, first three must be 0x00 and the last one must not be 0x00
  • field 5: the user ID string, variable length, terminated with a null (0x00)
  • field 6: the domain name of the host we want to contact, variable length, terminated with a null (0x00)

Server to SOCKS client:

  • field 1: null byte
  • field 2: status, 1 byte:
    • 0x5a = request granted
    • 0x5b = request rejected or failed
    • 0x5c = request failed because client is not running identd (or not reachable from the server)
    • 0x5d = request failed because client's identd could not confirm the user ID string in the request
  • field 3: network byte order port number, 2 bytes
  • field 4: network byte order IP address, 4 bytes

A server using protocol SOCKS4A must check the DSTIP in the request packet. If it represents address 0.0.0.x with nonzero x, the server must read in the domain name that the client sends in the packet. The server should resolve the domain name and make connection to the destination host if it can

[edit]SOCKS5

The SOCKS5 protocol is defined in RFC 1928. It is an extension of the SOCKS4 protocol. It offers more choices of authentication, adds support for IPv6 and UDP that can be used for DNS lookups. The initial handshake now consists of the following:

  • Client connects and sends a greeting which includes a list of authentication methods supported.
  • Server chooses one (or sends a failure response if none of the offered methods are acceptable).
  • Several messages may now pass between the client and the server depending on the authentication method chosen.
  • Client sends a connection request similar to SOCKS4.
  • Server responds similar to SOCKS4.

The authentication methods supported are numbered as follows:

  • 0x00: No authentication
  • 0x01: GSSAPI[11]
  • 0x02: Username/Password[12]
  • 0x03-0x7F: methods assigned by IANA[13]
  • 0x80-0xFE: methods reserved for private use

The initial greeting from the client is

  • field 1: SOCKS version number (must be 0x05 for this version)
  • field 2: number of authentication methods supported, 1 byte
  • field 3: authentication methods, variable length, 1 byte per method supported

The server's choice is communicated:

  • field 1: SOCKS version, 1 byte (0x05 for this version)
  • field 2: chosen authentication method, 1 byte, or 0xFF if no acceptable methods were offered

The subsequent authentication is method-dependent. Username and password authentication (method 0x02) is described in RFC 1929:

For username/password authentication the client's authentication request is

  • field 1: version number, 1 byte (must be 0x01)
  • field 2: username length, 1 byte
  • field 3: username
  • field 4: password length, 1 byte
  • field 5: password

Server response for username/password authentication:

  • field 1: version, 1 byte
  • field 2: status code, 1 byte.
    • 0x00 = success
    • any other value = failure, connection must be closed

The client's connection request is

  • field 1: SOCKS version number, 1 byte (must be 0x05 for this version)
  • field 2: command code, 1 byte:
    • 0x01 = establish a TCP/IP stream connection
    • 0x02 = establish a TCP/IP port binding
    • 0x03 = associate a UDP port
  • field 3: reserved, must be 0x00
  • field 4: address type, 1 byte:
    • 0x01 = IPv4 address
    • 0x03 = Domain name
    • 0x04 = IPv6 address
  • field 5: destination address of
    • 4 bytes for IPv4 address
    • 1 byte of name length followed by the name for Domain name
    • 16 bytes for IPv6 address
  • field 6: port number in a network byte order, 2 bytes

Server response:

  • field 1: SOCKS protocol version, 1 byte (0x05 for this version)
  • field 2: status, 1 byte:
    • 0x00 = request granted
    • 0x01 = general failure
    • 0x02 = connection not allowed by ruleset
    • 0x03 = network unreachable
    • 0x04 = host unreachable
    • 0x05 = connection refused by destination host
    • 0x06 = TTL expired
    • 0x07 = command not supported / protocol error
    • 0x08 = address type not supported
  • field 3: reserved, must be 0x00
  • field 4: address type, 1 byte:
    • 0x01 = IPv4 address
    • 0x03 = Domain name
    • 0x04 = IPv6 address
  • field 5: destination address of
    • 4 bytes for IPv4 address
    • 1 byte of name length followed by the name for Domain name
    • 16 bytes for IPv6 address
  • field 6: network byte order port number, 2 bytes

[edit]Software

[edit]SOCKS Servers

  • Dante is a circuit-level SOCKS server that can be used to provide convenient and secure network connectivity, requiring only the host Dante runs on to have external network connectivity.[citation needed]
  • OpenSSH allows dynamic creation of tunnels, specified via a subset of the SOCKS protocol, supporting the CONNECT command.
  • PuTTY is a Win32 SSH client that supports local creation of SOCKS (dynamic) tunnels through remote SSH servers.
  • Sun Java System Web Proxy Server is a caching proxy server running on Solaris, Linux and Windows servers that supports HTTPS, NSAPI I/O filters, dynamic reconfiguration, SOCKSv5 and reverse proxy.
  • WinGate is a multi-protocol proxy server and SOCKS server for Microsoft Windows which supports SOCKS4, SOCKS4a and SOCKS5. It also supports handing over SOCKS connections to the HTTP proxy, so can cache and scan HTTP over SOCKS.
  • SS5 SS5 is a socks server that implements the SOCKS v4 and v5 protocol.
  • Tor is a SOCKS server that conceals a client from its destination.
  • Nylon is a small SOCKS server supporting SOCKS4, SOCKS4a, SOCKS5 protocols as well as a mirror mode.
  • Srelay is a small SOCKS4/SOCKS5 proxy server.
  • OddSocks is a small SOCKS5 server that supports web-based authentication (most browsers do not implement SOCKS authentication).
  • sSocks is a package which contains: a socks5 server implements RFC 1928 (SOCKS V5) and RFC 1929 (Authentication for SOCKS V5), a reverse socks server and client, a netcat like tool and a socks5 relay.

[edit]SOCKS Clients

Client software must have native SOCKS support in order to connect through SOCKS. There are programs that allow to circumvent this limitation:

[edit]Proxifiers

[edit]Translating proxies

[edit]References

  1. ^ Darmohray, Tina. "Firewalls and fairy tales". ;LOGIN:. Vol 30, no. 1.
  2. ^ Archive copy at the Wayback Machine
  3. ^ "News Release from". Bluecoat. 2009-06-14. Retrieved 2009-06-19.[dead link]
  4. ^ Article from[dead link] Mohammad Asif infosecurityproductsguide.com
  5. ^ RFC 1928
  6. ^ CNET: Cyberspace from outer space
  7. ^ "2010 Circumvention Tool Usage Report". The Berkman Center for Internet & Society at Harvard University. October 2010.
  8. ^ "OpenSSH FAQ".
  9. ^ "Upgrading to TLS Within HTTP/1.1 (RFC 2817)". Retrieved 3 July 2011.
  10. ^ "Hypertext Transfer Protocol -- HTTP/1.1 (RFC)". Retrieved 3 July 2011.
  11. ^ "RFC 1961". Tools.ietf.org. Retrieved 2009-06-19.
  12. ^ "RFC 1929". Tools.ietf.org. Retrieved 2009-06-19.
  13. ^ IANA.org
  14. ^ "Torproject.org FAQ - Why do we need Polipo or Privoxy with Tor? Which is better?". Retrieved 2010-12-28.
  15. ^ "Ubuntuusers.de - Tor einrichten und verwenden.". Retrieved 2010-12-28.

[edit]External links


출처 - http://en.wikipedia.org/wiki/SOCKS






저작자표시

'Security > Common' 카테고리의 다른 글

SAML 이해  (0) 2013.12.29
openid - 개념  (0) 2013.06.15
crytography - key  (0) 2012.12.24
naver login process  (0) 2012.12.23
Pass phrase vs. Password  (0) 2012.07.29
Posted by linuxism
,

티스토리툴바