Network
네트워크를 학습하러 오신 여러분 환영합니다!
이번 학습에서는 우리가 그동안 접해왔던 웹 애플리케이션이 동작하는 원리에 대해 학습하게 됩니다. 우리가 사용하는 웹 브라우저의 동작 원리나, 실제 서버와 클라이언트에 대해 학습하게 됩니다. 왜 클라이언트와 서버로 나누어져 있는지, 실제 통신이 이루어지는 과정을 학습하게 됩니다.
학습 목표
- 웹 애플리케이션 네이티브 애플리케이션의의 기본 개념에 대해 이해할 수 있다.
- 네트워크를 만드는 기술을 이해할 수 있다.
- TCP/IP의 기본에 대해 이해할 수 있다.
- IP의 기본개념에 대해 이해할 수 있다.
- TCP와 UDP 개념과 그 차이를 이해할 수 있다.
- PORT의 개념과 그 차이를 이해할 수 있다.
- URL, DNS의 기본에 대해 이해할 수 있다.
- DNS 기본적인 작동원리를 이해할 수 있다.
- 웹을 구성하는 기술을 이해할 수 있다.
- 웹의 기본적인 개념에 대해 이해할 수 있다.
- 클라이언트-서버 아키텍처에 대해 이해할 수 있다.
- 웹 애플리케이션 아키텍처에 대해 이해할 수 있다.
- 웹 애플리케이션 아키텍처 요청흐름에 대해 이해할 수 있다.
- 웹 애플리케이션을 구현하는 방식과 기술들에 대해 이해할 수 있다.
- SSR과 CSR의 기본 개념과 그 차이를 이해할 수 있다.
- CORS의 기본 개념에 대해 이해할 수 있다.
- SPA를 가능하게 하는 AJAX에 대해 이해할 수 있다.
- HTTP messages의 구조를 설명할 수 있다.
- HTTP의 동작 방식을 이해할 수 있다.
- HTTP requests와 responses를 구분할 수 있다.
- HTTP의 응답 메시지를 찾아볼 수 있다.
웹 애플리케이션에 대한 이해
애플리케이션은 아는데 웹애플리케이션은 무엇일까?
웹 애플리케이션을 알기 위해 네이티브 애플리케이션을 함께 알아볼 필요가 있습니다.
핸드폰을 사용하면서 모바일용 애플리케이션을 다운로드하여 설치해 사용해 본 경험이 한 번씩은 있을 것이라 생각합니다. 이러한 특정기기에 설치해서 사용하는 애플리케이션을 네이티브 애플리케이션(Native-application)이라고 부릅니다.
네이티브 애플리케이션은 Apple iOS, Android OS, Windows와 같은 특정 실행환경에 종속되게 됩니다.
아이폰에 설치되게끔 만들어진 애플리케이션은 갤럭시나 윈도우 컴퓨터에서는 실행할 수 없죠.
하지만 단점만이 있는 것은 아닙니다. 아래에 네이티브 애플리케이션과 웹애플리케이션에 대해 정리해 보았습니다.
네이티브 애플리케이션의 장점
- 웹애플리케이션보다 빠릅니다.
- 애플리케이션이 설치된 기기의 시스템/기기의 리소스에 접근이 용이합니다.(GPS 기능이나 카메라).
- 인터넷 없이 사용 가능합니다.
- 웹애플리케이션에 비해 안전합니다.(모바일의 경우 앱스토어에 승인을 받아야 합니다.).
네이티브 애플리케이션의 단점
- 웹애플리케이션에 비해 개발비가 더 들어간다(아이폰과 안드로이드 간의 멀티 플랫폼 개발 등).
- 빠른 업데이트가 힘들다.
- 앱스토어에 승인받기가 힘들고 비용이 발생한다.
그렇다면 웹애플리케이션은 무엇이고 어떠한 장단점이 있을까요?
웹애플리케이션은 웹 브라우저를 통해 접근이 가능한 애플리케이션입니다.
정적인 웹사이트의 한계를 벗어나 다양한 동적인 응답을 웹 브라우저라는 소프트웨어를 통해 가능하게 한 애플리케이션이죠.
웹애플리케이션의 장점
- 브라우저를 통해 실행되기 때문에 설치나 다운로드가 필요 없다.
- 업데이트 등의 유지관리가 쉽다.
- 네이티브 애플리케이션에 비해 만들기가 비교적 간편하다.
- 애플리케이션 스토어 승인이 필요 없다.
웹 애플리케이션의 단점
- 인터넷이 없으면 사용이 안된다.
- 네이티브 애플리케이션에 비해 속도가 느리다.
- 애플리케이션 스토어에서 관리되지 않기 때문에 사용자 접근성이 떨어진다.
- 질적으로나 보안상 위험에 노출되기가 쉽다.
오늘날 네이티브 애플리케이션과 웹 애플리케이션은 서로 가진 기술의 장점을 흡수하고, 스스로의 단점을 보완하는 방식으로 계속해서 발전해 나가고 있습니다.
다음 챕터부터는, 앞으로 우리가 배우고 구성해 볼 웹 애플리케이션에 대해 좀 더 알아보는 시간을 가지도록 하겠습니다.
네트워크를 만드는 기술
TCP/IP 기본
LAN과 WAN
웹 애플리케이션에 대해 알기 전에 웹 애플리케이션이 작동하는 기반이라고 할 수 있는 네트워크에 대한 이해가 필요합니다.
여러분의 컴퓨터는 어떻게 인터넷에 연결이 되어있나요?
인터넷 제공업체에서 제공한 인터넷 라우터를 통해 연결되어 있을 것입니다. 유선이 되었든 무선이든 라우터에 연결이 되어있지 않다면 인터넷을 사용할 수 없습니다.
이러한 좁은 범위에서 연결된 네트워크를 LAN(Local Area Network)라고 부릅니다. 그래서 LAN을 연결하는 선을 우리는 LAN 케이블이라고 부릅니다.
이러한 수많은 LAN들이 모여 세계의 네트워크를 구성하는 WAN(Wide Area Network)가 구성되게 됩니다.
우리는 왜 인터넷비용을 지불할까요?
작은 거점의 네트워크 구성인 LAN이 WAN으로 확장하기 위해서는 각 거점을 연결하는 통신회선 서비스를 이용해야 합니다. KT 나 LGU+, SKT 등의 통신 사업자가 이러한 회선 서비스를 구성하고 고객에게 서비스를 제공합니다. 우리가 사용하는 인터넷은 이러한 통신 사업자의 설비를 빌려야 회선 서비스를 이용한 WAN에 접속이 가능하기 때문에. 비용을 지불하게 됩니다.
인터네트워킹(internetworking)
우리가 매일 일상적으로 사용하는 인터넷은 사실 네트워크끼리 연결하는 네트워크라는 의미의 인터네트워크에서 왔습니다.
네트워크를 확장하는 방식은 크게 두 가지 방법이 있습니다.
- 한 네트워크를 확장하는 방법.
- 네트워크와 네트워크를 연결하는 방법.
여러 네트워크를 연결하는 것을 인터네트워킹이라고 합니다.
인터네트워킹은 그 네트워크의 일부에서 고장이 나도 영향이 광범위하게 퍼지지 않는다는 점과, 불필요한 통신이 네트워크 전체로 확산하지 않는다는 점, 개별 네트워크를 각각의 방침에 따라 관리가 가능하다는 등의 장점이 있습니다.
그리고 전 세계적으로 인터네트워킹 하는 것이 우리가 사용하는 인터넷(The Internet)입니다.
프로토콜(protocol)
인터넷에 연결되어 있는 멀리 떨어진 컴퓨터들끼리 서로 소통을 하려면 어떻게 해야 할까요?
약속이 필요합니다.
이 공통된 약속을 프로토콜이라고 합니다. 지금은 ‘TCP/IP’ 프로토콜이 주로 사용하는 약속입니다.
약속은 왜 필요할까요?
우리가 가전제품을 사용할 때 전원에 연결해서 사용하는 전원코드를 생각해 보겠습니다. 예를 들어 가전제품 제조사마다 전원 연결부를 다르게 만들어서 내놓는다면 어떨까요?
안 맞는 제품을 살 때마다 전기 기술자를 불러서 콘센트를 바꿔달아야 할 것입니다. 심지어 220v에 맞지 않게 만든다면요?
그래서 전자제품에도 어느 정도 공통 규격이 정해져 있고, 제조사는 이를 바탕으로 제조를 합니다.
인터넷 통신도 마찬가지입니다. 어느 컴퓨터든 일관되게 네트워크를 사용할 수 있게 하는 공통언어가 바로 프로토콜입니다.
TCP / IP
인터넷 통신 스위트(Internet Protocol Suite) 은 인터넷에서 컴퓨터들이 서로 정보를 주고받는데 쓰이는 통신규약의 모음입니다.
이 모음은 다른 컴퓨터나, 다른 운영체제, 다른 회선 간의 통신이 가능하게 해 줍니다.
인터넷이 처음 시작하던 시기에 정의되어 현재까지 표준으로 사용하고 있는 TCP(Transmission Control Protocol)와 IP(Internet Protocol)에서 가져와 TCP/IP라고 부릅니다.
TCP/IP 4계층 모델
데이터가 계층모델을 통해 상대에게 도달하는 흐름
그럼 각 Layer의 요소가 네트워크 세계에서 실제로 어떻게 사용되는지 알아보도록 하겠습니다.
주소(address)
서울특별시청을 찾아가기 위해서는 서울특별시청의 주소를 알아야 합니다. 마찬가지로 네트워크 상에서 서울특별시청에 근무하는 김코딩 사무관의 PC에 접속하기 위해서는, 김코딩 사무관의 PC를 가리키는 주소를 알아야 합니다. 이렇게 네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address, IP 주소)라고 합니다.
IP주소
이어지는 챕터에서 좀 더 자세히 다루겠지만, 전체적인 맥락을 위해 가볍게 설명을 하고자 합니다.
IP 주소는 TCP/IP 구조에서 컴퓨터를 식별하기 위해 사용되는 주소입니다. 192.xxx.xxx.xxx 등의 주소를 본 적이 있을 것입니다.
컴퓨터나 휴대전화, 서버, 인터넷 라우터 등 네트워크 장비에 각각의 IP 주소가 할당되게 됩니다.
IP 주소에는 private 주소와 public 주소가 있습니다. LAN 네트워크 내부에서 사용되는 것이 Private IP 주소이고, Public IP주소는 인터넷에서 사용이 됩니다.
공유기를 설치하고 비밀번호를 설정하려면, 공유기 관리 페이지에 접속해야 합니다. 웹 브라우저에 닷(.)으로 구분된 네 덩이의 숫자를 입력하면, 공유기의 관리 페이지로 접속할 수 있습니다. 이때 사용되는 네 덩이의 숫자를 IP 주소라고 합니다.
IP는 Internet Protocol의 줄임 말로, 인터넷상에서 사용하는 주소체계를 의미합니다. 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분됩니다. 이렇게 네 덩이의 숫자로 구분된 IP 주소체계를 IPv4라고 합니다. IPv4는 Internet Protocol version 4의 줄임 말로, IP 주소체계의 네 번째 버전을 뜻합니다.
터미널에서 간단한 명령어로 자주 이용하는 코드스테이츠의 IPv4 주소를 확인할 수 있습니다. 터미널을 열고, nslookup codestates.com을 입력하면, 다음과 같은 화면을 만날 수 있습니다.
터미널에서 nslookup을 이용해 IP주소를 확인할 수 있습니다.
- localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭합니다.
- 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소입니다. 서버에서 접근 가능 IP 주소를 broadcast address로 지정하면, 모든 기기에서 서버에 접근할 수 있습니다.
인터넷 보급률이 낮았던 초기에는 이 버전(IPv4, IP version 4)으로 네트워크에 연결된 PC에 주소를 할당하는 일이 가능했습니다. 그러나 개인 PC의 보급으로 전 세계의 누구나 PC를 이용해 인터넷에 접속하고, 각종 서비스를 위해 서버를 생산하면서 IPv4로 할당할 수 있는 PC가 한계를 넘어서게 되었습니다. 이를 위해 세상에 나오게 된 것이 IPv6(IP version 6)입니다. IPv6는 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현할 수 있습니다.
하지만 IPv6가 등장하고 오랜 시간이 지났음에도 불구하고 이를 메인으로 사용하지 않습니다. 그 이유는 아직도 IPv4가 사용할만하기 때문입니다.
현재까지도 VPS 호스팅 서비스를 계약해 Public IPv4 부여받는 것은 부담이 없는 가격으로 가능합니다.
MAC 주소
IP address 만 가지고는 네트워크 상에서 송수신이 가능하지는 않습니다. 각 네트워크 기기는 처음부터 제조사에서 할당하는 고유 시리얼인 MAC 주소를 IP 주소와 조합해야만 네트워크를 통한 통신이 가능합니다.
이더넷에서는 네트워크상의 송수신 상대를 특정하고자 MAC 주소를 사용하고, TCP/IP 에서는 IP address를 사용하기 때문입니다.
같은 LAN에 속한 기기끼리 통신을 할 때는 우선 상대방의 MAC 주소를 파악하는 과정이 있게 됩니다.
이때 사용하는 것이 ARP (address resolution protocol)입니다. MAC 주소를 파악하기 위해 네트워크 전체에 브로드캐스트를 통해 패킷을 보내고.
해당 IP를 가지고 있는 컴퓨터가 자신의 MAC 주소를 Response하게 됨으로써 통신할 수 있게 해주는 프로토콜입니다.
패킷
기기끼리의 통신에는 회선 교환(Circuit Switching) 방식과 패킷 교환(Packet Switching) 두 가지 방식이 있습니다.
통신 회선을 설명하여 데이터 교환을 하는 회선교환 방식은 주로 음성전화 시스템에 사용됩니다. 전화는 일대일로 데이터를 교환하고, 전화 간 통화 중에는 다른 상대와 전화통화가 불가능합니다.
하지만 컴퓨터 네트워크는 여러 상대와 통신이 가능해야 합니다. 따라서 회성 교환방식은 컴퓨터 네트워크에서는 효율적이지 않습니다. 그래서 이를 극복하기 위해 패킷교환 방식이 생겨났습니다.
패킷 교환은 원본 데이터를 패킷(packet)이라고 하는 작은 단위로 나누고, 여러 회선을 공용해 통신을 주고받습니다.
하나의 패킷은 헤더와 페이로드로 구성되어 있고, 헤더에는 어떤 데이터의 몇 번째 데이터인지의 정보와 보내는 곳이나 최종 목적지에 대한 정보 등이 들어있습니다.
이렇게 주고받을 데이터를 작게 분할하여 전송하더라도, 도착한 곳에서 원래대로 복원이 가능합니다.
IP
앞서 우리는 TCP/IP에 대해 전체적으로 살펴보았습니다.
이번 챕터에서는 IP에 대해 조금 더 자세히 알아보도록 하겠습니다.
IP 주소 구조
서브넷 마스크(subnet mask)
IPv4 주소는 OOO.OOO.OOO.OOO의 형식으로 되어 있습니다.
10진수로 표기되어 있지만, 그 실체는 마침표로 구분된 4개의 8비트 필드(8자리 2진수 4개)로 되어있습니다.
각 8비트 필드는 IPv4 주소에서 1바이트를 나타냅니다. IPv4 주소의 바이트를 나타내는 이러한 형식을 점으로 구분된 십진수 형식이라고도 합니다.
IP 주소는 네트워크부와 호스트부로 나뉩니다. 네트워크부는 어떤 네트워크인지를 알 수 있는 정보이고, 호스트부는 그 네트워크 안의 특정 컴퓨터를 지칭하는 정보입니다.
IPv4 주소에서 네트워크부가 어디까지인지 나타내는 것이 서브넷 마스크입니다.
- IP 주소: 192.168.1.1
- 서브넷 마스크: 255.255.255.0
- 네트워크 주소: 192.168.1.0
- 브로드캐스트 주소: 192.168.1.255
8자리의 2진수 묶음을 옥텟이라고 부릅니다. IPv4 주소는 4개의 옥텟으로 이루어져 있고, 각각을 1옥텟, 2옥텟, 3옥텟, 4옥텟이라고 부릅니다.
위 서브넷 마스크의 경우는, 1에서 3까지의 옥텟을 네트워크부로 사용하는 서브넷 마스크입니다. 따라서 4옥텟은 호스트부로 사용하고 있음을 알 수 있습니다.
IP주소의 할당과 관리
MAC 주소와 달리, IP주소는 처음부터 주어지는 것이 아니라 할당이 되는 것이라고 배웠습니다. 위 그림처럼 호스트부를 변경해 가면서 IP 할당이 이루어지게 됩니다.
위와 같은 예라면, 호스트부는 8자리로 이루어진 2진수이므로, 할당할 수 없는 시작(0)과 끝 숫자(255)를 제외한 번호로 할당이 가능합니다.
호스트부가 0으로 만 이루어진 것은 네트워크 주소로 그 네트워크를 의미합니다. 호스트부가 1로만 이루어진 것은 브로드캐스트 주소로 ARP와 같은 기능을 사용하기 위해 사용합니다.
따라서 시작(0)과 끝(255)을 제외한 254개의 주소만이 할당가능한 IP주소입니다.
IP프로토콜의 한계
하지만 IP 프로토콜도 한계가 있습니다.
IP 프로토콜의 한계
- 비연결성
- 비신뢰성
패킷을 받을 대상이 없거나 특정한 이유로 서비스 불능 상태에 빠져도 데이터를 받을 상대의 상태 파악이 불가능하기 때문에 패킷을 그대로 전송하는 비연결성 문제가 있습니다.
중간에 패킷이 사라지더라도 보내는 기기 측에서는 알 수 있는 방법이 없습니다. 또한, 서로 다른 노드를 거쳐서 전송되는 특성상, 보내는 기기 측에서 의도한 순서대로 데이터가 도착하지 않을 수 있습니다.
또한, 한 IP에서 여러 애플리케이션이 작동하는 경우 특정할 수 없는 한계가 있습니다.
이러한 한계들을 극복하기 위해 TCP와 UDP가 사용되고 있습니다.
다음장에서는 TCP와 UDP를 조금 더 자세히 알아보도록 하겠습니다.
실습
아래 링크의 웹서비스를 이용해 자신의 네트워크 접속 정보를 확인해 보세요
심화 학습
네트워크 접속 기기가 많아지게 되면 IP 주소를 별도로 관리해야 합니다. 이를 위한 소프트웨어인 IPAM에 대해 알아보세요
- https://en.wikipedia.org/wiki/IP_address_management
- https://docs.microsoft.com/en-us/windows-server/networking/technologies/ipam/ipam-top
TCP, UDP
TCP/IP 4계층 모델
TCP와 UDP는 TCP/IP 4계층 모델을 기준으로 IP 프로토콜의 계층인 인터넷 계층의 상위에서 동작을 합니다. 전송계층에 속하는 TCP와 UDP는 2계층에서 동작하는 IP와 4계층에서 동작하는 애플리케이션(http 등)을 중개하는 역할을 합니다.
TCP와 UDP는 중개하는 역할을 하는 점에서는 동일하지만, 각각이 다른 아래와 같은 특징을 가지고 있습니다.
TCP는 통신 신뢰성을 높이는 실현하는 기능이 구현되어 있습니다. UDP에는 신뢰성을 높이는 기능이 없는 대신보다 높은 속도와 효율성을 제공합니다.
이러한 이유로, 데이터의 신뢰성을 필요로 하는 애플리케이션은 TCP로, 빠른 속도나 실시간 통신이 중요한 애플리케이션의 경우 UDP로 구분해서 사용합니다.
특히 웹애플리케이션에서 많이 사용하는 HTTP의 경우 모든 데이터를 제대로 송수신이 가능해야 하는 특성상, TCP를 사용합니다.
TCP/IP의 개념은 1970년대 미 국방부가 미국과 영국, 그리고 프랑스의 대학들의 연구자들과 협력하여 개발을 하였습니다.
각 국가가 파멸에 이를 수 있는 전쟁(핵 공격 및 장기간의 전쟁)에도 데이터의 온전성과, 통신기능의 원활한 사용을 위한 통신 프로토콜의 개발을 원한 미 국방부는, 신뢰할 수 있고, 탄력적인 성능을 가진 통신 프로토콜(TCP/IP)을 완성해 냈습니다.
TCP 3-way handshake는 양 끝단의(end to end) 기기의 신뢰성 있는 데이터 통신을 위해, TCP 방식이 연결을 설정하는 방식입니다.
마치 전화를 거는 것 같이 연결을 설정하는 이 방식은 세 단계를 통해 연결 설정을 합니다.
- Step 1 (SYN): 처음으로, sender는 receiver와 연결 설정을 위해, segment를 랜덤으로 설정된 SYN(Synchronize Sequence Number)와 함께 보냅니다. 이 요청은 receiver에게 sender가 통신을 시작하고 싶다고 알립니다.
- Step 2(SYN / ACK): receiver는 받은 요청을 바탕으로 SYN/ACK 신호 세트를 응답합니다. Acknowledgement(ACK) 응답으로 보내는 segment가 유효한 SYN요청을 받았는지를 의미합니다.
- Step 3(ACK): 마지막 단계에서, sender는 받은 ACK를 receiver에게 전송을 하면서, 신뢰성 있는 연결이 성립되었다는 사실을 sender와 receiver 양쪽에서 알 수 있고, 실제 데이터 전송이 시작되게 됩니다.
UDP
TCP처럼 가상의 회선을 설정해 신뢰성을 보장하면 당연히 좋은데 왜 UDP를 사용할까요? 그럼 모든 상황에서 TCP가 UDP보다 우수할까요?
당연히 답은 ‘No’입니다.
아래 TCP를 사용한 예시를 한번 들어보겠습니다.
- 온라인 게임 LOL을 플레이하는 중입니다. 결정적 순간에 기술을 사용해야 하는데 항상 조금 지연시간이 있습니다. 근데 지연시간이 매번 조금씩 달라서 타이밍을 잡기가 힘듭니다.
- 카카오톡으로 보이스 톡을 하는데, 내가 말하고 상대방이 말할 때마다 지연시간이 조금씩 발생하면서 싱크가 맞지가 않습니다.
아래와 같은 이유로 많은 애플리케이션 개발자들은 UDP를 사용합니다.
- 애플리케이션의 정교한 제어가 가능하다: TCP의 경우 receiver가 전송받을 준비가 될 때까지 세그먼트를 반복적으로 재전송합니다. 실시간 전송에 대한 요구가 큰 애플리케이션 들은 높은 latency를 지양하므로 약간의 데이터 손실을 감수합니다. 대신 개발자 스스로가 이를 보완하기 위해 애플리케이션에 추가 기능을 구현할 수 있습니다.
- 연결설정에 무관하다.: TCP 3-way handshake 가 없는 udp는 예비과정 없이 바로 전송을 시작합니다. 설정단계에서 발생하는 지연이 없는 만큼, 반응속도가 빠릅니다. 또한, TCP 가 신뢰성을 위해 많은 파라미터와 정보 전달이 필요함과 비교해 UDP는 연결설정 관리를 하지 않기 때문에 어떠한 파라미터도 기록하지 않습니다. 이 때문에 서버에서도 TCP와 비교에 더 많은 클라이언트를 수용이 가능합니다.
생각해 볼 주제:
- 위에서 학습한 내용을 토대로: 비디오 스트리밍 상황에 주로 사용하는 방식은 TCP 방식일까요 아니면 UDP가 되어야 할까요?
- 미 국방부는 어떠한 점에 착안하여 TCP/IP 가 극심한 전시 중 에도 신뢰성을 잃지 않는다고 판단하였을까요?
- DNS 서버가 TCP방식에서 동작한다면 어떠한 문제가 발생할 수 있을까요?
PORT
TCP와 UDP 둘 다 포트번호를 사용합니다.
IP프로토콜만 가지고는 한 IP에서 여러 애플리케이션이 동작할 때 특정 애플리케이션을 특정해 통신할 수 없다고 했었습니다.
포트번호는 대상 IP 기기의 특정 애플리케이션(connection endpoint)을 특정하는 번호입니다.
위 그림과 같이 한 서버 인스턴스에서 웹서버와 메일서버 두 개를 동시에 실행 중이라고 가정하겠습니다.
IP주소만으로는 어느 서버로 요청을 보내는지 알 수 없습니다. 이러한 경우를 위해, 포트 번호를 사용해 receiver를 특정해 어느 서버로 보내는 요청인지 특정할 수 있습니다.
로컬 환경에서 Spring을 실행하면 나타나는 화면에는, Tomcat started on port(s): 8080과 같은 숫자가 표현됩니다. 이 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)를 의미합니다. 로컬에서 실행했을 때에는 로컬 PC의 IP 주소 127.0.0.1로 접근하여, 8080번이 통로를 통해 실행 중인 서버를 확인할 수 있습니다. 이미 사용 중인 포트는 중복해서 사용할 수 없습니다.
포트 번호는 0~ 65,535까지 사용할 수 있습니다. 그중에서 0 ~ 1023번까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있습니다.
자주 사용되는 Well-known port
- 더 많은 포트 번호 확인하기 - List of TCP and UDP port numbers - Wikipedia
이미 정해진 포트 번호라도, 필요에 따라 자유롭게 사용할 수 있습니다. 잘 알려진 포트의 경우 URI 등에 명시하지 않지만, 그 외의 잘 알려지지 않은 포트(:8080과 같은 임시 포트)는 반드시 포함해야 합니다.
URL, DNS
URL
URL(Uniform Resource Locator) 은 웹에 게시된 어떤 자원을 찾기 위한 브라우저에서 사용되는 메커니즘입니다. 인터넷상에서 HTML이나 이미지 등 리소스의 위치를 특정하기 위한 서식으로서 탄생하였습니다.
브라우저의 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타냅니다. 예를 들어 https://naver.com:443 사이트에 접속하게 되면, naver.com 주소가 가리키는 서버의 기본 폴더를 뜻합니다. CLI 환경에서 폴더와 파일의 위치를 찾아 이동하듯이, 슬래시(/)를 이용해 서버의 폴더에 진입하거나 파일을 요청할 수 있습니다. 그러나 기본적인 보안의 일환으로 외부에서 직접 접근이 가능한 경우는 거의 없습니다. 이번 콘텐츠를 보다 쉽게 이해하기 위해, 크롬 브라우저에 다음 url을 입력해 보세요.
username에는 사용자 이름을 입력합니다.
Ubuntu:
- file://127.0.0.1/home/username/Desktop
macOS:
- file://127.0.0.1/Users/username/Desktop/
Windows:
- file://localhost/C:\Users/public\Desktop\
크롬 브라우저에 입력하면, 브라우저로 PC의 폴더와 파일을 탐색할 수 있습니다.
위 URL을 크롬 브라우저에 입력하면, 크롬 브라우저를 파일 탐색기로 쓸 수 있습니다. 이어서 입력한 URL의 각 부분이 무엇을 나타내는지 살펴봅니다.
URL은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냅니다. URL은 scheme, hosts, url-path로 구분할 수 있습니다. 가장 먼저 작성하는 scheme은 통신 방식(프로토콜)을 결정합니다. 일반적인 웹 브라우저에서는 http(s)를 사용합니다. hosts는 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냅니다. url-path는 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냅니다.
URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함합니다. query는 웹 서버에 보내는 추가적인 질문입니다. 위 그림의 http://www.google.com:80/search?q=Java를 브라우저의 검색창에 입력하면, 구글에서 Java를 검색한 결과가 나타납니다.
브라우저의 검색창을 클릭하면 나타나는 주소가 URI입니다. URI는 URL을 포함하는 상위개념입니다. 따라서, 'URL은 URI다.'는 참이고, 'URI는 URL이다.'는 거짓입니다.
Domain name
웹사이트의 주소를 https://142.250.207.78/weather/index.html처럼 IP 주소로만 작성해서 이용해야 한다면 기억하기에 매우 어려울 겁니다.
호스트이름과 도메인 이름으로 바꾸어 아래처럼 기억하기 쉬운 이름을 사용할 수 있습니다.
웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소가 있습니다. 만약 IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 볼 수 있습니다.
택시를 타고 목적지에 도착하는 상황을 가정해 보겠습니다. 서울 중구 세종대로 110이라는 도로명 주소가 있습니다. 택시를 타고, 기사님께 도로명 주소를 전달하면, 무사히 목적지에 도착할 수 있습니다. 그러나 도로명 주소 특성상 주소 자체가 상당히 길고, 주소지만 보면 어떤 건물이 있는지 파악하기 어렵습니다.
도로명 주소를 대신해서, 우리는 상호나 건물의 이름을 택시 기사님께 전달할 수도 있습니다. 택시를 타고 기사님께 서울시청까지 가 달라는 메시지를 전달해도, 우리는 무사히 목적지에 도착할 수 있습니다. 이와 유사하게 도메인 이름을 이용하면, 한눈에 파악하기 힘든 IP 주소를 보다 분명하게 나타낼 수 있습니다.
다음과 같이, 터미널에서 도메인 이름을 통해 IP 주소를 확인하는 명령어 nslookup으로 codestates.com의 IP 주소를 확인할 수 있습니다.
위 그림에서 IP 주소는 3.34.153.168이고, 도메인 이름은 codestates.com입니다. 주소창에 IP 주소(3.34.153.168)를 입력하면, codestates.com으로 이동할 수 있습니다.
그렇다면 이런 도메인은 어떻게 관리되고 있을까요?
현재 4억 개에 달하는 도메인을 관리하는 곳은 ICANN이라는 비영리 단체입니다.
그 밖의 조직으로 registry와 registrar가 있습니다.
Registry는 도메인 관리 기관입니다. 각 도메인 정보의 데이터베이스를 관리하고, registry에 따라 도메인 종류가 달라집니다.
Registrar는 중개 등록업체입니다. Registry의 데이터베이스에 직접 도메인 정보를 등록 가능합니다.
도메인 종류
도메인은 두 종류로 나뉩니다.
- gTLD – generic Top Level Domain
- ccTLD – country code Top Level Domain
gTLD는 전 세계에서 등록이 가능한 .com, .net, .org, .edu, .gov, .int, .mil 일곱 가지로 시작하여 현재까지 .biz, .name, .info 등이 추가되어 왔습니다.
gTLD의 경우 VERISIGN 등의 회사가 registrar이고, 국내 ICANN 인증 registrar는 가비아, 후이즈 등이 있습니다.
ccTLD의 경우 .kr, .us, .jp 등 200개 이상이 있습니다. 각국 네트워크 정보센터에서 위임받아 관리하며 .kr 의 경우 한국인터넷진흥원이 registry로 그리고 registrar는 가비아, 후이즈 등이 있습니다.
DNS
네트워크 상에 존재하는 모든 PC는 IP 주소가 있습니다.
그러나 모든 IP 주소가 도메인 이름을 가지는 것은 아닙니다. 로컬 PC를 나타내는 127.0.0.1 은 localhost로 사용할 수 있지만, 그 외의 모든 도메인 이름은 일정 기간 동안 대여하여 사용합니다.
그렇다면 이렇게 대여한 도메인 이름과 IP 주소는 어떻게 매칭하는 걸까요?
브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해서는, 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요합니다.
네트워크에는 이것을 위한 서버가 별도로 있습니다.
DNS는 Domain Name System의 줄임말로, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템입니다.
만약 브라우저의 검색창에 naver.com을 입력한다면, 이 요청은 DNS에서 IP 주소(125.209.222.142)를 찾습니다. 그리고 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 합니다.
시스템 작업이나 서버 교체 등 IP주소가 변경되는 경우는 많이 있습니다.
심화학습
DNS - 도메인 네임 시스템
웹을 구성하는 기술
웹(WEB)
웹의 구성
웹(WEB)은 인터넷에서 제공되는 하이퍼텍스트 시스템입니다.
하이퍼텍스트: 문서 안에 다른 문서의 위치정보 등을 포함하여 문서 간의 정보를 서로 연관 지어 참조할 수 있는 문서.
웹은 인터넷에서 제공하는 여러 기능의 구현물의 하나일 뿐이지만, 지금은 인터넷이라 하면 흔히 웹을 떠올리게 되었습니다.
하이퍼텍스트의 시작은 1989년 유럽 입자 물리 연구소(CERN)입니다. 연구소 직원이던 팀 버너스리가 정보 공유 수단으로써 고안한 것이 원형입니다. 연구소 내의 직원들이 수많은 정보를 주고받는 상황에 다른 운영체제나 애플리케이션을 사용하고 있어서 문제가 자주 발생하고는 했는데, 운영체제나 애플리케이션에 상관없이 일정한 형식으로 출력되게 하는 새로운 개념이 필요했습니다.
그래서 일정한 형식의 기준인 HTML을 제안하게 되는데, HTML은 운영체제나 애플리케이션이 달라도 브라우저만 있으면 모두가 동일한 정보를 볼 수 있도록 하였습니다.
이렇게 웹은 HTML로 대표되는 하이퍼텍스트 언어와 인터넷이 융합하여 탄생하게 되었습니다.
최초에는 문자정보 전달에만 초점이 맞춰져 있었습니다. 하지만 사용자와 개발자의 요구에 의해 확장되고 기술의 발전으로 웹 서버에서 동작하는 애플리케이션이나 HTML 자체의 사양 또한 올라가게 되었습니다.
기술의 발전과 함께 웹은 오늘날 게임, 동영상 서비스, 전자상거래, 거대 소셜미디어 서비스 등 다양한 용도로 활용되고 있습니다.
클라이언트-서버 아키텍처
웹에서 제공되는 서비스는 주로 서비스를 이용하는 (클라이언트)와 서비스 제공 쪽(서버)으로 나뉩니다. 이러한 구조를 클라이언트-서버 아키텍처라고 부릅니다.
클라이언트는 사용자가 직접 이용합니다. 따라서, 사용 편의성이나 휴대성 등을 고려해 개발이 이루어집니다.
서버는 유지보수를 할 시점을 제외하고는 24시간 일 년 내내 작동하고 있어야 합니다. 클라이언트가 언제 접속해서 서비스를 이용할지 모르기 때문입니다. 하지만, 사용자와는 직접적 접점이 없기 때문에 편의성 보다는 기능에 중점을 두고 개발이 이루어집니다.
다음 장에서 클라이언트-서버 아키텍처에 대해 조금 더 알아보도록 하겠습니다.
클라이언트-서버 아키텍처에 대한 이해
https://slides.com/codestates/2tier/fullscreen?token=eP65uGRC
웹 애플리케이션 아키텍처
웹 애플리케이션의 구조를 간단하게 도식화하면 위와 같을 것입니다.
우리는 일상에서 웹 애플리케이션을 자연스럽게 접하면서 살아가고 있습니다.
여러분은 다음과 같은 질문을 기술면접 상황에서 접하게 되면 어떤 방식으로 대답하실 수 있으신가요?
“웹 애플리케이션의 안 보이는 영역에서는 어떤 방식으로 작동하는지 아는 데로 설명해 주세요”
아마 지금까지 배워오고 기존지식을 활용하여 다음과 같이 대답할 수 있을 것입니다.
일반적으로 웹브라우저의 혹은 클라이언트의 요청은 서버단에 도달하게 되고, 서버단에서는 요청에 따른 back-end 로직을 실행한다. 그 이후, 서버는 응답을 클라이언트 단에 돌려주고 클라이언트는 이를 화면에 표시한다.
맞는 대답입니다. 하지만 뭔가 부족합니다.
이제부터, 우리는 웹 애플리케이션에 대해 조금 더 깊은 영역까지 알아보도록 하겠습니다. 웹 얘플리케이션의 각 요소와 계층이 어떤 방식으로 이루어져 있고, 클라이언트의 요청이 어떤 흐름을 따라 웹 애플리케이션의 각 요소와 계층을 통해 응답을 주게 되는지 조금 더 이해할 수 있습니다.
단편적인 기능개발에 직접적인 영향은 없을 수 있지만, 이러한 웹 애플리케이션 아키텍처 근본에 대한 지식이 훌륭한 개발자가 되는데 굉장히 중요합니다.
웹 애플리케이션 아키텍처란?
여러분은 웹사이트(website)와 웹 애플리케이션(web application)의 차이를 아시나요?
아마 같다고 생각하시는 분들이 많을 것이라 생각합니다. 우리는 일상용어로 혼용해서 사용하기도 합니다.
질문:
- naver.com 은 ‘website’ 일까요 OR ‘web application’ 일까요?
- facebook.com 은 ‘website’ 일까요 OR ‘web application’ 일까요?
웹 애플리케이션은 아래와 같은 특징이 있습니다.
- 데스크톱 애플리케이션처럼 상호작용 가능하다.
- 특정 기능을 가지고 있다(정보 검색 등).
- 정보나 자료 등의 콘텐츠 관리 시스템과 함께 작동한다.
웹 개발 영역에서 website라고 하면 일반적으로 정적 페이지들의 집합체를 의미합니다. 웹사이트가 정적 페이지들 뿐 아니라 동적 페이지를 포함하게 된다면 이미 web application 이 되게 됩니다.
이를 토대로 위 질문에 대한 답을 생각해 보니 어떤가요?
네 맞습니다! 오늘날 만들어지는 대부분의 웹사이트들은 사실 엄밀하게 이야기하면 웹 애플리케이션들입니다.
그럼 웹 애플리케이션 아키텍처는 무엇일까요?
웹 애플리케이션 아키텍처는 클라이언트-서버 간의 연결에 대한 설명 방법이라고 할 수 있습니다.
웹 애플리케이션 아키텍처는 어떻게 애플리케이션 내부의 요소들이 상호 간에 소통하는지 설명합니다.
위에 언급했던 네이버와 페이스북 그리고 여러분이 매일 사용하시는 코드스테이츠 urclass 또한 약간의 차이가 있을 뿐 같은 원리로 웹 애플리케이션 아키텍처를 따르고 있습니다.
조금 더 기술적으로 풀어보면, 유저가 웹브라우저에서 요청을 하면 애플리케이션의 다양한 요소들(브라우저, 유저 인터페이스, 미들웨어, 서버, 데이터베이스)이 상호작용을 합니다. 웹 애플리케이션 아키텍처는 이러한 요소들이 상호작용을 유지할 수 있도록 서로를 결부시키는 뼈대라고 할 수 있습니다.
유저가 웹 애플리케이션과 상호작용을 할 때, 응답은 보통 찰나에 이루어집니다.
여기서 우리가 유심히 생각해봐야 할 점은, 유저의 수없이 많은 다양한 요청과 입력에 대해 알맞은 응답을 할 수 있는가입니다. 이러한 점 때문에 웹 애플리케이션 서버는 많은 부분 요소와 외부 애플리케이션 또한 공유하여 설계가 됩니다.
웹 애플리케이션은 인터넷에 공개되는 순간부터 글로벌 네트워크의 막대한 트래픽에 노출될 수 있기 때문에 아래와 같은 요소를 고려해야 합니다.
- 신뢰성(reliability)
- 확장성(scalability)
- 보안성(security)
- 견고성(robustness)
웹 애플리케이션의 구현
웹 애플리케이션 구현방식
오늘날 웹 애플리케이션을 구성하는 방식은 크게 다음과 같이 세 가지 방식이 있습니다.
- Single Page Application
- Microservice architecture
- Serverless Architectures
하나씩 차례로 알아보도록 하겠습니다.
Single Page Application
위의 그림처럼 웹페이지에서 일부분만 바꾸고 싶다면 어떻게 해야 할까요?
오늘날 만들어지는 많은 웹 애플리케이션들은 Single Page Application으로 만들어집니다. 위와 같이 직관적으로 알기 쉽고 상호작용 가능한 요소들을 이용해 유저 경험을 극대화합니다.
Single Page Application에서는 유저의 입력과 요청에 의한 콘텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고 현재 페이지에서 이루어집니다.
Single Page Application은 필수적인 요소만을 요청합니다. 그리고 이러한 점은 페이지가 새로 고침 되는 것을 방지해 유저 경험을 극대화합니다.
이러한 기능을 위해 AJAX, Asynchronous JavaScript, 그리고 XML 이 주로 사용됩니다.
이러한 Single Page Application의 기능을 통해 유저는 페이지가 새로 고침 되지 않고, 요청한 응답을 기다리면서 페이지와 상호작용이 가능합니다.
Microservice architecture
작고 가벼운 특정한 한 가지 기능에 집중한 웹 애플리케이션을 의미합니다.
각 애플리케이션의 기능 요소들은 상호 간에 의존적으로 설계되지 않습니다. 따라서 개발단계에서도 그리고 개발 완성 이후로도 같은 개발 언어를 사용할 필요가 없습니다.
개발자는 원하는 언어를 사용해 기능 개발에 유연성을 더 갖게 되고. 개발 과정의 전반적인 속도와 생산성이 향상됩니다.
Serverless Architecture
Serverless Architecture는 개발자가 웹 애플리케이션의 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식입니다.
이 방식은 개발자가 기본적인 서버나 기반 기능들에 걱정할 필요 없이 특정기능의 개발에 집중할 수 있게 합니다.
웹 애플리케이션 구현 기술
HTTP
이후에 조금 더 자세히 다루겠지만, 이번 챕터에서 간단히 살펴보고 가도록 하겠습니다.
HTTP(HyperText Transfer Protocol)는 웹 브라우저상에서 클라이언트와 서버 간의 통신을 담당하는 프로토콜입니다. HTTP는 클라이언트에서의 데이터 요청과 서버에서의 요청에 대한 응답을 반복하면서 웹 애플리케이션을 작동시킵니다.
HTTP 요청을 할 때는 하고 싶은 처리의 종류를 나타내는 메서드의 이름과 처리 대상의 이름이 포함됩니다.
HTTP 응답에는 요청에 대한 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리결과인 메시지가 포함됩니다.
이름이 의미하듯 처음에는 문서 전송에 주로 이용되었지만 오늘날에 와서는, 대용량의 이미지, 음성, 영상, 파일 데이터 등 거의 모든 방식의 데이터 전송을 HTTP를 이용해서 처리합니다.
이후에 자세히 다루도록 하겠습니다.
Cookie와 Session
HTTP는 데이터를 요청하고 요청에 대한 응답을 전송하는 무상태성의 프로토콜입니다.
우리가 특정 쇼핑몰에 접속하여 쇼핑을 한다고 가정하겠습니다.
구매를 원하는 상품에 대해 장바구니에 넣고 그중에 일부 원하는 물품에 대해 결재를 진행하고 싶습니다. 또한 당장은 구매하지 않았지만 추후에 장바구니에 들어있는 물품 또한 다시 찾는 수고스러움을 감수하지 않고 편하게 구매절차를 진행하고 싶습니다.
위와 같은 기능을 실현하기 위해서는 무상태성의 특징을 가지고 있는 HTTP 프로토콜만 가지고는 불가능합니다.
이를 위해 필요한 기능이 쿠키와 세션입니다.
- 쿠키: 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 합니다. 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 작동하게 도와줍니다.
- 세션: 세션의 경우 서버에 Session-Id라는 고유 아이디를 할당해서 유저를 식별합니다. 단순하고 유출이 되면 안 되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭해서 저장해 관리합니다. 주로 사용되는 방법은, 세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적입니다.
사용자 인증
사용자 인증은 우리에게 익숙한 개념입니다. 컴퓨터나 특정 시스템을 사용할 때 유저를 식별할 수 있는 ID 값과 암호를 입력합니다. 심지어 현관문을 열 때도 비밀번호를 사용합니다.
이러한 과정은 의도하지 않은 제3자가 마음대로 컴퓨터나 시스템의 이용을 차단하기 위해 사용합니다.
오늘날의 웹 애플리케이션의 사용자 인증도 크게 다르지 않습니다. 하지만 점점 개인 정보를 이용한 인증이 강화되고 있습니다. 따라서, 웹에서의 인증은 개인정보를 바탕으로 합니다.
단지 사용자 식별용 고유 아이디와 암호뿐이 아니라, 개인의 신원 또한 파악하는 다요소 인증(MFA)이 웹 에서의 보안의 필수 요소로 까지 되었습니다.
여러분도 최근에 새로운 웹 애플리케이션에 가입할 때 개인 휴대전화로 일회용 패스워드를 받는다든가, 혹은 통신사 전용 소프트웨어를 사용하는 등의 추가인증 절차를 경험해 보았을 것입니다.
은행과 같이 더 높은 보안을 요구하는 서비스는 물리적 하드웨어 토큰에 OTP를 사용하는 것까지 있습니다.
가장 일상적으로 접하는 것은, 여러분이 urclass를 접속할 때도 사용하시는 OAuth 방식의 로그인이 있습니다. 이 방식은 서비스 자격증명 메커니즘을 다른 믿을만한 제3의 서비스에 위임해 인증하는 방식입니다.
블로깅 주제
- Microservices Architecture는 추가로 어떤 장점이 있고 어떤 경우에 사용하면 좋을까요?
- Serverless Architecture는 추가로 어떤 장점이 있고 어떤 경우에 사용하면 좋을까요?
심화 References 링크
- Microservice architecture
- Serverless architecture