TCP/UDP

HTTP/IP/TCP/UDP 는 모두 프로토콜

 

프로토콜은 클라이언트와 서버가 정보를 교환할 수 있도록 하는 메시지 형식에 대한 규칙이다. 

 

HTTP는 브라우저의 개발자 도구의 네트워크 탭에서 HTTP메시지의 헤더를 통해 어떤 구조로 메시지를 주고 받는지 눈으로 확인이 가능하고 IP 같은 경우 192.168.10.1과 같이 숫자로 주소값을 나타내고 있다는 것을 알 수 있다.

 

그러나! TCP/UDP같은 경우 실질적으로 눈에 보이는게 없다보니 잘 와닿지 않는다.

 

TCP/UDP에 대해 자세히 알아보자

 

TCP(전송 제어 프로토콜)?

IP(Internet Protocol)가 인터넷 프로토콜로써 복잡한 인터넷 망 속에서 클라이언트와 서버간에 통신할 수 있게 IP주소와 패킷과 같은 규칙을 통해 통신을 하게 하는 것이라면,

 

TCP(Transmission Control Protocol)는 규칙으로만 통신하기에 부족하거나 불안정하던 여러 단점들(패킷 순서가 이상하거나 패킷이 유실)을 커버해, 패킷 전송을 제어하여 신뢰성을 보장하는 프로토콜이라 생각하면 된다.

 

 

택배를 예시로 들어보자

 

인터넷 통신을 택배 수하물에 비유한다면, IP는 단순히 배달 주소지이고, TCP는 이 배달 주소지로 문제없이 전송되도록 여러 부가 정보를 담은 택배 스티커라고 비유할 수 있다.

 

 

 

TCP의 통신

TCP는 배달 전 목적지를 먼저 확인하고 배달이 끝난 후에도 완료 여부를 확인해 주는 프로토콜이다.

이러한 과정이 우리가 흔히 얘기하는 3way handshaking 과 4way handshaking이다.

 

각 과정이 어떻게 이뤄지는지 조금 더 자세히 알아보자

 

 

3way handshaking

 

TCP 연결을 생성할 때 SYN과 ACK이라는 패킷을 주고 받으며 통신한다. SYN과 ACK은 쉽게 말해 택배의 운송장 같은 느낌 이라고 생각하면 된다.

 

즉 SYN과 ACK을 통해 클라이언트와 서버는 서로 패킷 내부에 들어있는 플래그 값들을 확인하여 패킷의 순서와 올바른 패킷인지를 검증하는 것이다.

 

 

3way handshaking 동작과정

 

 

1. 클라이언트는 접속을 요청하는 SYN 패킷을 보내고 응답을 기다리기 위해 SYN_SENT 상태로 변한다.
2. LISTEN 상태였던 서버는 SYN 요청을 받으면 요청을 수락하는 ACK 패킷과 SYN 패킷을 보내고 SYN_RCVD(SYN_RECIEVED)상태로 변하여 클라이언트가 ACK 패킷을 보낼 때 까지 기다린다.
3. 클라이언트는 다시 ACK 패킷을 보내고, 이후 ESTABLISHED 상태가 되어 데이터 통신이 가능하게 된다.

 

데이터 통신 과정

 

1. Established 된 상태에서 서버에게 데이터를 보낸다.
2. 서버는 수신에 대한 응답으로 ACK플래그를 넣어 응답한다.
3. 만약 클라이언트가 서버로부터 ACK 패킷을 못받았으면 송신 불량으로 판단하고 데이터를 재전송 한다.

 

4way-handshaking

3way-handshaking과 마찬가지의 작업이지만 연결을 끊어주는 작업이라고 생각하면 된다.

 

 

 

4way-handshaking 동작과정

 

1. 서버와 클라이언트가 TCP연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 CLOSE()함수를 호출하면 FIN플래그를 보내게 되고 클라이언트의 상태는 FIN_WAIT1으로 변한다.
2. 서버는 클라이언트가 연결 해체한다는 것을 알게되고 CLOSE_WAIT 상태로 바꾼 후 ACK플래그를 전송한다. ※만일 서버에서 클라이언트로 보낼 데이터가 남은 경우 이때 나머지를 모두 전송시킨다.
3. ACK을 받은 클라이언트는 FIN_WAIT2로 변환되고, 이때 서버는 CLOSE() 함수를 호출하고 FIN플래그를 클라이언트에게 보낸다.
4. 서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK플래그를 보낸 후 TIME_WAIT 상태로 전환된다.
5. 이 후 모든것이 끝나면 CLOSED 상태로 변환된다.

 

 

 

TCP의 전송 제어 기법

TCP는 단어 그대로 원활한 통신을 위해 전송 흐름을 제어하는 기능을 프로토콜 자체에 포함하고 있다.

 

