[Network] 2-4. DNS - The Internet's Directory Service

인간은 다양한 방법으로 식별된다. 출생증명서에 기재된 번호, 신분증, 운전면허 등으로 식별될 수 있다.
각각은 사람들을 식별하는 데 사용될 수 있지만, 특정한 맥락에서는 하나의 식별자가 다른 식별자보다 더 적절할 수 있다.

ex) 미국의 세금 징수 기관 IRS의 컴퓨터들은 출생증명서 이름 대신 고정 길이의 사회보장번호를 사용하는 것을 선호
일반 사람들은 사회보장번호보다 기억하기 쉬운 이름을 선호한다.

인터넷도 마찬가지다. host에 대한 식별자로 hostname을 사용한다. (ex. www.google.com) 이 방법이 특히 사람들에게는 기억하기 쉬운 방법이다.

하지만, hostname은 host의 위치 정보에 대해 별다른 정보를 제공하지 못한다.
ex. www.eurecom.fr은 country code인 fr을 통해 프랑스에서 서비스한다는 정보를 제외하면 위치와 관련된 정보가 없다

게다가 hostname들은 가변길이의 알파벳으로 이뤄져있기 때문에 라우터에 의해 처리되기 어렵다.
때문에 host들은 IP 주소를 통해서 식별된다. IP주소에 대한 자세한 내용은 4장에서 다룬다.

1. Services Provided by DNS

① host이름을 IP주소로 변환하는 서비스 - 주요 서비스

호스트 이름과 IP 주소로 host를 식별하는 각각의 방법을 살펴봤다 .
사람은 host 이름을 가지고 식별하는 걸 좋아하지만, 라우터는 고정된 길이의 계층구조를 가진 IP 주소를 좋아한다.

각각의 방식을 둘 다 이용하기 위해서 호스트 이름을 IP주소로 변환해주는 디렉토리 서비스가 필요하다.
이것이 바로 DNS(Domain Name System)의 주요 서비스이다.

DNS는...

1) DNS 서버들의 계층구조로 구현된 분산 DB
2) host가 분산 DB로 질의(query)하도록 하는 응용프로그램 계층(Application Layer) 프로토콜이다.
3) DNS 서버는 주로 BIND(Berkeley Internet Name Domain) SW를 수행하는 Unix 컴퓨터다
4) DNS 프로토콜은 UDP상에서 수행되고 포트번호는 53번이다.

ex) DNS 사용 예시
사용자의 host에서 수행되는 브라우저 : www.someshcool.edu/index.html 을 요청한다고 하자.

그렇다면, 사용자의 host가 HTTP 요청 메시지를 웹 서버 www.someshcool.edu로 전송될 수 있도록
사용자의 host는 www.someshcool.edu의 IP주소를 얻어야 한다. 이를 위해서 다음과 같이 수행된다.

1) 똑같은 사용자 컴퓨터는 DNS 애플리케이션의 client 부분을 동작한다.
2) 브라우저는 URL로 부터 host의 이름인 www.someshcool.edu를 추출 & 그 이름을 DNS 애플리케이션의 client 부분에 넘긴다.
3) DNS 클라이언트는 DNS 서버로 host 이름을 포함한 질의(query)를 전송한다.
4) DNS 클라이언트는 host 이름에 대한 IP주소를 가진 응답을 받는다.
5) 브라우저가 DNS 클라이언트로 부터 IP주소를 받았다 & 해당 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

② host aliasing

복잡한 이름을 가진 host는 하나 이상의 별명을 가질 수 있다.

ex) relay1.west-coast.enterprise.com ⇒ enterprise.com, www.enterprise.com라는 2개의 host 별명을 갖는다고 하자.

이때 relay1.west-coast.enterprise.com은 정식 호스트 이름(canonical hostname)이 된다.

대체로 별칭 호스트 이름이 정식 호스트 이름보다 기억하기 쉽다.
그래서 DNS는 별칭 호스트 이름을 가지고 질의를 할 때 정식 호스트 이름을 얻기 위해서 사용될 수 있다.

③ Mail Server Aliasing

ex) bob이 yahoo에 계정이 있다면 bob@yahoo.com 라는 이메일 주소를 가질 것이다.

