인터넷에서 데이터를 주고받을 때, 우리는 보통 IP 주소만 떠올리기 쉽다.
하지만 IP 프로토콜만으로는 완전한 데이터 통신이 어렵다.
이번 글에서는 IP 프로토콜의 한계를 살펴보고, 이를 극복하기 위해 왜 전송 계층(Transport Layer)이 필요한지에 대해 알아보자.
IP 프로토콜의 한계
IP(Internet Protocol)는 네트워크 계층(Network Layer)에 속한 프로토콜로, 데이터를 목적지까지 전달하는 역할을 한다. 송신지와 수신지의 IP 주소를 기반으로 데이터를 패킷이라는 단위로 쪼개어 전송한다.
하지만 IP는 “일단 목적지까지 전달”하는 데 초점을 맞추기 때문에 다음과 같은 한계를 가진다.
1.
비연결형 서비스 (Connectionless)
•
데이터를 보내기는 하지만, 상대방이 받았는지 확인하지 않는다.
•
통신 상대와의 연결을 유지하지 않기 때문에 신뢰성이 부족하다.
2.
데이터 손실 가능성
•
중간 경로에서 패킷이 유실되어도 다시 전송하지 않는다.
3.
순서 보장 없음
•
패킷들이 서로 다른 경로로 가기 때문에 순서가 뒤바뀔 수 있다.
4.
흐름 제어나 혼잡 제어 미지원
•
수신자의 처리 능력을 고려하지 않으며, 네트워크 혼잡 상황을 제어할 수도 없다.
즉, 데이터를 보냈다고 끝이 아니라, 그 데이터가 정확히, 빠짐없이, 제시간에 도착했는지를 보장해주는 무언가가 더 필요하다.
그래서 전송 계층이 등장했다
이러한 한계를 보완하기 위해 전송 계층이 필요하다.
전송 계층은 종단 간(end-to-end) 통신을 담당하며, IP 위에서 보다 신뢰성 있는 데이터 전송을 지원한다.
전송 계층은 다음과 같은 기능을 제공한다.
1.
신뢰성 있는 데이터 전송 (Reliable Delivery)
•
데이터를 받았는지 확인하고, 못 받았으면 다시 보낸다.
2.
데이터 순서 보장
•
패킷이 섞여 도착해도 원래 순서대로 재조립해준다.
3.
에러 검출 및 재전송
•
데이터에 오류가 생기면 이를 감지하고 다시 요청할 수 있다.
4.
흐름 제어 (Flow Control)
•
수신자가 감당할 수 있을 만큼만 보낸다.
5.
혼잡 제어 (Congestion Control)
•
네트워크가 혼잡한 상황이라면 전송 속도를 줄이거나, 잠시 기다려준다.
전송 계층의 대표 주자들: TCP와 UDP
전송 계층에서는 대표적으로 두 가지 프로토콜이 사용된다.
바로 TCP와 UDP이다.
프로토콜 | 특징 |
TCP (Transmission Control Protocol) | 연결 지향적, 신뢰성 보장, 순서 보장, 느리지만 안전함 |
UDP (User Datagram Protocol) | 비연결형, 빠르지만 신뢰성 없음, 실시간 서비스에 적합 |
응용 계층을 식별하는 전송 계층
만약 우리가 어떤 친구에게 사진 파일을 보낸다고 가정해보자.
이 파일은 친구의 컴퓨터까지 도달했다. 이게 끝일까?
아니다. 이제 이 사진 파일을 실제로 실행중인 프로그램, 예를 들면 카카오톡에 전달해야 전송이 완전히 끝났다고 볼 수 있다.
컴퓨터는 동시에 수많은 프로그램을 실행할 수 있다. 메일 앱, 브라우저, 메신저, 게임 등등..
이 각각의 프로그램을 우리는 프로세스라고 부른다.
그래서 전송 계층에서는 패킷이 어떤 프로세스로 향해야 할지를 알려주는 정보가 필요한데, 그 역할을 하는 게 바로 포트 번호이다.
TCP 헤더와 UDP 헤더 살펴보기
네트워크 패킷을 주고 받는 프로세스에는 포트 번호가 할당된다.
즉, IP 주소와 포트 번호의 조합을 통해 특정 호스트가 실행하는 특정 프로세스를 식별할 수 있다.
그래서 IP 주소와 포트 번호는 다음과 같이 IP 주소:포트 번호 형식으로 함께 표기되는 경우가 많다.
192.168.0.15:8000
Plain Text
복사
다음의 TCP와 UDP 헤더를 살펴보면 TCP와 UDP 모두 포트 번호 필드인 송신지 포트 번호와 수신지 포트 번호를 포함하고 있다는 것을 알 수 있다.
포트 번호는 개발자가 자주 다루는 정보 중 하나이므로 조금 더 자세히 알아 두는 것이 좋다.
16비트로 표현할 수 있는 포트 번호의 총 개수는 , 즉 65,536개이다.
0번부터 할당되므로 0번부터 65535번 포트 번호를 할당할 수 있다.
포트 번호의 세 가지 유형
포트 번호는 그냥 아무렇게나 쓰는 게 아니라, 특정한 범위와 의미가 있다.
아래 세 가지로 나뉘어진다.
유형 | 범위 | 설명 |
Well-known 포트 | 0 ~ 1023 | 유명하고 범용적인 프로토콜이 사용하는 고정 포트 |
Registered 포트 | 1024 ~ 49151 | 특정 기업, 소프트웨어에서 사용하는 등록 포트 |
Dynamic/Private 포트 | 49152 ~ 65535 | 클라이언트에서 임시로 사용하는 포트 (자유롭게 사용 가능) |
1. Well-known 포트 (0~1023)
이건 말 그대로 너무 유형해서 찜 해둔 포트들이다.
프로토콜 | 포트 번호 |
HTTP | 80 |
HTTPS | 443 |
FTP | 20, 21 |
SSH | 22 |
DNS | 53 |
서버로 동작하는 프로그램은 대부분 이 범위의 포트를 사용한다.
예를 들어 웹 서버는 보통 80번(HTTP)이나 443번(HTTPS)을 사용한다.
2. Registered 포트 (1024~49151)
비교적 덜 범용적이지만 널리 사용되는 소프트웨어들이 쓰는 포트이다.
프로그램 | 포트 번호 |
MySQL | 3306 |
Redis | 6379 |
Microsoft SQL Server | 1433 |
OpenVPN | 1194 |
HTTP 대체 포트 | 8080 |
3. Dynamic 포트 (49152~65535)
이 범위의 포트는 임시로 할당해서 사용하는 용도이다.
특히 브라우저 같은 클라이언트 프로그램이 여기에 속하는 포트를 자주 사용한다.
내 컴퓨터에서 브라우저를 켜고 어떤 웹사이트(http://example.com)를 요청한다고 해보자.
•
서버(웹사이트)는 80번 포트에서 대기 중
•
내 브라우저는 동적 포트 하나를 임시로 할당받아 사용
이때 패킷 구성은 다음과 같이 구성된다.
•
수신지 포트: 80 (웹 서버의 포트)
•
송신지 포트: 51523 (브라우저가 할당받은 임시 포트)
포트 번호 리스트 확인하는 방법
공식 포트 번호 리스트는 IANA(Internet Assigned Numbers Authority)라는 곳에서 관리한다.
포트 번호와 어떤 프로토콜이 할당되어 있는지 알고 싶다면, 아래 링크에서 직접 확인해보자.
NAT와 NAPT
우리는 앞서 NAT과 관련된 개념을 다룬 적이 있다.
대부분의 라우터와 공유기는 NAT 기능을 내장하고 있기 때문에 사설 네트워크에서 만들어진 패킷이 네트워크 외부로 전송될 때는 다음과 같은 과정을 거친다.
•
내부에서 외부로 보낼 때: 사설 IP → 공인 IP
•
외부에서 내부로 받을 때: 공인 IP → 사설 IP
이때 네트워크 내부에 있는 사설 IP 주소 하나는 NAT 테이블에 의해 공인 IP 주소 하나로 일대일 대응되어 변환된다. 그러나 이와 같이 사설 IP 주소와 공인 IP 주소를 일대일로 변환하면 사설 IP 주소 수 만큼의 공인 IP 주소가 필요하므로 많은 공인 IP 주소가 필요할 수도 있다.
그래서 오늘날 대중적으로 활용되고 있는 NAT는 변환하고자 하는 IP 주소를 일대일로 대응하지 않고, 다수의 사설 IP 주소를 그보다 적은 수의 공인 IP 주소로 변환한다. 사설 IP 주소를 사용하는 여러 호스트가 적은 수의 공인 IP 주소를 공유하는 것이다. 그렇다면 어떻게 여러 개의 사설 IP 주소는 고유한 주소인 공인 IP 주소 하나로 변환될 수 있을까? 여기서 활용되는 것이 바로 포트이다.
서로 다른 사설 IP 주소가 같은 공인 IP 주소로 변환되더라도 다른 포트 번호로 변환된다면 네트워크 내부의 호스트를 특정할 수 있다. 가령 1.2.3.4라는 동일한 공인 IP 주소로 변환되더라도 포트 번호 6200번으로 변환되는지, 6201번으로 변환되는지에 따라 내부 IP 주소를 구분할 수 있다. 이처럼 IP 주소 변환 과정에서 변환할 IP 주소의 쌍과 더불어, 포트 번호도 함께 고려하는 포트 기반의 NAT를 NAPT(Network Address Port Translation)라고 한다.
요컨대, NAPT는 변환할 IP 주소 쌍과 더불어 포트 번호도 함께 기록하고 변환함으로써 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있도록 하는 NAT의 일종이다. NAPT는 네트워크 내부에서 사용할 IP 주소와 네트워크 외부에서 사용할 IP 주소를 N:1로 관리할 수 있다는 점에서 공인 IP 주소 수의 부족 문제를 개선하는 기술로 간주되고 있다.
포트 포워딩
이제 NAPT를 이해했다면, 자연스럽게 포트 포워딩(Port Forwarding) 개념도 이어서 이해할 수 있다.
우리가 NAT 혹은 NAPT 환경에서 외부로 요청을 보낼 때는 라우터가 내부 IP 주소와 포트 번호를 적절히 변환해주기 때문에 큰 문제가 없다. 하지만 외부에서 내부 네트워크로 들어오는 트래픽은 상황이 조금 다르다.
외부에서는 하나의 공인 IP 주소만 알고 있기 때문에, 이 IP를 공유하는 여러 대의 내부 장치 중 어느 장치의 어떤 서비스로 연결해야 할지 알 수 없다. 이때 필요한 기능이 바로 포트 포워딩이다.
포트 포워딩의 원리
포트 포워딩은 라우터나 방화벽이 외부에서 특정 포트로 들어오는 트래픽을 내부 네트워크의 특정 IP:포트로 전달해주는 설정이다.
예를 들어, 아래와 같은 상황을 가정해볼 수 있다.
•
외부 사용자가 203.0.113.10:8080 으로 접속
•
라우터가 이 요청을 내부의 192.168.0.5:80 으로 포워딩
•
결과적으로 내부의 웹 서버가 응답
즉, 외부에서는 마치 203.0.113.10:8080이 웹서버처럼 보이지만, 실제로는 라우터가 그 요청을 내부에 있는 웹서버로 대신 전달하고 있는 셈이다.
TCP vs UDP
TCP를 통해 신뢰할 수 있는 연결형 송수신이 가능하고, UDP를 통해 신뢰할 수 없는 비연결형 송수신이 가능하다. 다시 말해, TCP는 신뢰할 수 있는 프로토콜이자 연결형 프로토콜이고, UDP는 신뢰할 수 없는 프로토콜이자 비연결형 프로토콜이다.
TCP는 패킷을 주고받기 전에 연결 수립 과정을 거치며, 연결 수립 이후 패킷을 주고받을 때 신뢰성 보장을 위해 상태 관리, 흐름 제어, 오류 제어, 혼잡 제어 등의 각종 기능을 제공한다. 그리고 패킷의 송수신이 모두 끝나면 연결을 종료한다. 반면, UPD는 연결의 수립이나 종료 단계를 거치치 않고, 신뢰성을 높이기 위한 기능들도 제공하지 않는다.
물론 신뢰할 수 있는 연결형 송수신에는 시간과 연산이 소요되기 때문에 일반적으로 TCP가 UDP에 비해 송수신 속도가 느리다. 따라서 패킷의 유실 없는 송수신을 원한다면 UDP보다 TCP를 선택하는 것이 유리하고, 비교적 빠른 송수신을 원한다면 TCP보다 UDP를 선택하는 것이 유리하다.
TCP
TCP 세그먼트의 구조
TCP 헤더 필드의 수는 UDP보다 훨씬 많다. TCP가 UDP와 달리 연결의 수립과 종료, 신뢰성 보장을 위한 여러 기능을 제공하기 때문이다. 이 중 우리가 우선적으로 알아야 하는 필드는 크게 3가지이다.
위 그림에서 초록색으로 칠해져있는 순서 번호 필드와 확인 응답 번호 필드, 일부 제어 비트(ACK, SYN, FIN 플래그)이다.
각각 순서 번호와 확인 응답 번호가 명시되는 순서 번호 필드와 확인 응답 번호 필드는 함께 사용되므로 한 쌍처럼 기억해 두는 것이 좋다. 순서 번호(Sequence number)란 TCP 세그먼트의 올바른 송수신 순서를 보장하기 위해 세그먼트 첫 바이트에 매겨진 번호이다. 순서 번호를 통해 현재 주고받는 TCP 세그먼트가 송수신하고자 하는 데이터의 몇 번째 바이트에 해당하는지 알 수 있는 셈이다.
확인 응답 번호(acknowledgment number)는 상대 호스트가 보낸 세그먼트에 대한 응답으로, 다음으로 수신하길 기대하는 순서 번호이다. 예를 들어 다음과 같이 상대 호스트인 A가 순서 번호 3001인 세그먼트를 전송했고 호스트 B가 이를 잘 수신한 뒤, 그 다음으로 3201번 세그먼트를 받고자 하는 경우를 가정해보자. 그럼 호스트 B는 상대 호스트 A에게 ‘다음으로 3201번 세그먼트를 받기를 희망함’을 알리기 위해 확인 응답 필드에 ‘3201’을 명시한다.
제어 비트는 현재 세그먼트에 대한 부가 정보를 나타내는 정보로, 플래그 비트라고도 부른다. 제어 비트는 기본적으로 8비트로 구성되며, 각 자리의 비트가 각기 다른 의미를 가진다. 이후 언급될 TCP의 기본 송수신을 이해하기 위해서는 기본적으로 다음 3가지 제어 비트에 대해 알고 있어야 한다.
•
ACK: 세그먼트의 승인을 나타내기 위한 비트
•
SYN: 연결을 수립하기 위한 비트
•
FIN: 연결을 종료하기 위한 비트
MSS와 MTU의 차이
MSS (Maximum Segment Size)
→ TCP에서 전송할 수 있는 순수 데이터(payload)의 최대 크기
MTU (Maximum Transmission Unit)
→ IP 계층에서 전송할 수 있는 전체 패킷의 최대 크기 (헤더 포함)
예를 들어 MTU가 1500바이트이고, TCP/IP 헤더가 40바이트라면 MSS는 1460바이트가 된다.
TCP의 연결부터 종료까지
TCP는 총 3단계로 통신이 이루어진다.
1.
연결 수립 (3-way Handshake)
2.
데이터 송수신
3.
연결 종료 (4-way Handshake)
연결 수립: 쓰리 웨이 핸드셰이크
TCP의 연결 수립은 쓰리 웨이 핸드셰이크를 통해 이루어진다.
쓰리 웨이 핸드셰이크는 쓰리 웨이라는 이름처럼 세 단계로 이루어진 TCP의 연결 수립 과정을 뜻한다.
가령 호스트 A가 호스트 B에게 처음 연결 요청을 보낸다고 가정했을 때 각각의 단계는 다음과 같다.
송수신 방향 | 세그먼트 종류 | 세그먼트에 포함된 주요 정보 | 비유 |
A → B | SYN 세그먼트 | - 호스트 A의 초기 순서 번호
- 1로 설정된 SYN 비트 | "연결 시작합니다." |
B → A | SYN + ACK 세그먼트 | - 호스트 B의 초기 순서 번호
- 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호
- 1로 설정된 SYN 비트
- 1로 설정된 ACK 비트 | "네, 확인했습니다. 연결 시작해요!" |
A → B | ACK 세그먼트 | - 호스트 A의 다음 순서 번호
- 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호
- 1로 설정된 ACK 비트 | "네, 확인했습니다." |
TCP 연결 수립 과정에서 SYN 비트가 설정된 패킷을 처음으로 보내는 호스트가 곧 처음으로 연결 요청을 보내는 호스트이다. 위에서 SYN 비트가 1로 설정된 패킷을 처음으로 보내는 호스트 A가 연결 요청을 처음으로 보내는 호스트인 셈이다. 호스트 A처럼 처음 연결을 시작하는 과정은 액티브 오픈(active open)이라고 하고, 반대로 호스트 B처럼 연결 요청을 수신한 뒤 그에 대한 연결을 수립하는 과정은 패시브 오픈(passive open)이라고 한다.
데이터 송수신
TCP는 송수신하는 패킷의 신뢰성을 보장하기 위해 크게 3가지 기능을 제공한다.
1.
오류 제어
2.
흐름 제어
3.
혼잡 제어
TCP는 재전송을 기반으로 다양한 오류를 제어하고, 송수신의 흐름을 제어해 처리할 수 있을 만큼의 데이터만을 주고 받으며, 혼잡 제어를 통해 네트워크의 혼잡 정도에 따라 데이터의 전송량을 조절한다.
각각의 기능에 대해 좀 더 자세히 알아보자.
1.
오류 제어
•
TCP는 송수신 과정에서 잘못 전송된 세그먼트가 있을 경우, 이를 재전송하여 오류를 제어한다.
•
TCP 재전송이 발생하는 경우
1.
중복된 ACK 세그먼트 도착
•
송신한 세그먼트의 일부가 전송 중 유실되어 중복으로 ACK 세그먼트를 수신하게 되는 상황
2.
타임아웃 발생
•
TCP 세그먼트를 송신하는 호스트는 모두 재전송 타이머라는 특별한 값을 유지
•
호스트는 세그먼트를 전송할 때마다 이 재전송 타이머를 시작
•
이 타이머의 카운트다운이 끝난 상황을 타임아웃이라고 하며, 타임아웃 발생 시점까지 ACK 세그먼트를 받지 못하면 세그먼트 전송 과정에 문제가 발생한다고 간주하여 세그먼트를 재전송
파이프라이닝 전송
TCP의 기본적인 송수신 양상은 세그먼트를 보내고 받는 일련의 과정을 반복하며 이루어진다.
다만, 이러한 방식에는 단점이 있다. 한 번에 하나의 세그먼트만 주고받아야 하는 비효율이 있다.
한 번에 여러 세그먼트를 보낼 수 있다면 한 번에 송신하고 한 번에 각 세그먼트에 대한 확인 응답을 받는 것이 더 효율적이다.
그래서 오늘날의 TCP는 다음 그림과 같이 확인 응답을 받기 전이라도 여러 메시지를 보내는 방식으로 송신하며, 이를 파이프라이닝(pipelining) 전송이라고 부른다.
2.
흐름 제어
수신 호스트가 한 번에 n개의 바이트를 받아서 처리할 수 있다면 송신 호스트는 n개의 바이트를 넘지 않는 선에서 송신해야 한다. TCP의 흐름 제어는 이처럼 수신 호스트가 한 번에 받아 처리할 수 있을 만큼만 전송하는 것을 의미한다. 즉, 흐름 제어는 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 기능이다.
수신 호스트가 한 번에 처리할 수 있는 전송량은 TCP 수신 버퍼의 크기에 의해 결정된다.
수신 버퍼는 수신된 세그먼트가 애플리케이션 프로세스에 의해 읽히기 전에 임시 저장되는 공간으로, 커널에 정의되어 있다.
송신 호스트는 수신 호스트가 한 번에 처리할 수 있는 양을 어떻게 알고 보내줄 수 있을까?
TCP 헤더를 보면 윈도우(window)필드를 볼 수 있는데 이 윈도우 필드에는 수신 호스트가 한 번에 처리할 수 있는 수신 윈도우(receiver window) 크기가 명시된다.
수신 호스트는 윈도우 필드를 통해 송신 호스트에게 한 번에 처리 가능한 양을 알려 주고, 송신 호스트는 전달받은 해당 값을 토대로 세그먼트를 전송한다.
3.
혼잡 제어
혼잡(congestion)이란 많은 트래픽으로 인해 패킷의 처리 속도가 느려지거나 유실될 수 있는 상황을 의미한다.
혼잡 제어(congestion control)는 이러한 혼잡을 제어하기 위한 기능이다.
흐름 제어의 주체가 수신 호스트였다면 혼잡 제어의 주체는 송신 호스트이다.
송신 호스트가 주체적으로 얼마나 네트워크가 혼잡한지를 판단할 수 있어야 하고, 판단된 혼잡의 정도에 따라 세그먼트의 전송량을 조절할 수 있어야 한다.
•
혼잡 여부 판단 방법 = TCP 재전송 기준
◦
중복된 ACK 세그먼트 도착
◦
타임아웃 발생
네트워크의 혼잡 가능성을 검출한 송신 호스트는 ‘혼잡 없이 전송할 수 있을 정도의 양’만큼만 송신하게 된다.
이 값을 혼잡 윈도우(congestion window)라고 한다.
혼잡 윈도우가 크면 한 번에 전송할 수 있는 세그먼트의 양이 많음을 의미하고, 반대로 작으면 네트워크가 혼잡한 상황이므로 한 번에 전송할 수 있는 세그먼트의 양이 적음을 의미한다.
TCP의 혼잡 제어를 수행하는 호스트는 각자 혼자 윈도우 값을 고려하며, 혼잡 윈도우의 값을 넘지 않는 선에서 전송하게 된다.
•
혼잡 제어 알고리즘: AIMD
◦
Additive Increase/Multiplicative Decrease의 약자로 ‘합으로 증가, 곱으로 감소’를 의미
◦
AIMD는 세그먼트를 보내고, 그에 대한 응답이 오기까지
▪
혼잡이 감지되지 않으면 혼잡 윈도우를 RTT마다 1씩 선형적으로 증가
▪
혼잡이 감지되면 혼잡 윈도우를 절반으로 떨어뜨림
RTT(Round Trip Time): 메시지를 전송한 뒤 그에 대한 답변을 받는 데까지 걸리는 시간
연결 종료: 포 웨이 핸드 셰이크
TCP의 연결 종료는 송수신 호스트가 각자 한 번씩 FIN과 ACK를 주고받으며 이루어진다.
가령 호스트 A가 호스트 B에게 처음 연결 종료 요청을 보낸다고 가정했을 때 TCP 연결은 다음과 같은 단계를 거쳐 종료된다.
송수신 방향 | 세그먼트 종류 | 세그먼트에 포함된 주요 정보 | 비유 |
A → B | FIN 세그먼트 | - 1로 설정된 FIN 비트 | "연결 끊을게요." |
B → A | ACK 세그먼트 | - 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호
- 1로 설정된 ACK 비트 | "네, 확인했습니다." |
B → A | FIN 세그먼트 | - 1로 설정된 FIN 비트 | "이제 연결 끊어요." |
A → B | ACK 세그먼트 | - 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호
- 1로 설정된 ACK 비트 | "네, 확인했습니다." |
앞서 TCP 연결 수립 과정에서 먼저 연결 요청을 보낸 호스트의 동작을 액티브 오픈, 연결 요청을 받아들이는 호스트의 동작을 패시브 오픈이라고 배웠다. 이와 유사하게 TCP의 연결 종료 과정에서는 액티브 클로즈(active close)와 패시브 클로즈(passive close)가 있다. 액티브 클로즈란 먼저 연결을 종료하려는 호스트에 의해 수행되는 동작을 의미한다. 제시된 예시에서 먼저 연결 종료를 요청한 호스트는 A이므로 호스트 A에 의해 액티브 클로즈가 수행되었다고 할 수 있다. 반대로, 패시브 클로즈는 예시의 호스트 B와 같이 연결 종료 요청을 받아들이는 호스트에 의해 수행되는 동작을 말한다.
TCP의 상태 관리
TCP의 또 다른 중요한 특징은 상태를 유지한다는 점이다.
TCP는 상태를 유지하고 관리하는 프로토콜이라는 점에서 스테이트풀 프로토콜(stateful protocol)이라고도 부른다.
여기서 상태(state)란 현재 어떤 통신 과정에 있는지를 나타내는 정보를 말한다.
TCP의 상태는 각종 네트워크 명령어에서 심심찮게 찾아볼 수 있다.
TCP의 상태 정보를 토대로 현재 TCP 송수신 현황을 판단할 수 있고, 디버깅의 힌트로도 활용할 수 있다.
TCP에는 다양한 상태가 존재하고, 호스트는 TCP를 통한 송수신 과정에서 다음과 같이 다양한 상태를 오가게 된다.
처음부터 TCP의 모든 상태를 기억하기는 어렵지만, 다음과 같은 항목화를 통해 한결 수월하게 정리할 수 있다.
1.
연결이 수립되지 않았을 때 주로 활용되는 상태
2.
연결 수립 과정에서 주로 활용되는 상태
3.
연결 종료 과정에서 주로 활용되는 상태
상태 분류 | 주요 상태 |
1 | CLOSED, LISTEN |
2 | SYN-SENT, SYN-RECEIVED, ESTABLISHED |
3 | FIN-WAIT-1, CLOSE-WAIT, FIN-WAIT-2, LAST-ACK, TIME-WAIT, CLOSING |
1. 연결이 수립되지 않았을 때
상태 | 설명 |
CLOSED | 아무런 연결이 없는 상태 |
LISTEN | 일종의 연결 대기 상태(SYN 세그먼트를 기다리는 상태) |
서버로서 동작하는 패시브 오픈 호스트는 일반적으로 항상 LISTEN 상태로써 연결 요청을 기다린다.
LISTEN 상태인 호스트에 SYN 세그먼트를 보내면 쓰리 웨이 핸드셰이크가 시작된다.
2. 연결 수립 과정에서 주로 활용되는 상태
상태 | 설명 |
SYN-SENT | 액티브 오픈 호스트가 SYN 세그먼트를 보낸 뒤, 그에 대한 응답인 SYN + ACK 세그먼트를 기다리는 상태(연결 요청 전송) |
SYN-RECEIVED | 패시브 오픈 호스트가 SYN + ACK 세그먼트를 보낸 뒤, 그에 대한 ACK 세그먼트를 기다리는 상태(연결 요청 수신) |
ESTABLISHED | 쓰리 웨이 핸드셰이크가 끝난 뒤 데이터를 송수신할 수 있는 상태(연결 수립) |
3. 연결 종료 과정에서 주로 활용되는 상태
상태 | 설명 |
FIN-WAIT-1 | 액티브 클로즈 호스트가 FIN 세그먼트로 연결 종료 요청을 보낸 상태(연결 종료 요청 전송) |
CLOSE-WAIT | FIN 세그먼트를 받은 패시브 클로즈 호스트가 그에 대한 응답으로 ACK 세그먼트를 보낸 후 대기하는 상태(연결 종료 요청 승인) |
FIN-WAIT-2 | FIN-WAIT-1 상태에서 ACK 세그먼트를 받은 상태 |
LAST-ACK | CLOSE-WAIT 상태에서 FIN 세그먼트를 전송한 뒤 대기하는 상태 |
TIME-WAIT | 액티브 클로즈 호스트가 마지막 ACK 세그먼트를 전송한 뒤 접어드는 상태 |
유의할 점은 패시브 클로즈 호스트가 마지막 ACK 세그먼트를 수신하면 CLOSED 상태가 되는 반면, TIME-WAIT 상태에 접어든 액티브 클로즈 호스트는 일정 시간을 기다린 뒤 CLOSED 상태가 된다는 점이다. 일정 시간을 대기하는 이유는 마지막 ACK 세그먼트가 올바르게 전송되지 않았을 수 있고, 이 경우 재전송이 필요하기 때문이다.
CLOSING 상태
CLOSING이라는 상태도 있다. CLOSING은 서로가 FIN 세그먼트를 보내고 받은 뒤 각자 그에 대한 ACK 세그먼트를 보냈지만 아직 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못했을 때 접어드는 상태이다. 보통 양쪽이 동시에 연결 종료를 요청하고 서로의 종료 응답을 기다릴 경우에 발생하는 상태이다.
UDP
UDP 데이터그램의 구조
•
송신지 포트: 송신 프로세스가 할당된 포트 번호
•
수신지 포트: 수신 프로세스가 할당된 포트 번호
•
길이: 헤더를 포함한 UDP 다이어그램의 바이트 크기가 명시
•
체크섬: 송수신 과정에서의 데이터그램 훼손 여부
UDP는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜이다.
그래서 연결 수립 및 해제, 재전송을 통한 오류 제어, 혼잡 제어, 흐름 제어 등을 수행하지 않는다.
또한, 상태를 유지하지도 않는다. (스테이트리스 프로토콜)
UDP는 TCP에 비해 적은 오버헤드로 패킷을 빠르게 처리할 수 있기 때문에 주로 실시간 스트리밍 서비스, 인터넷 전화처럼 실시간성이 강조되는 상황에서 TCP보다 더 많이 쓰인다.