3회차 네트워크 | TCP, UDP/캐시/로드밸런싱 관련 정리

TCP vs UDP (TCP, UDP 특성)
캐시
로드밸런싱

 

TCP 그림

→ TCP와 UDP는 Transport Layer [전송 계층] 소속 프로토콜이다.

1. TCP와 UDP는 둘다 전송 계층에서 데이터를 보내기 위해 사용하는 프로토콜.
2. TCP는 연결형 서비스로 가상회선 방식을 제공하고 높은 신뢰성을 보장하며 흐름제어 및 혼잡 제어 기능을 제공한다.
3. UDP는 비연결형 서비스로 데이터그램 방식을 제공하고 패킷에 순서 부여나 재조립 등의 기능을 처리하지 않기 때문에 신속한 처리가 중요한 서비스에 사용된다.

---

TCP, UDP [전송 계층]

⬛ TCP (Transmission Control Protocol) | 전송 제어 프로토콜

1) 개념

• TCP : 연결형, 신뢰성 높은 프로토콜 (속도 느림)
• TCP는 패킷 사이의 순서를 보장하고 연결 지향 프로토콜 사용해서 연결하며 신뢰성을 구축해서 수신 여부를 확인한다.
• 전송 단위 : TCP 패킷 (= 세그먼트)

→ TCP 헤더가 붙은 데이터 : 세그먼트

💡 [TCP가 패킷 추적 및 관리 방법] : 각 패킷에 번호 부여
데이터는 패킷 단위로 나누어 같은 목적지 (IP계층)으로 전송된다.
이때 패킷에 번호 부여하여 전송하기 때문에 목적지에서 패킷의 분실 확인 및 재조립이 가능하다.
전송 과정에서 전송 순서 뒤바뀌더라도 수신지에서 재조립함

2) 특징

1. 연결형 서비스로 가상 회선 방식을 제공한다. ⇒ 항상 같은 경로 (전송 순서 보장)
2. 3-way handshaking ( 연결) , 4-way handshaking (해제)
3. 흐름 제어, 혼잡 제어, 오류 제어로 높은 신뢰성 보장
4. UDP보다 신뢰성은 높고, 속도는 느리다.
5. 서버와 클라이언트는 1대 1로 연결된다.
6. 전이중, 점대점 방식

전이중(Full-Duplex) : 전송이 양방향 동시에 일어날 수 있다.
점대점 (Point to Point): 각 연결이 정확히 2개의 종단점을 가지고 있다

💡 ⇒[ 가상 회선 패킷 교환 방식] → TCP는 연결지향형, 순서 보장
항상 같은 경로로 패킷을 전달하고, 3 2 1 순으로 보낸 데이터가 3 2 1 순으로 도착
패킷 전송 순서대로 도착하는 방식
다량의 데이터 연속적으로 보낼 때 ‘논리적 경로’ 배정하여 항상 같은 경로로 패킷이 전달되게 되는데, → 결과적으로 순서를 보장하게 된다.

가상회선

TCP는 가상회선 방식으로 데이터를 주고받기 때문에 항상 같은 경로로 패킷을 전달

 

3) TCP 헤더 구조

✅ 출발지 포트 (송신), 목적지 포트 (수신)
✅ Sequence number (32) = 일련 번호(ISN 넘버) : 전송 데이터 순서
✅ Acknowledgment number(32) 확인 응답 번호 (32)
   : 3-way에서 ACK보낼 때, 승인 번호로 상대방 ISN + 1 보내는 그 번호
    (실제로는 상대방 ISN에 자신이 받은 데이터 byte)로 승인번호 생성
✅ Data offset | 데이터 오프셋 (=헤더 길이)
    : 전체 세그먼트 중 데이터가 시작되는 위치 알 수 O
✅ Reserved (3)
    : 미래에 사용하기 위해 남긴 예비 필드
✅ Flags : 코드 비트 (6) : 연결 제어 필요한 (ACK, SYN, FIN )
✅ 윈도우 크기 : 한 번에 전송 가능한 데이터 크기
✅ Checksum : 체크섬 : 데이터 송신 과정에서의 오류 검출 위한 값
✅ Urgent pointer : 긴급 포인터
    : 긴급한 URG 플래그 1이다 ⇒ 수신 측은 이 포인터가 가리키는 데이터 우선 처리함
