IP의 한계와 포트

IP프로토콜

IP의 특징

• 신뢰할 수 없는 프로토콜
  패킷이 수신지까지 제대로 전송되었다는 보장을 하지 않음
  통신과정에서 패킷이 잘못 전송되어도 이를 확인하지 않고, 재전송도 하지않으며,
  순서대로 패킷이 도착할것이라는 보장도 하지 않는다는 의미
• 비연결형 프로토콜
  송수신 호스트 간에 사전 연결 수립 작업을 거치지 않음
  그저 수신지를 향해 패킷을 보내기만 할 뿐

IP는 왜 신뢰할 수 없는, 비연결형 통신을 할까?

주된 이유는 성능!
신뢰할 수 있는 연결형 통신 =

• TCP
  연결형 통신을 가능하게 함
  송수신하는 동안에는 연결을 유지하고, 송수신이 끝나면 연결을 종료
  신뢰성있는 통신을 가능하게 함
  재전송을 통한 오류 제어, 흐름 제어, 혼잡 제어 등 다양한 기능들을 제공
• UDP
  신뢰할 수 없는 통신, 비연결형 통신

포트를 활용한 애플리케이션 식별

포트: 네트워크 상의 애플리케이션 식별 정보

포트의 분류

• 잘 알려진 포트(well-known port)
  0번부터 1023번까지 포트
  시스템 포트
  범용적으로 사용되는 애플리케이션 프로토콜이 일반적으로 사용하는 포트 번호를 의미
  

• 등록된 포트 (registered port)
  포트번호 1024번부터 49151번까지
  잘 알려진 포트에 비해서는 덜 범용적
  흔히 사용되는 애플리케이션 프로토콜에 할당하기 위해 사용

• 동적 포트 (dynamic port)
  특별히 관리되지 않는 포트 번호 범위 : 자유롭게 사용가능
  서버는 대부분 잘 알려진 포트와 등록된 포트 사용
  클라이언트는 대부분 동적 포트 사용 ex)웹 브라우저

응용 계층을 식별하는 전송 계층

윈도우 - 리소스 모니터 - 네트워크 - TCP연결을 확인해보면
크롬 브라우저는 원격주소 호스트의 원격번호를 보고 프로토콜을 파악할 수 있다

NAT

NAT 변환 테이블 : 변환의 대상이 되는 IP 주소 쌍

• 사설 IP 주소 하나 당 공인 IP 주소 하나가 대응 : 많은 사설 IP 주소를 변환하기에는 무리가 있음
• 공인 IP 주소의 낭비 : 사설 IP 주소의 수 만큼 공인 IP 주소가 필요

포트기반의 NAT, NAPT

• NAPT 또는 APT
• NAPT는 NAT 테이블에 변환할 IP 주소 쌍과 더불어 포트 번호도 함께 기록하고, 반환

포트포워딩

가령..
네트워크 내부의 여러 호스트가 공인 IP 주소를 공유하는 상황
네트워크 외부에서 내부로 통신을 시작하는 상황
외부 호스트 입장에서는 어떤 IP주소를 수신지 주소로 삼아야 할까?

• 네트워크 내 특정 호스트에 IP 주소와 포트 번호 쌍을 호스트에게 할당한 뒤,
  외부 호스트에게 해당 접속 정보(IP주소:포트번호 쌍)을 알려주면 됨

ICMP

IP의 전송 특성을 보완하는 ICMP

• IP 패킷 전송 과정에 대한 피드백 메시지 제공
• 피드백 메시지?
  1) 전송 과정에서 발생한 문제 상황에 대한 오류 보고
  2) 네트워크에 대한 진단정보(네트워크상의 정보 제공)

ICMP 메시지 = 타입 + 코드

• 타입 : ICMP 메시지 유형 번호
• 코드 : 구체적인 메시지 내용 번호

TCP와 UDP

⭐️TCP

신뢰할 수 있는 통신을 위한 연결형 프로토콜

TCP 통신 단계

TCP는 통신하기 전에 연결을 수립하고 통신이 끝나면 연결을 종료

MSS 단위

• MSS -TCP 로 전송할 수 있는 최대 페이로드 크기
• TCP 헤더 크기는 제외
  MTU는 헤더의 크기까지 포함

TCP 세그먼트 구조

빨간색으로 테두리되어있는 필드가 중요한 필드임

송신지 포트, 수신지 포트

송수신하는 포트번호

⭐️순서번호

• 순서번호가 명시되는 필드
• 순서번호
  송수신되는 세그먼트 데이터의 첫 바이트에 부여되는 번호
  세그먼트의 올바른 송수신 순서를 보장하기 위한 번호

