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


MSS를 실제 C# Socket과 Wireshark를 통해 ^^ 확인해 보겠습니다. C# 소스 코드는 테스트 용도이므로 다음과 같이 간단하게 서버와 클라이언트를 구성할 수 있습니다.

// 서버 - Oracle Cloud VM Ubuntu 20.04
using System;
using System.Net;
using System.Net.Sockets;

class Program
{
    static void Main(string[] args)
    {
        Socket server = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        server.Bind(new IPEndPoint(IPAddress.Any, 15000));
        server.Listen(5);

        while (true)
        {
            Console.WriteLine("Accepting...");
            Socket client = server.Accept();

            do
            {
                string text = Console.ReadLine();

                if (string.IsNullOrEmpty(text) == true)
                {
                    break;
                }

                int readLen = int.Parse(text);
                byte[] buf = new byte[readLen];
                readLen = client.Receive(buf, 0, buf.Length, SocketFlags.None);
                Console.WriteLine($"read: {readLen}");
            } while (true);

            client.Close();
        }
    }
}

// 클라이언트 - 물리 머신 Ubuntu 20.04
using System;
using System.Net.Sockets;

unsafe class Program
{
    static void Main(string[] args)
    {
        {
            Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

            client.Connect("...serverip...", 15000);

            while (true)
            {
                string text = Console.ReadLine();

                if (string.IsNullOrEmpty(text) == true)
                {
                    break;
                }

                int sendSize = int.Parse(text);
                byte[] buffer = new byte[sendSize];

                client.Send(buffer, 0, buffer.Length, SocketFlags.None);
            }

            client.Close();
        }
    }
}

하는 일은 매우 간단합니다. 서버는 연결 하나를 받지만 recv를 사용자가 원하는 크기를 지정할 때까지 호출하지 않습니다. 또한 클라이언트 측도 마찬가지로 연결만 해두고 이후 send는 사용자가 원하는 크기를 지정할 때까지 호출하지 않습니다.

이제 서버를 띄워놓고 클라이언트에서 접속할 때 Wireshark로 패킷을 캡처하면 다음과 같은 결과가 나옵니다.

...client_ip...	...svr_ip... TCP 74 32912 → 15000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3363140511 TSecr=0 WS=128
...svr_ip... ...client_ip..  TCP 74 15000 → 32912 [SYN, ACK] Seq=0 Ack=1 Win=62636 Len=0 MSS=8960 SACK_PERM=1 TSval=1612454569 TSecr=3363140511 WS=128
...client_ip...	...svr_ip... TCP 66 32912 → 15000 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3363140514 TSecr=1612454569

보는 바와 같이 클라이언트에서 서버로 전송할 때는 MSS=1460이고, 서버에서 클라이언트로 보낼 때는 8960이라고 나옵니다. 이전에 설명했듯이, 1460은 일반적인 설정의 MSS 값이고, 8960은 Jumbo Frame이 설정된 환경의 값입니다.

어쨌든, 클라이언트는 1460을, 서버는 8960을 보냈으므로,

TCP/IP performance tuning for Azure VMs
; https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning

This setting is agreed to in the TCP three-way handshake when a TCP session is set up between a source and a destination. Both sides send an MSS value, and the lower of the two is used for the TCP connection.


둘 중의 작은 값인 1460이 해당 TCP 통신에서의 MSS 값이 됩니다.




자, 그럼 이제 소스 코드에 작성한 대로 임의의 데이터를 서버로 전송해 볼 텐데요, 우선 협의된 MSS 값보다 1이 큰 데이터를 서버로 보냈을 때의 Wireshark 캡처는 다음과 같이 나옵니다.

..client_ip... ...serverip... TCP 1514    32912 → 15000 [ACK] Seq=1 Ack=1 Win=64256 Len=1448 TSval=3445313658 TSecr=1693752398
..client_ip... ...serverip... TCP 79  32912 → 15000 [PSH, ACK] Seq=1449 Ack=1 Win=64256 Len=13 TSval=3445313658 TSecr=1693752398
...serverip... ..client_ip... TCP 66  15000 → 32912 [ACK] Seq=1 Ack=1462 Win=61184 Len=0 TSval=1694627715 TSecr=3445313658

예상했던 것처럼 2개의 패킷이 서버로 전송되긴 했지만, 크기가 1460이 아닌, 1448로 나와 있습니다. 왜 그런 것일까요? 그 이유는 TCP 헤더가 20바이트가 아닌, TSval, TSecr 정보에 해당하는 12 바이트를 더 점유하고 있기 때문입니다. 실제로 저 상황에서의 TCP 데이터를 보면,

Transmission Control Protocol, Src Port: 15000, Dst Port: 33544, Seq: 1, Ack: 1462, Len: 0
    Source Port: 15000
    Destination Port: 33544
    [Stream index: 3]
    [TCP Segment Len: 0]
    Sequence number: 1    (relative sequence number)
    Sequence number (raw): 2415159352
    [Next sequence number: 1    (relative sequence number)]
    Acknowledgment number: 1462    (relative ack number)
    Acknowledgment number (raw): 2123235886
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (ACK)
    Window size value: 478
    [Calculated window size: 61184]
    [Window size scaling factor: 128]
    Checksum: 0x5672 [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - Timestamps: TSval 1694627715, TSecr 3445313658
            Kind: Time Stamp Option (8)
            Length: 10
            Timestamp value: 1694627715
            Timestamp echo reply: 3445313658
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 49156]
        [The RTT to ACK the segment was: 0.003061175 seconds]
        [iRTT: 0.003105376 seconds]
    [Timestamps]

헤더 크기가 32로 나옵니다. 따라서, IP MTU(1500) - IPHeader(20) - TCPHeader(32) = 1448이 TCP 데이터로 보낼 수 있는 최대 크기가 됩니다. 따라서, 클라이언트에서 1448을 보내도록 다시 테스트를 해보면,

..client_ip...    ...serverip...  TCP 1514    33544 → 15000 [PSH, ACK] Seq=1462 Ack=1 Win=64256 Len=1448 TSval=3445823525 TSecr=1694627715
...serverip...  ..client_ip...    TCP 66  15000 → 33544 [ACK] Seq=1 Ack=2910 Win=59776 Len=0 TSval=1695137582 TSecr=3445823525

정확히 1개의 전송 패킷과, 1개의 ACK 패킷만을 확인할 수 있습니다. (단일 패킷 전송/ACK인 경우 전송 측의 Seq=1462와 Ack 패킷의 Ack=2910의 번호 차이도 1,448만큼 나오는 것이 우연은 아닙니다.)

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 2/2/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)
12540정성태2/17/2021851.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/2021921Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/20211055.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/20211167.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기
12536정성태2/9/20211043개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/2021733개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/2021999개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/2021961개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/2021873개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [1]
12531정성태2/5/2021733개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/20211167개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/2021820개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/2021875개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/2021896개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/2021718개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/2021606개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/2021754개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/2021750개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/2021900개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/20211036개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인
12520정성태1/30/2021634개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/2021754개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/20211682Linux: 37. Ubuntu에 Wireshark 설치
12517정성태1/30/20211324Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/2021831Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/2021934웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...