https://coffeedevelop.tistory.com/category/Java&Spring 을 브라우저에 입력하면 어떻게 될까요?
Step1. URL 구성요소
https://coffeedevelop.tistory.com/category/Java%26Spring
↓ ↓ ↓ ↓
[프로토콜]://[호스트(도메인)] [경로] [리소스]
- 프로토콜 : https://는 통신 프로토콜입니다. HTTPS는 Hypertext Transfer Protocol Secure를 나타냅니다. 이 스키마는 브라우저에 전송 계층 보안(TLS)을 사용하여 서버에 연결하도록 지시합니다. TLS는 인터넷을 통한 통신을 보호하는 암호화 프로토콜입니다.
- 호스트 : 웹 사이트의 도메인 이름입니다. 이 도메인 이름을 가지고 특정 서버의 IP 주소를 찾을 수 있습니다.
- 경로 : 해당 서버에서 리소스를 구분하는 경로입니다. 이를 컴퓨터에 있는 파일의 디렉터리 구조나 기타 디렉터리처럼 생각할 수 있습니다. 정적 HTML, CSS, Javascript, 이미지 파일, 동적으로 생성된 콘텐츠에 상관없이 리소스를 구성하는 방법입니다.
- 리소스 : 보려고 하는 웹사이트의 리소스입니다. 리소스에 .html 과 같은 확장자가 있을 수도 있는데 이는 서버에 있는 파일을 나타냅니다. 이 URL과 같은 확장자가 없으면 일반적으로 서버가 이 콘텐츠를 생성했음을 나타냅니다.
Step2. URL → IP 주소 변환 (DNS 과정)
1. 브라우저 캐시 확인 (DNS 프리패치)
- 이전에 방문한 적 있다면 브라우저가 IP 주소를 캐시하고 있을 수 있습니다 → 이때에는 캐시된 주소를 사용합니다.
2. OS의 hosts 파일 확인
- macOS/Linux: /etc/hosts
- Windows: C:\Windows\System32\drivers\etc\hosts
coffeedevelop.tistory.com이 hosts 파일에 있다면, 여기 적힌 IP 주소를 사용함합니다.
3. OS의 DNS 캐시 확인
- 시스템이 관리하는 DNS 캐시 확인 (최근에 같은 도메인을 조회했을 경우)
4. DNS 서버에 질의 (계층적 질의)
브라우저나 OS에서 캐시에도 없으면 설정된 DNS 서버 (예: 8.8.8.8) 로 질의가 전송됩니다.
아래 순서대로 질의를 시작합니다.
- Root DNS 서버 (전 세계에 13개 존재)
- TLD DNS 서버 (.com, .org, .net 등 관리)
- Authoritative DNS 서버 (tistory.com을 관리하는 DNS)
위 질의를 통해 결과적으로 coffeedevelop.tistory.com 도메인이 어떤 서버의 IP 인지 찾게됩니다.
Step3. TCP 3-way Handshake 및 TLS Handshake (HTTPS 보안 연결 수립)
TCP 3-way Handshake
HTTP 또는 HTTPS 는 TCP 위에서 동작하므로 웹서버와 연결을 위해 TCP 3-way Handshake 를 통해 TCP 연결을 합니다.
- 클라이언트 → 서버: SYN (접속 요청)
- 서버 → 클라이언트: SYN + ACK
- 클라이언트 → 서버: ACK
TLS Handshake (HTTPS 보안 연결 수립)
HTTPS를 사용하는 경우 주고 받는 데이터의 암호화를 위한 TLS (Transport Layer Security) 핸드셰이크라는 추가 과정을 수행합니다. 이는 암호화를 할 상호 대상을 확인하는 것입니다.
- 클라이언트 Hello: TLS 버전, 암호화 방식 등 제안
- 서버 Hello: 인증서(SSL/TLS), 공개키 등 전송
- 클라이언트: 인증서 확인 → 대칭키 생성 후 서버에 전달
- 서버: 대칭키로 응답 암호화 → 양방향 암호화 시작
TIP) 연결 재사용
우리가 이용하는 웹 브라우저와 서버가 통신 시 이용하는 HTTP/HTTPS 두 프로토콜은 TCP 핸드쉐이크, TLS 핸드쉐이크를 통해 연결을 합니다. 이 뿐 아니라, DNS lookup 과정도 거치기 때문에 브라우저 요청이 내 서버에 연결하기 까지 꽤 많은 시간이 소요됩니다. 이 시간을 줄이기 위해서 요즘 대부분의 웹 애플리케이션은 연결 재사용을 활용합니다.
TIP) Keep-Alive
연결 재사용을 위해서는 Keep-Alive 를 사용합니다. 이를 명시적으로 서버에서 사용한다고 명시하면, Response Header 로 Connection:keep-alive, Keep-Alive:timout=60, max=100 과 같이 응답됩니다.
그런데 나는 Keep-Alive 설정을 하지 않았은것 같다구요?
괜찮습니다. Response header에 Keep-Alive가 없어도 Timing에 DNS/TCP/SSL이 없고 Stalled만 있으면 연결 재사용이 이루어진 것입니다. HTTP/1.1 이상부터는 Keep-Alive가 기본 동작이라 헤더를 생략하는 경우가 많습니다.
다만, 높은 효과를 보기 위해서는 Keep-Alive는 같은 도메인에 여러 요청을 연속으로 보내는 상황에서 가장 효과적입니다.
정리하자면 아래와 같습니다.
HTTP/1.1부터 기본적으로 연결 재사용이 가능하며, 이를 Keep-Alive라고 합니다.
브라우저에서는 TCP 연결을 유지하여 성능을 높이기 위해 동일한 서버에 대한 요청을 하나의 커넥션으로 묶습니다.
크롬의 Timing 탭에서 Stalled만 있고 Connecting, SSL 등의 단계가 생략된 경우, 커넥션이 재사용된 것으로 간주할 수 있습니다.
높은 효과를 보기 위해서는 Keep-Alive는 같은 도메인에 여러 요청을 연속으로 보내는 상황에서 가장 효과적입니다.
STEP 4. HTTP 요청 전송
TLS가 수립된 후, 이제 HTTP 요청이 전송됩니다.
GET /category/Java&Spring HTTP/1.1
Host: coffeedevelop.tistory.com
User-Agent: Mozilla/5.0 ...
Accept: */*
Cookie: JSESSIONID=...
이 요청은 TLS로 암호화되어 전송되므로, wireshark 같은 툴로 확인 시 네트워크 패킷 상에서는 평문으로 보이지 않습니다.
STEP 5. 서버에서 요청 처리 후 응답
- 도메인 이름 기반으로 가상 호스트 라우팅
- tistory.com 서버는 여러 서브도메인을 가질 수 있으므로, Host 헤더 기준으로 해당 서브도메인의 서비스로 라우팅
- 경로 분석
- /category/Java&Spring → Spring 관련 글이 포함된 Java 카테고리 리스트 페이지로 인식
- 백엔드 로직 처리
- 백엔드에서 데이터를 처리 하여 생성한 html 형태의 콘텐츠로 요청을 처리합니다.
- 호출한 경로가 REST API 라면, xml 이나 json 같은 형태의 콘텐츠로 요청을 처리합니다.
STEP 6. 브라우저가 파싱하여 렌더링 및 후속 요청
- 서버에서 HTML 을 수신 받았다면 HTML 에 포함된 css, js, img 등 후속 리소스들에 대한 요청을 하여 화면을 렌더링하여 구성합니다.
- HTML 응답이 아니라면 렌더링하지 않고, XML/JSON 텍스트를 그대로 출력하거나 다운로드합니다.