순서번호 = 초기 순서번호 + 송신한 바이트 수

• 초기 순서 번호는 무작위 값
• 세그먼트 B의 순서 번호는 초기 순서 번호인 100에서 500 바이트 떨어진 셈이므로 600

확인 응답 번호

• 상대 호스트가 보낸 세그먼트에 대한 응답
• 다음으로 수신하기를 기대하는 순서 번호가 명시

제어비트 또는 플래그 비트

특정 명령에 사용되는 비트로, 정보통신 기술에서 사용됨
ex) TCP 제어 플래그, 소스 제어 플러그인 API에서 사용하는 비트 플래그.

ACK : 세그먼트의 승인을 나타내기 위한 비트

⭐️⭐️TCP 연결 수립과 종료

연결 수립: 쓰리 웨이 핸드셰이크

쓰리웨이 핸드셰이크 세 개의 단계로 이루어진 TCP의 연결 수립 과정
액티브 오픈 : 연결시작 호스트의 연결 수립 과정
패시브 오픈 : 연결 수락 호스트의 연결 수립 과정

연결 종료

송수신 호스트가 각자 한번씩 FIN과 ACK를 주고받으며 tcp가 연결 종료

• 액티브 클로즈 : 종료 시작 호스트의 종료 과정
• 패시브 클로즈 : 종료 수락 호스트의 종료 과정

네 단계로 연결을 종료한다는 점에서 포 웨이 핸드셰이크

TCP 상태

• 상태: 현재 어떤 통신 과정에 있는지를 나타내는 정보
• 상태를 유지하고 활용하는 TCP
  스테이트풀 프로토콜

TCP 상태의 유형

연결이 수립되지 않은 상태

CLOSED - 아무런 연결이 없는 상태
LISTEN - 서버의 데몬이 떠서 접속 요청을 기다리는 상태.

연결 수립 과정에서 주로 볼 수 있는 상태

SYN-SENT : 클라이언트가 서버에 연결을 요청하기 위해 SYN 패킷을 보낸 상태

연결 종료 상태

• FIN-WAIT-1
  일반적인 TCP 연결종료 과정에 있어 FIN-WAIT-1은 연결 종료의 첫 단계
• CLOSE-WAIT
  종료 요청인 FIN 세그먼트를 받은 패시브 클로즈 호스트가 그에 대한 응답으로 ACK 세그먼트를 보낸 후 대기하는 상태
• Fin-WAIT-2
  FIN-WAIT-1 상태에서 ACK받으면 FIN-WAIT-2상태로 전환됨
• TIME-WAIT
  액티브 클로즈 호스트가 FIN 세그먼트를수신한 뒤, 이에 대한 ACK 세그먼트를전송한 뒤 접어드는 상태
  패시브 클로즈 호스트는 마지막 ACK 세그먼트를 수신하면 closed 상태로 전이
  Time-WAIT 상태의 액티브 클로즈 호스트는 일정 시간을 기다린 뒤 CLOSED 상태로 전이

TCP 상태 확인 방법

# 모든 TCP 연결 보기
netstat -an | grep TCP

# 활성화된 연결만 보기
netstat -ant | grep ESTABLISHED

# 프로세스 정보와 함께 보기 (Linux)
netstat -antp

UDP

TCP보다 신뢰성은 떨어지지만 비교적 빠른 통신이 가능한 비연결형 프로토콜

UDP 데이터그램의 구조

UDP는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜
그래서 연결 수립 및 해제, 재전송을 통한 오류제어, 혼잡제어, 흐름제어 등을 수행하지 않음
상태를 유지하지도 않음 - stateless 프로토콜

UDP vs TCP

UDP는 일방적으로 마구마구 던지는 듯한 ….구조

TCP의 오류·흐름·혼잡 제어

TCP의 기능

재전송을 기반으로 다양한 오류를 제어
흐름 제어를 통해 처리할 수 있을 만큼의 데이터 송수신
혼잡 제어를 통해

재전송 기반 오류 제어

오류 검출과 재전송

TCP 세그먼트의 체크섬 필드, 충분할까?
TCP가 신뢰성을 제대로 보장하려면?

중복된 ACK 세그먼트를 수신했을 때

타임아웃이 발생했을 때

호스트가 세그먼트를 전송할 때마다 재전송 타이머 시작
타임아웃이 발생할 때까지 ACK 세그먼트를 받지 못하면 재전송

재전송 기법 : ARQ

수신 호스트의 답변과 타임아웃을 토대로 문제를 진단하고, 문제가 생긴 메시지를 재전송함으로써 신뢰성을 확보하는 방식

