TCP provides a communication service at
an intermediate level between an application program and the Internet Protocol
That is, when an application program
desires to send a large chunk of data across the Internet using IP, instead of
breaking the data into IP-sized pieces and issuing a series of IP requests, the
software can issue a single request to TCP and let TCP handle the IP details.
Due to network congestion, traffic load
balancing, or other unpredictable network behavior, IP packets can be lost,
duplicated, or delivered out of order. TCP detects these problems, requests
retransmission of lost data, rearranges out-of-order data, and even helps
minimize network congestion to reduce the occurrence of the other problems.
Once the TCP receiver has reassembled the sequence of octets originally
transmitted, it passes them to the receiving application. Thus, TCP abstracts
the application’s communication from the underlying networking details.
TCP is optimized for accurate delivery
rather than timely delivery, and therefore, TCP sometimes incurs relatively
long delays (on the order of seconds) while waiting for out-of-order messages
or retransmissions of lost messages. It is not particularly suitable for
real-time applications such as Voice over IP. For such applications, protocols
like the Real-time Transport Protocol (RTP) running over the User Datagram
Protocol (UDP) are usually recommended instead
Hypertext is structured text that uses
logical links (hyperlinks) between nodes containing text. HTTP is the protocol
to exchange or transfer hypertext.
HTTP functions as a request-response
protocol in the client-server computing model.
HTTP is an application layer protocol
designed within the framework of the Internet Protocol Suite. Its definition
presumes an underlying and reliable transport layer protocol, and
Transmission Control Protocol (TCP) is commonly used. However HTTP can use
unreliable protocols such as the User Datagram Protocol (UDP), for example in
Simple Service Discovery Protocol (SSDP).
HTTP resources are identified and located
on the network by Uniform Resource Identifiers (URIs)—or, more specifically,
Uniform Resource Locators (URLs)—using the http or https URI schemes. URIs and
hyperlinks in Hypertext Markup Language (HTML) documents form webs of
inter-linked hypertext documents.
HTTP/1.1 is a revision of the original
HTTP (HTTP/1.0). In HTTP/1.0 a separate connection to the same server is made
for every resource request. HTTP/1.1 can reuse a connection multiple times to
download images, scripts, stylesheets et cetera after the page has been
delivered. HTTP/1.1 communications therefore experience less latency as the
establishment of TCP connections presents considerable overhead.
An HTTP session is a sequence of network
request-response transactions. An HTTP client initiates a request by
establishing a Transmission Control Protocol (TCP) connection to a particular
port on a server (typically port 80; see List of TCP and UDP port numbers). An
HTTP server listening on that port waits for a client’s request message. Upon
receiving the request, the server sends back a status line, such as
“HTTP/1.1 200 OK”, and a message of its own. The body of this message
is typically the requested resource, although an error message or other
information may also be returned
Persistent connections 
HTTP persistent connection
In HTTP/0.9 and 1.0, the connection is
closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism
was introduced, where a connection could be reused for more than one request.
Such persistent connections reduce request latencyperceptibly, because the
client does not need to re-negotiate the TCP 3-Way-Handshake connection after
the first request has been sent. Another positive side effect is that in
general the connection becomes faster with time due to TCP’s
Version 1.1 of the protocol also made
bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1
introduced chunked transfer encoding to allow content on persistent connections
to be streamed rather than buffered. HTTP pipelining further reduces lag time,
allowing clients to send multiple requests before waiting for each response.
Another improvement to the protocol was byte serving, where a server transmits
just the portion of a resource explicitly requested by a client.
HTTP session state
HTTP is a stateless protocol. A stateless
protocol does not require the HTTP server to retain information or status about
each user for the duration of multiple requests. However, some web applications
implement states or server side sessions using one or more of the following
Hidden variables within web forms.
Query string parameters, for example,
10. HTTP Pipelining
HTTP pipelining is a technique in which
multiple HTTP requests are sent on a single TCP connection without waiting for
the corresponding responses.
The limitation of HTTP 1.1 still applies:
the server must send its responses in the same order that the requests were
received — so the entire connection remains first-in-first-out  and HOL
blocking can occur. The asynchronous operation of the upcoming HTTP 2.0 or SPDY
could be a solution for this.
The Microsoft .NET Framework 3.5 supports
HTTP pipelining in the module System.Net.HttpWebRequest.[
Out of all the major browsers, only Opera
has a fully working implementation that is enabled by default. All other
browsers HTTP pipelining is disabled or not implemented
11. HTTP 2.0
HTTP 2.0 is the next planned version of
the HTTP network protocol used by the World Wide Web.
HTTP 2.0 would be the first new version
of the HTTP protocol since HTTP 1.1 was described by RFC 2616 in 1999.
Goals for HTTP 2.0 include asynchronous
connection multiplexing, header compression, and request-response pipelining,
while maintaining full backwards compatibility with the transaction semantics
of HTTP 1.1.
SPDY (pronounced speedy) is an open
networking protocol developed primarily at Google for transporting web content
SPDY achieves reduced latency through
compression, multiplexing, and prioritization.
SPDY does not replace HTTP; it modifies
the way HTTP requests and responses are sent over the wire. This means that
all existing server-side applications can be used without modification if a
SPDY-compatible translation layer is put in place. When sent over SPDY, HTTP
requests are processed, tokenized, simplified and compressed. For example, each
SPDY endpoint keeps track of which headers have been sent in the past requests
and can avoid resending the headers that have not changed; those that must be
sent are sent compressed.
TCP is a communications protocol which
operates the transport layer and allows the packets of information to make it
around the internet from the host to the receiving computer.
is an access protocol that can use the internet to access the web or web pages.
It is a method that the browser software uses to access a particular file or
web page on the internet. Alternate to it is FTP.
HTTP is a layer built ontop of the TCP
layer to somewhat standardize data transmission. So naturally using TCP sockets
will be less heavy than using HTTP. If performance is the only thing you care
about then plain TCP is the best solution for you.
You may want to
consider HTTP because of its ease of use and simplicity which ultimately
reduces development time. If you are doing something that might be directly
consumed by a browser (through an AJAX call) then you should use HTTP. For a
browser to directly consume TCP connections without HTTP you would have to use
Flash or Silverlight and this normally happens for rich content such as video
In general performance oriented system
like those in the military or financial sectors will probably use plain TCP
connections. Where as general web focused companies will opt to use HTTP and
use IIS or Apache to host their services.
TCP guarantees the correct delivery of segments (TCP packets), that’s a feature
that HTTP doesn’t need to worry about. However, for some protocols like H.323
and SIP for VoIP, the use of UDP is critical and not simply a “design
decision” since UDP works faster that TCP because UDP reduces overhead due
to its simplicity.
is stateless, and thus doesn’t keep ports open