> 웹 프론트엔드 > JS 튜토리얼 > TCP 대 UDP 프로토콜

TCP 대 UDP 프로토콜

DDD
풀어 주다: 2024-11-05 11:06:02
원래의
618명이 탐색했습니다.

TCP와 UDP는 인터넷 프로토콜 제품군의 전송 계층에서 작동하며 네트워크를 통한 장치 간 데이터 전송을 촉진하는 역할을 합니다.

TCP(Transmission Control Protocol)는 송신자와 수신자 사이에 안정적인 채널을 구축하는 연결 지향 프로토콜입니다.

모든 데이터 패킷이 정확하고 올바른 순서로 전달되도록 보장하므로 데이터 무결성이 중요한 애플리케이션에 이상적입니다.

UDP(User Datagram Protocol)는 전용 종단 간 연결을 설정하지 않고 데이터를 전송하는 비연결 프로토콜입니다.

데이터 패킷의 전달이나 순서를 보장하지 않으므로 오버헤드가 줄어들고 전송 속도가 빨라집니다.

이로 인해 UDP는 안정성보다 속도가 더 중요한 애플리케이션에 적합합니다.


TCP와 UDP 이해


TCP vs UDP protocol

A. 전송 제어 프로토콜(TCP)

연결 지향 프로토콜

TCP는 연결 지향 프로토콜입니다. 즉, 데이터 전송이 시작되기 전에 발신자와 수신자 간에 공식적인 연결이 설정되어야 합니다.

이 설정 프로세스를 '3방향 핸드셰이크'라고 합니다.

이 핸드셰이크에서는 발신자와 수신자가 동기화(SYN) 및 승인(ACK) 패킷을 교환하여 초기 시퀀스 번호와 창 크기에 동의합니다.

이러한 연결을 설정하면 양측이 통신할 준비가 되어 안정적인 데이터 교환 채널을 제공할 수 있습니다.

TCP vs UDP protocol

안정적인 데이터 전송

TCP의 주요 강점 중 하나는 전송된 순서대로 데이터 패킷의 안정적인 전달을 보장하는 기능입니다.

이는 순서 지정 및 승인 메커니즘을 통해 달성됩니다.

  • 시퀀싱: 데이터의 모든 바이트에는 시퀀스 번호가 할당됩니다.

이를 통해 네트워크 라우팅으로 인해 패킷이 순서대로 도착하지 않더라도 수신자는 패킷을 올바른 순서로 재조립할 수 있습니다.

  • 승인: 수신자는 수신된 패킷에 대한 승인을 다시 보냅니다.

발신자가 특정 시간 내에 확인을 받지 못하면 패킷이 손실된 것으로 간주하고 다시 전송합니다.

흐름 제어 및 혼잡 제어

TCP는 흐름 제어 및 혼잡 제어 알고리즘을 통합하여 데이터 전송을 효율적으로 관리합니다.

  • 흐름 제어: 이 메커니즘은 발신자가 너무 많은 데이터로 수신자를 너무 빨리 압도하는 것을 방지합니다.

TCP는 수신자가 한 번에 수용할 수 있는 데이터의 양(창 크기)을 알리는 슬라이딩 창 프로토콜을 사용합니다.

발신자는 이 제한을 준수하여 원활한 데이터 흐름을 보장하고 수신자 측에서 버퍼 오버플로를 방지해야 합니다.

  • 혼잡 제어: TCP는 네트워크 상태를 모니터링하여 네트워크의 혼잡을 감지합니다.

느린 시작, 혼잡 회피, 빠른 재전송, 빠른 복구와 같은 알고리즘을 사용하여 데이터 전송 속도를 조정합니다.

패킷 손실이나 지연이 감지되면(잠재적인 정체 신호) 발신자는 네트워크 부담을 완화하기 위해 전송 속도를 줄입니다.

