TCP/UDP Data Detailed

First, the Mac frame header definition

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 previous layer is 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 Check and
}__ATTRIBUTE__ ((Packed)) Mac_frame_tail, *pmac_frame_tail;

Second, the definition of IP header structure

typedef struct _IP_HEADER
{
Char M_cversionandheaderlen; Version information (first 4 bits), head length (last 4 bits)
Char M_ctypeofservice; Service Type 8-bit
Short M_stotallenofpacket; Packet length
Short M_spacketid; Packet identification
Short M_ssliceinfo; Shard usage
Char M_cttl; Survival time
Char M_ctypeofprotocol; Protocol type
Short m_schecksum; Checksum
unsigned int m_uisourip; Source IP
unsigned int m_uidestip; Destination IP
} __attribute__ ((packed)) Ip_header, *pip_header;

Third, TCP header structure definition

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 bits: TCP header length, medium 6 bit: reserved, last 6 bits: Flag 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;

typedef struct _TCP_OPTIONS
{
Char M_ckind;
Char m_clength;
Char m_ccontext[32];
}__ATTRIBUTE__ ((Packed)) tcp_options, *ptcp_options;

Iv. definition of UDP header structure

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 important protocol in the family of TCP/IP protocols. It provides unreliable, non-connected services that rely on protocols from other tiers for error control. In a LAN environment, 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 an IP datagram. 2-3 is shown below:

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 IP protocol implementation, which is currently generally IPv4, i.e. 0100.

Header Length (Internet header Length,ihl) field: 4 bits. is a number with a 32-bit head, including optional options. Normal IP datagram (without any options), the value of this field is 5, which is 160 bits = 20 bytes. The maximum value for this field is 60 bytes.

Service type (type of service, TOS) field: occupies 8 bits. The first 3 bits are the priority sub-fields (precedence, which are now ignored). The 8th bit remains unused. The 4th to 7th bits represent latency, throughput, reliability, and cost, respectively. When they are valued at 1 o'clock, they represent requirements for minimum delay, maximum throughput, maximum reliability, and minimum cost respectively. Only 1 bits of this 4-bit service type can be placed in 1. Can be all 0, if all 0 represents the General Service. The Service Type field declares how the datagram can be handled by the network system when it is transmitted. For example: The Telnet protocol may require minimal latency, the FTP protocol (data) may require maximum throughput, the SNMP protocol may require maximum reliability, and the NNTP (Network news Transfer Protocol, Web-feed protocol) may require a minimum cost, The ICMP protocol may have no special requirements (4 bits are all 0). In fact, most of the main opportunities ignore this field, but some dynamic routing protocols such as OSPF (Open shortest Path first Protocol), Is-is (intermediate system to intermediate system Protocol) can make routing decisions based on the values of these fields.

Total Length field: occupies 16 bits. Indicates the length, in bytes, of the entire datagram. The maximum length is 65535 bytes.

Flag field: occupies 16 bits. Used to uniquely identify each datagram sent by the host. Usually each message is sent with a value of 1.

Flag bit field: occupies 3 bits. Flag whether a datagram requires fragmentation.

Segment offset field: occupies 13 bits. If a datagram requires fragmentation, this field indicates the position of the segment offset from the beginning of the original datagram.

Lifetime (Ttl:time to live) field: 8 bits. Used to set the maximum number of routers that a datagram can pass through. is set by the source host that sends the data, typically 32, 64, 128, and so on. Each router passes with a value minus 1 until 0 o'clock the datagram is discarded.

Protocol field: occupies 8 bits. Indicates the upper-level protocol type encapsulated by the IP layer, such as ICMP (1), IGMP (2), TCP (6), UDP (17), and so on.

Header checksum field: 16 bits. The content is the checksum code computed from the IP header. The method is calculated by summing the binary inverse code for each 16 bits in the head. (unlike ICMP, IGMP, TCP, and UDP, the data behind the wrong part of the IP is verified).

Source IP address, Destination IP address field: 32 bits each. Used to indicate the source host address of the sending IP data message and the destination host address of the receiving IP message.

Optional field: 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 length of the optional field must be an integer multiple of 32 bits, and if insufficient, 0 must be populated to meet this length requirement.

2. TCP Data Segment format

TCP is a reliable, connection-oriented byte-stream service. The source host needs to establish a connection with the target host before transmitting the data. Then, on this connection, the numbered data segments are sent and received sequentially. 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 destination host does not receive a confirmation of the data segment that was sent within the specified time.

As shown in 2-5, is the TCP header structure (RFC 793, 1323).

　　 　

Figure 2-5 TCP Header structure

