[네트워크] TCP와 UDP (3-way handshake)

 

보기 전 참고 : OSI 7계층 - 4계층 : 전송 계층 (Transport Layer)

[네트워크] OSI 7계층과 TCP/IP

 

앞에서 배웠던 2, 3계층은 목적지를 정확히 찾아가기 위한 주소 제공이 목적이었지만, 4계층에서 동작하는 프로토콜은 만들어진 목적이 조금 다르다.

목적지 단말 안에서 동작하는 여러 애플리케이선 프로세스 중 통신해야 할 목적지 프로세스를 정확히 찾아가고 패킷 순서가 바뀌지 않도록 잘 조합해 원래 데이터를 만들어내는 것이 4계층 프로토콜의 역할

이제 TCP와 UDP 프로토콜에 대해서 알아보도록 하자. 

1. 4계층 프로토콜(TCP, UDP)과 서비스 포트

OSI 7계층에서 다루었던 것처럼, 데이터를 주고받는 인캡슐레이션과 디캡슐레이션 과정에서 각 계층을 정의하는 헤더가 추가되고, 여기엔 여러 정보가 들어간다.

그 중 가장 중요한 두 가지 정보는 각 계층에서 정의하는 정보, 상위 프로토콜 지시자 정보이다.

• 각 계층에서 정의하는 정보
  • 수신 측의 동일 계층에서 사용하기 위한 정보
  • ex) 송신측에서 추가한 2계층 혜더의 MAC 주소 정보는 수신 측의 2계층에서 학인하고 사용
  • ex) 송신 측에서 추가한 3계층 IP 주소는 수신 측 3계층에서 사용
  • 4계층에서는 이런 정보로 시퀸스 번호(Seq Number), ACK 번호를 사용
• 상위 프로토콜 지시자 정보
  • 디캡슐레이션 과정에서 상위 계층의 프로토콜이나 프로세스를 정확히 찾아가기 위한 목적
  • 2계층 : 이더 타입 (ex: 0x0800(IP))
  • 3계층: 프로토콜 번호 (ex: 6(TCP))
  • 4계층: 포트 번호 (ex: 80(HTTP), 443(HTTPS), 13959, ... )

각 계층에서 정의하는 정보와 상위 프로토콜 지시자

전송 계층의 목적은

1. 애플리케이션에서 사용하는 프로세스를 정확히 찾아가고
2. 데이터를 분할한 패킷을 잘 쪼개 보내고
3. 잘 조립하는 것.

이를 TCP와 UDP가 담당하며, 패킷 분할과 조립을 위해 TCP 프로토콜에서는 시퀸스 번호와 ACK 번호를 사용한다.

 

---

TCP vs UDP?

이 둘에 대해 자세히 알아보기 전에, 간단히 개념을 정리하고 가보려고 한다.

둘 다 4계층에서 사용하는 프로토콜이라고는 하지만, 4계층 특징인 신뢰성, 연결 지향성 등은 TCP에만 있고 UDP에는 없다.

간단히 비유하자면 TCP는 택배, UDP는 우편이라고 생각하면 된다.

택배는 발신자가 보낼 준비하는 순간부터 운송장이 찍히고 수신자에게 알려진다. 그리고 움직이는 경유지마다 언제, 어디까지 도착해서 어느쪽으로 오고있는지 우리가 알 수 있으며, 필요하면 담당자에게 연락도 할 수 있다.
그래서 안전하게 도착해야 하고, 받지 못할 경우 큰 문제가 생기는 경우에는 당연히 택배(소포)를 사용한다.

우편은 발신자가 보내는 순간 우리의 손을 떠나버린다. 발신자도, 수신자도 우편이 지금 어디까지 갔는지 알 수 없다. 아직 도착하지 않은 건지, 유실된 건지도 알 수 없다.
그러나 가벼운 물품을 다수에게 보낼 때는 택배보다는 우편이 더 저렴하기 때문에, 이런 경우에 도착 여부가 중요하지 않다면 발신자 입장에선 우편을 사용하는 쪽이 효율적일 것이다.

