OSI 7계층 모델

앞 글에서 통신의 일을 계층으로 나누는 이유를 보았습니다. 그렇다면 어떤 계층들로 나눌까요? 네트워크의 계층을 설명할 때 가장 자주 쓰는 참조 모델이 OSI(open systems interconnection) 7계층 모델입니다. 1984년 국제표준화기구(ISO)가 발표한 이 모델은 통신의 과정을 일곱 계층으로 나누어 각 계층이 맡는 일을 정의합니다. 실제 인터넷이 이 모델대로 만들어진 것은 아니지만, 네트워크를 이해하고 장애를 진단할 때 여전히 가장 널리 쓰이는 틀입니다.

일곱 계층 한눈에 보기

계층은 아래에서 위로 번호를 붙입니다. 영어 문장 "Please Do Not Throw Sausage Pizza Away"의 첫 글자로 1계층부터 차례로 외우기도 합니다.

각 계층이 다루는 데이터의 단위를 PDU(protocol data unit)라고 합니다. 그림처럼 응용 계층은 메시지를, 전송 계층은 TCP라면 세그먼트, UDP라면 데이터그램을, 네트워크 계층은 패킷을, 데이터 링크 계층은 프레임을, 물리 계층은 비트를 다룹니다. 같은 데이터라도 어느 계층에서 보느냐에 따라 부르는 이름이 다릅니다.

아래 세 계층: 비트를 목적지 호스트까지

1계층, 물리 계층

물리 계층(physical layer)은 0과 1의 비트를 전기 신호, 빛, 전파 같은 물리적인 신호로 바꾸어 매체에 실어 보냅니다. UTP 케이블과 광섬유 같은 매체, RJ-45 같은 커넥터, 전압과 주파수, 비트를 신호로 바꾸는 부호화 방식이 이 계층에서 정해집니다. 물리 계층은 비트가 무슨 뜻인지에는 관여하지 않고, 비트를 매체에 싣고 받는 일만 합니다. 받은 신호를 그대로 다시 내보내는 허브와 리피터가 이 계층의 장비입니다.

2계층, 데이터 링크 계층

데이터 링크 계층(data link layer)은 같은 링크에 연결된 장치들 사이에서 데이터를 프레임(frame) 단위로 전달합니다. 비트들을 프레임으로 묶고, 이더넷과 Wi-Fi라면 MAC 주소로 같은 링크 안의 목적지를 가리킵니다. 프레임 끝에는 오류를 찾아내는 FCS(frame check sequence)를 붙이는데, 이더넷은 CRC-32라는 방식으로 이 값을 계산합니다. 파이썬의 zlib.crc32()도 같은 CRC-32 다항식을 씁니다.

import zlib

frame = b"Hello, Ethernet!"
fcs = zlib.crc32(frame)                    # 보내는 쪽이 계산해 프레임 끝에 붙인다
damaged = bytearray(frame)
damaged[4] ^= 0b00000100                   # 전송 중에 비트 하나가 뒤집혔다

print(f"보낸 FCS: {fcs:08x}")
print("그대로 받은 프레임의 검사:", "통과" if zlib.crc32(frame) == fcs else "실패")
print("비트 하나가 바뀐 프레임의 검사:", "통과" if zlib.crc32(bytes(damaged)) == fcs else "실패 -> 버린다")
print("바뀐 바이트:", bytes(damaged)[:6])

보낸 FCS: 26a19a21
그대로 받은 프레임의 검사: 통과
비트 하나가 바뀐 프레임의 검사: 실패 -> 버린다
바뀐 바이트: b'Hellk,'

받는 쪽은 프레임의 CRC를 다시 계산해 붙어 온 FCS와 비교하고, 다르면 프레임을 버립니다. o의 비트 하나가 뒤집혀 k가 된 것만으로 검사가 실패했습니다. 이더넷은 손상된 프레임을 버릴 뿐 다시 보내 달라고 하지 않으며, 잃어버린 데이터를 다시 보내는 일은 위의 전송 계층인 TCP가 맡습니다. 같은 링크 안에서 프레임을 MAC 주소로 전달하는 스위치가 이 계층의 대표 장비입니다.

3계층, 네트워크 계층

