복잡한 인터넷 세상에서 어디론가 메시지를 보내기 위해서는 최소한의 규칙이 필요하다. 쉽게 말해서 그 규칙이 ip다.
그럼 ip가 하는 역할을 좀 알아보자
- 지정한 ip 주소에 데이터 전달
- 패킷(packet)이라는 통신 단위로 데이터 전달
쉽게 말해서 특정 주소 A에서 특정 주소 B로 데이터를 전달하는데 이를 패킷이라는 단위로 데이터를 쪼게서 전달한다는 뜻이다. 하지만 이러한 IP도 한계가 있다.
ip의 한계
- 비연결성 : 받는 상대가 받을 수 있는지 확인 안함, 걍 보냄
- 비신뢰성 : 데이터가 잘 전달 됬는지 신경 안씀, 보낸 순서도 상관 안하고 그냥 먼저 도착하는 데이터 순으로 받게 됨
- 프로그램 구분 : 어떤 데이터가 어떤 프로그램의 데이터인지 구분하지 못함
그냥 상식적으로 생각해보자 편지를 보내면 상대방이 편지를 잘 받았는지 물리적으로 알 수 있는가? 없다! 옜날에는 데이터의 전송도 편지 배달과 같은 방식이였을 것이다.
그래서 위와 같은 한계를 극복하기 위해 TCP라는 방식이 생긴 것이다!
TCP/UDP
- TCP 은 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요한 네트워크 프로토콜이다. TCP는 데이터와 패킷이 보내진 순서대로 전달하는 것을 보장해준다
- UCP도 다른 컴퓨터와 데이터 통신을 하기 위한 네트워크 프로토콜의 일종이다.TCP와는 다르게 패킷의 순서, 수신여부를 보장하지 않는다.
그렇다면 이 TCP와 UDP가 네트워크에서 어디에 어떻게 적용되는가를 알아보자, 일단 우리는 네트워크의 계층구조에 대해 알고 있어야 한다.
일단 둘다 같은 네트워크에 대한 계층적 설명이다. 다만 바라보는 시점에 따라 계층의 이름과 세분화가 다르게 되어 있는 것이다.
OSI 7 Layer 개요
- 네트워크 통신을 체계적으로 다루고 있는 ISO 표준은 개방시스템 상호연결 (OSI) 모델 이다. OSI 모델은 1984년에 정의 되었다.
- 개방시스템(Open System)이란 기반구조와 관계없이 시스템간의 통신을 제공하는 프로토 콜의 집합이다.
- 계층구조를 가짐으로써 데이터자체의 흐름을 각 구간별로 데이터의 움직임을 알 수 있다. 또한 트러블슈팅 자체가 용이해지며 각기 다른 벤더사 와의 호환성도 해결될 수 있다.
TCP/IP Protocol Suite 개요
- TCP/IP는 현재의 인터넷에서 컴퓨터들이 서로 정보를 주고받는데 쓰이는 통신규약 (프로토콜)의 모음이다.
- 1960년대 말 미국방성의 연구에서 시작되어 1980년대 초 프로토콜 모델이 공개 되었다.
- 하드웨어, 운영체제, 접속매체에 관계없이 동작할 수 있는 개방성을 가진다.
뭐 사전적인 정의는 위와 같다. 오늘 알아볼 TCP/UDP는 두 계층적 설명에서 transport layer (전송 계층)에서 일어나는 일이다. 그리고 이번 글에서는 TCP/IP Protocol Suite을 중심으로 작성한다.
간단하게 위 계층 간 데이터 송수신 과정을 살펴 보면 다음 그림과 같다.
위 그림 처럼 데이터를 전송하면 아래 그림 처럼 각 계층을 통과하며 "캡슐화" 가 진행된다. 캡슐화를 해서 링크 계층을 통해 전달하면 받는 쪽에서는 "비캡슐화" 가 진행되며 데이터를 획득 한다.
TCP/UDP는 어디? "전송 계층" 에서 캡슐화를 담당해 정보를 처리한다. 받는 쪽에서 비캡슐화를 진행하하다 tcp헤더를 만나면 그에 맞는 로직을 작동한다고 이해하면 좋을듯 하다.
TCP를 알아보자~
먼길 돌아왔다...
TCP는 상대방의 연결 상태를 확인하고 데이터를 전송함으로 데이터의 순서를 보장한다! 이걸 어떻게 구현되어 있느냐
일단 데이터 전송 전에 서로 연결이 가능한지 확인을 한다. 이를 3way handshake 라고 한다
예를 들어 하나의 전송 데이터를 5개의 패킷으로 쪼겠고 이걸 순차적으로 SERVER로 전달한다고 해보자.
먼저 연결을 확인한다 (#1, #2). 그럼 #3에 패킷1을 같이 전달한다. 그럼 서버에서 패킷1을 수신했으면 다시 ACK으로 받아야할 다음 패킷2를 보내달라고 요청한다. 이걸 패킷5까지 반복한다.
아니 그럼 이 TCP 통신이 어디에 나와 있는데!
헤더에 나와 있습니다. 고갱님~
헤더를 한번 까보자
구조상 이렇게 생겼다. 이 tcp 헤더가 전체 ip 헤더의 protocol에 들어간다. 전체 헤더는..
대충 감이 오는가? 그럼 tcp 헤더의 각 부분에 대해 한번 알아보자.
Source port, Destination port
세그먼트의 출발지와 목적지를 나타내는 필드다. IP주소와 port 번호가 필요하겠지만 ip주소는 ip헤더에 담겨있기 때문에 TCP 헤더에는 ip주소 필드는 없고 포트만 넣는다.
Sequence Number
데이터의 순서를 뜻한다. 순서 번호는 최대 4,294,967,296까지 설정할 수 있어서 쉽게 중복되지 않는다. 이걸 보고 데이터를 받는 쪽에서 세그먼트를 순서대로 다시 조립할 수 있는 것이다.
Acknowledgment Number
일종의 승인 번호다. 데이터를 받은 쪽에서 "다음은 이 데이터를 줘"라고 보내는 번호이다. 연결 설정과 연결 해제 때 발생하는 핸드쉐이크 과정에서는 상대방이 보낸 시퀀스 번호 + 1로 자신의 승인 번호를 만들어내지만, 실제로 데이터를 주고 받을 때는 상대방이 보낸 시퀀스 번호 + 자신이 받은 데이터의 bytes로 승인 번호를 만들어낸다.
Data Offset
보내진 세그먼트에서 어디서 부터가 payload의 시작인지를 뜻한다.
Reserved
미래를 위해 예약된 필드로, 모두 0으로 채워져야 한다. 상단의 헤더 그림에도 그냥 0 0 0으로 찍혀있는 것을 확인해볼 수 있다.
Flags (NS ~ FIN)
- URG : Urgent Pointer(긴급 포인터) 필드에 값이 채워져있음을 알리는 플래그. 이 포인터가 가리키는 긴급한 데이터는 높게 처리되어 먼저 처리된다. 요즘에는 많이 사용되지 않는다.
- ACK: Acknowledgment(승인 번호) 필드에 값이 채워져있음을 알리는 플래그. 이 플래그가 0이라면 승인 번호 필드 자체가 무시된다.
- PSH: Push 플래그. 수신 측에게 이 데이터를 최대한 빠르게 응용프로그램에게 전달해달라는 플래그이다. 이 플래그가 0이라면 수신 측은 자신의 버퍼가 다 채워질 때까지 기다린다. 즉, 이 플래그가 1이라면 이 세그먼트 이후에 더 이상 연결된 세그먼트가 없음을 의미하기도 한다.
- RST: Reset 플래그. 이미 연결이 확립되어 ESTABLISHED 상태인 상대방에게 연결을 강제로 리셋해달라는 요청의 의미이다.
- SYN: Synchronize 플래그. 상대방과 연결을 생성할 때, 시퀀스 번호의 동기화를 맞추기 위한 세그먼트임을 의미한다.
- FIN: Finish 플래그. 상대방과 연결을 종료하고 싶다는 요청인 세그먼트임을 의미한다.
- NS: ECN에서 사용하는 CWR, ECE 필드가 실수나 악의적으로 은폐되는 경우를 방어하기 위해 RFC 3540에서 추가된 필드
- ECE: ECN Echo 플래그. 해당 필드가 1이면서, SYN 플래그가 1일 때는 ECN을 사용한다고 상대방에게 알리는 의미. SYN 플래그가 0이라면 네트워크가 혼잡하니 세그먼트 윈도우의 크기를 줄여달라는 요청의 의미이다.
- CWR: 이미 ECE 플래그를 받아서, 전송하는 세그먼트 윈도우의 크기를 줄였다는 의미이다.
Window Size
한번에 전송할 수 있는 데이터의 양을 뜻한다.
Checksum
데이터를 송신하는 중에 발생할 수 있는 오류를 검출하기 위한 값이다.
Urgent Pointer
긴급 포인터를 뜻한다. 만약 이 플래그가 1이라면 수신하는 쪽에서는 이 포인터가 가르키는 데이터를 우선 처리한다.
Options
옵션 필드는 TCP의 기능을 확장할 때 사용하는 필드들이며, 이 필드는 크기가 고정된 것이 아니라 가변적이다. 그래서 수신 측이 어디까지가 헤더고 어디서부터 데이터인지 알기 위해 위에서 설명한 데이터 오프셋 필드를 사용한다.
UDP를 알아보자~
솔직히 요즘에는 90% 이상의 IP 통신이 TCP를 사용한다. 그럼 UDP는 구리냐? 안쓰냐? 그건 아니다...
TCP와의 차이점 위주로 보자
- 기능이 거의 없다
- 연결 되었는지, 데이터가 잘 전달 되었는지, 데이터 전달 순서를 모두 신경쓰지 않는다.
- 다만 빠르다. 인증을 위한 절차를 주고 받지 않으니까.
- IP 프로토콜과 거의 같다. 포트나, 체크섬 정도만 추가되었다.
