자신의 직무가 백엔드인지, 프론트엔드인지에 따라 설명하는 관점이 달라질 수 있다. (프론트엔드면 렌더링하는 과정이 더 중요하다고 생각한다)

이 글은 백엔드의 관점에 맞춰서 작성되었다.

과정은 다음과 같다

1. 사용자가 웹 브라우저에 www.naver.com 을 입력하면 URL을 해독한다.

HTTP Method는 GET, POST, PUT, DELETE 등이 있지만(총 9개) 일반적으로 브라우저에 URL 주소를 입력하는 것은 GET을 사용한다. 자세한 HTTP Method 정보는 공식문서에서 찾아보길 바란다.

• 만약 www.naver.com/path/to/resource를 입력한다면
  도메인 이름: www.naver.com
  경로: /path/to/resource

이렇게 URL을 해독하는 단계가 먼저 수행된다.

• 만약 www.naver.com을 입력한다면
  도메인 이름 : www.naver.com
  경로: /
  /는 루트 디렉토리를 의미한다.

도메인 이름은 웹서버의 IP 주소를 찾기 위한 용도이고,
경로는 웹서버에서 원하는 리소스에 요청하기 위한 정보로 사용된다.

2. www.naver.com에 대응하는 IP주소를 DNS 서버에 요청한다.

• DNS란?
  DNS(Domain Name System)는 도메인 네임을 IP 주소로 변환해주는 시스템을 말한다.

우선, 브라우저 캐시, 운영체제 캐시를 확인해보고 없으면 마지막 수단으로 DNS 서버에 IP주소를 요청한다는 것을 알고 넘어가자

브라우저 캐시

브라우저는 최근에 방문한 도메인 이름과 해당 도메인의 IP 주소를 저장하여 재방문 시에 사용할 수 있도록 캐싱한다.

사용자가 도메인을 입력하면 브라우저는 자체 캐시를 확인하여 해당 도메인의 IP 주소를 찾는다.

브라우저는 웹 페이지 리소스(HTML, CSS, JavaScript)를 캐싱해놓고 사용자가 같은 페이지를 방문할 때 캐시에서 불러와 렌더링하는데, 추가로 DNS 정보도 따로 캐싱해둔다.

운영체제 캐시

브라우저 캐시에 해당 도메인이 없거나, 브라우저에서 캐시된 정보가 만료되었을 때 운영체제 캐시를 확인한다.

DNS 서버에 IP 주소를 요청

DNS 서버에 요청할때도 DNS 서버의 IP 주소 정보가 필요한데, 이것은 TCP/IP 설정 항목의 하나하나로 컴퓨터에 미리 설정되어 있기 때문에 컴퓨터는 DNS 서버의 IP를 이미 알고있다. (통신사마다 다르다)

우선, DNS 서버는 자주 요청되는 도메인에 대한 조회 결과를 캐싱하고 있다. DNS 서버에 도메인 조회를 요청할 때 DNS 캐시를 확인한다. 하지만, 없다면? 아래 과정을 수행한다.

DNS 서버에 www.naver.com이라는 웹 서버에 관한 정보를 조회하는데, 컴퓨터가 알고있는 DNS 서버(여기서는 가장 가까운 DNS 서버라고 하겠다)는 www.naver.com에 대한 IP주소를 모르기 때문에

1. 가장 가까운 DNS 서버가 루트 도메인의 DNS 서버로 브라우저의 IP 주소 요청 쿼리를 전송한다.
2. 루트 도메인에도 www.naver.com이라는 이름이 등록되어 있지 않지만, com 도메인의 DNS 서버의 IP주소를 알고있기 때문에 해당 IP주소를 가장 가까운 DNS 서버 에게 응답한다.
3. 그럼가장 가까운 DNS 서버는 com 도메인의 DNS 서버로 조회 요청을 보낸다.
4. com 도메인의 DNS 서버도 www.naver.com의 IP주소를 모르기 때문에 naver.com 도메인의 DNS 서버 IP주소를 응답한다.
5. naver.com 도메인의 DNS 서버는 www.naver.com의 IP주소를 알고있기 때문에 가장 가까운 DNS 서버에게 IP 주소를 응답한다.
6. 가장 가까운 DNS 서버는 브라우저(클라이언트)에게 www.naver.com의 IP주소를 응답한다.
7. 이제 브라우저는 IP주소를 찾았다.