반대로, 네트워크가 깨끗하면 TCP는 처리량을 최적화하기 위해 전송 속도를 점차 증가시킵니다.


TCP vs UDP protocol

B. 사용자 데이터그램 프로토콜(UDP)

비연결 프로토콜

UDP는 비연결 프로토콜입니다. 즉, 데이터가 전송되기 전에 전용 종단 간 연결이 필요하지 않습니다.

핸드셰이크 프로세스를 통해 연결을 설정하는 TCP와 달리 UDP는 사전 통신 설정 없이 데이터그램이라는 데이터 패킷을 수신자에게 직접 보냅니다.

이러한 연결 설정 부족으로 인해 초기 지연이 줄어들고 데이터 전송이 즉시 시작됩니다.

발신자는 수신자의 승인을 기다리지 않으므로 통신 프로세스가 간단하고 효율적입니다.

사전 연결을 설정하지 않고 데이터를 보냅니다.

  • 즉시 전송: 연결 설정이 없기 때문에 데이터가 준비되는 즉시 전송할 수 있으며 이는 시간에 민감한 애플리케이션에 매우 중요합니다.

  • 핸드셰이크 프로세스 없음: 연결 설정 및 종료와 관련된 오버헤드를 제거하여 대기 시간을 줄입니다.

  • 상태 비저장 통신: 각 데이터그램은 독립적이며 라우팅에 필요한 모든 정보를 포함하므로 프로토콜을 단순화하고 네트워크 장치의 리소스 사용량을 줄입니다.

신뢰할 수 없지만 더 빠른 데이터 전송

UDP는 네트워킹 용어로 다음을 의미하는 "신뢰할 수 없는" 서비스를 제공합니다.

  • 패킷 전달 보장 없음: 보낸 사람에게 알리지 않고 전송 중에 데이터그램이 손실될 수 있습니다.

  • 순서 보장 불가: UDP는 패킷 순서를 변경하지 않으므로 패킷이 순서 없이 도착할 수 있습니다.

  • 오류 수정 없음: TCP와 달리 UDP는 오류를 확인하지 않으며 손실되거나 손상된 패킷을 재전송하지 않습니다.

특정 상황에서 신뢰성이 없다는 장점

  • 오버헤드 감소: UDP는 패킷 전달을 추적하지 않거나 승인을 처리하지 않음으로써 네트워크를 통해 전송되는 추가 데이터의 양을 줄입니다.

  • 더 빠른 전송: 발신자와 수신자 모두에 필요한 처리량이 적어 처리량을 높이고 대기 시간을 줄일 수 있습니다.

  • 애플리케이션 수준 제어: 일부 애플리케이션은 전송 프로토콜에 의존하기보다는 자체적으로 안정성과 오류 수정을 처리하는 것을 선호합니다.

낮은 오버헤드

UDP의 미니멀한 디자인은 낮은 오버헤드에 기여합니다.

  • 작은 헤더 크기: TCP의 20바이트 헤더에 비해 UDP의 헤더 길이는 8바이트에 불과합니다. 크기가 작다는 것은 각 패킷에 전송되는 데이터의 양이 적어 대역폭이 절약된다는 의미입니다.

  • 간소화된 처리: 기능이 적다는 것은 네트워킹 장비와 엔드포인트에 대한 계산 작업이 줄어들어 특히 부하가 높은 경우 성능을 향상시킬 수 있음을 의미합니다.

  • 고성능 애플리케이션의 효율성: 오버헤드가 줄어들기 때문에 UDP는 대량의 데이터를 신속하게 전송해야 하고 일부 데이터 손실을 허용할 수 있는 애플리케이션에 적합합니다.


사용 사례 예 및 실제 적용


TCP vs UDP protocol

A. TCP 사용 사례

1. 웹 브라우징(HTTP/HTTPS)

페이지 렌더링을 위한 안정적인 데이터 전송 필요

