The TCP protocol is implemented in the operating system and provides a higher level of interface than IP. When you program TCP, you do not deal with datagrams. Instead, you have a channel of byte streams where you can put bytes to be delivered to the other computer, and you can read bytes from the channel that were sent by the other computer, exactly in the order as they were sent. This is a kind of connection between two computers and, what's more, between two programs.
When a packet is lost on the network, or when it is sent twice, or when it is delivered sooner than a later package, it is handled by the TCP software layer implemented by the operating system. This layer is also popularly called the TCP stack.
Since the TCP is a connected protocol, there is a need for something that tells the TCP stack which stream a datagram belongs to when it arrives. The stream is identified by two ports. A port is a 16-bit integer. One identifies the program that initiates the connection, called the source port. The other one identifies the target program: the destination port. These are contained in each and every TCP packet delivered. When a machine runs a Secure Shell (SSH) server and a web server, they use different ports, usually port 22 and 80. When a package comes that contains the destination port number 22 in the TCP header, the TCP stack knows that the data in the packet belongs to the stream handled by the SSH server. Likewise, if the destination port is 80, then the data goes to the web server.
When we program a server, we usually have to define the port number; otherwise, there is no way the clients will find the server program. Web servers are usually listen on port 80, and clients try to connect to that port. The client port is usually not important and not specified; it is allocated by the TCP stack automatically.
To connect from a client code to a server is easy: only a few lines of code. Sometimes, it is only one line of code. However, under the hood, there is a lot of work that the TCP stack does that we should care about—it takes time to build up a TCP connection.
To have a connection, the TCP stack has to send a datagram to the destination to know that it exists. If there is no server listening on the port, sending the data over the network has no result, except for wasting the network bandwidth. For this reason, the client first sends an empty data packet called SYN. When the other side receives it, it sends back a similar package called SYN-ACK. Finally, the client sends a package called ACK. If the packets go through the Atlantic, this is approximately 45ms for each package, which is equivalent to 45 million seconds in bureaucrat time. This is almost one and a half years. We need three of those to set up the connection, and there is more.
When a TCP connection starts, the client does not start to send the data without control. It sends some data packets and then it waits for the server to acknowledge their receipt. It would not only be useless, but also network wasting, to send data that the server is not prepared to accept and has to throw away. The TCP is designed to optimize the network usage. Therefore, the client sends some data, and then it waits for the acknowledgement. The TCP stack automatically manages this. If the acknowledgement arrives, it sends more packets, and if a carefully designed optimization algorithm, implemented in the TCP stack, believes that it is good to send more, it will send a bit more data than in the first step. If there are negative acknowledgements telling the client that the server could not accept some of the data and had to throw it away, then the client will lower the number of packets it sends without acknowledgement. But first it starts slow and cautious. This is called TCP slow start and we have to be aware of it. Although it is a low level networking feature it has consequences that we have to consider in our Java code: we use database connection pools instead of creating a new connection to the database each time there is a need for some data; we try to manage to have as few connections to web servers as possible using techniques such as keep-alive, SPDY protocol, or http/2.0 (also replacing SPDY).
For a start, it is enough that TCP is connection-oriented where you build up a connection to a server, send and receive bytes, and finally close the connection. When you have a network performance problem, you have to look at the issues I listed.