네트워크(3)

5. DNS

사람들이 네트워크를 통해 원격의 컴퓨터에 접속하기 위해서는 IP주소를 이용하여야 하지만, IP주소를 일일이 외울 수 없기 때문에 외우기 쉽고 알기 쉬운 도메인 이름을 사용한다.

DNS(Domain Name System)는 도메인 이름을 사용했을 때 입력한 도메인 주소를 실제 네트워크 상에서 사용하는 IP 주소로 바꾸는 역할을 하는 시스템이다.

6. 쿠키와 세션

HTTP의 특징 중에 비연결성(Connectionless) 과 무상태(Stateless) 로 인해 클라이언트의 이전 상태를 알 수 없게 되어서 클라이언트가 과거에 로그인을 성공하더라도 로그 정보를 유지할 수가 없기 때문에 매번 인증을 해야한다는 문제가 있었다.(이전글)

이 문제를 해결하기 위해 즉, 사용자에 대한 인증을 유지하기 위해 쿠키와 세션을 사용한다.

6-1. 쿠키

쿠키(Cookie)란 사용자가 어떠한 웹 사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를 통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일을 말한다.

구성 요소

• 이름
  • 쿠키를 구별하는 데에 사용되는 이름
• 값
  • 쿠키의 이름과 관련된 값
• 쿠키의 만료 기간
  • 쿠키가 유지되는 시간을 의미
  • 브라우저를 종료해도 쿠키는 소멸되지 않고 계속 존재할 수도 있다.
  • 쿠키를 강제로 제거할 수도 있다.
• 도메인
  • 쿠키를 전송할 도메인
  • 쿠키에 특정 도메인을 지정하면 쿠키는 그 도메인 내에서만 유효하다.
• 경로
  • 쿠키를 전송할 요청 경로

쿠키 동작 방식

• 쿠키 생성 단계
  • 클라이언트가 웹 서버에 쿠키의 생성을 요청하면 웹 서버는 쿠키를 생성한다.
  • 생성된 쿠키는 웹 서버에 의해 클라이언트로 전달한다.
• 쿠키 저장 단계
  • 전달된 쿠키는 클라이언트 컴퓨터의 하드디스크의 쿠키 저장 장소에 저장된다.
• 쿠키 전송 단계
  • 저장된 쿠키는 브라우저가 웹 서버에 요청을 할 때마다 URL과 함께 쿠키를 전송한다.

쿠키의 사용

• 로그인 창의 아이디를 자동완성
• 공지 메세지 "오늘 더 이상 이 창을 보지 않음" 체크
• 쇼핑몰의 장바구니 기능

위와 같은 조작되거나 가로채이거나 지워져도 큰 일은 일어나지 않는 정보들을 쿠키로 저장한다.

6-2. 세션

세션(Session)이란 쿠키를 기반으로 하고 있지만 생성된 모든 정보들은 클라이언트의 컴퓨터가 아닌 서버에 저장한다.

세션 동작 방식

• 세션 생성
  • 브라우저를 통한 요청에 대한 응답이 발생되면 서버에 세션이 생성된다.
  • 서버는 쿠키 형태의 유일한 값인 세션ID(JSESSIONID)를 생성해 클라이언트로 전송한다.
• 세션 활용
  • 세션이 생성된 후 클라이언트에서 서버로의 요청이 발생할 경우 세션 ID가 함께 전송된다.
  • 이 세션 ID를 통해서 서버는 사용자를 구분한다.

네이버에 로그인을 하고 네이버 내의 다른 사이트를 돌아다녀도 로그인이 유지가 된다. 하지만 브라우저에서 쿠키를 강제로 삭제하고 새로고침을 하면 로그아웃이 된다.

이 이유는 서버에서는 세션에 로그인 정보를 가지고 있지만 그 로그인 정보가 내 것인지를 증명할 세션 ID가 쿠키를 삭제함으로써 지워졌기 때문이다.

6-3. 쿠키와 세션의 차이

쿠키와 세션은 서로 비슷한데 세션도 결국 쿠키를 사용하기 때문이다.

• 쿠키는 클라이언트(사용자 PC)에 저장이 되고 세션은 웹 서버에 저장된다.
• 보안 면에서 세션이 더 뛰어나다.
  • 세션은 쿠키를 이용해서 세션 ID만 저장하고 세션 ID로 구분해서 서버에서 처리하기 때문이다.
• 쿠키는 서버의 자원을 전혀 사용하지 않고 세션은 서버의 자원을 사용한다.
  • 세션이 보안이 더 좋을지라도 모든 것들을 세션으로 처리한다면 사용자들이 몰릴 때 서버에 부하가 걸릴 수 있다.
  • 중요한 정보는 세션으로 관리하고 중요하지 않은 정보는 쿠키로 관리하는 방법을 사용한다.