웹 브라우징은 웹페이지를 올바르게 렌더링하기 위해 정확하고 완전한 데이터 전송에 크게 의존합니다.

HTTP 및 HTTPS 프로토콜은 TCP를 사용하여 텍스트, 이미지, 스크립트 등 웹페이지의 모든 요소가 안정적이고 올바른 순서로 전달되도록 합니다.

TCP의 오류 확인 및 확인 기능은 누락되거나 손상된 패킷의 재전송을 보장하여 사용자 경험과 기능에 필수적인 깨진 이미지나 불완전한 콘텐츠를 방지합니다.

2. 이메일 서비스(SMTP, IMAP)

완전하고 순서대로 메시지 전달 보장

SMTP(Simple Mail Transfer Protocol) 및 IMAP(Internet Message Access Protocol)과 같은 이메일 프로토콜은 TCP를 사용하여 안정적인 메시지 전송을 제공합니다.

이메일에는 손상되지 않은 상태로 도착해야 하는 중요한 정보와 첨부 파일이 포함되어 있는 경우가 많습니다.

TCP는 이메일의 모든 부분이 오류 없이 올바른 순서로 수신되도록 보장하여 통신의 무결성을 유지하고 개인 및 업무 통신에 중요한 데이터 손실을 방지합니다.


B. UDP 사용 사례

1. 실시간 통신(VoIP, 화상회의)

신뢰성보다 속도를 우선시하여 지연 시간 단축

VoIP(Voice over IP) 및 화상 회의와 같은 애플리케이션은 원활한 실시간 통신을 위해 지연을 최소화해야 합니다.

UDP는 연결을 설정하거나 패킷 전달을 보장하는 오버헤드 없이 데이터를 빠르게 전송할 수 있기 때문에 사용됩니다.

UDP는 모든 패킷의 도착이나 순서가 올바른지 보장하지 않지만 간헐적으로 데이터 패킷이 손실되면 짧은 결함이 발생할 수 있지만 전체 대화에 큰 영향을 미치지는 않습니다.

자연스러운 의사소통 흐름을 유지하기 위해 지연 시간을 줄이는 것이 우선입니다.

3. 스트리밍 서비스

연속 재생을 위한 사소한 데이터 손실 허용

라이브 비디오나 오디오 스트리밍과 같은 스트리밍 서비스는 UDP를 사용하여 사용자에게 지속적으로 데이터를 보냅니다.

프로토콜의 낮은 오버헤드 덕분에 오류 확인 및 재전송과 관련된 지연 없이 안정적인 스트림이 가능합니다.

사소한 패킷 손실로 인해 품질이 약간 저하될 수 있지만 일반적으로 사용자는 이를 인지할 수 없습니다.

핵심 목표는 버퍼링과 중단을 방지하여 중단 없이 시청하거나 청취할 수 있는 환경을 제공하는 것입니다.

UDP를 사용하면 완벽한 데이터 정확성보다 지속적인 재생을 우선시하는 서비스가 가능합니다.

2. 온라인 게임

실시간 상호작용을 위해 빠른 데이터 전송이 필요합니다

온라인 게임에서는 플레이어의 행동을 즉각적으로 반영하기 위해 신속하고 지속적인 데이터 교환이 필요합니다.

UDP는 반응형 게임플레이에 필수적인 저지연 통신을 제공하므로 선호됩니다.

플레이어는 눈에 띄는 지연 없이 실시간 상호 작용을 경험할 수 있습니다.

일부 데이터 패킷이 손실될 수 있지만 일반적으로 게임은 게임 상태를 자주 업데이트하여 보상하여 원활한 경험을 보장합니다.

게임플레이를 원활하게 유지하기 위해 절대적인 안정성보다는 속도에 중점을 둡니다.


성능 고려 사항

TCP와 UDP 중에서 선택할 때는 각 프로토콜의 특성이 네트워크 성능에 어떤 영향을 미치는지 고려하는 것이 중요합니다.

