[05] 응용 계층

DNS와 자원

• 메세지를 주고받고자 하는 대상 파악을 위해 도메인 네임 사용 가능
  • 이를 위해 위치 기반 식별자인 URL
  • 이름 기반의 식별자인 URN이 있음

도메인 네임과 네임 서버

• 도메인 네임
  • IP 주소와 대응되는 문자열 형태의 호스트 특정 정보
• 네임 서버
  • 도메인 네임과 IP 서버를 관리하는 곳
  • 도메인 네임을 관리하는 네임서버를 DNS 서버라고 부름

• 도메인 네임은 점을 기준으로 계층적으로 분류
  • 최상단에 루트 도메인이 있음
  • 그 다음에 최상위 도메인...

• 예시에서 www.example.com. 이라고 하면
  • 루트 도메인은 .
  • 최상위 도메인은 com
  • 2단계 도메인은 example
  • 3단계 도메인은 www
• 이 때 루트 도메인 까지 포함한 도메인 네임을 전체 주소 도메인 네임(Fully-Qualified Domain Name) 이라고 함
• FQDN의 첫번째 부분(www)을 호스트네임이라 함

계층적 네임 서버

• IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 것을
  • 도메인 네임을 풀이 한다, 혹은 리졸빙 한다 라고 함
• 이 과정에서 다양한 네임 서버들이 사용
  • 로컬 네임 서버
    • 클라이언트와 맞닿아있는 네임 서버
    • 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾는 네임 서버
    • 일반적으로 ISP 에서 할당해 주는 경우가 있음 
      • 또는 공개 DNS 서버를 이용할 수도 있음

• 루트 네임 서버
  • 로컬 네임 서버가 대응되는 IP주소를 찾지 못한 경우 루트 네임서버에게 도메인 네임을 질의
  • 루트 도메인을 관장하는 네임 서버로, TLD 네임 서버의 IP 주소를 반환

• TLD 네임 서버
  • TLD를 관리하는 네임 서버
  • 하위 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있음

• 책임 네임 서버
  • 특정 도메인 영역을 관리하는 네임 서버
  • 자신의 관리하는 영역에 대한 질의는 곧바로 답할 수 있음
  • 로컬 네임 서버가 마지막으로 질의하는 네임 서버
  • 일반적으로 로컬네임서버는 책임 네임 버서로부터 원하는 IP주소를 얻어 냄
• 네임 서버들은 모두 계층적인 구조를 띄고있다

• 로컬 네임 서버가 네임서버 들에게 질의하는 방법에는 재귀적 질의, 반복적 질의 두 가지가 있음

재귀적 질의

• 로컬 -> 루트 -> TLD -> 책임네임 서버 질의를 반복하며 최종 응답 결과를 역순으로 전달하는 방식

반복적 질의

• 클라이언트가 로컬 네임서버에게 IP 주소를 알고싶은 도메인 네임을 질의
• 루트 도메인 서버에게 질의 후 다음으로 TLD에게 질의, 다음으론 책임 네임서버에 질의하여 응답 결과를 클라이언트에게 전달

• 이러한 방법은 리졸빙을 위해 8개의 단계를 거쳐야 하기 때문에 시간이 오래걸림
• 그래서 기존에 응답받은 결과를 임시로 저장하여 같은질의의 경우 이를 활용
  • 이를 DNS 캐시라고 함
  • TTL과 함께 저장되어 시간이 지나면 자동으로 삭제

자원을 식별하는 URI

• 자원 이란, 네트워크 상의 메세지를 통해 주고 받는 대상
  • 오늘날은 HTTP 요청 메시지의 대상이라고도 표현
• 자원을 식별할 수 있는 정보를 URI라고함
  • 위치를 이용한 식별 URL
  • 이름을 이용한 식별 URN

URL

• 인터넷 환경에서 자원 식별에 많이 사용하는 방법
• 다음과 같은 형태로 구성

• Scheme
  • 자원에 접근하는 방법을 의미
  • 일반적으로 http:// 혹은 https://를 사용
• Authority
  • 호스트를 특정할 수 있는 정보를 사용
  • 도메인 네임 혹은 IP 주소가 사용
  • 콜론 뒤에 포트번호를 덧붙일 수 있음
• Path
  • 자원이 위치한 경로
  • 슬래시를 기준으로 계층적으로 표현

• query
  • 요청-응답 기반 프로토콜을 통해 주소 상에서 검색 쿼리를 넣는 것
  • 특정 단어에 대한 검색이나, 내림차순 정렬 등에 사용
  • path 뒤에 붙는 것이 일반적
  • ?query=value&query2=value2... 식으로 사용

