웹의 발전 과정과 간략한 동작 원리에 대해서 알아보겠습니다. 이 글은 MDN, 생활코딩의 웹1 영상, academind을 토대로 작성됐습니다.

웹의 동작 원리

서버와 클라이언트란?

2대의 컴퓨터가
서로 정보를 주고 받는 순간
인류는 완전히 새로운 존재가 되었습니다.
고객을 영어로는 클라이언트(client)라고 합니다.
사업자를 영어로는 서버(server)라고 합니다.
사람들은 요청하는 컴퓨터를 클라이언트 컴퓨터,
응답하는 컴퓨터를 서버 컴퓨터라고 부르기로 합니다. -생활코딩

이제 웹을 길거리라고 생각해보자. 횡단보도 한쪽에는 행인(클라이언트) 있고, 다른 쪽에는 클라이언트가 무언가를 사려고 하는 상점(서버)이 있다.

웹주소를 칠 때 일어나는 일들

인터넷 연결 상태

웹에서 데이터를 주고 받을 수 있도록 해준다. 행인이 현재 있는 횡단보도와 같다.

TCP/IP

어떻게 데이터가 인터넷을 타고 여행해야 하는지를 정의한다. 운송수단과 같아서, 당신이 상점에 가거나 뭔가를 사는 등의 행위를 할 수 있게 해준다.

DNS(Domain Name Servers)

웹사이트의 주소목록이라고 할 수 있다. 브라우저에서 웹 주소를 쳤을 때, 브라우저는 DNS를 뒤져봄으로써 웹사이트의 실제 주소를 찾는다.

브라우저는 각각의 웹사이트가 어떤 서버에 상고 있는지를 앎으로써, HTTP 메세지를 올바른 장소에 보낼 수 있도록 해야 한다. 이는 당신이 상점의 알맞은 주소에 찾아가는 것과 같다.

HTTP (Hypertext Transfer Protocol)

클라이언트와 서버가 서로 대화할 수 있는 언어를 정의한다. 상점에서 어떤 언어로 주문할 것이냐가 된다. 당연히 우리는 한국말을 쓰겠지만, 만약 서로 약속되지 않은 언어나 이상한 말을 하게 된다면 물건을 사지도 못할 것이다.

서버가 클라이언트의 요청을 승인하는 경우, 서버는 클라이언트쪽에 "200 OK"라는 메세지를 보낸다.

파일 (Component files)

웹사이트는 여러 개의 파일들로 구성되어 있다. 상점에서 사려고 하는 다양한 물건들과 같다. 이 파일들은 2가지로 나뉘어진다.
1. 코드 파일들 : 웹사이트는 기본적으로 HTML, CSS, and JavaScript로 이뤄져있다.
2. 기타 파일들 : 이미지, 음악, 비디오, PDF파일 등 웹사이트에서 주고 받으려는 파일들.

브라우저는 이 작은 파일 덩어리들을 해석함으로써 완전한 하나의 웹페이지를 구성하고, 브라우저 위에 디스플레이한다.

파싱(해석)의 순서

HTML파일은 CSS와 javascript파일을 참조할 수 있다.

서버의 관점에서 응답을 보내줄 때, 파일들이 어떤 우선순위와 순서로 파싱되어야 하는지는 매우 중요하다.

1. HTML파일이 가장 먼저 파싱되고, 서버는 해당 파일의 안을 들여다봄으로써 서버는 어떤 CSS파일과 어떤 자바스크립트 파일이 참조되었는지를 인식한다.
2. HTML이 파싱된 결과로 DOM(document object model)구조가 생성되면, CSS파일이 파싱되고 스타일이 DOM 구조의 알맞은 요소들에 적용된다. 여기서 페이지의 비주얼이 스크린에 페인팅되기 시작하고, 유저가 페이지를 볼 수 있게 된다.
3. 자바스크립트가 파싱된다.

정리

웹 브라우저의 주소창에 academind.com이라고 치는 순간,

1. URL이 해석된다.
2. 요청이 웹사이트의 서버로 전송된다.
3. 서버로부터의 응답이 파싱된다.
4. 페이지가 렌더링된다.

🔍 더 자세히 알아보자

Step 1 - URL 해석

웹사이트의 코드는 클라이언트쪽의 머신에 저장되어있지 않다. 따라서 클라이언트는 다른 컴퓨터, 즉 서버에 저장된 코드들을 가져와야만 한다.

URL창에 “academind.com”(도메인 주소)을 치고 엔터를 쳤을 때, 웹사이트의 소스 코드의 주인인 서버는 사실 IP (Internet Protocol)를 통해 그 주소가 구별된다.

