Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경

지난 글에서 살펴 본,

이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인
; https://www.sysnet.pe.kr/2/0/12521

Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경
; https://www.sysnet.pe.kr/2/0/12527

몇몇 실습을 윈도우 환경에서도 해보겠습니다. 우선 MTU 값은 netsh 명령어를 이용해 확인할 수 있습니다.

C:\Users\kevin> netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
  6          25        1500  disconnected  Local Area Connection
 15          10        1500  connected     Ethernet 3


C:\Users\kevin> netsh interface ipv4 show interfaces 15

Interface Ethernet 3 Parameters
----------------------------------------------
IfLuid                             : ethernet_32774
IfIndex                            : 15
State                              : connected
Metric                             : 10
Link MTU                           : 1500 bytes
Reachable Time                     : 32000 ms
Base Reachable Time                : 30000 ms
Retransmission Interval            : 1000 ms
DAD Transmits                      : 3
Site Prefix Length                 : 64
Site Id                            : 1
Forwarding                         : disabled
Advertising                        : disabled
Neighbor Discovery                 : enabled
Neighbor Unreachability Detection  : enabled
Router Discovery                   : dhcp
Managed Address Configuration      : enabled
Other Stateful Configuration       : enabled
Weak Host Sends                    : disabled
Weak Host Receives                 : disabled
Use Automatic Metric               : enabled
Ignore Default Routes              : disabled
Advertised Router Lifetime         : 1800 seconds
Advertise Default Route            : disabled
Current Hop Limit                  : 0
Force ARPND Wake up patterns       : disabled
Directed MAC Wake up patterns      : disabled
ECN capability                     : application

IP MTU 값이 1500이므로, IP Header == 20, TCP Header == 20인 일반적인 상황이라면 MSS는 1460이 될 것입니다. 실제로 ping 테스트를 (리눅스와는 옵션을 약간 다르게 조정해서) 이렇게 실행할 수 있습니다.

C:\temp> ping www.microsoft.com -l 1473 -f -n 1

Pinging e13678.dscb.akamaiedge.net [23.212.13.232] with 1473 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 23.212.13.232:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

C:\temp> ping www.microsoft.com -l 1472 -f -n 1

Pinging e13678.dscb.akamaiedge.net [23.212.13.232] with 1472 bytes of data:
Reply from 23.212.13.232: bytes=1472 time=4ms TTL=56

Ping statistics for 23.212.13.232:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 4ms, Average = 4ms

보다시피 리눅스에서와 동일하게 ICMP 8바이트를 제외한 1472 바이트가 하나의 패킷에 전달되는 것을 확인할 수 있습니다.




지난 글의 클라이언트/서버 C# 코드를 이번에는 Azure VM(Windows Server 2016)을 서버로, 물리 PC에 설치한 Windows 10을 클라이언트로 테스트하면 연결 시 다음과 같은 3-way handshake를 확인할 수 있습니다.

[...clnt_ip...]  [...azure_svr_ip..]  TCP 66  2406 → 15000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
[...azure_svr_ip..]  [...clnt_ip...]  TCP 66  15000 → 2406 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1
[...clnt_ip...]  [...azure_svr_ip..]  TCP 54  2406 → 15000 [ACK] Seq=1 Ack=1 Win=263424 Len=0

보는 바와 같이 클라이언트에서 서버로 전송할 때는 MSS=1460이고, 서버에서 클라이언트로 보낼 때는 1440이라고 나옵니다. 서버가 왜 1440을 보냈는지 이유는 알 수 없으나, 어쨌든 이렇게 되면 협상에 따라 MSS=1440으로 결정됩니다.

참고로, IPv6의 경우 IP 헤더가 40바이트이기 때문에 1460으로 나올 수 있습니다. 그 외에, IP-in-IP 터널링에서도 발생할 수도 있고, 혹은 options가 20바이트를 점유하는 경우에도 발생할 수 있습니다.




그런데, 재미있는 점이 하나 있습니다. 리눅스 환경에서는 MSS 크기에 맞게 서버로 패킷이 전송되는 반면, 윈도우의 경우에는 MSS 크기를 무시하고 전송한다는 점입니다. 가령, 리눅스에서 12,960 바이트를 전송하면 다음과 같이 정확히 9개의 패킷(1448 * 8 + 1376)으로 나눠 전달이 되는 것을 확인할 수 있습니다.

