[네트워크] TCP

CJY·2023년 8월 10일
0

네트워크

목록 보기
7/11

TCP

TCP란?

TCP (Transmission Control Protocol)는 인터넷 프로토콜 스위트의 중요한 프로토콜 중 하나로, 신뢰성 있고 연결 지향적인 데이터 전송을 제공하는 프로토콜입니다. TCP는 전송 계층에서 작동하며, 데이터를 세그먼트로 나누어 전송하고, 수신측에서 세그먼트를 재조립하여 정확하고 완전한 데이터 전달을 보장합니다.

특징

  • 연결 지향성 (Connection-oriented)
    TCP는 통신 시작 시 클라이언트와 서버 간에 연결을 설정한 다음 데이터를 주고받습니다. 이 연결 설정과 해제 과정은 신뢰성 있는 데이터 전송을 보장하는 데 중요한 역할을 합니다.

  • 신뢰성
    TCP는 데이터의 손실, 중복, 순서 변경 등을 감지하고 처리하여 정확한 데이터 전달을 보장합니다. 이를 위해 확인 응답과 재전송 메커니즘을 사용합니다.

  • 흐름 제어 (Flow Control)
    수신측이 처리할 수 있는 속도로 데이터가 전송되도록 하는 메커니즘입니다. 수신측에서 알림을 보내면 송신측은 그에 맞게 데이터를 전송하므로 수신자가 과도한 데이터로 인해 오버로드되지 않습니다.

  • 혼잡 제어 (Congestion Control)
    네트워크 혼잡을 방지하고 관리하기 위한 메커니즘으로, 네트워크 내의 혼잡 상황을 감지하고 전송 속도를 조절하여 전체적인 네트워크 성능을 최적화합니다.

  • 데이터 보증
    TCP는 데이터의 순서를 보장하며, 수신측에서 데이터를 조립하여 완전한 메시지를 제공합니다. 이를 통해 데이터의 무결성을 유지합니다.

TCP는 특히 웹 브라우징, 이메일, 파일 전송 및 원격 접속과 같은 응용 프로그램에서 널리 사용되는 프로토콜입니다. 이러한 응용 프로그램에서 신뢰성과 정확성이 중요한 역할을 하는데, TCP가 이러한 요구 사항을 충족시키는 데 큰 역할을 합니다.

3-way handshake

TCP의 연결 설정 과정인 "3-way handshake"는 클라이언트와 서버 간에 신뢰성 있는 연결을 설정하는 과정을 나타냅니다.

이 과정은 다음 세 단계로 이루어집니다.

  1. 클라이언트가 서버에 연결 요청 (SYN)
    클라이언트가 서버에 연결을 요청하는 SYN 패킷을 전송합니다. 이 패킷에는 클라이언트가 선택한 임의의 시퀀스 번호가 포함되어 있습니다. 이 시퀀스 번호는 클라이언트가 보내는 데이터의 시작점을 나타냅니다.

  2. 서버가 클라이언트에 응답 (SYN-ACK)
    서버는 클라이언트의 요청을 받고, 연결 수립을 위해 SYN-ACK 패킷을 클라이언트에게 전송합니다. 이 패킷에는 서버가 선택한 시퀀스 번호와, 클라이언트의 SYN 패킷에 포함된 시퀀스 번호에 1을 더한 값이 포함됩니다. 이는 서버가 클라이언트의 요청을 수신했으며, 클라이언트에게 연결 수립에 동의한다는 것을 의미합니다.

  3. 클라이언트가 서버에 응답 (ACK)
    클라이언트는 서버의 SYN-ACK 패킷을 받으면, 연결 수립에 동의하는 의미로 ACK 패킷을 서버에게 전송합니다. 이때 ACK 패킷에는 서버가 전송한 시퀀스 번호에 1을 더한 값이 포함됩니다.

이렇게 3-way handshake가 완료되면, 클라이언트와 서버 간의 연결이 성공적으로 설정됩니다. 이제 데이터 전송을 시작할 수 있습니다. 이 연결 설정 과정은 신뢰성 있는 통신을 위한 기반이며, 각 단계에서의 시퀀스 번호 교환은 데이터 전송 시 순서를 보장하고, 재전송 등의 신뢰성을 제공합니다.

4-way handshake

TCP의 연결 종료 과정을 나타내는 "4-way handshake"는 클라이언트와 서버 간의 연결을 정상적으로 종료하는 과정을 의미합니다.

