[Network] 전송 계층

DudeKYH·2024년 9월 28일

Network

목록 보기

7/8

전송 계층(Transport Layer)

전송 계층이란?

OSI 7계층 중 4번째에 위치한 계층이다
전송 계층은 계층 구조의 네트워크 구성요소와 프로토콜 내에서 송신자와 수신자를 연결하는 통신 서비스를 제공한다. - 나무위키

위의 설명을 봐도 정확히 전송 계층이 뭔지 아직 감이 잡히질 않는다.
우선 이전 OSI 3계층인 IP 계층을 다시 리마인드해보면
서로 다른 네트워크(WAN) 속에서 IP 주소를 통해 데이터들이 주고 받는다.
좀 더 자세히 설명하자면, IP 계층은 패킷이라는 단위로 송수신을 하는데,
패킷의 IP 헤더에는 출발지 IP 주소, 도착지 IP 주소가 포함되어 있기 때문에 여러 라우터들을 거쳐 데이터를 운반할 수 있는 것이다.
그리고, MTU라는 패킷의 최대 운반 크기(=통산 1500 Byte)만큼만 한 번에 운반이 가능하여, 그보다 데이터가 클 경우, 단편화를 진행하여 쪼개서 보내게 된다.
이 때, IP 헤더의 Identifucation / Flag / Fragment Offset 를 통해 단편화에 대한 정보를 담게 된다.

그러면 위 내용을 머릿속에 잘 그려놓고, 전송 계층이 정확히 무엇인지 알아가보자~

Port

우리는 앞서 OSI 2, 3계층은 MAC 주소와 IP 주소를 통해 데이터를 송수신하는 것을 알았다.
이 주소를 가지고 출발지의 컴퓨터에서 보내는 목적지의 컴퓨터까지 전달이 가능해졌다.

🤔그런데 이런 의문점이 생긴다.

우리는 컴퓨터를 사용하면서 많은 프로그램을 사용한다.
예를 들어, 카카오톡, 게임, 유튜브, 웹서핑 등이 있다.
컴퓨터가 어떠한 데이터를 받았다고 했을 때, 이 데이터는 과연 어떤 프로그램의 데이터로 판단을 해야하는 지 알 수 있는가?
😢없다!
위 문제점을 해결하기 위해 Port 라는 새로운 주소 체계가 탄생하였다.
통신하고자 하는 애플리케이션 간에 가상의 연결 통로를 만드는 작업을 연결 확립이라 하고 연결 통로의 출입구, 즉 애플리케이션과 연결 통로의 인터페이스를 포트(Port)라고 하며 포트를 식별하기 위한 주소를 포트 번호라고 합니다.

위와 같이 Port 를 통해 클라이언트는 특정 애플리케이션과 상대방의 애플리케이션 서버와 논리적인 연결을 맺어 데이터를 통신하게 된다.

Port의 종류

Port 번호 구간 : 0 ~ 65,535

1. Well-known Port

잘 알려진 포트로, 포트 번호에 이미 배정된 시스템이 예약되어 있다.(변경 불가능)

0 ~ 1,023 포트 번호의 구간을 가진다.

IANA(인터넷 할당 번호 관리 기구)에 의해 관리되고 있다.

<자주 볼 수 있는 Well-known Port>

2. Registered Port(=User Port)

특정 프로토콜이나 애플리케이션에서 사용하는 포트 번호

1,024 ~ 49,151 포트 번호의 구간을 가진다.

우리가 직접 사용 가능한 포트 번호지만, 몇몇은 이미 특정 프로토콜이 사용 중이므로 주의가 필요하다

<자주 볼 수 있는 Registered Port>

3. Dynamic Port(=Private Port)

서버가 클라이언트를 식별할 때 사용합니다.

예를 들어, 클라이언트는 서버와 통신하기 위해 운영체가 할당해준 Dynamic Port 중 동적으로 하나의 포트 번호를 사용하여 서버와 통신을 하게 된다.

49,152 ~ 65,535 포트 번호의 구간을 가진다.

전송 계층 프로토콜

전송 계층의 프로토콜은 크게 TCP, UDP 2가지로 나눌 수 있다.
각각 무엇인지 자세하게 알아보자.

TCP(Transmission Control Protocol)

