Hyper Text Transfer Protocol
Hyper Text Transfer Protocol
Hyper Text Transfer Protocol
Clients and servers communicate by exchanging individual messages (as opposed to a stream
of data). The messages sent by the client, usually a Web browser, are called requests and the
messages sent by the server as an answer are called responses.
Designed in the early 1990s, HTTP is an extensible protocol which has evolved over time. It
is an application layer protocol that is sent over TCP, or over a TLS-encrypted TCP
connection, though any reliable transport protocol could theoretically be used. Due to its
extensibility, it is used to not only fetch hypertext documents, but also images and videos or
to post content to servers, like with HTML form results. HTTP can also be used to fetch parts
of documents to update Web pages on demand.
Each individual request is sent to a server, which will handle it and provide an answer, called
the response. Between this request and response there are numerous entities, collectively
designated as proxies, which perform different operations and act as gateways or caches, for
example.
In reality, there are more computers between a browser and the server handling the request:
Due to the layered structure of the Web stack, most of these operate at either the transport,
network or physical levels, becoming transparent at the HTTP layer and potentially
making a significant impact on performance. Those operating at the application layers are
generally called proxies. These can be transparent, or not (changing requests not going
through them), and may perform numerous functions:
caching (the cache can be public or private, like the browser cache)
filtering (like an antivirus scan, parental controls, …)
load balancing (to allow multiple servers to serve the different requests)
authentication (to control access to different resources)
logging (allowing the storage of historical information)
2. HTTP is extensible
Introduced in HTTP/1.0, HTTP headers made this protocol easy to extend and experiment
with. New functionality can even be introduced by a simple agreement between a client and a
server about a new header's semantics.
3. HTTP is stateless, but not sessionless
HTTP is stateless: there is no link between two requests being successively carried out on the
same connection. This immediately has the prospect of being problematic for users
attempting to interact with certain pages coherently, for example, using e-commerce
shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use
of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow,
allowing session creation on each HTTP request to share the same context, or the same state.
HTTP Messages
HTTP/1.1 and earlier HTTP messages are human-readable. In HTTP/2, these messages are
embedded into a new binary structure, a frame, allowing optimizations like compression of
headers and multiplexing. Even if only part of the original HTTP message is sent in this
version of HTTP, the semantics of each message is unchanged and the client reconstitutes
(virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2
messages in the HTTP/1.1 format.
There are two types of HTTP messages, requests and responses, each with its own format.
Requests
An example HTTP request:
An HTTP method, usually a verb like GET, POST or a noun like OPTIONS or HEAD that
defines the operation the client wants to perform. Typically, a client wants to fetch a resource
(using GET) or post the value of an HTML form (using POST), though more operations may
be needed in other cases.
The path of the resource to fetch; the URL of the resource stripped from elements that are
obvious from the context, for example without the protocol (http://),
the domain (here developer.mozilla.org), or the TCP port (here 80).
The version of the HTTP protocol.
Optional headers that convey additional information for the servers.
Or a body, for some methods like POST, similar to those in responses, which contain the
resource sent.
Responses
An example responses:
SMTP Commands
• SMTP commands are sent from the client to the server.
• Each command consists of a keyword or command name followed by zero or more
argument. It means some keywords do not contain any argument.
• The format of command is:
Keyword: argument(s)
• There are 14 different SMTP commands listed in the table below:
SMTP Responses
• SMTP responses are sent from server to client.
• Each response begins with a three digit code and may be followed by additional
textual information.
• The leading digits indicate the category of the response.
The difference categories of response are:
1. Positive completion reply. It indicates that the requested action has been successfully
completed. A new request may be initiated.
2. Positive Intermediate reply. It indicates that the command has been accepted, but the
requested action is being held in abeyance, pending receipt of further information.
3. Transient Negative Completion reply. It indicates that the command was not accepted
and the requested action did not occur. However, the error condition is temporary and the
action may be requested.
4. Permanent Negative Completion reply. It indicates the command was not accepted and
the requested action did not occur.
1. Connection set up
2. Mail transfer
3. Connection termination
Connection Setup
An SMTP sender will attempt to set up a TCP connection with a target host when it has one
or more mail message to deliver to that host. The following sequence occurs during
connection setup:
SMTP Commands
The SMTP standard defines a set of commands - names of specific types of messages that
mail clients to the mail server when requesting information. The most commonly used
commands are:
HELO and EHLO - commands that initiate a new protocol session between client
and server. The EHLO command requests them to respond with any optional SMTP
extensions it supports
MAIL - command to initiate sending an email message
RCPT - command to provide one email address for a recipient of the current message
being prepared
DATA - command indicating the start of transmission of the email message. This
command initiates a series of one or more follow-on messages each containing a piece
of the message. The last message in the sequence is empty (containing only a period
(.) as a termination character) to signify the end of the email.
RSET - while in the process of sending an email (after issuing the MAIL command),
either end of the SMTP connection can reset the connection if it encounters an error
NOOP - an empty ("no operation") message designed as a kind of ping to check for
responsiveness of the other end of the session
QUIT - terminates the protocol session
The recipient of these commands replies with either success or failure code numbers.
IMAP
Internet Message Access Protocol
Definition
IMAP is an internet standard that describes a protocol for retrieving mail from an email
(IMAP) server.
What Can IMAP Do?
Typically, messages are stored and organized in folders on the server. Email clients on
computers and mobile devices replicate that structure, at least in part, and synchronize actions
(such as deletion or moving messages) with the server.
That means multiple programs can access the same account and all show the same state and
messages, all synchronized.
It allows you to move messages between email accounts seamlessly, have third-party services
connect to your account to add functionality (for example, to automatically sort or back up
messages).
IMAP is an acronym for Internet Messaging Access Protocol, and the protocol’s current
version is IMAP 4 (IMAP4rev1).
IMAP allows the client program to manipulate the e-mail message on the server
without downloading them on the local computer.
The e-mail is hold and maintained by the remote server.
It enables us to take any action such as downloading, delete the mail without reading
the mail.It enables us to create, manipulate and delete remote message folders called
mail boxes.
IMAP enables the users to search the e-mails.
It allows concurrent access to multiple mailboxes on multiple mail servers
IMAP Commands
The following table describes some of the IMAP commands:
IMAP_LOGIN
1
This command opens the connection.
CAPABILITY
2
This command requests for listing the capabilities that the server supports.
NOOP
3 This command is used as a periodic poll for new messages or message status updates during a
period of inactivity.
SELECT
4
This command helps to select a mailbox to access the messages.
EXAMINE
5
It is same as SELECT command except no change to the mailbox is permitted.
CREATE
6
It is used to create mailbox with a specified name.
DELETE
7
It is used to permanently delete a mailbox with a given name.
RENAME
8
It is used to change the name of a mailbox.
LOGOUT
9 This command informs the server that client is done with the session. The server must send BYE
untagged response before the OK response and then close the network connection.
Simple Message Transfer Protocol (SMTP) is what your email client (e.g. Gmail,
Thunderbird, Outlook, etc.) uses to send your email messages to your email server. The email
server is often hosted by your email service provider, for instance Google, but it can be also
hosted by your Internet service provider (most often by the same one that hosts your domain).
Next, SMTP is also used by the email server to send your message to the mailbox of your
recipient’s email server. From there, the recipient’s email client can fetch your message
using Internet Message Access Protocol (IMAP) and put it in their inbox, where they can
access it.
RPC
Remote Procedure Call (RPC)
Remote Procedure Call (RPC) is a powerful technique for constructing distributed, client-
server based applications. It is based on extending the conventional local procedure calling,
so that the called procedure need not exist in the same address space as the calling
procedure. The two processes may be on the same system, or they may be on different
systems with a network connecting them.
1. The calling environment is suspended, procedure parameters are transferred across the
network to the environment where the procedure is to execute, and the procedure is executed
there.
2. When the procedure finishes and produces its results, its results are transferred back to the
calling environment, where execution resumes as if returning from a regular procedure call.
Working of RPC
When a user logs into a local timesharing system, it is called local log-in. As a user types at a
terminal or at a workstation running a terminal emulator, the keystrokes are accepted by the
terminal driver. The terminal driver passes the characters to the operating system. The
operating system, in turn, interprets the combination of characters and invokes the desired
application program or utility. When a user wants to access an application program or utility
located on a remote machine, she performs remote log-in. Here the TELNET client and
server programs come into use. The user sends the keystrokes to the terminal driver, where
the local operating system accepts the characters but does not interpret them. The characters
are sent to the TELNET client, which transforms the characters to a universal character set
called network virtual terminal (NVT) characters and delivers them to the local TCP/IP
protocol stack. The commands or text, in NVT form, travel through the Internet and arrive at
the TCP/IP stack at the remote machine. Here the characters are delivered to the operating
system and passed to the TELNET server, which changes the characters to the corresponding
characters understandable by the remote computer. However, the characters cannot be passed
directly to the operating system because the remote operating system is not designed to
receive characters from a TELNET server: It is designed to receive characters from a terminal
driver. The solution is to add a piece of software called a pseudoterminal driver which
pretends that the characters are coming from a terminal. The operating system then passes the
characters to the appropriate application program.