웹은 어떻게 작동하는가

docs.scrimba.com

열어본 모든 페이지는 같은 짧은 여정을 따릅니다. 주소로 뭔가를 요청하면, 어딘가의 컴퓨터가 텍스트 문서를 보내주고, 브라우저가 그 텍스트를 보이는 페이지로 변환합니다. HTML은 그 텍스트가 작성되는 언어이므로, 그것이 거치는 여정을 이해하는 것은 이 핸드북의 모든 것의 배경입니다.

클라이언트와 서버

웹은 양쪽 간의 대화입니다. 브라우저는 페이지를 요청하는 프로그램인 **클라이언트**입니다. 웹사이트를 가지고 있다가 전달해주는 컴퓨터가 서버입니다. 당신이 요청하면, 서버가 답합니다.

레스토랑에서 주문하는 것으로 생각해보세요. 당신은 고객이고, 주방은 보이지 않는 곳에 있으며, 웨이터가 주문을 왕복으로 날라줍니다. 당신은 주방에 들어가서 요리를 하지 않습니다. 요리를 요청하면, 주방이 요리를 준비해서 보내줍니다. 브라우저는 고객이고, 서버는 주방이며, 웹은 둘 사이를 오가는 웨이터입니다.

모든 페이지 로드는 **클라이언트**가 서버와 대화하는 것입니다. 클라이언트는 요청을 만드는 프로그램으로, 거의 항상 브라우저이지만 모바일 앱이나 커맨드 라인 도구일 수도 있습니다. 서버는 어딘가의 컴퓨터에서 실행되고 있으면서 요청을 기다렸다가 응답을 보내는 프로그램입니다.

관계는 처음에는 일방향입니다. 클라이언트가 항상 먼저 말을 겁니다. 서버가 갑자기 페이지를 당신에게 밀어넣지는 않습니다. 서버는 클라이언트가 뭔가를 요청할 때까지 앉아서 기다렸다가 답장을 합니다. 한 서버가 한 번에 수천 명의 클라이언트에 답장하므로, 같은 주소에서 한 웹사이트가 많은 방문자를 서빙할 수 있는 것입니다.

클라이언트와 서버는 고정된 기계가 아니라 역할입니다. 클라이언트는 요청을 시작하는 모든 것이고, 서버는 요청을 기다렸다가 응답을 돌려보내는 모든 것입니다. 같은 물리적 컴퓨터가 한 연결에서는 서버이고 다른 연결에서는 클라이언트일 수 있습니다. 예를 들어, 웹 서버가 데이터베이스를 호출하는 경우입니다.

모델은 핵심적으로 요청 기반이고 상태가 없습니다(stateless). 상태가 없다는 것은 서버가 각 요청을 독립적으로 처리한다는 뜻입니다. 이전 요청에 대한 것을 서버가 기본적으로 기억하지 않습니다. 이것이 로그인이 나중의 요청에서 다시 확인되어야 하는 이유이며, 보통 클라이언트가 매번 함께 보내는 쿠키나 토큰으로 처리됩니다. 연결 자체가 요청 사이에 컨텍스트를 유지하지 않기 때문입니다. 프로토콜을 상태 없이 유지하는 것이 한 서버가 엄청난 트래픽으로 확장될 수 있게 해줍니다. 왜냐하면 요청 사이에 모든 방문자를 위해 열린 컨텍스트 스레드를 유지할 필요가 없기 때문입니다.

Juno클라이언트와 서버 양쪽이 한 가지 대화를 합니다: 브라우저는 요청하는 클라이언트이고, 서버는 답하는 컴퓨터입니다. 중간에 웨이터가 있는 고객과 주방처럼, 당신은 절대 주방에 들어가지 않고, 주문을 하면 음식이 나옵니다. 이 그림을 계속 기억하세요. 이 페이지의 나머지 내용은 모두 이것의 변형입니다.

