[혼자 공부하는 네트워크] 5장. 응용 계층

이 글은 「혼자 공부하는 네트워크」 책 내용을 정리한 내용입니다.

저작권 문제시 삭제하겠습니다.

---

 

OSI 모델

응용 계층

표현 계층

세션 계층

전송 계층

네트워크 계층

데이터 링크 계층

물리 계층

 

 

05-1.DNS와 자원

 

서버와 클라이언트가 '메세지를 주고 받고자 하는 대상'과 '송수신하고자 하는 정보'를 식별할 수 있어야 한다.

1) 메세지를 주고 받고자 하는 대상을 식별하기 위해 IP 주소 외에 도메인 네임을 사용할 수 있다.

2) 송수신하고자 하는 정보를 식별하기 위해 위치 기반 식별자 URL과 이름 기반 식별자 URN이 있다.

 

 

* 도메인 네임과 네임 서버

 

1. 도메인 네임

: 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보.

IP 주소보다 기억하기 쉽다. IP 주소가 바뀌더라도 바뀐 IP 주소에 도메인 네임을 다시 대응하면 되어 IP 주소만으로 호스트를 특정하는 것보다 더 간편하다.

ex) www.naver.com,  www.google.com  등

 

2. 네임 서버

: 도메인 네임과 IP 주소를 모아 관리.

공용 전화번호부 역할

 

cf) 개인 전화번호부 역할의 'hosts 파일'

: 호스트마다 갖고 있는 도메인 네임과 IP 주소의 대응 관계를 담은 파일.

- macOS 의 경우 /etc/hosts 에 위치

- 윈도우의 경우 %SystemRoot%\System\drivers\etc\hosts

 

 

3. 도메인 네임의 구조

www.example.com

 

 

도메인 네임은 .을 기준으로 계층적으로 분류된다.

 

1) 루트 도메인: www.google.com.  으로 접속해도 되지만 생략해서 표기한다.

2) 최상위 도메인(TLD: Top-Level Domain): 도메인 네임의 가장 마지막 부분.

ex) com, net, org, kr(대한민국), jp(일본), cn(중국), us(미국),...

3) 2단계 도메인: example

3) 3단계 도메인: www. www.example.com은 은 3단계까지 가면 도메인 네임 전체를 얻을 수 있어서 www 를 호스트 네임이라고 부르기도 한다.

cf) 전체 주소 도메인 네임을 (FQDN: Full-Qualified Domain Name) 라 칭한다

 

 

4. 계층적 네임 서버

 

계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룬다.

네임 서버는 여러 개 존재하며 전 세계 여러 군데에 위치해 있다.

이렇게 계층적으로 분산된 도메인 네임에 대한 관리 체계를 Domain Name System(DNS) 라 부른다.

 

IP 주소를 모르는 상태에서 도메인 네임에 대응 되는 IP 주소를 알아내는 과정: 도메인 네임을 풀이한다. 리졸빙한다. 라고 표현함.

 

1) 로컬 네임 서버

: 클라이언트와 맞닿아 있는 네임 서버. 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버

- 로컬 네임 서버의 주소는 ISP가 할당해 주는 경우가 많고, 공개 DNS 서버를 이용할 수도 있다.

- 대표적인 공개 DNS 서버의 예: 구글의 8.8.8.8, 8.8.4.4, 클라우드플레어의 1.1.1.1

 

2) 루트 네임 서버

루트 도메인을 관장하는 네임 서버. 

TLD 네임 서버의 IP 주소 반환.

 

3) TLD 네임 서버

TLD를 관리하는 네임 서버

TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환

 

4) 책임 네임 서버

자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 전달하지 않고 곧바로 답할 수 있는 네임 서버. 로컬 네임 서버가 마지막으로 질의하는 네임 서버.

 

 

* 도메인 네임을 리졸빙하는 과정

: 재귀적 질의, 반복적 질의

 

1) 재귀적 질의: 클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버가 루트 네임 서버에게, 루트 네임 서버가 TLD 네임 서버에게, TLD 네임 서버가 다음 단계에 질의하는 과정을 반복하고 최종 응답 결과를 역순으로 전달받는 방식. 

 

2) 반복적 질의: 로컬 네임 서버가 네임 서버들에게 차례로 질의해서 최종 응답 결과를 클라이언트에게 알려주는 방식

 

* DNS 캐시: 시간 절약을 위해 네임 서버들이 기존에 응답받은 결과를 임시 저장해놨다가 추후 같은 질의에 반환

 

 

5.  URI(Uniform Resource Identifier)

: 자원을 식별할 수 있는 정보. 자원을 식별하는 통일된 방식.

 

1) URL(Uniform Resource Locator): 위치를 이용해 자원을 식별하는 방식

2) URN(Uniform Resource Name): 이름을 이용해 자원을 식별하는 방식

 

*URL

1) scheme: 자원에 접근하는 방법. http, https