하지만, 야후 메일 서버의 호스트 이름은 더 복잡하다.

DNS는 호스트의 IP주소 뿐만 아니라 메일 애플리케이션에 의해 별칭 호스트 이름에 대한 정식 호스트 이름을 얻기 위해서 사용되기도 한다.

④ Load Distribution

DNS는 replicated Web Server같이 여러 개의 중복 서버들 사이에 부하를 분산하기 위해서도 사용된다.

ex) cnn.com
위와 같은 인기 사이트는 여러 서버에 중복되어 있어서 각각의 서버가 다른 종단 시스템에서 수행되고 다른 IP주소를 갖는다.

중복 웹 서버(Replicated Web Server)는 여러 개의 IP주소가 하나의 정식 호스트 이름과 연관되어 있다.
DNS 데이터베이스는 하나의 호스트 이름에 대한 여러 개의 IP 주소를 모아놓은 IP 주소의 집합을 갖고 있다.

만약에 client가 IP 주소 집합과 매핑되는 host 이름에 대한 DNS 질의를 한다면, 서버는 IP 주소 집합 전체를 갖고 응답한다. 하지만, 각각의 응답은 순환식으로 제공된다.

client는 대체로 주소 집합 내부의 첫 번째 IP주소로 HTTP 요청 메시지를 전송하기 때문에 DNS의 순환 방식은 여러 중복된 서버들 사이에서 트래픽을 분산하는 효과를 낸다.

참고 문서 RFC 1034, RFC 1035

2. DNS 동작 원리 개요

DNS가 어떻게 동작하는지 개괄적으로 살펴보자. 여기서는 Host 이름 ⇒ IP 주소로 변환하는 서비스에 초점을 맞춘다.

ex) 사용자의 host에서 실행되는 애플리케이션이 Host 이름 ⇒ IP 주소로 변환한다고 하자

1) 애플리케이션은 변환될 host 이름을 명시해서 DNS 클라이언트 부분을 호출한다.
2) 사용자 host의 DNS는 host 이름을 포함해서 네트워크에 질의(query) 메시지를 보낸다. 이때, 모든 DNS의 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 전송된다.
3) 어느 정도 시간이 지난 후에 사용자 host의 DNS는 요청한 host 이름과 매핑되는 DNS 응답 메시지를 받는다.
4) 해당 매핑을 애플리케이션에 전달한다.

이러한 동작이 가능하도록 어떻게 구현할 수 있을까?

① 중앙 집중 방식

모든 매핑 정보를 하나의 인터넷 name server에 저장해서 매핑하는 방식.
이러면 client는 모든 query를 하나의 name server에 전송하고 DNS 서버는 해당 query에 대해 응답 메시지를 전송한다.

하지만... 다음과 같은 문제가 있어서 오늘날의 인터넷에서는 이 방법을 사용하지 않는다.

• 서버가 고장나면 전 세계 인터넷이 동작하지 않을 수 있음
• 트래픽양 : 전 세계의 인터넷 트래픽을 감당할 수 없음
• 먼 거리의 중앙 집중 DB : 하나의 서버를 두고 먼 거리에 host가 있다면 당연히 그만큼 지연시간이 길어질 수밖에 없다.
• 유지관리 : 새로운 host가 반영될 때 마다 새롭게 갱신해야 하고 권한 부여 및 인증 문제도 수시로 챙겨야 한다.

때문에 DNS는 무조건 분산되도록 설계되었다. DNS는 분산 DB가 인터넷에서 어떻게 구현될 수 있는지를 보여주는 훌륭한 예시다.

② 분산 계층 데이터베이스

확장성 문제를 다루기 위해 DNS는 많은 서버를 이용해 이들 간에 계층 형태를 구성해서 전 세계에 분산시켰다.
대체로 위 그림처럼 계층으로 구성된 3가지 유형의 DNS 서버가 있다.
(root 서버, 최상위 레벨 도메인 네임(Top-Level Domain, TLD) DNS 서버, 책임(authoritative) DNS 서버)

이 3가지 분류의 서버들이 어떻게 상호작용하는지 알기 위해 DNS client가 host 이름 www.naver.com의 IP 주소를 결정한다고 하자.

