UDP & TCP in Transport Layer
Contents
1️⃣ UDP 프로토콜 (UDP Protocol)
2️⃣ TCP 프로토콜 (TCP Protocol)
3️⃣ TCP 프로토콜의 3단계 핸드셰이크 (3-Way Handshake in TCP Protocol)
4️⃣ TCP 프로토콜 데이터 전송 (Data Transmission)
Summary
💡 UDP 특징 (Characteristics of UDP)
비연결형 신뢰성 없는 서비스 (Connectionless Unreliable Service): UDP는 연결을 설정하지 않고 데이터를 전송하며, 신뢰성 보장을 제공하지 않음.
검사합 (Checksum): 기본적인 오류 검출 기능만 제공. 오류 제어나 흐름 제어, 혼잡 제어는 없음.
💡 TCP 특징 (Characteristics of TCP)
연결 지향 서비스 (Connection-Oriented Service): 프로세스 간 통신을 위한 신뢰성 높은 연결 지향 방식을 제공.
스트림 배달 서비스 (Stream Delivery Service): 데이터를 스트림 형태로 전달하며, 오류 제어와 흐름 제어를 통해 안정성 보장.
💡TCP의 주요 과정 (Main TCP Processes)
연결 설정 (Connection Establishment): 3단계 핸드셰이크(Three-Way Handshake)를 통해 안정적인 통신 채널을 설정.
- SYN → SYN+ACK → ACK 순으로 패킷을 교환.
데이터 전송 (Data Transmission):
피기백 (Piggyback): 데이터와 확인응답(ACK)을 동시에 전송하여 효율을 높임.
플래그 (Flags): PUSH, URGENT 등의 TCP 헤더 필드를 사용해 데이터 처리 요청 및 긴급 데이터를 구분.
연결 해제 (Connection Termination):
3단계 핸드셰이크 또는 4단계 핸드셰이크(절반 닫기)를 통해 연결 종료.
FIN과 ACK 플래그를 사용해 연결 종료를 확인.
4. 추가적인 TCP 특징
최대 세그먼트 크기 (Maximum Segment Size): 연결 설정 시 데이터 크기를 제한해 효율적 전송 보장.
윈도우 확장 인자 (Window Scale Factor): 고속 네트워크 상황에서 데이터 흐름을 원활히 하기 위한 확장 기능.
타임스탬프 옵션 (Timestamp Option): 패킷의 왕복 시간을 측정해 네트워크 성능 향상.
5. 주요 차이점 (Key Differences Between TCP and UDP)
TCP는 연결 설정, 데이터 신뢰성, 흐름 제어를 제공하며 신뢰성이 높음.
UDP는 간단하고 빠르지만 신뢰성을 제공하지 않음.로토콜과 OSI 7계층 (UDP and TCP Protocols
and OSI 7 Layers)
1️⃣ UDP 프로토콜 (UDP Protocol)
💡요약: TCP/IP 프로토콜 (TCP/IP Protocol)과 OSI 7계층 (OSI 7 Layers) 모델을 비교하여 UDP의 위치를 파악해본다. UDP (User Datagram Protocol)는 OSI 모델의 Transport Layer (전송 계층)에 위치해 있으며, TCP와 함께 데이터 전송을 담당하는 프로토콜이다. 이 계층에서는 데이터가 네트워크를 통해 전송되는 방식을 정의한다.
✅ UDP(User Datagram Protocol)는 비연결형 프로토콜 (UDP is a connectionless protocol)이다. 즉, 데이터를 보내기 전에 연결을 설정하지 않으며 빠른 전송이 가능하지만 신뢰성이 보장되지 않는다 (reliability is not guaranteed).
✅ TCP (Transmission Control Protocol)는 연결형 프로토콜로, 데이터를 보내기 전에 연결을 설정하여 데이터의 신뢰성을 보장 (ensures data reliability)한다. 하지만 이 과정에서 UDP보다 전송 속도가 느릴 수 다.
✅OSI 모델에서 Transport Layer는 송신자와 수신자 간의 데이터 전송을 담당하며, TCP와 UDP가 이 역할을 수행 (TCP and UDP perform this role)한다.
1️⃣ UDP 프로토콜 (UDP Protocol)
💡요약: UDP 헤더 (UDP Header)의 간단한 구조이다. UDP (User Datagram Protocol)의 헤더는 단 8바이트로 구성되어 있으며, 최소화된 오버헤드 (minimal overhead)를 가지고 있다. 이는 데이터 전송 속도를 높이기 위해 필수적인 정보만 포함 (includes only essential information to enhance data transmission speed)하도록 설계되었기 때문이다. TCP보다 더 작은 오버헤드를 가진다.
UDP 헤더의 구성 요소
✅Source Port Number (출발 포트 번호): 데이터를 보낸 장치의 포트 번호
✅ Destination Port Number (목적지 포트 번호): 데이터를 받을 장치의 포트 번호
✅ Total Length (전체 길이): 16비트, 헤더와 데이터를 포함한 데이터그램의 전체 길이를 나타낸다.
✅ Checksum (체크섬): 16비트, 데이터 무결성을 확인하기 위한 값이다. 데이터 전송 중 오류가 발생했는지 확인할 수 있게 한다.
UDP프로토콜 #1: 특징 (Characteristics of UDP)
💡요약: UDP는 빠른 데이터 전송 (fast data transmission)을 위해 간단한 구조와 비연결형 방식을 채택했지만, 신뢰성이 낮다 (low reliability)는 단점이 있다.
✅ 비연결형 신뢰성이 낮은 전송 프로토콜 (Connectionless and Low-Reliability Protocol): UDP는 연결을 설정하지 않고 데이터를 전송하여 빠른 속도를 제공한다. 그러나 중간에 데이터가 유실될 가능성이 있으며, 데이터의 도착 여부를 확인하지 않는다.
✅ 메시지 단위의 전송 프로토콜 (Message-Oriented Protocol): 데이터가 메시지 단위 (as a message unit)로 전송되며, 더 작은 단위로 잘리거나 재조합되지 않는다. 만약 데이터가 너무 크다면, 필요한 경우 응용 계층이나 IP 계층에서 자르고 재조합해야 한다.
✅ 비정규적인 송신율 (Unregulated Sending Rate): 네트워크 상태와 상관없이 일정한 속도로 데이터를 전송 (transmits data at a constant rate regardless of network conditions)한다. UDP는 네트워크가 혼잡하거나 안정적인 상태인지 신경 쓰지 않고, 응용 계층의 요구에 따라 데이터 전송을 수행 (performs data transmission as per application layer’s request)하게 된다. 반면에 TCP는 네트워크 상태를 고려하여 송신 속도를 조절 (adjusts the sending rate)을 하여 네트워크 혼잡을 방지하려고 한다는 차이점이 있다.
UDP프로토콜 #2: 서비스와 포트 번호 (Service and Port Numbers of UDP)
💡요약: 16비트 포트 번호는 0부터 65535까지 나뉘며 (divided from 0 to 65535), 잘 알려진 포트 (Well-Known Ports), 등록 포트 (Registered Ports), 동적 포트 (Dynamic Ports)로 구분되어 다양한 서비스에 사용된다.
✅ 포트의 분류
잘 알려진 포트 (Well-Known Ports) (0-1023): 주로 시스템과 서버에서 사용하는 포트이다. 예를 들어, DNS 서비스는 53번 포트를 사용한다.
등록 포트 (Registered Ports) (1024-49151): 일반 애플리케이션에서 사용하는 포트로, 사용자 애플리케이션이 등록하여 사용할 수 있다.
동적 포트 (Dynamic Ports) (49152-65535): 임시 포트로, 클라이언트가 임시로 연결을 설정할 때 사용한다.
✅잘 알려진 포트 예시
53번 포트 (Port 53): DNS (Domain Name Service)로, 도메인 이름을 IP 주소로 변환
69번 포트 (Port 69): TFTP (Trivial File Transfer Protocol)로, 파일 전송에 사용
123번 포트 (Port 123): NTP (Network Time Protocol)로, 네트워크 시간 동기화에 사용된다.
UDP프로토콜 #3: UDP서비스의 특성 (Characteristics of UDP Service)
💡요약: UDP는 비연결형 서비스로, 흐름 제어와 오류 제어, 혼잡 제어 기능이 없어 빠른 전송이 가능하지만, 네트워크가 과부화 되거나 데이터 손실 위험 (risk of data loss)도 있다.
✅ 비연결형 서비스 (Connectionless Service): 각 데이터그램이 독립적으로 전송되며, 연결을 설정하지 않고 전송 (transmits without establishing a connection)되기 때문에 전송 속도가 빠르다.
✅ 흐름 제어 없음 (No Flow Control): UDP는 전송 속도를 조절하는 기능 (does not have a mechanism to control transmission speed)이 없어서 데이터가 네트워크에 과부하를 주거나 손실될 수 있다.
✅ 오류 제어 없음 (No Error Control): UDP는 데이터 무결성을 확인하기 위한 검사합 (checksum for data integrity)을 제공하지만, 오류가 발생했을 때 재전송 기능 (does not provide retransmission function)은 지원하지 않습니다.
✅ 혼잡 제어 없음 (No Congestion Control): 네트워크 혼잡 상태를 고려하지 않으므로, 네트워크 상황에 관계없이 데이터를 전송한다.(transmits data regardless of network congestion).
UDP프로토콜 #4 : 검사합을 위한 Pseudo-header (Pseudo-header for Checksum)
💡요약: UDP는 데이터의 무결성을 검증하기 위해 검사합 (checksum)계산이 사용된다. 이는 데이터 전송 중 오류가 발생했는지 확인하는 역할을 한다. Pseudo-header는 검사합 계산 시 임시로 추가되는 헤더로, UDP가 데이터 전송 중 오류를 감지할 수 있도록 (to detect errors) 돕는 역할을 한다.
32비트 출발지 IP 주소 (32-bit Source IP Address): 데이터가 출발하는 장치의 IP 주소
32비트 목적지 IP 주소 (32-bit Destination IP Address): 데이터가 도착할 장치의 IP 주소
8비트 프로토콜 번호 (8-bit Protocol): 전송되는 데이터가 UDP를 사용하고 있음을 나타낸다.
16비트 UDP 전체 길이 (16-bit UDP Total Length): UDP 헤더와 데이터를 포함한 전체 길이를 나타낸다.
UDP프로토콜 #5 : 캡슐화와 역캡슐화 (Encapsulation and Decapsulation)
💡요약: 캡슐화는 데이터가 송신자에서 수신자로 전송될 때, 각 계층에서 헤더를 추가하여 데이터를 감싸는 과정을 뜻한다. 반대로, 역캡슐화는 수신자에서 데이터가 전달될 때, 각 계층에서 헤더를 제거하여 원래의 데이터 메시지를 복원하는 과정이다. 이 과정은 UDP뿐만 아니라 모든 네트워크 프로토콜에서 데이터를 안전하고 효율적으로 전송 (safely and efficiently transmit data)하기 위해 사용된다.
✅ 캡슐화 과정 (Encapsulation Process)
메시지 (Message): 송신자가 전송하려는 원본 데이터입니다.
UDP 헤더 추가 (Add UDP Header): UDP 계층에서 헤더를 추가하여 데이터의 출발지와 목적지 포트 정보를 포함시킨다.
IP 헤더 추가 (Add IP Header): IP 계층에서 송신자와 수신자의 IP 주소가 포함된 IP 헤더를 추가한다.
프레임 헤더 추가 (Add Frame Header): 최종적으로 네트워크 계층에서 프레임 헤더를 추가하여 데이터 전송을 위한 최종 준비가 완료된다.
✅ 역캡슐화 과정 (Decapsulation Process)
프레임 헤더 제거 (Remove Frame Header): 수신자는 네트워크 계층에서 프레임 헤더를 제거한다.
IP 헤더 제거 (Remove IP Header): IP 계층에서 IP 헤더를 제거하여 다음 계층으로 전달한다.
UDP 헤더 제거 (Remove UDP Header): UDP 계층에서 헤더를 제거하여 원본 메시지를 복원한다.
UDP프로토콜 #6 : 큐잉과 포트 주소 (UDP Queuing and Port Addresses)
💡요약: Daytime 클라이언트 (Daytime client)와 Daytime 서버 (Daytime server) 간의 통신 과정을 살펴본다. UDP 통신에서는 포트 주소가 클라이언트와 서버 간의 데이터를 구분하는 중요한 역할을 한다. 또한 각 포트에는 큐 (queue)가 있어 송신과 수신 메시지를 관리한다.
Daytime 통신 과정
클라이언트의 요청 (Client Request): Daytime 클라이언트는 포트 13을 사용하여 서버에 시간 정보를 요청한다. 이때 클라이언트의 출발 큐 (outgoing queue)에 메시지가 쌓이고, UDP는 이 메시지를 서버로 전송한다.
서버의 수신과 응답 (Server Reception and Response): 서버는 포트 52000으로 메시지를 받아 수신 큐 (incoming queue)에 저장하게 된다. 서버는 시간 정보를 생성하여 출발 큐에 쌓고, 클라이언트의 포트로 응답을 보낸다.
클라이언트의 수신 (Client Reception): 클라이언트는 서버로부터 받은 시간 정보를 수신 큐에 저장하여 확인할 수 있다.
2️⃣ TCP 프로토콜 (TCP Protocol)
💡요약: TCP는 전송 계층 (Transport Layer)에 속하며, 데이터의 신뢰성과 정확성을 보장하는 역할을 한다. 이 계층에서 TCP는 UDP와 함께 데이터의 전송을 관리 (manages data transmission)하며, 데이터가 수신자에게 손실 없이 도달하도록 돕는다.
✅ 연결형 프로토콜 (Connection-Oriented Protocol): TCP는 데이터를 보내기 전에 송신자와 수신자 간에 연결을 설정 (establishes a connection)하여 안정적인 데이터 전송을 보장한다.
✅ 오류 제어와 흐름 제어 (Error Control and Flow Control): TCP는 데이터를 보내고 나서 수신자로부터 확인 응답 (acknowledgment)을 받아 오류를 제어하고, 흐름 제어 (controls the flow)를 통해 데이터 전송 속도를 조절한다.
❓TCP 는 중간에 위치해 있는데 이 말은 역할이 더 크다는 뜻일까❓
그렇다. 전송 계층은 데이터가 송신자에서 수신자에게 안전하게 전달되도록 연결 관리, 오류 제어, 흐름 제어 (connection management, error control, flow control) 등의 기능을 수행하며, 전체 통신의 신뢰성과 안정성을 책임지는 계층 (ensures reliability and stability of the overall communication)이다.
특히, TCP와 같은 연결형 프로토콜 (connection-oriented protocol)은 안정적이고 신뢰성 있는 데이터 전송을 위해 설계되었기 때문에, 네트워크에서 중요한 역할을 한다.
TCP 프로토콜 #1: TCP 의 프로세스-대-프로세스 통신과 포트 주소 (Process-to-Process Communication and Port Addresses in TCP)
💡요약: TCP 프로토콜 (TCP Protocol)에서 사용하는 잘 알려진 포트 주소 (well-known port addresses)를 소개한다. TCP는 전송 계층 (Transport Layer)에 속하며, 애플리케이션 간 통신을 위해 프로세스-대-프로세스 통신 (process-to-process communication)을 수행한다. 이 과정에서 포트 번호 (port numbers)를 사용하여 특정 애플리케이션과의 통신을 구분한다. 예를 들어, HTTP (Hypertext Transfer Protocol)는 포트 80을 사용하여 웹 브라우저와 웹 서버 간의 통신을 처리한다.
잘 알려진 포트의 예시
포트 7: Echo - 송신자가 보낸 데이터를 그대로 돌려주는 서비스
포트 21: FTP (File Transfer Protocol) - 파일을 전송하기 위한 프로토콜
포트 25: SMTP (Simple Mail Transfer Protocol) - 이메일 전송을 위한 프로토콜
포트 53: DNS (Domain Name System) - 도메인 이름을 IP 주소로 변환
포트 80: HTTP (Hypertext Transfer Protocol) - 웹 페이지 전송에 사용
TCP 프로토콜 #2: 스트림 배달 서비스 (Stream Delivery Service in TCP)
💡요약: TCP는 스트림 배달 서비스(Stream of bytes)를 통해 데이터를 연속적인 흐름 (continuous flow)으로 전달하여, 송신 측에서 수신 측까지 끊김 없는 데이터 전송 (uninterrupted data transmission)을 제공한다.
스트림 배달의 특징
연속적인 데이터 흐름 (Continuous Data Flow): TCP는 데이터를 개별 패킷으로 구분하지 않고, 바이트 단위의 연속적인 흐름 (continuous flow of bytes)으로 전달한다.
데이터의 경계 구분 없음 (No Data Boundary Distinction): 데이터의 시작과 끝을 따로 구분하지 않아 송신 측의 데이터가 수신 측으로 끊김 없이 전달 (delivers data without interruption)되게 된다.
❓TCP와 UDP의 큰 차이점
TCP는 연결을 설정하고 신뢰성 있는 데이터 전송을 보장 (establishes connection and ensures reliable data transmission)하는 반면, UDP는 연결 없이 빠르게 데이터 전송을 수행 (transmits data quickly without connection)한다.
TCP 프로토콜 #3 : 흐름제어와 오류제어를 위한 송신/수신 버퍼 (Send/Receive Buffer for Flow Control and Error Control)
💡요약: TCP는 흐름 제어와 오류 제어를 위해 송신 및 수신 버퍼를 사용하여 데이터를 안전하고 효율적으로 전송 (transmit data safely and efficiently)한다. 송신 버퍼는 전송할 데이터를 저장하며, 확인 응답이 없는 경우 재전송 (retransmits if no acknowledgment)한다. 수신 버퍼는 받은 데이터를 순서대로 저장하고 읽기 준비 (ready for reading)한다.
✅ 버퍼의 역할
송신 버퍼 (Send Buffer): 송신 측에서는 데이터를 전송하기 전 버퍼에 저장 (stores data in buffer)한다. 이곳에 저장된 데이터는 네트워크로 전송되고, 전송된 데이터가 확인 응답(ACK)을 받지 못하면 재전송 (retransmits data if acknowledgment is not received)할 준비를 한다.
수신 버퍼 (Receive Buffer): 수신 측에서는 받은 데이터를 수신 버퍼에 저장 (stores received data in buffer)하여 순서에 맞게 처리 (processes data in order)한다. 아직 읽지 않은 데이터는 수신 버퍼에 남아 있으며, 읽힌 데이터는 다음 데이터로 넘어간다.
TCP 프로토콜 #4: 세그먼트 (TCP Segment)
💡요약: TCP는 스트림 배달 (stream delivery)을 제공하지만, 하위 계층인 IP 프로토콜은 패킷 단위로 데이터를 전송 (transmits data in packet form)한다. 따라서 TCP는 연속적인 바이트 흐름을 세그먼트라는 단위로 나누어 (divides into units called segments) 전송하게 된다. 각 세그먼트는 IP 계층에서 전송되기 위해 개별 패킷처럼 처리된다.
✅ 세그먼트의 역할
바이트 스트림의 분할 (Division of Byte Stream): TCP는 송신 측에서 데이터 스트림을 적절한 크기의 세그먼트로 나누어, IP 계층에서 패킷처럼 전송될 수 있도록 준비해준다.
수신 측에서 재조합 (Reassembly at Receiver): 수신 측에서는 받은 세그먼트를 다시 원래의 바이트 스트림으로 재조합하여 애플리케이션에 전달하게 된다.
TCP 프로토콜 #5: 서비스의 주요 특징 (Key Features of TCP Service)
💡요약: TCP는 양방향 통신, 신뢰성, 연결 지향 (two-way communication, reliability, connection-oriented)이라는 세 가지 주요 특징을 통해 데이터가 안전하게 전송되도록 보장한다.
✅ 전이중 통신 서비스 (Full-Duplex Communication Service): TCP는 양방향으로 동시에 데이터 전송이 가능 (allows simultaneous two-way data transmission)하여 송신자와 수신자가 동시에 데이터를 주고받을 수 있게한다.
✅ 신뢰성 서비스 (Reliable Service): TCP는 확인 응답 메커니즘 (acknowledgment mechanism)을 사용하여 데이터가 정확하게 수신되었는지 확인한다. 만약 데이터가 손실되거나 오류가 발생하면 재전송하여 오류 없는 데이터 전송 (error-free data transmission)을 보장한다.
✅연결 지향 서비스 (Connection-Oriented Service): TCP는 데이터를 전송하기 전에 가상 연결을 설정 (establishes a virtual connection)하여 송신자와 수신자 간에 연결을 맺는다. 데이터 전송이 완료되면 이 연결을 종료하여 효율적으로 통신을 관리한다.
TCP 프로토콜 #6: 번호화 시스템 (TCP Numbering System)
💡요약: TCP의 번호화 시스템은 각 바이트에 순서번호를 부여 (assigns sequence numbers to each byte)하여 수신 측이 정확한 순서로 데이터를 재조립 (reassemble data in the correct order)할 수 있도록 하는 역할을 한다. 확인응답번호는 수신된 데이터의 상태를 송신자에게 알려주어 오류 없는 데이터 전송 (error-free data transmission)을 보장한다.
✅번호화 시스템의 구성 요소: 실제 IP패킷으로 전송되는 세그먼트 단위의 순서 번호는 없으며, 모든 데이터 바이트에 순서번호를 부여한다.
송신 순서번호 (Sending Sequence Number): TCP 헤더에 있는 순서번호 필드는 현재 세그먼트에 있는 첫 번째 바이트의 순서번호 (sequence number of the first byte in the current segment)를 나타낸다. 이 번호는 데이터 흐름을 추적하는 데 사용된다.
확인응답번호 (Acknowledgment Number): TCP 헤더에 있는 확인응답번호는 수신 측에서 다음에 기대하는 바이트의 순서번호 (sequence number of the next byte expected by the receiver)를 나타낸다. 이 번호보다 작은 순서번호의 데이터는 정상적으로 수신 (indicates that all data with lower sequence numbers were received correctly)되었음을 의미한다.
TCP 프로토콜 #7: 세그먼트 형식 (TCP Segment Format)
💡요약: TCP 세그먼트의 구조 (structure of a TCP segment)를 자세히 살펴본다. TCP가 데이터를 전송할 때 사용하는 다양한 필드 또한 설명한다. TCP 세그먼트는 헤더 (header)와 데이터 (data)로 구성되어 있으며, 헤더에는 데이터 전송을 관리하는 데 필요한 여러 정보가 포함된다.
TCP 세그먼트 헤더의 주요 필드
✅ 출발지 및 목적지 포트 주소 (Source and Destination Port Address) - 각 16비트: 송신자와 수신자의 포트 번호 (port numbers)를 지정하여 통신하는 애플리케이션을 구분한다.
✅ 순서번호 (Sequence Number) - 32비트: 세그먼트의 첫 번째 바이트의 순서번호 (sequence number of the first byte in the segment)를 지정하여 데이터의 순서를 추적한다.
✅ 확인응답번호 (Acknowledgment Number) - 32비트: 수신 측에서 다음에 기대하는 바이트의 순서번호 (sequence number of the next expected byte)를 나타내며, 송신자가 데이터가 정상적으로 도착했는지 확인하는 데 사용된다.
✅ 헤더 길이 (Header Length) - 4비트: TCP 헤더의 길이를 나타내며, 데이터 시작 위치를 알 수 있게 한다.
✅ 제어 필드 (Control Field): SYN, ACK, FIN 등 다양한 제어 비트가 있으며, 이들은 연결 설정 및 종료 (establishing and terminating connections)와 같은 TCP 동작을 제어한다.
✅ 윈도우 크기 (Window Size) - 16비트: 수신 측에서 한 번에 받을 수 있는 데이터의 최대 크기 (maximum amount of data the receiver can accept)를 지정하여 흐름 제어에 사용된다.
✅ 검사합 (Checksum) - 16비트: 데이터의 무결성을 확인하여 오류가 발생했는지 검증 (verifies if errors occurred during transmission)하는 역할을 한다.
✅ 긴급포인터 (Urgent Pointer): 이 필드는 긴급한 데이터를 먼저 처리해야 할 때 사용된다. 일반적인 데이터 흐름과는 별도로 긴급한 데이터가 있음을 수신자에게 알려주는 신호 (a signal to the receiver that urgent data is present)를 제공한다.
✅옵션과 패딩 (Options and Padding): TCP가 추가적인 정보를 포함해야 할 때 사용하는 필드로, 길이가 일정하지 않기 때문에 패딩을 추가하여 헤더의 크기를 맞춘다. 최대 40 바이트 까지의 추가적인 정보를 전달할 수 있다.
💡Urgent Pointer는 TCP에 포함된 기능이지만, 현대의 네트워킹 환경에서는 거의 사용되지 않는다. (rarely used in modern networking environments). 대신, 많은 애플리케이션이 자체적인 긴급 데이터 전송 방식을 채택 (use their own methods for urgent data transmission)하여 더 높은 유연성과 일관성을 유지한다.
TCP 프로토콜 #8: 제어 필드 (Control Field in TCP Segment)
💡요약: TCP 세그먼트의 제어 필드는 6개의 주요 비트 (6 key bits)를 통해 연결의 시작, 유지, 종료 등의 과정을 제어한다. 각 비트는 특정한 기능을 담당 (performs specific functions)하여 TCP 연결의 안정성과 효율성을 높이는 데 기여한다.
제어 비트의 기능
✅ URG (긴급 포인터가 유효함) - 긴급 데이터를 나타낸다 (indicates urgent data). URG 비트가 1로 설정되면, Urgent Pointer가 활성화되어 긴급 데이터를 우선 처리 (prioritizes urgent data)하게 된다.
✅ ACK (확인 응답이 유효함) - 확인 응답 번호가 유효함을 나타낸다. (indicates acknowledgment number is valid). ACK 비트가 설정되면 수신 측에서 다음에 기대하는 데이터의 순서번호를 송신자에게 알려준다.
✅ PSH (즉시 전달 요청) - 데이터를 즉시 전달하도록 요청 (requests immediate delivery of data)한다. PSH 비트가 1이면, 송신자는 데이터를 즉시 수신 애플리케이션에 전달하도록 요청할 수 있다.
✅ RST (연결 리셋) - 연결을 재설정 (resets the connection)하는 데 사용된다. 연결에 문제가 발생하면 RST 비트가 설정되어, 현재 연결을 중단하고 새로 시작할 수 있게 된다.
✅ SYN (순서번호 동기화) - 연결 설정 시 초기 순서번호를 동기화 (synchronizes sequence numbers during connection setup)한다. TCP 연결을 설정할 때 첫 번째 세그먼트에서 사용된다.
✅ FIN (연결 종료) - 연결을 종료 (terminates the connection)할 때 사용된다. FIN 비트가 설정되면 더 이상 보낼 데이터가 없음을 나타내고, 연결을 종료하게 된다.
TCP 프로토콜 #9: 캡슐화 과정 (TCP Segment Encapsulation Process)
💡요약: TCP 통신에서는 UDP프로토콜과 마찬가지로 캡슐화, 역캡슐화 과정이 진행된다. 이러한 캡슐화와 역캡슐화 과정을 통해 데이터를 안전하게 전달한다. 캡슐화(Capsulation)는 데이터를 각 계층에서 헤더로 감싸 전송하는 과정이며, 수신 측에서는 역캡슐화(Decapsulation)로 원본 데이터를 복원 한다.
캡슐화 단계
✅ 애플리케이션 계층 데이터 (Application-layer Data): 애플리케이션에서 생성된 데이터를 전송하기 위한 원본 데이터이다.
✅ TCP 헤더 추가 (Add TCP Header): 전송 계층에서 TCP 헤더가 추가된다. 이 헤더는 순서번호, 확인응답 번호 (sequence and acknowledgment numbers) 등의 정보를 포함하여 데이터가 안전하게 전송되도록 한다.
✅ IP 헤더 추가 (Add IP Header): 네트워크 계층에서 IP 헤더가 추가된다. IP 헤더에는 송신자와 수신자의 IP 주소 (source and destination IP addresses) 등이 포함되어 데이터가 올바른 경로로 전달되게 된다.
✅ 프레임 헤더 추가 (Add Frame Header): 데이터 링크 계층에서 프레임 헤더가 추가된다. 이 헤더는 물리적 전송을 위한 정보 (information for physical transmission)를 포함하여 데이터를 네트워크로 전달한다.
TCP 프로토콜 # 10: 옵션 필드 (TCP Options Field)
💡요약: TCP 옵션 필드는 최대 40바이트의 추가 정보를 전달 (transmits up to 40 bytes of additional information)할 수 있는 공간이다. 이 옵션 필드는 싱글 바이트 옵션 (single-byte options)과 멀티 바이트 옵션 (multiple-byte options)으로 나뉘며, 각각 TCP 연결의 성능과 유연성을 높이는 역할을 한다.
TCP 옵션 필드의 주요 구성
✅ 싱글 바이트 옵션 (Single-byte Options)
End of option list: 옵션 목록의 끝을 표시한다.
No operation: 아무 작업도 수행하지 않는 옵션으로, 옵션 필드의 정렬 (used for alignment) 용도로 사용된다.
✅ 멀티 바이트 옵션 (Multiple-byte Options)
Maximum segment size: 세그먼트의 최대 크기를 설정하여 데이터 크기를 제한 (limits the size of data)한다.
Window scale factor: 윈도우 크기를 확장 (extends the window size)하여 더 많은 데이터를 처리할 수 있도록 한다.
Timestamp: 전송 시간 정보를 포함 (includes transmission time information)하여 지연을 측정할 수 있도록 돕는다.
SACK-permitted: 선택적 확인 응답(SACK)을 허용 (allows Selective Acknowledgment)함으로써, 일부 데이터만 재전송할 수 있게 한다.
SACK: 수신자가 손실된 특정 데이터만 요청 (requests retransmission of specific lost data)하도록 하는 역할을 한다.
TCP 프로토콜 # 11 : 최대 세그먼트 크기 (MSS: Maximum Segment Size)
💡요약: MSS는 하나의 TCP 세그먼트의 수신할 수 있는 데이터 크기를 제한하여 안정적인 데이터 전송을 보장 (ensures stable data transmission)한다. 송신자와 수신자가 협상하여 결정된다. 기본값은 536바이트이며, 연결이 유지되는 동안 변경되지 않는다.
✅데이터 최대 크기 설정 (Sets Maximum Data Size): MSS는 하나의 세그먼트로 수신할 수 있는 데이터의 최대 크기를 정하여, 전송할 때 세그먼트가 너무 크지 않도록 제한한다.
✅기본값 (Default Value): 만약 MSS 값이 설정되지 않으면 기본값으로 536바이트 (536 bytes)로 설정된다.
✅연결 설정 시 결정 (Determined at Connection Setup): MSS 값은 연결 설정 시 송신자와 수신자 간의 협상에 의해 결정되며, 연결이 유지되는 동안에는 변경되지 않는다 (does not change while the connection is active).
💡중요포인트: 수신 측에서 받을 수 있는 데이터 크기를 제한하여 효율적인 데이터 전송을 돕는다.
✅최대 세그먼트 크기 옵션 (Maximum Segment Size Option)
Kind: 2로 설정된 1바이트 필드와 Length: 4로 설정된 1바이트 필드로 구성되며, 뒤에 2바이트의 MSS 값이 있다.
MSS 옵션은 수신 측에서 수신할 수 있는 세그먼트의 최대 크기 (maximum segment size that can be received by the receiver)를 정의하여, 송신 측에서 너무 큰 세그먼트를 보내지 않도록 한다.
TCP 프로토콜 # 12 : 윈도우 확장 인자 (Window Scale Factor)
💡요약: 윈도우 확장 인자는 TCP 연결에서 수신 윈도우 크기를 확장하여 고속 네트워크에서 더 많은 데이터를 처리 (expands the receive window size to handle more data in high-speed networks)할 수 있게 한다. 기본 윈도우 크기가 충분하지 않을 때 유용하며, 연결 설정 시 유지되는 동안에는 변경할 수 없다.
윈도우 확장 인자의 주요 특징
✅ 고속 네트워크 (high-speed networks)에서 데이터를 빠르게 전송해야 할 때 유용하다. 기본 헤더의 수신 윈도우 크기는 최대 65,535 바이트 (maximum of 65,535 bytes)로 제한되는데, 고속 네트워크에서는 이 크기가 부족할 수 있다 (may be insufficient).
✅ 연결 설정 시 결정 (Determined During Connection Setup): 윈도우 확장 인자는 TCP 연결이 설정될 때 한 번만 결정된다. 연결이 유지되는 동안에는 변경할 수 없다. (cannot be changed while the connection is active).
✅ 확장된 윈도우 크기 계산 (Calculation of Expanded Window Size): 새로운 수신 윈도우 크기는 기본 수신 윈도우 크기 (base receive window size)와 2의 확장 인자 제곱 (2 raised to the power of the window scale factor)을 곱한 값으로 계산된다.
💡중요포인트: 큰 데이터 처리가 필요한 상황에서 윈도우 크기를 확장해 네트워크 성능을 높인다.
✅윈도우 확장 인자 옵션 (Window Scale Factor Option)
Kind: 3로 설정된 1바이트 필드와 Length: 3로 설정된 1바이트 필드, 그리고 1바이트의 스케일 인자 (scale factor)로 구성된다.
윈도우 확장 인자는 기본 윈도우 크기를 확장하여 더 큰 데이터 전송을 지원 (supports larger data transmissions)할 수 있도록 한다. 고속 네트워크에서 큰 데이터 처리에 유용하다.
TCP 프로토콜 # 13: 타임스탬프 (TCP Option: Timestamp)
💡요약: TCP의 타임스탬프 옵션은 패킷이 송신자에서 수신자까지 왕복하는 시간 (measures the round trip time for packets)을 측정하여 네트워크 지연을 파악하고 성능을 최적화하는 데 사용된다.
✅타임스탬프 옵션 필드 구성
Kind: 값이 8로 설정된 1바이트 필드로, 타임스탬프 옵션임을 나타낸다.
Length: 값이 10으로 설정된 1바이트 필드로, 타임스탬프 옵션의 총 길이를 의미한다.
Timestamp Value: 송신자가 현재 시간을 나타내는 값을 넣는 필드로, 이 값을 통해 전송 시점을 기록한다.
Timestamp Echo Reply: 수신자가 받은 타임스탬프 값을 그대로 반송하는 필드로, 이를 통해 송신자는 왕복 시간(RTT)을 계산할 수 있다.
TCP 프로토콜 # 14: SACK-허용 및 SACK 옵션 (TCP Options: SACK-Permitted and SACK Option)
💡요약: SACK-허용 옵션과 SACK 옵션은 TCP에서 더 효율적인 데이터 전송을 가능하게 하는 기능 (enable more efficient data transmission)을 제공한다. SACK은 네트워크에서 손실된 데이터를 선택적으로 재전송 (selectively retransmits lost data)하여 성능을 개선한다.
SACK 옵션의 주요 특징
✅ TCP의 기본적인 누적 확인 응답 방식 (cumulative acknowledgment method)을 보완하기 위해 사용된다. TCP의 기본 확인 응답 방식에서는 수신자가 마지막으로 제대로 받은 세그먼트까지만 확인 응답 (acknowledges only up to the last correctly received segment)을 보내기 때문에, 그 이후에 손실된 세그먼트가 있으면 N-프레임 후퇴 문제 (N-frame back problem)가 발생할 수 있다. 이를 해결하기 위해 선택적 확인 응답(SACK) (Selective Acknowledgment)을 사용하여, 어떤 세그먼트가 제대로 도착했는지를 세부적으로 알릴 수 있게 된다.
✅ SACK-허용(SACK-Permitted): TCP 연결을 설정할 때 SACK을 사용할 수 있도록 허용하는 옵션이다. 송신자와 수신자가 모두 이 옵션을 지원해야 SACK을 사용할 수 있다.
✅ 선택적 확인 응답(SACK): 선택적 확인 응답 방식은 특정 세그먼트만 확인 응답 (acknowledges only specific segments)함으로써, 어떤 세그먼트가 손실되었는지 정확히 알 수 있게 한다. 이 방식은 네트워크의 비효율적인 재전송을 줄이고 전송 속도를 높이는 데 도움을 준다.
TCP 프로토콜 # 15: SACK 옵션 (SACK Option in TCP)
💡요약: SACK 옵션 (Selective Acknowledgment option)에 대해 설명한다. SACK 옵션은 TCP 통신에서 누락된 데이터를 효율적으로 처리하기 위해 (used to handle missing data efficiently) 사용된다. 이 옵션은 특정 데이터 블록이 성공적으로 도착했는지 확인하며, 네트워크에서 데이터 손실을 관리하고 재전송을 줄이기 위해 (manages data loss and reduces retransmissions) 매우 유용하다.
SACK 옵션의 주요 구성 요소
✅ SACK-허용 옵션 (SACK-Permitted Option): Kind 값이 4로 설정된 필드로, SACK을 사용할 수 있도록 허용한다. 이 옵션이 설정되어 있어야 SACK 기능이 활성화된다.
✅ SACK 옵션 블록 (SACK Option Blocks): Kind 값이 5로 설정된 필드로, 각 블록에는 성공적으로 도착한 데이터의 왼쪽과 오른쪽 경계 (left and right edges)가 포함되어 있다. 각 블록은 특정 범위의 데이터가 잘 수신되었음을 나타내며 (indicates a specific range of successfully received data), 여러 블록을 사용하여 복수의 데이터 범위를 표시할 수 있다.
Left edge of 1st Block: 첫 번째 블록의 시작 위치를 나타낸다.
Right edge of 1st Block: 첫 번째 블록의 끝 위치를 나타낸다.
Left edge of nth Block: n번째 블록의 시작 위치를 나타낸다.
Right edge of nth Block: n번째 블록의 끝 위치를 나타낸다.
3️⃣3단계 핸드셰이크 (3-Way Handshake)
💡요약: TCP에서 3단계 핸드셰이크(3-way handshake) 과정을 통해 전이중 통신 채널 (full-duplex communication channel)을 설정하는 방법을 설명한다. 이 과정은 클라이언트와 서버가 서로 통신 준비가 되었음을 확인 (ensures that both client and server are ready for communication)하고 안전하게 연결을 시작하기 위해 사용된다. 3단계라는 의미는 총 3번의 메시지 교환이 이루어진다는 뜻 (indicates that 3 messages are exchanged)이다.
3단계 핸드셰이크 과정
✅ 능동개방(SYN) (Active Open - SYN): 클라이언트가 서버에 연결을 요청 (client requests a connection with the server)합니다. 이를 위해 클라이언트는 TCP 연결 요청 메시지인 SYN 패킷을 서버로 보낸다.
✅ 수동개방(SYN-ACK) (Passive Open - SYN-ACK): 서버는 클라이언트의 요청을 수락하고 연결 준비가 되었음을 알림 (server acknowledges the client’s request and indicates readiness). 서버는 클라이언트의 SYN 요청에 응답하기 위해 SYN-ACK 패킷을 클라이언트에게 보낸다.
✅ 확인 응답(ACK) (Acknowledgment - ACK): 클라이언트가 서버의 응답을 확인하고 연결이 시작됨 (client acknowledges server's response, and the connection begins). 클라이언트는 최종적으로 ACK 패킷을 서버로 보내, 연결이 완료되었음을 알린다.
3단계 핸드셰이크 절차 (TCP Connection Setup: 3-Way Handshake Procedure)
💡요약: TCP의 3단계 핸드셰이크 절차는 안정적이고 신뢰할 수 있는 연결을 보장 (ensures a stable and reliable connection)하기 위해 클라이언트와 서버가 3번의 메시지를 주고받는 과정이다. 이를 통해 양쪽 모두 연결 준비가 되었음을 확인하고, 안전한 데이터 통신을 시작할 수 있게 된다.
✅ 3단계 핸드셰이크 절차
클라이언트가 SYN 세그먼트를 서버로 전송 (Client Sends SYN Segment to Server):
- 클라이언트는 임의의 초기 순서번호 (initial sequence number)를 지정하여 서버에 전송다. 이때 전송되는 데이터는 없지만, 순서 번호 하나를 소모 (consumes one sequence number)하게 된다.
서버가 SYN+ACK 세그먼트를 클라이언트로 전송 (Server Sends SYN+ACK Segment to Client):
서버는 송신 측에서 사용할 초기 순서번호 (initial sequence number)를 지정하여 전송한다.
또한, 수신하기를 기대하는 다음 순서 번호를 담아서 ACK 하는것으로 이전의 SYN패킷에 대해서 확인 응답 서버의 수신윈도우 크기인 rwnd값을 포함하여 전송한다.
클라이언트가 서버로 ACK 응답을 전송 (Client Sends ACK Response to Server):
클라이언트는 서버가 보낸 SYN+ACK 메시지를 확인한 후, 이에 대한 확인 응답(ACK)을 보낸다.
클라이언트는 자신의 수신 윈도우 크기(rwnd 값)을 포함하여 서버에게 전송한다. 이는 서버가 얼마나 많은 데이터를 보낼 수 있는지 (informs server of the amount of data it can send) 결정하는 기준이 된다.
이 ACK는 연결 확인만을 위해 사용되며, 데이터를 포함하지 않으면 순서번호를 소모하지 않는다. (does not consume sequence number if it contains no data).
3단계 핸드셰이크 절차의 시각적 표현 (Visual Representation of the 3-Way Handshake Process)
💡요약: 3단계 핸드셰이크 (3-way handshake) 절차를 시각적으로 살펴본다. TCP 연결 설정에서 클라이언트와 서버가 서로 신호를 주고받는 방식 (how client and server exchange signals to establish a connection)을 설명한다.
✅3단계 핸드셰이크 과정
클라이언트의 SYN 전송 (Client sends SYN):
- 클라이언트는 연결을 시작하기 위해 서버에게 SYN 플래그 (SYN flag)를 설정한 패킷을 보낸다. 이 패킷은 초기 순서 번호(Seq: 8000)를 포함하고 있으며, 이는 클라이언트가 전송할 데이터의 순서를 나타낸다.
서버의 SYN+ACK 응답 (Server sends SYN+ACK response):
- 서버는 클라이언트의 요청을 확인한 후, SYN 플래그와 ACK 플래그 (SYN and ACK flags)가 설정된 응답 패킷을 보낸다. 이 패킷에는 서버의 초기 순서 번호(Seq: 15000)와 클라이언트의 SYN에 대한 확인 응답이 포함되어 있다. 또한, 수신 윈도우 크기(rwnd: 5000)가 포함되어 있다.
클라이언트의 최종 ACK 전송 (Client sends final ACK):
- 클라이언트는 서버의 응답을 확인하고, 마지막으로 ACK 플래그가 설정된 패킷을 서버로 전송하여 연결이 완료 (connection is established)되었음을 알린다. 이 패킷에는 클라이언트의 새로운 순서 번호와 수신 윈도우 크기(rwnd: 10000)가 포함되어 있다.
❓초기 순서번호가 0이나 1이 아니라 8000인 이유는 ❓
초기 순서 번호(Initial Sequence Number)가 0이 아닌 이유는 보안과 연결 안정성을 위해서이다. 초기 순서 번호가 항상 0이면 악의적인 사용자가 연결을 쉽게 예측할 수 있게 된다. 예측 가능한 순서 번호는 스푸핑 공격(spoofing attacks)과 같은 공격에 취약해질 수 있다. 랜덤한 초기 순서 번호를 사용하면 외부에서 예측하기 어려워져 보안성이 높아진다. 또한 같은 IP 주소와 포트로 재연결할 때, 이전 연결의 패킷과 현재 연결의 패킷이 구분되지 않을 수 있다. 랜덤한 초기 순서 번호를 사용하면 과거의 연결과 현재 연결을 명확하게 구분할 수 있어 중복 패킷이나 연결 혼선이 방지된다. TCP 표준(RFC 793)에서는 각 연결에서 초기 순서 번호를 임의로 선택하는 것을 권장하고 있다. 이 방법을 통해 연결마다 고유한 순서 번호가 사용되도록 하여 연결의 무결성을 유지하도록 설계되었다.
4️⃣ 데이터 전송 (Data Transmission)
💡요약: TCP의 데이터 전송은 양방향으로 동시에 이루어지며, 확인 응답을 데이터와 함께 전송 (acknowledgment is sent along with data)하여 효율성을 높인다. 푸쉬 플래그와 긴급 플래그는 각 상황에 맞는 특별한 데이터 전송 요구를 지원한다.
전이중 데이터 전송과 플래그 사용 (Data Transmission: Full-Duplex and Flags Usage)
💡요약: TCP는 양방향으로 동시에 데이터를 주고받을 수 있는 전이중 통신(Full-duplex communication)을 지원한다. 또한, 데이터 전송 시 확인 응답을 동시에 전송(send acknowledgment along with data)하는 방식인 피기백(Piggyback) 방식을 사용하여 효율성을 높인다.
데이터 전송 과정에서 사용되는 주요 플래그
✅푸쉬(PSH) 플래그 (Push Flag):
- 푸쉬 플래그가 설정되면 TCP는 데이터를 즉시 수신 응용 프로그램으로 전달 (immediately delivers data to the receiving application)한다. 이는 데이터를 버퍼에 대기시키지 않고 바로 전달하는 것을 의미한다. 예를 들어, 채팅과 같은 즉각적인 데이터 처리가 필요한 상황에서 유용하다.
✅ 긴급(URG) 플래그 & 긴급 포인터 (Urgent Flag & Urgent Pointer):
- 긴급 플래그와 긴급 포인터는 특정한 데이터를 특별히 빠르게 처리 (process data urgently)해야 할 때 사용된다. 예를 들어, 알림 메시지나 중요한 시스템 신호가 있을 때 사용되며, 수신 프로그램은 이 데이터를 우선적으로 처리하게 된다.
데이터 전송 1# : 연결 설정과 데이터 전송 (Connection Establishment and Data Transfer in Data Transmission)
💡요약: 연결 설정(connection establishment), 데이터 전송(data transfer), 그리고 연결 종료(connection termination) 단계가 포함된 TCP의 데이터 전송 과정을 그림으로 확인한다.
✅중요포인트✅
연결 설정 단계에서 클라이언트와 서버가 통신을 시작
데이터 전송 단계에서 클라이언트는 순서 번호를 통해 서버와 데이터를 주고받는다.
서버는 다음 순서 번호로 응답(ACK)하여 데이터가 성공적으로 전송되었음을 확인한다.
✅ 연결 설정 (Connection Establishment):
- 클라이언트와 서버 간의 연결이 설정된다. 연결이 성공적으로 설정되면 데이터 전송이 시작되게 된다.
✅ 데이터 전송 (Data Transfer):
클라이언트는 순서번호(Seq) 8001에서 시작하여 9000번 바이트까지 데이터를 서버로 전송한다.
서버는 이 데이터를 수신하고, 다음 데이터의 시작 순서 번호인 9001로 응답한다.
클라이언트는 이후 9001부터 10000번 바이트까지 데이터를 다시 전송한다.
전송이 성공적으로 이루어지면 서버는 10001번 순서번호의 ACK를 전송하여 수신 확인을 한다.
✅ 연결 종료 (Connection Termination):
- 모든 데이터가 전송된 후 클라이언트와 서버는 연결을 종료한다.
데이터 전송 2# : 연결해제 (TCP Connection Termination in Data Transmission)
💡요약: TCP 연결은 클라이언트나 서버 어느 쪽에서도 종료 (either client or server can initiate the termination)할 수 있으며, 연결 해제의 안정성을 보장하기 위 3단계 핸드셰이크 또는 4단계 핸드셰이크(3-way or 4-way handshake)를 사용하게 된다. 또한 절반-닫기 옵션을 통해 한쪽만 먼저 종료할 수도 있어 유연한 데이터 전송을 지원합니다.
✅절반-닫기(Half-Close):
한쪽에서 먼저 연결을 해제하는 방식으로, 한쪽이 연결을 닫더라도 상대방이 여전히 데이터를 전송할 수 있는 상태 (one side can still send data while the other side
closes)로 유지할 수 있게 된다.
✅ 3단계 또는 4단계 해제 (3-way or 4-way termination):
3단계 해제는 특정 조건에서 사용되며, 빠르게 연결을 해제할 때 유용하다.
4단계 해제는 각 측에서 연결 해제를 확인하는 두 가지 옵션 단계 (two-step options in 4-way handshake)로, 더 완전한 연결 종료 과정을 거치게 된다.
데이터 전송 3# : 3단계 핸드셰이크 연결해제 (TCP Connection Termination: 3-Way Handshake Procedure)
💡요약: TCP 연결을 안전하고 순서에 맞게 종료 (safely and orderly termination)하는 3단계 핸드셰이크 방법을 설명한다. FIN과 ACK 플래그를 사용하여 양쪽에서 연결이 성공적으로 종료되었음을 확인한다.
✅중요 포인트
클라이언트가 FIN 세그먼트로 연결 해제를 요청한다.
서버가 FIN+ACK 세그먼트로 응답하여 연결 해제를 준비한다.
클라이언트가 최종 ACK를 전송하여 연결 해제가 완료되게 된다.
✅ 3단계 절차
클라이언트의 FIN 세그먼트 전송 (Client sends FIN segment):
- 클라이언트가 연결을 종료하려고 할 때, FIN 세그먼트를 서버에게 전송한다. 이 FIN 세그먼트는 순서 번호를 하나 소모(consumes a sequence number)하며, 데이터가 포함될 수도 있다.
서버의 FIN+ACK 세그먼트 전송 (Server sends FIN+ACK segment):
- 서버는 클라이언트의 FIN 세그먼트를 수신하고, FIN+ACK 세그먼트로 응답한다. 이 세그먼트는 클라이언트의 FIN에 대한 확인 응답(ACK)과 함께 서버가 연결을 종료할 준비가 되었음을 알리는 FIN을 포함하게 된다.
클라이언트의 최종 ACK 세그먼트 전송 (Client sends final ACK segment):
- 클라이언트는 서버의 FIN 세그먼트를 확인한 후, ACK 세그먼트를 서버로 전송하여 연결 종료를 확인한다. 이로써 연결이 완전히 종료되게 된다.
데이터 전송 4# : 3단계 핸드셰이크 연결해제 (TCP Connection Termination: 3-Way Handshake Procedure)
💡요약: 3단계 핸드셰이크 (3-way handshake)를 사용하여 TCP 연결을 안전하게 종료하는 과정 (safely terminating a TCP connection)을 그림으로 확인해본다. TCP 연결 종료는 클라이언트와 서버 간의 FIN과 ACK 플래그 (FIN and ACK flags)를 주고받으며 이루어진다.
💡중요포인트
FIN 플래그는 연결 종료 요청을 의미한다.
ACK 플래그는 상대방의 종료 요청을 수락했음을 나타낸다.
3단계 과정으로 클라이언트와 서버 간 연결이 안전하게 종료된다.
✅ 클라이언트의 FIN 전송 (Client sends FIN):
- 클라이언트는 먼저 FIN 플래그를 설정하여 서버에 연결을 종료하겠다는 의사를 전달한다. 이를 액티브 클로즈 (active close)라고 부르며, 클라이언트가 연결 종료를 시작하게 된다.
✅ 서버의 FIN+ACK 전송 (Server sends FIN+ACK):
- 서버는 클라이언트의 FIN 요청을 받고, ACK 플래그와 FIN 플래그가 설정된 세그먼트로 응답한다. 이 과정에서 서버도 연결 종료를 준비하며, 이를 패시브 클로즈 (passive close)라고 부른다.
✅ 클라이언트의 최종 ACK 전송 (Client sends final ACK):
- 클라이언트는 서버의 FIN 요청을 확인하고, 마지막 ACK를 서버로 보내며 연결 종료를 완료하게 된다.
데이터 전송 5# : 절반 닫기와 리셋플래그 연결해제 (TCP Connection Termination: Half-Close and Reset Flag)
💡요약: 절반-닫기는 한쪽에서만 연결을 해제하고 다른 방향으로의 통신은 유지할 수 있는 방법이며, 리셋 플래그는 비정상적인 상황에서 연결을 즉시 종료할 때 사용된다.
💡중요포인트
절반-닫기는 한쪽에서만 연결을 해제하고 다른 방향으로의 통신을 유지(maintains communication in the other direction)할 수 있게 한다.
리셋 플래그는 비정상적인 상황에서 즉시 연결을 종료(immediately terminate the connection)하는 데 사용된다.
✅절반-닫기(Half-Close)
한쪽 방향에서만 TCP 연결을 해제하고, 다른 방향으로는 필요한 만큼 통신을 계속할 수 있다.
예를 들어, 클라이언트가 더 이상 데이터를 전송할 필요는 없지만, 서버에서 클라이언트로는 여전히 데이터를 보내야 할 때 사용할 수 있다.
양쪽에서 연결을 해제하는 시기가 다를 수 있기 때문에 최종적으로 모든 연결을 해제하려면 4단계 핸드셰이크 (4-way handshake)가 필요하게 된다.
✅ 리셋 플래그(Reset Flag)
제어 필드의 리셋 플래그를 사용하여 연결 거절(SYN세그먼트)에 대해서 거절하거나 혹은 연결을 비정상 종료할 수 있다.
이 플래그는 연결 설정 중이거나 이미 설정된 연결을 갑작스럽게 종료할 때 사용된다.
예를 들어, 연결 요청이 거부되거나 오류가 발생했을 때 사용될 수 있다.
데이터 전송 6# : 절반 닫기와 리셋플래그 연결해제 (TCP Connection Termination: Half-Close and Reset Flag)
💡요약: 절반-닫기는 TCP 연결 종료 과정에서 한쪽 방향의 데이터 전송을 종료하지만 다른 방향의 데이터 전송은 유지할 때 사용된다. 일반적으로 클라이언트가 FIN을 먼저 전송하면서 시작되며, 서버가 데이터를 보내는 동안 연결이 완전히 종료되지 않도록 유지됩니다. 절반-닫기는 4단계 핸드셰이크뿐만 아니라 TCP 연결이 활성화된 어느 단계에서든 실행 가능하며, 특정한 방향의 데이터 송수신만 종료하려는 경우 유용하다. 하지만 일반적으로 절반-닫기는 연결 종료 과정의 일부로 실행되는 경우가 많다.
💡중요포인트
FIN 플래그: 연결을 종료하겠다는 요청.
ACK 플래그: 상대방의 요청을 수락하고 확인했다는 응답.
✅클라이언트의 FIN 전송 (Active Close)
클라이언트는 더 이상 데이터를 보낼 필요가 없을 때, FIN 플래그가 설정된 세그먼트를 서버로 전송한다. “더 이상 데이터를 보내지 않겠다”는 뜻이다.
이는 클라이언트가 연결 종료를 요청한 것을 의미하며, 연결 종료를 액티브 클로즈 (Active Close)라고 한다.
서버로부터 데이터를 받는 기능은 유지한다.
✅ 서버의 ACK 전송
서버는 클라이언트의 FIN 요청을 수락하고 ACK 플래그가 설정된 세그먼트를 클라이언트로 보낸다. 이는 클라이언트의 연결 종료 요청을 확인했다는 의미이다.
이 상태에서도 서버는 여전히 데이터를 전송할 수 있으며, 클라이언트는 데이터를 수신할 수 있다.
✅ 서버의 FIN 전송 (Passive Close)
서버도 연결 종료를 준비하고, FIN 플래그가 설정된 세그먼트를 클라이언트로 보낸다. “나도 데이터 전송을 종료하겠다”는 알림이다.
이는 서버가 연결을 종료하려는 패시브 클로즈 (Passive Close) 단계이다.
서버도 이 시점부터 송신을 종료하지만, 클라이언트로부터 ACK를 받을 준비는 계속된다.
✅ 클라이언트의 최종 ACK 전송
클라이언트는 서버의 FIN 요청을 수락하고, 마지막으로 ACK 플래그가 설정된 세그먼트를 서버로 전송한다.
이로써 연결이 완전히 종료되게 된다.
