Computer Network & Web 면접 질문 요약

Computer Network & WEB 질문

Q. 브라우저 주소창에 http://www.test.com 입력 후 엔터를 눌렀을 때 부터 페이지가 렌더링되는 과정을 상세히 설명하세요.

A. 아래와 같다

1. local DNS 서버에게 www.test.com에 해당하는 ip주소가 있는지 물어본다. 있다면 바로 해당 ip로 받아온다.
2. local DNS 서버에 없다면 루트 DNS 서버에 물어본다. 있다면 바로 해당 ip로 받아온다.
3. 루트 DNS 서버에 없다면 .com 을 관리하는 DNS 서버에 물어본다. 있다면 바로 해당 ip를 받아온다.
4. .com 을 관리하는 DNS 서버에 없다면, test.com을 관리하는 DNS 서버에 물어본다. 있다면 바로 해당 ip를 받아온다.
5. 목적지의 ip를 알게되었으니 TCP 통신을 통해 소켓을 개방한다.
6. HTTP 프로토콜로 요청한다.
7. 만약 라우팅 중 프록시 서버를 만난다면 웹 캐시에 저장된 정보를 response 받는다.
8. 프록시 서버를 만나지 못해 www.test.com을 서빙하는 서버까지 간다면 서버에서 요청에 맞는 데이터를 response로 전송한다.
9. 브라우져의 loader가 해당 response를 다운로드할지 말지 결정을한다.
10. 브라우져의 웹 엔진이 다운로드한 .html 파일을 파싱하여 DOM 트리를 결정한다.
11. .html 파싱중 script 태그를 만나면 파싱을 중단하는 것이 원칙(지연 가능).
12. script 태그에 있는 자원을 다운로드 하여 처리가 완료되면 다시 파싱을 재개한다.
13. CSS parser가 역시 .css 파일을 파싱하여 스타일 규칙을 DOM 트리에 추가하여 렌더 트리를 만든다.
14. 이 렌더트리를 기반으로 브라우져의 크기에 따라 각 노드들의 크기를 결정한다.
15. 페인트한다 : 렌더링 엔진이 배치를 시작한다.

Q.TCP 통신을 조금 더 자세히 설명해보세요.

A. 트랜스포트 계층에서 사용되는 프로토콜로 3-hand-shaking을 기반으로 신뢰할 수 있는 데이터를 보내는 것이 가장 큰 특징이다. 3-hand-shaking은

1. client -> server : SYC
2. server -> client : ACK+SYC
3. client -> server : ACK
   를 보내고 받음으로 서버와 클라이언트간의 연결성을 확립하는 것 이다.

Q. TCP 통신 시 2번 단계의 클라이언트가 서버가 보낸 ACK+SYC를 받지 못한다면 어떻게 되나요?

A. 1번단계에서 클라이언트는 서버로 SYC를 보내고 시간을 잰다. timeout이 되기전 까지 ACK+SYC가 오지 않는다면 다시 서버로 SYC를 보내고 ACK+SYC 수신을 대기한다.

Q. 만약 https://www.test.com 이라면 어떻게 동작하는가?

A. 5번 단계에서 3-hand-shaking에 몇가지가 더 추가된다.

1. client -> server : SSL정보 및 암호화방식, 무작위 바이트 문자열(A)
2. server -> client : 인증서, 무작위 바이트 문자열(B)
3. client가 CA에 인증서 목록에 있는지 확인 후 있다면 공개키를 받는다.
4. client -> server : 무작위 바이트 문자열 A와 B를 조합해서 확보한 공개키로 암호화한 데이터
5. server에서 비밀키로 받은 무작위 바이트 문자열 조합을 복호화한다. 이 조합을 가지고 session key를 만든다.
6. 해당 session key를 가지고 암호화한 데이터를 주고 받는다.

Q. 프록시 서버 기능에 대해 설명해보시오.

A. 클라이언트가 프록시 서버를 통해서 다른 네트워크 서비스에 간접적으로 접근을 할 수 있게 하는 것을 말한다. 프록시 서버는 요청된 내용들을 캐시에 저장을하고 다음에 같은 요청이 들어온다면 캐시에 저장된 정보를 제공함으로써 전송시간을 줄일 수 있다.

Q. 말씀하신 기능대로 라면 프록시 서버 캐시에 저장된 내용을 계속해서 다운로드 받게될텐데 페이지가 바뀌는 업데이트를 했거나, 값이 계속해서 바뀐다면 어떻게 처리하나요?

A. 실제 서버에서 응답할 때 캐시 만료기한을 설정해두면 됩니다. 프록시서버라도 최초로 받는 요청에는 실제 서버로 요청을 보내야하기 때문에 그 때 실제 서버에서 캐시 만료기한을 설정해서 프록시 서버로 보내면 됩니다. 그러면 프록시서버로 사용자가 요청을 했을 때 요청한 시각이 프록시에서 다운로드 받은 시간에서 만료기한 이내이면 프록시에서 다운로드를 할 것이고 그렇지 않다면, 다시 실제 서버로 요청을 하게 될 것입니다.
저 역시 배포시에 위와 같은 문제를 겪었는데 배포때를 제외하고는 모두 캐시되는게 좋다고 판단하여 Vue.js로 빌드할 경우 index.html에서 요구하는 css, js파일들의 파일명을 바꾸어서 해결했었습니다.

