校驗程式 深入LwIP（一） 校驗和機制

題圖來自網路

校驗和機制的運算很簡單，計算方法為將校驗範圍內的位元組取反相加，校驗方法為將校驗範圍內的位元組與校驗和相加，如果結果為 1 ，則代表沒有傳輸錯誤發生。

取反相加，相加就相加了，為什麼要取反？取反是因為上文提到的校驗方式：

傳送的訊息欄位為 1011，校驗和取反相加：0100，最終傳送的訊息為 1011 0100

接收端驗證訊息時，將訊息欄位與校驗和字段通通相加，得到：1011 + 0100 = 1111，全部為1，所以沒有錯誤發生。

作為對比，小明同學提出一種不需要取反的方法，傳送端訊息字段相加得到校驗位。接收端只將訊息字段相加，然後和校驗欄位做比較。相當於傳送端節省了取反的開銷，而接收端的開銷從做一次二進位制加法+與全1做比較變成一次比較（資料字段相加後與校驗和字段比較）。那麼兩種方法孰優孰劣？為什麼 tcp/ip 選擇了前者。作者目前的理解是，當時的設計者基於當時的硬體開銷狀況，選擇了目前使用的這套校驗機制。可能現在的開銷情況會有所不同，需要一些更細緻的硬體實現細節和實驗來了解。

顯然校驗和只能發現奇數字錯誤，曾經學過通訊原理的小明同學表示，為什麼不用漢明碼，最小碼距 3 ，可以檢 2 個錯，還能糾 1 個錯。對於在三層以上使用的校驗和來說，檢錯太多可以算得上是多做無功，因為資料已經通過了二層的檢驗機制，去除了那些受到了嚴重錯誤的資料。過大的校驗開銷並不實用。

兩個數相加，可能是 8 位，也可能是 16 位，亦或者是 32 位，總有可能會溢位，這多了一位如何是好。

簡單 把這溢位的 1 加到最低位去

這裡只需要乙個固定的生成/驗證校驗機制，並不是運算。

那如果又溢位了呢？

那就再加到最低位去。

對每個數先取反再相加似乎很麻煩，把每個數加起來再取反好像容易多了，並且兩者是相同的。

1011 取反-> 0100 0110 取反-> 1001 取反相加 1101

直接相加-> 10001 處理溢位 -> 0010 取反 -> 1101 兩者相同

在 ip 資料報首部校驗中，校驗和的寬度為 16bit ，兩個位元組。校驗和本身的長度決定了累加欄位的寬度。ip 首部校驗和計算中，以兩個位元組為單位進行累加。

位元組0 位元組1 + 位元組2 位元組3 + .....+校驗和位元組0 校驗和位元組1.

在校驗和程式中，按照主機位元組序進行計算，即低位址在前，最後將生成的校驗和轉換為網路位元組序。需要轉換因為校驗和的寬度為 16 位，如果校驗只有 1 個位元組，那麼就無所謂位元組序的轉換了。

在將兩個位元組組成 16 位待累加數時，低位址的位元組在高位，這對應於協議中位元組的位置，具體可以參見下方的 lwip 程式實現。

lwip 提供了不只一種校驗的標準實現方式，多種方式可以通過定義在 lwipopts.h 中的巨集定義進行切換。

校驗和相關的函式位於 lwip 根目錄下的 /core/inet_chksum.c 中。inet_chksum 函式為校驗和計算提供統一的入口，接收兩個引數：校驗區域的開始位址以及校驗區域的位元組長度。

inet_chksum 函式中呼叫了真正的校驗和計算函式，我們首先分析 v1.4.1 版本中的校驗和函式：

static u16_t

lwip_standard_chksum(void *dataptr, u16_t len)
if (len > 0) 
//完成了所有數的累加後，開始處理進製。
//溢位的機制是，如果發生了溢位，則無視溢位的 1 ，將 1 加到求和結果中
//lwip 這裡的處理是：不關心每次溢位的產生，將所有數完成求和後，統一將高 16 位（溢位數）加到低 16 位（求和數）
//溢位數就相當於溢位的總次數，每次溢位加1，那麼將溢位次數統一加到結果中即可
acc = (acc >> 16) + (acc & 0x0000fffful);
//在完成上一次操作後，可能又發生了溢位，再執行一次同樣的操作，請問是否可能再發生溢位？
if ((acc & 0xffff0000ul) != 0) 
//將校驗和轉換為網路位元組序
return htons((u16_t)acc);
}

lwip 實現中，通過宣告乙個 32 位的累加數，先將所有的 16bit數累加，得到溢位的總數（累加數的高 16 位），一起加到校驗和結果（低 16 位）中。

