From the early days of the Internet, HTTP based applications in intranet hosts were defined to access public network resources through proxy mechanisms. These applications listen on the local proxy connection port (8080 is allowed by default) and make a request in a particular form so that the agent can properly handle it. The agent handles communications between internal customers and external servers based on requirements and policies defined by proxy server administrators, which is also known as the CERN proxy, and the HTTP protocol and HTTP proxy mechanism defined by the relevant organization. Now, often referred to as HTTP proxies or web proxies, they have the same meaning and are a mechanism for handling HTTP clients and servers, which is very good and even includes the ability to authenticate users with specific HTTP requests/responses. Figure 01 illustrates the process by which the client connects directly to the client;
Figure 02 illustrates the process of a CERN proxy request;
Unfortunately, this proxy mechanism is usually limited to HTTP proxies, and applications that use non-HTTP protocols require other solutions, and for these applications, another mechanism called the socks agent is designed, initially called SOCKS4, It provides TCP proxy services for virtually any application, including FTP, SMTP, POP3, or even HTTP. This mechanism, in addition to adding a proxy to the application protocol, is similar to CERN. The SOCKS client application negotiates with the SOCKS proxy server using the SOCKS proxy (10801 is allowed by default) to establish a connection to the remote server. Once this connection is established, the SOCKS Proxy server will assume basic NAT routing functionality in the session protocol between the client and server, SOCKS4 to support name resolution (SOCKS4A) and UDP transmissions, user authentication and IPV6 (SOCKS5 and extensions). Although socks provides a large number of features that the CERN agent cannot provide, it requires the application to use the SOCKS protocol at development time if it is to successfully establish a connection with a remote host. Figure 03 illustrates the basic socks agent behavior.