<div id="readability-page-1" class="page"><div id="root"><div><p>오늘 실험하고 배운 것들을 소소하게 기록해 봅니다. </p>
<h3 id="1-네트워크-프로그래밍">1. 네트워크 프로그래밍</h3>
<ul>
<li>네티에서 FieRegion을 통해 네트워크로 파일 쓰기를 요청하면 최종적으로 sun.nio.ch.SocketDispatcher 클래스에서 native 메서드인 write() 호출이 일어납니다. native write() 메서드는 실제로 쓰기에 성공한 바이트 수를 반환하는데 쓰기 요청한 바이트 수 보다 적을 수 있습니다. 실험 결과 루프백이나 속도가 빠른 로컬 유선 네트워크를 통해 통신할 때는 8MB를 요청하면 대부분 8MB 전체 쓰기에 성공합니다. 그러나 느린 WIFI 통신을 통하면 8MB를 요청하면 대부분 128~256KB 또는 그 이하의 데이터만 실제로 쓰여졌습니다.</li>
<li>여기서 8MB는 네티가 파일 전송에 mapped transfer 방법을 사용할 때 전송 요청할 수 있는 최대 크기를 상수로 고정해 둔 수치입니다. 즉 8MB 보다 큰 수를 전송 요청해도 항상 8MB 이하로 잘라서 요청이 일어납니다.</li>
<li>TCP 전송 버퍼가 64KB 인데 왜 어떻게 native write 메서드 호출에서 한 번에 8MB를 전송하는지 의문이 생겼습니다.</li>
<li>SO_SNDBUF 타입에 대한 setsockopt() 호출을 통해 소켓의 송신 버퍼의 크기를 설정할 수 있습니다. 전송 버퍼의 크기는 전송 윈도우 크기와 반드시 일치할 필요는 없다고 합니다. (<a href="https://learn.microsoft.com/en-us/windows/win32/winsock/sol-socket-socket-options">참고</a>)</li>
<li>리눅스에서 SIOCOUTQ 타입에 대한 ioctl() 호출을 통해 소켓의 송신큐에서 아직 전송되지 않은 데이터 길이를 구할 수 있습니다. (<a href="https://linux.die.net/man/7/tcp">참고</a>)</li>
<li>TCP는 연결 과정(3-way handshake)에 서로의 수신 윈도우 크기를 교환하니다. 이 때 스케일 값을 TCP 헤더 옵션 필드에 전달함으로 TCP 헤더에 수신 윈도우 필드 2바이트로 표현할 수 있는 65535보다 큰 값을 활용할 수 있게 합니다.</li>
<li>그런데 TCP 수신 윈도우 스케일 값이 적용된다고 한 번에 전송되는 데이터의 크기가 커지는 것은 아닙니다. 윈도우 스케일을 통해 윈도우가 커지면 계속 전송할 수 있는 용량이 커지는 것이지 스케일업한 크기 만큼 한 번에 큰 데이터를 전송할 수 있다는 뜻은 아닙니다.네트워크 패킷으로 캡처해서 분석해 보니 상대방의 수신 윈도우에 여유가 있다면 큰 데이터를 1460바이트가 지연없이 계속 보내지는 것을 확인할 수 이었습니다.</li>
</ul>
<h3 id="2-네트워크-패킷-분석-도구">2. 네트워크 패킷 분석 도구</h3>
<ul>
<li>캡처 필터에서 특정 대역을 필터링하는 방법 - tcp portrange 61000-62000</li>
</ul>
<h3 id="3-ftp-프로토콜">3. FTP 프로토콜</h3>
<ul>
<li>FTP는 21번 포트를 제어 포트로 사용하지만, 보안상의 이유로 실제 데이터를 교환하는 포트는 클라이언트와 동적으로 협의하여 결정된다. 오늘 확인해 보니 61000번 대에서 데이터를 교환할 때 마다 다른 포트가 선택되어지는 것을 확인했다.</li>
</ul></div><div><p><a href="/@joosing"><img src="https://velog.velcdn.com/images/joosing/profile/f0237be9-1add-432a-89ec-14bf7c0e937c/image.png" alt="profile"></a></p></div><div><h4>0개의 댓글</h4></div></div></div>

Joo's Work

JooSing

오늘 실험하고 배운 것들을 소소하게 기록해 봅니다. 
1. 네트워크 프로그래밍
네티에서 FieRegion을 통해 네트워크로 파일 쓰기를 요청하면 최종적으로 sun.nio.ch.SocketDispatcher 클래스에서 native 메서드인 write() 호출이 일어납니다. native write() 메서드는 실제로 쓰기에 성공한 바이트 수를 반환하는데 쓰기 요청한 바이트 수 보다 적을 수 있습니다. 실험 결과 루프백이나 속도가 빠른 로컬 유선 네트워크를 통해 통신할 때는 8MB를 요청하면 대부분 8MB 전체 쓰기에 성공합니다. 그러나 느린 WIFI 통신을 통하면 8MB를 요청하면 대부분 128~256KB 또는 그 이하의 데이터만 실제로 쓰여졌습니다.
여기서 8MB는 네티가 파일 전송에 mapped transfer 방법을 사용할 때 전송 요청할 수 있는 최대 크기를 상수로 고정해 둔 수치입니다. 즉 8MB 보다 큰 수를 전송 요청해도 항상 8MB 이하로 잘라서 요청이 일어납니다.
TCP 전송 버퍼가 64KB 인데 왜 어떻게 native write 메서드 호출에서 한 번에 8MB를 전송하는지 의문이 생겼습니다.
SO_SNDBUF 타입에 대한 setsockopt() 호출을 통해 소켓의 송신 버퍼의 크기를 설정할 수 있습니다. 전송 버퍼의 크기는 전송 윈도우 크기와 반드시 일치할 필요는 없다고 합니다. (참고)
리눅스에서 SIOCOUTQ 타입에 대한 ioctl() 호출을 통해 소켓의 송신큐에서 아직 전송되지 않은 데이터 길이를 구할 수 있습니다. (참고)
TCP는 연결 과정(3-way handshake)에 서로의 수신 윈도우 크기를 교환하니다. 이 때 스케일 값을 TCP 헤더 옵션 필드에 전달함으로 TCP 헤더에 수신 윈도우 필드 2바이트로 표현할 수 있는 65535보다 큰 값을 활용할 수 있게 합니다.
그런데 TCP 수신 윈도우 스케일 값이 적용된다고 한 번에 전송되는 데이터의 크기가 커지는 것은 아닙니다. 윈도우 스케일을 통해 윈도우가 커지면 계속 전송할 수 있는 용량이 커지는 것이지 스케일업한 크기 만큼 한 번에 큰 데이터를 전송할 수 있다는 뜻은 아닙니다.네트워크 패킷으로 캡처해서 분석해 보니 상대방의 수신 윈도우에 여유가 있다면 큰 데이터를 1460바이트가 지연없이 계속 보내지는 것을 확인할 수 이었습니다.
2. 네트워크 패킷 분석 도구
캡처 필터에서 특정 대역을 필터링하는 방법 - tcp portrange 61000-62000
3. FTP 프로토콜
FTP는 21번 포트를 제어 포트로 사용하지만, 보안상의 이유로 실제 데이터를 교환하는 포트는 클라이언트와 동적으로 협의하여 결정된다. 오늘 확인해 보니 61000번 대에서 데이터를 교환할 때 마다 다른 포트가 선택되어지는 것을 확인했다.

개발일기 #106 : ﻿네트워크 프로그래밍에 대한 소소한 배움들

댓글

개발일기 #106 : 네트워크 프로그래밍에 대한 소소한 배움들