TCP 깊게 이해하기

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

---

TCP란 컴퓨터와 다른 컴퓨터가 데이터를 전송하기 위한 전송계층의 규약이다.

인터넷 통신에서 가장 많이 사용되는 프로토콜로 TCP/IP가 있다.

데이터 전송에는 TCP를 사용하고 목적지까지 도달하는 라우팅 과정은 IP를 사용한 통신 방식을 TCP/IP라 부른다.

 

TCP의 특징

• 신뢰성 있는 데이터 전송
• 연결형 서비스
• 흐름제어, 혼잡제어
• ARQ

TCP는 위와 같은 특징이 있다. 사실 모두 신뢰성을 위한 특징들이다.

하나하나 세세하게 알아봐보자.

 

 

연결형 서비스

---

TCP는 클라이언트(송신자)와 서버(수신자) 간 데이터 전달을 위해 연결설정과 연결종료를 해야한다.

TCP는 신뢰성있는 데이터 전송이 목적이기에 데이터를 전송하기 전 송신지와 수신지가 데이터를 전송 받을 수 있는 안전한 상태인지 체크를 하게 된다. 

이 과정으로 이뤄지는 작업이 3-way-handshake와 4-way-handshake이다.

 

연결설정(3-Way-Handshake)

TCP의 연결설정 방식을 3-way-handshake라고 한다.

총 패킷을 3번 전달하며 syn, ack이라는 플래그 목적의 컨트롤 비트를 사용하여 연결을 설정한다.

클라이언트에서 syn 비트를 1로 체크하여 서버에 보내고 서버에서는 수신 받았음을 알리기 위해 syn과 ack 비트를 1로 체크하여 클라이언트로 보낸다. 

클라이언트에서 syn과 ack에 1로 체크된 패킷을 받았다면 서버는 최종적으로 다시 ack 비트를 1로 체크하여 클라이언트에 보내고 연결이 설정된다.

 

연결종료(4-Way-Handshake)

연결종료 방식은 4-Way-Handshake라고 불리며 이름에 알 수 있듯 패킷을 4번 전달하며 이때 사용되는 컨트롤 비트는 fin과 ack이다.

클라이언트에서 fin을 1로 체크하고 서버로, 서버에서 fin이 1로 체크된 패킷을 받았다면 ack을 1로 체크하고 클라이언트로 반환하고,  다시 fin을 1로 체크하고 클라이언트로 반환한다. 클라이언트에서는 위의 두 패킷을 받았다면 ack을 1로 체크한 패킷을 서버에 보냄으로써 연결을 종료한다.

 

 

TCP 패킷의 생성과정과 구조

---

데이터 스트림으로 데이터를 받으면 이를 일정한 단위로 끊으며 TCP 패킷(정확한 표현은 세그먼트)을 만든다.

TCP 패킷은 TCP 헤더와 TCP 데이터로 구성되어있으며 TCP 헤더는 데이터 전송을 위해 필요한 정보를 가지고 있으며, TCP 데이터는 데이터 스트림으로부터 일정한 단위로 잘린 데이터입니다. 

Header	Source port	송신지 포트
	Destination port	수신지 포트
	Sequence Number	분할된 데이터의 순서번호 (데이터가 순차적으로 전송 됬는지 또는 수신지에서 재조립시 사용)
	Acknowledgment number	송신지로부터 받아야하는 다음 Sequence Number
	Data Offset	TCP 헤더의 크기로 최소 20바이트이며 헤더 선택 값이 채워질 시 최대 60바이트
	컨트롤 비트(플래그)	플래그 목적으로 사용되는 컨트롤 비트
	window size	전송할 수 있는 최대 데이터 크기(패킷 개수), 서버 측에서 결정함 (서버 측 상황에 따라 받을 수 있는 데이터의 크기가 달라질 수 있으므로)
	Checksum	- 에러 검출 값으로 송신지에서 체크섬 계산식을 통해 송신할 데이터의 체크섬 값을 기입하고 수신지에서 전송 받은 데이터로 체크섬을 계산하여 비교하여 에러 검출  - 에러 발생시 패킷 재전송 요구(ARQ : Automatic repeat request)