흐름제어가 왜 필요할까?

1. 송신자가 데이터를 전송하는 속도가 수신자가 데이터를 처리하는 속도보다 빠른경우 수신자의 버퍼에는 미처 처리하지 못한 데이터가 쌓이게 된다.
2. 송신자가 사용하는 네트워크에 엄청나게 많은 인원이 데이터를 전송하는 경우 라우터 또한 데이터를 처리하는 속도와 데이터를 보관해두는 버퍼가 있는데 라우터의 처리 속도보다 데이터가 많이 들어온다면 송신자는 라우터가 처리하지 못한 데이터를 잃어버린 데이터라 간주하고 다시 데이터를 요청하게 된다. 그렇다면 이 과정이 반복되며 네트워크는 더욱 혼잡해 질 것이다.

※라우터: 네트워크와 네트워크 간 경로를 설정하고 가장 빠른 길로 트래픽을 이끌어주는 네트워크 장비

 

이를 해결하기 위한 대표적인 제어로 흐름 제어(Flow Control), 오류 제어(Error Control), 혼잡 제어(Congestion Control) 등이 있다.

 

 

흐름 제어(Flow Control)

수신자가 처리할 수 있는 데이터 속도가 다르기 때문에, 송신 측은 수신 측의 데이터 처리 속도를 파악하고 얼마나 빠르게 어느 정도의 데이터를 전송할 지 제어

 

stop and wait 방식

상대방에게 데이터를 보낸 후 잘 받았다는 응답이 올 때까지 기다리는 방식으로 다소 비효율적이다. 이를 개선한 것이 슬라이딩 윈도우 방식이다.

 

슬라이딩 윈도우(Sliding Window) 방식을 사용

• 슬라이딩 윈도우? - 알고리즘의 한 종류로 말 그대로 고정적인 너비를 가진 창문을 두고 옆으로 한칸씩 이동하며 값을 구하는 방법
• 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답없이 세그먼트를 전송할 수 있게 하여 Window라는 데이터를 담는 공간을 동적으로 조절하여 데이터량을 조절

 

 

 

오류 제어(Error Control)

 

통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 방식으로

Go Back N 기법과 Selective Repeat(선택적인 재전송) 기법을 사용한다.

 

 

Go Back N

 

Go Back N 기법

연속으로 데이터를 보내다가 오류가 발생한 지점부터 재전송하는 방식으로 위의 그림을 보면 4번에서 에러가 발생했기 때문에 4번부터 다시 순서대로 보내 제어한다.

 

 

 

Selective Repeat

오류가 발생한 데이터만 재전송하고 그전에 받았던 순서가 잘못된 데이터 버퍼를 재정렬하여 제어한다.

 

 

혼잡제어(Congestion Control)

네트워크가 불안정하여 데이터가 원활히 통신이 안되면 제어를 통해 재전송을 하게 되는데, 재전송 작업이 반복되면 네트워크가 붕괴될 수 있다. 따라서 네트워크 혼잡 상태가 감지되면 송신 측의 전송 데이터 크기를 조절하여 전송량을 조절한다.

흐름 제어는 송신 측과 수신 측의 전송 속도를 다루고, 혼잡 제어는 라우터를 포함한 넓은 범위의 전송 문제를 다룬다.

 

 

 

AIMD(Additive Increase Multicative Decrease)

처음에 패킷 하나를 보내는 것으로 시작하여 전송한 패킷이 문제없이 도착한다면 window size를 1씩 증가시키며 전송하는 방법이다. 만약 패킷 전송을 실패하거나 Time_Out이 발생하면 Window Size를 절반으로 감소시킨다.

 

이 방식을 사용하는 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있다.

문제는 초기에 네트워크의 높은 대역폭을 사용하지 못해 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다. 즉 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

 

Slow Start(느린 시작)

 

AIMD와 같이 패킷을 하나씩 보내고 문제가 발생하지 않으면 각 ACK 패킷마다 윈도우 크기를 1씩 증가시킨다. 즉 한 주기가 지나면 윈도우 크기는 2배가 된다.

AIMD와 다른점은 전송 속도를 지수 함수 꼴로 증가시켜서 윈도우 크기를 더 빠르게 증가시킨다.

이후 혼잡이 감지되면 윈도우 크기를 1로 줄인다. 처음엔 네트워크 수용량을 예상할 수 있는 정보가 없지만, 한 번 혼잡 현상이 발생한 후에는 네트워크의 수용량을 어느 정도 예상할 수 있다.

그래서 혼잡 현상이 발생하는 윈도우 크기의 절반까지는 지수 함수 꼴로 윈도우 크기를 증가시키고 그 이후에는 완만하게 1씩 증가시킨다.

 

 

 

 

