socket send buf 사이즈에 대한 질문
서버의 socket send buf 를 setsockopt 를 이용해 1메가로 셋팅하고 소켓을 non-block 로 셋팅하고 데이터를 송신을 합니다.
client 의 네트워크 처리 속도가 서버의 send 데이터량을 감당할 수 을 정도로 서버에서 많을 양을 쏩니다.
이렇게 되면 네트워크 delay 로 인해 서버측 socket의 send buf에는 데이터가 쌓여가다가 send buf 사이즈인 1메가에 도달하면 write 함수에서 EAGAIN 을 리턴합니다.
위에 있는게 제가 생각하는 통신 시나리오입니다.
근데 실상 send buf 가 20~30K 정도 쌓여있는데 EAGAIN 이 리턴됩니다. 여기에 의문이 생기는거죠. 1메가까지는 버텨야 하는거 아닌가 하는...
소켓을 특징이라면 tcp 이고 논블럭이고 NO DELAY(네이글 알고리즘 사용안함) 으로 셋팅되어 있다는것죠.
그리고 send 버퍼에 쌓인 데이터양은 netstat 를 이용해서 확인했습니다.
setsockopt 를 이용해서 send buf 사이즈 셋팅하는데 잘못 한거 아니냐 라는 의문이 생겨서 getsockopt 를 이용해 셋팅된 사이즈를 확인해 보면 1메가로 셋팅된게 맞습니다.
그럼 OS 에서 1메가까지 지원 안하는게 아니냐? 라고 생각 할 수도 있는데 솔라리스 2.8 을 사용하고 cpu는 스팍울트라인데, 이 플랫폼은 tcp 버퍼 1메가 까지 지원하는걸 확인했습니다.
그래서 생각한게 혹시 버퍼 사이즈 말고 버퍼를 일정 사이즈로 분활하는 그런 정책도 있는게 아닌가 하는 생각을 했습니다. 마치 파일 시스템의 file allocation unit 처럼요. 그런데 여기에 대한 설명 자료나 셋팅 옵션 같은걸 찾을 수 없어서 알 수가 없네요.
덧붙여 서버에서 send 하는 자료는 200~300바이트 정도 사이즈를 초당 수백~수천개 송신합니다. server / client 간 네트워크 band width 는 2~300K CPS 입니다.
이런 현상에 대해 알고 계시면 도움을 주시면 감사하겠습니다.
이것 저것 테스트하다가 뭔가 원천적으로 제가 잘 못 알고 있는게 아닌가
이것 저것 테스트하다가 뭔가 원천적으로 제가 잘 못 알고 있는게 아닌가 해서 한가지 더 질문 드립니다.
netstat 에서 Send-Q 필데 있는 값이 "send 버퍼에 쌓여있는 바이트 사이즈" 가 맞나요? 아니면 send 윈도우 내에 있는 남은 바이트인가요? 전자라고 생각했는데 왠지 후자 인가 싶어서 질문 드립니다.
댓글 달기