이러한 개념을 한 번 정리하고, 이제 이들에 대해 더 자세히 알아보자!

---

2. TCP(Transmission Control Protocol, 전송 제어 프로토콜)

TCP는 위에서 다룬 4계층의 특징을 대부분 포함하고 있다.

• 신뢰성
  
  • 안전한 세션 연결
  • 데이터 분할
  • ACK Number(Acknowledge Number) : 분할된 패킷 전송 여부 확인 - 잘 전송되었는지에 대한 응답
  • 👉🏻 신뢰할 수 없는 공용망에서도 정보유실 없는 통신 보장
• 순서제어
  • 패킷에 번호(Sequence Number)를 부여해 전송 상태 확인
• 흐름제어
  • 전송 크기(Window Size)를 고려해 통신 (한 번에 얼마나 보내야 수신자가 잘 처리할 수 있는지)

👉🏻 여러 역할 덕분에 네트워크 상태를 크게 고려하지 않고, 특별한 개발 없이 쉽고 안전하게 네트워크 사용이 가능

2-1. 패킷 순서, 응답 번호

시퀀스 번호와 ACK 번호의 기본 동작 방식

• 분할된 패킷을 잘 분할하고 수신 측이 잘 조합하도록 패킷에 순서와 응답 번호를 부여한다.
  
  • Seq no(시퀀스 번호) : 패킷에 순서를 부여하는 것
  • ACK Number(ACK 번호) : 응답 번호를 부여하는 것
• 두 번호(Seq, ACK) 를 이용해 패킷의 순서가 바뀌거나 중간에 손실된 패킷을 파악할 수 있다.
• 송신자가 번호를 부여해 보낸다. 수신자는 받아서 번호 순서를 확인하고, 그 다음 번호를 요청한다.
• 송신측에서 ACK 번호를 수신받으면 확인 후 다음 패킷에 번호를 부여해 송신한다. 

이걸 좀 더 자세히 살펴보자.

시퀀스 번호, ACK 번호도 양방향으로 함께 동작

1. 출발지에서 시퀀스 번호를 0으로 보낸다(SEQ=0) : "0번째 보낼 거야"
2. 수신측에선 0번 패킷을 잘 받았다는 표시로 응답 번호(ACK)에 1을 적어 응답한다. 이때 수신측에서는 자신이 처음 보내는 패킷이므로 자신의 패킷에 시퀀스 번호 0을 부여한다. : "0번째 받았고, 이제 1번째 내놔"
3. 송신측은 수신측에서 보낸 ACK번호로 받은 1번 (1번 패킷)을 시퀀스 번호로 작성하고 ACK번호는 상대방의 0번 시퀀스를 잘 받았다는 의미로 시퀀스 번호를 1로 부여해 다시 송신한다. "0번째 받은 거 확인, 이제 1번째 보낼 거야"

2-2. 윈도 사이즈와 슬라이싱 윈도

• 윈도 사이즈 : 한 번에 받을 수 있는 데이터의 크기
• 슬라이싱 윈도 : 네트워크 상황에 따라 윈도 사이즈를 조절하는 것

TCP는 일방적으로 패킷을 보내는 것이 아니라 상대방이 잘 받았는지 확인하기 위해 ACK 번호를 확인하고 다음 패킷을 전송한다.
패킷이 잘 전송되있는지 확인하기 위해 별도 패킷을 받는 것 자체도 통신 시간을 늘리고, 송신자와 수신자가 먼 거리에 떨어저 있으면 왕복 지연시간(Round Trip Time, RTT)이 늘어나 응답을 기다리는 시간이 더 길어진다.

작은 패킷을 하나 보내고 응답을 받아야만 하나를 더 보낼 수 있다면 모든 데이터를 전송하는 데 긴 시간이 걸리기 때문에, 데이터를 보낼 때 패킷을 하나만 보내는 것이 아니라 많은 패킷을 한꺼번에 보내고 응답을 하나만 받는다.

가능하면 최대한 많은 패킷을 한꺼번에 보내는 것이 효율적이지만 네트워크 상태가 안 좋으면 패킷 유실 가능성이 커지므로 적절한 송신량을 결정해야 하는데, 이 때 슬라이싱 윈도를 수행해 윈도 사이즈를 조절한다.

