브라우저 주소창에 URL을 치면 일어나는 일들
최근에 컴퓨터 네트워크 공부를 다시 하면서 "브라우저 주소창에 URL을 치면 일어나는 일을 아는대로 말 하기"라는 웹 개발자 면접 단골 질문에 대해 다시 생각해보게 되었습니다. 해당 질문을 면접에서 받았을 때 어느정 도 깊이로 말하는게 좋을까 생각했습니다만 한편으로는, 깊이와 상관없이 그냥 브라우저가 웹 화면을 띄우는 과정들을 그냥 다 알아보면 어떨까 싶어서 정리해 봤습니다.
몇몇 프론트엔드 기술 면접 독스에 있는 내용보다 살짝 매운맛이다-라고 생각하고 보시면 좋을 것 같습니다. 이것까지 아실 필요 없을수도 있고요 더 자세하게 정리합니다.
패킷의 길고도 짧은 여행
어떻게 클라이언트의 HTTP 요청 메시지가 서버에 전송되고, 이걸 받은 서버의 HTTP 응답 메시지가 클라이언트에 전송되는지, 그리고 브라우저가 컨텐츠를 표시하는데까지의 모든 과정을 번호순으로 정리해 보았습니다. 조금 자세하지 못하게 요약된 부분도 있기도 해서 관련 레퍼런스, 이미지와 함께 설명하도록 하겠습니다.
1. 브라우저가 주소창에 입력된 URL을 해석한다
주소창에 주소를 치면, 브라우저가 URL을 해독해서 원격지에서 조회할 웹 서버와 파일명, 포트번호(웹서버는 기본적으로 80)을 판단하고 실제 HTTP 메시지 포맷에 맞게 GET 리퀘스트 메시지를 작성할 준비를 합니다.
크롬 브라우저의 경우 브라우저 애플리케이션의 최상위 프로세스인 브라우저 프로세스의 UI 스레드가 주소창에 입력된 입력값을 평가한다고 합니다. 크롬 주소창은 검색창의 역할도 하니 주소창에 친 문자열이 URL인지 검색어인지도 검사합니다.
2. 브라우저가 HTTP GET 요청 메시지 를 작성한다
URL에서 해석한 정보를 바탕으로 해당 자원을 취할 수 있고 HTTP 메시지 포맷에 맞는 상태라인, 헤더, 바디를 가지고있는 GET 리퀘스트 메시지를 작성합니다.
3. 브라우저가 DNS 요청을 OS에 의뢰하고 실행한다
DNS(Domain Name System)는 도메인 주소와 IP 주소를 대응시키기 위한 서버입니다. 인터넷 세상에는 막대한 수의 서버가 있기 때문에 이것을 전부 1대의 DNS 서버에 등록하는 것은 불가능합니다. 도메인을 .
으로 분리하여 계층화된 도메인 정보를 DNS 서버에 정보를 분산시켜 다수의 DNS 서버에 등록합니다. 그리고 DNS 조회 요청이 오면 URL에 해당하는 부분을 따라가며 다수의 DNS 서버가 연대하여 정보가 어디에 등록되어있는지를 찾아내는 구조를 가지고 있습니다.
DNS 요청의 프로토콜은 UDP이고, DNS 서버의 IP 주소는 컴퓨터의 TCP/IP 설정 항목 중 하나라 OS가 이미 알고 있습니다. 엑세스 대상의 웹 서버가 DNS에 등록되어 있으면 IP 주소를 포함한 응답이 오고, 응답은 OS의 DNS 리졸버가 내용을 해석한 후 IP 주소를 추출하여 메모리에 저장하고 브라우저의 프로세스가 접근 할 수 있게 합니다.
브라우저는 직접 네트워크 요청을 할 수 없습니다. DNS 요청을 포함한 모든 네트워크 요청은 OS에 의뢰해서 진행합니다.
4. 브라우저가 OS의 프로토콜 스택에 메시지 송신을 의뢰하고 소켓을 작성한다
TCP/IP에 사용되는 프로토콜 스택의 실제 구현체는 OS단에 존재합니다.
소켓은 두 단말 의 통신 동작을 제어하기 위한 제어 정보의 총체입니다. 통신 제어 정보를 기록하는 메모리 영역을 가리키는 말이기도 합니다. 뭔가 하드웨어적인 개념에 더 가까울 것이라 생각했는데 생각보다는 아니었던 것 같습니다.
클라이언트에서는 DNS조회로 IP 주소를 알아내면 지정된 포트 번호는 서버측 컴퓨터의 프로세스를 특정하기 때문에 서버측 컴퓨터의 어떤 소켓과 접속할지를 지정할 수 있습니다.
통신 종단점의 두 소켓은 파이프로 읽기 쓰기 동작을 거듭하며 데이터를 주고받게 됩니다. OS에서는 소켓이 만들어지면 메모리 영역을 확보하고, 고유한 파일 디스크립터를 통해 소켓을 식별하게 됩니다.
5. TCP 프로토콜 스택은 Three-Way Handshake를 통해 서버와의 연결을 설립한다
TCP 프로토콜은 Three-Way Handshake 악수를 통해 SYN과 ACK 비트를 주고받으면서 각 단말이 통신이 가능한 상태인지 확인합니다. 과정을 간단히 설명하면 다음과 같습니다.
- 처음에 송신처에서 접속 요청 프로세스가 SYN 비트를 1로 만들어 연결 메시지를 전송합니다.
- TCP 헤더를 받은 서버는 포트 번호에 해당하는 소켓을 찾고 필요한 정보를 기록해서 접속 동작이 진행됩니다. 서버가 요청을 수락하면 수신처도 SYN 비트를 1, ACK를 1 만들어서 재전송합니다.
- 서버에서 돌아오는 헤더를 받은 프로세스에서는 SYN이 1이면 접속 성공으로 소켓의 서버 IP 주소나 포트 번호등과 함께 소켓에 접속 완료를 나타내는 제어 정보를 기록합니다.
- 마지막으로 클라이언트는 패킷을 받았다는 것을 알리기 위해 ACK 비트를 1로 만든 TCP 헤더를 반송합니다.
만약 통신 프로토콜이 https라면 https(TLS) 핸드쉐이크도 TCP 핸드쉐이크에 이어서 진행합니다.
6. TCP 프로토콜 스택에서 패킷을 만들고 TCP 헤더를 붙인다.
여기서부터는 OSI 4 계층, 전송 계층의 시작점입니다.
핸드쉐이크를 통해 접속이 성립되었으면 서버로 보내야 하는 데이터(HTTP 메시지)를 TCP로 보낼 수 있는 최대치(MSS)에 맞춰 데이터를 알맞게 자르고 자른 데이터들마다 TCP 헤더를 붙여 몇번째 데이터인지 등등 제어 정보(TCP 헤더)를 덧붙입니다. 첫번째로 데이터를 조각낸 패킷을 만듭니다.
TCP 헤더의 주요한 정보들로는 송수신처의 포트 번호, 데이터 오프셋(데이터의 시작지점), ACK 번호, 6비트짜리 컨트롤 비트(URG, ACK, FIN, SYN, PSH, RST)가 있습니다.
7. IP 프로토콜 스택은 패킷을 더 잘게 나누고 원격지의 MAC 주소를 기반으로 한 MAC 헤더를 붙인다
TCP에서 만든 패킷의 기본적인 단위들을 회선과 네트워크 상황에 맞게 MTU를 기반으로 더 잘게 나누고 더 잘게 나눠진 패킷들에 IP 헤더를 붙입니다. 그런데 단말이 소통하려면 IP주소 뿐 아니라 단말이 가진 네트워크 인터페이스(LAN카드)의 고유한 MAC 주소가 필요합니다.
ARP(Address Resolution Protocol)는 IP 주소를 기반으로 MAC주소를 알아오는 역할을 합니다. ARP는 일단 먼저 같은 네트워크 내부에서 브로드캐스트로 요청을 보내서 원격지 서버가 네트워크 내부에 있으면 해당 단말의 MAC 주소를, 외부에 있으면 네트워크 라우터의 MAC 주소를 가져옵니다. 알아낸 주소를 토대로 MAC 헤더를 패킷들마다 만들어 붙입니다.
IP 헤더의 주요 정보로는 수신처 IP 주소, 4계층 프로토콜 종류, 송신처 IP 주소, 플래그(패킷이 조각으로 나뉜 것인지, 조각으로 나누는 것이 가능한지), 프래그먼트 오프셋(이 패킷의 데이터 부분이 메시지의 맨 앞부분부터 몇번째 바이트인지 나타냄) 등이 있습니다.
8. LAN 어댑터를 통해 바이너리 데이터를 전기신호로 바꾼다
송신측에서 패킷 읽을 타이밍을 잡을 때 쓰는 프리앰블 비트, 패킷의 개시 위치가 어디서부터인지를 알게 해주는 비트, 패킷 오류 검출을 위한 FCS 비트 등 데이터를 추가하여 이진 데이터를 전기신호로 바꿉니다.
그렇지만 아시다시피 LAN 어댑터가 컴퓨터에 무조건 꽂혀있어야만 인터넷을 사용할 수 있는 것은 아닙니다. Wifi나 핸드폰 데이터를 사용한 무선 통신으로도 인터넷을 이용할 수 있는데요.
- Wifi 공유기를 사용하는 경우 : 공유기는 IP 주소 하나를 여러 대의 컴퓨터가 공유해서 인터넷에 접속할 수 있도록 하는 기기입니다. 공유기도 LAN 어댑터가 꽂혀 있습니다. 와이파이를 사용하는 각 단말들은 무선 근거리 통신으로 공유기에 전기신호를 보내고, 공유기를 통해서 LAN 어댑터로 신호가 나갑니다.
- 스마트폰 데이터로 접속하는 경우 : 가장 가까운 기지국으로 전기 신호를 보내고, 기지국은 초고속 유선망과 연결되어 있습니다.