這裡存在兩個問題：16bit 數累加時，如果有 2^16 個數累加，那麼會使 32 位數本身發生溢位，但好在目前人類還沒提出這麼長的協議，所有不用擔心 32 位數的溢位問題。

另乙個問題是，如果將溢位數與結果數累加後，有可能再次溢位 1 ，所以在完成第一次高 16 位與低 16 位的運算後，需要再進行一次該運算，第二次運算不可能產生溢位。（可以用最極端的情況考慮下 16bit 全1 與 16bit 全1 進行運算）

v2.0 版本的預設標準校驗和函式使用一種經過優化的校驗和計算函式，在迴圈中一次計算 8位元組，對開始和結束的非 8 位元組對齊位元組，則另行處理。

u16_t

lwip_standard_chksum(const void *dataptr, int len)
ps = (const u16_t *)(const void*)pb;
if (((mem_ptr_t)ps & 3) && len > 1) 
pl = (const u32_t *)(const void*)ps; 
while (len > 7) 
sum = tmp + *pl++; 
if (sum < tmp) 
len -= 8;
} sum = fold_u32t(sum); 
ps = (const u16_t *)pl;
while (len > 1) 
if (len > 0) 
sum += t; 
sum = fold_u32t(sum); //進行溢位處理操作 作用和之前版本的語句相同
sum = fold_u32t(sum); //直接進行兩次高位和低位相加，而不再對是否溢位進行判斷
if (odd) 
return (u16_t)sum;
}

程式的巧妙之處不少，如果校驗和計算位址從奇位址開始，那麼校驗和的計算順序使用主機位元組序，反之則使用網路位元組序。

另外將高 16 位加到低 16 位的操作會直接執行兩次。先前的版本執行第二次相加操作時，會先進行一次判斷。直接執行加法操作可能要比做判斷快一些。

老實說，作者目前對這個函式的原理還只是略懂，這裡暫時不繼續展開了，歡迎有興趣的讀者一起討論。

校驗和的計算和校驗都使用上述的校驗和生成函式完成。在傳送端生成校驗時，校驗和字段先填充為 0 ，計算完成後將結果填入校驗和字段傳送。接收端則直接對所有字段進行校驗和計算，判斷計算結果是否為全 1 。

在一次自環測試中，使用網路助手傳送某些字串可以接收到同樣的字串，完成自環測試。但是某些字串傳送後卻接收不到 。通過 wireshark 抓包發現，字元所在的包收到了，但是因為 udp 校驗和錯誤沒有被作業系統交付給應用層網路除錯助手顯示。

那麼為什麼有些字串可以通過校驗，有些字串卻會有校驗和錯誤，而且發現他們的校驗和總是比正確的校驗和大 1。

通過檢查發現，網路助手對端協議棧使用和 lwip 1.4 版本類似的方法實現校驗和，使用 32 位變數累加 16 位字段的校驗和，但是沒有處理 32 位變數的進製，導致在產生進製的情況下，校驗和比正確的結果小 1，所以在取反後就比正確的結果大 1 。

校驗和的錯誤實現會造成協議棧的錯誤，更糟糕的是這些錯誤似乎「偶爾」發生。

對於硬體 verilog 來說，假設要校驗的字段以資料流的形式輸入，那麼只要不斷將輸入的資料流相加，最後取反即可，也會在後續的文章中更詳細地討論硬體的實現。

十六進製制數相加校驗和計算程式

function getcheckstr astr string aindex integer string varnewstr1,he,oldstr string tj boolean i integer begin i 1 he tj true oldstr copy astr,aindex,l...

關於ip報文校驗和一些思考

首部檢驗和字段是根據ip首部計算的檢驗和碼。它不對首部後面的資料進行計算 為了計算乙份資料報的ip檢驗和，首先需要把檢驗和字段置為0 對首部中每個16bit進行二進位制反碼求和 整個首部看成是由一串16bit的字組成 收到乙份ip資料報後，同樣對首部中每個16bit進行二進位制反碼求和。由於接收方在...

校驗18位身份證號碼（判斷最後一位校驗位和性別）

公民身份號碼是一系列組合碼，由十七位數字本體碼和一位校驗碼組成。1 將身份證號碼前17位數分別乘以不同的係數。從第一位到第十七位的係數分別為 7 9 10 5 8 4 2 1 6 3 7 9 10 5 8 4 2 2 將這17位數字和係數相乘的結果相加 3 用加出來和除以11，看餘數是多少？4 餘數...