URL을 입력하면 발생하는 일

2021년 4월 29일 · 약 7분

Owner

한동안 이 타이틀의 문서가 유행했다.
프론트엔드를 알고있는지에 대해 지표로 확인되는 것 같고, 네트워크와 브라우저의 렌더링 기법까지 알아야하기 때문에 확산되는 듯한데 정작 가장 중요한 캐시레이어에 대한 정보가 없었다.

플로우

핸드폰이 RRC 유휴상태에 있으므로 폰의 무선 전파가 근처의 중계탑과 동기화를 마친 다음 요청을 보내 무선 전파 컨텍스트를 성립시킨다.
핸드폰이 중계탑에서 리소스를 할당받고 정해진 데이터율과 전력으로 데이터를 전송할 준비를 마친다.
요청시 패킷
- 코어 네트워크 -> 서빙게이트웨이 -> 패킷게이트웨이 -> 외부 네트워크로 연동된다.
응답시 패킷
- 외부 네트워크 -> 패킷게이트웨이 -> 서빙게이트웨이 -> 이동성관리엔티티 (MME) -> 핸드폰이 유휴상태일 경우 중계탑에 브로드캐스팅 -> 무선 전파 컨텍스트 재수립 -> 사용자 위치를 서빙게이트웨이로 전송 -> 중게탑과 서빙게이트웨이 간에 터널링 -> 핸드폰으로 응답 전송
IP 는 패킷게이트웨이에서 관리한다.
RRC 협상 -> DNS 룩업 -> TCP 핸드쉐이크 -> TLS 핸드쉐이크 -> HTTP 요청 순이다.

쿠키가 있으면 요청과 함께 전송할지 결정한다.
요청에 재사용 가능한 커넥션이 있는지 확인한다.
새 커넥션을 열 수 있는지 확인한다. (HTTP/1.1 의 도메인별 커넥션 상한에 제한되는지 확인)
서버의 IP를 알고 있는지 확인한다.
- 모르는 경우 브라우저 내부 캐시 -> OS 캐시 -> OS 호스트파일을 확인하여 없는 경우 DNS 질의를 시작한다.
- DNS 질의는 네트워크 설정에서 설정된 IP 또는 DHCP 로 지정된 IP 를 확인한다.
- ARP 캐싱이 없는 경우 ARP 요청 프레임을 브로드캐스팅하고 자신의 IP 주소가 요청 프레임과 일치하는 단 하나의 기기는 ARP 응답을 보내면서 캐싱한다.
- IP 데이터그램을 캡슐화하여 네임서버에 질의를 한다.
- DNS 질의는 기본 UDP, 512Bytes 이상일 경우 TCP 를 이용하며 rfc7766 에 정의되어있다.
- 네임서버 -> DNS 리커서 (리졸버) 서버 -> 루트 네임서버 -> 최상위 도메인(TLD) 을 통해 IP 로 반환된다.
IP 주소를 알았으므로 ARP 로 주소를 확인한다.
스위치 -> 라우터 -> 방화벽을 거친다.
소켓을 열고 핸드쉐이크를 시작한다. (1RTT)
대부분의 사이트가 HTTPS 로 서빙되므로 첫 연결에서는 TLS 핸드쉐이크를 시작한다. (1~2RTT)
- TLS 버전, 알고리즘, 압축 방식 협상
- 공개 인증서 반환
- 암호화

HTML, CSS를 파싱한다.
- 하위 리소스를 로드한다.
- 파싱 중 script 태그를 만날 경우 로드하고, 파싱하고, 실행하여 HTML 파싱을 일시적으로 차단한다.
defer JS를 파싱한다.
렌더 트리를 생성한다.
레이아웃을 계산한다.
레이아웃 트리를 순회하며 페인트 레코드 (순서)를 생성한다.
컴포지터 스레드에서 각 레이어를 레스터라이즈한다.
픽셀을 렌더링한다.