Network Part가 아닌 Web에 대한 Part를 다룰 예정이므로 자세한 부분은 제외했으며, 이해를 돕기 위한 흐름으로 작성했다.
HTTP 2.0을 이해하기 앞서서 Window size에 대한 사전 이해가 필요하다.
여기서 Window size는 OS가 아니다. TCP Window size는 데이터의 양 또는 버퍼의 크기라고 이해를 하면 쉽다.
Window size
TCP(Transmission Control Protocol, 전송 제어 프로토콜)은 연결 이후 데이터와 패킷의 신뢰성을 보장한다.
데이터의 전달할 수 있는 크기는 Window size이며 16bytes(2^16 = 65536, 0-65535, 65535 bytes)의 크기를 갖는다.
데이터를 전달하는 방법은 아래와 같다.
전달한 패킷의 응답이 올 경우 다음 패킷을 전달할 수 있다.
(Stop and wait)
좀 더 효율적인 방법도 있다. 3-handshake 후 송신측의 window size와 송신한 window size 값을 계산하여 공간이 부족할 경우에는 송신을 중단하고, 수신 공간이 생기면 TCP Header의 Window Field로 송신측에 알린다. (sliding windows)
이를 일반적으로 Flow control, 흐름제어라고 한다.
TCP Stream 23번의 경우 최초의 패킷은 Window size value 값을 64240을 송신측이 전달하고 동일한 값을 수신측이 받았다.
Window size 65535가 아닌 이유는 일반적으로 MTU 1500일 경우 IP Heaer 20bytes와 TCP Headers 20bytes를 제외한 1460 MSS(Maximum segement size, TCP segmenet의 최대 데이터 양)을 갖는다. 일반적인 경우 65535 / 1460 = 44.886... 이므로 기본적인 값으로 44 * 1460 = 64240의 window size를 전달한다.
만약에 window size가 작다면 어떻게 될까? 매우 비효율적일 것이다.
그러면 많이 보내면 효율적일까?
하지만 보낼 수 있는 송신자 의 보낼 수 있는 Resource와 받을 수 있는 수신자 의 받을 수 있는 Resource는 한정적이며 각기 다르므로 고정할 수는 없다.
DoS 공격중에 Slowread가 있다. Slowread Attack은 window size를 고의적으로 작게보내어 리소스를 소모하는 공격이다.
Window scale
이론적으로 위의 학습을 기반으로 계산해보자.
RTT(Round Trip Time)이 20ms, Window size 65535 bytes 일 경우
bps는 bit per second이므로 Bandwidth는 byte * 8 / ms 의 수식으로 계산할 수 있다.
- byte → bit, ms → sec 변환 : 65535 * 8 / 0.02 (sec) = 524280 bit / 0.02 sec
- 0.02 sec → sec 변환 : 524280 * 50 / sec = 26241000 bit / sec
- 단위 변환 : 25599kbps → 24Mbps
고작 처리량이 24Mbps 뿐이 안나온다. 이는 현대의 속도로는 엄청나게 느린 속도이다. 그래서 Window Scale을 사용한다.
Window scale이 8일 경우 2^8 256배율을 갖는다.
고로 높은 속도를 위해서는 Window scale가 필요하다.
