Is it true that TCP is short for TCP/IP and they mean the same thing?
TCP and IP (v4 & v6) are definitely separable, and one does not imply the other, as proved by the example of TCP over IPX (RFC 1791).
However, TCP cannot be built over just any network protocol. Two reasons:
- There is no segment size field in the TCP header (only the Data Offset, which gives the size of the TCP header). Therefore TCP will work only with a lower layer protocol that includes enough information to calculate the size of the TCP segment (i.e., the payload size of the lower layer protocol). That assumption is true for IPv4 (RFC 791), IPv6 (RFC 2460) and IPX (RFC 1791). But not true in general, e.g., not for avian carriers (RFC 1149) (see note a).
- TCP is only designed to work over a connectionless network protocol. TCP effectively does not work over certain connection-oriented network protocols (e.g., the ATM constant bit-rate service), because the two fighting rate control functions lead to very poor or unpredictable performance. Another degenerate example is TCP over a TCP tunnel.
The TCP specification, RFC 793, is not a good source to decide this question, because it admits that it leaves its interface with the lower layer largely unspecified.
Note a) For TCP to reassemble datagrams printed on little sheets of paper (whether carried by pigeons or a more intelligent corvid network), the size of the payload would have to be written in a standard location. Alternatively, an adaptation layer could heuristically determine the segment size. The optical scanner used in the implementation of the host stack of the avian carriers spec (RFC 1149) included such an heuristic adaptation layer, but it remains undocumented.
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.
The interface between TCP and lower level protocol is essentially unspecified except that it is assumed there is a mechanism whereby the two levels can asynchronously pass information to each other. Typically, one expects the lower level protocol to specify this interface. TCP is designed to work in a very general environment of interconnected networks. The lower level protocol which is assumed throughout this document is the Internet Protocol.
Internet Protocol Suite
TCP 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.
Applications 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.
TCP and UDP are two transport layer protocols used in the Internet Protocol Suite.
If there are others I don't know of them and any others would represent a vanishingly small specialist use. Others transport layer protocols have been defined - their usage probably represents only a small proportion of global IP traffic†
Whilst 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 Layer
Ethernet 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.
Appendix 1 - A note on Transport Layer Protocols
The only transport layer protocols in significant use on networks that use the Internet Protocol Suite are TCP and UDP.
†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.
Note also this statement in Google's FAQ for their QUIC protocol
Why didn’t you build a whole new protocol, rather than using UDP? Middle boxes on the Internet today will generally block traffic unless it is TCP or UDP 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.
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.
I have always heard that TCP is short for TCP/IP
Actually it stands for Transmission Control Protocol over Internet Protocol
and they mean the same thing.
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.
However, is it not possible for TCP to be built on top of another protocol besides 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)
However, is it not possible for TCP to be built on top of another protocol besides IP?
Beside the classical TCP/IPv4 and TCP/IPv6, a few experimental protocols have been designed, for example:
As part of our Net100 and Probe efforts in improving bulk transfers over high speed, high latency networks, we have developed an instrumented and tunable version of TCP that runs over UDP. The UDP TCP-like transport serves as a test-harness for experimenting with TCP-like controls at the application level similar to TReno.
And iproxy: Running TCP services over UDP, which is more fun:
iproxy comprises of a client-side proxy and a server-side proxy that allows arbitrary TCP/IP services to run over Broadcast, Multicast or Unicast UDP. It was originally conceived as a method to configure servers that had not been given an IP address on the LAN using an web-based interface.
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: https://www.rfc-editor.org/rfc/rfc1791
For those with short memories, IPX was the Novell Netware protocol: http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange
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 didirectional serial link with an implicit recipient would be enough; you could as well implement TCP over a pair of pipes)
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 intermediate shared router. Other routing protocols are possible (including for the delivery via Multicast and broadcast networks). And you have the choice of the security mechanisms.
An example of use is 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)
Other examples is to encapsulate TCP over HTTP (or HTTPS) version 1.1 with its native "streamed" extension. Most VPNs that allow bridging networks over the Internet will do the same. The bridge can even encapsulate multiple protocols: Ethernet, PPP, IPv4 and IPv6 (extending the local LAN or Ethernet segment only), NetBEUI/LanMan, router discovery (within the bridged network), including in raw mode (allowing DHCPv4 or DHCPv6) in the bridged network. HTTPS is used because the encapsulation over HTTPS allows also encryption, and authentication for establishing and securing the bridge, but does not require end-to-end authentication/encryption for clients and servers over the bridged network, and because routers are highly optimized for HTTP and HTTPS.
Note that TCP includes a setup option to negociate optimal MTU sizes, for serial links or pipes this has no real meaning, so it will just use some reasonnable default for the optimal TCP frame, that the recipient can accept in its input buffers, and so that the emitter can also adjust the emission window in multiple of that maximum TCP MTU frame size, used to allow resending broken/lost TCP frames on demand from the recipient, which needs to acknowledge them either one by one selectively, or by groups). TCP is a very simple protocol, but it can be tuned a lot (notably its emission and reception windows needed for reliability and retransmissions); however it tends to be old now, because there are also alternatives to resending lost frames, notably by using forward error correction (the only solution for example with unidirectional broadcasts, or directed unicasts), and TCP offers by itself no way to share a unicast return channel with other concurrent TCP streams, while keeping a specific transmission channel (notably broadcasts). To avoid bottlenecks, the return channel of TCP may be a dummy one (as if we had acknowledging everything on the reception site), but use another bidirectional stream for negociating retransmission on unicast channels (this is used for example in TV broadcasts: most of the encontent may be sent using unidirectional multicast (without needed any ackknowledge, but possibly using forward error correction meaning some extra emission bandwidth), but lost data may be recovered over a standard TCP stream (pair of unidirectionalchannels), for specific requests of retransmission (but using another mechanism than TCP frames or multicast frames for identifying missing data blocks, such as timecodes). If you can interleave multiple TCP streams over a carrier encapsulation channel you can do many things to aoid the roundtrip and brutal variation of the TCP window sizes. Today it is common to use HTTP streams as this carrier, but it is not so good because HTTP itself will use its own TCP encapsultion. Alternatives is to use UDP as a carrier: TCP over UDP is an excellent technic (and UDP often traverses NAT much more easily than TCP that requires negociating and translating port numbers, and there's a limited number of TCP ports over the same IP host; but no limitation if TCP does not need IP and is varried over somethnig else than IP): TCP does not need routing info, it does not negociate it, does not perform by itself any domain name resolution or IP route discovery.
An alternative to TCP is RUDP (reliable UDP) which uses a smarter strategy than basic windows used by TCP (which are known bottlenecks in terms of maximum bandwidth, because windows used by TCP require acknowledgement by he recipient, and there's a significant rountrip time for them). Other alternatives are implemented in VPN protocols which have significantly better strategies to avoid bandwidth bottlenecks, while preserving the reliability and sometimes improving it a lot (e.g. with encryption, and stronger data signatures than the very basic CRC used by TCP data frames which is not even enough for forward error correction).
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.