신뢰할 수 있고 정확한 데이터를 전달하기 위해 연결형 통신을 사용하는 프로토콜입니다.
TCP 프로토콜은 데이터를 패킷이라는 여러 개의 작은 조각으로 분할하고, 패킷의 전송 속도를 조절하여 패킷이 수신지까지 제대로 전송되는지 확인한다.
네트워크의 혼잡도와 여러 경로의 라우팅에 따라 분할된 패킷들이 송신한 순서와 다르게 수신될 수 있는데, TCP 프로토콜은 수신자에게 도착한 여러 패킷들을 모두 확인하여, 올바른 순서대로 재조립함으로써 데이터 전송의 정확성과 신뢰성을 보장한다!

TCP 헤더 (20 Byte)

TCP 통신 과정을 이해하기 전에 TCP 헤더에는 어떤 필드들이 있는지 알아보자.
그리고, 밑에서 설명할 통신 과정에 대해서 TCP 헤더의 필드들이 어떻게 사용되는지도 함께 알아보자.

Source Port(16 bit)
- 출발지 Port 번호
Destination Port(16 bit)
- 도착지 Port 번호
Sequence Number(32 bit)
- 데이터 순서 번호
Acknowledgment Number(32 bit)
- 수신한 데이터의 다음 수신할 데이터 순서 번호
Offset(4 bit)
- TCP 헤더의 Byte 크기
- TCP 헤더의 길이 ÷ 4 한 값을 2진수로 담는다. (20Byte = 이진수 0101)
- TCP 헤더 영역과 데이터 영역을 구분하기 위해 Offset 필드가 필요하다
Reserved(6 bit)
- 예약된 필드
- 현재는 사용되지 않는 공간이다.
TCP Flags(6 bit) :
- Urgent(URG) : 우선순위를 지정하는 플래그
- Acknowledgement(ACK) : 응답 확인 플래그
- Push(PSH) : 버퍼링 없이 데이터를 즉시 전달하는 플래그
- Reset(RST) : 비정상 세션을 종료하는 플래그
- Synchronization(SYN) : 세션 연결 시작 플래그
- Finish(FIN) : 세션 정상 종료 플레그
Window(16 bit)
- 자신의 수신 버퍼 여유공간의 크기를 담는 필드
- Windows 필드를 통해 TCP의 흐름 제어 기능을 제공한다.
- 송신자는 수신자의 Window 값을 통해 얼마나 보낼 수 있는지를 알 수 있다.
- 또 네트워크 혼잡 상태에 따라 Windows 크기를 변경하기도 한다.
Checksum(16 bit)
- 데이터의 무결성을 확인하기 위해 필요한 필드
- 통신 간의 데이터의 비트 변조나 오류가 발생했는지를 Checksum을 통해 확인 가능!
Urgent Pointer(16 bit)
- 어디서부터 Urgent 시작위치인지 알려주는 필드

위의 TCP 헤더와 Payload(=데이터)를 붙여 TCP 프로토콜은 세그먼트(Segment) 단위로 데이터를 송수신한다.

TCP의 패킷 분할과 조립 과정

TCP 프로토콜은 데이터의 크기가 MSS(Maximum Segment Size)보다 클 경우, 분할하여 보내게 된다.

MSS(Maximum Segment Size)란?

TCP에서 데이터를 분할하는 단위를 뜻한다.

일반적으로 사용하는 표준 MSS의 크기는 1,460 Byte이다

이는 MTU(=1,500 Byte)에서 TCP header와 IP hearder의 크기를 뺀 값이다.

TCP 프로토콜은 전송할 데이터가 클 경우, 여러 패킷으로 분할하고 각각 TCP 헤더를 붙어 세그먼트 단위로 보내게 된다.

위 그림은 송신 호스트가 MSS보다 큰 데이터를 보내게 될 경우의 통신 과정을 보여주고 있다.

1) 송신자는 MSS 크기보다 큰 데이터를 보낼려고 한다.
2) TCP 프로토콜은 데이터를 MSS 단위로 패킷 분할하고 각각 TCP 헤더를 붙여주어 세그먼트 단위로 캡슐화를 한다.
3) 하위 OSI 계층을 통해 수신 호스트에게 전달된다.
4) 수신 호스트는 여러 세그먼트를 수신한다.
5) TCP 헤더의 여러 정보들을 토대로 순서대로 재조립하여 본래의 데이터로 합친다.

지금부터는 TCP의 연결 시작 / 연결 종료 / 데이터 전송에 대한 과정을 살펴보면서
TCP의 특징인
1) 연결 지향
2) 정확성과 신뢰성이 보장
어떻게 가능한 지 알아보자

