네트워크 이론 기초 - 4. L4 Layer - TCP, UDP

 

1. TCP

 

TCP 개요

다시 한번 OSI 7 Layer의 전체적인 개념을 짚고 넘어간다.

 

 

L4 레이어에서의 식별자는 Port 번호이다. Port 번호 단위가 나오면 L4 Layer 수준 이상으로 넘어가는 것이라고 생각하면 된다.

 

TCP에는 연결(Connection, Session) 개념이 있다.

 

 

TCP는 Client와 Sever로 구성된다. Server에서는 Socket을 열고 대기하고 있다(Listen). Client에서는 OS에서 3000번을 열었고, Server에서는 Web인 경우 보통 80번을 열기 때문에 위 그림처럼 트래픽이 전달되는 구조이다.

 

연결 대기 중이 아닌데 연결 요청이 오면 Kernel mode 수준에서 연결을 못받아준다는 응답을 보낸다.

 

 

TCP 연결 과정: 3-way handshaking

 

 

SYN(Synchronization), ACK(Acknowledgement) 요청과 응답이 반복되면서 진행되는 것을 볼 수 있다. 여기서 Sequence number를 보내는데, 처음 클라이언트에서 1000번으로 보내면 서버에서 그걸 알아들었다는 뜻으로 1001번을 ACK로 보낸다. 이런 순서를 통해 통신하는 방식이다. TCP는 Sequence 번호를 교환하는 것을 기반으로 한다. 서버는 본인의 Sequence number인 4000을 보내고 마지막으로 클라이언트가 이를 알아들었다는 뜻으로 4001을 보내면 연결이 성립된다. 각 Client와 Server가 연결됐다고 판단하는 Established 순간이 다르다는 것도 알아두자.

 

3-way handshaking 과정에서는 Segment 단위에 IP/TCP Header만 있고 Payload는 없는 형태이다. 또한 정책을 교환하게 되는데, 그 중 MSS(Maximum Segment Size)도 교환한다. 예를 들어 한쪽이 1460 byte, 나머지가 1400 byte라면 1400 byte라는 낮은 기준에 서로의 기준을 맞춰서 통신한다.

 

 

TCP 연결 종료 과정: 4-way handshaking

연결을 하겠다고 요청하는 것이 클라이언트였다. 연결을 끊겠다는 요청을 보내는 것도 클라이언트이다. 클라이언트쪽이 Active한 쪽이다.

 

클라이언트에서 FIN(Finish) 요청을 ACK와 함께 보낸 후, 서버의 ACK를 받은 뒤 다시 서버의 FIN + ACK를 기다린다. 이후 서버에서도 FIN + ACK를 보내고 클라이언트의 ACK를 받는다. 즉 FIN + ACK, ACK 통신이 2벌로 일어난다.

 

특히 클라이언트의 마지막 TIME_WAIT 상태는 연결을 끊자고 요청한 클라이언트에서 발생하고, 이후 연결이 끊어진다는 것을 의미한다는 것을 기억하면 도움이 된다. 이후 closed되고 나면 socket이 회수되면서 자원이 회수된다. 만약 서버의 소켓이 모자란 경우, 서버에서 연결을 끊어버리는 것이 아니라 클라이언트에 요청하여 연결을 끊는 요청을 보내라고 요청한다. 이런 방식으로 서버를 설계해야 서버에서 TIME_WAIT가 발생하지 않는다. Active 역할은 클라이언트가 하는 것이다.

 

 

TCP Header 형식

 

 

32 bit 단위이다. port 번호가 16 bit씩 차지하므로 2^16이므로 0 ~ 65535까지이다. 다만 0과 65535는 사용하지 않는다. Sequence Number, Acknowledgement number는 위에서 배운바와 같고, Data offset은 Payload가 있는지 없는지 표시하는, IHL(Internet Header Length)와 비슷한 개념이라고 생각하면 된다.

 

나머지 NS, CWR, ECE 등은 flag로 상태값을 표시한다.추가로 RST는 Reset으로 연결을 끊고 다시 하자는 것, PSH(Push)는 버퍼링하지말고 즉시 보내자는 요청을하는 flag이다. NS, CWR, ECE 부분은 혼잡 제어 부분이다. Loss, Re-Trans, Duplicate-ACK, Out of order, Zero window와 같은 장애 유형이 발생했을 때 표시하고 제어해주는(혼잡 제어) 역할을 한다.

 

 

2. UDP

 

udp header 형식

tcp와 비교해보면 매우 단순하다. 혼잡 제어나 수신 측의 버퍼 등 상황을 전혀 고려하지 않는다. 클라이언트를 신경쓰지 않는 것이다.

 

UDP를 사용하는 대표적인 예시는 영상 송출, 게임 서버 같은 경우가 있다. 영상 송출 서버에 엄청나게 많은 클라이언트가 연결되어 있는 경우, 느린 클라이언트에 속도를 맞추는 것이 아니라 클라이언트를 무시하고 그냥 데이터를 쭉 보내야한다. 게임 서버도 TCP로 처리하는 경우 하향 평준화가 되어버리므로 UDP로 처리한다. 캐릭터가 중간중간 끊겨서 움직이는 것은 중간 데이터가 없어서 끊겨보이는 것이다. 이걸 만약 TCP로 처리한다면 재전송하는 등 문제가 발생하고, 다른 유저에게도 영향이 가므로 TCP 대신 UDP로 처리한다. 다만 UDP도 필요한 경우 커스텀한 혼잡 제어 로직을 만들기도 한다.

 

 

 

3. 연결 개념

 

연결되었다고 데이터가 잘 전송된다고 믿으면 안된다.

TCP 통신 중 LAN선이 분리되는 등 연결이 끊어지게되면 재확인을 한다. Heartbeat을 체크한다고 표현한다. 그리고 재전송 타이머의 시간이 넘어가기 전에는 연결은 계속 유지된다. 재전송 타이머의 근사값은 대략 3초이며, 대부분의 운영체제들은 1초 미만이다. 타이머 만료 이후에도 확인 응답을 받지 못하는 경우 세그먼트를 재전송하며 RTO(Retransmission Time-Out) 값은 2배로 증가한다. 보통 5회 재전송을 시도하며 1초, 2초, 4초, 8초, 16초 간격으로 재전송을 한다. 5회 모두 실패 시 전송 오류가 발생하는 것이된다. 따라서 연결은 되어있는 상태지만, 실제로 데이터는 전달되지 않는 시간이 걸릴 수 있으므로 연결되었다고해서 무조건 데이터가 전달된다고 생각하면 안된다.

 

참고로 위와 같이 연결이 끊어지는 경우를 충격이라고 표현하고, 이런 충격을 대비하기 위해서 타임아웃인 1초 값 이상의 데이터를 버퍼에서 완화하는 구조로 만든다.

 

 

 

 

 

 

참조

 

인프런: 외워서 끝내는 네트워크 핵심이론-기초, 널널한 개발자

https://www.inflearn.com/course/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%ED%95%B5%EC%8B%AC%EC%9D%B4%EB%A1%A0-%EA%B8%B0%EC%B4%88/dashboard