결국 최상위 루트 도메인에서 하위 계층으로 내려가면서 최종적으로 도메인 네임에 해당하는 IP주소를 찾게 되는 것이다.

com. kr 등등이 포함된 최상위 도메인(TLD)부터 시작한다고 알고있지만, 사실은 그 위에 루트 도메인이 하나 더 있다.

하위 도메인을 담당하는 DNS 서버의 IP 주소가 상위 DNS 서버에 등록되어 있기 때문에 가능한 일이다. (인터넷에 있는 DNS 서버는 수 만대나 있으니까 다 확인하는건 너무 비효율적이다)

3. IP주소와 포트로 TCP 커넥션을 생성한다.

TCP 커넥션을 수립할때는 3-Way-HandShake 과정이 이루어진다.

TCP Header 정보이다. 참고하자.

그림의 1~3을 따라가면 되지만 자세하게 설명하자면 아래와 같다.

1. 클라이언트가 SYN 패킷를 전송한다.(전송계층 관점으로 볼때는 세그먼트이다) 단, TCP 헤더의 Sequence Number 필드에 initial Sequnce Number(임의의 값)을 채우고 + SYN 플래그 비트값을 1로 세팅하고 넘긴다. 이것이 SYN 패킷이다.
2. 서버는 자신의 패킷를 보낼때 TCP 헤더의 Sequence Number 필드에 마찬가지로 initial Sequence Number(임의의 값)을 채우고 + SYN 플래그 비트값을 1로 세팅하고, Acknowledgement Number 필드에 클라이언트가 보낸 Sequence Number 값을 + 1해서 넘긴다. 또 ACK 플래그 비트를 1로 세팅하고 넘긴다. 이것이 SYN+ACK 패킷이다.
3. 클라이언트는 ACK를 보내는데 Acknowledgement Number 필드에 서버한태 받은 Sequence Number 값을 + 1해서 담고 ACK 플래그 비트를 1로 세팅하고 서버로 보낸다. 이것이 ACK 이다.

이로써 TCP 커넥션이 수립되었고 HTTP 프로토콜을 사용해 통신할 수 있다.

4. 브라우저는 HTTP Request 메시지를 웹서버로 GET 요청한다.

5. 웹서버는 HTTP Response 메시지를 브라우저(클라이언트)에게 응답한다.

6. 브라우저는 받은 응답을 해석하고, 웹 페이지를 렌더링한다.

렌더링 과정에 대한 자세한 내용은 생략한다.

만약 필요하다면, naver d2 - 브라우저는 어떻게 동작하는가?를 살펴보길 바란다.

7. 브라우저와 웹서버간의 TCP 커넥션이 해제된다.

렌더링 과정이 끝나고 마지막에 TCP 커넥션이 해제되는데 이때, 4-Way-Handshake 과정이 이루어진다.

1. 클라이언트는 서버로 데이터를 다 보냈다면, FIN 패킷을 통해 서버와의 연결을 끊겠다고 선언한다.
2. 서버는 즉시 ACK를 보내지만, 서버도 보낼게 있을테니 기다렸다가 다 보내면 자신도 끝낼 준비가 되었다는 신호로 FIN 패킷을 클라이언트에게 보낸다.
3. 그럼 클라이언트는 ACK를 즉시 보내고 일정시간 이후에 연결이 종료된다.

왜 일정시간 이후에 연결이 종료될까?

1. 서버가 FIN 패킷을 보내기전에 보낸 다른 데이터가 아직 도착하지 않았을 수도 있기 때문이다.
2. 클라이언트가 보낸 마지막 ACK가 유실될 수도 있기 때문이다. 만약 유실된다면 서버는 ACK를 받지 못해서 FIN 패킷을 재전송할텐데, 만약 연결이 바로 종료된다면? 서버는 계속 FIN -> 타임아웃 -> FIN -> 타임아웃 -> FIN ...을 반복할 것이기 때문이다. 그래서 이정도면 ACK가 도착했거니 하는 시간동안 기다렸다가 해제된다.

8. www.naver.com의 홈페이지가 화면에 보인다.