Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
윈도우 서버 환경에서, 최대 생성 가능한 소켓(socket) 연결 수는 얼마일까?

사실, 처음 이 질문에 의문을 느꼈을 때 제 심중의 대답은 Port 수 제한이었습니다. unsigned short(2byte) 이니까 65535 일 텐데 그나마 시스템에서 사용하는 포트를 제외해야 하니 약 60K 정도는 생성할 수 있을 것이라는 계산이었습니다.

서버 한대에 6만 개의 클라이언트라면 그다지 나쁘지 않은 연결 수인 것 같았지만, 최근의 64비트 다중 코어/소켓을 장착한 고성능 서버들이 출현하는 상황에서 거의 무한대에 가까운 16byte 주소값을 갖는 IPv6에서도 포트를 나타내는 타입이 USHORT 인 것을 보고는 다소 놀랬습니다.

=== ws2ipdef.h ===
typedef struct sockaddr_in6 {
    ADDRESS_FAMILY sin6_family; // AF_INET6.
    USHORT sin6_port;           // Transport level port number.
    ULONG  sin6_flowinfo;       // IPv6 flow information.
    IN6_ADDR sin6_addr;         // IPv6 address.
    union {
        ULONG sin6_scope_id;     // Set of interfaces for a scope.
        SCOPE_ID sin6_scope_struct; 
    };
} SOCKADDR_IN6_LH, *PSOCKADDR_IN6_LH, FAR *LPSOCKADDR_IN6_LH;

여전히 미래에도 60K 동시 연결만을 제공한다는 걸까요?

도저히 그럴 수는 없다는 상식으로, 검색을 해보았습니다. 그런데... 꽤나 의외더군요. 이에 대한 의문을 갖는 사람도 별로 없었을 뿐더러, 대부분은 답변까지 포함해서 틀린 답들 뿐이었습니다. (일부 답변은 Windows 2000만 있었을 당시라서 그 때에는 맞는 답일 수 있습니다.)

이론상 접속 가능한 최대 인원은? 
; http://www.gpgstudy.com/forum/viewtopic.php?topic=5370

다시한번질문드립니다.소켓의 한계...한피씨의 서버용량은???
; http://www.borlandforum.com/impboard/impboard.dll?action=read&db=bcb_qna&no=15833

소켓 생성시 최대개수는..... 얼마나..  
; http://www.devpia.com/Maeul/Contents/Detail.aspx?BoardID=50&MaeulNo=20&no=206826&ref=206665

Windows에서 열 수 있는 Socket 수 얻는 방법
; http://bspfp.pe.kr/63

WSAAsyncSelect 로가능한 소켓갯수는...
; http://www.tipssoft.com/bulletin/board.php?bo_table=QnA&wr_id=16299

사실, 검색도 힘들었는데... 디아블로인가... ^^; 게임에서 제공되는 소켓 아이템이라는 동일 이름 때문이었습니다. (다시 한번 놀랬지만, 게임 유저들의 그 참여/공유 정신은 대단한 것 같습니다. ^^)

다음 차례로, 외국 자료가 남았군요. 검색을 해보니, 진단이 딱 나옵니다.

One Million TCP Connections...
; http://www.serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html

윈도우상에서의 이론 상 한계는 "16,777,214" 이라고 합니다. 이 정도면 결국 실질적인 한계가 문제인데, 아래의 글에서 잘 정리해 주고 있습니다.

How to support 10,000 or more concurrent TCP connections
; http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html

  • Data copies
  • Context switches
  • Memory allocation
  • Lock contention

즉, 서버 스펙도 따라야 하고, 해당 응용 프로그램의 메모리/로직에 따라서 천차만별이 된다는 것이죠. ^^

참고로, 아래는 일반적인 threshold 값들인데 아마도 Windows Server 2003 기준의 값인 것 같습니다. 운영체제마다 변경된 부분이 있을 테니 적용할 때는 적절하게 감안을 해주셔야 할 것입니다.

Configure the max limit for concurrent TCP connections 
; http://smallvoid.com/article/winnt-tcpip-max-limit.html




그런데, 아직... 의문이 안 풀린 분들이 있을 텐데요. 과연 어떻게 포트 번호 범위를 넘어서는 16,777,214 값이 나오게 된 걸까요? 이에 대한 설명은 위에서 소개한 "One Million TCP Connections..." 글의 댓글에서 글쓴이가 쉽게 설명해 주고 있습니다.

No, that's a common misconception. You're limited to the local ports when making outbound connections as each connection consumes a local port and they are limited to 65535 as you point out and when you take into account the number of ports already in use for other services and any connections currently in TIME_WAIT the maximum number of outbound ports is usually at most 50k.