TCP 윈도 사이즈

TCP 헤더에서 윈도사이즈로 표현할 수 있는 최대 크기는 2¹⁶이다. 이는 64k만큼 윈도사이즈를 가질 수 있다는 의미지만, 회선의 안정성이 높아지고 고속화되는 현대 네트워크에서는 너무 작은 숫자이다.

그래서 이를 해결하기 위해 TCP 헤더 사이즈를 늘리지 않고 뒤의 숫자를 무시하는 방법으로 윈도 사이즈를 증가시켜 통신한다. 이런 방식을 사용하면 기존 숫자의 10배, 100배로 윈도 사이즈가 커진다. 

만약 TCP에서 패킷 유실이 발생한다면?

윈도 사이즈를 절반으로 낮추고 정상적인 통신이 되는 경우 서서히 원래 사이즈로 늘린다. 이 때 네트워크 경합이 발생해서 패킷 유실이 생기면 작아진 윈도 사이즈로 인해 회선을 제대로 사용하지 못하는 경우가 생길 수 있는데, 이를 해결하기 위해 회선 속도 증가, 버퍼가 큰 네트워크 장비 사용 또는 TCP 최적화 솔루션을 통해 문제를 해결(혹은 최소화)할 수 있다.

2-3. 3-Way Handshake

TCP에서는 본격적인 통신을 하기 전 사전 연결작업을 진행한다. 

수신자가 아직 데이터를 받을 수 있는 준비가 안 되어있을 때 일방적으로 데이터를 송신하게 되면 해당 데이터는 처리가 불가능하므로 폐기될 수밖에 없다. 

TCP 프로토콜은 이러한 상황을 방지하기 위해 본격적인 통신 전 데이터를 주고받을 준비가 되있는지 미리 확인하는 작업을 거친다. 

이 때 세 번의 패킷을 주고 받으면서 통신을 서로 준비하는데 이를 3-way handshake라 부른다.

3-way handshake

LISTEN : 서버에서 서비스를 제공하기 위해 클라이언트 접속을 받아들일 수 있는 상태
SYN-SENT : 클라이언트에서 SYN 패킷을 보내는 상태 
SYN-RECEIVE : 클라이언트의 SYN 패킷을 받은 서버의 상태
ESTABLISHED
    - 클라이언트 : 서버로부터 SYN, ACK 응답받은 상태
    - 서버 : 클라이언트로부터 ACK 응답받은 상태

위 그림에 따라 3-way handshake 를 순서대로 살펴보자.

1. 서버는 서비스를 제공하기 위해 클라이언트의 접속을 받아들일 수 있는 LISTEN 상태로 대기.
2. 클라이언트에서는 통신을 시도하며 SYN 패킷을 보냄. : SYN-SENT 상태.
   
   • 서버에서 클라이언트의 SYN 패킷을 받으면 SYN-RECEIVE 상태로 변경
   • 클라이언트에게 SYN, ACK을 보내 응답.
3. 클라이언트는 이 응답(SYN, ACK)을 받으면 ESTABLISHED 상태로 변경됨.
   
   • 클라이언트는 서버에게 이에 대한 응답(ACK)을 다시 보냄.  
   • 서버도 이 응답을 받고 ESTABLISHED상태로 변경됨.
   • 클라이언트와 서버 양 측이 모두 ESTABLISHED 상태가 되었다 👉🏻 연결이 성공적으로 완료되었음

플래그(Flag)

3-way handshake 과정이 생기다보니 기존 통신과 새로운 통신을 구분해야 했다.

어떤 패킷이 새로운 연결 시도인지, 기존 통신에 대한 응답인지 구분하기 위해 헤더에 플래그(Flag)라는 값을 넣어 통신한다.

TCP 헤더

TCP 플래그는 총 6가지로, 통신의 성질을 나타낸다. (초기 연결, 응답, 정상 종료, 비정상종료 등의 용도)

