Transport Layer (in TCP/IP 4 Layers)

2023.04.13 - [Network/Network 스터디] - Application Layer (in TCP/IP 4 Layers)

Application Layer (in TCP/IP 4 Layers)

이전 포스팅에서 TCP/IP 4 계층 구조의 마지막 계층인 애플리케이션 계층에 대해 다뤘었다.

이번에는 애플리케이션 계층(4 계층)과 인터넷 계층(2 계층)을 이어주는 전송 계층(3 계층)에 대해 알아보자.

 

 

전송 계층(Transport Layer)

전송 계층은 애플리케이션 계층과 인터넷 계층 사이에 존재하는 계층으로, 두 계층을 이어주는 역할을 수행한다.

송신 측 기준으로, 다음의 순서를 거친다.

1. 전송 측 호스트가 보낸 네트워크 패킷을 인터넷 계층으로부터 수신한다.
2. 이를 전송 계층에서 사용하는 프로토콜 데이터 단위인 세그먼트로 변환한다.
3. 세그먼트 헤드 데이터를 참조하여 이를 올바른 포트(소켓)에 넘겨준다.

이 과정에서 특정 호스트의 인터넷 계층(1)과 애플리케이션 계층(N)을 잇는 역할을 수행하기 때문에

전송 계층은 다중화와 역다중화를 수행한다고 표현한다.

(송신 측에서 이뤄지는 상황을 다중화, 반대 상황을 역다중화라고 한다.)

전송 계층에서 사용되는 프로토콜에는 TCP와 UDP가 존재한다.

 

UDP

UDP는 전송 계층이 수행해야할 최소한의 역할 만을 수행한다.

1. 다중화, 역다중화 
2. 오류 검출

이렇기 때문에 UDP 세그먼트의 헤더는 TCP 세그먼트의 헤더의 비해 작은 크기를 갖는다.

(8 byte vs 20 byte)

따라서 데이터 전송의 신뢰성보다는, 작은 오버헤드나 TCP의 혼잡 제어로부터 자유로울 필요성이 더 클 때 사용된다.

대표적으로는 애플리케이션 계층의 DNS가 UDP를 채택한다.

또한 HTTP의 가장 최신 버전인 HTTP/3에서 TCP 대신 UDP 방식을 채택하고 있다.

(여담으로 UDP 프로토콜 의 데이터 단위를 세그먼트 대신 데이터그램으로 표현하기도 한다.)

다중화, 역다중화

UDP에서는 해당 역할을 수행하기 위해

세그먼트 헤더에 전송 측의 포트 번호와 수신 측의 포트 번호가 포함된다.

이들은 각각 2 byte의 크기를 갖는데,

이를 통해 수신 측에서는 인터넷 계층을 통해 전달받은 세그먼트를 올바른 소켓에 매핑시킬 수 있게 된다.

오류 검출

UDP에서는 해당 역할을 위해 세그먼트 헤더 내 체크섬을 포함시킨다. 

송신 측 헤더를 통해 체크섬을 만들고, 수신 측에서는 체크섬을 만들 때 사용된 헤더에 체크섬을 더하는 방식으로 오류 검출을 수행한다.

애초에 체크섬은 생성 시 사용된 데이터들과 더해졌을 때 1111111111111111(2) 이 되도록 만들어졌기 때문에

수신 측에서 수행한 계산 결과가 위와 같지 않다면 전송 과정에서 문제가 발생했음을 알 수 있다.

다만 UDP의 역할은 단순 검출까지이고 이에 대한 회복은 수행하지 않는다.

또한 체크섬을 0으로 생성하면 오류 검출 과정을 생략하겠다는 의미를 갖는다.

 

TCP

전송 계층 이하의 환경에서는 패킷의 도착 순서를 보장하지 못하고,

패킷이 손상될 수 있으며 심지어는 패킷을 아예 잃어버릴 수도 있다.

TCP는 이러한 환경 속에서도 전송 계층 레벨에서 작동하며 신뢰할 수 있는 연결을 보장한다. 

UDP가 수행하는 역할은 모두 수행하면서도,(다중화, 역다중화, 오류 검출 등)

다양한 기법을 통해 UDP가 보장하지 못하는 연결을 신뢰성을 보장한다.

대신 그에 따라 세그먼트 헤더에 포함되어야하는 정보가 UDP보다 많아서, 어느정도 오버헤드가 존재한다.

3-way Handshake

TCP 프로토콜은 연결 지향 프로토콜이기 때문에

TCP 연결 시 3-way handshake라고 불리는 사전 작업을 수행한다.

출처: https://sjlim5092.tistory.com/35

위 과정을 간략히 설명하면 다음과 같다. 