Inbound ports are identified by a tuple that consists of the local ip and port and the remote ip and port and so are not limited in the same way. I've run tests whereby a simple server on very modest hardware supported more than 70,000 concurrent active connections - the test server and client that I used can be found here: http://www.lenholgate.com/archives/000568.html


오~~~ 역시 머리 좋은 사람들은 다르군요. ^^ 어차피 내부에서 해당 소켓을 식별만 하면 되는데 굳이 2바이트 정수로 제한할 필요없이 구분키의 범위를 연결을 시도한 측의 IP/Port를 함께 포함하니 자연스럽게 65,535 개의 한계가 없어져버립니다. 실제로 글쓴이는 760 MB 메모리만을 가진 Windows Server 2003 시스템으로 7만 개의 동시 연결을 테스트했다고 합니다.

재미있군요. 직접 테스트 해보실 분들 계신가요? 700 MB 정도에 7만 개면, 24 GB 메모리면 테스트에 사용한 동일한 서버 프로그램으로 210만 개는 무난하게 나온다는 얘기가 되는 군요. 그럼, 서버는 그 정도 사양으로 한 대 준비하면 될 것 같고. 반면에 클라이언트는 제법 준비를 해둬야 합니다. 왜냐 하면 클라이언트 측은 여전히 65,535 포트 범위 제한이 있기 때문에, 100만개 연결 테스트만 해도 20 대 정도가 넘게 필요합니다. Virtual NIC의 특별한 제한이 없다면 가상 PC를 20개 정도 마련해야 겠군요. (참고로, 가정용 무선 Access Point로는 네트워크 연결 테스트하지 마세요. ^^ 제 경우에는 천 개만 넘어도 네트워크가 멈춰버렸습니다.)

혹시, 환경 구성해서 테스트 하시는 분이 계시면 결과 좀 공유 부탁드리겠습니다. ^^



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

[연관 글]





[최초 등록일: ]
[최종 수정일: 12/21/2010 ]

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

비밀번호

댓글 쓴 사람
 



2010-12-22 09시40분
[lancers] 이거 10년 전쯤 예전 회사에서 해보던 짓이었는데.. -_-;;
당시에도 간단한 테스트로는 몇만개까지 만들 수 있었습니다.
하지만, 그건 '간단한 테스트'에만 해당되는 것이죠.
서버 App쪽에 어떤 코드를 넣느냐 따라서 결과가 천차만별이 됩니다.

'One Million TCP Connections...' 글쓴이가 말한 게 딱 정답이죠.
Q - "Can a machine of a given spec running Windows Server 2003 support 1 million concurrent TCP connections?"
A - Only if your server software can also support that number of connections...
[손님]
2010-12-22 11시35분
어쨌든, 제가 건질 수 있었던 것은 65K 제한이 없다는 것이었습니다. 접속해 오는 측의 IP/Port 정보를 포함한 튜플을 구분자로 쓴다는 것이 가장 의미있는 정보가 아닐까 싶습니다.

640K 메모리가 불과 20년도 안된 것을 생각하면,,, 향후에는 몇 만개가 아니라 몇 십만개도 의미가 있을날이 오겠지요. ^^
정성태
2010-12-22 06시30분
[ryujh] 안녕하세요.

아직 테스트는 안해봤는데 원격이 아닌 localhost 에서는 어떤지요?

위의 글대로 하려면 공부부터 해야되서 혹시나 해보셨는지 문의합니다.

최근 케이블모뎀을 교체했었는데 과도한 연결때문이 아닌지 생각도 되고 그렇습니다.
[손님]
2010-12-22 08시08분
ryujh 님이 한번 해보세요. ^^
저는 해본적이 없습니다. 아직 필요성도 없고. 나중에 시간날 때 한번 해볼만한 걸로 목록에는 들어있지만.

일단 localhost 라고 해도 접속하는 측이 65K 포트로 제한되기 때문에 그 이상은 넘어갈 수 없습니다. 가상 환경을 적용해보면 어떨까 싶은데... 생각만 하고 있습니다. ^^
정성태
2011-01-03 03시42분
정성태
2013-06-26 03시00분
Node.js w/1M concurrent connections!
; http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/

600k concurrent HTTP connections, with Clojure & http-kit
; http://http-kit.org/600k-concurrent-connection-http-kit.html
정성태
2013-08-31 10시37분
Tuning Windows for TCP/IP performance
; http://kb.globalscape.com/KnowledgebaseArticle10438.aspx
정성태
2013-11-15 04시53분
[김학진] 검색하다가 열어보니 여기로 왔네요 ㅋ