2) authority: 호스트를 특정할 수 있는 정보. IP 주소, 도메인 네임. (:) 으로 포트번호를 붙일 수도 있음.

3) path: 자원이 위치한 경로. (/) 를 기준으로 계층적으로 표현

4) query: <query=value> 형태로 특정 결과를 가져올 수 있다.

5) fragment: 자원의 한 조각을 가리키기 위한 정보. html 파일과 같은 자원에서 특정 부분을 가리킴.(스크롤 이동)

 

 

* URN

: 자원에 고유한 이름을 부티는 이름 기반 식별자. 자원의 위치와 무관하게 자원을 식별할 수 있다는 장점.

ex) urn:isbn.0451450523

 

 

 

05-2. HTTP

 

HTTP: 응용 계층에서 정보를 주고받는 데 사용되는 프로토콜

요청과 응답을 기반으로 동작, 미디어 동립적, 상태를 유지하지 않고 지속 연결을 지원한다.

 

1. HTTP의 특성

 

1) 요청 - 응답 기반 프로토콜

: 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작한다.

 

2) 미디어 독립적 프로토콜

: 주고받을 자원의 특성과 무관하게 자원을 주고받을 수단의 역할만을 수행한다.

: HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입(MIME 타입) 이라고 부른다. 타입/서브타입 형태로 명시

 

3) 스테이트리스 프로토콜

: 서버가 HTTP 요청을 보낸 클라이언트와 고나련된 상태를 기억하지 않는다.

: TTTP 서버가 많은 클라이언트와 동시에 상호작용해야 하고 여러 대로 구성되므로 상태 정보를 저장하고 있지 않는 것이 성능상의 이점이 더 많기 때문.

: 언제든 쉽게 서버를 추가할 수 있고(확장성), 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대체 가능하다.(견고성)

 

4) 지속 연결 프로토콜

: 매번 새롭게 연결을 수립/종료하는 것 보다 더 빠르게 여러 HTTP 요청과 응답을 처리할 수 있다.

 

 

2. HTTP 메시지의 구조

 

1) 시작라인(요청라인/상태라인)

 

- HTTP 요청 메시지인 경우: 요청 라인.

메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄바꿈)

 

메서드: GET, POST, PUT, DELETE 등

요청대상: HTTP 요청을 보낼 서버의 자원. http://www.example.com/hello?q=world 일 때 /hello?q=world

HTTP 버전: HTTP/<버전> 형태로 적어줌

 

- HTTP 응답 메시지인 경우: 상태 라인.

HTTP 버전 (공백) 상태 코드 (공백) 이유 구문 * (줄바꿈)

 

상태 코드: 요청에 대한 결과를 나타내는 3자리 정수

이유 구문: 상태 코드에 대한 문자열 형태의 설명

 

ex) HTTP/1.1 200 OK, HTTP/1.1 404 Not Found

 

2) 필드 라인(헤더 라인)

: 0개 이상의 HTTP 헤더가 명시됨. HTTP 통신에 필요한 부가 정보.

 

3) 메시지 본문

: 메시지 본문은 존재하지 않을 수도 있고, Json, html 등 다양한 콘텐츠 타입이 사용될 수 있다.

 

3. HTTP 메서드

 

* GET 예시

 

* API 문서

: 어떤 URL에 어떤 메서드를 보낼 수 있는지, 어떤 쿼리 문자열이 사용될 수 있는지, 올바르게 요청을 보냈을 경우 어떤 응답 메시지를 받을 수 있는지 등을 명시한 가이드 문서

 

 

4. HTTP 상태코드

 

202: 작업시간이 긴 대용량 파일 업로드 작업이나 배치 작업과 같이 요청 결과를 곧바로 응답하기 어려운 상황

 

리다이렉션 상태: 요청을 완수하기 위해 추가적인 조치가 필요한 상태

영구적인 리다이렉션: 자원이 완전히 새로운 곳으로 이동해서 경로가 영구적으로 재지정된 상태

 

일시적인 리다이렉션: 자원의 위치가 임시로 변경된 상태

 

클라이언트에 의한 에러가 있는 상태.

서버가 처리할 수 없는 형태로 요청했거나 존재하지 않는 자원에 대한 요청을 보내는 경우

 

서버 에러에 대한 상태.

 

 

5. HTTP의 발전

1) HTTP/0.9: 사용가능한 메서드 GET, 요청 메시지 한 줄로 구성. 헤더 지원불가

 

2) HTTP/1.0: HEAD, POST 메서드 추가. 헤더 지원 시작. 지속 연결 지원 불가.

 

3) HTTP/1.1: 지속 연결 지원. 응답 전에 다음 요청을 보낼 수 있는 파이프라이닝 기능 추가. 콘텐츠 협상 기능 등 다양한 편의 기능 및 사용 가능한 헤더 추가. 오늘날까지 널리 사용되는 버전.

 

