Nov 25, 2013 ~ Network Services

The Transmission Control Protocol TCP is the Transport layer of the protocol and serves to ensure a reliable, verifiable data exchange between hosts on a network. TCP breaks data into pieces, wraps the pieces with the information needed to identify it as a piece of...

Share: Facebook Twitter Google+

TCP/IP and the OSI Model As you learned in Chapter 2, “The OSI Model,” the OSI model divides computer-to-computer communications into seven connected layers; TCP/IP uses the Department of Defense (DoD) model, which describes communications in only four layers, as Figure...

Share: Facebook Twitter Google+

TCP/IP Design Goals When the U.S. Department of Defense began to define the TCP/IP network protocols, their design goals included the following: TCP/IP had to be independent of all hardware and software manufacturers. Even today, this is fundamentally why TCP/IP makes such good sense in the corporate world: It is...

Share: Facebook Twitter Google+

A Brief History of TCP/IP The first Request for Comments (RFC) was published in April 1969, laying the groundwork for today’s Internet, the protocols of which are specified in the numerous RFCs monitored, ratified, and archived by the Internet Engineering Task Force (IETF). TCP/IP was first proposed in 1973 and was split into separate protocols,...

Share: Facebook Twitter Google+

Introducing TCP/IP Because TCP/IP is so central to working with the Internet and with intranets, you should understand it in detail. We’ll start with some background on TCP/IP and how it came about and then move on to the descriptions of the technical goals defined by the original designers. Then you’ll get a look at how TCP/IP compares...

Share: Facebook Twitter Google+

The Transmission Control Protocol
TCP is the Transport layer of the protocol and serves to ensure a reliable, verifiable data exchange between hosts on a network. TCP breaks data into pieces, wraps the pieces with the information needed to identify it as a piece of the original message, and allows the pieces to be reassembled at the receiving end of the communications link. The wrapped and bundled pieces are called datagrams. Datagrams are also referred to as segments for TCP due to the way it often splits the original data into more manageable chunks. The most important information in the header includes the source and destination port numbers, a sequence number for the datagram, and a checksum.
The source port number and the destination port number ensure that the data is sent back and forth to the correct application process running on each computer. The sequence number allows the datagrams to be rebuilt in the correct order in the receiving device, and the checksum allows the protocol to check whether the data sent is the same as the data received. It performs this last feat by running the bits of the segment through a complex polynomial expression and inserting the resulting number in the header. This is when IP enters the picture. Once the header is on the datagram, TCP passes the datagram to IP to be routed to its destination. The receiving device then performs the same calculation, and if the two calculations do not match, an error has occurred somewhere along the line and the datagram is silently discarded by the destination device and resent by the source device after its timer expires waiting for a positive acknowledgment that never arrives.

Figure 3.2 shows the layout of the datagram with the TCP header in place.

In addition to the source and destination port numbers, the sequence number, and the checksum, a TCP header contains the following information:

Acknowledgment Number Indicates that the data was received successfully. If the datagram is damaged in transit, the receiver throws the data away and does not send an acknowledgment

back to the sender. After a predefined time-out expires, the sender retransmits the data for which no acknowledgment was received. Only positive forward acknowledgments are sent in TCP. Positive means that only successful transmissions are acknowledged. Forward means that the acknowledgment number represents the next sequence number the destination device expects to receive.

Offset Specifies the length of the header in 32-bit chunks.

Reserved This field specifies variables that are set aside for future use. This field must contain zeros.

Flags These are six one-bit fields that indicate various things, such as whether this segment is the end of the higher-layer message, that the acknowledgment number is significant, that the sender is requesting that a virtual circuit with the receiver be established or torn down, or that the data in the segment is urgent.

Window Provides a way to increase the number of segments transmitted before the sender expects an acknowledgment, which improves efficiency in data transfers. Conversely, decreasing

the value of this field can indicate that network problems endanger the integrity of the data so more segments need to be acknowledged until conditions improve.

Urgent Pointer Gives the location in the segment where the urgent data ends, assuming the urgent data begins at the beginning of the segment. This allows out-of-band transmission of special

