[Computer Science]

TCP/IP(흐름/혼잡 제어, 3방향/4방향 핸드셰이크)

TCP/IP

먼저 TCP와 IP의 개념에 대해 알아봅시다!

TCP/IP는 OSI-7 계층에서 계층 3과 4를 처리하는 프로토콜(통신 프로토콜)입니다. TCP/IP 패킷 통신 방식의 인터넷 프로토콜인 IP그리고 TCP, 전송 제어 프로토콜구성

• IP
  • 3계층의 OSI 7계층(네트워크 계층)
  • 끝점이 다른 끝점으로 가고자 할 때 경로를 찾고 목적지 = 라우팅을 찾습니다.
  • 소포 배송 보증 X
  • 패킷을 보내고 받는 순서는 다를 수 있습니다.
• TCP
  • 4계층에 OSI 7계층(전송 계층)
  • 신뢰할 수 있는 연결을 유지하기 위해 발신자와 수신자 사이의 논리적 연결을 담당합니다.
  • IP를 통해 실행되는 프로토콜
  • 데이터가 어떤 순서로 전달되는지 확인
  • HTTP, HTTPS, FTP 및 SMTP와 같은 TCP 기반의 많은 애플리케이션 프로토콜 존재

즉, TCP/IP는 TCP와 IP의 조합입니다. TCP/IP를 사용한다는 것은 IP 주소 시스템을 따르고, IP ​​라우팅을 사용하여 목적지에 도달하고, TCP의 속성을 사용하여 발신자와 수신자 사이의 논리적 연결을 설정하고 이를 유지할 수 있다는 의미의 신뢰성을 보장하는 것을 의미합니다.

TCP/IP에 대해 이야기하는 것은 송신자가 IP 주소를 사용하여 수신자에게 데이터를 보내는지, 데이터가 올바르게 전송되는지, 너무 빠르지 않은지, 올바르게 수신되는지에 대한 이야기입니다!

TCP

위에서 언급했듯이 TCP는 모든 데이터를 안정적으로 보내는 데 가장 높은 가치를 부여합니다. 데이터를 안정적으로 전송하기 위해 필요한 정보는 TCP 헤더에 포함되어 제공됩니다.

SYN, ACK, FIN, RST, 소스 포트, 대상 포트, 시퀀스 번호, 창 크기, 체크섬과 같은 정보를 제공하며 여기에는 신뢰성 보장, 흐름 제어 및 혼잡 제어에 포함될 수 있는 요소도 포함됩니다.

이 정보를 기반으로 TCP는 상대방과 안정적인 연결을 설정하고 데이터를 전송합니다. 이 작업은 3방향 핸드셰이크입니다.

3방향 악수, 4방향 악수

신뢰할 수 있는 커뮤니케이션이란 무엇입니까?

• 데이터를 보내기 전에 송신자와 수신자가 서로 통신할 수 있는지 확인하십시오.
• 동시에 수신 가능한 데이터 양 확인
• ….

이 과정이 바로 3-way handshake입니다!

특히, 연결을 설정하는 프로세스 3방향 핸드셰이크그리고 이별의 과정 4방향 핸드셰이크오전.

3방향 핸드셰이크

목적:

양측이 데이터를 송수신할 준비가 되었는지 확인하고 데이터 전송이 실제로 시작되기 전에 상대방이 준비되었음을 알 수 있도록 합니다.

TCP 헤더 정보를 사용하여 위의 과정을 수행하는 것이 좋습니다. 3방향 핸드셰이크아래 그림에 나와 있습니다.

• 발신자는 수신자에게 SYN을 보내 통신이 가능한지 확인합니다.
  • 스테이션이 처음으로 데이터를 전송할 때 시퀀스 번호 임의의 난수로 지칭
  • SYN 플래그 비트가 1로 설정된 세그먼트 전송
  • 포트 상태
    • 호스트 A: 닫힘
    • 서버: 듣기
• 수신자는 SYN을 수신하고 송신자에게 SYN/ACK를 보내 통신할 준비가 되었음을 나타냅니다.
  • 접근 요청을 받은 서버는 요청을 수락 + 발신자인 호스트 A도 포트를 열라는 메시지를 보냄(SYN + ACK)
  • 포트 상태
    • 호스트 A: 닫힘
    • 서버: SYN_RCV
