What is socket?

To write a network program, you must use socket. This is what programmers know. In addition, during the interview, we will also ask if the other party will be able to program the socket? In general, many people will say that socket programming is basically listen, accept, send, write and other basic operations. Yes, just like common file operations, as long as they have been written.

 

For network programming, we must also call it TCP/IP. It seems that other network protocols no longer exist. For TCP/IP, we also know TCP and UDP. The former ensures data correctness and reliability, while the latter allows data loss. Finally, we also know that we must know the IP address and port number of the other party before establishing a connection. In addition, ordinary programmers will not know too much, and many times this knowledge is enough. At most, when writing a service program, multiple threads are used to process concurrent access.

 

We also know the following facts:

1. A specified port number cannot be shared by multiple programs. For example, if IIS occupies port 80, Apache cannot use port 80.

2. Many firewalls only allow data packets on specific ports to pass through.

3. After a service program accesses a connection request on a port of listen, a new socket is generated to process the request.

 

As a result, a problem that puzzled me for a long time emerged. If a socket is created and bound to port 80, does it occupy port 80? If this is the case, after the accept request, what port is used for the generated new socket (I always thought the system would assign it an idle port number by default )? If it is an idle port, it must not be port 80, so the destination port of the TCP packet in the future will not be port 80-the firewall will definitely organize it to pass! In fact, we can see that the firewall does not block such a connection, and this is the most common connection request and processing method. Why is the firewall not blocking such a connection? How does it determine that the connection is generated because of port connet80? Is there any special mark in the TCP packet? Or what does the firewall remember?

 

Later, I carefully studied the principles of the TCP/IP protocol stack and gained a deeper understanding of many concepts. For example, TCP and UDP belong to the same transport layer and are jointly deployed on the IP layer (Network Layer. The IP layer is mainly responsible for transmitting data packets between nodes (end to end). The node here is a network device, such as a computer. Because the IP layer is only responsible for sending data to nodes, but cannot distinguish the preceding applications, TCP and UDP protocols are added with port information, the port identifies an application on a node. In addition to adding port information, the UPD protocol basically does not process the IP layer data. The TCP protocol also adds more complex transmission control, such as sliding data transmission windows and receiving confirmation and re-transmission mechanisms to achieve reliable data transmission. No matter what a stable TCP data stream is seen at the application layer, all IP data packets are transmitted below, and data is reorganized by the TCP protocol.

 

Therefore, I have reason to suspect that the firewall does not have enough information to determine more information about TCP packets, except for IP addresses and port numbers. In addition, we can also see that the so-called port is used to distinguish different applications, so that it can be correctly forwarded when different IP packets arrive.

 

TCP/IP is just a protocol stack. Like the operating mechanism of the operating system, it must be implemented in detail and provide external operation interfaces. Just as the operating system provides standard programming interfaces, such as Win32 programming interfaces, TCP/IP must also provide programming interfaces externally. This is the socket programming interface!

 

In the socket programming interface, the designer puts forward a very important concept, that is, socket. This socket is very similar to the file handle. In fact, in the BSD system, it is stored in the same process handle table as the file handle. This socket is actually a serial number, indicating its position in the handle table. We have seen many of them, such as file handles and window handles. These handles actually represent some specific objects in the system. They are used to pass in as parameters in various functions to operate on specific objects. This is actually a problem in C language, in C ++, this handle is actually the this pointer, but actually the object pointer.

 

Now we know that socket and TCP/IP are not necessarily related. The socket programming interface is designed to adapt to other network protocols. Therefore, the emergence of socket is only more convenient to use the TCP/IP protocol stack, which abstracts TCP/IP and forms several basic function interfaces. For example, create, listen, accept, connect, read, and write.

 

Now we understand that if a program creates a socket and listens to port 80, it declares its possession of port 80 to the TCP/IP protocol stack. In the future, all TCP data packets destined for port 80 will be forwarded to this program (the program here, because the socket programming interface is used, is first processed by the Socket Layer ). The so-called accept function abstracts the TCP connection establishment process. The new socket returned by the accept function actually refers to the connection created this time. A connection includes two parts: the source IP address and the source port, and the source IP address and the target port. Therefore, accept can generate multiple different sockets, And the IP addresses and ports contained in these sockets remain unchanged. Only the source IP addresses and source ports change. In this way, these socket ports can all be 80, and the socket layer can accurately identify the ownership relationship between the IP packet and the socket based on the source/destination pair, this completes the encapsulation of TCP/IP protocol operations! At the same time, the rules for IP packet handling by the fire wall are clear and clear, and there are no complicated situations as previously imagined.

 

It is important to understand that socket is just an abstraction of TCP/IP stack operations, rather than a simple ing relationship!