What is the difference between repeater over datalist and datagrid?

The Repeater class is not derived from the WebControl class, like the DataGrid and DataList. Therefore, the Repeater lacks the stylistic properties common to both the DataGrid and DataList. What this boils down to is that if you want to format the data displayed in the Repeater, you must do so in the HTML markup.
The Repeater control provides the maximum amount of flexibility over the HTML produced. Whereas the DataGrid wraps the DataSource contents in an HTML < table >, and the DataList wraps the contents in either an HTML < table > or < span > tags (depending on the DataList's RepeatLayout property), the Repeater adds absolutely no HTML content other than what you explicitly specify in the templates.
While using Repeater control, If we wanted to display the employee names in a bold font we'd have to alter the "ItemTemplate" to include an HTML bold tag, Whereas with the DataGrid or DataList, we could have made the text appear in a bold font by setting the control's ItemStyle-Font-Bold property to True.
The Repeater's lack of stylistic properties can drastically add to the development time metric. For example, imagine that you decide to use the Repeater to display data that needs to be bold, centered, and displayed in a particular font-face with a particular background color. While all this can be specified using a few HTML tags, these tags will quickly clutter the Repeater's templates. Such clutter makes it much harder to change the look at a later date. Along with its increased development time, the Repeater also lacks any built-in functionality to assist in supporting paging, editing, or editing of data. Due to this lack of feature-support, the Repeater scores poorly on the usability scale.
However, The Repeater's performance is slightly better than that of the DataList's, and is more noticeably better than that of the DataGrid's. Following figure shows the number of requests per second the Repeater could handle versus the DataGrid and DataList

Explain < @OutputCache% > and the usage of VaryByParam, VaryByHeader.

OutputCache is used to control the caching policies of an ASP.NET page or user control. To cache a page @OutputCache directive should be defined as follows < %@ OutputCache Duration="100" VaryByParam="none" % >
VaryByParam: A semicolon-separated list of strings used to vary the output cache. By default, these strings correspond to a query string value sent with GET method attributes, or a parameter sent using the POST method. When this attribute is set to multiple parameters, the output cache contains a different version of the requested document for each specified parameter. Possible values include none, *, and any valid query string or POST parameter name.
VaryByHeader: A semicolon-separated list of HTTP headers used to vary the output cache. When this attribute is set to multiple headers, the output cache contains a different version of the requested document for each specified header

What is the difference between HTTP-Post and HTTP-Get?

As their names imply, both HTTP GET and HTTP POST use HTTP as their underlying protocol. Both of these methods encode request parameters as name/value pairs in the HTTP request.
The GET method creates a query string and appends it to the script's URL on the server that handles the request.
The POST method creates a name/value pairs that are passed in the body of the HTTP request message.
Name and describe some HTTP Status Codes and what they express to the requesting client.
When users try to access content on a server that is running Internet Information Services (IIS) through HTTP or File Transfer Protocol (FTP), IIS returns a numeric code that indicates the status of the request. This status code is recorded in the IIS log, and it may also be displayed in the Web browser or FTP client. The status code can indicate whether a particular request is successful or unsuccessful and can also reveal the exact reason why a request is unsuccessful. There are 5 groups ranging from 1xx - 5xx of http status codes exists.
101 - Switching protocols.
200 - OK. The client request has succeeded
302 - Object moved.
400 - Bad request.
500.13 - Web server is too busy.