[network] OSI 7 layer

오늘 아마도 OSI 7대 대한 질문을 받았다.(아마도) 예전에 내가 다른 친구들에게 설명까지 했던 내용인데 요 몇년사이에 까맣게 잊어버리다니.. 어휴 정말 이러고도 콤푸타쟁이라고 하고 다니냐 싶은 생각이 절로든다.

질문은 이랬다.

 

Q. 브라우저에서 www.naver.com  을 입력하고 브라우저가 네이버 웹 화면을 띄우기까지 과정을 설명해보세요

A. DNS  www.naver.com  이라는 주소를 resolve하고 해당 ip로 웹 요청을 날립니다. 4층-transport layer에서 3-way handshake가 발생하고, key 교환하고 뭐 어쩌고 저쩌고 했던것 같다. <- 다시 생각해보면 틀린거같은데.. 

그래서 다시 정리하는 김에 OSI 7 Layer를 그냥 정리하기보다는 네이버, 카카오톡 같은 예시를 들어서 한번 정리해보겠다.

 

1. 브라우저 단에서 요청

 우리는 DNS(Domain Name Service) 라는 기능을 정말 익숙하게 사용하고있다. 그게 뭔지 잘 모르는 사람도 말이다. 사실 기술이라는 것들이 원래 그렇다. 우리가 늘상 엘리베이터를 이용하지만, 전자공학이나 컴퓨터 공학을 전공하지 않은 사람이 3대 이상 엘리베이터를 조작하는 로직에 대해 관심을 가지고 있을까?

 

1-1. DNS

 우리가 브라우저 주소창에서 naver.com 를 입력하면 어떤 일이 발생할까? 우선은 이 naver.com 이라는게 어떤 의미인지부터 해석을 해야할 것이다. 그럼 이 해석을 어떻게 할까? 이때 바로 DNS 서버가 관여한다.

브라우저 주소창

 아무튼, 이 DNS 라는 것은 Domain Name 이라는 것을 IP와 짝을지어주는 기능을 한다. 다음을 보자

nslookup 이라는 이 명령은 dns를 resolve 해주는 명령어다. 입력 인자로 사이트 주소를 주고 있다. 이때 이 주소가 바로 domain name이다.

Domain Name	IPv4	IPv6
naver.com	223.130.200.219 223.130.200.236 223.130.192.247 223.130.192.248	64:ff9b::df82:c8ec 64:ff9b::df82:c8db 64:ff9b::df82:c0f7 64:ff9b::df82:c0f8
dcinside.com	121.125.60.151	64:ff9b::797d:3c97

* 네이버에 IP가 많은 이유는 가용성(원활한 서비스 제공)확보를 위해 Load Balancer를 두었기 때문일 것이다.

자 그럼 이런 기능은 누가 해주는걸까? 바로 DNS 서버가 해 준다. 통신사들이나 검색엔진은 사용자를 위해 이러한 DNS 서버를 가지고 있고, DNS를 제공한다. 또는 규모가 어느정도 큰 기업들은 자체적으로 DNS 서버를 운용하기도 한다.

 

윈도우 운영체제에서 IP 설정을 하다보면 위와 같은 창을 볼 수 있다. IP주소 설정칸 밑에 DNS 서버 주소 사용 칸이보이는가? 이 칸이 바로 DNS 서버 주소를 설정하는 공간이다.

자 보통은 기본 DNS에 8.8.8.8, 보조 DNS에 8.8.4.4를 설정할 것이다. 이것이 무엇일까? 바로 구글 DNS 서버다. 인터넷 브라우저를 켜서 8.8.8.8을 입력해보라.

위 그림과 같은 DNS 서비스를 볼 수 있다.

 

자 정리해보면 다음과 같다.

1. 브라우저 단에서 어떤 주소 ex)www.naver.com 를 입력하면 브라우저는 DNS 서버에 질의하는 구나!
2. DNS서버로 부터 수신받은 IP 주소로 이제 통신 요청을 하는구나!

 DNS 를 왜 사용하는 걸까? 편리하기 때문이다. 여러분은 12자리의 IPv4 주소나 32자리의 16진수로 구성된 IPv6주소를 외우는게 쉽겠는가? 아니면 그냥 naver.com 이라는 주소를 외우는게 쉽겠는가?

 

1-2. DNS 확인하기

 

이런 DNS 서버 주소는 컴퓨터 시스템의 어딘가에 기록해 관리된다.

linux : /etc/resolv.conf
windows : /HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

* 어떤 블로그에는 %systemroot%/system32/etc/hosts 파일에 기록된다고 하는 곳도 있는데 이는 틀린 설명이다.

 

