지난 시간 4계층인 application layer에 대해 학습을 진행했었다. 학습한 지 2주만에 다시 진행하는 스터디!
4계층을 다시 생각해보면 지금 기억나는건 서버랑 클라이언트..? 그나마 HTTP 1.0버전의 문제와 2.0 정도...? 에휴.. 이것저것 하다 보니 헷갈리기 시작한다
어쨌든 이번 학습할 내용은 이전에 학습한 4계층과 앞으로 학습할 2계층을 연결해주는 기능을 하는 3계층인 Transport Layer에 대해 알아보고자 한다.
✅ Transport Layer
앞서 말한대로 application layer와 network layer 사이에 존재하는 계층으로 다음과 같은 일을 수행한다.
✔️ Transport Layer 하는 일
- 서로 다른 호스트에서 돌아가는 application-process 간 logical communication 제공
- host 사이에서의 통신으로 프로토콜은 end_system에서 작동하며 segment라는 단위로 패킷 주고 받음
-> Router를 거쳐 데이터들이 전달되지만, transport layer 입장에서는 라우터를 거치는 과정은 보이지 않고 두 end_system 사이의 logical commnuication만 보게 되므로 위와 같이 작성하였다.
💯 그렇다면 Router에는 어떤 것들이 존재하는가?
: 네트워크, 데이터 링크, physical layer만 존재
sender (패킷 송신) : segment단위로 메세지를 잘라 transport layer의 헤더를 붙여 network layer로 보냄 - 다중화
receiver (패킷 수신) : segment를 합쳐 메세지를 만들고, application으로 전달 - 역다중화
Transport Layer에서 통신이 이루어지기 위해선 TCP/UDP 프로토콜이 사용된다.
해당 내용을 살펴보자!
✅ UDP (User Datagram Protocol)
사용자 데이터그램 프로토콜.
즉, 데이터를 데이터그램(독립적인 관계) 단위로 처리하는 프로토콜
UDP는 위 그림처럼 다음과 같은 특징을 갖는다.
- 비연결형 서비스로 데이터그램 방식을 제공한다
- 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
- UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
- 신뢰성이 낮다
- TCP보다 속도가 빠르다
UDP는 Transport Layer가 수행해야 할 최소한의 역할(다중화, 역다중화, 오류검출)만을 수행함.
그렇기에 UDP segment 헤더는 TCP에 비해 크기가 작고 오류만 검출할 뿐, 회복은 수행하지 않는다.💯 그렇다면 UDP 서버의 특징은? - (대표적으로 DNS)
- UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없다.
- 소켓 대신 IP를 기반으로 데이터를 전송한다.
- 서버와 클라이언트는 1대1, 1대N, N대M 등으로 연결될 수 있다.
- 데이터그램(메세지) 단위로 전송되며 그 크기는 65535바이트로, 크기가 초과하면 잘라서 보낸다.
- 흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.
- 파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 중요시 되는 경우에 사용된다.
❗ 흐름 제어 vs 혼잡 제어
흐름제어 : 데이터를 송수신하는 곳의 데이터 처리 속도를 조절해 수신자의 buffer overflow 방지
혼잡제어 : 네트워크 내 패킷 수에 상한성을 거는 방법으로 패킷을 조금씩 전송해 혼잡 붕괴 방지✨ UDP Flow
✅ TCP (Transmission Control Protocol)
신뢰성 있는 전송계층의 통신 방법. 영어 그대로 해석하면 전송을 제어하는 프로토콜
즉, 인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜
통상 IP를 TCP와 함께 사용하는데, IP가 데이터 배달을 처리하면, TCP는 패킬을 추척, 관리하는 역할을 담당한다.
TCP는 위 그림처럼 다음과 같은 특징을 갖는다.
- 연결 지향 방식 (받는 패킷 확정된 논리적 경로 배정하므로)
- 3-way handshaking 과정을 통해 연결 설정, 4-way handshaking으로 해제
- 흐름 제어 및 혼잡 제어
- 높은 신뢰성 보장
- UDP에 비해 속도가 느린 편
- Full-Duplex , point-to-point 방식
전송계층 이하의 환경 (network, datalink layer)에서는 패킷의 도착 순서를 보장하지 못하고, 패킷이 손상될 수 있고 심지어는 패킷을 잃어버릴 수 있다. TCP는 이러한 환경 속에서 3계층 level에서 작동하며 신뢰성있는 연결을 보장한다. 따라서 UDP가 수행하는 역할 + 신뢰성이라고 생각하면 되고, 포함되는 정보가 UDP보다 많으므로 어느정도 오버헤드가 발생함.
🎈 3-way handshaking :
출처
과정은 다음과 같다.
1. 클라이언트 측에서 연결요청을 SYN=1, (클라이언트측 순서번호) = a라는 값과 함께 송신
2. 서버 측에서는 a를 잘 수신했다는 응답으로 SYN = 1, (서버측 순서번호) = b, ACK = a+1
(a를 잘 수신하였고 그 다음 순서인 a+1을 기다리고 있음을 의미)
3. 클라이언트 측은 서버 측이 반환한 응답을 잘 받았음을 의미하는 SYN = 0(연결 성립), ACK = b+1을 반환위와 같은 방식을 통해 TCP 연결은 신뢰성이 있다고 할 수 있다.
💯 그렇다면 TCP 서버의 특징은?
- 서버소켓은 연결만을 담당
- 연결과정에서 반환된 클라이언트 소켓은 데이터 송수신에 사용
- 서버 : 클라이언트 = 1 : 1
- 스트림 전송으로 전송 데이터의 크기가 무제한
- 패킷에 대한 응답을 해야하기에 (시간지연, CPU소모) 성능이 낮음
- Streaming 서비스에 불리 (손실된 경우 재전송 요청 처리)
✨ TCP Flow
💯 (TCP 정리) 신뢰성 있는 전송
앞서 설명을 통해 TCP기법은 전송 측에서 전송한 데이터가 수신 측에서 잘 받았다는 응답여부로 순서를 보장하며 신뢰성있는 프로토콜임을 알 수 있었다.
이때 주목할 점은 송신입장에서 이후 계층은 신뢰성 여부를 판단하기 힘들기에 현 단계인 transport layer에서 신뢰성을 확실하게 보장해야 한다.
따라서 TCP에서는 타이머, 순서번호, 확인 응답(ACK), 재전송 등의 방법을 활용한다.
- 우선 전송 측에서 전송하는 data stream의 byte에 고유한 순서 번호를 부여하여 송신
- 그 이후 수신 측은 연속된 다음 순서 번호를 ACK응답에 담아 전송 측에 반환
- 이때, 타이머의 개념이 등장해 지정된 시간 내에 ACK응답을 못받으면 데이터 누락으로 간주하고 누락된 순서번호의 segment를 송신 측으로 재전송한다. (segment 분실의 경우에도 마찬가지)
- 누락된 순서 번호로 인해 순서 보장여부가 깨지는 것도 위 과정으로 해결이 가능하다.
✅ multiplexing & demultiplexing
서버 컴퓨터 하나에 두개의 서버가 돌아가는 상황
-> 네트워크 레이어는 IP 주소를 보고 가기에 두 클라이언트 모두 한 서버로 가고, TCP가 두 프로세스 중 어느 프로세스로 갈 지 결정해 주는 역할을 한다.
sender에서의 multiplexing : 여러 소켓에서의 데이터를 다루기 위해 transport header를 붙여서 보내준다.
receiver에서의 demultiplexing : header를 보고 어느 소켓으로 보낼 지 결정
- Connectionless demultiplexing -> UDP
- Connection - Oriented demultiplexing -> TCP
✨ 흐름제어 정리
TCP 방식에서 송수신 측은 모두 개별적인 수신 buffer를 갖는다.
송신 측에서 보낸 segment는 모두 수신 buffer에 쌓이고, 다음 계층인 application에서 수신한 데이터는 buffer에서 지워진다. 만일 application에서 수신하는 데이터를 읽는 속도보다 전송속도가 빠르다면 buffer는 넘치게 되고 오버플로우가 발생하게 되므로, 이러한 속도를 일치시켜줄 필요가 있어 이를 흐름제어라고 한다.
구체적인 과정은 다음과 같다.
수신 buffer의 가용 공간을 수신 윈도우라고 하고 해당 값인 rwnd를 segment header에 담아 송신 측에 반환하여 송신 측은 이를 확인하고 rwnd값이 0 미만이 되지 않도록 속도를 조절한다.
✨ 혼잡제어 정리
앞서 UDP에서 설명한 것처럼 혼잡제어란, 네트워크 내 패킷 수에 상한성을 거는 방법으로 패킷을 조금씩 전송해 혼잡 붕괴 방지하는 기법이다. 여기서 혼잡이란 라우터를 패킷들이 통과할때 큐라우터 내 queue가 가득차 패킷이 분실되는 상황을 의미한다.
TCP는 혼잡상태 여부를 판단하고자 앞서 설명한 타이머 방식과 중복 ACK응답 확인 방식을 사용한다.
- 타이머 방식은 이전 설명과 동일하게 지정된 시간 내 ACK응답이 오지않으면 전송한 패킷이 분실된 것으로 처리하고 현 네트워크 상황을 혼잡처리한다.
- 중복 ACK응답 확인 방식은 수신측에 segment가 잘 도착은 하지만, 중복 ACK응답을 송신측이 전달받으며 중간에 누락된 segment여부를 판단하여 혼잡처리하는 것을 의미한다. TCP에서는 일반적으로 중복 ACK응답이 3번 반복되는 경우 패킷 분실처리를 한다.
지금까지, TCP가 현 네트워크 상황을 혼잡처리하는 판단여부를 정리했고, 이제부터 어떻게 이 혼잡제어를 수행하는지 알아보자.
TCP는 전송 측에서 관리하는 혼잡 윈도우(cwnd) 변수 및 슬로우 스타트, 혼잡 회피, 빠른 회복 등의 3가지 방법으로 혼잡제어를 수행한다.
슬로우 스타트란, TCP연결 초기에는 아주 느린 속도로 segment를 전송하다 cwnd값을 지수 단위로 범위를 늘려 네트워크가 감당할 수 있는 최대 전송 속도까지 빠르게 도달하는 방식이다. 범위를 늘리다 패킷이 분실되었다고 판단되면 cwnd값을 분실시점의 절반 값으로 재설정하며 다시 슬로우 스타트를 시작한다. 이때 ssthresh(지수 단위 네트워크 최대 도달 지점)에 도달한 시점에 TCP는 혼잡 회피 상태에 돌입한다고 한다.
혼잡 회피란 cwnd값이 ssthresh에 도달한 이후 +1 씩 증가하며 cwnd값을 네트워크 max 전송 속도 지점에 도달시키는 상태를 의미한다. 다음과 같은 2가지 경우에 혼잡회피 상태는 종료하게 된다.
- ACK응답에 대해 타임아웃 발생 -> 혼잡회피 종료 (cwnd = ssthresh/2)
- 중복 ACK응답이 일정횟수 (일반적으로 3회) 이상 발생한 경우 -> cwnd = (ssthresh/2 + 혼잡회피(중복 응답횟수))
위 과정을 거치면, 빠른 회복 상태에 도달한다.
- 빠른 회복이란 중복 ACK 응답 상황에서 중복된 만큼 cwnd값을 +1씩 증가시키고 해당 중복상황이 해결되었으면, 혼잡 회피 상태로 돌입하게 만든다. 만일 빠른 회복 상태에서 타임 아웃이 발생한다면 이 경우엔 슬로우 스타트 단계로 다시 돌입해 cwnd값을 0으로 재설정한다.
아래 그림은 TCP가 혼잡제어를 수행하는 위 내용을 정리한 그림이다.
출처