"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=1 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=1449 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=2897 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=4345 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [PSH, ACK] Seq=5793 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=7241 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=8689 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1514","32990  >  15000 [ACK] Seq=10137 Ack=1 Win=64256 Len=1448 TSval=3494193047 TSecr=1743410262"
"..clnt_ip...","...serverip...","TCP","1442","32990  >  15000 [PSH, ACK] Seq=11585 Ack=1 Win=64256 Len=1376 TSval=3494193047 TSecr=1743410262"
"...serverip...","..clnt_ip...","TCP","66","15000  >  32990 [ACK] Seq=1 Ack=7241 Win=56576 Len=0 TSval=1743507109 TSecr=3494193047"
"...serverip...","..clnt_ip...","TCP","66","15000  >  32990 [ACK] Seq=1 Ack=12961 Win=56576 Len=0 TSval=1743507109 TSecr=3494193047"

반면, 아래는 Window 10 Client에서 Windows Server 2016 Azure VM Server에 12,960 바이트를 send한 경우인데,

..client_ip...  ..server_ip..   TCP 7254    31894 → 15000 [ACK] Seq=1 Ack=1 Win=263424 Len=7200
..server_ip..  ..client_ip...  TCP 60  15000 → 31894 [ACK] Seq=1 Ack=2881 Win=262656 Len=0
..server_ip..  ..client_ip...  TCP 60  15000 → 31894 [ACK] Seq=1 Ack=5761 Win=262656 Len=0
..client_ip...  ..server_ip..   TCP 5814    31894 → 15000 [PSH, ACK] Seq=7201 Ack=1 Win=263424 Len=5760
..server_ip..  ..client_ip...  TCP 60  15000 → 31894 [ACK] Seq=1 Ack=12961 Win=262656 Len=0

2개의 패킷으로만 나눠 가고 있습니다. (패킷 1개에 가기도 합니다.) 이러한 차이점이 서버와의 협상 차이에서 오는 것은 아닌 것 같습니다. 왜냐하면 리눅스 때와 같이 Oracle Cloud의 Linux VM에 12,960 바이트를 보내도,

..client_ip...  ...serverip...  TCP 13014   31905 → 15000 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=12960
...serverip...  ..client_ip...  TCP 60  15000 → 31905 [ACK] Seq=1 Ack=7301 Win=56576 Len=0
...serverip...  ..client_ip...  TCP 60  15000 → 31905 [ACK] Seq=1 Ack=12961 Win=56576 Len=0

1개의 패킷으로만 처리하고 있으니 최대 크기가 9000의 Jumbo Frame으로도 설명이 안 됩니다. (사실, 애당초 연결 시 결정되는 MSS 값은 1440이라 Jumbo Frame과도 연관이 없습니다.)

참... 이걸 뭐라고 해석해야 할지 모르겠군요. 관련 문서를 찾아 보면 다음과 같은 설명이 있습니다.

What is MSS (maximum segment size)?
; https://www.cloudflare.com/learning/network-layer/what-is-mss/

Essentially, the MSS is equal to MTU minus the size of a TCP header and an IP header:

MTU - (TCP header + IP header) = MSS

One of the key differences between MTU and MSS is that if a packet exceeds a device's MTU, it is broken up into smaller pieces, or "fragmented." In contrast, if a packet exceeds the MSS, it is dropped and not delivered.


혹시 윈도우 버전의 Wireshark에 버그가 있는 걸까요? 그렇다 해도 저런 식으로 버그가 발생하는 것은 쉽지 않을 듯 싶은데요. ^^; 갈수록 더 미궁으로 빠지는군요. (이와 관련한 네트워크 전문가가 계시다면 덧글 부탁드립니다. ^^) (2021-02-09 업데이트: 이것의 원인은 "Large Send Offload" 때문입니다.)




(2021-02-03 업데이트) 위의 결과를 설명할 수 있는 한 가지 가정이라면, Wireshark의 device driver가 Network 레이어의 상단에 위치해서 저런 식의 출력이 되지 않을까 싶습니다. 가령, 연결만 하고 대상 서버의 VM을 paused 상태로 바꾼 다음 send를 시도하면 다음과 같이 출력되는 것을 확인할 수 있습니다.

...[생략]...
3713    42.664245   ..client_ip...  ..server_ip...  TCP 14654   2436 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=14600
3731    42.972303   ..client_ip...  ..server_ip...  TCP 1514    [TCP Retransmission] 2436 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=1460
3774    43.580628   ..client_ip...  ..server_ip...  TCP 1514    [TCP Retransmission] 2436 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=1460
3874    44.784230   ..client_ip...  ..server_ip...  TCP 1514    [TCP Retransmission] 2436 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=1460
4074    47.194383   ..client_ip...  ..server_ip...  TCP 1514    [TCP Retransmission] 2436 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=1460
4493    51.998457   ..client_ip...  ..server_ip...  TCP 1514    [TCP Retransmission] 2436 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=1460
...[생략]...