✅ 옵션 필드 : TCP 기능 확장 시 사용하는 필드

TCP 헤더에는 목적지까지 데이터를 신뢰성 있게 전송하기 위해 필요한 정보들을 담는다.
[코드 비트 (6) ]에 연결 제어에 필요한 ACK, SYN, FIN 정보 기록함
[일련번호(32) ] : 송신 측. 몇 번째 데이터인지 송신했는지 알려줌
[확인 응답 번호 (32) ] : 수신 측. 몇 번째 데이터 수신했는지 (상대 ISN + 1) 로 알려줌
[체크섬 (16) ] : 오류 검출 방식으로 체크섬 상태 필드값을 통해 해당 패킷 오류 검출 여부 확인

TCP 헤더 구조

---

⬛ UDP (User Datagram Protocol) | 사용자 데이터그램 프로토콜

1) 개념

• UDP : 비연결형, 빠른 프로토콜 (신뢰성 낮음)
• UDP는 순서를 보장하지 않고, 수신 여부 확인하지 않으며 단순히 데이터만 보내는 데이터 그램 패킷 교환 방식을 사용한다.
• 전송 단위 : UDP 패킷 (=데이터그램)

→ UDP 헤더가 붙은 데이터 : UDP 데이터그램

2) 특징

1. 비연결형 프로토콜로 데이터그램 방식을 제공한다. ⇒ 매번 다른 경로 (전송 순서 보장 X)
2. 비연결형이기 때문에 연결 설정/해제 과정 불필요 (연결비용 줄어든다) 3way, 4way 없음
3. UDP 헤더의 체크섬 필드를 통해 최소한의 오류만 검출한다.
4. TCP보다 속도는 빠르고, 신뢰성은 낮다.
5. UDP는 신뢰성 < 연속성 중요한 서비스에 활용한다.
6. 1대 1, 1대 N, N 대 M 으로 서버-클라이언트 연결할 수 있다.
7. TCP와는 다르게 UDP는 중간에 패킷이 유실이나 변조가 되어도 재전송을 하지 않는다
8. 데이터의 전송 순서 보장X
9. TCP와 달리 흐름제어, 혼잡제어 처리 없기 때문에 TCP보다 속도 빠른 대신 신뢰성 낮다.
10. 데이터그램이라는 패킷으로 데이터를 조각내서 전송하지만 패킷 순서나 재조립 등의 서비스는 제공X

💡 ⇒ [ 데이터그램 패킷 교환 방식 ] → UDP 는 비연결형, 순서 보장 X
각 패킷이 모두 다른 경로로 전송되며, 독립적인 패킷으로 전송되는데, 순서도 3 2 1 순으로 보냈음에도 2 3 1 등의 완전 다른 순서로 도착할 수 있다는 거다.
패킷 도착 순서 보장 X 방식

데이터그램 패킷

TCP와 달리, UDP는 비연결형 프로토콜이다.
연결을 위해 할당되는 (고정된) 논리적 경로가 없다.
그래서 각 패킷이 모두 다른 경로로 전송된다.
별도의 경로 설정X 독립적인 패킷으로 전송되며 수신 측에서 데이터를 처리

 

3) UDP 헤더 구조

• 전송 계층에서 효율적으로 빠르게 데이터 보내기 위한 정보들만 담김
• TCP만큼 높은 신뢰성, 정확성 필요하지 않아서, 확실히 헤더가 가볍다.
• 체크섬으로 최소한의 오류 검출함

UDP 헤더 구조

---

TCP 관련 추가 정리

SYN (Synchronization) : 연결 요청 플래그

ACK (Acknowlegement) : 응답 플래그

ISN (Initial Sequence Numbers) : 초기 네트워크 연결 시 할당된 32비트 고유 시퀀스 번호

→ 여기서 ISN은 새로운 TCP 연결의 첫 번째 패킷에 ‘랜덤으로 할당된’ 시퀀스 번호

---

⬛ TCP 연결 성립 | 3-way HandShake

