Here is my understanding of how a client-server HTTP server works.
The client creates a TCP socket connection to connect to the server and sends data.
The server creates a TCP socket connection to listen for incoming requests.
So it looks like both the client and the server need to agree on the use of the Transport protocol to use (in this case TCP). But if we want a website to work over UDP/QUIC protocol then we need both the client and the server to create a UDP socket connection. But some websites use TCP and others use UDP...
So does it mean it would need to look like this? To know beforehand which protocol a website uses?
if (URI == 'https://www.google.com') {
// Website that works over UDP
client.create.UDP.socket
client.sendData
server.create.UDP.socket
server.receive.data
} else {
// Website that works over TCP
client.create.TCP.socket
client.sendData
server.create.TCP.socket
server.receive.data
}
So the client needs to keep a record of which website uses TCP and which websites use UDP/QUIC and create that kind of socket to communicate with it?
If a protocol supports both TCP and UDP, the server listens both on the TCP port and the UDP port. The port number is generally the same, e.g. DNS uses TCP port 53 and UDP port 53.
Usually the client has a preference. Let's say it prefers TCP. The client will first try to connect with TCP. If the server does not respond, the client will retry with UDP. Alternatively, the server can respond over TCP but ask the client to switch to UDP. The client can then decide to continue with TCP or switch to UDP.
For QUIC 1 2, the browser will first connect using HTTP over TCP. The server will respond with a message stating that it also supports QUIC. If the browser also supports this protocol, the browser will reconnect to the server using QUIC.
Related
Hello I have a http server running on port 80. Now as I am new to sockets, I got to know that we can upgrade the connection on the same port and make both work on the same port.
Now I am confused what will happen to the other client.
Consider this:
I send a get request to the server that please upgrade my connection from http to websocket using the same TCP/IP. The server responded with 101. It upgraded the connection. So far so good.
Now the port 80 is a websocket port rather than http. So now, socket.io would be maintaining the connection and request and not the app in express();
So when the next client comes to the same port 80 to do something non-socket related or anything, how the http mechanism would work because the connected is already a socket one now.
How it is doing what it is doing here.
Now the port 80 is a websocket port rather than http.
A TCP listener socket is agnostic to the application protocol. It is only about establishing a new TCP connection. There are not even application data transferred on the listener socket.
Using a specific application protocol like HTTP or switching between application protocols like switching from HTTP to WebSocket, only effects the newly established (accepted) connection but not the listener socket. This also means that it is possible to use different application protocols on different TCP connections, even if all of these connections originated on a single TCP listener socket.
Hi guys I'm currently developing a C project in which we basically need to connect N clients to a server through a proxy. I'm doing the first connecting using the TCP protocol. After this, the client may request a file download using UDP. Do I need to have another socket listening to another port and connect the client again to this port or is this an incorrect way of thinking?
TCP and UDP communicate in very different ways. You'll need a separate socket for each
one.
You'll probably want to use the TCP socket to communicate the UDP port to use.
Usually we can set up a proxy server by some kind of tools such as CCProxy which provides proxy services for HTTP, SOCKS, FTP packets etc.
Also, Proxifier or Proxycap is used to forward the packets of specific application on the client PC.
However, when UDP packets are forwarded to the proxy server, these packets cannot be correctly forwarded to the destination originally the application wanted them to go.
When I use a network analyzer to observe the UDP traffic flow, the UDP packets are just passed to the proxy server from my PC without going to the correct destination finally.
Besides, someone suggested that the UDP relay is not enabled in the proxy server so the UDP packets cannot be routed successfully. How can I enable the UDP relay function on the proxy server?(Assume that I can control the proxy server completely)
Any kind of proxy, whether it is for TCP or UDP, needs to be told where to forward outgoing packets to. That also allows the proxy to know who is requesting the forwarding so it can route matching inbound packets back to that same requester.
Lets assume SOCKS, for example. SOCKS v4 does not support UDP (or IPv6), but SOCKS v5 does. However, it requires the requesting app to establish a TCP connection to the SOCKS proxy and ask it to forward UDP packets on the app's behalf until that TCP connection is closed.
Tools like CCProxy, Proxycap, Proxifier, etc work (for TCP, anyway) by intercepting outgoing TCP conections and redirecting them to the proxy server, transparently handling any proxy handshaking to set up forwarding, before then allowing any application data to flow through the TCP connection. Once the TCP connection has been established, the proxifier does not need to do anything more with the connection since the app is now talking directly to the proxy.
I do not know if such tools support UDP. It would be much harder to implement, since there is no outgoing connection to redirect. Every outbound UDP packet would have to be intercepted, then the proxifier would have to check if it already has its own SOCKS v5 TCP connection associated with the packet's local/remote tuple and if not then create a new one and send the necessary UDP forwarding handshake, then encapsulate every outbound UDP packet for that tuple and send it to the proxy's outbound IP/Port, and receive every matching inbound UDP packet for that tuple from the proxy so it can be de-encapsulated and forwarded to the app's local IP/Port that sent out the original outbound UDP packet. And because UDP is connection-less, the proxifier would have to also implement a timeout mechanism on its SOCKS v5 TCP connection to the proxy so it can eventually be closed after a period of UDP traffic being idle.
That is a LOT more work for a UDP proxifier to do compared to TCP.
And that is just for SOCKS. HTTP/FTP proxies do not support UDP at all (since HTTP/FTP are TCP-based protocols). And there are other tunnel/proxy protocols as well, which may or may not have their on UDP capabilities.
So you have to check the capabilities of your proxifier tool to see if it supports UDP or not.
I'm working on a program in which a UDP server keeps listening to incoming requests.
If a particluar kind of request is received, it tries to create a RMI server using the same port on which the UDP server was listening.
So, is this possible?
or I need to have different ports?
Yes it's possible. TCP and UDP port numbers are in different namespaces.
First of all, is there any problem with using both UDP and TCP on the same server?
Secondly, can I use the same port number?
Yes, you can use the same port number for both TCP and UDP. Many protocols already do this, for example DNS works on udp/53 and tcp/53.
Technically the port pools for each protocol are completely independent, but for higher level protocols that can use either TCP or UDP it's convention that they default to the same port number.
When writing your server, bear in mind that the sequence of events for a TCP socket is much harder than for a UDP socket, since as well as the normal socket and bind calls you also have to listen and accept.
Furthermore that accept call will return a new socket and it's that socket that you'll then have to also poll for receive events. Your server should be prepared to continue accepting connections on the original socket whilst simultaneously servicing multiple clients each of which will be triggering receive events on their own sockets.
Firstly,there is no problem using both tcp and udp on the server.
Secondly,we can have both UDP and TCP requests on same port ,because each request is identified by a quintuple contained by source IP ,Destination IP, Source Port, Destination Port, PROTOCOL(as protocol can be TCP or UDP).