IP/TCP message headers and corresponding structural bodies

In the network programming, most of the time is to use the kernel filled with the message header, and then we fill in the data section to send. But if you're not sending a TCP/IP protocol, or some other reason, you need to fill the header of your message. In the filling of the message, the first is to understand the structure of the message header.

The following is the structure of the IP header and the structure of IP headers, respectively, to RFC791 and RFC793.

Also incidentally looked at the next UDP protocol introduction, reference RFC768. There was a doubt that UDP should come out after the IP protocol, in order to solve TCP's shortcomings, why the RFC number than IP and TCP advance so much. So I looked for some history that didn't get the results, and I finally found the answer in the RFC document, 791 and 793 were the upgraded versions of 760 and 761, respectively. Now it seems a little more reasonable.

Now that you've solved the little question, go ahead. We use the TCP/IP protocol to send data when the IP header and tcp/first and then with the data section.

Understand the format of the head, and then look at the structure of the head in the library file definition

struct IPHDR
  {
#if __byte_order = = __little_endian
    unsigned int ihl:4;     The length of the header
    unsigned int version:4;     Protocol version number, 4/6, indicating Ipv4/ipv6
#elif __byte_order = = __big_endian
    unsigned int version:4;
    unsigned int ihl:4;
#endif
    u_int8_t tos;       Type of service Types field
    u_int16_t Tot_len;  The total length of the IP packet
    u_int16_t ID;       Identification field
    u_int16_t Frag_off;     Fragment offset segmented migration, 
    u_int8_t ttl;       Time to Live maximum of 255, each through a route minus 1
    u_int8_t protocol;  protocol, such as TCP is 6,UDP is 8,icmp is 1, in in.h has defined
    u_int16_t check;    First calibration and
    u_int32_t saddr;    Source IP address
    u_int32_t daddr;    Destination IP address
    /*the options start here. *
  /};

struct TCPHDR
  {
    u_int16_t source;   Source port number
    u_int16_t dest;     Destination port number
    u_int32_t seq;      The initial byte number of the data in the whole message is
    u_int32_t ack_seq;  The next byte that you want to receive
    u_int16_t Res1:4;   Reserved word
    u_int16_t doff:4;   TCP head length
    u_int16_t fin:1;    Used to release a link
    u_int16_t syn:1;    Sync serial number, used to initiate the link
    u_int16_t rst:1;    Reset a messy link
    u_int16_t psh:1;    Immediately after receiving the data to the application
    u_int16_t ack:1;    1 indicates ack_seq valid, 0 means ack_seq should be ignored
    u_int16_t urg:1;    Emergency pointer
    u_int16_t res2:2;   This is not found in the format, also did not find any effect
    u_int16_t window;   The size of the sliding window
    u_int16_t check;    Calibration and
    u_int16_t urg_ptr;  Just the location of the emergency data in the current data segment
};

Some of the judgment sizes in TCPHDR are too long to be deleted.

The interpretation of the data field is also more concise, detailed explanation forget when you can look up other information, short text can play the role of the hint. I haven't studied for a while.