• 데이터 보내기 전에 연결 확립을 위해 ‘패킷 요청을 3번 교환’하는 것

3 way 핸드셰이킹

1) SYN 단계

• 클라이언트는 (클라이언트의 ISN)을 담아서 SYN을 서버에 보낸다.

2) SYN + ACK 단계

• 서버는 클라이언트의 SYN에 대한 ACK를 보내고,
• 이때 함께 [서버의 ISN] + 승인번호 (클라이언트의 ISN + 1) 값을 보낸다.

3) ACK 단계

• 클라이언트는 다시 서버의 SYN에 대한 ACK를 보내주는데,
• 함께 승인번호로 [서버의 ISN + 1] 값을 보낸다.

→ 이로서 연결 확립됨

---

⬛ TCP 연결 해제 | 4-way HandShake

4 way 핸드셰이

1단계

• 클라이언트가 연결 종료 요청 FIN 보낸 뒤 자체적으로 FIN_WAIT_1 상태로 들어가서 서버 응답 대기

2단계

• 서버는 클라이언트의 FIN에 대해 확인했다는 ACK(승인)를 보내고, 서버는 CLOSE_WAIT 상태로 들어간다. (모든 데이터를 보내기 위해)
• 클라이언트는 서버의 ACK 받으면 FIN_WAIT_2 상태로 들어간다.

3단계

• 서버는 CLOSE_WAIT 상태에서 데이터를 마저 다 보내고, 연결 종료 되었다는 FIN을 클라이언트에 보낸다.
• 이걸 받고 클라이언트는 TIME_WAIT 상태가 된다. //아직 서버로부터 미처 받지 못한 데이터 남아있을 가능성 때문에 대기

4단계

• 클라이언트는 서버로 ACK 보내고
• 서버는 ACK 받은 이후, 소켓을 닫는다. CLOSED 상태가 된다.
• 이후 클라이언트도 TIME_WAIT 상태에서 2MSL만큼의 시간 대기 시간 끝나면 CLOSED 된다.

→ 이로써 클라이언트와 서버 간의 연결이 해제된다.

→ 최근에는 FIN/ACK 동시에 보낸다. 매번 어떤 식으로 ? (뭐에 대한 ACK를 보내는지 ? ) 조사

💡 Q. 왜 연결-해제 과정은 각자 3단계, 4단계로 차이가 날까 ? FIN→ (ACK+FIN) →ACK 보내면 되는 거 아닌가 ?
[답변] 서버가 아직 보낼 데이터가 남아있을 수 있기 때문에, 먼저 클라이언트가 보낸 FIN에 대한 ACK보낸 뒤 일정 시간 CLOSE_WAIT 상태였다가, 서버가 닫기 전 남은 데이터를 마저 다 보낸 후에야 다시 FIN을 보내기 때문이다.

---

TCP 연결과 관련한 추가 정리

TCP 연결에서 active close를 수행하는 쪽은 2MSL 동안 TIME_WAIT 상태를 유지해야 합니다

⬛ TIME_WAIT

• 클라이언트 쪽에서 서버의 FIN 받자마자 세션 닫아버리면, (네크워크 지연 등의 이유로) 지연 패킷이 발생할 경우 데이터가 유실된다.
• 이런 상황을 방지하기 위해 클라이언트는 서버로부터 FIN을 수신하더라도 일정 시간 동안은 대기했다가 CLose를 한다.

💡 Q. 왜 굳이 일정 시간 TIME_WAIT 후에 닫을까 ?
1) 지연 패킷이 발생할 경우 대비
2) 두 장치가 연결 닫혔는지 확인 목적

⬛ 2MSL (Maximum Segment Life Time) : TIME_WAIT 상태에서의 대기시간

• 신뢰성 있는 연결 종료를 위해
• 네트워크 상의 패킷이 모두 소멸을 위해
• TIME_WAIT 상태에서 2MSL만큼 기다린 후 이전에 사용한 패킷이 모두 소멸하도록 기다려야 한다.

---

[타임 아웃 (Timeout) 정리]

→ 프로그램이 특정 시간 내에 성공 수행되지 않아 자동으로 중단되는 것

