[Computer Science] 5주차 스터디 - TCP/IP(흐름제어, 혼잡제어, 3way handshake, 4way handshake) , TCP VS UDP

TCP/IP (흐름/혼잡 제어, 3-way/4-way handshake)

TCP/IP

TCP와 IP의 개념에 대해서 먼저 알아보자!

TCP/IP는 OSI 7계층 에서 3계층과 4계층을 다루는 프로토콜(통신 규약)이다. TCP/IP는 패킷 통신 방식의 인터넷 프로토콜인 IP와 전송 조절 프로토콜인 TCP로 이루어져 있다.

• IP
  • OSI 7계층에서 3계층(Network Layer)
  • 한 EndPoint가 다른 EndPoint로 가고자 하는 경우 경로와 목적지를 찾아줌 = Routing
  • 패킷 전달 여부 보증 X
  • 패킷을 보낸 순서와 받는 순서가 다를 수 있음
• TCP
  • OSI 7계층에서 4계층(Transport Layer)
  • 송신자와 수신자의 논리적 연결(Connection)을 담당, 신뢰성 있는 연결 유지하도록 도움
  • IP위에서 동작하는 프로토콜
  • 데이터의 전달 여부와 전송 순서 보장
  • HTTP, HTTPS, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 애플리케이션 프로토콜 존재

즉, TCP/IP는 TCP와 IP를 합쳐 부르는 말로 TCP/IP를 사용한다는 것은 IP주소 체계를 따르고 IP Routing을 이용해 목적지에 도달하며 TCP의 특성을 활용해 송신자와 수신자의 논리적 연결을 생성하고 신뢰성을 유지할 수 있도록 하겠다는 것을 의미한다.

TCP/IP를 말한다는 것은 송신자가 수신자에게 IP주소를 사용하여 데이터를 전달하고 데이터가 제대로 전송 되었는지, 너무 빠르지는 않는지, 제대로 받았다고 연락이 오는 지에 대한 이야기!

TCP

TCP는 위에서 말한 것처럼 데이터를 안정적으로 모두 보내는 것을 가장 중요시 한다. 데이터를 안정적으로 보내기 위해 필요한 정보들을 TCP Header에 담아서 전달한다.

SYN, ACK, FIN, RST, Source Port, DEstination Port, Sequence Number, Window size, Checksum과 같은 정보를 전달하는데 이는 신뢰성 보장과 흐름 제어, 혼잡 제어에 관여할 수 있는 요소들도 포함되어 있다.

TCP는 이 정보들을 기반으로 상대와 신뢰성 있는 연결을 맺고 데이터를 전송하는데 그 때 하는 행동이 있다. 이 행동이 바로 3-way handshake이다.

 

3-way handshake, 4-way handshake

신뢰성 있는 통신이란 무엇일까?

• 송신자와 수신자가 데이터를 전송하기 전 서로 통신 가능 여부 확인
• 한 번에 받을 수 있는 데이터의 양 확인
• ….

➡️ 이 과정이 바로 3-way handshake!

자세히 말하면 연결을 성립하는 과정이 3-way handshake이고 연결을 해제하는 과정이 4-way handshake이다.

3-way handshake

목적:

양쪽 모두 데이터를 주고받을 준비가 되었다는 것을 보장하고 실제로 데이터 전달이 시작하기 전에 한 쪽이 다른 쪽이 준비되었다는 것을 알 수 있도록 하기 위해

위의 과정을 TCP header의 정보를 이용하여 진행하는 것이 3-way handshake이고 아래 그림과 같다.

• 송신자가 수신자에게 SYN을 보내 통신이 가능한지 확인
  • 송신자가 최초로 데이터를 전송할 때 Sequence Number를 임의의 랜덤 숫자로 지정
  • SYN플래그 비트를 1로 설정한 Segment전송
  • Port 상태
    • Host A : CLOSED
    • Server : LISTEN
• 수신자가 SYN을 받고 SYN/ACK를 송신자에게 전송하여 통신할 준비가 되었음을 알림
  • 접속 요청을 받은 Server가 요청을 수락 + 송신자인 Host A도 Port를 열어 달라는 메세지 전송 (SYN + ACK)
  • Port 상태
    • Host A : CLOSED
    • Server : SYN_RCV
• 송신자가 수신자의 SYN/ACK를 받고 ACK를 날려 전송 시작을 알림
  • 마지막으로 송신자 Host A가 수락 확인을 보내 연결을 맺음 (ACK)
  • 이때 전송할 데이터가 있다면 이 단계에서 데이터 전송 가능
  • Port 상태
    • Host A : ESTABLISHED
    • Server : ESTABLISHED

