TCP에 대하여 설명해주세요.
TCP는 전송 계층의 연결형 프로토콜입니다. 3way-handshake 과정을 통해 클라이언트와 서버를 연결하고 4way-handshake 과정을 통해 연결을 해제합니다. TCP는 데이터의 처리속도를 제어하는 흐름제어를 제공합니다. 또한, 네트워크의 패킷이 과도하게 증가하지 않도록 방지하는 혼잡제어를 제공합니다. 이러한 특성으로 인해 TCP는 높은 신뢰성을 보장하지만, 느린 속도를 가집니다.
UDP에 대하여 설명해주세요.
반면 UDP는 전송 계층의 비연결형 프로토콜입니다. 3way-handshake 과정을 통해 연결하는 과정이 없기 때문에 신뢰성이 떨어진다는 단점이 있지만, 즉각적인 통신이 가능하기 때문에 속도가 빠르다는 장점이 있습니다.
TCP의 흐름제어에 대해서 말씀하셨는데, 흐름제어에 대해 설명해주시겠어요?
송신자와 수신자가 통신하는 과정에서 수신자의 데이터 처리 속도가 송신자의 송신 속도보다 빠르다면 문제될 것이 없지만, 만약 수신자의 데이터 처리속도가 더 느리다면 문제가 발생합니다. 수신자의 제한된 버퍼를 초과하는 양의 패킷이 전달되면, 그 과정에서 패킷이 손실될 수 있고, 불필요한 재전송을 해야합니다. TCP는 이러한 상황을 방지하기 위해 흐름제어를 제공합니다.
흐름 제어에는 Stop And Wait 방식과 Sliding Window 방식이 존재합니다. Stop And Wait 방식은 패킷을 보낼 때마다 그에 해당하는 ACK 응답을 받고나서 그 다음 패킷을 보내는 방식입니다. 하지만 이러한 방식은 데이터를 전송하는데 너무 많은 시간을 필요로 하기에 비효율적인 방식으로 평가받고 있습니다.
반면 Sliding Window 방식은 수신측의 정보를 통해 정해진 Window Size 만큼은 ACK 응답을 받지 않고도 연속적으로 패킷을 전달하는 방식입니다. 초기 Window Size는 3way-handshake 과정에서 수신 측의 Window Size로 정해집니다. 이후 Window Size는 수신 측의 버퍼에 남아있는 공간의 크기로 변화합니다. Window Size는 수신 측에서 송신 측으로 ACK 응답을 보낼 때 TCP헤더에 담아서 보내게됩니다.
그렇다면, TCP의 혼잡제어에 대해서도 설명해주시겠어요?
만일 데이터의 양이 라우터가 처리할 수 있는 양을 넘어서게되면, 라우터는 데이터를 처리할 수 없습니다. 송신 측에서는 이러한 과정을 데이터의 손실로 인지하고 재전송을 진행하여 네트워크를 혼잡하게 합니다. 이러한 상황은 송신측의 송신 속도를 적당히 조절함으로써 방지할 수 있습니다. 이러한 방식을 혼잡제어라고 명칭합니다.
혼잡제어의 방식에는 어떤 것들이 있죠?
AIMD 방식은 합 증가 곱 감소 방식입니다. 패킷을 하나 보내고 문제가 없다면, Window 의 크기를 1씩 늘려가면서 전송합니다. 만약 혼잡을 감지하게되면 Window 사이즈를 반으로 줄입니다. AIMD 방식은 Window의 크기를 너무 느리게 증가시키기 때문에 원활한 네트워크 통신을 하기까지 오랜 시간이 소요된다는 단점이 있습니다.
Slow Start 방식은 AIMD 방식과 다르게 Window의 크기를 지수적으로 증가시킵니다. 하지만 이 과정에서 혼잡을 탐지하게되면 Window의 크기를 1로 고정시킵니다. Slow Start 방식은 윈도우의 크기를 갈수록 빠르게 증가시키기 때문에 AIMD가 가지지 못한 장점을 가지게됩니다.
Fast Retransmit 방식은 수신자 입장에서 패킷이 순서대로 도착하지 않는 경우 사용됩니다. 수신 측에 패킷이 순서대로 도착하지 않는다면, 수신 측에서는 순서대로 잘 도착한 마지막 패킷의 다음 순번을 ACK 응답에 실어서 보냅니다. 송신 측에서 이러한 ACK을 중복 3번을 받게되면 재전송을 실시합니다. 송신측은 Time out 시간이 되기 전에 패킷을 재전송 할 수 있기때문에 시간적인 효율성을 챙길 수 있습니다.
Fast Recovery 방식은 혼잡을 감지하면 Window의 크기를 1로 만들지 않고 반으로 줄인 뒤, 선형적으로 Window 크기를 증가시킵니다. 이 방식을 적용하면 한번 혼잡을 겪고난 뒤 AIMD 방식으로 동작하게됩니다.
아까 말씀하신 3way-handshake 과정에 대해서도 설명해 주실래요?
TCP의 헤더에서는 Control bit 로 불리는 6개의 비트가 있습니다. 이 중에는 SYN과 ACK 필드가 존재합니다. 클라이언트가 서버와의 연결을 요청하는 SYN을 보냅니다. 서버가 이에 응답하는 SYN+ACK 을 보내고, 클라이언트가 이에 응답하는 ACK을 전송하면 TCP 연결이 완료됩니다.
그렇다면 4-way handshake 는 어떤 것이죠?
클라이언트가 연결의 해제를 원하면 서버측에 FIN 요청을 보냅니다. 서버는 이에 ACK 응답을 보냅니다. 연결을 해제할 준비가 되면 서버는 클라이언트에 FIN 요청을 보냅니다. 클라이언트는 이에 응답하는 ACK을 보내고 TIME-WAIT 상태가 됩니다.
왜 연결은 3way 인데 종료는 4way 방식을 사용하나요?
클라이언트가 전송을 마쳤다고 하더라도 서버에서 전송할 데이터가 남아있을 수 있기 때문입니다. 그렇기에 일단 클라이언트가 요청하는 FIN 에 응답하는 ACK를 보내고, 데이터를 모두 전송한 뒤에 클라이언트측에 FIN 요청을 보냅니다.
만일 서버가 연결을 해제하는 FIN 플래그를 요청하기 전에 보낸 패킷이 지연이나 손실로 인해 FIN 보다 늦게 도착하게 되면 해당 패킷을 어떻게 받을 수 있나요?
클라이언트는 서버의 FIN 요청에 마지막 ACK 플래그를 응답하고 TIME-WAIT 상태에 들어갑니다. 이 기간동안 세션을 남겨두고 패킷을 기다리는 시간을 가집니다.
TCP는 왜 초기 순서번호인 ISN 을 난수로 설정할까요? 0부터 시작하는 순차번호를 사용하지 않는데 이유가 있을까요?
TCP 연결을 맺을때 사용하는 Port는 시간의 지남에 따라 재사용되는 경우가 많습니다. 따라서 과거에 사용한 적이 있는 포트를 사용할 때 0부터 시작하는 순차번호를 사용한다면, 이전의 연결로부터 오는 패킷으로 인식할 수 있습니다. 이러한 경우를 방지하고자 ISN을 난수로 설정합니다.
그렇다면 UDP를 사용할 경우 신뢰성을 제공할 수 있는 방법이 존재하지 않는건가요?
방법이 없지는 않습니다. UDP 프로토콜 자체에서 신뢰성을 보장할 수는 없지만, 응용 계층의 프로토콜에 이 과정을 위임하면 UDP를 사용하면서도 신뢰성을 보장할 수 있습니다. 예시로 HTTP/3 은 응용 계층 프로토콜인 QUIC을 사용합니다. HTTP/3 은 전송계층에서는 UDP를 사용하지만 응용계층에 QUIC 프로토콜로 TCP와 유사한 신뢰성을 제공함으로써 높은 신뢰성과 빠른 속도를 제공합니다.
