Does TCP/IP work top-down or bottom-up?

Question

Programming

We all know what the TCP/IP stack is.
If you are reading this, then you know how it works in detail.
Application layer (http)
Transport (tcp/udp)
Network (ip)
but the rest is not so important.
Let's say that there is some application that works over the network.
Need to send Data from point A to point B, and then from point B to point A.
Describe this process using the tcp/ip stack from beginning to end. I use my three-layer model.
At the highest level of abstraction, it should be something like this:
We're at point A, we're flying ... HTTP => TCP => IP now we're at point B, it's time to go back HTTP => TCP => IP here we are at point A.
Next question
IP is responsible ONLY for "breaking" data into packets, and adding meta-data, or is it also somehow involved in transportation? If it is involved, then I don't understand at all, if not, then the picture emerges.

Answer 1

I recommend Olifer to read. Each level is responsible for its own. In general, there are seven of them in the standard ISO / OSI model, and this model is usually used when talking about levels. Network - this is level 3, it does not participate in any transportation, what it does specifically - read Oliferov and RFC. Below the network - channel, it is responsible for Ethernet frames (if the transmission is over Ethernet), even lower - physical - and now it is just responsible for transportation. After the transport level comes the session level - it is practically not used anywhere now, then the presentation level - SSL works here and then the application level.

Answer 2

This whole model is nothing more than a convention, it must be considered as a hierarchy of data structures, and not at all immutable and hidden from each other levels. In some cases, even the application layer can be taken into account in the direction of sending a packet, and HTTP can be parsed directly from Ethernet frames. Nothing prevents HTTP from containing Ethernet frames. NAT, which determines the direction of sending by the TCP and UDP port number, has already become commonplace. Application protocols containing IP addresses and ports should not be in OSI at all, as it does not allow abstraction, but there are plenty of them. And it turned out sideways with the advent of IPv6, and they are generally incompatible with other network layer protocols and turned a blind eye to this. And all this mess is now called the network stack.
IP certainly contains a fragmentation mechanism, but due to poor design it is rarely used and not for TCP. TCP was originally designed to fragment endless data streams with delivery verification, so it breaks into the network layer to know the MTU, and even break the connection (no route, unreachable) after receiving some ICMP packets. To the remote host, TCP also tells its MTU.

Answer 3

ip only specifies which host this packet belongs to, no more!

Answer 4

1) the application layer (HTTP) uses TCP as a service (namely, some API provided by the OS, such as Berkeley sockets) and expresses a desire to send some amount of data to point B; in theory, the amount of data can be anything, because the task of TCP is to break the data into pieces and stick your header to them. The resulting chunks with headers are called TCP segments; these headers contain everything that is necessary to provide all the guarantees that TCP gives, namely: a) the packet number to receive packets in the order they were sent and the possibility of assembling the sent data; b) the integrity of the packages and the absence of errors in them; c) port numbers of the recipient and the sender (so that several programs on the same machine can exchange data); d) checkboxes for maintaining a TCP connection. The whole point of TCP is to provide you, i.e. application layer, some kind of reliable virtual "wire" with which you kind of connected one program on one machine to another program on another machine. In terms of switching types, TCP over IP is circuit switching over packet switching.
2) After assembling each segment, TCP uses the IP layer as a service, and gives it segments to pack into packets. The IP level is needed to provide the ability to drop (ie, route) any packet from the current node to any other on the network. IP does not provide any guarantees about the order in which packets arrive at the host, and even that they will arrive at all (IPv6 also does not check the integrity of the packet), however, with its help, network equipment is able to choose different (!) Ways to deliver packets to the recipient and implement this delivery. In the header of an IP packet, as in a letter, the sender node and the recipient node are indicated.
After the package is assembled, it is sent to the link layer for delivery over a specific physical medium.
Now imagine if these levels (TCP / IP) did not exist. The simplest thing that comes to mind that works according to this scheme is data transfer via a COM port between two machines. In such a scheme, you would probably receive data in the order they were sent, and possibly even have error control, BUT:
a) only one application could send / receive data, because. no virtual connections (no multiplexing);
b) machines must be physically connected to transfer data. Well, or plant an aunt who would poke wires, as in the first telephone exchanges with manual switching of channels.
IP saves you from point b), TCP - from point a) and those additional. problems that IP adds with its presence.