• Connection Timeout은 초기 연결 과정에서 시간 초과가 난 상황을 말하고,
• Read timeout은 데이터를 읽는 동안 대기 시간 초과입니다. 서버에서 데이터를 받아오는데 시간 초과가 난 경우입니다.

Timeout 구간

---

⬛ TCP의 (흐름제어, 혼잡제어, 오류제어) → 신뢰성 보장

⇒ TCP 흐름 제어

: 송/수신 간에 데이터 처리 속도 차이 해결 기법

• 송신 측과 수신 측 사이의 ‘데이터 처리 속도 차이’가 다를 수 있다.
• 송신 측이 더 빠르다면 수신 측 버퍼가 넘치는 오버플로우 문제가 발생한다.
• 이런 문제를 해결하기 위해 크게 2가지 방법이 있다.

[흐름 제어 기법]

(1) stop and wait : 패킷 1개 전송 후 ack가 오면 다음 패킷 보내는 방법

→ 간단하지만 속도 느림

(2) 슬라이딩 윈도우 : 수신 측이 설정한 윈도우 크기만큼 송신 측이 확인 응답 없이도 데이터를 연속적으로 보내는 기법

→ 확인 응답이 오면 그 크기만큼 윈도우를 늘린다.

---

⇒ TCP 혼잡 제어

: 네트워크 혼잡 피하기 위해 송신 측 데이터 전송 속도 강제로 줄이는 기법

• 송신 측 데이터 전달 ↔ 네트워크 데이터 처리 속도 차이 해결하기 위한 기법
• 혼잡 : 네트워크 내에 패킷 수가 과도하게 증가하는 현상
• 혼잡 제어 : 혼잡 현상 방지하고 제거하기 위한 기능

[혼잡 제어 기법]

(1) AIMD (Additive Increase / Multiplicative Decrease) : 합 증가 곱 감소 알고리즘

• 패킷 전송 문제 없으면 window 크기를 1씩 증가
• 패킷 전송 문제 있으면 보내는 속도를 절반으로 감소시킨다.
• 단점 : 초기 전송 속도 느리고, 네트워크 혼잡 상황 미리 감지 못한다. (즉, 네트워크 혼잡해지고 나서야 대역폭을 줄이는 방식이다.)

(2) Slow Start (느린 시작)

• 윈도우 크기를 2배씩 늘린다.
• 혼잡 현상 발생 시 크기를 1로 감소시킨다.
• 그 후엔 혼잡이 발생한 절반까지만 2배로 늘려 전송하고 1씩 증가한다.

(3) Fast Retransmit (빠른 재전송)

• 패킷 손실된 경우, 이전 순서까지 완료됐다는 ACK를 보내기 떄문에 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다.
• 이것을 ACK를 3개 받으면 재전송 하고 혼잡 감지하고 윈도우 크기 줄이게 된다.

→ 네트워크 혼잡 시, 순서가 중복

(4) Fast Recovery (빠른 회복)

• 혼잡 발생 시 윈도우 크기를 절반으로 줄이고 선형 증가시킨다.
• 혼잡 상황 한번 겪고 나면 AIMD 방식으로 동작하게 된다.

---

⇒ TCP 오류 제어

: 데이터 유실되거나 잘못된 데이터 수신 시 (오류 검출 시) 대처하는 방법

• TCP는 통신 중에 오류가 발생하면 해당 데이터를 재전송한다.
• 이때, 재전송 기반 오류 제어 [ARQ (Automatic Repeat Request)] 를 사용한다.
• 재전송 자체가 비효율적이므로 최대한 적게 사용하는 게 좋다 .

[오류 검출 방법]

(1) 송신 측이 ACK(긍정 응답)을 못 받음

→ 송신 측이 보낸 데이터가 전송 과정에서 유실됐거나, 수신 측이 보낸 ACK 자체가 유실된 경우

(2) 중복된 ACK를 받는다.

(3) 수신 측이 NACK(부정 응답)을 보냄

---

[재전송 기법] ARQ 기법

(1) Stop and Wait : 하나씩 전송

