전송계층 - TCP와 UDP

패킷의 최종 목적지는 호스트가 실행하는 프로세스이다. 이는 IP주소+포트 번호의 조합으로 알아낼 수 있는데, 전송계층은 이 포트 번호를 다루는 계층이다.

포트 번호

포트 번호는 총 16비트로 표현된다. 그래서 0~2^16-1까지 표현이 가능하다.

0~1023	웰노운 포트
1024~49151	등록된 포트
49152~65535	동적 포트

웰노운 포트는 대중적으로 사용되는 애플리케이션을 위한 포트이다. 예를들어 FTP(20, 21), SSH(22), TELNET(23), DNS(53), DHCP(67, 68), HTTP(80), HTTPS(443) 등이 있다.

또 등록된 포트는 우리가 아는 MySQL(3306), Redis(6379), MSSQL(1433)등이 있다.

마지막으로 동적 포트는 일반적으로 클라이언트로서 동작하는 프로그램에게 할당되는 포트이다. 우리가 웹 브라이저를 통해 특정 사이트에 접속한다면 웹 브라우저에는 동적포트 내 임의의 포트 번호가 할당된다.

	TCP	UDP
연결수립	O	X
상태관리, 흐름제어	O	X
오류제어, 혼잡관리	O	X
연결 종료	O	X

UDP가 TCP에 비해 간단한 만큼 UDP는 헤더도 훨씬 간단하게 생겼다.

비교적 간단한 UDP 헤더부터 살펴보도록 하자. UDP 헤더에는 송, 수신지의 포트 번호가 담겨있다. 그리고 길이 필드에는 헤더를 포함한 UDP 패킷의 바이트 크기가, 체크섬에는 송, 수신 과정에서의 데이터그램 훼손 여부를 검증하는 정보가 포함된다.

TCP 헤더에도 송, 수신지의 포트번호가 있다. 그 외에 다른 값들도 있는데 순서번호와 확인 응답번호라는 것이 있다. 순서번호는 현재 패킷이 주고받고자 하는 데이터의 몇 번째 패킷인지를 나타낸다. 또 확인 응답번호는 앞으로 받고자 하는 패킷의 번호이다. 예를 들어 5번째 패킷까지 받았다면 확인 응답번호에는 6이 세팅된다. 이는 TCP의 신뢰성을 보장하기 위한 것이다. TCP가 신뢰성을 보장한다는 것은 보낸 패킷이 잘 도착했는지를 확인한다는 뜻인데, 순서번호와 확인 응답 번호가 여기에 사용된다.

또 ACK, SYN, FIN등은 제어비트에 포함되는 값들로 말 그대로 “비트”이다. 즉 0 또는 1의 값으로 표현된다. 이 값들은 추후 TCP의 연결 수립 과정에서 사용된다.

 

TCP 연결 수립

TCP의 연결 수립이란 우리가 많이 들어본 3-way-handshake를 말한다. 앞서 살펴본 SYN, ACK 값들과 순서번호, 확인 응답 번호를 사용하여 제어정보를 주고받는다.

클라이언트가 서버측에 연결을 시도한다고 가정했을 때 아래 3가지 과정이 진행된다.

1. 클라이언트가 서버에 SYN 비트를 1로 설정하고, 순서 번호를 포함하여 서버에 전송한다.
2. 서버는 SYN 비트와 ACK 비트를 1로 설정하고, 순서 번호에 자신의 순서번호. 그리고 클라이언트로부터 받은 순서번호에 1을 더한 값을 확인 응답 번호에 세팅하여 전송한다.
3. 클라이언트도 ACK비트를 1로 설정하고, 확인 응답 번호에 서버로부터 받은 값에 1을 더한 값을 세팅하여 서버로 전송한다.

 

이렇게 연결한 후 패킷을 주고받는 과정에서 TCP는 신뢰성 보장을 위해 크게 오류제어, 흐름제어, 혼잡제어 기능을 제공한다. 이 기능들이 어떻게 수행되는지 살펴보도록 하자.

 

TCP 오류제어

TCP는 신뢰성 보장을 위해 오류제어, 흐름제어, 혼잡제어라는 기능을 제공한다.

먼저 오류제어는 말 그대로 오류가 일어났을 때 대처하는 것이다. 앞서 TCP는 전송한 패킷이 잘 도착했는지를 확인한다고 했는데, 잘 도착하지 않았음을 감지하면 패킷을 재전송함으로써 오류를 제어한다. 오류를 감지하는 것은 크게 2가지 경우가 있는데, 하나는 중복된 ACK을 수신하는 것이고, 하나는 타임아웃이 발생하는 것이다.

중복된 ACK 수신

예를 들어 N번째 패킷을 보냈는데 이것이 유실되었다고 가정하자. 그러면 수신지에서는 ACK에 1을 세팅하고, 확인 응답 번호에 또다시 N을 세팅하여 보낼 것이다. 이렇게 중복된 ACK을 수신하면 송신자는 N번째 패킷을 재전송한다.

타임 아웃 발생

TCP 패킷을 송신하는 호스트는 내부적으로 재전송 타이머라는 값을 가지고 있다. 패킷을 보낸 뒤 일정 시간 내에 ACK을 받지 못하면 문제가 발생했다고 생각하고 해당 패킷을 재전송한다.

 

TCP 흐름제어

TCP 흐름제어라는 것은 수신자가 처리할 수 있는 한도 내로 패킷을 보내는 것이다. 좀 더 자세히 보자면 수신자는 데이터를 받으면 이를 자신의 수신버퍼라는 곳에 저장하게 되고, 애플리케이션이 이를 읽어간다. 그렇기에 수신자가 한 번에 처리할 수 있는 패킷의 크기는 TCP 수신 버퍼의 크기에 의해 결정된다.

