Assume our browser is using UDP protocol; then request to the server,will it be passed through all the lower lower layers or it goes directly to the receiver end by...
If it goes all through the layers then it uses a physical link; then how it could be a connection-less protocol?
Wireless uses TCP or UDP?
please do answer me...am totally confused with this concept....
Every application protocol specifies which transport protocol it uses.
TCP is used for the HTTP connection to the web server. UDP is normally used for performing DNS queries, although it's possible for it to switch to TCP in some cases.
The browser uses HTTP, an application protocol layered over TCP, which is a connection-oriented protocol. Or else it uses HTTPS, which is HTTP over SSL over TCP.
Your remarks about UDP are both illogical and irrelevant.
Related
Let's assume that I start a server at one of the computers in my private network (192.168.10.10:9900).
Now when making a request from some other computer in the same network, how does the client computer (OS?) knows which protocol to use / which protocol the server follows ? [TCP or UDP]
EDIT: As mentioned in the answers, I was basically looking for a default protocol which will be used by the client in the absence of any transport protocol information.
TCP / UDP protocols work at the transport layer level (TCP / IP MODEL) and its main difference is that TCP has a method to ensure the arrival of messages while UDP is lighter because of its virtue is to be faster in Information delivery. The use of one protocol or another is always defined by the application that will use it.
So the reference you put on the private server with ip: port 192.168.10.10:9900 is very vague to be more precise we could say that we have an Apache web server running on the ip: port 192.168.10.10:9900 (the port for default is 80 when installing the server, but it can be changed in the configuration).
Now the web servers (apache, IIS, etc.) work using the TCP protocol because when a client (computer, cell phone, etc.) consults a page through a browser (Chrome, Firefox, etc.), the ideal thing is that all the website and not just some pieces. This is why this type of servers chose and use this protocol in the first instance since they seek that in the end the result is that the user obtains the complete page regardless of whether a few more milliseconds are sacrificed in the validations involved in using TPC.
Now going to the client side. The user when visiting a web page from any browser (Chrome, Firefox, etc.) will use TCP since this protocol is already configured in the browser to send the query messages and subsequently receive the messages with the same form Website information.
Now this behavior is going to be repeated for any client / server application. For example, to change the type of application on the UDP side, we can observe the operation of DHCP services which are used to receive an IP when connecting any device to a Wi-Fi network. In this case, this service seeks to be as fast as possible (instead of the most reliable) since you want the device to connect as quickly as possible to the network, so use the UDP protocol and in this case any equipment when connecting To a WIFI network you will send your messages using this protocol.
Finally, if you want to know promptly about the type of TCP / UDP protocol used by a specific application, you can search on the Wireshark application which allows you to scan the messages that leave the device or show the protocol used in the different layers of the application.
There is no reason any client would make a request to your server, so why would it care what protocol it follows? Clients don't just randomly connect to things to see if there's a server there. So it doesn't make any difference to any client.
Normally, the client computer will use the TCP protocol as default. If you start the server using UDP protocol mode, then when you use curl -XGET 192.168.10.10:9900/test-page, it will give you back an curl: (7) Failed to connect to 192.168.10.10 port 9900: Connection refused error. You can try it, use the nc -lvp 9900 -u, it will give you that result.
The answers here are pointing to some default protocol. Its' not that, Whenever you start an application let say HTTP server, the server's internal has code to open a socket(which can be TCP or UDP), since HTTP:80 is a TCP protocol the code creates a TCP socket. Similarly for other network application it depends on their requirement what kind of transport layer protocol to use (TCP Or UDP). Like a DNS client will create a UDP socket to connect to DNS server, since DNS:53 is mostly over UDP. Both TCP and UDP have different use cases, advantages and disadvantages. Depending on there uses cases / advantages / disadvantages of UDP/TCP decision is taken to implement server using either of them.
I used to think Skype sends and receives UDP data packets for real-time audio communication so it cannot use HTTP proxy as HTTP is based on TCP, as what people usually think. But in the support site of Skype, there is an article about HTTP proxy saying that'll affect how Skype makes the communication.
Skype uses different protocols based on the capabilities of the network. If it is behind a firewall and can not call out directly with UDP it will try to detect a HTTP proxy and use it to tunnel the traffic using a proxy CONNECT request. This means it will use TCP in this case. While this might degrade the quality of the connection because latency is often better with UDP (at the cost of data loss), this is often better than no connection at all.
If a client inside firewall connects to a public server through TCP, once the connection is formed, the firewall allows two-way communication. This is what we normally see in our daily usage. My question is: is this also true for UDP?
Since UDP does not have connect, I will modify the question a little bit...
Suppose the client inside firewall sends a UDP packet to a public server, can the server respond back through firewall using the source address and port of incoming packet?
Yes this is called NAT traversal (or UDP punch through) and works in a similar way to TCP - the stateful NAT device is aware you recently sent a UDP packet from a certain end point internally to a certain end point outside and for a period will accept UDP packets from the same outside endpoint and forward them to the same internal end point.
I always prefer the IETF docs than the plethora of conflicting information out there (including on this site):
https://www.rfc-editor.org/rfc/rfc5128
UPDATE: There are other techniques to "UDP hole punching" such as UPnP's Internet Gateway Protocol and PCP. Each has their advantages and disadvantages and I am afraid there is no one solution works on all NATs!
Can clients using http 1.0 or older use UDP sockets instead of TCP sockets?
I was wondering as to what could prevent such use apart from firewall issues and packet size limitations. However, if that isn't a problem, is there anything else that prevents such use.
Also, have they been used traditionally?
From RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", section 1.3, "Overall Operation":
On the Internet, HTTP communication generally takes place over TCP/IP
connections. The default port is TCP 80 [15], but other ports can be
used. This does not preclude HTTP from being implemented on top of
any other protocol on the Internet, or on other networks. HTTP only
presumes a reliable transport; any protocol that provides such
guarantees can be used, and the mapping of the HTTP/1.0 request and
response structures onto the transport data units of the protocol in
question is outside the scope of this specification.
So, if you can implement a reliable transport over UDP then you can use HTTP. Of course, at that point you may as well use TCP instead of abusing datagrams.
I've read about WebSockets and I wonder why browser couldn't simply open trivial TCP connection and communicate with server like any other desktop application. And why this communication is possible via websockets?
It's easier to communicate via TCP sockets when you're working within an intranet boundary, since you likely have control over the machines on that network and can open ports suitable for making the TCP connections.
Over the internet, you're communicating with someone else's server on the other end. They are extremely unlikely to have any old socket open for connections. Usually they will have only a few standard ones such as port 80 for HTTP or 443 for HTTPS. So, to communicate with the server you are obliged to connect using one of those ports.
Given that these are standard ports for web servers that generally speak HTTP, you're therefore obliged to conform to the HTTP protocol, otherwise the server won't talk to you. The purpose of web sockets is to allow you to initiate a connection via HTTP, but then negotiate to use the web sockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream.
Web browsers operate at the Application layer, whereas TCP operates at the Transport Layer. As a web application developer, it's easier to send messages over the wire via the Application Layer instead of raw bytes at the Transport Layer.
Underlying WebSockets is TCP, it's just abstracted away for simplicity.
Websocket is a application layer protocol while TCP is transport layer protocol. At transport layer, we usually have TCP and UDP protocol. Any message from application layer need to go through transport layer to be transmitted to other machine. Hence, websocket and tcp have a relationship to each other and can not be comparable.
To make it simple, the websocket communications are done over TCP port number 80 (or 443 in the case of TLS-encrypted connections), which is of benefit for those environments which block non-web Internet connections using a firewall.
Would you like to use existed TCP port or open a new TCP port that might be blocked by firewall?