[네트워크] L4 Transport (전송 계층) -TCP, UDP, RTP, RTCP

✍️ L4 Transport (전송 계층)

TCP	UDP
Virtual Connection Non Real Time 신뢰성 Delay	Datagram 방식 Real Time 비 신뢰성 Simple (간결)

👉 TCP는 가상 회선(Virtual Connection) 즉, 논리적 경로를 설정하여 데이터를 전송하고, UDP는 경로를 설정하지 않고 데이터들을 독립적으로 전송하는 방식이다. 이 때 데이터를 TCP에서는 세그먼트, UDP에서는 데이터그램이라 부른다. 

 

PDU (Packet Data Unit)란, 프로토콜 데이터 단위의 약자로 각 계층에서 처리하는 데이터 단위를 말한다. 

상위 계층에서는 데이터, L4 Transport에서는 세그먼트/ 데이터그램 L3 Network에서는 패킷, L2 DataLink에서는 프레임, L1에서는 비트라고 한다.

 

👉 TCP는 논리적인 연결을 맺어야 하기 때문에 Real Time 서비스가 아니고, 반면에 UDP는 독립적으로 전송하므로 Real Time 서비스에 적합하다. 

 

👉 신뢰성을 보장하기 때문에 TCP가 더 좋은 프로토콜이라고 말할 수는 없다. 상황에 따라 쓰임이 다를 뿐이다. TCP가 좋은 프로토콜이라 생각하여 전화를 TCP로 구현한다고 상상해보자. 말 한마디 한마디를 다 검사하여 보내고, 잘 보내졌는지 확인하면 전화의 의미가 없어진다. 약간 끊김이 있더라도 실시간 통신으로 구현하는 것이 효율적이다.(실제로 전화를 할 때 목소리가 어눌하게 들린다고 해서 소통이 안되는 것도 아니고..) 이렇듯 상황에 따라 적절한 프로토콜을 사용하는 것이 중요하다.

