You’ve probably heard of TCP, and might know it has something to do with sending and receiving information across the Internet. You’ve undoubtedly seen HTTP at the front of URLs nearly every time one shows up in your web browser.
But when it comes to understanding how these two protocols interact, as well as the role they play in the overall data transmission puzzle, things can get confusing. Let’s break down what TCP and HTTP really are, what sets them apart, and how they work together.
What Is TCP?
Data streaming from source to destination gets split up into chunks known as “packets” for more manageable transport. Whenever you send or receive a packet of data, a host of information about that data rides along. This includes information added by the Transmission Control Protocol, or TCP.
TCP’s job is to ensure that all data sent in a stream moves from Point A to Point B in correct order and intact. Protocols like TCP tell the destination computer which application should receive said data. TCP in particular sacrifices raw speed to ensure reliability in the data being transmitted. Note that some forms of data transmission such as video streaming, where perfect accuracy matters far less than speed, are better off using different protocols that optimize for speed over accuracy.
Packet transfer, if left to its own devices, will not be completely reliable. That’s why TCP uses a technique known as positive acknowledgement with retransmission, requiring the receiving end of a transmission to give a response as to what data has been received. Thanks to this, the sender knows what packets to send next, or perhaps resend, to maintain a flawless stream of data. The bytes sent, therefore, can exactly match the bytes received. No data is altered or lost along the way.
If you want to read more about how this checking process works, click here.
What Is HTTP?
While TCP contains information about what data has or has not yet been received, HTTP contains specific instructions on how to read and process this data once it arrives. Before data is sent from one node on the Internet to another, it gets wrapped in information detailing the nature of the request being sent, or the response to said request. This is done using HTTP, or the Hypertext Transfer Protocol.
When you type a URL into your web browser, you are sending an HTTP request to a web server. That server will then respond, again using the formatting of HTTP. (If you’re wondering about HTTPS, which you might’ve noticed in front of most popular sites these days, the “S” stands for “secure”—meaning that those packets are encrypted.)
The two most common examples of HTTP requests are: 1. “POST,” denoting that this contains data to be pushed to the server 2. “GET,” asking that a resource from the server be fetched
So: TCP manages the data stream, and HTTP describes what the data in this stream contains.
TCP vs. HTTP: The Seven-Layer Onion
Ogres are like onions; so are data packets.
HTTP is located at Layer 7 of the Open Systems Interconnection model (OSI model), AKA the innermost eye-watering nugget of the onion. TCP is at L4. You can also think of this as layers of abstraction from the data itself contained within a packet. L1, the physical layer, is the tangible electrical signals (or perhaps radio signals or another physical medium) that the data is transformed into for transmission. L1 is therefore the farthest layer from the inner data.
Why have these distinct layers? Let’s say, for example, that data is incoming from a web server to our computer to load a website. Our computer captures physical electricity, which is in a sense “wrapping” the packet of non-tangible data for transport. As we progress to L4, without TCP the computer wouldn’t know which application to point the packet toward. Here, TCP can tell the computer to direct the packet to our web browser.
Once within an application like Firefox or Chrome, the HTTP instructions are read. The browser learns the nature of the incoming data, and can at last load the contents of the webpage correctly.
And so, the unraveling layers act as an assembly line, working in sequence to take the raw materials in the data packet to a usable state.