신입 개발자 면접 질문 예상 목록에 항상 있는 "주소창에 google.com을 검색하면 일어나는 일"을 정리해 보겠습니다. 네트워크 관련 질문이므로 '네트워크'를 가장 자신 있는 과목으로 뽑는다면 이 질문을 받을 가능성이 높아보입니다. 유명한 면접 질문인 만큼 이 과정을 정리한 블로그들이 이미 많지만 저 역시 작성해보고자 합니다.
과정 정리(& 목차)
- IP 주소를 찾는다. (resolving한다)
- 브라우저 로컬 캐시에서 해당 URL의 IP 주소를 찾는다. (이후 운영 체제 캐시를 확인한다)
- 캐시에서 찾지 못하면, ISP의 DNS 서버에 쿼리를 날려 IP 주소를 찾는다.
- 브라우저는 IP주소의 서버와 TCP 연결을 한다.
- 연결이 되면 브라우저는 HTTP 요청을 한다.
- 서버는 브라우저에 HTTP 응답을 보낸다.
- 브라우저는 받은 리소스(HTML 문서)를 파싱하고 화면에 렌더링한다.
위 5가지 과정은 면접을 준비한다면 답변으로 꼭 기억해 줍시다.
1. IP 주소를 찾는다.(resolving한다)
google.com같은 문자열로 구성된 '도메인 네임'을 IP 주소로 리졸빙하기 위해서
1) 로컬 DNS에 물어보고, 없다면
2) root 네임 서버에 물어보고, 없다면
3) TLD 네임 서버에 물어보고, 없다면
3) 책임 네임 서버에 최종적으로 물어서 답을 받습니다.
위 과정에서 더 빠른 답을 받기 위해서 각 서버는 DNS 캐시를 이용합니다.
도메인 네임이란
google.com, naver.com 같은 우리에게 익숙한 문자열 형태의 주소를 '도메인 네임'이라고 부릅니다.
도메인 주소는 숫자로 구성된 IP 주소에 비해 기억하기 쉽고, 변하지 않는다는 장점이 있습니다.
도메인 네임에 해당하는 IP 주소를 찾는 과정(resolving 과정)
IP 주소를 모르는 상태에서 도메인 네임에 대응하는 IP 주소를 찾는 과정을 '도메인 네임을 resolving 한다'라고 합니다.
browser(client)는 가장 먼저 1) 로컬 DNS 서버에 물어보고 없다면 2) 루트 도메인을 관장하는 root 네임 서버에 물어봅니다. 3) 루트 네임 서버에도 모른다면 최상위 도메인을 다루는 TLD 네임 서버에 물어보고, 최종적으로 4) 특정 도메인 zone을 관리하는 책임 네임 서버에 물어봅니다. 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임서버입니다.
위와 같이 질의를 하며 IP 주소를 리졸빙하는 과정은 "재귀적 질의"와 "반복적 질의" 방식이 있습니다.
DNS 캐시
리졸빙을 할 때 재귀적 질의나 반복적 질의를 해서 IP 주소를 얻을 수 있다면, 시간이 오래 걸리고 네트워크 상 메시지 수가 엄청 늘어날 수 있습니다. 특히 전세계에서 사용하는 google 접속의 경우 과부하가 걸릴 것입니다. 그렇기에 각 DNS 서버는 기존에 응답받은 결과를 임시로 저장했다가 다음 질의에 활용하는 DNS 캐시를 사용합니다. 이 임시저장된 캐시값은 TTL(Time To Live) 시간만큼 보관되어 있습니다.
2. 브라우저는 IP 주소의 서버와 TCP 연결을 한다.
TCP는 4L(전송 계층)의 프로토콜 중 하나로 신뢰성, 연결성을 특징으로 합니다.
손실된 패킷, 손상된 패킷, 중복된 패킷에 대한 처리를 제공하고 패킷 순서를 보장하므로 신뢰성있고,
통신 연결 수립과 연결 종료 과정이 있으므로 연결성이 있습니다.
TCP 연결을 하기 위해서 3-way handshake를 합니다. 이름에서 보이듯 3가지 단계로 이루어져 있습니다.
| 세그먼트 종류 (어떤 제어비트가 1인가) |
설명 | |
| A → B | SYN segment | A가 B에게 연결을 요청하면서 연결 시작을 알리는 제어비트인 SYN을 1로 설정해서 B에게 보낸다. |
| A ← B | SYN segment, ACK segment |
B는 A에게 연결 시작 동작임을 알리고 요청을 동의한다는 표현을 위해 SYN과 ACK 제어비트를 1로 설정해서 보낸다. |
| A → B | ACK segment | A는 자신이 보낸 요청이 확인되었다는 것을 알리기 위해 ACK 제어비트를 1로 설정해서 B에게 보낸다. |
추가적으로 TCP는 연결 종료시에는 4-way handshake를 사용합니다.
3. 연결이 되면 브라우저는 HTTP 요청을 한다.
HTTP는 5L(응용 계층)에서 정보를 주고 받기 위해 사용하는 프로토콜입니다.
HTTP의 중요한 4가지 특성은 아래와 같습니다.
- 요청과 응답 기반 동작: 말 그대로 요청을하면 그에 대한 응답을 주면서 소통한다.
- 미디어 독립적: 주고받을 자원의 특성과 상관없이 자원을 주고받는 수단(interface)자체이다.
- stateless
- 서버가 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다. 각 요청은 다른 것으로 여긴다.
- 만약 각 클라이언트의 상태를 기억한다면 서버는 엄청난 부담이 되어 동시에 여러 클라이언트를 상대하기 어려울 수 있다.
- 지속 연결(킵 얼라이브, keep alive)
- 초기의 HTTP(버전 1.0 이하)는 '비지속 연결'을 했다. 3-way handshake를 통해 TCP 연결 후, 각 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작했다. 즉 요청 1번당 연결 설정과 연결 해제의 과정을 반복해야 했다.
- HTTP 1.1 이상은 '지속 연결(킵 얼라이브)'를 수행해서 더 빠르게 응답할 수 있다.
HTTP로 요청할 때는 아래와 같은 예시 형식으로 요청한다.
GET /google-page HTTP/1.1
HOST: www.google.com
User-Agent: ...
Accept: text/html
첫 줄인 요청 라인은 메서드(공백)요청대상(공백)HTTP버전(줄바꿈)으로 구성된다.
4. 서버는 브라우저에 HTTP 응답을 보낸다.
HTTP 요청에 대한 응답은 상태 라인으로 시작합니다. 상태라인은 HTTP버전(공백)상태코드(공백)이유구문0개이상(줄바꿈)으로 구성되어 있습니다.
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 11111
<!DocType html>
<html>
...
</html>
5. 브라우저는 받은 리소스(HTML 문서)를 파싱하고 화면에 렌더링한다.
브라우저는 HTML 문서를 DOM(Document Object Model)로 파싱하고, HTML 내의 <link>, <script>, <img>같은 태그를 분석해 CSS, JS, 이미지 등의 추가 리소스를 요청한다.
참고자료
학습하는 중이라 부족한 점이 많습니다.
잘못된 것이 있다면 댓글로 알려주시고, 궁금한 것이 있으셔도 댓글로 질문주세요.
'💻️ 프로그래밍' 카테고리의 다른 글
| 신입 개발자 면접 준비를 위한 HTTP와 HTTPS 차이점 (0) | 2024.12.29 |
|---|---|
| HTTP 멱등성(Idempotency): 개념에서 적용까지 (2) | 2024.12.19 |
| 자바 오브젝트 정렬: Comparable과 Comparator (0) | 2024.12.14 |
| Spring Persistence Framework: MyBatis (1) | 2024.12.09 |
| Spring Persistence Framework: Spring Data JPA (4) | 2024.12.05 |
