[Network] Stateless, Connectionless

해당 글은 VSFe 깃허브 레포를 참고하여 작성한 글입니다. (아래 출처에 표기)

 

✅ Stateless와 Connectionless에 대해 설명해 주세요.

▶ Stateless (무상태)

🔽 개념

• 클라이언트와 서버의 동작, 상태 정보를 저장하지 않는 형태이다.
• 클라이언트와 서버 간 모든 요청이 서로 독립적이고, 이전 요청의 정보를 저장하지 않는다.

Stateful: Stateless의 반대말로, 서버가 클라이언트의 이전 상태를 보존한다는 의미이다.

🔽 한계

• 클라이언트 측에서 상태를 유지해야 하거나, 상태 정보를 매 요청 시 서버를 전달해야 할 상황에서는 Stateful로 설계를 해야 하는데, Stateless가 기본값인 HTTP에서는 비용이 많이 들 수 있다. (예: 로그인, 팝업을 하루동안 보지 않기 등)

🔽 해결 방안

• 브라우저 쿠키(Cookie)나 서버 세션(Session) 등을 사용하여 상태를 유지한다.

쿠키와 세션에 대한 설명은 여기를 참고하면 좋을 것 같다.

 

▶ Connectionless (비연결성)

🔽 개념

• 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 유지하지 않는 것이다.

🔽 한계

• 연결이 끊어지면 새로 연결할 때 TCP/IP 연결을 새로 맺어야 하므로 3-way Handshake에 따른 시간이 추가된다.
• 사이트 요청 시 HTML, CSS, Javascript, 이미지 등 많은 리소스를 다운로드해야 하는데, 리소스마다 연결을 생성하기 때문에 오버헤드(overhead)가 너무 크다.
• 전송 중에 데이터가 손실되거나 손상될 수 있으며, 이를 확인하거나 복구하는 메커니즘이 부족하다.

오버헤드(overhead): 시스템이나 프로세스에서 실제 작업을 수행하는 데 필요한 추가적인 리소스(시간, 메모리, 대역폭 등)를 의미한다.

🔽 해결 방안 

• 지속적 연결(Persistent Connection): 매번 TCP 연결을 설정하는 것이 아니라, TCP를 연결을 재사용하도록 하는 것이다. keep-alive 헤더를 통해 일정 시간(time out 전까지) 동안 연결 상태를 유지한다.

(아래에서 구체적으로 설명)

 

 

✅ 왜 HTTP는 Stateless 구조를 채택하고 있을까요?

• 서버가 클라이언트의 상태를 추적하거나 저장할 필요가 없기 때문에, 구현이 쉽고 서버 확장이 용이하다.
• 서버 간의 상태 정보를 저장할 필요가 없기 때문에, 서버 장애로 인한 문제가 비교적 적다.
• Stateless 구조에서는 동일한 요청에 대한 동일한 응답을 생성하기 때문에, 응답을 캐시하는 것이 용이하다. 이는 네트워크 부하를 줄이고 응답 시간을 개선하는데 도움이 된다.

 

 

✅ Connectionless의 논리대로면 성능이 되게 좋지 않을 것으로 보이는데, 해결 방법이 있을까요?

🔽 문제

• Connectionless 모델은 각 요청마다 새로운 연결을 생성하지 않기 때문에 초기 연결 설정에 드는 시간과 리소스를 절약할 수 있다. 그러나, 연결을 유지하지 않기 때문에 연결이 의도와 다르게 끊어지게 된다면 이후 추가적인 연결 설정들이 성능 저하로 이어질 수 있다.
• 또한 전송 중에 데이터가 손실되거나 손상될 수 있으며, 이를 확인하거나 복구하는 메커니즘이 없어 신뢰성 문제가 발생한다.

🔽 해결 방안

• 지속적 연결(Persistent Connection): 매번 TCP 연결을 설정하는 것이 아니라, TCP를 연결을 재사용하도록 하는 것이다. keep-alive 헤더를 통해 일정 시간(time out 전까지) 동안 연결 상태를 유지한다. (HTTP/1.1 도입)
• 서버 푸시(Server Push): 서버가 클라이언트의 요청 없이도 응답을 보내는 것이다. (HTTP/2.0 도입)
• 멀티플렉싱(Multiplexing): 하나의 Connection에서 여러 요청과 응답을 동시에 처리할 수 있다. 따라서 요청마다 새로운 TCP 연결을 만들어야 했던 문제를 해결한다. (HTTP/2.0 도입)
• 헤더 압축(Header Compression): 압축 기술을 사용하여 헤더 정보를 효율적으로 압축한다. 이를 통해 헤더 크기를 줄여 오버헤드를 줄인다. (HTTP/2.0 도입)
• QUIC(Quick UDP Internet Connections) 사용: QUIC은 HTTP/3.0의 기반으로, 패킷 손실 감지에 걸리는 시간 단축할 수 있고, 클라이언트 IP가 바뀌어도 연걸이 유지되고, 연결 지연(latency)을 감소시킬 수 있다.

해당 용어들은 HTTP의 발전 과정 중 나온 개념에 대한 이해가 필요하다. 여기를 참고하면 좋을 것 같다.

 

 

✅ TCP의 keep-alive와 HTTP의 keep-alive의 차이는 무엇인가요?

• TCP의 keep-alive: TCP 수준에서의 연결이 여전히 활성 상태인지 확인하기 위해 사용되는 기능이다. 일정 시간 동안 데이터 교환이 없을 경우, keep-alive 패킷을 송수신하여 연결이 유효한지 검사한다.
• HTTP의 keep-alive: HTTP 프로토콜 수준에서 클라이언트와 서버 간에 여러 HTTP 요청/응답을 동일한 TCP 연결을 재사용하여, TCP 연결의 설정과 종료에 따른 지연과 오버헤드를 줄인다.

🔽 차이점

	TCP keep-alive	HTTP keep-alive
목적	연결이 살아있는지 확인	TCP 연결을 여러 HTTP 요청/응답에서 재사용
작동 방식	주기적으로 작은 패킷 전송	HTTP 헤더로 연결 유지 요청
설정 위치	운영체제 네트워크 설정	애플리케이션 레벨(웹 서버/브라우저)
사용 상황	장시간 유휴 상태 연결 확인	웹 페이지 로딩 시 여러 리소스 요청 최적화
도입 계층	전송 계층(Transport Layer), 4계층	응용 계층(Application Layer), 7계층

OSI 7계층에 대한 설명은 여기를 참고하면 좋을 것 같다.

🔽 사용 예시

• TCP의 keep-alive: 서버와 클라이언트가 데이터 전송 없이 5분 동안 대기하고 있을 때, TCP keep-alive 패킷이 주기적으로 전송되어 연결이 여전히 살아있는지 확인한다. 응답이 없으면 연결이 종료된다.
• HTTP의 keep-alive: 웹 브라우저가 HTML 페이지를 요청하고, 이 페이지에 포함된 10개의 이미지를 가져와야 할 때, HTTP keep-alive를 사용하면 브라우저는 하나의 TCP 연결을 통해 HTML 페이지와 10개의 이미지를 모두 요청할 수 있다. 각 이미지마다 새로운 연결을 만들 필요가 없다.

결론적으로 이름만 비슷하다.

 

 

📍 문제 출처

Tech-Interview / 03-NETWORK.md

 

📍 참고 자료

• HTTP, Stateless, Connectionless, HTTP 메시지 개념
• Stateless & Connectionless
• [HTTP] HTTP는 Stateless, Connectionless하다
• Stateless, Connectionless