[네트워크] https://www.google.com/ 을 접속할 때 일어나는 일

💡 면접 단골 문제
💡 OSI 7계층과 연관지어 설명할 수 있어야 함

요약

1. https://www.google.com/ 을 브라우저 주소창에 친다.
2. 브라우저가 URL을 Parsing한다.
3. 브라우저가 HTTP GET Request Message를 작성한다.
4. 브라우저가 캐시에서 DNS 기록을 확인하여 도메인 네임의 IP 주소를 찾는다.
5. 캐시에서 찾지 못한 경우, Local DNS 서버가 DNS query를 날려 재귀적으로 IP 주소를 찾는다.
6. 브라우저가 올바른 IP 주소를 받으면, OS의 프로토콜 스택에 메시지 송신을 의뢰하고 소켓을 작성한다.
7. TCP 프로토콜 스택(프로토콜 스택의 전송계층)이 서버와 TCP connection을 한다.
8. 전송계층에서 패킷을 만들고, 아래 계층으로 내려가면서 패킷의 헤더를 추가하여, 물리계층의 LAN 어댑터로 전송한다.
9. 물리계층의 LAN 어댑터에 의해 전기 신호로 변환되어 송출된다.
10. LAN의 라우터에 패킷이 도달한다.
11. 액세스 회선, 인터넷 접속용 라우터를 통과하여 인터넷의 내부로 중개된다.
12. 패킷이 웹 서버에 도착하고, 요청 메시지가 재조립된다.
13. 웹 서버 어플리케이션은 완성된 요청 메시지를 받고, Response를 작성하여 클라이언트에게 보낸다.
14. 브라우저가 HTML content를 보여준다.

---

정리

📢 1. https://www.google.com/ 을 브라우저 주소창에 친다.

브라우저는 사용자가 주소창에 입력한 정보가 사이트 주소인지 검색어인지 확인한다.
즉, RFC 1738에 따라 유효한 URL이 맞는지 확인한다.

📢 2. 브라우저가 URL을 Parsing한다.

브라우저는 전체 URL을 몇 조각으로 나눠서 사용자가 원하는 위치를 파악한다.(Parsing)

https:// : 브라우저가 어떤 방식으로 웹사이트에 접속해야하는지 알려주는 프로토콜
www. : 대부분의 웹사이트가 굳이 www를 붙이지 않아도 상관없지만, 브라우저는 완전한 주소를 보여주기 위해 굳이 표시한다.
도메인 네임 : google.com에 해당. 모든 웹사이트에는 고유한 도메인 네임이 있다.

📌 인터넷 프로토콜

• HTTP
• HTTPS : HTTP에 데이터 암호화가 추가된 프로토콜. 브라우저에 정보를 암호화하라고 명령해서 해커의 공격을 방지한다.
  
  

📢 3. 브라우저가 HTTP GET Request Message를 작성한다.

브라우저는 GET 요청을 통해 서버에게 www.google.com 웹페이지를 요구한다.

• 비밀 자료들을 포함하던지, form을 제출하는 상황에서는 POST 요청을 사용할 수도 있다.
  
  

📢 4. 브라우저가 캐시에서 DNS 기록을 확인하여 도메인 네임의 IP 주소를 찾는다.

컴퓨터는 도메인 네임을 이해하지 못하고, IP 주소를 이해한다. 따라서 IP 주소를 알아야만 웹사이트에 접속할 수 있다. 브라우저는 4개의 캐시에서 DNS 기록을 확인하여, 도메인 네임에 대응되는 IP 주소를 찾는다.

🔎 1
브라우저 DNS 캐시를 확인한다.

• 브라우저는 일정 기간 동안 DNS 기록을 저장하고 있다.

🔎 2
OS DNS 캐시를 확인한다.

• IP 주소를 찾지 못했다면, 브라우저는 system call을 통해 OS가 저장하고 있는 DNS 기록들의 캐시에 접근한다.
• OS DNS 캐시 파일 : hosts

🔎 3
Router DNS 캐시를 확인한다.

• IP 주소를 찾지 못했다면, DNS 기록을 캐싱하고 있는 router와 통신하여 찾는다.

🔎 4
ISP DNS 캐시를 확인한다.

• IP 주소를 찾지 못했다면, ISP에서 DNS 기록을 찾는다.
• 브라우저가 Local DNS 서버(기지국 DNS서버)에게 해당 도메인의 IP 주소를 물어본다.
• Local DNS 서버에는 해당 IP 주소가 있을 수도, 없을 수도 있다. 있다면 바로 PC에게 해당 IP 주소를 주고, 없다면 다른 DNS 서버들과 통신을 시작한다.
  

