Portfolio

모든 것이 HTTP

HTTP: HyperText Transfer Protocol

HTTP 메세지에 모든 것을 전송하는 시대이다. 맨 처음에는 HTML, Text를 전송하기 위해 나왔는데, 요즘은 이미지, 음성, 영상 파일 뿐 아니라 json, xml, 서버 간에 데이터를 주고 받을 때도 사용되어 거의 모든 형태의 데이터가 전송 가능하다.

HTTP 버전 중 가장 많이 사용되고 있는 1.1 버전의 내용을 잘 알아두자. 1.1 이후에 나온 2, 3 버전은 1.1 기반으로 성능 개선만 한 버전이기 때문에 1.1 버전을 잘 알아두면 이해하는데 무리가 없다.

HTTP/1.1, HTTP/2 는 TCP 기반 프로토콜이고, HTTP/3 은 UDP 기반 프로토콜이다.

크롬브라우저로 네이버를 들어가서 개발자도구를 확인해보았다. 프로토콜 탭을 보면 나와있는 h2가 바로 HTTP 버전을 의미하는 것이다. HTTP/2, HTTP/3도 많이 사용되고 있는 추세이다.

HTTP 특징

클라이언트 서버 구조

무상태 프로토콜(stateless), 비연결성

HTTP 메세지를 통해서 통신 (보낼 때도 받을 때도)

단순하고 확장 가능함

이 내용은 아래에 더 자세히 설명할 것이다.

클라이언트 서버 구조

HTTP는 클라이언트 서버 구조로 이루어져 있다. 클라이언트 서버 구조는 Request Response 구조로, 클라이언트가 서버에 요청을 보내고 응답을 대기한다. 서버는 요청을 받고 요청에 대한 결과를 만들어서 응답한다.

되게 간단한 구조인데, 이렇게 클라이언트 서버를 따로 구분하는 것이 중요하다. 클라이언트는 UI, 사용성에 집중하고, 서버는 비지니스 로직, 데이터 등에 집중해서 각각 독립적으로 진화할 수 있기 때문이다.

예를 들어, 트래픽이 엄청 많아졌다고 가정할 때, 클라이언트를 건드리지 않고 서버에서 해당 로직만 수정해주면 된다.

Stateful, Stateless

Stateful은 서버가 클라이언트의 상태를 유지한채 통신한다.

Stateless는 서버가 클라이언트의 상태를 유지하지 않고 통신한다.

HTTP는 무상태 프로토콜(Stateless)을 지향한다.

예를 들어 설명해보겠다.

Stateful

Stateless

나: 노트북 주세요.

직원: 100만원입니다. (노트북 산다는 사실을 유지)

직원: 100만원입니다.

나: 2개 주세요.

나: 노트북 2개 주세요.

직원: 200만원 입니다.

위의 대화는 문제가 없이 문맥이 흘러간다. 그런데 여기서 만약 직원이 중간이 바뀌면 어떤 일이 생길까?

구분선 이후로부터 직원이 바뀌었다고 가정했을 때,

Stateful의 경우부터 보면, 갑자기 새로운 직원에게 2개를 달라고 하는 셈이다. 그럼 직원은 뭐를 2개 달라는 거지?라고 생각하고 문맥 흐름이 이상해진다.

그러나, Stateless의 경우에는 다시 노트북 2개를 달라고 정보를 구체적으로 말해 문맥상 아무런 문제가 생기지 않는다.

이렇게 Stateful은 항상 같은 서버가 유지되어야 한다. 서버에 클라이언트가 보낸 이전 요청들을 유지하고 있어서 클라이언트는 요청을 보낼 때, 이전 요청을 포함해서 보내진 않는다. 이런 경우, 만약 서버에 장애가 생기면 아무 서버나 연결할 수가 없다. 이전 요청들이 없기 때문에.

그런데 Stateless는 이전 요청을 유지하지 않기 때문에 서버에 장애가 생기더라도 아무 서버랑 연결할 수 있다. 또, 많은 서버가 필요할 경우 스케일 아웃이 가능하다. 즉, 수평 확장에 유리하다.

그렇지만 Stateless도 한계가 존재한다. 모든 것을 무상태로 설계할 수는 없다. 예를 들어, 로그인의 경우 어떤 사용자가 로그인을 했는지 상태를 서버에 유지해야하기 때문에 무상태로 설계하면 안된다. 이때는 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지하는데, 이러한 상태 유지는 최소한만 사용하는 것이 좋다.

비 연결성(connectionless)

HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 여기서 연결이라는 것은 클라이언트가 서버에 요청을 보내면 서버가 응답을 다시 보내는데, 이 때 연결을 유지하지 않기 때문에 응답 후에는 바로 TCP/IP 연결을 종료한다. 이렇게하면 서버 자원을 매우 효율적으로 사용할 수 있다.

그러나 한 번 요청할 때마다 TCP/IP 연결을 새로 맺어야하는 한계가 있다. 이 말은 즉, 3 way handshake 시간이 그만큼 추가된다는 것을 의미한다. 그래서 이 문제를 HTTP 지속 연결로 해결하고 있다. HTTP/2, HTTP/3 버전에서는 이런 부분을 더 많이 개선했다.

HTTP 메세지

HTTP 메세지는 요청 메세지와 응답 메시지로 나뉜다.

HTTP 메시지 구조는 다음과 같으며, 요청 메세지와 응답 메세지의 차이는 시작 라인이다.

그리고 공백 라인은 꼭!!! 필수로 빠지면 안된다. body 부분은 선택사항이다.

HTTP 요청 메세지의 시작 라인

start-line 중 request-line 으로, method (공백) request-target (공백) HTTP-version (엔터) 로 구성된다.

1) method: 서버가 수행해야 할 동작을 지정하는 HTTP 메서드가 들어간다. 이건 다음 챕터에서 더 자세히 다룰 예정이다.

2) request-target: 요청 대상을 적는 곳이다. 절대 경로 '/'로 시작하는 경로와 '?'로 시작하는 쿼리를 적어주면 된다.

3) HTTP-version: HTTP 버전을 작성한다.

HTTP 응답 메세지의 시작 라인

start-line 중 status-line 으로, HTTP-version (공백) status-code (공백) reason-phrase (엔터) 로 구성된다.

1) HTTP-version: HTTP 버전을 작성한다.

2) status-code: HTTP 상태 코드를 작성한다. 요청 성공인지 실패인지 등을 숫자로 나타낸다. 이것도 뒤에서 자세히 다룰 예정이다.

3) reason-phrase: 숫자만 보고 상태를 파악하기 어려울 수도 있어서 사람이 이해할 수 있는 짧은 상태 코드를 설명하는 문구를 나타낸다.

HTTP 헤더

HTTP 전송에 필요한 모든 부가정보를 담는다. 표준 헤더로 메세지 바디 내용, 메세지 바디 크기, 요청 클라이언트 정보 등 너무 많아서 외울 필요는 없다..!

HTTP 메세지 바디