UDP的checksum

只讨论IPv4

1. 概念

简单说，UDP的checksum计算，就是伪首部+UDP首部+UDP数据。伪首部并不是IP首部的一部分，而是由IP首部中的源IP（32 bit）、目的IP（32 bit）、协议号（8 bit），和UDP首部中的UDP长度（16 bit）共同拼凑起来的。

 

2. 实现

《TCP/IP详解》卷1第11章第3节中指出：UDP检验和的基本计算方法与IP首部检验和计算方法相类似（16 bit字的二进制反码和），但是它们之间存在不同的地方。

首先，UDP数据报的长度可以为奇数字节，但是检验和算法是把若干个16 bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。

其次，UDP数据报和TCP段都包含一个12字节长的伪首部，它是为了计算检验和而设置的。伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地（例如，IP没有接受地址不是本主机的数据报，以及IP没有把应传给另一高层的数据报传给UDP）。

 

《TCP/IP详解》卷2第23章第6节第2小节中说明：

在计算UDP检验和时使用以下三个事实：(1)在伪首部中的第三个32 bit字看起来与IP首部中的第三个32bit字类似：两个8 bit值和一个16 bit值。(2)伪首部中三个32 bit值的顺序是无关的。事实上，Internet检验和的计算不依赖于所使用的16 bit值的顺序。(3)在检验和计算中另外再加上一个全0的32 bit字没有任何影响。

 

需要注意的是，并不是所有的UDP都一定包含checksum，这是一个可选填的区域。《RFC 768》中说：假如checksum的运算结果为0，那么传输的checksum将全为1（即用0xFFFF代替0x0000），因为这在补码运算中是等效的。而如果传输的checksum为全0(0x0000)，就说明发送方并没有计算checksum (for debugging or for higher level protocols that don't care)。所以实现代码需要在验证checksum之前，先判断checksum是否存在。

 

BSD 4.4中的实现代码如下：

/* udpcksum.c - udpcksum */
#include 
#include 
#include
/*------------------------------------------------------------------------
 *  udpcksum -  compute a UDP pseudo-header checksum
 *------------------------------------------------------------------------
 */
unsigned short
udpcksum(struct ep *pep, int len)
{
     struct ip *pip = (struct ip *)pep->ep_data;
     struct udp *pudp = (struct udp *)pip->ip_data;
     unsigned short *sptr;
     unsigned long ucksum;
     int  i;
     ucksum = 0;
     sptr = (unsigned short *) &pip->ip_src;
     /* 2*IP_ALEN octets = IP_ALEN shorts... */
     /* they are in net order.  */
     for (i=0; i<IP_ALEN; ++i)
         ucksum += *sptr++;
     sptr = (unsigned short *)pudp;
     ucksum += hs2net(IPT_UDP + len);
     if (len % 2) {
         ((char *)pudp)[len] = 0; /* pad */
         len += 1; /* for the following division */
     }
     len >>= 1; /* convert to length in shorts */
     for (i=0; i<len; ++i)
         ucksum += *sptr++;
     ucksum = (ucksum >> 16) + (ucksum & 0xffff);
     ucksum += (ucksum >> 16);
     return (short)(~ucksum & 0xffff);
}

struct ep 为Ethernet Packet

struct ip 为IP
struct udp 为UDP

 

IP_ALEN  IPv4中一个IP的长度为4字节，所以这里为4

IPT_UDP UDP协议号，0x11 (17)

 

3. 特殊情况

 

在我的vista机器上使用winpcap抓取数据包，通过nslookup查询 www.baidu.com时，发送的UDP包的checksum只计算了伪首部，并未计算UDP首部和数据。经过google，了解到，之所以会有这样的现象，是因为操作系统为了提高效率，将大部分checksum的计算交给了硬件，即网卡(NIC)。本文提供了两种方案来解决这个问题。

 

方案A

事先保存网络字节序的本机IP地址，在处理UDP数据包前先比较源IP和本机IP，相等说明是这是发送的数据包，可以跳过checksum校验，否则说明是收到的数据包，进行checksum校验。IPv4中只是4字节的IP地址比较，代价相当小，可以忽略不计。

优点：实现非常简单，代价小。

缺点：未对发送数据包的checksum验证，若开启混杂模式，且内网有伪装IP攻击，则不能检查。

 

方案B

同时进行伪首部和完整UDP包的checksum校验，其中一项通过则认为该UDP包正确。因多了一次校验，效率会降低，优化算法后，代价也可以忽略不计。

优点：实现较简单，代价小。能够弥补方案A的缺点。

缺点：同时校验两项，存在误码UDP的数据包的checksum有可能与该数据包的伪首部checksum相同。

 

 

4. 参考

《TCP/IP详解》

《RFC 768》

 

 

 

 

============================================================================================================= 

== 下为附文 

RFC 768                                                        J. Postel
                                                                     ISI
                                                          28 August 1980
 
                         User Datagram Protocol
                         ----------------------
Introduction
------------
This User Datagram  Protocol  (UDP)  is  defined  to  make  available  a
datagram   mode  of  packet-switched   computer   communication  in  the
environment  of  an  interconnected  set  of  computer  networks.   This
protocol  assumes  that the Internet  Protocol  (IP)  [1] is used as the
underlying protocol.
This protocol  provides  a procedure  for application  programs  to send
messages  to other programs  with a minimum  of protocol mechanism.  The
protocol  is transaction oriented, and delivery and duplicate protection
are not guaranteed.  Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP) [2].
Format
------
                                    
                  0      7 8     15 16    23 24    31  
                 +--------+--------+--------+--------+ 
                 |     Source      |   Destination   | 
                 |      Port       |      Port       | 
                 +--------+--------+--------+--------+ 
                 |                 |                 | 
                 |     Length      |    Checksum     | 
                 +--------+--------+--------+--------+ 
                 |                                     
                 |          data octets ...            
                 +---------------- ...                
                      User Datagram Header Format
