TCP/IP

문정현·2024년 11월 28일

TCP 개요

전송 제어 프로토콜(Transmission Control Protocol, TCP)은 근거리 통신망, 인트라넷, 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟을 안정적이고, 순서대로, 에러 없이 교환할 수 있게 합니다. TCP는 전송 계층에 위치하며, 네트워크의 정보 전달을 통제하는 프로토콜이자 인터넷을 구성하는 핵심 프로토콜 중 하나입니다. 웹 브라우저들이 월드 와이드 웹(WWW)에서 서버에 연결할 때 사용됩니다(예: SMTP, 파일 전송).

TCP의 특징

  1. 흐름 제어 (Flow Control):
    • 송신자는 자신이 얼마나 보낼 수 있는지, 수신자는 어디까지 받았는지를 끊임없이 확인합니다.
    • TCP 헤더 내의 Window Size를 사용하여 한 번에 받고/보낼 수 있는 데이터의 양을 조정합니다.
    • Acknowledgment Number를 통해 송신자는 수신자가 받은 데이터 양을 확인합니다. 예를 들면, 300번째 데이터를 받으면 Acknowledgment Number에 1을 더한 301을 보내고, 이 데이터의 순서 번호를 Sequence Number라고 합니다.
  2. 혼잡 제어 (Congestion Control):
    • 연결 초기에는 데이터 송출량을 낮게 잡고 보내면서 수신자의 수신을 확인하며 데이터 송출량을 조금씩 늘리는 Slow Start 기법을 사용합니다.
    • 네트워크 혼잡을 피하기 위해 송신자는 점진적으로 데이터 송출량을 늘려가며 네트워크 상태를 확인합니다.

3-way Handshake

TCP를 사용하는 송신자와 수신자는 데이터를 전송하기 전, 먼저 서로 통신이 가능한지 확인하고, 한 번에 얼마나 받을 수 있는지 등의 정보를 확인합니다. 이 과정을 3-way Handshake라고 하며, 신뢰성 있는 통신을 위해 필요합니다.

  1. SYN: 송신자가 연결 요청을 보냅니다. (예: 여보세요?)
  2. SYN/ACK: 수신자가 요청을 받고 응답을 보냅니다. (예: 네, 여보세요?)
  3. ACK: 송신자가 수신자의 응답을 받고 확인합니다. (예: 상대방의 여보세요를 듣고 대화 시작)

TCP와 HTTP의 차이 (전문 길이 명시의 관점에서만)

TCP는 HTTP와 다르게 패킷의 길이 정보를 명시하여 데이터 통신을 주고 받는다

여기서 왜? 라는 질문을 받았지만 선뜻 대답할 수 없었다

가장 큰 이유는 TCP가 스트림 기반 프로토콜로 바이트 스트림을 지속적으로 전달하기 때문이다

바이트 스트림이란?
한번에 한 바이트씩 연속적으로 전송되는 데이터의 흐름과 같이 끊임없이 연속되는 바이트 열

따라서 TCP는 지속적인 연결을 유지하면서 데이터를 전송하기 때문에 수신 측에서는 데이터의 경계를 알기 위해 길이 정보를 필요로 한다.

같은 맥락에서 예를 들자면 TCP가 너무 큰 데이터의 경우 패킷을 조각화 하여 전송하는데

이때 각 패킷의 길이 정보를 통해 원래의 데이터로 정확하게 재 조립이 가능 할 것이다.

반면, HTTP는 애플리케이션 계층의 프로토콜로, 각 요청과 응답이 독립적이고, 명확한 메시지 단위로 처리되기 때문에 (특히 Content-Length로 관리됨) TCP와 다른 것.

이중화 환경에서 부하 분산

구조 설명

  • 포트 3334: 노드 1과 노드 2로 나누어 동작.
  • L4 로드 밸런서: 총 4개의 연결을 2개씩 나누어 노드 1과 노드 2로 분산.

문제 상황

  • 노드 2 다운: 모든 연결이 노드 1로 몰림.
  • 노드 2 복구: 부하가 다시 분산되지 않음.

상세 설명

  1. 초기 설정:
    • 포트 3334가 노드 1과 노드 2로 나누어져서 동작.
    • L4 로드 밸런서가 4개의 연결을 받아 2개씩 노드 1과 노드 2로 분산.
  2. 문제 발생:
    • 노드 2가 다운됨.
    • L4 로드 밸런서가 모든 연결을 노드 1로 전달.
    • 노드 1에 과부하 발생.
  3. 복구 시 문제:
    • 노드 2가 다시 살아남.
    • 이미 노드 1로 몰린 연결이 유지됨.
    • 새로운 연결만 노드 2로 분산되지만, 기존 연결은 그대로 노드 1에 남아 있음.
    • 부하가 고르게 분산되지 않음.

해결 방안

  • 세션 지속성 관리: 세션 지속성을 적절히 관리하여, 노드가 복구되었을 때 기존 세션을 분산할 수 있는 정책 필요.
  • 동적 재분배: 실시간으로 부하를 감지하고 노드 간 연결을 동적으로 재분배하는 알고리즘 도입.
  • 헬스 체크 강화: 노드 상태를 지속적으로 모니터링하고 빠르게 대처할 수 있는 헬스 체크 메커니즘 강화.

결론

TCP 이중화 구조에서 노드 다운 및 복구 시 부하 분산 문제가 발생할 수 있습니다. 이를 해결하기 위해서는 세션 지속성 관리, 동적 재분배, 헬스 체크 강화 등의 방안이 필요함

REFERENCE

https://aws-hyoh.tistory.com/57

profile
기록 == 성장

0개의 댓글