월드 와이드 웹(WWW)에서 사용자가 웹 브라우저를 통해 특정 웹 페이지를 보는 과정, 즉 **클라이언트(웹 브라우저)와 서버(웹 서버) 간의 통신 과정(HTTP 통신)**을 단계별로 상세하게 설명합니다. 또한, 이 과정에서 사용되는 **도메인 이름 시스템(DNS)**과 **웹 캐시(Web Cache)**의 역할, 그리고 앱(App)과 웹사이트(Website)의 차이점에 대해서도 알아봅니다.

1. 웹 통신의 기본 복습:
   • 웹은 HTTP(HyperText Transfer Protocol)라는 약속을 통해 HTML 문서를 주고받는 서비스입니다.
   • 웹 브라우저(클라이언트)와 웹 서버 애플리케이션(서버)이 HTTP를 사용하여 통신합니다.
2. 웹 페이지 요청 과정:
   • ① URL 입력: 사용자는 웹 브라우저 주소창에 원하는 웹 페이지의 URL(Uniform Resource Locator)을 입력합니다.
     • URL은 보통 프로토콜://서버주소/파일경로 형태로 구성됩니다.
     • 프로토콜 지정: http, https (암호화된 HTTP), ftp (파일 전송용 프로토콜) 등을 명시합니다. https는 통신 내용을 암호화하여 보안성을 높인 방식입니다.
     • 서버 주소: 원래는 IP 주소를 사용해야 하지만, 사람이 외우기 어려워 **도메인 이름(Domain Name)**을 사용합니다.
   • ② DNS 조회: 웹 브라우저는 입력된 도메인 이름(www.country.com 등)에 해당하는 실제 서버의 IP 주소를 알아내기 위해 **DNS(Domain Name Server)**에 질의합니다.
     • DNS는 전화번호부처럼 도메인 이름과 IP 주소를 매핑하여 관리하는 서버입니다.
     • 컴퓨터 네트워크 설정에는 사용할 DNS 서버의 IP 주소가 미리 설정되어 있어야 합니다. (ISP가 제공하거나, Google DNS 8.8.8.8 등 공개 DNS 사용 가능)
     • DNS는 도메인 이름을 받아 해당 IP 주소를 응답으로 보내줍니다.
   • ③ 도메인 이름 구조 (계층적):
     • 도메인 이름은 점(.)으로 구분된 계층 구조(트리 구조)를 가집니다.
     • 최상위 도메인(Top Level Domain, TLD): .com, .kr 등 가장 마지막 부분. 국가 코드(ccTLD)와 일반(gTLD)으로 나뉩니다. 국제인터넷주소관리기구(ICANN) 등에서 관리합니다.
     • 2단계 도메인(Second Level Domain): mycompany, youtube 등 TLD 바로 앞 부분. 보통 기관/회사 이름이며, 사용료를 내고 구매합니다.
     • 서브 도메인(Sub-domain): www, shop, mail 등 2단계 도메인 소유자가 용도에 맞게 자유롭게 만들어 사용하는 부분입니다.
   • ④ HTTP 요청 메시지 생성 (캡슐화):
     • 웹 브라우저는 알아낸 서버 IP 주소를 이용해 HTTP 요청 메시지를 만듭니다.
     • HTTP 헤더: 요청할 URL, 요청 방식(Method, 예: GET – 정보 요청), 기타 정보 포함.
     • TCP 헤더: 신뢰성 있는 전송을 위해 TCP 사용. 목적지 포트(HTTP: 80, HTTPS: 443), 출발지 포트(랜덤) 포함.
     • IP 헤더: 목적지/출발지 IP 주소 포함.
     • 이더넷 프레임: LAN 통신을 위한 MAC 주소 등 포함. (헤더/트레일러)
   • ⑤ 요청 메시지 전송: 생성된 메시지(패킷)는 인터넷을 통해 해당 웹 서버로 전송됩니다.
