TCP / UDP 1 [Network]

TCP, UDP 흔히 통신 프로토콜의 두 강자라고 불리는 이 둘의 차이를 러프하게 설명하면 다음과 같다. 

• UDP : 아무것도 안하는 애
• TCP : 거의 다 하는 애

3, 4계층에서 이루어지는 공정을 간단하게 설명하면 두 개의 host 들 사이에서 datagram을 송수신하는 단계로, 이 송수신 과정에서 발생하는 에러를 검출하고 복구하는 계층이 바로 Transport layer, 4계층이다. (물론 4계층에서는 더 중요한 작업이 있긴 하다.)

 그리고 3계층과 4계층에서 이루어지는 '어떤 프로세스'를 수행하는데 있어 필요한 통신 프로토콜이 바로 TCP, UDP다. 

 

➡️ 3계층 : 컴퓨터와 컴퓨터 사이에 논리적인 줄을 연결하는 것. (라우터를 가운데에 위치시키고 두 개의 줄을 갖는다. But 그렇다고 2개의 IP address를 갖느냐? 그건 아님.)

➡️ 4계층 : 에러 검출 및 복구 계층 + 컴퓨터와 컴퓨터 간의 프로세스, 주고 받는 정보(ex. Port Number) 자체가 더 중요.

• IP address + 프로그램(프로세싱 중)의 식별 번호 = port 번호. 

 

📌 TCP

 4계층(Tranport Layer)에서는 앞서 1, 2, 3 계층에서 잡아내지 못한 에러를 검출하고 복구하는 역할을 한다. 이 때 TCP 는 정보를 주고 받는 과정에서 사용되는 통신 프로토콜로, 통상 메시지로 불리는 정보로 송수신하지 않는다. 대신 byte를 packet 형태로 모아 Segment라는 단위로 정보를 주고 받는다.

 이는 C++ 의 stream 형태와 굉장히 유사한데, 말 그대로 물이 흐르듯 유려~ 하게 byte 정보를 주고 받는다. 이를 두고 TCP를 Stream-Oriented Protocol 이라고도 부르며, 이 segment 정보는 송신 과정에서 사라지거나, 오류를 발생시키기도 한다. 

수신과 송신 과정에서 정보는 항상 같은 속도로 가지 않는다. 그래서 TCP는 정보의 임시 저장을 위한 공간인 버퍼를 필요로 한다. 이 버퍼의 한 가지 방식이 우리가 '큐'에서 흔히 보던 원형 큐다. 

 

 

그럼 이 Byte 정보로 이루어진 TCP segment 의 format 가운데 header 필드를 한 번 살펴보자. 우선 Header라고 하는 영역에는 윈도우 사이즈(정보를 받을 수 있는 저장 영역)가 전체 byte 정보의 일부(16bit)를 차지하고 있으며, 보내는 쪽의 port address와 받는 쪽의 port address도 있다. 이외에도 정보를 잘 수신했다는 통신 정보 Ack도 있으며, 이 내부 byte 정보들을 통해 TCP는 에러 검출 외에도 여러 작업을 수행한다.

 

 

1️⃣ Flow control (흐름 제어)

---

TCP 헤더의 필드 가운데 윈도우 사이즈(rwnd)가 전체 byte 정보의 일정 부분을 차지하고 있는데, 이 윈도우 사이즈는 수신자(받는 쪽)가 받을 수 있는 수신 버퍼의 가용 사이즈를 의미한다.

 

→ 이 때 TCP 흐름 제어 동작(flow control)에서는 ‘받는 자(receiver)'의 입장이 굉장히 중요하다. 클라이언트는 정보를 보내고, 서버는 정보를 받게 되는데 정보를 받을 수 있는 서버의 리시브 버퍼 크기는 정해져 있고, 일단 정보를 주고 받기 시작하면 가용한 버퍼의 용량은 지속적으로 감소하게 된다.

 이때 수신자는(서버) 받을 수 있는 정보의 사이즈를 rwnd 값을 통해 계속 알려주고, 보내는 쪽(클라이언트)에서는 이를 넘어가지 않도록 조절을 하는데, 이것이 바로 TCP의 'flow control(흐름제어 동작)'이다.

 

2️⃣ Error control (에러 제어)

---

