일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 커널제거
- 자바스크립트 비동기
- feynman's restaurant
- Readme image
- computer vision
- recommender
- react-cookie
- Hits
- 러스트
- 파인만의 식당문제
- 페이지랭크
- 커널생성
- 딥러닝
- 프라미스
- 머신러닝
- Git
- brew 권한
- 컴퓨터 보안 키분배
- 메세지인증코드
- image restoration
- 파이썬
- 비동기 프로그래밍
- rust
- 인페인팅
- 키분배 알고리즘
- cs231n
- 인공지능
- 협업필터링
- pagerank
- tcp
- Today
- Total
Worth spreading
Why TCP avoids measuring the SampleRTT for retransmitted segments? 본문
Why TCP avoids measuring the SampleRTT for retransmitted segments?
annual 2017. 4. 2. 18:37
Question :
Why do you think TCP avoids measuring the SampleRTT for retransmitted segments?
Answer1 :
The retransmitted segments contain the same data and the same sequence numbers as the previously sent packets. Therefore, for the retransmitted segments, we would expect the same ACK numbers as the previously sent TCP segments. When we receive these particular ACKs from the receiver, we don't really know or care whether they were sent as responses to the retransmitted segments or to the previously sent TCP segment.
Answer2 :
This fails to work if there is a sudden increase in network RTT; if the new RTT is larger than the RTO, then all samples will be discarded!
문제:
재전송된 값들을 SampleRTT 값을 구하는 데 사용하지 않는 이유는?
답1 :
재전송된 값들은 이전에 보낸 패킷과 같은 데이터와 같은 순서번호를 가지고 있다. 따라서 재전송한 값의 ACK 번호는 이전에 보낸 값의 ACK 번호와 같을 것이다. 그렇게 되면 우리가 수신자로부터 ACK를 받았을 때 우리는 그 ACK가 처음 보낸 값에 대한 것인지 재전송한 값에 대한 것인지 알수 없다. 따라서 재전송한 값은 SampleRTT 계산에 포함하지 않는다.
답2 :
만약 정상적으로 전송이 되지 않은 값의 RTT가 매우 클 때, 만약 해당 RTT 값이 RTO 값보다 크다면 모든 샘플 값들은 초기화될 것이 때문에 재전송 값을 포함하지 않는다.
2번 답은 약간 애매한...
'Computer science > Computer Network(컴퓨터 통신)' 카테고리의 다른 글
라우터의 hop 추적하기(traceroute) (0) | 2018.09.18 |
---|---|
TCP flow control의 결함 (0) | 2017.04.04 |
TCP의 fast retransmit (0) | 2017.04.04 |