• 발신자는 수신자로부터 SYN/ACK를 수신하고 ACK를 전송하여 전송 시작을 알립니다.
  • 마지막으로 송신자 호스트 A는 연결 설정 승인(ACK)을 보냅니다.
  • 이때 전송할 데이터가 있으면 이 단계에서 데이터를 전송할 수 있다.
  • 포트 상태
    • 호스트 A: 설정됨
    • 서버: 설정

TCP를 통해 통신하는 응용 프로그램이 데이터가 전송되기 전에 정확한 전송을 보장하기 위해 다른 컴퓨터와의 세션을 미리 설정하는 프로세스입니다.

4방향 핸드셰이크

목적:

다른 컴퓨터에 연결된 세션을 안전하게 종료하려면

• 송신자는 FIN 플래그를 수신자에게 전송하여 연결 종료를 알립니다.
  • 호스트 A는 FIN 플래그를 보내고 호스트 B가 동일한 FIN 플래그로 응답할 때까지 연결이 열려 있습니다.
  • 포트 상태
    • 호스트 A: FIN_WALT1
    • 호스트 B: 설정됨
• 수신자가 FIN 플래그를 수신하면 응답 패킷 ACK가 전달됩니다.
  • 호스트 B는 확인 메시지를 한 번 보내고 자신의 통신이 끝날 때까지 기다립니다.
  • 아직 보낼 데이터가 있으면 계속 보내기
  • 호스트 A는 호스트 B의 첫 번째 FIN 플래그에 대한 ACK를 수신하고 호스트 B의 두 번째 FIN 플래그를 기다립니다.
  • 포트 상태
    • 호스트 A: FIN_WALT2
    • 호스트 B: CLOSE_WAIT
• 수신자는 FIN 플래그를 발신자에게 보내 연결을 닫습니다.
  • 호스트 B가 통신을 마치고 연결을 닫을 준비가 되면 FIN 플래그를 보내 연결을 닫을 준비가 되었음을 알리고 호스트 A의 응답을 기다립니다.
  • 포트 상태
    • 호스트 A: FIN_WALT2
    • 호스트 B: LAST_ACK
• 송신자는 수신자에게 승인 ACK를 보내고 그 직후 세션이 종료됩니다.
  • 호스트 A는 호스트 B로부터 FIN 플래그를 수신한 후 ACK 응답을 전송하여 TIME_WAIT 상태로 진입합니다.
  • 호스트 B는 호스트 A로부터 ACK를 받으면 변경되지 않고 종료됩니다.
  • 호스트 B가 응답하지 않으면 호스트 A도 종료됩니다.
  • 포트 상태
    • 호스트 A: TIME_WAIT → 닫은
    • 호스트 B: 닫힘

호스트 A가 즉시 닫히지 않는 이유는 무엇입니까?
FIN 플래그****를 보내기 전에 Host B에서 보낸 패킷이 여러 가지 이유로(라우팅 지연, 패킷 손실…) FIN 패킷보다 늦게 도착하면 Host A가 이미 CLOSED이면 이 패킷은 폐기됩니다. 잃어버린. 따라서 이러한 상황에 대비하여 FIN 플래그를 수신하더라도 일정 시간(기본 240초) 동안 세션을 유지하며 추가 패킷을 기다리는 과정을 거친다. 이 프로세스를 TIME_WAIT라고 합니다.

흐름 제어 및 혼잡 제어

TCP에는 흐름 제어 및 혼잡 제어 기능이 있으며 이러한 기능 덕분에 안정적인 통신을 유지할 수 있습니다.

흐름 제어

송신측과 수신측의 데이터 처리 속도 차이를 해소하기 위한 기술

Host – Host(End to End): 호스트 간의 패킷 수를 제어합니다.

• 수신측 속도 > 송신측 속도 문제 없음
• 수신측 속도 < 송신측 속도 ➡ 문제❗

발신자가 수신자가 데이터를 처리할 수 있는 것보다 더 빨리 데이터를 보내면 수신자가 제한된 저장 용량(일반적으로 대기열)을 초과하여 데이터 손실이 발생할 수 있습니다. 따라서 이러한 상황이 발생하지 않도록 하려면 송신기의 데이터 전송을 강제로 줄여야 합니다.