Source, Destination port number field: 16 bits. The TCP protocol identifies the application process on the source and target side by using "port". The port number can use any number from 0 to 65535. When a service request is received, the operating system dynamically assigns a port number to the client's application. On the server side, each service serves the user on a "well known port" (Well-know).

Sequence Number field: 32 bits. Used to identify a stream of data bytes sent from the TCP source to the TCP destination, which represents the first data byte in the message segment.

Confirmation Number field: occupies 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 from the source.

Head Length field: occupies 4 bits. Give the number of heads to 32 bits. A TCP header with no option field is 20 bytes long and can have 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: Emergency pointer (urgent pointer) valid.

ACK: Confirm the serial number is valid.

PSH: The receiver should hand over this segment to the application layer as soon as possible.

RST: Rebuilding the connection.

SYN: Initiates a connection.

FIN: Releases a connection.

Window Size segment: 16 bits. This field is used for flow control. The unit is the number of bytes, which is the number of bytes that the native expects to receive at one time.

TCP checksum field: 16 bits. The entire TCP message segment, TCP header and TCP data, is verified and evaluated by the target side.

Emergency pointer field: occupies 16 bits. It is an offset, and the sum of the values in the Ordinal field represents the ordinal of the last byte of the emergency data.

Option field: occupies 32 bits. This may include options such as window enlargement factor, timestamp, and so on.

3. UDP Data Segment format

UDP is an unreliable, non-connected datagram service. The source host does not need to establish a connection with the destination host before transmitting the data. The data is sent directly to the destination host after the UDP header fields such as source, destination port number, etc. At this point, the reliability of each data segment is guaranteed by the upper layer protocol. UDP is more efficient than TCP in cases where data is transmitted less and less.

As shown in 2-6, is the UDP header structure (RFC 793, 1323):

　　 　

Figure 2-6 UDP Data segment format

Source, Destination port number field: 16 bits. The function is the same as the port number field in the TCP data segment and is used to identify the application process on the source and target side.

Length field: occupies 16 bits. Indicates the total length byte of UDP header and UDP data.

Checksum field: occupies 16 bits. Used to verify UDP headers and UDP data. Unlike TCP, this field is optional for UDP, and the checksum field in the TCP data segment is mandatory.

2.3 Sockets

The source and destination port fields are included in each TCP, UDP data segment. Sometimes, we collectively name an IP address and a port number as a socket (socket), and a socket pair (socket pair) can uniquely determine the sides of each TCP connection in the connected network (client IP address, client number, server IP address, server port number).

As shown in 2-7, are some of the common protocols and their corresponding service port numbers.

　　 　

Figure 2-7 Common protocols and corresponding port numbers

It is important to note that different application layer protocols may be based on a reliable TCP protocol depending on the transport layer protocol, such as FTP, TELNET, and SMTP 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 capabilities on different ports. such as FTP port 21 is used to listen to the user's connection request, and 20 port is used to transfer the user's file data. As another example, the SNMP 161 port is used for SNMP management process to obtain the data of the SNMP agent, while 162 port is used by SNMP agent to send data to SNMP management process actively.

There are also protocols that use the services provided by different protocols of the transport layer. For example, the DNS protocol uses both TCP 53 ports and UDP 53 ports. The DNS protocol provides the DNS zone file transfer service on port 53 of UDP, providing domain name resolution services on TCP port 53.

2.4 Handshake process When a TCP connection is established and released

1, TCP to establish a connection of three times handshake process

The TCP session is initialized by a three-time handshake. The goal of the three-time handshake is to synchronize the sending and receiving of data segments. It also indicates to other hosts the amount of data (window size) that it can receive at one time, and establishes a logical connection. The three-time handshake can be summarized as follows:

The source host sends a synchronous flag bit (SYN) 1 TCP data segment. The initial sequence number (Initial Sequence number,isn) is also indicated in this paragraph. Isn is a random value that changes over time.

The target host sends back the acknowledgment data segment, and the synchronization flag bit (SYN) in this segment is also set to 1, and the confirmation flag bit (ACK) is set to 1, while the Confirm ordinal field indicates that the target host expects to receive the ordinal of the next data segment of the source host (that is, the previous data segment was received and there is no error) In addition, the segment initial sequence number of the target host is also included in this paragraph.

The source host then sends back a data segment, with an incremented send sequence number and an acknowledgment sequence number.

So far, the three-time handshake for 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 Three-time handshake process for establishing a connection

2. Four handshake process for TCP release connection

The release of the TCP connection requires four handshakes, the step is: the source host sends a release connection flag bit (FIN) to 1 of the data segment to issue the end session request

TCP/UDP Data Detailed