📌 DNS(Domain Name System)

• URL들의 이름과 IP주소를 저장하고 있는 데이터베이스
• 도메인 네임을 IP 주소로 변환하기 위해 이용
• 목적 : 편리성

❓ 왜 이렇게 많은 곳에서 캐시를 저장할까?
네트워크 트래픽을 조절하고 데이터 전송 시간을 줄이기 위함이다.

📢 5. 캐시에서 찾지 못한 경우, Local DNS 서버가 DNS query를 날려 재귀적으로 IP 주소를 찾는다.

브라우저는 직접 네트워크 요청을 할 수 없다. DNS 요청을 포함한 모든 네트워크 요청은 OS에 의뢰해서 진행한다.

🔎 1
Local DNS 서버가 Root DNS 서버에게 해당 IP 주소를 물어본다.

• 이를 위해 각 Local DNS 서버에는 Root DNS 서버의 정보(IP 주소)가 미리 설정되어 있어야 한다.

🔎 2
Root DNS 서버가 해당 IP 주소를 모르는 경우, "com 도메인"을 관리하는 DNS 서버에게 물어보라고 응답한다.

• Root DNS 서버 : 나는 몰라.. 대신 google.com의 주소 중 .com의 주소를 알고 있으니, com DNS 서버에게 물어봐!

🔎 3
Local DNS 서버가 "com 도메인을 관리하는 DNS 서버"에게 해당 IP 주소를 물어본다.

🔎 4
해당 DNS 서버가 IP 주소를 모르는 경우, "google.com 도메인"을 관리하는 DNS 서버에게 물어보라고 응답한다.

🔎 5
Local DNS 서버가 "google.com 도메인을 관리하는 DNS 서버"에게 IP 주소를 물어본다.

🔎 6
해당 DNS 서버는 IP 주소를 알려준다.

🔎 7
이를 수신한 Local DNS 서버는 google.com에 대한 IP 주소를 캐싱하고(이후 바로 응답을 줄 수 있도록), IP 주소를 PC에게 전달한다.

📌 DNS query

• 목적
  • Local DNS 서버가 다른 DNS 서버에게 물어봐서 특정 사이트의 IP 주소를 찾는 것이다. 이를 Recursive Query라고 한다.

📌 ISP(Internet Service Provider)

• 인터넷 서비스를 제공하는 주체
• 3개의 계층으로 나눌 수 있다.
  • 3단계 ISP(Tier-3)
    인터넷 전송을 구매하는 제공업체 ex) KT, LG U+ ...
  • 2단계 ISP(Tier-2)
    1단계 ISP와 3단계 ISP를 연결하는 공급자
  • 1단계 ISP(Tier-1)
    다른 1단계 ISP와 인터넷 트래픽을 교환하는 인터넷 제공 업체.
    대서양 인터넷, 해저 케이블과 같은 인프라를 구축한다.

📌 Local DNS 서버

• ISP의 DNS 서버
• DNS recursor라고 부른다.
• 다른 DNS 서버들에게 물어 도메인 네임의 올바른 IP 주소를 찾는 책임을 가진다.
• 컴퓨터의 LAN선을 통해 인터넷이 연결되면, 인터넷을 사용할 수 있게 IP를 할당해주는 통신사(KT, LG U+...) DNS 서버가 등록된다.

📌 DNS Lookup

• Forward DNS Lookup : 도메인 네임을 통해 IP 주소를 알아내는 것
• Reverse DNS Lookup : IP 주소를 통해 도메인 네임을 알아내는 것
  
  

📢 6. 브라우저가 올바른 IP 주소를 받으면, OS의 프로토콜 스택에 메시지 송신을 의뢰하고 소켓을 작성한다.

ㅤ

📌 프로토콜 스택

• OS 내부에 있는 네트워크 제어용 소프트웨어
  
  

📢 7. TCP 프로토콜 스택(프로토콜 스택의 전송계층)이 서버와 TCP connection을 한다.

📌 TCP/IP 3-way handshake

