First, Mac frame header definition
/* Data frame definition, first 14 bytes, tail 4 bytes * *
typedef struct _MAC_FRAME_HEADER
{
Char m_cdstmacaddress[6]; Destination MAC Address
Char m_csrcmacaddress[6]; SOURCE MAC Address
Short M_ctype; The previous layer protocol type, such as 0x0800 represents the IP protocol, 0x0806 is ARP
}__ATTRIBUTE__ ((packed)) Mac_frame_header,*pmac_frame_header;
typedef struct _MAC_FRAME_TAIL
{
unsigned int m_schecksum; Data Frame Tail Checksum
}__ATTRIBUTE__ ((Packed)) Mac_frame_tail, *pmac_frame_tail;
second, the definition of IP header structure
/*ip header definition, total 20 bytes */
typedef struct _IP_HEADER
{
Char M_cversionandheaderlen; Version information (top 4 digits), head length (after 4 digits)
Char M_ctypeofservice; Service Type 8 bits
Short M_stotallenofpacket; Packet length
Short M_spacketid; Packet identification
Short M_ssliceinfo; Fragmentation use
Char M_cttl; Survival time
Char M_ctypeofprotocol; Protocol type
Short m_schecksum; Calibration and
unsigned int m_uisourip; Source IP
unsigned int m_uidestip; Destination IP
} __attribute__ ((packed)) Ip_header, *pip_header;
third, TCP header structure definition
/*TCP header definition, total 20 bytes */
typedef struct _TCP_HEADER
{
Short M_ssourport; Source Port number 16bit
Short M_sdestport; Destination port number 16bit
unsigned int m_uisequnum; Serial number 32bit
unsigned int m_uiacknowledgenum; Confirmation Number 32bit
Short M_sheaderlenandflag; Top 4: TCP head length; 6 digits: reserved; after 6 digits: sign bit
Short m_swindowsize; Window Size 16bit
Short m_schecksum; Inspection and 16bit
Short M_surgentpointer; Emergency data offset 16bit
}__ATTRIBUTE__ ((Packed)) Tcp_header, *ptcp_header;
Option definitions in the/*TCP header
Kind (8bit) +length (8bit, length of the entire option, containing the first two parts) + content (if any)
KIND = 1 means no operation NOP, no back part
2 means that the length after the maximum segment is the maximum segment option (in bytes, 1+1+ the content part length)
3 indicates that the length behind Windows scale is that of the Windows Scale option (in bytes, 1+1+ the length of the content part)
4 indicates SACK permitted length is 2, no content part
5 means this is a sack packet length of 2, no content part
8 indicates a timestamp, length is 10, and 8 bytes of time stamp
*/
typedef struct _TCP_OPTIONS
{
Char M_ckind;
Char m_clength;
Char m_ccontext[32];
}__ATTRIBUTE__ ((Packed)) tcp_options, *ptcp_options;
the definition of UDP head structure
/*UDP header definition, total 8 bytes */
typedef struct _UDP_HEADER
{
unsigned short m_ussourport; Source Port number 16bit
unsigned short m_usdestport; Destination port number 16bit
unsigned short m_uslength; Packet length 16bit
unsigned short m_uschecksum; Checksum 16bit
}__ATTRIBUTE__ ((Packed)) Udp_header, *pudp_header;
====
Http://www.cnblogs.com/li-hao/archive/2011/12/07/2279912.html
--------------------------------------------------------------------------------------------------------------- ---------------------- TCP, IP, UDP header format
2.2 TCP/IP message format
1. IP message Format
IP protocol is the most core protocol in the TCP/IP protocol family. It provides unreliable, connectionless services, and relies on other layers of protocol for error control. In LAN environments, IP protocols are often encapsulated in Ethernet frames (see section 1.3 of this chapter) for transmission. All TCP, UDP, ICMP, and IGMP data are encapsulated in IP datagrams. As shown in Figure 2-3:
Figure 2-3 TCP/IP packet encapsulation
Figure 2-4 is the IP header (header) format: (RFC 791).
Figure 2-4 IP Header format
which
Version field: 4 bits. The version number used to indicate the implementation of the IP protocol, currently generally IPv4, that is, 0100.
Header Length (Internet header Length,ihl) field: 4 bits. Is the number of heads that are 32 bits, including the optional option. Normal IP datagram (without any options), the value of the field is 5, or 160 bits = 20 bytes. The maximum value for this field is 60 bytes.
Service type (type of service, TOS) field: 8 bits. The first 3 bits are priority child fields (precedence, which are now ignored). The 8th bit is reserved for unused. The 4th to 7th bits represent latency, throughput, reliability, and cost, respectively. When they take a value of 1 o'clock, they represent requirements for minimum delay, maximum throughput, maximum reliability, and minimum cost. Of these 4-bit service types, only 1 bits are 1. Can be all 0, if all 0 means General Service. The Service Type field declares how the datagram can be processed when it is transmitted by the network system. For example, the Telnet protocol may require minimal latency, the FTP protocol (data) may require maximum throughput, and the SNMP protocol may require maximum reliability, and NNTP (Network news Transfer Protocol, Network News Transfer Protocol) may require minimal cost, The ICMP protocol may have no special requirements (4 bits are all 0). In fact, most master opportunities ignore this field, but some dynamic routing protocols such as OSPF (Open shortest Path one Protocol), Is-is (intermediate system to intermediate system Protocol) can route decisions based on the values of these fields.
Total Length field: up to 16 bits. Indicates the length, in bytes, of the entire datagram. The maximum length is 65535 bytes.
Flag field: 16 bits. Used to uniquely identify each datagram sent by the host. Usually each message is sent, and its value is added by 1.
Flag bit field: 3 bits. Mark whether a datagram requires segmentation.
Segment offset field: 13 bits. If a datagram requires a fragment, this field indicates where the offset of the original datagram started.
Lifetime (Ttl:time to live) field: 8 bits. The number of routers that can be used to set up the datagram. Set by the source host that sends the data, typically 32, 64, 128, and so on. After each router, its value is reduced by 1, until 0 o'clock the datagram is discarded.
Protocol field: up to 8 bits. Indicates the top-level protocol type encapsulated by the IP layer, such as ICMP (1), IGMP (2), TCP (6), UDP (17), and so on.
Header checksum field: up to 16 bits. The content is based on the IP head calculation of the checksum code obtained. The calculation method is as follows: The binary inverse code summation is performed on each 16 bit in the head. (unlike ICMP, IGMP, TCP, UDP, the data after the wrong part of the IP is validated).
Source IP address, Destination IP address field: each accounted for 32 bits. Used to indicate the source host address of the sending IP data message and the destination host address of the IP message received.
Optional fields: up to 32 bits. Used to define any of the options: Record path, timestamp, and so on. These options are rarely used, and not all hosts and routers support these options. The option field must be an integer multiple of 32 bits, and if not enough, 0 must be populated to achieve this length requirement.
2. TCP Data Segment format
TCP is a reliable, connection-oriented byte throttling service. The source host needs to establish a connection with the target host before transferring data. Then, on this connection, the numbered data segments are sent in order. At the same time, it is required to confirm each data segment to ensure the reliability. The source host sends the data segment again if the target host has not received a confirmation of the data segment that was sent within the specified time.
As shown in Figure 2-5, is the TCP header structure (RFC 793, 1323).
Figure 2-5 TCP Header structure
source, Target port number field: 16 bits. The TCP protocol identifies the source and target application processes by using ports. The port number can use any number between 0 and 65535. When a service request is received, the operating system dynamically assigns the port number to the client's application. On the server side, each service serves the user in the "well-known port" (Well-know ports).
Sequence Number field: 32 bits. Used to identify the byte stream of data that is sent from the TCP source to the TCP destination, which represents the first bytes of data in the message segment.
Confirm Number field: 32 bits. The confirmation Number field is valid only if the ACK flag is 1 o'clock. It contains the next byte of data that the target side expects to receive on the source side.
Head Length field: up to 4 bits. Gives the number of heads up to 32 bits. There are no option fields with a TCP head length of 20 bytes and up to 60 bytes of TCP headers.
Flag bit fields (U, A, P, R, S, F): 6 bits. The meanings of each bit are as follows:
URG: The emergency pointer (urgent pointer) is valid.
ACK: Verify that the serial number is valid.
PSH: The receiver should hand over this message segment to the application layer as soon as possible.
RST: Rebuilding the connection.
SYN: Initiating a connection.
FIN: Frees a connection.
Window large small print segment: 16 bits. This field is used for flow control. The unit is a byte number, which is the number of bytes that the native expects to receive at a time.
TCP checksum field: up to 16 bits. The whole TCP segment, TCP head and TCP data, are verified and validated by the target side.
Emergency pointer field: up to 16 bits. It is an offset, and the value in the ordinal field is added to indicate the ordinal of the last byte of the emergency data.
Option field: 32 bits. Options such as window enlargement factor, timestamp, and so on may be included.
3. UDP Data Segment format
UDP is an unreliable, connectionless datagram service. The source host does not need to establish a connection with the target host before transferring data. The data is sent directly to the destination host after the UDP header fields such as the source and destination port number are called. At this time, the reliability of each data segment depends on the upper layer protocol to ensure. UDP is more efficient than TCP in the case of fewer and smaller data transfers.
As shown in Figure 2-6, is the UDP header structure (RFC 793, 1323):
Figure 2-6 UDP Data segment format
source, Target port number field: 16 bits. The function is the same as the port number field in the TCP data segment, which identifies the application process for the source and target ends.
Length field: Up to 16 bits. Indicates the total length byte of the UDP header and UDP data.
Checksum field: up to 16 bits. Used to validate UDP headers and UDP data. Unlike TCP, this field is optional for UDP, and the checksum field in the TCP data segment is required.
2.3 Sockets
Both the source and destination port fields are included in each TCP, UDP data segment. Sometimes, we call an IP address and a port number collectively as a socket (socket), a socket pair (socket pair) uniquely determines both sides of each TCP connection in the Interconnect network (customer IP address, client number, server IP address, server port number).
As shown in Figure 2-7, there are some common protocols and their corresponding service port numbers.
Figure 2-7 Common protocols and corresponding port numbers
It should be noted that different application layer protocols may be based on different transport layer protocols, such as FTP, TELNET, and SMTP protocols based on reliable TCP protocols. TFTP, SNMP, and RIP are based on unreliable UDP protocols.
At the same time, some application layer protocols occupy two different port numbers, such as FTP 20, 21 ports, SNMP 161, 162 ports. These application-layer protocols provide different functions on different ports. An FTP port of 21 is used to listen for a user's connection request, while Port 20 is used to transmit the user's file data. Again, SNMP 161 ports are used by SNMP management processes to obtain data for SNMP agents, while Port 162 is used by the SNMP agent to actively send data to the SNMP management process.
There are also protocols that use the services provided by different protocols in the transport layer. such as the DNS protocol uses both TCP 53 ports and UDP 53 ports. The DNS protocol provides domain name resolution services on UDP 53 ports and provides DNS zone file transfer services on TCP 53 ports.
2.4 The handshake process when a TCP connection is established and released
1, TCP establishes the connection three times handshake process
The TCP session is initialized with a three-time handshake. The goal of the three-time handshake is to synchronize the sending and receiving of the data segment. It also indicates to other hosts the amount of data they can receive at one time (the window size) and establishes a logical connection. These three handshake processes can be summarized as follows:
The source host sends a synchronous flag bit (SYN) to 1 TCP data segments. The initial sequence number (Initial Sequence number,isn) is also indicated in this section. Isn is a random value that changes over time.
The target host sends back a confirmation data segment, the SYNC flag bit (SYN) in this section is also set to 1 and the confirmation flag bit (ACK) is also set to 1, while the Confirm ordinal field indicates that the target host expects to receive the ordinal number of the next data segment of the source host (that is, the previous data segment has received and no errors). In addition, the segment initial ordinal number of the target host is also included in this section.
The source host sends back a data segment with an incremented send and confirm sequence number.
So far, the three handshake of the TCP session is complete. Next, the source host and target host can send and receive data to each other. The entire process can be represented in Figure 2-8.
Figure 2-8 TCP establishes a connection three times handshake process
2, TCP release connection four times handshake process
The release of a TCP connection requires four handshake, as follows:
The source host sends an end session request to a data segment that releases the connection flag bit (FIN) to 1
http://zoufengfu168.blog.163.com/blog/static/5461055200991333616451/