Juno클라이언트와 서버 클라이언트가 요청하면 서버가 답장하고, 클라이언트가 항상 먼저 말을 겁니다. 한 서버가 많은 클라이언트를 한 번에 처리하므로, 한 주소가 많은 방문자를 서빙합니다. 뭔가 로드될 때, 당신은 그 왕복의 한 라운드를 보는 것입니다.

Juno클라이언트와 서버 클라이언트와 서버는 상자가 아니라 역할이고, 같은 컴퓨터가 양쪽을 할 수 있습니다. 웹은 기본적으로 상태가 없으므로, 서버는 클라이언트가 매번 증명을 다시 보내지 않으면 요청 사이에 아무것도 기억하지 않습니다. 쿠키나 토큰이 하는 일이 바로 그것입니다. 상태가 없다는 것은 우회해야 할 제약이 아니라, 한 서버가 실제 트래픽을 견딜 수 있게 해주는 것입니다.

URL과 도메인

당신이 입력하는 주소는 URL: 균일 자원 위치입니다. 웹 위의 한 가지 것의 전체 주소이며, 우편 주소가 한 집을 가리키는 방식과 같습니다.

https://scrimba.com/learn을 봅시다. https 부분은 브라우저가 서버와 어떻게 대화해야 하는지입니다. scrimba.com 부분은 도메인이며, 웹사이트의 이름으로 거리와 도시 같은 것입니다. /learn 부분은 특정 페이지로의 경로이며, 집 번호 같은 것입니다. 함께, 그들은 정확히 한 페이지를 가리키고, 입력하는 것은 브라우저에 어디로 가야 하는지 알려줍니다.

**URL**은 부분들로 만들어지고, 이름을 지으면 전체가 읽기 더 쉬워집니다. https://scrimba.com/learn/html을 봅시다:

• https는 스키마: 브라우저가 페이지를 가져오는 데 사용하는 프로토콜입니다.
• scrimba.com은 도메인: 사이트의 사람이 읽을 수 있는 이름입니다.
• /learn/html은 경로: 그 사이트의 어느 페이지입니다.

도메인은 숫자를 대신하는 친근한 것입니다. 모든 서버는 IP 주소로 도달 가능하며, 192.0.2.10 같은 문자열이고, 도메인 이름은 당신이 그것을 외울 필요가 없도록 해줍니다. 도메인을 입력하면, 브라우저는 DNS(도메인 이름 시스템)를 통해 IP 주소를 찾습니다. DNS는 이름을 숫자로 바꾸는 전화번호부 같이 작동합니다.

**URL**은 브라우저가 자원을 찾기 위해 필요한 모든 것을 인코딩하고, 각 부분이 역할을 합니다. https://shop.example.com:443/products?id=42#reviews에서: 스키마는 https이고, shop은 서브도메인이며, example.com은 등록된 도메인이고, 443은 포트이며, /products는 경로이고, ?id=42는 쿼리 문자열이며, #reviews는 프래그먼트입니다.

포트는 서버의 번호가 매겨진 문(443은 HTTPS의 기본값이므로 보통 생략됩니다). 쿼리 문자열은 서버에 매개변수를 전달하며, 서버가 반환하는 것을 바꿀 수 있습니다. 프래그먼트는 # 뒤에 있으며 브라우저만 처리하고 서버로 보내지지 않습니다. 페이지 내 위치를 가리킵니다. 도메인을 IP 주소로 해석하는 것은 DNS(도메인 이름 시스템, 웹의 이름을 숫자로 바꾸는 디렉토리)를 통해 진행되고, 그 조회 자체가 네트워크 왕복이므로, 차가운 DNS 해석은 페이지의 첫 바이트가 도착하기 전에 사용자가 지불하는 지연입니다. 해부학을 아는 것은 실용적입니다: 서버가 볼 수 있는 것(경로와 쿼리), 볼 수 없는 것(프래그먼트), 그리고 느린 첫 로드가 숨을 수 있는 곳을 알려줍니다.

JunoURL과 도메인 URL은 한 페이지의 전체 주소입니다. https는 서버와 대화하는 방식을 말하고, scrimba.com 같은 도메인은 사이트의 이름이며, /learn 같은 경로는 그것의 한 페이지를 가리킵니다. 왼쪽에서 오른쪽으로 읽으면 브라우저가 정확히 어디로 가는지 알려줍니다.