• ACK를 받고 난 뒤에 다음 데이터를 보내는 방식이다.
• 일정 시간 지나서 timeout이 발생하면 이전 데이터를 재전송한다.

(2) Go Back N : 손실된 패킷 이후를 모두 다시 재전송

• 연속적으로 데이터 보내다가 오류 발생한 지점부터 재전송하는 방식이다**.** (순서는 보장)
• 오류 발생 지점 이후에 제대로 보낸 데이터까지 재전송 하는 방식이라 비효율적이다.

(3) Selective Repeat | ARQ : 손실된 패킷만 재전송

• 오류가 발생한 손실 데이터만 재전송하는 방식이다. (순서가 보장 X)
• (2) 의 GBn 기법은 발생 이후를 모두 삭제하기 때문에 적어도 데이터는 순차적일테지만,
• (3)의 SR 기법은 손상 데이터만 재전송하기 때문에 별도로 재정렬이 필요하다.
• 따라서 별도의 데이터 재정렬 수행해야 하고, 별도의 버퍼도 필요로 한다. (유지비용 증가)

---

로드밸런서와 로드밸런싱

웬만한 서비스들은 1대의 서버로 모든 트래픽 감당하기 부족하다.

이에 대한 대응 2가지

(1) Scale-up 스케일업 : 하드웨어 성능 올리기

(2) Scale-out 스케일 아웃 ; 여러 대 서버가 나눠서 작업하는 것

→ 스케일 아웃 자체가 로드 밸런싱은 아니다. 어떻게 할지 중 로드밸런싱을 활용하는 것

---

⬛ 로드 밸런싱 (Load Balancing) | 기술

• 둘 이상의 CPU or 저장 장치 같은 컴퓨터 자원들에게 작업을 분산시키는 것
• 그 중 스케일 아웃 : 여러 서버에게 균등하게 트래픽 분산시켜 처리하는 ‘로드 밸런싱’이다.

⬛ 로드 밸런서 (Load Balancer) | 서버 분산 장치

• 여러 서버에 부하를 나누어주는 시스템
• 로드 밸런서를 클-서버 사이에 두고 부하 일어나지 않도록 여러 서버에 분산시키는 역할

---

⬛ 로드 밸런싱 작동 방식 (2)

1) L4 로드 밸런싱

• OSI 7 계층의 4번쨰 계층인 Transport Layer에서 로드 밸런싱을 해주는 것
• 사용자는 로드 밸런서에 먼저 접속하고
• 로드 밸런서는 여러 대의 웹 서버 중 한 곳으로 포워딩 해준다.

→ L4 로드 밸런싱은 TCP와 UDP 포트 정보를 바탕으로 한다.

→ 데이터의 내부 보지 않고 패킷 레벨에서만 로드를 분산하기 때문에 속도 빠르고 효율 높다.

2) L7 로드 밸런싱

• OSI 7계층의 최상단 Application Layer에서 로드 밸런싱을 해주는 것
• (HTTP 헤더, 쿠키 등과 같) 사용자가 요청한 것을 기준으로 더 섬세하게 특정 서버에 트래픽 분산이 가능
• L4에 비해 더 섬셈한 라우팅 가능하고 비정상적 트래픽 필터링도 가능하다.
• 다만, 패킷 내용 복호화를 해야 하기 때문에 더 많은 시간 소요된다.

---

⬛ 로드 밸런싱 알고리즘

• 서버 부하를 고르게 분산시키는 알고리즘

1) 라운드 로빈

• 클라이언트 요청 여러 대 서버에 순차적 분배

2) 가중 라운드 로빈

• 각 서버에 가중치 지정 후 가중치 높은 서버에 우선적으로 클라이언트의 요청 전달

3) 최소 연결 방식 (Least Connection)

• 요청이 들어온 시점에 가장 적게 연결된 서버에 요청을 전송하는 방식 // ? 무엇과 적게 연결?

→ L4 에선 가상 회선 연결 // L7에선 가장 적은 연결(세션) 상태 보이는 서버에 우선적 할당

4) 최소 응답 시간 (Fastest Response Time)