1) DNS client는 루트 서버 중 하나에 접속한다.
2) 루트 서버는 최상위 레벨 도메인 com을 갖는 TLD 서버 IP 주소를 보낸다.
3) client는 com을 갖는 TLD 서버 중 하나에 접속하고 서버는 도메인 naver.com을 가진 책임 서버의 IP 주소를 보낸다.
4) client는 naver.com의 책임 서버중 하나에 접속한다.
5) 서버는 호스트 이름 www.naver.com의 IP주소를 보낸다.

3가지 DNS 서버에 대해 더 자세히 알아보자.

① 루트 DNS 서버 : 그림 2.18 에 표기된 것 처럼 1000개 이상의 루트 서버 인스턴스가 전 세계에 흩어져 있다. 루트 네임 서버들과 이를 관리하는 기관과 그들의 IP 주소 목록은 사이트에서 확인할 수 있다. 루트 DNS 서버는 TLD 서버의 IP 주소를 제공한다.

② 최상위 레벨 도메인 (TLD) :

• com, org, net, edu와 같은 상위 레벨 도메인과 kr, uk와 같은 국가의 상위 레벨 도메인에대한 TLD 서버
• Verysign global registry service는 com TLD에 대한 TLD 서버를 담당한다.
• Educause에서는 edu TLD에 대한 TLD 서버를 담당한다.

TLD를 지원하는 네트워크 인프라는 매우 크고 복잡하다.

• 참고
  1) Verysign 네트워크의 개괄
  2) 상위 레벨 도메인 목록

TLD 서버는 책임 DNS 서버에 대한 IP주소를 제공한다.

③ 책임 DNS 서버 : 인터넷을 통해 접근하기 쉬운 host를 가진 모든 기관은 host 이름을 IP주소로 매핑하는 공개적인 DNS 레코드를 제공해야한다. 기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있다.
또한 기관은 이 레코드를 가질 수 있도록 자신의 책임 DNS 서버를 구현할 수 있고 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불한다.

루트, TLD, 책임 DNS 서버들은 모두 DNS 서버들의 계층구조를 갖는다.

DNS의 또 다른 중요한 형태는 로컬 DNS 서버다. 로컬 DNS 서버는 서버들의 계층 구조에 엄격하게 속하지는 않지만 DNS 구조에 있어 중요한 역할을 한다.

ISP(대학 ISP 또는 주거지역 ISP)들은 로컬 DNS 서버를 갖는다.
host가 ISP에 연결 ⇒ 해당 ISP는 로컬 DNS 서버로 부터 IP 주소 받음 ⇒ 그렇게 받은 IP주소를 host에 전달
이에 대한 자세한 내용은 아래에서 살펴볼 것이다.

ex) 호스트 cse.nyu.edu가 gaia.cs.umass.edu의 IP주소를 원한다고 하자.
또한 cse.nyu.edu에 대한 NYU의 로컬 DNS 서버가 dns.nyu.edu / gaia.cs.umass.edu에 대한 책임 DNS 서버는 dns.umass.edu라고 하자.

1) 호스트 cse.nyu.edu가 로컬 DNS 서버 dns.nyu.edu에게 DNS query 메시지를 보낸다. (원하는 내용은 gaia.cs.umass.edu의 IP주소였기 때문에 gaia.cs.umass.edu에 대한 내용이 포함된다)
2) 로컬 DNS 서버 dns.nyu.edu는 해당 query를 루트 DNS 서버에 전달한다.
3) 루트 DNS 서버는 edu를 인식하고 edu에 대한 책임을 가진 TLD 서버의 IP 주소 목록을 로컬 DNS 서버에게 보낸다.
4) 로컬 DNS 서버는 질의 메시지를 목록에 있던 주소 목록 중 하나의 TLD DNS 서버에 질의 메시지를 보낸다.
5) TLD 서버는 umass.edu를 인식하고 dns.umass.edu라는 이름을 가진 책임 DNS 서버의 IP 주소를 포함해서 응답한다.
6) 로컬 DNS 서비스가 직접 dns.umass.edu로 질의 메시지를 전송하고 gaia.cs.umass.edu의 IP 주소를 응답받는다.

