#5 Application Layer 2 - HTTP

1. HTTP(HyperText Transfer Protocol)

• HTML 등의 하이퍼미디어 문서를 전송하기 위한 프로토콜
  
  
• 일반적으로 웹 브라우저와 웹 서버간의 통신을 위해 설계되었지만 다른 용도로 사용할 수도 있음
  
  
• 주로 TCP를 사용(HTTP/3 부터는 UDP를 사용한다고 한다.)

 

 

2. HTTP의 특성

 ① 비연결성(Connectionsless)

• HTTP 프로토콜은 서버가 클라이언트의 요청을받아 처리하고나면 연결을 유지하지 않고 해제해버림
• 더 많은 클라이언트로부터 요청을 받기 위해 연결 유지에 드는 리소스를 절약하기 위함
• 클라이언트의 요청에 대해 매번 새로운 연결을 수립하고 해제하는 오버헤드가 발생
  
  
• KeepAlive 속성을 부여하여 주기적으로 상대의 상태를 묻는 패킷을 보내 반응이 있는동안은 연결을
  유지하도록 할 수 있지만 연결을 유지하기 위해 리소스를 사용하므로 주의해야함

 

 ② 무상태(Stateless)

• HTTP 프로토콜의 비연결성으로 인해 서버는 클라이언트를 식별할 수 없는 상태
  
  
• 서버가 클라이언트를 식별하려면 어딘가에 클라이언트의 정보를 저장해둘 필요가 있음
  1. 쿠키(Cookie)
     • 클라이언트측에 클라이언트의 정보를 저장
     • 정보가 클라이언트측에 저장되기 때문에 서버에 부담이 가진 않지만 보안이 취약
  2. 세션(Session)
     • 서버측에 클라이언트의 정보를 저장
     • 정보가 서버측에 저장되기 때문에 서버의 리소스를 차지하게되지만 보안면에서 쿠키보다 나음
     • 동시 접속자 수가 많아지면 서버 과부하의 원인이 될 수 있음
     • 세션 정보 또한 중간에 탈취당할 수 있기 때문에 보안면에서 여전히 불안요소가 있음
  3. 토큰(token)을 사용한 인증
     • 보호할 데이터를 토큰으로 치환(암호화)하여 원본데이터대신 토큰을 사용하는 방식
     • OAuth, JWT 등이 대표적

 

 

3. HTTP 응답 상태코드

 클라이언트의 요청에 대한 서버의 응답에 포함되는 요청의 처리 상태를 나타내는 메시지

 

• 1XX : 요청 접수중, 처리중 등 서버의 상태를 나타내는 코드. 특수한 경우를 제외하면 거의 사용되지 않음
  
  
• 2XX : 성공 코드. 요청이 성공적으로 접수/처리된 경우
  
  
• 3XX : 리다이렉션 코드. 요청한 페이지가 새 위치로 이동했거나 마지막 요청 이후 변경이 없는 경우
  
  
• 4XX : 요청 오류 코드. 클라이언트측의 문제(잘못된 주소, 허용되지 않은 방식 등)로 처리에 문제가 생긴 경우
  
  
• 5XX : 서버 오류 코드. 서버측의 문제(미구현 기능, 불량 게이트웨이 등)로 처리에 문제가 생긴 경우

 

 

4. HTTP Method

 HTTP 프로토콜상에 정의된 요청의 방식

 

• GET : 서버에게 리소스를 요청(조회)하기 위해 사용
  
  
• HEAD : GET과 유사하지만 본문 없이 헤더만을 통해 정보를 획득하기 위해 사용
  
  
• PUT : 서버가 요청에 따라 리소스를 생성하거나 수정해야하는 경우 사용
  
  
• POST : 입력 데이터를 요청 본문에 넣어 서버에 전송하기 위해 사용
  
  
• DELETE : 서버에 리소스 삭제를 요청하기 위해 사용
• TRACE : 요청 패킷이 서버에 도착하는 사이 변조되는 등의 문제가 발생하는지 여부를 확인하기 위해 사용
• OPTIONS : 서버에게 특정 리소스가 지원하는 메소드를 알아보기 위해 사용

 

 

5. RESTful API

 ① REST(Representational State Transfer)

• HTTP 프로토콜을 개선해나가는 과정에서 이전 버전의 HTTP로 구축된 웹과의 호환성문제가 대두
• 로이 필딩(Roy Fielding)은 이를 해결하기 위해 웹과 같은 분산 하이퍼미디어 시스템을 위한
  아키텍쳐 스타일인 REST를 만들어냄
• 여기서 말하는 아키텍쳐 스타일이란 제약 조건의 집합과도 같은 의미로, REST 가 내세우는 모든
  제약 조건을 만족하여 시스템을 설계했을 때 비로소 REST 하다고 말할 수 있음

 ② REST 아키텍쳐의 6가지 제약조건

1. 클라이언트-서버 구조
   • 유저 인터페이스를 데이터 저장소와 분리하는 것으로 여러 플랫폼에 대해 인터페이스의 이식성을 높임
   • 서버측의 컴포넌트를 단순화하는 것으로 확장성을 높임
   • 서버, 클라이언트측의 컴포넌트가 독립적으로 발전 가능해짐
     
     
2. 무상태(Stateless)
   • 클라이언트의 어떤 컨텍스트도 서버에 저장되지 않으며 세션 상태 등은 전적으로 클라이언트측에 저장
   • 시스템의 가시성, 신뢰성, 확장성을 증가시키기 위함
     
     
3. 캐시(Cache)
   
   • 서버의 응답 데이터는 암시적으로든 명시적으로든 캐싱 가능 여부가 정해져있어야 함
   • 클라이언트측은 캐싱 가능하다고 정해진 응답에 대해서는 그 데이터를 재사용할 권리를 가짐
   • 네트워크 효율성을 증가시키기 위함
