전송 계층 - TCP 중심으로

전송 계층 개요

네트워크 계층과 응용 계층 사이에 위치해 둘을 보완하거나 지원해주는 계층!

IP의 한계 보완

신뢰할 수 없는 통신 Unreliable Protocol

IP는 패킷이 수신지까지 제대로 전송됐다는 보장을 하지 않는다!!

당연히 재전송도 해주지 않으며, 패킷이 올바른 순서로 도착할 거란 보장 역시 하지 않는다!!

최선형 전달 Best Effort Delivery
단어의 의미와 달리 "노오력"만 한다는 뜻... 최선을 다 해보겠으나 보장은 못 해요 ^_^

비연결형 통신 Connectionless Protocol

송수신 호스트 간에 사전 연결 수립 작업이 없다!!

그니까 "나 보낼게?", "그려 보내라~" 이런 약속이 전혀 없고, 그저 패킷을 보내기만 할 뿐임

이렇게만 보면 IP를 왜 쓰는 겨 싶겠지만, 신뢰성을 보장하기 위해선 그만큼 성능을 포기해야한다!!

또한 패킷이 두어 개 유실되더라도, 전송 속도를 우선시하게 되는 환경이 있을 수 있다!!

워터파크 들어가는데 신분증 검사하고, 주소지 확인하고 한다고 생각해보자!!

줄만 겁나 길어지고 워터파크에서 뭔 저런 걸 하냐 싶겠지?! 그런 거당!

이런 신뢰 X, 비연결형 통신의 특성을 그대로 받은 것이 UDP고!

이를 보안해 신뢰 O, 연결형 통신을 지원하는 것이 TCP다!!

연결형 통신
송수신 동안은 연결을 유지하고, 송수신 종료 시 연결을 종료하는 통신 방법
요청과 응답을 주고 받기로 했다면 그 동안은 두 호스트가 손 잡고 있는 거다!

응용 프로그램 식별

전송계층에선 PORT 번호를 활용해 "특정 컴퓨터"의 "특정 프로세스"까지 정확히 접근할 수 있게 해준다!

---

PORT 번호

16비트로 표현한다! 때문에 사용 가능 포트 수는 총 2의 16승, 약 6만 5천 개로,

그 이유로 PORT 번호는 0번부터 65535번까지 사용하고 있음!!

크게 범용적인 번호 유형들과 그렇지 않은 번호 유형으로 나눌 수 있는데,

전자엔 well-known port와 registered port가 있고, 후자엔 dynamic port가 있다!!

잘 알려진 포트 well-known port

범용 애플리케이션 프로토콜들이 일반적으로 사용하는 번호들이다!

넘 유명해서 파급력이 굉장한 녀석들이 찜해놓은 느낌!!

대표적인 녀석들 몇몇만 정리해보자면,

FTP	SSH	TELNET	DNS	DHCP	HTTP	HTTPS
20, 21	22	23	53	67, 68	80	443

시스템 포트 system port라 칭하기도 한다!!

등록된 포트 registered port

위 녀석보단 덜 하지만, 특정 기업의 프로그램이나, 자주 쓰이는 오픈 소스 등에 할당돼있는 번호!

OpenVPN	Microsoft SQL Server	MySQL 데이터 베이스	HTTP 대체 백업용
1194	1433	6379	8080

동적 포트 dynamic port

IANA (Internet Assigned Numbers Authority)에서 관리하는 위 두 녀석들과 달리, 자유롭게 사용 가능한 번호들

서버는 대부분 전자의 둘을 쓰고, 클라는 대부분 동적 포트를 쓰게 된다!!

사설 포트 private port나 임시 포트 ephemeral port라 부르기도 함!

---

NAPT ( Network Address Translation )

NAT 테이블에 주소 쌍과 더불어 port 번호도 함께 기록하는 식으로 변형한 프로토콜!!

하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있게 됨!! (1:N 관계)

port 번호를 통해 각 호스트들을 식별할 수 있게되기 때문!! 오늘날 대부분 이 NAPT를 활용한다!!

