[Network] HTTP 통신은 Stateless가 맞을까?

의문의 시작

Rest API는 HTTP를 기반으로 하는 Client/Server Side 통신을 도와주는 아키텍처이다. 그렇기에 Rest API는 HTTP 프로토콜의 특징을 그대로 가지고 오며, 명확한 표준은 없지만 HTTP 통신에 대해 비 강제적인 제약을 가해 일반적으로 통용 가능한 규칙을 적용시키기 위해 사용된다고 개인적으로 생각한다.

그리고 이 Rest API를 더 자세히 알기 위해서 나는 HTTP를 조금 더 공부해 보기로 했다.

 

---

HTTP란?

HTTP는 OSI 7 계층(애플리케이션 계층)에서 적용되는 프로토콜이며
...
생략
...

• 특징
  • Stateless
  • TCP/IP 기반
  • ...

...
생략
...

HTTP는 Stateless한 특징을 가지고 있고 이 특징으로 인해 client/server 구조에서 server가 고정될 필요가 없어 scale out된 어떠한 서버에도 request를 날릴 수 있다.(확장성이 좋다.)
TCP/IP를 기반으로 동작한다.

 

그러면 TCP/IP는 어떤 특징이 있을까?

 

---

TCP/IP란?

...
생략
...

• 특징
  • Stateful
  • ...

...
생략
...

3-way-handshake를 통해 연결되며 서버는 클라이언트의 정보를 보관한다.

 

Stateless한 HTTP가 Stateful 한 기반의 TCP/IP로 동작한다라..

---

HTTP의 발전

은 이전에 기록해둔 포스팅을 참고!(2021.09.02 - [Study/Server] - [Network] HTTP란? 그리고 HTTP 1.1, HTTP 2)

주관적으로 생각해 본 모순

HTTP1.1 keep-alive

HTTP1.0은 Stateless한 통신이 맞다고 생각한다. 비록 TCP/IP의 특징을 베이스로 하기 때문에 3-way-handshake 과정을 거치지만 하나의 request에 대해 하나의 response를 주고 통신은 종료된다. 서버 측에서 클라이언트의 정보를 알고 있어야 할 필요가 전혀 없다. 하지만 정말 내 의문의 시작이었던 HTTP1.1부터 연속된 request를 받아들여 지속적인 3-way-handshake와 4-way-handshake를 하지 않아 RTT 발생을 줄이는데 도움을 주지만 2.0에서 가장 큰 개선사항이라 볼 수 있는 HOL의 문제를 일으키는 keep-alive!!!

내 개인 프로젝트에 rest api를 호출한 모습. Connection: keep-alive

stateless와 keep-alive는 너무 상충되는 것 아닌가? 라는 생각을 할 수 있다. 

혹여 timeout과 max값으로 이 keep-alive를 적절히 조절하면 stateless와 stateful의 장점을 다 살릴 수 있지만 기본적으로 stateless관점에서 API를 설계 해야 하고 stateful 한 연결은 최대한 짧을수록 좋다.. 인가?

 

 HTTP2.0 gRPC

그렇다면 이건..

https://docs.microsoft.com/ko-kr/aspnet/core/grpc/comparison?view=aspnetcore-6.0

마이크로 소프트 docs에서 gRPC(HTTP 2.0를 사용하는 통신 프로토콜)의 장점 중 하나인 스트리밍을 가지고 와 봤다. 장점을 스트리밍이라고 말한다. HTTP는 stateless 한 통신인데 스트리밍이 장점이다. 심지어 양방향 스트리밍이 지원된다. 이 정도면 stateful 한 것이 더 발전된 것이다.라는 말을 하고 싶은 것일까나..

 

 

 

---

결론

HTTP가 stateless 하다는 것은 옛말이고 지금 상태에선 맞지 않는 말이다! 라는 말을 하고 싶은 건 아니다. 글을 작성하다 보니 keep-alive가 어떻게 동작하는지 이해할 수 있었고 이는 stateless 한 HTTP통신의 단점을 커버하기 위해 만들어진 것이지 가장 기초적인 개념인 stateless 부정한 것은 아니며 stateless를 이해하고 API를 설계하여야 더 좋은 API가 작성될 것임을 깨달았다. 하지만 또 한편으로는 무조건 적으로 HTTP의 특징이 stateless라고 말하는 것은 위험한 생각이 아닐까? 라는 생각도 하게 됐다. Stack over flow의 글이나 다른 포스팅된 글에서도 양쪽의 의견이 있는 것 보면 이에 대한 생각은 다양한 듯하다. 

 

HTTP는 기본적으로 Stateless를 생각하고 설계됐고 설계해야 할 프로토콜이지만 상황에 따라 더 효율적인 처리를 하기 위해 Stateful 한 스킬을 가지고 있는 프로토콜.

내가 내린 결론이다. 둘 다 맞는 말이라는 오픈 마인드를 가지기로 했다.

 

세상은 빠르게 변하니까! 특히 개발진영은 더욱!

 

 

---

참고

https://stackoverflow.com/questions/19899236/is-tcp-protocol-stateless

Is TCP protocol stateless?

https://goodgid.github.io/HTTP-Keep-Alive/

 

HTTP Keep Alive 알아보기

https://docs.microsoft.com/ko-kr/aspnet/core/grpc/comparison?view=aspnetcore-6.0