網絡字節順序

不多有人關心字節順序（Byte Ordering），由於它真的不多用到。何爲字節順序呢？讓咱們先來看一個例子，假設如今有一個WORD類型的變量，它的值爲0x7788，那麼它在內存中是怎麼存放的呢？
內存中：

                                 低地址                                                                               高地址

0x77

0x88

 

                                高地址                                                                                 低地址

0x77

0x88

       

        事實上，對於不一樣的CPU、不一樣的操做系統，上圖中的兩種字節順序都是可能的。若是像圖上半部分那樣：高字節在前，低字節在後，則這種字節順序稱做爲big-endian；若是像圖下半部分那樣：低字節在前，高字節在後，則這種字節順序稱做爲 little-endian。

常見的CPU、操做系統上使用的字節順序
CPU 操做系統 字節順序
x86 (Intel、AMD等) 全部 little-endian
DEC Alpha 全部 little-endian
HP-PA NT little-endian
HP-PA UNIX big-endian
SUN SPARC 全部 big-endian
MIPS NT little-endian
MIPS UNIX big-endian
PowerPC NT little-endian
PowerPC 非NT big-endian
RS/6000 UNIX big-endian
Motorola m68k 全部 big-endian
        通常來講，咱們不用關心字節順序問題，除非要涉及到跨平臺的通訊和資源共享，好比本章將要介紹的網絡編程（網絡傳輸協議TCP/IP採用的是big- endian）。假設如今要在使用不一樣字節順序的機器之間傳輸和交換數據，那該怎麼辦呢？（一樣的數據，不一樣的機器可能有不一樣的理解，豈不是有悖初衷！）有兩種方法，一種是所有轉換成文原本傳輸，另外一種是雙方都按照某一方的字節順序來傳輸（這時就有一個不一樣字節順序之間的相互轉換問題）。

        Socket編程中常常採用第二種方法。整個傳輸過程以下：發送端將本機的數據轉換成網絡的字節順序（調用API函數htonl或htons），而後發送；接收端收到網絡數據後，先將數據轉換成本機的字節順序（調用API函數ntohl或ntohs），而後再進行其它操做——如此就能保證「會議精神」在通訊雙方的正確傳達了！

這個過程當中用到的幾個API函數：ntohl、htonl、ntohs、htons，名字都差很少，很難區分。可是若是知道了它們的來歷，問題也就不存在了：n是network，網絡的意思；h是host，本地主機的意思。ntohl，就是將32位的u_long類型的數據從網絡字節順序轉換成本機字節順序（htonl的字節順序轉換過程與ntohl相反）；ntohs，就是將16位的u_short類型的數據從網絡字節順序轉換成本機字節順序（htons的字節順序轉換過程與ntohs相反）。 最後還有一個小問題：如何知道本機的字節順序呢？有個很簡單的方法，以下： BOOL IsLittleEndian(void) { WORD wValue = 0x5678; return (*((BYTE*)&wValue) == 0x78); }