설명 어렵게하거나 책만 읽는 엉터리 강사, 대학 교수들도 많고, 제목은 쉽다면서 내용은 엉터리 백과사전같은 책이나 글이 워낙 많다보니 정말 나한테 도움되는 자료를 찾지 못하고 힘들게 해맬때가 많았습니다. 그러다가 유튜브 알고리즘 덕분에 오게됬는데 이렇게 개념을 명쾌하고 쉽게 설명해주는건 처음봤어요. 너무 속시원하네요 ㅠㅠ 좋은 강의 감사합니다.
ACK , Wait , TCP buffer -> File IO buffer 로 read하는 속도 , 수신측의 window size 이 4가지의 관계에 대해서 배웠네요. 또한 wait의 존재 때문에 TCP 와 UDP의 속도 차이가 난다는 사실 도 배웠습니다. 일단 한번 강의를 쭉 들었지만 , 중요한 내용이므로 다음에 또 복습 하도록 하겠습니다. 항상 좋은 강의 감사드립니다.
대략 Segment가 두 개 정도 오게 되면 즉시 다음 차례인 3번을 보내는 게 아니고 ACK#3이 올 때까지 Wait를 한다. 여기서 속도 지연이 발생한다. TCP가 UDP보다 느린 이유 중의 하나이다. TCP Buffer의 크기는 Window Size라고 불리는데 수신 측에서 Segment가 날라오면 조립해서 넣을 수 있는 공간을 의미하며, ACK를 보낼 때 Window Size를 포함하고 있다. 수신 측의 Window Size가 MSS보다 크다면 3번을 보내고 그렇지 않다면 Wait가 걸린다. TCP Buffer에서 File I/O Buffer로 Segment를 빨리 퍼올리지 못하면, (즉 Read속도가 Network수신속도보다 느리면) TCP Buffer의 여유공간은 점점 줄어들게 될 것이고 Wait가 걸려서 속도지연이 생기게 된다..! 그림으로 그려주시면서 상세한 과정을 택배에 빗대어 설명해주시니까 도움이 많이 됩니다 감사합니다!
와... 오늘 내용이 얼마나 많은 주제에 대해서 다루는 건지 ㅋㅋㅋ 널널한 개발자님처럼 이 내용을 잘 추상화해서 그림 한 장으로 표현하실 수 있으려면 네트워크에 대해 얼마나 많이 알아야 하는 걸까요 주니어 입장에서 너무 좋은 내용 가르쳐주셔서 감사합니다. 늘 많이 배웁니다 선생님 :D Process가 File에 할 수 있는 Operation : RWX 소켓에 대해 읽는다 -> Receive 소켓에 대해 쓴다 -> Send => 서버 프로세스가 Socket에 대고 IO를 한다 파일을 잘개 쪼개 버퍼에 올리고, 버퍼 내용을 복사해서 Send한다 => Buffered I/O 이때 Buffer에 담긴 쪼갠 파일도 Segment(4계층) 단위로 쪼개고, header를 붙여 Packet(3계층)으로 만들어 전송한다. 패킷은 논리적으로 End-to-End로 전송되지만, Frame 자체는 2계층에서 전송되며 최종 원하는 단말로 전송될 때까지 계속 갈아 끼워진다. MAC 주소를 활용한 동일한 물리적 네트워크 단위의 통신인 이더넷 프로토콜 전송이기 때문이다. 클라이언트에서 Segment를 받으면 다음 Segment 번호에 대해 요청으로 ACK를 반환한다. ACK 메세지에는 클라이언트의 TCP Buffer의 가용 영역인 Window Size를 포함한다. 사실 서버에서는 Segments를 보낸 상태에서 WAIT하고 있었다. 이제서야 잘 보낸 것을 확인하고 다음 Segment를 보낸다. 이러한 WAIT이 TCP 성능 저하의 원인 이러한 무작정 WAIT하는 전략의 성능 이슈를 막기 위해 등장한 전략이 있다. Window Size > Maximum Segment Size ? YES : NO(then Wait) Receive Process가 Socket에 대하여 TCP Buffer를 읽으면 Read 속도 > Network 속도 ? YES : TCP Buffer Size가 작아지며 처리 지연 현상 발생 따라서 처리 지연 문제 발생시 장애 원인을 Network가 아니라 프로그램 구조에서 찾아야 한다 !!일단 Process가 TCP Buffer를 읽는 속도가 얼마나 빠른지 확인하라. Network에서 수신하는 속도보다 무조건 빨라야 병목이 발생하지 않는다!!
저는 공공기관에서 기반시설을 담당하고 있는 사람인데요 IT를 공부하는 또는 관련 직종에 종사하는 모든 분들이 이 영상을 보셨으면 좋겠네요 정말 유익한 정보이자 실무자에게 반드시 필요한 지식입니다 대부분 필드에서 서버, 보안, 네트워크, 개발자, PC 담당자가 서로 바쁘다가 늘 쟁점대서 싸우는 상황이 바로 '속도가 느리다' 인데요 이영상을 보고 저도 많이 몰랐고, 많이 오해했다는 것을 깨닫고 갑니다 나아가 얼마나 네트워크 통신에서 '소통'이 중요한가를 다시한번 느끼게 되네요 정말 감사하고 앞으로도 두고두고 돌려보도록 하겠습니다 감사합니다.
너무 좋은 강연 감사드립니다. 비전공자이며 제조업 종사자입니다. 현업에서 '서버, MES, 방화벽,클라이언트' 간 통신 이슈로 네트워크 업체를 닥달해서 패킷 단위를 변경해서 해결한 문제가 하나 있었는데, 이 영상을 보니 클라이언트쪽 소프트웨어 개발 문제였던 것 같네요. 네트워크는 정말 어렵네요.
음...MES 환경에서는 더 예외적인 일들이 자주 벌어집니다. 소위 IoT 장치들이 많기 때문입니다. 그래도 어떻게든 해결은 하신 것 같아 다행입니다. 이미 관련한 노하우를 가지고 계시겠으나 향후 그런 문제가 반복된다면 반드시 패킷 덤프를 분석해보실 것을 강력히 권합니다. 감사합니다. :)
오~ 좋은 강의 입니다. TCP/IP 관련되어 처음 접근 하시는 분들이 실수 하시는부분 몇가지입니다. LAB 환경에서만 제대로 된다고 실제 환경이 되면 다양한 상황이 될수가 있습니다. 그래서 1. 소켓은 무조건 ASYNC 소켓으로 작성을 하세요. 이건 CONNECT 분만 아니라 송수신에서도 중요합니다. ASYNC 소켓은 함수 리턴값이 아니라 에러코드값으로 판단하면 됩니다. 2. 송/수신은 반드시 지정된 크기가 전송될때까지로 해야 합니다. 즉, 100 바이트 전송을 send 함수로 넘겨만 주었다고 무조건 100 바이트 전송이 이루어지는건 아닙니다. 90바이트 10바이트 전송이 가능합니다. TCP/IP 통신은 전송을 게런티 해주지, 전송 시간(지금 당장)까지 게런티 해주는게 아닙니다. 이 모든것들은 통신이라는것이 중간에 여러 통신 기기(주로 라우터)들을 거쳐서 이루어 지기 때문에 이곳에서 우선권(QoS 등등)을 지닌 패킷과 MTU 크기등에 따라 프레그먼트가 발생하게 됩니다. 즉, A --- > B --- > D 라우터를 통하는게 아니라 A--- > B, A--->C B-->D , C--->D 이런식으로 패킷이 분리되어 전송이 가능한것입니다. 에플리케이션 레이어에서는 몰라도 되는것이지만 이상한 상황이 발생한다면 대부분 이곳에서 발생하는 것이기에 1,2번은 반드시 지키면서 하시면 큰 무리는 없을겁니다. 자신만의 ASYNC 소켓과 (주로 접속 관련) 전송 함수들을 만들어 놓으면 평생 사용하시면 됩니다. L3 쪽에 관심이 있으시면 WIRESHARK 같은거 켜놓으시고 IP/TCP 헤더 부분만 잘 보셔도 큰 도움이 되실겁니다. ^^
좋게 봐주셔서 감사합니다. 다만...몇 가지는 바로 잡는 것이 좋겠습니다. C/C++ 개발자 관점에서 보면 Async 소켓으로 반드시 작성해야 하는 것은 아닙니다. 물론 서버가 극한의 성능을 발휘하기 위해서는 IOCP나 epoll같은 비동기 구조를 채택 할 수 밖에 없습니다. 그리고 단편화가 발생하는 가장 큰 이유중 하나는 VPN 입니다. L3 수준 터널링이 적용되고 심지어 중첩될 경우 단편화가 발생 할 수 있습니다. 더불어 알아두시면 도움이 될 것 같습니다. 좋은 정보와 의견 고맙습니다. :)
클라우드 엔지니어로 취직한지 3개월 째 되는 병아리입니다. 퀄리티 있는 강의 감사드립니다. 언제나 보기 좋게 이미지로 설명해주셔서 읽기 능력이 떨어지는 저에게 너무 좋은 강의 같아요. 지금 구축 프로젝트에 투입되었는데 네트워크가 부족해서 개발자님의 네트워크 기초 이론 꼬박꼬박 듣고 있습니다. 인프런 강의도 조만간 사서 듣고 역량을 키워보겠습니다.
임베디드 SW 개발 분야에 최근 입사한 쌩신입입니다. 업무를 위해 여러 CS 강의를 듣던 중인데, 파일이 분해 및 재조립되는 과정을 퍼즐에 비유하신 부분을 듣고 정말 감탄했습니다... 비전공자나 CS 관련 지식이 얕은 사람이 들어도 정말 중요한 정보를 이렇게 쉽게 가르칠 수 있다는 점이 정말 대단한 것 같습니다.
이 영상이 중요한 이유: 원인이 어디인가를 찾을때 굉장히 유용하다. 내 pc의 window size가 작아서 나타나는 버그인데 네트워크단만 주구장창 봐봤자 문제해결을 할 수 없다. 이것 때문에 인생이 바뀐다고 하신거 같습니다. 약간 어그러성 발언도 있는건 같은데 어느 부분 맞기도 하죠.
음...제 의도를 말하자면...대부분 한 가지만 보기 때문입니다. End-point만 보거나 Network만 보거나...결국 그 둘을 같이 봐야 한다는 것이죠. 시야를 넓히면 확실히 업그레드 됩니다만...인생이 바뀌는 수준이 될 지는 상대적인 측면이 있습니다. 그러니...초보 유튜버의 어그로 정도로 이해해주시면 좋겠습니다. ^^
와. tcp,ip 통신의 원리를 이리 쉽게 잘 이해하시는분은 첨보네요. 와이어샥 패킷분석할때 정말 필요한정보라 여러번 들었습니다. 학부때 책에서 들었을때 이해가 안갔는데 네트웍 문제있어서 와이어샥 패킷분석하느라 이론책을 엄청 들어다보고도 잘 이해가 잘 안갔는데 선생님 설명듣고 10년만에 이해했습니다. 너무 감사해요. 이걸 알아야 딜레이현상에 대해 분석이 가능하더라구요.
예전에 cpp에서 시리즈 넘버 순서대로 패킷 쌓아서 Struct 만들고 데이터 뽑아내는 업무를 한 적이 있었는데 그 내면에 ack 3번의 내용은 정말 신세계네요~!! 좋은 설명 감사합니다! ack 3번의 wait로 인한 지연('tcp는 udp에 비해 느리다'라는 원인) 네트워크 속도 지연이 클라이언트의 Window size때문에 발생할 수 도 있다.
안녕하세요 선생님 너무나도 친절하고 자세한 설명 덕에 tcpip 통신에 대해 한층더 깊게 이해를 할 수 있었던 것 같습니다. 궁금한 점이 세가지 정도 있습니다. 1. Segment는 tcp level에서 쪼개질때 어떤 기준으로 쪼개지는걸까요? 일정한 크기 단위로 쪼개지나요? 2. Tcp buffer의 경우는 하드웨어적인 위치가 어디인걸까요? os내의 시스템이니 컴퓨터 램을 그대로 쓰는걸까요? 3. Tcp buffer는 process에서 그러한것처럼 connection별로 생성되는 것일까요 아니면 공유를 하나요? 만약 공유를 한다면 동시성을 어떻게 관리르하나요?
좋은 평가와 피드백 감사합니다. 질문에 답변도 드리자면... 1. MSS(Maximum segment size)기준으로 일정하게 잘립니다. 2. 아니오. 송신의 경우는 파일버퍼, 수신의 경우에는 OS마다 다르지만 운영체제가 관리하는 수신 버퍼를 주로 사용합니다. 3. 소켓 별로 생성된다고 보면 되겠습니다. 어차피 TCP 세션마다 소켓이 하나씩 생기므로 Connection(Session)별로 생성된다고 봐도 무방하겠습니다. 열공하세요~~~! ^^
소켓 뿐만 아니라 모든 통신에서 가장 중요한 말씀인 것 같습니다. 통신에서 수신 받는 버퍼 처리를 최대한 빨리 해줘야 하는데 그러지 않는 프로그램이 많긴 합니다. 전 이 내용을 펌웨어 처리 할 때 똑같이 격는데 펌웨어에서는 인터럽트 수신을 하고 이 때 인터럽트 루틴에서 최대한 빠르게 처리하고 넘겨야 성능저하가 안생기는데 인터럽트 루틴에서 뻘짓을 하는 사람도 많이 있습니다. 결론적으로 중요한 포인트는 비슷한 것 같습니다. 좋은 내용 감사합니다. 많이 배우고 있습니다.
펌웨어에서 처리를 하신다니...혹시 가속기 같은 것을 개발하고 계신 것은 아닌지 궁금하네요. ^^ ISR에서는 무조건 빨리 반환해야 하는 것이 대원칙이라 할 수 있지요. 거기서 시간 끌었다가는 시스템이 몽땅 느려지는 불상사가 발생할 수도 있으니... 관련 경험도 많으실 것 같네요. 훌륭하십니다!
서버 측 flow: 1. 클라이언트 측에서 "파일 다운로드" 요청 2. 서버에서 TCP/IP 연결이 되었을 경우, 소켓 통신 가능 3. 소켓은 File의 형태이기에 Process에서 이 File인 소켓한테서 "Receive, Send"를 할 수 있음 4. 클라이언트의 요청을 "Receive"로 받아서, 요청을 "읽고", 5. 해당 요청이 이제 "파일 다운로드"이니, 해당 파일을 SSD, HDD 등의 메모리에서 찾아서 Device Driver와 File System을 거쳐서 6. 서버 프로세스가 할당된 메모리, 즉, 버퍼에 64KB 씩 잘라서 넣는다. 7. 이런 64KB 씩 자른 파일을, 소켓 통신을 통해서 TCP로 보내게 되는데, 8. 소켓(Application 영역) 영역 에서 TCP Buffer로 Send를 한다는 말이다. 9. 이렇게 Send를 할 때, COPY를 하는 것이다. 10. TCP Buffer에서는 이제 COPY가 되어 있는 상태이고, 11. 이제, TCP -> IP로 내려갈 때, 분해가 일어나게 되는데, 12. 바로 Segmentation이 일어나서, 데이터들이 Segment로 잘게 분해된다. 13. 그 후 Packet으로 감싼다. -> 이렇게 이해하면 되나요?
recv() 함수는 일단 데이터 수신하자 마자...처리를 담당하는 요소에 자료를 넘기고 다시 recv() 상태로 전환해야 합니다. 비동기 처리를 하든 Actor 패턴을 적용해 로직을 분리하든...대책을 세워야 합니다. 그렇지 않고 길제 붙들고 있다보면 Zero-window를 발생시킬 위험이 증가하게 되지요. 참고하시기 바랍니다. ^^
소리가 잘 안들리면, 볼륨이 아니라 내 귀가 잘 들리는지부터 확인해라... 좋은 비유일지 모르겠습니다만.. 퍼즐과 택배의 비유로 이해가 아주 쏙쏙 잘 되는 것 같습니다! 좋은 강의 감사드려요 :) 혹시 여기서 배운 지식을 간단하게 경험할 수 있는 튜토리얼방법에는 뭐가 있을까요?? 튜토리얼 강의나 글이 있으면 추천 부탁드립니다!!
임베디드 SW 개발자이고 정말 유익하게 봤습니다. OS 없이 베어메탈로 했지만 TCP 관련 거의 유사한 이슈가 발생해서 버퍼 비우는 속도 이슈 같다고 그렇게 설명했는데 고객사측에서 이해를 못 하더라구요. 저도 모르는게 있어서 설명이 엉성했었는데 이 걸 그 때 봤었으면 몇 개월씩 밤 샐 일이 없었을텐데.... 왜 이걸 일찍 못 봤을까요.. ㅠ
프론트엔드 분야 취준생입니다. 아무래도 브라우저 위에서 동작하는 소프트웨어를 개발하기 때문에, 백엔드 분야보다 cs 지식이 덜 중요하다고들 하지만, 저는 cs 지식까지 아는 것은 당연한 프로그래머의 역량이라고 생각하여 공부하는 중입니다. 항상 너무 잘 챙겨보면서 공부하고 있습니다. 감사합니다!!
취업 후 3~4년 정도 지나 시간이 갈 수록 CS지식에 대한 갈증이 더 늘어납니다. 할 수만 있다면 취업 전에 알고 가시는 것이 좋긴 합니다. 그렇다고 전공자처럼 다 할 수는 없겠으나 채널에 올려진 정도만 알고 가셔도 어느 정도 도움이 되리라 생각합니다. 열공하시고 꼭 좋은 기업에 취업도 하시기를 응원하겠습니다. :)
와... 정말 중요한 강의 잘 들었습니다. 일을 하면서 딱 이것때문에 테스트 과정에서 문제가 발생했는데 네트워크 문제라고 계속 삽질만 했었거든요. 며칠 밤샘.... 경험이 있어서 그런지... 너무 뇌리에 각인되는 강의입니다. 그리고 마지막에 이렇게 도식 작성하는 사람 없다고 하셨는데, '리눅스커널의구조와원리' 책에서 커널 모드와 유저모드를 구분해서 비슷한 도식으로 그리는 것을 봤습니다. 혹시 같은 분이신지도 궁금하네요.
좋은 평가와 피드백 감사합니다. User/Kernel mode를 분리해 그림을 그리는 것은 자주 있는 일입니다. 제가 '잘난척'했던 이유는 이 분리와 OSI 7 layer 및 구현의 개념적 도식을 하나로 묶어서 설명하시는 분드을 뵙지 못했기 때문입니다. 그리고 저는 그 책의 저자가 아닙니다. 참고하시기 바랍니다. ^^
안녕하세요. 먼저 좋은 강의 감사하다는 말씀 드리고 싶습니다! 요번에 주니어개발자가 되었는데 비전공자라 네트워크 지식이 전무해서 어려움을 느끼고 공부하려고 이것저것 찾아보던 찰나에 좋은 강의 접하게 되어 기쁩니다. 초보자가 듣기에도 설명이 명쾌하고 그림 그리면서 하나씩 반복해서 짚어주시니 이해도 잘 됩니다! 다만, 곧 지금까지 올려주신 네트워크 기초 이론을 다 듣게될 것 같아서 좀 더 공부해보고 싶은데 혹시 어떤 내용 혹은 책을 공부해보는 것이 좋을까요?
우선 HTTP 프로토콜에 대해서 자세히 공부하기를 권합니다. 좋든 싫든 지금의 상당수 IT 환경은 Web 기술로 설명됩니다. 만일 L3~4 수준의 공부를 이어가고 싶은 것이라면 차라리 CCNA 같은 자격증 공부를 해보는 것도 좋겠다 싶습니다. 그러나 혹시 아예 라우터를 직접 만들어보고 싶다면 C/C++을 정말 열심히 공부하고 WinPcap 라이브러리 정도는 다뤄보는 것이 좋겠습니다.
아직 많이 모르는 대학생 1학년이지만 명강의 덕분에 이해가 쏙쏙 되었습니다.. 프로그램에서 버퍼에 있는 것을 빨리 끄집어내야지 속도가 빨라질 것이군요.... 읽는속도가 네트워크 수신 속도 보다 빨라야 한다 잘 새기겠습니다. UDP는 그러면 신뢰성(쓰핸쉐)이 없어서 막 보내므로 wait이 없는 것일 텐데.. 그래서 더 빠른 것이겠네요
네, 맞습니다. 수신자에 대한 배려가 전혀 없으며 그 만큼 빠른 전송이 가능합니다. 그리고 원한다면 소켓 수준에서 개발자가 흐름제어 로직을 만들 수도 있습니다. 관심이 있다면 UDP기반 혼잡 제어 로직이 적용된 프로토콜을 설계해보기를 권합니다. 그 후 HTTP/2에 대해서도 알아보시기 바랍니다. 좋은 공부가 될 것입니다. :)
좋은 강의 감사드립니다. 아직 기초부터 배워가는 1년차 NW SE로써, 단순히 TCP/UDP의 통신속도 차이를 수신확인 여부에 의한 것으로만 인식하고 있던 중에, 새로운 사실 배워갑니다. 앞으로도 잘 부탁드리겠습니다. 조금 기초적인 질문일수도 있겠습니다만, 말씀하신 Window size로 인한 지연 문제가 발생할경우, 로그 등으로 확인할 때에는 패킷로스 비율로 나타날 수 있나요?
인서울 4년대 전공자입니다. 널널한 개발자님의 '이것이 c++이다' 교재로 수업을 들은 기억이 있네요. 예전 전공 교수님보다 잘 가르치시고, 내용도 풍부하고, 이론과 실전이 잘 결합돼서 대학교 네트워크 강의보다 좋은 것 같습니다. 널널한 개발자님의 네트워크 강의를 정주행한다면 웬만한 전공자보다 네트워크에 더 많은 지식을 얻을 거라 확신합니다.
![[입문용] 프로토콜과 OSI 7 layer 설명! 네트워크의 기능들이 어떻게 구조화 돼서 동작하는지를 설명합니다! 👍](/img/1.gif)
24:15 부분에서 "수신측에서 받는 쪽 아니에요~~"라는 말은 잘못됐습니다. '보내는 쪽'이라 해야 맞는데 말이 헛나왔습니다. ㅠㅠ 혼란을 드려 죄송합니다. 영상보실 때 참고하시기 바랍니다.
보내는 쪽은 '송신'으로 해석 하면 되는거죠? 뒤에도 수신측이 보내는 것 처럼 말씀하셔서 조금 헷갈렸네요 ㅠ
@@김성훈-w6f 네, 맞습니다. 혼란을 드려 죄송합니다. -_-;;;
@@nullnull_not_eq_null 그래도 너무 유익한 내용이었습니다 정말 감사합니다!
안녕하세요.
제가 1982년도에 TCP/IP 를 국내에서 최초로 분석하고 UNIX System 에 porting 하였습니다.
국책 연구 기관에서 수행하였고, 보고서도 냈습니다.
강연도 많이 하러 다녔는데... 새롭습니다...
헉~! 1세대 인터넷 개발자시군요! 놀랍고 또 너무나 반갑습니다. 이렇게 찾아주시고 글도 남겨주셔서 영광입니다. 이룩하신 성과로 우리나라 환경이 이렇게 까지 발전 할 수 있었음을 누구도 부정하지 못할 것입니다. 존경과 감사의 마음을 담아 인사 올립니다. :)
Thank you for your service for next generation!
감사합니다 덕분에 지금 환경에서 편하게 생활하고 있습니다
고인물
고인물이 아니라 석유 급. 유전 없는 나라에서 대체 에너지를 만드신 초창기 산업세대 ㄷㄷ
컴퓨터공학과 학부생인데 이해가 매우 잘 되어 글을 올립니다. 이런 양질의 강의 올려주셔서 감사합니다. 유료강의보다도 더 개념적으로 깊은 강의 인것 같네요 선생님. 다시한번 감사합니다.
좋은 평가와 피드백 감사합니다. 컴공 전공이라면...이 영상은 달달 외워 두시기 바랍니다. 분명히 도움이 될 것입니다. 훌륭한 IT 엔지니어의 탄생을 응원합니다. ^^
네트워크 엔지니어 입니다. 너무 좋은 강의 감사합니다. 제 스스로도 속도 지연에 대한 원인을 네트워크에서만 찾으려고 해서 힘든게 있었는데, 엔드 투 엔드가 이런 로직으로 동작 한다는걸 안다는건 저에게 큰 감동이네요
좋은 평가 감사합니다. 네트워크 엔지니어시면 이 영상 잘 활용하시기 바랍니다. 장애 발생 시 억울한(?) 일을 피하실 수 있기 때문입니다. ^^;;
설명 어렵게하거나 책만 읽는 엉터리 강사, 대학 교수들도 많고, 제목은 쉽다면서 내용은 엉터리 백과사전같은 책이나 글이 워낙 많다보니 정말 나한테 도움되는 자료를 찾지 못하고 힘들게 해맬때가 많았습니다. 그러다가 유튜브 알고리즘 덕분에 오게됬는데 이렇게 개념을 명쾌하고 쉽게 설명해주는건 처음봤어요. 너무 속시원하네요 ㅠㅠ 좋은 강의 감사합니다.
좋은 평가 감사합니다. 도움이 된 것 같아 마음이 흡족하네요. 좋아요와 구독 부탁드리고 홍보도 좀 부탁드려봅니다. ^^;;;
작년에 봤는데 또 보니 감회가 새롭군요. 인생이 달라졌습니다. 일단 퇴근이 앞당겨 지더군요. 감사합니다.
와우~~! 그러시군요. 마음이 행복해지는 피드백 정말 고맙습니다. :)
27:00 Flow control 이네요~ 전공자라 개념을 따로따로 배우는데
한눈에 다시 보니까 쉽게 연결이 되네요 정말 좋은 강의입니다!
더 깊이 들어가려면 흐름제어에 대해 알아야 하지요. 그 전에 이 정도만 미리 알고 공부하면 좀 더 수월하지 않을까 생각합니다. 좋은 평가 감사합니다. ^^
ACK , Wait , TCP buffer -> File IO buffer 로 read하는 속도 , 수신측의 window size 이 4가지의 관계에 대해서 배웠네요.
또한 wait의 존재 때문에 TCP 와 UDP의 속도 차이가 난다는 사실 도 배웠습니다.
일단 한번 강의를 쭉 들었지만 , 중요한 내용이므로 다음에 또 복습 하도록 하겠습니다. 항상 좋은 강의 감사드립니다.
네, 복습 중요하지요. UDP가 빠른 이유는 기다리지 않기 때문임을 기억하시면 좋겠습니다. 열공하세요. ^^
1년전 영상이지만.. 유료로 들어도 아깝지 않은 퀄리티의 영상입니다.. 이런 좋은 강의를 무료로 주시다니.. 비용을 지불하는 대신 이 채널을 제 동료들에게 널리널리 알리겠습니다.
좋은 평가 감사합니다. 홍보도 해주신다면 더 고맙겠습니다. 열심히 강의 만들 이유가 하나 더 늘어 난 것 같습니다. ^^;;;
대략 Segment가 두 개 정도 오게 되면 즉시 다음 차례인 3번을 보내는 게 아니고 ACK#3이 올 때까지 Wait를 한다. 여기서 속도 지연이 발생한다. TCP가 UDP보다 느린 이유 중의 하나이다. TCP Buffer의 크기는 Window Size라고 불리는데 수신 측에서 Segment가 날라오면 조립해서 넣을 수 있는 공간을 의미하며, ACK를 보낼 때 Window Size를 포함하고 있다. 수신 측의 Window Size가 MSS보다 크다면 3번을 보내고 그렇지 않다면 Wait가 걸린다. TCP Buffer에서 File I/O Buffer로 Segment를 빨리 퍼올리지 못하면, (즉 Read속도가 Network수신속도보다 느리면) TCP Buffer의 여유공간은 점점 줄어들게 될 것이고 Wait가 걸려서 속도지연이 생기게 된다..! 그림으로 그려주시면서 상세한 과정을 택배에 빗대어 설명해주시니까 도움이 많이 됩니다 감사합니다!
잘 정리하셨습니다. 그렇게 잘 기억해두면 앞으로 여러 상황을 근본적으로 이해하는데 도움이 되리라 확신합니다. ^^
와... 오늘 내용이 얼마나 많은 주제에 대해서 다루는 건지 ㅋㅋㅋ 널널한 개발자님처럼 이 내용을 잘 추상화해서 그림 한 장으로 표현하실 수 있으려면 네트워크에 대해 얼마나 많이 알아야 하는 걸까요 주니어 입장에서 너무 좋은 내용 가르쳐주셔서 감사합니다. 늘 많이 배웁니다 선생님 :D
Process가 File에 할 수 있는 Operation : RWX
소켓에 대해 읽는다 -> Receive
소켓에 대해 쓴다 -> Send
=> 서버 프로세스가 Socket에 대고 IO를 한다
파일을 잘개 쪼개 버퍼에 올리고, 버퍼 내용을 복사해서 Send한다 => Buffered I/O
이때 Buffer에 담긴 쪼갠 파일도 Segment(4계층) 단위로 쪼개고, header를 붙여 Packet(3계층)으로 만들어 전송한다.
패킷은 논리적으로 End-to-End로 전송되지만, Frame 자체는 2계층에서 전송되며 최종 원하는 단말로 전송될 때까지 계속 갈아 끼워진다. MAC 주소를 활용한 동일한 물리적 네트워크 단위의 통신인 이더넷 프로토콜 전송이기 때문이다.
클라이언트에서 Segment를 받으면 다음 Segment 번호에 대해 요청으로 ACK를 반환한다. ACK 메세지에는 클라이언트의 TCP Buffer의 가용 영역인 Window Size를 포함한다.
사실 서버에서는 Segments를 보낸 상태에서 WAIT하고 있었다. 이제서야 잘 보낸 것을 확인하고 다음 Segment를 보낸다. 이러한 WAIT이 TCP 성능 저하의 원인
이러한 무작정 WAIT하는 전략의 성능 이슈를 막기 위해 등장한 전략이 있다.
Window Size > Maximum Segment Size ? YES : NO(then Wait)
Receive Process가 Socket에 대하여 TCP Buffer를 읽으면
Read 속도 > Network 속도 ? YES : TCP Buffer Size가 작아지며 처리 지연 현상 발생
따라서 처리 지연 문제 발생시 장애 원인을 Network가 아니라 프로그램 구조에서 찾아야 한다
!!일단 Process가 TCP Buffer를 읽는 속도가 얼마나 빠른지 확인하라. Network에서 수신하는 속도보다 무조건 빨라야 병목이 발생하지 않는다!!
좋은 평가와 피드백 감사합니다. 소켓 프로그래밍 + 네트워크 보안 프로그램 개발을 병행하다보니 조금 더 아는 것뿐 입니다. 해서 전체적인 흐름을 제대로 설명하지는 못하고 있습니다. 저도 더 공부해야 한다는 것이죠. ^^;;;;
저는 공공기관에서 기반시설을 담당하고 있는 사람인데요
IT를 공부하는 또는 관련 직종에 종사하는 모든 분들이 이 영상을 보셨으면 좋겠네요 정말 유익한 정보이자 실무자에게 반드시 필요한 지식입니다
대부분 필드에서 서버, 보안, 네트워크, 개발자, PC 담당자가 서로 바쁘다가 늘 쟁점대서 싸우는 상황이 바로 '속도가 느리다' 인데요
이영상을 보고 저도 많이 몰랐고, 많이 오해했다는 것을 깨닫고 갑니다 나아가 얼마나 네트워크 통신에서 '소통'이 중요한가를 다시한번 느끼게 되네요
정말 감사하고 앞으로도 두고두고 돌려보도록 하겠습니다
감사합니다.
좋은 평가와 피드백 감사합니다. 이미 인프라 담당을 하고 계시므로 저보다 더 다양한 현실 문제를 경험하셨을 것 같습니다. 앞으로도 열심히 강의 올리겠습니다. ^^
댓글 보면서 공부할겸 보고 있는데 무례한 댓글들도 꽤 있네요 ㅠㅠ
전공자로서 도움이 많이 되고 있어요..
쉽게 설명해주셔서 흐름을 이해할 수 있게됐고. 이걸 바탕으로 깊게 들어가면 될 것 같아요
방향성을 제시해줘서 감사해요!!
좋게 봐주셔서 고맙습니다. 흐름을 잘 알면 깊은 이론을 이해한 것에 있어 확실히 유리합니다. 열공하시고 좋은 결과 얻으세요~~! :)
너무 좋은 강연 감사드립니다. 비전공자이며 제조업 종사자입니다.
현업에서 '서버, MES, 방화벽,클라이언트' 간 통신 이슈로 네트워크 업체를 닥달해서 패킷 단위를 변경해서 해결한 문제가 하나 있었는데, 이 영상을 보니 클라이언트쪽 소프트웨어 개발 문제였던 것 같네요. 네트워크는 정말 어렵네요.
음...MES 환경에서는 더 예외적인 일들이 자주 벌어집니다. 소위 IoT 장치들이 많기 때문입니다. 그래도 어떻게든 해결은 하신 것 같아 다행입니다. 이미 관련한 노하우를 가지고 계시겠으나 향후 그런 문제가 반복된다면 반드시 패킷 덤프를 분석해보실 것을 강력히 권합니다. 감사합니다. :)
자바, 스프링처럼 언어, 프레임워크에 대한 기술적인 지식도 중요하지만 개발자의 기본지식이 더 엄청 중요한 것 같습니다. 영상 올려주셔서 감사합니다.
인프라에 대한 이해가 높을 수록 백엔드 개발자는 유리한 점이 많습니다. 좋은 평가와 피드백 감사합니다. ^^
13:13 보기전 어떤내용인지 미리볼려고 눌러봤다가 바로끕니다 벌써머리가지끈거리네요 최고의강의입니다!
머리가 좀 아프실 수 있습니다. 그래도 꼭 도전하셔서 본인의 것으로 만드시기를 강력히 권합니다. ^^
오~ 좋은 강의 입니다. TCP/IP 관련되어 처음 접근 하시는 분들이 실수 하시는부분 몇가지입니다. LAB 환경에서만 제대로 된다고 실제 환경이 되면 다양한 상황이 될수가 있습니다. 그래서
1. 소켓은 무조건 ASYNC 소켓으로 작성을 하세요. 이건 CONNECT 분만 아니라 송수신에서도 중요합니다. ASYNC 소켓은 함수 리턴값이 아니라 에러코드값으로 판단하면 됩니다.
2. 송/수신은 반드시 지정된 크기가 전송될때까지로 해야 합니다. 즉, 100 바이트 전송을 send 함수로 넘겨만 주었다고 무조건 100 바이트 전송이 이루어지는건 아닙니다. 90바이트 10바이트 전송이 가능합니다. TCP/IP 통신은 전송을 게런티 해주지, 전송 시간(지금 당장)까지 게런티 해주는게 아닙니다.
이 모든것들은 통신이라는것이 중간에 여러 통신 기기(주로 라우터)들을 거쳐서 이루어 지기 때문에 이곳에서 우선권(QoS 등등)을 지닌 패킷과 MTU 크기등에 따라 프레그먼트가 발생하게 됩니다. 즉, A --- > B --- > D 라우터를 통하는게 아니라 A--- > B, A--->C B-->D , C--->D 이런식으로 패킷이 분리되어 전송이 가능한것입니다. 에플리케이션 레이어에서는 몰라도 되는것이지만 이상한 상황이 발생한다면 대부분 이곳에서 발생하는 것이기에 1,2번은 반드시 지키면서 하시면 큰 무리는 없을겁니다. 자신만의 ASYNC 소켓과 (주로 접속 관련) 전송 함수들을 만들어 놓으면 평생 사용하시면 됩니다.
L3 쪽에 관심이 있으시면 WIRESHARK 같은거 켜놓으시고 IP/TCP 헤더 부분만 잘 보셔도 큰 도움이 되실겁니다. ^^
좋게 봐주셔서 감사합니다. 다만...몇 가지는 바로 잡는 것이 좋겠습니다. C/C++ 개발자 관점에서 보면 Async 소켓으로 반드시 작성해야 하는 것은 아닙니다. 물론 서버가 극한의 성능을 발휘하기 위해서는 IOCP나 epoll같은 비동기 구조를 채택 할 수 밖에 없습니다.
그리고 단편화가 발생하는 가장 큰 이유중 하나는 VPN 입니다. L3 수준 터널링이 적용되고 심지어 중첩될 경우 단편화가 발생 할 수 있습니다. 더불어 알아두시면 도움이 될 것 같습니다.
좋은 정보와 의견 고맙습니다. :)
이런 훌륭한 교수님을 이제 보게됐다는게 너무 후회스럽습니다 ㅠㅠ
좋은 강의 감사합니다
좋은 평가 감사합니다. 열공하시고 좋은 결과 얻으시기를 응원합니다. ^^
오우 전공 지식으로 알고 있던 부분이 사실 이미지론 잘 안 떠올랐었는데 지금 강의를 들으니 어떤 부분이 중요하고 또 어떻게 데이터가 흘러가는지 알고 있던게 머릿 속에 그려집니다! 이 감각을 잊지 않게 노력해야겠어요 감사합니다
피드백 감사합니다. 내부 구조를 어느 정도라도 알면 다양한 이론과 현상을 이해할 수 있습니다. 열공하시고 좋은 성과 거두시기 바랍니다.
클라우드 엔지니어로 취직한지 3개월 째 되는 병아리입니다.
퀄리티 있는 강의 감사드립니다. 언제나 보기 좋게 이미지로 설명해주셔서 읽기 능력이 떨어지는 저에게 너무 좋은 강의 같아요.
지금 구축 프로젝트에 투입되었는데 네트워크가 부족해서 개발자님의 네트워크 기초 이론 꼬박꼬박 듣고 있습니다.
인프런 강의도 조만간 사서 듣고 역량을 키워보겠습니다.
이제 3개월이면...아직 적응기라 할 수 있겠습니다. 꼭 잘 적응하셔서 훌륭한 엔지니어로 성장하시기 바랍니다. 저도 열심히 강의 올리겠습니다. 감사합니다. ^^
엄청난 명강의네요. 학부생인데 진짜 놀라워요. 3년 전 강의인데 CS에서 이런 강의가 계속해서 나왔으면 좋겠어요. 정말정말 감사합니다
좋게 봐주셔서 고맙습니다. 앞으로 더 좋은 강의로 보답하겠습니다. :)
네트워크 공부 어렵습니다. 그중에 각 용어의 개념 이해를 이렇게 해주는 책이나 사람을 아직 못봤습니다. window size 다시 알게 됐습니다. 감사합니다.
좋은 평가와 피드백 감사합니다. 혹시 장애대응도 하셔야 한다면 이 영상 속 내용이 어느 정도 도움을 드릴 수 있겠습니다. ^^
임베디드 SW 개발 분야에 최근 입사한 쌩신입입니다.
업무를 위해 여러 CS 강의를 듣던 중인데, 파일이 분해 및 재조립되는 과정을
퍼즐에 비유하신 부분을 듣고 정말 감탄했습니다...
비전공자나 CS 관련 지식이 얕은 사람이 들어도 정말 중요한 정보를
이렇게 쉽게 가르칠 수 있다는 점이 정말 대단한 것 같습니다.
좋게 봐주셔서 고맙습니다. 신입으로 살아 남는 것이 지금으로써는 과제가 아닐까 싶습니다. 그래도 너무 지쳐서 무너지지는 않도록 쉬엄쉬엄 하시기 바랍니다. 참, 건강도 잘 챙기시고요. 비타민 D 꼭 드세요~! :)
이런 자세한 설명을 유튜브 검색으로 볼수 있다는거 자체가 축복인거 같아요. 마치 '이래도 니가 공부를 안할거야?'라고 떠미는듯한 ㅋㅋ 유료강좌는 또 얼마나 자세할지 궁금하네요
좋게 봐주셔서 고맙습니다. 열공하시고 좋은 결과 얻으시기 바랍니다. :)
강의 내용 숨막히게 스릴 넘치게 봤네요. 이거 진짜로 중요하다 말씀 안하셔도 강의의 포스가 남다릅니다.
와우~~! 스릴까지...^^;;; 좋은 평가 감사합니다. 앞으로도 열심히 강의 올리겠습니다.
최근 네트워크 공부를 하느라 선생님 영상을 몇개 정독했습니다. 아무런 전공도 없고 지식도 없이 군생활만 8년차인 저는 네트워크 엔지니어로 이직을 준비하고있고 시스템/클라우드 엔지니어를 목표로 하고있습니다. 선생님 영상 정주행하면서 목표를 위해 열심히 달려보겠습니다.
국가를 위해 많이 수고하셨군요. 열심히 공부하셔서 바라는 바 꼭 이루시기를 응원합니다. 고맙습니다. :)
면접준비하다가 들어왔는데… 그동안 단편화되어 있던 정보가 쭉 하나로 합쳐지네요 진짜 인생이 달라진다 표현해도 될꺼 같아요 감사합니다.
좋게 봐주셔서 고맙습니다. 면접 준비와 관련한 영상들이 채널 내에 더 있습니다. 지금은 대부분 멤버십으로 제한되어 있습니다만 이 영상이 도움이 됐다면 참고가 되리라 생각합니다. 좋은 결과 있으시길 바랍니다. 건투를 빕니다! :)
선생님, 이 강의 덕에 취직 했습니다. 선생님 덕분에 인생을 바꿀 기회를 얻었습니다. 감사합니다.
와우~~! 정말 너무나 반가운 소식입니다. 꼭 기회를 자신의 것으로 만드시기를 진심으로 응원합니다. :)
세그먼트화 되어있던 제 네트워크 지식이 이 영상을 보고 조립이 된 것 같습니다.
훌륭한 택배기사님 이십니다 ㅎㅎ
좋은 영상 감사합니다!!😊
와우~! 이런 센스 넘치는 피드백 고맙습니다. :)
1년전 시청하고, 지금 1년이 지난 후 다시 복습해보니 그때보다 이해되는 내용이 더 많아졌네요..ㅎㅎㅎ 나중엔 말씀하신 내용을 전부 이해가 될때까지 열공하고 오겠습니다!
와우~~! 1년 후 복습까지!! 훌륭합니다. 원론적인 이야기라...크게 달라질 것이 없는 내용이긴 합니다. 계속해서 이해도만 높이시면 되겠습니다. :)
지금까지 본 네트워크 강의 중 가장 이해하기 쉬웠습니다. 감사합니다 :)
좋은 평가 감사합니다. ^^
그저 감탄, 관련 지식이 거의 없는데도 되게 쉽게 설명해주신다는 느낌이 들었어요!
예시를 들어 설명해주시니까 쏙쏙 이해 됨!
그리고 판서가 기가 막히네요 ㅎㅎ
좋게 봐주셔서 고맙습니다. 앞으로도 좋은 강의 올리도록 노력하겠습니다. :)
학교 네트워크 수업때 배웠던 모든 내용들이 디스크 조각모음 되는 느낌을 받았습니다. 특히 Frame이 One-hop 떨어진 곳으로 이동할 때를 택배차를 바꿔탄다로 표현한 것은 놀람을 금치못했습니다. 고맙습니다.
좋게 봐주셔서 고맙습니다. 영상이 도움이 된 것 같아 행복하네요. :)
우아! HW개발자라 소켓프로그램, TCP/IP를 해보진 않았지만, 강의가 쏙 들어오게 설명하시네요. Good
좋은 평가와 피드백 감사합니다. ^^
TCP 강의 영상은 이것 저것 보고 또 봐도 국내 원탑은 널개님 영상이네요. (오늘 3번째 시청)
와우~~! 극단적이 좋은 평가 고맙습니다. :)
개념 정리를 잘해주셔서 머리속 데이터가 새로이 잘 정렬된 기분입니다. ㅎㅎ
현업에서 이런 저런 일들을 할 때도, 기본적인 이론이 정립이 잘 되어 있어야 확신을 가지고 일을 할 수 있는 것 같아요.
좋은 평가와 피드백 감사합니다. 정리도 잘 되셨다니...강사로써 보람을 느낍니다.
좋은지식 얻고갑니다 ! 정처산업기사 공부 도중에 알고리즘에 떠서 우연찮게 봤는데 정말 재밌었어요 ㅋㅋㅋ 초반 1분 설명듣고서는 정확히 이해가 안됬지만 택배로 설명하는 부분에서 지식이 조금이나마 이해 됬을 때 느끼는 짜릿한 소름이 느껴져서 정말 좋았어요 !
좋은 평가와 피드백 감사합니다. 다행히 어느 정도 이해도 되신 것 같아 정말 다행입니다. 강사로써 보람을 느낍니다. ^^;;;
CCNA 공부하는 중인데 글로만 봐서는 이해가 완전히 안되었는데 너무 잘 설명해주셔서 기억에 오래 남을거같아요! 고맙습니다.
그러셨군요. 도움이 된 것 같아 다해이네요. :)
데이터통신 시험 앞두고 재시청했습니다! 도대체 이 영상 하나로 몇 문제가 커버 가능한지… 정말 감사드립니다!
곧 시험을 앞두고 계시는 군요. 꼭 좋은 결과 있기를 바랍니다. 잘 되실 겁니다. 이렇게 복습도 열심히 하시니까요. :)
머리에 쏙 들어오게 정말 잘 정리해주시네요. 그리고, 유선이든 무선이든 통신 개념과 용어가 많이 비슷하네요. 그리고 택배로 연결해서 설명해주시니, 이렇게 쉽게 이해할 수있군요. 감사합니다.
좋게 봐주셔서 고맙습니다. 택배만 잘 기억해도 패킷에 대한 이해는 어느 정도 끝납니다. :)
와 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 저거로 한번 개고생 해보신 경험이 있으시군요ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 진짜 얼마나 짜증나고 답답하고 화났다가 이유알고 어이없었을까 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 진짜 재밌었습니다, 감사합니다
와우~! 도움이 된 모양이네요. 피드백 고맙습니다. :)
이 영상을 처음본게 작년이었는데 그때 당시에는 그냥 그런가 보다 하고 지나쳤지만, 최근 운영체제나 네트워크에 대한 CS공부를 하고 다시보니까 이해하기 쉽게 잘 정리된 명강의라고 생각됩니다.
좋게 봐주셔서 고맙습니다. 아는 만큼 더 보이는 법이 아닐까 싶습니다. 그 자체로 성장의 증거가 되겠습니다. 잘 가고 계신 것 같네요. :)
감사합니다 일요일 아침에도 보게 만드는 강의 제목이네요!
와우~~! 휴일을 공부에 투자하시는군요. 건투를 빕니다!
이 영상이 중요한 이유: 원인이 어디인가를 찾을때 굉장히 유용하다. 내 pc의 window size가 작아서 나타나는 버그인데 네트워크단만 주구장창 봐봤자 문제해결을 할 수 없다. 이것 때문에 인생이 바뀐다고 하신거 같습니다. 약간 어그러성 발언도 있는건 같은데 어느 부분 맞기도 하죠.
음...제 의도를 말하자면...대부분 한 가지만 보기 때문입니다. End-point만 보거나 Network만 보거나...결국 그 둘을 같이 봐야 한다는 것이죠. 시야를 넓히면 확실히 업그레드 됩니다만...인생이 바뀌는 수준이 될 지는 상대적인 측면이 있습니다. 그러니...초보 유튜버의 어그로 정도로 이해해주시면 좋겠습니다. ^^
좋은 강의 너무 감사합니다! 지금까지 공부했던 것들이 하나로 조립이 안되는 기분이었는데 이 강의를 듣고 하나의 그림으로 연상이 되네요ㅠㅠ 진짜 너무 갓강의입니다 두고두고 복습하겠습니다. 다시 한번 감사합니다!!
좋은 평가와 피드백 감사합니다. 이 영상은 몇 번이고 다시 보셔서...꼭 자신의 것으로 만드시기를 강력히 권합니다. ^^
복잡한 내용을 너무 간결한고 이해하기 쉽게.... 머리속에 콕콕 들어오네요~
좋은 평가와 피드백 감사합니다. 잘 기억해두시면 장애대응을 비롯해 여러 분야에서 써먹을 수 있습니다. ^^;;;
감사합니다. 이강의는 최소 3번 반복해서 들어야 할 내용이네요.
음...여러 번 보시고 본인의 것으로 만드시기를 강력히 권합니다. :)
와. tcp,ip 통신의 원리를 이리 쉽게 잘 이해하시는분은 첨보네요. 와이어샥 패킷분석할때 정말 필요한정보라 여러번 들었습니다. 학부때 책에서 들었을때 이해가 안갔는데 네트웍 문제있어서 와이어샥 패킷분석하느라 이론책을 엄청 들어다보고도 잘 이해가 잘 안갔는데 선생님 설명듣고 10년만에 이해했습니다. 너무 감사해요. 이걸 알아야 딜레이현상에 대해 분석이 가능하더라구요.
좋은 평가와 피드백 감사합니다. 이미 Wireshark을 사용 중인 사람이라면 이 영상의 내용이 가지는 의미도 잘 이해하셨을 것 같습니다. 특히 장애대응에 관한 내용을 공부할 때 유용하지요. :)
네트워크를 공부하고있는 비전공자 입니다. 도움이 정말 많이 되었습니다!!! 감사합니다!
개발까지는 아니더라도 Linux TCP 튜닝 부분에 대해 알아보세요. 그냥 네트워크만 아는 것과는 아주 큰 차이가 있답니다. 열공하세요~~~!
비전공자도 이해하기 쉽게 알려주시니까 너무 좋아요^^ 유튜브 알고리즘으로 채널 추천이 나와서 알게 되었는데 유튜브 알고리즘의 추천은 진리네요 ㅎㅎ
좋은 평가 감사합니다. 저희 채널은 '대한민국 모든 개발자의 전공자화'를 지향합니다. 관련 강의 계속 열심히 만들어 올리겠습니다. 열공하세요~~~! ^^
학부때 배웠던건데 오랫만에 다시 들으니 기억도 새록새록 좋네요~
그렇군요. 피드백 감사합니다. TCP 흐름제어에 대해 학부 시절 많이 다루셨나 보네요. 부럽습니다. ^^;;
마우스 커서가 없어서 어디서 어떻게 표현하는지 눈이 계속 화면의 공간을 추적해야해서 질 좋은 강의를 100% 못 소화시키네요 ㅋㅋ 두세번 더 보겠습니다.
이 영상이 채널 재오픈 초기에 촬영된 것이라...부족한 부분이 많습니다. 아무래도 다시 촬영하던가 해야 할 것 같네요. 그럼에도 좋게 봐주셔서 고맙습니다. :)
예전에 cpp에서 시리즈 넘버 순서대로 패킷 쌓아서 Struct 만들고 데이터 뽑아내는 업무를 한 적이 있었는데 그 내면에 ack 3번의 내용은 정말 신세계네요~!!
좋은 설명 감사합니다!
ack 3번의 wait로 인한 지연('tcp는 udp에 비해 느리다'라는 원인)
네트워크 속도 지연이 클라이언트의 Window size때문에 발생할 수 도 있다.
TCP를 공부할 때 미리 알았더라면 좋았을 내용으로 저는 이 영상을 꼽습니다. 특히 소켓 프로그래밍을 공부하기 전에 알았더라면...아마도 야근일 수가 1개월 이상은 줄어들지 않았을까 생각해봅니다. 좋은 평가와 의견 감사합니다. ^^
최근에 강의하시는 부분이 네트워크 관련이다 보니 다시 돌아와서 강의 듣고 있습니다 ㅎㅎ 자세한 설명 감사드립니다!
피드백 감사합니다. 열공하세요~~~! ^^
데이터 (osi-7,6,5) < 세그먼트 (osi-4) < 패킷 (osi-3) < 프레임 (osi-2) < 그리고 0 과 1 (osi-1 전기신호/빛/라디오 파동)... 이 과정을 엄청나게 많이 왔다갔다하는걸 보면 네트워크는 마법이 맞는거 같아요.
그렇게 생각 할 수도 있겠습니다. 의견 고맙습니다. :)
I appreciate your informative lecture, you are such a great teacher! That was amazing!
좋은 평가 고맙습니다. :)
이번 주 토요일에 네트워크 관리사 2급 실기 시험치는데요... 좋은 자료 감사드립니다.
아, 그렇군요. 시험 잘보셨기를 바랍니다. :)
@@nullnull_not_eq_null 합격 할 가능성 매우 높습니다. 자료 많은거 획득하고 잘보고왔어요.
안녕하세요 선생님 너무나도 친절하고 자세한 설명 덕에 tcpip 통신에 대해 한층더 깊게 이해를 할 수 있었던 것 같습니다. 궁금한 점이 세가지 정도 있습니다.
1. Segment는 tcp level에서 쪼개질때 어떤 기준으로 쪼개지는걸까요? 일정한 크기 단위로 쪼개지나요?
2. Tcp buffer의 경우는 하드웨어적인 위치가 어디인걸까요? os내의 시스템이니 컴퓨터 램을 그대로 쓰는걸까요?
3. Tcp buffer는 process에서 그러한것처럼 connection별로 생성되는 것일까요 아니면 공유를 하나요? 만약 공유를 한다면 동시성을 어떻게 관리르하나요?
좋은 평가와 피드백 감사합니다.
질문에 답변도 드리자면...
1. MSS(Maximum segment size)기준으로 일정하게 잘립니다.
2. 아니오. 송신의 경우는 파일버퍼, 수신의 경우에는 OS마다 다르지만 운영체제가 관리하는 수신 버퍼를 주로 사용합니다.
3. 소켓 별로 생성된다고 보면 되겠습니다. 어차피 TCP 세션마다 소켓이 하나씩 생기므로 Connection(Session)별로 생성된다고 봐도 무방하겠습니다.
열공하세요~~~! ^^
친절한 답변 너무나 감사합니다… 정말 많이 배우고 있습니다
열공을 응원 합니다!! ^^
소중한 강의를 공유해주셔서 정말 감사합니다🙇♂
21:51 에 나오는 ACK 는 TCP 헤더의 확인응답번호를 말씀하신거죠?
TCP 헤더의 제어비트 중 일부인 ACK 비트와 헷갈려서 질문드립니다!
네, 맞습니다. 영상에서 관련 설명이 있습니다. 참고하시기 바랍니다. :)
소켓 뿐만 아니라 모든 통신에서 가장 중요한 말씀인 것 같습니다. 통신에서 수신 받는 버퍼 처리를 최대한 빨리 해줘야 하는데 그러지 않는 프로그램이 많긴 합니다. 전 이 내용을 펌웨어 처리 할 때 똑같이 격는데 펌웨어에서는 인터럽트 수신을 하고 이 때 인터럽트 루틴에서 최대한 빠르게 처리하고 넘겨야 성능저하가 안생기는데 인터럽트 루틴에서 뻘짓을 하는 사람도 많이 있습니다.
결론적으로 중요한 포인트는 비슷한 것 같습니다. 좋은 내용 감사합니다. 많이 배우고 있습니다.
펌웨어에서 처리를 하신다니...혹시 가속기 같은 것을 개발하고 계신 것은 아닌지 궁금하네요. ^^
ISR에서는 무조건 빨리 반환해야 하는 것이 대원칙이라 할 수 있지요.
거기서 시간 끌었다가는 시스템이 몽땅 느려지는 불상사가 발생할 수도 있으니...
관련 경험도 많으실 것 같네요. 훌륭하십니다!
오우 너무 잘 들었습니다. 이렇게 쉽게 소켓 통신 설명하는 자료 처음 만나네요.
좋은 평가와 피드백 감사합니다. ^^
끝까지 들으니 얻어가는 게 분명 있네요! 마지막이 핵심인 것 같아요.
혼잡제어에 대해 조금 더 알아보시기 바랍니다. 실력향상에 크게 도움될 것입니다. ^^
진짜 명강의입니다. 너무 쉽고 재밌게 풀어주셔서 시간가는 줄 모르고 봤어요 ㅎㅎ 바로 구독 누릅니다!
좋은 평가와 피드백 그리고 구독 감사합니다. ^^
비전공자로 개발만 하다가 최근 서버/네트워크까지 다루는 부서로 오고나서 멘붕의 연속이었는데 좋은 강의 듣고갑니다 ㅜㅜ 구독할께요
이제는 역량을 더 넓혀야 할 때를 만나신 모양이네요. 열공하시고 더 성장하시고 연봉도 더 오르시길 바랍니다. :)
정말 최고 양질의 강의 너무 감사합니다.
좋은 평가와 피드백 감사합니다. ^^
좋은 강의 감사드립니다! 취준생한테는 정말 단비같은 강의에요 ㅜㅜ 비전공자라 이런 기본지식을 채울 방법이 막막했는데 깊이있는 부분까지 잘 설명해주셔서 정말 좋았습니다
도움이 되셨다니....기분 좋습니다. 보시고 질문이 있으면 언제든 글 올려주시기 바랍니다. ^^
에요->예요
전문용어들을 잘 몰라도 그냥 이해가 되는 신기한 경험 ㅎ
정말 강의 잘하시네요.
아하~~! 그렇군요. 좋은 평가와 피드백 감사합니다. ^^
서버 측 flow:
1. 클라이언트 측에서 "파일 다운로드" 요청
2. 서버에서 TCP/IP 연결이 되었을 경우, 소켓 통신 가능
3. 소켓은 File의 형태이기에 Process에서 이 File인 소켓한테서 "Receive, Send"를 할 수 있음
4. 클라이언트의 요청을 "Receive"로 받아서, 요청을 "읽고",
5. 해당 요청이 이제 "파일 다운로드"이니, 해당 파일을 SSD, HDD 등의 메모리에서 찾아서 Device Driver와 File System을 거쳐서
6. 서버 프로세스가 할당된 메모리, 즉, 버퍼에 64KB 씩 잘라서 넣는다.
7. 이런 64KB 씩 자른 파일을, 소켓 통신을 통해서 TCP로 보내게 되는데,
8. 소켓(Application 영역) 영역 에서 TCP Buffer로 Send를 한다는 말이다.
9. 이렇게 Send를 할 때, COPY를 하는 것이다.
10. TCP Buffer에서는 이제 COPY가 되어 있는 상태이고,
11. 이제, TCP -> IP로 내려갈 때, 분해가 일어나게 되는데,
12. 바로 Segmentation이 일어나서, 데이터들이 Segment로 잘게 분해된다.
13. 그 후 Packet으로 감싼다.
-> 이렇게 이해하면 되나요?
네, 맞습니다. 다만 클라이언트 다운로드 요청은 TCP연결이 된 이후에 가능한 것입니다. 그러므로 1, 2번은 순서를 바꿔야 합니다. 참고하시기 바랍니다.
그러면 TCP 구조로 개발을 할 때는, Recieve를 먼저 하고, 태스크를 많이 부여해야겠네요. 감사합니다.
recv() 함수는 일단 데이터 수신하자 마자...처리를 담당하는 요소에 자료를 넘기고 다시 recv() 상태로 전환해야 합니다. 비동기 처리를 하든 Actor 패턴을 적용해 로직을 분리하든...대책을 세워야 합니다. 그렇지 않고 길제 붙들고 있다보면 Zero-window를 발생시킬 위험이 증가하게 되지요. 참고하시기 바랍니다. ^^
소리가 잘 안들리면, 볼륨이 아니라 내 귀가 잘 들리는지부터 확인해라... 좋은 비유일지 모르겠습니다만..
퍼즐과 택배의 비유로 이해가 아주 쏙쏙 잘 되는 것 같습니다! 좋은 강의 감사드려요 :)
혹시 여기서 배운 지식을 간단하게 경험할 수 있는 튜토리얼방법에는 뭐가 있을까요?? 튜토리얼 강의나 글이 있으면 추천 부탁드립니다!!
음...소켓 프로그래밍이나 TCP/IP 프로토콜 스택을 직접 개발해보는 방법이 있겠습니다. 딱히 튜토리얼을 본 적은 없는 것 같습니다. TCP 프로토콜을 개발하는 것 자체가 흔한 일은 아니라서요. 참고하시기 바랍니다.
너무 알아듣기 쉬운 설명 감사합니다. 인생 달라지는 기분 들었습니다 :)
좋은 평가와 피드백 감사합니다. 이렇게 외워만 두셔도...여러 이론을 이해하는데 도움이 되리라 확신합니다. ^^
정말 감사합니다. 비전공자라서 어려움이 있었는데, 한번에 실무 팁까지 알려주셔서 많은 도움이 되었습니다!
그러셨군요. 도움이 됐다니...다행스러운 일입니다. 좋은 평가와 피드백 고맙습니다. :)
임베디드 SW 개발자이고 정말 유익하게 봤습니다. OS 없이 베어메탈로 했지만 TCP 관련 거의 유사한 이슈가 발생해서 버퍼 비우는 속도 이슈 같다고 그렇게 설명했는데 고객사측에서 이해를 못 하더라구요. 저도 모르는게 있어서 설명이 엉성했었는데 이 걸 그 때 봤었으면 몇 개월씩 밤 샐 일이 없었을텐데.... 왜 이걸 일찍 못 봤을까요.. ㅠ
이제라도 보셨으니...같은 이슈가 반복되지는 않을 것 같습니다. 무엇보다 그 고생이 더 큰 역량으로 환산될 수 있을 것이라 생각합니다. 고맙습니다. :)
와 네트워크 이렇게 쉽고 재밌게 알려주시는 분은 처음이네요.. 감사합니다!
좋은 평가와 피드백 감사합니다. ^^
너무 재밌게 잘 봤습니다! 그림 그려서 설명해주시니까 더 와닿는것 같아요. 감사드립니다
이해가 잘 되셨다니...정말 다행이네요. 새해 열공하신 만큼 좋은 성과도 거두시기 바랍니다. 고맙습니다. :)
이야, 정말 설명 잘하시네요. 판서는 마치 화가가 그림을 완성해나가는 것같아요. 예술작품이네요
좋게 봐주셔서 고맙습니다. 이 판서 내용만 잘 이해하시면...어지간한 문제의 원인은 일정 수준 짐작이 가능하지요. :)
선생님 넘 감사합니다 덕분에 운영체제 마지막 챕터에서 TCP/IP 얘기 나와서 궁금했는데 빛과 소금이십니다
운영체제를 공부해서 알고 있다면...이 영상은 매우 중요합니다. 꼭 자기것으로 만드시기를 강력히 권합니다. 그리고 좋은 평가와 피드백 감사합니다.
@@nullnull_not_eq_null 요 영상 이해가 안가서 처음부터 쭉 달렸는데 드디어!! 여기까지~~ 와아
그림이 집착하시는게 의외로 몰입이 매우 잘되네요. 자극적인 강의였어요
피드백 감사합니다. 그림을 머리에 통째로 넣어버릴 수 있기를 바라는 마음이 있습니다. ^^
프론트엔드 분야 취준생입니다. 아무래도 브라우저 위에서 동작하는 소프트웨어를 개발하기 때문에, 백엔드 분야보다 cs 지식이 덜 중요하다고들 하지만, 저는 cs 지식까지 아는 것은 당연한 프로그래머의 역량이라고 생각하여 공부하는 중입니다. 항상 너무 잘 챙겨보면서 공부하고 있습니다. 감사합니다!!
취업 후 3~4년 정도 지나 시간이 갈 수록 CS지식에 대한 갈증이 더 늘어납니다. 할 수만 있다면 취업 전에 알고 가시는 것이 좋긴 합니다. 그렇다고 전공자처럼 다 할 수는 없겠으나 채널에 올려진 정도만 알고 가셔도 어느 정도 도움이 되리라 생각합니다. 열공하시고 꼭 좋은 기업에 취업도 하시기를 응원하겠습니다. :)
진짜 설명 퀄리티가 미쳤다 이해가 너무 잘된다...
좋은 평가와 피드백 감사합니다. ^^
구독하고 갑니다! 출퇴근때 종종 보면서 복기해야곘어요 감사합니다.
구독 감사합니다. :)
와... 정말 중요한 강의 잘 들었습니다.
일을 하면서 딱 이것때문에 테스트 과정에서 문제가 발생했는데 네트워크 문제라고 계속 삽질만 했었거든요. 며칠 밤샘.... 경험이 있어서 그런지... 너무 뇌리에 각인되는 강의입니다.
그리고 마지막에 이렇게 도식 작성하는 사람 없다고 하셨는데, '리눅스커널의구조와원리' 책에서 커널 모드와 유저모드를 구분해서 비슷한 도식으로 그리는 것을 봤습니다. 혹시 같은 분이신지도 궁금하네요.
좋은 평가와 피드백 감사합니다. User/Kernel mode를 분리해 그림을 그리는 것은 자주 있는 일입니다. 제가 '잘난척'했던 이유는 이 분리와 OSI 7 layer 및 구현의 개념적 도식을 하나로 묶어서 설명하시는 분드을 뵙지 못했기 때문입니다. 그리고 저는 그 책의 저자가 아닙니다. 참고하시기 바랍니다. ^^
Linux socket can 통신하면서 로그 분석했을때 수신측에서 특정 패킷 못 받고 지연 되는 결과가 나왔었는데 강의 듣고 이제 이해가 가네요!! 감사합니다!
피드백 감사합니다. 그렇다면 이제 어떻게 개선해야 할 것인지도 아셨을 것 같습니다. 건투를 빕니다!
감사합니다. 개발을 할수록 근본적인 작동방식에 대한 지식이 부족하다고 느껴졌었는데 올려주신 강의들이 정말 많은 도움이 됩니다 고맙습니다!!
도움이 됐다는 피드백...너무 좋습니다. 원리까지 완벽하게 자신의 것으로 만드시기 바랍니다. 건투를 빕니다!
감사합니다 선생님!! 할 말이 너무 많다고 항상 말씀하시는데,, 전부 듣고싶어요ㅎㅎ
음...보안, 성능, 장애... 다 해야 해서 그렇습니다. 의견 감사합니다. ^^
감사합니다. 매번 문제가 되던 부분이 있었는데 해당 영상 보면서 도움이 많이 되었습니다.
뭔가 답을 찾으신 모양이네요. 피드백 감사합니다. ^^
제목 어그로에 클릭을 안할수가 없네요. 그리고 강의도 너무 좋네요 감사합니다.
이번 강의는 무조건 암기해야 합니다. 그래야 복잡한 RFC 문서를 이해하는데 도움이 됩니다. 해서...어그로를 좀 끌어봤습니다. ^^;;; 열공하세요~~~!
해당 개념은 TCP 뿐만 아니라 DMA 버퍼 등 커널 단에서도 응용이 되는거 같습니다. 감사합니당~
아, 그러셨군요. 도움이 됐다니 다행이네요. :)
질 높은 강의 감사합니다. 네트워크 공부하는데, 이해의 폭이 더 넓어졌습니다^^
좋은 평가 감사합니다. 열공하시고 더 좋은 성과 거두시기 바랍니다. ^^
드디어 제목 어그로에 눈을 떠버리심 ㅋㅋㅋ
이건 매우 중요하니까요. 낚아서라도 보게 해야 합니다. ^^;;;
@@nullnull_not_eq_null 리스펙!!!!
@@nullnull_not_eq_null 감사합니다
포트포워딩 찿다가 들렀는데 어설프레
그러려니 했던 개념에 눈하나가 트였네요
😂😂😂👏👏👏👏
이 댓글 보고 안보고 스킵 합니다~
안녕하세요. 먼저 좋은 강의 감사하다는 말씀 드리고 싶습니다! 요번에 주니어개발자가 되었는데 비전공자라 네트워크 지식이 전무해서 어려움을 느끼고 공부하려고 이것저것 찾아보던 찰나에 좋은 강의 접하게 되어 기쁩니다.
초보자가 듣기에도 설명이 명쾌하고 그림 그리면서 하나씩 반복해서 짚어주시니 이해도 잘 됩니다! 다만, 곧 지금까지 올려주신 네트워크 기초 이론을 다 듣게될 것 같아서 좀 더 공부해보고 싶은데 혹시 어떤 내용 혹은 책을 공부해보는 것이 좋을까요?
우선 HTTP 프로토콜에 대해서 자세히 공부하기를 권합니다. 좋든 싫든 지금의 상당수 IT 환경은 Web 기술로 설명됩니다. 만일 L3~4 수준의 공부를 이어가고 싶은 것이라면 차라리 CCNA 같은 자격증 공부를 해보는 것도 좋겠다 싶습니다. 그러나 혹시 아예 라우터를 직접 만들어보고 싶다면 C/C++을 정말 열심히 공부하고 WinPcap 라이브러리 정도는 다뤄보는 것이 좋겠습니다.
Wait가 걸리는 부분
1. ACK로 인한 Wait
2. Windows Size의 크기로 인한 Wait -> Windows Size가 점점 줄어드는 것은 Client의 Read가 느려지면서 점차 Windows Size의 공간이 커져가기 때문에
수신측에서 버퍼를 비우는 속도가 느려지면 Window size는 줄어듭니다. 즉, 수신버퍼가 점점 꽉 차가는 것이라 하겠습니다. 참고하시기 바랍니다. :)
기술면접 대비해서 공부중이었는데 비전공자라 잘 몰랐던 부분이었는데 대학강의 듣는줄 알았습니다. 감사합니다. : D
어떤 분야 기술면접 준비 중인데 이 영상을 보게 됐는지 궁금하네요. 좋은 결과 있으시길 바랍니다. 건투를 빕니다!
@@nullnull_not_eq_null 백엔드 개발자입니다 ^^전공 지식이 약한것 같아 자주 보고 있습니다. 감사합니다.
@@지돌쓰벱베 아...그렇군요. 건투를 빕니다. 즐프하세요. ^^
이 어려운내용을 풀어내는 능력보고 놀래서 영상보다가댓글남깁니다;;
좋은 평가 고맙습니다. 다만, 비속어는 수정을 요청드립니다. 제가 아니라 유튜브에서 댓글을 지워버릴 수 있습니다. :)
@@nullnull_not_eq_null 넵 수정했어요 :) 유튭강의 정주행하고 인프런까지 달려볼게여
아직 많이 모르는 대학생 1학년이지만 명강의 덕분에 이해가 쏙쏙 되었습니다.. 프로그램에서 버퍼에 있는 것을 빨리 끄집어내야지 속도가 빨라질 것이군요.... 읽는속도가 네트워크 수신 속도 보다 빨라야 한다 잘 새기겠습니다. UDP는 그러면 신뢰성(쓰핸쉐)이 없어서 막 보내므로 wait이 없는 것일 텐데.. 그래서 더 빠른 것이겠네요
네, 맞습니다. 수신자에 대한 배려가 전혀 없으며 그 만큼 빠른 전송이 가능합니다. 그리고 원한다면 소켓 수준에서 개발자가 흐름제어 로직을 만들 수도 있습니다. 관심이 있다면 UDP기반 혼잡 제어 로직이 적용된 프로토콜을 설계해보기를 권합니다. 그 후 HTTP/2에 대해서도 알아보시기 바랍니다. 좋은 공부가 될 것입니다. :)
좋은 강의 감사드립니다. 아직 기초부터 배워가는 1년차 NW SE로써, 단순히 TCP/UDP의 통신속도 차이를 수신확인 여부에 의한 것으로만 인식하고 있던 중에, 새로운 사실 배워갑니다. 앞으로도 잘 부탁드리겠습니다. 조금 기초적인 질문일수도 있겠습니다만, 말씀하신 Window size로 인한 지연 문제가 발생할경우, 로그 등으로 확인할 때에는 패킷로스 비율로 나타날 수 있나요?
Packet loss는 말 그대로 '손실'입니다. Window size는 ACK를 모니터링하거나 Window Update를 모니터링하면 알 수 있습니다. 참고하시기 바랍니다.
인서울 4년대 전공자입니다. 널널한 개발자님의 '이것이 c++이다' 교재로 수업을 들은 기억이 있네요.
예전 전공 교수님보다 잘 가르치시고, 내용도 풍부하고, 이론과 실전이 잘 결합돼서 대학교 네트워크 강의보다 좋은 것 같습니다.
널널한 개발자님의 네트워크 강의를 정주행한다면 웬만한 전공자보다 네트워크에 더 많은 지식을 얻을 거라 확신합니다.
교재로 제 책을 사용하는 학교가 있는 줄은 몰랐습니다. 학교 수업에 맞춰진 책이 아니었는데...공부를 방해하지는 않았는지 걱정이 되네요. 좋은 평가와 피드백을 주신 것으로 보아 그래도 큰 문제는 없으셨나 봅니다. 좋은 평가와 피드백 감사합니다. ^^
초보 인프라엔지니어 입니다.. 시청 완료했습니다.. 기억이 흐릿해질 때 쯤 다시 와서 돌리겠습니다.. 화이팅
인프라 엔지니어라면 잘 기억해두기를 강력히 권합니다. 피드백 감사합니다. ^^
학교에서 그냥 그렇구나 하고 걍 외우고 넘어간걸 자세히 들으니까 이해가 쏙쏙 되네요
좋은 평가와 피드백 감사합니다. 학교에서 관련 분야를 전공하시나 보네요. ^^
이 영상보고 인생이 바뀌는 것 같아서 바로 로또 예약 걸었습니다 .감사합니다!!!! 추가 댓글이 없으면 계속 변신중 인것으로 하겠습니다!!
와우~~~! 무려 로또 ^^;;; 로또 번호추천 프로그래밍 강좌라도 만들어야 할까 싶네요. 의견 감사합니다. ^^