Q. HTTP와 프로토콜에 대해 설명하세요.

A. Hyper Text Transfer Protocol의 약자로 인터넷에서 데이터를 주고 받을 수 있는 프로토콜입니다. 프로토콜은 컴퓨터나 다른 원거리 장비들 간의 메시지를 주고 받기 위해 지켜야하는 일종의 규약이다.

Q. HTTP REQUEST 방식 중 GET과 POST의 차이에 대해 설명해보세요.

A. GET방식은 서버에 데이터를 전달하기 위해서는 url query로 밖에 전달을 할 수가 없어 보안에 취약하다. 그래서 GET은 데이터를 받는 용도로 사용하는데 적합하다. 반면에 POST방식은 서버로 전달하고자 하는 데이터를 header에 넣어서 전달을 한다. 헤더를 직접 열어보지 않는 이상 확인할 수 없다. 또한 HTTPS을 사용할 경우 해당 내용이 암호화되기 때문에 더더욱 안전하기 때문에 POST방식은 DB의 내용을 갱신해야하거나 서버로 데이터를 전달해야할 때 쓰는 것이 적합하다.

Q. GET, POST를 제외하고 다른 방식들 중 아는게 있나?

A. PUT, DELETE, FETCH 말고도 상당히 많은 것으로 알고있다. PUT은 데이터 갱신용, DELETE는 데이터 삭제용으로 사용해본적 있지만, FETCH 포함하여 나머지는 사용해 본적은 없다.

Q. HTTP는 비연결성 프로토콜이냐? 연결성 프로토콜이냐?

A. 비연결성 프로토콜입니다. REQUEST에 대한 RESPONSE만 전달이 되고 연결을 유지하지 않습니다.

Q. 왜 비연결성인가?

A. 초기 HTTP가 고안됬을 때는 뜻을 보면 알 수 있듯이 Hyper Text를 주고 받기 위해 만들어져서 따로 연결을 할 필요가 없기 때문으로 알고 있습니다.

Q. 현대 웹 에서는 비연결성을 해결하기 위해 어떻게 하는가?

A. 전통적으로 Cookie와 Session을 많이 이용한다. Cookie에 클라이언트에 대한 정보를 저장해뒀다가 사용하거나 Session을 등록해서 유지하는 방식으로 많이쓴다. HTML5에서 제공하는 Session Storage나 Local Storage도 사용할 수 있다. 세션 스토리지는 세션이 유지되고 있을 때 까지는 브라우저 내부 스토리지에 저장을 하고 세션이 끊키면 자동으로 없어진다. 로컬 스토리지 같은 경우는 사용자나 프론트엔드 내부적으로 삭제를 하지 않는 이상 영구적으로 저장된다.

Q. Cookie, Session, Session Storage, Local Storage 중 어떤 것이 가장 효율적인가요?

A. 정답은 없다고 생각한다. 프로젝트의 목적성과 타겟에 맞게끔 개발자가 직접 정해야한다. 모든 브라우져에서 지원되어야 하는 호환성이 굉장히 중요한 e커머스 경우에는 Session Storage나 Local Storage를 쓰기에는 무리가 있다.

Q. Front-End 개발시 호환성 체크는 어떻게 하나요?

A. 저 같은 경우는 stack browser를 사용해서 체크하고, 많이 사용되는 IE같은 경우에는 로컬으로 접속해서 부가적으로 확인을 재차한다. IOS에 있는 브라우져는 로컬에 XCODE 시뮬레이터로 아이폰 브라우져를 체크하고 안드로이드는 안스에 있는 에뮬레이터로 주로 사용되는 기종들만 체크했다.

Q. CORS문제는 겪어본적 있는가?

A. 당연히 겪어봤다

Q. 자바스크립트에서 HTTP request를 동기로 호출하고 값을 처리하면 발생하는 문제점이 무엇인가?

A. Request에 대한 Response에 받는 응답시간이 길어질 수도 있기 때문에 절차 지향적으로 짜놓은 코드가 제대로 동작하지 않을 수도 있다.

Q. 위와 같은 문제를 해결하기 위한 방법은 무엇이 있는가?

A. CallBack 함수를 만들어 호출하면 해당 REQUEST에 대한 응답이 온 후에 이후에 그값을 가지고 다시 다른 함수를 실행한다.

Q. 콜백함수의 문제점이 무엇인가? 그리고 거기에 대한 해결책은?

