HTTP

HTTP

HyperText Transfer Protocol.
인터넷에서 데이터를 주고받을 수 있도록 하는 프로토콜. Application Layer 에 해당한다. HTTP는 클라이언트-서버 관계에서 다음과 같이 동작한다.
요청(request): client -> server
응답(reply): server -> client

이 과정에서 서버와 클라이언트 간에는 HTML, JSON, XML 등의 정보 파일이 교환된다.

HTTP의 특징

• 일반적으로 HTTP는 reliable transport를 지향하며 따라서 TCP/IP를 기반으로 한다.
• HTTP는 일반적으로 connectionless다. 즉, 클라이언트와 서버의 1회 연결 후, 클라이언트의 요청에 대한 서버의 응답이 완료되면 연결을 끊어버린다. 이로 인한 장단점은 다음과 같다.
  • HTTP는 인터넷에서 불특정 다수의 통신 환경을 지원하다. 만약 서버에서 특정 클라이언트들과의 연결을 지속한다면 이에 따라 많은 리소스 및 오버헤드가 발생한다.
  • 따라서 연결을 유지하기 위한 리소스를 줄여 더 많은 연결을 지원하기 위해 비연결적 특징을 가진다.
  • 그러나 서버와 클라이언트의 연결이 매번 끊어지는 특성으로 인해 서버는 클라이언트의 상태를 모르는, stateless가 된다.
  • 따라서 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결을 생성해야하는 오버헤드가 발생한다.
  • HTTP 1.1부터는 위의 문제점 해결을 위해 Keep-Alive 기능을 제공한다.
• connectionless는 자연스럽게 stateless로 이어진다. 따라서 서버는 클라이언트의 상태를 기억할 수 없으며, 다음과 같은 일이 발생할 것이다.

  쇼핑몰 사이트 접속 -> 로그인 -> 상품 클릭 -> 로그인 -> 주문 -> 로그인 -> ,,,

• 사용자 정보를 기억하지 못하고 위와 같이 매번 로그인을 해야한다면 매우 불편할 것이다. 이를 위한 해결법은 다음과 같다.
  • 쿠키: HTTP 헤더에 set-cookie를 설정하여 클라이언트가 쿠키를 유지하고, 서버가 이를 활용하는 방법.
  • 세션: 쿠키는 클라이언트에 저장되기 때문에 보안에 취약하다. 세션은 서버단에서 정보를 저장한다. 그러나 세션 역시 정보 탈취의 위험이 있으며 서버에 사용자의 정보를 저장하기 때문에 서버의 메모리를 차지하고 이는 곧 오버헤드로 이어질 수 있다.
  • 토큰: OAuth, JWT. 보호 대상의 데이터를 그대로 저장하는 것이 아닌, 토큰으로 치환하여 저장한다. 정보 탈취를 당하더라도 토큰으로부터 데이터를 얻을 수 없어 보안성이 높다.

HTTP의 버전

HTTP 1.0

• Connectionless. 따라서 동일한 클라이언트라도 새로운 요청에 대해 매번 새로운 연결(3-way handshake)을 생성해야 한다.
• 요청 / 응답에 대한 메타 데이터를 포함한 헤더 필드 제공 (Status Code, Content-Type 등)
• Method: Get, Head, Post

HTTP 1.1

• Keep Alive: 동일한 클라이언트의 요청마다 매번 3-way handshake가 요구된다면 이는 오버헤드를 유발한다. 이를 해결하는 것이 Keep-Alive다. 정해진 시간 또는 횟수만큼 연결을 유지하며, Htpp 헤더를 통해 설정할 수 있다.
• 그러나 Keep Alive가 항상 좋은 것은 아니다. 위에서 언급했듯, 연결을 지속하는 것 역시 오버헤드가 되며 사용자가 많다면 연결이 많아져 새로운 사용자를 수용하지 못할 위험도 있다.
• Pipelining: 기존의 HTTP 1.0의 경우, 요청에 대한 응답을 클라이언트가 받아야지만 다음 요청을 할 수 있었다. 따라서 요청 1에 문제가 생긴다면 요청 2, 요청 3 역시 진행되지 못한다. 파이프라이닝은 앞선 요청에 대한 응답이 오기 전에 추가적인 요청을 가능하게 함으로써 각 요청에 대한 각 응답을 개별적으로 받고 처리한다. 이로 인해 응답속도가 높아지고 페이지 뷰의 속도가 빨라진다.
• Host Header: 버츄얼 호스팅을 가능하게 한다. 즉 하나의 IP가 여러 도메인을 보유할 수 있다.
• Method: Get, Head, Post, Put, Delete, Trace, Options

HTTP 2.0

• HTTP 1.1의 클라이언트에서 응답 대기 없이 서버로 요청을 보낸다고 해도, 서버에서는 클라이언트의 요청 순서대로 응답을 해야한다. 이로 인해 HOL(Head of Line) 문제가 발생 가능하다. 즉 클라이언트에서 파이프라이닝을 적용했다고 해도 앞선 요청에 대한 처리 및 응답이 지연되면 뒤의 요청에 대한 처리가 지연될 수 있다.
• Multiplexed Streams: HOL blocking을 해결할 수 있다. 하나의 connection으로 동시에 여러 메시지를 주고 받을 수 있다. 따라서 응답 역시 순서에 상관 없이 stream으로 주고 받는다.
• Stream Prioritization: 응답에 대한 우선순위를 설정하여 우선순위가 높은 요청에 대해 먼저 응답한다.

응답 상태 코드

응답 상태 코드 (status code): 클라이언트의 요청에 대한 서버의 응답 (처리) 상태.

• 1xx (정보): 요청을 받았으며 작업을 계속 진행한다.
• 2xx (성공): 요청을 성공적으로 받고 처리하였다.
• 3xx (리다이렉션): 클라이언트는 요청을 마치기 위해 추가적인 작업이 요구된다.
• 4xx (요청 오류): 클라이언트에 오류가 있다. (잘못된 요청 등)
• 5xx (서버 오류): 서버에 오류가 있다. 즉 서버가 요청을 처리하지 못했다.

HTTP Method

• Get: 서버에게 리소스를 요청 (조회)
• Head: Get과 유사하지만, 서버는 body 없이 헤더만을 응답. 즉 헤더의 정보만을 요구할 때 사용
• Put: 서버가 요청의 body를 통해 데이터 추가(최초 1번) 또는 수정을 수행한다.
• Post: 서버가 요청의 body를 통해 데이터를 추가한다. (동일한 데이터의 경우에도 계속 데이터 추가)
• Delete: 서버가 요청받은 리소스를 삭제한다.
• Trace: 클라이언트-서버 사이의 모든 HTTP Application의 요청/응답을 따라가며 메시지의 이상 유무를 확인한다.
• Options: 서버에게 특정 리소스가 어느 메소드를 지원하는지 물어본다.

HTTP 헤더 구성

추후 작성 예정