TCP와 UDP 알아보기

프로토콜이란?

위의 그림은 인터넷으로 통신을 하는데 있어서의 계층 별로 나타낸 프로토콜의 모음이다.
전송 계층에 속하는 TCP, UDP는 이름에서 알다시피 전자 기기인 호스트 간의 데이터 전송 조율을 담당하는 계층이다. 
 
브라우저로 인터넷을 하다보면 어떻게 서버와 연결이 맺어지고 해당 데이터를 가지고 오는지 궁금해질 때가 있다. 내가 요청한 웹사이트나 데이터에 대해서 요청 메시지를 보내면 서버는 어떻게 해당 요청 메시지를 분석하고 처리하여 우리에게 응답 메시지와 함께 데이터를 줄 수 있는 것일까? 전자 기기는 스스로 생각하여 일을 처리할 수 없기 때문에 특정 규칙에 따라서 특정 포맷과 타입의 메시지에는 어떤 응답 메시지를 보내는지 정해져 있어야만 한다. 따라서, 전자 기기간의 통신을 위해서는 일련의 규칙이나 표준이 있어야만 서로 통신을 주고 받을 수 있다. 이를 프로토콜 이라고 한다.
 
 
 
 

---

TCP

특징

TCP는 크게 4가지의 특징을 가진다.
 
 

1. 신뢰성

인터넷 통신을 사용하다 보면 패킷이 손실되거나, 중복된 메시지가 오거나, 네트워크 계층에서 메시지 순서가 바뀌어 전송이 되는 등 다양한 변수가 일어날 수 있다. 이러한 변수들에 대해서 메시지의 신뢰성을 높이기 위해 TCP는 여러가지 기법을 통해 신뢰성을 높인다.
 
 
TCP Segment 순서가 뒤바뀌었다면?
각각의 TCP Segment는 Sequence Number를 가지고 있기 때문에 수신자 측에서는 어떤 순서로 오든지 간에 해당 번호를 가지고 순서대로 조합하면 순서가 뒤바뀌어도 문제가 되지 않는다.
 
 
TCP Segment가 손상 되었다면?
TCP Header에는 오류를 체크하는 부분이 있다. 이를 Checksum 부분이라고 하는데, 해당 Checksum을 통해서 TCP Segment를 검사하고 송신자가 보낸 Segment가 수신자로 전송이 되는 과정 중에 손상이 되었는지 판단할 수 있고 손상 되었다면 해당 Segment를 버려버린다.


TCP Segment가 손실 되었다면?
발신자는 재전송 시간초과 (RTO: Retrasmission Time-Out) 타이머를 Segment 각각 구동하여, 타이머가 시간초과 될 경우 해당 Segment를 재전송한다.
따라서, Segment가 중간에 유실되거나 Checksum 검사 후 버려졌다면 발신자 타이머가 초과될 것이고 재전송하여 받을 수 있다.

추가적으로, RTO의 설정은 성능에 큰 영향을 끼친다. 타이머 주기가 너무 짧으면 실제로 손실이 되지 않은 상태임에도 재전송을 보내 데이터 중복을 유발할 수 있고, 타이머 주기를 너무 길게 설정하면 손실이 발생한 이후 늦게 데이터를 받기까지 걸린 시간만큼 데이터를 재조립하는 시간이 걸려버린다. 이러한 RTO 설정은 RTT (Round Trip Time)에 의해 결정된다.
 
 
 

2. 흐름 제어

TCP Segment를 수신하는 컴퓨터는 CPU, 네트워크 대역폭 등의 변수로 인해서 수신자의 처리 속도보다 훨씬 빠른 속도로 송신자가 데이터를 보내는 가능성이 있기 때문에 TCP는 송신자가 보낸 데이터의 양을 제어하는 흐름 제어 매커니즘을 구현하고 있다.
 
 
Stop and Wait

상대방에게 데이터를 보낸 후 수신자에게 잘 받았다는 응답이 올 때까지 기다리는 방식을 말한다.
이러한 방식은 구현 자체도 간단하고 개발자가 이해하기도 쉽지만 패킷을 하나씩 보내기 때문에 매우 매우 느리다는 단점이 있다.
 
 
Sliding Window

슬라이딩 윈도우 방식은 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때 그때 수신 측의 데이터 처리 상황을 송신 측에게 알려줘서 데이터의 흐름을 처리하는 방식이다. 수신 측은 자신의 CPU, 네트워크 상황에 따라서 윈도우 크기를 설정하고 송신 측에서 확인 응답 없이 패킷을 전송할 수 있게하여 데이터의 흐름을 동적으로 조절한다.
 
 
 

3. 혼잡 제어

