학부 네트워크 강의에서 3-way, 4-way handshake를 접하셨을겁니다. 기억을 더듬자면 SYN/SYNACK/ACK, FIN/ACK/FIN/ACK 라는 상태 이동 행위들이 있고 상태 중에는 CLOSE_WAIT, TIME_WAIT, FIN_WAIT 과 같은 상태가 있습니다. 이 중 CLOSING은 상대와 내 컴퓨터가 서로 동시에 FIN 패킷을 보낼때 전환되는 상태입니다.
그림. TCP flow chart
예시를 들기 위해 2대의 컴퓨터를 내 컴퓨터와 상대 컴퓨터라고 정의하겠습니다. flow chart를 보면 밑에 "CLOSING" 단계가 있습니다. CLOSING은 내 컴퓨터가 세션을 끊으려고 FIN 패킷을 보냈는데 상대 컴퓨터도 동시에 FIN 패킷을 보낸 경우입니다. 일반적인 경우에는 서로 ACK을 보내기 때문에 자연스럽게 "TIME_WAIT" 상태로 넘어가지만, TLSv1.2 연결을 맺는 경우에는 이야기가 다릅니다
TLSv1.2는 내 컴퓨터와 상대 컴퓨터가 세션을 맺고 서로 필요한 데이터를 주고 받습니다. 여기까지는 일반적인 경우에 같은데, TLSv1.2를 세션에서는 서로 더 이상 주고받을 패킷이 없는 경우에 "난 완료했어"라는 패킷을 추가로 보냅니다. wireshark로 해당 패킷을 보면 다음과 같은 형태로 나타납니다
Transport Layer Security
TLSv1.2 Record Layer: Encrypted Alert
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 26
Alert Message: Encrypted Alert
내 컴퓨터와 상대 컴퓨터가 위 패킷을 서로 주고받게 되면 FIN 패킷을 보냅니다
문제는 여기서부턴데, 일부 클라이언트의 경우 TIME_WAIT을 하지 않고 세션을 강제로 끊습니다. 어차피 끊을 세션이고 서로 주고받을 데이터가 더 없다는 것도 확인했는데 TIME_WAIT할 필요가 없는 것입니다. 내 컴퓨터나 상대 컴퓨터가 CLOSING 상태로 간 경우에는 TIME_WAIT하는 시간과 같은 시간으로 기다렸다가 자연스럽게 소켓을 날리지만 서버가 무수히 많은 소켓을 열 경우에는 문제가 될 수 있습니다. C10K 문제같은 상황이 벌어질 수 있는 것이죠
다행히 운영 중인 서버는 포트를 그정도로 많이 필요로 하지 않아 문제가 없었지만 혹시 이로 인해 문제가 생긴다면 다음 글을 참고할 수 있을 것 같습니다 (링크)