• fragment
  • 자원의 한 조각을 기리키기 위한 정보
  • HTML과 같은 자원에서 특정 부분을 가리키기 위해 사용
  • #section-1.1.2 과 같이 사용

URN

• 위치가 변할 수 있는 자원은 위치 변경시 기존 URL로는 식별할 수 없음
• 고유한 이름을 붙여 위치와 무관하게 자원 식별 가능
• urn:isbn:number
• urn:ietf:rfc:2648 처럼 기구 단체 이름과 이름이 붙음
• URL을 더 많이 사용하긴 함...

HTTP

HTTP의 특성

• 요청과 응답을 기반으로 동작
• 미디어 독립적임
  • HTTP는 자원을 주고받을 수단(인터페이스)의 역할만 수행
  • HTTP에서 메세지로 주고받는 자원의 종류를 미디어 타입, MIME 이라고 함
  • 미디어 타입은 기본적으로 슬래시 기준으로 타입/서브타입 형식으로 구성
  • 타입은 데이터 유형을, 서브타입은 주어진 타입에 대한 세부 유형을 나타냄

• 상태를 유지하지 않음
  • 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않음
  • 클라이언트의 모든 요청은 독립적인 요청으로 간주
  • 이런 이유로 HTTP의 설계 목표는 확장성과 견고성

• 만약 상태를 유지할 경우 특정 클라이언트가 특정 서버에 종속될 가능성이 있음
• 지속 연결을 지원
  • 하나의 TCP 연결 상에서 여러개의 요청, 응답을 주고받을 수 있는 기술
    • Keep-Alive

HTTP 메세지 구조

 

시작 라인

• 요청 메세지 혹은 응답 메세지인자에 따라 요청 라인 / 상태 라인으로 구분
• 요청라인의 형식은 다음과 같음

• 메서드
  • 클라이언트가 서버의 자원에 대해 수행할 작업의 종류
  • GET, POST, PUT, DELETE 등...
• 요청 대상
  • HTTP 요청을 보낼 서버의 자원을 의미
  • URI의 경로가 명시
  • 이 때 path 이후의 줄이 요청 대상임
    • /hello?q=world ....
  • 요청 사항이 없다면 '/'로 표기
• HTTP 버전
  • 사용된 HTTP의 버전
  • HTTP/1.1
• 상태라인의 형식은 다음과 같음

• 여기서 이유 구문이란, 상태 코드에 대한 문자열 형태의 설명을 의미
  • OK 혹은 NOT FOUND 등...

필드 라인

• 0개이상의 HTTP 헤더가 명시
• 헤더라인이라고도 함
• HTTP 통신에 필요한 부가 정보를 의미
• 콜론을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성

• 본문이 필요한 경우, 메세지 본문에 명시
  • 존재할 수도 있고, 아닐 수도 있음

HTTP 메서드

• 종류는 다음과 같음

GET 요청

• 특정 자원 조회시 사용
• 흔히 사용되는 메서드 중 하나
• 요청 메세지

• 응답 메세지

• 이 때 메세지 본문을 포함시키는 것은 바람직 하지 않아 요청 메세지에서는 쿼리 문자열을 사용하는 경우가 많음

HEAD - 헤더만 요청

• GET과 동일한 역할이지만 메세지 본문이 포함되지 않음

POST - 처리 요청

• 서버로 하여금 특정 작업을 처리하도록 요청
• 범용성이 매우 넓은 메서드
• 처리할 대상은 메세지 본문으로 명시 됨

• 클라이언트가 서버에 새로운 자원을 생성하고자 할 때 사용
• 응답 메세지

PUT - 덮어 쓰기 (수정)

• 요청 자원이 없으면 메세지 본문으로 새 자원을 생성
• 이미 자원이 존재하면 메세지 본문으로 자원을 완전히 대체

• 위와 같이 요청시, 클라이언트가 보낸 요청 대로 제목과 아이디가 수정
• 이 때 Contents는 사라짐

PATCH - 일부 수정

• PUT과는 다르게 부분적 수정에 이용
• 아까와는 다르게 명시가 되어있지 않던 Contents의 내용은 사라지지 않고 유지되어있음.

DELETE - 삭제 요청

• 특정 자원을 삭제하고 싶을 때 사용하는 메서드

API 문서

• 어떤 URL 로 요청을 받았을 때 서버는 어떻게 응답할 것인지 문서로 정리한 것

HTTP 상태 코드

• 요청에 대한 결과를 나타내는 세자리 정수

200번대 - 성공 상태

• 요청이 성공됐음을 의미

300번대 - 리다이렉션 상태

• 요청을 완수하기위해 추가적인 조치가 필요한 상태
• 요청을 다른곳으로 이동 시켰다는 것을 의미

