Notice
Recent Posts
Recent Comments
Link
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

나나나

[네트워크] 웹의 동작 본문

CS

[네트워크] 웹의 동작

Leenk 2021. 4. 11. 21:16

1. 웹의 동작 원리

http://tcpschool.com/webbasic/works

웹 동작 방식

①② 사용자가 웹 브라우저를 통해 찾고 싶은 웹 페이지의 URL 주소를 입력함.

③ 사용자가 입력한 URL 주소 중에서 도메인 네임(domain name) 부분을 DNS 서버에서 검색함.

④ DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달함.

⑤⑥ 웹 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성함.

이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송됨.

⑦ 이렇게 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환됨.

⑧ 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색함.

⑨⑩ 검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성함.

이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송됨.

⑪ 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환됨.

⑫ 변환된 웹 페이지 데이터는 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됨.

2. URL이란?

  • 웹에 게시된 어떤 자원을 찾기 위해 브라우저에 의해 사용되는 메카니즘
  • URL은 Uniform Resource Locator, 즉 인터넷에서 자원의 위치를 나타낸다. 각각의 유일한 URL은 유일한 자원을 가리킨다. HTML 페이지, CSS 문서, 이미지 등이 그 예시이다. 때때로 존재하지 않는 자원이나 옮겨진 자원을 가리킬 때가 있는데 이를 방지하기 위해 자원과 관련 URL을 웹 서버 관리자가 주의 깊게 관리해야 한다.

기본 URL의 구조

https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_URL

더보기

www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

  • 프로토콜(HTTP, HTTPS, FTP, MAILTO)
    • 브라우저가 어떤 규약을 사용하는지를 명시한다. 프로토콜은 컴퓨터 네트워크에서 데이터를 교환하거나 전송하기 위한 방법들의 세트이다.
  • 도메인 네임(www.example.com)
    • 어떤 웹 서버가 요구되는 지를 가리킨다. 직접 IP 주소를 사용해도 된다. 하지만 편리성을 위해 도메인 네임을 주로 사용한다.
  • Port(:80)
    • 웹서버에서 자원에 접근하기 위해 사용하는 게이트 번호이다. 만약 웹서버가 표준 HTTP포트(80번, HTTPS는 443번이다.)를 사용한다면, 포트 번호는 보통 생략한다. 그렇지 않다면 포트 번호는 필수이다.
  • 자원에 대한 경로(path/to/myfile.html)
    • 웹서버에서 자원에 대한 경로를 나타낸다. 초기의 웹에서는 이러한 경로가 웹서버에서의 물리적 파일 위치를 나타냈다. 하지만 요즘에는 실제 물리적 경로를 나타내지 않고 웹 서버에서 추상화하여 보여준다.
  • 파라미터(?key1=value1)
    • 웹서버에게 제공하는 추가 파라미터들이다. 웹서버는 자원을 반환 하기 전 파라미터들을 사용해 추가적인 작업을 한다. 각각의 웹 서버는 파라미터들에 대한 각자의 규칙이 있다.
  • 앵커(#SomewhereInTheDocument)
    • 자원 자체의 특정 부분에 대한 앵커이다. 일종의 북마크로 생각할 수 있다. 북마크된 지점에 위치한 내용을 보여주기 위해 브라우저에게 방향을 알려준다. 그러면 브라우저는 앵커가 정의된 지점으로 스크롤하는 등의 동작을 한다. #뒤에 오는 부분은 요청과 함께 서버에 보내지지는 않는다.

3. DNS와 동작원리

https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/

  • 웹 브라우저는 IP주소를 통해 상호작용하는데, 숫자인 IP주소보다 읽기 쉬운 형태의 도메인 네임을 이용한다. DNS(Domain Name System)은 사람이 읽기 쉬운 도메인 네임과 IP 주소가 매핑되어 있으며 일종의 전화부호부와 같은 기능을 한다.
  • DNS 서버는 도메인 네임에 대한 요청을 IP주소로 변환하여 최종 사용자가 도베인 네임을 웹 브라우저에 입력할 때 해당 사용자를 어떤 서버에 연결할 것인지를 제어한다. 이 때 이 요청을 '쿼리'라고 부른다.

웹 페이지 로딩과 DNS 서버

  • DNS Recursive Resolver(Recursor) : 리커서(리졸버)는 클라이언트로부터 쿼리를 받도록 고안된 서버이다. 일반적으로, 클라이언트의 DNS 쿼리를 충족시키기 위한 추가 요청을 수행한다.
  • DNS Root Name server : 모든 리커서에게 알려져 있으며 DNS 레코드 검색의 첫 번째 대상이다. 해당 도메인의 확장자에 따라 리커서를 TLD 네임서버에 대한 정보를 담아 응답한다.
  • DNS TLD Name server : 최상위 도메인인 TLD 서버는 특정 IP주소 검색의 다음 단계이며, 호스트 이름의 마지막 부분을 호스팅한다. ex).com .net 루트로부터 응답을 받은 후 해당하는 TLD 네임서버로 쿼리를 보내고 이 네임서버는 해당 도메인의 권한 있는 네임서버를 가리키는 방식으로 응답한다.
  • Authoritative Name server : 최종 이름 서버로 네임 서버 쿼리의 종착점이다. 권한 있는 이름 서버가 요청한 레코드에 대한 엑세스 권한이 있다면, 요청한 호스트 이름의 IP 주소를, 초기 요청을 한 DNS 리커서에게 돌려보낸다.

