[ Web ] 주소창에 www.google.com을 입력했을 때 일어나는 일

 

웹 동작 방식

 

웹 브라우저에 www.google.com을 입력했을 때 일어나는 일 

1. 웹 브라우저에 www.google.com을 입력합니다. 

 

2. 웹 브라우저에 Caching된 DNS 기록을 체크합니다.

:: DNS( Domain Name System ) : DNS는 URL들의 이름과 IP주소를 저장하고 있는 데이터베이스입니다. 인터넷에 있는 모든 URL들에게는 고유의 IP주소가 저장되어 있습니다. 이 IP주소를 통해 해당 웹사이트를 호스팅하고 있느느 서버 컴퓨터에 접근 할 수 있습니다. 

ex ) nslookup www.google.com  을 터미널에 입력하면 IP주소를 알 수 있습니다.

 

:: CACHE ( Caching ) : 컴퓨터는 사용자의 명령이 입력되면 CPU는 연산을 하고 동작에 필요한 내용이 RAM에 저장됩니다. 컴퓨터가 발전하면서 CPU의 처리속도가 RAM에 비해 빨라져 왔기 때문에 CPU가 RAM에 접근할 때 병목현상이 일어나게 되었습니다. 이를 방지하기 위해 CPU와 RAM사이에 용량은 작지만 속도가 빠른 작은 메모리를 탑재했는데 이것이 캐시입니다. 캐시에는 CPU캐시, Disk캐시, Browser캐시 등 다양하게 존재합니다.

 

3. 요청한 URL이 캐시에 없으면 ISP의 DNS 서버가 www.google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS Query를 보내줍니다.

ISP의 DNS 서버는 인터넷을 통해 다른 DNS 서버들에게 물어 도메인 이름의 올바른 IP주소를 찾아줍니다. ISP의 DNS 서버를 DNS recursor라고 하며, 다른 DNS 서버를 name server라고 합니다.

 

웹 페이지 로드와 관련된 4개의 DNS서버 ( DNS의 작동원리 )

1. DNS recursor : 도서관의 어딘가에서 특정한 책을 찾아달라고 요청받는 사서로 생각할 수 있습니다. DNS recursor는 웹 브라우저 등의 애플리케이션을 통해 클라이언트 컴퓨터로부터 쿼리를 받도록 고안된 서버입니다. 일반적으로 recursor는 클라이언트의 DNS쿼리를 충족시키기 위해 추가요청을 수행합니다.

2. Root name server : 사람이 읽을 수 있는 호스트 이름을 IP주소로 변환하는 첫 번째 단계입니다. 도서관에서 책장 위치를 가리키는 색인으로 생각할 수 있으며, 일반적으로 특정한 위치에 대한 참조로 사용됩니다.

3. TLD name server : 서버는 도서관 특정 책장으로 생각할 수 있습니다. 이 이름 서버는 특정 IP 주소 검색의 다음 단계이며, 호스트 이름의 마지막 부분을 호스팅합니다. ( naver.com에서 TLD서버는 'com'입니다. )

4. Authoritative name server : 최종 이름 서버로서, 사전처럼 특정 이름을 해당 정의로 변환합니다. 이 서버는 이름 서버 쿼리의 종착점입니다. 이 서버가 요청한 레코드에 대한 액세스 권한이 있다면, 요청한 호스트 이름의 IP주소를 초기에 요청한 DNS recursor에게 돌려 보내줍니다.

 

4. 웹 브라우저가 서버와 TCP Connection 합니다.

TCP/IP( Transmission Control Protocol / Internet Protocol )

TCP/IP는 네트워크 프로토콜 스위트로 온라인상의 안전하고 효율적인 데이터 전송의 필수 요건을 정의합니다.

통신규약에는 여러가지가 있는데 대표적으로 HTTP 프로토콜이며, IP 프로토콜을 사용하는 모든 프로토콜을 총칭하여 TCP/IP 프로토콜 이라고 합니다.

웹 브라우저가 올바른 IP주소를 받게 되면 IP주소에 해당하는 서버와 connection을 빌드하게 됩니다. 브라우저는 인터넷 프로토콜을 사용해서 서버와 연결이 됩니다. 인터넷 프로토콜의 종류는 여러가지지만, 웹 사이트의 HTTP요청의 경우 일반적으로 TCP를 사용합니다.

