본 내용들은 면접 질문 정리에서 작성된 질문과 작성자가 추가로 넣은 질문들을 포함해서 최대한 공식문서를 기반으로 답변을 작성하려고 노력했습니다.
틀린 내용이 있다면 바로 지적해주시면 감사하겠습니다.
• TCP와 UDP의 차이에 대해 설명해 주세요.
TCP와 UDP는 신뢰성 있는 데이터의 전송과 분할 전송의 차이가 있습니다. TCP는 3-way handshake를 활용해 상대방과의 통신이 원활한지 확인하여 데이터를 분할해서 전송하고 있고, 전송하는 도중에 패킷이 유실되더라도 이를 감지하여 재전송을 통해 상대방에게 데이터를 신뢰성 있게 보낼 수 있습니다. UDP는 TCP와 다르게 3-way handshake를 하지 않으며 유실되더라도 재전송을 하지 않고, 분할해서 데이터를 보낼 수 없다는 차이점이 있습니다. 하지만 이러한 과정을 생략하기 때문에 TCP 보다 더 빠르게 사용자에게 데이터를 보낼 수 있다는 특징이 있습니다.
• Checksum이 무엇인가요?
체크섬은 중복 검사의 한 형태로, 네트워크 상에서 받은 자료의 무결성을 검사하는 단순한 방법입니다.
한 통신에서 전달받은 데이터를 모두 더하고, 그중의 최상위 캐리 니블을 버린 채 보수를 만들어 체크섬 바이트를 더함으로써 체크섬을 활용한 자료의 무결성을 검증할 수 있습니다.
• TCP와 UDP 중 어느 프로토콜이 Checksum을 수행할까요?
둘 다 패킷에서 Checksum을 가지고 있으므로 둘 프로토콜 모두 수행할 수 있습니다. 하지만 TCP는 필수, UDP는 선택입니다.
• 그렇다면, Checksum을 통해 오류를 정정할 수 있나요?
아니요 오류를 검출할 수는 있지만 정정할 수는 없습니다.
• 수신받은 패킷에 오류가 있을 때 이를 수정하는 방법이 있나요?
수신받은 패킷에 오류가 검출되었다면 송신자에게 다시 패킷을 보내달라고 요청하는 방법과 받은 패킷을 직접 수정하는 방법 두 가지가 있습니다. 전자의 경우 이러한 방법론들을 ARQ(Automatic Repeat Request) 기법이라고 하며, 후자의 경우 대표적인 방식으로는 해밍 코드 방식이 있습니다. 단, 해밍 코드 방식은 1 비트의 에러를 정정할 수 있으며, 그 이상의 에러가 검출될 경우 정정하지 못한다는 단점이 있습니다.
• TCP가 신뢰성을 보장하는 방법에 대해 설명해 주세요.
배경 지식: 신뢰성이란 데이터의 손상과 손실이 없는 것을 말합니다. 신뢰성을 보장해야 하는 이유는 전송 채널의 데이터는 감쇠(채널의 저항으로 인한 에너지 손실 발생), 왜곡(복합신호의 구성 성분들이 주파수별로 채널을 통과하는 속도가 상이), 잡음(열 잡음, 유도 잡음 등등), 패킷별 전송 경로 상이(먼저 전송한 정보가 먼저 도착함을 보장하진 않음) 등의 이유로 신뢰성을 보장받을 수 없기 때문입니다.
TCP는 ARQ(Automatic Repeat Request) 기법을 활용하여 Sequence Number를 기반으로 데이터를 순차적으로 재조립하고 이를 합쳐 Checksum을 활용한 데이터 무결성 검증을 진행하는 방식으로 신뢰성을 보장하고 있습니다. 또한 정상적으로 연결이 되었거나 종료되었는지 확인하기 위해서 3-way handshake 기법과 4-way handshake 기법을 사용하고 있습니다.
• TCP의 흐름 제어 처리 방법에 대해 설명해 주세요.
배경 지식: TCP를 통해 데이터를 전송할 때 흐름을 제어해야 하는 이유는, 송/수신측 간의 전송 속도 조절을 통해 패킷을 버퍼에 넘치지 않고 효율적으로 수용할 수 있도록 하기 위해서다. 수신 측을 고려하지 않고 송신 측에서 너무 많은 데이터를 보내게 될 경우, 수신 측에서 가지고 있던 버퍼의 양을 초과해 버퍼 오버플로우가 날 수 있으며, 이때 넘친 데이터들은 손실되게 되고 송신 측에서는 해당 데이터를 다시 보내야 하는 상황이 생긴다. 그러므로 흐름 제어를 통해 수신 측의 버퍼의 공간을 확인하고 효율적으로 데이터를 보냄으로써 데이터를 두 번 보내는 일이 없도록 하기 위해 흐름 제어를 사용한다.
흐름 제어 처리 방법으로는 슬라이딩 윈도우 기법이 있습니다. 데이터를 보내고 잘 보내졌다는 응답을 다시 받았을 때, 그때 수신 측의 남은 윈도우 크기도 같이 보내주어, 남은 버퍼의 크기를 확인하고 이에 맞춰 송신 측에서 데이터를 해당 양만큼만 보내는 방식입니다.
• 슬라이딩 윈도우의 크기는 어떻게 결정되나요?
슬라이딩 윈도우의 크기는 수신 측의 버퍼 크기에 따라 결정됩니다. 수신 측은 TCP 헤더의 Window Size 필드를 통해 자신의 남은 버퍼 공간을 송신 측에 알려주고, 송신 측은 이 크기를 초과하지 않는 범위에서 데이터를 전송합니다.
• TCP의 혼잡 감지를 하는 방법을 설명해주세요.
TCP에서 혼잡 감지를 할 수 있는 방법은 Timeout, 3 Duplicated ACKs(수신자의 입장에서 송신자가 패킷을 더 보내지 않아 패킷을 보내달라고 ACK 요청을 3번 한 것, 3번의 ACK를 받은 송신자는 재전송을 한다. Dup Ack를 받자마자 재전송을 하는 것이 아니라 3번까지 기다린다.) 두 가지가 있습니다. Timeout 현상에서는 패킷이 수신 측에서 전달되는 과정에서 유실됐다고 판단되기 때문에 혼잡이 발생했다고 판단할 수 있으며, 3 Duplicated ACKs은 같은 응답이 3번 온 것을 통해 패킷 유실이 발생했으나, 수신자 송신자에게 ACK는 전송할 수 있는 상황이라고 추측함을 통해 혼잡을 감지할 수 있습니다.
그외의 ECN이라는 방식도 존재합니다.(라우터가 중간에 혼잡을 감지하는 방식)
• TCP의 rwnd와 cwnd에 대해서 설명해 주세요
rwnd는 수신자의 버퍼 크기를 말하며, cwnd는 송신자의 버퍼 크기를 말합니다. rwnd는 보통 흐름 제어에서 사용하며 cwnd는 rwnd와 비교했을 때 cwnd가 더 작을 경우 혼잡제어에서 사용합니다. rwnd가 더 작을 경우 rwnd를 사용하게 됩니다.
• TCP의 혼잡 제어 처리 방법에 대해 설명해 주세요.
배경 지식: 혼잡 제어를 하는 이유는 종단 간 환경에서 뿐만 아니라, 네트워크 상에서 데이터가 전송될 때 라우터나 홉 등에서 발생할 수 있는 네트워크 혼잡 상황을 방지하기 위해서다. 수신 측의 버퍼 크기가 남았다고 해도 데이터가 이동하는 네트워크 계층의 버스의 크기는 여러 개의 송/수신 측에서 보내지는 데이터를 담고 있기 때문에, 자신만 생각할 수 없게 된다. 때문에 서로 상호 협의 하의 데이터를 효율적으로 보낼 수 있도록 네트워크 계층을 위한 혼잡 제어 방법이 필요한 것이다.
TCP의 혼잡 제어 방식으로는 대표적으로 Tahoe와 Reno 방식이 있습니다. Tahoe는 패킷 손실 발생 시 혼잡 윈도우를 1로 줄이고 다시 Slow Start(1부터 2의 제곱만큼 보내는 혼잡 윈도우의 크기 증가)부터 시작하는 방식이고, Reno는 3번의 중복 ACK를 받았을 때는 Fast Recovery를 사용하여 혼잡 윈도우를 반으로만 줄이고 AIMD(cwnd / 2의 임계점을 넘을 때부터 1씩 증가하고 혼잡 윈도우를 반으로 줄이는 방식)로 동작합니다. 단, 타임아웃으로 혼잡이 감지되면 Tahoe처럼 Slow Start부터 다시 시작합니다. 현재는 Linux, Window 시스템에서 CUBIC이 기본 혼잡제어 알고리즘으로 사용되고 있는데, 이는 윈도우 크기를 시간의 3차 함수로 증가시키며 RTT에 독립적으로 동작하여 높은 대역폭과 긴 지연 시간을 가진 네트워크에서도 효율적으로 동작한다는 특징이 있습니다.
• 왜 HTTP는 TCP를 사용하나요?
HTTP는 순서대로 데이터를 받아서 처리할 수 있어야 하고, 보내진 데이터가 수신자에게 완전히 받아질 수 있어야 페이지를 구성할 수 있기 때문에 전송 간 신뢰성이 필요합니다. 따라서 일관된 순서를 보장할 수 없고 데이터 유실의 위험이 있는 UDP 대신 TCP를 사용합니다.
웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가 - 웹 성능 | MDN
• 그렇다면, 왜 HTTP/3 에서는 UDP를 사용하나요? 위에서 언급한 UDP의 문제가 해결되었나요?
HTTP/3는 기존 TCP의 한계를 극복하기 위해 UDP를 기반으로 설계되었습니다. TCP는 혼잡 제어로 인해 패킷 전송량이 제한되어 현대의 대용량 데이터 전송에 비효율적이었습니다. HTTP/3는 UDP를 사용하되, 애플리케이션 계층의 QUIC 프로토콜을 통해 데이터를 제어합니다. 특히 QUIC의 멀티 스트림 방식을 통해 패킷 손실이 발생해도 다른 스트림에 영향을 주지 않고 독립적으로 처리할 수 있어, TCP의 단일 스트림 방식보다 효율적인 데이터 전송이 가능합니다.
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
• 그런데, 브라우저는 어떤 서버가 TCP를 쓰는지 UDP를 쓰는지 어떻게 알 수 있나요?
브라우저에서 개발자 도구의 네트워크 탭을 보면 각 요청에서 사용된 프로토콜의 이름이 쓰여있는데, 거기서 HTTP/1, HTTP/2로 되어 있는 것은 TCP를 사용할 것이고 HTTP/3으로 되어 있는 것은 UDP를 사용하고 있다고 유추할 수 있을 거 같습니다.
• 본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?
저라면, 실시간 메시지 소통이나 금융 거래 같이 데이터의 무결성이 보장되어야 하는 경우에는 TCP를 사용할 것이고 동영상 스트리밍 서비스처럼, 대용량으로 데이터를 보내야 하고 설사 데이터의 유실이 발생할 수 있어도 그것이 사용자에게 크게 불편함이 없는 수준으로 보일 수 있는 곳에는 UDP를 사용할 거 같습니다.