앞선 예시에서 TLD 서버가 호스트 이름에 대한 책임 서버를 안다고 가정했지만 일반적으로는 그렇지 않다.
TLD 서버는 호스트 이름에 대한 책임 DNS를 아는 중간 DNS 서버만 알고 있다.

그래서 일반적으로 그림을 그리면 다음과 같다.

ex) 메사추세스 대학교가 대학에 대한 DNS 서버(dns.umass.edu)를 갖고 있다고 하자.
그리고 메사추세스 대학교의 각 학과도 자신만의 DNS 서버를 갖고 있고 각 학과 DNS 서버가 학과 안의 모든 호스트를 책임진다고 하자.

아래 설명을 위 그림의 내용과 같이 보도록 하자.
중간 DNS서버 dns.umass.edu가 cs.umass.edu로 끝나는 호스트 이름을 가진 host에 대한 query를 받으면

1) cs.umass.edu로 끝나는 모든 host에 대한 책임을 가진 dns.cs.umass.edu의 IP 주소를 반환한다.
2) 이때, 해당 IP 주소는 dns.nyu.edu에게 전달한다.
3) 로컬 DNS 서버 dns.nyu.edu는 전달받은 IP 주소를 dns.cs.umass.edu에게 전달해서 원하는 IP주소를 전달받는다.
4) 그렇게 dns.nyu.edu는 전달받은 IP주소를 host에게 전달한다.

이 경우 총 10번의 메시지를 주고받는다는 걸 확인할 수 있다. 그림 2.19의 예시는 재귀적 질의(recursive query)와 반복적 질의(iterative query)를 둘 다 사용한다.

• 재귀적 질의 부분 : cse.nyu.edu 에서 dns.nyu.edu로 보내는 질의는 자신(cse.nyu.edu)을 대신하여 필요한 매핑을 얻도록 dns.nyu.edu에게 요구하는 부분
• 반복적 질의 부분 : 나머지 3가지 부분. 각각의 질의는 dns.nyu.edu가 직접 전송하기 때문에 반복적 질의다.

이론상 DNS 질의(query)는 반복적이고 재귀적일 수 있다. 아래 그림은 모든 query가 재귀적인 DNS 질의 사슬인 경우를 보여준다.

DNS 캐싱

DNS는 delay 성능 향상과 네트워크의 DNS 메시지의 개수를 감소시키기 위해 캐싱을 사용한다.
DNS 캐싱의 아이디어는 매우 간단하다.

질의 사슬(query chain)에서 DNS 서버가 DNS 응답을 받았을 때 DNS 서버의 로컬 메모리에 응답에 대한 정보를 저장할 수 있다.

ex) 그림 2.19에서 로컬 DNS 서버 dns.nyu.edu는 임의의 DNS 서버로 부터 응답을 받을 때 마다 응답에 포함된 정보를 저장할 수 있다.

만약 (host이름, IP 주소) 쌍을 DNS 서버에 저장한 상태에서 다른 host로 부터 똑같은 DNS 질의를 받는다면 로컬에 저장한 IP 주소값을 반환만 해주면 된다. (물론, 로컬에 저장된 내용은 사본이기 때문에 2일 정도 지나면 삭제한다)

ex) host : apricot.nyu.edu가 cnn.com에 대한 IP주소를 dns.nyu.edu에게 질의했다고 하자.

dns.nyu.edu는 앞서 살펴본 과정을 거쳐서 cnn.com의 IP주소를 host에게 반환했다.

그런 다음에 다른 host인 kiwi.nyu.edu가 똑같은 호스트 이름(cnn.com)을 질의했다고 하자.
cnn.com은 캐싱한 값이기 때문에 똑같은 과정을 거치지 않고 곧바로 cnn.com의 IP주소를 호스트에게 반환할 수 있다.

또한 로컬 DNS 서버는 TLD 서버의 IP주소도 저장할 수 있어서 굳이 루트 DNS 서버를 거치지 않고 추가적인 질의 과정을 수행할 수도 있다.

3. DNS 레코드와 메시지