네트워크 계층(network layer)은 서로 다른 네트워크 사이의 통신을 맡습니다. IP 주소를 보고 패킷이 목적지까지 어떤 라우터들을 거쳐 갈지 정하는 라우팅(routing)이 핵심이며, 데이터의 단위는 패킷(packet)입니다. 데이터 링크 계층이 같은 링크의 다음 장비까지 프레임을 보낸다면, 네트워크 계층은 여러 링크를 이어 최종 목적지 호스트까지 패킷을 보냅니다. 대표 장비는 라우터입니다.

4계층, 전송 계층: 프로세스 사이의 통신

네트워크 계층이 패킷을 어느 컴퓨터로 보낼지 정한다면, 전송 계층(transport layer)은 그 컴퓨터의 어느 프로그램에 전달할지 정합니다. 출발지와 목적지의 프로세스 사이의 통신을 맡는 것입니다. 이때 포트 번호(port number)를 쓰며, HTTP는 80번, HTTPS는 443번, SSH는 22번을 기본으로 씁니다. 포트 번호는 IP 주소, 전송 프로토콜과 함께 통신의 끝점을 가리킵니다.

대표적인 전송 프로토콜은 둘입니다. TCP는 연결을 맺고, 보낸 바이트를 순서대로 빠짐없이 전달해 주는 바이트 스트림을 제공하며 웹, 이메일, 파일 전송에 쓰입니다. UDP는 연결 없이 데이터그램을 하나씩 보낼 뿐 순서나 재전송을 보장하지 않으며, DNS와 실시간 영상, 게임에 쓰입니다. UDP 위에서 신뢰성을 직접 구현하는 QUIC도 있습니다. TCP가 바이트를 빠짐없이 전달해 준다고 해서 응용 프로그램의 요청이 성공했다는 뜻은 아니라는 점에 주의해야 합니다.

위 세 계층: 세션, 표현, 응용

세션 계층(session layer)은 두 시스템 사이의 대화를 시작하고, 유지하고, 끝내는 일을 맡습니다. 표현 계층(presentation layer)은 데이터의 형식을 바꾸고, 압축하고, 암호화하는 일을 맡는 것으로 설명합니다. 문자 인코딩 UTF-8, 압축 gzip, 데이터 직렬화 형식 JSON이 표현 계층의 예로 자주 거론됩니다.

응용 계층(application layer)은 사용자와 가장 가까운 계층으로, HTTP, DNS, SMTP, SSH처럼 실제 서비스를 제공하는 프로토콜이 여기에 속합니다. 오늘날의 인터넷에서 세션과 표현 계층은 따로 구현되는 일이 드물고, 대부분 응용 프로그램과 라이브러리 안에 섞여 있습니다. HTTP의 쿠키가 세션을 관리하고, 압축과 문자 인코딩은 HTTP 헤더로 정하며, 암호화는 TLS 라이브러리가 맡는 식입니다.

여러 계층에 걸치는 것도 있습니다. 이더넷과 Wi-Fi의 표준은 신호를 만드는 방식과 프레임의 형식을 함께 정하므로 1계층과 2계층에 걸쳐 있습니다. IP 주소로 MAC 주소를 알아내는 ARP는 2계층과 3계층 사이를 이어 주는 일을 합니다.

OSI 모델의 한계와 쓸모

OSI 모델이 발표된 1984년에는 이미 TCP/IP가 인터넷에서 널리 쓰이고 있었고, 실제로 표준이 된 것은 TCP/IP였습니다. 그래서 OSI 모델은 인터넷의 프로토콜과 딱 맞아떨어지지 않습니다. 세션과 표현 계층은 따로 보이지 않고, TLS를 몇 계층으로 볼지도 설명하는 사람마다 다릅니다. 실제 인터넷의 구조는 다음 글의 TCP/IP 모델이 더 잘 나타냅니다.

그럼에도 OSI 모델은 여전히 쓸모가 있습니다. 무엇보다 공통의 언어가 됩니다. L4 로드 밸런서는 IP 주소와 포트, 전송 프로토콜을 보고 트래픽을 나누고, L7 로드 밸런서는 HTTP의 URL과 헤더, 쿠키까지 보고 나눈다는 식으로, 계층의 번호만으로 장비가 무엇을 보는지 전할 수 있습니다. 다만 L7 로드 밸런서가 HTTPS의 내용을 보려면 TLS를 그 장비에서 풀어야 합니다. 또 "이 문제는 몇 계층에서 생긴 것인가"라는 질문은 장애를 진단하는 기본 틀이 됩니다.

