[CS] ...하면 생기는 일¶

0. 개요¶

고전적인 인터뷰 질문인 "당신의 브라우저 주소창에 google.com을 치고 엔터를 누르면 어떤 일이 생길까요?"에 대한 답변에 대한 나름의 요약입니다

1. 웹페이지 접속과정¶

클라이언트 request, 서버 response 도식화

이 그림을 보지않고, 그려내고 설명할 수 있다면, 면접에서는 문제 없지 않을까,,??

요청과정 도식화

출처

1,2 . 사용자가 DNS 주소를 주소창에 입력합니다.

3,4 . Application 계층의 HTTP은 DNS 주소에서 도메인 네임에 해당하는 IP주소를 받아옵니다.

5 . HTTP 프로토콜에서 이를 Request 메시지(HTTP 헤더를 가진)로 만들어서 Transport 계층의 TCP로 전달 합니다.

TCP에서 인터넷을 통해 해당되는 IP주소를 가진 서버로 전송합니다. 서버의 TCP는 Application 계층으로 Request를 전달합니다.
HTTP는 Request 정보를 통해 해당되는 URL을 웹서버에 전달합니다.
웹페이지에서는 URL에 해당되는 페이지의 정보를 HTTP로 전달합니다.
HTTP는 Response 메시지로 만들어서 TCP로 전달합니다.

10,11. 역순으로 사용자의 컴퓨터에 Reponse 메시지가 전달되며, 이 데이터로 브라우저에 렌더링하여 보여줍니다.

DNS : 현실적인 비유로는 가게 이름. 가게 이름을 통해서 주소를 찾아보고 이를 통해 해당되는 주소로 이동할수 있듯이. IP주소로 주소를 사용하면 기억하기가 어렵기 때문에 도메인 주소를 사용합니다.

2. 좀 더 DEEP하게.¶

출처

요약그림

2.1 URL 파싱¶

브라우저는 우리가 주소창에 입력한 값이 검색어인지 URL인지 바로 알아차릴 수 없습니다. 주소창에 프로토콜이나 유효한 도메인이 주어지지 않으면, 검색엔진에 입력값을 넘겨줍니다. (주소창에 아무 단어나 치면 크롬에서는 구글 검색결과로 넘어가듯이요) 만일 검색어가 아니라면 아래의 과정을 수행합니다.

HSTS 리스트 점검¶

1) HSTS (HTTPS에 해당하는 URL 리스트)에서 해당 DNS가 있는지 점검합니다.

DNS 검색¶

2) 도메인이 캐시에 들어 있는지 확인합니다.

3) 캐시에 없는 도메인이라면 gethostbyname이라는 라이브러리 함수를 참조합니다.

이 함수는 로컬의 다른 host에서 해당 도메인이 참조될 수 있는지를 확인합니다.

4) 모두 실패하게 되면 DNS에 직접 요청을 보냅니다.

이때 DNS서버가 같은 서브넷에 있다면, DNS서버에 대해 ARP 프로세스를 진행합니다.

DNS서버가 다른 서브넷에 있다면 기본 게이트웨이 IP에 대해 ARP 프로세스를 진행합니다.

2.2 ARP 프로세스¶

ARP 브로드캐스트를 보내기 위해서는 네트워크 스택 라이브러리가 검색할 목적지 IP의 주소를 알아야 합니다. 또, ARP 브로드캐스트를 보내는 데 사용하는 인터페이스의 MAC 주소 역시 알아야 합니다.

1) 캐시에서 검색(있다면, 목적지 IP = MAC)

2) 캐시에 없다면 목적지 IP주소가 로컬 라우트 테이블의 서브넷에 있는지 확인.

3) 라우트 테이블의 서브넷에 있다면, 그 서브넷에 속하는 인터페이스 활용.

없다면, 거븐 게이트웨이의 서브넷에 속하는 인터페이스 활용.

4) 선택한 네트워크 인터페이스의 MAC주소 검색

5) Data Link Layer를 통해 ARP요청

ARP 요청

6) 컴퓨터와 라우터가 직접 연결 : 라우터가 ARP Reply

컴퓨터가 허브에 연결되어 있다면 : 허브가 ARP Reply

컴퓨터가 스위치에 연결되어 있다면 : 스위치가 ARP Reply

ARP 응답

2.3 소켓열기¶

IP주소를 전달받고, 호스트명/포트번호 뽑아내서 socket이라는 시스템 라이브러리 호출.

동시에 TCP 소켓 스트림 AF_INET/AF_INET6 과 SOCK_STREAM을 요청

