• Login/Register
  • Section: Internet /Monday 13th October 2014

    Alphabetic Index : A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

    Search β):

    * SOCKS *

    ساکس (پروتکل)

    (Wikipedia) - SOCKS This article is about the internet protocol. For other uses, see Socks (disambiguation). Internet protocol suite Application layer Transport layer Internet layer Link layer
    • BGP
    • DHCP
    • AAA/AAAS
    • DNS
    • FTP
    • HTTP
    • IMAP
    • LDAP
    • MGCP
    • NNTP
    • NTP
    • POP
    • ONC/RPC
    • RADIUS
    • RTP
    • RTSP
    • RIP
    • SIP
    • SMTP
    • SNMP
    • SSH
    • TACACS
    • Telnet
    • TLS/SSL
    • XMPP
    • more...
    • TCP
    • UDP
    • DCCP
    • SCTP
    • RSVP
    • more...
    • IP
    • ICMP
    • ICMPv6
    • ECN
    • IGMP
    • IPsec
    • more...
    • ARP
    • NDP
    • OSPF
    • Tunnels
      • L2TP
    • PPP
    • MAC
      • Ethernet
      • DSL
      • ISDN
      • FDDI
    • more...
    • v
    • t
    • e

    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 proxies TCP connections to an arbitrary IP address, and provides 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).



    The protocol was originally developed/designed 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, making SOCKS publicly available. The protocol was extended to version 4 by Ying-Da Lee of NEC.

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

    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. The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia.


    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, e.g., by governments, workplaces, schools, and country-specific web services.

    Some SSH suites, such as OpenSSH, support dynamic port forwarding that allows the user to create a local SOCKS proxy. 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.

    Comparison to HTTP proxying

    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 a SOCKS proxy may interpret and rewrite headers (say, to employ another underlying protocol, such as FTP; however, an HTTP proxy simply forwards an HTTP request to the desired HTTP server). Though HTTP proxying has a different usage model in mind, the CONNECT method allows for forwarding TCP connections; however, SOCKS proxies can also forward UDP traffic and work in reverse, while HTTP proxies cannot. HTTP proxies are traditionally more aware of the HTTP protocol, performing higher-level filtering (though that usually only applies to GET and POST methods, not the CONNECT method).


    Bill wishes to communicate with Jane over the internet, but a firewall between them exists on his network; Bill is not authorized to communicate with Jane directly. So, instead, Bill connects to the SOCKS proxy on his network, informing it 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.


    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 directly with the proxy in exactly the same way it would communicate directly with Jane''s server if it could; that is, it sends a standard HTTP request header. The HTTP proxy itself connects to Jane''s server, and then transmits back to Bill any data that Jane''s server returns.

    Protocol SOCKS4

    A typical SOCKS4 connection request looks like this:

    SOCKS Client to SOCKS Server:

    SOCKS Server to SOCKS client:

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

    From this point onwards, any data sent from the SOCKS client to the SOCKS server is relayed to, and vice versa.

    The command field may be 0x01 for "connect" or 0x02 for "bind"; the "bind" command allows incoming connections for protocols such as active FTP.


    SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address; this is useful when the client itself cannot resolve the destination host''s domain name to an IP address.

    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:

    Server to SOCKS client:

    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.


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

    The authentication methods supported are numbered as follows:

    The initial greeting from the client is

    The server''s choice is communicated:

    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

    Server response for username/password authentication:

    The client''s connection request is

    Server response:

    Software Servers Clients

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

    Proxifiers Translating proxies

    Tags:Asia, Computer, Domain, Domain name, HTTP, IPv4, Internet, Internet protocol suite, Java, Link layer, Linux, Microsoft, Proxy, SOCKS, Silicon, Sun, Telnet, Wikipedia

    Add definition or comments on SOCKS

    Your Name / Alias:
    Definition / Comments
    neutral points of view
    Source / SEO Backlink:
    Anti-Spam Check
    Enter text above
    Upon approval, your definition will be listed under: SOCKS

    Happy Summer Sale

    Home About us / Contact    Products    Services    Iranian History Today    Top Iran Links    Iranian B2B Web Directory    Historical Glossary
    Copyright @ 2004-2016 fouman.com All Rights Iranian