- small packet (request/response workload): short timeout
iPhone의 TCP rexmit timout은 1, 1, 3, 6, ... 이렇게 되니까 오늘 세미나 내용에서도 나왔던
sleep -> connected state로 가는 데 3초 정도이라면 1+1+3 초 timeout에 성공하게 되고요, 5초입니다. short timeout을 잘 define해야 하는데요.
Android는 TCP rexmit TO이 3,3,6,9... 이기에 3+3 인 6초에 성공하게 됩니다.
여기에 실제 RTT 200-500ms 를 더하면 7-8초는 기본 mobile timeout이 되어야 한다로 정리될 것 같네요.
- Try to use underlying TCP socket instead of HTTP: HTTP layer가 기존의 TCP
session을 재 사용하기 때문에.
이건 2가지 상반되는 이야기기 있는데, socket reuse하면 congestion window가 full open되어
있기에
bandwidth sensitive 한 workload에 좋은 반면에 문제가 있는 TCP session은 다시 맺는 게 좋을 것
같다인데
이것도 위의 sleep -> connected state의 시차 때문에 생기는 illusion인 것 같네요. 6초
timeout에 걸리는
connection이 다시 열면 바로 연결되겠죠.
- small packet (request/response workload): short timeout
iPhone의 TCP rexmit timout은 1, 1, 3, 6, ... 이렇게 되니까 오늘 세미나 내용에서도 나왔던
sleep -> connected state로 가는 데 3초 정도이라면 1+1+3 초 timeout에 성공하게 되고요,
5초입니다. short timeout을 잘 define해야 하는데요.
Android는 TCP rexmit TO이 3,3,6,9... 이기에 3+3 인 6초에 성공하게 됩니다.
여기에 실제 RTT 200-500ms 를 더하면 7-8초는 기본 mobile timeout이 되어야 한다로 정리될 것 같네요.
- Try to use underlying TCP socket instead of HTTP: HTTP layer가 기존의 TCP session을 재 사용하기 때문에.
이건 2가지 상반되는 이야기기 있는데, socket reuse하면 congestion window가 full open되어 있기에
bandwidth sensitive 한 workload에 좋은 반면에 문제가 있는 TCP session은 다시 맺는 게 좋을 것 같다인데
이것도 위의 sleep -> connected state의 시차 때문에 생기는 illusion인 것 같네요. 6초 timeout에 걸리는
connection이 다시 열면 바로 연결되겠죠.