TCP는 3-way-handshake를 진행할 때 수신자가 송신자에게 자신의 수신 윈도우(한 번에 처리할 수 있는 양)의 크기를 알려준다. 앞서 살펴본 TCP 헤더의 윈도우 필드를 통해서 말이다. 즉 송신자는 이를 통해 수신자가 한 번에 처리할 수 있는 크기의 패킷을 전송한다.

 

TCP 혼잡제어

혼잡제어는 많은 트래픽으로 인해 패킷의 처리 속도가 느려지거나 느려지는 상황을 방지하는 것이다. 흐름제어는 받는 쪽의 입장에서 한 번에 받을 수 있는 양을 보내는 것이었는데 혼잡제어는 보내는 쪽에서 판단하여 결정한다. 이때 네트워크의 혼잡 여부는 앞서 오류제어와 같이 중복된 ACK을 수신하거나 타임아웃이 발생했을 때 네트워크가 혼잡하다고 판단한다.

앞서 수신자가 수신 윈도우(Reveiver WiNDow)라는 값을 가지고 있었듯이 송신자도 혼잡 윈도우(Congestion WiNDow)라는 값을 가지고 있다. 혼잡 윈도우는 혼잡 없이 전송할 수 있는 양을 의미한다. 즉 송신자는 min(rwnd,cwnd)값 만큼을 보내게 된다.

이러한 혼잡 윈도우의 크기는 혼잡 제어 알고리즘에 의해 연산되는데 가장 대표적인 것은 AIMD(Additive Increase/Multiplicative Decrease)이다. 혼잡이 감지되지 않을 때는 합으로 증가를 하다가 혼잡이 감지되는 순간 절반으로(1/2곱으로) 감소시킨다.

출처: https://code-lab1.com/tcp-%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4/

패킷을 보내고 응답이 수신되기까지의 시간을 RTT라고 하는데 AIMD는 혼잡 윈도우를 RTT마다 1씩 증가시키고 혼잡이 감지되면 혼잡 윈도우를 절반으로 감소시키는 알고리즘이다.

TCP Tahoe와 TCP Reno

TCP Tahoe와 TCP Reno는 대표적인 혼잡제어 알고리즘이다. 이것의 동작방식을 이해하려면 먼저 아래 용어를 알고 있어야 한다.

TCP SlowStart	window size를 1부터 지수승으로 증가시키는 것을 말한다. → 1, 2, 4, 8, 16 … 그러다가 패킷 손실을 감지하면 window size를 1로 줄인다.
AIMD	window size를 1MSS씩 증가시키다가 패킷 손실을 감지하면 window size를 절반으로 줄인다.
sshthresh(임계점)	임계점은 slow start threshold(ssthresh)인데, 말 그대로 여기까지 slow start를 사용하겠다는 뜻이다. 운영체제마다 구현방식이 다르지만 처음에는 임계점을 매우 큰 값(예: 65535 바이트)로 설정해두고, 혼잡이 발생하면 혼잡이 발생한 시점의 cwnd의 절반으로 설정한다.

TCP Tahoe
임계점 도달 전까지는 Slow Start, 임계점 도달 시 AIMD 방식 사용.
이후 혼잡이 발생하면 cwnd값을 1로 줄이고 다시 Slow Start

TCP Reno
TCP Tahoe와 비슷하지만 3 duplicate ACKs와 Timeout을 구분한다는 점이 다르다.
3 duplicate ACKs를 만나면 일부 패킷만 손실된것이고 네트워크가 완전히 막히지 않았다고 판단한다. 그래서 윈도우를 절반으로 줄인다. 그리고 ssthresh값도 현재 윈도우 값의 절반으로 설정한다.
Timeout은 ACK가 전혀 도착하지 않았다는 뜻이고 네트워크가 매우 혼잡한 상황이라고 판단한다. 그래서 ssthresh값은 그대로 두고(현재 정보는 신뢰 불가하니 다음 혼잡상황에 조절하자!) cwnd값을 1로 줄여 slow start부터 시작한다.

 

TCP 연결 종료

TCP의 종료는 4-way-handshak라고도 한다. 앞서 살펴본 FIN과 ACK값이 사용된다.

이번에도 클라이언트에서 연결 끊기에 들어간다고 가정하고 살펴보도록 하자. 먼저 클라이언트쪽에서 컨트롤 비트 중 FIN의 값을 1로 설정하여 서버로 보낸다. 서버는 FIN을 1로 설정한 패킷을 받았다는 의미에서 ACK 패킷을 반송하고, 서버 쪽에서도 Close가 호출되어 FIN을 1로 설정한 패킷을 반송한다. 그러면 클라이언트에서도 이를 받아 ACK 패킷을 반환하고, 서버가 이를 받으면 서버는 Closed 상태가 된다. 클라이언트는 몇 분 정도 TIME_WAIT 상태로 대기하다가 Closed로 전환된다.

이때 몇 분을 기다리는 이유는 마지막 ACK이 제대로 전송되지 않았을 경우를 대비해서이다. 만약 마지막 ACK을 보내고 소켓을 말소해버렸는데 ACK이 서버에 전송되지 않았다고 가정하자. 그러면 서버는 FIN을 다시 보내겠지만 이미 클라이언트는 소켓을 말소해버렸기 때문에 받을 수가 없다. 이런 상황을 방지하기 위해 몇 분 정도를 기다리는 것이다.