What happens when you type a URL in browser?

Here details of what happens in the background when we type a URL in our browsers.

Step 1. URL is typed in the browser.

Step 2. If requested object is in browser cache and is fresh, move on to Step  8.

Step 3. DNS lookup to find the ip address of the server

when we want to connect to google.com, we actually want to reach out to a server where google web services are hosted. One such server is having an ip address of 74.125.236.65. Now, if you type "http://74.125.236.65" in your browser, this will take you to google home page itself. Which means, "http://google.com" and "http://74.125.236.65" are nothing but same stuff. But, it is not so. Google has multiple servers in multiple locations to cater to the huge volume of requests they receive per second. Thus we should let Google decide which server is best suited to our needs. Using "google.com" does the job for us. When we type "google.com", DNS(Domain Name System) services comes into play and resolves the URL to a proper ip address.

Following is a summary of steps happening while DNS service is at work:

·         Check browser cache: browsers maintain cache of DNS records for some fixed duration. So, this is the first place to resolve DNS queries.

·         Check OS cache: if browser doesn't contain the record in its cache, it makes a system call to underlying Operating System to fetch the record as OS also maintains a cache of recent DNS queries.

·          Router Cache: if above steps fail to get a DNS record, the search continues to your router which has its own cache.

·          ISP cache: if everything fails, the search moves on to your ISP. First, it tries in its cache, if not found - ISP's DNS recursive search comes into picture. DNS lookup is again a complex process which finds the appropriate ip address from a list of many options available for websites like Google. You can read more about this here.

Step 4. Browser initiates a TCP connection with the server.

Step 5. Browser sends a HTTP request to the server.

Browser sends a GET request to the server according to the specification of HTTP(Hyper Text Transfer Protocol) protocol.
        

GET http://google.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: google.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

      
Here, browser passes some meta information in the form of headers to the server along with the URL - "http://google.com". User-Agent header specifies the browser properties, Accept-Encoding headers specify the type of responses it will accept. Connection header tells the server to keep open the TCP connection established here. The request also contains Cookies, which are meta information stored at the client end and contain previous browsing session information for the same website in the form of key-value pairs e.g. the login name of the user for Google.

A quick guide to HTTP specification can be found here.

Step 6. Server handles the incoming request

HTTP request made from browsers are handled by a special software running on server - commonly known as web servers e.g. Apache, IIS etc. Web server passes on the request to the proper request handler - a program written to handle web services e.g. PHP, ASP.NET, Ruby, Servlets etc.
      
For example URL- http://edusagar.com/index.php is handled by a program written in PHP file - index.php. As soon as GET request for index.php is received, Apache(our webserver at edusagar.com) prepares the environment to execute index.php file. Now, this php program will generate a response - in our case a HTML response. This response is then sent back to the browser according to HTTP guidelines.

Step 7. Browser receives the HTTP response

HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Connection: Keep-Alive
Content-length: 1215
Date: Fri, 30 May 2014 08:10:15 GMT

.........<some blob> ................

HTTP response starts with the returned status code from the server. Following is a very brief summary of what a status code denotes:        

·                 1xx indicates an informational message only

·                 2xx indicates success of some kind

·                 3xx redirects the client to another URL

·                 4xx indicates an error on the client's part

·                 5xx indicates an error on the server's part

Server sets various other headers to help browser render the proper content. Content-Type tells the type of the content the browser has to show, Content-length tells the number of bytes of the response. Using the Content-Encoding header's value, browsers can decode the blob data present at the end of the response.

Step 8. Browsers displays the html content

Rendering of html content is also done in phases. The browser first renders the bare bone html structure, and then it sends multiple GET requests to fetch other hyper linked stuff e.g. If the html response contains an image in the form of img tags such as <img src="/assets/img/logo.png" />, browser will send a HTTP GET request to the server to fetch the image following the complete set of steps which we have seen till now. But this isn't that bad as it looks. Static files like images, javascript, css files are all cached by the browser so that in future it doesn't have to fetch them again.     

Step 9. Client interaction with server

Once a html page is loaded, there are several ways a user can interact with the server. For example, he call fill out a login form to sign in to the website. This also follows all the steps listed above, the only difference is that the HTTP request this time would be a POST instead of GET and along with that request, browser will send the form data to the server for processing (username and password in this case).
      