• 영구적인 리다이렉션이란
  • 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것을 의미
  • 서버가 도메인을 이전하거나, 웹사이트의 큰 개편이 있을 때 접할 수 있음
  • 301, 308번이 있음

• 일시적인 리다이렉션이란
  • 자원의 위치가 임시로 변경되거나, 임시로 사용할 URL 이 필요한 경우 사용
  • 요청을 보낸 URL은 기억해야 함
  • 302, 303, 307 번이 있음

400번대: 클라이언트 에러 상태 코드

• 클라이언트에 의한 에러가 있음을 알려주는 코드
• 존재하지 않는 자원이나, 서버가 처리할 수 없는 형태로 요청을 보낸 경우

• 이 때 특정 자원에 대한 인증이 필요할 때, 인증을 하지 않으면 401번 에러가 뜸
  • 401번 에러는 반드시 www-Authenticate라는 헤더를 통해 인증 방법을 알려주어야 함
• 403번은 권한이 없다는 경우인데, 인증과 권한 부여는 다른 것
  • 인증이란 자신이 누구인지 증명
  • 권한이란 인증된 주체에게 작업을 허용하는 것
• 404번은 존재하지 않는 링크에 대해 접근할 때, 혹은 자원에 접근할 때 알려주는 코드

500번대 : 서버 에러 상태 코드

• 서버가 일으킨 에러

• 서버 자체의 오류나 중간 서버의 통신 오류 등으로 인해 발생

HTTP 헤더와 HTTP 기반 기술

• Http 필드라인에는 HTTP헤더가 명시

HTTP 헤더

• 요청시 주로 사용되는 헤더, 응답시 주로 사용되는 헤더, 모두 사용되는 헤더가 있음

요청시 활용되는 헤더

• Host, User Agent, Referer, Authorization 헤더가 있음
• Host
  • 요청을 보낼 호스트를 나타내는 헤더
  • 도메인 네임으로 명시, 포트번호가 포함될 수 있음

• User Agent
  • 웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램
  • 요청 메세지 생성에 관여한 클라이언트 프로그램과 관련된 정보가 명시

• Referer
  • 개발 시 아주 유용한 헤더 중 하나
  • 클라이언트가 요청을 보낼 때 머무르던 URL이 명시
  • 유입 경로를 파악하는데 아주 좋음

• Authorization
  • 클라이언트의 인증 정보를 담는 헤더
  • 인증 타입과 인증을 위한 정보가 차례로 명시됨
  • 가장 기본적인 타입은 Basic
    • username:password처럼 콜론을 이용해 합치고, Base64 인코딩한 값을 인증정보로 삼음

응답 시 활용되는 HTTP 헤더

• Server, Allow, Retry-After, Location, WWW-Authenticate 헤더가 있음
• Server 
  • 요청을 처리하는 서버측의 소프트웨어와 관련된 정보 명시

• Allow 
  • 클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용

• Retry-After
  • 현재 요청을 처리할 수 없지만, 나중에 가능할 수도 있다는 뜻
  • 추후의 시간을 명시하여 보냄

• Location
  • 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더
  • 리다이렉션 발생 시나, 새로운 자원 생성시 사용
• WWW-Authenticate
  • 상태코드 401에 대응하는 헤더로, 자원에 접근하기 위한 인증 방식을 설명하는 헤더
  • 추가로 보안 영역이나, 인증에 사용될 문자집합도 알려줄 수 있음

요청, 응답에 모두 활용되는 HTTP 헤더

• Date
  • 메세지가 생성된 날짜와 시각에 관련된 정보

• Connection
  • 클라이언트의 요청과 응답 간의 연결방식을 설정하는 헤더
  • Keep-alive나, close 등...

• Content-Length
  • 본문의 바이트 단위 크기(길이)를 나타냄

• Content-Type, Content-Language, Content-Encoding
  • 메세지 본문의 표현 방식을 설명하는 헤더
  • 표현 헤더의 일종
  • 타입에는 미디어 타입을, 랭귀지에는 자연어를, 인코딩에는 메세지 본문을 압축하거나 변환한 방식이 명시
  • Language에는 ko-KR 처럼 "한국에서 사용하는 한국어" 라는 의미로 표현

캐시

• 같은 이미지를 두,세번 요청하면 다시 주는 것이 아닌, 캐시를 이용하여 재지급
• 캐시란, 불필요한 대역폭 낭비 및 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술
  • 동일한 요청에 대해 더 빠르게 데이터 접근가능
  • 불필요한 대역폭 낭비도 줄일 수 있음
• 웹 브라우저에 저장되어있거나, 중간 서버에 저장되어 있기도 함
  • 웹 브라우저에 저장되어 있으면 개인 전용 캐시
  • 중간 서버에 저장되어 있으면 공용 캐시
