8: Timestamps
8: 타임 스탬프(시간 도장)
This option carries
two four-byte timestamp fields. The
Timestamp Value field (TSval) contains the current value of the timestamp clock
of the TCP sending the option. The Timestamp
Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header;
if it is valid, it echoes a timestamp value that was sent by the remote TCP in
the TSval field of a Timestamps option.
When TSecr is not valid, its value must be zero. The TSecr value will generally be from the
most recent Timestamp option that was received; however, there are exceptions
that are explained below. A TCP may send
the Timestamps option (TSopt) in an initial segment (i.e., a segment containing
a SYN bit and no ACK bit), and it may send a TSopt in other segments only if it
received a TSopt in the initial segment for the connection (see RFC 1323 [7]).
Timestamps are quite commonly used. If
timestamp options are exchanged in the connection set-up phase, then they are
expected to appear on all subsequent segments.
If this exchange does not happen, then they will not appear for the
remainder of the flow.
이 옵션은 2개의 4바이트 타임스탬프 영역을 전송합니다. 타임스탬프 값 영역(TSval)은 TCP 가 옵션을 전송하는 현재 값의 타임스탬프 시각의 가지고 있습니다. 타임스탬프
에코 응답 영역(TScr)은 단지 ACK 비트가 TCP 헤더에 존재할 때만 유효합니다. 유효하다면 이 값은 원격지 TCP 의 타임스탬프 옵션 영역의 TSVal 값이 에코(메아리) 되어 보내집니다. 유효하지
않다면 이 값은 0이 되어야 합니다. TSerc 값은 일반적으로
가장 최근에 받아진 타임스탬프 옵션 값이 되어야 합니다. 그 이유는 추후에 설명하겠습니다. TCP 는 초기 세그먼트에서 타임스탬프 옵션을 보낼 수 있습니다. (예. SYN 비트와 ACK 비트가 없는 세그먼트) 그리고 TSopt 값은 처음 연결에서 보낸 경우에만 다른 세그먼트에
보낼 수 있습니다. (RFC 1323) 타임스탬프는 자주 공통적으로 사용됩니다. 만약 타임스탬프 옵션이 연결 설정 단계에서 교환되었으면, 그들은
연속적인 세그먼트 상에서 나타나는 것을 예상할 수 있습니다. 만약에 교환이 일어나지 않는다면, 그들은 나머지 흐름에서도 나타나지 않을 것입니다.
Because the value
being carried is a timestamp, it is logical to expect that the entire value
need not be carried. There is no obvious
pattern of increments that might be expected, however.
하나의 타임스탬프를 가지고 오기
때문에, 전체 값에 계속 가지고 다닐 필요가 없습니다. 하지만, 예상할 수 있는 확실한 패턴이나 형태는 존재하지 않습니다.
An important reason
for using the timestamp option is to allow detection of sequence space
wrap-around (Protection Against Wrapped Sequence-number, or PAWS, see RFC 1323
[7]). It is not expected that this is a
serious concern on the links on which TCP header compression would be deployed,
but it is important that the integrity of this option be maintained. This issue is discussed in, for example, RFC
3150 [32]. However, the proposed Eifel algorithm [35] makes use of timestamps, so it is
currently recommended that timestamps be used for cellular-type links [34].
타임스탬프를 쓰는 중요한 이유는 순차적인 랩-어라운드(엇갈려) 공간을 탐지할 수 있게 하기 위해서 입니다 (엇갈린 순차-번호에 대한 보호 또는 PAWS, RFC 1323을 참조 하세요). TCP 헤더가 압축되어
보내어지는 링크에는 그다지 신경 쓸 사항이 아니지만, 이 옵션의 무결성(결함 없음)이 보장되기 위해서는 중요합니다. 이 문제는 예를 들어 RFC 3150 에 명시되어 있습니다. 하지만 이펠 알고리듬(또는 알고리즘)으로 제안된 타임스탬프 생성이 사용되고 있어, 현재 휴대전화-형식의 링크에서(도) 쓰이는
것을 추천하고 있습니다.
With regard to
compression, note that the range of resolutions for the timestamp suggested in
RFC 1323 [7] is quite wide (1ms to 1s per 'tick'). This (along with the perhaps wide variation
in RTT) makes it hard to select a set of encodings that will be optimal in all
cases.
압축에 관해서는 처리 범위가 타임스탬프가
제안된 RFC 1323을 참조 하면 그 범위는 꽤 넓습니다. (1ms에서 1초 당 ‘틱’) 이는 (RTT 의 다양한 변화에 따라 달라집니다.) 모든 경우에서 최적의
상태에서 부호화하기가 쉽지 않다는 걸 알게 해줍니다.