• 쿠키에 만료 시간을 설정할 수 있지만 브라우저를 종료해도 계속해서 남아있다. 반면에 세션은 만료 시간을 정한다 해도 브라우저가 종료되면 만료 시간에 상관없이 삭제된다.

7. REST API

7-1. API

API는 Application Programming Interface의 약자로 구글 맵 API, 카카오 비전 API 등 기존에 있는 응용 프로그램을 통해서 데이터를 제공받거나 기능을 사용하고자 할 때 사용하는 인터페이스 및 규격을 말한다.

Interface는 사물 간 또는 사물과 인간 간의 의사소통이 가능하도록 일시적 혹은 영속적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 의미한다.

예를 들어서 TV 는 사용자가 TV 를 끄거나 키고, 채널을 변경하기 위한 제어 장치가 필요한데 이를 위해 리모컨이 있는 것이다. 여기서 리모컨을 인터페이스라고 한다.

소프트웨어와 소프트웨어 사이에도 수 많은 정보 요청과 교환이 일어나는데 이들 사이에서도 리모컨처럼 소프트웨어들 간의 소통할 수 있는 창구가 필요하다. 즉 API는 사람을 위한 인터페이스가 아니라 프로그램을 위한 인터페이스라는 것이다.

7-2. REST API

REST 란 REpresentational State Transfer 의 약자로 웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용”하는 것으로, 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다고 한다.

더 구체적으로는 HTTP URI을 통해 자원을 명시하고, HTTP Method(POST, GET, DELETE, PUT)를 통해 해당 자원에 대한 CRUD(CREATE, READ, UPDATE, DELETE) 오퍼레이션을 적용하는 것이라고 한다.

REST 아키텍처의 원칙

• 클라이언트-서버 구조(Client-Server)
  • 클라이언트 구현과 서버 구현은 서로에 독립적으로 수행된다.
  • 클라이언트 측의 코드는 서버에 영향을 주지 않고 언제든지 변경할 수 있으며 그 반대도 마찬가지이다. 따라서 서로 간의 의존성이 줄어들게 된다.
• 무상태성(Stateless)
  • 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다.
    • 즉 세션과 쿠키 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
  • 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
    • 각 API 서버는 클라이언트의 요청만을 단순 처리한다.
    • 이전 요청이 다음 요청의 처리에 연관되어서는 안 된다.
• 캐싱 가능(Cacheable)
  • REST는 HTTP 표준을 기반으로 만들어졌기 때문에 HTTP의 특징인 캐싱을 사용할 수 있다.
    • 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 확장성과 성능을 향상시킨다.
• 균등한 인터페이스(Uniform Interface)
  • Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다. 즉, 통일된 Interface를 통해 어떠한 기술(Python, PHP, C#, Ruby, Java)이든 플랫폼(iOS, Android, Mac, Windows)이든 상관없이 사용할 수 있다.
• 계층형 구조(Layered System)
  • 클라이언트는 계층형 구조가 불가능하지만 REST 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시킬수 있다.
• Code on Demand(optional)
  • 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다.
    • 평소에는 정적인 데이터를 xml 또는 json에 담아서 클라이언트로 보내고 클라이언트가 이것을 가공한다.
    • 하지만 code on demand 라는 것은 클라이언트에 보내는 데이터를 바로 실행 가능한 코드로 보내서 이것을 클라이언트에서 실행하는 것을 말한다.

Uniform Interface 의 4가지 제약 사항

• Identification of resources
  • 리소스가 URI로 식별된다.
• Manipulation of resources through representations
  • 리소스를 삭제하거나 수정할 때 HTTP 메시지에 이러한 표현을 담아서 전송해야한다.
• Self-descriptive Messages
  • 서버와 클라이언트 사이에서 주고 받는 메시지는 스스로를 설명해야한다는 의미이다.
  • 메시지만 보고도 어떤 기능을 수행하는지 알 수 있어야 한다는 것이다.

GET / HTTP/1.1

이런 호출은 목적지가 없기 때문에 Self-descriptive 하지않다.

Get / HTTP/1.1
Host: www.example.org

이렇게 목적지를 추가하면 Self-descriptive 하다 라고 말할 수 있다.

• Hypermedia As The Engine Of Application State(HATEOAS)
  • 애플리케이션의 상태는 하이퍼미디어에 의해 변경된다는 것이다. 따라서 서버는 하이퍼미디어를 통해 다음 액션에 대한 선택지를 클라이언트에게 제공해야 한다.

아직 공부가 부족해서 이 정도까지만 정리하고 다음에 REST API 만 따로 정리해서 포스팅 해야겠다.

REST API에 대한 더 자세한 내용은 밑의 링크를 참고

참고

• http://tcpschool.com/webbasic/works
• https://senticoding.tistory.com/87
• 쿠키, 세션, 캐시가 뭔가요?
• REST API가 뭔가요?
• 그런 REST API로 괜찮은가
• https://sabarada.tistory.com/26
• REST 위키