• 정지 대기 방식
  • 패킷을 한 번에 하나씩 전송하는 비효율적인 방법
  • 따라서 다음 패킷은 전송된 각 패킷에 대한 승인을 수신한 경우에만 전송됩니다.
• 슬라이딩 윈도우 기술
  • 수신자는 3-way handshake 동안 송신자에게 동시에 처리할 수 있는 데이터의 양(window size)을 전송한다. 또한 통신 과정에서 네트워크 정체 등의 상황에 따라 창 크기를 유연하게 조정할 수 있습니다. 수신측에서 송신측으로 승인(ACK)을 보낼 때 TCP 헤더에 포함하여 보낼 수 있습니다.
  • 운영 절차는 다음과 같습니다. 윈도우에 포함된 패킷은 지속적으로 전송되며, 수신자로부터 ACK(Acknowledgement)를 수신하면 윈도우가 옆으로 이동하여 다음 패킷이 전송됩니다. 그런 다음 모든 데이터가 수신될 때까지 위의 과정을 반복합니다.

혼잡 제어

발신자 측의 데이터 전송과 네트워크 처리 속도의 차이를 해결하는 기술

호스트 – 네트워크: 네트워크의 패킷 수를 제어하여 오버플로우 방지

• 발신자의 로컬 데이터 네트워크와 인터넷에 연결된 대규모 네트워크를 통해 전송
• 라우터에 데이터가 과부하(혼잡)되면 모든 데이터를 처리할 수 없습니다.

라우터가 전송된 모든 데이터를 처리할 수 없는 경우 호스트는 재전송해야 하므로 혼잡이 증가하고 오버플로 또는 데이터 손실이 발생합니다. 따라서 이러한 네트워크의 혼잡을 피하기 위해서는 송신측에서 강제로 송신 데이터의 전송 속도를 줄여야 합니다.

• 가산 이득/승법 감소(AIMD)
  • 직역하면 총액증가/상품감소 방식입니다.
  • 개별적으로 패킷 보내기
  • 문제없이 도착 : 창을 1씩 늘리면서 전송
  • 보내기 실패: 창 크기 절반
  • 네트워크에 늦게 합류하는 호스트는 처음에는 불리하지만 시간이 지남에 따라 평형에 접근합니다.
  • 윈도우 크기가 너무 작게 증가하기 때문에 네트워크의 모든 대역폭을 사용하여 합리적인 속도로 통신하는 데 시간이 오래 걸릴 수 있다는 단점이 있습니다.
  • 또한 네트워크가 정체될 상황을 예상하지 않고 네트워크가 정체된 후에만 대역폭을 줄입니다.

• 느린 시작
  • 위의 AIMD 방법은 윈도우 크기를 선형적으로 증가시키기 때문에 올바른 네트워크 속도를 얻는 데 오랜 시간이 걸립니다. 따라서 Slow Start는 창 크기를 기하급수적으로 늘립니다.
  • 보낸 데이터의 ACK가 도착할 때마다 윈도우 크기가 증가하고 최종 윈도우 크기는 한 주기 후에 두 배가 됩니다.
  • 과부하 발생: 창 크기를 1로 줄입니다.
  • 그 후 윈도우 크기는 다시 혼잡이 발생한 윈도우 크기의 절반이 될 때까지 이전보다 2배 증가한 후 이후 1씩 증가한다.
  • 이 방법은 윈도우의 크기가 처음에는 천천히 커질 수 있지만 시간이 지남에 따라 윈도우의 크기가 급격히 커진다는 장점이 있다.

• 빠른 재전송
  • 패킷을 받는 입장에서는 분할된 내용이 순서대로 도착할 수 없다. 이러한 상황이 발생하면 수신측은 문제 패킷의 시퀀스 번호와 함께 ACK 패킷을 전송합니다.
  • 이러한 중복 ACK가 세 번 수신되면 재전송이 발생합니다.
  • 또한 정체 상황이 발생했다고 판단하여 정체를 감지하고 윈도우 크기를 줄인다.

• 빠른 회복
  • 과부하가 걸리면 창 크기를 1로 줄이는 대신 반으로 줄이고 선형으로 늘립니다.
  • 일회성 과부하 후 AIMD 모드에서 작동합니다.

TCP 대 UDP

먼저 TCP와 UDP의 배경을 간단히 살펴보면 다음과 같다.