DNS 조회 단계

  1. 사용자가 웹 브라우저에 www.example.com을 입력한다.
  2. Local DNS에 IP주소가 존재한다면 바로 반환하고 끝내고 없을 경우 다음과 같은 과정을 거친다.
  3. DNS 리졸버는 www.example.com에 대한 쿼리를 Root DNS(.) 서버에 요청한다.
  4. Root DNS 서버는 .com 도메인을 관리하는 TLD DNS 서버의 주소를 담아 응답한다.
  5. 리졸버는 응답받은 TLD DNS 서버에 요청한다
  6. TLD는 권한을 가진 도메인 이름 서버의 IP주소를 담아 응답한다.
  7. 리졸버는 해당 도메인 이름 서버로 쿼리를 요청한다
  8. 도메인 네임에 대한 권한이 있는 네임서버는 IP주소를 리졸버에게 반환한다.
  9. DNS 리졸버는 해당 IP 주소를 웹 브라우저에 반환한다. 사용자에게 좀 더 빠르게 응답할 수 있도록 IP 주소를 캐싱한다.
  10. 브라우저는 받은 IP주소로 www.example.com에 대한 HTTP 요청을 보낸다.
  11. 해당 IP의 서버는 브라우저에서 렌더링할 요청 받을 웹 페이지를 찾아 반환한다.

DNS 쿼리 유형

  • 재귀 쿼리 : 쿼리에 대한 IP주소를 즉각 응답하거나, 다른 서버에게 질의한 결과로 응답한다. 찾고 있는 정보가 없다면 에러 메시지를 보낸다.
  • 반복 쿼리 : 쿼리에 대한 IP주소를 즉각 응답하거나, 해당 작업을 할 수 있는 응답 가능한 다른 DNS 서버에 연결할 수 있도록 한다. 클라이언트는 다수의 DNS 서버들에게 같은 질의를 반복한다.

DNS 캐싱

  • 캐싱의 목적은 데이터를 임시로 저장해 데이터 요청에 대한 성능과 신뢰성을 높이는 것이다.
  • DNS 캐싱은 요청하는 클라이언트와 가까운 곳에 데이터를 저장함으로써 DNS 쿼리를 조기에 확인하고 DNS 쿼리 체인의 추가 쿼리를 막아 로드 시간은 향상되고 대역폭/CPU의 소비는 줄인다.
  • DNS 데이터는 다양한 위치에 캐시될 수 있으며, 각 위치에 TTL(Time To Live)에 의해 결정된 설정 시간 동안 DNS 레코드를 저장한다.

브라우저 DNS 캐싱

최신 웹 브라우저는 DNS레코드를 캐시한다. 이는 캐시를 확인하고 IP 주소에 대한 올바른 오청을 하기 위해 처리해야 할 단계가 적어진다.

운영 체제 수준의 DNS 캐싱

스텁 확인자 혹은 DNS 클라이언트라 불리는 곳에서 쿼리를 처리한다. 스텁 확인자는 요청을 받으면 자체 캐시를 검사하여 레코드의 존재여부를 확인하고 없으면 DNS 쿼리를 ISP 내부의 DNS 재귀 확인자에게 보낸다.

재귀 확인자 DNS 캐싱

DNS쿼리를 수신하면 요청한 호스트-IP주소 변환이 로컬 지속성 계층 내에 있는지 확인한다.

  • A레코드는 없지만 NS레코드는 있는 경우 : DNS 쿼리의 여러 단계를 거치지 않고 해당 이름 서버에 직접 쿼리한다. 불필요한 루트 및 TLD 서버 조회를 방지해 DNS 쿼리 확인이 빨리 이루어진다.
  • NS 레코드가 없고 TLD서버를 가리키는 레코드만 있는 경우 : 루트가 아닌 TLD로 쿼리를 보낸다.

'CS' 카테고리의 다른 글

[네트워크]HTTP 메소드와 멱등성  (0) 2021.04.11
[네트워크]HTTP 헤더  (0) 2021.04.11
[네트워크] TCP  (0) 2021.04.11
[네트워크] TCP와 UDP  (0) 2021.04.11
[네트워크] OSI 7계층  (0) 2021.04.11