로드밸런서 L4, L7

[문제 발생]

KT 클라우드에서 로드밸런서를 하나 썼다 (L4 Switch)그런데 우선 HTTP/HTTPS모드가 있고, TCP모드가 존재한다. 우선 L4 Switch에서 HTTP/HTTPS모드가 있다는게 이해가 가지 않았었다.
우선 웹 소켓을 썼고 두 대의 컴퓨터가 존재한다. 웹소켓 처음에는 HTTP를 사용한다. TCP프로토콜의 3 way handshake를 통해 연결을 우선 맺게 되는데, 이때 ack를 1번 PC에 ack sync를 2 번째 PC에 보내는 등 한 pc와 3way handshake를 맺는게 아니라 2 pc에 나눠서 이상한 형태로 가게 되었다.
하지만, TCP모드는 3way handshake가 잘 맺어짐.

[chatGpt를 통한 대화및 궁금증 해결]

<aside> 📎 질문 L4 스위치에서 http 모드로 소켓통신을 할때 3way handshake가 분산되는데, tcp 모드로 통신을 걸면 한 곳으로 잘 가거든? 왜 이러는거야?

대답

L4 스위치가 HTTP 모드로 동작하는 경우, L4 스위치는 HTTP 패킷을 해석하고 일부 정보를 분석하여 로드 밸런싱 및 다른 네트워크 기능을 수행합니다. 이 때 L4 스위치는 HTTP의 특정 헤더 필드를 기반으로 서버 선택, 세션 유지, 유효성 검사 등을 수행할 수 있습니다.

그러나 HTTP 프로토콜은 일반적으로 TCP 프로토콜을 기반으로 하며, TCP는 3-way handshake를 사용하여 연결을 설정하고 종료합니다. 이 때 HTTP 모드로 동작하는 L4 스위치는 TCP 3-way handshake를 분산하여 여러 서버로 전송합니다. 이로 인해 세션이 성공적으로 설정되지 않을 수 있으며, 이는 속도 저하, 오류 및 다른 문제를 초래할 수 있습니다.

반면 TCP 모드에서는 L4 스위치가 TCP 3-way handshake를 자체적으로 수행하며, 연결이 성공적으로 설정될 때까지 대기합니다. 따라서 TCP 모드에서는 연결 설정이 정확하게 수행되고, 세션이 잘 유지됩니다.

따라서 HTTP 모드에서는 TCP 모드보다 3-way handshake가 분산되는 경우가 많으며, 이는 세션 설정 문제를 초래할 수 있습니다. 따라서 성능과 안정성을 위해 TCP 모드를 사용하는 것이 좋습니다.

</aside>

<aside> 📎 질문 공식 사이트 또는 공식문서를 제시해줘

대답

L4 스위치의 HTTP 모드와 TCP 모드의 동작 방식에 대한 공식 문서는 제조사 또는 제공 업체마다 다를 수 있습니다.

일부 제조사는 자체적으로 문서화하거나 사용자 매뉴얼, 설명서 또는 데이터 시트에 상세한 정보를 기재하고 있을 수 있으며, 다른 제조사의 경우에는 해당 정보가 별도의 문서로 공개되어 있지 않을 수 있습니다.

따라서 사용하고 있는 L4 스위치의 제조사 및 모델명을 확인하고, 해당 제조사의 공식 웹사이트를 방문하여 관련 문서를 찾아보시는 것이 가장 빠르고 정확한 방법일 것입니다.

그러나, TCP와 HTTP 프로토콜 및 3-way handshake에 대한 공식 문서는 IETF(Internet Engineering Task Force)에서 제공되며, 다음과 같은 문서들을 참고하시면 됩니다.

Transmission Control Protocol(TCP) : **https://tools.ietf.org/html/rfc793**
Hypertext Transfer Protocol(HTTP) : **https://tools.ietf.org/html/rfc7230**
TCP Three-Way Handshake : **https://tools.ietf.org/html/rfc793#page-15**

위 문서들은 영어로 작성되어 있으며, 상세한 내용과 원리에 대한 이해가 필요합니다.

</aside>

<aside> 📎

질문 로드배런서 L4 스위치는 어차피 4계층의 포트까지밖에 인식하지 못하잖아 근데 HTTP모드란게 왜 있는거야? HTTP모드랑 TCP모드가 무엇인지 그리고 차이점이 무엇인지 알려줘