3-way handshake : TCP의 연결 확립 과정

위 그림은 Client가 Server와 연결을 맺는 과정을 보여주고 있다.

1) STEP 1 : Client ▶ SYN_SENT

클라이언트는 서버에 연결을 요청하는 SYN Segment를 보낸다.
- TCP Flags의 SYN bit를 1로 설정한다.
- Sequence Number는 클라이언트의 최초 순서 번호(=client_isn[100])로 설정한다. (isn = initial sequence number)
- 그리고 서버로부터 ACK 응답을 기다리는 동안 SYN_SENT 상태가 된다.

2) STEP 2 : Server ▶ SYN_RECEIVED

서버가 클라이언트의 SYN Segment에 대한 ACK Segment를 전송한다.
- Acknowledgment Number는 client_isn + 1[101] 로 설정한다.
- Sequence Number는 서버의 최초 순서 번호(server_isn[200])로 설정한다.
동시에 서버가 클라이언트에게 연결을 요청하는 SYN Segment를 전송한다.
- SYN bit를 1로 설정한다.
그리고 SYN/ACK Segment를 전송하고 SYN RCVD의 상태로 클라이언트의 ACK를 기다린다.

3) STEP 3 : Client ▶ ESTABLLISHED

클라이언트는 서버의 SYN Segment에 대한 ACK Segment[201]를 전송한다.
- 연결 요청이 아니기 때문에 SYN bit를 0으로 설정한다.
클라이언트는 서버로부터 ACK Segment을 받고 연결이 완료된 ESTABLLISHED 상태가 된다.

4) STEP 4 : Server ▶ ESTABLLISHED

서버는 클라이언트의 ACK Segment를 받고 연결이 완료된 ESTABLLISHED 상태가 된다.

5) 클라이언트와 서버는 3-way-handshake 과정을 통해 연결이 완료되었다.

4-way handshake : TCP의 연결 종료 과정

위 그림은 Client가 Server와 연결을 종료하는 과정을 보여주고 있다.

1) STEP 1 : Client ▶ FIN_WAIT1

클라이언트가 연결을 종료하겠다는 FIN Segment를 보낸다.
- TCP Flags의 FIN bit를 1로 설정한다.
그리고 서버로부터 ACK 응답을 기다리는 동안 FIN_WAIT1 상태가 된다.

2) STEP 2 : Server ▶ CLOSE_WAIT

클라이언트가 보낸 FIN Segment를 받고, 응답을 ACK Segment를 보낸다.
그리고 못보낸 데이터를 다 보낼 때까지 CLOSE_WAIT 상태가 된다.

3) STEP 3 : Client ▶ FIN_WAIT2

서버가 자신이 보낸 FIN Segment에 대한 ACK Segment를 받게 된다.
그리고 서버가 못보낸 데이터를 다 받을 때까지 FIN_WAIT2 상태가 된다.

4) STEP 4 : Server ▶ 못 보낸 패킷을 모두 보낸다.

5) STEP 5 : Server ▶ LAST_ACK

모든 데이터를 보내고 연결을 종료할 준비가 되면, 연결해지를 위한 준비가 되었음을 알리기 위해 클라이언트에게 FIN Segment를 전송한다.
- TCP Flags의 FIN bit를 1로 설정한다.
그리고 서버는 클라이언트의 ACK 응답을 기다리는 동안 LAST_ACK 상태가 된다.

6) STEP 6 : Client ▶ TIMED_WAIT

서버의 연결 해지 준비가 되었다는 ACK Segment를 받고 확인했다는 ACK Segment를 서버에게 보낸다.
그리고 클라이언트는 TIMED_WAIT 상태가 된다.
※ 왜 클라이언트가 바로 연결을 종료하지 않고 TIMED_WAIT 상태를 거치는 이유
- 클라이언트가 서버로부터 FIN Segment를 받았다고 하더라도 네트워크 환경에 따라서
  아직 서버가 CLOSE_WAIT 상태일 때 보낸 데이터가 아직 클라이언트에게 도착하지 않았을 가능성이 있다.
  - 만약, TIMED_WAIT 상태 없이 바로 연결을 CLOSED 한다면, 아직 못받은 데이터는 유실되는 것이므로 TCP의 신뢰성이 깨지게 된다.
  - 따라서, 클라이언트는 일정 시간동안의 TIMED_WAIT 상태에 머물러서 잉여 패킷을 받기 위해 기다리게 된다.

7) STEP 7 : Server ▶ CLOSED

