이 포스트는 널널한 개발자님 강의를 참조하여 작성한 포스트입니다.
TCP '연결'이라는 착각
🙋🏻 Question
'파일 다운로드 중 LAN케이블을 분리했다가 다시 연결하면 어떻게 될까?'
우리가 TCP/IP로 오딘가 연결해서 파일을 다운로드 한다고 하자. 근데 여기서 LAN케이블을 잠깐 빼보자. 그러면 TCP연결은 어떻게 될까? 과연 이 연결은 유지될까? 끊어질까?
우리가 연결을 끊었다는 것은 L4에서의 연결이 끊어졌다는 것이다. 근데 내가 L1수준에서 LAN선을 잠깐 뽑았을 때 결과는 어떻게 될까? 일단 결론부터 보면 TCP 연결은 유지된다. 물론 우리가 LAN선을 얼마동안 길게 뽑아두었는지와 관련이 있을 것이다. 사실, RFC라고 표준문서에 기술되어 있는 부분과 실제 범용OS에서 구현되어 있는 것이 다르다. 그래서 이 부분에 대한 현실적인 판단이 필요한데 그리고 이러한 차이때문에 상단 process를 개발하는 socket 프로그래밍하시는 분들은 연결이 되어있는가에 대해서 지속적으로 검사해야 한다. 그러니까 3-way handshaking이 끝났는데도 연결을 재확인한다. 고급스럽게 이것을 hearbeat를 보낸다고 한다. 즉, heartbeat를 보내 연결이 되었는지를 확인한다. TCP연결을 전화통화로 비유하면 새벽에 내가 고민이 있어서 친구한테 연락을 해서 하소연을 하는데 어느순간 친구가 대답이 없으면 '야? 자냐?'라고 말할것이다. 이것이 heartbeat이다. 그럼 왜 heartbeat를 보낼까? 비유적으로 보면 전화통화가 되었다해도 위의 상황처럼 상대방이 잘 듣는지 모른다. 이것때문에 heartbeat를 보낸다.
결론적으로 우리가 전화가 끊어져도 우리가 끊어진지 모르고 애기하는 것처럼 LAN선이 끊어져도 연결은 유지된다. 정확히는 일정시간동안 유지된다. 그럼 얼마나 오래 유지될까?
- 재전송 타이버의 기본 근사랎은 대략 3초다. 하지만 대부분의 OS들은 1초미만이다.
- 재전송 타이머 만료후에도 확인응답을 받지 못한 경우 세그먼트를 재전송하고 RTO(Retransmission Time-out)값을 2배로 증가한다.
- 예를 들어 1초 > 2초 > 4초 > 8초 > 16초 간격으로 재전송한다.
- 보통 최대 5회 재전송을 시도하고 5회이상 모두 실패할 경우 보통 전송오류를 발생시킨다.
RFC문서를 보면 정말 오랫동안 유지된다고 기술되어 있다. 하지만 범용OS는 그렇지 않고 OS 알아서 끊어버린다. 즉, TCP연결은 착각이다.
클라이언트든 서버든 뭔가 데이터를 보낼때 반대측에서 ACK가 와야하는데 안 오는 경우 재전송을 하는데 그 때 시간이 3초라고 되어있지만 범용 OS는 1초내로 재전송을 한다.
두 호스트간의 거리를 연결할때 RTT로 측정을 하는데 3-way-handshaking 할 때 SRTT값을 계산해서 얼마나 기다릴지 의사결정 할 때 참고하는데 이런것들은 상황마다 다르다.
재전송 타이머의 기본 근사값을 조절하는게 일종의 OS 튜닝이다.
우리가 LAN 케이블을 1초동안 뺏다가 다시 끼면 파일 다운로드는 잠깐 멈추다가 다시 이어서 다운로드를 할 것이다. 즉, 일정시간동안 케이블이 분리되는 경우 이것을 쉽게 '충격'이라고 한다.
충격이 발생했어도 서비스는 원활히 돌아가야만 할 것이다. 예를 들어 IPTV에서 1초동안 데이터가 안 와도 버퍼에다가 넣어둔다. 그래서 버퍼를 두는 이유도 충격완화때문이다.
이런 일이 유선에는 거의 없을수 있겠지만 무선은 자주 일어난다. 우리가 모바일로 지하철에 LTE로 유튜브를 시청하면 역을 지날때마다 중간중간 중계기를 거칠때마다 충격이 발생하는것과 같은데 그래도 우리는 유튜브를 잘 시청이 가능한 것이다.
