Big endian и Little endian для IPv4 и IPv6
Подскажите пожалуйста, правильно ли я понимаю:
Big endian и Little endian - различаются между собой собственно просто порядком байт. Но, я вдруг запутался немного, а в каких именно байтах имеет значение этот порядок ?
Ну вот к примеру возьмем стандартную форму записи IPv4 уже в двоичном виде - он будет занимать 4 байта. В данном случае порядок байт будет применен именно в целом к этим 4 байтам?
Или же к 4ем октетам по отдельности ? Если так, то прямой и обратный порядок для IPv4 не имеет значения, так как каждый октет состоит ровно из одного байта. А вот в случае с IPv6 прямой и обратный порядок будет иметь значение - так как ipv6 состоит из 8 хекстетов по два байта каждый.
Я правильно понимаю ?
Ответы (3 шт):
Вы собственно сами ответили на свой вопрос - применять понятие big/little к одному байту нет смысла. Поэтому, оно примеряется к многобайтовым данным.
Так сложилось исторически, что по сети обычно бегают данные в big endian. И когда заполняются всякие tcp заголовки, то там порядок байт "прямой"
Но, я вдруг запутался немного, а в каких именно байтах имеет значение этот порядок ?
это имеет отношения к "полям". Например, какой-то размер или порядковый номер.
А вот в случае с IPv6 прямой и обратный порядок будет иметь значение - так как ipv6 состоит из 8 хекстетов по два байта каждый.
порядок в TCP/UDP заголовках будет "прямой".
А вот как это все будет сохранятся в пользовательском приложении - это другое дело. С большой вероятностью ipv6 будет сохранятся просто как последовательность байт, а вот ipv4 - как 4байтовый int/DWORD. И на x86 порядок в результате будет обратный.
Нет, вы совсем не правильно поняли. Big endian и Little endian (и совмещенные варианты) определяет, как та или иная аппаратная архитектура интерпретирует хранение разрядов в памяти для арифметических типов данных - integer, floating-point, fixed-point и т.п. Big endian - это когда подразумевается, что в байтах с меньшим адресом хранятся старшие разряды числа, а Little endian - что младшие. Адреса IP (4 или 6) не являются арифметическим типом данных. Big / Little endian никак на них не влияет, и они всегда должны интерпретироваться, как то описано в соответствующем RFC.
Смотрите:
temp_int1 = 0x2a03; //10755
std::cout << "-----------------------------------------------------------------------------------------------" << std::endl;
std::cout << (unsigned int)(((unsigned char*)&temp_int1)[0]) << ":";
std::cout << (unsigned int)(((unsigned char*)&temp_int1)[1]) << ":";
std::cout << (unsigned int)(((unsigned char*)&temp_int1)[2]) << ":";
std::cout << (unsigned int)(((unsigned char*)&temp_int1)[3]) << ":";
std::cout << std::endl;
std::cout << "-----------------------------------------------------------------------------------------------" << std::endl;
std::cout << (unsigned int)(((unsigned short*)&temp_int1)[0]);
Вывод на консоль соответвенно будет:
3:42:0:0:
10755:
То есть я взял и в int поместил число 10755 или 0x2a03 в hex`е.
А потом вывел значение каждого байта с 0 по 4. Видно, что значения байт вывелись сначала младший байт, потом старший. То есть в little endian.
Теперь!! Я беру текстовое представление ipv6:"2a03:2880:f10a:83:face:b00c:0:25de" c первым хекстетом 2a03 совпадающиv с тем, что я присваивал в int и вызываю функцию inet_pton:
char my_char_ipv6_ver1[] = "2a03:2880:f10a:83:face:b00c:0:25de";
int family_protocol_ = 23; //семейство протоколов. 2 - это для ipv4; 23 - это для ipv6;
char my_transform_buffer_ipv6_ver1[16];
inet_pton(family_protocol_, my_char_ipv6_ver1, my_transform_buffer_ipv6_ver1);
//Сюда my_transform_buffer_ipv6_ver1 - функция inet_pton поместила преобразованный ipv6 из текстового представления в бинарный вид.
std::cout << (unsigned int)(((unsigned char*)&my_transform_buffer_ipv6_ver1)[0]) << ":";
std::cout << (unsigned int)(((unsigned char*)&my_transform_buffer_ipv6_ver1)[1]) << ":";
Вывод консоли:
42:3:
То есть выводим первые два байта первого хекстета 2a03 и видим, что значения поменялись!!! Теперь в первом байте указано значение 42, а во втором 3. То есть в соответствии с Big Endian.