JunoURL과 도메인 URL은 스키마, 도메인, 경로로 나뉘고, 그 부분들을 보면 어떤 주소든 한눈에 읽을 수 있습니다. 도메인은 숫자를 대신하는 친근한 이름입니다: DNS는 scrimba.com을 브라우저가 실제로 도달할 수 있는 IP 주소로 바꾸는 전화번호부입니다. 그 조회는 페이지가 로드되기 전에 조용히 일어납니다.

JunoURL과 도메인 URL의 모든 부분이 자리를 차지합니다: 스키마, 서브도메인, 도메인, 포트, 경로, 쿼리, 프래그먼트. 서버는 경로와 쿼리를 보지만 절대 프래그먼트는 보지 않습니다. # 뒤의 부분은 브라우저에 남기 때문입니다. 그리고 DNS 해석은 실제 왕복이므로, 차가운 조회는 첫 번째 바이트 전에 사용자가 지불하는 지연이며, 첫 로드가 느껴질 때 기억할 가치가 있습니다.

요청과 응답 주기

엔터를 누르면, 브라우저는 서버로 **요청**을 보냅니다: "이 페이지를 보내주세요"라고 말하는 짧은 메시지. 서버는 응답을 보냅니다: 페이지 그 자체. 그 왕복이 한 번의 완전한 여정이고, 페이지를 열거나 링크를 클릭할 때마다 일어나는 것입니다.

도서관 사서에게 책을 요청하는 것으로 생각해보세요. 제목을 말하고(당신의 요청), 사서가 찾아서 건네줍니다(응답), 이제 당신은 손에 들고 있습니다. 책이 없으면, 사서는 대신 그것을 알려줍니다. 그것도 한 가지 응답입니다. 웹도 같은 방식으로 작동하지만, 훨씬 빠르고 초당 여러 번입니다.

페이지 로드는 하나의 **요청**과 하나의 응답입니다. 브라우저는 원하는 페이지와 원하는 방식을 이름 지으며 요청을 보냅니다. 서버는 페이지가 포함된 응답을 보내고, 요청이 어떻게 되었는지 말하는 상태 코드를 함께 보냅니다.

당신은 세 가지 상태 코드를 계속 볼 것이므로, 먼저 이것들을 배우세요:

• 200 OK: 작동했습니다. 당신이 요청한 것이 여기 있습니다.
• 404 Not Found: 서버는 괜찮지만, 그 주소에는 아무것도 없습니다.
• 301 Moved Permanently: 이 페이지는 이제 다른 곳에 있고, 브라우저는 새 주소로 따라가야 합니다.

서버가 보통 페이지에 대해 보내는 것은 페이지의 그림이 아닙니다. 이것은 HTML로 작성된 평문 문서이며, 당신이 손으로 작성하는 것과 같은 태그입니다. 브라우저는 그 텍스트를 받고 그것으로부터 보이는 페이지를 만듭니다.

**요청**과 응답 주기는 HTTP(HyperText Transfer Protocol)로 정의됩니다: 클라이언트와 서버가 메시지를 어떻게 구성하는지에 대한 동의된 규칙 집합입니다. 요청은 메서드(동사: 가져오기는 GET, 데이터 보내기는 POST), 경로, 그리고 헤더(이름과 값의 쌍으로 메타데이터. 예를 들어 클라이언트가 수용하는 형식)를 전달합니다. 응답은 상태 코드, 자신의 헤더, 그리고 보통 바디(실제 콘텐츠)를 전달합니다.

