추가 코멘트 남깁니다 * 15:57 부터 나오는 시퀀스 다이어그램에서 signal의 경우에는 해당 다이어그램처럼 동작하는데, callback의 경우에는 data moved from kernel space to user space할 때 OS가 별도의 스레드를 만들어서 그 스레드에서 콜백 코드를 실행한다고 이해해주시면 되겠습니다 다이어그램 표현이 정확하지 않아서 죄송합니다 ㅠ
강의 감사합니다! 영상 이것저곳에서 흘리신 땀이 묻어나오네요 :) 영상을 보면서 궁금한 점이 생겼습니다. async하다라는 말이 작업을 요청한 곳에서 처리하지않고, callback이나 event를 사용해서 나중에(작업이 완료되는 시점)에 다른 곳에서 처리되도록 하는걸로 이해했는데요! 그러면 '나중에 다른곳'에서 처리된다는 의미는 다른 thread를 의미하는건가요? 아니면 같은 thread에서 callback이 실행되는 것이 보장되나요?
앗 async라는 용어는 워낙 범용적으로 그리고 컨텍스트에 따라 조금씩 다른 의미로 사용되기 때문에 callback이나 event로 한정지어서 생각하시면 안될 수도 있습니다 '다른 곳에서' 처리된다는 얘기 자체는 콜백인 경우 콜백 코드가 다른 스레드에서 처리된다는 의미였고요, signal의 경우, signal handler를 등록해서 처리한다는 의미인데 이 경우에는 같은 스레드에서 처리가 될 겁니다 여하튼 핵심은 async라는 의미 자체는 워낙 다양해서요, 각 상황별로 어떤 의미로 사용되는지를 따로 영상으로 정리했는데요, 아래 영상을 봐주시면 도움이 되지 않을까 싶습니다 :) ua-cam.com/video/EJNBLD3X2yg/v-deo.html
안녕하세요 좋은 강의 들으면서 질문이 생겨 남깁니다. python 이나 node js 는 싱글 쓰레드 기반이라고 알고 있습니다. 그런데 싱글 쓰레드 환경에서 Non-Block 상황이 조금 헷갈리는데요. I/O 오퍼레이션을 담당하는 OS kernel 의 쓰레드는 python 이나 node js 의 코드를 실행하는 쓰레드와 다른 쓰레드인건가요?
안녕하세요~ 우선 좋은 말씀 감사합니다 :) python은 프로그래밍 언어이기 때문에 싱글 스레드 기반이라는 표현이 적절하진 않을 것 같구요, (혹시 GIL 때문에 그렇게 말씀하신 것이라면, GIL은 여러 스레드가 동시에 CPU 작업을 하지 못하게 막는 것이라서, 여러 스레드가 동시에 IO 작업을 하는 것은 가능합니다) node.js 같은 경우에는 (제가 직접 써본적은 없어서 깊게는 모르지만) 하나의 메인 스레드가 이벤트루프 방식으로 동작을 할 때 여러 요청에 대해서 nonblock IO를 사용하며, 그래서 하나의 메인 스레드로 동작하는 것이 가능한 것으로 알고 있습니다. nonblock IO를 할 수 없는 상황인 경우에만 미리 만들어둔 스레드풀에 위임해서 처리하는 것으로 알고 있고요. 관련해서 구글링을 해보니 이런 글이 보이는데, 혹시 도움이 되실까 하여 남겨봅니다 tk-one.github.io/2019/02/07/nodejs-event-loop/
select는 모든 fd에 대해서 read 시스템콜을 호출하는게 아니고 읽기가 준비된 fd에 대해서만 read 시스템콜을 호출하기 때문에 io멀티플렉싱인건가요? fd가 준비됐다는걸 확인하기 위해 반복문을 사용해서 주기적으로 체크는 하지만, 실제로 확인하는 방식이 read시스템콜을 이용한 확인이 아니라 io 멀티플렉싱 모델이라 하는게 맞을까요?
오~ 답변드릴게요~ I/O 멀티플렉싱은 한번에 여러 개의 소켓을 확인할 수 있음을 의미합니다 select 함수의 경우에도 여러 file descriptor(리눅스는 소켓도 file descriptor로 관리됨)에 대해서 감지하고픈 이벤트(read, write, etc)를 select 함수를 호출하면서 등록해 놓으면, 하나 이상의 file descriptor에서 관심있던 이벤트가 동시에 발생했을 때도 '한번에' 감지할 수 있습니다 그래서 감지된 file descriptor들을 FD_ISSET을 통해 확인하고 그 file descriptor들에 대해서만 read를 하면 됩니다
강의 잘 들었습니다! 오늘은 영상의 길이가 긴 만큼 내용이 이해하는데 어렵네요. 어려운 내용이라 그런지 댓글에도 여러 질문들이 있어서 읽다보니 제가 갖고 있던 의문이 해결되는 댓글도 있어서 좋았습니다. 그럼에도 질문거리가 남아있네요 하하... 강의 13:40 경에 설명하신 내용을 듣다보니, 밑에 있던 댓글과 관련해서 궁금한 내용이 생겨 질문드립니다. 밑에 댓글을 보니 여러 소켓들 중에서 실제 요청이 들어온 소켓들만 감지하는(I/O multiplexing) 목적의 스레드가 있어서, 실제 요청이 들어오게되면 이 스레드에 의해 요청이 들어온 연결에 스레드를 할당하여 요청을 처리한다고 되어있었는데요. 1. 그럼 강의 13:40 에서 그림에 나와있는 왼편에 있는 스레드도 IO multiplexing 목적의 스레드라고 할 수 있을 것 같은데, 해당 스레드가 시스템콜을 통해 커널로 하여금 IO가 수행되어 데이터가 들어오면 이를 다시 스레드에게 notify 해주는 매커니즘으로 동작하고, 그 밑에서 데이터를 옮긴다고 되어있네요. 그럼 밑에서 실질적인 데이터를 옮기는 작업은 실제 요청이 들어온 연결에 할당된 스레드에서 수행되는 것인가요? 만약 맞다면, io multiplexing 스레드에서 request 처리 스레드로 어떻게 이를 알리는 것인지 궁금합니다. (아니면, io multiplexing thread가 커널에 요청할 때 어떤 소켓에 대해서 모니터링을 요청하는지 식별값을 전달할테니, 커널이 직접적으로 개입하여 데이터가 들어온 소켓에게 할당되는 스레드에 직접 signal을 날리는 것인지...?) 2. 13:40 의 그림 같은 경우는 io multiplexing 스레드가 시스템콜을 요청한 이후에, blocked 된 상태인데, 물론 설명을 통해 시스템콜 요청 이후에도 run 할 수 있게 코드를 작성할 수 있다고 하셨지만, 강의의 경우에는 non blocking io 가 아니라 blocking io 로 보는게 맞는건가요? 만약 run할 수 있게도 코드를 작성할 수 있다면, 마지막의 ibm의 표에서는 blocking과 non-blocking 모두에 속할 수 있는 것인가요..? 3. non-blocking io를 해결하기위해 사용하는 방법론중 3번에 해당하는 callback/signal이 잘 사용되지 않는 이유가 따로 있을까요? 그리고, 결국 2번 io multiplexing도 여러 소켓에 대해 여러 동작(read, write, 등)을 모니터링할 수 있는 장점이 있지만, 마지막에 이를 실제 스레드가 처리하기 위해서는 커널이 notify를 해주어야하는데 그럼 3번의 부분집합이라고 볼 수 있지 않나요? 4. 영상의 말미에 synchronous와 asynchronous 의 설명에서 asynchronous의 경우는 io를 요청한 당사자가 결과까지 직접 챙기는 것이 아닌, 커널로부터 notify를 받거나 callback 형태로 동작한다고 하셨습니다. 유저레벨에 있는 스레드는 직접 io할 수 없기 때문에, 무조건 시스템콜로 커널을 통해서 io를 수행해야하는데, 커널에서 하드웨어와 io를 마치고나서 다시 유저 스레드로 io가 끝났음을 알려주는 인터럽트 같은 notify가 있기 때문에, 이러한 인터럽트성 notify를 제외한 제 3의 스레드가 개입된 흐름(여기서는 kernel -> io multiplexing thread -> requset 처리 thread)과 AIO의 callback or signal 메커니즘을 말하는 것인가요? 질문을 항상 받아주셔서 감사드립니다.
댓글까지 꼼꼼히 봐주시고 역시 최고십니다 !!ㅎ 답변 드리겠습니다!! 1. 네, 맞습니다. I/O multiplexing을 통해 어느 소켓에 데이터가 들어왔는지 감지가 됐기 때문에, 그 소켓에서 실제로 데이터를 읽게 되는 스레드가 해당 요청을 처리하는 식으로 많이들 동작합니다 어떤 스레드에게 어떤 소켓을 할당할지는 구현하기 나름일 것 같은데요. 이번 영상에서는 스레드풀을 활용하는 방법을 소개하긴 했습니다~ 아주 추상적으로 설명드리면, 스레드풀에 작업을 할당할 때 할당할 소켓만 구분해서 할당하면 될 것 같습니다 2. 약간 다릅니다. block이 되는 것은 I/O 작업이 아니라 I/O multiplexing 함수입니다. 영상에서는 I/O multiplexing을 제공하는 시스템콜을 블락으로 호출한 경우로 가정하고 설명한 것이고요, 소켓 자체는 nonblock I/O로 동작하도록 설정해줘야 합니다 3. >> non-blocking io를 해결하기위해 사용하는 방법론중 3번에 해당하는 callback/signal이 잘 사용되지 않는 이유가 따로 있을까요? 이건 저도 잘 모르겠네요. 여러 사정이 있을 수 있는데, 적극적으로 개발이 되고 있지는 않는 것 같더라고요 >> 결국 2번 io multiplexing도 여러 소켓에 대해 여러 동작(read, write, 등)을 모니터링할 수 있는 장점이 있지만, 마지막에 이를 실제 스레드가 처리하기 위해서는 커널이 notify를 해주어야하는데 그럼 3번의 부분집합이라고 볼 수 있지 않나요? 2번의 notify가 된다는 의미는 스레드가 딴 작업을 하고 있는데 OS가 쿡 찔러서 요청한 I/O 작업 데이터 준비 됐다고 알려준다는 그 의미는 아니고요, ‘소켓들에 데이터가 준비돼어 있다’를 “알려준다”는 의미로 notify를 사용했습니다 그렇기 때문에 2번의 경우에는 I/O multiplexing 시스템콜을 사용하면, 준비된게 있다고 응답받으면 그 후처리를 또 해줘야 하고 3번은 일단 시스템콜로 I/O 작업을 요청하면 요청한 그 스레드는 더 이상 신경쓸 필요가 없기 때문에 2번과는 좀 다르죠 * 참고로 설명하다가 발견한 것인데요, 영상에서 16:00에 사용된 슬라이드에서 callback과 signal 둘 다, 호출한 스레드해서 처리되는 것처럼 그렸는데요, signal은 이렇게 동작하는데 callback은 스레드 하나를 새로 만들어서 처리하는 방식입니다 제가 오해가 생기게끔 잘못 표현한 부분입니다 ㅠ (시그널은 보시는 것과 같이 동작합니다, 인터럽트 처럼 동작하는 거라서요) 4. 죄송해요.. 이건 제가 어떤 질문인지 정확히 파악을 못했습니다 ㅠㅠ
@@ez. 항상 빠르고 정성스러운 답변 감사드립니다. 답변을 읽고나서 제 생각을 공유드리고 질문도 같이 드립니다 ㅎㅎ 3번의 경우는 개념적으로는 상당히 명료한 편이라서 이해하는데는 그렇게 어려움이 들진 않는데, 역시 이해하기 상대적으로 난해한건 2번인거 같아요. 제가 질문 2번으로 드렸던 "io multiplexing이 signal/callback 매커니즘의 부분집합으로 볼 수 있지 않나요?" 라는 질문에 답변을 통해 제가 이해한 두 방법론의 가장 큰 차이점을 말씀 드리자면, 만약 io의 전체 과정을 1. 외부 네트워크로부터 데이터를 로컬 컴퓨터의 소켓 버퍼(커널 영역 메모리)로 읽어옴. 2. 소켓 버퍼에 들어있는 데이터를 유저 스페이스 메모리로 읽어옴. 이렇게 크게 2개로 나눴을때, io multiplexing의 경우 1번 단계 + 데이터가 들어왔는지 monitoring을 io multiplexing 스레드가 담당하고, 2번 단계를 요청을 처리하는 스레드가 담당한다고 이해했습니다. 그래서 답변에 "소켓 자체는 nonblock I/O로 동작하도록 설정해줘야 합니다" 라고 해주셨구요. signal/callback의 경우 전체과정을 한 스레드가 모두 처리하고, 데이터가 준비되는 동안 non-blocking 방식으로 동작하다가 데이터가 준비되면 signal 혹은 callback의 형태로 2번 단계가 수행된다고 이해했습니다. 일상생활에 비슷한 경우를 예로 들어보자면, multiplexing은 부모님과 아이가 같이 놀이공원을 갔을 때, 부모님이 아이 대신 놀이기구의 줄을 서주시다가 본인 차례가 되었을 때, 아이에게 그 자리를 양보하는 경우가 떠올랐습니다. 부모님이 놀이기구를 탈 수 있는 순서(서버로 들어오는 요청)를 대신 기다리고, 순서가 왔을 때, 아이에게 놀이기구 탑승을 넘겨준 것이죠. (이후의 non-blocking 상황은 이해의 편의상 제외했습니다.) signal/callback 의 경우 놀이기구에 탑승시간을 예약하는 시스템이 있어서, 아이가 혼자 놀이기구 탑승시간을 예약해놓고, 다른 일을 하고 있다가(non-blocking) 본인의 순서가 오면 핸드폰으로 탑승 알림이 오는 상황이 생각났습니다. (알림이 다시 오더라도 read 요청을 할 필요가 없는 경우죠.) 쓰다보니 글이 길어졌는데 읽어주셔서 감사합니다. ====================================================================== + 추가적으로 질문이 또 생겨버려서 고견 부탁드립니다. "스레드가 딴 작업을 하고 있는데 OS가 쿡 찔러서 요청한 I/O 작업 데이터 준비 됐다고 알려준다는 그 의미는 아니고요, ‘소켓들에 데이터가 준비돼어 있다’를 “알려준다" ===> 이 답변에서 소켓들에 데이터가 준비되어 있음을 커널이 io multiplexing 수행 스레드에게 알려주는 것이고, 이 알림을 받은 io multiplexing 스레드가 준비된 데이터를 읽고 처리할 새로운 스레드를 만들어서 처리하는 것으로 이해했습니다. 여기서 커널이 io meltiplexing 스레드에게 단순히 io interrupt 같은 것으로 알림을 주는 건가요? 또, 만약에 io multiplexing 의 경우 데이터가 준비되었다는 것을 알림을 받고난 후에 요청을 처리하는 스레드가 소켓버퍼에서 유저스페이스 메모리로 데이터를 가져올 텐데, 이 때 read를 non-blocking으로 하는 이유는 데이터를 가져오는 동안 cpu를 낭비하지 않기 위함인가요? 데이터가 이미 소켓에 준비되어있다는 것을 알고 있기 때문에, 만약에 하고자하는 작업이 io 밖에 없다면 block과 non-block의 성능차이가 없을 것 같아서요. p.s. 4번 질문은 단어적인 헷갈림 때문인지라 없는 질문이라고 생각해주셔도 될 것 같습니다. 항상 감사합니다!
@@세승-v4s 제가 아무래도 설명을 잘 못한 것 같아요 ㅠㅠ 좀 더 설명을 드리자면 2번 방식 스레드가 I/O multiplexing 시스템콜을 호출하게 되면 한번의 호출로도 관심있던 소켓들 중에서 어느 소켓들에 실제로 데이터가 준비됐는지를 OS가 확인하고 반환해 줍니다 예를 들어 스레드 A가 I/O multiplexing 시스템콜을 blocking으로 호출하게 되면 OS가 어느 소켓들에 실제로 데이터가 준비됐는지를 반환해주기 (여기서는 notify의 의미를 어떤 소켓들이 준비됐는지 호출 결과를 반환함으로써 알려준다의 의미로 이해해주시는 것이 더 좋을 것 같습니다) 전까지는 해당 스레드 A는 더 이상 진행을 하지 못하고 결과를 얻을 때 까지 기다리게 됩니다 (호출 결과를 얻기까지 스레드는 그 호출에 blocking되기 때문에 이걸 blocking이라고 부르죠) 이 방식이 영상에서 설명했던 방식이었구요, 이후에 결과를 받게 되면, 스레드 A가 결과를 바탕으로 데이터가 준비된 소켓들을 루프를 돌면서 직접 하나하나씩 소켓들에 접근해서 처리해 줄 수도 있고요, 근데 그러면 순차적으로 작업해야해서 성능이 떨어지니까,, 데이터가 준비된 소켓들에 각각 스레드를 할당해서 각 스레드가 소켓에 있는 데이터들을 처리하게 만들어줄 수도 있는 것이죠 비유로 말씀해 주신 것은,, 조금 애매해서 일단 패스하겠습니다 3번 방식은 스레드가 I/O 작업을 OS에 요청할 때 ‘소켓에 데이터가 준비되면, 이런 이런 코드를 실행시켜주세요’라고 준비된 데이터를 어떻게 처리해야하는지 그 콜백 코드까지도 전달하는 방식이 콜백 방식이고요, 그래서 OS는 데이터가 준비되면 새로운 스레드 하나 만들어서 그 콜백 코드를 실행해서 병렬로 처리되도록 하는 방식이고요, 시그널 방식은, 미리 시그널 핸들러에 특정 시그널이 오면 어떻게 동작하라고 정의해 놓은 후에, 프로그램 실행 중에 스레드가 I/O 작업을 위해 OS에 요청하면, OS는 데이터가 준비되면 그 특정 시그널을 해당 스레드에 보내고, 그 특정 시그널을 받은 해당 스레드는 (마치 인터럽트 된 것처럼) 미리 시그널 핸들러에 정의됐었던 코드를 실행하는 형태로 처리하는 방식이에요 3번은 아직 잘 안쓰이는 것 같지만, 2번은 I/O multiplexing (가령 epoll) 관련 예제 코드를 찾아보시면 이해가 되실 것 같습니다 :) - 그리고 그 외의 질문들은 시간 관계상 답변드리기가 어려울 것 같아요 ㅠㅠ 기본적으로는 항상 자세히 설명드리고 싶은 마음이고 그러다 보니 답글을 달 때도 시간을 꽤 많이 쓰게 되더라고요ㅠㅠ 그래서 항상 자세히 답변을 드리기에는 시간적인 어려움이 있어서 혹시나 앞으로도 자세히 답변을 못하는 경우가 생기더라도 이해를 부탁드려요~! 항상 응원합니다 !! 👍
강의 잘 들었습니다! 20분 동안 계속 설명해 주시느라 힘드셨을거 같아요.. 그만큼 강의 내용이 너무 알찼습니다..! 저는 네트워크 공부가 처음이라 여러 번 듣고 있네요 ㅠ.. 혹시 강의 시간 10:50 초 즈음에 통신을 blocking 모드로 하면 안돼는 이유에 대해서 설명해 주셨는데요! 스레드와 프로세스 구분이 좀 어려워서요...ㅠ 저 핑크색 서버에서 보내주는 데이터를 blocking 모드로 기다리느라고, 다른 서버들에서 보내주는 데이터가 버퍼에 찾음에도 처리하지 못한다고 하셨잖아요! 그때 기준은 스레드가 아니구 프로세스 기준 아닌가요?... http 스레드의 경우에 로직에 api 통신을 해서 응답을 처리하는 부분이 있다고 하면 해당 스레드는 blocking i/o가 더 적합하지 않나 싶은 생각이 들었습니다.. 응답을 못받으면 다음 로직을 실행할 수가 없어서요! 제 생각을 정정해 주실 수 있으실까요!! 항상 강의 잘 듣고 있습니다 ㅎㅎ 여러 번 반복해서 들을만큼 너무 좋은 강의를 무료로 올려주셔서 참 감사합니다!
영상 언제나 꾸준히 봐주셔서 감사합니다 :) 기본 컴공 지식은 처음엔 어려울 수 있지만 개발에 근간이 되는 지식이기 때문에 도움이 되고자 열심히 정리해서 올리고 있어요 ㅎㅎ --- 질문 주신 부분 답변 드리면 우선 해당 예제는 서버 입장입니다 서버는 요청을 하는 존재가 아니라 요청을 받는 존재입니다 그렇기 때문에 해당 예제는 요청이 오길 기다리고 있는 상태를 설명하고 있는 것이에요 (요청을 받는 서버가 있다면 요청을 하는 존재가 있겠죠, 그걸 클라이언트라고 하는 거고요) 그리고 해당 예제는 서버가 여러 클라이언트와 커넥션을 맺고 요청을 기다리고 있는 상황입니다 그러면 서버 입장에서는 커넥션들 마다 요청이 왔는지를 확인하는 스레드가 있어야 하는데 그 스레드가 block으로 동작하게 되면 한 커넥션에 발이 묶여버릴 수 있는 문제점을 설명한 것이라고 이해해 주시면 되겠습니다 --- 언제나 열심히 하시는 모습이 멋지시고 저도 좋은 자극을 받습니다 👍
@@ez. 아...! 그러면 말씀하신 스레드가 "그러면 서버 입장에서는 커넥션들 마다 요청이 왔는지를 확인하는 스레드" 이거군요! 소켓의 상태를 체크하는 스레드가 프로세스마다 있다고 이해하면 될까요?? 와 정말 감사합니다...!! 항상 적게 일하시고 돈 많이 버시고 건강하세요!ㅎㅎ 앞으로도 꾸준히 공부하도록 하겠습니다 감사합니다!
@@weyoung1346 네, 맞습니다~ 서버는 동시에 들어오는 요청들을 어떻게 처리하는지에 따라 분류할 수 있는데요, 이 예제는 thread-per-request 로 동작하는 방식을 개념적으로 설명했다고 보시면 되겠습니다 자주 강조하는 것처럼, 언제나 디테일한 구현은 조금씩 다를 수 있습니다만 개념적으로 이해하시기에는 전혀 문제될 것이 없습니다 👍 좋은 말씀 해주셔서 감사해요 :) 자주 봐주시는 구독자님들 덕분에 저도 꾸준히 할 수 있네요 ㅎㅎ 우리 모두 화이팅입니다 !!
@@ez. 자꾸 여쭤봐서 죄송합니다 ㅠ 그럼 8080포트에 떠있는 A라는 프로세스의 소켓의 상태를 감지하는 스레드 ( q스레드 ) 가 하나 있고 , A 프로세스에 3명의 클라이언트가 요청을 보내 세 개의 소켓에 데이터가 들어오면 ,( 각 요청 w, e, r 스레드 ) q스레드가 소켓에 데이터가 들어온 것을 감지해서 프로세스 A에게 알려주는 형태로 동작하는 것일까요...???
@@weyoung1346 질문을 보다 보니 혹시 프로세스와 스레드에 대한 이해를 조금 헷갈려 하시는 것 같기도 해서요,ㅠㅠ 이에 대해 설명드리면, 프로세스는 메모리에 올라가서 사용자에 의해 '실행 중인 프로그램'을 의미하며 그 프로그램의 정보(메모리 주소 공간, 프로세스 ID 등등)이 OS에 의해 관리된다고 이해하시면 됩니다 그리고 프로세스는 최소 하나의 스레드를 무조건 가집니다 왜냐하면 스레드가 실제로 CPU 코어에서 실행되는 단위이기 때문입니다 그래서 실제로 CPU 코어에서 실행되는 것은 프로세스가 아니라 스레드입니다 이제 원래 질문에 대해 자세히 설명드리겠습니다~ 서버 프로그램을 실행하게 되면 그 프로그램에 대한 프로세스가 동작하게 됩니다 해당 프로세스는 기본적으로 하나의 스레드가 있을 거고 그 스레드가 서버소켓을 8080 포트로 열고 다른 클라이언트로부터 연결 요청이 들어오길 기다리고 있을 겁니다 이렇게 서버 소켓을 열고 기다리는 스레드를 설명의 편의를 위해 메인스레드라고 하겠습니다 그러면 메인스레드에서 열고 있던 서버소켓으로 여러 클라이언트들의 TCP 연결 요청이 들어오면 그때마다 TCP 연결을 맺은 소켓이 생성되는데 그 소켓마다 또다른 스레드를 만들어서 이후 소켓으로 들어오는 실제 요청을 처리하게 하는 방식이 thread-per-connection 입니다 하지만 이번 예제는 thread-per-request를 설명하는 예제입니다 이 방식은 소켓이 열릴 때 마다 스레드를 만들지 않습니다 (쉽게 설명하면) 클라이언트들로 부터 TCP 연결 요청을 받아서 연결을 맺으면 생성되는 소켓들을 따로 모읍니다 그러면 그 소켓들 중에서 실제 요청이 들어온 소켓들만 감지하는(I/O multiplexing) 목적의 스레드가 따로 있어서 그 스레드가 실제 요청이 들어온 소켓들에 대해서만 요청을 처리할 수 있도록 스레드들을 할당합니다 (보통 스레드풀을 통해 해결하겠죠, 영상에서도 잠시 이 얘기를 했고요) 예를 들어 서버와 TCP 연결을 맺고 있는 클라이언트가 열 개라고 해보겠습니다 참고로 TCP 연결은 서버와 연결 후에 클라이언트 요청이 처리되면 연결을 끊는 식으로 1회성으로 동작하지 않습니다 기본적으로 keep-alive가 적용되기 때문에 연결을 맺은 후에는 여러번 요청을 주고 받을 수 있습니다 그러면 그 열 개 중에 다섯 개의 연결에서만 실제 요청이 왔다고 해볼게요 그러면 연걸된 클라이언트 수는, 즉 서버 입장에서 열린 소켓 수는 열 개이지만, 다섯 개의 연결에서만 실제 요청이 왔기 때문에 (스레드풀 에서) 다섯 개의 스레드만 사용해서 요청을 처리하면 됩니다 이게 thread-per-request 방식이고, 만약 thread-per-connection 방식이라면 연결마다 스레드를 만들기 때문에 (메인 스레드를 제외하고) 열 개의 스레드가 사용될거에요 도움이 됐길 바라요 :) p.s. 다음에는 이렇게까지 자세히 설명드리지는 못할 수 있어요 ㅠ 제가 잘 설명드리고 싶은 마음에 답변을 생각보다 시간을 많이 써서 작성을 하기 때문에 전체적인 작성 시간이 꽤 되거든요 ㅠ 대신 어느 정도 설명도 드리면서 어떤 부분을 검색하시면 되는지 가이드를 같이 드리도록 할게요 👍
Mono.fromRunnable(() -> sysout(자바, 스프링 백엔드 3년차 개발자 입니다. 자바, 스프링에 대한 지식들만 공부하다가 네카라쿠배에 도전하고 싶어서 기초지식을 학습중인데 우연히 쉬운코드님의 채널을 알게되었습니다. 영상 하나하나가 너무 자세하고 딥하고 이해하기쉽게 설명해주셔서 정주행하고 있습니다. 또 좋은영상 부탁드리겠습니다.));
추가 코멘트 남깁니다
* 15:57 부터 나오는 시퀀스 다이어그램에서 signal의 경우에는 해당 다이어그램처럼 동작하는데, callback의 경우에는 data moved from kernel space to user space할 때 OS가 별도의 스레드를 만들어서 그 스레드에서 콜백 코드를 실행한다고 이해해주시면 되겠습니다
다이어그램 표현이 정확하지 않아서 죄송합니다 ㅠ
블로킹io와 넌블로킹io에 대한 개념을 정말 명확히 설명해주셔서 감사합니다. 진짜 자료 준비하고 동영상 촬영에 편집까지 하시느라 고생 많하셨습니다.
감사합니닷!!!! 조금씩 어떻게 공부해야하는지 점점 더 명확해지고 있어요!!! 쉬운코드님 강의 덕분이에요!!
와 들으면서 정리하고 있는데 이건 댓글을 남겨서 감사해야 할 정도로 너무 정리와 설명을 잘해주시네요ㅠㅠㅠ 글만으로는 이해하기가 조금 힘들었는데 덕분에 살았습니다... 감사해용...
정말 너무 너무 유익했습니다 ㅎㅎ 일년 전에 본 영상인데 지금 보니 또 다르게, 더 잘 이해 되네요! 감사합니다!
20분 순삭입니다 ㅋㅋ 설명을 정말 잘 하시네요. 머릿속에 있던 내용이 잘 정리됩니다. 감사합니다.
크 칭찬 감사합니다~~! (편집 기술이 많이 들어갔어요ㅎㅎ) 계속해서 좋은 영상으로 찾아뵐게용 :)
정말 좋은 영상입니다. 국내 블로그에 sync, async, blocking, non blocking을 설명하는 글들은 너무 추상적인 말로 설명이 되어 있어서 모호하다고 생각했었는데, 정말 궁금증이 한방에 해소되었습니다. 감사합니다.
와우 엄청난 칭찬의 말씀 감사드려요 👍👍👍
앞으로도 좋은 영상으로 찾아뵐게요
자주 놀러와주세용 ㅎㅎ
매번 가려운 곳을 긁어주는 영상 감사합니다!
크..! 감사합니다~! :) 효자손이 되겠습니다!!ㅎㅎ
명쾌하게 설명주는 좋은 영상 감사합니다ㅎㅎ
덕분에 막 멀티플렉싱 IO 웹서버 만들어가면서 공부했던게 단번에 되살아났네요ㅎㅎ :)
오우 리마인딩 영상이 됐군요 ㅎㅎ
유익하게 봐주셔서 감사합니다 :)
감사합니다 !!
정리가 잘 안되어 있는 내용들인데, 개념을 잘 정리할 수 있었습니다 ㅎㅎ
요번주제는 진짜 좀 어려운거같습니다...준비하시는게 영상은 20분이지만 뒤에 너무많은 노력이 있으셨을거같아요ㅠㅠ너무 고생하셨고 좋은영상 정말 감사합니다!!
우아 ㅠㅠ 보이지 않는 노력들까지도 생각해 주셔서 너무 감동입니다 ㅠㅠ 지수님은 천사시네요 :)
맞아요 이 내용이 조금 어려울 수 있어요 ㅠ 백발백중 시리즈 마무리 되면 구독자 분들이 어렵게 느끼셨던 내용들은 조금 더 보충해서 영상 만들어 보려구요 :)
와 정말 오랜만에 찐 강의를 만나뵙게 된 기분입니다. 정말 감사합니다. (block/non-block, sync/async의) 잘못 퍼져나간 지식도 바로 잡아주시는 점 너무 감사드립니다👍👍
좋게 봐주셔서 정말 정말 감사합니다 ㅠㅠㅠ 앞으로도 좋은 영상으로 꾸준히 인사드릴게요 :)
추천으로 다시 보게되었습니다 좋은 영상 고맙습니다 ㅎ
비전공자로서 IT 기업 입사를 앞두고 있어서,
OS 관련 영상 강의들을 보면서 공부하고 있었는데
정말 이해하기 쉽고 알찬 강의인 것 같습니다.
정말 감사힙니다~
감사합니다 ㅠㅠ 도움을 드리고 있는 것 같아서 저도 많이 뿌듯하네요 :)
새롭게 시작하는 회사 생활도 화이팅이에요!! 👍
이번 영상도 깊이있게 감사합니다. socket에 read/write buffer라는 개념이 있는지 몰랐네요 ㅎㅎ 번아웃 안오시도록 자주는 못올려주셔도 오래 계속하셨으면 좋겠네요 ㅎㅎ 잘보고갑니닷
크~~ 늘 응원해주셔서 정말 감사해요 👍👍👍
컨디션과 멘탈 관리 잘 해서 꾸준히 좋은 영상 올릴 수 있도록 하겠습니다 :)
오늘도 감사합니다 선생님.
내용 너무 마음에 들어요~~ 감사합니다. ^^
우아 댓글 감사해요~!!ㅠㅠ 앞으로도 마음에 쏙 드는 내용으로 찾아뵐게요 :)
준비하시느라 너무 고생 많으셨습니다! 좋은영상 감사합니다!
감사합니다~!! 늘 응원해 주시고 영상 유익하게 봐주셔서 감사해요 👍👍👍
이런 강의영상을 무료로 볼수있게 해주는 쉬운코드님께 무한한 감사를 보냅니다😊😊
좋게 봐주셔서 감사합니다 😄
새해에도 우리 모두 화이팅이에요~!!👍
수고많으셨습니다. 내용이 너무 알차고 많은 도움이되네요~ 감사합니다 ~^^
좋게 봐주셔서 감사합니다 😄
앞으로도 꾸준히 좋은 영상으로 인사드릴게요 :)
내용너무 좋습니다. 감사합니다
크ㅜㅜ 소중한 댓글 정말 감사해요 :) 계속해서 좋은 내용으로 찾아올게요~!
고생많으셨어요 유용한 정보 감사드립니다❤
유익하게 봐주셔서 정말 감사합니다 😍 👍
멤버십 가입도 정말 정말 감사합니다 ㅠㅠㅠㅠ
요번 주제는 좀 어려운 내용이네요ㅎㅎ 강의 준비 하시기 진짜 힘드셨을 것 같은데 고생 많으셨습니다!! 감사히 잘 보고 있습니다^^
와ㅜㅜ 알아주셔서 감사합니다 ㅜㅜ 댓글이 정말 큰 힘이 돼요~!! 계속해서 좋은 영상으로 보답할게요~!! 응원합니다~!!
보면 볼수록 너무 설명 잘하는데 조회수는 왜 줄어들까요?,, 저만 알고 싶지만 주변에서 cs지식 필요하다하면 꼭 추천하겠습니다..
우와ㅠㅠ 추천해주시면 정말 정말 감사하죠ㅠㅠ
혹시 재생목록에서 보고 계시는거라면 재생목록이 아마 조회수 높은 순으로 정렬되어 있을 거라서 아래로 갈수록 조회수가 줄어들 수 있을 거 같아요
면접볼때 신입이 이 정도 다 알고있으면... 프리패스일듯하네요
@@조바이든-r6r 오오 그 말은 쉬운코드와 함께라면 프리패스 카드를 얻어갈 수 있다고 봐도 되겠군요?! :)
강의 감사합니다! 영상 이것저곳에서 흘리신 땀이 묻어나오네요 :) 영상을 보면서 궁금한 점이 생겼습니다. async하다라는 말이 작업을 요청한 곳에서 처리하지않고, callback이나 event를 사용해서 나중에(작업이 완료되는 시점)에 다른 곳에서 처리되도록 하는걸로 이해했는데요! 그러면 '나중에 다른곳'에서 처리된다는 의미는 다른 thread를 의미하는건가요? 아니면 같은 thread에서 callback이 실행되는 것이 보장되나요?
앗 async라는 용어는 워낙 범용적으로 그리고 컨텍스트에 따라 조금씩 다른 의미로 사용되기 때문에 callback이나 event로 한정지어서 생각하시면 안될 수도 있습니다
'다른 곳에서' 처리된다는 얘기 자체는 콜백인 경우 콜백 코드가 다른 스레드에서 처리된다는 의미였고요, signal의 경우, signal handler를 등록해서 처리한다는 의미인데 이 경우에는 같은 스레드에서 처리가 될 겁니다
여하튼 핵심은 async라는 의미 자체는 워낙 다양해서요, 각 상황별로 어떤 의미로 사용되는지를 따로 영상으로 정리했는데요,
아래 영상을 봐주시면 도움이 되지 않을까 싶습니다 :)
ua-cam.com/video/EJNBLD3X2yg/v-deo.html
@@ez. 아아 생각보다 범용적인 개념이었군요. 답변 감사합니다!
진짜 좋네요 도움이 정말 많이됩니다!!
크~! 감사합니다 :)
자주 들러주세요~ 좋은 내용으로 늘 기다리고 있겠습니다 ㅎㅎ
최고입니다!!! 감사합니다👏👏👏
크~! 칭찬의 말씀 저도 정말 감사합니다!! 👍👍👍
안녕하세요 좋은 강의 들으면서 질문이 생겨 남깁니다.
python 이나 node js 는 싱글 쓰레드 기반이라고 알고 있습니다.
그런데 싱글 쓰레드 환경에서 Non-Block 상황이 조금 헷갈리는데요. I/O 오퍼레이션을 담당하는 OS kernel 의 쓰레드는 python 이나 node js 의 코드를 실행하는 쓰레드와 다른 쓰레드인건가요?
안녕하세요~ 우선 좋은 말씀 감사합니다 :)
python은 프로그래밍 언어이기 때문에 싱글 스레드 기반이라는 표현이 적절하진 않을 것 같구요, (혹시 GIL 때문에 그렇게 말씀하신 것이라면, GIL은 여러 스레드가 동시에 CPU 작업을 하지 못하게 막는 것이라서, 여러 스레드가 동시에 IO 작업을 하는 것은 가능합니다)
node.js 같은 경우에는 (제가 직접 써본적은 없어서 깊게는 모르지만) 하나의 메인 스레드가 이벤트루프 방식으로 동작을 할 때 여러 요청에 대해서 nonblock IO를 사용하며, 그래서 하나의 메인 스레드로 동작하는 것이 가능한 것으로 알고 있습니다. nonblock IO를 할 수 없는 상황인 경우에만 미리 만들어둔 스레드풀에 위임해서 처리하는 것으로 알고 있고요.
관련해서 구글링을 해보니 이런 글이 보이는데, 혹시 도움이 되실까 하여 남겨봅니다
tk-one.github.io/2019/02/07/nodejs-event-loop/
@@ez. 친절한 답변 정말 감사드립니다!
부족한 CS 공부를 하다보니, 뭔가 뒤죽박죽 헷갈리는게 많네요 ㅜㅜ
쉬운코드님 강의에서 많은 도움 받고있습니다. 정말 감사합니다!!
@@김지훈-c5x4z 크~! 저도 늘 애청해주셔서 항상 많이 감사해요 :)
계속해서 좋은 영상으로 도움 드릴 수 있도록 하겠슴당!
좋은 영상 감사합니다 :)
헤헤 감사합니당 :)
질문이 있습니다. select가 I/O 멀티플렉싱 분류에 속해있었는데 select는 반복적으로 소켓을 확인하니까 1번 반복적으로 확인하는 방법에 속하는거아닌가요?
select는 모든 fd에 대해서 read 시스템콜을 호출하는게 아니고 읽기가 준비된 fd에 대해서만 read 시스템콜을 호출하기 때문에 io멀티플렉싱인건가요? fd가 준비됐다는걸 확인하기 위해 반복문을 사용해서 주기적으로 체크는 하지만, 실제로 확인하는 방식이 read시스템콜을 이용한 확인이 아니라 io 멀티플렉싱 모델이라 하는게 맞을까요?
오~ 답변드릴게요~
I/O 멀티플렉싱은 한번에 여러 개의 소켓을 확인할 수 있음을 의미합니다
select 함수의 경우에도 여러 file descriptor(리눅스는 소켓도 file descriptor로 관리됨)에 대해서 감지하고픈 이벤트(read, write, etc)를 select 함수를 호출하면서 등록해 놓으면, 하나 이상의 file descriptor에서 관심있던 이벤트가 동시에 발생했을 때도 '한번에' 감지할 수 있습니다
그래서 감지된 file descriptor들을 FD_ISSET을 통해 확인하고 그 file descriptor들에 대해서만 read를 하면 됩니다
와 진짜 감사합니다. 제가 지금까지 봐 온 블로그, 유튜브, 인프런 강의 등등 중에서 최고입니다. 핵심은 다 담겨있으면서도 엄청 쉽게 설명해주시네요. 정말 잘 듣겠습니다!
우왕~~ 너무 너무 좋게 봐주셔서 정말 정말 감사합니다 👍👍👍
앞으로도 잘 부탁드립니다!
저도 화이팅할게요~!
설명 미쳣다
강의 잘 들었습니다! 오늘은 영상의 길이가 긴 만큼 내용이 이해하는데 어렵네요.
어려운 내용이라 그런지 댓글에도 여러 질문들이 있어서 읽다보니 제가 갖고 있던 의문이 해결되는 댓글도 있어서 좋았습니다.
그럼에도 질문거리가 남아있네요 하하...
강의 13:40 경에 설명하신 내용을 듣다보니, 밑에 있던 댓글과 관련해서 궁금한 내용이 생겨 질문드립니다.
밑에 댓글을 보니 여러 소켓들 중에서 실제 요청이 들어온 소켓들만 감지하는(I/O multiplexing) 목적의 스레드가 있어서, 실제 요청이 들어오게되면 이 스레드에 의해 요청이 들어온 연결에 스레드를 할당하여 요청을 처리한다고 되어있었는데요.
1. 그럼 강의 13:40 에서 그림에 나와있는 왼편에 있는 스레드도 IO multiplexing 목적의 스레드라고 할 수 있을 것 같은데, 해당 스레드가 시스템콜을 통해 커널로 하여금 IO가 수행되어 데이터가 들어오면 이를 다시 스레드에게 notify 해주는 매커니즘으로 동작하고, 그 밑에서 데이터를 옮긴다고 되어있네요. 그럼 밑에서 실질적인 데이터를 옮기는 작업은 실제 요청이 들어온 연결에 할당된 스레드에서 수행되는 것인가요? 만약 맞다면, io multiplexing 스레드에서 request 처리 스레드로 어떻게 이를 알리는 것인지 궁금합니다. (아니면, io multiplexing thread가 커널에 요청할 때 어떤 소켓에 대해서 모니터링을 요청하는지 식별값을 전달할테니, 커널이 직접적으로 개입하여 데이터가 들어온 소켓에게 할당되는 스레드에 직접 signal을 날리는 것인지...?)
2. 13:40 의 그림 같은 경우는 io multiplexing 스레드가 시스템콜을 요청한 이후에, blocked 된 상태인데, 물론 설명을 통해 시스템콜 요청 이후에도 run 할 수 있게 코드를 작성할 수 있다고 하셨지만, 강의의 경우에는 non blocking io 가 아니라 blocking io 로 보는게 맞는건가요? 만약 run할 수 있게도 코드를 작성할 수 있다면, 마지막의 ibm의 표에서는 blocking과 non-blocking 모두에 속할 수 있는 것인가요..?
3. non-blocking io를 해결하기위해 사용하는 방법론중 3번에 해당하는 callback/signal이 잘 사용되지 않는 이유가 따로 있을까요? 그리고, 결국 2번 io multiplexing도 여러 소켓에 대해 여러 동작(read, write, 등)을 모니터링할 수 있는 장점이 있지만, 마지막에 이를 실제 스레드가 처리하기 위해서는 커널이 notify를 해주어야하는데 그럼 3번의 부분집합이라고 볼 수 있지 않나요?
4. 영상의 말미에 synchronous와 asynchronous 의 설명에서 asynchronous의 경우는 io를 요청한 당사자가 결과까지 직접 챙기는 것이 아닌, 커널로부터 notify를 받거나 callback 형태로 동작한다고 하셨습니다.
유저레벨에 있는 스레드는 직접 io할 수 없기 때문에, 무조건 시스템콜로 커널을 통해서 io를 수행해야하는데, 커널에서 하드웨어와 io를 마치고나서 다시 유저 스레드로 io가 끝났음을 알려주는 인터럽트 같은 notify가 있기 때문에, 이러한 인터럽트성 notify를 제외한 제 3의 스레드가 개입된 흐름(여기서는 kernel -> io multiplexing thread -> requset 처리 thread)과 AIO의 callback or signal 메커니즘을 말하는 것인가요?
질문을 항상 받아주셔서 감사드립니다.
댓글까지 꼼꼼히 봐주시고 역시 최고십니다 !!ㅎ
답변 드리겠습니다!!
1. 네, 맞습니다. I/O multiplexing을 통해 어느 소켓에 데이터가 들어왔는지 감지가 됐기 때문에, 그 소켓에서 실제로 데이터를 읽게 되는 스레드가 해당 요청을 처리하는 식으로 많이들 동작합니다
어떤 스레드에게 어떤 소켓을 할당할지는 구현하기 나름일 것 같은데요. 이번 영상에서는 스레드풀을 활용하는 방법을 소개하긴 했습니다~ 아주 추상적으로 설명드리면, 스레드풀에 작업을 할당할 때 할당할 소켓만 구분해서 할당하면 될 것 같습니다
2. 약간 다릅니다. block이 되는 것은 I/O 작업이 아니라 I/O multiplexing 함수입니다. 영상에서는 I/O multiplexing을 제공하는 시스템콜을 블락으로 호출한 경우로 가정하고 설명한 것이고요, 소켓 자체는 nonblock I/O로 동작하도록 설정해줘야 합니다
3.
>> non-blocking io를 해결하기위해 사용하는 방법론중 3번에 해당하는 callback/signal이 잘 사용되지 않는 이유가 따로 있을까요?
이건 저도 잘 모르겠네요. 여러 사정이 있을 수 있는데, 적극적으로 개발이 되고 있지는 않는 것 같더라고요
>> 결국 2번 io multiplexing도 여러 소켓에 대해 여러 동작(read, write, 등)을 모니터링할 수 있는 장점이 있지만, 마지막에 이를 실제 스레드가 처리하기 위해서는 커널이 notify를 해주어야하는데 그럼 3번의 부분집합이라고 볼 수 있지 않나요?
2번의 notify가 된다는 의미는 스레드가 딴 작업을 하고 있는데 OS가 쿡 찔러서 요청한 I/O 작업 데이터 준비 됐다고 알려준다는 그 의미는 아니고요, ‘소켓들에 데이터가 준비돼어 있다’를 “알려준다”는 의미로 notify를 사용했습니다
그렇기 때문에 2번의 경우에는 I/O multiplexing 시스템콜을 사용하면, 준비된게 있다고 응답받으면 그 후처리를 또 해줘야 하고
3번은 일단 시스템콜로 I/O 작업을 요청하면 요청한 그 스레드는 더 이상 신경쓸 필요가 없기 때문에 2번과는 좀 다르죠
* 참고로 설명하다가 발견한 것인데요, 영상에서 16:00에 사용된 슬라이드에서 callback과 signal 둘 다, 호출한 스레드해서 처리되는 것처럼 그렸는데요, signal은 이렇게 동작하는데 callback은 스레드 하나를 새로 만들어서 처리하는 방식입니다
제가 오해가 생기게끔 잘못 표현한 부분입니다 ㅠ (시그널은 보시는 것과 같이 동작합니다, 인터럽트 처럼 동작하는 거라서요)
4. 죄송해요.. 이건 제가 어떤 질문인지 정확히 파악을 못했습니다 ㅠㅠ
@@ez. 항상 빠르고 정성스러운 답변 감사드립니다.
답변을 읽고나서 제 생각을 공유드리고 질문도 같이 드립니다 ㅎㅎ
3번의 경우는 개념적으로는 상당히 명료한 편이라서 이해하는데는 그렇게 어려움이 들진 않는데, 역시 이해하기 상대적으로 난해한건 2번인거 같아요.
제가 질문 2번으로 드렸던 "io multiplexing이 signal/callback 매커니즘의 부분집합으로 볼 수 있지 않나요?" 라는 질문에 답변을 통해 제가 이해한 두 방법론의 가장 큰 차이점을 말씀 드리자면,
만약 io의 전체 과정을
1. 외부 네트워크로부터 데이터를 로컬 컴퓨터의 소켓 버퍼(커널 영역 메모리)로 읽어옴.
2. 소켓 버퍼에 들어있는 데이터를 유저 스페이스 메모리로 읽어옴.
이렇게 크게 2개로 나눴을때,
io multiplexing의 경우 1번 단계 + 데이터가 들어왔는지 monitoring을 io multiplexing 스레드가 담당하고, 2번 단계를 요청을 처리하는 스레드가 담당한다고 이해했습니다. 그래서 답변에
"소켓 자체는 nonblock I/O로 동작하도록 설정해줘야 합니다" 라고 해주셨구요.
signal/callback의 경우 전체과정을 한 스레드가 모두 처리하고, 데이터가 준비되는 동안 non-blocking 방식으로 동작하다가 데이터가 준비되면 signal 혹은 callback의 형태로 2번 단계가 수행된다고 이해했습니다.
일상생활에 비슷한 경우를 예로 들어보자면, multiplexing은 부모님과 아이가 같이 놀이공원을 갔을 때, 부모님이 아이 대신 놀이기구의 줄을 서주시다가 본인 차례가 되었을 때, 아이에게 그 자리를 양보하는 경우가 떠올랐습니다. 부모님이 놀이기구를 탈 수 있는 순서(서버로 들어오는 요청)를 대신 기다리고, 순서가 왔을 때, 아이에게 놀이기구 탑승을 넘겨준 것이죠. (이후의 non-blocking 상황은 이해의 편의상 제외했습니다.)
signal/callback 의 경우 놀이기구에 탑승시간을 예약하는 시스템이 있어서, 아이가 혼자 놀이기구 탑승시간을 예약해놓고, 다른 일을 하고 있다가(non-blocking) 본인의 순서가 오면 핸드폰으로 탑승 알림이 오는 상황이 생각났습니다. (알림이 다시 오더라도 read 요청을 할 필요가 없는 경우죠.)
쓰다보니 글이 길어졌는데 읽어주셔서 감사합니다.
======================================================================
+ 추가적으로 질문이 또 생겨버려서 고견 부탁드립니다.
"스레드가 딴 작업을 하고 있는데 OS가 쿡 찔러서 요청한 I/O 작업 데이터 준비 됐다고 알려준다는 그 의미는 아니고요, ‘소켓들에 데이터가 준비돼어 있다’를 “알려준다"
===> 이 답변에서 소켓들에 데이터가 준비되어 있음을 커널이 io multiplexing 수행 스레드에게 알려주는 것이고, 이 알림을 받은 io multiplexing 스레드가 준비된 데이터를 읽고 처리할 새로운 스레드를 만들어서 처리하는 것으로 이해했습니다.
여기서 커널이 io meltiplexing 스레드에게 단순히 io interrupt 같은 것으로 알림을 주는 건가요?
또, 만약에 io multiplexing 의 경우 데이터가 준비되었다는 것을 알림을 받고난 후에 요청을 처리하는 스레드가 소켓버퍼에서 유저스페이스 메모리로 데이터를 가져올 텐데, 이 때 read를 non-blocking으로 하는 이유는 데이터를 가져오는 동안 cpu를 낭비하지 않기 위함인가요? 데이터가 이미 소켓에 준비되어있다는 것을 알고 있기 때문에, 만약에 하고자하는 작업이 io 밖에 없다면 block과 non-block의 성능차이가 없을 것 같아서요.
p.s. 4번 질문은 단어적인 헷갈림 때문인지라 없는 질문이라고 생각해주셔도 될 것 같습니다.
항상 감사합니다!
@@세승-v4s
제가 아무래도 설명을 잘 못한 것 같아요 ㅠㅠ
좀 더 설명을 드리자면
2번 방식
스레드가 I/O multiplexing 시스템콜을 호출하게 되면 한번의 호출로도 관심있던 소켓들 중에서 어느 소켓들에 실제로 데이터가 준비됐는지를 OS가 확인하고 반환해 줍니다
예를 들어 스레드 A가 I/O multiplexing 시스템콜을 blocking으로 호출하게 되면 OS가 어느 소켓들에 실제로 데이터가 준비됐는지를 반환해주기 (여기서는 notify의 의미를 어떤 소켓들이 준비됐는지 호출 결과를 반환함으로써 알려준다의 의미로 이해해주시는 것이 더 좋을 것 같습니다) 전까지는 해당 스레드 A는 더 이상 진행을 하지 못하고 결과를 얻을 때 까지 기다리게 됩니다 (호출 결과를 얻기까지 스레드는 그 호출에 blocking되기 때문에 이걸 blocking이라고 부르죠)
이 방식이 영상에서 설명했던 방식이었구요,
이후에 결과를 받게 되면, 스레드 A가 결과를 바탕으로 데이터가 준비된 소켓들을 루프를 돌면서 직접 하나하나씩 소켓들에 접근해서 처리해 줄 수도 있고요, 근데 그러면 순차적으로 작업해야해서 성능이 떨어지니까,, 데이터가 준비된 소켓들에 각각 스레드를 할당해서 각 스레드가 소켓에 있는 데이터들을 처리하게 만들어줄 수도 있는 것이죠
비유로 말씀해 주신 것은,, 조금 애매해서 일단 패스하겠습니다
3번 방식은
스레드가 I/O 작업을 OS에 요청할 때 ‘소켓에 데이터가 준비되면, 이런 이런 코드를 실행시켜주세요’라고 준비된 데이터를 어떻게 처리해야하는지 그 콜백 코드까지도 전달하는 방식이 콜백 방식이고요, 그래서 OS는 데이터가 준비되면 새로운 스레드 하나 만들어서 그 콜백 코드를 실행해서 병렬로 처리되도록 하는 방식이고요,
시그널 방식은, 미리 시그널 핸들러에 특정 시그널이 오면 어떻게 동작하라고 정의해 놓은 후에, 프로그램 실행 중에 스레드가 I/O 작업을 위해 OS에 요청하면, OS는 데이터가 준비되면 그 특정 시그널을 해당 스레드에 보내고, 그 특정 시그널을 받은 해당 스레드는 (마치 인터럽트 된 것처럼) 미리 시그널 핸들러에 정의됐었던 코드를 실행하는 형태로 처리하는 방식이에요
3번은 아직 잘 안쓰이는 것 같지만, 2번은 I/O multiplexing (가령 epoll) 관련 예제 코드를 찾아보시면 이해가 되실 것 같습니다 :)
-
그리고 그 외의 질문들은 시간 관계상 답변드리기가 어려울 것 같아요 ㅠㅠ
기본적으로는 항상 자세히 설명드리고 싶은 마음이고 그러다 보니 답글을 달 때도 시간을 꽤 많이 쓰게 되더라고요ㅠㅠ 그래서 항상 자세히 답변을 드리기에는 시간적인 어려움이 있어서 혹시나 앞으로도 자세히 답변을 못하는 경우가 생기더라도 이해를 부탁드려요~!
항상 응원합니다 !! 👍
대단하십니다..
엄청난 칭찬 감사합니다 :)
강의 잘 들었습니다! 20분 동안 계속 설명해 주시느라 힘드셨을거 같아요..
그만큼 강의 내용이 너무 알찼습니다..! 저는 네트워크 공부가 처음이라 여러 번 듣고 있네요 ㅠ..
혹시 강의 시간 10:50 초 즈음에 통신을 blocking 모드로 하면 안돼는 이유에 대해서 설명해 주셨는데요!
스레드와 프로세스 구분이 좀 어려워서요...ㅠ
저 핑크색 서버에서 보내주는 데이터를 blocking 모드로 기다리느라고,
다른 서버들에서 보내주는 데이터가 버퍼에 찾음에도 처리하지 못한다고 하셨잖아요!
그때 기준은 스레드가 아니구 프로세스 기준 아닌가요?...
http 스레드의 경우에 로직에 api 통신을 해서 응답을 처리하는 부분이 있다고 하면
해당 스레드는 blocking i/o가 더 적합하지 않나 싶은 생각이 들었습니다..
응답을 못받으면 다음 로직을 실행할 수가 없어서요!
제 생각을 정정해 주실 수 있으실까요!!
항상 강의 잘 듣고 있습니다 ㅎㅎ 여러 번 반복해서 들을만큼 너무 좋은 강의를 무료로 올려주셔서 참 감사합니다!
영상 언제나 꾸준히 봐주셔서 감사합니다 :)
기본 컴공 지식은 처음엔 어려울 수 있지만 개발에 근간이 되는 지식이기 때문에 도움이 되고자 열심히 정리해서 올리고 있어요 ㅎㅎ
---
질문 주신 부분 답변 드리면
우선 해당 예제는 서버 입장입니다
서버는 요청을 하는 존재가 아니라 요청을 받는 존재입니다
그렇기 때문에 해당 예제는 요청이 오길 기다리고 있는 상태를 설명하고 있는 것이에요
(요청을 받는 서버가 있다면 요청을 하는 존재가 있겠죠, 그걸 클라이언트라고 하는 거고요)
그리고 해당 예제는 서버가 여러 클라이언트와 커넥션을 맺고 요청을 기다리고 있는 상황입니다
그러면 서버 입장에서는 커넥션들 마다 요청이 왔는지를 확인하는 스레드가 있어야 하는데
그 스레드가 block으로 동작하게 되면 한 커넥션에 발이 묶여버릴 수 있는 문제점을 설명한 것이라고 이해해 주시면 되겠습니다
---
언제나 열심히 하시는 모습이 멋지시고 저도 좋은 자극을 받습니다 👍
@@ez. 아...! 그러면 말씀하신 스레드가 "그러면 서버 입장에서는 커넥션들 마다 요청이 왔는지를 확인하는 스레드" 이거군요!
소켓의 상태를 체크하는 스레드가 프로세스마다 있다고 이해하면 될까요??
와 정말 감사합니다...!!
항상 적게 일하시고 돈 많이 버시고 건강하세요!ㅎㅎ 앞으로도 꾸준히 공부하도록 하겠습니다 감사합니다!
@@weyoung1346 네, 맞습니다~
서버는 동시에 들어오는 요청들을 어떻게 처리하는지에 따라 분류할 수 있는데요,
이 예제는 thread-per-request 로 동작하는 방식을 개념적으로 설명했다고 보시면 되겠습니다
자주 강조하는 것처럼, 언제나 디테일한 구현은 조금씩 다를 수 있습니다만
개념적으로 이해하시기에는 전혀 문제될 것이 없습니다 👍
좋은 말씀 해주셔서 감사해요 :)
자주 봐주시는 구독자님들 덕분에 저도 꾸준히 할 수 있네요 ㅎㅎ
우리 모두 화이팅입니다 !!
@@ez. 자꾸 여쭤봐서 죄송합니다 ㅠ
그럼 8080포트에 떠있는 A라는 프로세스의 소켓의 상태를 감지하는 스레드 ( q스레드 ) 가 하나 있고 ,
A 프로세스에 3명의 클라이언트가 요청을 보내 세 개의 소켓에 데이터가 들어오면 ,( 각 요청 w, e, r 스레드 )
q스레드가 소켓에 데이터가 들어온 것을 감지해서 프로세스 A에게 알려주는 형태로 동작하는 것일까요...???
@@weyoung1346
질문을 보다 보니 혹시 프로세스와 스레드에 대한 이해를 조금 헷갈려 하시는 것 같기도 해서요,ㅠㅠ 이에 대해 설명드리면,
프로세스는 메모리에 올라가서 사용자에 의해 '실행 중인 프로그램'을 의미하며 그 프로그램의 정보(메모리 주소 공간, 프로세스 ID 등등)이 OS에 의해 관리된다고 이해하시면 됩니다
그리고 프로세스는 최소 하나의 스레드를 무조건 가집니다
왜냐하면 스레드가 실제로 CPU 코어에서 실행되는 단위이기 때문입니다
그래서 실제로 CPU 코어에서 실행되는 것은 프로세스가 아니라 스레드입니다
이제 원래 질문에 대해 자세히 설명드리겠습니다~
서버 프로그램을 실행하게 되면 그 프로그램에 대한 프로세스가 동작하게 됩니다
해당 프로세스는 기본적으로 하나의 스레드가 있을 거고 그 스레드가 서버소켓을 8080 포트로 열고 다른 클라이언트로부터 연결 요청이 들어오길 기다리고 있을 겁니다
이렇게 서버 소켓을 열고 기다리는 스레드를 설명의 편의를 위해 메인스레드라고 하겠습니다
그러면 메인스레드에서 열고 있던 서버소켓으로 여러 클라이언트들의 TCP 연결 요청이 들어오면
그때마다 TCP 연결을 맺은 소켓이 생성되는데 그 소켓마다 또다른 스레드를 만들어서 이후 소켓으로 들어오는 실제 요청을 처리하게 하는 방식이 thread-per-connection 입니다
하지만 이번 예제는 thread-per-request를 설명하는 예제입니다
이 방식은 소켓이 열릴 때 마다 스레드를 만들지 않습니다
(쉽게 설명하면) 클라이언트들로 부터 TCP 연결 요청을 받아서 연결을 맺으면 생성되는 소켓들을 따로 모읍니다
그러면 그 소켓들 중에서 실제 요청이 들어온 소켓들만 감지하는(I/O multiplexing) 목적의 스레드가 따로 있어서
그 스레드가 실제 요청이 들어온 소켓들에 대해서만 요청을 처리할 수 있도록 스레드들을 할당합니다 (보통 스레드풀을 통해 해결하겠죠, 영상에서도 잠시 이 얘기를 했고요)
예를 들어 서버와 TCP 연결을 맺고 있는 클라이언트가 열 개라고 해보겠습니다
참고로 TCP 연결은 서버와 연결 후에 클라이언트 요청이 처리되면 연결을 끊는 식으로 1회성으로 동작하지 않습니다
기본적으로 keep-alive가 적용되기 때문에 연결을 맺은 후에는 여러번 요청을 주고 받을 수 있습니다
그러면 그 열 개 중에 다섯 개의 연결에서만 실제 요청이 왔다고 해볼게요
그러면 연걸된 클라이언트 수는, 즉 서버 입장에서 열린 소켓 수는 열 개이지만, 다섯 개의 연결에서만 실제 요청이 왔기 때문에 (스레드풀 에서) 다섯 개의 스레드만 사용해서 요청을 처리하면 됩니다
이게 thread-per-request 방식이고, 만약 thread-per-connection 방식이라면 연결마다 스레드를 만들기 때문에 (메인 스레드를 제외하고) 열 개의 스레드가 사용될거에요
도움이 됐길 바라요 :)
p.s.
다음에는 이렇게까지 자세히 설명드리지는 못할 수 있어요 ㅠ
제가 잘 설명드리고 싶은 마음에 답변을 생각보다 시간을 많이 써서 작성을 하기 때문에 전체적인 작성 시간이 꽤 되거든요 ㅠ
대신 어느 정도 설명도 드리면서 어떤 부분을 검색하시면 되는지 가이드를 같이 드리도록 할게요 👍
잘들었습니다! 요즘엔 업로드를 안하시는데 무슨일 있으신가요 ㅠㅠ
ㅠㅠ 걱정해 주셔서 감동입니다 🥹
저희 첫째가 2주간 방학이었어서 놀러다니면서 같이 시간보내느라 못 올렸어요
오늘 곧 새 영상이 하나 올라갑니다 !
다시 열심히 달려볼게요~! 👍
더럽게 광고 많이 해서 안 본다
별 대단한 내용도 아닌데 광고가 이렇게 많냐
Mono.fromRunnable(() -> sysout(자바, 스프링 백엔드 3년차 개발자 입니다.
자바, 스프링에 대한 지식들만 공부하다가 네카라쿠배에 도전하고 싶어서 기초지식을 학습중인데 우연히 쉬운코드님의 채널을 알게되었습니다.
영상 하나하나가 너무 자세하고 딥하고 이해하기쉽게 설명해주셔서 정주행하고 있습니다.
또 좋은영상 부탁드리겠습니다.));
좋은 영상 감사합니다 :)