이 과정은 다음 네 단계로 이루어집니다.

  1. 클라이언트가 서버에 연결 종료 요청 (FIN)
    클라이언트가 먼저 연결을 종료하고자 할 때, 클라이언트는 FIN 패킷을 전송하여 연결 종료를 요청합니다. 이때 더 이상 전송할 데이터가 없다는 의미로 FIN 플래그를 설정합니다.

  2. 서버가 클라이언트에게 응답 (ACK)
    서버는 클라이언트의 연결 종료 요청(FIN)을 받으면, ACK 패킷을 전송하여 이를 확인합니다. 이때 서버는 아직 전송할 데이터가 남아있다면 이 데이터를 보낼 수 있습니다.

  3. 서버가 연결 종료 요청 (FIN)
    서버가 먼저 연결을 종료하고자 할 때, 서버는 FIN 패킷을 클라이언트에게 전송하여 연결 종료를 요청합니다. 이때 역시 더 이상 전송할 데이터가 없다는 의미로 FIN 플래그를 설정합니다.

  4. 클라이언트가 서버에게 응답 (ACK)
    클라이언트는 서버의 연결 종료 요청(FIN)을 받으면, ACK 패킷을 전송하여 이를 확인합니다. 이때 클라이언트는 서버의 FIN 패킷을 받고 나서도 잠시 동안 연결을 열어두며, 아직 서버로부터 받지 못한 데이터가 있는지 확인합니다. 모든 데이터를 받았다면 클라이언트는 자체적으로 타이머를 설정하여 일정 시간이 지난 후에 연결을 완전히 종료합니다.

이렇게 4-way handshake가 완료되면, 클라이언트와 서버 간의 연결이 정상적으로 종료됩니다. 연결 종료 과정에서 클라이언트와 서버 간에 모든 데이터가 정확하게 주고받은 후에 연결이 완전히 종료됨을 보장합니다.

혼잡 제어

혼잡 제어(Congestion Control)는 네트워크 내에서 혼잡을 관리하고 제어하는 메커니즘입니다. 네트워크 혼잡이 발생하면 데이터 전달 속도가 느려지거나 데이터 손실이 발생할 수 있으므로, 혼잡 제어는 네트워크 성능을 유지하고 최적화하기 위해 중요한 역할을 합니다.

목표

  • 네트워크 혼잡 방지
    네트워크의 대역폭과 처리량을 넘어서는 데이터 트래픽이 발생하지 않도록 혼잡을 미리 예방합니다.

  • 혼잡 상황 탐지
    네트워크 내에서 혼잡이 발생하는지 감지합니다. 이를 위해 패킷 손실률, 대기 시간, 대역폭 사용률 등을 모니터링합니다.

  • 효율적인 대처
    혼잡 상황이 발생하면 네트워크 성능을 유지하기 위해 전송 속도를 조절하거나 데이터 흐름을 관리합니다.

원리

  • 혼잡 윈도우 (Congestion Window)
    TCP 송신자는 혼잡 상황에 따라 데이터를 얼마나 많이 보낼지를 결정하는 "혼잡 윈도우"를 유지합니다. 이 윈도우 크기는 네트워크의 혼잡 정도에 따라 동적으로 조절됩니다.

  • 혼잡 신호 (Congestion Signal)
    패킷 손실, 대기 시간 증가 등의 신호를 기반으로 혼잡 상황을 감지합니다.

  • AIMD (Additive Increase, Multiplicative Decrease)
    혼잡 윈도우 크기를 조절하는 기법으로, 데이터 전송이 성공적으로 이루어질 경우 윈도우 크기를 조금씩 증가시키고, 혼잡 상황이 감지될 경우 윈도우 크기를 반으로 줄입니다.

  • Slow Start
    TCP 연결 초기에는 혼잡 윈도우를 작게 설정하여 천천히 데이터 전송 속도를 증가시킵니다.

AIMD

  • Additive Increase
    데이터 전송이 성공적으로 이루어지는 동안에는 혼잡 윈도우 크기를 조금씩 증가시킵니다. 이 증가량은 일반적으로 1 세그먼트 크기(최초 MSS)입니다. 데이터 전송이 성공하면서 네트워크가 혼잡하지 않다는 신호로 판단합니다.

  • Multiplicative Decrease
    혼잡 상황을 감지하면 데이터 전송 속도를 기존의 혼잡 윈도우 크기의 절반으로 줄입니다. 이로써 네트워크 혼잡 상황에 대응하고 데이터 전송 속도를 조절합니다.

AIMD는 데이터 전송 속도를 조절함으로써 네트워크 혼잡 상황을 관리하는데 사용되며, 이를 통해 네트워크 성능을 최적화하고 안정적으로 유지할 수 있습니다. TCP 혼잡 제어 알고리즘 중 다양한 알고리즘이 AIMD의 개념을 기반으로 작동하여 혼잡 상황을 탐지하고 대응합니다.

