Shulou(Shulou.com)06/01 Report--

To write a network program, you must use Socket, which is what programmers know. Also, during the interview, we will ask each other whether they can program Socket? In general, many people will say that Socket programming is basically listen, accept and send, write and other basic operations. Yes, just like the common file operation, as long as you have written it, you must know it. [@more@]

When it comes to network programming, we also say TCP/IP, as if other network protocols no longer exist. For TCP/IP, we also know TCP and UDP, the former guaranteeing data correctness and reliability, the latter allowing data loss. Finally, we also know that before establishing a connection, we must know the IP address and port number of the other party. Besides, ordinary programmers don't know much, and many times this knowledge is enough. At best, when writing service programs, multithreading is used to handle concurrent access.

We also know the following facts:

1 。A specified port number cannot be shared by more than one program. For example, if IIS uses port 80, Apache cannot use port 80.

2 。Many firewalls only allow packets on certain destination ports.

3 。After listening to a port and accepting a connection request, the server generates a new socket to process the request.

So a question that puzzled me for a long time arose. If a socket is created and bound to port 80, does that mean that the socket occupies port 80? If so, what port is the new socket generated when it accepts a request (I always thought the system would assign it a free port number by default)? If it is an idle port, it must not be port 80, so the destination port of TCP packets in the future is not 80-the firewall will certainly prevent it from passing! In fact, we can see that firewalls do not block such connections, and this is the most common way to request and process connections. My puzzle is, why isn't the firewall blocking this connection? How does it determine which connection was made because of connet port 80? Is there something special about TCP packets? Or the firewall remembered something?

Later, I carefully studied the principles of TCP/IP protocol stack and had a deeper understanding of many concepts. For example, TCP and UDP belong to the transport layer and are jointly installed on the IP layer (network layer). The IP layer is primarily responsible for packet transmission between nodes (End to End), where a node is a network device, such as a computer. Because the IP layer is only responsible for sending data to nodes and cannot distinguish between different applications above, TCP and UDP protocols add port information to their foundations, and ports are then identified as an application on a node. In addition to adding port information, the UPD protocol basically does not perform any processing on IP layer data. TCP also adds more sophisticated transmission controls, such as sliding slice windows and acknowledgement and retransmission mechanisms, to ensure reliable data delivery. No matter what kind of stable TCP data flow the application layer sees, the following IP data packets are transmitted one by one, and the TCP protocol needs to reassemble the data.

So, I have reason to suspect that firewalls don't have enough information to judge TCP packets for anything more than IP addresses and port numbers. Moreover, we also see that the so-called ports are used to distinguish between different applications so that different IP packets can be forwarded correctly when they arrive.

TCP/IP is just a protocol stack, just like the operating mechanism of the operating system, it must be implemented concretely, and at the same time it must provide an external operating interface. Just as operating systems provide standard programming interfaces, such as Win32 programming interfaces, TCP/IP must also provide programming interfaces to the outside world, which is the Socket programming interface--so that's what happened!

In the Socket programming interface, the designer proposed a very important concept, that is, socket. This socket is very similar to file handles, and in fact is stored in the same process handle table as file handles in BSD systems. This socket is actually a serial number indicating its position in the handle table. We've seen this a lot, file handles, window handles, and so on. These handles, in fact, represent some specific objects in the system, used as parameters in various functions to operate on specific objects-this is actually a C language problem, in C++ language, this handle is actually this pointer, actually object pointer.

We now know that socket is not necessarily linked to TCP/IP. Socket programming interfaces are designed to accommodate other network protocols as well. Therefore, the appearance of socket is only more convenient to use TCP/IP protocol stack, which abstracts TCP/IP and forms several basic function interfaces. Create, listen, accept, connect, read, write, etc.

Now we understand that if a program creates a socket and asks it to listen on port 80, it is declaring its possession of port 80 to the TCP/IP stack. Later, all TCP packets destined for port 80 will be forwarded to the program (here, because the program uses the Socket programming interface, it is first processed by the Socket layer). The so-called accept function is actually the TCP connection establishment process abstractly. The new socket returned by the accept function actually refers to the connection created this time, and a connection includes two parts of information, one is the source IP and source port, and the other is the sink IP and sink port. Therefore, accept can generate multiple different sockets, and the sink IP and sink port contained in these sockets are unchanged, and only the source IP and source port change. In this case, the socket sink port can be 80, and the Socket layer can accurately distinguish the ownership relationship between IP packets and sockets according to the source/sink pair, thus completing the operation encapsulation of TCP/IP protocols! At the same time, the IP packet processing rules of the arson wall are also clear and clear, and there are no complicated situations envisaged above.

It is important to understand that sockets are abstractions of TCP/IP stack operations, not simple mappings!

A socket is determined by four identifiers, client ip, client port, server ip, server port,

In a client and server communication process, client ip, server ip, server port, are the same, only the client port is different, but as long as one is different, even if it is a new socket,

So accept returns a new socket.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.