1. 클라이언트 측에서 연결 요청을 SYN=1, {클라이언트 측 순서 번호}=a라는 값과 함께 보냄.
2. 서버 측에서는 a를 잘 수신했다는 응답을 SYN=1, {서버 측 순서 번호}=b, ACK=a+1(a를 잘 수신했고 그 다음 순서를 기다린 다는 의미의 +1)의 값들로 반환.
3. 클라이언트 측은 서버 측이 반환한 응답을 잘 받았다는 의미에서 SYN=0(연결이 성립되었다는 의미의 0, 이후 해당 연결의 세그먼트에서는 모두 0의 값을 가짐), ACK=b+1 의 값을 반환. 

해당 과정을 통해 두 호스트를 연결하는데 이상이 없음을 확인하고, TCP 연결을 위한 각종 변수들을 초기화하면서 TCP 연결이 성립된다.

신뢰적인 데이터 전송

TCP 기법은 애플리케이션의 입장에서 전송 측에서 전송한 데이터의 도착, 변조 여부, 순서를 보장하는 신뢰할 수 있는 프로토콜이다.

여기서 주목할 것은 전송 계층 이하의 계층에서는 이러한 부분들을 보장해주지 못한다는 것인데, 이를 위해 TCP 프로토콜에서는 타이머, 순서 번호, 확인 응답(ACK), 재전송 등의 방법을 활용한다.

우선 전송 측에서는 전송하고자하는 데이터의 스트림의 바이트에 고유한 순서 번호를 부여한다.

그 후엔 데이터를 수신 측에 전송하게 되는데, 수신 측은 지금까지 수신한 연속된 순서 번호 데이터의 바로 다음 순서 번호를 ACK 응답에 담아 전송 측에 반환한다.

이 때 타이머의 개념이 등장하는데,

만약 전송 측이 타이머에 지정된 기간 동안 ACK 응답을 받지 못한다면 이를 전송 데이터의 누락으로 간주하고 해당 순서 번호의 세그먼트를 재전송한다. 이 때 전송 데이터가 누락된 것이 아니라 ACK 응답이 분실된 것이라도 수신 측에서는 순서 번호를 통해 중복 검사를 수행할 수 있기 때문에 문제되지 않는다.

마지막으로, 순서를 보장하기 위해 수신 측에서는 누락된 순서 번호가 존재할 경우, 누락된 순서 번호 이전의 데이터는 모두 애플리케이션 계층으로 밀어넣고 그 이후 순서 번호의 데이터를 순서가 만족될 때까지 버퍼에서 임시 저장하게 된다.

흐름 제어

TCP 방식에서 송수신에 참여하는 두 주체는 모두 개별적인 수신 버퍼를 갖는다. 

전송 측에서 보낸 세그먼트들은 모두 수신 버퍼에 쌓이고, 애플리케이션 계층에서 수신한 데이터는 버퍼에서 지워진다.

만약 애플리케이션 계층에서 데이터를 읽어내는 속도보다 전송 측의 전송 속도가 더 빠르다면 결국 수신 버퍼는 가득차고 오버플로우가 발생하여 문제가 발생할 것이다. 

따라서 수신 버퍼를 읽어내는 수신 측 속도와 버퍼를 채우는 전송 측 속도를 일치시킬 필요가 있다.

이를 위해 TCP 방식에서는 흐름 제어라고 불리는 기법을 사용한다.

수신 버퍼의 가용 공간을 수신 윈도우라고 하는데, 수신 측은 윈도우 값(rwnd 값)을 세그먼트 헤드에 담아서 전송 측에 반환한다.

전송 측은 해당 값을 보고 수신 윈도우가 0 미만의 값이 되지 않도록 속도를 조절하여 흐름 제어를 달성한다.

혼잡 제어

네트워크 상에 지나치게 많은 패킷이 존재하게 되면 패킷들이 라우터를 통과할 때 큐에서 대기하는 시간이 길어지고, 심지어는 라우터의 큐가 가득차 패킷이 분실되기도 한다. 

이러한 상황을 '혼잡' 상태라고 하며 TCP 프로토콜은 이를 완화하기 위해 혼잡 제어를 수행한다.

최근에는 네트워크 계층에서 혼잡 상태에 이르기 전에 미리 경고 시그널을 보내는 방식도 존재하지만, 기본적으로 네트워크 계층은 신뢰할 수 없기 때문에 전송 계층의 TCP 프로토콜이 스스로 현재 네트워크 상황이 혼잡한지 판단할 기준이 필요하다.

TCP에서는 문제를 간단히 하기 위해 패킷이 분실된 상황을 혼잡한 상황으로 여기고, 패킷의 분실 여부에 대한 판단 기준이 필요했다.

이를 위해, TCP는 타이머 방식과 중복 ACK 응답 확인 방식을 사용한다.

타이머 방식은 간단하다. 세그먼트를 전송한 뒤 일정 시간동안 ACK 응답이 오지 않을 경우 이는 패킷이 분실된 것으로 보고, 이를 통해 현재 네트워크 상황이 혼잡한 것으로 판단한다.