DNS 분산 DB를 구현한 DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드(Resource Record, RR)를 저장한다.
각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다. 여기서는 간단한 개요를 살펴볼 것이다.
참고문서1, 참고문서2, 참고문서3

자원 레코드는 다음과 같은 필드를 포함한 튜플로 되어 있다.

(Name, Value, Type, TTL)

TTL(Time To Live)은 자원 레코드가 살아있는 시간을 의미한다. 앞으로 얘기할 예시에서는 TTL 필드를 무시하겠다. 
Name과 Value는 Type의 값에 따라 의미가 달라진다. 

• Type=A : Name은 호스트 이름 / Value는 호스트 이름에 대한 IP 주소. 즉, Type A 레코드는 표준 호스트 이름의 IP주소 매핑을 제공함 ex. (relay1.bar.foo.com, 145.37.93.126, A)
• Type=NS : Name은 도메인 / Value는 도메인 내부의 호스트에 대한 IP주소를 얻을 수 있는 방법을 알고 있는 책임 DNS 서버의 호스트 이름 ex. (foo.com, dns.foo.com, NS)
• Type=CNAME : Name은 별칭 호스트 이름 / Value는 Name에 대한 정식 호스트 이름이다. 이 레코드는 질의한 호스트에게 호스트 이름에대한 정식 이름을 제공한다. ex. (foo.com, relay1.bar.foo.com, CNAME)
• Type=MX : Name은 별칭 호스트 이름 / Value는 Name을 갖는 메일 서버의 정식 이름이다. ex. (foo.com, mail.bar.foo.com, MX)

한 DNS 서버가 어떤 호스트 이름에 대한 책임 서버라면 그 DNS 서버는 호스트 이름에 대한 Type A 레코드를 포함한다.
왜냐하면, 호스트 이름에 대한 책임 서버이기 때문에 호스트 이름과 매핑되는 IP주소를 갖고 있기 때문이다.

책임 서버가 아니면 그 DNS 서버는 호스트 이름을 포함한 도메인에 대한 Type NS 레코드를 포함한다.
왜냐하면, 책임 서버가 아니라서 당연히 호스트와 매핑되는 IP주소를 갖지 않는다. 대신에 책임 서버가 어디있는지에 대한 정보를 갖고 있기에 Type NS 레코드를 갖는다.

ex) host : gaia.cs.umass.edu 에 대한 책임 서버가 아닌 TLD 서버가 있다고 하자.

⇒ 이 서버는 호스트 gaia.cs.umass.edu를 포함한 도메인에 대한 레코드 (ex. (umass.edu, dns.umass.edu, NS))를 가질 것이다.
⇒ 또한 Type A 레코드(ex. (dns.umass.edu, 128.119.40.111, A))를 가질 수도 있다.

DNS 메시지

앞서 DNS 질의(query)와 응답 메시지에 대해서 얘기했다. DNS에서는 이 2가지 메시지 유형이 전부다.
요청과 응답 메시지는 아래 그림과 같은 포맷을 갖고 있다.

• 첫 12바이트(헤더 영역)
  1) 질의(query) 식별을 위한 16비트 숫자 : query에 대한 응답 메시지에 복사되어 client가 보낸 query와 수신된 응답이 서로 일치하는지 이 값을 통해 식별한다.
  2) 플래그(flags)3) 개수(count) 필드 : 헤더 다음에 오는 데이터 영역의 4가지 타입의 발생 횟수를 나타냄
• - 질의/응답 플래그 (1비트) : 0이면 질의(query) / 1이면 응답 - 책임 플래그 (1비트) : DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정됨 - 재귀 요구 플래그 (1비트) : DNS 서버가 레코드를 갖지 않을 때 client가 재귀적 질의를 수행하기를 원할 때 설정됨 - 재귀가능 필드 (1비트) : DNS 서버가 재귀 질의를 지원하면 응답에 설정됨
• 질문 영역(question section) : 현재 질의(query)에 대한 정보를 포함한다.
  1) 질의되는 이름을 포한한 이름 필드(name field)
  2) 이름에 대해 요청받는 질문 타입을 나타내는 타입 필드(type field) ex. A타입 인지 / MX 타입인지
