URL redirection is a concept where a browser when visits a source URL gets redirected to a destination URL. There are multiple reasons to do so some of which are :-
Want users to always visit your site on HTTPS instead of HTTP.
Have a shortened URL and want users to visit the actual site when the short URL is used.
Have your content on one website but have an alias for the same.
Have a new home for your website and want users to no longer visit the old one.
There are multiple ways to achieve it where each method serves its own purpose and should be leveraged according to the specific needs. Some of the popular ways are listed below.
301/302/307/308 redirection
This URL redirection is unmasked redirection. It is called so because the target URL is not masked and visible to the user and the user is made aware of it.
It needs that the response HTTP status code is 301/2/7/8 and a Location header is passed in the response headers.
Here's an excerpt from the RFC itself:
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection.
The browser is smart for a lot of reasons and this is one of it. It sees that the status code is 3XX, understands that redirection needs to kick in and then looks for the Location header in the response headers. It then visits the target URL mentioned by the Location header through the usual process of visiting a URL.
301 and 308 are used for permanent redirections whereas 302 and 307 are used for temporary redirections.
In permanent redirections, the target website is indexed by the search engines whereas in temporary redirections, the search engines are made aware that this redirection is on a temporary basis and indexing needs to be set for the source URL itself.
You can read more on the specific use cases of each here.
The difference between 301-308 or 302-307 is that the first set of them - 301/2 do not explicitly ask the user agent to change the METHOD during redirection whereas the latter ones - 307/8 explicitly ask the user agent to not change the METHOD during redirection. It is just a contract enforcement mechanism.
You can read more on this here.
Frame redirection
This URL redirection is masked redirection. It is called so because the target URL is masked and the user is not made aware of it explicitly.
It works by embedding the entire content of a target site into a frame and generating a new page. This page will be served by a domain forwarding service which ensures that this works seamlessly.
When an internet user visits the source URL, the resultant IP as part of the DNS resolution is that of the domain forwarding service. The service sees that someone needs to visit the source URL, checks the mapped target URL for the same on its end, takes the content of the target URL, embeds it into a frame and then generates and returns the page.
One important thing to note in this kind of redirection is the non-changing URL in the address bar.
If abc.com is fetching content for xyz.com, and if the user clicks on some link on the page, the URL in the address bar would not change to abc.com/some-path even when the content will be fetched from xyz.com/some-path.
The reason the address bar does not reflect the path when using frames is because of how web browsers handle frames. The URL in the address bar is associated with the main document and not the individual frames within that document. Each frame is a separate HTML document with its own URL, but this URL is not displayed in the address bar of the browser.
When a frame is loaded, it's essentially a separate webpage being loaded within the main webpage. The browser treats each frame (and the content within) as a separate document. This means that when you navigate within a frame, the URL of the main document (which is what's displayed in the browser's address bar) doesn't change.
This redirection is not to be confused with CNAME redirection which is also a masked redirection.
CNAME redirection
This kind of redirection is masked.
The DNS lookup for a query when a URL is entered in the browser doesn't complete till an A/AAAA record is found since these are the ones that provide an IP for the browser to connect with.
A CNAME record involves a source and a destination and implies that every time an authoritative IP is fetched for the source domain, the target domain's resolution needs to kick in and its IP needs to be returned for that of the source domain.
So, this redirection works at the DNS level itself and hence, needless to say, the web server which sits behind that IP will need to handle requests for both domains. This is different from frame redirection where the web server doesn't have to handle requests from the source domain.
You can read more on this and the above 2 methods as well here.
Refresh Meta tag and HTTP refresh header
This kind of redirection is unmasked.
Upon adding a refresh meta tag to the HTML document, the browser automatically refreshes the page to the mentioned URL and if you mention the delay as 0, the refresh happens instantaneously simulating a redirection.
This works just like sending the Refresh header in the HTTP response.
So, the web server for the source domain can either serve an HTML page with the refresh meta tag mentioning the target URL or the web server can respond with the refresh header in the response and then the browser can serve the target URL page.