저렇게 나오는 것을 보면, 14654라고 뜨긴 했지만 내부적으로는 1514로 쪼개 네트워크에 싣는 것으로 예측됩니다. (아무튼... 가정입니다. ^^)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 6/27/2021

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12640정성태5/13/2021666오류 유형: 716. RDP 연결 - Because of a protocol error (code: 0x112f), the remote session will be disconnected. [1]
12639정성태5/12/2021457오류 유형: 715. Arduino: Open Serial Monitor - The module '...\detection.node' was compiled against a different Node.js version using NODE_MODULE_VERSION
12638정성태5/12/2021506사물인터넷: 63. NodeMCU v1 ESP8266 - 펌웨어 내 파일 시스템(SPIFFS, LittleFS) 및 EEPROM 활용
12637정성태5/10/2021500사물인터넷: 62. NodeMCU v1 ESP8266 보드의 A0 핀에 다중 아날로그 센서 연결 [1]
12636정성태5/10/2021569사물인터넷: 61. NodeMCU v1 ESP8266 보드의 A0 핀 사용법 - FSR-402 아날로그 압력 센서 연동파일 다운로드1
12635정성태5/9/2021454기타: 81. OpenTabletDriver를 (관리자 권한으로 실행하지 않고도) 관리자 권한의 프로그램에서 동작하게 만드는 방법
12634정성태5/9/2021531개발 환경 구성: 572. .NET에서의 신뢰도 등급 조정 - 외부 Manifest 파일을 두는 방법파일 다운로드1
12633정성태5/7/2021523개발 환경 구성: 571. UAC - 관리자 권한 없이 UIPI 제약을 없애는 방법
12632정성태5/7/2021575기타: 80. (WACOM도 지원하는) Tablet 공통 디바이스 드라이버 - OpenTabletDriver
12631정성태5/5/2021525사물인터넷: 60. ThingSpeak 사물인터넷 플랫폼에 ESP8266 NodeMCU v1 + 조도 센서 장비 연동파일 다운로드1
12630정성태5/5/2021570사물인터넷: 59. NodeMCU v1 ESP8266 보드의 A0 핀 사용법 - CdS Cell(GL3526) 조도 센서 연동파일 다운로드1
12629정성태5/5/2021715.NET Framework: 1057. C# - CoAP 서버 및 클라이언트 제작 (UDP 소켓 통신)파일 다운로드1
12628정성태5/4/2021506Linux: 39. Eclipse 원격 디버깅 - Cannot run program "gdb": Launching failed
12627정성태5/4/2021527Linux: 38. 라즈베리 파이 제로 용 프로그램 개발을 위한 Eclipse C/C++ 윈도우 환경 설정
12626정성태5/3/2021525.NET Framework: 1056. C# - Thread.Suspend 호출 시 응용 프로그램 hang 현상 (2)파일 다운로드1
12625정성태5/3/2021604오류 유형: 714. error CS5001: Program does not contain a static 'Main' method suitable for an entry point
12624정성태5/2/2021761.NET Framework: 1055. C# - struct/class가 스택/힙에 할당되는 사례 정리 [6]파일 다운로드1
12623정성태5/2/2021571.NET Framework: 1054. C# 9 최상위 문에 STAThread 사용파일 다운로드1
12622정성태5/2/2021419오류 유형: 713. XSD 파일을 포함한 프로젝트 - The type or namespace name 'TypedTableBase<>' does not exist in the namespace 'System.Data'
12621정성태5/1/2021763.NET Framework: 1053. C# - 특정 레지스트리 변경 시 알림을 받는 방법파일 다운로드1
12620정성태4/29/2021988.NET Framework: 1052. C# - 왜 구조체는 16 바이트의 크기가 적합한가? [1]파일 다운로드1
12619정성태4/28/2021866.NET Framework: 1051. C# - 구조체의 크기가 16바이트가 넘어가면 힙에 할당된다? [1]파일 다운로드1
12618정성태4/27/2021561사물인터넷: 58. NodeMCU v1 ESP8266 CP2102 Module을 이용한 WiFi UDP 통신파일 다운로드1
12617정성태4/26/2021506.NET Framework: 1050. C# - ETW EventListener의 Keywords별 EventId에 따른 필터링 방법파일 다운로드1
12616정성태4/26/2021509.NET Framework: 1049. C# - ETW EventListener를 상속받았을 때 초기화 순서파일 다운로드1
12615정성태4/26/2021396오류 유형: 712. Microsoft Live 로그인 - 계정을 선택하는(Pick an account) 화면에서 진행이 안 되는 문제
1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...