송신측과 수신측 사이의 네트워크 내에서 패킷의 수가 과도하게 증가하는 현상을 방지하거나 제거하는 기능을 혼잡 제어라고 한다.
흐름 제어는 송신측과 수신측 사이의 전송 속도를 다루는거라면, 혼잡 제어는 호스트와 라우터를 포함한 네트워크 상에서의 전송을 다루게 된다는 점이 차이점이다.
 
 
AIMD (Additive Increase / Multiplicative Decrease)

처음에 패킷을 하나씩 보내면서 문제 없이 도착했다는 것을 알면 WIndow 크기를 1씩 증가시키면서 전송하는 방법이다.
만약, 패킷 전송에 실패하거나 일정 시간을 넘어버리면 Window 크기를 절반으로 감소시킨다.
이러한 특징 때문에, 빠른 속도로 통신하기까지 시간이 오래 걸린다는 단점이 있다.
 
 
Slow Start
AIMD와 다르게 Window 크기를 매 RTT마다 지수승으로 증가시킨다.
이때, ssthresh 개념이 등장하는데, 
 
 
Tahoe

빠른 재전송 정책이 도입된 방법으로, 처음에 동일하게 Slow Start 방식으로 윈도우 크기를 증가시키다가 
ssthresh 즉, 임계점 시점 이후로부터는 AIMD 방식을 사용하는 정책이다.
3 ACK Duplicated와 TimeOut 상황이 발생하면 Window 크기를 1로 줄여버리고
ssthresh 를 혼잡 상황이 발생했던 Window 크기의 절반으로 설정하는 특징이 있다.
 
 
Reno

3 ACK Duplicated와 TimeOut을 구분해서 대응한다는 점에서 Tahoe와 다른 특징을 가진다.
3 ACK Duplicated가 발생하면, Window 크기를 1로 초기화 하지 않고, 절반으로 줄이고 ssthresh 값을 재설정 하고,
TimeOut 상황이 발생하면, Window 크기를 1으로 줄이지만 ssthresh 값은 그대로 유지한다는 특징이 있다.
 
 
 

4. 연결형 서비스

송신측과 수신측 사이의 논리적인 연결을 확립하고 데이터를 전송하는 방법으로 신뢰성 높은 데이터 전송을 할 수 있다.
 
 
3-way handshaking (연결)

처음 TCP 통신을 하기 위해서는 송신측과 수신측 사이에 연결을 맺어야 하는데 이러한 과정을 3-way handshaking 이라고 한다.
 
[STEP 1]
수신측은 송신측에 접속을 요청하는 SYN 패킷을 보낸다. 이때 송신측은 SYN/ACK 응답 패킷을 기다리는 SYN_SENT 상태가 된다.
 
[STEP 2]
수신측은 SYN 패킷을 받고 송신측에 요청을 수락한다는 ACK, SYN flag가 설정된 패킷을 보내고 수신측은 ACK 패킷을 기다리는 SYN_RECEIVED 상태가 된다.
 
[STEP 3]
송신측은 수신측에게 ACK 패킷을 보내고 이후로부터는 연결이 이루어지고 데이터를 요청하거나 보낼 수 있게 된다.
이때 ACK 패킷을 받은 수신측은 ESTABLISHED 상태가 된다.
 
 
 
4-way handshaking (연결 종료)

마찬가지로 TCP 통신 연결을 종료하는 과정을 4-way handshaking 이라고 한다.
 
 
[STEP 1]
송신측이 연결을 종료하겠다는 의미인 FIN 패킷을 전송한다.
 
[STEP 2]
수신측은 ACK 패킷을 보내고 자신의 어플리케이션에서 연결을 종료 가능 상태를 기다리는 TIME_WAIT 상태로 전환된다.
 
[STEP 3]
수신측에서 연결을 종료할 수 있는 상태가 됐다면 FIN 패킷을 송신측에게 보낸다.
 
[STEP 4]
송신측은 ACK 패킷을 보내고 ACK 패킷이 중간에서 유실되거나 지연되는 것을 대비하여 일정 시간동안 대기한다.
 
[STEP 5]
수신측에서 ACK 패킷을 받으면 연결을 종료하고, 송신측도 대기하는 시간이 모두 지나면 연결을 종료한다.
 
 
 
 

---

헤더 구조

HTTP, TCP, IP 등 다양한 프로토콜은 각자 자신의 헤더를 붙여서 데이터의 정보를 표현한다.
TCP도 마찬가지로 다양한 기능을 제공하기 때문에 여러가지 정보를 헤더에 담고있다.
기본적으로 20 bytes를 차지하지만, 뒤의 옵션 필드가 최대로 붙으면 60 bytes 까지 헤더 크기를 가질 수 있다.
 
 
Source Port, Destination Port