공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형상태로 수렴하게 됩니다.

문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못합니다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식입니다.

Slow Start

  • 연결 시작
    TCP 연결이 생성되면, 송신자는 전송할 수 있는 데이터의 양을 처음에는 매우 작게 설정합니다. 일반적으로 1 세그먼트 크기(최초 MSS, Maximum Segment Size)로 시작합니다.

  • 지수적인 증가
    Slow Start에서는 각 라운드마다 송신자는 현재까지 성공적으로 전송된 데이터 양에 따라 전송할 수 있는 데이터 양을 지수적으로 증가시킵니다. 즉, 매 라운드마다 전송 가능한 데이터 양이 두 배씩 증가합니다.

  • 혼잡 발생 감지
    데이터 전송 중에 패킷 손실이나 대기 시간 증가 등의 혼잡 신호를 감지하면, 송신자는 데이터 전송 속도를 줄이고 다시 Slow Start 상태로 돌아갑니다.

Slow Start의 목적은 네트워크에 부하를 일으키지 않고 초기에 안정적인 데이터 전송을 유지하는 것입니다. 초기에 너무 많은 데이터를 보내면 혼잡이 발생할 수 있으므로, 네트워크 혼잡을 최소화하면서 전송 속도를 증가시키는 것이 Slow Start의 핵심입니다.

처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있습니다.

그러므로 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킵니다.

Fast Retransmit

패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보냅니다.

단, "순서대로 잘 도착한 마지막 패킷"의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 "중복된 ACK 패킷"을 받게 됩니다.

송신자는 중복된 순번의 패킷을 3개 받으면 재전송을 합니다. 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 window size를 줄입니다.

Fast Recovery

3개의 중복 ACK 패킷을 받으면 약간 혼잡한 상황이라 판단하여 window size를 1로 줄이지 않고 반으로 줄인 후 선형증가하는 방식입니다.(AIMD)

TCP Tahoe

TCP Tahoe는 TCP 혼잡 제어 알고리즘 중 하나로, 초기 혼잡 제어 메커니즘 중의 하나입니다. TCP Tahoe는 1988년에 처음 발표된 것으로, 네트워크 내의 혼잡 상황을 감지하고 조절하는 기능을 포함하고 있습니다. Fast Recovery가 처음으로 도입된 정책이라고 합니다.

처음에는 Slow Start 방식으로 윈도우를 증가시키다가 ssthresh 시점 이후부터는 AIMD 방식을 적용합니다.

진행 중 TimeOut 이나 3 ACK Duplicated 발생 시 네트워크가 혼잡하다는 것을 인지하고 ssthresh는 window size의 절반으로, window size는 1로 회귀하는 방식입니다.

하지만 이 방법에선 혼잡 상황이 발생할 때 마다 윈도우를 1로 초기화하는 부분이 비효율적입니다.

TCP Reno

TCP Tahoe 정책과 모두 동일하지만 3 ACK Duplicated와 TimeOut을 구분해 대응합니다.

3 ACK Duplicated가 발생하면 윈도우 크기를 1로 초기화 하지 않고 AIMD 방식으로 window size를 절반으로 줄여 다시 선형증가하는 방식을 사용합니다. ssthresh도 window size의 절반으로 설정합니다.

TimeOut이 발생한다면 TCP Tahoe와 동일하게 윈도우 사이즈를 1로 줄이고 Slow Start를 시작하지만 ssthresh 값은 변경하지 않습니다.

흐름 제어

흐름 제어(Flow Control)는 송신측과 수신측 사이에서 데이터의 전송 속도를 조절하여 데이터의 과도한 유입을 방지하고, 수신측이 처리할 수 있는 속도로 데이터가 전달되도록 보장하는 메커니즘입니다. 흐름 제어는 데이터의 무결성과 신뢰성을 유지하며, 네트워크의 성능을 최적화하기 위한 중요한 개념입니다.

  • 수신자의 수용 능력 고려
    수신측이 수용할 수 있는 속도로 데이터를 전송하여 데이터의 손실이나 데이터 큐의 오버플로우를 방지합니다.

  • 데이터 무결성 유지
    수신측이 데이터를 처리할 시간과 여유가 없을 경우 데이터가 유실될 수 있습니다. 흐름 제어를 통해 수신측의 처리 능력을 고려하여 데이터 유실을 최소화합니다.

방법

  • Stop and Wait
  • Sliding window
profile
열심히 성장 중인 백엔드

0개의 댓글