• 답변 영역(answer section) : DNS 서버로 부터의 응답에서 답변 영역은 원래 질의된 이름에 대한 자원 레코드를 갖는다.
  • 즉, 자원 레코드(RR) 튜플 (Name, Value, Type, TTL)을 갖는다는 뜻이다.
  • 응답할 때 여러 개의 RR을 보낼 수 있다. 호스트 이름은 여러 개의 IP 주소를 가질 수 있기 때문이다.
• 책임 영역(authority section) : 다른 책임 서버의 레코드를 포함한다.
• 추가 영역(additional section) : 말 그대로 추가적으로 도움이 되는 정보
  • ex) MX 질의에 대한 응답
    • 응답 필드 : 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 갖고 있다.
    • 추가 영역 : 메일 서버의 정식 호스트 이름에 대한 IP주소를 제공하는 Type A 레코드를 갖고 있다.

nslookup 프로그램 : query 메시지가 호스트에서 DNS 서버로 곧장 전송될 수 있또록 하는 프로그램.

DNS 데이터베이스에 레코드 삽입

지금까지 다룬 내용은 DNS DB에서부터 레코드를 어떻게 조회하는지에 대해서 다뤘다.
그렇다면, 처음에 어떻게 레코드를 DNS DB에 삽입할까.

ex) 벤처기업을 설립했다고 하자.

가장 먼저 할 일은 회사의 도메인 이름인 networkutopia.com을 등록기관에 등록하는 것이다.
등록기관(registrar)이란... 도메인 네임의 유일성을 확인하고 그 도메인 네임을 DNS DB에 넣고 이 서비스에 대한 요금을 받은 회사다.

도메인 이름 networkutopia.com을 등록기관에 등록할 때
등록 기관에 주책임 서버의 이름 & IP 주소과 부책임 서버의 이름 & IP 주소를 제공해야 한다.
각각을 (dns1.networkutopia.com, 212.2.212.1), (dns2.networkutopia.com, 212.212.212.2) 라고 하자.

2개의 책임 DNS 서버 각각에 대해 등록 기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다.
networkutopia.com에 대한 주책임 서버의 경우 등록기관은 아래의 2개의 자원 레코드를 DNS 시스템에 삽입한다.

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

웹 서버 www.networkutopia.com에 대한 Type A 자원 레코드와 메일 서버 mail.networkutopia.com에 대한 Type NS 자원 레코드가 내 책임 DNS 서버에 등록되는 것을 확인해야 한다. 호스트 이름에 대한 IP 주소가 제대로 매핑 되었는지, 호스트 이름을 알고 있는 책임 DNS 서버를 제대로 매핑했는지 확인해야 하기 때문이다.

이 모든 단계가 끝나면 사람들은 웹 사이트에 방문할 수 있고 전자메일을 보낼 수 있다.

이를 확인함으로써 DNS에 대해 무엇을 배웠는지 복기하는데 도움을 준다.

ex) 호주에 있는 A라는 사람이 ⇒ www.networkutopia.com 웹 페이지를 보고 싶다.

그러면...

1) A의 호스트는 DNS 질의(query)를 자신의 로컬 DNS 서버에 전송
2) 로컬 DNS 서버는 TLD com 서버에 접속한다. 이 TLD 서버는 Type NS와 Type A 자원 레코드를 갖고 있다. 왜냐하면, 앞서 얘기한 것 처럼 등록 기관이 각각의 자원 레코드를 TLD com에 삽입했기 때문이다.
3) TLD com 서버는 A의 로컬 DNS 서버로 2개의 자원 레코드를 포함한 응답을 보낸다.
4) 로컬 DNS 서버에서 www.networkutopia.com에 대응되는 Type A 레코드를 요구하는 DNS 질의를 212.212.212.1에게 전송한다.
5) 212.212.212.1 서버는 클라이언트가 요구하는 웹 서버 212.212.71.4의 IP 주소를 제공한다.
6) 로컬 DNS 서버는 212.212.71.4의 IP 주소를 A에게 전달한다.
7) A의 브라우저는 212.212.71.4 호스트로 TCP 연결을 초기화하고 그 연결을 바탕으로 HTTP 요청(request)을 보낸다.