잘보고 가용 ㅋ
[손님]
2013-11-16 04시04분
^^ 그러게요. 재미있는 웹 세상입니다.
정성태
2020-07-03 01시52분
[rickey] 2020년에 이런 엄청난 글을 읽을줄이야..
[손님]
2020-09-22 07시47분
[Luna] 쉬운 설명을 위해서 인(서버), 아웃(클라) 라고 가정하면 두가지 차이가 생깁니다.
서버는 80번 포트 처럼 특정한 포트에 바인드되어 c100k이상의 포트한도를 넘을 수 있는데 클라:* -> 서버:80 때문에 사실 포트 한도는 없습니다.
클라는 위에 설명된 대로 가용할 포트대역이 필요하여 c100k이상에 포트한도를 넘을 수 없는데 서버:* -> 서버:80 때문에 아이피당 c65k정도 한도에 걸립니다.
HTTP/2.0 같이 적은 연결로도 여러가지 데이터 전송이 가능한 방식이 있지만 강제사항은 아니므로 오늘날에도 위와 같은 문제를 겪을 수 있습니다.

지금의 가정용 컴퓨터의 성능조차도 차고넘치는데도 윈도기반 코어쪽에 걸린 제한은 바뀌지 않았다는 의심이듭니다.
윈도우 10에서 노드js 서버로 클라이언트 루프백연결을 만개씩 추가하는 로직으로 두번 실행하면 14000정도 접속되고 ENOBUFS 오류가 나게됩니다. (이후 모든 TCP인터넷 연결 오류가나고 UDP통신은 되지만 같은 방법으로 제한이 걸립니다)
가령 루프백 연결은 127.0.0.1:* -> 127.0.0.1:9000(PHP백엔드가정) 65535포트 범위한도이지만 127.*.*.*:* 대역을 로직으로 쓰는 경우에 사실상 한도가 없습니다.

인터넷 환경에서는 공인아이피:* -> 공인아이피:80 처럼 연동을 하게 되므로 포트범위 한도는 명확하게 걸립니다.
클라우드 서비스 같은 곳에서는 NAT환경을 제공하고 가상아이피를 량것 부여하여 사용하므로서 나가는 연결에 포트한도를 확장 시키는것 같습니다.(하지만 아마존 리눅스...)


마이크로소프트 문서를 온통 뒤져보아도 포트 소모 문제는 임시방편으로만 제공하고 있는 것 같아서 어쩌면 서버로직이라고 해도 크게 다른건 없을 것 같습니다.
더군다나 서버제품군이라고 차이를 명확하게 정의하는 영업파트도 없는 것 같아요.

이미 사업권을 클라우드서비스로 확장중이니깐 하드한 이슈가 안나오면 안 바뀔 것 같습니다. 이를 테면 tcpip.sys 드라이버를 대체할걸 만드는게 더 빠를지도 모르겠어요.
리눅스커널 도커를 쓰면 되겠지만 윈도기반 서비스에 연동 해야 할 지는 또 모르는 일인것이죠.
[손님]
2020-09-22 09시29분
@Luna 두 번째 단락의 설명이 좀 이해가 안 되는군요, 그러니까 NodeJS에서 localhost로 서버를 열고 있을 때, 같은 머신 내에 있는 클라이언트로부터 2만 개의 클라이언트 접속을 못한다는 건가요? 그리고 그 원인이 윈도우라는 것을 의미하는 건가요? (만약 그렇다면 그건 잘못 알고 있는 것입니다. 설령 NodeJS로 그렇게 나온다고 해도 그건 Node 측의 제한이지, 윈도우의 제약이 아닙니다.)

그리고 "소스IP:Port-대상IP:Port"의 쌍으로 관리하기 때문에 다른 설명들은 모두 그 안에서 설명이 됩니다. 그런데, "마이크로소프트 문서를 온통 뒤져봐도... 포트 소모 문제는 임시 방편..."이라고 하셨는데 그 부분에 대한 설명을 좀 더 해주실 수 있을까요? 포트의 범위를 정한 것은 마이크로소프트가 아닌, TCP 관련 표준을 만드는 곳에서 그렇게 한 것입니다. 이미 포트를 65K로 정했는데 마이크로소프트가 어떻게 해야 그 제한을 없앨 수 있다는 건지 잘 이해가 안 갑니다.

마지막으로, 글을 다시 한번 정리해서 테스트 코드 등과 함께 자신의 블로그 등을 이용해서 올려 주시면 어떨까 싶습니다. 첫 번째의 설명을 보면 무슨 의미인지 잘 모르겠습니다.