TCP를 이용하여 통신하는 응용 프로그램이 데이터를 전송하기 전 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정

 

4-way handshake

목적:

상대방 컴퓨터와 연결했던 세션을 안전하게 종료하기 위해

• 송신자가 수신자에게 FIN 플래그를 전송하여 연결 종료를 알림
  • Host A가 FIN 플래그를 전송하는데 Host B가 FIN 플래그로 똑같이 응답하기 전까지 연결 계속 유지
  • Port 상태
    • Host A : FIN_WALT1
    • Host B : ESTABLISHED
• 수신자가 FIN 플래그를 전달 받으면 응답 패킷 ACK 전달
  • Host B는 일단 확인 메시지 ACK를 보내고 자신의 통신이 끝날 때까지 기다림
  • 전송할 데이터가 남아 있다면 이어서 계속 전송
  • Host A는 Host B에게 첫 FIN 플래그에 대한 ACK를 받은 상태로 Host B가 보내는 두 번째 FIN 플래그를 기다림
  • Port 상태
    • Host A : FIN_WALT2
    • Host B : CLOSE_WAIT
• 수신자가 연결 종료를 위해 송신자에게 FIN 플래그 전송
  • Host B가 통신을 마치고 연결을 종료할 준비가 되면 연결 해지를 위한 준비가 되었음을 알리기 위해 FIN 플래그 전송하고 Host A의 응답을 기다림
  • Port 상태
    • Host A : FIN_WALT2
    • Host B : LAST_ACK
• 송신자는 수신자에게 확인 응답 ACK를 보내고 얼마 뒤 세션 종료됨
  • Host A는 Host B에게서 FIN 플래그를 받은 후 확인 응답인 ACK를 보내면서 TIME_WAIT상태가 됨
  • Host B는 Host A에게 ACK를 받으면 그대로 종료
  • Host B에게서 응답이 없다면 Host A도 종
  • Port 상태
    • Host A : TIME_WAIT → CLOSED
    • Host B : CLOSED

Host A가 바로 CLOSED 되지 않는 이유?
만약 Host B가 FIN 플래그를 ****전송하기 전에 보낸 패킷이 여러 가지 이유(Routing 지연, 패킷 유실…)로 FIN 패킷보다 늦게 도착하게 되었을 때 Host A가 이미 CLOSED 된 상태라면 이 패킷은 Drop되고 데이터가 유실될 것이다. 따라서 이러한 일을 대비하여 FIN 플래그를 수신하더라도 일정 시간(default 240초)동안 세션을 유지하고 잉여 패킷을 기다리는 과정을 거치게 되고 이 과정을 TIME_WAIT이라고 한다.

 

흐름 제어와 혼잡 제어

TCP는 흐름 제어 기능과 혼잡 제어 기능이 있는데 이 기능들 덕분에 신뢰성 있는 통신을 유지할 수 있다.

흐름 제어

송신자와 수신자의 데이터 처리 속도 차이를 해결하기 위한 기법

Host - Host(End to End) : Host 사이의 패킷 수 제어

• 수신자 측 속도 > 송신자 측 속도 ➡️ 문제 없음
• 수신자 측 속도 < 송신자 측 속도 ➡️ 문제 발생❗

수신자 측에서 데이터를 처리하는 속도보다 송신자 측에서 보내는 데이터의 속도가 더 빠르다면 수신자 측에서 제한된 저장 용량(일반적으로 큐)을 초과하여 데이터 손실 문제를 가져올 수 있다. 따라서 이러한 사태의 발생을 막기 위해 강제로 송신자 측의 데이터 전송을 줄여야 한다.

• Stop and Wait 방식 
  • 패킷을 하나씩 보내기 때문에 비효율적인 방법
  • 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
• Sliding Window 기법
  • 수신자 측이 한 번에 처리할 수 있는 데이터의 양(Window 크기)을 3-way handshake할 때 송신자 측에 전달한다. 통신 과정 중에도 네트워크 혼잡 등의 조건을 통해 Window 크기를 유동적으로 설정 가능하다. 수신자 측에서 송신자 측으로 확인 응답(ACK)를 보낼 때 TCP Header에 담아서 보내면 된다.
  • 동작 방식은 다음과 같다. 윈도우에 포함된 패킷을 계속 전송하고 수신자 측으로부터 확인 응답(ACK)이 오면 윈도우를 옆으로 옮겨 다음 패킷들을 전송한다. 이후 데이터를 다 받을 때까지 위 과정을 반복한다.