A. 콜백함수를 이용하여 비동기처리를 많이 하게되면 콜백헬이라 불리는 가독성이 엄청나게 떨어지는 코드를 만들게 된다. 이러한 가독성저하는 유지보수에 문제를 야기할 수 있으므로 Promise 나 Async/Await을 사용하면 해결할 수 있다. Promise에서는 요청 후 비동기 처리하는 부분은 then절에 추가하면 되고 Async/Await는 Await이 then절과 같은 역할을 한다.

Q. Promise vs Async/Await 당신의 선택은?

A. ES7에 Async/Await 문법이 추가되었다고 들었다. 그만큼 많은 사람들이 쓴다고 비교했을 때 장점으로 치면 try & catch를 이용해서 예외처리를 할 수 있고, 간단한 비동기 처리 경우에는 확실히 가독성이 뛰어나다는 점이였다. 그러나 나는 Promise를 선호하는 편이다. Async/Await가 Promise로 구성되있다는 사실을 접하게 되었고 Promise를 잘 모르는 상태로 Async/Await를 쓰면 알 수 없는 오류에 빠지기 쉽다는 글을 보았다. Promise로 다양한 비동기 처리를 경험해보고 다양한 오류를 만나기 전까지는 Promise로 더 공부를 하는게 나에게 맞는다고 생각한다.

Q. Angular를 처음 선택한 이유는 무엇인가?

A. 처음 Front-End 프레임워크를 선정하여 공부할 때 확실히 하고 싶었다. Angular가 자료도 방대했고 react나 Vue.js 보다 튜토리얼도 잘 지원하였고, typescript 때문에 진입장벽이 높다고들 하지만 오히러 JAVA나 C++과 비슷한 느낌이들어 크게 어렵지 않았다. 모든 프레임워크에서 겪을 만한 Component를 나누는 기준이나 MVC 기반 설계와 같은 부분이 더 어려웠다.

Q. 그렇다면 마이그레이션할 프레임워크를 Vue.js로 선택한 이유는 무엇인가?

A. 가장 큰 문제는 첫 페이지 렌더링 속도였다. Angular가 다른 프레임워크에 비해 무겁고 렌더링이 느리다. 빌드옵션을 JIT에서 AOT로 변경하고, 의존성 모듈을 최소화 시켜 일부 해결하긴 했지만 만족스럽지 못했다. 그러던 와중에 마이그레이션을 결심하게 되었고 React와 Vue.js 사이에 많은 고민을 했는데 React는 Angular와 컴포넌트의 구조가 조금 다르기도 했고 Redux 나 Flux 같은 라이브러리도 꽤 많이 공부해야겠다는 생각이 들었다. 리액트의 최대 강점인 가상DOM도 Vue.js 2.0에 도입이 되었고 Vue.js 소개페이지에 보면 렌더링 속도도 가장 빨랐기에 Vue.js를 선택하게 되었다. 마지막까지 고민되었던 점은 REACT 생태계?가 훨씬 더 크기 때문에 훨씬 모르는 부분을 찾기가 수월할 것이라는 점이였지만 Vue도 나름의 커뮤니티가 있었기에 최종적으로 Vue.js를 선택하였다. 마이그레이션 당시 Vue Forum에 몇가지 질문할게 있어 질문을 올리면 빠르면 2시간 늦어도 하루이틀내로 원하는 답을 들을 수 있어서 진행하는데 크게 문제되지는 않았다.

Q. AOT와 JIT에 대해 설명해주세요.

A. JIT는 Just In Time Compile의 약자로 브라우저에서 템프릿 컴파일을 진행하기 때문에 느리다. 또한 JIT 컴파일러를 포함해야하기 때문에 용량도 크다.

AOT는 Ahead Of Time Compile의 약자로 빌드 시 템플릿을 먼저 컴파일을 해둔다. 빌드에는 시간이 더 소요되지만 브라우저에서는 컴파일이 실행되지 않기 때문에 꽤나 빠르다.

그래서 개발 시에는 JIT 방식으로 빠르게 빌드해서 변경사항을 확인하고, 실제 서비스 배포시에는 AOT방식으로 빌드해서 전체 용량 감소 및 컴파일 시간을 없애야한다.

Q. 가상DOM을 설명해주세요.

A. 가상돔은 추상화한 돔이다. 만약 가상돔을 사용하지 않고 div 태그 1000개에 css 효과가 추가된다고 가정을 한다면 이 천개의 돔노드들을 일일이 검색하고 업데이트를 해줘야한다. 이러한 탐색비용과 업데이트 비용을 좀 더 줄이고자 추상화한 돔에서 탐색과 업데이트를 한 후 변경사항을 실제 돔에 반영한다. 가상돔은 어떻게 돔을 추상화할 것인지, 언제 돔에 변경사항을 적용시킬지에 대한 알고리즘이 핵심이다.

Q. Vue.js는 어떻게 돔을 추상화하고, 언제 돔에 변경사항을 적용시키나요?

A. 이거는 Vue.js를 까봐야 아는데.. 물어보면 모른다해야겠다...