Microsoft MVP성태의 닷넷 이야기
기타: 84. 직렬화로 설명하는 Little/Big Endian [링크 복사], [링크+제목 복사],
조회: 13340
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)

직렬화로 설명하는 Little/Big Endian

아래와 같은 질문이 있는데,

c# socket 통신할때 빅엔디언으로 바꿔줘야 하나요?
; https://www.sysnet.pe.kr/3/0/5759

마침 한 번도 엔디언 관련한 이야기를 꺼낸 적이 없어서 이렇게 글로 남깁니다. ^^




걸리버 여행기에서 유래한 엔디언(Endianness)이라는 단어는 컴퓨터 업계에서는 바이트의 배열 방법을 일컫습니다.

예를 들어 볼까요? '0', '1', '2'라는 문자 데이터는 0x30, 0x31, 0x32에 해당합니다. 그럼, 이 값을 "파일"에 저장한다고 가정해 보겠습니다. 딱히 이에 대해서는 생각할 여지가 없이 그대로 데이터를 저장할 것입니다.

// text.txt에 저장된 바이트

0x30 0x31 0x32

문제는, 이러한 데이터의 크기가 단순히 1바이트 짜리가 아닌, 2바이트 이상이 되었을 때 발생합니다. 가령, 숫자 24592는 바이트로 바뀌어 16진수로 표현된 경우에는 0x6010이 됩니다. 그리고 이 값을 파일에 저장하기 위해서는 2가지 방법이 가능합니다.

[숫자 0x6010을 저장하는 방법]

1) 숫자의 상위 바이트 영역을 먼저 저장 (Big Endian)
0x60 0x10

2) 숫자의 하위 바이트 영역을 먼저 저장 (Little Endian)
0x10 0x60

걸리버 여행기의 소인국 사람들의 논쟁을 보면서 뭐 저런 걸로 다 싸우냐고 할 텐데요, 재미있게도 소설이 아닌 현실에서도 (싸움까지는 안 했겠지만) 저런 식의 결정 장애를 겪고 있는 사람들이 정말 있었던 것입니다.




유명한 Intel 아키텍처에서는 Little Endian 방식으로 바이트를 배열합니다. 그래서 숫자 24592를 Intel CPU가 채택된 시스템에서 메모리에 저장하면 0x10, 0x60과 같이 저장이 됩니다. 비주얼 스튜디오 + C#을 이용해 실제로 다음과 같은 코드를,

internal class Program
{
    static unsafe void Main(string[] args)
    {
        Console.WriteLine(BitConverter.IsLittleEndian);

        short x = 24592;
        IntPtr ptr = new IntPtr(&x);

        Console.WriteLine($"{ptr:x16}");
    }
}

디버깅 모드로 실행(F5)하면 메모리 창을 이용해 저장 순서를 확인할 수 있습니다.

endian_byte_order_1.png

보는 바와 같이 변수의 메모리 주소(위의 경우 0xfd1f17e5e8) 위치에 0x10, 0x60 순으로 2바이트 short 데이터가 저장돼 있습니다.

반면 PowerPC 아키텍처에서는 그 반대로 Big Endian을 채택했으므로 동일한 숫자를 메모리에 저장할 때 0x60, 0x10으로 저장합니다.

그런데, 사실 CPU로 인해 달라지는 사례가 유명해서 그렇지, 엄밀히 엔디언은 CPU에 종속된 단어는 아닙니다. 제가 이 글의 처음에 쓴 것처럼, 2바이트 이상의 데이터 타입을 특정 미디어에 저장할 때, 즉 I/O 장치에 전송할 때 어디에서나 발생할 수 있는 선택의 문제입니다.

가령, 파일로 데이터를 저장할 때를 예로 들어보겠습니다. C#으로 다음과 같이 숫자를 저장하면,

internal class Program
{
    static unsafe void Main(string[] args)
    {
        short x = 0x6010; // 10진수 24592
        byte[] buffer = BitConverter.GetBytes(x);
        File.WriteAllBytes("test_little.bin", buffer);
    }
}

/* 위의 코드는 이렇게 명시적으로 바이트 순서를 지정하는 것과 동일
    { 
        byte upper = (byte)((x & 0xFF00) >> 8);
        byte lower = (byte)(x & 0xFF);
        byte[] buffer = new byte[] { lower, upper };
        File.WriteAllBytes("test_little.bin", buffer);
    }
*/

test_little.bin 파일에는 0x10, 0x60과 같이 저장되는 반면 동일한 숫자를 다음과 같이 저장하면,