클라이언트의 ACK Segment를 받으면, 서버는 클라이언트와의 세션 연결을 Close한다.

8) STEP 8 : Client ▶ CLOSED

일정 시간동안 TIMED_WAIT 상태를 머무르다가 세션 연결을 Close한다.

TCP의 데이터 전송 과정

위 그림은 송신 측에서의 데이터 전송 과정을 보여준다.

총 8000 Byte의 데이터를 MSS 크기 단위로 분할하고 각각 Segment로 캡슐화하여 보내고 있다.
각 세그먼트의 Sequence Number(=순서 번호)를 +1460 하여 순서를 기록할 것이다.

위 그림은 수신 측에서의 데이터 수신 과정을 보여준다.

첫번째로 수신한 Segment의 Sequence Number(=순서 번호) + 1한 값을 Acknowledgment Number로 넣어 송신 측에게 전달한다.
그리고 수신 측의 ACK Segment를 받은 송신 측은 2번째인 세그먼트를 보내고
수신 측은 또 확인하여 ACK Segment를 보내는 과정을 반복한다.
만약, 데이터 전송 과정에서 문제가 발생하여 수신 측에 데이터가 오지 않을 경우, 아무런 ACK Segment를 보내지 않는다.
그러면 송신 측에서 보낸 Segment에 대한 ACK Segment가 일정 시간 동안 응답이 오지 않을 경우,
데이터를 재전송하여 데이터 전송의 "신뢰성"을 보장한다!

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

위의 TCP 데이터 전송 과정을 보면 송신측은 세그먼트를 보낼 때마다 송신 측의 응답을 확인하고 다음 세그먼트를 보내고 있다.
이렇게 되면 송신 측은 확인에 대한 응답이 돌아올 때까지 아무 일도 하지 않고 기다리게 되면서
결국 패킷의 전송 속도가 지연되게 된다!!!

이는 매우 비효율적인 전송 과정이기 때문에 TCP 프로토콜은 슬라이딩 윈도우 기법을 통해
흐름 제어(Flow Control) 기능을 제공하여 효율적이고 신뢰성있게 데이터를 전달한다.

TCP 헤더의 필드 중 Window를 보았을 것이다.

윈도우 사이즈는 수신자가 한 번에 받아낼 수 있는 수신 가능한 버퍼의 크기를 의미한다.
따라서, 송신 측은 Window 수치를 확인하고 초과하지 않는 선에서
여러 세그먼트를 한 번에 전송한다.

Window Size의 결정 시점

3-way-handshake 과정에서 수신자가 Window 크기에 대한 초기값을 헤더의 Window 필드에 기록하여 알려준다.

그 후, 지속적으로 ACK 확인 응답을 보낼 때마다 수신자는 자신의 수신 버퍼 여유 공간을 확인하여 알려준다.

UDP(User Datagram Protocol)

UDP 프로토콜의 특징은 다음과 같다.

비연결형 통신을 지향한다
신뢰성이 낮다.
흐름 제어, 순서 제어 기능이 없다.
TCP보다 통신 속도가 빠르다
- 당연한 얘기겠지만, TCP가 제공하는 연결 지향, 흐름 제어, 순서 제어, 신뢰성 있는 통신에 대한 기능을 제공하지 않기 때문에 UDP가 빠른 것이다.

UDP 프로토콜은 TCP와 정반대의 성향을 가지고 있는 것 같다.

UDP 헤더 (8 Byte)

Source Port (16 bit)
- 출발지 Port 번호
Destination Port (16 bit)
- 도착지 Port 번호
Length (16 bit)
- UDP 헤더의 크기(=8 Byte)를 포함한 패킷 전체의 길이를 Byte 단위로 표시
- 최대 크기 : 65,535 - 8(UDP 헤더) - 20(IP 헤더) = 65,507 Byte
Checksum (16 bit)
- 최소한의 에러 검출을 위한 Checksum 필드
- 0 이면, 수신측은 Checksum 계산도 하지 않는다.

참고자료

https://better-together.tistory.com/134 [변계사 Sam의 테크 스타트업!:티스토리]
https://better-together.tistory.com/140 [변계사 Sam의 테크 스타트업!:티스토리]
https://ghdwlsgur.github.io/docs/Network/TcpHeader [TCP 헤더 읽어드립니다]

DudeKYH

게임서버프로그래머를 꿈꾸는 자

이전 포스트

[Network] 네트워크 계층

다음 포스트