MSL(Maximum Segment Lifetime)
만약 TCP 자체를 구현해야 한다면, MSL 값을 반드시 세팅해 주어야 한다.
RFC1122 : 2분.
Berkeley-derived version : 30초.
MSL은 IP Datagram이 Network에 존재할 수 있는 최대시간이다.
original url : https://ko.wikipedia.org/wiki/Time_to_live
TTL(Time To Live) & 홉 리미트(hop limit)
인터넷 프로토콜에서 TTL은 8비트 크기의 필드이다. IPv4 헤더에서 TTL은 20 옥텟 중 8번째 옥텟이며, IPv6 헤더에서는 40 옥텟 중 8번째 옥텟이다. TTL의 최댓값은 단일 옥텟의 최댓값에 해당하는 255이다. 권장되는 초기값은 64이다.[1][2]
TTL값은 IP 데이터그램이 인터넷 시스템 내에서 존재할 수 있는 시간의 상한선으로 볼 수 있다. TTL 필드는 데이터그램의 송신자에 의해 설정되며, 목적지까지의 전송 경로에 있는 모든 라우터들에 의해 그 값이 감소된다. 목적지에 다다르기 전에 TTL 필드의 값이 0이 되면 해당 데이터그램은 폐기되고 ICMP 에러 데이터그램 11 - Time Exceeded가 송신자에게 보내진다. TTL 필드의 목적은 전달되지 못한 데이터그램이 인터넷 시스템 내에서 지속적으로 순환하여 넘쳐나게 되는 상황을 방지하는 데에 있다.
IPv4 환경에서 TTL 값의 단위는 초이며, 이론적으로 이 값은 목적지까지의 경로에서 경유하게 되는 모든 호스트에서 1 이상의 양만큼 감소될 수 있다. 그러나 실제 적용에서 TTL 값은 매 홉(hop)마다 1씩만 감소된다. 이러한 상황을 고려하여, IPv6에서 이 필드의 명칭은 홉 리미트(hop limit)로 변경되었다.
http://www.ktword.co.kr/abbr_view.php?m_temp1=1115
IP 패킷 수명 ㅇ TTL(IPv4) 또는 Hop Limit(IPv6) - IP 패킷 전달에 대한 생존 시간 . 인터넷에서 IP 패킷이 라우팅되며 남아있는(거쳐야할) 라우터의 갯수를 표현하는 수 .. 이는 IP 패킷 헤더 내에 하나의 필도(8 비트)로 포함됨 - 각 라우터는 IP 패킷을 라우팅할 때 마다 TTL의 값을 감소시킴 ㅇ TTL 크기 - 최대값 . TTL 값은 최대 255인 8비트의 홉 한계를 갖음 - 기본값 . IANA에서는 TTL 기본값을 64로 할당하여 제안하고 있으나, 필요시 다른 값도 사용 가능
with hop limit of 255 cannot exist in a network for more than MSL seconds.
: TTL < MSL
The 'lost' state of packet in a network when is below.
1. Router crash
2. link between two routers and shutdowned -> need some seconds or minutes to stabilize / find alternate path.
then, 'Routing Loop' can occur (A router to B router, B router to A router sending so infinitly!)
then the packets blocked.
in the meantime, if the lost packet is TCP segment, and it's state is 'timeout', then retransmits to destination endpoint by alternate path.
if 'Routing Loop' is restored at MSL time later after when losted packet can be transmit, the packet that was in the loop is sent to the destination endpoint.
this packet is called 'Lost Duplicate' or 'Wandering Duplicate'.
There are 2 reasons for the TIME_WAIT state.
1. To implement TCP's full-duplex connection for termination reliably.
2. To expire the old duplicate segments in the network.
첫 번째 이유.
figure 2.5 그림을 보장.
1. Client에서 Server로 보내는 마지막 ACK가 손실된다.
2. Server에서는 MSL시간 동안 기다린 후에도 ACK가 오지 않는다면, FIN을 재전송한다. 이 때, Client는 마지막 ACK를 보내기 위해 TIME_WAIT State를 유지한다.
3. 만약 Client가 보낸 ACK를 또 받지 못한다면, TIME_WAIT State를 끝내게 된다(2MSL 시간이 지나서),
Server는 이제부터 같은 IP로부터의 Connection이 들어온다면 RST(TCP Segment의 다른 형식)로 응답한다. Server는 이제부터 이 사건을 Error로 인식한다.
4. TCP가 양쪽 Data-Flow의 Connection Terminate(Full-Duflex-Close)에 필요한 모든 작업을 완벽히 수행한다면, TCP는 반드시 이 4개의 segment 손실을 다뤄야한다.
두 번째 이유.
A(12.106.32.254::1500) 와 B(206.168.112.219::21)가 Connection되어 있는 상태라 가정한다.
1. Connection이 Close된다. (양 측이 TIME_WAIT 상태가 됨.)
2. 잠시 후 A와 B를 다시 같은 IP/Port로 Connect시킨다.
3. 이것을 Incarnation이라 부른다.
4. TCP는 일정 시간 지난 후 다시 생성된 Connection(Incarnation)에서 이전 연결에서 Close되면서 잔류하던
Old Duplicates를 정상적인 패킷으로 인식하지 않아야 한다.
이것을 해결하기 위해 TCP는 TIME_WAIT State 상태인 Connection에서, Incarnation을 허용하지 않는다.
TIME_WAIT State의 지속 시간이 MSL의 2배인 이유가 있다.
Client에서는 일단 마지막 ACK를 서버로 전송한 후, 2MSL 시간 동안 TIME_WAIT State를 유지하고, Socket을 Close시킨다.
2MSL시간 동안 TIME_WAIT State를 유지하는 이유는,
Server는 Client에게 FIN을 보내면서 MSL 시간동안 Client의 ACK를 기다리게 된다.
MSL은 최고로 늦게 전송되는 시간이기도 하다. 패킷의 유효기간이기 때문에.
1. ACK가 MSL 시간 안에 Server로 전송이 되었다 -> 완벽하게 Close된 상태이다.
2. MSL 시간이 되었는데도 ACK를 Server에서 받지 못했다 -> Server는 다시 Client에게 FIN을 보낸다.
그러면서 다시 MSL시간을 기다린다. 이 때 Client는 자신의 마지막 ACK에 대한 약간의 책임을 지는 것이다.
Client에서 이 FIN을 받으려면 Client는 애초부터 자신이 보낸 ACK 패킷의 MSL 시간과, 이 ACK를 받지 못한 Server로부터 전송되는
FIN 패킷에 대한 MSL시간을 더해서 2MSL을 유지하는 것이다.
거듭 말하지만, Client가 마지막 ACK를 보냈을 때, Server로부터 응답이 온다면 Client가 보낸 ACK가 손실되었다는 뜻이다.
3. 이 과정을 거치고도 Server에서 ACK를 못 받게 되면, Server에서는 Client를 Error로 판단하고,
이제부터 같은 IP로부터의 Connection이 들어온다면 RST(TCP Segment의 다른 형식)로 응답한다.
아마 3번 과정은 Timeout 시간(4~10분)동안 유지되고, 그 이후엔 연결이 종료된 것으로 판단하여 다시 정상적으로 Connection을 받는 것 같다..
책을 좀 더 읽다 보면 더 자세히 알 수 있을 듯 하다..
'Network > Unix Network Programming' 카테고리의 다른 글
[UNP] Transport Layer에 대한 이야기 (0) | 2017.03.22 |
---|---|
[UNP] SCTP Association Establishment and Termination (0) | 2017.03.14 |
[Unix Network Programming] Chapter 2.6 TCP Connection Establishment and Termination (0) | 2017.02.27 |
[Unix Network Programming] Chapter 2.5 SCTP(Stream Control Transmission Protocol) (0) | 2017.02.27 |
[UNP] 2.4 (TCP) Transmission Control Protocol (0) | 2017.02.24 |
[UNP] Chapter 2.3 (UDP) User Datagram Protocol (0) | 2017.02.21 |
[UNP] Chapter 2 The Big Picture - 용어 설명 (0) | 2017.02.21 |
[UNP] Chapter 2 The Transport Layer: TCP, UDP, and SCTP 1 소개 (0) | 2017.02.21 |