주니어 개발자를 위한, ‘웹’으로 알아보는 네트워크

지금까지 4화에 걸쳐서, 네트워크에서 데이터가 어떻게 이동하여 목적지를 찾아가는지 전체적인 흐름을 알아보았습니다. 이제 이론을 통해 머릿속으로 네트워크에 대한 이미지를 떠올릴 수 있게 되었으니, 이번에는 우리가 가장 많이 사용하는 웹 브라우저를 통해 웹 페이지를 받아오는 과정을 실전으로 알아보도록 하겠습니다. 아직 이전에 발행된 네트워크 시리즈 4화를 보지 못 한 분은 먼저 읽고 오시면 도움이 됩니다.

‘엄청 쉬운 네트워크 이야기’ 시리즈 다시 보기

• 1화. 주니어 개발자를 위한 엄청 쉬운 네트워크 이야기
• 2화. 택배 배송 과정으로 알아보는 엄청 쉬운 컴퓨터 네트워크
• 3화. 주니어 개발자를 위한 엄청 쉬운 TCP/IP 4계층 이야기
• 4화. 주니어 개발자를 위한 TCP/IP 주요 프로토콜 알아보기

우리가 컴퓨터를 켜면 자동적으로 접속하게 되는, 전 세계의 정보가 모여 있는 크롬, 엣지, 파이어폭스, 웨일과 같은 웹 브라우저를 네트워크적으로 해석해보자면, “응용계층 프로토콜인 HTTP를 사용하여 통신을 가능하게 해주는 클라이언트 응용프로그램” 이라고 할 수 있습니다. 이 웹 브라우저를 사용하여 https://yozm.wishket.com/magazine/를 호출하게 되면 발생하는 네트워크 흐름을 알아보겠습니다.

인터넷 목적지 주소

<주니어 개발자를 위한 엄청 쉬운 TCP/IP 4계층 이야기>에서, 네트워크에서 데이터를 올바른 목적지로 보내기 위해서 필요한 주소로 2가지를 언급했습니다. IP주소와 MAC주소인데요. 웹 브라우저에서 동작하는 html, css, js와 같은 파일들을 받아오기 위한 목적지 주소는 어떻게 설정할까요? 바로 URL(Uniform Resource Locator)이라 부르는 주소 표시줄에 표현되는 값으로 설정합니다.

사실 MAC주소도 IP주소로 찾기 때문에, 실질적으로 필요한 주소는 IP주소라고 볼 수 있습니다. 우리가 아는 IP주소는 10.0.0.1과 같은 숫자로 이루어져 있죠. 그런데 위의 주소 표시줄의 경우 영어 단어로 이루어져 있습니다. 이건 어떻게 된 일일까요?

IP주소의 식별

초기 인터넷에서는 IP주소만으로 통신을 했습니다. 그러나 네트워크가 발전함에 따라, IP주소만으로 통신하기에는 개발자 혹은 사용자들의 불편함이 있었습니다.

예를 들어보겠습니다. 웹 브라우저를 실행시키고 네이버에 접속하려고 한다면, 어떤 목적지 주소로 요청을 해야 네이버 서버에 접속이 가능할까요? 과거에는 네이버에 직접 물어보지 않으면 알 방법이 없었습니다. 즉, 네이버에 전화해서 IP주소를 알려 달라고 요청한 뒤, “223.130.195.200”라는 답변을 듣고 나서, 주소 표시줄에 입력해야만 네이버 메인 화면을 볼 수 있었다는 말입니다.

이 과정은 조금만 생각해봐도 엄청나게 답답합니다. 웹페이지를 요청하기 위한 4개의 숫자를 외우거나, 종이에 “223.130.195.200 네이버” 같은 메모해 놓지 않으면, 매번 IP주소를 물어봐야 하는 상황이 생기는 것입니다.

이를 해결하기 위해 나온 첫 번째 방법은 로컬 컴퓨터에 입력해 놓는 방법이었습니다.

hosts 파일

hosts라는 파일에 IP주소와 이름을 입력해 놓음으로써, 통신 시 자동으로 이름을 IP주소로 변환하도록 한 것입니다. 위의 “223.130.195.200 네이버”를 hosts 파일에 입력해 놓음으로 매번 IP주소를 확인할 필요 없이 “네이버”이라는 호스트 이름을 기억함으로 통신이 가능하게 된 것입니다.

