본 내용들은 면접 질문 정리에서 작성된 질문과 작성자가 추가로 넣은 질문들을 포함해서 최대한 공식문서를 기반으로 답변을 작성하려고 노력했습니다.
틀린 내용이 있다면 바로 지적해주시면 감사하겠습니다.
• 3-Way Handshake에 대해 설명해 주세요.
3-Way Handshake는 TCP가 상대방과의 연결 과정에서 정상적으로 상대방과 데이터를 주고 받을 수 있는지 확인할 때 사용합니다. 연결 시도를 한 상대가 SYN을 보내면 연결 시도를 수락한 상대가 SYN-ACK을 보내고 다시 그 대답을 받은 상대가 ACK를 보내어 서로가 데이터를 원활히 주고받을 수 있음을 확인합니다. 이러한 절차를 3-Way Handshake라고 합니다.
TCP 핸드셰이크 (TCP handshake) - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN
• ACK, SYN 같은 정보는 어떻게 전달하는 것 일까요?
TCP 헤더에는 Control Flag라고 하는 6개의 비트 필드가 있습니다. 이 중 ACK와 SYN 비트를 통해 제어 정보를 전달하는데, Sequence Number와 Acknowledge Number 필드와 함께 사용됩니다. 예를 들어, SYN과 Sequence Number를 함께 사용하면 전송하려는 데이터의 순서를 표시할 수 있고, ACK와 Acknowledge Number를 함께 사용하면 특정 데이터를 정상적으로 수신했다는 응답을 보낼 수 있습니다.
• ACK만 보내는 경우는 어떠한 경우일까요?
ACK만 보내는 경우는 TCP 연결 유지나, 아니면 상대방의 데이터를 잘 받았다는 신호만 상대방에게 반환해주기 위해 사용됩니다. 또한 수신 버퍼가 비어 데이터를 받을 준비가 되었다는 뜻으로 ACK만 보낼 수도 있습니다.
• 2-Way Handshaking 를 하지않는 이유에 대해 설명해 주세요.
2-Way Handshaking 방식으로는 상호 데이터 전송이 가능한 상태를 보장할 수 없기 때문입니다. 2-Way Handshaking을 사용하게 되면 먼저 데이터를 보낸 쪽만 데이터가 정상적으로 보내질 수 있다는 것을 인지할 수 있으므로 상대방 쪽에서의 전송이 원활하게 잘 되었는지 상대방은 알 수가 없습니다. 때문에 2-Way 대신 3-Way Handshaking을 사용하여 전송을 확인하고 Sequence Number를 동기화(여기서의 동기화는 같은 값을 가지게 하는 것을 말하는 것이 아닙니다. 서로의 상태를 업데이트 한다는 뜻입니다.)합니다.
• 두 호스트가 동시에 연결을 시도하면, 연결이 가능한가요? 가능하다면 어떻게 통신 연결을 수행하나요?
두 호스트가 동시에 연결을 시도할 경우에도 연결이 가능합니다. 하지만 이때는 양쪽 호스트 중 가장 나중에 SYN 응답이 받아진 연결을 주축으로 연결을 수립하게 됩니다. 이는 오래된 중복 연결을 방지하여 half-open 상태를 방지하기 위함입니다.
RFC 793: Transmission Control Protocol
• SYN Flooding 에 대해 설명해 주세요.
SYN Flooding이랑 일종의 Dos 공격으로 악의적인 사용자가 3-way Handshaking 과정 중 ACK을 제외한 2-way Handshaking 과정까지만 진행하고 연결을 끊는 방식의 공격을 의미합니다. 이 공격을 통해 서버는 ACK을 응답받을 때까지 악의적인 사용자와의 연결을 유지하여야 하고, 이러한 악의적인 사용자가 많아지면 많아질 수록 커넥션의 개수가 늘어나기 때문에 서버에 부하가 걸려 정상적인 동작을 할 수 없게 됩니다.
• SYN Flooding 을 막으려면 어떻게 해야 할까요.
방화벽을 사용해 SYN Flooding 공격을 원천 차단하거나 SYN cookies를 사용하는 방법이 있습니다.
• 위 질문과 모순될 수 있지만, 3-Way Handshake의 속도 문제 때문에 이동 수를 줄이는 0-RTT 기법을 많이 적용하고 있습니다. 어떤 방식으로 가능한 걸까요?
이전에 상대방의 호스트와 이미 3-way Handshaking을 해본 적이 있다면 이전 세션에서 사용했던 정보를 사용해서 3-way Handshaking을 진행하지 않고 바로 TLS를 통한 데이터 전송을 할 수 있도록 하는 기법입니다. 이때 클라이언트와 서버는 이전에 통신할 때 사용했던 암호화 키와 세션 정보을 클라이언트에 남겨놓아야 해당 0-RTT 기법을 사용할 수 있습니다. 그러나 해당 기법은 누군가에게 0-RTT 요청이 인터셉트 될 수 있다면, 가로챈 사용자도 다른 세션을 활용해 진짜 클라이언트처럼 상대방 호스트와 통신을 할 수 있기에 통신이 안전하지 않게 된다는 위험이 있습니다.
• 4-Way Handshake에 대해 설명해 주세요.
4-Way Handshake는 연결자가 상대방과의 연결을 종료하고 싶을 때 안전하게 통신을 종료하기 위해서 사용되는 매커니즘입니다. 연결자는 FIN 비트를 활성화 한 상태로 보내고 상대방의 응답을 기다립니다. 상대방은 연결자의 FIN 비트를 정상적으로 받았다면 ACK로 화답하고 추가적으로 연결자에게 보낼 데이터가 더 없는지 확인합니다. 보낼 데이터가 있다면 보낸 다음 FIN + ACK를 연결자에게 보냅니다. 상대방에게 FIN+ACK를 받은 연결자는 다시 ACK를 상대방에게 전달함과 동시에 통신을 종료합니다. 그리고 이후 ACK를 받은 상대방도 통신을 종료하게 됩니다.
• 패킷이 4-way handshake 목적인지 어떻게 파악할 수 있을까요?
TCP 데이터에 Flag bit의 FIN 비트가 1인지의 유무에 따라 해당 패킷이 4-way handshake 목적을 가지고 있는 패킷인지 알 수 있습니다.
• 빨리 끊어야 할 경우엔, (즉, 4-way Handshake를 할 여유가 없다면) 어떻게 종료할 수 있을까요?
양쪽에서 서로에게 FIN 비트와 함께 연결 종료 의사를 밝히게 되면, 기존의 4-way handshake보다 더 빠르게 연결 종료를 확인하게 되고 동시에 연결을 종료할 수 있습니다. 이를 Simultaneous Close라고도 합니다.
RFC 793: Transmission Control Protocol
• 4-Way Handshake 과정에서 중간에 한쪽 네트워크가 강제로 종료된다면, 반대쪽은 이를 어떻게 인식할 수 있을까요?
Timeout을 통해서 한쪽 네트워크의 강제 종료를 식별합니다. 4-way Handshake 상태에서 Time wait 상태가 오래 지속된다면, 상대방의 네트워크가 강제로 종료되었다고 판단하고 자체적으로 연결을 종료하게 됩니다.
RFC 793: Transmission Control Protocol
• 왜 종료 후에 바로 끝나지 않고, TIME_WAIT 상태로 대기하는 것 일까요
종료 신호를 보낸 송신 측은 더 이상 보낼 데이터가 없지만, 수신 측은 아직 전송할 데이터가 남아있을 수 있습니다. 따라서 TIME_WAIT 상태를 통해 수신 측의 추가 데이터 전송 가능성을 고려하여 일정 시간 대기한 후 연결을 종료합니다.