IPv4 and TCP header data formats

IPv4 (Internel protocol) head

#include <linux/ip.h> struct IPHDR {#if defined (__little_endian_bitfield) __u8 ihl:4,version:4; #elif defined (__b Ig_endian_bitfield) __u8 Version:4,ihl:4; #else #error "Please fix <asm/byteorder.h>" #endif __u8 tos; __be16-tot_len; __be16-id; __be16-frag_off; __U8 TTL; __U8 Protocol; __be16-check; __BE32-SADDR; __BE32-DADDR; };

iphdr->version: Version (4-bit), the current protocol version number is 4, so IP is sometimes referred to as IPv4.
IPHDR->IHL: Header Length (4 bits): The header length refers to the number of digits in the IP layer header (that is, how many 4-byte-32 bits the IP layer header contains), including any options. Since it is a 4-bit field, the header is a maximum of 60 bytes. The value of the normal IP datagram (no selections) field is 5 <==> 5 * 32/8 = 5 * 4 = Bytes.
Iphdr->tos: Service Type field (8-bit): The service type (TOS) field includes a 3 bit priority subfield (now ignored), 4 bit TOS subfield, and 1 bit unused bit but must be set to 0. The TOS sub-fields for the 4 bit represent: minimum latency, maximum throughput, maximum reliability, and minimum cost. Only 1 of these bits can be set in 4 bit. If all 4 bits are 0, then it means General Service.
Iphdr->tot_len：The total Length field (16 bits) refers to the length of the entire IP datagram, in bytes. With the header Length field and the total Length field, you can know the starting position and the length of the data content in the IP datagram. Because the word is 16 bits long, IP datagrams up to 65535 bytes total Length field is necessary in the IP header because some data links (such as Ethernet) need to be populated with some data to achieve the minimum length. Although the minimum frame length for Ethernet is 46 bytes, the IP data may be shorter. If there is no total length field, then the IP layer does not know how many of the 46 bytes are the contents of the IP datagram.
Iphdr->id: The Identity field (16-bit) uniquely identifies each datagram sent by the host. It usually adds 1 to the value of each message sent.
Iphdr->frag_off (16-bit): Low 13 bits of Frag_off domain-segmented offset (Fragment offset)The field indicates where the segment is located in the current datagram. All fragments (shards) must be multiples of 8 bytes, except for the last fragment of a datagram. This is 8 bytes is the basic staging unit. Because the domain has 13 bits, each datagram has a maximum of 8,192 segments. Therefore, the maximum datagram length is 65,536 bytes, which is 1 larger than the Iphdr->tot_len domain.
Iphdr->frag_off 3-bit high: (1) bit 0 is reserved, must be 0, and (2) bit 1 is the "more shards" (Mf-more Fragment) flag. In addition to the last piece, each of the other components of the datagram is to put the bit 1. (3)bit 2 is a "non-fragmented" (Df-don ' t Fragment) flag, and if this bit is 1,ip the datagram will not be fragmented. This datagram is discarded and an ICMP error message is sent to the starting port if there is a datagram that needs to be fragmented.
Iphdr->ttl: TTL (time-to-live)-8 bit, the time to live field sets the maximum number of routers that datagrams can pass. It specifies the time-to-live of the datagram. The initial value of the TTL is set by the source host (typically 32 or 64), and once it passes through a router that handles it, its value is subtracted by 1. When the value of this field is 0 o'clock, the datagram is discarded and an ICMP packet is sent to notify the source host. The TTL (time to live) domain is a counter that restricts the grouping lifetime. The Count time unit here is seconds, so the maximum lifetime is 255 seconds. The counter must be decremented on each hop, and the counter must be decremented multiple times when the datagram is queued for a longer time on a router. In practice, it just jumps the counter, and when it decrements to 0, the packet is discarded and the router sends a warning packet to the source host. This feature prevents the datagram from staying in the network for long periods of time, and sometimes it can happen when the routing table is destroyed.
Iphdr->protocol: Protocol field (8-bit): It can identify which protocol is transmitting data to IP according to it. When the network layer is assembled to complete a full datagram, it needs to know how to handle it. The Protocol (PROTOCOL) field indicates which transport process to give it to. TCP is a possibility, but UDP or other protocols are also possible.
Iphdr->check: The first Test and field (16-bit) are the tests and codes based on the IP header. It does not calculate the data behind the header. ICMP, IGMP, UDP, and TCP both contain headers and data checks and codes in their respective headers. To calculate the IP test for a datagram, first set the test and field to 0. Then, a binary inverse of each of the first bits of the header is summed (the entire header is considered to consist of a string of words with a number of bits), and the results are in the test and field. When an IP datagram is received, a binary inverse is summed for each of the first bits in the header. Since the receiver contains the test in the header of the sender in the calculation process, the receiver calculates a total of 1 if the header does not have any errors in the transmission process. If the result is not full 1 (that is, validation and error), then IP discards the received datagram. But do not generate error messages, from the top to find the lost data and re-transmission.
iphdr->saddr: 32-bit Source IP address
iphdr->daddr: 32-bit Destination IP address

Network byte order
The 4 byte value is transmitted in the following order: First, 0~7bit, followed by 8~15bit, then 16~23bit, and finally 24~31 bit. This transmission order is called the big endian byte order. Because all binary integers in the TCP/IP header are required in this order when they are transmitted over the network, it is also referred to as the network byte order.


TCP Header

#include <linux/tcp.h> struct TCPHDR {__be16 source; __be16 dest; __be32 seq; __be32 ack_seq; #if defined (__lit Tle_endian_bitfield) __u16 Res1:4, Doff:4, Fin:1, Syn:1, Rst:1, Psh:1, Ack:1, Urg:1, Ece:1, cwr:1; #elif defined (__big_endian_bitfield) __u16 doff:4, Res1:4, Cwr:1, Ece:1, Urg:1, Ack:1, Psh:1, Rst:1, Syn:1, Fin:1; #else #error "Adjust your <asm/byteorder.h> defines" #endif __be16 window; __BE16 check; __be16 urg_ptr; };

Tcphdr->source: 16-bit Source port number
tcphdr->dest: 16-bit destination port number
Tcphdr->seq: Indicates the number of bytes of data sent in the entire message segment. The serial number is the unsigned number of the-bit. For security reasons, its initial value is a randomly generated number that reaches the 32-bit maximum and starts at zero.
Tcphdr->ack_seq：Specifies the bytes expected to be received by the other party.
Tcphdr->doff：The TCP header length, which indicates how many 32-bit words (that is, 4 bytes) are contained in the TCP header. This information is necessary because the options field is variable in length, so the length of the entire TCP header is also varied. Technically, this field actually indicates the starting address of the data part within the segment (measured in 32-bit words as units), because this value is exactly the length of the TCP header in terms of the word, so the effect is equivalent.
tcphdr->res1: To reserve a bit.
Tcphdr->window: Is the size of the 16-bit sliding window, in bytes, starting with the value indicated by the confirmation Sequence Number field, which is the number of bytes that receive the correct expected receive, and its maximum value is 63353 bytes. Traffic control in TCP is done through a sliding window of variable size. The window field specifies how many bytes can be received from the confirmed bytes. Window = 0 is also legal, which is equivalent to that up to now up to ack_seq-1 bytes have been received, but the receiver is now in a bad state, need to rest, wait a while to continue to receive more data, thank you. Later, the receiver can tell the sender to continue sending the data segment by sending a data segment with the same ack_seq but window not being 0.
Tcphdr->check: Inspection and, covering the entire TCP segment, this is a mandatory field that must be computed and stored by the sender and validated by the receiving end.
tcphdr->urg_ptr: This field is used to indicate the position of the emergency data in the current data segment, which is a byte offset value relative to the current sequence number. This facility can replace interrupt information.
fin, SYN, RST, PSH, ACK, Urg for 6 flag bits
The fact that the 6-bit fields have been retained for more than One-fourth centuries and still intact is an indication of how thoughtful the TCP designers are thinking about them. They have the following meanings:
Tcphdr->fin: is used to release a connection. It means that the sender has no data to transmit.
Tcphdr->syn: The synchronization sequence number used to initiate a connection.The SYN bit is used to establish the connection process. In the connection request, syn=1; Ack=0 indicates that the data segment does not use a piggyback acknowledgment domain. The connection answer is a confirmation, so there is a syn=1; Ack=1. In essence, the SYN bit is used to represent the connection request and the connection accepted, but the two cases are further distinguished by an ACK bit.
Tcphdr->rst: This is used to reset an already chaotic connection, which can be confusing, possibly due to a host crash, or some other reason. This bit can also be used to reject an invalid data segment, or to deny a connection request. In general, if you get a data segment that sets the RST bit, that means you have a problem at the end.
Tcphdr->psh: The receiver should request the data to be submitted to the application immediately after receiving the data, rather than buffering it until the entire buffer is full (this may be for efficiency reasons).
Tcphdr->ack：The ack bit is set to 1 to indicate that the TCPHDR->ACK_SEQ is valid and requires that the check Ack_seq field be required. If the ACK is 0, the data segment does not contain confirmation information, so the Tcphdr->ack_seq field should be ignored.
Tcphdr->urg: The emergency pointer is valid.
tcphdr->ece: The use is temporarily unknown.
TCPHDR->CWR: The use is temporarily unknown.
The kernel source code establishes the TCP header in the function Tcp_transmit_skb ().