이번에는 전송계층에서의 프로토콜인 TCP / UDP에 대해서 알아보았다.
TCP는 생소한 개념들과 여러 정보들이 많이 포함되어 있기에 복잡한 면이 있지만,
이를 잘 정리하고 이것을 기반으로 이해하고 외울 수 있다면 반대되는 개념인 UDP는 쉽게 이해가 가능하다.
TCP / UDP 두 프로토콜 모두 OSI 7계층 중 전송계층에서 사용되는 프로토콜이다.
모두 데이터를 전송하기 위해 사용되지만 방식과 특징에서 차이가 있다고 할 수 있는데,
가장 큰 차이점은 무엇일까?
바로 '신뢰성'에 있다.
TCP는 데이터의 신뢰성을 보장하고, 그에 따라 복잡한 과정과 기능들이 존재한다.
UDP는 데이터의 속도와 효율성을 보장한다. 즉, 신뢰성이 없고 보다 단순한 과정으로 이루어져 있다.
이 '신뢰성'이라는 단어에는 많은 뜻을 내포하고 있다.
TCP를 예로 들어볼 때, 내가 상대방과 통신을 하고 싶다.
TCP는 신뢰성을 보장해야 하기 때문에, 여러 필요한 절차들이 있을 것이다. 아래는 간략한 예시이다.
- 둘 사이에서 데이터가 실제로 잘 오고 가는지에 대한 확인도 필요할 것이다.
- 데이터를 여러 개(간단하게 1, 2, 3, 4라고 해보자)를 보낸다고 하면, 데이터가 상대방에게 도착할 때도 1, 2, 3, 4로 도착할 수 있게끔 순서번호도 보장을 해줘야 할 것이다.
- 데이터 전송 과정 중 중간에 데이터가 손실이 되었다면, 재전송을 통해서 다시 올바르게 상대방에게 도착할 수 있도록 보장을 해줘야 할 것이다.
이러한 일련의 과정을 통해서 TCP를 우리가 '신뢰성'이 있다고 이야기를 한다.
그렇다면 반대되는 UDP는? 그냥 빨리 보내는 기능을 한다.
위의 TCP와는 다르게 신뢰성을 위한 행동은 아무것도 없다.
이러한 두 프로토콜의 차이점을 구분한 상태에서 자세하게 알아보자.
TCP
연결 지향적 프로토콜이다.
연결 지향적(Connection-Oriented)이라는 말은 TCP에서 어떻게 이해하면 될까.
이 말은 즉, 연결된 상태에서 데이터를 주고받는다 ⇋ 연결이 성공해야 통신이 가능하다..라는 의미이다.
아래에서 TCP가 연결을 성립하기 위한 방식을 말하는 3-way handshake라는 방식에 대해 알아볼 예정이지만
간단하게 이야기해 보면, TCP는 통신을 시작하기 전에 먼저 연결을 설정하고, 데이터를 전송하고 나서 연결을 종료한다.
이러한 방식으로 데이터가 신뢰성 있게(정확하고 안정적으로) 전송될 수 있다.
이전 글에서 OSI 7 계층 중 전송계층의 전송단위가 TCP에서는 세그먼트(Segment)라는 것을 알아두었다.
TCP가 뭔지 대충 알겠고, 전송단위도 세그먼트라는 것을 알았으니
어떻게 이 TCP라는 프로토콜이 작동하는지에 대해 알아보자.
일단은 전송할 데이터를 일정한 단위로 나눌 것이다.
그리고 그 각각의 단위에 'TCP 헤더'라는 것을 추가한다.
그렇게 '세그먼트(TCP 세그먼트)'라는 전송단위가 생성되는 것이다.
그리고 전송계층의 하위계층인 네트워크 계층으로 전달되는 방식이다.
즉, 세그먼트의 구성 = TCP헤더 + 데이터(*데이터 페이로드)로 구성되어 있다고 할 수 있다.
*데이터 페이로드란 프로토콜 관점에서 전송되는 실질적인 데이터 부분을 가리키는데, 헤더와 데이터를 구분하기 위해 사용된다.
데이터라고 이해해도 좋다. 두 용어 모두 일반적으로 데이터를 전송하는 데 사용되는 정보를 가리킨다.
TCP 헤더
TCP 헤더를 알아보기 전에 헤더라는 개념을 간략하게 짚고 넘어가 보자.
헤더 : 데이터 구조에서 시작 부분이며 해당 데이터의 전송 및 처리를 위한 중요한 정보들을 제공한다.
네트워킹에서 프로토콜에 따라 구성요소가 다를 수 있으나 주로 데이터 형식, 시간, 주소 데이터 등으로 구성되었다.
사실 보안뿐만 아니라 IT는 공부할수록 너무나도 많은 개념과 정보들이 존재하기에
위와 같은 개념 앞으로 계속 공부하면서 자세하게 알아보는 시간을 가져보자.
TCP 헤더는 그럼 뭐라고 설명해야 할까?
TCP 헤더는 세그먼트의 시작 부분에 위치하여 데이터의 전송 및 수신을 관리하기 위한 정보를 담고 있다.
그렇다면 TCP헤더는 어떠한 구조로 이루어져 있을까?
TCP 헤더의 구조
TCP 헤더는 아래에서 알아볼 UDP 헤더와는 달리 굉장히 복잡한 구조를 가진다.
신뢰성을 보장하고자 하는 TCP는 당연하게 많은 과정을 거칠 수밖에 없고, 그에 따라 복잡한 헤더 구조를 가진다.
우리는 예측할 수 있다.
UDP는 단순한 헤더구조를 가지고 통신을 하기에 속도가 빠르겠구나 → O
TCP는 복잡한 구조를 가지고 있기에 UDP에 비해 속도가 느리겠구나 → O
TCP헤더는 다음과 같이 구성되어 있다.
위의 그림에서 각 부분(Source Port : 발신지•출발지 포트 주소, Sequence number 등)을 TCP 헤더의 '필드'라고 간주된다.
'필드'는 헤더의 각 부분을 구성하는 구성 요소라고 한다.
1. 출발지 *포트(Source Port, 16 bits)
세그먼트를 생성한 송신 측의 *포트 번호.
즉, 수신 측은 세그먼트가 어떤 송신자로부터 왔는지 식별이 가능하다.
*포트(Port) 논리적 접속 장소, 프로그램 또는 서비스 간의 데이터 통신을 원활하게 수행할 수 있도록 한다.
즉, 서버와 클라이언트 간에 데이터 통신을 가능케 하는 역할을 하며 전기 플러그에 비유될 수 있다.
컴퓨터 네트워크에서 포트는 '데이터를 주고받는 창구'라고 할 수 있을 것이다.
하지만 컴퓨터는 많은 프로그램과 서비스를 동시에 실행할 수 있는데,
각각의 프로그램은 고유한 식별번호인 '포트 번호'라는 것을 가지고 있다.
이러한 포트 번호는 특정 프로그램이나 서비스를 컴퓨터 내에서 식별하는 데 사용되며,
이를 통해 컴퓨터는 어떤 프로그램이나 서비스에 데이터를 전달해야 하는지 알 수 있다.
2. 목적지 포트(Destination Port, 16 bits)
세그먼트가 전송되어야 하는 수신 측의 포트 번호.
즉, 세그먼트를 수신할 수신자를 지정할 수 있다.
3. 시퀀스 번호(Sequence Number, 32 bits)
송신 측에서 각 세그먼트에 지정하는 일련번호.
수신 측은 이러한 시퀀스 번호 덕에 데이터의 추적과 순서 파악 및 순서 재구성이 가능하다.
위와 같은 특징으로 데이터를 올바르게 순서대로 보낼 수 있으므로 신뢰성 있는 기능을 한다고 할 수 있다.
이 시퀀스 번호 필드는 수신 측이 TCP 세그먼트에 지정된 시퀀스 번호를 사용하여
데이터를 올바른 순서로 재구성할 수 있다는 점에서 순서 번호와 관련되어 있다고 알아두자.
4. 확인 응답 번호(Acknowledgment Number, 32 bits)
송신 측이 수신 측으로 보낸 데이터가 제대로 전송되었는지 확인 응답으로 사용한다.
즉, 데이터가 수신 측으로 올바르게 전달되었는지 확인 가능하다.
어떠한 방식으로 확인을 할까?
송신 측이 데이터를 전송한 후 수신 측으로부터 확인 응답을 기다리고
수신 측은 받은 데이터의 시퀀스 번호를 확인 후 이를 확인 응답 번호로 송신 측에게 전송하는 방식이다.
이렇게 데이터가 잘 오고 가는지 확인하는 용도로 사용되며, 이 또한 신뢰성을 보장하기 위한 행위라고 할 수 있다.
5. 데이터 오프셋(Data Offset, 4byte(32 bits))
Hlen이라고도 불린다.
TCP 세그먼트의 시작 부분을 기준으로 TCP 헤더의 길이를 나타낸다.
이때, TCP 헤더의 길이를 몇 개의 4byte로 구성되는지 나타내는데,
이를 통해 수신 측은 세그먼트 내의 헤더와 데이터를 올바르게 식별하고 처리할 수 있다.
6. 제어 비트(Flags 또는 Control Bits, 6 bits)
URG(긴급), ACK(확인 응답), PSH(즉시 전송), RST(재설정), SYN(동기화), FIN(종료)와 같은
플래그 비트라고 불리는 것들을 통해, 흐름제어 오류제어 등 다양한 제어 기능 제공한다.
7. 윈도 크기(Window Size, 16 bits)
수신 측이 현재 받을 수 있는 데이터의 양을 나타내는 값.
송신 측은 이 값을 고려하여 데이터의 흐름을 제어할 수 있다.
8. 체크섬(CheckSum, 16 bits)
TCP 세그먼트 헤더와 데이터의 무결성을 확인하기 위해 오류 검출 역할을 한다.
즉, 모든 송수신 과정에서 오류가 있는지 없는지 체크를 한다.
UDP 헤더에도 체크섬이 존재하기 때문에 UDP 부분에서 다시 한번 알아보자.
9. 긴급 포인터(Urgent Pointer, 16 bits)
TCP 세그먼트 내에서 우선적으로 처리되어야 하는 긴급 데이터가 포함된 세그먼트 내에서의 위치를 나타낸다.
이를 통해 수신 측은 긴급 데이터를 신속하게 처리할 수 있다.
일반적으로 긴급 데이터는 중요한 제어 정보, 긴급 메시지를 포함한다.
10. 옵션(Options, 가변 길이 0~40byte)
TCP 헤더는 여러 가지 옵션(MSS, SACK...)을 포함하는데, 이러한 옵션들로 특정 기능을 활성화하고 동작을 지원한다.
11. 예약(Reserved, 6 bits)
이 필드는 현재는 사용되지 않는 비트를 의미하며 이때, 0으로 설정되어 있다.
TCP 헤더의 구조를 유지하기 위해 예약되어 있는 비트이며, 향후 프로토콜의 확장이나 업데이트에 대비하여 예약되어 있다.
12. 패딩(Padding)
TCP 헤더의 길이를 일정 크기로 유지하기 위해 사용된다.
헤더의 길이가 특정 크기에 도달하지 않을 때, 추가 바이트를 삽입하여 헤더의 크기를 필요한 만큼 확장한다.
이는 특정 네트워크 요구 사항에 따라 헤더의 크기를 일정하게 유지하고 정렬을 유지하기 위해 사용된다.
패딩은 헤더의 일관된 구조를 유지하는 데 도움이 된다고 할 수 있다.
이러한 Reserved, Padding 필드들은 TCP 프로토콜의 향후 확장 및 유연성을 고려하여 설계되었다.
정확한 헤더 구조와 크기의 유지는 데이터 통신의 안정성과 효율성을 보장하기 위해 중요하다.
이렇게 복잡한 헤더 구조와 각각의 특징을 보았을 때,
TCP가 안정적이고 신뢰성 있는 데이터의 전송을 지원한다는 것을 다시 알 수 있다.
TCP 세그먼트의 전송제어와 같은 제어 기능들이
데이터를 신뢰성 있게 전달하기 위한 매우 중요한 역할을 한다고 할 수 있다.
TCP 헤더 중 제어비트(Flags 또는 Control Bits)에는 여러 플래그(혹은 플래그비트)라고 불리는 것들이 포함되어 있다.
위에서 간략하게 알아보았던 URG, ACK 등이 이에 포함된다.
여기에는 주요 플래그 6가지가 있는데, 자세하게 알아보자.
TCP-Flags
1. URG(긴급)
긴급한 데이터가 포함되어 있음을 나타낸다.
이 플래그가 설정되면 긴급 포인터 필드가 유효해지며, 수신 측에게 해당 위치부터 데이터를 즉시 처리해야 함을 알려준다.
"필드가 유효해진다"는 표현은 해당 필드가 사용 가능하거나 유효한 값을 가질 수 있는 상태가 된다는 의미이다.
쉽고 자세하게 풀어서 알아보자
이 URG 플래그는 평상시에 비활성화되어 있는 것이 특징이다.
하지만 만약 긴급상황이 발생해서 긴급하게 데이터를 보내야 한다면 이 URG 플래그가 활성화된다.
또한 위에서 TCP 헤더 구조를 알아보았을 때 긴급 포인터(URG Pointer)라고 불리는 필드가 있었는데,
이 필드가 동시에 작동된다.
그 말을 즉, 평상시에는 URG Pointer 필드도 뭔가 동작하는 게 없었다는 것이다.
URG 플래그가 동작을 하며 URG Pointer 필드도 같이 동작을 하는 점을 알아두자.
2. ACK(확인)
확인 응답 번호를 포함하고 있음을 나타낸다.
이 플래그가 설정되면 확인 응답 번호 필드가 유효해지며, 수신 측은 해당 번호를 통해 데이터의 수신 여부를 확인한다.
ACK 플래그는 서로 간의 플래그가 오고 가면서 제대로 송수신이 되었는지 확인응답을 위한 목적으로 사용된다.
여기서는 TCP의 재전송 기능을 자세하게 알아보자.
ACK 필드는 수신 측으로부터 정상적으로 데이터가 수신되었음을 나타내는 역할을 한다고 했다.
TCP는 데이터 전송 후 수신 측으로부터 확인 응답(ACK)을 받아야만 데이터 전송이 완료되었다고 간주한다.
만약 일정 시간 동안 수신 측으로부터 ACK를 받지 못하는 경우,
송신 측은 데이터 전송 후 일정 시간 동안 ACK를 기다린다
송신 측은 데이터가 손실되었거나 손상되었을 가능성을 고려하여
(즉, 데이터 전송이 성공적으로 이루어지지 않았다고 판단하고)
해당 데이터를 재전송한다.
타임아웃(TimeOut)
위에서 송신 측은 데이터 전송 후 '일정시간' 동안 ACK를 기다린다고 했다.
이러한 시간을 '타임아웃(TimeOut)'이라고 한다.
예를 들면, 다음과 같은 상황에서 타임아웃이 발생하고 재전송이 발생한다.
#1 데이터 세그먼트가 손실이 된 경우
수신 측이 데이터를 받지 못하고 있을 것이다.
이때, 시간이 초과되고 타임아웃이 발생하여 송신 측은 데이터를 다시 보낸다.
#2 데이터 세그먼트가 손상된 경우
수신 측이 데이터를 체크섬 또는 기타 오류 검출 방법을 사용하여 오류를 감지하면,
송신 측은 수신 측으로부터 정상적인 응답을 받지 못한다.
이렇게, 타임아웃이 발생하면 데이터를 재전송한다.
#3 네트워크 혼잡으로 인해 ACK가 지연되는 경우
네트워크가 혼잡할 경우 ACK가 송신 측에 도달하는 데 시간이 오래 걸릴 수 있다.
이 경우, 송신 측은 일정 시간 동안 ACK를 기다린 후에 재전송을 시도할 수 있다.
이렇게 재전송 기능은 TCP의 신뢰성을 보장하기 위해 중요한 역할을 한다.
위의 예시들을 보았을 때, 결국 타임아웃 안에 ACK를 받지 못한 것이다.
이때, 송신 측은 타임아웃 시간을 적절히 설정할 수 있다.
즉, 네트워크 환경에 따라 동적으로 조정될 수 있다.
왜?
타임아웃 시간이 너무 짧으면, 네트워크 내의 일시적인 지연이나 혼잡으로 인해 패킷이 일시적으로 유실될 수 있고
잘못된 판단으로 재전송을 유발 → 불필요한 재전송 → 네트워크 자원 낭비의 굴레로 떨어진다.
반대로 타임아웃 시간이 지나치게 길면, 패킷 유실 시 재전송까지 기다려야 하는 시간이 늘어날 수 있다.
이는 데이터 전송의 지연을 초래하고 전반적인 통신 성능을 저하시킬 수 있으며,
네트워크 문제를 신속하게 감지하고 대응하는 데 어려움을 겪을 수 있다.
타임아웃 시간이 조정되는 방식
TCP에서 타임아웃 시간은 라운드트립 시간(RTT)과 재전송 타임아웃(RTO)의 개념에 근거하여 동적으로 조정된다.
이 두 가지 요소 또한 TCP에서 신뢰성과 효율성을 높이기 위해 중요한 역할을 한다.
1. 라운드트립 시간(RTT)
RTT는 데이터가 송신 측에서 수신 측까지 이동한 후에,
수신 측에서 응답이 송신 측으로 돌아오는 데 걸리는 전체 시간을 나타낸다.
즉, 패킷의 왕복 시간을 나타낸다.
RTT는 이런 식으로 간단하게 패킷의 송신과 응답에 소요된 시간을 측정하지만,
네트워크 환경의 변동으로 인해 실제 전송 시간은 항상 일정하지 않다.
이러한 변동 요소들은 주로 네트워크의 혼잡도, 패킷 유실률, 네트워크 지연 등이 포함된다.
2. 재전송 타임아웃(RTO)
반면에 RTO는 데이터를 송신한 후에 해당 데이터에 대한 확인 응답(ACK)을 기다리는 시간을 나타낸다.
이는 데이터가 송신 측에서 수신 측으로 전송된 후에,
수신 측에서 응답 패킷이 다시 송신 측에 도달하는 데 걸리는 시간을 말한다.
따라서 RTO는 송신 측에서 데이터를 보낸 후에 응답을 기다리는 지연 시간을 의미한다.
RTT에서의 변동성을 고려하여 RTO는 RTT를 기반으로 하지만
추가적으로 네트워크 환경의 여러 요소
(네트워크 혼잡도, 패킷 유실률, 네트워크 지연, 네트워크 지연 변동성, 대역폭 등)를 고려하여 계산된다.
이렇게 함으로써 송신자는 효율적인 데이터 전송을 보장하는 동시에 안정성을 유지할 수 있다.
어떻게 RTT를 기반으로 계산되는지 간단히 알아보자.
RTO는 RTT가 길어지면 일반적으로 RTO도 증가하여 더 많은 시간을 기다리도록 조정된다.
이는 네트워크 지연이나 혼잡으로 인해 패킷의 전달이 지연될 가능성이 높기 때문이다.
이는 재전송 시간을 늘려서 패킷이 유실되었을 경우를 대비하여 더 많은 시간을 기다릴 수 있도록 한다.
반대로, RTT가 짧아지면 송신자는 패킷이 올바르게 도착했다고 판단하여
더 빠르게 재전송을 시도하기 위해 RTO를 감소시킨다.
TCP는 이렇게 네트워크 환경의 변화에 민첩하게 대응하기 위해 이러한 추가적인 요소들을 고려한다.
이를 통해 TCP는 데이터의 안정적이고 신뢰성 있는 전송을 보장하며,
네트워크 환경의 변화에 능동적으로 대응할 수 있다.
재전송을 위한 타임아웃 기반 방법은 일반적으로 효과적이지만 항상 최선이라고 할 수는 없기 때문에
이외에 다양한 방법도 존재한다.
3. PSH(푸시)
수신 측에 데이터를 즉시 전달하도록 요청한다. 이 플래그가 설정되면 수신 측은 데이터를 즉시 상위 계층으로 전달한다.
"데이터를 즉시 상위 계층으로 전달한다" 무슨 말일까?
전 글에서 OSI 7 계층을 배워보았다. 여기서 우리는 4계층에서 다음 계층으로 전송을 해야 한다면,
중간에 건너뛸 수 없고 4계층 → 5계층 → 6 계층으로으로 가듯이 동작을 하는 게 일반적이라고 알고 있다.
하지만 PSH 플래그를 사용하면 데이터를 계층을 건너뛰고 상위계층에다가 한 번에 보내줄 수 있다는 것이다.
즉, 이런 식으로 데이터를 빠르게 보낼 수 있는 기능을 가지고 있다.
4. RST(재설정)
연결을 재설정하거나 초기화한다.
이 플래그가 설정되면 연결이 중단되고 초기 상태로 돌아간다.
RST 플래그는 연결을 재설정하거나 재시작을 하기 위한 목적으로 사용되는 것인데,
이 플래그는 한 가지 알아두어야 할 것이 있다.
뭔가 정상적으로 다 종료가 돼서 그 이후에 재시작을 하는 형태가 아니라
‘강제’로 종료를 시키고 '강제'로 재시작을 하는 행위이다.
중간에 어떠한 데이터를 보내고 있는 과정이 있든 간에
일단 RST 플래그를 사용하면 '강제'로 재부팅을 담당한다고 알아두자.
그래서 RST 플래그는 나중에 보면 알겠지만 공격자들이 뭔가 중간에 정보를 탈취하거나
세션을 가져오기 위해서 사용되는 플래그로 많이 보이고 있다.
5. SYN(동기화)
우리가 이 다음 단계에서 알아볼 예정인 연결성립단계(3-way handshake)에서
연결을 설정하기 위해 사용되는 플래그이다.
이 SYN 플래그는 평상시엔 동작되지 않고,
서로 간의 연결을 성립하고자 할 때 사용되는 플래그이며, 연결에 대한 동기화 시점에서 사용된다고 알아두자.
6. FIN(종료)
연결 종료를 요청하거나 확인한다.
이 플래그가 설정되면 데이터의 송수신이 완료되었음을 나타내며, 연결을 종료하고 상태를 정리한다.
FIN 플래그는 연결을 종료하고자 할 때 사용하는 것이다.
정상적인 종료를 할 때 사용되는 플래그라고 할 수 있는데,
RST와 FIN의 큰 차이점은 RST는 강제로서 동작들이 일어나는 특징이고
FIN은 정상적으로 종료가 되는 과정이 이루어진다.
이 둘에 대한 비교가 과거 정보보안기사에 나왔다고 한다.
송신자 ⇋ 수신자 간의 연결, 일반적으로 클라이언트 ⇋ 서버 간 네트워크 연결을 설정하기 위한 방식을 알아볼 것이다.
여기서는 3-way handshake라는 방식이 사용되며, 이는 '연결성립단계'라고 보면 된다.
플래그비트 중 SYN, ACK를 사용하여 연결성립이 가능하다.
이때, 바로 연결을 할 수 있는 게 아니라 동기화(SYN) 요청 통해서 요청에 대한 응답(ACK)을 통해 서로 간의 통신을 한다.
3번의 요청/응답 과정에서 여러 가지 요소를 확인하고 수립하여,
양쪽 모두가 상대방과의 통신이 준비되었음을 보장 후 연결된다.
3-way handshake
[Step1] : 클라이언트에서 서버로 연결 요청 (SYN)
클라이언트가 서버에 *SYN 패킷(연결 요청)을 보낸다.
TCP는 데이터를 세그먼트로 나누어 전송한다.
각 세그먼트에는 SYN, ACK, FIN과 같은 플래그 비트가 설정될 수 있고,
이러한 플래그비트가 설정되면 데이터 세그먼트가 아니라, 연결 설정, 응답, 종료를 나타내는 세그먼트가 된다.
즉, *SYN 패킷은 SYN 플래그 비트가 설정되어 연결 설정을 나타내는 TCP 세그먼트를 의미한다.
클라이언트는 서버의 응답을 기다리는 SYN_SENT상태가 된다.
[Step2] 서버에서 클라이언트로 연결 수락 및 확인 응답 (SYN-ACK)
서버는 "어 너가 보낸 SYN 패킷 잘 받았어"라는 의미로
요청을 받았다는 대답(ACK)과 함께 클라이언트에게 서버 연결 요청(SYN)을 요청한다(SYN-ACK).
이렇게 서버는 LISTEN 상태에서 SYN 패킷을 받고 SYN_RECEIVED 상태가 된다.
[Step3] 클라이언트에서 서버로 연결 확인 응답 (ACK)
클라이언트는 SYN-ACK 패킷을 받고 ESTABLISHED 상태로 변경 후, 서버에 ACK 패킷을 보낸다.
자세하게 알아보자.
클라이언트 입장에서는 서버 측에다가 연결을 요청하는 SYN 패킷을 보냈는데,
서버로부터 SYN 패킷을 잘 받았다는 의미인 ACK 패킷을 회신했다.
그럼 클라이언트는 "어, 이제 통신을 해도 될 것 같네? 이제 통신 시작할게"라는 의미로
서버에 ACK 패킷을 보낸다.
그렇게 ACK 패킷을 받은 서버 또한 ESTABLSHED 상태로 변경되고,
클라이언트 ⇋ 서버 간 연결이 확립된다.
나중에 네트워크 분석할 때 정말로 우리가 분석하고자 하는 포인트를 잡는다면
3-way handshake가 일어나는지 여부 먼저 확인하고 그 이후에 진행하는 게 좋다.
그러면 이제 클라이언트와 서버 간 네트워크 연결을 종료하는 과정도 필요할 것이다.
여기서는 4-way handshake라는 방식이 사용되며, 이는 '연결해제단계'라고 보면 된다.
클라이언트와 서버 간 네트워크 연결을 안전하게 종료하기 위해 수행되며,
플래그비트 중 FIN과 ACK를 사용하여 연결 해제가 가능하다.
3-way handshake와는 달리 4단계의 과정이며,
전제조건은 현재 연결이 성립된 상태에서 클라이언트가 종료를 하고 싶은 것이다.
4-way handshake
[Step1] 클라이언트에서 서버로 연결 종료 요청 (FIN)
클라이언트는 더 이상 데이터를 보내지 않겠다는 의미로 ("나 끝났으니까 종료하고 싶어")
FIN(종료) 플래그가 설정된 패킷을 서버로 보낸다.
클라이언트는 ESTABLSHED 상태에서 ACK 또는 FIN을 기다리는 FIN_WAIT_1 상태가 된다.
[Step2] 서버에서 클라이언트로 확인 응답 (ACK)
서버는 클라이언트로부터 받은 FIN 패킷에 대해 ACK(확인 응답) 플래그가 설정된 패킷을 보낸다.
이로써 서버는 클라이언트의 연결 종료 요청을 받았음을 확인한다.
그런데 3-way handshake 방식을 보고 나서는 일반적으로
"어 너가 보낸 FIN 패킷 잘 받았어"라는 의미로 FIN 패킷과 ACK 패킷 두 개의 신호를 동시에 반환하겠지..라고
생각을 할 수 있겠지만 사실상 서버는 FIN을 받았을 때, 일단은 ACK만 먼저 보낸다.
"어 너가 보낸 거 잘 받았는데 잠깐만 기다려"라는 의미로 ACK만 먼저 보내는 것이다.
그 이유는 무엇일까?
클라이언트 입장에서는 더 이상 받을 게 없고 통신을 종료해도 될 것 같다고 판단을 했기 때문에,
FIN이라는 플래그를 보낸 거지만 서버는 아직 연결을 종료하기 위한 준비가 안된 것이다.
그 당시에 통신하고 있는 상황일 수 있고
연결을 종료하기 위해서 일련의 과정이 필요할 수도 있기 때문이다.
서버는 ESTABLSHED 상태에서 상대방의 종료 요청을 받은 CLOSE_WAIT 상태가 된다.
클라이언트는 자신이 보낸 FIN에 대한 ACK를 받았고 상대방의 FIN을 기다리는 FIN_WAIT_2 상태가 된다.
[Step3] 서버에서 클라이언트로 연결 종료 요청 (FIN)
서버는 CLOSE_WAIT 상태에서 자신의 FIN 요청을 보낸 후 FIN에 대한 ACK를 기다리는 LAST_ACK 상태가 된다.
즉, 서버는 더 이상 데이터를 보내지 않겠다는 의미로 FIN 플래그가 설정된 패킷을 클라이언트로 보낸다.
[Step2]에서 서버는 ACK를 보낸 후에 일정시간을 어느 정도 기다렸다가
이 [Step3]에서 서버가 연결을 종료하고자 FIN이라는 플래그가 설정된 패킷을 추가적으로
클라이언트에게 반환한다.
[Step4] 클라이언트에서 서버로 확인 응답 (ACK)
클라이언트는 서버로부터 받은 FIN 패킷에 대해 서버에게 ACK 플래그가 설정된 패킷을 보낸다.
이로써 클라이언트는 서버의 연결 종료 요청을 받았음을 확인하고, 클라이언트는 연결을 해제한다.
클라이언트 입장에서는 "ACK도 잘 받았고 FIN도 잘 받았으니까 이제 종료할게?"라는 의미로 다시 ACK를 보낸 것이고,
ACK패킷을 받은 서버도 연결 해제를 완료하는 것이다.
이를 다시 풀어보면
클라이언트는 상대방의 종료 요청 FIN을 받고 마지막으로 상대방에게 ACK를 보낸다.
클라이언트와 서버는 모두 TIME_WAIT 상태가 되며, 이 상태를 통해 이전에 사용한 연결이 완전히 종료되도록 하여
모든 패킷이 네트워크에서 소멸하도록 한다.
TIME_WAIT 상태가 끝나면 클라이언트와 서버 모두 CLOSED 상태가 되며,
더 이상의 데이터 전송이나 통신을 수행하지 않는다.
이런 식으로 각각의 모든 과정이 플래그비트를 기반으로 동작을 한다는 점과
3-way handshake, 4-way handshake는 너무나도 자주 나오는 내용이라는 점을 잘 알아두자.
그리고 이와 같은 과정을 봤을 때,
TCP는 데이터의 손실을 방지하고, 연결을 깔끔하게 종료함으로써
네트워크의 효율성과 안정성을 유지하는 데 중요한 역할을 함을 다시 알 수 있다.
이제 TCP와 반대되는 개념인 UDP를 알아보자.
앞에서 잠깐 다뤘듯이 UDP는 단순한 구조를 가진다.
UDP
비연결 지향적 프로토콜이다.
비연결 지향적(Connectionless-Oriented)이라는 말은 UDP에서 어떻게 이해하면 될까.
이 말은 즉, 연결 절차를 거치지 않고 송신자가 일방적으로 데이터를 발신한다..라는 의미이다.
중요한 점은 신뢰성이 떨어지고, 빠르게 보내고자 하는 목적이라는 점이다.
이전 글에서 OSI 7 계층 중 전송계층의 전송단위가 UDP에서는 데이터그램(Datagram)이라는 것을 알아두었다.
이는 순서가 보장되지 않고, TCP와는 달리 handshake 과정이 없기에,
데이터그램이 독립적으로(서로 다른 통신선로를 통해) 전달될 수 있다.
TCP와 유사하게 전송할 데이터를 일정한 단위로 나누고
각각의 단위에 'UDP 헤더'를 추가 후
'데이터그램(UDP 데이터그램)' 전송단위가 생성되는 것이고.
그리고 전송계층의 하위계층인 네트워크 계층으로 전달되는 방식이다.
데이터그램 구성 = UDP 헤더 + 데이터(*데이터 페이로드)
UDP는 사실상 통신되는 서비스가 많지 않다.
신뢰성이 없고 빠르게 보내고자 하는 목적으로 사용하기 때문에,
실시간 스트리밍, DNS 등에 사용된다.
UDP 헤더 구조
UDP 헤더는 TCP 헤더와 달리 간단한 형태로 구성되어 있다.
1. 출발지 포트 (Source Port, 16 bits)
전송하는 시스템의 포트 번호를 나타낸다.
이를 통해 수신자는 응답을 보낼 때 어떤 포트로 보내야 하는지 식별 가능하다.
2. 목적지 포트 (Destination Port, 16 bits)
수신 시스템의 포트 번호를 나타낸다.
이를 통해 수신 시스템은 데이터를 수신할 적절한 응용 프로그램이나 서비스로 전달 가능하다.
3. 길이 (Length , 2byte(16 bits))
UDP 헤더와 데이터그램을 포함한 전체 패킷의 길이를 바이트 단위로 나타낸다.
4. 체크섬 (Checksum , 16 bits)
데이터의 오류를 검출하기 위해 사용된다.
이 필드는 선택적으로 사용되며, 이 값이 0인 경우 체크섬이 사용되지 않았음을 의미한다.
TCP 헤더와 동일하게 체크섬이 작동하는데, 무슨 차이가 있을까?
각 프로토콜의 특성과 목적에 따라 차이가 존재한다.
TCP의 체크섬
TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 체크섬을 사용한다.
데이터의 무결성을 보장함과 동시에 데이터가 전송 중에 손실되거나 손상되는 것을 감지한다.
송신 측에서 데이터를 전송하기 전에 체크섬을 계산하여 포함시키고,
수신 측에서는 체크섬을 다시 계산하여 송신 측에서 전송한 값과 비교한다.
이를 통해 데이터의 손실이나 오류를 감지하는 것이다.
UDP의 체크섬
UDP는 신속한 데이터 전송을 지향하는 프로토콜로,
체크섬을 사용하여 데이터의 오류를 검출하는 기능만을 제공한다.
UDP의 체크섬은 데이터의 무결성을 확인하기 위해 사용되며,
데이터그램의 체크섬 값이 0인 경우에는 체크섬이 사용되지 않았음을 나타낸다.
UDP는 데이터의 신속한 전송을 목표로 하기 때문에, 데이터의 손실이나 오류에 대한 보장을 제공하지는 않는다.
즉, 체크섬이라는 동일한 점이 있지만 TCP는 모든 송수신과정에서 오류가 있는지 없는지를 체크를 하지만,
UDP는 그냥 선택적으로 체크섬을 이용한다고 보면 된다.
하고 싶으면 하고 하기 싫으면 하지 않는다. 이런 식으로 차이점이 존재한다.
위와 같이 UDP 헤더는 간단한 구조로 이루어져 있어 데이터의 신속한 전송이 가능하며,
TCP 헤더와는 달리 연결 설정, 확인 응답, 흐름 제어, 오류 복구 등의 기능이 없기 때문에 TCP보다 헤더의 크기가 더 작다.
TCP와는 달리 간단한 형태의 데이터그램을 사용하여 통신하기에 연결 설정-해제에 대한 별도의 단계가 필요 없다.
UDP의 데이터전송 과정
데이터그램 전송
UDP는 연결 설정 단계를 거치지 않고, 데이터그램을 보낼 준비가 되면 간단히 전송한다.
데이터그램에는 출발지 포트와 목적지 포트 정보가 포함되어 있어, 수신 측은 이 정보를 기반으로 데이터를 수신한다.
데이터그램 수신
수신 측은 순서와는 상관없이 개별적으로 전송되었던 데이터그램을 도착하는 순서와 관계없이 독립적으로 처리한다.
위와 같은 전송과정을 볼 때, UDP는 데이터의 순서를 보장하지 않으며,
데이터의 손실이나 오류에 대한 보장도 제공하지 않는다는 것을 다시 알 수 있다.
이렇게 길고 길게 TCP / UDP를 알아보았다.
다음에는 OSI 계층별 장비에 대해 알아보겠다.
'IT_정보보안 > 인프라 & 보안기초' 카테고리의 다른 글
| 6. 계층 별 프로토콜(2) (0) | 2023.11.28 |
|---|---|
| 5. 계층 별 프로토콜 (1) (1) | 2023.11.28 |
| 4. 계층 별 장비 (2) | 2023.11.13 |
| 2. OSI 7 Layer (1) | 2023.11.01 |
| 1. 네트워크 보안 (1) | 2023.10.31 |
