개요
이전 시간에는 TCP/IP 3계층인 네트워크 계층을 배웠는데요. 네트워크 계층에서는 라우터와 IP를 통해 외부 네트워크에 있는 목적지로 전송할 수 있는 것을 알아봤습니다. 그렇다면 그렇게 전송받은 데이터를 PC 내부에서 어떤 응용프로그램으로 전달해줘야 할까요? 그 해답은 바로, 이번 시간에 배울 전송 계층입니다.
전송계층의 특징
데이터를 받긴 받았는데..
데이터를 받긴 받았는데.. 이거 누구꺼야?
예를 들어, 내가 게임을 하고 있는데 브라우저에서 요청한 데이터가 게임한테 가면 안되겠죠? 이 데이터가 누구로부터 온것인지, 누구한테 보내는건지에 대한 정보를 바로 네트워크 계층에서 알고 있습니다.
연결형 통신(TCP), 비 연결형 통신(UDP)
전송 계층의 또 다른 특징으로는 신뢰성/정확성 그리고 효율성으로 구분할 수 있습니다.
신뢰성/정확성은 보통 연결형 통신이라 하고, 효율성은 비 연결형 통신이라고 합니다.
연결형 통신은 매번 확인을 합니다.
a: 님 데이터 보내도 됨?
b: ㅇㅇ 보내셈
a: 데이터 보냄ㅋ
b: ㅇㅋ 잘 받음
a: ㅇㅋ비 연결형 통신은 확인을 하지 않습니다.
a: 데이터 보냄
a: 데이터 보냄
a: 데이터 보냄
a: 데이터 보냄
...이 둘은 목적 자체가 다릅니다. 연결형은 신뢰성과 정확성을 추구하는 통신이고, 비연결형은 효율성이 더 우선인 통신이기 때문입니다.
보통 연결형 통신은 꼭 전달이 잘 이뤄져야 하는 채팅 등에 사용되고, 비 연결형은 동영상과 같이 데이터가 유실되도 괜찮은 곳에 사용됩니다.
TCP, UDP에 대해서는 아래에서 더 자세하게 다루겠습니다.
TCP: 연결형 통신
위에서 TCP 통신은 신뢰성과 정확성을 추구하는 연결형 통신이라고 했습니다.
위 그림에서 전송계층을 보면, 응용계층에서 데이터를 받아 헤더를 붙이는 과정(캡슐화)을 수행합니다. 이때 헤더 + 데이터를 세그먼트라고 부릅니다. TCP 헤더를 살펴보면 위에서 살펴본 전송계층의 특징을 어떻게 수행하는지도 알 수 있습니다.
TCP 헤더를 살펴봅시다!
제일 먼저 보이는 부분이 출발지, 목적지 포트 번호입니다. TCP 헤더에 이 정보가 포함되어 있으니 어디서 보냈고 어디로 보내져야할지가 정해졌네요! 다른 부분들을 다 살펴보기 보다는 중요한 부분들만 살펴보겠습니다.
연결 확립을 위한 3-way handshake
3-way handshake란 송신측과 수신측이 데이터를 주고받기 위해 연결을 수립하는 과정을 말합니다. 이때 패킷을 세번 주고 받으면서 연결을 수립하는데요, 이때 TCP 헤더의 코드 비트를 이용합니다.
코드 비트 부분을 살펴볼까요?
여기서 제일 중요한 부분은 ACK, SYN, FIN 이 세 가지에요.
- ACK: 확인했다는 의미
- SYN: 연결 하겠다는 의미
- FIN: 완료했다는 의미
그럼 3-way handshake는 다음과 같이 진행될 것입니다.
- 송신 측: 연결 확립 요청
- SYN: 1
- 수신 측: 연결 확립 응답 + 연결 확립 요청
- SYN: 1, ACK: 1
- 송신 측: 연결 확립 응답
- ACK: 1
연결 종료를 위한 4-way handshake
그럼 4-way handshake는 다음과 같이 진행될 것입니다.
- 송신 측: 연결 종료 요청
- FIN: 1
- 수신 측: 연결 종료 응답
- ACK: 1
- 수신 측: 연결 종료 요청
- FIN: 1
- 송신 측: 연결 종료 응답
- ACK: 1
이 정도면 정말이지.. TCP는 확인 중독인 것 같다..
지금 몇 번째 이게 데이터지..? (일련번호와 확인 응답 번호)
이제 그 패킷은 비트열로 변환되어 전송되게 됩니다. 그럼 여기서 의문이 생기죠? 저 패킷들을 보내는 것은 알겠는데 받는 쪽에서는 저 패킷이 A라는 이미지의 패킷인지 또 몇 번째 패킷인지.. 가 궁금할거에요. 이 부분에 대해서는 뒤에서 배우는 TCP라는 녀석을 배우면 이해가 될 것 입니다.
혹시 제일 첫번째 시간에서 이미지를 전송하는 방법에 대해서 기억나시나요? 엄청 큰 이미지를 전송할 때, 한방에 보내면 데이터의 크기도 너무 크고 시간이 오래 걸리니까 잘게 쪼개서 보낸다고 했습니다.
그럼 그 잘게 쪼갠 패킷의 순서가 중요하겠죠? 예를들어 제가 채팅을 123456789… 라고 보냈는데 크기가 너무 커서 쪼개서 보냈는데 순서가 뒤죽박죽이면 받는쪽에서 987654… 이런식으로 받으면 안되잖아요? 그걸 어떻게 잘 보내는 것일까요? 바로 TCP 헤더에 있는 일련번호와 확인 응답 번호가 이 문제를 해결해줄 것입니다!
일련번호는 송신 측에서 수신 측에 이 데이터가 몇 번째 데이터인지 알려줍니다.확인 응답 번호는 수신 측에서 송신 측에 몇 번째 데이터를 받았는지 알려주는 것입니다.
데이터를 분할하여 보낼 때 다음과 같은 프로세스로 진행됩니다.
- 3 핸드 셰이크 수립 시 일련번호와 확인 응답 번호가 결정됩니다.
- 송신 측은 수신 측에게
일련번호: 1, 확인 응답 번호: 1001을 보냅니다. - 수신 측은 잘 받았다는 의미로
일련번호: 1001, 확인 응답 번호: 101을 보냅니다. - 2,3을 반복합니다.
만약 데이터를 제대로 못받았다면, 송신 측에서는 다시 재전송합니다.
윈도우 크기
TCP 헤더에는 윈도우 크기라는게 있습니다. 이를 이용해서 세그먼트들을 저장할 수 있는 버퍼로 활용되는데요. 3 핸드 셰이크 단계에서 서로의 윈도우 크기를 주고 받아 둘 중 적은 윈도우 크기를 버퍼 공간으로 사용합니다.
이 버퍼 공간은 세그먼트들을 여러 개를 받아서 한번에 확인 응답을 보낼 수 있도록 하는 공간입니다. 매번 세그먼트를 받았을 떄마다 응답을 하면 그만큼 지연도 있고 비효율적이니까요.
이 버퍼를 이용하면 다음과 같이 통신할 수 있습니다.
송신 측 <-> 수신 측
----------------
데이터 ->
데이터 ->
데이터 ->
<- 확인 응답
<- 확인 응답
<- 확인 응답
...윈도우 크기 만큼만 세그먼트들을 저장할 수 있다는 점을 꼭 기억해야 합니다.
목적지가 어딜까? (포트 번호)
데이터를 받긴 받았는데 이 데이터가 어디로 가야 하는지 어떻게 알까요?
바로 목적지 포트 번호를 통해 알 수 있습니다. 예를들어 제가 8080포트로 어플리케이션을 띄워놓고 다른 PC에 있는 MySQL(3306)로 요청을 보낸다면 출발지 포트 번호는 8080이 되고, 목적지 포트 번호는 3306이 되겠#죠?
UDP: 비연결형 통신
UDP는 TCP와 달리 효율성을 중요시하는 프로토콜입니다. 그래서 매 통신마다 확인을 받지 않습니다. 어 그러면 데이터가 유실되는거 아닌가요? 라고 생각하실 수 있습니다.
그래서 UDP는 동영상같은 서비스에 많이 활용됩니다. 동영상을 TCP로 통신하면 너무 오래걸리기 때문에 UDP 프로토콜을 사용합니다.
UDP 헤더
UDP 헤더는 UDP 데이터그램이라고 합니다. TCP에 비하면 헤더의 들어간 데이터들이 정말 적습니다.
세그먼트 통신 방식
송신 측 <-> 수신 측
----------------
데이터 ->
데이터 ->
데이터 ->
데이터 ->
데이터 ->
데이터 ->
...TCP와 다르게 3핸드셰이크도 없고, ACK도 안받습니다. 그냥 무작정 데이터만 계속 보내고 있습니다.
이처럼 UDP는 효율성을 중요시 하기 때문에 연결 수립이나 ACK를 받지않고, 데이터를 빠르게 보내서 효율적인 통신을 할 수 있게 해줍니다. 다만 데이터가 유실될 수 있다는 점이 있기 때문에 신뢰성이 요구되는 서비스에서는 피하시는게 좋습니다.
글 읽어주셔서 감사합니다!
[목차] 네트워크 기초 시리즈 (앞으로 쭉 포스팅할 예정!)
- 네트워크를 들어가기 앞서 (OSI 7 Layer, TCP/IP 5 Layer, 캡슐화란?)
- 물리 계층에서는 어떤 일을 할까? (TCP/IP 1 Layer)
- 데이터 링크 계층에서는 어떤 일을 할까? (TCP/IP 2 Layer)
- 네트워크 계층에서는 어떤 일을 할까? (TCP/IP 3 Layer)
- 전송 계층에서는 어떤 일을 할까? (TCP/IP 4 Layer)
- 응용 계층에서는 어떤 일을 할까? (TCP/IP 5 Layer