Segment의 출발지와 목적지의 포트 번호를 나타내는 필드로, 각각 16 bits로 이루어져 있다.
출발지와 목적지의 주소를 판별하기 위해서는 밑의 네트워크 계층에 있는 IP 주소, 포트 번호를 필요로 한다.
 
 
Sequence Number

시퀀스 번호는 총 32 bits로 구성되어 4, 294, 967, 296 까지의 수를 담을 수 있다.
해당 필드를 이용하여 데이터의 순서를 나타낼 수 있고 이는 순서가 뒤바뀌어 전송되도 순서를 맞춰줄 수 있다.
해당 시퀀스 번호는 
 
 
Acknowledgment Number

승인 번호라는 의미로, 데이터를 받은 수신자가 예상하는 다음 Sequence Number를 의미하며, 마찬가지로 32 bits로 구성된다.
 
 
Data Offset

옵션에 따라서 헤더의 크기가 가변적으로 변하기 때문에, 헤더의 크기를 제외하고 실제 데이터 시작 위치를 알려주는 필드이다.
 
 
Flags

9개의 비트 플래그이다. 플래그들은 현재 Segment의 속성을 나타낸다.
3-way handshaking, 4-way handshaking 등에서 사용하느 SYN, ACK, FIN 등의 플래그가 해당 필드에서 설정된다.
 
 
Window Size

한번에 전송할 수 있는 데이터의 양을 의미하며, 16 bits 를 차지하므로 총 65535 만큼의 값을 표현할 수 있다.
해당 값의 단위는 byte 이므로, 최대 64KB 만큼의 데이터를 한번에 전송할 수 있다.
 
 
Checksum

데이터를 송신하는 중에 데이터가 변형되거나 손상되었을 경우 오류를 검출하기 위해 필요한 필드이다.
TCP는 해당 필드를 통해 오류가 검출되면 재전송을 수행하여 데이터 전송을 보장한다.
 
 
 
 

---

UDP

특징

1. 데이터그램 방식

UDP에서는 TCP와 다르게 패킷 (Packet)이 아니라 데이터 전송 단위로 데이터그램 (Datagram)을 이용한다.
 
 

2. 비 연결형 서비스

UDP는 데이터 전송 전에 3-way handshake와 같은 송/수신자 사이 가상 회선을 설정하지 않고,
패킷들이 각기 독립적으로 전송되는 방식이다. 
 
 

3. 비 신뢰성

ACK와 같이 해당 데이터를 받았다는 신호를 주지 않기 때문에, 전송을 했을 때 실제로 데이터가 잘 전송 되었는지 확인이 불가능 하다.
따라서, 실시간 스트리밍과 같이 일부 데이터가 손실되었다고 해도 큰 영향을 받지 않는 서비스에서 주로 사용한다.
 
 

4. 빠른 속도

가상 회선을 설정하는 절차와 데이터 순서, ACK 등 신뢰성 있는 데이터 전송을 위한 절차가 모두 없으므로
빠르게 목적지까지 데이터를 전송할 수 있다.
 
 
 
 

---

헤더 구조

UDP 헤더는 TCP 헤더와 다르게 매우 간단한 구조로 되어있다.
Source Port, Destination Port, Length, Checksum 모두 16 bits로 구성되어 있어 헤더의 총 크기는 8 bytes이다.
 
 
Source Port, Destination Port
TCP 헤더와 마찬가지로 출발지와 목적지의 포트 번호를 나타내는 필드이다.
 
 
Length
UDP 헤더와 데이터의 길이를 합친 길이를 byte로 나타낸 필드이다.
 
 
Checksum
TCP와 마찬가지로 데이터를 송신하는 중에 데이터가 변형되거나 손상되었을 경우 오류를 검출하기 위해 필요한 필드이다.
UDP는 오류가 검출되면 재전송을 수행하지 않고 해당 데이터그램을 폐기시켜 버린다.
 
 
 
 

---

요약

구분	TCP	UDP
신뢰성	높음	낮음
속도	낮음	높음
전송 순서	순서 보장	순서가 바뀔 수 있음
오류 감지 및 수정	있음	없음
연결성	연결형	비연결형
통신 방식	1 : 1	1 :1 or 1 : N or N : N

 
 
 
 
 

---

참고 문헌

https://forum.huawei.com/enterprise/en/how-to-verify-oduk-sncp-protection/thread/690318483918831616-667213856692383744

TCP/IP (흐름제어/혼잡제어) | 👨🏻‍💻 Tech Interview

TCP의 헤더에는 어떤 정보들이 담겨있는걸까?

[TCP/UDP] TCP와 UDP의 특징과 차이