이러한 방식으로, 이전에 비해 통신을 편하게 할 수 있게 되었지만, 금방 이 방식에도 문제점이 생기게 됩니다.

hosts파일의 중앙집중화 hosts.txt

만약 네이버의 IP가 변경되면 어떤 일이 벌어질까요? 로컬 컴퓨터 hosts파일에 “223.130.195.200 네이버”라고 등록해 놓은 모든 컴퓨터가 변경된 IP로 업데이트해야 할 것입니다.

이러한 문제로 하나의 중앙서버에 host.txt파일을 만들어, 모든 컴퓨터의 hosts파일을 공유하는 중앙집중화를 하게 되었습니다. 중앙서버에 hosts.txt를 검색하여 통신에 이용하게 되면, 위처럼 네이버의 IP가 변경되더라도 로컬 컴퓨터는 수정없이 동작할 수 있었습니다. 네이버가 IP를 변경해도 중앙서버의 host.txt파일이 업데이트만 된다면, 이를 검색하는 모든 컴퓨터에는 자동으로 적용될 것이기 때문입니다.

그러나 이 또한 네트워크가 발전함에 따라 한계를 맞이하게 됩니다.

DNS(Domain Name System)의 등장

네트워크가 급속도로 성장하면서 더 이상 하나의 중앙서버에서 모든 호스트 이름을 관리하기가 어려워졌습니다. 과거에는 컴퓨터의 성능도 그렇게 좋지 않았기 때문에 수천, 수만의 호스트 이름이 등록되면, 이를 요청하는 컴퓨터들의 개수도 상당하기 때문에, 응답하는 것에 부하를 많이 받기 때문입니다. 또한 각 로컬 컴퓨터의 hosts 파일을 수정하게 되면 중앙서버의 hosts.txt도 수정이 되어, 이 또한 부하가 엄청났던 것입니다.

그래서 이를 해결하기 위해 나타난 것이 우리가 지금 알고 있는 도메인 네임 시스템(DNS) 입니다. 도메인(Domain)은 영역을 뜻하며, 모든 호스트의 IP주소를 “영역별로 구분하여 이름을 주겠다”는 의미입니다.

온점(.)으로 영역을 구분하여 IP주소를 이름으로 표현하도록 한 것입니다. 그리고 각 영역마다 도메인 이름 서버를 계층적으로 두어, 모든 도메인 이름이 하나의 서버에 등록되는 게 아니라 계층 별로 등록된 후, 최상위부터 최하위까지 질의를 통해 최종적으로 IP주소를 구하는 방법이 고안됐죠. 이를 통해 부하를 해결함과 동시에 확장성도 갖추게 된 것입니다.

이렇게 하여 생겨나게 된 도메인 이름을 이용하여 통신에 사용하는 대표적인 프로토콜이 HTTP(웹)와 SMTP(메일) 입니다. DNS에 관련된 내용은 많은 자료들이 있으니 필요하신 분들은 찾아보시기 바랍니다. 이 글에서는 웹을 통하여 네트워크를 알아보기 위해, IP주소가 도메인 이름으로 표현된다는 내용을 간단하게 알아본 것이기 때문에 이만 넘어가도록 하겠습니다.

URL(Uniform Resource Locator)

이렇게 웹 브라우저 주소 표시줄에 표현되는 도메인 네임을 이용하여, 웹 페이지를 요청할 목적지 주소를 찾을 수 있습니다. 이제 목적지를 찾았으니 어떤 리소스(html, css, js 등등)를 요청할지 경로를 지정해야 하는데요. 이를 URL이라고 합니다. 로케이터(Locator)라는 의미 답게 목적지에서 리소스의 위치를 찾을 수 있습니다.

요즘IT URL 주소인 https://yozm.wishket.com/magazine를 예로 살펴본다면, “https://”는 프로토콜을 의미하고, “yozm.wishket.com”는 도메인 이름, “/”뒤로 “/magazine”과 같은 표현은 모두 리소스의 경로를 나타냅니다. 과거의 웹 브라우저는 정적인 화면, 즉 html을 주로 사용했기 때문에, 주소 표시줄에 리소스의 확장자를 정하지 않으면 html을 요청한다는 의미로 사용됩니다.

