[CORE-009][중급] 주소를 입력하면 웹페이지가 열리는 과정
페이지 정보
본문
[이번 수업]
브라우저에 주소를 입력한 뒤 화면이 보일 때까지 URL 해석, DNS, 연결과 TLS, HTTP, 화면 그리기가 어떻게 이어지는지 한 흐름으로 배웁니다.
[선수지식]
IP 주소, 포트, 파일과 폴더의 뜻을 알면 좋습니다. 터미널 두 개를 열 수 있어야 합니다.
[학습목표]
1. URL의 각 부분이 통신에서 하는 일을 설명한다.
2. DNS부터 HTTP 응답까지의 순서를 연결한다.
3. 로컬 서버 요청을 관찰하고 각 줄의 의미를 읽는다.
[핵심개념]
`https://example.test:443/news?id=7` 같은 URL은 통신 방법인 스킴(`https`), 서버 이름인 호스트, 포트, 자원 경로와 질의로 나뉩니다. 브라우저는 먼저 URL을 해석하고 캐시로 재사용할 응답이 있는지도 확인합니다.
호스트가 도메인 이름이면 DNS가 통신할 IP 주소를 찾습니다. DNS는 이름과 주소 등의 자원 정보를 분산해 관리합니다. 캐시에 답이 없을 때 재귀 확인자가 루트, 최상위 도메인, 권한 있는 이름 서버의 정보를 따라갈 수 있으며, 실제로는 중간 캐시 덕분에 매번 전체 과정을 반복하지 않습니다.
주소를 얻으면 브라우저는 서버와 전송 연결을 준비합니다. HTTPS에서는 TLS가 서버 인증서를 통해 접속 대상의 신원을 확인하고 암호화에 쓸 키를 합의합니다. HTTP 버전에 따라 전송 방식은 다를 수 있지만, 그 위에서 브라우저는 `GET /news?id=7` 같은 요청을 보내고 서버는 상태 코드, 헤더, 본문으로 응답합니다. `200`은 해당 HTTP 요청이 성공했다는 뜻입니다. 리다이렉트나 캐시가 있으면 일부 단계는 달라질 수 있습니다.
받은 HTML은 토큰으로 해석되어 문서 구조가 됩니다. 브라우저는 CSS, JavaScript, 이미지 같은 자원을 발견하면 추가 요청을 보내고, 스타일 계산·배치·그리기를 거쳐 픽셀을 표시합니다. 따라서 첫 응답 성공과 화면 전체 완성은 같은 시점이 아닙니다.
[따라하기]
외부 사이트 대신 빈 폴더를 로컬 웹서버로 열어 봅니다. 첫 번째 터미널에서 실행하세요.
```text
mkdir web-flow-lab
cd web-flow-lab
# Windows
py -m http.server 8000 --bind 127.0.0.1
# macOS 또는 Linux
python3 -m http.server 8000 --bind 127.0.0.1
```
운영체제에 맞는 서버 명령 하나만 실행하고 그대로 둡니다. 두 번째 터미널에서 Windows는 `curl.exe -v http://127.0.0.1:8000/`, macOS와 Linux는 `curl -v http://127.0.0.1:8000/`을 실행합니다. 중요한 예상 결과는 다음과 같습니다.
```text
> GET / HTTP/1.1
> Host: 127.0.0.1:8000
< HTTP/1.0 200 OK
<!DOCTYPE HTML>
```
`127.0.0.1`은 내 컴퓨터를 가리키므로 DNS를 건너뛰고, `http`라서 TLS도 없습니다. `GET /`은 루트 자원을 달라는 요청이며 Python 서버가 폴더 목록 HTML을 돌려줍니다. 서버 터미널에도 `GET / HTTP/1.1`과 `200` 기록이 남습니다. 실습이 끝나면 서버 터미널에서 `Ctrl+C`를 누르세요.
[흔한 실수]
브라우저가 항상 DNS 전체를 새로 조회한다고 생각하면 안 됩니다. 한 HTML 요청만으로 페이지가 완성된다고 보기도 어렵습니다. 이미지·글꼴·스크립트 요청, 캐시, 리다이렉트 때문에 순서와 횟수가 달라집니다. `200`만 보고 화면 기능까지 정상이라고 결론 내리지 말고 브라우저 개발자 도구의 네트워크와 콘솔도 확인하세요.
[보안 주의]
본인 소유의 로컬·격리 환경에서만 실습하세요. 서버를 `0.0.0.0`에 열거나 개인정보가 있는 폴더에서 실행하지 말고 `127.0.0.1`로 제한합니다. 실제 웹에서는 인증서 경고를 무시하지 말고 HTTPS를 확인하세요. URL의 질의 문자열은 기록될 수 있으므로 비밀번호·토큰·개인정보를 넣지 않습니다.
[직접 해볼 과제]
실습 폴더에 제목 하나가 있는 `index.html`과 색상을 지정한 `style.css`를 만드세요. 브라우저 개발자 도구의 네트워크 탭에서 문서와 CSS 요청이 따로 나타나는지 확인하고 상태 코드를 기록하세요.
[확인문제]
1. DNS 캐시가 있으면 전체 이름 조회를 반복하지 않아도 되는 이유는 무엇인가요?
2. HTTPS에서 TLS가 HTTP 요청 전에 수행하는 두 가지 역할은 무엇인가요?
3. HTML 응답이 200이어도 화면 완성이 늦거나 실패할 수 있는 이유는 무엇인가요?
[다음 학습]
다음은 CS-009에서 객체지향과 함수형 사고를 비교합니다.
[공식 참고 자료]
- URL 공식 표준: https://url.spec.whatwg.org/
- DNS 개념 표준: https://www.rfc-editor.org/rfc/rfc1034.html
- TLS 1.3 표준: https://www.rfc-editor.org/rfc/rfc8446.html
- HTTP 의미 표준: https://www.rfc-editor.org/rfc/rfc9110.html
- HTML 해석 표준: https://html.spec.whatwg.org/multipage/parsing.html
- HTML 화면 표시 표준: https://html.spec.whatwg.org/multipage/rendering.html
브라우저에 주소를 입력한 뒤 화면이 보일 때까지 URL 해석, DNS, 연결과 TLS, HTTP, 화면 그리기가 어떻게 이어지는지 한 흐름으로 배웁니다.
[선수지식]
IP 주소, 포트, 파일과 폴더의 뜻을 알면 좋습니다. 터미널 두 개를 열 수 있어야 합니다.
[학습목표]
1. URL의 각 부분이 통신에서 하는 일을 설명한다.
2. DNS부터 HTTP 응답까지의 순서를 연결한다.
3. 로컬 서버 요청을 관찰하고 각 줄의 의미를 읽는다.
[핵심개념]
`https://example.test:443/news?id=7` 같은 URL은 통신 방법인 스킴(`https`), 서버 이름인 호스트, 포트, 자원 경로와 질의로 나뉩니다. 브라우저는 먼저 URL을 해석하고 캐시로 재사용할 응답이 있는지도 확인합니다.
호스트가 도메인 이름이면 DNS가 통신할 IP 주소를 찾습니다. DNS는 이름과 주소 등의 자원 정보를 분산해 관리합니다. 캐시에 답이 없을 때 재귀 확인자가 루트, 최상위 도메인, 권한 있는 이름 서버의 정보를 따라갈 수 있으며, 실제로는 중간 캐시 덕분에 매번 전체 과정을 반복하지 않습니다.
주소를 얻으면 브라우저는 서버와 전송 연결을 준비합니다. HTTPS에서는 TLS가 서버 인증서를 통해 접속 대상의 신원을 확인하고 암호화에 쓸 키를 합의합니다. HTTP 버전에 따라 전송 방식은 다를 수 있지만, 그 위에서 브라우저는 `GET /news?id=7` 같은 요청을 보내고 서버는 상태 코드, 헤더, 본문으로 응답합니다. `200`은 해당 HTTP 요청이 성공했다는 뜻입니다. 리다이렉트나 캐시가 있으면 일부 단계는 달라질 수 있습니다.
받은 HTML은 토큰으로 해석되어 문서 구조가 됩니다. 브라우저는 CSS, JavaScript, 이미지 같은 자원을 발견하면 추가 요청을 보내고, 스타일 계산·배치·그리기를 거쳐 픽셀을 표시합니다. 따라서 첫 응답 성공과 화면 전체 완성은 같은 시점이 아닙니다.
[따라하기]
외부 사이트 대신 빈 폴더를 로컬 웹서버로 열어 봅니다. 첫 번째 터미널에서 실행하세요.
```text
mkdir web-flow-lab
cd web-flow-lab
# Windows
py -m http.server 8000 --bind 127.0.0.1
# macOS 또는 Linux
python3 -m http.server 8000 --bind 127.0.0.1
```
운영체제에 맞는 서버 명령 하나만 실행하고 그대로 둡니다. 두 번째 터미널에서 Windows는 `curl.exe -v http://127.0.0.1:8000/`, macOS와 Linux는 `curl -v http://127.0.0.1:8000/`을 실행합니다. 중요한 예상 결과는 다음과 같습니다.
```text
> GET / HTTP/1.1
> Host: 127.0.0.1:8000
< HTTP/1.0 200 OK
<!DOCTYPE HTML>
```
`127.0.0.1`은 내 컴퓨터를 가리키므로 DNS를 건너뛰고, `http`라서 TLS도 없습니다. `GET /`은 루트 자원을 달라는 요청이며 Python 서버가 폴더 목록 HTML을 돌려줍니다. 서버 터미널에도 `GET / HTTP/1.1`과 `200` 기록이 남습니다. 실습이 끝나면 서버 터미널에서 `Ctrl+C`를 누르세요.
[흔한 실수]
브라우저가 항상 DNS 전체를 새로 조회한다고 생각하면 안 됩니다. 한 HTML 요청만으로 페이지가 완성된다고 보기도 어렵습니다. 이미지·글꼴·스크립트 요청, 캐시, 리다이렉트 때문에 순서와 횟수가 달라집니다. `200`만 보고 화면 기능까지 정상이라고 결론 내리지 말고 브라우저 개발자 도구의 네트워크와 콘솔도 확인하세요.
[보안 주의]
본인 소유의 로컬·격리 환경에서만 실습하세요. 서버를 `0.0.0.0`에 열거나 개인정보가 있는 폴더에서 실행하지 말고 `127.0.0.1`로 제한합니다. 실제 웹에서는 인증서 경고를 무시하지 말고 HTTPS를 확인하세요. URL의 질의 문자열은 기록될 수 있으므로 비밀번호·토큰·개인정보를 넣지 않습니다.
[직접 해볼 과제]
실습 폴더에 제목 하나가 있는 `index.html`과 색상을 지정한 `style.css`를 만드세요. 브라우저 개발자 도구의 네트워크 탭에서 문서와 CSS 요청이 따로 나타나는지 확인하고 상태 코드를 기록하세요.
[확인문제]
1. DNS 캐시가 있으면 전체 이름 조회를 반복하지 않아도 되는 이유는 무엇인가요?
2. HTTPS에서 TLS가 HTTP 요청 전에 수행하는 두 가지 역할은 무엇인가요?
3. HTML 응답이 200이어도 화면 완성이 늦거나 실패할 수 있는 이유는 무엇인가요?
[다음 학습]
다음은 CS-009에서 객체지향과 함수형 사고를 비교합니다.
[공식 참고 자료]
- URL 공식 표준: https://url.spec.whatwg.org/
- DNS 개념 표준: https://www.rfc-editor.org/rfc/rfc1034.html
- TLS 1.3 표준: https://www.rfc-editor.org/rfc/rfc8446.html
- HTTP 의미 표준: https://www.rfc-editor.org/rfc/rfc9110.html
- HTML 해석 표준: https://html.spec.whatwg.org/multipage/parsing.html
- HTML 화면 표시 표준: https://html.spec.whatwg.org/multipage/rendering.html
- 이전글[CS-009][중급] 객체와 함수로 장바구니 만들기 26.09.03
- 다음글[IOT-008][중급] 정해진 시간 안에 작업 끝내기 26.09.03
댓글목록
등록된 댓글이 없습니다.