이제 Transport Layer, Network Layer, Link Layer을 거쳐 출발지/목적지 정보를 저장.

소켓흐름

1) Transport Layer (세그먼트) : 목적지 포트번호, 출발지 포트번호

2) Network Layer(패킷) : 목적지 IP주소, 현재 IP주소

3) Link Layer(프레임) : 머신 NIC의 MAC주소, 로컬 게이트 웨이의 MAC 주소

인터넷을 통해 정보가 전송되므로 패킷으로 전달함.

패킷은 이더넷/와이파이/로컬네트워크를 통해 로컬 서브넷을 관리하는 라우터에 도착한다. 거기서부터, 패킷은 자율 시스템 (AS) 의 보더 라우터까지, 다른 자율 시스템까지, 그리고 결국 마지막으로 목적지 서버에 도달함!! 이때 각 패킷은 IP 헤더내에 TTL이라는 수명을 가지는데, 라우터 하나를 지날때마다 하나씩 줄어들고 TTL이 0이되면 패킷 드랍이 발생한다.

2.4 TLS HandShake¶

서버 클라이언트간의 인증 과정, 일반적이 handshake와 유사하나 내용이 다를 뿐.

1) 클라이언트 → 서버 : transport Layer Security (TLS) 버전, 암호 알고리즘 목록, 가능한 압축 방식

2) 서버 → 클라이언트 : TLS 버전, 암호 알고리즘, 압축 방식 CA (Certificate Authority)가 사인한 공개 인증서

3) 클라이언트 - 서버측 디지털 인증서가 유효한지를, 신뢰할 수 있는 CA 목록을 통해 확인

                   -  신뢰성이 확보되면, 의사 난수 바이트를 생성해 서버의 공개키로 암호화

4) 클라이언트 → 서버 : Finished 메시지보냄 , 교환 내역을 해시한 값을 대칭키로 암호화

5) 서버 : 해시를 생성해 클라이언트에서 도착한 값과 일치하는지 확인

6) 서버 → 클라이언트 : 대칭키를 통해 암호화한 Finished 메시지

이러한 과정이 종료된 후 ,TLS 세션이 대칭키로 암호화된 어플리케이션 (HTTP) 데이터를 전송할 수 있게됨(보안확보!)

2.5 HTTP 프로토콜¶

위에서 만든 패킷과 암호화 과정을 토대로 실제로 HTTP 전송을 시작한다.

유저측 HTTP 프로토콜

1) 만일 구글이 만든 브라우저이면 HTTP에서 SPDY로 업그레이드할지 여부를 확인

그렇지 않다면 HTTP 요청 보냄.

HTTP 요청

2) 요청과 헤더를 보낸 후에, 하나의 빈 줄을 서버에 보내 요청 내용이 모두 보내졌음을 알림.

3) 서버는 HTTP 코드를 통해서 요청에 대해 답변을 함.(캐시에 없을 경우)

HTTP 응답

4) 빈 줄을 하나 붙인 뒤, www.google.com 의 HTML 본문을 페이로드에 담아 보냄.

3') 서버는 HTTP 코드를 통해서 요청에 대해 답변을 함.(캐시에 있을 경우)

4') 브라우저가 자체 캐시에서 HTML 폼을 가져옴

5) 이 과정을 페이지의 모든 정보를 가져올 때 까지 반복

서버측 HTTP 프로토콜

HTTPD의 요청 처리 (HTTPD ? 리눅스용인 Apache나 nginx 그리고 윈도우용인 IIS, 우리가 보통 부르는 웹서버를 의미)

1) 웹서버는 request를 HTTP 메소드, 도메인, 페이지로 쪼갬

2) 도메인에 해당되는 가상호스트가 서버에 설정되어 있는지 확인.

3) request한 HTTP 메소드를 도메인이 수행할 수 있는지 확인

4) 클라이언트에서 HTTP 메소드가 허용되는지 확인.

5) 확인 과정을 거친후 request한 정보에 대응되는 내용을 가져옴.

6) 최종적으로 내용을 분석한후 클라이언트에 넘겨줌

2.6 브라우저 렌더링¶

이후에는 우리가 알 듯이 브라우저에서 렌더링하는 과정이 발생합니다.

이 글에서는 브라우저의 렌더링 과정은 생략하도록 하겠습니다.

출처¶

주의! 상상 그 이상으로 자세합니다.. 🤣🤣🤣

원본 : https://github.com/alex/what-happens-when

번역본 : https://github.com/SantonyChoi/what-happens-when-KR

작성자: 신태범

작성일: 2021-07-11