Microsoft MVP성태의 닷넷 이야기
기타: 84. 직렬화로 설명하는 Little/Big Endian [링크 복사], [링크+제목 복사]
조회: 3975
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13568정성태2/27/2024220닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/2024214오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/2024211오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/2024371닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/2024912Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20241007디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/2024962오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20241072닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20241106디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20241491오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20241185닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241069Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241118Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20241186닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/2024978VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241105닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241039닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20241148닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20241208Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20241492개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20241305개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20241132개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241069Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/2024998닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241034오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...