리눅스 시스템에서는 resolvectl 명령 또는 /etc/resolv.conf 를 사용함으로써 알 수 있다. 현재 아래 리눅스 시스템은 wsl이고, dns 서버 주소가 사설 ip 대역인것 으로 봐서 아마 호스트로 passthrough 되어있지 않을까 하는 생각이 든다.

 

windows 에서는 다음 방법으로 확인 가능하다.

ipconfig /all 명령을 사용하거나 또는 

레지스트리의 해당 NIC 부분을 확인하면 된다. 현재 IP 설정이 Static이라면 NameServer에 기록되겠지만 DHCP이므로 DhcpNameServer에 기록되었다. 192.168.100.129는.. 핸드폰에서 쓰는 DNS 서버인가..? (참고로 필자는 현재 스벅에서 핫스팟을 쓰고있다. 내통신사 KT :) )

 

1-3. DNS 캐시

 소소한 최적화 기법으로 브라우저는 OS 에게 요청 하기전에 스스로 DNS 캐시정보가 있는지 탐색한다. DNS 서버 정보가 있으면 그대로 query하고, 그게 아니라면 OS에게 요청한다. 

 

2. OSI 7 Layer

 DNS 서버로부터 내가 접속하기를 원하는 도메인 서버의 IP 정보를 응답받았다. 그 뒤에는 어떤 과정이 발생할까?OSI 1-2 계층은 너무 로우 레벨이기 때문에 크게 얘기할게 없다. 그래도 한번 얘기를 해보자

 먼저 OSI 7 레이어에 대해 간략하게 정리해보겠다.

layer	name	기능
1	Physical	전기 신호 전달 0,1
2	Data Link	MAC 주소 기반, Ethernet Protocol
3	Network	ARP(Address Resolv Protocol, IP <> MAC 간 변환)
4	Transport	Port, 3-way handshake
5	Session	세션 관리, 유지
6	Presentaition	TLS 암호화, 키교환, 데이터 인코딩&디코딩
7	Application	실제 HTTP 요청 발생

필자는 질질멘토님에게 Please Do Not Touch Stive's Pet Elegator 라고 배웠다.

 브라우저가 어떤 IP에게 web request 요청을 날리는 것은 7계층 application layer의 작업이다. 그런데 우리는 어떤 네트워크와 통신을 하기위해서는 가장 먼저 3-way handshake가 이루어 진다고 배웠다. 대관절 이건 무슨말이란 말인가? 제대로 한번 생각해보면 사실 그렇다. 

 

OSI 7 Layer

 

 실제로는 web request가 발생하기전에 4계층간의 3-way handshake가 먼저 발생한다고 보는 것이 옳다. 즉 최초 통신은 다음과 같은 형태가 되는 것이다. 그리고 한번 데이터 통신이 발생할때는 무조건 캡슐화와 역캡슐화를 수행하고 4-3-2-1, 1-2-3-4와 같은 순서로 수행하게 이루어져 있다.

[STEP 1] 클라이언트 → 서버 (SYN 전송)
- 계층 흐름:
   → [7] - [6] - [5] ❌ (없음, TCP 핸드쉐이크 우선)
   → [4] TCP SYN → [3] IP 패킷 생성
   → [2] MAC 프레임 생성
   → [1] 전기 신호 전송

[STEP 2] 서버 측 수신
- 수신 흐름:
    → [1] 신호 수신
    → [2] 프레임 수신 및 MAC 확인
    → [3] IP 확인
    → [4] TCP SYN 파싱 

[STEP 3] 서버 → 클라이언트 (SYN-ACK 응답)
- 전송 흐름:
    → [4] TCP SYN-ACK 생성
    → [3] IP 설정
    → [2] 프레임 생성
    → [1] 신호로 전송

[STEP 4] 클라이언트 측 수신
- 수신 흐름: [1] → [2] → [3] → [4] (SYN-ACK 확인)

[STEP 5] 클라이언트 → 서버 (ACK 전송)
- 전송 흐름: [4] ACK 생성 → [3] IP → [2] MAC → [1] 전송

[STEP 6] 서버 수신: [1] → [2] → [3] → [4]

자 이렇게 3-way handshake가 완료되고 나서 다시 암호화를 위한 알고리즘 협상과 key 교환이 이루어진다. 그러면 또다시 6-5-4-3-2-1 과같은 지루한 과정이 펼쳐진다.

암호화 알고리즘과 key 교환 까지 이루어지고 나면 이제 정말 7레이어의 완전한 https 프로토콜 통신이 이루어지는 것이다.

 

3. 키교환 이후 통신 흐름

 자 이제 키교환에 성공했다. 그럼 정말로 http get method를 사용해 naver.com 의 메인화면의 컨텐츠를 받아올 수 있다. 이를 순서대로 나타내보면 다음과 같다.

 

