1) 링크를 클릭하면, 브라우저가 제일 먼저 하는 일
1-1) URL 해석
예: https://example.com/products/123
https: 통신 규칙(보안 포함)example.com: 서버 주소(도메인)/products/123: 서버 안에서 “어떤 자원/페이지"를 원하는지
1-2) DNS 조회 (도메인 → IP)
- 브라우저는
example.com이 어느 컴퓨터(IP) 인지 알아야 접속 가능함 - 그래서 캐시(브라우저/OS/공유기) → 없으면 DNS 서버에 물어봐서 IP를 얻음
2) 서버랑 연결 맺기 (네트워크 레벨)
2-1) TCP 연결 + (HTTPS면) TLS 핸드셰이크
- TCP: “연결 통로” 만드는 절차
- TLS(HTTPS): “암호화 통로” 만드는 절차 (인증서 확인 포함)
이 단계가 끝나야 “HTTP 요청"을 보낼 수 있음
3) HTTP 요청/응답 (여기서부터 본격적으로 ‘웹’)
3-1) 브라우저가 HTTP Request를 보냄
대충 이런 느낌(개념적으로):
GET /products/123 HTTP/1.1- Host:
example.com - Cookie: (로그인 세션 등)
- Accept:
text/html/application/json… - 등등 링크 접속 = 보통 GET 요청이라고 생각하면 됨
4) 서버에서는 무슨 일이 일어나냐? (여기가 핵심)
서버는 요청을 받으면 보통 이런 파이프라인을 탐
4-1) Web Server / Reverse Proxy
예: Nginx 같은 게 앞단에서
- 정적 파일(이미지, css, js)은 바로 응답하거나
- 뒤의 애플리케이션 서버로 전달
4-2) 애플리케이션 서버(백엔드 프레임워크)가 라우팅
예: /products/123 이면
- “이 URL은 products 컨트롤러의 detail 핸들러로 보내!” 같은 규칙이 있음
여기서 MVC가 나오면:
- C(Controller): 요청을 받는 창구. 파라미터 읽고, 어떤 로직 실행할지 결정
- M(Model): 데이터/비즈니스 로직, DB 조회, 계산, 규칙 적용
- V(View): 화면(HTML) 만들기(혹은 API면 JSON 만들기)
흐름을 MVC로 말하면 보통 이렇게임:
- Controller가 요청 받음
- Model로부터 필요한 데이터 가져옴 (DB 조회 등)
- View를 랜더링해서 HTML 응답(또는 JSON 응답)
4-3) DB/캐시/외부 API 호출
예: “상품 123의 정보를 달라”
- DB에서 조회하거나
- 캐시(Redis 같은)에서 꺼내거나
- 다른 서비스(API)를 호출해서 합치거나
4-4) 서버가 HTTP Response를 보냄
보통 둘 중 하나가 대표적임
- HTML 응답: “완성된 페이지를 서버가 만들어서” 줌
- JSON 응답: “데이터만 주고, 화면은 브라우저 JS가 조립” (SPA/프론트엔드 분리)
5) 브라우저는 응답을 받고 화면을 그린다
5-1) HTML을 받았다면: 파싱 → 추가 요청 폭발
브라우저가 HTML을 읽다가
<link rel="stylesheet" href="...">(CSS)<script src="...">(JS)<img src="...">(이미지) 같은 걸 보면 추가로 또 요청을 보냄
그래서 페이지 하나가 뜨는 동안 요청이 1번이 아니라 수십~수백 번 나갈 수 있음
5-2) JS가 더 요청하기도 함 (AJAX/fetch)
페이지가 뜬 뒤에
- “댓글 불러오기”
- “추천 수 갱신” 같은 건 화면 렌더링 후에 JS가 다시 서버에 API 호출해서 채우기도 함
한 줄로 정리하는 “링크 접속의 본질”
브라우저가 서버에게 “이 URL에 해당하는 결과물을 줘” 라고 요청(Request)하고, 서버가 결과(Response)를 주면, 브라우저가 그걸 화면으로 그림