• 서버 현재 연결 상태, 응답 시간 모두 고려하여 가장 적은 연결 수와 가장 짧은 응답 시간 갖는 서버에 우선 요청 보냄 // 세션 부하를 확인하여 그것에 맞게 부하 분산

5) IP 해시 방식

• 사용자 IP 해싱하여 부하 분산시켜 사용자가 항상 동일한 서버로 연결되는 것 보장

---

⬛ 로드 밸런서 장애 대비

한 대의 로드밸런스 서버가 여러 대의 서버로 요청을 분산하기 때문에 로드 밸런스 서버 자체가 장애나면 서비스 전체가 정지될 수 있다.

따라서, 로드 밸런서를 이중화(= 고가용성 로드밸런서)하여 대비한다.

• 고가용성 로드밸런서 = 마스터 + 스탠바이 역할
• 마스터 서버가 장애나면, 대기 중이던 스탠바이 서버가 로드밸런서 역할 담당함

---

캐시

→ 캐시 교체 알고리즘 : Cache Miss 시 데이터를 Cache에 저장해야 하는데, 저장 공간이 작기 때문에 기존 데이터를 삭제하고 찾아온 데이터를 넣어줘야한다. 데이터 삭제시 어떤 데이터를 삭제할 것인가도 여러가지 방법이 있다.

⬛ 캐시 (Cache)

1) 개념

• 이미 가져온 데이터나 계산된 결과값의 복사본을 임시적으로 저장함으로써 처리 속도를 향상시키며, 이를 통해 향후 요청을 더 빠르게 처리가능함
• 자주 사용하는 데이터의 경우 캐시에 담아두고 프로세서가 메인 메모리 대신 캐시에 접근하도록 하여 처리 속도를 높여주는 것
• 애플리케이션 처리 속도 높여준다.
• 반복적이고 동일 결과 나오는 데이터 / 자주 조회되는 데이터 / 입력값과 출력값이 일정한 데이터
• 캐싱된 데이터가 ‘데이터 갱신’으로 DB와 불일치할 수 있기 때문에 업데이터 잦은 데이터는 캐싱 대상으로 부적합하다.

2) 종류

⬛ 로컬 캐시 | (Local Cache)

• 로컬 메모리 (즉, 내부 저장소) 에 데이터 저장
• 따라서 서버마다 캐시를 따로 저장
• 다른 서버의 캐시는 참조 어려움
• 서버 내에서 작동하므로 속도 빠르다
• 로컬 서버 장비의 메모리 or 디스크 이용

💡 → 캐시 결과를 삭제하거나 변경할 때 해당 서버에만 적용이 되고
다른 애플리케이션 서버는 캐시 정책에 따라 만료될 때까지 정합성이 맞지 않는 경우가 발생함

⬛ 글로벌 캐시 | (Global Cache)

• 서버 외부에 [캐시 저장소]를 따로 둠
• 여러 서버에서 캐시 서버에 접근하여 참조 가능
• 별도의 캐시 서버 이용하므로 서버 간 데이터 공유 쉬움
• 네트워크 트래픽 사용해야 하니 로컬 캐시보다 속도 느림

💡 → 캐시 서버를 따로 분리하여 캐시 결과를 저장하고
캐시가 필요할 때 하나의 서버에 요청하기 때문에 캐시 결과의 변경 사항을 동기화할 필요 없음

→ 글로벌 캐시의 사용 예시 CDN

🎈 CDN이란 ?

• Content Delivery Network
• 지리적 제약 없이 전 세계 사용자에게 빠르게 컨텐츠 전송하는 기술
• CDN의 원리는 간단하다. 정적 컨텐츠(동영상, Text, 사진 등등)를 메인 서버(오리진 서버)에서 제공하는 것이 아니라, 사용자 근처에 있는 엣지 서버(CDN 캐시 서버)에 미리 넣어놓고 사용자가 요구하면 메인 서버 대신 그 데이터를 넘겨주는 서비스를 의미한다

로컬 CDN은 국내에만 캐시 서버(PoP: Point of Presence)가 생성됩니다

반면, 글로벌 CDN은 국내뿐만 아니라 북미, 유럽, 아시아, 남미, 호주 등 전 세계 주요 지역에 캐시 서버가 생성됩니다.