• IP는 호스트에서 호스트로 **기기**에서 **기기**까지만 지원합니다. 따라서 한 장치 내에서 여러 프로그램이 통신할 때 IP 포트 번호의 출생 배경에 대한 제한만 있을 뿐입니다.
• IP 오류가 발생하면 ICMP에서 알려줍니다. ICMP는 알려주기만 하고 처리할 수 없기 때문에 IP를 통해 처리해야 합니다.

TCP 대 UDP

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

사용자 데이터그램 로그

• 전송 계층에서 사용하는 프로토콜
• 비연결 프로토콜
• 신뢰할 수 없는 전송 프로토콜
  • 배송 주문 보증 X
  • 흐름 제어 X, 오류 제어 X, 손상된 세그먼트에 대한 재전송 X
  • 사용자 프로세스의 모든 부분
• 데이터그램의 데이터 처리
  • 연결에 할당된 논리적 경로가 없습니다.
  • 따라서 각 패킷은 서로 다른 경로를 통해 전송되며 독립적인 관계를 갖습니다.
  • 즉, 데이터는 서로 다른 경로에서 독립적으로 처리됩니다.
• 속도(데이터 처리)가 빠름
  • 신뢰성보다 연속성이 중요한 서비스에 사용
  • 예) 스트리밍, 스피치, 멀티미디어…
• MTU 크기에 따라 데이터를 분리하여 전송하면 데이터를 의미 있는 단위로 나누어 전송합니다.
• 헤더 체크섬 필드를 통한 최소한의 오류 감지

전송 제어 프로토콜(TCP):

전송 제어 프로토콜

• 전송 계층에서 사용하는 프로토콜
• 연결 방식 프로토콜(1:1 통신)
• 신뢰성이 보장된 프로토콜
  • 보장된 전송 순서 O
  • 흐름 제어 및 혼잡 제어 제공
  • 손상된 세그먼트에 대한 재전송 제공
• 가상 회선에 대한 방법 제공
  • 연결 설정(세 손 흔들기)
  • 이별(4악수)
• IP와 함께 사용
  • IP: 데이터 전달
  • TCP: 패킷 추적 및 관리
• UDP보다 느림
  • 연속성보다 안정성이 더 중요한 서비스에 사용
  • 멀티캐스팅 또는 브로드캐스팅 지원 X
• MTU 크기에 따라 데이터를 분리하여 전송하면 데이터를 ByteStream으로 분리하여 처리합니다.

* 참고: MTU(Maximum Transmission Unit): 최대 전송 단위

UDP와 TCP는 각각 별도의 포트 주소 공간을 관리하므로 동일한 포트 번호를 사용해도 좋습니다. 즉, 두 프로토콜에 동일한 포트 번호가 할당되더라도 서로 다른 포트로 간주됩니다.

함께

• 포트 번호를 사용하여 주소 지정
• 데이터 오류 검사를 위해 헤더에 체크섬 필드가 있습니다.

차이점

DNS가 UDP를 사용하는 이유

DNS는 애플리케이션 계층 프로토콜로 TCP 또는 UDP를 사용해야 합니다. DNS는 안정적으로 보이지만 UDP를 사용하는 이유는 무엇입니까?

DNS는 데이터 교환을 의미하며, 이 경우 TCP를 사용할 경우 데이터가 전송되기까지 다음과 같은 시간이 소요됩니다.

• 세션 설정 처리
• 보낸 데이터가 제대로 수신되었는지 확인하는 과정

프로토콜 오버헤드가 UDP보다 큽니다!

그리고 다음과 같은 이유로 UDP를 사용하는 것이 훨씬 더 효율적입니다.

• DNS 쿼리 집합은 UDP 세그먼트에 맞을 만큼 충분히 작습니다.
• UDP는 3방향 핸드셰이크를 사용할 필요가 없으며 연결 X를 유지할 필요가 없습니다.
• 요청 누출은 애플리케이션 수준에서 제어할 수 있습니다.
  • 애플리케이션 계층에서 타임아웃 추가 또는 재전송 작업으로 제어 가능

그러나 TCP를 사용하는 경우가 있습니다.

• 영역 전송을 사용하는 경우
  • Zone Transfer: DNS 서버간 요청 송수신 시 사용하는 Transfer
• 데이터 크기가 512바이트를 초과하는 경우(UDP 제한)
• 답변을 받지 못한 경우

참고 자료