wireshark를 이용한 TCP 프로토콜 분석하기 1 (Window Size Scaling)

2022.12.13. 최초 작성

 

 

 

 

 

프로토콜은 어떻게 통신할지를 정해놓은 약속으로 통신규약이라고 한다. 네트워크 프로토콜을 공부할 때는 문서로만 공부하기보다는 가능하면 와이어샤크와 같은 도구를 이용해 프로토콜의 특징을 직접 확인하는 것이 좋다. 백문이 불여일견(百聞不如一見)이다.

 

프로토콜 분석을 위한 패킷이 필요하다. 직접 패킷 캡처해도 되고, 샘플 캡처 파일을 다운 후 분석해도 된다.

 

와이어샤크 위키 페이지에 있는 샘플 캡처 파일을 다운 후 실습하기로 한다.

https://wiki.wireshark.org/SampleCaptures

SampleCaptures

 

 

TCP 샘플 캡처 파일을 2개 제공한다.

첫 번째는 TCP Window Scaling이 사용 가능 하나 일부 패킷에서는 크기조정이 적용되지 않은 파일이다.

두 번째는 파일과 문자열을 전송하는 패킷으로 TCP Window Scaling이 모두 적용된 파일이다.

 

 

[그림1] TCP 샘플 캡처 파일

 

 

위 두 개의 파일을 모두 분석해보고 차이점을 알아보려면 우선 TCP에서 Window의 역할을 알아야 한다.

TCP에 대해 정의되어있는 RFC 793 문서에 보면 TCP Header의 포맷이 아래와 같이 정의되어있다.

 

https://www.rfc-editor.org/rfc/rfc793

RFC 793: Transmission Control Protocol

 

 

[그림2] rfc793  문서에 정의된  TCP Header 의 포맷

 

 

 

Windows는 흐름제어를 위해 사용하는 16비트 필드이다. 65,535 bytes까지 가능하다.

수신자가 한 번에 버퍼링할 수 있는 최대 크기(byte)를 Windows 필드에 넣어 보내면 송신자는 그 크기만큼 수신자의 ACK를 기다리지 않고 데이터를 전송할 수 있다.

 

만약 수신자 측에서 어떠한 이유에 의해서 버퍼에 들어온 데이터를 읽어가지 못하면 Windows Size가 줄어들다가 0이 된다. Windows Size가 0이 되어 더 이상 데이터를 수신할 수 없는 것을 TCP Zero Window라고 한다.

 

 

처음 RFC 793 문서에 정의된 내용에 따르면 Windows Size는 최대 65,535 Bytes까지 가능하다. TCP는 신뢰성 있는 통신을 위해 송신자가 보낸 데이터를 수신자가 받으면 ACK를 전송하도록 설계되어있다.

그러나 인터넷 속도가 빨라지고 인터넷으로 전송할 데이터의 양이 늘어남에 따라 TCP로 한 번에 보내는 데이터의 양이 늘어날 필요성이 생겼다.

 

RFC 1323에서는 이러한 문제를 해결하기 위해 Windows Size 조정이 가능하도록 TCP WINDOW SCALE OPTION을 제공한다.

 

https://www.rfc-editor.org/rfc/rfc1323

RFC 1323: TCP Extensions for High Performance

 

 

TCP Header에 옵션으로 Window Scale이란 값이 추가되었는데 이 값은 2의 지수 승으로 계산된다.

예를 들면 Window Scale 값이 8일 경우 2의 8승으로 256이 되고 여기에 Windows를 곱하여 최종적으로 계산된 Windows Size가 나온다.

 

2 ^ Window Scale x Windows = Calculated Windows Size

 

[그림3] TCP 윈도우 스케일 옵션

 

 

이 내용은 마이크로소프트 Windows Server의 네트워크 문서에도 잘 설명되어 있다.

 

https://learn.microsoft.com/ko-kr/troubleshoot/windows-server/networking/description-tcp-features

Windows TCP 기능에 대한 설명 - Windows Server

 

배율 인수	크기조정 값	초기 창	창 크기조정
0	1	65535 이하	65535 이하
1	2	65535	131,070
2	4	65535	262,140
3	8	65535	524,280
4	16	65535	1,048,560
5	32	65535	2,097,120
6	64	65535	4,194,240
7	128	65535	8,388,480
8	256	65535	16,776,960
9	512	65535	33,553,920
10	1024	65535	67,107,840
11	2048	65535	134,215,680
12	4096	65535	268,431,360
13	8192	65535	536,862,720
14	16384	65535	1,073,725,440

 

 

첫 번째 200722_win_scale_examples_anon.pcapng 파일을 분석해보면 일부 패킷에서 TCP Window Scaling이 사용 가능 하나 일부 패킷에서는 크기조정이 적용되지 않은 것을 확인할 수 있다.

 

 

[그림4] window size scaling 사용 안함

 

 

 

[그림5] window size scaling 알수없음

 

 

 

두 번째 200722_tcp_anon.pcapng 파일을 분석해보면 Window Size Scaling이 모두 정상적으로 적용된 것을 알 수 있다.

 

[그림6] window size scaling 정상

 

 

 

 

[결론] 

과거에 처음 TCP가 만들어졌을 때는 인터넷으로 전송할 데이터의 양이 적었고 속도도 느렸다. 하지만 시간이 지나며 인터넷으로 전송할 데이터의 양이 늘어나고 인터넷 속도도 빨라져서 문제가 생겼다.

TCP가 가지고 있던 Window 값의 크기가 16bit여서 65,535 Bytes까지의 한계가 생긴 것이다.

 

문제를 해결하기 위해 옵션에 Window Scale이란 값이 추가하고 기존의 Window 값과 계산하여 최종적으로 Windows Size 값을 정하도록 프로토콜을 수정하였다. 그리고 지금은 Window Scaling 옵션이 선택이 아닌 필수가 되었다.

 

이처럼 프로토콜은 처음 만들어졌을 때 완벽하지 않고 필요하여 나중에 변경된다. 한번 공부해 놓은 것이 평생 가는 지식이 될 수 없다는 것이다. 그러므로 단순히 외우는 것보다는 개념과 원리를 알고 필요할 때 원하는 것을 찾아서 분석할 수 있는 능력이 더 중요하다.

 

만약 Window Scaling 옵션이 적용되어 있지 않다면 인터넷의 속도가 느려질 수 있다.

네트워크 장비나 소프트웨어에서 어떠한 오류 때문에 Window Scaling 옵션이 적용되지 않는다면 65,535 Bytes로 패킷의 크기가 제한되어 한 번에 전송하는 데이터의 양이 작고, 불필요하게 수신자의 ACK를 확인받아 인터넷 속도가 느려질 수도 있다.

 

 

 

728x90

반응형