yiyj10305235

강의 내용이 업데이트되었으니 참고바랍니다!

네트워크 전체 흐름 복습 질문

안녕하세요, LoDf님!1. 목적지 IP 설정 관련클라이언트는 외부에서 서버의 사설 IP를 알 수 없으므로, 말씀하신 대로 패킷 생성 시 목적지는 반드시 서버의 공인 IP여야 합니다. 기존 자료에서 '서버 IP'라고만 표기하여 혼동을 드린 것 같은데, 이 부분은 클라이언트가 DNS를 통해 알아낸 공인 IP라는 점을 더 명확히 인지할 수 있도록 수정하겠습니다.2. 출발지 IP 변환 관련53페이지에서 출발지 IP가 라우터 B의 사설 IP로 변경된 부분은, 강의 자료를 정리하는 과정에서 일반적인 인터넷 통신 방식과 특수한 케이스인 Full NAT 방식이 일부 혼동되어 반영되었습니다. 지적해주신 대로 일반적인 포트 포워딩(DNAT) 환경에서는 서버가 실제 접속자를 식별할 수 있도록 출발지 IP를 변환하지 않고 그대로 유지하는 것이 맞습니다.&nbsp;향후 조치 사항빠른 시일 내에 해당 챕터의 슬라이드와 대본을 표준 DNAT 방식(출발지 IP 유지)으로 업데이트하겠습니다.&nbsp;감사합니다.

안녕하세요, 이지우님! 말씀하신대로 단순화하고 처리속도를 높이기 위해서입니다. 모두 양수로 변환해두면, 수를 비교할때 부호 없는 정수를 비교하듯이 왼쪽에서 오른쪽으로 비트를 훑으며 바로 크기를 판별할 수 있습니다. 즉, 하드웨어 수준에서 비교 연산 속도를 극대화하기 위한 설계입니다. 참고로 왜 127을 더하는지에 대한 답변은 <a target="_blank" rel="noopener noreferrer nofollow" href="https://inf.run/yYiXf">다른 질문</a>을 참고해주세요! 감사합니다.

127을 더하는 이유?>

안녕하세요, 쉽지않네님! 좀 더 깊이 설명드리자면, DHCP 과정에서 서버는 클라이언트의 MAC 주소 역시 수집합니다. 제일 처음 보낸 '저 IP 좀 주세요'라는 신호(Discover) 안에 MAC 주소가 포함됩니다. 서버는 이걸 보고 "아, 이 번호를 쓰는 컴퓨터가 요청을 보냈구나"라고 기억해 둡니다.그래서 서버가 마지막에 ACK 패킷을 보낼 때, 겉면에는 할당해 줄 IP 주소를 적어두지만 실제 배달은 미리 수집한 MAC 주소를 보고 보냅니다. 감사합니다.

DHCP 동작 과정 그림의 DHCP ACK에서 질문이 있습니다.

안녕하세요, 김태우님! 질문 주신 내용이 정확합니다.강의 슬라이드 오른쪽의 JVM 구성도 그림을 보시면 자바 컴파일러가 <code>.class</code> 파일을 만드는 과정이 명확히 구분되어 있는데, 좌측의 요약 텍스트를 정리하는 과정에서 표현이 다소 혼용되었네요.지적해주신 대로 자바 코드를 바이트 코드로 변환하는 것은 '자바 컴파일러'의 역할이며, JVM은 이 바이트 코드를 기계어로 해석하여 실행하는 역할을 수행합니다.혼란을 드려 죄송하며, 해당 텍스트 설명 부분은 빠른 시일 내에 수정하도록 하겠습니다. 발견해주셔서 감사드립니다!

JVM - 자바 가상머신의 구조와 실행 매커니즘 2. 자바개요 부분에서 질문 있습니다.

안녕하세요. 이지현님! 결론부터 말씀드리면 강의 내용이 수정되어야 하는 것이 맞습니다.자바스크립트의 모든 함수는 일급 객체 취급하기 때문에 객체가 맞고 그에 따라 <code>__proto__</code> 속성을 갖습니다. 이때 <code>Parent.__proto__</code>는 <code>Function.prototype</code>을 참조하게 됩니다.<code>Function.prototype</code>은 <code>Parent.prototype</code>과는 별개이며<ul><li><code>Function.prototype</code>은 Parent 함수가 참조하는 프로토타입이고</li><li><code>Parent.prototype</code>은 함수를 통해 생성된 인스턴스가 참조하는 프로토타입입니다.</li></ul>즉, 함수는 누군가의 자식인 동시에 누군가의 부모가 될 수 있는 이중적인 구조를 가집니다.놓친 부분을 바로 잡아주셔서 감사드립니다. 강의는 수정하여 재업로드하도록 하겠습니다.감사합니다.