즉, 위의 내용을 요약해보자면 “프로토콜의 형식은 https, 목적지 주소는 yozm.wishket.com, 가져올 리소스는 magazine.html” 이라 볼 수 있는 것입니다. 이런 내용은 웹 브라우저의 개발도구화면(F12)에서도 확인해 볼 수 있습니다.

URN(Uniform Resource Name)과 URI(Uniform Resource Identifier)

그러나 인터넷 환경이 발전하면서, 단순히 경로 만으로 리소스를 표현하는 것에 어려운 점이 있었습니다. 위의 요즘IT의 도메인 네임(yozm.wishket.com)만 입력할 경우, 처음 뜨는 화면을 magazine이라는 URL로 표현되고 있는데, 만약 서버에서 magazine.html 파일의 이름이 main.html로 변경되었을 경우, 화면이 뜨지 않는 상황이 생길 것입니다. URL은 리소스의 경로를 표현하지만 “/magazine.html”이라는 파일이 없기 때문입니다. 올바른 화면을 표시하기 위해서는 “/main”으로 변경되어야 할 것입니다.

리소스의 위치가 변경되면, 경로도 수정해야 하는 불편한 점이 있는 것이죠. 이로 인해, 주소 표시줄에 경로의 의미로 사용하지 않고 리소스에도 이름을 부여하는 URN(Uniform Resource Name)이라는 고유한 이름으로 리소스를 찾을 수 있도록 발전되었습니다. 즉, 서버에 magazine이라는 이름으로 리소스를 요청하면, 서버가 무작정 경로를 찾는 것이 아닌, 정해져 있는 리소스를 반환할 수 있게 된 것입니다.

그런데 실제 웹에서의 통신은 경로와 이름을 전부 사용하고 있기 때문에 최종적으로 이를 포괄하는 URI(Uniform Resource Identifier)라는 개념으로 정착하게 되었습니다.

웹, HTTP를 이용한 통신을 하기에 앞서, 어떠한 목적지에서 어떤 리소스를 가져올 것인지에 대해 간단하게 알아보았습니다. 위에서 말한 내용들을 통합하여, 이제 실제 네트워크의 흐름에 대해 알아보겠습니다.

웹 통신