상태 코드는 범위로 나오고, 범위는 당신이 누구를 봐야 하는지 알려줍니다. 2xx는 성공입니다(200 OK). 3xx는 리디렉션입니다(301 Moved Permanently는 브라우저와 검색 엔진에 자원이 새로운 정규 주소를 가지고 있다고 알려주므로, SEO를 위해서는 제대로 하는 것이 가치가 있습니다). 4xx는 클라이언트 오류이며, 요청이 잘못되었다는 의미입니다(404 Not Found, 403 Forbidden). 5xx는 서버 오류이며, 요청은 괜찮지만 서버가 실패했다는 의미입니다(500 Internal Server Error). 구분은 실용적입니다: 4xx는 당신을 요청으로 향하게 하고, 5xx는 당신을 서버로 향하게 합니다. 문서에 대한 응답 바디는 HTML 텍스트이고, Content-Type 헤더는 브라우저에게 평문이나 이미지가 아니라 HTML로 처리하도록 하는 것입니다. 알아두면 한 가지 더: HTTP는 와이어를 통해 모든 것을 읽을 수 있게 보내고, HTTPS는 같은 프로토콜을 암호화로 감싸서 사이에 있는 누구도 읽거나 변조할 수 없게 하므로, 모든 실제 사이트가 오늘날 HTTPS를 사용하는 이유입니다.

Juno요청과 응답 주기 모든 페이지는 왕복입니다: 브라우저는 이것을 보내주세요라고 말하는 요청을 보내고, 서버는 페이지가 포함된 응답을 보냅니다. 도서관 사서에게 책을 요청해서 건네받거나, 여기 없다고 말해지는 것처럼. 그 왕복은 페이지를 열 때마다 일어나며, 조용하고 빠릅니다.

Juno요청과 응답 주기 나가는 요청 하나, 돌아오는 응답 하나이며, 상태 코드가 붙습니다. 200(작동했음), 404(그 주소에는 아무것도 없음), 301(이동함, 나를 따라오세요) 먼저 배우세요. 당신이 볼 대부분의 것을 다룹니다. 그리고 페이지에 대해 실제로 돌아오는 것은 그림이 아니라 평문 HTML이며, 브라우저가 그것을 뷰로 만든다는 것을 기억하세요.

Juno요청과 응답 주기 HTTP는 여정의 문법입니다: 요청은 메서드, 경로, 헤더를 가지고, 응답은 상태 코드, 헤더, 바디를 가집니다. 상태 코드를 범위로 읽으세요. 4xx는 요청을 고치라는 뜻이고, 5xx는 서버가 넘어졌다는 뜻이며, 그 분할은 당신이 어디를 봐야 하는지 알려줍니다. 바디는 Content-Type으로 태그된 HTML 텍스트이고, HTTPS는 암호화가 감싸진 HTTP이므로, 모든 실제 사이트가 사용합니다.

브라우저가 받은 HTML로 하는 것

응답은 페이지만큼의 HTML 텍스트입니다. 브라우저는 그 텍스트를 위에서 아래로 읽고 화면에 그립니다: 제목 태그를 보고 크고 굵은 텍스트를 보여주고, 단락 태그를 보고 본문 텍스트의 줄을 보여주고, 이미지 태그를 보고 사진을 가져옵니다.

레시피를 읽고 요리하는 것으로 생각할 수 있습니다. 텍스트는 식사 그 자체가 아니라 식사에 대한 설명이고, 브라우저는 그 설명을 실제로 볼 수 있고 사용할 수 있는 것으로 바꾸는 요리사입니다. 같은 HTML은 항상 같은 페이지를 만듭니다. 브라우저가 매번 같은 지침을 따르기 때문입니다.

브라우저는 HTML 텍스트를 보이지 않고, 그것으로부터 페이지를 만듭니다. 문서를 위에서 아래로 읽으면서, 태그를 **DOM**으로 바꿉니다. DOM(Document Object Model): 메모리에 유지되는 페이지의 요소의 살아있는 나무입니다. DOM이 실제로 표시되고 CSS와 JavaScript가 나중에 읽고 변경하는 것입니다.

순서가 여기서 중요합니다. 브라우저는 당신이 작성한 순서대로 문서를 읽으므로, 위쪽에 있는 <script> 또는 스타일시트는 아래 콘텐츠보다 먼저 다루어집니다. 이것이 페이지가 페이지에 대한 정보를 <head>에 두고 보이는 콘텐츠를 <body>에 두는 실제 이유이고, 태그를 배치하는 것이 효과가 일어나는 시기에 영향을 미치는 이유입니다. 당신은 단순히 요소를 나열하는 것이 아니라 브라우저에 읽는 순서를 주는 것입니다.

