REQUEST FOR COMMENT
HTTP
RFC-2616
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, hypermedia information systems. HTTP has been in use by the
World-Wide Web global information initiative since 1990. The first version
of HTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer
across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved the
protocol by allowing messages to be in the format of MIME-like messages,
containing meta information about the data transferred and modifiers on the
request/response semantics. HTTP communication usually takes place over TCP/IP
connections. The default port is TCP 80 [19], but other ports can be used.
HTTP messages consist of requests from client to server and responses from
server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
When we are accessing through proxy, The proxy server MUST signal persistent
connections separately with its clients and the origin servers
(or other proxy servers) that it connects to. Each persistent connection
applies to only one transport link.
A proxy server MUST NOT establish a HTTP/1.1 persistent connection with an
HTTP/1.0 client.
An example Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
The set of common HTTP methods are
- GET
The GET method means retrieve whatever information is identified by the
Request-URI. If the Request-URI refers to a data producing process,
it is the produced data which shall be returned as the entity in the response
and not the source text of the process, unless that text happens to be the
output of the process.
- DELETE
The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or othermeans) on the origin server. The client cannot be
guaranteed that the operation has been carried out, even if the status code
returned from the origin server indicates that the action has been completed
successfully.
- CONNECT
This specification reserves the method name CONNECT for use with a proxy
- HEAD
The HEAD method is identical to GET except that the server MUST NOT return a
message-body in the response. The metainformation contained in the HTTP
headers in response to a HEAD request SHOULD be identical to the information
sent in response to a GET request. This method can be used for obtaining
metainformation about the entity implied by the request without transferring
the entity-body itself. This method is often used for testing hypertext links
for validity, accessibility, and recent modification.
reference::http://www.w3.org/Protocols/rfc2616/rfc2616.html
SMTP
RFC-821
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel.
An important feature of SMTP is its capability to relay mail across
transport service environments. A transport service provides an
interprocess communication environment (IPCE). An IPCE may cover one
network, several networks, or a subset of a network.
The SMTP design is based on the following model of communication: as
the result of a user mail request, the sender-SMTP establishes a
two-way transmission channel to a receiver-SMTP. The receiver-SMTP
may be either the ultimate destination or an intermediate. SMTP
commands are generated by the sender-SMTP and sent to the
receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
sender-SMTP in response to the commands.
Once the transmission channel is established, the SMTP-sender sends a
MAIL command indicating the sender of the mail. If the SMTP-receiver
can accept mail it responds with an OK reply. The SMTP-sender then
sends a RCPT command identifying a recipient of the mail. If the
SMTP-receiver can accept mail for that recipient it responds with an
OK reply; if not, it responds with a reply rejecting that recipient
(but not the whole mail transaction). The SMTP-sender and
SMTP-receiver may negotiate several recipients. When the recipients
have been negotiated the SMTP-sender sends the mail data, terminating
with a special sequence. If the SMTP-receiver successfully processes
the mail data it responds with an OK reply. The dialog is purposely
lock-step, one-at-a-time.
Once the transmission channel is established, the SMTP-sender sends a
MAIL command indicating the sender of the mail. If the SMTP-receiver
can accept mail it responds with an OK reply. The SMTP-sender then
sends a RCPT command identifying a recipient of the mail. If the
SMTP-receiver can accept mail for that recipient it responds with an
OK reply; if not, it responds with a reply rejecting that recipient
(but not the whole mail transaction). The SMTP-sender and
SMTP-receiver may negotiate several recipients. When the recipients
have been negotiated the SMTP-sender sends the mail data, terminating
with a special sequence.
TCP
RFC-793
The Transmission Control Protocol (TCP) is intended for use as a highly
reliable host-to-host protocol between hosts in packet-switched computer
communication networks, and in interconnected systems of such networks.
The TCP interfaces on one side to user or application processes and on
the other side to a lower level protocol such as Internet Protocol.
The TCP is able to transfer a continuous stream of bytes in each
direction between its users by packaging some number of bytes into
segments for transmission through the internet system. In general,
the TCPs decide when to block and forward data at their own
convenience. The TCP provides reliability by checking for
for data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system. This
is achieved by assigning a sequence number to each byte transmitted,and
requiring a positive acknowledgment (ACK) from the
receiving TCP. If the ACK is not received within a timeout
interval, the data is retransmitted.
TCP provides a means for the receiver to govern the amount of data
sent by the sender. This is achieved by returning a "window" with
every ACK indicating a range of acceptable sequence numbers beyond
the last segment successfully received. The window indicates an
allowed number of bytes that the sender may transmit before
receiving further permission.The reliability and flow control mechanisms
described above require that TCPs initialize and maintain certain status
information for each data stream. The combination of this information,
including sockets, sequence numbers, and window sizes, is called a connection.
Each connection is uniquely specified by a pair of sockets
identifying its two sides.
reference::http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1180.html
UDP
RFC-768
The User Datagram Protocol (UDP) is defined to make available a
datagram mode of packet-switched computer communication in the
environment of an interconnected set of computer networks. This
protocol assumes that the Internet Protocol (IP) [1] is used as the
underlying protocol.This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism.The protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed. The protocol consists of the following fields:
1. Source Port :
Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted.
2. Destination port :
Destination Port has a meaning within the context of a particular
internet destination address. Length is the length in bytes of the user
datagram including the header and the data.
3. CheckSum :
Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data, padded with zero bytes at the end.
The header prefixed to the UDP header contains the source address, the
destination address, the protocol, and the UDP length. The major uses of
this protocol is the Internet Name Server, and the Trivial File Transfer.
reference::http://www.faqs.org/rfcs/rfc768.html