NAT ( Network Address Translation )
공인 주소와 사설 주소를 상호 변환시켜주는 프로토콜이다!!
공인 주소는 호스트가 속한 네트워크 외부에서 참조하게 되는 주소고,
사설 주소는 소속 네트워크 내에서 활용하는 주소다!!
NAT 테이블
공인 주소 : 사설 주소 데이터 쌍이 저장되는 데이터 테이블
다만 이러면 사설 주소 하나당 공인 주소 하나를 대응시켜야하는데, 주소 가지 수 제한 때문에 한계가 있고,
가능한 영역이라 해도 이런 방식은 공인 주소 낭비다!! 애초에 하나씩 쓸 거면 사설 주소로 그냥 쓰지!!

포트 포워딩 Port Forwarding

네트워크 내 특정 호스트마다 공인 IP주소와 port 번호를 할당해주고, 이를 외부 호스트에게 알려줌으로써,

소속 네트워크가 아닌 곳에서도 특정 호스트에 접근할 수 있도록 해주는 기법 (포트가 어디로 향할지!!)

---

TCP ( Transmission Control Protocol )

TCP 통신은 크게 세 단계로 진행된다!! 먼저 약속을 해야하니 연결을 맺고!! 데이터를 주고 받고!!

끝나면 연결을 서로 합의하에 종료한다!! 연결 수립과 종료엔 handshake 개념이 관련되고,

데이터 송수신엔 오류, 흐름, 혼잡 제어 개념이 연관이 있다!!

차례차례 알아보도록 하기 전에, TCP의 데이터 단위인 세그먼트의 구조에 대해 체크하고 가보자구!!

MSS ( Maximum Segment Size )
TCP로 전송할 수 있는 최대 페이로드 크기 제한!! 헤더의 크기는 제외하고 측정한다!!
유사한 개념인 MTU는 헤더 크기까지 포함하는 개념이다!!

세그먼트 구조

세그먼트는 데이터 송수신 뿐만 아니라, 연결 및 제어 등의 절차를 위한 정보 역시 담기기 때문에 다양한 필드가 존재한다!! 대표적인 구성으론 송신지 포트 번호, 수신지 포트 번호, 

순서 번호 sequence number, 확인 응답 번호 acknowledgment number,

제어비트 control bits, 윈도우 window 등이 있고! 주요한 녀석들만 좀 더 알아보도록 하겠음!

순서 번호 sequence number

세그먼트의 첫 바이트에 부여된 번호로, 올바른 송수신 순서를 보장하기 위해 할당한다!!

초기 순서 번호 ISN( Initial Sequence Number )는 대개 무작위 값으로 지정되고,

다음 순서 번호부터는 초기 순서 번호 + 송신 바이트 수의 값으로 지정된다!!

위 사진에서 ISN이 100인 세그의 크기가 500이니까, 그 다음으로 보낼 세그의 순서 번호는 600!!

확인 응답 번호 acknowledgment number

상대 호스트가 보내준 세그에 대한 응답임을 표현하기 위해 할당한다!!

일반적으로 수신한 세그의 순서 번호에 1을 더한 값으로 지정!!

제어비트 control bits 

이 세그먼트에 대한 부가 정보들을 나타내는 필드로, 8비트로 구성되며, 각 비트가 1이라면 그 속성이 존재한다는 의미!!

• ACK : 이 세그가 확인 응답을 위한 녀석임을 알려줌!! ( Acknowledgment )
• SYN : 이 세그가 연결 수립 요청에 관한 녀석임을 알려줌!! ( Sink )
• FIN : 이 세그가 연결 종료 요청에 관한 녀석임을 알려줌!! ( Finish )
• 등등등

윈도우 window

상대 호스트에게 내가 한 번에 처리할 수 있는 데이터의 크기를 알려주는 필드!!

윈도우에 지정된 값이 500이라면, 나는 한 번에 500 바이트를 처리할 수 있다는 의미

이후 알아볼 흐름 제어 Flow Control과 관계가 있는 필드니 이따 마저 살펴보는 걸로!!

---

TCP의 연결 수립 : 3-way handshake

TCP는 데이터를 주고 받기 전에 약속을 맺는다고 했다!! 마치 정상 회담에서  시작 전에

각국 정상들이 악수를 나눈 걸 상상해보면 handshake란 의미가 좀 더 와닿을 듯 하다!! 

근데 악수를 세 번 해서 3-way다!! 각 단계를 살펴봅시당

1. 먼저 호스트 A가 연결 수립 요청에 관한 세그를 보낸다!!
   이 세그엔 SYN 비트가 켜져있으며, 호스트 A의 초기 순서 번호가 포함돼있다!!
