Is it true that TCP is short for TCP/IP and they mean the same thing?
Is it possible for TCP to be built on top of another protocol besides IP?
-
33Why not? I might have seen TCP over morse code once.– soandosCommented Jul 16, 2012 at 20:24
-
2An example would be an ICMP tunnel, which uses TCP over ICMP. But it is true that it is not usual building TCP on top of anything not IP. Usually is the network access layer the one using a wider range of protocols and channels (such as bongo drums).– Mister SmithCommented Jul 17, 2012 at 8:40
-
1@TomWijsman Tried an failed? From what I understand, any trouble they had had to do with addressing issues and interoperability rather than any trouble getting TCP to work.– tylerlCommented Jul 18, 2012 at 2:48
-
2@harper With regular Morse code, 200 characters/minute is certainly not unheard of for skilled operators, and 100 c/min (20 wpm) is definitely achievable by most people with enough practice. Of course, at those speeds, you don't really hear each individual character, but rather much the sound of words. (It's said that the hallmark of a skilled operator is that they remember the conversation, but not the words used.) I would imagine however that 100 c/min characters spaced to an overall speed of 50-60 c/min would be doable with negligible character error rates.– userCommented Jul 18, 2012 at 7:34
-
2@harper It depends on your required level of accuracy. For largely chit-chatting (rag-chewing, in amateur radio speak), getting a word here and there wrong is not really a problem, because the context matters more than the exact words used. For telegram traffic, emergency/distress communications and so on, particularly if the text is ciphered, every word and indeed every character must be (not just received but also) copied correctly (and legibly). Note that I said that 200 c/min is "not unheard of"; not commonplace. 100 c/min however is fairly common on the amateur radio bands.– userCommented Jul 18, 2012 at 8:02
|
Show 12 more comments
14 Answers
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.
-
4Technically accurate (as far as I can tell), thorough, backed by references, clear, and light-hearted. I'd give this a handful of upvotes it I could. Commented Oct 22, 2015 at 18:35
-
2
-
Hm. I thought the Avian Carriers in RFC 1149 sat under IP, replacing the data link layer (Ethernet vel sim). Commented May 17, 2021 at 22:09
-
It's a common misconception that RFC1149 solely specifies the link layer for avian carriers, a misconception reinforced by the title and content. However, later analysis has concluded that RFC1149 specifies both the avian carrier layer and the datagram layer that it encapsulates. Commented May 19, 2021 at 11:33
-
Closer inspection of RFC 1149 reveals evidence of earlier, possibly covert work on avian overlay networks using a centralized hub topology. It is conjectured that the hubs, termed lofts by those versed in the art, used cut-through forwarding to bypass the latency of duct-tape decapsulation, optical scanning, re-printing and re-encapsulation. Further evidence of covert work on avian routers can be found in two leaked mentions in RFC 2549 Commented May 19, 2021 at 12:08
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.
answered Jul 16, 2012 at 20:31
-
102IP itself has been implemented over many network technologies, even carrier pigeons. The birds were actually used to demonstrate delivery of ICMP Ping packets, with a 55% packet loss (apparently due to operator error) and latencies ranging from one to two hours. It would be possible to run TCP on top of that, but the connection setup would require a lot of birds....– RBerteigCommented Jul 17, 2012 at 1:36
-
22About RBerteig's comment; consider a carrier pigeon carrying a mini-SDHC card. There's the difference between latency and throughput. :-)– userCommented Jul 17, 2012 at 6:33
-
17@MichaelKjörling This would not interoperate with RFC 1149: “The IP datagram is printed, on a small scroll of paper”.– kmkaplanCommented Jul 17, 2012 at 9:43
-
4@kmkaplan Unless the datagram was printed on the label of the SDHC card. It's like the cliché from several films - "oh, it's actually ON the harddrive!" Commented Jul 17, 2012 at 11:12
-
41Would have to have some seriously large holes in the firewall to allow avian carriers through. Commented Jul 17, 2012 at 15:01
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.
Application Layer
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.
Transport Layer
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†
Internetwork Layer
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
(my emphasis)
answered Jul 16, 2012 at 21:12
-
1Brought me all the way back to 1996 and the OSI Model en.wikipedia.org/wiki/OSI_model– RudiCommented Jul 17, 2012 at 15:06
-
There are more than 2 transport layer protocols: en.wikipedia.org/wiki/Transport_layer#Protocols Commented Jul 19, 2012 at 11:53
-
@StuartBlackler: Interesting point, thanks. Are there any (other than TCP & UDP) that don't fall into what I called the "vanishingly small specialist use" category and which are used over IP? If I measured IP traffic at an Internet Exchange Point, what proportion of the transport layer protocols would be anything other than TCP or UDP? Commented Jul 19, 2012 at 15:23
-
Take DCCP for example, it's still a new protocol but I imagine over the next few years you will see more applications use the protocol. Reason I don't think it's mainstream yet is because I don't believe there is support for it in Windows. Think of it as UDP with congestion control. Can be very handy for a lot of applications such as Skype and gaming :) Have a look at it. To answer your question, it's probably a very small amount at the moment Commented Jul 20, 2012 at 15:37
-
@Rudi err, you should realize that is not the OSI reference model, and if you do realize that, then don't mislead people into thinking that it is. It's the TCP/IP model / architecture... Sometimes the TCP/IP architecture is described with the terminology of OSI, the OSI reference model. But the 4 layers shown and with those names, is very much TCP/IP not OSI. No issue with red's post but your comment is misleading at best.– barlopCommented Aug 3, 2015 at 1:22
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.
-
1Correct - the first version of TCP included the functionality of IP. Maybe another reason why people say "TCP/IP" is that the vast majority of the time when you're sending data over IP, you want to guarantee that all of it gets delivered and in the right order, so you use TCP. For instance, all HTTP and FTP traffic uses TCP. One category of exceptions is real-time data; Skype, for instance, uses UDP, because you'd rather get the latest packet in a conversation than stop everything to get one that you missed. Commented Jul 21, 2012 at 15:42
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.
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.
answered Jul 17, 2012 at 19:16
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.
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.
However, is it not possible for TCP to be built on top of another protocol besides IP?
Yes, you could indeed create an alternate system to TCP that uses IP. Take a look at the Internet Protocol Suite for some details.
answered Jul 16, 2012 at 20:36
-
13It's a little misleading to say that IP provides for "connecting" two points together. IP provides a way to send discrete individual packets from one machine to another; each packet is independent of all others. TCP provides the illusion of a continuous connection, which is really a sequence of packets sent via IP.– WyzardCommented Jul 17, 2012 at 0:50
-
4IP isn't related to hardware or physical signaling either. That's handled by lower-level technologies, e.g. Ethernet.– WyzardCommented Jul 17, 2012 at 0:58
-
9There is a lot wrong with this answer, and it misses the question entirely. First, Ethernet is just one link layer protocol that has been used to carry IP. There are plenty of others, and IP does not know or care about any of them. IP has nothing to do with the hardware; it is the routing layer between networks, above the hardware used to connect them. The point of the question was whether you can use TCP on something other than IP, not whether you can use something other than TCP that uses IP ( see UDP for an example of that ).– psusiCommented Jul 17, 2012 at 4:28
-
3@synetech, the question was not "can something else be used on IP". It was "can TCP be used on something else", i.e. without IP.– WyzardCommented Jul 17, 2012 at 22:40
-
2
> the fact that !TCP can go over IP does not necessarily mean TCP can go over !IP Huh?psusi is trying to be clever by using "!" as the "not operator". His comment should be read as: "the fact that something that is not TCP can go over IP does not necessarily mean TCP can go over something that is not IP". It is made in referrence to the last sentence of your answer, which showed the existence of "Alternate systems to TCP". However showing that alternatives to TCP exists does not necessarily imply nor hint that alternatives to IP exists.– Lie RyanCommented Jul 21, 2012 at 16:32
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.
answered Jul 17, 2012 at 0:05
-
1
-
1What about IPv6? It's just IP. There interface of sending and receiving a packet remains the same. So, TCP can use the same function. OS can just replace the function pointer from IPv4 and IPv6 and it would still work. I am not sure what you are saying here ? Commented Jul 18, 2012 at 3:59
-
3IPv6 and IPv4 are similar, with similar interfaces for upper layers, but certainly not the same protocol and not strictly functionally equivalent either. Commented Jul 18, 2012 at 4:10
-
1You might as well pretend that UDP is the same protocol as IP, because they offer extremely similar interfaces to upper layers: set a local and a remote endpoint addresses, send and receive packets... Commented Jul 18, 2012 at 4:16
-
Yes but TCP over IPv6 is just another proof that IPv4 is not a required protocol for implementing TCP. You can as well implement TCP over a non-routing protocol, it just requires a lower layer that includes an input stream and an output stream; the lower layer does not even need to use datagrams: TCP over a bidirectional serial link or over a software I/O pipe does work as well. There are in fact many posibilities, widely used on the Internet, including TCP over HTTP or HTTPS and various VPN protocols.– verdy_pCommented Jan 12 at 5:34
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.
-
Yeah, but that's UDP over IP; I see what you did there... Commented Jul 18, 2012 at 2:53
-
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.
-
1You are probably thinking about when IPX was tunnelled over TCP/IP. Which unsurprisingly didn't last long. Commented Jul 17, 2012 at 17:25
-
1
-
1And as well, there was TCP over TokenRing, TCP over X25, even if they have fallend out of use; TCP over parallel ports or serial links are still used. Now there's also TCP over USB, TCP over Bluetooth, TCP over HDMI or DisplayPort, TCP over management bus channels used by some firmwares, and even TCP over SCSI! TCP is very versatile!– verdy_pCommented Aug 8, 2022 at 20:04
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.
