简单!
全部博文(366)
分类: LINUX
2012-02-15 16:39:18
The IP packet (Layer 3 in the OSI model) is created by taking the layer 4 TCP or UDP datagram and adding IP headers to it. The IP packet is then sent to Layer 2 where more headers are added to it, creating a frame or cell (Ethernet, Frame Relay, ATM, etc), which is then transmitted along the physical Layer 1..
IP Packet Length (size of the packet, in bytes)
Minimum Packet Length = 20 bytes
Maximum Packet Length = 65,535 bytes
The packet length is a very important consideration, since all network administrators need to minimize SAR (Segmentation And Reassembly), or fragmentation. Therefore, they need to know the MTU (Maximum Transmission Unit), which is the largest IP packet that can travel through from sender to receiver, self-contained, with no fragmentation. The MTU applies to the entire path, and includes all devices that a packet passes through. You can discover this value using pings (see ). However, the MTU value may change, depending on the route taken, so it is best to run the ping test repeatedly, several times a week, for about one month.
Here we detail only v4 packets. The packet length differs for IPv4 and IPv6 (IPnG - IP next Generation). IPv4 is still by far, the predominant protocol, with IPv6 a long way off:
IP packets encapsulated into Ethernet Frames
Note that maximum length Ethernet II frames (1518 bytes, with a payload of 1500 bytes) are much smaller that maximum length IP packets (65,535 bytes). Therefore, for large packets, they must be fragmented into many frames !!
For example, the number of Ethernet frames required to deliver a maxed out packet of 65535 bytes across an Ethernet LAN, between two workstations can be calculated as follows:
65535 divide by 1500 = 43.69
Therefore it will take 44 Ethernet frames to carry one maximum-sized IP packet across a data link. Now, does this mean that IP packets are constantly being fragmented? Not at all !! Most applications send small chunks of data, that is below the maximum frame size.
Transmitting the IP Packet (byte order and bit order)
Typically, IP packets are first encapsulated into a Layer 2 PDU, which 99% of the time is Ethernet. Since the packets are within frames, the bit/byte order is determined by looking at the transmission of the Ethernet frame. Actually there is no need to even think about IP packet transmission, since they are not transmitted directly. But we will cover it here by going over the methodology of Ethernet frame transmission.
The transmission is a bit strange, in that the byte order is big-endian (leftmost byte is sent first), but bit order little-endian (rigthmost, or LSB (Least Significant Bit) of the byte is sent first). For example, if you are sending a frame:
<---
Well, most Ethernet frames contain IP packets !! And the IP packets are transmitted in the same way, as an internal portion of the Ethernet frame.
For example we will show the first 4 bytes:
11100001 00001111
10101010 10010011
Byte1
Byte2 Byte3
Byte4
The data normally moves to the left, and this is true for each of the 4 bytes - they will be transmitted in big-endian, meaning "left byte first". But we must reverse the bits in each byte, to show the actual serial stream of bits moving to the left. So the actual bits being transmitted to the left, are as follows with the bits in each byte reversed:
< 10000111 11110000
01010101 11001001
Byte1
Byte2 Byte3
Byte4
(reversed) (reversed)
(reversed) (reversed)
NOTE: Ethernet frame transmission is "dumb" - and it does not group bytes. It has no idea that it is sending a 6-byte address, or a 2-byte Type, etc. It simply sends the entire frame, one byte at a time, from left to right, with each byte being sent LSB first and MSB last.
IP Packet Fields (the contents of the packet)
As with layer 2 Frames, the layer 3 data units (packets) are divided up into a number of sub-units called "fields". The following diagram shows all of the fields of a single IP packet. There are numerous fields, and therefore they are depicted using 32-bits per row. In reality they are lined up side-by-side in one long row of data, which is transmitted serially. For the purpose of placing them all in one simple diagram, we have followed the same representation that is used by the RFC (RFC791). It reads like a book, beginning the the version field and ending with the payload field.
For detailed information on any particular field - just click on it :
Version - 4 bits - specifies the IP version in use (currently 4)
Header Length (HLEN) or Internet Header Length (IHL) - the length of the header in 32-bit words (5 words + Options words - the max options is 10 words, therefore the max IHL is 15 words usually 5 without options)
TOS - Type of Service. This field has the following components:
Identification - used for fragmentation and reassembly. Each datagram unique identifier for each originating datagram. Must be copied into each fragment. (usually incremented by 1 for each datagram)
Flags - 3 bits - first bit is always zero, so some do not consider that a "flag". Next bit is DF (Don't Fragment, 1=Don't Fragment) and the last bit is MF (More Fragments, 0=last fragment, 1=more fragments coming)
Fragment Offset. Starting location of this fragment with original datagram. In 8-octet multiples.
Time to Live. Handled as follows:
Protocol. Specifies the protocol of the data payload, and hence the structure of the payload.
Header Checksum. Formed from the ones-complement of the header, treating it as a sequence of 16-bit integers (big-endian). Addresses. 32-bit network addresses of the source and destination hosts. (address structure will be covered later)
Options - 99% of IP packets have no options !!! These are mainly used for control and debugging. The presence of optional fields is determined by the header length. Some are copied into each fragment; others only continue in the first. Options include:
摘自