TCP 는 기반 프로토콜로 HTTP 를 사용합니다. HTTP/1.1, HTTP/2 가 그렇습니다.
HTTP/3 에서는 성능 개선으로 UDP 의 기반 프로토콜로 HTTP 를 사용합니다.
주로 HTTP/1.1 을 사용하지만, 2, 3의 사용도 점점 증가하고 있습니다.
HTTP 의 특징
클라이언트와 서버가 데이터를 주고받는 구조로 되어있습니다. 클라이언트가 요청을 하면 서버에서는 요청에 대한 응답을 보내줍니다.
HTTP 메시지로 통신하며, HTTP 는 Stateless 를 지향하며 비연결성 이라는 특징을 갖습니다.
서로 계속 연결되어있지 않고 상태를 기억하지 않기 때문에, 구조가 단순하며 확장 (Scale out) 이 보다 용이합니다.
클라이언트 & 서버 구조
HTTP 의 구조는 클라이언트와 서버로 이루어져있습니다. 클라이언트가 HTTP 메시지를 서버로 보내고, 클라이언트는 응답을 받을 때 까지 기다립니다. 서버로부터 응답 (HTTP 메시지) 을 받으면 확인하여 처리를 합니다.
여기서 말하는 클라이언트는 사람이라기보다는, 해당 서비스를 사용하는 웹 페이지, 모바일 앱 등을 의미합니다.
과거에는 하나에 클라이언트, 서버가 모두 있었습니다. 그러나 클라이언트와 서버가 분리되어 각자의 역할에 보다 집중할 수 있게 되었습니다.
클라이언트에서는 단순히 사용자의 입장에서의 UI, UX, 브라우저 등에 대해서만 고려를 하면 됩니다. 서버 (백엔드) 에서는 트래픽에 대해서만 고려하면 됩니다.
무상태 프로토콜 (Stateless)
무상태란, 서버가 클라이언트의 상태 를 보존하지 않는 것을 말합니다. 상태란 문맥 (컨텍스트) 등을 의미합니다.
무상태인데 데이터를 어떻게 주고받을 수 있을까요? 클라이언트가 매번 필요한 데이터를 서버에게 모두 보내기 때문입니다.
즉 1번 예시처럼 대화를 하는 경우에는 점원이 Stateful 한 것이고, 2번처럼 대화하는 것은 점원이 Stateless 한 경우 입니다. 2번 예시에서는 대화를 할 때에는 이전에 했던 얘기일지라도 동일하게 이야기하고 있습니다.
무상태의 장점과 단점
그렇다면 왜 무상태를 지향하는 걸까요? 이유는 서버가 상태를 기억하지 않기때문에, 구조가 보다 단순해지며 확장 (수평확장, Scale out) 에 유리하기 때문입니다.
서버는 모든 상태를 기억하지 못하기때문에, 클라이언트가 어떤 서버로 요청을 보내도 상관이 없습니다. 따라서 특정 서버가 장애가 발생하거나 트래픽이 갑자기 몰려 서버를 증설해야 하는 경우에도 유연하게 대응할 수 있습니다.
그러나 한꺼번에 모든 데이터를 보내주어야 하기 때문에, 보내야하는 데이터의 양이 많습니다.
무상태의 한계
그러면 모든 것을 무상태로 하면 좋을 것 같은데요, 무상태에도 한계는 있습니다.
로그인이 필요 없는 단순 서비스 소개 화면 같은 경우에는 무상태여도 상관이 없습니다. 그러나 로그인과 같이, 상태를 기억을 해야 하는 경우가 있습니다. 이럴 때에는 일반적으로는 브라우저 쿠키와 서버 세션 등을 사용하여 상태를 유지합니다.
클라이언트가 매번 필요한 데이터를 서버에게 모두 보내기 때문입니다. (무상태가 가능한 이유)
그런데 그렇다면, 매번 client 가 모든 정보를 server 에게 보내주면 되지 않을까요? 굳이 상태 유지를 해야할 필요가 있을까요? 보안위협이 있을 수 있기 때문이라고 생각합니다. 때문에 서버또한 해당 사용자가 로그인을 했다는 정보를 알고 있어야 합니다.
그래서 클라이언트에서 서버로 특정 사용자의 정보를 보내고, 이를 서버도 메모리나 DB 등을 통해 기억을 해야 합니다.
아무튼 무상태는 보다 단순하고 유연한 대응이 가능하기 때문에 상태를 유지하는 것은 최소한으로 하는 것이 좋습니다.
비 연결성 (connectionless)
비연결성 이란
HTTP 는 기본적으로는 연결을 유지하지 않는 모델입니다. 연결을 유지하지 않기 때문에 어떤 요청도 어떤 서버로부터 응답을 받아도 문제되지 않습니다. 따라서 서버의 자원을 효율적으로 사용할 수 있습니다.
비연결성의 단점
그러나 비연결성은 말그대로 연결이 되어있지 않기 때문에, 매번 TCP/IP 연결을 새로 맺어야 합니다. 따라서 3 way handshake 시간이 매번 추가됩니다.
다행히도 HTTP 1.1 의 Keep alive 설정을 통해 지속 연결 (Persistent Connections) 을 할 수 있어, 매번 3 way handshake 를 해야 하는 문제점이 개선되었습니다.
- https://etloveguitar.tistory.com/137
HTTP 의 역사와 특징
참고자료
HTTP 의 역사
HTTP 2.0, 3.0 의 사용
TCP 는 기반 프로토콜로 HTTP 를 사용합니다. HTTP/1.1, HTTP/2 가 그렇습니다. HTTP/3 에서는 성능 개선으로 UDP 의 기반 프로토콜로 HTTP 를 사용합니다.
주로 HTTP/1.1 을 사용하지만, 2, 3의 사용도 점점 증가하고 있습니다.
HTTP 의 특징
클라이언트와 서버가 데이터를 주고받는 구조로 되어있습니다. 클라이언트가 요청을 하면 서버에서는 요청에 대한 응답을 보내줍니다. HTTP 메시지로 통신하며, HTTP 는 Stateless 를 지향하며 비연결성 이라는 특징을 갖습니다. 서로 계속 연결되어있지 않고 상태를 기억하지 않기 때문에, 구조가 단순하며 확장 (Scale out) 이 보다 용이합니다.
클라이언트 & 서버 구조
HTTP 의 구조는 클라이언트와 서버로 이루어져있습니다. 클라이언트가 HTTP 메시지를 서버로 보내고, 클라이언트는 응답을 받을 때 까지 기다립니다. 서버로부터 응답 (HTTP 메시지) 을 받으면 확인하여 처리를 합니다.
여기서 말하는 클라이언트는 사람이라기보다는, 해당 서비스를 사용하는 웹 페이지, 모바일 앱 등을 의미합니다.
과거에는 하나에 클라이언트, 서버가 모두 있었습니다. 그러나 클라이언트와 서버가 분리되어 각자의 역할에 보다 집중할 수 있게 되었습니다. 클라이언트에서는 단순히 사용자의 입장에서의 UI, UX, 브라우저 등에 대해서만 고려를 하면 됩니다. 서버 (백엔드) 에서는 트래픽에 대해서만 고려하면 됩니다.
무상태 프로토콜 (Stateless)
무상태란, 서버가 클라이언트의 상태 를 보존하지 않는 것을 말합니다. 상태란 문맥 (컨텍스트) 등을 의미합니다. 무상태인데 데이터를 어떻게 주고받을 수 있을까요? 클라이언트가 매번 필요한 데이터를 서버에게 모두 보내기 때문입니다.
즉 1번 예시처럼 대화를 하는 경우에는 점원이 Stateful 한 것이고, 2번처럼 대화하는 것은 점원이 Stateless 한 경우 입니다. 2번 예시에서는 대화를 할 때에는 이전에 했던 얘기일지라도 동일하게 이야기하고 있습니다.
무상태의 장점과 단점
그렇다면 왜 무상태를 지향하는 걸까요? 이유는 서버가 상태를 기억하지 않기때문에, 구조가 보다 단순해지며 확장 (수평확장, Scale out) 에 유리하기 때문입니다.
서버는 모든 상태를 기억하지 못하기때문에, 클라이언트가 어떤 서버로 요청을 보내도 상관이 없습니다. 따라서 특정 서버가 장애가 발생하거나 트래픽이 갑자기 몰려 서버를 증설해야 하는 경우에도 유연하게 대응할 수 있습니다.
그러나 한꺼번에 모든 데이터를 보내주어야 하기 때문에, 보내야하는 데이터의 양이 많습니다.
무상태의 한계
그러면 모든 것을 무상태로 하면 좋을 것 같은데요, 무상태에도 한계는 있습니다.
로그인이 필요 없는 단순 서비스 소개 화면 같은 경우에는 무상태여도 상관이 없습니다. 그러나 로그인과 같이, 상태를 기억을 해야 하는 경우가 있습니다. 이럴 때에는 일반적으로는 브라우저 쿠키와 서버 세션 등을 사용하여 상태를 유지합니다.
그런데 그렇다면, 매번 client 가 모든 정보를 server 에게 보내주면 되지 않을까요? 굳이 상태 유지를 해야할 필요가 있을까요? 보안위협이 있을 수 있기 때문이라고 생각합니다. 때문에 서버또한 해당 사용자가 로그인을 했다는 정보를 알고 있어야 합니다. 그래서 클라이언트에서 서버로 특정 사용자의 정보를 보내고, 이를 서버도 메모리나 DB 등을 통해 기억을 해야 합니다.
아무튼 무상태는 보다 단순하고 유연한 대응이 가능하기 때문에 상태를 유지하는 것은 최소한으로 하는 것이 좋습니다.
비 연결성 (connectionless)
비연결성 이란
HTTP 는 기본적으로는 연결을 유지하지 않는 모델입니다. 연결을 유지하지 않기 때문에 어떤 요청도 어떤 서버로부터 응답을 받아도 문제되지 않습니다. 따라서 서버의 자원을 효율적으로 사용할 수 있습니다.
비연결성의 단점
HTTP 2, HTTP 3 에서 더 많은 최적화가 이루어져있습니다.