2. 호스트 B는 이에 대한 요청 확인 및 수락 응답에 대한 세그를 보낸다!!
   이 세그엔 SYN과 ACK 비트가 켜져 있으며, 호스트 B의 초기 순서 번호와,
   1번에서 받은 세그에 대한 확인 응답 번호가 포함된다!!
3. 마지막으로 호스트 A가 수락 확인 응답에 대한 세그를 보낸다!!
   이 세그엔 ACK 비트가 켜져 있으며, 호스트 A의 다음 순서 번호와,
   2번에서 받은 세그에 대한 확인 응답 번호가 포함된다!!

액티브 오픈 Active Open
연결을 요청한 호스트의 연결 수립 과정을 말한다!!
패시브 오픈 Passive Open
연결을 수락하는 호스트의 연결 수립 과정을 말한다!!

TCP의 연결 종료 : 4-way handshake

반대로 데이터를 전부 주고 받고는 연결 종료를 하게 되는디, 이 때는 악수를 네 번한다!!

1. 먼저 호스트 A가 연결 종료 요청에 대한 세그를 보낸다!! 이 세그엔 FIN 비트가 켜져있다!!
2. 호스트 B가 이에 대한 요청 확인 응답을 보낸다!! 이 세그엔 ACK 비트가 켜져있고,
   1에서 받은 세그에 대한 확인 응답 번호가 포함된다!!
3. 이후 호스트 B는 실행 중인 애플리케이션들도 종료하고, 리소스도 정리하는 등 종료 준비를 마치고
   연결 종료를 알리는 세그를 보낸다!! 이 세그엔 FIN 비트가 켜져있다!!
4. 마지막으로 호스트 A가 종료 확인 응답에 대한 세그를 보낸다!!
   이 세그엔 ACK 비트가 켜져 있으며, 3번에서 받은 세그에 대한 확인 응답 번호가 포함된다!!

액티브 클로즈 Active Close
종료를 요청한 호스트의 연결 해제 과정을 말한다!!
패시브 클로즈 Passive Close
종료를 수락하는 호스트의 연결 해제 과정을 말한다!!

---

TCP state

TCP는 상태정보를 통해 현재 어떤 통신 절차가 진행 중인지를 알려준다!!

이런 상태정보를 활용하는 프로토콜이라면 stateful하다고 하고, 그렇지 않으면 stateless하다고 한다!!

TCP state 유형

1) 연결이 수립되기 전 상태들

CLOSED

아무 연결도 없고 연결을 받지도 않는 상태

LISTEN

일종의 연결 대기 상태 (서버가 SYN 세그를 기다리고 있는 경우 등)

서버로 동작하는 Passive Open 호스트는 일반적으로 항시 LISTEN 상태를 유지한다!!

이런 호스트들에게 SYN 세그를 보냄으로써 3-way handshake가 시작됨!!

2) 연결 수립 절차 도중의 상태들

SYN-SENT

Active Open 호스트 가 연결 수립 요청을 보낸 후 대기하는 상태 (클라가 SYN 세그를 보낸 직후)

SYN-RECEIVED

Passive Open 호스트가  수립 요청에 대한 확인 응답을 보낸 후 대기하는 상태!! (서버가 SYN+ASK 세그로 응답한 직후)

ESTABLISHED

두 호스트 간에 연결 수립이 완료된 상태!!

3) 연결 종료 절차 도중의 상태들

FIN-WAIT-1

Active Close 호스트가 연결 종료 요청을 보낸 후 대기하는 상태 (클라가 FIN 세그를 보낸 직후)

CLOSE-WAIT

Passive Close 호스트가 종료 요청에 대한 확인 응답을 보낸 후 대기하는 상태!! (서버가 ACK 세그로 응답한 직후)

FIN-WAIT-2

Active Close 호스트가 종료 확인 응답을 받고 종료 완료 알림을 마저 기다리는 상태!! (서버에게서 ACK 세그를 받은 직후)

LAST-ASK

Passive Close 호스트가 종료 처리를 마치고 종료 완료 알림을 보낸 후 대기하는 상태 (서버가 FIN 세그를 보낸 직후)

TIME-WAIT

Active Close 호스트가 완료 알림을 받은 후 이에 대한 확인 응답을 보낸 상태 (클라가 ACK 세그로 응답한 직후)

CLOSED