혼잡 제어

송신자 측의 데이터 전달과 네트워크 처리 속도 차이를 해결하기 위한 기법

Host - 네트워크 : 네트워크 내의 패킷 수 제어하여 오버플로우 방지

• 송신자 측의 데이터 지역망과 인터넷으로 연결된 대형 네트워크를 통해 전달
• 만약 한 라우터에 데이터가 몰릴 경우(Congestion) 데이터를 모두 처리하는 것은 불가능

라우터가 자신에게 온 데이터를 모두 처리하지 못한다면 Host들은 재전송을 해야 하고 혼잡을 가중시켜 오버플로우 혹은 데이터 손실이 발생할 수 있다. 따라서 이러한 네트워크의 혼잡을 피하기 위해 송신자 측에서 보내는 데이터의 전송 속도를 강제로 줄여야 한다.

• AIMD(Additive Increase / Multiplicative Decrease)
  • 직역하면 합 증가/곱 감소 방식이다.
  • 처음에 패킷을 하나씩 보냄
  • 문제 없이 도착 : 윈도우의 크기를 1씩 증가시키며 전송
  • 전송 실패 : 윈도우 크기를 반으로 줄임
  • 네트워크에 늦게 들어온 호스트가 처음에는 불리하지만 시간이 흐르면서 평형 상태로 수렴
  • 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 오래 걸릴 수 있다는 단점이 있다.
  • 또한, 네트워크가 혼잡해지는 상황을 미리 감지하지 못하여 네트워크가 혼잡해지고 나서야 대역폭을 줄인다.

 

• Slow Start(느린 시작)
  • 위의 AIMD방식이 윈도우 크기를 선형적으로 증가시키기 때문에 제대로 된 네트워크 속도가 나오기까지 시간이 오래 걸린다. 따라서 Slow Start는 지수적으로 윈도우 크기를 증가시킨다.
  • 보낸 데이터의 ACK가 도착할 때마다 윈도우 크기 증가시켜 한 주기가 지나면 최종 윈도우 크기는 2배가 됨
  • 혼잡 현상 발생 : 윈도우 크기를 1로 줄임
  • 그 후 다시 혼잡 현상이 발생했던 윈도우 크기의 절반까지는 전처럼 창 크기를 2배씩 증가시키고 그 이후부터는 완만하게 1씩 증가시킴
  • 이 방법은 처음에는 윈도우의 크기가 조금 느리게 증가할 수 있지만 시간이 가면 갈수록 윈도우 크기가 점점 빠르게 증가한다는 장점이 있다.

 

• Fast Retransmit(빠른 재전송)
  
  • 패킷을 받는 입장에서 세그먼트로 분할된 내용이 순서대로 도착하지 않을 수도 있다. 이런 상황이 발생한다면 수신자 측에서는 문제가 되는 패킷의 순번을 ACK 패킷에 실어서 보낸다.
  • 이런 중복 ACK를 3개를 받으면 재전송이 이루어진다.
  • 또한, 혼잡한 상황이 일어난 것으로 판단하여 혼잡을 감지하고 윈도우 크기를 줄이게 된다.

 

• Fast Recovery(빠른 회복)
  • 혼잡한 상태가 되면 윈도우 크기를 1로 줄이지 않고 반으로 줄이고 선형증가 시키는 방법이다.
  • 혼잡 상황을 한번 겪은 후에는 AIMD방식으로 동작한다.

 

 

TCP vs UDP

먼저 TCP와 UDP가 나오게 된 배경을 간단히 살펴보면 다음과 같다.

• IP는 Host to Host로 **장치** to **장치**만을 지원한다. 따라서 하나의 장비 안에서 여러 프로그램들이 통신을 할 경우에는 IP만으로 한계가 있다 ➡️ Port 번호 탄생 배경
• IP에서 오류가 발생한다면 ICMP에서 알려준다. ICMP는 알려주기만 할 뿐 대처를 못하기 때문에 IP보다 위에서 처리를 해줘야 한다  ➡️ IP보다 상위 프로토콜인 TCP/UDP 탄생 배경

TCP vs UDP

UDP(User Datagram Protocol) :

사용자 데이터그램 프로토콜