data, signifying to the receiving device that this data should be pushed ahead of any other that it has received but has not yet processed. Special data could include keyboard break sequences in

a Telnet session, which should immediately be processed by the receiving device in order to discontinue potentially harmful processing of previously received data. In light of this use, it makes

sense that the transmitting device would place such critical control information at the beginning of a new, emerging segment.

Options Communicates various parameters of the TCP virtual circuit. The only option originally specified in the TCP RFC (RFC 793) was maximum segment size, which has to be communicated
in the first segment during connection establishment. Later RFCs specify additional options. The latest list of TCP options can be found on the web site for the Internet Assigned Numbers Authority (www.iana.org/assignments/tcp-parameters).

Padding Ensures that the header ends on a 32-bit boundary so that the offset field makes sense as a whole number.

The data in the segment immediately follows this header information.

The Actual Use of TCP Communications
The following list summarizes the TCP process:

Flow control allows two systems to cooperate in datagram transmission to prevent overflows and lost segments.
Acknowledgment lets the sender know that the recipient has received the information.
Sequencing ensures that segments arrive in the proper order.
Checksums allow easy detection of corrupted segments.
Retransmission of lost or corrupted segments is managed in a timely way.

TCP/IP and the OSI Model
As you learned in Chapter 2, “The OSI Model,” the OSI model divides computer-to-computer communications into seven connected layers; TCP/IP uses the Department of Defense (DoD)
model, which describes communications in only four layers, as Figure 3.1 shows. Each successively higher layer builds on the functions provided by the layers below.

Note:

The DoD model has fewer layers than the OSI model has, but that does not mean that it has less functionality. We draw the models to the same height because all data communications functionality is there. The DoD model simply combines the functionality of those layers into “larger” layers whose protocols perform all related functions of the equivalent OSI layers. Remember, that’s part of the OSI reference model’s success. Even though the original protocols never really caught on, the model itself is at once generic in its description of
protocol functionality and specific in its separation of communications tasks into more layers than just about any other model.

FIGURE 3 . 1 A comparison of the seven-layer OSI model, the four-layer DoD model, and how TCP/IP maps to each model

As you may remember from Chapter 2’s discussion of the OSI model, the layers are as follows:

Application Layer The highest layer; defines the manner in which applications interact with the network—including databases, e-mail, and terminal-emulation programs using Application layer protocols similar to Lightweight Directory Access Protocol (LDAP), Simple Mail Transfer Protocol (SMTP), and Telnet.

Presentation Layer Defines the way in which data is formatted, presented, converted, and encoded.

Session Layer Coordinates communications and maintains the session for as long as it is needed—performing security, logging, and administrative functions.

Transport Layer Defines protocols for structuring messages and supervises the validity of the transmission by performing error checking.

Network Layer Defines data-routing protocols to increase the likelihood that the information arrives at the correct destination node.

Data Link Layer Validates the integrity of the flow of the data from one node to another by synchronizing blocks of data and controlling the flow.

Physical Layer Defines the mechanism for communicating with the transmission medium and the interface hardware.

Note:

Although no commercially available networking protocol suite follows the OSI model exactly, most perform all the same functions.

In the DoD model, the four layers are as follows:

Process/Application Layer The highest layer; applications such as FTP, Telnet, and others interact through this layer. Corresponds to the top three layers of the OSI model.

Host-to-Host Layer TCP and UDP add transport control information to the user data. Corresponds to the Transport layer of the OSI model.

Internet Layer Adds IP information to form a packet. Corresponds to the Network layer of the OSI model.

Network Access Layer Defines the mechanism for communicating with the transmission medium and the interface hardware. Corresponds to the bottom two layers of the OSI model.

Each layer adds its own header and, in the case of Data Link protocols, trailer control information to the basic data structure and encapsulates the protocol data unit (PDU) from the layer

above. On the receiving end, this header and trailer information is stripped, one layer at a time, until the equivalent of the original data arrives at its final destination.

Note:

PDU is a generic term used to describe the end product of a protocol. It can be thought of as the entire data structure handed down by that protocol to the protocol at the next lowest layer, or the information placed on the network media by the Physical layer. A PDU will consist of the original user data and any upper-layer control information (headers and trailers) imposed by upper-layer protocols encapsulated by the control information of the protocol creating the PDU.

Now let’s look at how TCP and IP work together.

TCP/IP Design Goals
When the U.S. Department of Defense began to define the TCP/IP network protocols, their design goals included the following:

TCP/IP had to be independent of all hardware and software manufacturers. Even today, this is fundamentally why TCP/IP makes such good sense in the corporate world: It is not tied to IBM, Novell, Microsoft, DEC, or any other specific company.
It had to have good built-in failure recovery. Because TCP/IP was originally a military proposal, the protocol had to be able to continue operating even if large parts of the network suddenly disappeared from view, say, after an enemy attack.
It had to handle high error rates and still provide completely reliable end-to-end service. It had to be efficient and have a low data overhead. The majority of IP packets have a simple, 20-byte header, which means better performance in comparison with other networks. A simple protocol translates directly into faster transmissions, giving more efficient service. It had to allow the addition of new networks without any service disruptions.

As a result, TCP/IP was developed with each component performing unique and vital functions that allowed all the problems involved in moving data between machines over networks

to be solved in an elegant and efficient way. Before looking at both TCP and IP individually, you should understand where TCP/IP fits into the broader world of network protocols and, particularly,

how it compares to the theoretical reference model published by the International Organization for Standardization (ISO) as the OSI model.

The popularity that the TCP/IP family of protocols enjoys today did not arise just because the protocols were there, or even because the U.S. government mandated their use. They are popular because they are robust, solid protocols that solve many of the most difficult networking problems and do so in an elegant and efficient way.

The Internet, an internet, an intranet, and an extranet
The title of this sidebar may be a bit confusing and look a bit informal with the odd capitalization, but it’s for a very good reason. While internet is a truncated version of internetwork, a lot of play has come from the root of these words. Let’s examine the word internetwork first, just to make sure we understand where all the variants come from. As you know, a network is a conglomeration
of devices tied together with a common technology. Well, once you establish two or more of these networks, work can be started on bringing them together. The interconnection and intercommunication between these autonomous networks is known as an internetwork or just internet. We know we have an internet when we use routers or other layer 3 devices to interconnect the networks. What kind of fun can we have with these words?

First of all, just by capitalizing the word internet to form Internet, we get the proper name of the global commercial internetwork that is tied together by TCP/IP (actually, all of these entities are)
and that has a scope of the planet we call home. If those Mars rovers have IP addresses, the scope suddenly gets a bit grander. That’s the flexibility of TCP/IP for you. What if we analyze the
meaning of inter? An internet is connectivity and communication across network boundaries. Does that mean, then, that an intranet is connectivity and communication within a network?
Gotcha. An intranet is more an opposite of the Internet, in terms of scope. If the Internet spans many administrative boundaries, encompassing many disparate networks, then an intranet,
while often an internet (how’s that for a catch?), encompasses only networks under a single administrative domain, a large corporation’s internal internetwork. Did you catch that? An intranet can be an internet, but not the Internet. Fun, huh?
Well, then, that just leaves extranet. Think of an extranet as an intranet becoming a very controlled Internet. That is, if an intranet is made up of all networks under a single administrative control, then an extranet is the expansion of that to include one, two, or just a few additional outside networks. Said differently, an extranet is an intranet interconnected and intercommunicating with networks that are under separate administrative control. This isn’t nearly as
unruly as the Internet, because this interconnectivity arose from some sort of partnership or affiliation between the parties. Let’s say, for instance, that a manufacturing company wants to have a vendor monitor its inventory so that whenever materials that the vendor supplies reach a minimum threshold, an order can be generated automatically, without personnel from the manufacturing company getting involved. That would require some sort of limited vendor access to internal manufacturing company resources. While the manufacturing company wants the vendor to have access to all that they need to help automate the supply process, they don’t want the vendor accessing sensitive financial, personnel, or possibly engineering information. By tweaking the firewalls just so, the vendor’s trusted network assets can be allowed access to the manufacturing company’s inventory control system but nothing else. That’s an extranet. While there’s a big difference between them all, they are all very similar. They are all generally TCP/IP internetworks.

