[내가아는 것] 웹 브라우저에 www.naver.com을 입력하면 일어나는 일

오늘 러닝뛰면서 https://www.youtube.com/watch?v=GAyZ_QgYYYo&t=56s 이 영상을 듣기 시작했다.

듣다가 "웹 브라우저에 http://www.naver.com을 입력하면 일어나는 일"을 알려주겠다고 했다.

이말 듣자마자 영상 꺼버리고, 집 돌아오는 내내, 또 샤워하는 내내 생각해봤다.

 

약 1년간 현업에서 일하면서 내가 뭘 얼마나 어디까지 배웠는지 돌이켜보는 좋은 경험이었다.

들어가기 전에 약점부터 정리하자면,

• TLS 핸드셰이크가 정확히 기억 안난다. 큰일났다.
• DNS가 내부적으로 어떻게 동작하는지 잘 모르겠다. ㅋㅋ 그냥 리졸브할 때 FQDN보면서 효율적으로 한다는것 밖에 기억이 안난다.
• 어플리케이션 메모리에 있는 데이터를 커널 메모리로 내린다고 했는데, 이게 어플리케이션 소켓이랑 커널 소켓간의 관계를 생각하고 막 쓴 말이다.
  • tcp 3-way handshake할 때는 아직 소켓이 생성되지 않은 상태이므로, 어플리케이션/커널 소켓 버퍼가 생기지 않은 상태이다.
  • 나중에 소켓 생성 이후 send / receive할 때 어플리케이션/커널 소켓 버퍼 간 데이터 교환이 일어난다.
• 루프백 인터페이스에 요청보내는경우 NIC까지 패킷이 안간다. 커널 내부에서 판단해 루프백인경우 다시 내 컴퓨터로 돌린다.
• DMA는 NIC같은 하드웨어가 OS를 거치지 않고 메모리 데이터에 바로 접근할 수 잇게 끔 해주는 친구다.
  • OS가 메모리에 존재하는 소켓 버퍼 데이터를 DMA가 접근가능한 메모리 주소로 옮겨주고, 알려주면, NIC이 DMA를 써서 데이터를 가져간다.
• https://www.youtube.com/watch?v=YahjHM9UNCA
  • 이 사람은 브라우저의 리다이렉트/캐싱 동작에 대해 상세히 설명해준다. 와 나는 이런거 하나도 모르고 살긴 했다.

 

 

---

내가 답변할려했던 것:

 

 브라우저에 해당 주소를 입력합니다. 해당 주소는 영어로 되어있는데, 이걸 네트워크 주소로 식별하기 위해 DNS에 질의를 합니다. DNS는 FQDN을 보고 IP를 리졸브해줍니다. 이걸 가지고 이제 브라우저에서 해당 IP를 가지는 머신의 443번 포트에 연결을 시도하게 됩니다. 여기서 443번 포트를 말한 이유는, 보통 브라우저 URL입력창에 입력한 주소는 https 프로토콜을 사용해서 연결시도하게 되기 때문입니다.

 

 자, 이 배경상황에서, 사용자의 컴퓨터 기준에서부터 설명하겠습니다.

브라우저는 그 자체로 또 하나의 어플리케이션이기때문에, 리졸브한 ip와 포트를 가지고 해당 서버에 연결을 시도하게 됩니다. https 프로토콜을 사용할 것인데, 이는 tcp 레이어 위의 어플리케이션 레이어 프로토콜이기때문에, 우선 내부적으로 tcp 소켓부터 생성한 후 연결 시도할 것입니다. tcp 3-way handshake를 완성한 기점에서, 다음 레이어의 프로토콜 핸드셰이크를 해야하는데, https이므로 보안계층인 tls 핸드셰이크를 먼저 합니다. 암호 슈트 교환하고, 암호화를 진행해서, 이후 http 프로토콜을 사용해 http 데이터를 주고받게 됩니다. http는 stateless 프로토콜이라 핸드셰이크 과정이 없답니다 하하

 

 이렇게 핸드셰이크하는 과정 및 데이터를 주고받는 모든 과정은 패킷단위로 이뤄지는데, 말씀드리다보니 요 패킷이 어떻게 클라이언트브라우저에서 네이버 서버로 가는지 설명을 못햇네요. 브라우저 어플리케이션에서 연결 요청을 보낼때, 클라이언트 로컬 컴퓨터 내부적으로 OS가 브라우저 어플리케이션 메모리에 연결관련 정보를 커널 메모리로 옮길겁니다. 우리가 패킷을 보내고자 하는 곳은 루프백인터페이스에 속하는게 아니라 외부 네트워크에 속하는 위치이기 때문에? OS가 해당 데이터를 DMA가 접근 가능한 메모리 공간으로 옮겨줍니다. 자 그럼 이제 NIC이 메모리에 존재하는 연결관련 정보를 DMA를 사용해서 가져오고, 이거를 0101010 이진 데이터로 변환해서 뿅뿅쏩니다. 요즘은 광LAN선 많이 쓰니까 빛으로 빵빵쏩니다. 혹은 와이파이로 연결되었다면, 와이파이 대역에 맞게 전자기파를 빵빵 쏩니다. 그때는 공유기라는 집안 로컬 스위치가 고걸 받고요, 음? 내 네트워크에 존재하는 녀석이면 로컬 스위치가 이걸 내부로 다시 돌려줄텐데, 네이버 서버는 우리집 옆에서 시끄럽게 돌아가고있는게 아니니까 외부로 나갈겁니다. 그러면 연결된 주택이나 아파트에 존재하는 라우터로 가고요, 그렇게 여러 홉들을 지나, 네이버 서버가 존재하는 네트워크로 가장 효율적인 경로로 가게 되고, 네이버 서버가 존재하는 네트워크에 진입합니다.

 

 어쨌든, 브라우저에서 보낸 www.naver.com 요청은 사실 해당 서버의 루트 페이지인 /에 get 요청을 보내게 되는거일텐데요, 그래서 바로 프론트엔드 서버로 찌르게 되냐? 아 사실 그게 아닐 것 같습니다. 네이버같은 대형 서비스는 트래픽 제어를 위해 로드밸런서를 먼저 거치도록 할 것 같습니다. 그래서 사실 저건 리버스프록시의 도메인인거죠. 리버스 프록시에 딱 요청 보내면? 해당 프록시가 클라이언트인것처럼 대신 프론트엔드 서버에 get 요청보내주고, 고 서버는 html페이지,css, js등 소스파일 구성해주고, DB에 fetch할 데이터가 있다면 백엔드에 요청 보내고, 그렇게 데이터 돌려받았다면 좀 채우거나 혹은 나중에 채울 수 있도록 하거나 해서 리버스 프록시에 데이터를 다시 보내고, 이걸 다시 네트워크를 타서 클라이언트 브라우저로 보내게 되고, 클라이언트 브라우저가 받은 데이터를 렌더링해주면? 페이지가 보일 것 같습니다.

 

 자!~!근데 놀라운 사실이 하나 더있습니다. www.naver.com을 만약 최근에 접속한 적이 있다면? 렌더링 속도가 무지막지하게 빨라집니다. 클라이언트 브라우저가 get요청과 결과값을 캐싱 해두거든요!

 

정리하면, DNS 해석부터 TCP/TLS 연결, HTTP 요청/응답, 서버 로드밸런서 아키텍처를 거쳐 응답을 받고, 브라우저 렌더링과 캐싱을 통해 최종 페이지가 표시됩니다.