4) HTTP/2.0: HTTP/1.1의 효율과 성능을 높인 버전. 헤더 압축 전송, 바이너리 데이터 기반의 메시지 송수신, 미래에 사용될 것으로 예상되는 자원을 미리 전송해주는 서버 푸시 기능 제공. 병렬로 메시지를 주고받는 멀티플렉싱 기술 도입.

 

5) HTTP/3.0: 이전 버전들이 TCP 기반으로 동작하는 것과 달리 UDP 기반으로 동작. 비연결형 프로토콜 UDP 가 더 빨라서 속도가 대폭 향상됨.

 

 

05-3. HTTP 헤더와 HTTP 기반 기술

 

1. HTTP 헤더

1) 요청 시 활용되는 HTTP 헤더

- Host: 요청을 보낼 호스트를 나타내는 헤더. 도메인 네임으로 명시 됨.

GET /hypertext/WWW/TheProject.html HTTP/1.1 Host: info.cern.ch

 

- User-Agent: HTTP 요청을 시작하는 클라이언트 측의 프로그램과 관련된 정보 명시.

User-Agent: Mozilla/5.0 (Windows NT 10.0; win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

 

- Referer: 클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시 됨. 클라이언트의 유입 경로 파악 가능

Referer: https://en.wikipedia.org/

 

- Authorization: 클라이언트의 인증 정보 명시. Basic 인증(Base64 로 인코딩한 값을 명시함.), Bearer 인증(OAuth 인증)

Basic 인증과 Bearer 인증의 모든 것

Authorization: Basic bWluY2h1bDoxMjM0

 

Authorization: Bearer <token 값>

 

2) 응답 시 사용되는 HTTP 헤더

- Server: 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보를 명시

Server: Apache/2.4.1 (Unix)

 

- Allow: 클라이언트에게 허용된 HTTP 메서드 목록을 명시. 405(Method Not Allowed) 상태 코드에서 응답하는 메시지에 Allow 헤더가 함께 사용됨.

Allow: POST, OPTIONS

 

- Retry-After: 자원을 사용할 수 있는 날짜 혹은 시각을 나타냄. 503(Service Unavailable) 상태 코드에서 응답하는 메시지에 Retry-After 헤더가 함께 사용됨.

Retry-After: Fri, 23 Aug 2024 09:00:00 GMT Retry-After: 120

 

- Location: 클라이언트에게 자원의 위치를 알려 주기 위해 사용되는 헤더

 

- WWW-Authorization: 자원에 접근하기 위한 인증 방식을 설명하는 헤더. 

WWW-Authorization: Basic realm="Access to engineering site", charset="UTF-8"

 

 

3) 요청 및 응답 모두에서 사용되는 HTTP 헤더

-Date: 메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더.

Date: Tue, 15 Nov 1994 08:12:31 GMT

 

- Connection: 클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더

Connection: keep-alive Connection: close

 

- Content-Length: 본문의 바이트 단위 크기(길이)

Content-Length: 100

 

- Content-Type, Content-Language, Content-Encoding: 메시지 본문의 표현 방식

Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip

 

 

* 캐시

: 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술

 

* 캐시 신선도

캐시된 사본 데이터가 얼마나 최신 원본 데이터와 유사한지를 나타내는 정도

 

1) 캐시된 데이터에 유효 기간을 설정하는 방법

Expires: <날짜>

Cache-Control: max-age=<초>

 

2) 캐시의 유효 기간이 만료되었더라도 여전히 최신 상태의 정보인지 확인

요청: If-Modifed-Since: <날짜>

응답: 요청받은 자원이 변경되었음(200(OK)), 요청받은 자원이 변경되지 않았음(304(Not Modified)), 요청받은 자원이 삭제되었음(404(Not Found))

 

3) 자원의 버전으로 요청하기

요청: If-None-Match: <엔티티 태그>

응답: 요청받은 자원이 변경되었음(200(OK)), 요청받은 자원이 변경되지 않았음(304(Not Modified)), 요청받은 자원이 삭제되었음(404(Not Found))

 

 

* 쿠키

: 서버에서 생성되어 클라이언트 측에 저장되는 데이터.

상태를 유지하지 않는 HTTP 의 특성을 보완하기 위한 수단.

<이름, 값> 쌍의 형태.

ex) Session 인증

쿠키에 사용가능한 도메인, 경로도 함께 저장된다.

 

요청 메시지

Cookie: 이름=값; 이름=값;

 

응답 메시지

HTTP/1.1 200 OK

Content-Type: text/html

Set-Cookie: name=minchul; phone=100-100; message=Hello; Expires=Fri, 23 Aug 2024 09:00:00 GMT

 

* 쿠키 보안

Secure: HTTPS 프로토콜이 사용되는 경우에만 쿠키를 전송되도록 하는 속성

HttpOnly: HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성

 

* 쿠키의 협상과 표현

: 같은 URI 에 대해 가장 적합한 자원의 형태를 제공하는 매커니즘

Accept-Language, Accept-Charset, Accept-Encoding 등으로 선호하는 자원을 명시해서 요청할 수 있다.