[Network] #15 TCP와 UDP
[혼자 공부하는 네트워크↗️], 컴퓨터 네트워킹: 하향식 접근 (제8판)을 바탕으로 정리한 글입니다.
- 지난 포스팅에서 살펴봤듯, 전송 계층의 가장 중요한 프로토콜은 TCP와 UDP이다.
- 이번 포스팅에서는 TCP와 UDP에 대해 자세히 살펴보자.
1. TCP와 UDP 개념
TCP (Transmission Control Protocol)
- 신뢰할 수 있는 통신을 위한 연결형 프로토콜
- 데이터 송수신 전에 연결을 수립하고 종료 후 연결을 종료한다.
- TCP는 유니캐스트(단일 송수신) 전송을 지원하는 프로토콜이므로 멀티캐스트(여러 수신자에게 동시에 전송)는 주로 UDP에서 지원한다.
UDP (User Datagram Protocol)
TCP보다 신뢰성은 떨어지지만 비교적 빠른 통신이 가능한 비연결형 프로토콜
2. TCP 통신 단계
2.1 TCP 통신의 기본 개념
TCP는 통신 (데이터 송수신) 하기 전에 연결을 수립하고 통신이 끝나면 연결을 종료한다.
- 이번 포스팅에서는 TCP의 연결 수립과 연결 종료 과정에 대해 중점적으로 다룰 것이다.
- 연결 수립: 데이터 송수신 전에 연결을 수립
- 연결 종료: 데이터 송수신 후 연결을 종료
2.2 MSS 단위
MSS(MSS; Maximum Segment Size) 단위란 TCP로 전송할 수 있는 최대 페이로드 크기를 의미한다.
- MSS는 페이로드만 포함하며, TCP 헤더는 제외된다.
- 단, MTU는 헤더 크기까지 포함된다.
2.3 TCP 세그먼트 구조
중요한 세그먼트 필드를 위주로 살펴보자.
2.3.1 송신지 포트 / 수신지 포트
송수신하는 포트 번호가 명시된다.
- 송신지 포트와 수신지 포트는 지난 포스팅에서 다루었다.
- 포트 번호란 실행중인 어플리케이션 프로세스를 식별하는 번호이다.
2.3.2 순서 번호 / 확인 응답 번호
순서 번호 (sequence number)
- 순서 번호가 명시되는 필드이다.
- 순서 번호
- 송수신되는 데이터의 첫 바이트에 부여된 번호로, 세그먼트의 올바른 송수신 순서를 보장한다.
- TCP는 세그먼트가 순차적으로 전송되므로, 순서 번호를 통해 각 세그먼트가 올바른 순서로 도달했는지를 확인할 수 있다.
- 즉, TCP를 통해 몇 번째 데이터를 주고받고 있는지에 대한 번호이다.
- e.g., 1900 바이트 크기의 데이터를 500바이트씩 나눠서 보내면, 첫 번째 세그먼트의 첫 바이트는 순서 번호 100을 가질 수 있다. 이후 보내는 세그먼트는 각각 이전 순서 번호에서 500씩 증가한 값을 가진다. (600, 1100, 1600)
확인 응답 번호 (acknowledgment number)
- 다음으로 수신하기를 기대하는 순서 번호가 명시되는 필드이다.
- 상대 호스트가 보낸 세그먼트가 잘 도달했음을 확인하는 응답 번호이다.
- e.g., 상대방에게 순서 번호 100번 세그먼트를 보냈다면, 상대방은 이 세그먼트를 잘 받았다는 응답으로 “다음 순서 번호”인 101을 보낸다. 이 값이 확인 응답 번호에 해당한다.
💡 즉, TCP 세그먼트를 주고받는다고 함은 특정 순서 번호에 대한 세그먼트를 보내고, 그에 대한 확인 응답 번호를 받고, 확인 응답 번호에 해당하는 순서 번호 세그먼트를 보내고, 그에 대한 확인 응답 번호를 받고가 반복되는 과정이다.
예시
예를 들어 응용 계층으로 부터 1900 바이트 크기의 데이터를 전달받았다고 가정해보자.
그리고 이때 MSS가 500 바이트라고 가정해보자. (네 개의 세그먼트로 분할)
그러면 각각의 세그먼트에는 다음과 같은 세그먼트가 붙을 것이다.
- 초기 순서 번호 (ISN; Initial Sequence Number)는 무작위 값
- 세그먼트 B의 순서 번호는 초기 순서 번호인 100에서 500바이트 떨어진 셈이므로 600
- 세그먼트 C의 순서 번호는 초기 순서 번호로부터 1000바이트 떨어진 1100
- 세그먼트 D의 순서 번호는 초기 순서 번호로부터 1500바이트 떨어진 1600
그럼 확인 응답 번호엔 어떤 번호가 할당될까?
- 수신자가 다음으로 받기를 기대하는 순서 번호 (일반적으로
수신한 순서 번호 + 1
) - 확인 응답 번호 값을 보내기 위해서는 제어 비트에서 승인을 나타내는 비트인 ACK 플래그를 1로 설정해야한다.
2.3.3 제어 비트 (= 플래그 비트)
제어 비트(control bits) 또는 플래그 비트(flag bits)란, 현재 세그먼트에 대한 부가 정보를 나타내는 필드이며, 기본적으로 8비트로 구성된다.
- SYN: 연결을 수립하기 위한 비트
- ACK: 세그먼트의 승인을 나타내기 위한 비트
- FIN: 연결을 종료하기 위한 비트
ACK 비트가 1로 설정된 세그먼트는 ACK 세그먼트, SYN 비트가 1로 설정된 세그먼트는 SYN 세그먼트, FIN 비트가 1로 설정된 세그먼트는 FIN 세그먼트라고 부른다.
2.3.4 윈도우
수신 윈도우 (한 번에 수신하고자 하는 데이터의 양) -> 흐름제어를 위해서 사용
2.4 TCP 연결 수립과 종료
2.4.1 연결 수립: three-way handshake
three-way handshake란, 세 개의 단계로 이루어진 TCP 연결 수립 과정을 의미한다.
e.g., 호스트 A와 B가 three-way handshake를 한다고 가정
- 액티브 오픈(active open): 연결을 시작하는 호스트의 연결 수립 과정
- 패시브 오픈(passive open): 연결을 수락하는 호스트의 연결 수립 과정
2.4.2 연결 종료: four-way handshake
송수신 호스트가 각자 한 번씩 FIN과 ACK를 주고받으며 TCP가 연결을 종료한다.
- 액티브 클로즈(active close): 종료를 시작하는 호스트의 종료 과정
- 패시브 클로즈(passive close): 종료를 수락하는 호스트의 종료 과정
3. TCP state
3.1 stateful과 stateless 프로토콜
- state: 현재 어떤 통신 과정에 있는지를 나타내는 정보
- stateful 프로토콜: 상태를 유지하고 활용하는 프로토콜 (e.g. TCP)
- stateless 프로토콜: 상태를 유지하지 않고 활용하지 않으면서 동작하는 프로토콜 (e.g., UDP, HTTP)
3.2 TCP state 유형
- 연결이 수립되지 않은 상태
- 연결 수립 과정에서 주로 볼 수 있는 상태
- 연결 종료 과정에서 주로 볼 수 있는 상태
3.2.1 연결이 수립되지 않은 상태
- CLOSED
- 아무런 연결이 없는 상태
- LISTEN
- 일종의 연결 대기 상태 (SYN 세그먼트를 기다리는 상태)
- 서버로서 동작하는 패시브 오픈 호스트는 일반적으로 LISTEN 상태 유지
- LISTEN 호스트에게 STN 세그먼트를 보내면 쓰리 웨이 핸드셰이크 시작
3.2.2 연결 수립 상태
- SYN-SENT
- 연결 요청을 보낸 뒤 대기하는 상태
- 액티브 오픈 호스트가 SYN 세그먼트를 보낸 뒤 그에 대한 응답인 SYN+ACK 세그먼트를 기다리는 상태
- STN-RECEIVED
- 패시브 오픈 호스트가 STN+ACK 세그먼트를 보낸 뒤, 그에 대한 ACK 세그먼트를 기다리는 상태
- ESTABLISHED
- 연결이 확립되었음을 나타내는 상태
- 연결이 확립되었음을 나타내는 상태
3.2.3 연결 종료 상태
- FIN-WAIT-1
- 일반적인 TCP 연결 종료 과정에 있어 FIN-WAIT-1은 연결 종료의 첫 단계
- CLOSE-WAIT
- 종료 요청인 FIN 세그먼트를 받은 패시브 클로즈 호스트가 그에 대한 응답으로 ACK 세그먼트를 보낸 후 대기하는 상태
- 종료 요청인 FIN 세그먼트를 받은 패시브 클로즈 호스트가 그에 대한 응답으로 ACK 세그먼트를 보낸 후 대기하는 상태
- FIN-WAIT-2
- FIN-WAIT-1 상태에서 ACK 세그먼트를 받고 상대 호스트의 FIN 세그먼트를 기다리는 상태
- LAST-ACK
- CLOSE-WAIT 상태에서 FIN 세그먼트를 전송한 뒤 이에 대한 ACK 세그먼트를 기다리는 상태
- CLOSE-WAIT 상태에서 FIN 세그먼트를 전송한 뒤 이에 대한 ACK 세그먼트를 기다리는 상태
- TIME-WAIT
- 액티브 클로즈 호스트가 FIN 세금너트를 수신한 뒤, 이에 대한 ACK 세그먼트를 전송한 뒤 접어드는 상태
- 패시브 클로즈 호스트는 마지막 ACK 세그먼트를 수신하면 CLOSED 상태로 전이
- TIME-WAIT 상태의 액티브 클로즈 호스트는 일정 시간을 기다린 뒤 CLOSED 상태로 전이
- ACK 세그먼트가 전송될 때 잘못 전송되거나 유실될 수도 있기 때문에 TIME-WAIT만큼 기다린 후 종료
3.3 TCP 상태 확인하기
맥 OS나 리눅스 - 터미널을 열고
netstat
을 입력
4. UDP
4.1 UDP 데이터그램의 구조
UDP는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜
- 그래서 연결 수립 및 해제, 재전송을 위한 오류 제어, 혼잡 제어, 흐름 제어 등을 수행하지 않음
- 상태를 유지하지도 않음 -> stateless 프로토콜
- UDP는 TCP에 비해 적은 오버헤드로 패킷을 빠르게 처리
- 주로 실시간 스트리밍 서비스, 인터넷 전화처럼 실시간성이 강조되는 상황에서 TCP보다 더 많이 쓰임
UDP 데이터그램은 사실상 IP 헤더를 감싸는 껍데기
4.2 QUIC
QUIC(Quick UDP Internet Connections)는 두 종단 사이에 신뢰성 있는 데이터 전송을 위한 응용 계층 프로토콜로, 구글에서 개발한 고속 인터넷 전송 프로토콜이다.
- HTTP/2의 단점을 보완하기 위해 설계되었으며, 현재 HTTP/3로 발전해 표준화되었다.
- TCP 대신 UDP를 사용하여 더 빠르고 효율적인 웹 통신을 목표로 한다.
QUIC의 주요 특징
- UDP 기반
- 기존의 TCP 대신 UDP를 사용하여 연결 지연을 줄이고 빠른 데이터 전송을 지원
- TCP는 연결 설정 시 3-way handshake가 필요하지만, QUIC은 0-RTT 연결을 통해 초기 연결을 빠르게 시작할 수 있다.
- 연결지향적 + 보안적
- QUIC은 연결을 설정하기 위해 1번의 핸드쉐이킹만 필요하며, 보안을 위해 TLS를 내장하여 데이터를 암호화한다.
- TCP와 TLS는 2번의 핸드쉐이킹을 요구하지만, QUIC은 1번의 핸드쉐이킹으로 연결을 설정하고 데이터를 암호화하여 보안성을 강화한다.
- 스트림
- QUIC은 멀티플렉싱 기능을 제공하여, 여러 개의 스트림을 독립적으로 처리할 수 있다.
- 즉, 하나의 연결 내에서 여러 데이터 흐름을 동시에 전송하며, 각 스트림은 다른 스트림에 영향을 미치지 않는다.
댓글남기기