TCP Timestamps 꼭 써야하나?

TCP Timestamps 때문에 힘들었던 썰

 

TCP Timestamps 쓰면 TCP 성능면에서 유리한데 왜 안 써? 하시는 분들 많으실 겁니다.

 

아래 트러블 슈팅 썰 한번 보시고 환경에 맞게 판단하시면 될 거 같습니다.

 

○ 발단 그리고 현상

    어느 날 서버 B에서 서비스 S가 호출되지 않는다.

    동일한 환경의 서버 A는 호출이 잘 된다.

    사용자들은 영향이 없다.

 

 

참 이상하지 않는가... 방화벽 문제인 줄 알았는데 아니다.

 

○ 우연한 발견

Divide and Conquer를 위해 여러 정보를 수집 중 특이점이 발견되었다.

IOS를 사용하는 Catalyst 시리즈에서는 잘 되는데 NX-OS 사용하는 Nexus시리즈에서는 반응이 없다? 아니 왜?

패킷을 까 보니 Catalyst에서 출발한 패킷은 tsval이 없고 Nexus에서 출발한 패킷은 tsval이 있다.

 

아니 그러면 서버 A는 어떤데?

   희한하게 서버 A와 서버 B 모두 tsval이 있다.

 

그럼 이게 문제라고 볼 수 있는가?

   일단 적어도 신규 세션(3 way handshake)에 대해서는 그렇게 동작하니 공통점으로 규정할까 했다.

 

○ 일단 찾아보자

구글 신에게 no syn ack after syn이라고 물어보니 초반부터 느낌 좋은 게 걸린다

tcp timestamps를 끄면 해결된다는 답변이 가장 높은 점수를 얻었다.

하지만 paws가 동작하기 않기에 끌 때 주의가 필요하다고 한다. (TCP 성능이 떨어짐?)

그런데... 어차피 윈도우 클라이언트는 timestamps를 사용하지 않았고 성능에 대해 이슈가 없었다.

그래서 서버 B에서 timestamps를 끈다고 한들 성능에 영향을 주는 부분이 적을 거 같다고 생각했다.

 

○ 그럼 바꿔보자

서버 B의 커널 값 조절 (net.ipv4.tcp_timestamps=0)을 했더니 귀신같이 접속된다.

 

 

○ 결론

TCP Timestamps를 사용할지 말지는 운영 환경에 따라 다른 거 같다.

나라면... 대외 서비스 서버에서는 사용하지 않을 것이며 내부 쪽은 디폴트 값 쓰다가 이슈 발생하면 그때 tcp timestamps 값 확인해보고 끄던지 할 것 같다.

 

TIME_WAIT가 무서워서 tcp_tw_reuse를 써야 한다?

reuse 역시 NAT가 엮이면 문제를 일으킬 소지가 다분하다.

대외 서비스는 TIME_WAIT가 오래 지속되지 않게 프로그래밍하는 게 베스트라고 생각한다.

 

 

 

 

○ 참고 할만한 페이지들

 

TCP Timestamps에 보안상 문제가 있다고 하니 추가적 명분도 있었다.

NVD - CVE-2006-6893 (nist.gov)

NVD - CVE-2006-6893

 

 

 

 

그리고 지금 와서 얘기하지만 아래 문서도 있다.

Linux에서 TCP 타임스탬프 응답을 사용하지 않도록 설정 (vmware.com)

 

 

 

 

아래는 문서는 끄는 게 좋은지 켜는 게 좋은지 디폴트 값은 무엇인지 알려주지는 않네.

Optimizing RHEL 8 for Real Time for low latency operation Red Hat Enterprise Linux for Real Time 8 | Red Hat Customer Portal

Optimizing RHEL 8 for Real Time for low latency operation Red Hat Enterprise Linux for Real Time 8 | Red Hat Customer Portal