클라이언트와 서버 간의 데이터 패킷들이 오가려면 TCP Connection이 되어야합니다.

TCP/IP three-way handshake라는 프로세스를 통해서 클라이언트와 서버간의 connection이 이뤄지게 됩니다. ( 클라이언트와 서버가 SYN과 ACK메시지를 가지고 3번의 프로세스를 거친 후에 연결됩니다. )

1. 클라이언트 머신이 SYN 패킷을 서버에 보내고 connection을 열어달라고 요청합니다.
2. 서버가 새로운 connection을 시작할 수 있는 포트가 있으면 SYN/ACK 패킷으로 답장합니다.
3. 클라이언트는 SYN/ACK 패킷을 서버로부터 받으면 서버에게 ACK 패킷을 보내줍니다.

위 과정을 거쳐 TCP connection이 완성됩니다.

 

5. 웹 브라우저가 서버에 HTTP요청을 해줍니다.

TCP로 연결이 되면 데이터를 전송하면 됩니다.

클라이언트의 브라우저는 GET요청을 통해 서버에게 google.com의 웹 페이지를 요구합니다. 요청할 때 비밀 자료들을 포함하던지, form을 제출하는 상황에서는 POST요청을 사용할 수도 있습니다. 이 요청을 할 때 다른 부가적인 정보들도 함께 전달됩니다.

• Browser Identification ( User-Agent Header )
• 받아들일 요청의 종류 ( Accept Header )
• 추가적인 요청을 위해 TCP connection 유지를 요청하는 connection Header
• Browser에서 얻은 Cookie정보
• 기타 등등

 

6. 서버가 요청을 처리하고 Response를 생성합니다.

서버는 웹 서버를 가지고 있습니다. 이들은 브라우저로부터 요청을 받고 Request Handler에 요청을 전달해서 요청을 읽고 Response를 생성하게 됩니다. Request Handler란 ASP.NET, PHP, Ruby등으로 작성된 프로그램을 의미합니다. 이 Request Handler는 요청과 요청의 Header, Cookie를 읽어서 요청이 무엇인지 파악하고 필요하면 서버에 정보를 업데이트 합니다. 그 다음 Response를 특정 포맷( JSON, XML, HTML )으로 작성합니다.

 

7. 생성한 Response를 Client로 보내줍니다.

서버의 Response에 요청한 웹 페이지, Status Code, Compression Type ( Content-Encoding )

어떻게 인코딩 되어 있는지, 어떻게 페이지를 캐싱할지 ( Cache-Control ), 설정할 쿠키가 있다면 쿠키, 개인정보 등이 포함됩니다.

 

Status Code의 응답 상태

• 정보 응답 ( 100 ~ 199 ) Informational Responses : 요청을 받았으며, 프로세스를 계속 진행합니다.
• 성공적인 응답 ( 200 ~ 299 ) Successful Responses : 요청을 성공적으로 받았으며 인식했으며 수행합니다.
• 리다이렉션 메시지 ( 300 ~ 399 ) Redirection Messages : 요청 완료를 위해 추가 작업 조치가 필요합니다.
• 클라이언트 오류 응답 ( 400 ~ 499 ) Client Error Responses : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.
• 서버 오류 응답 ( 500 ~ 599 ) Server Error Responses : 서버가 명백히 유효한 요청에 대해 충족을 실패했습니다.

HTTP 상태코드 자세히 보러가기

 

8. 웹 브라우저가 HTML Content를 보여줍니다.

브라우저는 HTML Content를 단계적으로 보여줍니다. 처음에는 HTML의 스켈레톤을 렌더링합니다. 그 다음 HTML Tag들을 체크하고 추가적으로 필요한 웹 페이지 요소들을( 이미지, CSS StyleSheets, Javascript 등 ) GET으로 요청합니다. 이 정적인 파일들은 브라우저에 의해 캐싱이 되서 해당 페이지를 방문할 때 다시 서버로부터 불러와지지 않도록 합니다. 그 다음 google이 렌더링 됩니다.