"Linux High Performance Server Programming" Learning Summary (ii)--IP Agreement detailed

Chapter II IP Protocol detailed

IP protocol is the core protocol in the family of TCP/IP protocol and one of the foundation of socket network programming. The IP protocol is characterized by the provision of stateless, non-connected, unreliable services for the upper layer.

Stateless refers to the IP communication between the two sides of the state information of the transfer of data, popular some said that the two sides sent the IP datagram is independent of each other, without any context. The disadvantage of such a feature is the inability to handle repetitive and chaotic IP datagrams, for example, assuming that due to network reasons or IP routing causes the nth number is reported than the number of n+1 to the destination host or the same IP datagram through different paths to the destination multiple times, At this point the IP module of the receiving end cannot detect the chaos and repetition, and when the data is delivered to the upper layer protocol, it causes disorder. Of course, the advantages of stateless are also obvious, simple and efficient, we do not need to like the TCP protocol to maintain a portion of the kernel resources, communication between the two sides do not have to exchange state information at the IP layer.

No connection means that both sides of the communication do not maintain any information for a long time, so the upper layer protocol must specify the IP address of each other when sending data.

Unreliable refers to the IP protocol does not guarantee that the other party receives IP packets, only to ensure that the maximum effort to deliver, and once the sender detects the sending failure, will only notify the upper layer, and will not retransmit, so the reliable transmission of data needs to be completed by the upper layer protocol.

In the IPV4 header, there are a few important points to note that the first 4-bit header length is to identify how many 32bit of the IP header, that is, how many 4 bytes, so the maximum length of the IP header is (24-1) *4=60 bytes, and the 16-bit total length is in bytes, Therefore, the maximum length of the IP datagram is (216-1) = 65535 bytes, but due to the existence of Path MTU, the average actual transmission length is far from reaching this maximum value. The first bit in the following three-bit flag is reserved, the second bit is the DF bit, which means that the Shard is forbidden, and if this position is one, the IP module will force non-sharding, the third bit is the MF bit, which represents more shards, except for the last shard of the datagram. The next 13-bit offset is in 8 bytes, in other words, the actual slice offset is the value of this bit left three bits, so, in addition to the last Shard, the remaining shard length should be an integer multiple of 8.

With respect to IP shards, if the IP datagram length is greater than the MTU, then he will be fragmented, and the Shard may occur on the sending side, may occur in the transmission process, the datagram may also be multiple shards, but only on the receiving end of the IP module is reassembled. Let's look at the process and assembly of IP shards in an example.

The Ethernet MTU is 1500, so removing the IP header, the data portion can transmit a maximum of 1480 bytes. Assuming we now have a 1481-byte ICMP packet with 8 bytes of ICMP header and 1473 bytes of data part, the Sender IP module will contain the first 1480 bytes of the ICMP header, plus the IP header as the first Shard, the MF 1, The last remaining 1 bytes plus the IP header of the MF 0 are sent to the receiving end. So we see, for the IP module, the upper layer of the protocol header and the data section is the same, in this layer is the data section. When two packets are transmitted to the receiving end, the IP module strips the IP header of the two messages in turn to assemble them. But before we mentioned that the IP protocol is stateless, that is, two IP messages are not context-sensitive, if the second segment of the packet to the receiving end first, then the receiver can also correctly assemble it? The answer is yes, because we talked about the IP header has a piece offset field, according to this field, the IP module will be able to accurately place the IP shard where it should be placed.

The next important question is, how does the IP protocol pick up the path? In order to study this problem, we must first understand the IP module workflow.

The workflow of the IP module looks complicated, but it's very simple, and we analyze it from right to left. When the host receives a datagram, it first carries out a CRC check on the datagram header, and then begins to analyze the header information, and if the datagram sets the source station routing option, invokes the datagram forwarding sub-module for processing; otherwise continue to see if the destination IP address is the IP address or broadcast address of the machine, That is, if the datagram is sent to itself, if it is, the data is delivered to the upper layer protocol, if not, continue to invoke the datagram forwarding sub-module, when the datagram forwarding sub-module received a message, the first detection of the native system is allowed to forward, if not allowed to discard, If allowed, it will be done to the IP datagram output sub-module.

And we skip the forwarding process, select the next hop Routing and ICMP redirection is the core of IP routing. The core data structure of IP module for datagram routing is the routing table, which is classified according to the target IP address of the datagram, the same type of IP datagram is sent to the same next hop, and the routing table classifies the IP address, which is the IP routing mechanism. It is divided into three steps: 1) Find the host address in the routing table that exactly matches the destination IP address of the datagram, and if it is found, use the route table entry, otherwise turn to step 2. 2) Find the network IP address in the routing table and the destination IP address of the datagram with the same network ID, that is, the IP address of the same network segment, if found, use the route table entry, or turn to step 3. 3) Select the default route, which usually means that the next hop route is the gateway.

Read here we will think, then how the routing table is generated, and how the host knows which IP address to send packets should be forwarded to whom? There are two ways to update the routing table, the first is manual static update, but the general application is very few, only in the native experiment will be used, the second is through the BGP, RIP, OSPF protocol, etc. to update the routing table.

When a data forwarding sub-module receives a datagram that needs to be forwarded and the native allows forwarding, the following actions are performed: 1) Check the TTL of the data header and discard it if the TTL is 0. 2) Check the strict Source station routing option in the data header, if it is already set, check if it is a local IP address, if not send an ICMP source station routing failure message to the sending side. 3) Send an ICMP redirect message to the source if necessary. 4) reduce the TTL by one. 5) Handle IP header options. 6) IP sharding if necessary.

The ICMP redirect message is mentioned earlier, what does this do? In fact, the host to tell the source, this datagram from me to walk detour, and tell him how to go. For example, in a network segment has host A and Host B, the gateway is router C, connected to the outside network, we put A's gateway address to B's IP address, and the forwarding function of B to open, then a to the outside of the network to send a datagram, the datagram is sent to the default gateway is Host B, But Host B finds itself receiving the port of the packet and the port it is about to forward is the same, and the source address host A and his next hop router C is in the same network segment, he will tell a, you can go directly C, do not pass me, so that a can use ICMP redirection to their own routing table to update.

"Linux High Performance Server Programming" Learning Summary (ii)--IP Agreement detailed