Thread: Important terms

hello

while surfing through the proxy forums, one word has always make me thought. Everyone over here is asking for good quality of SOCKS4 or SOCKS5 proxy. On some posts they mentions about HTTP proxies.

I just wanna make myself clear about those 2 type of proxies. Will you guys help me out?

Thanks

Did you ever used any proxy befor? However, from your browser got to Tools>options>Advanced>Network>setting
Tere you will be found proxy option where you will find all the options. The proxy we use to brows webpage are http.

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 may be used for any form of TCP or UDP socket connection, whereas an HTTP proxy takes an HTTP request and forwards it an HTTP server. Though HTTP proxying has a different use-case in mind, the CONNECT [7] method allows one to forward TCP connections, there is however no mechanism for UDP proxying.

Originally Posted by DavidHunke

Did you ever used any proxy befor? However, from your browser got to Tools>options>Advanced>Network>setting
Tere you will be found proxy option where you will find all the options. The proxy we use to brows webpage are http.

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 may be used for any form of TCP or UDP socket connection, whereas an HTTP proxy takes an HTTP request and forwards it an HTTP server. Though HTTP proxying has a different use-case in mind, the CONNECT [7] method allows one to forward TCP connections, there is however no mechanism for UDP proxying.

Thanks Mr DavidHunke for clearing the issue in a nice way.

Originally Posted by DavidHunke

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 may be used for any form of TCP or UDP socket connection, whereas an HTTP proxy takes an HTTP request and forwards it an HTTP server. Though HTTP proxying has a different use-case in mind, the CONNECT [7] method allows one to forward TCP connections, there is however no mechanism for UDP proxying.

These terms are very new to me....................
what are TCP and UDP socket connection? ?? ???
What is CONNECT [7] ?

Originally Posted by nicole

These terms are very new to me....................
what are TCP and UDP socket connection? ?? ???
What is CONNECT [7] ?

TCP/IP is a connection whereas there is a negotiation. Imagine somebody knocking on your door and saying "Hi, I'm SharePro" and making an introduction. In TCP/IP there is a negotiation pattern designed to recognize who is connecting with you. What there IP address is, where they are from, etc. In UDP, its lot less personal. Imagine somebody screaming in the middle of the street "Who wants to go to SharePro's party". In UDP, nobody checks to see where it came from, rather only accepts the message.

So in other words, In UDP - anybody who hears the call can respond. But often enough, they don't know who was the person who initially screamed "Who wants to go to SharePro's party". There was no initial personal introduction. Because of the nature of UDP, you can "Spoof" IP addresses, hence fake your IP address and make it look like your somebody else (i.e. US Gov, etc). But in TCP/IP, you cannot fake an IP. The most you can do is use a proxy. SOCKS simply provide an extra layer of security by requiring authentification so that only the authorized users can access. Basically SOCKS are tcp/ip connections that can allow UDP packets to forward as well.

Examples....
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 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.


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.

Originally Posted by SharePro

TCP/IP is a connection whereas there is a negotiation. Imagine somebody knocking on your door and saying "Hi, I'm SharePro" and making an introduction. In TCP/IP there is a negotiation pattern designed to recognize who is connecting with you. What there IP address is, where they are from, etc. In UDP, its lot less personal. Imagine somebody screaming in the middle of the street "Who wants to go to SharePro's party". In UDP, nobody checks to see where it came from, rather only accepts the message.

So in other words, In UDP - anybody who hears the call can respond. But often enough, they don't know who was the person who initially screamed "Who wants to go to SharePro's party". There was no initial personal introduction. Because of the nature of UDP, you can "Spoof" IP addresses, hence fake your IP address and make it look like your somebody else (i.e. US Gov, etc). But in TCP/IP, you cannot fake an IP. The most you can do is use a proxy. SOCKS simply provide an extra layer of security by requiring authentification so that only the authorized users can access. Basically SOCKS are tcp/ip connections that can allow UDP packets to forward as well.

Examples....
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 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.


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.

Really i want to know this information. Great!!! I am also clear about this proxy. Though i never use proxy.

Originally Posted by DavidHunke

Did you ever used any proxy befor? However, from your browser got to Tools>options>Advanced>Network>setting
Tere you will be found proxy option where you will find all the options. The proxy we use to brows webpage are http.

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 may be used for any form of TCP or UDP socket connection, whereas an HTTP proxy takes an HTTP request and forwards it an HTTP server. Though HTTP proxying has a different use-case in mind, the CONNECT [7] method allows one to forward TCP connections, there is however no mechanism for UDP proxying.

Inspirational post. Knowledge is one of the most valuable things in the world,

Originally Posted by SharePro

TCP/IP is a connection whereas there is a negotiation. Imagine somebody knocking on your door and saying "Hi, I'm SharePro" and making an introduction. In TCP/IP there is a negotiation pattern designed to recognize who is connecting with you. What there IP address is, where they are from, etc. In UDP, its lot less personal. Imagine somebody screaming in the middle of the street "Who wants to go to SharePro's party". In UDP, nobody checks to see where it came from, rather only accepts the message.

So in other words, In UDP - anybody who hears the call can respond. But often enough, they don't know who was the person who initially screamed "Who wants to go to SharePro's party". There was no initial personal introduction. Because of the nature of UDP, you can "Spoof" IP addresses, hence fake your IP address and make it look like your somebody else (i.e. US Gov, etc). But in TCP/IP, you cannot fake an IP. The most you can do is use a proxy. SOCKS simply provide an extra layer of security by requiring authentification so that only the authorized users can access. Basically SOCKS are tcp/ip connections that can allow UDP packets to forward as well.

Examples....
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 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.


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.

excellent reply for nichole. thanks a lot. very much impressive discussion.

Originally Posted by SharePro

TCP/IP is a connection whereas there is a negotiation. Imagine somebody knocking on your door and saying "Hi, I'm SharePro" and making an introduction. In TCP/IP there is a negotiation pattern designed to recognize who is connecting with you. What there IP address is, where they are from, etc. In UDP, its lot less personal. Imagine somebody screaming in the middle of the street "Who wants to go to SharePro's party". In UDP, nobody checks to see where it came from, rather only accepts the message.

So in other words, In UDP - anybody who hears the call can respond. But often enough, they don't know who was the person who initially screamed "Who wants to go to SharePro's party". There was no initial personal introduction. Because of the nature of UDP, you can "Spoof" IP addresses, hence fake your IP address and make it look like your somebody else (i.e. US Gov, etc). But in TCP/IP, you cannot fake an IP. The most you can do is use a proxy. SOCKS simply provide an extra layer of security by requiring authentification so that only the authorized users can access. Basically SOCKS are tcp/ip connections that can allow UDP packets to forward as well.

Examples....
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 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.


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.

Hey SharePro you are absolutely right. I'm agree with you.