Data	data	TCP 데이터로 실제 전송하려는 데이터

 

TCP 패킷의 헤더에는 위와 같이 많은 정보들이 저장되어있다. 

Sequence Number를 통해 순서가 보장된 데이터 처리를 진행할 수 있고,

Acknowlegement Number, window size를 통해 흐름제어가 가능하며,

Checksum을 통해 에러를 검출할 수 있다.

모두 신뢰성 있는 데이터 전송을 위해 활용되는 값들이다.

 

 

TCP 흐름제어 및 에러제어(ARQ)

---

수신지의 데이터 처리 속도가 보내는 송신지 보다 느리게 되면 패킷이 유실되게 된다. 

흐름 제어는 송신 측과 수신 측의 데이터 처리 속도 차이로 생기는 문제를 해결하기 위한 기법이다.

 

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

 

송신지에서 윈도우 사이즈 만큼 패킷을 지속적으로 전달하고 응답으로 받은 acknowledge number를 윈도우의 시작점이 되도록 이동한다.

 

[윈도우 슬라이딩 과정]

TCP/IP 를 사용하는 모든 호스트들은 송신 그리고 수신을 위한 2개의 Window 를 가지고 있다.
Window의 크기는 받는쪽에서 보낸 window size를 보내는 window size로 설정한다.

 

1. 송신지

• 200 이전 바이트 모두 보낸 상태
• 200~202 보냈으나 아직 응답 받지 못함
• 203~  아직 보내지 않은 상태

 

2. 송신지 윈도우 사이즈 결정

 

• 200 이전 바이트의 응답시 받은 window size를 송신측의 윈도우 사이즈로 결정한다.

 

3. 윈도우 이동

 

• 수신측으로 부터 acknowledgement number 203을 받았다면 윈도우의 시작 위치를 203으로 이동한다.
  수신측에서 202까지 정상적으로 받았음을 알 수 있다.

 

에러 제어 : ARQ

흐름제어를 진행한다고 하더라도 패킷이 유실되는 상황은 나타난다.

네트워크 대역폭을 사용하기 위한 경쟁상황도 존재하고, 통신이 불안정한 상태로 빠질 수도 있다.

먼저 에러를 검출에는 체크섬, 타임아웃, 시퀀스넘버(누락된 패킷 또는 중복된 패킷) 등을 활용할 수 있다.

에러를 찾았다면 수정하기 위해 송신지에 패킷 재전송을 요구하는데 이를 ARQ(Automatic repeat request)라고 부른다.

ARQ에는 아래와 같은 방식이 있다.

• Stop-and-Wait
• Go-Back-N
• Selective Repeat

각각의 방식은 아래와 같이 이루어진다.

- 윈도우 사이즈가 1인 방식  - 패킷 전송 후 ack을 받고 다음 패킷을    전송 하는 방식  - 하나의 패킷이 정상적으로 보내졌는지     확인하고 에러 시 재전송  - 비효율적이며 TCP에서 사용하지 않음	- 윈도우 사이즈가 2이상  - 윈도우 사이즈만큼 지속적으로    패킷을 보내며 에러 발생시    해당 패킷부터 다시 재전송  - TCP에서 사용	- 에러 발생 패킷에 대해서만 재전송을       요구해 재조립하는 방식  - 타임아웃 이전에 도착한 패킷은 버퍼에    저장하고 타임아웃 후 재전송 요구하여    받은 패킷을 버퍼의 상위로 올려 조립  - TCP에서 사용

 

 

TCP 혼잡제어

---

혼잡제어는 흐름제어와 비슷하게 전송하는 패킷의 갯수를 제어하지만,

네트워크 대역폭, 네트워크 자원 경쟁과 같은 상황으로 발생하는 패킷 유실 상황을 제어하는 개념이다.