주요 요소에는 지연 시간, 처리량, 안정성, 그리고 이러한 요소가 애플리케이션의 기능과 사용자 경험에 미치는 영향이 포함됩니다.


지연 시간 및 처리량

1. TCP 오버헤드

승인 패킷 및 핸드셰이크로 인해 지연이 발생할 수 있습니다

TCP는 안정성과 순서 있는 데이터 전달을 위해 설계되었으므로 추가 오버헤드가 발생합니다.

  • 3방향 핸드셰이크: 데이터 전송이 시작되기 전에 TCP에서는 3방향 핸드셰이크를 통해 연결이 설정되어야 합니다.

이 프로세스에는 SYN(동기화) 및 ACK(승인) 패킷 교환과 초기 대기 시간 추가가 포함됩니다.

  • 승인 및 재전송: 연결이 설정된 후 TCP는 수신된 패킷에 대한 승인을 요구하여 안정성을 보장합니다.

승인을 받지 못한 경우 TCP는 데이터를 재전송합니다. 이는 전송을 보장하지만 특히 대기 시간이 긴 네트워크나 장거리에서는 지연이 발생할 수 있습니다.

  • 흐름 제어 및 혼잡 제어: TCP는 네트워크 상태에 따라 데이터 전송 속도를 조정하여 혼잡을 방지합니다.

이러한 메커니즘은 네트워크 안정성에 도움이 되지만 정체 기간 동안 처리량을 줄여 애플리케이션 성능에 영향을 줄 수 있습니다.

2. UDP 효율성

오버헤드 감소로 지연 시간 감소
UDP의 설계는 속도와 효율성을 우선시합니다.

연결 설정 없음: UDP는 연결이 없으므로 데이터를 보내기 전에 핸드셰이크가 필요하지 않습니다.

초기 설정이 없기 때문에 지연 시간이 줄어들어 즉각적인 데이터 전송이 가능합니다.

승인 없음: UDP는 승인을 기다리지 않거나 손실된 패킷을 재전송하지 않으므로 TCP에서 이러한 프로세스와 관련된 지연이 제거됩니다.

최소 프로토콜 오버헤드: UDP는 더 작은 헤더 크기와 더 적은 프로토콜 메커니즘을 통해 네트워크를 통해 전송되는 추가 데이터의 양을 줄여 처리량을 늘리고 대기 시간을 줄입니다.

B. 신뢰성과 속도의 균형

1. 지원자격

속도가 중요한지 신뢰성이 중요한지 판단

TCP와 UDP 중에서 선택하는 것은 애플리케이션의 특정 요구 사항에 따라 다릅니다.

  • 신뢰성이 중요한 경우: 파일 전송, 웹 검색, 이메일 서비스와 같은 애플리케이션에는 완전하고 정확한 데이터 전달이 필요합니다.

이러한 경우 데이터 무결성과 순서를 보장하려면 TCP의 신뢰성 기능이 필수적입니다.

  • 속도와 낮은 지연 시간이 중요한 경우: 라이브 비디오 스트리밍, 온라인 게임, VoIP와 같은 애플리케이션은 완벽한 안정성보다 실시간 데이터 전달을 우선시합니다.

여기서 UDP는 오버헤드가 낮고 전송 속도가 빠르기 때문에 일부 데이터 패킷이 도중에 손실되더라도 선호되는 선택입니다.

2. 하이브리드 접근 방식

적절한 경우 두 프로토콜 모두 사용

일부 시나리오에서는 TCP와 UDP를 결합하여 성능을 최적화할 수 있습니다.

  • 선택적 프로토콜 사용: 애플리케이션은 특정 기능에는 TCP를 사용하고 다른 기능에는 UDP를 사용할 수 있습니다.