Fast Retransmit(빠른 재전송)

패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK패킷을 보내게 된다.

단! 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK패킷에 실어 보내게 되므로 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송 해줄 수 있다.

중복된 순번의 패킷을 3개 받으면 재전송을 하게 된다. 이는 혼잡한 상황이 일어난 것이기 때문에 window size를 줄이게 된다.

 

Fast Recovery(빠른 회복)

혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다.이 정책까지 적용하면 혼잡 상황을 한 번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

 

 

 

UDP(사용자 데이터그램 프로토콜)

보통 UDP를 TCP와 비교할 때 대략 TCP는 신뢰성이 높고 느린 반면 UDP는 신뢰성이 낮고 빠르다 라고 들어봤을 것이다.

아무래도 TCP는 신뢰성 있는 통신을 할 수 있도록 3way handshaking을 거치게 되는데 위에서 설명한 것과 같이 많은 작업들이 필요했다.

 

그런데 인터넷 기술이 발달하고 전송해야 하는 데이터도 단순 텍스트를 넘어 동영상이나 음악과 같은 멀티미디어도 전송하면서 데이터의 크기가 점점 커지게 되고 빠른 통신이 필요하게 되었다.

 

UDP는 데이터그램 방식을 사용하는 프로토콜이기 때문에 패킷간의 순서가 존재하지 않는 독립적인 패킷을 사용한다.

여기서 데이터 그램 방식이란 패킷의 목적지만 정해져 있자면 중간 경로는 어딜 타든 신경쓰지 않기 때문에 핸드쉐이크 과정 같은 연결 설정이 필요 없게 된다.

 

즉 UDP는 신뢰성 확보를 위해 거치던 TCP의 과정을 거치지 않기 때문에 속도가 더 빠를 수 밖에 없다. 그래서 UDP는 실시간 영상 스트리밍과 같은 고용량 데이터를 다루는 곳에 이용된다.

 

 

TCP 헤더와 UDP 헤더의 크기 차이

 

TCP헤더 구성

 

TCP는 워낙 오래전에 설계되다 보니 이런 저런 기능이 많이 포함되어 헤더가 거의 꽉 차있다.

헤더에는 아래 표와 같은 정보가 포함된다.

 

필드	내용	크기
송수신자의 포트 번호	TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당되는 포트 주소	16
시퀀스 번호(Sequence Number)	송신자가 지정하는 순서 번호, 전송되는 바이트 수를 기준으로 증가. SYN = 1 : 초기 시퀀스 번호가 된다. ACK 번호는 이 값에 1을 더한 값. SYN = 0 : 현재 세션의 이 세그먼트 데이터의 최초 바이트 값의 누적 시퀀스 번호	32
응답 번호(ACK Number)	수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용.	32
데이터 오프셋(Data Offset)	TCP 세그먼트의 시작 위치를 기준으로 데이터의 시작 위치를 표현(TCP 헤더의 크기)	4
예약 필드(Reserved)	사용을 하지 않지만 나중을 위한 예약 필드이며 0으로 채워져야한다.	6
제어 비트(Flag Bit)	SYN, ACK, FIN 등의 제어 번호 -> 아래 추가 설명 참조	6
윈도우 크기(Window)	수신 윈도우의 버퍼 크기를 지정할 때 사용. 0이면 송신 프로세스의 전송 중지	16
체크섬(Checksum)	TCP 세그먼트에 포함되는 프로토콜 헤더와 데이터에 대한 오류 검출 용도	16
긴급 위치(Urgent Pointer)	긴급 데이터를 처리하기 위함, URG 플래그 비트가 지정된 경우에만 유효

 

 

UDP 헤더 구성

반면 UDP는 데이터 전송 자체에만 초점을 맞추고 설계되었기 때문에 헤더에 들어있는게 없다.

즉 수신자가 데이터를 받든 말든 데이터만 전송하기 때문에 신뢰성을 보장해주지 않지만 대신 속도가 빠른 것이다.

아래와 같은 정보가 들어있다.

필드	크기	내용
송신자의 포트 번호	16	데이터를 보내는 애플리케이션의 포트 번호
수신자의 포트 번호	16	데이터를 받을 애플리케이션의 포트 번호
데이터의 길이	16	UDP 헤더와 데이터의 총 길이
체크섬(Checksum)	16	데이터 오류 검사에 사용

 

 

 

 

References

https://inpa.tistory.com/entry/NW-%F0%9F%8C%90-%EC%95%84%EC%A7%81%EB%8F%84-%EB%AA%A8%ED%98%B8%ED%95%9C-TCP-UDP-%EA%B0%9C%EB%85%90-%E2%9D%93-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

https://velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4

https://coding-factory.tistory.com/614

https://benlee73.tistory.com/186