TCP뿐 만이 아니고, 모든 통신 기기들은 각각의 목적과 의도에 따라 정보를 송신하고, 수신하는 과정을 반복한다. 이 때 TCP는 그 정보들 간의 인과관계는 배제한 채, 정보 송수신 과정에서 발생한 에러를 검출하고 복구하는 프로세스를 한다.

 

→ 예를 들어 1, 2, 3, 4라는 이름의 정보를 보낸다고 할 때, 이 정보들은 Router라는 통신 기기를 거치면서 순서가 뒤바뀌거나 종종 사라지기도 한다. 그럼 TCP는 도착한 정보들의 순서를 재조합하고, 중간에 잃어버린 정보들을 다시 끼워맞춘다. 이 때 TCP(Transmission Control Process)는 아래 다른 공정과 함께 그 작업을 수행한다.

 

3️⃣ Congestion control (혼잡 제어)

---

 클라이언트와 서버 사이에 있는 네트워크에서 동작하는 혼잡 제어 단계로, 최초의 인터넷과 현재 네트워크에는 현저한 차이가 있다. 최초의 인터넷은 멀리 떨어져 있는 사이에서 이루어지는 공정이었고, 현재는 데이터 센터 내에 있는 서버 to 서버, 즉 가까이서 정보를 주고받는 관계에서 이 혼잡 제어에 대한 인식이 두드러졌다.

 

⇒ 2계층의 IP 네트워크에서 특정 링크나 장치에 트래픽이 순식간에 모이게 되면, 트래픽들이 지나치게 모이게 되는데 이러한 현상을 두고 ‘Conjestion(혼잡)’이라 부른다. 이를 해결하고자 TCP는 두 가지 방식을 제안했다.

1. slow-start
2. exponential increase+) additive increase : 두 배가 아니고 1씩 늘어남. 등등

→ 프로그램 최초 실행 시 cwnd(congestion window)는 무조건 1이다. TCP는 보낼 수 있는 최초의 트래픽을 1로 시작해서 ack가 잘 오면, 2로 증가하고, 다시 잘 응답이 오면 2를 또 곱한다. 즉 제곱의 형태(exponential increase)를 띄고 있다.

 

#️⃣ 정보가 사라지면?

---

TCP는 piggybacking 과 full-duplex라는 동작으로 어플리케이션을 연결하고 주고받는 패킷을 처리한다. 하지만 1970년대 초기 군사 목적으로 시작된 TCP에게 이러한 동작(segment 송수신, ack 주고 받기, 혼잡 제어 등등)은 현대에 이르러 그 속도와 성능 측면에서 발목을 잡게 되었다. 

 

⏩ 모든 TCP는 시작할 때 다 너무 느리다. (혼잡 제어, slow-start 기능 때문에 너무 느림)

⏩ 상대방의 수신 정보에 Ack 를 일일이 확인하고 실제 지연을 지속적으로 파악해야 하는 번거로움이 있다. 

 

 

📌 UDP

TCP 와는 달리 UDP 는 가장 큰 특징으로 4계층에서 에러 검출 및 복구 작업을 하지 않는다는 것에 있다. 3계층까지의 에러에 대해서 크게 신경쓰지 않는다는 말과 같다. 흔히 지하철이나 앨리베이터에서 전화가 자주 끊기고 하지 않던가 (사실 조금 더 복잡한 개념이긴 하지만..)

 여튼 그러면 왜 UDP를 사람들이 계속 쓰는 걸까?? 그 이유는 바로 보내는 정보의 크기와 중요도에 있다. 말 그대로 잃어버려도 크게 중요하지 않은 정보들을 보낼 때 UDP를 사용한다. 마찬가지로 UDP의 header 필드를 한 번 살펴보자. 

보다시피, TCP의 header에 비해 훨씬 크기도 작고 들어있는 정보도 작다. 양쪽에서 송수신되는 정보들은 각각 독립적인 형태로 움직이면서 프로세스에 대한 정보만 싣고 나른다. 이러한 특징 때문에, UDP는 Connectionless Service 라고 부르기도 하며, 앞서 언급했듯 에러 검출 및 복구 작업을 하지 않기 때문에 , Unreliable 한 통신 프로토콜이다. 

 

1️⃣ Connection-less , Unreliable

 

2️⃣ No Error control.

 

 

다음에 계속..!