HTTP 구조와 Stateless

HTTP(HyperText Transfer Protocol)

현대 http는 1.1 버전에서 나온 기능을 많이 사용한다. 현재 나와있는 http2, http3는 모두 http 1.1 버전 기능의 성능을 높인 것이다. http2까지는 TCP 위에서 동작한다. 하지만 HTTP3는 UDP를 기반으로 개발을 하고 있다. 그 이유는 TCP가 3-way hand-shake를 하기 때문에 속도가 느리고 데이터가 너무 많아서 빠른 메커니즘이 아니기 때문이다. TCP는 이미 많이 설계가 되어 있어 수정이 불가능한데, UDP는 수정이 가능하여 새로 설계하여 http3을 개발하고 있다.

HTTP 구조

HTTP 메시지 구조는 위 사진처럼 되어 있다. 3번째에 있는 공백 라인은 데이터가 없어도 무조건 있어야 한다.

 

-HTTP 요청 메시지

첫 번째 줄은 start-line라고 부르며 요청 메시지에서는 request-line이다.

request-line: HTTP 메서드(GET, POST 등), 요청 대상(/search?q=hello&hl=ko), HTTP Version 이렇게 3가지가 온다.

 

-HTTP 응답 메시지

첫 번째 줄은 start-line라고 부르며 요청 메시지에서는 status-line이다. 

status-line: HTTP 버전, 상태 코드(200, 400, 500 등), 이유 문구(사람이 이해 가능한 짧은 글)

맨 마지막 파란색 박스는 message-body인데 올 수도 있고 안 올 수도 있다.

 

-HTTP 헤더

HTTP 헤더는 위 사진의 노란색 박스처럼 생겼으며 field-name: OWS field-value OWS이다.(OWS는 띄어쓰기 허용을 의미) 따라서 "Host :www.google.com"은 에러가 난다. 그리고 filed-name은 대소문자 구분이 없다.

그리고 HTTP 헤더는 body를 제외한 모든 정보가 들어있다고 보면 된다. 표준 헤더는 엄청 많고 서버와 협의가 되면 의해 임의의 헤더를 추가할 수 있다.

 

-HTTP 메시지 바디

실제 전송할 데이터이며 HTML, 이미지, 영상 JSON 등의 데이터를 전송할 수 있다. 데이터를 압축해서도 보낼 수 있다.

Stateful와 Stateless

Stateful(상태 유지)

Stateful은 클라이언트와 서버가 소통하는 과정에서 서로의 이전 정보를 알고 있는 것이다. 예를 들어 로그인이 되어 있다고 치면 자신이 누구인지 한 번 통신을 하면 그다음 요청부터는 자신의 정보를 담은 데이터를 주지 않아도 된다. 하지만 이렇게 서버를 운영하면 클라이언트와 서버가 1 대 1로 연결이 되어야 하며 수 n명의 회원이 요청을 보내면 서버가 n개가 있어야 한다. 뿐만 아니라 서버에서 오류가 난다면 그 서버와 통신하는 사용자는 서비스를 이용할 수 없다는 치명적인 단점이 있다.

Stateless(무상태)

Stateless는 클라이언트가 보낸 보낸 정보를 서버가 저장하지 않는다. 그렇기에 요청을 할 때마다 자신의 정보를 담은 데이터를 보내줘야 한다. 이렇게 서버를 운영하면 1 : N으로 서버를 운영할 수 있다. 클라이언트는 서버가 여러 개 있어도 아무 서버에게 요청을 보내도 다 처리가 가능하다. 이로 인해 서버 1개에서 오류가 나도 다른 서버에 요청을 보낼 수 있다. 이는 엄청난 확장성을 가져 서버 수평 확장에 유리하고 이를 스케일 아웃이라고 부른다. 하지만 이런 Stateless도 단점은 존재한다. 데이터를 너무 많이 보내는 점은 단점이라 할 수 있다.

 

-대용량 트래픽

수강 신청이나 선착순 이벤트는 순간적으로 요청이 많이 들어와서 대용량 트래픽이 발생한다. 이런 경우는 서버 개발자가 처리하기 많이 힘들다. 이때 해결 방법은 이벤트 페이지 전에 사용자들이 보고 즐길 수 있는 페이지를 만들어서 한 눈을 팔게 하면 트래픽을 좀 줄일 수 있다.

비 연결성(connectionless)

계속 연결하는 모델

사진처럼 클라이언트와 서버가 계속 연결을 유지하면 클라이언트가 서버를 이용하지 않을 때도 이용하지 않아 자원이 낭비된다. 따라서 많은 사용자가 서비스를 이용할 수 없다.

연결을 유지하지 않는 모델

사진처럼 요청과 응답이 이루어지면 TCP 연결을 종료하는 방식이다. 연결을 유지하지 않으면 최소한의 자원으로 서버를 유지할 수 있다. 많은 사용자가 서비스를 이용해도 실제 서버에서 동시 처리하는 요청은 수십 개 이하로 작다. 

 

-단점

1. 3-way-handsake를 계속해서 시간이 오래 걸림

2. js, css, 이미지 등 리소스가 필요할 때마다 연결을 새로 해야 됨

=> 이런 문제를 HTTP 지속 연결(Persistent Connections)로 해결했다.

 

-HTTP 지속 연결(Persistent Connections)

지속 연결이 없을 때

HTTP 지속 연결을 사용하지 않으면 리소스를 가져올 때마다 새로 TCP 연결을 해서 시간이 많이 소요된다.

지속 연결을 할 때

HTTP 지속 연결을 사용하면 매번 요청을 하지 않고 한 번에 리소스를 다 가져올 수 있다.