4. 통일된 인터페이스(Uniform Interface)
   • 컴포넌트간의 인터페이스를 통일하여 시스템의 전반적인 구조를 단순화하고 상호작용의 가시성 향상
   • 데이터가 어플리케이션이 원하는 상태가 아닌 표준화된 형식으로 전달되기 때문에 효율성이 떨어질 수 있음
   • 웹과 같은 대규모 하이퍼 미디어 데이터 전송을 위한 시스템에 최적화
     
     
5. 계층화된 시스템(Layered System)
   • 시스템을 계층화하여 시스템 전체의 복잡성을 낮추고 각 계층의 서비스를 독립적으로 관리할 수 있도록 함
   • 중개자(Intermediaries)는 로드 밸런싱을 통해 서버의 부담을 낮추고 서버의 확장성을 높여줄 수 있음
   • 데이터 처리에 오버헤드와 지연이 발생하여 사용자의 체감 성능이 떨어질 수 있지만 공유 캐싱을 통해
     이를 상쇄할 수 있음
     
     
6. Code-On-Demand(Optional)
   • 클라이언트가 서버로부터 애플릿이나 스크립트 등의 코드를 제공받아 기능을 확장할 수 있도록 함
   • 클라이언트측에 기본적으로 구현되어있어야할 기능의 수가 줄어들어 클라이언트가 단순화됨
   • 서버측에서 새로운 기능을 추가적으로 지원하기 편해져 확장성이 증가
   • 시스템의 가시성을 감소시킬 수 있는 제약이기에 필수적인 제약은 아님
   • 현재 웹 기준 자바 스크립트가 이에 해당

 

 ③ REST API - REST 규칙을 완벽하게 지키는 API

• HTTP의 규칙에만 따라도 클라이언트-서버 구조, 무상태, 캐시, 계층화된 시스템, Code-On-Demand 등
  대부분의 REST 규칙은 잘 지켜짐
  
  
• 단일 인터페이스(Uniform Interface)의 네 가지 제약조건 중 두 가지가 문제가 됨
  • 리소스의 식별(identification of resources)
    • URI를 사용함으로서 만족
      
      
  • 메시지를 통한 리소스의 조작(manipulation of resources through representations)
    • 단순히 메시지를 통해 자원을 조작할 수 있다면 만족
  • 자기 서술적 메시지(self-descriptive messages)
    • 메시지만으로 해당 요청을 어떻게 처리해야할지에 대한 충분한 정보를 포함해야함
    • 오늘날 대부분의 API가 지키지 못하는 규칙
    • 웹에서는 기본적으로 만족
      
      
  • 하이퍼링크를 통한 상태전이(hypermedia as the engine of application state - HATEOAS)
    • 애플리케이션의 상태 전이가 하이퍼미디어를 통해 이뤄짐
    • 웹에서는 기본적으로 만족

 

 ④ RESTful API - REST 스러운 API

• 완벽한 REST API를 만들기는 현실적으로 어려움이 따름
• 완벽하진 않더라도 가능한 선에서는 REST 규칙을 지키는 RESTful API를 구현할 수는 있음
• URI 매핑이 깔끔해지고 메시지가 의미하는 바가 명확해진다는 장점을 가짐

 

 

6. HTTP 헤더

 ① 요청 라인(Request Line)

• {HTTP 메소드} {요청 uri} HTTP/{HTTP 버전}  의 형태로 구성

 

 ② 공통 헤더(General Headers)

• Date : 메시지가 발행된 날짜와 시간
  
  
• Connection : 현재 전송 이후 연결의 유지여부(Keep-Alive / close)
  => HTTP /1.1 에서 주로 사용 (HTTP /2 이후로는 사용불가)
  
  
• Content-Length : 본문의 크기를 바이트단위로 표시
  
  
• Content-Type : 컨텐츠 타입(MIME)과 인코딩을 명시할 수 있음
  
  
• Content-Language : 사용자의 언어
  
  
• Content-Encoding : 컨텐츠의 압축 인코딩(br, gzip, deflate, compress, identity 등).
  
  
• Cache-Control : 요청과 응답 내의 캐싱 매커니즘을 위한 디렉티브를 정하는데 사용

 

 ③ 요청 헤더(Request Headers)

• Host : 서버의 도메인 네임
• User-Agent : 사용자가 요청을 보내는데 사용한 클라이언트(운영체제, 애플리케이션, 브라우저)
• Accept : 클라이언트가 수용 가능한 미디어 타입(MIME)
• Cookie : 웹 서버가 클라이언트에 저장해둔 쿠키 정보
• Origin : 요청이 시작된 주소
• If-Modified-since : 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한
• Authorization : 서버에게 인증 토큰을 보내기 위한 헤더. JWT 등을 사용한 인증에서 사용

 

 ④ 응답 헤더(Response Headers)

• Server : 웹 서버의 정보
  
  
• Access-Control-Allow-Origin : 서버가 허용하는 요청 시작 주소
  
  
• Access-Control-Allow-Headers : 서버가 허용하는 헤더
  
  
• Access-Control-Allow-Methods : 서버가 허용하는 메소드
  
  
• Allow : 리소스가 지원하는 메소드 집합
  
  
• Content-Diposition : 브라우저가 응답 본문을 표시할 방식(inline: 본문표시 / attachment : 다운로드)
  => attachment 의 경우 filename 옵션으로 파일명 지정도 가능
  
  
• Location : 300번대 응답(리다이렉션)이나 201 Created 응답(리소스 생성)시 이동할 페이지 주소 명시
  
  
• Content-Security-Policy : 컨텐츠 보안정책 명시(외부 컨텐츠를 가져올 경우)