대답

로드밸런서는 L4와 L7의 레이어에서 동작할 수 있습니다. L4 스위치는 네트워크 레이어(4계층)에서 동작하여 IP 주소와 포트번호를 기반으로 트래픽을 분산합니다. 반면에 L7 스위치는 응용 프로그램 레이어(7계층)에서 동작하여 HTTP 요청 헤더와 URL과 같은 응용 프로그램 레벨의 정보를 기반으로 트래픽을 분산합니다.

HTTP 모드와 TCP 모드는 L4 스위치에서 동작할 때, 트래픽을 어떻게 처리할지를 결정하는 방식입니다. L4 스위치의 TCP 모드는 트래픽을 라우팅하기 전에 TCP 세션을 설정하고 유지하는 것이 중요합니다. 반면에 L4 스위치의 HTTP 모드는 HTTP 요청 헤더를 읽어서 트래픽을 라우팅하기 전에 특정 서버로 라우팅할지 결정할 수 있습니다.

HTTP 모드에서는 L4 스위치가 HTTP 요청 헤더 필드를 읽고, 요청 URI와 Host 헤더를 검사하여 특정 서버로 라우팅합니다. 이는 L7 로드밸런싱과 유사한 방식으로 동작하지만, L7 로드밸런싱보다 덜 복잡하고 처리 속도가 빠르기 때문에 대규모 웹 사이트에서 많이 사용됩니다.

반면 TCP 모드에서는 L4 스위치가 IP 주소와 포트번호를 기반으로 라우팅합니다. TCP 모드는 HTTP 모드보다 간단하며 처리 속도가 더 빠릅니다. 그러나 HTTP 모드와 달리, L4 스위치는 TCP 세션을 설정하고 유지하는 데 초점을 맞춥니다.

따라서 HTTP 모드는 L4 스위치에서 L7 로드밸런싱을 제공하며, TCP 모드는 L4 로드밸런싱을 제공합니다. 이 두 모드는 트래픽을 어떻게 처리할지에 따라 달라지며, 적절한 모드를 선택하면 성능 및 안정성을 향상시킬 수 있습니다.

</aside>

<aside> 📎 질문 그러면 l4 스위치는 응용계층까지도 decapsulation할수도 있는거네

대답

L4 스위치는 일반적으로 응용계층까지 decapsulation하는 기능을 제공하지는 않습니다. L4 스위치는 기본적으로 TCP/UDP 프로토콜을 사용하여 IP 패킷을 전달하며, 패킷의 소스 및 대상 IP 주소 및 포트 번호를 기반으로 트래픽을 분산합니다. 따라서 L4 스위치는 IP 패킷의 정보만을 바탕으로 라우팅을 수행하며, 패킷의 내용을 직접 확인하지 않습니다.

반면에 L7 로드밸런서는 HTTP 요청 헤더 및 URL 정보를 분석하여 라우팅을 수행하므로, 응용계층에서의 decapsulation과 분석이 가능합니다. 하지만 이러한 기능을 제공하기 위해서는 L7 로드밸런서가 보다 복잡한 구조를 가지고 있으며, 더 많은 리소스가 필요합니다. 따라서 L4 스위치와 L7 로드밸런서는 각각의 장단점이 있으며, 사용 목적에 따라 선택되어야 합니다.

</aside>

<aside> 📎 질문 잠깐만 그러면 정리하자 보통 클라우드환경에서 제공해주는 로드밸런서는 L4, L7모드를 고를수 있는거고 그것이 tcp모드와 http모드인거지?

대답

네, 일반적으로 클라우드 환경에서 제공하는 로드밸런서는 L4 및 L7 모드를 지원하며, 사용자가 선택하여 사용할 수 있습니다. L4 모드는 주로 TCP 및 UDP와 같은 전송 계층 프로토콜을 사용하는 서비스에 사용되며, L7 모드는 HTTP 및 HTTPS와 같은 응용 계층 프로토콜을 사용하는 서비스에 사용됩니다. 이러한 모드 중에서도 HTTP를 지원하는 L7 로드밸런서는 HTTP 모드를 지원하며, 이를 통해 HTTP 요청 헤더 및 URL 정보를 분석하여 트래픽을 분산할 수 있습니다. 그러므로 로드밸런서의 모드를 선택하는 것은 서비스의 특성과 요구사항에 따라 결정됩니다.