• 전송 계층에서 사용하는 프로토콜
• 비연결형 프로토콜
• 신뢰성이 없는 전송 프로토콜 
  • 전송 순서 보장 X
  • 흐름 제어 X, 오류 제어 X, 손상된 세그먼트에 대한 재전송 X
  • ➡️ 모두 사용자 프로세스의 몫
• 데이터를 데이터그램 단위로 처리
  • 연결을 위해 할당되는 논리적 경로 없음
  • 따라서 각 패킷이 다른 경로로 전송되고 독립적인 관계
  • 즉, 데이터를 서로 다른 경로로 독립적으로 처리
• 속도(데이터의 처리)가 빠름
  • 신뢰성보다 연속성이 중요한 서비스에 사용
  • Ex) 스트리밍, 음성, 멀티미디어…
• MTU사이즈에 맞게 데이터를 분리해서 보낼 때 데이터를 의미있는 단위로 분리해서 전송
• Header의 Checksum 필드를 통해 최소한의 오류만 검출

 

TCP(Transmission Control Protocol) :

전송 제어 프로토콜

• 전송 계층에서 사용하는 프로토콜
• 연결형 프로토콜 (1:1 통신)
• 신뢰성이 보장되는 프로토콜
  • 전송 순서 보장 O
  • 흐름 제어 및 혼잡 제어 제공
  • 손상된 세그먼트에 대한 재전송 제공
• 가상 회선 방식 제공
  • 연결의 설정(3-hand-shaking)
  • 연결의 해제(4-hand-shaking)
• IP와 함께 사용
  • IP : 데이터의 배달
  • TCP : 패킷 추적 및 관리
• 속도가 UDP보다 느림
  • 연속성보다 신뢰성이 중요한 서비스에 사용
  • 멀티캐스팅이나 브로드캐스팅 지원 X
• MTU사이즈에 맞게 데이터를 분리해서 보낼 때 데이터를 ByteStream으로 분리 후 처리

 

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

UDP와 TCP는 각각 별도의 포트 주소 공간을 관리하므로 같은 포트 번호를 사용해도 무방하다. 즉, 두 프로토콜에서 동일한 포트 번호를 할당해도 서로 다른 포트로 간주한다.

 

공통점

• 포트 번호를 이용하여 주소를 지정
• 데이터 오류 검사를 위한 Checksum필드가 Header에 존

차이점

 

DNS에서 UDP를 사용하는 이유

DNS는 Application layer protocol로 TCP나 UDP중 하나를 사용해야 한다. DNS라면 reliable해야할 것 같은데 왜 UDP를 사용할까?

DNS는 데이터를 교환하는 경우인데 이때 TCP를 사용한다면 데이터를 송신할 때까지 다음의 시간이 소요된다.

• 세션 확립을 위한 처리
• 송신한 데이터가 수신되었는지 점검하는 과정

➡️ Protocol Overhead가 UDP에 비해 크다!

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

• DNS의 Request 양은 UDP segment에 들어갈 정도로 작음
• UDP는 3-way handshake를 사용하지 않아도 되고 연결을 유지할 필요 X
• Request에 대한 손실은 Application Layer에서 제어가 가능
  • Application Layer에서 Timeout추가 혹은 resend작업을 통해 제어 가능

 

그러나 TCP를 사용할 때가 있다.

• Zone transfer를 사용해야 하는 경우
  • Zone transfer : DNS 서버 간의 요청을 주고 받을 때 사용하는 transfer
• 데이터 크기가 512bytes(UDP 제한)이 넘을 때
• 응답을 못 받은 경우

 

 

 

참고 자료

https://m.blog.naver.com/PostView.nhn?blogId=minki0127&logNo=220804490550&proxyReferer=https://www.google.com/ 

TCP 와 UDP [동작원리/헤더/차이점]

https://velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4

TCP 와 UDP 차이를 자세히 알아보자

https://bangu4.tistory.com/74

[네트워크] 3-way / 4-way Handshake 란?

https://sh-safer.tistory.com/146

[TCP] 4-way Handshake란? / 와이어샤크, tcpdump 확인

https://aws-hyoh.tistory.com/entry/TCPIP-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

TCP/IP 쉽게 이해하기

https://jsonsang2.tistory.com/17

흐름제어(Flow control)과 혼잡제어(Congestion control)

https://benlee73.tistory.com/186

TCP 의 흐름 제어 / 오류 제어 / 혼잡 제어

https://steady-coding.tistory.com/507

[네트워크] TCP/IP 흐름 제어 & 혼잡 제어