TCP(Transmission Control Protocol)는 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나로, 신뢰성 있는 데이터 전송을 목표로 설계된 프로토콜
인터넷에서 데이터를 전송할 때, 데이터를 패킷이라는 작은 조각으로 나누어 전송하게 되는데, TCP는 이 패킷들의 전송을 관리해주는 역할을 한다.
특징
3 way handshake는 TCP 프로토콜에서 사용하는 연결 설정 과정
클라이언트와 서버 사이에 데이터 전송을 시작하기 전에, 양측이 서로 연결 가능한지 확인하고 소통하기 위한 기본 파라미터를 동기화하는데 사용된다.
사용하는 이유
연결 가능성 확인: 클라이언트와 서버가 서로의 존재와 연결 가능성을 확인한다. 이를 통해 불필요한 데이터 전송을 줄이고 효율적인 통신이 가능해진다.
동기화: 양측의 초기 시퀀스 번호를 교환하여, 패킷 전송 순서를 정확하게 관리할 수 있어, 신뢰성 있는 데이터 전송이 가능해진다.
흐름 제어 및 혼잡 제어 파라미터 설정: 3 way handshake 과정에서, 양측은 서로의 윈도우 크기(Window Size)와 같은 중요한 통신 파라미터를 교환하고 동기화하게 되어 효율적인 데이터 전송이 가능해집니다.
과정
사진출처: https://networkhunt.com/tcp-three-way-handshake/
SYN (동기화): 클라이언트가 서버에게 SYN 패킷을 보내어 연결 요청을 합니다. 이 패킷에는 클라이언트의 초기 시퀀스 번호(Sequence Number)가 포함되어 있습니다.
SYN-ACK (동기화-응답): 서버는 SYN 패킷을 받고, 자신의 초기 시퀀스 번호와 함께 ACK 패킷을 클라이언트에게 보냅니다. 이 과정에서 서버는 클라이언트의 시퀀스 번호를 확인하고, 자신의 시퀀스 번호를 설정합니다.
ACK (응답): 클라이언트는 서버의 SYN-ACK 패킷을 받으면, 서버의 시퀀스 번호를 확인하고, 최종적으로 ACK 패킷을 보내어 연결 과정을 완료합니다.
4 way handshake는 TCP 프로토콜에서 사용되는 연결 해제 과정
클라이언트와 서버 간의 통신이 완료된 후, 양쪽에서 연결을 안전하게 종료할 수 있다.
사용하는 이유
양방향 통신 종료: TCP는 전이중 통신을 지원하기 때문에, 양쪽 모두 통신을 종료하고자 함을 확인해야 한다. 4 way handshake를 통해 이를 안전하게 처리할 수 있다.
데이터 전송 완료 확인: 4 way handshake 과정에서 서버는 모든 데이터를 클라이언트에게 전송하고 나서야 연결을 종료하게 된다. 이를 통해 데이터 전송의 신뢰성을 보장할 수 있다.
과정
사진 출처: https://beenii.tistory.com/127
FIN (종료): 클라이언트가 서버에게 통신을 종료하고자 함을 알리기 위해 FIN 패킷을 보낸다.
ACK (응답): 서버는 클라이언트의 FIN 패킷을 받고, 해당 패킷에 대한 확인 응답으로 ACK 패킷을 클라이언트에게 전송한다. 이때 서버는 아직 전송해야 할 데이터가 남아있을 수 있으므로, 연결을 바로 종료하지는 않는다.
서버 데이터 전송 완료 및 FIN: 서버가 남아있는 모든 데이터를 클라이언트에게 전송하고, 전송이 완료되면 클라이언트에게 자신도 연결을 종료하겠다는 의미로 FIN 패킷을 보냅니다.
ACK (응답): 클라이언트는 서버의 FIN 패킷을 받고, 해당 패킷에 대한 확인 응답으로 ACK 패킷을 서버에게 전송합니다. 이 ACK 패킷이 도착하면 서버는 연결을 종료합니다.
혼잡 제어(Congestion control)는 네트워크에서 데이터의 전송 속도를 조절하여 전체적인 성능을 향상시키고, 네트워크의 혼잡도를 낮추기 위한 메커니즘
TCP 프로토콜에서 혼잡 제어는 패킷 손실, 지연 시간 증가, 네트워크의 자원 사용량 등 여러 요인을 고려하여 데이터 전송 속도를 동적으로 조절한다.
필요한 이유
네트워크 자원의 공정한 분배: 여러 사용자가 동시에 네트워크를 사용할 경우, 혼잡 제어를 통해 각 사용자에게 공정한 네트워크 자원 할당이 가능하다.
성능 향상: 혼잡 제어를 통해 패킷 손실 및 지연 시간을 최소화하고, 네트워크의 전체적인 성능을 향상시킬 수 있다.
안정적인 네트워크 운영: 네트워크 혼잡도를 조절함으로써, 네트워크의 안정성을 유지하고 장애 발생 가능성을 줄일 수 있다.
종류
슬로우 스타트(Slow Start): 초기 전송 속도를 낮게 시작하여, 속도를 점진적으로 증가시키는 알고리즘이다. 네트워크의 혼잡 상태를 파악하고 적절한 전송 속도를 찾기 위해 사용된다.
합 증가 / 곱 감소(AIMD(Additive Increase / Multicative Decrease)): 일정한 전송 속도에서 시작하여, 혼잡 윈도우 크기를 1씩 증가시키켜 속도를 증가시키지만, 중간에 패킷 손실이 발생하거나 혼잡 상태가 감지되면 혼잡 윈도우 크기를 반으로 줄여서 네트워크 혼잡을 회피하는 알고리즘이다.
빠른 회복(Fast Recovery): 패킷 손실이 발생하면 전송 속도를 급격히 낮추지 않고, 일정 수준에서 유지하며 혼잡 상태를 회복하는 알고리즘이다. 빠른 회복을 통해 전송 속도를 빠르게 회복하고 성능을 향상시킬 수 있다.
빠른 재전송(Fast Retransmit): 패킷 손실이 감지되면 즉시 해당 패킷을 재전송하는 알고리즘이다. 빠른 재전송을 통해 패킷 손실에 대한 처리 시간을 단축하고, 전송 속도를 빠르게 회복할 수 있다.
CUBIC: 슬로우 스타트, 혼잡 회피, 빠른 회복 등의 알고리즘을 결합하여, 전송 속도를 동적으로 조절하는 알고리즘이다. 테일러드 커브는 네트워크의 혼잡 상태에 따라 적절한 전송 속도를 선택하고, 성능을 최적화한다.
BBR(Bottleneck Bandwidth and RTT): BBR은 병목 대역폭과 반품 시간(Round-Trip Time) 정보를 이용하여 전송 속도를 결정하는 알고리즘이다. BBR은 네트워크의 현재 상태를 파악하고, 최적의 전송 속도를 적용하여 성능을 향상시킨다.
// 슬로우 스타트와 혼잡 회피는 전통적인 혼잡 제어 알고리즘에서 주로 사용되는 기법. 빠른 재전송과 빠른 회복은 TCP Reno 및 TCP NewReno에서 도입되어, 전송 속도를 빠르게 회복하고 성능을 향상시키는 데 도움이 된다. 최근에는 특히 TCP CUBIC과 BBR이 높은 성능과 네트워크 환경 적응력으로 인해 널리 사용되고 있다.
// 혼잡제어 정책: TCP Tahoe => TCP Reno(리눅스, 윈도우, 스마트폰) => TCP CUBIC(리눅스 디폴트)
수신 측의 처리 능력에 맞춰 송신 측의 전송 속도를 조절하여, 수신측이 처리할 수 있는 범위 내에서 데이터를 전송하는 메커니즘
수신측의 버퍼 오버플로우를 방지하고, 데이터 손실을 최소화하기 위해 사용한다.
필요한 이유
수신측 처리능력 고려: 송신측이 수신측의 처리능력을 초과하여 데이터를 전송하면, 수신측에서 데이터 손실이 발생할 수 있다. 흐름 제어를 통해 이러한 상황을 방지할 수 있다.
버퍼 오버플로우 방지: 수신측에서 처리할 수 있는 데이터 양을 초과하는 경우, 버퍼 오버플로우가 발생하여 데이터 손실이 발생할 수 있다. 흐름 제어를 사용하면 송신측과 수신측의 전송 속도를 적절하게 조절하여 이를 방지할 수 있다.
네트워크 자원 효율적 사용: 흐름 제어를 통해 송신측과 수신측 간의 데이터 전송 속도를 최적화하면, 네트워크 자원의 효율적인 사용이 가능하고,네트워크의 전체적인 성능을 향상시킬 수 있다.
종류
정지-대기(Stop-and-Wait): 송신측이 한 번에 하나의 패킷을 전송한 후, 수신측의 ACK(응답)를 기다리는 방식으로, 수신측이 ACK를 전송하면, 송신측은 다음 패킷을 전송한다. 단순하지만 효율성이 낮다.
슬라이딩 윈도우(Sliding Window): 송신측이 수신측의 윈도우 크기에 따라 여러 패킷을 연속적으로 전송할 수 있는 방식이다. 수신측은 ACK를 전송함으로써 송신측에게 자신이 처리할 수 있는 패킷의 양을 알려준다. 정지-대기 방식에 비해 효율성이 높다.
수신측 윈도우 조절(Receiver Window Scaling): 수신측이 자신의 버퍼 크기에 따라 윈도우 크기를 동적으로 조절하는 방식이다. 이를 통해 수신측의 처리능력에 맞게 데이터 전송 속도를 조절할 수 있다.