• 캐시는 원본이 아닌 사본을 저장하기 때문에 데이터 변경에 대해 대비를 해야함
  • 캐시 신선도를 이용하여, 캐시된 데이터에 유효기간을 설정
  • 기간 만료시 원본 데이터를 재 요청하는 방식으로 신선도를 유지
  • 유효 기간을 부여하는 방법으로 Expires 헤더(날짜)와, Cache Control 헤더의 Max-Age 값을 사용 가능

• 캐시의 유효기간이 만료되었다면, 신선도를 재검사 해야하는데 두 가지 방식이 있음
  • 날짜를 기반으로 서버에게 물어보기
  • 엔티티 태그를 기반으로 서버에게 물어보기

날짜를 기반으로 서버에게 물어보는 법

• If-Modified-Since 헤더를 통해 특정 시점 이후 원본 데이터 변경에 대해 답 요청
• 만약 변경이 있었다면, 새 자원으로 응답하도록 서버에게 요청

• 다음과 같이 요청을 받으면 서버는 다음과 같은 상황을 따르게 됨
  • 변경
  • 변경되지 않음
  • 삭제
• 자원 변경시
  • 상태코드 200과 함께 새 자원 반환
• 자원 변경이 없었을 시
  • 상태코드 304와 함께 변경되지 않음을 알림
  • 이 때, 변경 시점도 함께 알려줄 수 있음
• 삭제시
  • 404를 통해 자원이 존재하지 않음을 알림

엔티티 태그를 기반으로 서버에게 물어보는 법

• Etag(엔티티 태그)는 자원의 버전을 식별하기 위한 정보
• 버전이란 유의미한 변경사항을 의미
• 자원이 변경될 때 마다, 식별하는 Etag값이 변경

• 신선도 검사를 위해 If-None-Match 헤더를 사용

• 해당 요청을 통해, Etag 값이 바뀌었는지 확인하고, 변경 시에 새 자원으로 응답해달라는 의미
• 서버는 다음과 같은 상황을 따름
  • 변경
  • 변경되지 않음
  • 삭제
• 변경 시
  • 200값과 함께 데이터, Etag값을 응답
• 변경되지 않았을 시
  • 304값과 함께 응답
• 삭제시
  • 404 응답

쿠키

• HTTP는 기본적으로 스테이트리스 프로토콜임
• 그러나 웹을 구성할 때는 로그인 상태 유지 등, 상태를 유지해야하는 경우가 필요함
  • 이 때 사용하는 것이 쿠키
• 쿠키란, 서버에서 생성되어 클라이언트에 저장되는 데이터
  • 스테이트리스 프로토콜인 HTTP의 특성을 보완하기 위한 수단
  • <이름, 값> 쌍의 형태를 띄고 있음
  • 적용 범위 및 만료 기간 등을 가질 수 있음
• 서버는 쿠키를 생성하여 클라이언트에게 전송하고, 클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 동일한 서버에 보내는 요청 메세지에 쿠키를 포함하여 전송
  • 이 메세지를 통해 두 요청이 같은 클라이언트에서 온 것인지, 로그인 상태를 유지하고 있는지 등 확인 가능

• Set-Cookie 헤더를 통해 쿠키의 이름, 값 과 세미콜론으로 구분된 속성을 전달할 수 있음

• 여러 개의 쿠키를 전달 시 세미 콜론을 이용하여 여러 쿠키의 이름 전달 가능

• 같은 도메인이라도 쿠키를 구분하여 사용하고 싶을 때는, path를 사용하여 적용될 경로를 명시

• Expires 또는 Max-Age를 통해 유효기간 설정 가능

쿠키의 한계점

• 보안에 취약함
  • 이를 보완하기 위해, Secure와 HttpOnly 속성 이용
  • Secure
    • HTTPS 프로토콜일 때만 쿠키를 전송하는 속성
  • HttpOnly
    • HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성
    • 자바스크립트에서 쿠키에 접근하지 못하도록 하는 속성
  • 두 개 모두 위변조를 방지하기 위한 속성임

콘텐츠 협상과 표현

• 콘텐츠 협상
  • 같은 URI에 대하여 가장 적합한 자원의 형태를 제공하는 메커니즘
  • 송수신 가능한 자원의 형태를 "자원의 표현"이라고 함
  • 주요 헤더로는 Accept, Accept-Language, Accept-Charset, Accept-Encoding 헤더 등이 포함
    • 예시로, 한국어일 경우 Accept-Language: ko가 헤더에 추가
    • HTML 문서 타입 선호시, Accept:text/html을 추가하여 서버에 요청

• 선호도에 우선순위를 반영할 수 있는 특징이 있음