개요
웹브라우저 주소창에 www.google.com 과 같이 URL을 입력했을 때 어떤 일이 벌어지는지는 개발자 면접 시 자주 나오는 질문 중 하나입니다.
웹 통신 과정에 대한 전반적인 내용이기 때문에 다양한 답변이 나올 수 있고, 깊게 파면 팔수록 방대한 내용이 나올수 있는데 이번 글에서는 큰 틀에서 흐름을 알아보는 수준으로 정리하고자 합니다.
통신 흐름
1. URL 파싱
사용자가 주소창에 특정 URL을 입력하게 되면 브라우저는 먼저 URL의 구조를 해석하는 과정을 진행합니다.
해당 문자열이 URL인지 일반 검색을 위한 문자열인지 확인하고, 통신을 위한 프로토콜은 어떤 것을 사용하는 지, 도메인은 무엇인지 등을 파싱합니다.
2. DNS Lookup
URL을 파싱한 뒤 도메인에 해당하는 IP를 찾는 과정인 DNS Lookup 과정을 캐시조회, DNS 쿼리 순으로 진행합니다.
📌 캐시 조회
브라우저는 DNS에 쿼리하기 전에 이전에 요청한 적이 있는지 다음과 같은 순서로 캐시를 조회합니다.
1. 웹 브라우저 캐시
-
웹브라우저는 서버에 요청한 정보를 일정 시간동안 내부 디스크에 기록하고 있습니다.
-
해당 디스크 내에는 리소스 (html, css, 이미지 등)와 IP주소 등이 있습니다.
2. OS의 hosts 파일
- 도메인과 IP가 매핑되어 있는 단순 텍스트 파일로, 보통 보안 프로그램에 의해 임의로 수정하지 못하게 되어있다
3. OS의 DNS 캐시
- 윈도우는 터미널에서 ipconfig /displaydns을 치면 조회할 수 있다.
4. 라우터의 DNS 캐시
- 로컬 네트워크에 연결된 라우터의 DNS 캐시를 찾는다.
5. ISP의 DNS 캐시
- ISP는 인터넷 서비스 제공자로 SKT,KT,LG 등이 있다.
📌 DNS 쿼리
만약 캐시가 있다면 더이상 진행하지 않고 캐싱된 IP을 사용하고, 캐시가 없다면 브라우저는 로컬 DNS 서버에게 도메인 정보(FQDN)를 전달하며 IP를 요청합니다.
로컬 DNS 서버는 웹브라우저로부터 FQDN을 받은 뒤, Root 도메인부터 Third-Level 도메인 순으로 각각 DNS 네임서버에 도메인에 맞는 IP를 요청합니다.
각 DNS 네임 서버는 도메인에 매핑된 IP주소가 저장되어 있는지 찾고, 없다면 다음 레벨의 도메인 서버에 대한 정보(IP주소 등)를 로컬 DNS 서버에게 반환합니다.
로컬 DNS 서버는 전달받은 다음 레벨의 DNS 네임서버에게 질의를 해가면서 최종적으로 IP주소를 전달 받습니다.
이 과정을 Recursive Query 라고 합니다.
이렇게 IP 주소를 찾은 뒤에는 로컬 DNS 서버에 캐시를 업데이트하고 브라우저에 찾은 IP를 반환합니다.
3. IP 라우팅을 통해 목적지 까지의 최적의 경로 찾기
DNS를 통해 IP주소는 알아냈지만, 목적지 까지 어떻게 가야하는지는 모르는 상태이기 때문에
라우터의 라우팅 테이블을 통해 해당 서버 네트워크 게이트웨이까지의 최적의 전송 경로를 찾습니다.
4. ARP를 통해 해당 서버의 MAC 주소 알아내기
목적지 서버와 실질적으로 통신하기 위해 ARP 프로토콜을 사용해서 논리적인 IP 주소를 물리적인 MAC 주소로 변환합니다.
웹브라우저가 있는 서버는 ARP 요청 패킷을 생성해서 대상 호스트가 존재하는 네트워크 내에 브로드 캐스트 방식으로 요청합니다.
해당 네트워크 내의 모든 호스트와 라우터들은 ARP 요청을 수락하고, 요청 대상자인 호스트만 IP주소와 MAC 주소를 반환합니다.
5. TCP 소켓 연결
목적지 서버의 MAC 주소와 물리적인 전송 경로까지 알아냈기 때문에, 브라우저는 서버와의 통신을 위해 TCP 소켓 연결을 진행합니다.
TCP 소켓 연결은 TCP 3-way handshake를 통해 진행하고, 만약 HTTPS 프로토콜을 사용한다면 SSL/TLS Handshake 까지 수행합니다.
TCP 3-way handshake 단계는 다음과 같습니다.
1. 클라이언트는 서버에게 접속을 요청하는 SYN 패킷을 보냅니다. 이 때 클라이언트는 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 됩니다.
2. 서버는 클라이언트와 연결을 할 수 있는 포트가 남아있는 지 확인 하고 SYN/ACK 패킷을 사용해서 응답합니다. 이 때 서버는 ACK 응답을 기다리는 SYN_RECEIVED 상태가 됩니다.
3. 클라이언트는 SYN/ACK 패킷을 수신한 뒤, 다시 ACK 패킷을 서버에 보내서 최종적으로 논리적인 연결을 완료합니다. 이 때 서버의 상태는 ESTABLISHED 상태가 된다.
SSL/TLS Handshake 단계는 다음과 같습니다.
1. 클라이언트는 서버에게 자신이 지원하는 암호화 알고리즘 목록을 전달합니다 (Client Hello)
2. 서버는 암호화 알고리즘을 선택해서 클라이언트에게 전달합니다 (Server Hello)
3. 서버는 CA에게 부터 받은 인증서를 클라이언트에게 전달합니다. (Certificate)
4. 클라이언트는 브라우저에 내장된 CA의 공개키로 복호화해서 인증서의 유효성을 검증하고, 서버의 공개키를 가져옵니다
(여기서 서버의 공개키가 인증서 내부에 있다고 가정하고, 서버가 직접 공개키를 건내는 Server Key Exchange 과정은 생략합니다)
5. 클라이언트는 통신 간에 데이터 암호화에 사용 될 대칭키를 생성하고, 대칭키를 서버의 공개키로 암호화 합니다 (Client Key Exchange)
6. 클라이언트는 암호화한 대칭키를 서버에게 전달하고, 서버는 자신의 개인키로 복호화해서 대칭키를 획득합니다 (ChangeCipherSpec, Finished)
7. 이후 서로 교환한 대칭키를 통해 데이터를 암호화 및 복호화 하며 통신을 진행한다 (SSL Handshake 종료)
6. HTTP(s) 프로토콜을 통해 통신
TCP 연결까지 완료 된 이후 브라우저는 HTTP 요청 메시지를 생성하고 목적지 서버로 전달하는 과정을 진행합니다.
웹브라우저가 소켓 라이브러리를 통해 HTTP 메시지를 전송하면, 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에 전달됩니다.
프로토콜 스택은 HTTP 메시지에 제어 정보를 덧붙여서 패킷으로 생성한 뒤, 네트워크 어댑터(LAN / WIFI 어댑터)를 통해 패킷을 전기 신호 또는 무선 신호로 변환하여 송출합니다.
네트워크 어댑터를 통해 송출된 패킷은 공유기 / 스위칭 허브 / 모뎀 등을 통해서 ISP의 라우터로 전달된 뒤 목적지 서버까지 물리적인 전송을 하게 됩니다. (이 때, IP 라우팅과 ARP 를 통해 알아낸 경로와 MAC 주소를 토대로 전송하게 됩니다)
도착지 서버에 패킷이 도착하면 서버의 프로토콜 스택이 패킷을 추출하여 메시지로 복원하고 웹서버의 애플리케이션으로 전달합니다.
웹서버의 애플리케이션은 요청에 대한 HTTP 응답 메시지를 생성한 뒤 동일한 방식으로 웹 브라우저에게 전달합니다.
7. 브라우저 랜더링 및 통신 종료
웹 브라우저는 전달받은 HTTP 응답 메시지를 해석한 뒤, 받은 데이터를 브라우저 화면에 그리는 랜더링을 수행합니다.
모든 요청 및 응답이 완료되면 HTTP(s) 연결을 종료하며 통신을 마무리합니다.
요약
- 주소창에 URL을 입력하면 웹 브라우저는 URL을 해석 하고, DNS Lookup을 통해 도메인에 해당하는 IP 주소를 찾습니다.
- DNS Lookup은 먼저 브라우저 캐시 , OS의 호스트파일, OS DNS 캐시, 공유기/ISP 에 설치된 로컬 DNS 서버의 캐시 순으로 캐싱되어 있는 IP를 찾은 뒤 있다면 바로 브라우저에 반환하고 없다면 로컬 DNS 서버에게 질의합니다.
- 로컬 DNS 서버는 Root 도메인부터 순차적으로 IP주소를 질의하는 Recursive Query를 수행해서 IP주소를 찾은 뒤 캐시에 저장 및 브라우저에 반환 합니다.
- IP 주소를 찾은 이후에는 IP 라우팅을 통해 목적지 까지의 최적의 전송 경로를 알아내고, 실질적인 통신을 위해 ARP 프로토콜을 사용해 목적지 서버의 물리 주소인 MAC주소를 알아내는 과정이 수행됩니다.
- 이렇게 전송 경로와 MAC 주소까지 알아낸 뒤에는 TCP 3-way handshake 와 SSL/TLS handshake를 통해 TCP 소켓을 연결하고, HTTP 메시지를 생성해서 웹 서버에게 요청합니다.
- 이 때 요청한 HTTP 메시지는 프로토콜 스택에 의해 패킷으로 변환되고 네트워크 어댑터, 공유기, 모뎀, 라우터 등의 물리 장비를 통해 목적지 서버로 실제 물리적인 전송을 수행합니다.
- 목적지 서버의 프로토콜 스택은 전달받은 전기/무선 신호를 패킷으로 변환하고, 패킷을 HTTP 메시지로 복원한 뒤 웹 서버 애플리케이션으로 전달합니다.
- 웹 서버의 애플리케이션은 요청을 받은 뒤 그에 해당하는 HTTP 응답 메시지를 동일한 방법을 통해 클라이언트에게 반환합니다.
참고