byte upper = (byte)((x & 0xFF00) >> 8);
byte lower = (byte)(x & 0xFF);
byte[] buffer = new byte[] { upper, lower };
File.WriteAllBytes("test_big.bin", buffer);

0x60, 0x10 순으로 바이트가 배열됩니다. 데이터 저장 시의 엔디언 선택이 중요한 이유는, 그 데이터를 다시 로드할 때에도 순서를 맞춰야 하기 때문입니다. 만약, Little endian 방식으로 숫자 24592를 저장한 파일을 PowerPC 계열에서 로드한다면 엉뚱하게 4192로 읽히게 됩니다.

따라서 전혀 다른 아키텍처에서 사용되는 파일을 다룬다면 데이터 저장에서부터 엔디언 방식을 합의해야만 합니다. 참고로, C#의 경우 현재 실행 중인 환경의 엔디언 종류를 BitConverter.IsLittleEndian으로 알 수 있습니다.

// 닷넷의 지원 범위가 x86/x64와 ARM32/64이기 때문에 대부분의 경우 True를 반환
Console.WriteLine(BitConverter.IsLittleEndian);

이렇게 CPU 아키텍처와 독립적으로 응용 프로그램 수준에서 엔디언을 정해야 하는 것은 당연할 수 있습니다. 가령 윈도우에서 실행하는 아래아 한글이 파일을 Little 엔디언으로 저장하면, 이후 PowerPC 아키텍처를 지원하는 운영체제에서 실행하는 아래아 한글 파일을 만들게 된다면 반드시 데이터를 Little 엔디언으로 읽어내야 합니다.

이러한 예로, BMP나 GIF 파일은 little 엔디언을 따르지만 JPG 포맷은 big 엔디언을 따릅니다.

그런데, 단순히 응용 프로그램 하나로 해결될 문제가 아닌 사례가 있습니다. 바로 네트워크 통신입니다.

일례로, TCP 헤더의 포트 번호는 2바이트 숫자인데, 이 값은 단순히 응용 프로그램에서만 쓰이지 않고 라우터 등의 네트워크 통신 장비에서도 인식을 해야 합니다. 따라서, 이에 대해서는 전체 산업계에서 합의를 봐야 하고 결국 Big Endian으로 직렬화하자고 정의를 한 것입니다.

또한, 이러한 합의는 단순히 네트워크 프로토콜의 헤더에만 국한하지 않고 TCP/IP 응용 프로그램 내에서의 데이터 송/수신도 Big Endian으로 하는 것이 관례처럼 되었습니다. 아마도 초창기 네트워크가 운영되던 시절에는 서버 급에서 Big Endian을 채택한 시스템이 많아 자연스럽게 Big Endian으로 합의했을 것입니다.

그렇다고 모든 네트워크 통신이 Big 엔디언은 아닙니다. TCP/IP와는 달리 USB나 PCI 통신은 Little 엔디언을 따릅니다.

물론, 이러한 산업 표준에서의 관례와는 별개로 응용 프로그램 데이터는 여러분들이 마음대로 서버 프로그램과 함께 정의하면 그만입니다. 즉, 서버와 합의만 할 수 있다면 소켓으로 송/수신하는 데이터만큼은 그냥 Little 엔디언으로 처리해도 무방합니다.

이 정도면 대충 설명이 되었을 것 같고, 그 외에도 Middle Endian 등의 용어들도 있지만 그냥 있다는 정도만 알아두셔도 될 듯합니다.

여기까지... 이제 위의 설명을 염두에 두고 "c# socket 통신할때 빅엔디언으로 바꿔줘야 하나요?" 질문을 다시 볼까요?

1) 네트워크 통신에서 빅엔디언으로 약속된걸로 알고있는데요.
2) 인텔/amd 환경에서 데이터 보낼때 항상 빅엔디언으로 바꾸는 코드를 넣어줘야 하나요?
3) 아니면 내부적으로 알아서 빅엔디언으로 변환해서 보내고
4) 받을때에는 환경에 맞춰서 알아서 바이트 정렬을 해주나요?

이 글의 내용을 충분히 이해했다면 다음과 같은 답변으로 정리가 될 것입니다.