1. 클라이언트 측 브라우저 요청 (캡슐화)

7. Application	웹 요청 생성	GET / HTTP/1.1\r\nHost: naver.com
6. Presentation	암호화	TLS 세션 키로 암호화
5. Session	TLS 세션 유지	세션 ID 재사용, 복호화 상태 유지
4. Transport	TCP 세그먼트 생성	Port 443로 세그먼트 전송
3. Network	IP 패킷 생성	클라이언트 IP → 1.1.1.1
2. Data Link	MAC 프레임	MAC 주소 기반 전송 (라우터 방향)
1. Physical	신호 전송	케이블 or 무선 전송 (전기/전파)

 

2. 서버 측 수신 (역캡술화)

1. Physical	신호 수신	NIC로 신호 수신
2. Data Link	프레임 해석	MAC 주소 검사, 프레임 수락
3. Network	IP 패킷 검사	목적지 IP 확인
4. Transport	포트 검사	TCP 세그먼트 → Port 443 수신
5. Session	TLS 세션 확인	세션 키 유효성 검사
6. Presentation	복호화	TLS 복호화하여 HTTP 요청 획득
7. Application	HTTP 처리	라우팅 처리 및 HTML 콘텐츠 준비

 

3. 서버 → 클라이언트 응답 (HTML, CSS, JS, 등)

서버가 HTML 파일과 필요한 리소스를 생성해 클라이언트로 응답

서버 응답 흐름 (캡슐화)

7	HTML 콘텐츠 생성 (예: index.html)
6	TLS 암호화
5	세션 유지
4	TCP 세그먼트로 전송
3	IP 패킷
2	MAC 프레임 생성
1	신호 전송

 

4. 클라이언트 수신 흐름 (역캡슐화 후 렌더링)

1	신호 수신
2	프레임 수신
3	IP 패킷 검사
4	포트 번호 확인 후 재조립
5	TLS 세션 확인
6	복호화 (HTTP 응답 획득)
7	HTML 파싱 + 렌더링 (DOM 트리, CSSOM, JS 실행)

 

4. 패킷 분석

실제로 이런 흐름인지 wireshark를 사용해서 패킷을 한번 잡아보자

 

4-1. 3-way handshake

 네이버 IP로 패킷을 필터링했다. 가장 먼저 3-way handshake가 보인다.

 

4-2. TLS 통신

 TCP 연결이 Establish된 후 암호 알고리즘 합의가 이루어진다. 즉 TLS handshake가 시작되는 것이다.

147번 패킷에서는 클라이언트가 서버쪽으로 이렇게 물어본다. "안녕 서버야, 나 지금 이런 암호화 알고리즘 사용할 수 있어!"
154번 패킷에서 서버는 클라이언트에게 수신했다는 응답을 날리고
155번 패킷에서 어떤 암호화 알고리즘을 사용할지 결정한 후 클라이언트에게 이를 알려준다.

실제로 147번 패킷을 열어보면 다음 TLS(Transport Layer Security) 데이터를 볼 수 있다.

 Cipher Suites 항목을 보면 된다. 총 16개의 알고리즘을 지원하고, 하나당 2byte의 hex 데이터로 표현한다. 따라서 총 크기는 32bytes다.

그러면 서버는 자신이 지원하는 암호화 알고리즘과 대조 후 최신의 적당히 빠르면서 안전한(아마도) 알고리즘을 선택해서 "응 그러면 우리 이렇게 암호화 해서 통신하자" 하고 알려준다. 바로 다음처럼 말이다

또 147, 155 패킷에서 서로의 공개키도 교환한다.

그럼 패킷을 한번 복호화해보자

 복호화 전과 같이 TCP-3way handshake, TLS-handshake 후 naver IP 에 GET method로 / 경로에 접근했음을 곧바로 파악할 수 있다.

 

5. 카카오톡으로 생각해보기

 자 그렇다면 우리가 카카오톡을 사용해서 통신할때는 어떨까? 카카오톡으로 친구와 대화를 하고싶다. 그러기 위해서는 카카오톡에 로그인을 해야할 것이다.

1. 카카오톡에 로그인을 하면 우선 카카오톡 서버와 TCP-3way handshake가 이루어진다.
2. TCP 연결이 Establish 된 다음, TLS handshake를 수행한다.
3. TLS handshake가 완료된 후 우리의 계정과 비밀번호가 안전하게 서버로 전송되고, 서버는 DB에 저장된 값을 이용해 우리가 입력한 인증값을 검증한다.
4. 인증이 성공했다면 서버는 클라이언트쪽으로 세션 토큰(JWT, 또는 커스텀 토큰)을 발급한다.
5. 사용자 데이터 동기화 후 실시간 채팅을 시작할 수 있게 된다.