rfc1337 파라미터에 대해

Linux의 파라미터 튜닝 부분 중에 rfc1337 파라미터 튜닝 부분이 있는데,

국내 대부분의 블로그?나 사이트에서 튜닝에 대한 정보를 반대로 잘못 표시하고 있다.

rfc1337은 TIME_WAIT를 줄이기 위한 파라미터가 아니다.

대부분의 국내 블로그 사이트를 보면 마치 TIME_WAIT을 줄이기 위해 설정하는 것으로 나오는데,

TIME_WAIT상태에서 RST 시그널을 받아 바로 세션을 KILL하는 

TIME_WAIT Assassination을 방지하기 위한 설정이다.

즉, RST시그널이 오더라도 TIME_WAIT을 유지하도록 하는 파라미터이다.

net.ipv4.tcp_rfc1337

From kernel doc:

tcp_rfc1337 - BOOLEAN
	If set, the TCP stack behaves conforming to RFC1337. If unset,
	we are not conforming to RFC, but prevent TCP TIME_WAIT
	assassination.
	Default: 0

So, isn't 0 the safe value? Our wiki says otherwise. -- Lahwaacz (talk) 08:56, 17 September 2013 (UTC)

With setting 0 the system would 'assassinate' a socket in time_wait prematurely upon receiving a RST. While this might sound like a good idea (it frees up a socket quicker), it opens the door for tcp sequence problems/syn replay. Those problems were described in RFC1337 and enabling the setting 1 is one way to deal with them (letting TIME_WAIT packets idle out even if a reset is received, so that the sequence number cannot be reused meanwhile). The wiki is correct in my view. Kernel doc is wrong here - "prevent" should read "enable". --Indigo (talk) 21:12, 17 September 2013 (UTC)

o TCP 시퀀스 번호는 2의 32승 바이트 정도의 수이다.
A.1500(호스트 A, 포트 1500)와 B.2000사이에 연결이 되었다고 가정하면 한 세그먼트 접속은 상실(lost)되고 재전송 된다. 그러나 세그먼트가 정말 상실된건 아니고, 중간 라우터에 보류 중이며, 다시 네트웍 괘도에 올라가게 된다.(이것을 "헤메 는 복사본:wandering duplicate"라고 부른다.) 그러나 패킷이 상실되고 재전송되고 다시 보이게(reappearing) 되는 사이에 접속은 닫혀지고 그래서 다른 연결이 그 같은 호스트의 같은 포트에서 만들어 진다. 이것을 또다른 "실현:incarnation "이라고 부른다. 그러나 새로운 incarnation을 위해 선택된 시퀀스 번호도 이전에 나타났던 헤메는 복사본의 시퀀스 번호와 중복 되게 된다. (이건 정말 가능한 일이다. 주어진 시퀀스 번호 선택 방법에 따라 TCP 에 대한 연결을 만들기 때문이다.) 여러 분이 헤메는 복사본을 새로운 연결의 incarnation에 보내려 한다면 이 방법은 피하라. 이 방법을 피하기 위해 재 설립될 접 속의 incarnation을 TIME_WAIT상태가 끝날 때 까지 허용하지 말라. 비록 TIME_WAIT상태가 "TIME_WAIT암살"이라고 불리우 는 이 두 번째 문제를 완벽히 해결해 주지는 못할 지라도. 자세한건 RFC 1337을 보라.