두 호스트 간 연결 해제가 완료된 상태!!

---

TCP의 제어 기능

신뢰성을 제대로 보장하기 위해선

송신 호스트가 보낸 세그에 문제가 발생했음을 인지할 수 있어야하고!!

오류 감지 시 해당 세그를 다시 보낼 수 있어야 한다!!

TCP는 이 재전송을 바탕으로 오류를 제어하게 되고, 이 때 활용하는 프로토콜이 ARQ다!!

TCP가 오류로 인식하는 두 가지 상황
1. 중복된 ACK 세그를 수신한 경우
2. 타임아웃 Timeout이 발생한 경우
  - 송신 호스트가 세그를 보낼 때마다 재전송 타이머가 시작된다!
  - 타이머가 시간을 모두 소모한 경우 타임아웃이 발동한다!!
  - 타임아웃 발동 전까지 응답을 받지 못하면 문제가 생겼다고 판단해 세그를 재전송한다!!

1) 오류 제어

ARQ (Automatic Repeat Request)

수신 호스트의 답변(=ACK세그)과 타임아웃 상태를 토대로 문제를 진단하고,

오류가 검출된 메세지를 재전송함으로써 신뢰성 확보를 도모하는 프로토콜이다!!

크게 세 가지 유형이 있으니 각각을 알아보도록 하자!!

Stop-and-Wait ARQ

메세지가 제대로 전달됐음을 확인하기 전까지는 새로운 메세지를 보내지 않는 방식

장점은 단순한 방법으로 높은 신뢰성을 보장한다는 것이고,

단점은 매 송신마다 확인을 받다보니 네트워크 이용 효율이 낮고, 이에 따라 성능도 저하된다는 점이다!!

이에 대한 개선으로 다른 ARQ에선 파이프라이닝 기법을 활용한다!!!

파이프라이닝 Pipelining
수신 호스트의 응답이 오기 전까지 여러 메세지를 연속해서 보내놓는 방식!!

 

Go-Back-N ARQ

파이프라이닝 기법으로 여러 세그를 보내던 중 오류가 발생하면 해당 세그부터 전부 재전송하는 방식

예를 들어, 다섯 개의 세그를 보내고 응답을 기다리고 있는데 세번째 세그에 문제가 생겼다면,

세번째부터 다섯번째 세그까지 재전송하게 된다!! 이때 네번째나 다섯번째는 문제가 없더라도 재전송한다!!

이 방식에서 수신 호스트가 보내주는 n번째 순서에 대한 확인 응답은 n번만 해당하는 ACK가 아니고, n번까지에 대한 ACK가 되고, 이를 누적 확인 응답 CACK ( Cumulative Acknowledgement )라 한다!!

빠른 재전송 Fast Retransmit
재전송 타이머가 만료되기 전이라도 세 번의 중복 ACK 세그를 받았다면 타임아웃으로 간주, 곧바로 재전송하는 기법

 

Selective Repeat ARQ

파이프라이닝 기법으로 여러 세그를 보내는 건 같지만, 오류 발생 시 문제아 녀석들만 선택적으로 재전송하는 방식

수신 호스트가 보내주는 확인 응답은 각 세그에 대한 개별적인 ACK가 되고,

이를 개별 확인 응답 SACK ( Selective Acknowledgement )라 한다!!

---

2) 흐름 제어

파이프라이닝 기법으로 여러 메세지를 보낼 땐 고려해야할 요소들이 있다!!

호스트가 한 번에 받아 처리할 수 있는 세그의 양에는 한계가 있따!!

이를 고려해 최적 크기의 메세지를 보내는 것이 이상적인 통신이 되겠고,

송신 호스트는 수신 호스트의 처리 속도를 배려하며 송수신 속도를 균일하게 조정해야한다!!

다만 Stop-and-Wait ARQ라면 별도의 흐름 제어가 필요 없당... 하나 주고 확인 받고 반복하기 때문

슬라이딩 윈도우 Sliding Window

여기서 윈도우는 수신 호스트가 한 번에 받아 처리할 수 있는 세그의 크기를 말한다!!

다르게 말하면 송신 호스트가 파이프라이닝할 수 있는 최대 메세지 크기를 뜻한다!!

즉, 윈도우의 크기만큼은 확인 응답을 받기 전에 연속해서 전송이 가능하다는 뜻!!

