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?

  • 417
  • 4
  • 14
  • 26,733
  • 82
  • 197
  • 273
  • 33
    Why not? I might have seen TCP over morse code once. – soandos Jul 16 '12 at 20:24
  • 2
    An 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 Smith Jul 17 '12 at 08:40
  • http://en.wikipedia.org/wiki/AppleTalk tried and failed, from what I can tell; so, theoretically (as shown by the answers) probably a yes but I guess in practice that it's pretty hard to accomplish... – Tamara Wijsman Jul 17 '12 at 14:33
  • 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. – tylerl Jul 18 '12 at 02:48
  • @tylerl: Requiring various re-implementations as to eventually drop themselves out of the game; what hasn't failed is perhaps IPX which is pretty close to what IP is, any further and you indeed get such issues which make things compatible. I would call it big trouble, and thus hard to accomplish... – Tamara Wijsman Jul 18 '12 at 02:52
  • There's IP over Avian.. https://en.wikipedia.org/wiki/IP_over_Avian_Carriers – Wayne Werner Jul 18 '12 at 05:05
  • @soandos: How many chars per second can you hear w/o error? – harper Jul 18 '12 at 05:21
  • @harper, all depends on the speed :) – soandos Jul 18 '12 at 05:22
  • @soandos Sorry, I meant chars per minute. Yes I asked for your listen speed. ;-) – harper Jul 18 '12 at 05:24
  • 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. – user Jul 18 '12 at 07:34
  • @MichaelKjörling 200c/min is a tough speed. The examen speed for onboard ship radio operators was 120c/min, although this was taken with ciphered text. clear text was more difficult since you may "guess the next word" what is errornous. – harper Jul 18 '12 at 07:49
  • 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. – user Jul 18 '12 at 08:02
  • I would think the only restriction would be that the medium be packet switched – 8bitwide Jul 18 '12 at 22:59
  • OT: Maybe it would be better to migrate to Serverfault ? – ziu Jul 19 '12 at 10:22
  • @ziu, I often can't see the difference between serverfault and superuser. The consensus seems to be *"troubleshooting computers at your workplace"* vs *"troubleshooting computers at home"* http://meta.serverfault.com/a/2604/87017 http://meta.stackexchange.com/a/28238/159916. Many questions are suitable for both sites of course. Well if you'd ask me, I think they got to be merged back into 1 site... but well I digress. – Pacerier Jul 19 '12 at 17:24
  • TCP over IP explicitly include the IPv4 or IPv6 addresses in the TCP checksum calculation. How Is the checksum defined for TCP over morse code? – netvope Apr 02 '15 at 02:14
  • @netvope, That has nothing to do with IP does it? TCP's checksum is for its contents, regardless of what the contents is. – Pacerier Apr 06 '15 at 05:57

