How can you explain in simple terms the difference between TCP/UDP protocols and HTTP, FTP, SMTP and other protocols?

Let's first assume that there is no TCP, or even no IP layer, and there is only the data link layer corresponding to MAC. How far can protocols such as HTTP run!

Is it possible to directly encapsulate HTTP in Ethernet Frame?

Of course you can. In the same Layer 2 broadcast domain, the other party is identified by MAC address, and then HTTP data is sent and received through the network card interface function.

[[254478]]

The second question: How to ensure that the data reaches the other party without any loss?

Should the network card be used to ensure reliable data transmission? The network card only interprets the Ethernet frame header, and none of the 14-byte fields in the Ethernet header can perform the task of reliable transmission. Does HTTP have to implement a reliable data transmission mechanism on its own? For example, when sending a 1000-byte data segment, it has to wait for the other party to confirm receipt before sending it again. This can ensure reliable data transmission.

Similarly, FTP, STMP, POP3, and BGP all need to ensure reliable data transmission. Do they also have to implement these reliable mechanisms themselves?

A must!

In other words, as long as there is an application, reliable transmission must be implemented by the application protocol! Isn't it stupid??? The reliable transmission mechanism of all application protocols is the same, and the code should be similar. If we encapsulate these reused codes, that is, the interface function API, let it realize reliable data transmission, and use an identifier to indicate which application protocol it is, is it feasible?

Of course it is possible, isn't that how courier companies operate?

This is the highly abstracted traffic dispatcher from the core of the great TCP/IP protocol: TCP!

TCP

It encapsulates the reliable transmission mechanism code into an interface function API, namely socket, and uses TCP Port to identify the application protocol of its service. The application protocol only needs to interpret its own protocol and protocol data to complete the end-to-end conversation.

Second question: With Ethernet + TCP + application protocol, how far can this packet go?

That's the size of a broadcast domain, right? No matter how much you show off, you can't escape the circle of the broadcast domain!

The IP layer is used to solve this problem. The IP layer makes the Internet possible. As the advertising slogan goes: impossible is nothing! You should know that IP is the abbreviation of Internet Protocol.

You may ask, I want the IP layer, not the TCP layer, can I just encapsulate the data in the IP layer?

That's great! Not only is it possible, but many protocols do this, including OSPF, EIGRP, GRE, ESP, AH, etc. If they want to ensure reliable transmission, they can implement it themselves with code, which of course is possible.

The problem is that IP uses only one byte to represent the protocol number. In theory, it can only recognize 255 upper-layer protocols. Resources are very tight, and they are all occupied by well-known big-name protocols, such as TCP, ICMP, IGMP, including the ones mentioned above. Where will you get a chance to use them?

In order to solve this resource shortage problem, another little invention was invented, a little puppet that is only used to identify the application protocol: UDP!

UDP

In fact, UDP does not do anything else except providing a port to distinguish application protocols. However, the port number occupies 2 bytes, and theoretically can distinguish 65535 application protocols. This alone is enough to make its mission complete. It is precisely because it is a completely stateless protocol unlike TCP that it is favored by some applications. Because UDP is stateless, IP is also stateless, and all session states are controlled by the application protocol, this is also an option.

In addition, UDP-based applications can achieve reliable transmission, such as TFTP, which can achieve reliable transmission by itself; you can also give the data to UDP and let it send it out. There is no need to confirm the data sent out. Students will ask: What kind of application is this? Voice traffic, if it is lost, it is lost. If the other party can't hear it, just say it again.

Overview

TCP provides a reliable transmission mechanism and is stateful.

UDP provides more house numbers to identify upper-layer protocols and is stateless.