If I use a name like "www.example.com" to go to a web page, the browser will start from right to left, looking at the TLD to find the domain and then proceed further. If I enter the IP address of that host, how will the browser parse it?
RFC 3986 defines how to parse and handle URLs. Parsing an IPv4 address is quite simple, you just need to:
- Take the string, and check if it is a.b.c.d with a, b, c and d being numbers in the range 0..255.
- Check that not all four numbers are zero. (0.0.0.0 is not a valid target address.)
Each number parsed can be stored in one byte in memory (hence the range 0..255). If you store them in memory with a given byte order (network byte order), then you get a 4 byte struct that can be used by networking APIs.
Normally browsers don't need to parse the address themself, then can just call an OS function that does that for them. But care has to be taken (see RFC section 7.4), some OS functions allow IPv4 address notations that are not allowed by the RFC. These are for example a.b.c (a, b as 0..255, c as 0..65536) or just a with a in 0..2^32-1 (IE once supported this, but this can be a security issue).
Handling of IPv6 addresses is quite similar, but IPv6 addresses us : as a delimiter, are longer and support a shorter writing with :: instead of :0: or :0:0:.
Your question is based on a faulty assumption.
The web browser does not really do anything special with the host name. It will call out to a resolver library routine, asking "hey, I've got this funny-looking string; can you give me a corresponding IP address that I can actually connect to?". In practice there's likely a few layers of indirection involved, so that the "address bar code" can simply pass the entire string that was entered by the user to some routine, which ultimately triggers loading the requested page.
The actual name resolution is normally handled by the name resolution routines provided by the programming library, which in turn likely call out to the operating system which in turn makes a DNS request and passes it to the configured DNS resolver server. It is the DNS resolver server which breaks this down into parts that it can answer directly and follows any delegations involved. This means that the web browser is totally oblivious to that process.
IP addresses are on a specific form: either
n.n.n.n where each
n is a number between 0 and 255, or an IPv6 address enclosed in square brackets
[s0m3:add:re::s:s]. This can easily be detected programatically and handled as a special case, simply converting the IP address to binary form and using it to connect to the given host instead. There are ready-made library functions for doing such conversions, since it is such a common case to have a string containing an IP address (provided by the user, read from a configuration file, or whatever) and wanting to connect to it.
Note that the above is very generalized. Some operating systems may provide TCP connect functions that accept a fully qualified host name directly and do the lookups on behalf of the caller; others may require the caller to look up the host name first and then make another call to initiate the TCP connection. Even so, the general process is the same; the difference is only which piece of code is responsible for which part of the flow. (And even if the connect call can accept a host name, it may be advantageous to resolve it to an IP address first anyway; for example, you get to choose whether you prefer IPv4 or IPv6, or can apply proxying settings.)
Actually, browser won't parse URL right-to-left. It will attempt to match it to a pattern:
Scheme tells how to handle the URL. If it's
https, it will be processed inside the browser, otherwise the browser may decide to handle it (for example
ftp) or pass it to external application provided by OS (eg.
skype and many, many others).
When the browser has extracted the domain part from the URL, it will check if it's already an IP. If it's not, then it will query DNS server to get the server's IP.
Note that simply replacing domain name with server's IP won't work for most websites. It's because of virtual hosts. It's a mechanism that lets you run multiple websites on one IP address. When the server behind an IP receives a HTTP request, it checks request headers to determine what website the client wants to see. Then it serves appropriate document. Now, if a server
198.51.100.1 is configured to accept only requests for
example.com, it won't respond to your request for
http://198.51.100.1/ because the domain is not