HTML을 픽셀로 바꾸는 것은 파이프라인이고, 그 모양을 아는 것은 어떤 페이지가 더 느리게 칠해지는지 알려줍니다. 브라우저는 HTML 텍스트를 파싱하고(읽고 구조를 만들고) DOM(Document Object Model: 모든 요소의 메모리 내 나무)으로 바꿉니다. CSS를 평행한 나무로 파싱하고, 둘을 합치고, 기하학을 계산하고(레이아웃: 각 상자가 어디에 앉는지), 마지막으로 픽셀을 화면에 칠합니다.

파서가 위에서 아래로 읽기 때문에, 배치가 시기를 바꿉니다. 자원은 브라우저가 그 자원을 마칠 때까지 콘텐츠를 칠하지 않을 때 렌더링 차단입니다. <head>의 스타일시트는 설계상 렌더링을 차단하므로 페이지가 스타일 없이 깜빡거리지 않지만, 느린 것은 전체 첫 칠을 멈춥니다. <head>의 고전적인 <script>는 더 나쁩니다: 파서는 멈추고, 스크립트를 다운로드하고 실행하고, 그 다음 다시 시작하므로, 문서의 높은 곳에 있는 스크립트는 아래의 모든 요소를 지연시킵니다(defer와 async 속성이 그 차단을 깨기 위해 존재합니다). 이것이 문서 순서와 <head> 배치가 뭐가 먼저 칠해지는지를 결정하는 이유입니다: 차단 자원 위의 모든 것은 그것을 기다립니다.

이것은 레이턴시와 연결됩니다. 바이트가 사용자에게 여행하는 데 걸리는 시간이며, 어떤 양의 로컬 속도도 제거할 수 없습니다. 모든 요청은 왕복 비용을 가지므로, 더 적은 요청과 더 작고 더 이른 바이트는 페이지가 더 빨리 칠하기 시작한다는 의미입니다. HTML에서 당신이 제어하는 레버는 순서입니다: 사용자가 먼저 봐야 할 것을 문서에 높이 두고, 차단 자원을 그것의 방식에서 멀리하고, 첫 의미 있는 칠은 더 일찍 도착합니다. 더 적고 더 이른 바이트가 이 레이어의 전체 성능 게임입니다.

Juno브라우저가 받은 HTML로 하는 것 돌아오는 HTML은 페이지에 대한 설명이고, 브라우저는 그것을 실제 것으로 바꾸는 요리사입니다. 위에서 아래로 읽습니다: 제목 태그, 크고 굵은 텍스트, 단락 태그, 본문 텍스트, 이미지 태그, 사진 가져오기. 같은 HTML이 들어오면, 같은 페이지가 나옵니다. 매번.

Juno브라우저가 받은 HTML로 하는 것 브라우저는 HTML을 위에서 아래로 읽고 DOM을 만듭니다. DOM은 실제로 보이는 요소의 살아있는 나무입니다. 순서대로 읽기 때문에, 태그를 배치하는 곳이 그것이 작용하는 시기를 결정합니다. 이것이 head와 body 분할의 실제 이유입니다. 당신은 요소의 더미가 아니라 브라우저에 읽는 순서를 주는 것입니다.

Juno브라우저가 받은 HTML로 하는 것 파싱을 DOM으로, CSS와 합치고, 배치하고, 칠하기: 그 파이프라인이 배치가 시기를 바꾸는 이유입니다. 렌더링 차단 자원 위의 모든 것은 그것을 기다리므로, head에 있는 느린 스타일시트나 평문 <script>는 첫 칠을 멈추고, defer와 async가 하는 일이 그것입니다. 제거할 수 없는 레이턴시를 더하고, 움직임은 항상 같으므로, 더 적고 더 이른 바이트이며, 가장 중요한 것을 문서에 높이 두세요.