I have always heard that TCP is short for TCP/IP and they mean the same thing.
However, is it not possible for TCP to be built on top of another protocol besides IP?
|
|
I haven't read the whole RFC but the language in section 1.4 seems to suggest that any "lower level" protocol can be used.
|
|||||||||||||||||||||
|
Internet Protocol SuiteTCP is not short for TCP/IP. TCP/IP is often used as a shorthand way of saying "The Internet Protocol Suite" and usually includes other standard protocols. When people say TCP/IP they are usually including UDP over IP (in which UDP is used instead of TCP) and a great many other protocols such as ARP, ICMP, DNS, SNMP and other application layer protocols. Application LayerApplications use Application Layer protocols such as SMTP (for email). These sit on one of two transport layer protocols - TCP and UDP. A few application layer protocols will use either or both of UDP and TCP but most are used with only one transport layer protocol. Transport LayerTCP and UDP are two transport layer protocols used in the Internet Protocol Suite. Internetwork LayerWhilst it might be theoretically possible to use TCP over something other than IP, in practice TCP is always used over IP - the Internet Protocol. IP moves packets between networks (think of IP as connecting multiple LANs together) Network Interface LayerEthernet is just the most popular family of low-level link-layer protocols on which TCP/IP is carried, but TCP/IP is also widely used over ATM and others.
†Just for fun, I measured traffic on my (very) small LAN, which includes NetBIOS (over TCP), SSH, Rsync, Email, software updates, DNS, general Windows-box chatter and a few other types of traffic. |
|||||||||||
|
|
The reason why TCP/IP is such a common abbreviation (as opposed to, say UDP/IP or SCTP/IP) is because the two protocols were designed together, and in the original paper by Vint Cerf and Bob Kahn, the two concepts were combined together into a single protocol. Soon thereafter they were divided into IP to provide routing and TCP to provide flow control, multiplexing, error-detection, etc. It wasn't until six years later that UDP was introduced to provide a "lightweight" multiplexing layer without the rest of the overhead involved with TCP. Still, TCP and IP are two separate things and completely and intentionally independent. The fact that TCP does not require IP is immediately apparent with the fact that TCP can run unmodified on both IPv4 and IPv6, which are two completely different protocols. With a little work, you could create a competing protocol to IP that would serve the same purposes, but it would probably have to contain most if not all of the same features, and would probably end up looking a lot like IP anyway. You could argue that extensions to IP (such as IPSec) are effectively alternate layer 3 protocols, so there you go. |
|||||||
|
|
You can replace IP with something else. In fact, that's exactly what you're doing when you're using TCP over IPv6. TCP is still TCP, but the IP is v6 instead of v4. AFAIK, nobody's created any other layer-3 protocols to work with TCP above them, but there's no reason you couldn't. |
|||
|
|
Actually it stands for Transmission Control Protocol over Internet Protocol
That's not correct. First, Ethernet is the low-level hardware system that controls how the actual hardware parts function. Next, think of IP as a phone system or traffic signs. It provides the basic control of connecting system two points together. TCP on the other hand is more like a messaging system or traffic control officer which directs messages/cars to the correct point. Taken together, TCP/IP, provides a system of reliably transferring data to and from any two connected devices. With the Internet, when you want to send or receive data, the IP part of the system is the part that controls making the actual hardware connections with the wires (or wireless waves). The TCP part of the system is the software that is responsible for taking the data and breaking it up, sending it, reassembling the received data, and checking the data and re-sending if necessary. There are countless explanations with analogies and technical details available, especially in video form. DifferenceBetween.net has a particularly good one about this exact subject.
Yes, you could indeed create an alternate system to TCP that uses IP. Take a look at the Internet Protocol Suite for some details. |
|||||||||||||||||||||
|
|
TCP and IP are like butter over bread. You can pair anything else that works with either protocol, but these two are so complementary it is just a yummy reliable way to transfer data and fill the tummy with internet data. It greases the tube to allow other dry foodstuff and data handshaking alike to support this pairing. But in no way is it exclusive. Q However, is it not possible for TCP to be built on top of another protocol besides IP? A Yes it is possible. I like the Morse Code and Pigeon examples of TCP without IP. |
|||
|
|
|
TCP is a layer 4 protocol. It provides guaranteed transportation of data in form of an ordered stream from one process on a computer to another process on same/another computer. IP is a layer 3 protocol. It provides transportation from one host to another. As long as there is a protocol which can do host to host transfer of data, TCP will work. So, TCP can be implemented over any protocol, but, We have only made IP. IP is simple and does the work. There is no need for another Layer 3 protocol. |
|||||||||||||||
|
|
When you design a network, you've got to choose a set of protocols (which are basically sets of communication rules between machines), for each of various "layers" (which you can imagine as different abstraction levels, that network designers like to keep in mind when creating and combining protocols). Simpler version: protocols are like boxes in which we put our messages. Those boxes have different sizes, and you put your message in the smallest box, then the smallest box in a box that is a little bigger, etc. Choosing a set of protocols is choosing what kind of boxes you'll use, for each "layer" that surrounds your message. TCP and IP are protocols for two independent layers, that were created together and to be usable together; but can very well be used with other protocols. That happens fairly often: you can use IP along with a non-TCP protocol, or TCP along with a non-IP protocol. The reason why TCP/IP is such a common abbreviation is that those two protocols formed, together, the basis of the Internet and were key to its success. (TCP and IP do have some functionalities that were designed specifically for them to function together, which is something purists often complain about, but they don't really prevent you from interfacing them with other protocols) |
||||
|
|
|
I think it's possible to run TCP over IPX transport, if you want to go retro. |
|||||||
|
|
Implementations of TCP on top of various protocols that support the transport of a basic datagram already exist. In fact the need is not even to specify the routing information (TCP does not even need IP to work with, just a serila link with an implicit recipient would be enough). So you've got TCP implemented in top of UDP (advantage : you use a single port on the "server" side, or you can embed it over an existing connection transporting various multiplexed channels). Only the IP level provides the routing, but TCP does not need it. All that matters is that the concept of a MTU is provided by the lower layer. This allows the protocol to bypass the limitations of NAT traversal, without requiring to register an UPnP translation port for a specific host. It allows independant tuning of the MTU and MSS, optimized for each client instead of by each iintermediate shared router. Other routing protocols are possible (includnig for the delivery via Multicast and broadcast networks). And you have the choice of sthe scurity mechanisms. An example of use if Gogo6.net (which implements its IPv6 transport channel over a TCP session using a reimplementation of TCP over UDP v4 (it works on most home acccess routers that still only have an IPv4 address, and not always suppporting the UPnP method; without any need to configure it by users using a constant port number specific to the application, even when it is not running) |
|||
|
|
Beside the classical TCP/IPv4 and TCP/IPv6, a few experimental protocols have been designed, for example:
And iproxy: Running TCP services over UDP, which is more fun:
So you see: TCP on unicast UDP, and even TCP on broadcast or multicast UDP! AFAIK only TCP/IPv4 and TCP/IPv6 enjoy a large deployment. |
|||||
|
|
|
The answer is no! For example there is an old RFC describing TCP over IPX: http://tools.ietf.org/html/rfc1791 For those with short memories, IPX was the Novell Netware protocol: http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange |
|||
|
|
There are examples of communication systems in the military using TCP but not IP since the comm path is a serial-type connection that doesn't get routed thru routers, etc. If you look at the a TCP packet before it's headered with IP fields it seems easily possible to not use IP if your "routing" protocol is different. |
|||
|
|