Benefits of Using TCP/IP over Other Networking Protocols
There are several benefits to using the TCP/IP networking protocol:

TCP/IP is a widely published open standard and is completely independent of any hardware or software manufacturer.
TCP/IP can send data between different computer systems running completely different operating systems, from small PCs all the way to mainframes and everything in between.
TCP/IP is separated from the underlying hardware and will run over Ethernet, Token Ring, and X.25 networks, to name a few, and even over dial-up telephone lines.
TCP/IP is a routable protocol, which means it can send datagrams over a specific route, thus reducing traffic on other parts of the network.
TCP/IP has reliable and efficient data-delivery mechanisms.
TCP/IP uses a common addressing scheme. Therefore, any system can address any other system, even in a network as large as the Internet. (We will look at this addressing scheme in the section “Understanding IP Addressing” later in this chapter.)

A Brief History of TCP/IP
The first Request for Comments (RFC) was published in April 1969, laying the groundwork for today’s Internet, the protocols of which are specified in the numerous RFCs monitored,
ratified, and archived by the Internet Engineering Task Force (IETF). TCP/IP was first proposed in 1973 and was split into separate protocols, TCP and IP, in 1978. In 1983, TCP/IP
became the official transport mechanism for all connections to ARPAnet, a forerunner of the Internet, replacing the earlier Network Control Protocol (NCP). ARPAnet was developed by
the Department of Defense’s (DoD’s) Advanced Research Projects Agency (ARPA), formed in 1957 in response to the Soviet Union’s launch of Sputnik and later renamed the Defense Advanced Research Projects Agency (DARPA), which was split into ARPAnet and MILNET in 1983 and disbanded in 1990.
Much of the original work on TCP/IP was done at the University of California, Berkeley, where computer scientists were also working on the Berkeley version of UNIX (which eventually grew into the Berkeley Software Distribution [BSD] series of UNIX releases). TCP/IP was added to the BSD releases, which in turn was made available to universities and other institutions for the cost of a distribution tape. Thus, TCP/IP began to spread in the academic world, laying the foundation for today’s explosive growth of the Internet and of intranets as well.
During this time, the TCP/IP family continued to evolve and add new members. One of the most important aspects of this growth was the continuing development of the certification and
testing program carried out by the U.S. government to ensure that the published standards, which were free, were met. Publication ensured that the developers did not change anything or
add any features specific to their own needs. This open approach has continued to the present day; use of the TCP/IP family of protocols virtually guarantees a trouble-free connection

between many hardware and software platforms.

Introducing TCP/IP

Because TCP/IP is so central to working with the Internet and with intranets, you should understand it in detail. We’ll start with some background on TCP/IP and how it came about and then move on
to the descriptions of the technical goals defined by the original designers. Then you’ll get a look at how TCP/IP compares to a theoretical model, the Open Systems Interconnect (OSI) model.

Network Services

Hotspot Mikrotik 777

Design Hotspot-12 beautiful Server Mikrotik

Hotspot login server free

Merge 2 lines in server Pfsense?

setup squid cahce in Ubuntu

Monday, November 25, 2013

The Transmission Control Protocol

TCP/IP and the OSI Model

TCP/IP Design Goals

A Brief History of TCP/IP

Introducing TCP/IP

REC

REC

Search

Followers

Blog Archive

Subscribe Here

Sponsor

Categories

About

Social Share

Business

Gallery

videos

Categories

Labels

Blog Archive

Monday, November 25, 2013

The Transmission Control Protocol

TCP/IP and the OSI Model

TCP/IP Design Goals

A Brief History of TCP/IP

Introducing TCP/IP

Recent Posts

Theme Support

Total Pageviews

Monday, November 25, 2013

Social Profiles

REC

REC

Search

Followers

Blog Archive

Subscribe Here

Sponsor

Categories

About

Social Share

Business

Gallery

videos

Categories

Labels

Blog Archive

Monday, November 25, 2013

Recent Posts

Theme Support

Total Pageviews