네트워크 / 웹 사이트에 접속하는 과정

웹 사이트에 접속하는 과정

구글에 접속하는 방법은 쉽다. 주소창에 https://www.google.com 만 입력하면 된다. 

 

google.com 이 ip주소가 아니라는 건 안다. 우리가 봐온 ip주소는 192.168.151.112 같은 숫자 꼴이었으니 말이다. 이런 google.com, naver.com처럼 ip 주소를 문자로 표현할 수 있도록 하는 서비스를 DNS(Domain Name System)이라고 하고 그 문자열을 도메인이라고 한다.

 

이번 포스팅에서는 대충 DNS 서버로부터 ip주소를 얻어 서버에 페이지 리소스를 요청하고 응답받는다는 대답 말고, 조금 더 깊게 데이터를 요청하고 응답하기까지의 과정을 TCP/IP 모델의 역할과 함께 설명하고자 한다.

 

 

1. 목적지 ip 주소 확인

도메인 주소가 입력되면 해당 목적지의 ip 주소를 먼저 찾아야한다. DNS에 ip 주소를 요청하기 앞서, 브라우저의 캐시 파일이나 로컬의 hosts 파일을 확인한다. 참조할 수 있는 데이터 있다면 그 주소를 사용하면 될 것이고, 없다면 DNS로부터 ip주소를 응답받는다.

 

 

2. DHCP (Dynamic Host Configuration Protocol)

클라이언트 PC는 자신의 ip주소도 모르는 상황으로, udp 더미 패킷을 브로드캐스트 하여 DHCP 서버로부터 DHCP 서버의 ip주소, Lifetime 등을 포함한 정보를 수신하고 최적의 서버를 고르게 된다.

 

(DHCP 서버는 광역 패킷에서 port로 구분된다. 예를 들면 port 67은 DHCP 서버만 열고 있고, 나머지는 다 닫아서 DHCP 서버가 아닌 노드는 패킷을 무시한다.)

 

클라이언트 PC는 선택한 DHCP 서버로부터 자신의 ip주소, 가장 가까운 라우터 ip주소 등의 정보를 얻게 된다.

 

이제 클라이언트 PC는 자신의 ip주소, 목적지 ip주소, 가장 가까운 라우터의 ip주소를 알고 있다.

 

 

 

3. ARP (Address Resolution Rotocol)

가장 가까운 Router의 ip주소를 알고 있는 상황에서 MAC 주소를 알아야 한다. 찾고자 하는 라우터의 ip 주소를 포함한 광역 패킷을 브로드캐스트 하고 호스트들은 자신의 ip 주소와 동일한지 확인하여 일치한다면 자신의 MAC 주소를 응답한다.

 

각 노드는 광역 패킷에 포함된 라우터의 ip 주소와 일치 여부를 확인한다.

 

이렇게 가장 가까운 라우터의 MAC 주소도 얻었다.

 

 

4. Framing과 Error Control

A에서 X에게 보내고자 하는 데이터는 010001100101과 같은 비트들의 연속일 것이다. 이 연속되는 비트 열을 X가 받으면, 어디부터 A가 보낸 데이터이고 어디까지가 의미를 갖는지 알 수 없을 것이다.

 

 

Ethernet의 frame 구조

 

Framing은 패킷의 시작과 끝 부분에 식별 비트열을 배치시키는 과정, 또는 반대로 식별자를 읽어 프레임 단위로 비트열을 처리하는 과정을 말한다.

 

이 과정에서 송신 측(A)은 에러 검출을 위한 필드(FCS)를 삽입한다. 수신 측(X)이 데이터를 읽었을 때 에러가 있는지 확인하여 에러를 직접 수정하거나, 폐기 후 재송신을 요청할 수 있도록 하기 위함이다.

 

 

A -> D frame 목적지 정보

 

위 그림에서처럼 A에서 D로 데이터를 전송할 때, 목적지 MAC 주소는 현재 Link (A->X)의 도착 MAC 주소를, 감싼 패킷에 쓰여있는 목적지 ip주소는 D의 ip주소가 들어간다.

 

헷갈릴 수 있겠지만, 2 계층과 3 계층을 독립적으로 생각하면 편할 것이다. 프레임의 MAC 주소는 Link를 기준으로 한다.

 

 

5. Flow Control과 Congestion Control

데이터가 잘 전달되려면 송신 측만 데이터를 잘 가공해서 보낸다고 끝이 아니다. 앞서 Framing에서 수신 측을 생각하여 FCS 필드를 추가해준 것처럼 수신 측의 처리 속도나, 네트워크 상황을 고려하여 송신해야 한다.

 