생성자 함수 프로토 타입

안녕하세요, jungmin257님! 워크북까지 성실히 학습해주셔서 감사합니다. 네. 말씀해주신대로 '다음 실행할 명령어의 주소를 저장하는' 역할은 변함없습니다.IF(명령어 인출) 단계에 PC 값이 업데이트된다는 것도 맞습니다.다만 질문의 취지를 생각해봤을 때파이프라인 구조에서는 좀 더 복잡한 제어 흐름 관리가 요구됩니다. 비파이프라인 구조에서도 분기나 점프가 발생하면 PC 값은 변경됩니다.하지만 파이프라인에서는 이미 여러 명령어가 동시에 각 단계에 들어가 있는 상태이기 때문에,분기나 점프가 발생하면:- PC 값을 수정해야 하고- 이미 인출된 잘못된 명령어를 제거해야 할 수도 있으며(flush)- 경우에 따라 분기 예측과 같은 기법이 필요해집니다.즉, PC의 역할 자체는 동일하지만,파이프라인 구조에서는 PC 갱신이 시스템 전체 흐름에 더 큰 영향을 주게 되고,제어 흐름 관리가 훨씬 복잡해집니다. 감사합니다.

워크북 질문 중에서 질문이 있습니다.

안녕하세요, redbean님.말씀해주신 것처럼 TCB는 TCP 연결의 시퀀스 번호, 윈도우, 연결 상태 등을커널 내부에서 보관하고 관리하는 구조를 의미합니다.강의에서 TCB라는 용어 자체는 별도로 다루지 않았지만,3-way handshake, 순서 보장, 흐름/혼잡 제어를 설명하는 과정에서실제로 TCB에 저장되는 상태 정보들은 이미 모두 활용해 설명드린 내용입니다.이번 강의에서는 TCP의 동작 원리와 흐름 이해에 필요한 범위에 초점을 두어,커널 내부의 구현 레벨 개념인 TCB 자체는 별도로 상세히 다루지 않았습니다.

TCB에 대한 설명은 없는것 같은데 이유가 있을까요?

안녕하세요. 곽민재님! 현대적인 어플리케이션 프로그래밍 관점에서는 말씀해주신대로 제어권(Blocking)과 결과 확인(Sync)을 철저히 구분해서 사용하는 추세입니다. 하지만 시스템 표준인 POSIX나 Windows/Linux API 레벨의 전통적인 정의에서는, I/O 작업이 진행되는 동안 실행 흐름이 멈추느냐(Synchronous) 아니면 따로 노느냐(Asynchronous)를 기준으로 용어를 사용해온 것으로 보입니다. 아래의 참고 자료에서 그 내용을 확인할 수 있습니다. 참고 자료<ul><li><a target="_blank" rel="noopener" class="ng-star-inserted" href="https://learn.microsoft.com/en-us/windows/win32/fileio/synchronous-and-asynchronous-i-o">MS 공식 문서: Synchronous and Asynchronous I/O</a></li><li><a target="_blank" rel="noopener" class="ng-star-inserted" href="https://man7.org/linux/man-pages/man7/aio.7.html">Linux Manual: POSIX Asynchronous I/O (aio.7)</a></li></ul>P.S. 질문을 통해 저도 많이 배웠네요. 감사합니다 :)

블로킹/논블로킹과 동기/비동기

안녕하세요, summerender님.말씀하신 대로 시스템 콜은 넓게 보면 소프트웨어 인터럽트에 속하지만, 물리적인 인터럽트 라인이 세팅되는 것은 아닙니다. 혼동을 피하기 위해 다음과 같이 자료를 수정하겠습니다.<ol><li>기존: 프로세스 A는 인터럽트를 발생시킴 => CPU의 인터럽트 라인에 인터럽트가 세팅됨</li><li>수정: 프로세스 A가 시스템 콜(소프트웨어 인터럽트)을 실행함 => CPU가 이를 인지하고 모드를 커널 모드로 전환하여 운영체제에게 제어권을 넘김</li></ol>정확한 동작 원리를 짚어주셔서 감사합니다.

yiyj10305235

Bài viết