예를 들어 화상 회의 앱은 지연 시간을 최소화하기 위해 실시간 오디오 및 비디오 스트림에 UDP를 사용할 수 있으며, 안정적인 전달을 보장하기 위해 앱 내에서 문자 메시지나 파일 전송에 TCP를 사용할 수 있습니다.

  • UDP를 통한 사용자 정의 신뢰성 메커니즘: 개발자는 UDP 위에 자체 오류 검사 및 재전송 전략을 구현할 수 있습니다.

이 접근 방식을 사용하면 애플리케이션의 요구 사항에 맞게 특별히 맞춤화되어 필요할 때 안정성을 높이고 지연 시간이 짧은 통신이 가능해집니다.

  • 병렬 연결: 일부 애플리케이션은 TCP와 UDP 연결을 동시에 설정하여 각 프로토콜의 장점을 적절하게 활용합니다.

보안에 미치는 영향

TCP와 UDP 중에서 선택할 때는 성능과 안정성뿐만 아니라 보안에 미치는 영향도 고려하는 것이 중요합니다.

각 프로토콜에는 악의적인 행위자가 악용할 수 있는 고유한 취약점이 있습니다.

이러한 취약점을 이해하고 적절한 완화 기술을 구현하는 것은 네트워크 보안을 유지하는 데 중요합니다.

5초간 생각

브이. 보안에 미치는 영향

TCP와 UDP 중에서 선택할 때는 성능과 안정성뿐만 아니라 보안에 미치는 영향도 고려하는 것이 중요합니다. 각 프로토콜에는 악의적인 행위자가 악용할 수 있는 고유한 취약점이 있습니다. 네트워크 보안을 유지하려면 이러한 취약점을 이해하고 적절한 완화 기술을 구현하는 것이 중요합니다.

A. TCP 보안 문제

1. 취약점

SYN Flooding 공격에 대한 취약성

TCP의 연결 지향 특성상 클라이언트와 서버 간의 연결을 설정하려면 3방향 핸드셰이크(SYN, SYN-ACK, ACK)가 필요합니다.

SYN 플러딩 공격에서 공격자는 서버에 대량의 SYN 요청을 보내지만 핸드셰이크를 완료하지 않음으로써 이 메커니즘을 악용합니다.

구체적으로 공격자는 다음과 같습니다.

  • 스푸핑된 IP 주소로 수많은 SYN 패킷을 보냅니다.

  • 서버는 SYN-ACK 패킷으로 응답하고 각각의 미완료 연결에 리소스를 할당합니다.

  • 클라이언트의 최종 ACK가 도착하지 않기 때문에 이러한 연결은 반쯤 열린 상태로 유지되어 서버의 메모리와 처리 능력을 소모합니다.

결과적으로 서버 리소스가 과부하되어 합법적인 클라이언트가 연결을 설정할 수 없어 서비스 거부(DoS) 상태가 발생하게 됩니다.

2. 완화 기술

SYN 쿠키 구현

SYN 쿠키는 반개방 연결에 추가 리소스를 요구하지 않고 SYN 플러딩 공격을 완화하는 서버측 기술입니다. 작동 방식은 다음과 같습니다.

SYN 패킷이 수신되면 서버는 리소스를 할당하는 대신 상태(예: 시퀀스 번호 및 기타 연결 매개변수)를 SYN-ACK 패킷의 ISN(초기 시퀀스 번호) 필드에 인코딩합니다.

클라이언트가 ACK 패킷으로 응답하면(핸드셰이크 완료) 서버는 ISN에서 원래 연결 상태를 재구성하고 연결 설정을 진행할 수 있습니다.

이 접근 방식을 사용하면 서버가 절반만 열린 연결을 추적할 필요가 없기 때문에 리소스에 과부하를 주지 않고 많은 수의 SYN 요청을 처리할 수 있습니다.

방화벽 및 침입 방지 시스템 사용

SYN 플러딩 공격을 감지하고 완화하도록 방화벽과 침입 방지 시스템(IPS)을 구성할 수 있습니다.

