Strictly speaking, the TCP/IP protocol family does not define "dedicated TCP/IP" network hardware specifications. The hardware scope is too broad and there are many standards. Most of the Low-layer network hardware standards today are developed by IEEE, but many standards are exclusive to vendors.
To allow TCP/IP protocols to communicate smoothly with different types of hardware, we need to establish some standard protocols for your reference. Taking the most common Ethernet network as an example, we don't have to worry about how vendors design network interface drivers. Once it is accepted by the system, the network storage layer (Datalink) you can use the network interface to send and receive data on the physical network.
Problems related to IP address and object address
In the "Network basics" course, we know that the shipping method used on the Ethernet is CSMA/CD (Carrier-Sensing Multiple Access with Collision Detection): although the message frame will be in the entire segment (segment) it is transmitted in broadcast mode, and all nodes will receive the message box. However, only the message box with the target address that matches the actual address will be received. Therefore, regardless of the Upper-Layer Protocol (TCP/IP or other Protocols), if Ethernet is used for transmission at the bottom layer, you must use the MAC (Media Access Control) object address. To query the object addresses on all interfaces of the current system, enter the ifconfig command in Linux ﹕
eth0 Link encap:Ethernet HWaddr 00:A0:0C:11:EA:11 inet addr:203.30.35.134 Bcast:203.30.35.159 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:3 Base address:0x300eth1 Link encap:Ethernet HWaddr 00:80:C7:47:8C:9A inet addr:192.168.0.17 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12303 errors:0 dropped:0 overruns:0 frame:0 TX packets:12694 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x2e0 |
From the preceding command results, we can find that the last part of the first line of information about each interface is the object address of the interface. When a message frame is transmitted over a physical network, the IP address (or the interface address) is useless. But the problem is: when we use TCP/IP, the upper-layer protocols are based on IP addresses for transmission. At this time, we must have a set of methods to correspond to IP addresses and physical addresses.
In this process, the key point is to map the IP address to the physical address. Some networks that use simple physical addresses (such as proNET-10) actually occupy only one byte length and allow users to select their own physical addresses When configuring the network card. It is relatively simple to map the IP address and the real address on such a network. We can set the real address to the same as the IP address. For example, if the IP address of a node is 192.168.1.17, we can set this object address to 17. In this way, you can easily obtain the object address based on the IP address in proNET. This correspondence is very simple and easy to maintain. When a new machine is connected to the Internet, it does not need to modify or re-compile the existing data.
However, we know that on the Ethernet, each physical interface has a 48-bit (6 byte) MAC address, while IP (v4) uses a 32bit (4 byte) address) ﹔ each address format can only be used by corresponding level agreements, and cannot be used interchangeably. At this time, we cannot use a simple mathematical relationship to correspond IP addresses to physical addresses.
Corresponding methods of IP address and object address
Create a table
First, the simplest way we think of is to create a table on each machine that corresponds to an IP address and an object address ). However, this method still cannot solve the following situation ﹕
· If the number of nodes on the network is large, such as sanded, it is almost impossible to include all node mappings in the table.
· If a node changes (for example, network card replacement), it is also a headache to make correct changes to all tables.
· For a non-disk workstation, because there is no local storage device, nothing more than creating a table.
Write advanced programs
In addition to creating tables, we can also write the actual network address to the high-order network program. However, like the previous method, if the hardware address changes or other changes become emotional, the program also needs to be re-compiled.
Obviously, the above two methods are not very clever.
ARP Protocol
Here we will introduce Address Resolution Protocol (ARP ). ARP is an address interpretation protocol designed by TCP/IP designers to use the broadcast nature of Ethernet. Its main feature and advantage is that its address ing is dynamic. It obtains the ing between the IP address and the object address in the query mode. Its working principle is very simple ﹕
1. First, each host creates an ARP table in the ARP Cache to record the relationship between the IP address and the physical address. Each piece of data in this Table will eventually disappear according to its own survival time, to ensure the authenticity of the data.
2. when the sending host has a packet to send to the target host and obtains the IP address of the target host, the sending host will first check whether there is a physical address of the IP address in its ARP table.. If yes, use this address directly to send the box packet scheme. If no, an ARP Request broadcast packet is sent to the network to query the object address of the target host. This package contains the IP address and object address of the sender.
3. At this time, all hosts on the network will receive the broadcast packet, and check whether the IP field of the packet is consistent with its own IP address. If not, ignore the scheme. If yes, update the object address and IP address of the sender to its ARP table. If the corresponding IP address already exists, use the new data to overwrite the original data. and then respond to an ARP Reply packet to the other party, telling the sender of the host about its own physical address ﹔
4. When the sender receives ARP Reply, it also updates its ARP table scheme and can use this record for transfer.
5. If the sender does not obtain ARP Reply, the query fails.
For more information about ARP queries, see ﹕
ARP Query Process
The preceding ARP table is created only after the TCP/IP protocol is loaded to the core. If the TCP/IP protocol is uninstalled or the machine is disabled, the table is cleared until the next time. when the Protocol is loaded or started, it is re-established. At the same time, it sends an ARP broadcast to the network, telling other machines what its current address is, so that all machines can maintain the most correct information.
However, the size of the ARP cache is limited. If the limit is exceeded, the more time the transition data is not used, the more data must be cleared to free up space for storing updated data. Therefore, when the machine receives the ARP equest packet, if the query object is not its own, it will not update its ARP table based on the sender's address information, but will ignore the packet completely. At the same time, each piece of data in the cache is not permanently saved: when each piece of data is updated, it is assigned a Survival Countdown value. If the last time is reached ﹐ this information will be cleared. However, if the data has been used before the countdown, the timing value will be assigned again.
Of course, there is still a mechanism for ARP to handle the situation where ARP table data does not meet the actual address information (for example, you receive the address information update message of the target end before the current connection is complete) the reply or target host is too busy to answer ARP requests.
RARP Protocol
The ARP Protocol just introduced is to find the physical address by querying the network. The RARP protocol we will discuss next is the opposite: it gets its own IP Address by querying other hosts on the network..
Usually, when we use the ethernet card, a manufacturer will burn the physical address of the network card in the ROM when leaving the factory. This address cannot be changed (some models of network cards, or through other technical means allow you to modify the object address ). Regardless of whether the system is up or not, this address will exist and it is easy for the system to obtain it. However, in some diskless) on the workstation, the system files are stored on the remote server. When it is started, it cannot communicate with the server because it does not have an IP address, and cannot load the system files. Then, we must have a way for such a non-disk workstation to obtain its own IP address before communicating with the server. The RAPR Protocol was designed to solve this problem.
Like the ARP protocol, RARP also queries the IP address in the form of broadcast, but the IP address is not someone else, but your own IP address. We can see that the operation of RARP is very similar to ARP ﹕
RARP Query Process
First, query the host to send an RARP Request broadcast packet to the network, and query its own IP address from other hosts. At this time, The RARP server on the network will send the IP address of the sender to the queryer using the RARP Reply packet. In this way, the host will get its own IP address.
However, unlike ARP, the query host may get more than one RARP Reply after dropping the RARP Request packet (In ARP query, we can make sure that only one response is received ). Because there may be more than one RARP server on the Network (designed based on backup and sharing considerations), all servers that receive RARP requests will attempt to respond to the query host in RARP Reply. In this case, the network will be flooded with this RARP response, making it an additional load. At this time, we have two ways to solve the RARP response problem.
The first method is to allocate a master server to each host that initiates the RARP request. Normally, only the master server responds to the RARP request. Other hosts only record the time when the RARP request was received.. If the master server cannot respond smoothly, the query host sends the RARP request again in broadcast mode while waiting for the Failover. If other non-master servers receive the same request within a short time after receiving the first request.
The second method is similar: Normally, when the master server receives the RARP request, it will directly respond to the slave server to avoid all non-master servers returning the RARP response at the same time, and each non-master server will randomly wait for a while before responding. If the master server fails to respond, the query host will be delayed for a period of time before the second request is made to ensure that the response from the non-master server is received during this period of time. Of course, designers can carefully design the delay time to a reasonable interval.
Related Articles]
- Implementation of ARP Sniffer in Windows switching Environment
- Sun Solaris TCP/IP network stack unknown Denial of Service Vulnerability