더 깊이: OSI에서 지금도 쓰이는 것

OSI 작업은 참조 모델만 만드는 일이 아니라, 각 계층에 맞춘 프로토콜까지 표준으로 정하는 일이었습니다. 인터넷에서는 결국 TCP/IP가 쓰이게 되었지만, OSI 쪽에서 만든 표준 가운데 몇은 지금도 매일 쓰입니다. 대표적인 것이 HTTPS의 인증서 형식인 X.509입니다. ITU-T X.509의 정식 제목은 "Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks"로, OSI의 디렉터리 서비스인 X.500 시리즈의 한 부분입니다.

그래서 인증서의 주체 이름은 CN=example.com, O=Example, C=KR처럼 X.500의 구별 이름(distinguished name) 형식으로 적힙니다. 사내 계정 관리에 흔히 쓰는 LDAP도 RFC 4511의 요약이 밝히듯 X.500의 데이터 모델과 서비스 모델을 따르는 디렉터리에 접근하는 프로토콜입니다. 라우팅에서는 IS-IS가 그렇습니다. OSI의 도메인 내부 라우팅 프로토콜로 만들어진 IS-IS는 RFC 1195에서 IP 경로도 함께 다루도록 확장되어 AS 안의 라우팅 프로토콜로 쓰이는데, OSI에서 온 프로토콜이라 지금도 IP 패킷에 실리지 않고 데이터 링크 계층 위에서 바로 오갑니다.

정리

• OSI 모델은 통신을 물리, 데이터 링크, 네트워크, 전송, 세션, 표현, 응용의 일곱 계층으로 나누며, 계층마다 비트, 프레임, 패킷, 세그먼트, 메시지 같은 데이터 단위를 다룹니다.
• 물리 계층은 비트를 신호로 바꾸고, 데이터 링크 계층은 같은 링크 안에서 프레임을 전달하며 FCS로 손상된 프레임을 버리고, 네트워크 계층은 IP 주소로 여러 링크를 이어 목적지 호스트까지 패킷을 보냅니다.
• 전송 계층은 포트 번호로 프로세스를 가리키며, TCP는 순서 있는 바이트 스트림을, UDP는 데이터그램을 제공합니다.
• 세션과 표현 계층의 일은 오늘날 대부분 응용 프로그램과 라이브러리 안에서 이루어집니다.
• OSI 모델은 인터넷의 실제 구조와 다르지만, L4와 L7처럼 장비와 문제를 설명하는 공통의 언어로 쓰입니다.

연습 문제

1. TCP는 성공했는데 404

클라이언트가 서버와 TCP 연결을 맺고 HTTP 응답 404 Not Found를 받았습니다. "TCP는 신뢰성이 있으니 요청한 파일도 제대로 받았을 것"이라는 말은 맞나요? 전송 계층과 응용 계층이 각각 무엇을 했는지 나누어 설명하세요.

2. 기능으로 계층 찾기

다음 일들은 각각 어느 계층의 일인가요? 첫째, HTTP 요청의 URL을 보고 어느 백엔드 서버로 보낼지 고른다. 둘째, 목적지 IP 주소를 보고 다음 라우터를 고른다. 셋째, 다음 라우터의 MAC 주소를 프레임의 목적지로 적는다. 넷째, 목적지 포트 443을 보고 받은 데이터를 웹 서버 프로세스에 넘긴다.

3. CRC가 막는 것과 막지 못하는 것

본문의 CRC 예제처럼 이더넷은 손상된 프레임을 찾아 버립니다. 그렇다면 이더넷만으로 데이터가 빠짐없이 전달된다고 할 수 있나요? 버려진 프레임의 데이터는 어떻게 되나요?

다음 글 TCP/IP 4계층 모델에서는 실제 인터넷이 쓰는 TCP/IP 모델의 네 계층과, OSI 모델과의 대응 관계를 살펴봅니다.