Once server authenticates the user, it will send the proper HTML content(may be user's profile) back to the browser and thus user will see that new webpage after his login request is processed.

Step 10. AJAX queries

Another form of client interaction with server is through AJAX(Asynchronous JavaScript And XML) requests. This is an asynchronous GET/POST request to which server can send a response back in a variety of ways - json, xml, html etc. AJAX requests doesn't hinder the current view of the webpage and work in the background. Because of this, one can dynamically modify the content of a webpage by calling an AJAX request and updating the web elements using Javascript.

Comparison/Difference between Web Application and Windows Application

Web Application 

·         Application loaded in the server. Client machine use the application using URL. you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

·         It is a computer software application that is coded in a browser-supported language (such as HTML, ASP, PHP, Perl, Python etc.) and reliant on a common web browser to render the application executable.

·         Web applications are very much useful when they are hosted. Web app can be access from anyware in the world through the internet.

·         Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, back-end testing and load testing.

·         Web applications are programs that used to run inside some web server (e.g., IIS) to fulfill the user requests over the http.

·         Common Web applications include Webmail, online retail sales, online auctions, wikis, discussion boards, Weblogs 

Windows Application

·         Application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment.

·         A program that is written to run under Microsoft's  Windows operating system.

·         Windows applications typically run under all 32-bit versions of Windows

·         Runs on personal computers and work stations.

·         Window based app. need to be install on your machine to access.

·         Windows applications (desktop) need to be installed on each client's PC.

·         Windows application runs faster than Web application.

·         Windows application have many inbuilt classes in .Net compared to Web application.

What is Hybrid Application?

Somewhere between native and web apps you’ll find hybrid apps. They are usually quicker to build (and thus cheaper) than native apps, but a step-up from what you can expect out of browser-based web apps. Is the hybrid app the best of both worlds?

The bulk of the app is built using cross-compatible web technologies, such as HTML5, CSS and Javascript — the same languages used to write web apps. Some native code is used however to allow the app to access the wider functionality of the device and produce a more refined user experience. For native apps, instead only native code is used. The advantage of this approach is obvious: only a portion of native code has to be re-written to make the app work on the different kinds of devices available.

An advantage that hybrid apps have over native is that it’s faster and easier to develop. It’s also easier to maintain and you can change platforms. The app itself will not be as fast as a native app as it still depends on the browser speed.

There are two main players in the world of hybrid apps: Phonegap/Cordova and Appcelerator Titanium. With these tools you create HTML/CSS/Javascript local files, design and build the app as if it was a website, then use Cordova to wrap them into a mobile app.

Getting your hybrid app to run appropriately on each platform generally takes substantial work. In some situations, the total cost might become comparable to that of fully native apps, rendering the cost benefits negligible. It all depends on how close you want to get to the “native user experience” or how simple your app is.

When the user accesses your web content online through a hybrid app, performance will be sluggish when compared with a native app.

Still, there’s one big advantage in hybrid apps.  Being built on one single core, you can add functionality and have multiple versions of the app all benefit from it. On the contrary, with native apps, for every new functionality you want to introduce, the feature will have to be replicated on each platform.

Examples of hybrid apps: Facebook, TuneIn Radio, LinkedIn
Hybrid app solutions: PhoneGap, BridgeIt

Compare/Difference between Native Application and Mobile Web Application

A light bulb goes off. You have the next great idea for a mobile app that you want to develop. It’ll change lives. It’ll make you millions. What’s the next step you need to take?
One of the things you’ll need to decide early on in your mobile application development process is how you’ll build and deploy your app. There are two main directions you can go: native app or mobile web app. In this article, we’ll talk about the differences between the two so you can make an informed decision.

Native App vs. Mobile Web App: Definition

First, let’s define what we mean in this article when we say "native app" and "mobile web app".

What is a Native App?

A native app is an app for a certain mobile device (smartphone, tablet, etc.) They’re installed directly onto the device. Users typically acquire these apps through an online store or marketplace such as The App Store or Android Apps on Google Play.
Examples of native apps are Camera+ for iOS devices and KeePassDroid for Android devices.

What is a Mobile Web App?

When we talk about mobile web apps in this article, we’re referring to Internet-enabled apps that have specific functionality for mobile devices. They’re accessed through the mobile device’s web browser (i.e. on the iPhone, this is Safari by default) and they don’t need to be downloaded and installed on the device.

Comparison of Native App vs. Mobile Web App

Let’s do a quick rundown and evaluate native apps versus mobile web apps under these factors:

• User interface
• Development
• Capabilities
• Monetization
• Method of delivery
• Versioning of the app
• Strengths
• Weaknesses

User Interface

Some companies choose to develop both a native app and a mobile web app. Here’s a side-by-side look at Facebook’s native app and mobile web app:

Notice that, in terms of the general look-and-feel, there’s little difference between the two, making for a consistent user experience.

Development

Native Apps	Mobile Web Apps
Each mobile application development platform (e.g. iOS, Android) requires its own development process	Runs in the mobile device’s web browser and each may have its own features and quirks
Each mobile application development platform has its own native programming language: Java (Android), Objective-C (iOS), and Visual C++ (Windows Mobile), etc.	Mobile web apps are written in HTML5, CSS3, JavaScript and server-side languages or web application frameworks of the developer’s choice (e.g. PHP, Rails, Python)
Standardized software development kits (SDKs), development tools and common user interface elements (buttons, text input fields, etc.) are often provided by the manufacturer of the platform	There are no standard software development kits (SDKs) that developers are required to use to make a mobile web app
There are tools and frameworks to help in developing apps for deployment on multiple mobile OS platforms and web browsers (e.g. PhoneGap, Sencha Touch 2, Appcelerator Titanium, etc.)

Capabilities

Native Apps	Mobile Web Apps
Can interface with the device’s native features, information and hardware (camera, accelerometer, etc.)	Mobile web apps can access a limited amount of the device’s native features and information (orientation, geolocation, media, etc.)

Monetization

Native Apps	Mobile Web Apps
Mobile-specific ad platforms such as AdMob (though there can be restrictions set by the mobile device’s manufacturer)	Mobile web apps can monetize through site advertisement and subscription fees
Developers have the ability to charge a download price and app stores will typically handle the payment process (in exchange for a percentage of sales)	Charging users to use the mobile web app requires you to set up your own paywall or subscription-based system

Method of Delivery

Native Apps	Mobile Web Apps
Downloaded onto a mobile device	Accessed through a mobile device’s web browser
Installed and runs as a standalone application (no web browser needed)	No need to install new software
Users must manually download and install app updates	Updates are made to the web server without user intervention
There are stores and marketplaces to help users find your app	Since there is no app store for the Mobile Web, it can be harder for users to find your app

Versioning of the App

Native Apps	Mobile Web Apps
Some users may choose to ignore an update, resulting in different users running different versions of the app	All users are on the same version

Strengths

Native Apps	Mobile Web Apps
Typically perform faster than mobile web apps	Have a common code base across all platforms
App stores and marketplaces help users find native apps	Users don’t have to go to a store or marketplace, download the app and install the app
App store approval processes can help assure users of the quality and safety of the app	Can be released in any form and any time as there isn’t an app store that has to approve the app
Tools, support and standard development best practices provided by device manufacturers can help speed up development	If you already have a web app, you can retrofit it with a responsive web design

Weaknesses

Native Apps	Mobile Web Apps
Are typically more expensive to develop, especially if you’re supporting multiple mobile devices	Mobile web apps can’t access all of the device’s features (yet)
Supporting multiple platforms requires maintaining multiple code bases and can result in higher costs in development, maintenance, pushing out updates, etc.	Supporting multiple mobile web browsers can result in higher costs in development and maintenance, etc.
Users can be on different versions and can make your app harder to maintain and provide support for	Users can be on different mobile browsers and can make your app harder to maintain and provide support for
App store approval processes can delay the launch of the app or prevent the release of the app	For users, it may be harder to find a mobile web app because of the lack of a centralized app store (though listings do exist such as Apple’s Web apps and you can request to be listed in them)

Native App vs. Mobile Web App: How Do You Choose?

To help you decide how you should build your mobile app, ask yourself these questions:

• Does the mobile app require the use of any special device features (i.e., camera, the camera’s flash, accelerometer, etc.)?
• What’s my budget?
• Does the mobile app need to be Internet-enabled?
• Do I need to target all mobile devices or just certain devices?
• What programming languages do I already know?
• How important is speed and performance?
• How will this app be monetized effectively?

Answering these questions can help you make an informed decision.

Conclusion

Whether you decide to build a native app or a mobile web app depends on many factors: business objectives, target audience, technical requirements and so on.
You don’t necessarily have to choose between building a native app or a mobile web app. As mentioned earlier, companies like Facebook maintain both native apps and a mobile web app. However, for many of us, budget and resource constraints will require us to decide if we need to build a native app or a mobile web app (or, at least, will require us to prioritize which one to develop first).