3. 웹 서버의 응답 과정:
   • ⑥ 요청 메시지 처리 (역캡슐화): 웹 서버는 수신된 메시지의 각 헤더(이더넷, IP, TCP)를 차례로 제거하며 웹 서버 애플리케이션에 전달합니다.
   • ⑦ HTML 문서 준비: 웹 서버 애플리케이션은 HTTP 헤더의 URL을 확인하고 해당 HTML 문서를 찾습니다.
     • 정적 페이지: 미리 만들어진 HTML 파일 그대로 전송.
     • 동적 페이지: 게시판 목록처럼 내용이 변하는 경우, 프로그래밍을 통해 실시간으로 HTML을 생성하여 전송.
   • ⑧ HTTP 응답 메시지 생성 (캡슐화):
     • HTTP 헤더: 처리 결과 상태 코드(예: 200 OK – 성공), 데이터 종류(MIME-Type, 예: text/html), 문자 인코딩 방식(예: charset=UTF-8) 등 포함.
     • 데이터(Body): 준비된 HTML 문서 내용.
     • TCP, IP, 이더넷 헤더를 덧붙여 응답 메시지(패킷)를 만듭니다.
   • ⑨ 응답 메시지 전송: 생성된 메시지는 웹 브라우저로 전송됩니다.
4. 웹 페이지 표시 과정:
   • ⑩ 응답 메시지 처리 및 렌더링: 웹 브라우저는 수신된 응답 메시지의 헤더들을 제거하고, HTML 문서를 해석(파싱)하여 화면에 표시(렌더링)합니다.
   • ⑪ 추가 파일 요청/수신: HTML 문서 내에 이미지, 동영상, CSS, Javascript 파일 등이 포함되어 있다면, 해당 파일들을 다시 웹 서버에 요청하고 받아와 화면에 적용하는 과정을 반복합니다.
5. 웹 브라우저 호환성 문제:
   • 웹 브라우저 종류(크롬, 엣지, 사파리 등)에 따라 HTML, CSS, JS를 해석하는 방식이 조금씩 달라 같은 웹사이트라도 다르게 보이거나 기능이 작동하지 않는 호환성(크로스 브라우징) 문제가 발생할 수 있습니다. (웹 표준 준수 노력)
6. 웹 캐시 (Web Cache):
   • 필요성: 자주 방문하는 웹사이트의 이미지 등 변경되지 않는 파일들을 매번 서버에서 새로 받아오는 것은 비효율적입니다.
   • 작동 방식: 웹 브라우저는 한 번 받아온 파일들을 컴퓨터의 임시 저장 공간(디스크)에 **캐시(Cache)**로 저장해 둡니다. 다음에 같은 파일을 요청할 때 서버에서 다시 받지 않고 저장된 캐시를 사용합니다.
   • 캐시 업데이트 확인: 파일이 변경되었는지 서버에 확인하고, 변경되었을 경우에만 새로 받아옵니다.
   • 문제점 및 해결: 가끔 캐시 문제로 이전 내용이 보이거나 오류가 발생할 수 있습니다. 이 경우 브라우저의 강력 새로고침 (Ctrl+Shift+R 등) 기능을 사용하면 캐시를 무시하고 모든 파일을 서버에서 새로 받아옵니다.
7. 앱(App) vs 웹사이트(Website):
   • 과거에는 설치해서 사용하는 앱과 웹 브라우저로 접속하는 웹사이트의 기능 차이가 컸습니다.
   • 앱: 설치 불편, 업데이트 번거로움 / 높은 신뢰성, 컴퓨터 자원 활용 용이, 고성능/고기능 구현 가능.
   • 웹사이트: 설치 불필요, 접근 용이 / 보안 제약, 기능/성능 제한.
   • 최근 경향: 웹 기술 발전으로 웹사이트(웹앱)의 기능이 강력해지면서 앱과 웹사이트의 경계가 모호해지고 있습니다.

웹 브라우저를 통해 웹사이트를 보는 과정은 URL 입력, DNS 조회, HTTP 요청/응답 메시지 생성 및 교환, HTML 렌더링 등 여러 복잡한 단계를 거칩니다. 이 과정의 효율성을 높이기 위해 도메인 이름, 웹 캐시 등의 기술이 사용됩니다. 또한, 웹 기술의 발전으로 앱과 웹사이트의 경계가 흐려지고 있습니다.