⭐️ARQ의 대표적인 세가지(중요)

Stop-and-Wait ARQ

제대로 전달했음을 확인하기 전까지는 새로운 메시지를 보내지 않는 방식
송신하고 확인받고, 송신하고 확인받고…
장점: 단순하지만 높은 신뢰성을 보장
단점: 네트워크의이용 효율이 낮아지고 성능이 저하됨

Go-Back-N ARQ

파이프라이닝 기반 ARQ 일종
여러 세그먼트 전송 중 오류가 발생하면 해당 세그먼트부터 전부 재전송
순서번호 n번에 대한 ACK 세그먼트는 ‘n번만의’ 확인 응답이 아닌 ‘n번까지의 누적 확인 응답’

Selective Repeat ARQ

선택적으로 재전송: 각각의 패킷들에 대해 ACK 세그먼트를 보내는 방식

흐름제어

파이프라이닝 기반 Go-BACK-N ARQ/Selective Repeat ARQ 가 정상 동작하려면?

TCP의 흐름제어

송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게

슬라이딩 윈도우 : TCP 흐름 제어 기법

윈도우 - 송신 호스트가 파이프라이닝할 수 있는 최대량
즉, 윈도우의 크기만큼 확인 응답을 받지 않고도 한번에 전송가능하다는 의미

송신측의 윈도우도 있다

수신 호스트는 TCP 헤더를 통해 송신 호스트에게 자신이 받을 데이터의 양을 알려줌
송신 윈도우 : 헤더로 전달받은 수신

혼잡 제어

혼잡

많은 트래픽으로 인해 패킷의 처리속도가 늦어지거나 유실될 우려가 있는 네트워크 상황

TCP의 혼잡제어

송신 호스트가 혼잡한 정도에 맞춰 유동적으로 전송량을 조절하는 기능
흐름 제어의 주체가 수신 호스트라면
혼잡 윈도우 - 혼잡 없이 전송할 수 있을 법한 데이터 양

• 혼잡 윈도우가 크면? 한번에 전송할 수 있는 세그먼트 수가 많음
• 혼잡 윈도우가 작으면? 한번에 전송할 수 있는 세그먼트 수가 적음

수신 윈도우는 수신 호스트가 헤더로 알려줌
혼잡 윈도우는 송신 호스트가 있어서

TCP의 혼잡 제어 알고리즘

혼잡 제어를 수행하는 일련의 방법

가장 기본적인 알고리즘인 AIMD

• ‘합으로 증가, 곱으로감소‘
• 혼잡이 감지되지 않는다면 - 혼잡 윈도우를 RTT마다 2씩 선형적으로 증가
• 혼잡이 감지되면 - 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복

⭐️RTT(중요)

메시지를 전송한 뒤 그에 대한 답변을 받는데까지 걸리는 시간

오류 검출과 재전송

TCP가 신뢰성 있는 데이터 전송을 보장하는 기본 메커니즘

오류 검출:

체크섬으로 데이터 무결성 확인
시퀀스 번호로 데이터 순서와 유실 확인
ACK로 수신 확인

재전송:

타임아웃: 일정 시간 내 ACK 못받으면 재전송
빠른 재전송: 중복 ACK 3번 받으면 즉시 재전송

느린시작 알고리즘

혼잡 윈도우를 1부터 시작해 문제 없이 수신된 ACK 세그먼트 하나당 1씩 증가시키는 방식

TCP의 혼잡 제어 알고리즘

느린 시작 임계치
혼잡 윈도우 값이 계속 증가하다가,
혼잡 윈도우 크기가 느린 시작 임계치 이상이 되거나
타임아웃이 발생하거나
세 번의 중복된 ACK 세그먼트를 수신하면 다음 세가지 바법 중 하나를 선택

• 타임아웃 발생
• 혼잡윈도우 >= 느린시작 임계치
• 세 번의 중복 ACK 발생

혼잡 회피 알고리즘

RTT마다 혼잡 윈도우를 1MSS씩 증가시키는 알고리즘
혼잡 윈도우크기 선형적으로 증가
“워워워”: 느린 시작 임계치를 넘어서면 혼잡 여지가 있으니 조심해서 혼잡 윈도우증가하기

빠른 회복 알고리즘

세 번의 중복 세그먼트 수신 vs 타임 아웃 뭐가 더 심각한 문제일까?
빠른 전송률 회복을 위해 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘
단, 빠른 회복 도중이라도 타임 아웃이 발생하면 다시 느린 시작을 수행

혼잡 제어 알고리즘 종합 : 느린시작, 혼잡 회피, 빠른재전송, 빠른회복