• 클라이언트와 서버간의 데이터 패킷들이 오고 가기 위해서는 TCP connection이 되어야 한다.
• TCP/IP 3-way handshake 프로세스를 통해 클라이언트와 서버간의 connection이 이뤄진다.
• 클라이언트와 서버가 SYN과 ACK 메시지들로 3번의 프로세스를 거친 후 연결된다.
  • 과정

    1. 클라이언트 머신이 SYN 패킷을 서버에 보내고, connection을 open해 달라고 요청한다.
    2. 서버가 새로운 connection을 시작할 port가 있다면 SYN/ACK 패킷으로 응답한다.
    3. 클라이언트가 서버로부터 SYN/ACK 패킷을 받으면, 서버에게 ACK 패킷을 보낸다.
    4. 위 3개의 과정이 완료되면 TCP connection이 완성된다.

📢 8. 전송계층에서 패킷을 만들고, 아래 계층으로 내려가면서 패킷의 헤더를 추가하여, 물리계층의 LAN 어댑터로 전송한다.

🔎 1
전송 계층(TCP 프로토콜 스택)에서 패킷을 만들고, TCP 헤더를 추가한다.

• HTTP 메시지를 TCP로 보낼 수 있는 최대치(MSS)에 맞춰 데이터를 알맞게 자르고, 각각 TCP 헤더를 붙여, 데이터를 조각낸 패킷을 만든다.
• 클라이언트 측 포트 번호(Source Port), 서버 측 포트번호(Destination Port)가 세그먼트라는 이름으로 TCP 헤더에 추가된다.

🔎 2
인터넷 계층(IP 프로토콜 스택)을 통해 송신 측, 수신 측 IP 주소가 헤더에 추가된다.

🔎 3
링크 계층에서 MAC 주소가 헤더에 추가된다.

🔎 4
패킷을 물리계층의 LAN 어댑터로 전송한다.

📢 9. 물리계층의 LAN 어댑터에 의해 전기 신호로 변환되어 송출된다.

📢 10. LAN의 라우터에 패킷이 도달한다.

ㅤ

📌 네트워크

• LAN(Local Area Network) : 가정, 빌딩 안 사무실처럼 좁은 범위의 네트워크
• WAN(Wide Area Network) : ISP가 제공하는 서비스를 사용하여 구축된 넓은 범위의 네트워크
  
  

📢 11. 액세스 회선, 인터넷 접속용 라우터를 통과하여 인터넷의 내부로 중개된다.

라우터를 나간 패킷은 액세스 회선을 통과하여 인터넷의 내부로 중개된다.

📌 액세스 회선

• 인터넷과 LAN을 연결하는 통신회선
  
  

📢 12. 패킷이 웹 서버에 도착하고, 요청 메시지가 재조립된다.

패킷은 고속 라우터들을 거치면서, 최종적으로 목적지 서버가 포함된 네트워크(LAN)의 라우터를 거쳐, 목적지 웹 서버의 단말에 도착한다.

🔎 1
전기신호를 받은 웹 서버의 LAN 어댑터가 전기신호를 변환한다.

🔎 2
올바른 패킷일 경우, OS단의 프로토콜 스택으로 보내진다.

🔎 3
아래 계층에서 위 계층 방향으로 디캡슐레이션이 이루어져 요청 메시지가 재조립된다.

📢 13. 웹 서버 어플리케이션은 완성된 요청 메시지를 받고, Response를 작성하여 클라이언트에게 보낸다.

클라이언트의 요청 과정과 똑같이 진행된다.

📌 웹 서버

• HTTP 또는 HTTPS를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)을 전송해주는 서비스 프로그램
• ex) Apache
  
  

📢 14. 브라우저가 HTML content를 보여준다.

브라우저는 단계적으로 HTML content를 보여준다.
🔎 1
HTML skeleton을 rendering한다.

🔎 2
HTML tag들을 체크하고, GET 방식으로 추가적 웹페이지 정적인 요소들 (이미지, css stylesheet, javascript ..)을 위와 똑같은 과정으로 서버에 요청하고 받아온다.

• 이 정적인 파일들은 브라우저에 의해 캐싱되어 나중에 해당 페이지 방문시 서버로부터 다시 불러오지 않도록 한다.

🔎 3
결과적으로 www.google.com 의 모습이 보인다.

---

참고자료
https://sso-feeling.tistory.com/604
https://velog.io/@woo00oo/%EC%9B%B9-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC
https://hwan-shell.tistory.com/320
https://joonfluence.tistory.com/96
https://velog.io/@syleemk/HTTP-%EC%9D%B8%ED%84%B0%EB%84%B7-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC
https://maxkim-j.github.io/posts/packet-travel