[](data:image/svg+xml,%3csvg%20xmlns=%27http://www.w3.org/2000/svg%27%20version=%271.1%27%20width=%2730%27%20height=%2730%27/%3e)

</aside>

<aside> 📎 질문 하나 궁금한게 HTTP헤더까지 까면서 특정서버에 보내는 케이스는 어떤 케이스가 있는거야? 보통은 내가 보내고싶은 서버의 IP의 특정 프로세스의 Port까지만으로 끝나잖아.

대답

HTTP 헤더를 분석하면서 특정 서버에 보내는 경우에는 일반적으로 HTTP 기반의 가상 호스팅(Virtual Hosting) 환경에서 발생합니다. 가상 호스팅이란 하나의 물리적 서버에서 여러 개의 도메인을 호스팅하는 방법으로, 하나의 IP 주소를 공유하여 여러 개의 도메인을 처리할 수 있습니다.

가상 호스팅 환경에서는 클라이언트의 HTTP 요청 헤더에 있는 호스트 헤더 정보를 분석하여 해당 도메인에 매핑된 가상 호스팅 서버로 요청을 전달합니다. 이때, 가상 호스팅 서버는 각 도메인마다 별도의 웹 서버 프로세스를 운영하고, HTTP 헤더 정보를 분석하여 해당 도메인에 맞는 웹 콘텐츠를 응답합니다.

따라서, HTTP 헤더까지 분석하여 특정 서버에 요청하는 경우는 가상 호스팅 환경에서 발생하며, 이러한 경우에는 HTTP 헤더 정보를 참조하여 요청을 처리하는 서버를 선택하게 됩니다. 일반적으로 L7 로드밸런서에서 이와 같은 가상 호스팅 기능을 지원하며, 클라이언트의 요청을 받은 후 호스트 헤더 정보를 분석하여 적절한 서버에 전달하는 역할을 수행합니다.

</aside>

<aside> 📎 질문 하나 궁금한게 있어 두 PC가 TCP 프로토콜에 의해 3WAY Handshake를 통해 연결을 했다고 하는데, 연결을 했다라는 표현 정확히 어떻게 된걸 얘기하는거야?

대답

TCP의 3-way handshake는 클라이언트와 서버 사이에 안정적인 연결을 설정하기 위한 절차입니다.

이 절차는 다음과 같이 진행됩니다:

클라이언트가 서버에 SYN(Synchronize) 패킷을 보냅니다.
서버는 SYN 패킷을 받았다는 확인 신호인 ACK(Acknowledgment)와 SYN 패킷을 보냅니다.
클라이언트는 서버로부터 받은 SYN+ACK 패킷에 ACK를 보내면서 연결이 성공적으로 수립되었다는 신호를 보냅니다.

이러한 과정을 통해 클라이언트와 서버는 안정적인 연결을 설정하고 데이터 전송을 시작할 수 있습니다. 따라서 "연결을 했다"는 것은 클라이언트와 서버가 3-way handshake를 통해 안정적인 연결을 설정했다는 것을 의미합니다.

나의 대답 서로의 프로세스를 주고받을수 있는지를 OS가 판단한다. (모종의 사태 방화벽 등으로 SYN 패킷이 요청 프로세스에 도착 안할수 있기도 함). 3 way handshake는 어차피 TCP까지밖에 패킷에 없고, 받은 PC의 OS는 그것을 판단해서 TCP Flag와 seq number, ACK number, 를 채워서 응답을 보낸다. 그리고 서로 SYN, SYN-ACK, ACK 이렇게 3번 왔다 갔다하면 연결이 되었다고 서로 생각하고, 안심하고 데이터를 전송하게 된다. → 말 그대로 논리적으로 연결되었다고 생각함. 연결되었다고 논리적으로라도 판단을 해야하는 이유는 아까 말한 것처럼 방화벽, 패킷 손실 등의 모종의 이유들이 중간에 있을수 있다는 점이다. 즉 통신하기 힘든 상황인 경우 어차피 응용계층에서 데이터를 보내봤자 못보니까 미리 확인하는 작업이라 생각하면 된다.

</aside>