1) 응용 프로그램이 전송하는 데이터 자체가 언제나 100% 빅엔디언이라고 장담할 수는 없습니다.
2) 응용 프로그램의 데이터가 빅엔디언으로 합의되었다면 Intel/AMD 환경에서는 항상 엔디언 변환 코드를 넣어야 합니다.
3) 내부적으로 알아서 변환하지는 않습니다.
4) 응용 프로그램에서, (예를 들어 TCP의 경우) Receive로 수신한 바이트는 합의를 빅엔디언으로 했다면 자신의 환경에 맞게 바이트 정렬을 바꿔야 합니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/21/2022]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 91  92  93  94  95  96  97  98  99  100  101  102  [103]  104  105  ...
NoWriterDateCnt.TitleFile(s)
11358정성태11/15/201726693사물인터넷: 9. Visual Studio 2017에서 Raspberry Pi C++ 응용 프로그램 제작 [1]
11357정성태11/15/201727185개발 환경 구성: 336. 윈도우 10 Bash 쉘에서 C++ 컴파일하는 방법
11356정성태11/15/201728774사물인터넷: 8. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스 + 키보드로 쓰는 방법 [4]
11355정성태11/15/201724505사물인터넷: 7. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스로 쓰는 방법 [2]파일 다운로드2
11354정성태11/14/201728722사물인터넷: 6. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 키보드로 쓰는 방법 [8]
11353정성태11/14/201725897사물인터넷: 5. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 이더넷 카드로 쓰는 방법 [1]
11352정성태11/14/201721986사물인터넷: 4. Samba를 이용해 윈도우와 Raspberry Pi간의 파일 교환 [1]
11351정성태11/7/201725236.NET Framework: 698. C# 컴파일러 대신 직접 구현하는 비동기(async/await) 코드 [6]파일 다운로드1
11350정성태11/1/201721217디버깅 기술: 108. windbg 분석 사례 - Redis 서버로의 호출을 기다리면서 hang 현상 발생
11349정성태10/31/201721705디버깅 기술: 107. windbg - x64 SOS 확장의 !clrstack 명령어가 출력하는 Child SP 값의 의미 [1]파일 다운로드1
11348정성태10/31/201718158디버깅 기술: 106. windbg - x64 역어셈블 코드에서 닷넷 메서드 호출의 인자를 확인하는 방법
11347정성태10/28/201721768오류 유형: 424. Visual Studio - "클래스 다이어그램 보기" 시 "작업을 완료할 수 없습니다. 해당 인터페이스를 지원하지 않습니다." 오류 발생
11346정성태10/25/201718339오류 유형: 423. Windows Server 2003 - The client-side extension could not remove user policy settings for 'Default Domain Policy {...}' (0x8007000d)
11338정성태10/25/201716737.NET Framework: 697. windbg - SOS DumpMT의 "BaseSize", "ComponentSize" 값에 대한 의미파일 다운로드1
11337정성태10/24/201718881.NET Framework: 696. windbg - SOS DumpClass/DumpMT의 "Vtable Slots", "Total Method Slots", "Slots in VTable" 값에 대한 의미파일 다운로드1
11336정성태10/20/201719654.NET Framework: 695. windbg - .NET string의 x86/x64 메모리 할당 구조
11335정성태10/18/201718661.NET Framework: 694. 닷넷 - <Module> 클래스의 용도
11334정성태10/18/201719692디버깅 기술: 105. windbg - k 명령어와 !clrstack을 조합한 호출 스택을 얻는 방법
11333정성태10/17/201718862오류 유형: 422. 윈도우 업데이트 - Code 9C48 Windows update encountered an unknown error.
11332정성태10/17/201719819디버깅 기술: 104. .NET Profiler + 디버거 연결 + .NET Exceptions = cpu high
11331정성태10/16/201718148디버깅 기술: 103. windbg - .NET 4.0 이상의 환경에서 모든 DLL에 대한 심벌 파일을 로드하는 파이썬 스크립트
11330정성태10/16/201717424디버깅 기술: 102. windbg - .NET 4.0 이상의 환경에서 DLL의 심벌 파일 로드 방법 [1]
11329정성태10/15/201721593.NET Framework: 693. C# - 오피스 엑셀 97-2003 .xls 파일에 대해 32비트/64비트 상관없이 접근 방법파일 다운로드1
11328정성태10/15/201724497.NET Framework: 692. C# - 하나의 바이너리로 환경에 맞게 32비트/64비트 EXE를 실행하는 방법파일 다운로드1
11327정성태10/15/201718257.NET Framework: 691. AssemblyName을 .csproj에서 바꾼 경우 빌드 오류 발생하는 문제파일 다운로드1
11326정성태10/15/201718547.NET Framework: 690. coreclr 소스코드로 알아보는 .NET 4.0의 모듈 로딩 함수 [1]
... 91  92  93  94  95  96  97  98  99  100  101  102  [103]  104  105  ...