이를 바탕으로, 보내놓은 세그들 중 응답을 받은 녀석들은 빠지고, 새로운 세그를 또 보내는 식으로

윈도우가 비지 않게 계속 채우게 되는데, 이 방식이 윈도우가 스르륵 움직이는 것 같아서 슬라이딩이란 이름이 붙었다!!

---

3) 혼잡 제어

혼잡 Congestion

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

송신 호스트는 혼잡도를 고려해 유동적으로 전송량을 조절하게 된다!!

혼잡 윈도우 Congestion Window

혼잡 윈도우가 크다면, 즉 한 번에 주고받을 수 있는 데이터 크기에 여유가 있다면

비교적 혼잡하지 않은 상황으로 간주하고, 작다면 혼잡한 상황으로 간주한다!!

다른 윈도우 정보와 달리 혼잡 윈도우는 수신 호스트에겐 필요 없는 정보다...

데이터를 받기만 하면 되는디 이 녀석이 오는 길이 험한지 어쩐지는 알 필요가 없기 때문!!

따라서 송신 호스트는 혼잡윈도우를 알아서 계산해야하고, 이때 쓰는 알고리즘들에 대해 알아보도록 하자!!

1) AIMD 알고리즘 ( Additive Increase / Multiplicative Decrease )

합으로 증가 / 곱으로 감소한다는 의미로, AIMD의 변화는 선형적이다!!

혼잡이 감지되지 않는 경우 혼잡 윈도우를 RTT마다 1씩 증가시킨다!!

RTT ( Round Trip Time )
메세지를 전송한 후 그에 대한 응답을 받는 데까지 걸리는 시간

 

반면 혼잡이 감지되면 혼잡 윈도우를 절반만큼 감소시킨다!!

이때 혼잡 감지 조건은 오류 검출 조건과 동일한 중복 ACK 세그 수신 또는 타임아웃 발생이다!!

선형적 변화
증가 또는 감소하는 폭이 늘 같음!! 
1 증가하고, 1 증가하고, 1 증가하는 그런 경우 
지수적 변화
증가 또는 감소하는 폭이 변화함!! 
1 증가한 후, 2 증가하고, 4 증가하는 그런 경우

2) Slow Start 알고리즘

문제 없이 수신된 ACK 세그 하나당 혼잡 윈도우를 증가시킨다!!

이때 증가폭은 RTT마다 2배씩 지수적으로 증가하기 때문에, 신속하게 전송 속도를 끌어올릴 수 있당

느린 시작 임계치 Slow Start Threshold라는 특정 값까지만 증가시킬 수 있으며,

임계치 도달, 타임아웃, 또는 세 번의 중복 ACK 세그 수신 시 알고리즘을 종료한다!!

느린 시작 종료 시 이어지는 알고리즘이 세 가지가 있으니 좀 더 알아보도록 하자!!

느린 시작을 재개한다

혼잡 회피를 수행한다

RTT마다 혼잡 윈도우를 MSS만큼씩 증가시킨다!! 혹시나 해서 MSS는 Maximum Segment Size다!!

지수적으로 증가하던 혼잡 윈도우를 선형적으로 증가하게끔 바꿔 증가 추이를 더디게 하는 것!!

혼잡이 발생하기 시작한 거 같으니 안전하게 조금씩만 늘리도록 조정하는 것이당!

빠른 회복을 수행한다

전송률을 신속하게 회복하기 위해서 느린 시작을 스킵하고 혼잡회피를 수행하는 것을 뜻한다!!

세 번의 중복 ACK 세그 수신 시 빠른 재전송 + 빠른 회복을 수행한다!!

만약 빠른 회복 중이라도 타임아웃이 발생한다면 느린 시작을 수행하게 된당

명시적 혼잡 알림 ECN ( Explicit congestion notification )

위 두 알고리즘이 송신 호스트만 관여하는 방법이라면, ECN은 중간 노드의 도움을 받는 방법이다!!

대개 라우터의 도움을 받게 되고, 데이터 이동 중 혼잡이 감지되면

라우터가 메세지의 ECN 관련 비트들을 1로 만들어, 이를 받은 호스트가 아 혼잡이 발생했구나 확인하는 방식!!

송신 호스트만 혼잡 제어를 수행할 경우 사후 제어만 가능하지만, ECN을 활용함으로써 더 빠른 대처가 가능!!