강의 10:21를 듣고, DHCP Server는 broadcast domain에 묶여서 해당 LAN영역에서 host가 요청한 인터넷 설정에 필요한 작업을 자동으로 세팅해준다. broadcast domain에 묶였기 때문에 gateway의 네트워크 주소( 여기서는 192.168.0 )를 넘어서 외부 네트워크와 통신하지 않는다. 제가 잘 이해했나요?
만약 다음과 같이, 서버에서 multicast RPC 호출을 진행하는 로직을 함수 내부에서 작성했고, 함수 내 로직을 RPC 호출 전, 후 2개로 나눈다면 (로직 1 -> 로직 1 내부 RPC 호출 -> 서버 _Imple 실행, 클라에 Imple 실행 명령 -> 로직2 실행) 인 것인가요? 아니면 (로직 1 -> 로직 1 내부 RPC 호출 -> 서버 Imple 실행 -> 로직2 실행 -> 나중에 패킷 보낼때 클라의 Imple 실행 명령 보냄) 인 것인가요? 궁금합니다. 만약 RPC가 아닌 Property Relication인 경우에는 두번째 방식과 비슷한 것 (나중에 패킷 보낼때 보냄)이라고 이해 했는데요, RPC일 경우에는 어떤 플로우가 맞나요? 둘중에 하나가 맞다면, Server, Client RPC들도 같을까요?
보통 이렇게 콘솔프로그램으로 만든 서버는 어떻게 배포를 해야하나요? bin/Debug의 exe로 서버컴퓨터에서 실행시키지는 않을 것 같은데.... 따로 Setup파일을 만들어서 서버에 배포를 하는 건가요? 따로 Setup파일을 만든다면 어떤 방식으로 하는지도 궁굼합니다.!
안녕하세요 선생님. 양질의 강의 너무너무 감사드립니다. AWS에서 이커머스를 운영하고 있는데 최근에 접속자가 몰려 네트워크 장애가 일어났습니다. 당시 웹서버를 늘려서 CPU 병목 등은 해결을 했지만 네트워크 장애 상황은 나아지질 않았습니다. 이후 테스트 환경을 세팅하고 장애 상황을 재연한 뒤 wireshock 을 이용해 패킷 분석도 해봤습니다. 참고로 인스턴스 하나에 프론트엔드(nextjs) 서버(==서버)와 백엔드(django) 서버(클라이언트) 둘 다 띄워져 있는 설정이고, 그 둘 사이의 송수신을 분석한 결과 알게 된 사실은 다음과 같습니다. 캐시(redis)가 걸린 요청은 CPU 자원을 소모하지 않는다. >총 CPU 역시 여유가 있음. 1. 패킷 분석 결과 장애상황에서도 속도가 크게 느려지지 않았다. 그렇지 않은 요청은 쿼리와 결과가 아주 간단한 요청임에도 시간이 많이 걸렸다. 패킷 분석 결과 TCP 연결을 종료할 때 공통적으로 병목이 일어남. (1초 내외) 처음엔 Zero-window 문제인가 했는데, 패킷 로그를 보니 window size도 문제가 없는 것 같고, FIN_WAIT2 에서 시간이 오래 걸린 것 같은데 원인을 모르겠네요. 참고로 4-way handshaking 의 로그는 다음과 같습니다. (8000 포트가 백엔드 서버, 55032 포트가 프론트엔드의 임시포트로 추정) ``` 65234 21.171396396 127.0.0.1 127.0.0.1 TCP 66 8000 → 55032 [FIN, ACK] Seq=384 Ack=570 Win=65536 Len=0 TSval=2505689308 TSecr=2505689308 65343 21.213509737 127.0.0.1 127.0.0.1 TCP 66 55032 → 8000 [ACK] Seq=570 Ack=385 Win=65280 Len=0 TSval=2505689351 TSecr=2505689308 66656 22.900434334 127.0.0.1 127.0.0.1 TCP 66 55032 → 8000 [FIN, ACK] Seq=570 Ack=385 Win=65536 Len=0 TSval=2505691037 TSecr=2505689308 66657 22.900437554 127.0.0.1 127.0.0.1 TCP 66 8000 → 55032 [ACK] Seq=385 Ack=571 Win=65536 Len=0 TSval=2505691037 TSecr=2505691037 ``` 정리하자면, DB와 인스턴스 자체의 리소스(cpu, 메모리 등)엔 문제가 없는 것으로 보이고, DB 풀링도 되고 있는 상황에서 전체 패킷 로그를 보면 데이터 전송에 오래 걸린 게 아니라 TCP 연결 종료만 오래 걸려서 애플리케이션(nextjs)의 문제라고 결론지으려다가도 캐시 걸린 요청은 문제가 없어서 원인을 특정하기가 무척 힘드네요. FIN_WAIT2 에서 병목이 일어나는데 해결할 방법이 있을까요? 다시 한 번 귀에 쏙쏙 들어오는 강의 마련해주셔서 감사합니다.
ReceiveBuffer 강의 듣는중 의문이 있어 문의드려요. TCP로 통신을할 경우 커널단에서 패킷 전체가 전송이 완료된후 OnReceive가 일어나는것으로 이해하고 있었는데 해당강의 에서는 어플리케이션단에서 전체 패킷이 다 들어왔는지 확인 후 처리를 하는 로직이 들어가는거 같아 혼돈이 오는것 같습니다. 제가 이해한게 잘 못 되었을까요? TCP 단에서 전체 패킷이 다 도착한 후 OnReceive가 일어나는게 맞다면 어플리케이션단에서 다시 한번 확인 후 처리하는 이유가 있을까요? PacketSession에서 마지막에 client에서 데이터를 쓰기위해 sendBuffer에서 사용할 영역을 예약하는 open에 문의 사항이 있습니다. 1) 강의대로 따라 하게되면 client에서 open(4096)을 하면 불필요하게 필요이상으로 버퍼를예약해서 실제 사용하지도 않지만 많이 예약하게되 _usedSize보다크게 되면서 계속해서 버퍼를 새로 만드는것으로 보이는데 실제 프로젝트에서는 필요한 사이즈만큼만 예약하게 되나요? 2) snedBuffer.Close() 에서 usedSize가 강의 에서는 _usedSize = usedSize로 되어있는데 이러면 계속 같은 버퍼 공간에 덮어 씌어질거같은데 _usedSize += usedSize로 되야 할거 같은데 이부분은 제가 잘못 이해 한건지 아니면 오타일까요?
안녕하세요 메모리 릭과 관련해서 질문 드립니다 비주얼 스튜디오에서 프로그램 실행시키면 진단 도구 창이 뜨고 그 안에 현재 프로세스가 얼마나 메모리 잡아 먹는지 보여주는데 콘솔에 로그 찍으면 메모리 계속 잡아먹으니까 서버와 클라 모두 콘솔에 아무것도 로그를 찍지 않게 빈 상태로 두었는데도 약 30초마다 3~5MB 씩 오릅니다 그래서 강의 자료에 있는 모든 코드를 복붙해서 어떤 로그도 안찍게 살짝 수정 후 실행했더니 결과는 동일하게 조금씩 오르더라구요 이 상태에서 서버는 계속 작동시키고 클라를 끄니까 메모리 릭 현상이 멈추긴 했습니다만 이 현상이 선생님 환경에서도 일어나는지 궁금하네요.. 기본 서버 강의라서 아직 최적화가 덜 돼서 그런건지요..?
획일화 할 수 없는 질문이라는 것 압니다만 문항에 secret manager이랑 systems manager parameter store이 있으면 secret manager가 정답일 확률이 더 높나요? 둘 차이가 뭔지 검색해도 잘 모르겠는데 전자가 기능이 더 많은 것 같아서요
안녕하세요 루키스님 qna 게시판을 보다가 루키스님이 주말마다 언리얼 클라이언트 연동 강의를 주말마다 진행하고 계신다는 글을 봤는데 혹시 멘토링으로 진행하시는 건가요? 만약 진행 중이시라면 지금이라도 참여할 수 있을까요? 강의로 촬영하고 계신 거면 언제쯤 출시되는지 궁금합니다.
강사님 안녕하세요? 수업이 너무 재밌습니다. 전공때 너무 지루해서 대충 넘어갔는데 강사님 설명을 듣다보니 네트워크 마스터가 되어가는 느낌입니다. 본론으로 들어가서 아래 토폴로지 구성에서 라우터와 서버를 크로스 오버 케이블로 연결하신 이유가 따로 있으신가요? Auto-MDIX 덕분에 다이렉트 케이블과 구분이 없이 사용 가능 하기 때문인가요?? 강의 내용에선 크로스 오버 케이블 : OSI 7 Layer 기준 같은 계층의 장비 다이렉트 케이블 : OSI 7 Layer 기준 다른 계층 장비 라고 하셨는데 해당 토폴로지 구성에선 별 다른 설명 없이 크로스 오버 케이블 사용하셔서 혼란스럽습니다.
루트 네임서버와 탑레벨 네임서버는 공용인가요? 공용이라는 의미는 모든 DNS가 .이 공통일거 같고 com, net 같은거는 동일할거 같아서요. 글로벌리 동일한 서버인건지? 동일한 서버그룹인건지? 동일하다면 누가? 관리주체인지? 동일하지 않다면 어떤 기준으로 정해지고, 각각의 서버 관리주체는 누구인건지 궁금합니다!
acceptex 함수를 사용하면 accept 쓰레드를 하나 만들어서 사용하는 거에 비해서 확실하게 성능 이득을 보는편인지 궁금합니다. 제 생각은 그렇게 차이가 심하게 날거라고 생각이 안 들거든요. 왜냐면, acceptex를 사용하면 그만큼 IOCP WorkThread 부담을 줄거라고 생각이 들고요, 그리고 소켓 풀로부터 어느 만큼 미리 만들어서 등록을 시켜줘야할지도 관건이 되겠고.. 결국 그 소켓 풀로 만드는 것도 풀이 비어 있으면 만드는 비용도 들어서 그렇게 큰 기대 효과를 못 볼거라고 생각이 들어서요. 그래서 결국 accept만 하는 스레드를 따로 빼서하는 것도 괜찮은 방법이라고 생각이 들거든요. 이 부분에 관해서 어떻게 생각을 하시는지 궁금합니다.
정리차 여쭤봅니다. 브로드 캐스팅 범위를 IP 주소상 range가 잡히면 줄어든다 > 3계층 부터는 논리적(가상)으로 설명이 가능하니, 범위를 나누는 논리적인 방법이 3계층에 있다 그럼 이 기능이 서브넷 마크스를 통해 IP주소를 나누는게 되겠죠? 논리 = 가상으로도 표현함 H/W를 S/W으로 구현 할 수 있다는 말을 듣고 한방에 정리가 되었습니다.