14 Answers14


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.

  • 40,002
  • 15
  • 104
  • 126
  • 73,030
  • 15
  • 129
  • 214
  • 102
    IP itself has been implemented over many network technologies, even [carrier pigeons](http://en.wikipedia.org/wiki/IP_over_Avian_Carriers). 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.... – RBerteig Jul 17 '12 at 01:36
  • 22
    About RBerteig's comment; consider a carrier pigeon carrying a mini-SDHC card. There's the difference between latency and throughput. :-) – user Jul 17 '12 at 06:33
  • 17
    @MichaelKjörling This would not interoperate with RFC 1149: “The IP datagram is printed, on a small scroll of paper”. – kmkaplan Jul 17 '12 at 09: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!" – Jon Hanna Jul 17 '12 at 11:12
  • 3
    @all Creative thinking outside all boxes :-) – nalply Jul 17 '12 at 11:33
  • 1
    @kmkaplan I wasn't aware that RFC 1149 interoperability was a requirement. – user Jul 17 '12 at 12:30
  • 3
    @RBerteig On the other hand, FTP over avian carriers _might_ be practical. – kinokijuf Jul 17 '12 at 14:33
  • 41
    Would have to have some seriously large holes in the firewall to allow avian carriers through. – squillman Jul 17 '12 at 15:01
  • 3
    On bandwidth vs. latency: Back in the day we used to observe that it was really hard to beat the bandwidth supplied by a truck load of 9-track tape reels. Today, a single envelope with an SDHC card eclipses that by many orders of magnitude. But in both cases, the latency is pretty high. On the other hand, stunts have been done showing that a courier (or even a bird) and a card easily beats most network connections for large file transfers. – RBerteig Jul 18 '12 at 00:24
  • 2
    A company or two made TCP over IPX drivers way back when, before IPX completely died. (Or was it SPX over IP?) IPX was basically identical to IP aside from the particulars of the header bits, so there was no reason it couldn't work. You could easily define a PCP (postcard protocol), utilizing USPS addresses and segmenting based on whatever fits on the back, and run TCP over that. – SilverbackNet Jul 18 '12 at 01:04
  • @RBerteig It's far from fact that TCP over pigeon was implemented.. The RFC was an april fools joke, and the link wikipedia gives for its "implementation" is just a short blog post on some site with no pictures about implementing the RFC. Very likely a joke, because if somebody had implemented something as bizarre as IP over pigeons even on a small scale, and wanted to write about it, they'd have at least taken pictures of the spectacle or written in more detail. And no names are given there for who did it. It's titled with the words "informal report". I wouldn't trust it. – barlop Aug 03 '15 at 01:19
  • 1
    @barlop [Here's at least one user group](http://www.blug.linux.no/rfc1149/) that claims to have done the stunt, with logs, detailed accounts from multiple parties, and photos of the actual birds involved. Of course it was a stunt, and not in the least bit practical. But it is the kind of stunt that appeals to the same kind of people that would write the IFC as a joke so I always found it plausible that someone could have gone and done it. – RBerteig Aug 03 '15 at 22:48
  • @RBerteig +1 good find, and it's a webpage from the same website as the wikipedia reference so the wikipedia reference was legit. – barlop Aug 03 '15 at 23:25

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.

IP layer diagram From bootdiscs.net

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.Wirshark Protocol Hierarchy Statistics

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)

  • 81,981
  • 20
  • 135
  • 205
  • 1
    Brought me all the way back to 1996 and the OSI Model http://en.wikipedia.org/wiki/OSI_model – Rudi Jul 17 '12 at 15:06
  • There are more than 2 transport layer protocols: http://en.wikipedia.org/wiki/Transport_layer#Protocols – Stuart Blackler Jul 19 '12 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](http://en.wikipedia.org/wiki/Internet_exchange_point), what proportion of the transport layer protocols would be anything other than TCP or UDP? – RedGrittyBrick Jul 19 '12 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 – Stuart Blackler Jul 20 '12 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. – barlop Aug 03 '15 at 01: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.

  • 2,155
  • 1
  • 15
  • 21
  • 1
    Correct - 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. – Nathan Long Jul 21 '12 at 15:42

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:

  1. 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).
  2. 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.

