[This page should at some point in time be merged with Client/Server desynchronization ]
A network based program generally has 2 sides - server and client. The client, as the name suggests, is the part of the program that is processed locally for each end-user, and the server is one main processing chain that runs regardless of any clients that are connected to it. As mentioned, clients can connect to the server, sending and receiving both requests and information in return. A server, unless configured otherwise, has no limit to how many clients can be connected to it at any given point, but a client can only be connected to one server at a time. The main bottleneck in any network application is the internet bandwidth, in other words, the amount of data over time that can be sent out from the server (also the amount of data clients have to send to the server, albeit a less significant problem). This means that such an application should try to minimize the amount of communication between the client and server, and only send necessary (otherwise unobtainable) data between the 2, such as user input, server-wide events, other clients activities, etc.
Client[]
In Minecraft, the client is your local game running on your machine, and is in charge of all local calculations, such as graphics, audio, and UI (User Interface), as well as some of the server calculations too, because the client runs a local semi-copy of the server, which is there to bring down the amount of bandwidth usage. From this point on, we will refer to this local semi-copy of the server simply as "the client". The client calculates some things similarly to the server, with slight variation. For example, the client does not have access to the world seed, and therefor cannot process any randomness that occurs on the server. The client can also only deal with what it has, so other things that the server handles, like other players' actions, chat, commands, and some other things, exclusive to the server, cannot be processed by the client.
Server[]
There is a distinction regarding the definition of the server in Minecraft, depending on whether the game is local (singleplayer) or remote (multiplayer).
If the game is run locally, then the local version of the server mention in the "Client" section, is still present, but another, full copy of the server is also run locally. This is called an integrated server, as it is integrated inside your client. Because a local game also has 2 copies of the server, one referred to as "the server" (the full version) and the other referred to as "the client" (the semi-copy. This distinction is because the client still only communicates with the semi-copy, and the semi-copy and full copy still communicate with each other through a network handler, though the address is localhost), even this local server could have client/server de-synchronizations.
If, however, the server is remote, the client only has a semi-copy of the server, as described in the "Client" section. A remote server differs from an integrated server in a few things, namely players' restrictions to commands and other things, but also certain unique data structures, such as player lists, whitelists, blacklists, permission lists, etc. Since this server is run on a different machine than your local game ("client"), it uses the routing network, more commonly known as the internet, to transfer data between the server and client, and vice versa. The internet is not perfect, and has a certain amount of varying delay, which makes some things work less fluently than they do on singleplayer. Also, the internet can lose connection on your end, the server's end, or anything in between, causing you to disconnect from a server on occasion.
Communication[]
The server and client are both separate, and each calculates blocks and entities separately. The client is in charge of rendering, player placement, and a few other mechanics. This means that it is possible to render blocks that are not actually there on the server. These are ghost blocks. It is possible to use a ghost block as a anchor for placement of another block, thus allowing for block placement midair. Damage packets sent from the server contain a knockBack direction vector (even if no knockBack is applied, in which case it will be the zero vector), which takes into consideration whatever the server thinks is happening with the player's movement. This causes the client to process the movement the same as the server for 1 gametick, effectively re-synchronizing between the two.
Here is an example of using entities to push the client, and reconnecting the connection between the client and server https://www.youtube.com/watch?v=P7FM1JRbNWo
Here is another example of verticle momentum using ghost slime blocks. There is also an explaination included. https://www.youtube.com/watch?v=sFAlX7TKz1s
Packets[]
As mentioned, the client and server, regardless of whether they are remote from each other or not, need to communicate with each other. The standard method for client-server communication across the internet (and also locally, for the purposes of some applications, like Minecraft) is called "packets". A packet is a small, well, packet, of information, or data, that needs to be transferred one way between the two sides. Once a packet is generated with all the data it should contain, it is sent to a network handler, which then wraps it with headers, containing important generic information, like the origin's IP address, the destination's IP address, the time of generation, etc. Along the way, it is wrapped by other headers generated by each machine ("router") it went through on it's way, so that it could more easily find it's way back, if a response is necessary. On the other side, it is received and unwrapped from all it's headers, so that only the raw data inside is exported from that side's network handler, and sent to the packet processor. Then, the contents of the packet are read, and actions are taken appropriately, including responses returned, if necessary.
Packets are generally very small bundles of information, usually containing no more than several hundred bytes. Their information is compressed and minimized, and then extrapolated on the other side into real data. Because of this, the 2 sides must have a contract between them of how exactly the data should look. You can read more about packets online. What we can learn about Minecraft's behavior from it's usage of packets, is that (especially felt when the internet is slow or disconnected) often times, data transferred between the client and server is lost, delayed differently, or altered, because of the flaws of the internet, applying differently to each little package of information, causing a certain fluctuation in the data stream transferred between client and server (and vice versa).