✍️ 포트번호 (Port #)

👉 Well-known Port (0~1023)

- 어떤 특권을 가진 서비스에 의해 사용될 수 있도록 예약되어있다.

- 루트권한으로만 포트를 열 수 있다. 루트 권한으로 실행된 프로그램만이 이 포트에서 데이터를 수신할 수 있지만, 권한에 상관 없이 모든 프로그램이 이 포트로 데이터를 보낼 수 있다.

👉 Registered Port (1024 ~ 49151)

- 서버 소켓으로 사용하는 영역

👉 Dynamic Port (49152 ~ 65535)

- 매번 접속할 때마다 포트번호가 동적으로 부여

- 서버 소켓 포트로 사용할 수 없다.

 

✍️ TCP (Transmisson Control Protocol, 전송 제어 프로토콜)

👉 TCP는 가상 회선(Virtual Connection) 즉, 논리적 경로를 설정하여 데이터를 전송한다.

    📌 왜 :  L3:인터넷 프로토콜 (IP)의 신뢰성을 보장하기위해

 

👉 TCP는 신뢰성을 보장하기 위해 다양한 방법을 쓴다. 아래에서 자세히 알아보자!

 

✏️ 3-way handshaking

: Virtual Connection을 만들기 위한 과정이다. IP는 비신뢰성 프로토콜로 패킷이 도착했는지 안했는지 상관하지 않는다. 이에 클라이언트와 서버 모두 데이터를 전송할 준비가 되어있다는 것을 SYN-ACK, ACK를 주고받음으로써 보장하고, 실제로 데이터 전달이 시작하기 전에 서로 준비되어 있다는 것을 알 수 있도록 한다.

[3-way handshaking]

 

[Wireshark로 본 3-way handshaking]

 

✏️ TCP Timer

: 수신측으로부터 확인 응답 메시지를 기다리며 확인 응답이 오지 않을 경우 세그먼트를 재전송한다. 재전송 타이머, 영속 타이머, 킵얼라이브 타이머, 시간-대기 타이머가 있다.

 

📌 재전송 타이머(Retransmission Timer)

- 타이머가 끝나기 전에 세그먼트에 대한 확인 응답이 수신되면 타이머는 소멸

- 확인응답이 수신되기 전에 타이머가 종료될 시 세그먼트는 재전송되고 타이머는 초기화

 

📌 영속 타이머 (Persistence Timer)

Window Probe Packet : 아직도 Window Size 0 이야? 묻는 패킷

- 1Byte

- 수신측 상황을 주기적으로 점검

- ACK 응답 유도

- 교착상태방지 ( Deadlock )

: 수신측에서 진짜 바빠서 ACK를 못보내는건데 송신측에서 관심이 없다 생각하여 Virtual Connection을 끊어버릴 수도, 수신측은 Window Size가 생겼음에도 송신,수신 측 모두 그냥 기다리는 현상

 

📌 킵얼라이브 타이머 (KeepAlive Timer)

- 두 TCP의 연결이 장기간 휴지(Idle)상태인 것을 방지하기 위해 사용

- 2시간이 지나도록 세그먼트를 수신하지 못하면 Probe 세그먼트 전송

- 75초 간격으로 10개의 Probe전송에도 응답이 없으면 연결 해제

시간-대기 타이머 (Time-Wait Timer)

- 중복, 지연 패킷을 처리하기 위한 타이머

- 연결 종료 동안 연결을 유지하며 그 안에 old Packet 도착한 경우 Discard

 

✏️ TCP 헤더 

: 20 Byte + Option(최대 40Byte) 로 최대 60Byte이다.

 

간략하게 설명하자면,

📌 Source port address : 출발지 포트 번호

📌 Destination port address : 목적지 포트번호

📌 Sequence number : 순서번호로, 3-way handshaking 및 sliding window에서 사용한다. 3-wat handshaking에서의 seq로 내가 보내는 세그먼트가 무엇인지 표시해주는 역할을 하며, sliding window에서는 내가 못 받은 패킷이 무엇인지 알려주는 역할을 한다. 

📌 Acknowledgement number : 세그먼트를 잘 받았다고 알려주는 역할을 하며, seq +1로 보낸다.

📌 HLEN: 헤더 길이를 의미하며, 4비트 즉 15까지 표현이 가능하다. 따라서 HLEN * 4로 헤더 길이를 표시한다.

📌 Reserved : 예약된 필드, 현재 사용되지 않는다.

📌 플래그

   - U (Urgent) : 긴급 비트, 이 비트가 설정되어 있으면 우선순위가 높다. Urgnet Pointer와 세트
   - A (Ack) : 응답 비트, 세그먼트 잘 받았을 때 사용 (통신 체크)
   - P (Push) : TCP 버퍼와상관없이 데이터를 계속 밀어 넣겠다
   - R (Reset) : 상대방과 연결 상태를 리셋한다. (어떤 문제 등이 발생했을 때 사용)
   - S (Syn) : 동기화 비트, 상대방과 연결을 시작할때 사용되는 플래그
   - F (Fin) : 종료 비트 (정상 종료를 의미)

여담으로 보안기사등 시험에서 플래그를 외워야 하는 경우가 있는데, UAPRSF 우아 프로스펙트다-! 라고 외우면 편하다.

📌 Window size : TCP 흐름제어 할 때 사용. 수신 버퍼가 얼마나 남았는지 확인하고 사이즈에 맞게 데이터를 송신한다.

📌 Checksum : 에러검출 할 때 사용.

📌 Urgent Pointer : 긴급하게 처리해야 할 필요가 있는 데이터를 의미

✏️ 흐름제어 (Flow Control)

: 수신 측의 버퍼 상태를 확인하고, 꽉 차려고 하면 전송속도를 줄이고 비어있다면 원활한 전송을 시행 (Window Size를 기재해서 알림)

📌 Sliding Window (슬라이딩 윈도우)

 

✏️ 오류제어 (Error Control)

- TCP는 통신 중에 오류가 발생하면 해당 데이터를 재전송한다. 

 

📌 Stop & Wait : ACK를 받으면 다음 데이터를 보낸다. 하나 보내고 ACK 받으면 다음 데이터를 보낸다. 이때 ACK가 오지 않는 데이터를 재전송 하는 방법이다. 

📌 Go Back N : 연속적으로 데이터를 보내다 오류가 발생한 시점부터 다시 보낸다. 예를 들어, 세그먼트를 6개 보냈다고 가정했을 때, ACK 가 1,2,4,5,6을 받으면 3부터 다시 보내는 방식이다. 

📌 Selective Repeat: 오류가 발생한 데이터만 재전송한 방식이다. 위 같은 상황이 발생했을 때 3번째 세그먼트만 보내준다. 재조합이 필요해서 수신측에서 별도의 버퍼가 필요하다.

 

✏️ 혼잡제어 (Congestion Control)

- 각 노드마다 연결된 파이브(전송선)의 크기가 다르기 때문에 작은 파이브를 만나면 손실이 발생할 수도 있다. 이러한 중간노드의 혼잡상태를 제어하는 것

 

📌 Slow Start :정해놓은 RTT 기간동안 ACK가 오면 2배씩 증가시켜서 보냄 즉, 아주 작은 값 1부터 시작해서 전송 속도를 증가 시키는 방법이다. 여기서 증가하는 숫자는 윈도우 사이즈를 말한다.

      RTT(Round Trip Time, 왕복시간)

📌 Congestion Avoidance(Additive increase): 정해놓은 RTT 기간동안 ACK가 오면 +1씩 증가시켜서 보냄 즉, 이름 그대로 천천히 속도를 높이는 방법을 말한다. Slow Start 과정에서 임계점에 도달하면 Additive increase로 전환한다.

📌 Fast Recovery(Multiplicative decrease): Congestion이 발생하면 처음부터가 아닌 중간지점에서부터 시작한다. 병목 현상(혼잡)이 발생하면 데이터 전송량을 1/2 반으로 줄인 다음 Additive increase 단계로 돌아가서 전송량을 늘린다.

📌 Tahoe TCP

 : Slow start로 시작해서 임계점(Threshold)에 도달하면 Additive increase로 전환한다. 이 때 혼잡이 발생하면 초기 상태로 돌아와 다시 Slow start부터 시작한다. 이 때, 임계점은 혼잡이 발생한 시점의 절반이 된다. 

 : 위 파란색 그래프를 보면 첫 임계점은 8이고 12에서 혼잡이 발생했다. 이후 다시 초기 상태인 1부터 시작하며, 임계점은 혼잡이 발생한 12의 절반인 6이 된 것을 확인할 수 있다.

 

📚 정리 (요약)

① 일정시간동안 ACK가 오면 2배씩 증가한 cwnd를 보냄

② congestion이 발생하면 처음부터 다시 전송 (cwnd의 양을)

③ 2배씩 보내다가 ssthresh = congestion/2 지점부터는 +1씩 전송: Congestion Avoidance

 

📌 Reno TCP

 : Reno 는 Tahoe의 다음 버전으로, 3 duplicate ACKS와 TIMEOUT을 구분한다는 점이 다르다. 처음은 Tahoe와 똑같이 진행을 하다 혼잡이 발생한다. 이 때 3 duplicate ACKS라고 판단할 경우 윈도우 사이즈를 절반으로 줄이고 Additive increace로 속도를 설정한다. (위 검은색 그래프를 참고하면 된다.) 만약 TIMEOUT이라고 판단할 경우 Tahoe와 마찬가지로 1부터 시작해서 Slow start부터 시작한다. 두 상황 모두 임계점은 혼잡이 발생한 시점의 1/2이다.

 

📚정리 (요약)

① RTT동안 ACK가 오면 2배씩 증가한 cwnd를 보냄: slow start

② congestion이 발생하면 처음부터 2배씩 증가하며 전송

③ ssthresh = congestion/2 지점부터는 Congestion Avoidance

④ Congestion 발생 시 기존 sstresh +3 지점부터 cwnd 보냄: Fast Recovery

변경된 ssthresh =congestion/2

 

더 자세하고 친절한 설명은 블로그를 참조 하기 바란다. ( 혼잡 제어 부분이 미흡하여 해당 블로그를 보고 정리해서 올린다 😢)

 

✍️ UDP (User Datagram Protocol)

👉 인터넷에서 정보를 주고받을 때, 서로 주고받는 형식이 아닌 한쪽에서 일방적으로 보내는 방식의 통신 프로토콜

👉  Real Time Protocol

: 인터넷상에서 서로 정보를 주고받을 때 정보를 보낸다는 신호나 받는다는 신호 절차를 거치지 않고 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜. 보내는 쪽에서 받는 쪽이 데이터를 받았는지 받지 않았는지 확인할 수 없고, 또 확인할 필요도 없도록 만들어진 프로토콜

👉 Best Effort : 말 그대로 빠른 시간 내에 데이터 전송을 최우선으로 한다. 데이터의 손실(Loss)나  데이터가 순서대로 도착(Out of order)을 보장하지 않는다. (즉 데이터에 대한 품질(QoS)는 보장하지 않는다.)

👉 Connection-less

👉 헤더 8 Byte : Source/Destination Port#, segment, checksum

 

✍️ RTP (Real Time Protocol)

👉 실시간으로 음성이나 동화를 송수신하기 위한 전송 계층 통신 규약으로, 실시간 전송을 제공하는 프로토콜

👉 4.5계층 (UDP 위에 있다.)

 

✏️ 실시간 서비스란?

: 일반 고속 통신 서비스와는 구분되는 특징이 있다. 파일 전송, 전자 메일 같은 전통적인 인터넷 서비스 환경에서 가장 중요한 사항은 신뢰성이며 부차적으로 전체 네트워크 시스템의 성능과 지연 문제가 다루어진다. 이에 비해 실시간 서비스에서는 전송 시간이 중요하다. 송신 프로세스가 전송한 데이터의 전송 간격이 수신 프로세스에 그대로 유지되도록 하는 것이 중요하며 대부분 특정 데이터가 정해진 시간 안에 반드시 도착하도록 요구한다. 특정 시간을 초과하여 도착한 데이터는 결과적으로 무용지물이 되고 만다.

 

✏️ 출현 배경

: 인터넷에 사용하는 기존의 TCP와 UDP는 실시간 서비스에서 요구하는 전송 특성을 충분히 지원하지 못한다.

📌 TCP는 패킷의 순서와 신뢰성이 지나치게 강조되어 패킷의 재전송 기능과 복잡한 흐름 제어 기능으로 인해 실시간 환경에는 부적합하다.

📌 UDP는 기능이 단순하여 빠른 데이터 전송을 지원하지만 데이터그램의 순서를 보장하지 못한다는 문제가 있다.

따라서 실시간 데이터 전송 서비스의 특성을 지원할 수 있는 새로운 형태의 프로토콜이 필요하게 되었다.

TCP와 UDP를 근간으로 인터넷 환경에서 실시간 서비스를 제공하는 가장 현실적인 방법 중 하나는 UDP에 데이터그램 순서 번호 기능을 추가하는 것이다.

 

✏️ RTP의 특징

① 불규칙하게 수신되는 데이터 순서를 정렬하기 위해 타임스탬프(Time stamp) 방식을 사용한다.

② 프로토콜 동작이 응용 프로그램의 라이브러리 형태로 구현되는 ALF(Application Level Framing) 방식을 사용하기 때문에 프로토콜 내부에 위치하는 버퍼의 크기를 각 응용 프로그램마다 별도로 관리하기가 용이하다. 따라서 응용 환경이 요구하는 알고리즘에 따라 버퍼 크기를 개별적으로 조절할 수 있다.

 

실시간 응용 서비스에 유용하다. 그러나 자원 예약이나 QoS 보장 같은 기능은 제공하지 못하므로 실시간 동영상 서비스를 지원하기에 아직 부족한 면이 있다.

 

✏️ UDP로 RTP 서비스 할 때 문제점 해결

📌 RTP는 실시간 서비스를 제공하기 위해 작고 빠른 전송 기능을 제공하는 UDP 위에서 구현된다. 따라서 비연결형 서비스를 제공하는 UDP의 데이터그램 분실이나 도착 순서 변경 같은 전송 오류는 RTP 자체에서 해결해야한다. 그리고 UDP에서 제공하는 포트주소 기능등을 사용하여 송수신 프로세스 간의 연결을 관리한다.

📌 UDP는 실시간 서비스에 필요한 기능을 전부 제공하지 않기 때문에 RTP의 내부 기능에 이와 관련된 사항을 구현해야 한다. 대표적인 예가 데이터 순서 번호 기능을 대체할 수 있는 기능을 작성하여 데이터 분실과 순서 변경 오류를 해결하는 것이다.

 

✏️ RTP를 Router에 못 올리는 이유

📌 RTP는 4.5계층으로 UDP를 처리하고 RTP를 처리한다.( Router는 3계층까지 구현 )

📌유효한 Data인지는 End Host에 가봐야 알 수 있다.

 

✍️ RTCP (RTP Control Protocol, RTP 제어 프로토콜)

👉 RTP는 데이터 전송 프로토콜, 이를 제어하는 프로토콜이 RTCP

👉 Session에 관한정보

ex Conference Call

위와 같이 화상 회의를 하는 경우 Port#와 Application ID가 같으므로 Session ID로 구분하여 각 해당 창에 띄운다.

 

📌 마무리

마무리를 제대로 못 짓겠다 😥😥 아래 포트폴리오에서 보듯이 갑작스럽게 마무리 하고 다음 파트로 넘어갔는데, 6년전에 쓴 포트폴리오라 기억이 잘 안나서 공부하고 추가해야겠다. 마지막 세션 ID는 교수님께서 RTP 예로 화상 전화를 들어주셔서 정리하다 만 거 같다. 우선  포트폴리오에 있는 자료를 먼저 포스팅하고 내용을 덧붙이는 형태로 진행을 해야겠다.

 

📝 포트폴리오 원본