흐름제어가 송신측 장비(OS, 하드웨어)의 데이터 처리 능력 차이로 인해 제어하는 개념이라면

혼잡제어는 네트워크 경쟁 상황이나 통신 불안정 상황에 따른 제어 개념이다.

 

AIMD (Additive Increse/Multicative Decrease)

AIMD는 윈도우 사이즈를 증가시킬 땐 선형적으로 조금씩 늘리며 증가시키고, 전송 실패 시 배수로 감소시키는 방법이다.

패킷의 갯수를 증가시킬땐 천천히 증가시키고 에러 발생시 한번에 대폭 줄이기 때문에 안전한 데이터 전송을 보장하여 TCP에서 흐름제어에 사용되는 방식이다.

다만, 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 오래 걸린다는 단점이 있다.

 

Slow Start (느린 시작)

TCP를 통한 data 전달은 위와 같이 data가 여러 패킷으로 잘려 나뉘어 전송된다.

처음 1개의 패킷을 전송하고 그 다음은 2개, 4개와 같이 기하급수적으로 패킷을 늘려나가며 최대로 전송할 수 있는 패킷의 개수를 찾아나간다.

네트워크의 대역폭(BandWidth)이 있기 때문에 패킷이 유실되면 최대값을 넘었다고 판단하는 것이다.

적은 갯수로 시작하여 늘려나가기 때문에 속도가 느린 단점이 있으며 이를 'TCP의 느린 시작' 이라고도 부른다.

 

빠른 재전송

패킷 손실 발생시 재전송 요구는 원래 타임 아웃 이후에 이뤄졌다.

허나, 이 방식은 TCP의 데이터 처리율을 떨어트리는 주요 이유가 되어 처리율을 높이는 새로운 기준이 나타나게 됬다.

응답으로 보내는 패킷의 acknowledgment number를 통해 어느 번호까지 받았고 다음번에 받아야할 패킷의 번호를 전달하는데, 이 값이 중복으로 3번 같은 값이 전달되게 되면 해당 패킷 번호 이후에 유실이 났음을 감지하고 타임아웃 여부와 관계 없이 해당 번호부터 재전송이 이뤄지게 된다.

 

빠른 회복

혼잡한 상태가 되면 윈도우 크기를 1로 줄이지 않고 반으로 줄여 선형 증가시키는 방법

 

 

TCP 혼잡 제어 정책

---

SSTresh(Slow Start Treshhold) : Slow Start 임계점

 

Slow Start를 통해 window size를 기하급수적으로 늘리다 네트워크 대역폭을 만나게 되면 이에 대한 제어가 어려워질 수 있다.

혼잡이 예상 되는 구간에 진입하면 기하급수적으로 증가시키는 Slow Start 방식에서 1씩 증가시키는 AIMD 방식으로 전환하게 되는데 이 기준점을 SSTresh라고한다.

 

1. TCP TAEHO

Taeho는 패킷 유실 상황(3 Ack Duplicated)과 시간 초과 상황이 발생하면 윈도우 사이즈를 1로 줄이고,

SSTresh 값을 혼잡 발생 윈도우 사이즈의 절반으로 줄인다.

 

 

2. RENO

 

Reno는 패킷 유실 상황에서는 윈도우 사이즈를 반만 줄이고 sshtresh 값은 윈도우 사이즈와 같게 한다.

시간 초과 상황에서는 윈도우 사이즈를 1로 줄이고 sshtresh 값은 변경하지 않는다.

 

Reno는 혼잡 발생시 윈도우 사이즈를 반만 줄이기에 1로 줄여 다시 slow start를 시작하는 taeho에 비해 성능이 좋다.(빠른 회복)

허나, 네트워크가 불안정하여 윈도우 사이즈를 반으로 줄여도 혼잡 상태가 지속될 수 있는 환경이라면 Taeho가 더욱 안정적인 처리가 가능하다.

Taeho는 안정적이지만 성능이 느린 반면, Reno는 Taeho에 비해 안정적이지는 않지만 성능은 좋다.