• SYN(Synchronization:동기화)
  • 연결 시작 용도로 사용
  • 연결이 시작될 때 SYN 플래그에 1로 표시해 보냄

• ACK(Acknowledgement)
  • ACK 번호가 유효할 경우 1로 표시해 보낸다. 
  • 초기 SYN이 아닌 모든 패킷은 기존 메세지에 대한 응답이므로 ACK 플래그가 1로 표기된다.
• FIN(Finish) 
  • 연결 종료 시 1로 표시
  • 데이터 전송을 마친 후 정상적으로 양방향 종료 시 사용
• RST(Reset)
  
  • 연결 종료 시 1로 표시.
  • 연결 강제 종료를 위해 연결을 일방적으로 끊을 때 사용
• UGR(Urgent)
  • 긴급 데이터인 경우 사용, 1로 표시
• PSH(Push)
  • 서버측에서 전송할 데이터가 없거나 데이터를 버퍼링 없이 응용 프로그램으로 즉시 전달 할 것을 지시할 때 사용.

3-way handshake 과정

3-way handshake 과정

1. 통신 최초 시도시 송신자는 플래그에 있는 SYN 필드를 1로 표기하고 seq 번호를 적어 보낸다. 
2. SYN 패킷을 받은 수신자는 SYN, ACK 비트를 플래그에 1로 표기해 응답한다. 
   
   • 수신자가 보내는 첫 패킷이므로 SYN은 1
   • 기존 송신자의 응답이기도 하므로 ACK 비트도 함께 1로 표기
   • 이때 ACK 번호는 송신자가 보낸 seq 번호에 1을 추가한 값을 넣어 응답. (seq 번호로 10을 받았으니 다음 11번을 달라 👉🏻 ACK 번호는 11 )
3. 수신자의 응답(SYN, ACK)을 받은 송신자는 연결을 확립하기 위해 다시 응답을 보낸다.
   
   • 이때는 기존 메세지의 응답이므로 ACK 필드만 1로 표기.
   • 수신자가 seq 번호를 20으로 보냈기 때문에 송신자의 ACK 번호는 21

3. UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)

맨 처음에 설명했던 대로 UDP는 TCP와는 다르게 4계층 프로콜이 가져야 할 특징이 거의 없다. 

신뢰성, 연결지향, 전송 보장 등이 없기 때문에 UDP 헤더는 비교적 심플하며 내용이 거의 없다. 

UDP 헤더

TCP 헤더에 있던 내용들(시퀀스 번호, ACK 번호, 플래그 윈도 사이즈 등)이 없음.

이처럼 UDP는 신뢰성을 가지기 위해 필요한 정보가 없는 프로토콜이므로 제한된 용도로만 사용된다. 

UDP의 용도

• 음성 데이터나 실시간 스트리밍
  
  • 시간에 민감한 프로토콜(실시간성 보장)이나 애플리케이션을 사용하는 경우 UDP 프로토콜이 사용된다.
• 단방향으로 다수의 단말과 통신하며 응답을 받기 어려운 환경
  • EX: 사내 방송, 증권 시세 데이터 전송

즉, 신뢰성보다는 일부 데이터가 유실되더라도 시간에 맞춰서 계속 전송하는것이 중요한 시스템에서 UDP를 사용하게 된다. 

특징

• UDP는 사전에 연결을 확립하는 과정(3-way handshake 같은)이 없다. 대신 UDP의 첫 데이터는 리소스 확보를 위해 인터럽트(Interrupt)를 거는 용도로 사용되고 유실. 
• UDP 프로토콜을 사용하는 앱 대부분은 이런 상황을 인지하고 동작. 
• 또는 연결 확립에 TCP 프로토콜을 이용해 앱끼리 모든 준비를 마친 후 실제 데이터만 UDP를 이용하는 경우가 대부분임.

 

---

참고

⌜IT 엔지니어를 위한 네트워크 입문⌟ 길벗, 2023
[3장] 네트워크 통신하기 | 3.4 TCP와 UDP (p.98~111)

* 책을 참고해 필요한 내용을 정리한 것이므로, 책의 내용과 다를 수 있습니다.