"
서버는 80번 포트 처럼 특정한 포트에 바인드되어 c100k이상의 [포트한도를 넘을 수 있는데] 클라:* -> 서버:80 때문에 사실 [포트 한도는 없습니다.]
"

포트한도를 넘을 수 있는 것과 포트 한도가 없다는 것이 무슨 차이가 있는 건가요?
정성태
2020-09-25 01시47분
[Luna] 확인은 tcp server를 열고 tcp client를 1만개씩 localhost 연결 시켜서 하였습니다. (클러스터 10개 fork, 1000개씩 접속)
윈도우쪽에 제한이라고 생각하는 점은 클라이언트를 2번 실행하면 ENOBUFS 상태가 되는데 이때 다른 아이피:포트에 tcp 연결, 인터넷 tcp연결 등등 모두 가능하지 않기 때문입니다. (#1의 레지스트리 MaxUserPort 값은 건드리지 않은 5000 상태입니다.)

임시방편 이라고 한 이유도 #2의 영구적인 솔루션이 아니라고 하고 있고 이런 자료들 외에 방안이 따로 찾아지지 않는 이유에서 였습니다.

윈도우에서 나가는 연결이 c65k가 한도라면 리눅스 환경에서는 c65k 이상의 나가는 연결을 해결하기위하여 #3의 가상아이피를 활용하여 사용하는 것 같습니다.
좀 더 시간을 내서 다양한 검증을 해보아야 겠지만 과거부터 지금까지 시간이 많이 지나서 포트 한도 문제를 해결 했을 만도 한데 막상 그렇진 않은것이 아닌가 싶어요.

#1 https://support.microsoft.com/ko-kr/help/196271/when-you-try-to-connect-from-tcp-ports-greater-than-5000-you-receive-t
#2 https://docs.microsoft.com/ko-kr/windows/client-management/troubleshoot-tcpip-port-exhaust
#3 https://qunfei.wordpress.com/2016/09/20/from-c10k-to-c100k-problem-push-over-1000000-messages-to-web-clients-on-1-machine-simultaneously/

서버에 들어오는 연결은 각자 아이피를 가진 클라이언트들이 들어와서 서버쪽에 포트를 더 소비 하지는 않으므로 client:* -> server:80 한도가 존재하지 않는다는 의미였습니다.
서버에서 다른 서버로 리버스프록시를 구성할 때는 server:1-65535 -> server:80 처럼 포트 가용성 범위는 65535이고 아이피 갯수에 따라 나가는 연결 수가 늘어날 수 있습니다.

테스트가 잘못 되었을 수 있을것 같은 부분으로 아이피 수가 아니라 네트워크아답터 수에 따라 버퍼도 늘려줬을 수도 있을 것 같다는 생각이 문들 스처지나가요.
공인, 사설 인터넷를 불문하고 인터넷 아이피를 하나만 받은 경우에는 나가는 연결수가 최대 c65k 이지만 두개이면 c130k 처럼 가용 대역도 늘어나지요.
하지만 127.0.0.1 이나 127.0.0.2 처럼 외부가아닌 루프백아이피 통한 연결은 포트 범위가 한정적이지만 가용가능한 아이피대역이 많았기에 윈도우기반에서 처음부터 고려되지 않은게 아닐까 하는 생각됩니다.

윈도우 10 기반에서 들어오는 연결 수는 서버 성능에 좌우되고 나가는 연결은 아이피를 더 넣거나 랜을 추가하여도 최대 65534 까지인것 같습니다.
스택오버플로쪽 댓글중에는 한도보다 더 연결하려면 서버 제품군을 써야한다는 코맨트를 보았는데 정말 윈도우 데스크탑 제품군에 대한 제한일 수도 있으니 이 부분은 좀더 검증을 해보아야 겠어요.

계속 서버 검증만 하고 있을수가 없다보니깐 검색이라도 해서 자료를 찾는데 나가는 연결쪽에 대한 자료는 거의 없는것 같아요.
[손님]
2020-09-26 02시27분
@Luna 일단 아래의 글에 정리했으니 한 번 읽어 보세요.

윈도우 환경에서 클라이언트 소켓의 최대 접속 수
; https://www.sysnet.pe.kr/2/0/12350

위의 글에서도 언급했지만, 한 가지 Luna 님의 테스트 환경이 궁금한데, MaxUserPort 값이 5000 이라면 원래 1만 개의 연결이 가능하지 않고 4,000 개 정도에서 ENOBUFS 오류가 발생했어야 합니다. 정확한 가용 포트 수는 "netsh int ipv4 show dynamicport tcp" 명령어로 확인할 수 있으니 그 결과가 아마도 16,384가 나올 것입니다. (확인해 보시고, 아니면 또 덧글 달아 주세요.)

어쨌든, Luna 님의 환경에서는 윈도우의 (아마도) 기본 값 환경 구성이므로 16,384가 최대 클라이언트 연결 수가 맞고, 그 상황에서는 NodeJS의 그런 테스트 결과도 맞습니다.

그런데, 나가는 연결에 대한 c65k 문제는 윈도우 만의 문제가 아닌 리눅스도 마찬가지로 보입니다. 제시하신 #3번 링크는 (리눅스 환경에서 c65k 이상의 나가는 연결을 해결하기 위한 내용이 아니고) 1대의 TCP 서버를 두고, 그것에 100만 개의 연결 테스트를 위해 (클라이언트 제약이 c65k이므로) 20 개의 마이크로 서버를 구성했다는 내용입니다. 따라서 윈도우와 별반 다르지 않은 제약을 가지고 있는 듯합니다.

이외에 더 궁금한 것이 있으면 추가로 덧글 남겨주세요.
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12378정성태10/20/2020103.NET Framework: 954. C# - x86/x64 환경에 따라 달라지는 P/Invoke 함수의 export 이름파일 다운로드1
12377정성태10/15/2020109디버깅 기술: 172. windbg - 파일 열기 시점에 bp를 걸어 파일명 알아내는 방법(Managed/Unmanaged)
12376정성태10/15/202043오류 유형: 669. windbg - sos의 name2ee 명령어 실행 시 "Failed to request module list." 오류
12375정성태10/15/2020147Windows: 177. 윈도우 탐색기에서 띄우는 cmd.exe 창의 디렉터리 구분 문자가 'Yen(¥)' 기호로 나오는 경우 [1]
12374정성태10/14/2020129.NET Framework: 953. C# 9.0 - (6) Function pointers파일 다운로드2
12373정성태10/14/202067.NET Framework: 952. OpCodes.Box와 관련해 IL 형식으로 직접 코딩 시 유의할 점
12372정성태10/14/2020138.NET Framework: 951. C# 9.0 - (5) Attributes on local functions파일 다운로드1
12371정성태10/13/202052개발 환경 구성: 519. Visual Studio의 Ctrl+Shift+U (Edit.MakeUppercase) 단축키가 동작하지 않는 경우
12370정성태10/13/202053Linux: 33. Linux - nmcli를 이용한 고정 IP 설정
12369정성태10/12/2020806Windows: 176. Raymond Chen이 한글날에 밝히는 윈도우의 한글 자모 분리 현상 [1]
12368정성태10/12/202049오류 유형: 668. VSIX 확장 빌드 - The "GetDeploymentPathFromVsixManifest" task failed unexpectedly.
12367정성태10/12/202049오류 유형: 667. Ubuntu - Temporary failure resolving 'kr.archive.ubuntu.com'
12366정성태10/13/2020127.NET Framework: 950. C# 9.0 - (4) Native ints파일 다운로드1
12365정성태10/12/2020119.NET Framework: 949. C# 9.0 - (3) Lambda discard parameters파일 다운로드1
12364정성태10/11/2020155.NET Framework: 948. C# 9.0 - (2) Skip locals init파일 다운로드1
12363정성태10/11/2020173.NET Framework: 947. C# 9.0 - (1) Target-typed new파일 다운로드1
12362정성태10/11/2020155VS.NET IDE: 151. Visual Studio 2019에 .NET 5 rc/preview 적용하는 방법
12361정성태10/19/2020227.NET Framework: 946. C# 9.0을 위한 개발 환경 구성
12360정성태10/8/202067오류 유형: 666. The type or namespace name '...' does not exist in the namespace 'Microsoft.VisualStudio.TestTools' (are you missing an assembly reference?)
12359정성태10/7/202061오류 유형: 665. Windows - 재부팅 후 iSCSI 연결이 끊기는 문제
12358정성태10/7/202048오류 유형: 664. Web Deploy 설치 시 "A newer version of Microsoft Web Deploy 3.6 was found on this machine." 오류
12357정성태10/7/202049오류 유형: 663. 이벤트 로그 - The storage optimizer couldn't complete retrim on New Volume
12356정성태10/7/202073오류 유형: 662. ASP.NET Core와 500.19, 500.21 오류 (0x8007000d)
12355정성태10/3/202098오류 유형: 661. Hyper-V Linux VM의 Internal 유형의 가상 Switch에 대한 IP 연결이 되지 않는 경우
12354정성태10/2/202084오류 유형: 660. Web Deploy (msdeploy.axd) 실행 시 오류 기록
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...