Bob Briscoe
  • 441
  • 4
  • 5
  • 4
    Technically 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. – Scott - Слава Україні Oct 22 '15 at 18:35
  • 2
    The avian example is lucid and hilarious! – john Nov 11 '18 at 00:49
  • Hm. I thought the Avian Carriers in RFC 1149 sat under IP, replacing the data link layer (Ethernet vel sim). – Mark Reed May 17 '21 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. – Bob Briscoe May 19 '21 at 11:33
  • Closer inspection of [RFC 1149](https://datatracker.ietf.org/doc/html/rfc1149) 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](https://datatracker.ietf.org/doc/html/rfc2549) – Bob Briscoe May 19 '21 at 12:08

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.

Mark Reed
  • 556
  • 2
  • 11

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.

Tony Stewart EE75
  • 1,759
  • 11
  • 14

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.

  • 4,447
  • 23
  • 29
  • 68,243
  • 36
  • 223
  • 356
  • 13
    It'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. – Wyzard Jul 17 '12 at 00:50
  • 4
    IP isn't related to hardware or physical signaling either. That's handled by lower-level technologies, e.g. Ethernet. – Wyzard Jul 17 '12 at 00:58
  • 9
    There 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 ). – psusi Jul 17 '12 at 04:28
  • @Wyzard, you may want to have your vision checked (or just avoid responding to things that you only skimmed). – Synetech Jul 17 '12 at 17:33
  • @psusi, you do understand that this is a general overview right? I have linked to technical explanations should the OP want detailed information, but the question as asked simply wants a clarification about TCP and IP being the same or not, which I have clearly explained is not the case. – Synetech Jul 17 '12 at 17:34
  • 1
    @Synetech, that is not what the question says at all. The question was whether TCP can be used over another protocol besides IP. – psusi Jul 17 '12 at 17:44
  • @psusi, re-read the question. It has two parts: are they the same and can something else be used on IP. I addressed *both* parts clearly without giving extraneous technical details (though I did provide links for tech specs if the OP wants to read through them). – Synetech Jul 17 '12 at 17:52
  • 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. – Wyzard Jul 17 '12 at 22:40
  • Okay, so *half* was backward. I still explained clearly about them not being the same and showed the relationship and that other things can run on IP, which at the very least implies that TCP should be able to run on an alternative to IP. – Synetech Jul 18 '12 at 00:15
  • 1
    Bitter, bitter, bitter. Feel free to write your own answer if you know better. – Synetech Jul 18 '12 at 02:25
  • 1
    The question only has one part. The first sentence is simply background, which you mistakenly combined with the second sentence to reverse its meaning, resulting in your answer being backwards. Pointing out the mistake in the background as you did is fine, but the question is still whether TCP can go over !IP, and the fact that !TCP can go over IP does not necessarily mean TCP can go over !IP. The purpose of comments is not to pick on you, but so you can correct the answer. – psusi Jul 18 '12 at 17:36
  • *> The question only has one part. The first sentence is simply background... Pointing out the mistake in the background as you did is fine, but the question is still whether TCP can go over !IP[sic]*   You may want to familiarize yourself with the site (and the [XP Problem](http://meta.stackexchange.com/questions/66377/) a little. There are hundreds of examples of people answering the the underlying problem instead of the letter of the question as well as people answering part of a question and letting someone else answer another part. – Synetech Jul 19 '12 at 16:53
  • *> the fact that !TCP can go over IP does not necessarily mean TCP can go over !IP*   Huh?     *> The purpose of comments is not to pick on you, but so you can correct the answer.*   That's what the Edit button and wiki-nature of the site are for. But then I guess some people are too lazy to simply type even a couple of sentences when clicking an arrow is easier. – Synetech Jul 19 '12 at 16:55
  • 1
    `TCP on the other hand is more like a messaging system or traffic control officer which directs messages/cars to the correct point.` <- that is actually IP, the routers (traffic control officer) works on the IP level, not TCP. TCP is more like the logistic company that plans the number of trucks to send and their intervals to maintain a constant and reliable delivery of goods. – Lie Ryan Jul 21 '12 at 16:03
  • 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 Ryan Jul 21 '12 at 16:32
  • I'm not sure that what TCP/IP stands for has the word "over" in it.While it's true that TCP is over IP,Did u just put that in to make TCP/IP sound less confusing for people.As far as I can tell TCP/IP just stands4what TCP stands for followed by what IP stands for(the slash being unspoken,perhaps as it's not an 'or'..n nobody really says the whole thing spoken anyway,they just say tee see pee eye pee,as you know).If u wanted a word in there you could say 'with' or as you did- 'over'.But I don't think1can say that it *stands for* TCP "over" IP.Thats perhaps just a word u added for clarification? – barlop Nov 17 '14 at 13:08

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.

  • 629
  • 2
  • 11
  • 29
  • 1
    What about IPv6? – curiousguy Jul 18 '12 at 01:40
  • 1
    What 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 ? – SurenNihalani Jul 18 '12 at 03:59
  • 3
    IPv6 and IPv4 are *similar*, with *similar interfaces* for upper layers, but certainly **not the same protocol** and not strictly functionally equivalent either. – curiousguy Jul 18 '12 at 04:10
  • 1
    **You 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... – curiousguy Jul 18 '12 at 04:16

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:

Almost TCP over UDP (atou)

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.

  • 405
  • 2
  • 8

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

  • 178
  • 5

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)

  • 31
  • 4

I think it's possible to run TCP over IPX transport, if you want to go retro.

  • 308
  • 1
  • 8
  • 1
    You are probably thinking about when IPX was tunnelled over TCP/IP. Which unsurprisingly didn't last long. – andygavin Jul 17 '12 at 17:25
  • 1
    http://tools.ietf.org/html/rfc1791 – GDR Jul 18 '12 at 16:04
  • 1
    And 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_p Aug 08 '22 at 20:04

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).

  • 357
  • 2
  • 4

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.

  • 21
  • 1