속도 제한: 단일 IP 주소 또는 서브넷에서 SYN 패킷 수를 제한하면 공격의 영향을 줄일 수 있습니다.

임계값 및 경고: 일반 SYN 트래픽에 대한 임계값을 설정하고 초과 시 경고를 생성하면 조기 감지에 도움이 됩니다.

위조된 IP 주소 필터링: 수신 및 송신 필터링을 구현하여 위조된 소스 IP 주소가 포함된 패킷을 차단합니다.

타임아웃 조정

반쯤 열린 연결의 시간 초과 기간을 조정하면 리소스를 더 빨리 확보할 수 있습니다.

SYN-RECEIVED 시간 초과 줄이기: 반쯤 열린 연결을 끊기 전에 서버가 최종 ACK를 기다리는 시간을 줄입니다.

B. UDP 보안 문제

1. 취약점

DNS 증폭과 같은 증폭 공격에 취약함

UDP는 비연결성 특성과 검증 부족으로 인해 증폭 공격에 취약합니다. 공격자는 대상을 향한 트래픽 양을 증폭시켜 DDoS(분산 서비스 거부)를 일으킬 수 있습니다. DNS 증폭 공격의 경우:

  • 공격자는 DNS 확인자를 열기 위해 스푸핑된 소스 IP 주소(피해자의 IP)가 포함된 소규모 DNS 쿼리 요청을 보냅니다.
  • DNS 서버는 피해자의 IP 주소에 대해 더 큰 DNS 응답으로 응답합니다.
  • 응답이 요청보다 훨씬 크기 때문에 증폭 요인이 중요할 수 있습니다.

유사한 증폭 공격은 NTP(Network Time Protocol) 및 SSDP(Simple Service Discovery Protocol)와 같은 다른 UDP 기반 서비스를 악용할 수 있습니다.

2. 완화 기술

속도 제한

속도 제한을 구현하면 네트워크를 오가는 트래픽 흐름을 제어할 수 있습니다.

  • 들어오는 요청 제한: 서버가 단일 IP 또는 서브넷에서 응답하는 초당 요청 수에 대한 임계값을 설정합니다.
  • 아웃바운드 응답 제한: 서버가 증폭기로 사용되는 것을 방지하기 위해 서버가 응답을 보내는 속도를 제한합니다.

강력한 필터링 메커니즘

악성 트래픽 차단을 위한 고급 필터링 기술 사용:

  • 수신 및 송신 필터링: 네트워크 에지에서 스푸핑된 IP 주소가 포함된 패킷을 차단하여 해당 패킷이 네트워크에 들어오거나 나가는 것을 방지합니다.
  • 애플리케이션 계층 게이트웨이: 애플리케이션 계층 데이터를 전달하기 전에 검사하고 검증할 수 있는 프록시 또는 게이트웨이를 사용합니다.
  • 프로토콜 규정 준수 검사: 들어오는 요청이 예상되는 프로토콜 동작을 준수하는지 확인하고 형식이 잘못되었거나 의심스러운 패킷을 삭제합니다. 사용하지 않는 UDP 서비스 비활성화

사용하지 않는 UDP 서비스를 비활성화하여 공격 표면 줄이기:

  • 불필요한 포트 닫기: UDP 포트에서 실행되는 불필요한 포트 서비스를 종료합니다.

  • 개방형 서비스 보안: 필요한 서비스에 대해 인증 및 액세스 제어를 구현하여 남용을 방지합니다.

  • DNSSEC 및 RRL(응답 속도 제한) 사용
    DNS 서버의 경우:

DNSSEC(Domain Name System Security Extensions): DNS 응답에 인증을 추가하여 스푸핑 공격의 효과를 줄입니다.

응답 속도 제한: 증폭 공격에 참여하지 못하도록 응답 속도를 제한하도록 DNS 서버를 구성합니다.

위 내용은 TCP 대 UDP 프로토콜의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

원천:dev.to
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