Fields
------
Source Port is an optional field, when meaningful, it indicates the port
of the sending  process,  and may be assumed  to be the port  to which a
reply should  be addressed  in the absence of any other information.  If
not used, a value of zero is inserted.
 
 
Postel                                                          [page 1]
                                                             28 Aug 1980
User Datagram Protocol                                           RFC 768
Fields
 
Destination  Port has a meaning  within  the  context  of  a  particular
internet destination address.
Length  is the length  in octets  of this user datagram  including  this
header  and the data.   (This  means  the minimum value of the length is
eight.)
Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data,  padded  with zero octets  at the end (if  necessary)  to  make  a
multiple of two octets.
The pseudo  header  conceptually prefixed to the UDP header contains the
source  address,  the destination  address,  the protocol,  and the  UDP
length.   This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.
                  0      7 8     15 16    23 24    31 
                 +--------+--------+--------+--------+
                 |          source address           |
                 +--------+--------+--------+--------+
                 |        destination address        |
                 +--------+--------+--------+--------+
                 |  zero  |protocol|   UDP length    |
                 +--------+--------+--------+--------+
If the computed  checksum  is zero,  it is transmitted  as all ones (the
equivalent  in one's complement  arithmetic).   An all zero  transmitted
checksum  value means that the transmitter  generated  no checksum  (for
debugging or for higher level protocols that don't care).
User Interface
--------------
A user interface should allow
  the creation of new receive ports,
  receive  operations  on the receive  ports that return the data octets
  and an indication of source port and source address,
  and an operation  that allows  a datagram  to be sent,  specifying the
  data, source and destination ports and addresses to be sent.
 
 

[page 2]                                                          Postel
28 Aug 1980
RFC 768                                           User Datagram Protocol
                                                            IP Interface
 
IP Interface
-------------
The UDP module  must be able to determine  the  source  and  destination
internet addresses and the protocol field from the internet header.  One
possible  UDP/IP  interface  would return  the whole  internet  datagram
including all of the internet header in response to a receive operation.
Such an interface  would  also allow  the UDP to pass  a  full  internet
datagram  complete  with header  to the IP to send.  The IP would verify
certain fields for consistency and compute the internet header checksum.
Protocol Application
--------------------
The major uses of this protocol is the Internet Name Server [3], and the
Trivial File Transfer [4].
Protocol Number
---------------
This is protocol  17 (21 octal)  when used  in  the  Internet  Protocol.
Other protocol numbers are listed in [5].
References
----------
[1]     Postel,   J.,   "Internet  Protocol,"  RFC 760,  USC/Information
        Sciences Institute, January 1980.
[2]     Postel,    J.,   "Transmission   Control   Protocol,"   RFC 761,
        USC/Information Sciences Institute, January 1980.
[3]     Postel,  J.,  "Internet  Name Server,"  USC/Information Sciences
        Institute, IEN 116, August 1979.
[4]     Sollins,  K.,  "The TFTP Protocol,"  Massachusetts  Institute of
        Technology, IEN 133, January 1980.
[5]     Postel,   J.,   "Assigned   Numbers,"  USC/Information  Sciences
        Institute, RFC 762, January 1980.
 
 
 
 
Postel                                                          [page 3]