[HTTP] HTTP란? 개념와 특징, 구조

✏️ HTTP (HyperText Transfer Protocol)

HyperText 문서를 통해서 연결할 수 있는 html을 전송하는 프로토콜로 처음 사용되었으나 현재는 HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML(API) 등 거의 모든 형태의 데이터 전송이 가능하며, 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

HTTP/1.1, HTTP/2의 기반 프로토콜은 TCP 프로토콜 위에 동작을 하며, HTTP/3는 UDP기반으로 개발되어 있다. 현재 HTTP/1.1 주로 사용하며 HTTP/2, HTTP/3도 점점 증가하는 추세다.

✏️HTTP의 특징

클라이언트와 서버 구조로 되어있다.

Request Response 구조. 클라이언트가 서버에 요청을 보내고, 응답을 대기한다. 서버가 요청에 대한 결과를 만들어서 응이 오면 그 응답 결과를 열어서 클라이언트가 동작을 하게 된다.

Stateless, 무상태 프로토콜을 지향한다

서버가 클라이언트의 상태를 보존하지 않는다는 의미다.

• Stateful (상태유지): 서버가 클라이언트의 이전 상태를 보존하는 것.

아래의 예시에서 상태유지와 무상태를 이해해보자.

Stateful
고객: 노트북 얼마에요? 점원: 100만원입니다. 고객: 2개 주세요. 점원: 200만원입니다. 카드 혹은 현금 어떻게 결제하시겠어요? 고객: 카드로 결제해주세요. 점원: 200만원 결제됐습니다. ==> 질문을 할 때마다 정보를 상기시켜주지 않아도 클라이언트가 요청을 할 수 있다. 하지만 이렇게 상태를 유지해야하는 경우에는 대화마다 점원이 바뀐다면 의사소통하기 어려움.

Stateless
고객: 노트북 얼마에요? 점원: 100만원입니다. 고객: 2개 주세요. 점원: 뭐를 2개 드릴까요? 고객: 노트북입니다. 점원: 200만원입니다. 카드 혹은 현금 어떻게 결제하시겠어요? 고객: 카드로 결제해주세요. 점원: 뭐를, 몇 개, 어떻게 결제해드릴까요? ==> 무상태에는 위처럼 말하면 안되고, 클라이언트는 요청을 할 때마다 요청 정보를 매번 말해야 한다. 즉, Stateful(상태유지)때와는 달리 필요한 데이터를 매번 말해야 하는 것.

상태유지는 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 함.) 하지만 무상태는 중간에 다른 점원으로 바뀌어도 된다. 갑자기 고객이 증가해도 점원 대거 투입할 수 있다.(=클라이언트 요청이 갑자기 증가해도 서버를 대거 투입할 수 있다.) 또한 무상태는 응답 서버(점원)를 쉽게 바꿀 수 있다. 즉, 무한한 서버 증설이 가능한 것이다.

즉, 무상태는 클라이언트가 애초에 요청할 때 필요한 데이터를 다 담아서 서버에 보내버리기 때문에 중간에 아무 문맥이 필요하지 않고, 요청을 받던 서버가 아닌 다른 서버가 받아도 괜찮은 것이다.

⚠️Stateless의 한계

• 로그인과 같은 상태를 유지해야하는 경우에는 어쩔수없이 사용해야하는 경우가 있다.
• 전송되는 데이터량이 크다.

이러한 한계에도 웹 애플리케이션을 설계할 때는 최대한 무상태로 설계하는 것이 바람직하다.

비연결성

TCP/IP 연결 같은 경우에는 소켓을 연결한 다음 요청을 보내서 응답을 받게되는데 이 연결은 유지가 된다. 클라이언트1이 요청을 보내 응답을 받고, 다시 클라이언트2, 클라이언트3이 서버에 접속해서 요청>응답을 받아도 클라이언트1은 여전히 연결이 계속 유지되는 것. 이렇게 연결을 유지하는 모델은 계속 서버와 연결을 유지해야한다는 단점을 가지고 있다.

연결을 유지하지 않는 모델은 클라이언트가 요청을 하고 응답을 받게되면 바로 연결을 끊는다. 이렇게 하면 서버는 연결 유지를 하지 않아도 되고, 최소한의 자원을 사용한다는 장점을 가진다.

HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 일반적으로 초 단위 이하의 빠른 속도로 응답하기 때문에 1시간동안 수 천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적다. ex) 계속 연속해서 검색 버튼을 누르지 않는다. 서버 자원을 매우 효율적으로 사용할 수 있는 것이다.

⚠️비연결성의 한계

• TCP/IP연결을 새로 맺는 다는 것은 3way handshake, SYN/ACK하는 시간이 추가된다는 뜻.

• HTML뿐만 아니라 이미지, CSS, 자바스크립트 등 수많은 자원이 함께 다운로드가 된다.

  ==> 그래서 HTTP는 지속연결(Persistent Connection)을 기본적으로 사용하는데 지속연결이 되면, 요청/HTML응답 > 요청/자바스크립트 응답 > 요청/이미지응답 > 종료 이 과정이 연결, 연결종료를 반복하지 않고 가능하다.

✅ Stateless를 기억하자.

• 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 (ex.1시에 치킨 이벤트)을 다룰 때는 특히.

• 이런 이벤트 설계할 때는 순수한 HTML 정적 페이지를 우선 뿌리고, 사용자들이 한번 보게 한 다음 시간을 벌고 이벤트 버튼을 누르도록 유도해야 함.

  ==> 새로운 요청이 들어올 때마다 자유롭게 서버 확장이 가능하므로, 수평적 확장이 가능하게 하여 트래픽이 증가할 때 자원을 효과적으로 할당함.

✏️HTTP 메시지

HTTP의 요청메시지와 응답메시지는 구조가 다르다.

먼저 HTTP 메시지는 아래와같은 구조를 가진다.

start-line(시작라인)
header(헤더)
empty line(공백라인..CRLF)
message body

[HTTP 요청 메시지]

GET /seach?q=hello&hl=ko HTTP/1.1 ==> 시작라인
Host : www.google.com ==> 헤더
==> 공백라인

요청메시지도 본문에 필요한 메시지 body 가질 수 있음.

[HTTP 응답메시지]

HTTP/1.1 200 OK
Content-Type: text/thml;charset=UTF-8 Content-Length: 3423
==> 공백라인
<html> <body> … </body> </html> ==> http 응답 메시지 (html이면 html내용이 들어있게 됨.)

시작라인

stat-line 는 크게 request-line / status-line 로 나눌 수 있다.

• request-line(요청라인) : HTTP Request 메시지의 시작 부분으로, 클라이언트가 서버에게 요청하는 내용을 정의

  • 구조: Method(메서드) SP Request-URI(요청 URI) SP HTTP-Version(HTTP 버전) CRLF

    예: GET /index.html HTTP/1.1

• **Status-Line (상태 라인): **HTTP Response 메시지의 시작 부분으로, 서버가 클라이언트에게 응답하는 내용을 정의

  • 구조: HTTP-Version(HTTP 버전) SP Status-Code(상태 코드) SP Reason-Phrase(상태 이유 구문) CRLF

    예: HTTP/1.1 200 OK

헤더

• HTTP 전송에 필요한 모든 부가 정보 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저)정보, 메시지 바디의 내용, 서버 애플리케이션 정보, 캐시 관리 정보 등이 있음.
• 필요 시 임의의 헤더 추가 가능

메시지 바디

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능