중복 ACK 응답 확인 방식은, 수신 측에서 세그먼트의 수신에 대한 응답으로 보내는 ACK가 누적 방식이라는 것에 착안했다. 
즉, 중복된 ACK 응답이 반복된다면 이는 수신 측에 세그먼트가 도착은 하고 있으나 중간에 누락된 세그먼트가 있음을 내포한다는 것이다. TCP에서는 일반적으로 중복 ACK 응답이 3번 이상될 경우 패킷이 분실된 것으로 판단한다.

TCP 단에서 어떻게 혼잡 상태를 판단하는지 알게 되었으니, 이제는 TCP가 어떻게 혼잡 제어를 수행하는지 알아보자.

TCP는 전송 측에서 관리하는 혼잡 윈도우(cwnd) 변수 및 크게 슬로우 스타트, 혼잡 회피, 빠른 회복으로 부리는 3가지 방법을 통해 혼잡 제어를 수행한다.

슬로우 스타트란 TCP 연결이 수립된 후, 초기에는 아주 느린 속도로 세그먼트를 전송하다가 점차 이를 빠르게 만드는 것을 의미한다. 가령 연결이 수립된 직후, cwnd는 세그먼트 하나 크기의 값일 수 있다. 슬로우 스타트 방식에서는 수신 측이 보내는 ACK 응답의 수만큼 cwnd의 크기를 세그먼트 단위로 키운다. 즉 초기에는 세그먼트 1개를 동시에 전송할 수 있었다가, 점차 2개, 4개, 8개, 16개... 로 늘어나는 방식이다. 즉, 슬로우 스타트 방식은 TCP 연결 초기에 아주 느린 전송 속도로부터 전송 속도(cwnd)를 지수적으로 상승시켜 네트워크가 감당할 수 있는 최대 전송 속도까지 빠르게 도달하는 방법이다. 슬로우 스타트는 TCP가 패킷이 분실되었다고 판단할 때까지 지속되며, 패킷이 분실되었다고 판단하면 그 즉시 cwnd를 초기값으로 줄이고(여기에서는 세그먼트 하나 분량) ssthresh라는 변수를 분실 시점의 cwnd의 절반 값으로 설정한 뒤 다시 슬로우 스타트 상태로 돌입한다. 이후, cwnd 값이 ssthresh 값과 다시 동일해지는 시점에 TCP는 혼잡 회피 상태로 돌입한다.

혼잡 회피란 슬로우 스타트 단계를 통해 cwnd 값을 빠르게 한계까지 도달시킨 상황에서 조금 더 조심스럽게 cwnd 값을 증가시키는 상태를 의미한다. 이전(슬로우 스타트 단계)에는 cwnd 값이 폭발적으로 증가했다면, 이제는 조금 더 한계치에 가깝게 다가가기 위해 지수적 증가 방식을 버리고 선형적 증가 방식을 채택한다. 가령 특정 시점의 cwnd가 세그먼트 16개 분량이라면, 16개의 세그먼트에 대한 ACK가 모두 도착한 뒤에 cwnd를 세그먼트 17(16+1)개 분량으로 증가시키는 식이다. 혼잡 회피 방식은 크게 두가지 경우에 종료되게 된다. 첫번째는 ACK 응답에 대해 타임아웃이 발생한 경우이다. 해당 경우에는 슬로우 스타트처럼 ssthresh 값을 해당 시점 cwnd 값의 절반으로 설정하고 cwnd 값을 초기값으로 수정한다. 두번째 경우는 중복 ACK 응답이 일정 횟수 이상 발생했을 때이다. 이 때는 타임아웃과는 달리 수신 측에서 지속적으로 세그먼트를 수신했음을 의미한다. 따라서 첫번째 경우처럼 급진적인 방식으로 cwnd 값을 수정하는 것이 아닌, cwnd 절반 값에 중복 ACK 응답 횟수 만큼 더한 값을 새로운 cwnd 값으로 수정한다.(ssthresh 값은 동일하게 문제 시점의 cwnd 값의 절반으로 수정) 이후 빠른 회복 상태에 돌입한다.

빠른 회복이란 중복 ACK 응답 상황에서 이를 위해 중복된 만큼 cwnd 값을 증가시키고, 해당 중복 상황이 해결된 경우 혼잡 회피 상태로 돌입하게 만든다. 만약 빠른 회복 단계에서 타임 아웃이 발생한다면, 이 경우엔 기존 슬로우 스타트, 혼잡 회피와 마찬가지의 방식으로 작동한 뒤 슬로우 스타트 단계로 이동한다.

아래 그림은 TCP 프로토콜에서 혼잡 제어가 이루어지는 방식을 한 눈에 보여준다.

출처: https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html