• 网络校验和计算


    1. 前言
    校验和计算是NAT功能和内容修改功能的基本功,这些操作进行后都需要修改数据头中的校验和。
    2. 16位校验和计算
    2.1 基本原理 
    IP/ICMP/IGMP/TCP/UDP等协议的校验和算法都是相同的,采用的都是将数据流视为16位整数流进行重复叠加计算。为了计算检验和,首先把检验和字段置为0。然后,对有效数据范围内中每个16位进行二进制反码求和,结果存在检验和字段中,如果数据长度为奇数则补一字节0。当收到数据后,同样对有效数据范围中每个16位数进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全0或全1(具体看实现了,本质一样) 。如果结果不是全0或全1,那么表示数据错误。
    2.2 程序算法
    2.2.1 C实现 
    这是RFC1071中提供的C语言程序:
    unsigned short csum(unsigned char *addr, int count)
    {
               /* Compute Internet Checksum for "count" bytes
                *         beginning at location "addr".
                */
           register long sum = 0;
           while( count > 1 ) {
               /* This is the inner loop */
                   sum += * (unsigned short) addr++;
                   count -= 2;
           }
               /* Add left-over byte, if any */
           if( count > 0 )
                   sum += * (unsigned char *) addr;
               /* Fold 32-bit sum to 16 bits */
           while (sum>>16)
               sum = (sum & 0xffff) + (sum >> 16);
           return ~sum;
    }
     
    当然,如果用汇编语言实现计算速度会快得多,对于不同的CPU体系,需要各自对应编写不同的汇编,在Linux内核源代码中有各种CPU体系的IP校验和计算源代码。
    2.2.2 增量式修改
    如果只修改了一个字节,如只修改IP头中的TTL,重新计算校验和时是没必要将所有数据范围内数据重新计算一遍的,RFC1141中提出了增量式算法:
             ~C' = ~(C + (-m) + m') = ~C + (m - m') = ~C + m + ~m'
    C'为修改后的校验和,C为修改前的校验和,m为修改前的数值,m'为修改后的数值,~为补码值。
    C代码实现为:
    UpdateTTL(iph,n)
          struct ip_hdr *ipptr;
          unsigned char n;
          {
              unsigned long sum;
              unsigned short old;
              old = ntohs(*(unsigned short *)&ipptr->ttl);
              ipptr->ttl -= n;
              sum = old + (~ntohs(*(unsigned short *)&ipptr->ttl) & 0xffff);
              sum += ntohs(ipptr->Checksum);
              sum = (sum & 0xffff) + (sum>>16);
              ipptr->Checksum = htons(sum + (sum>>16));
          }
     
    2.3 网络应用
    2.3.1 IPv4 
    IPv4层中的校验和只包括IPv4头部分,不包括上层协议头和应用层数据,校验和是必须计算的。
    2.3.2 IPv6 
    IPv6头本身已经不包括校验和字段,只靠上层协议的校验和。
    2.3.3 ICMP/IGMP
    ICMP/IGMP校验和计算范围为从ICMP/IGMP开始到数据结束,不包括IP头部分,校验和是必须计算的。
    2.3.4 TCP/UDP
    TCP/UDP的校验和计算有点特殊,所计算的数据范围除了包括TCP/UDP头开始到数据结束外,还要包括一个IP伪头部分,所谓伪头,只有12字节数据,包括源地址(4字节)、目的地址(4字节)、协议(2字节,第一字节补0)和TCP/UDP包长(2字节)。TCP的校验和是必须的,而UDP的校验和是可选的,如果UDP中校验和字段为0,表示不进行校验和计算,因此对于UDP协议数据的修改后想偷懒的话直接将校验和设为0 就可以了。
    2.3.4.1.IP和TCP校验和的计算:
    in_cksum(unsigned short *addr, int len)
    {
        register int nleft = len;
        register u_short *w = addr; //u_short 16bit 
        register int sum = 0;
        u_short answer =0;
        while (nleft >1)
        {
            sum += *w++;
            nleft -= 2;  //16bit=2 bytes
        }
        if (nleft == 1)   //odd时,pad zero
        {
           *(u_char *)(&answer) = *(u_char *)w;
           sum += answer;
        }
        sum = (sum >>16) + (sum & 0xffff);
        sum += (sum >> 16);
        answer = ~sum;   //求反
        return(answer);
    }
     
    /* calculate the ip checksum */
    send_tcp.ip.check = 0;   //先检验和置0
    send_tcp.ip.check=in_cksum((unsigned short *)&send_tcp.ip, 20);
     
    /* calculate the tcp checksum */
    struct pseudo_header //tcp伪头部
    {
        unsigned int source_address;
        unsigned int dest_address;
        unsigned char placeholder;
        unsigned char protocol;
        unsigned short tcp_length; //以上3*32字节为伪造的tcp首部
        struct tcphdr tcp;  //TCP头
        u_char html[bufsize];  //html数据,包括http头和数据
    } pseudo_header;
    /* set the pseudo header fields */
    pseudo_header.source_address = send_tcp.ip.saddr;
    pseudo_header.dest_address = send_tcp.ip.daddr;
    pseudo_header.placeholder = 0;
    pseudo_header.protocol = IPPROTO_TCP;
    pseudo_header.tcp_length = htons(20);
    bcopy((char *)&send_tcp.tcp, (char *)&pseudo_header.tcp, 20);
    //将send_tcp的数据拷如pseudo_header中的tcp
    bcopy(htmlbuf, (char *)&pseudo_header.html, sizeof(htmlbuf));
    send_tcp.tcp.check = in_cksum((unsigned short *)&pseudo_header, sizeof
    (pseudo_header));
     
    2.3.4.2.UDP校验和计算:
    UDP的CHECKSUM算法与IP包的HEADER CHECKSUM的计算方法基本一样,只是取样数据不同。UDP中,参与计算CHEKCSUM的数据包括三部分: 亚头部+UDP头部+数据部分亚头部包括:2byte源IP地址+2byte目的IP地址+0x00+1byte协议+2byte的UDP长度UDP包头:2byte源端口+2byte目的端口+2byteUDP包长+0x0000(checksum)数据部分
    计算方法,以2字节为一个单位,将其顺序相加,就会产生2个字节的SUM,如果超过2字节,则将高位的值再加回低位,然后取补,得到的就是UDP的checksum.
    fixCheckSumUDP(struct udphdr * const        udp,
                               struct iphdr const * const        ip,
                               void const * const                       data)
    {
            uint32_t                sum;
            struct 
            {
                    struct in_addr src;
                          struct in_addr dst;
                    uint8_t                mbz;
                    uint8_t                proto;
                    uint16_t                len;
            } __attribute__((__packed__))        pseudo_hdr;
            pseudo_hdr.src.s_addr   = (ip->saddr).s_addr;
            pseudo_hdr.dst.s_addr   = (ip->daddr).s_addr;
            pseudo_hdr.mbz   = 0;
            pseudo_hdr.proto = ip->protocol;
            pseudo_hdr.len   = udp->len;
            udp->check = 0;
            sum = calculateCheckSum(&pseudo_hdr, sizeof(pseudo_hdr), 0);
            sum = calculateCheckSum(udp, sizeof(*udp), sum);
            sum = calculateCheckSum(data, ntohs(udp->len)-sizeof(*udp), sum);
            
            sum = ~ntohs(sum);
            if (sum==0) 
                    sum=~sum;
            
            udp->check = sum;
    }

    3. 32位校验和
    3.1 以太帧
    以太帧校验和使用的是CRC校验,校验和为4字节32位,算法比较适合硬件实现,其计算和校验都是底层完成的,在IP栈以上时就不用考虑,即使上层直接是构造以太帧发送,也只需构造以太头部即可,发送时由底层自动添加后面的校验和。
    3.2 SCTP 
    在SCTP(协议号:132)协议中,校验和计算比较特殊,采用了和以太包校验和相似的CRC32算法(RFC3309),计算结果是32位而不再是16位。计算范围为从SCTP头到数据结束,不包括IP伪头。
    以下是从Linux内核源码SCTP实现中摘取的CRC32算法源码:
    /* Example of the crc table file */
    #ifndef __crc32cr_table_h__
    #define __crc32cr_table_h__ 
    #define CRC32C_POLY 0x1EDC6F41
    #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 
    static unsigned long crc_c[256] =
    {
    0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
    0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
    0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
    0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
    0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
    0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
    0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
    0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
    0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
    0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
    0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
    0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
    0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
    0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
    0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
    0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
    0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
    0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
    0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
    0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
    0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
    0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L,
    0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L,
    0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
    0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L,
    0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L,
    0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L,
    0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L,
    0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L,
    0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L,
    0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 
    0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L,
    0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL,
    0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L,
    0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L,
    0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL,
    0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L,
    0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
    0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL,
    0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L,
    0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L,
    0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL,
    0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL,
    0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L,
    0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL,
    0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L,
    0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L,
    0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL,
    0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L,
    0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL,
    0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL,
    0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L,
    0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL,
    0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L,
    0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L,
    0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL,
    0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
    0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
    0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
    0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
    0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
    0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
    0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
    0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
    };
    #endif 
    u_int32_t
    crc32c(unsigned char *buffer, unsigned int length)
    {
    unsigned int i;
    unsigned long crc32 = ~0L;
    unsigned long result;
    unsigned char byte0,byte1,byte2,byte3; 
    for (i = 0; i < length; i++){
          CRC32C(crc32, buffer[i]);
    }
    result = ~crc32; 
    /* result now holds the negated polynomial remainder;
       * since the table and algorithm is "reflected" [williams95].
       * That is, result has the same value as if we mapped the message
       * to a polynomial, computed the host-bit-order polynomial
       * remainder, performed final negation, then did an end-for-end
       * bit-reversal.
       * Note that a 32-bit bit-reversal is identical to four inplace
       * 8-bit reversals followed by an end-for-end byteswap.
       * In other words, the bytes of each bit are in the right order,
       * but the bytes have been byteswapped. So we now do an explicit
       * byteswap. On a little-endian machine, this byteswap and
       * the final ntohl cancel out and could be elided.
       */ 
    byte0 = result & 0xff;
    byte1 = (result>>8) & 0xff;
    byte2 = (result>>16) & 0xff;
    byte3 = (result>>24) & 0xff; 
    crc32 = ((byte0 << 24) |
               (byte1 << 16) |
               (byte2 << 8) |
               byte3);
    return ( crc32 );
    }
     
    4. 结论 
    Linux内核网络编程中经常会遇到重新计算校验和的问题,这个基本功一定是要掌握的,其实内核中已经提供了大量的校验和计算函数供使用,要尽量使用这些已有函数而不必自己重新编写。
  • 相关阅读:
    根据界面上的button增加、删除、重命名文件夹,名字是数据库下面某一表单的某一列的名字
    打包测试的过程记录
    java中return的作用
    UVA
    UVA
    UVA
    HDU
    HDU
    spring技术详解
    Java对象的生命周期与垃圾回收以及四种引用
  • 原文地址:https://www.cnblogs.com/p2liu/p/6048763.html
Copyright © 2020-2023  润新知