어떻게 “academind.com”이라는 도메인 주소가 IP주소로 변환되는 걸까?

DNS 서버 (Domain Name System)

DNS서버의 목적은 도메인 주소를 IP 주소로 변환하는 것이다. DNS서버를 도메인을 IP주소로 바꾸는 거대한 사전이라고 상상해볼 수 있다.

그러므로 사용자가 도메인 주소를 쳤을 때 브라우저가 가장 처음 할 일은, DNS서버로부터 해당 도메인 주소의 IP주소를 얻는 것이다.

Step 2 - 요청 전송

IP주소가 해석됨에 따라, 브라우저는 서버로부터 해당 IP주소로 요청을 보낸다.

HTTP

요청은 보이지 않는 곳에서 기술적으로 일어나는 일이다. 브라우저는 수많은 정보(정확한 URL에 담긴 다른 정보가 있는지, 어떤 종류의 요청을 보내야 하는지, 메타데이터가 있어야 하는지 등등)를 챙기고 그 데이터 묶음(?)을 해당 IP 주소로 보낸다.

데이터는 HTTP(HyperText Transfer Protocol) 통신규약을 통해 보내진다. HTTP란 서버와 클라이언트간의 요청과 응답이 어떻게 보여야 하는지, 어떤 데이터가 포함되어야 하는지, 요청이 어떻게 보내질 것인지 등을 공식화한 약속이다.

모든 단계와 체계가 공식화되었으므로, 서버쪽에서는 응답을 어떻게 읽고 해석해야 하는지를 따로 고민할 필요가 없다. HTTP 규약을 지켰다면 요청이 정상적으로 보내지고, 지키지 않았다면 요청이 정상적으로 보내지지 않는 거.

이제 서버는 요청을 적절히(?) 다룬 뒤 (당연히 요청에 대한 응답은 서버마다 다르다.) 응답을 보낸다. 단순하게 생각하면 응답은 서버 입장에서 보내는 요청이다.

요청과 마찬가지로, 응답은 데이터를 담고 있다. 하나의 페이지를 요청할 때, 응답은 해당 페이지를 스크린에 렌더링하기 위해 필요로 하는 코드들을 담고 있을 것이다.

요청을 정상적으로 받았을 때, 서버에서는 무슨 일이 일어날까?
그건 웹 개발자들이 정의한 것에 따라 다르다. 결국 웹사이트를 완성하기 위해서 응답은 보내져야 한다. 모든 응답이 웹사이트 하나를 통째로 답고 있을 필요는 없다. 응답에는 파일, 이미지, 영상과 같이 어떤 데이터든지 담길 수 있다.

Step 3 - 응답 파싱

브라우저는 서버로에 의해 전송된 응답을 받게 된다. 그러나, 응답을 받은 것 자체로는 아무것도 렌더링할 수 없다.

브라우저가 응답을 파싱해야 한다. 브라우저는 응답에 담긴 데이터와 메타데이터(전체 데이터에 대해 설명하는 데이터)를 인식하고, 이걸 기반으로 무엇을 할지를 결정한다. 그리고 브라우저는 데이터의 종류에 따라서 최선의 메커니즘을 적용하려고 한다.

응답은 여러 조각의 구체적인 메타데이터를 담고 있다. 많은 메타데이터가 있지만 여기서는 content-type만 알아보자.

여기서 content-type는 해당 내용의 타입이 text/html이라는 걸 브라우저에게 전달하고 있다.

content-type : text/html은 브라우저가 실제 데이터(HTML코드)를 파싱할 수 있게 해준다.

그리고 브라우저는 HTML을 어떻게 파싱해야 할지 알고 있다. 이제 남은 일은 HTML을 모두 해석하고 HTML이 참조하는 또 다른 데이터들을 해석할 차례다.

Step 4 - 페이지 렌더링

브라우저는 HTML데이터와 HTML코드안에 담긴 참조 파일들을 통해서 웹사이트를 짓는다.

위에서 Type을 자세히 볼 필요가 있다. document는 HTML문서를 뜻한다. 가장 처음에 인식되는 응답 내용이므로 표의 맨 위에 있다.

stylesheet은 CSS파일이라는 걸, script는 자바스크립트 파일이라는 것을 뜻한다. 이 파일들을 추가적으로 파싱한 뒤 브라우저는 전체 페이지를 렌더링하고 작동한다.

이제 끝이다!

그러나 아직 궁금한 점들이 많이 남아있다. 다음에 더 알아봐야겄다.

1. HTTP의 구체적인 부분들과 작동 원리
2. 브라우저가 페이지를 렌더링하는 원리
3. 코드가 파싱되는 원리
4. DOM (document object model)
5. 메타데이터