웹 브라우저를 통해, 요즘IT(https://yozm.wishket.com/magazine/)에 접속하게 되면, 가장 먼저 도메인 이름을 통해 IP주소를 얻어와야 합니다. 따로 DNS 서버에 대해 설정을 하지 않았다면, 운영체제는 기본 게이트웨이(Default Gateway),즉 같은 네트워크에 존재하는 라우터로 DNS프로토콜을 보내게 됩니다. 그리고 라우터는 가입 되어있는 통신사(KT, SKT, LGU+)의 DNS서버로 보내게 됩니다.

도메인 이름(yozm.wishket.com)을 통해 IP(13.209.131.189)를 구하게 된 후에는 앞서 <주니어 개발자를 위한 TCP/IP 주요 프로토콜 알아보기>에서 배웠던 흐름대로 흘러가게 됩니다. 그래서 이번 시간에는 앞부분만 좀 더 상세히 살펴 본 후 넘어가도록 하겠습니다.

첫번째로 13.209.131.189를 목적지 IP 주소로 입력한 후, MAC 주소를 이용하여 프레임을 전달 합니다. 이 때, 실질적으로 프레임이 이동하기 위해서는 목적지 MAC 주소를 구해야 한다고 했었습니다. 목적지 IP 주소로 ARP(Address Resolution Protocol)를 통해 MAC 주소를 구해야 한다는 의미입니다.

두번째는, 운영체제는 현재 컴퓨터의 IP주소와 목적지 IP주소를 비교하여, 두 가지가 서로 다른 네트워크 주소라는 것을 확인하고, 다음 프레임의 목적지 MAC 주소를 기본 게이트웨이로 정합니다.

운영체제는 IP주소의 무엇을 보고, 다음 목적지를 기본 게이트웨이로 판단했을까요? 이것을 알기 위해서는 IP주소의 변화 과정을 따라가야 합니다만, 이 주제 또한 긴 내용을 필요로 하여, 이번 시간에선 간단하게 알아보고 넘어가도록 하겠습니다.

서브넷 마스크

우리가 IP주소를 확인할 때, 항상 같이 따라다니는 “/24” 와 같은 숫자를 본적이 있으실 겁니다. 이는, 4개의 8bit로 이루어진, 총 32bit 중 앞에서부터 24bit를 네트워크 주소로 보겠다는 것입니다.

서브넷 마스크라는 이름과 같이, IP주소를 여러 개의 네트워크로 구분하여 사용할 수 있도록 해주는 기술입니다.

그림 9의 빨간색 박스가 뜻하는 것이 네트워크 주소입니다. 그 길이가 24bits 이므로 “10.0.0.1/24”와 같이 “주소/서브넷 마스크”로 표기하여 네트워크 주소와 호스트 주소를 구분할 수 있는 것입니다. 네트워크 주소도 IP주소이기 네트워크에서 표현 가능한 주소여야 합니다. 그래서 서브넷 마스크로 지정된 빨간색 박스의 값은 유지하고, 나머지 호스트 주소의 가장 첫번째 숫자로 IP주소를 선정하는 것입니다. 위의 경우 서브넷 마스크에 해당하는 10.0.0과 나머지 호스트 주소 0 ~ 255가 표현가능한 숫자 중 가장 첫번쨰 숫자인 0으로 하여, 10.0.0.0으로 네트워크 주소를 나타 냅니다. 10.0.0.1은 호스트 주소라고 볼 수 있겠습니다.

그래서 서브넷 마스크로 네트워크를 구분 지을 때는 반드시 1개의 네트워크 주소와, 그 나머지를 호스트 주소로 할당할 수 있습니다. 이 말은, 네트워크 주소 부분이 같으면 같은 네트워크, 다르다면 다른 네트워크라고 판단할 수 있다는 말입니다. 목적지 IP 주소가 같은 네트워크인지 다른 네트워크인지가 왜 중요할까요? ARP로 MAC주소를 구하는 다음의 상황을 통해서 다른 네트워크의 목적지 IP주소를 같은 네트워크에서 찾게 될 경우 어떠한 일이 발생하는지 알아보겠습니다.

그림 10과 같은 상황에서 13.209.131.189의 MAC 주소를 찾을 수 있을까요? 스위치는 목적지MAC주소가 브로드 캐스트인 것을 확인하고 연결 되어있는 모든 컴퓨터에게 ARP를 전송할 것입니다. 그러나 연결 되어있는 어떤 컴퓨터도 13.209.131.189 IP 주소를 가지고 있지 않기 때문에 프레임을 전달하기 위한 목적지 MAC 주소 자체를 구할 수가 없는 상황이 생기게 됩니다.

다른 네트워크로 내보내기 위해서는 반드시 라우터를 거쳐야 하므로, 다른 네트워크 주소로 프레임을 전달하고자 할 경우, 기본 게이트웨이로 설정하여 무조건 내보내게 되어 있습니다.

ARP의 목적지 IP를 같은 네트워크의 기본 게이트웨이로 설정했기 때문에, MAC 주소(DD:DD:DD:DD:DD:DD)를 구할 수 있을 것입니다.

그렇게 구한 MAC 주소를 HTTP를 전달하는 것에 사용할 수 있는 것입니다. 이후의 내용은 역시 이전 시간에 배운 네트워크 흐름과 동일하기 때문에, 이 정도에서 마무리 하도록 하겠습니다.

결론

이전 시간과 더불어 이번 시간에는 조금 더 상세한 내용을 다루어 보았습니다. “MAC주소로 이동하고 IP주소로 최종 목적지를 알 수 있다”라는 흐름만 이해하셨다면, 네트워크와 관련된 내용을 들었을 때, 상상할 수 있는 힘을 얻으신 것이라고 생각합니다.

아직도 전하지 못한 내용이 너무나도 많지만, 제가 처음에 전달하고자 했던 “네트워크에서의 데이터 흐름”은 어느 정도 전달 드린 것 같습니다. 이에 만족하고, 주니어를 위한 네트워크 지식은 여기서 마무리하도록 하겠습니다. 감사합니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.