송신 측의 송신 속도보다 수신 측의 데이터 처리 속도가 느린 경우, 또는 수신 측에서 수신해야하는 다른 데이터가 너무 많은 경우 등의 이유로 수신측의 버퍼가 오버플로우 되는 상황을 방지하기 위해 피드백을 주고받는 방법이 Flow Control이다. 

 

이와 유사하게, 네트워크 혼잡도가 높아 데이터가 쌓이는 상황을 대비하여 현 네트워크 상황을 지속적으로 유추하여 손실을 피하는 방법이 Congestion Control이다.

 

Congestion control, Tahoe 방식과 Reno 방식

 

6. 아날로그 신호로 변환

이렇게 최종적으로 만들어진 A의 전송 데이터는 비트 열이다. 물리 계층에서는 이를 아날로그 신호로 변환하여 전송한다. 또 반대로 수신하는 입장에서는 이런 아날로그 신호를 받아 비트열로 변환한다.

 

 

 

7. Routing과 Forwarding

드디어 X 라우터에서 A의 데이터를 받았다. 프레임을 읽어 아래 그림과 같은 패킷을 읽었다.

 

'아 A에서 시작했고, 이제 D를 향해 가야 하는구나.'   

 

 

이런 X의 상황에서 아래 그림을 보자. Y1, Y2, Y3로 세 개의 다음 라우터가 있을 때 X는 어느 라우터를 다음 라우터로 결정하는 게 좋을까. cost가 무한대인 Y1으로 가선 안될 것이고, 이왕이면 cost가 가장 적은 Y3가 좋을 것 같다.

 

 

 

이렇게 다음 목적지를 선택하는 과정을 Routing이라고 한다. 여러 라우팅 알고리즘을 사용하여 목적지까지의 최적의 루트를 계산하여 경로와 비용을 매핑한 표를 Routing Table, 그리고 입력 포트와 수신 포트를 매핑한 테이블을 Forwarding Table이라고 한다.

 

즉 최적의 목적지를 계산하고 경로를 결정하는 과정이 Routing, 데이터를 다음 라우터로 이동시키는 과정이 Forwarding이다.

 

 

8. 도착, 그 이후

위 과정이 반복된다. 최적의 라우터를 결정하여 라우터로 데이터를 전송하고, 다시 이 데이터를 받아 패킷을 분석하여 다음 목적지 결정을 반복하여 D에 도착한다.

 

이후에는 transport layer에서 port 정보를 꺼내 어떤 프로세스에 접근해야 하는지 확인하고, application layer를 지나면서 HTTP 프로토콜에 따라 요청 URL로 변환되어 필요한 데이터를 검색하게 된다.

 

검색된 서버의 데이터는 다시 HTTP 프로토콜을 따라 HTTP 응답 메시지로 변환되고, 위와 반대의 순서로 다시 클라이언트 PC에 전송된다.

 

그 데이터를 PC에서 받아 브라우저에 출력된 결과물이 바로 우리가 웹 사이트를 검색했을 때의 출력물인 것이다.

 

 

정리. 딱딱한 Layer 설명 없이 재밌는 정리를 하고 싶었는데...

TCP/IP 모델을 공부하고, '레이어별 역할, 데이터 전송 단위, 장비, 프로토콜' 등의 딱딱한 계층 설명을 하고 싶지 않다는 생각 아래에 이 글을 쓰게 되었는데 와 닿는 설명이 되었는지 모르겠다. 

 

오히려 나에게 도움이 많이 되었다. 한번 쭉 설명을 하고 나니 머릿속에서 분리되어 있던 각 계층별 기능이 유기적으로 이어졌다. 부족했던 부분은 더 공부하게 되었다.

 

항상 생각하지만, 글로 읽는 것보다 그림으로 풀이하는 게 나에게는 정말 잘 맞는 공부 방법인 것 같다. 한 번씩 이렇게 그림으로 로직을 정리하면 그냥 책을 읽는 것보다 훨씬 오래 기억되고 생각 정리도 잘되는 느낌이다.

 

다음 포스팅은 'MAC 주소와 IP 주소가 따로 있는 이유', 'IP 주소가 부족하진 않을까?'에 대해서 공부하고 정리할 생각이다.

 

 

참고 자료.

KOCW에서 한양대학교 이석복 교수님 컴퓨터 네트워크 강의를 수강하고 정리한 글입니다.

컴퓨터네트워크

네트워크에 대한 배경 지식이 없는 분은 유튜브 우아한Tech 채널의 [10분 테크톡] 히히의 OSI 7 Layer 영상을 추천드립니다.