모의면접 4주차 - 브라우저의 동작 원리 / HTTP / 네트워크

H Kim·2022년 3월 14일

모의인터뷰

목록 보기
5/9
post-thumbnail

브라우저 동작 원리

Q. 브라우저 렌더링 (작동) 원리에 대해 설명하세요

  • Loading
  • DOM Tree: HTML 마크업을 처리하고 DOM 트리를 빌드한다. ("무엇을" 그릴지 결정)
  • CSSSOM Tree: CSS 마크업을 처리하고 CSSOM 트리를 빌드한다. ("어떻게" 그릴지 결정)
  • Rendering Tree: DOM과 CSSOM을 결합하여 렌더링 트리를 형성한다 ("화면에 그려질 것만" 결정)
  • Layout: "Box-Model"을 생성한다.
  • Paint: 화면에 그린다.

Q. 웹페이지가 사용자에게 보여지는 과정에 대해서 설명하세요.

  • Prompt for unload
    현재 페이지에서 다른 페이지로 이동할 때 발생하는 이벤트. 뒤로가기 버튼이나 링크를 눌러 다른 도메인의 페이지로 이동할 경우 발생한다.
  • Redirect ~ Response
    네트워크 통신. 요청을 받고 HTML 파일 등의 리소스를 브라우저로 가져오는 일련의 과정이다. AppCache 는 이미 요청한 응답에 대한 캐싱을 확인해서 캐싱된 데이터가 있다면 통신을 또 하지 않고 바로 사용해서 퍼포먼스 효율을 높인다. DNS는 도메인을 서버의 IP 주소로 변환하는 역할을 한다. TCP 레이어에서 요청이 성공적으로 이루어지면 Response가 온다.
  • Processing
    다운로드한 HTML파일과 CSS파일을 활용해 DOM Tree와 CSSOM Tree를 만들어 렌더링 트리를 구성한다.
  • Load
    렌더 과정까지 마무리되면 다운로드한 파일을 사용자가 알아볼 수 있게 화면에 보여준다.

Q. Client Side Rendering 과 Server Side Rendering 의 차이에 대해서 설명하세요.

  • CSR
    • 웹 페이지의 렌더링이 클라이언트 (브라우저) 측에서 일어나는 것이다.
    • 서버와 클라이언트 간의 데이터 트래픽이 감소하고 렌더링이 한번만 있기 때문에 페이지 이동이 빠르다.
    • SEO(검색최적화) 사용은 불가능하다.
    • 보안 관련해서는 쿠키에 사용자 정보를 저장해야 해서 위험 요소가 될 수 있다.
    • 초기로딩속도가 느리긴하지만, 화면전환에 있어서 클라이언트에서 이루어져서 빠른 전환이 가능하다.

  • SSR
    • 첫 페이지의 렌더링을 클라이언트 측이 아닌 서버 측에서 처리한다.
    • 버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 보여주는 방식이기 때문에 SEO 측면에서 유리하다.
    • View 변경이 될 때마다 계속적으로 서버에 요청을 해야 하기 때문에 서버 부담이 커진다.
    • 보안 관련해서는 서버에서 세션으로 사용자의 정보를 저장할 수 있다.
    • 초기로딩속도가 빨라서 사용자가 느끼기엔 좋지만, 동작은 하지 않는다.

두 방법 중 더 좋은 방법이라는 것은 없으며 각자의 장단점을 가지고 있기 때문에 만들려고 하는 서비스의 성질을 파악하여 적절한 것을 골라서 쓰는 것이 바람직하다.


Q. 프론트엔드 입장에서 신경써야 할 보안은 어떤 것들이 있나요?

  • CSRF(Cross Site Request Forgery / 사이트 간 요청 위조)
    • 특정 사이트가 사용자의 브라우저를 신뢰하는 점을 이용해서 다른 사이트에서 유저가 보내는 요청을 조작해 공격하는 방식이다. 이는 서버에서 발생한다.
    • 예방법
      • referrer 검증 (SameSite 쿠키 설정): 서버에서 request의 referrer을 확인하여 도메인이 일치하는지 검증하는 방법.
      • Security Token 사용 (CSRF Token): 사용자의 세션에 임의의 난수값을 저장하고 사용자의 매 요청마다 해당 난수 값을 포함시켜 전송 후 서버에서 검증. 서버 측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공.
      • Double Submit Cookie 검증: Security Token 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법. 스크립트 단에서 요청 시 난수 값을 생성하여 쿠키에 저장하고 동일한 난수 값을 요청 파라미터에도 저장하여 서버로 전송한다.

  • XSS(Cross Site Scripting)
    • 공격자가 상대방의 브라우저에 Script를 실행할 수 있게 하여 사용자의 세션을 가로채거나 웹 사이트 변조, 악의적 컨텐츠 삽입, 피싱 공격을 하는 것이다.
    • 예방법
      • 중요한 정보를 쿠키에 저장하지 않는 것
      • 정규표현식을 사용한 태그 입력 필터 설치
      • HTML 포맷의 입력 제한

Q. SPA의 장점이 무엇인가요?

Single Page Application의 약자로서 하나의 페이지로 구성된 애플리케이션을 뜻한다.

사용자가 요청한 각각의 페이지를 서버가 생성해서 전달해주는 것이 아니라, 클라이언트가 동적으로 페이지를 다시 작성하는 방식이며, 첫 페이지 요청 시 단 한번만 리소스를 로딩하고 그 이후로는 페이지 로딩 없이 필요한 부분만 서버로부터 받아서 화면을 갱신한다.

  • 클라이언트가 모든 페이지를 가지고 있으므로 앱과 같은 자연스러운 사용자 경험을 제공한다. 사실상 로딩 이후에는 모바일 앱과 동일한 방식으로 동작을 한다고 볼 수 있다. 페이지를 이동 하더라도 필요한 부분 (컴포넌트)만 부분적으로 교체하면 되므로 효율성이 증가한다.
  • 서버가 해야 할 화면 구성을 클라이언트가 수행하므로 서버 부담이 경감된다.
  • 모듈화 또는 컴포넌트별 개발이 용이하다.
  • 백엔드와 프론트엔드가 비교적 명확하게 구분된다.
  • 앱과 웹이 동일한 서버를 이용할 수 있다.
  • PWA(Progressive Web App)과 궁합이 잘 맞는다.

Q. lazy loading이 무엇인가요?

페이지를 읽어들이는 시점에 중요하지 않은 리소스 로딩을 추후에 하는 기술이다. (페이지 내에서 바로 필요하지 않은 이미지들의 로딩 시점을 뒤로 미루는 기술)

예를 들어 페이지 브라우저 뷰포트에서 보여지는 이미지만을 로드하고 나머지 이미지는 스크롤 이벤트가 발생했을 때 다시 로드하는 방식의 무한스크롤이 그 일례이다.이 기술을 통해 웹 성능을 향상시키고 통신 비용을 줄일 수 있다.

기존의 경우 사용자가 웹 페이지를 열면 전체 페이지의 내용이 다운로드 되어 단일 이동으로 렌더링이 된다. 이를 통해 브라우저는 웹페이지를 캐시할 수 있지만 사용자가 다운로드한 모든 콘텐츠를 실제로 본다는 보장은 없다. 이럴 경우 데이터는 이미 다 받아서 캐싱해 놓았는데 사용자가 떠나버리면 웹페이지에서는 메모리 및 대역폭 낭비가 발생할 수 있다. 따라서 페이지에 액세스할 때 모든 콘텐츠를 대량으로 로드하는 대신 사용자가 필요한 페이지의 일부에 액세스할 때 콘텐츠를 로드할 수 있는 방식이 도입되었다.


Q. 웹페이지 redirect의 다양한 구현법에 대해서 설명하세요.

  • HTTP 리다이렉트
    3xx 상태코드를 지닌 응답을 활용해 리다이렉트를 할 수 있다. 리다이렉트 응답을 수신한 브라우저는 제공된 새로운 URL을 사용해 즉시 로드한.

  • HTML 리다이렉트
    meta 태그와 http-equiv 속성으로 가능하지만 브라우저에서 뒤로가기 버튼을 무용지물로 만들기 때문에 지양해야 하는 방법이다.

  • JavaScript 리다이렉트
    window.location 코드를 통해 리다이렉트가 가능한다.


Q. Reflow가 발생하는 이유와 방지 방법은 무엇인가요?

Reflow는 브라우저 렌더링을 위해 DOM 트리를 그리는 과정에서 발생한다. 생성된 DOM 노드의 레이아웃 수치(너비, 높이, 위치 등) 변경 시 영향 받은 모든 노드의(자신, 자식, 부모, 조상(결국 모든 노드) ) 수치를 다시 계산하여(Recalculate), 렌더 트리를 재생성하는 과정이다.


이러한 Reflow는 아래와 같은 경우 발생한다.

  • 노드의 추가 또는 제거
  • 요소의 위치 변경
  • 요소의 크기 변경 (margin, padding, border, width, height, 등..)
  • 폰트 변경 과(텍스트 내용) 이미지 크기 변경(크기가 다른 이미지로 변경 시)
  • 페이지 초기 랜더링 (최초 Layout 과정)
  • 윈도우 리사이징

Reflow 최적화 방법

  • 클래스 변화에 따른 스타일 변경 시, 최대한 DOM 구조 상 끝단에 위치한 노드에 준다. 가급적 말단에 위치한 노드의 수치를 변경하면 리플로우 수행 반경을 일부 노드로 제한시킬 수 있기 때문이다.
  • 인라인 스타일을 최대한 배제한다. 코드 가독성 또한 높일 수 있다.
  • 애니메이션이 들어간 노드는 가급적 position:fixed 또는 position:absolute로 지정하여 전체 노드에서 분리 시킨다. 보통 JS + CSS 애니메이션 효과는 해당 프레임에 따라 무수히 많은 Reflow 비용이 발생하는데 position 속성을 fixed, absolute로 주면 지정된 노드는 전체 노드에서 분리되어 해당 노드의 Repaint 비용만 들어가게 된다.

Q. 디자인 패턴이란 무엇이고 각각의 장단점에 대해서 설명하세요.

소프트웨어 개발 방법으로 사용되는 개념으로 과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 그 방법에 이름을 붙여서 이후에 재사용하기 좋은 형태로 특정 규약을 만들어서 정리한 것이다. 디자인 패턴은 소프트웨어 설계에 있어 공통적인 문제들에 대한 표준적인 해법과 작명법을 제안하며, 알고리즘과 같이 프로그램 코드로 바로 변환될 수 있는 형태는 아니지만, 특정한 상황에서 구조적인 문제를 해결하는 방식이다. 간단하게 말하면 효율적인 코드를 만들기 위한 방법론이다.

  • 생성 패턴(Creational Patterns)
    객체 생성에 관련된 패턴. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.
  • 구조 패턴(Structural Patterns)
    클래스나 객체를 조합해 더 큰 구조를 만드는 패턴입니다. 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 서로 다른 객체들을 묶어 새로운 기능을 제공하는 패턴.
  • 행위 패턴(Behavioral Patterns)
    객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴. 한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는것에 중점을 두는 방식이다.

네트워크 프로토콜

Q. OSI 7계층에 대해 설명해주세요.

OSI 7 계층은 ISO(국제표준화기구)에서 네트워크 통신 과정을 7단계로 정의한 표준 규약 네트워크이며 통신이 일어나는 과정을 7단계로 나눈 것이다. 이는 통신이 일어나는 과정이 단계별로 파악하기 위해서이다. 7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들이지 않고도 이상이 생긴 단계만 고칠 수 있기 때문에 흐름을 한눈에 알아보기 쉽다는 장점이 있다.


  • 1 계층(물리 계층): 단순하게 장비를 가동시키기 위한 전기 공급부터 장비 끼리의 물리적인 연결을 위한 랜 케이블, 그리고 무선통신을 위한 주파수까지 다양한 전기적/물리적인 것들을 포함한다. 광케이블, 전선과 같은 통신 케이블과 모뎀 등이 이 계층에 속한다.
  • 2 계층(데이터링크 계층): 1 계층의 물리적인 링크를 이용하여 데이터를 신뢰성있게 전송하는 계층이다. 브릿지나 스위치, 이더넷이 이 계층에 속하고 MAC Address로 통신한다.
  • 3 계층(네트워크 계층): IP를 기반으로 데이터가 들어있는 패킷을 이용해 데이터 전송 경로를 결정한다.
  • 4 계층(전송 계층): 데이터 전송에 대한 전반적인 조율을 담당하는 계층이다. 이 계층에서는 TCP/UDP 포트 정보를 참조해 데이터를 전송하며 통신의 신뢰성을 보장할 수 있다.
  • 5 계층(세션 계층): 데이터가 서로 만나는 환경을 조성해주는 단계로 이 계층에서는 통신 시스템 사용자간의 연결을 유지하거나 설정한다. TLS, SSH등이 이 계층에 속합니다.
  • 6 계층(표현 계층): 데이터를 더 빠르고 안전하게 전송하기 위한 압축, 그리고 더 안전하게 전송하기 위한 암호화/복호화 작업을 하는 계층이다. 이를 통해 위의 세션 계층 간의 주고받는 인터페이스를 일관성 있게 제공할 수 있다. JPEG, MPEG등이 이 계층에 속한다.
  • 7 계층(응용 계층): 도착한 데이터를 최종 사용자가 확인하는 마지막 단계이다. HTTP 프로토콜이 이 계층에 속한다.

Q. TCP와 UDP 방식의 차이점을 설명해주세요.

두 프로토콜 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어 있으나,

TCP의 경우 연결형 서비스로 가상 회선 방식을 제공한다. TCP는 데이터의 전달을 보증하며 전송 순서 또한 제어할 수 있기에 IP의 한계를 보완할 수 있다. 그래서 비연결형 서비스인 UDP에 비해 신뢰할 수 있는 프로토콜이다.

UDP는 비 연결형 서비스로 TCP와 같은 3way handshake를 사용하지 않는다. 그래서 데이터 전달이 보증되지 않고 전송 순서 또한 보장되지 않는다. 하지만 UDP는 IP 프로토콜에 PORT 정보와 체크섬 필드 정보만 추가된 단순한 프로토콜이기 때문에 TCP에 비해 속도가 빠르고 커스터마이즈가 가능하다는 장점이 있다.


  • TCP의 3 Way-HandShake와 4 Way-HandShake란?

TCP에서 장치간의 논리적인 접속을 성립하기 위해 사용하는 방식이다.

3 way handshake는 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정이다. 먼저 클라이언트가 서버에 접속을 요청하는 SYN 패킷을 보내면 클라이언트는 서버의 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 된다. 서버가 SYN요청을 받으면 클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다린다. 이때 서버는 SYN_RECEIVED 상태가 된다. 클라이언트는 서버에게 ACK을 보내고 이후로 부터는 연결이 이루어지고 데이터가 오가게 된다. 이때의 서버 상태는 ESTABLISHED 이다.

3-Way handshake는 TCP의 연결을 초기화 할 때 사용한다면, 4-Way handshake는 세션을 종료하기 위해 수행되는 절차이다.

클라이언트가 연결을 종료하겠다는 FIN플래그를 전송하면 서버는 일단 확인메시지를 보내고 자신의 통신이 끝날때까지 기다린다. 이때 서버의 상태는 TIME_WAIT이다. 서버가 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다. 그 후 클라이언트는 확인했다는 메시지를 보낸다. 서버에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황이 발생한다면 클라이언트에서 이 패킷은 Drop되고 데이터는 유실될 수 있기에 이에 대비하여 클라이언트는 서버로부터 FIN을 수신하더라도 일정시간동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 한다.


Q. DNS에 대해 설명해주세요.

DNS란 Host의 Domain Name을 Host의 IP로 변환해주는 서비스인 Domain Name Service를 말한다. www.example.com과 같이 사람이 읽을 수 있는 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 한다.

DNS는 전화번호부처럼 이름과 숫자 간의 매핑을 관리한다. DNS 서버는 이름에 대한 요청을 IP 주소로 변환하여 최종 사용자가 도메인 이름을 웹 브라우저에 입력할 때 해당 사용자를 어떤 서버에 연결할 것인지를 제어하는데 이 요청을 쿼리라고 한다.


DNS 서비스 과정

  • Host가 도메인 네임의 IP주소를 Local DNS서버에게 요청을 보낸다.
  • Local DNS서버는 루트 DNS 서버에게 Domain Name을 보내고 루트 DNS 서버는 com과 같은 최상위 도메인을 인식한 후 TLD 서버의 주소를 넘겨준다.
  • Local DNS서버는 TLD서버에게 Domain Name을 보내고 TLD 서버는 최상위 도메인과 서브도메인을 인식한 후 Authoritative 서버의 주소를 넘겨준다.
  • Local DNS서버는 Authoritative 서버에게 Domain Name을 보내고 전체 도메인 네임에 해당하는 Ip주소를 얻어온다.
  • Local DNS서버는 변환된 Ip 주소를 Host에게 넘겨주고 Host는 이 IP를 사용해서 어플리케이션 간에 통신을 할 수 있다.

Q. 프록시 서버가 필요한 이유에 대해 설명해주세요.

  • 캐시 데이터를 사용
    프록시 서버 중 일부는 프록시 서버에 요청된 내용을 캐시를 사용해 저장하는데, 그러면 캐시에 저장되어있는 내용에 대한 재요청은 서버에 따로 접속할 필요가 없이 저장된 내용을 그대로 돌려주면 되기 때문에 전송 시간을 절약할 수 있고 외부 트래픽을 줄임으로써 네트워크 병목 현상도 방지할 수 있다.

  • 보안 목적
    프록시 서버가 중간에 경유되게 되면 IP를 숨기는 것이 가능하기 때문이다. 또한 프록시 서버를 방화벽으로 사용하기도 한다(프록시 방화벽).

  • 접속 우회
    클라이언트가 위치한 국가에서 접속이 제한이 되는 사이트가 있는데 이런 경우 프록시 서버를 사용하면 접속을 다른나라로 우회할 수 있다. 우회에 사용할 서버 주소와 포트를 구한 후 '인터넷옵션>연결>LAN설정>프록시서버'에서 서버 주소와 포트를 설정해주면 설정해준 서버에서 접속한 것처럼 속일 수 있기 때문에 접속 제한을 우회할 수 있다.


HTTP

Q. Http와 Https 통신 방식의 차이에 대해 설명해주세요.

HTTP는 하이퍼 텍스트 전송 프로토콜의(Hypertext Transfer Protocol)의 약자이다. 서로 다른 시스템들 사이에서 통신을 주고받게 해주는 가장 기초적인 프로토콜이다. 웹 서핑을 할 때 서버에서 브라우저로 데이터를 전송해 주는 용도로 가장 많이 사용된다. 그리고 인터넷의 초기에 모든 웹사이트에서 기본적으로 사용되었던 프로토콜이기도 하다.

HTTPS는 하이퍼 텍스트 전송 프로토콜 보안(Hypertext Transfer Protocol Secure)의 약자이다. 일반 HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않아 데이터가 쉽게 도난당할 수 있다는 보안 취약점이 있었다. 이를 SSL(보안 소켓 계층)을 사용하면서 해결한 것이 바로 HTTPS이다. SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을 때 이것이 도난당하는 것을 막아준다.


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

  • 무상태와 비연결성에 대해 설명해주세요.

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미한다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성된다.

클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부른다.

1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜이다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송된다. HTTP의 확장성 덕분에, 오늘날 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트(POST)하기 위해서도 사용된다. HTTP는 또한 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있다.

HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시)에 의해 전송된다. 대부분의 경우, 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있다. 예를 들어, 검색 엔진 인덱스를 채워넣고 유지하기 위해 웹을 돌아다니는 로봇이 그러한 경우이다.

각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 response라고 불리는 응답을 제공한다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하는 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다.

실제로는 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들이 존재한다. 라우터, 모뎀 등이 있다. 웹의 계층적인 설계 덕분에, 이들은 네트워크와 전송 계층 내로 숨겨진다. HTTP은 애플리케이션 계층의 최상위에 있다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없다.


  • 무상태 프로토콜(Stateless)
    서버가 클라이언트의 상태를 보존하지 않아(Stateless) 서버 확장성이 높다는 장점(응답 서버를 쉽게 바꿀 수 있어 무한한 서버가 증설이 가능)이 있으나 클라이언트가 추가 데이터를 전송해야 한다는 단점이 있다.
    로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만 로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야 한다는 한계가 있다.

  • 비연결성(Connectionless)
    TCP/IP의 경우 기본적으로 연결을 유지하는데 요청이 존재하지 않더라도 이 연결을 유지하는 데에 서버의 자원이 계속해서 소모된다. 그러나 비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊어 최소한의 자원으로 서보 유지를 가능하게 한다.
    트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동한다.
    하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드되는데 해당 자원들을 각각 보낼 때마다 연결 끊고 다시 연결하고를 반복하는 것은 비효율적이기 때문에 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다. HTTP 초기에는 각각의 자원을 다운로드하기 위해 연결과 종료를 반복해야 했으나 HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다.

Q. REST API에 대해 설명해주세요.

REST API(RESTful API, 레스트풀 API)란 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻한다. REST는 Representational State Transfer의 줄임말이다.

API 또는 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)는 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트이다. API는 정보 제공자와 정보 사용자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠(호출)와 생산자에게 필요한 콘텐츠(응답)를 구성하는 것이다.


Q. GET 메서드와 POST 메서드의 차이점에 대해 설명해주세요.

  • GET
    • 클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용된다.
    • GET을 통한 요청은 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링 (query string) 이라고 부른다.
    • GET 요청은 캐시가 가능하다.
      : GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환한다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있다.
    • 브라우저 히스토리에 남는다.
    • 북마크 될 수 있다.
    • 표준이 따로 있는 건 아지고 브라우저마다 다르지만 어쨌든 길이 제한이 있다.
    • 보안을 위해서는 중요한 정보를 다뤄서는 안 된다.(파라미터에 다 노출되기 때문)
    • 데이터를 요청할때만 사용 된다.

  • POST
    • 클라이언트에서 서버로 리소스를 생성하거나 업데이트하기 위해 데이터를 보낼 때 사용된다.
    • POST는 전송할 데이터를 HTTP 메시지 body 부분에 담아서 서버로 보낸다. ( body의 타입은 Content-Type 헤더에 따라 결정된다.)
    • GET에서 URL의 파라미터로 보냈던 것이 body에 담겨 보내진다.
    • 데이터를 전송할 때 길이 제한이 따로 없어 용량이 큰 데이터를 보낼 때 사용하거나 GET처럼 데이터가 외부적으로 드러나는건 아니라서 보안이 필요한 부분에 많이 사용된다. (그러나 데이터를 암호화하지 않으면 body의 데이터도 볼 수 있다.)
    • 캐싱되지 않으며 브라우저 히스토리에 남지 않고 북마크도 되지 않는다.

Q. PUT 메서드와 PATCH 메서드의 차이점에 대해 설명해주세요.

둘 다 정보를 수정하는 용도의 메서드이다.

  • PUT : 리소스의 모든 것을 업데이트 한다.
  • PATCH : 리소스의 일부를 업데이트 한다.

가령 한 사용자에 대해 여러 정보를 객체로 수집하여 서버로 보내는 경우, PUT은 보내지지 않은 정보에 대해서는 null값으로 업데이트하지만, PATCH는 기존 데이터를 유지하는 방식으로 대응한다.


Q. Expires, Date, Age, If-Modified-Since의 차이점에 대해 설명해주세요.

캐시 처리 단계 중 음답 생성 단계에서 응답 헤더에 포함되느 정보들이다.

  • Expires: 절대 유효기간이며 이 시기를 지나면 사용할 수 없다.
  • Data: 원서버에서 최초로 생겨난 일시이며 조정해서는 안 된다.
  • Age: 언제까지 유효한지 기간을 정할 수 있다.
  • If-Modified-Since: 날짜 재검사 방식으로 특정 날짜 이후로 수정된 것으로 이 캐시가 새로운 것인지 그대로인지를 감지한다.

Q. If-Modified-Since와 If-None-Match의 차이점에 대해 설명해주세요.

  • If-Modified-Since
    검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알아내는 것이다. Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함한다. 이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다. 서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메시지에 이를 담아서 알려준다. 이때 HTTP Body는 응답 데이터에 없으며 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻이다.
    그러나 Last-Modified와 If-Modified-Since는 1초 미만 단위로는 캐시 조정이 불가능하며 데이터를 수정해서 날짜는 다르지만 같은 데이터를 수정해서 데이터 결과가 똑같은 경우를 구분할 수 없고 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에는 단점을 가지고 있다.

  • If-None-Match
    ETag와 If-None-Match 검증 헤더 방식이다. 이는 캐시용 데이터에 임의의 고유한 버전 이름을 달아두고 데이터가 변경되면 이 이름을 바꾸어서 변경해 단순하게 Etag만 보내서 같으면 유지하고 다르면 다시 받는 방식이다. 이는 캐시 제어 로직을 서버에서 완전히 관리하는 방식이기도 하다.


Q. 브라우저 저장소에 대해서 설명해주세요.

브라우저 저장소로 Cookie와 Web Storage가 있다. Cookie와 Web Storage 모두 해당 도메인과 관련된 데이터를 클라이언트 웹브라우저에 저장할 수 있도록 해준다. 둘 다 사이트의 도메인 단위로 접근이 제한된다. 예를 들면, A 도메인에서 저장한 데이터는 B 도메인에서 접근할 수 없는 것이다.

  • Cookie
    • 매번 서버로 전송
    • 문자열만 저장이 가능
    • 용량에 제한
    • 만료 일자가 존재
  • Web Storage
    • 데이터를 클라이언트에 저장만 할 뿐 서버로 전송하지 않음
    • 문자열 외에도 구조화된 객체를 저장
    • 하나의 사이트에서 저장할 수 있는 용량에 제한 없음
    • 한 번 저장한 데이터는 영구적으로 존재
    • 지속성에 따라 LocalStorage와 SessionStorage로 구분되며 데이터의 지속성에 따라 선택하여 사용한다.
      • LocalStorage: 저장한 데이터를 명시적으로 지우지 않는한 영구적으로 보관이 가능하다. 도메인마다 별도로 LocalStorage가 생성되며, 도메인만 같다면 전역적으로 공유가 가능하다.
      • SessioniStorage: 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다. 도메인마다 별도로 생성되는 점은 LocalStorage와 같지만, 같은 사이트의 도메인이라도 브라우저가 다르면 서로 다른 영역이 된다. 이는 브라우저 컨텍스트가 다르기 때문이다.

Q. HTTP 상태 코드에 대해서 설명하세요.

1xx (정보): 요청을 받았으며 프로세스를 계속한다.
2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다.
3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다.
4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.
5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다.

HTTP 상태 코드 정리

보안/인증

Q. CORS에 대해 설명해주세요.

  • CORS(Cross-Origin Resource Sharing)는 무엇인가 왜 이러한 방법이 정의 되었으며, 본인이 코드를 작성하면서 CORS와 관련하여서 경험하였던 이슈는 무엇인가요? 어떤 옵션을 통해서 해결하셨나요?

추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.

보통 외부 API를 이용할 때 CORS 에러를 겪으며, 이는 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여주기 위한 동일 출처 정책(SOP) 때문에 정의된 것이다. CORS는 이를 해결하는 방법이다(오류가 아님).

이러한 CORS 문제를 해결하기 위해서는 CORS 설정을 통해 서버의 응답 헤더에 ‘Access-Control-Allow-Origin’을 작성하여 문제를 해결했다.


  • Preflight Request에 대해 설명해주세요.
    실제 요청을 보내기 전, OPTIONS 메소드로 사전 요청을 보내 해당 출처 리소스에 접근 권한이 있는지부터 확인하는 것이다. 프리플라이트 요청은 실제 요청을 보내기 전 미리 권한을 확인할 수 있기에 실제 요청을 처음부터 모두 보내지 않아 리소스 측면에서 효율적이다. 또한 CORS에 대비가 되어있지 않은 서버를 보호할 수도 있다.

  • same-origin 정책에 대해 설명해주세요.
    어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식이다. 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여준다.

  • 로컬과 실제 환경 배포할 때의 CORS 세팅에 있어서 주의해야 할 점에 대해 설명해주세요.

백엔드에는 배포 URL을 기준으로 Access-Control-Allow-Origin 헤더가 세팅하는 것이 가장 좋은 방법이다.

다만 로컬에서 개발 할 때는 localhost:3000 과 같은 범용적인 URL를 사용하게 되기 때문에 CORS 정책 위반 문제가 발생하기 쉽다. 이럴 때에는 프론트쪽에서 라이브러리에서 제공하는 프록시 기능을 사용해서 CORS 정책을 우회하도록 한다.

  • package.json에 직접 세팅
//package.json
{
  ...,
  "proxy": "http://localhost:8000",
  ...,
}
  • http-proxy-middleware 설치

Q. SSL 인증서 암호화 기법인 대칭키 암호화 기법, 공개키 암호화 기법에 대해 설명해주세요.

  • SSL 인증서
    디지털 인증서라고도 하는 SSL(보안 소켓 계층) 인증서는 브라우저 또는 사용자의 컴퓨터와 서버 또는 웹사이트 간에 암호화된 연결을 수립하는 데 사용된다. SSL 연결은 인증되지 않은 사용자의 방해로부터 각 방문(세션) 중에 교환된 중요한 데이터를 보호한다.

  • 대칭키 암호화 기법
    • 암복호화에 사용하는 키가 동일하다.
    • 암호화방식에 속도가 빨라 대용량 데이터의 암호화에 적합하다.
    • 키를 교환해야 하는 문제가 있고 이 과정에서 키가 탈취될 수 있다. 또한 이용자가 많아질수록 키 관리가 어려워져 확장성이 떨어진다.
    • 대표적 알고리즘: DES, 3DES, AES, SEED, ARIA
  • 공개키 암호화 기법
    • 암복호화에 사용하는 키가 서로 다르며 비대칭키 암호화라고 한다.
    • 암호화방식에 속도가 느리다.
    • 키를 교환하거나 분배할 필요가 없으며 따라서 기밀성과 보안성이 강화되었다.
    • 대표적 알고리즘: Diffie Hellman, RSA, DSA, ECC

1) B 공개키/개인키 쌍 생성
2) 공개키 공개(등록), 개인키는 본인이 소유
3) A가 B의 공개키를 받아옴
4) A가 B의 공개키를 사용해 데이터를 암호화
5) 암호화된 데이터를 B에게 전송
6) B는 암호화된 데이터를 B의 개인키로 복호화 (개인키는 B만 가지고 있기 때문에 B만 볼 수 있음)


Q. OAuth에 대해서 간단히 설명해주세요.

OAuth2.0은 인증을 위한 표준 프로토콜의 한 종류
보안 된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜 중 한 방법이다.

유저 입장에서는 회원가입 절차를 자주 사용하고 중요한 서비스들(예를 들어 google, github, facebook) 의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 하여 간소화 할 수 있다는 장점이 있다.

또한 보안상의 이점도 존재한다.검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 되기 때문에 더 안전하게 사용할 수 있다.

OAuth 개념 및 동작 방식 이해하기


  • Token
    • 인증에 필요한 정보들을 암호화시킨 토큰
    • 사용자는 Access Token을 HTTP 헤더에 실어 서버에 전송
    • 임의로 생성된 비밀번호 같이 동작한다. 제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 Refresh Token으로 새로 생성되어야 한다.
    • 세션/쿠키는 세션 저장소에 유저 정보를 넣는 반면, 토큰 안에 유저의 정보들이 넣어진다는 점이다. 클라이언트 입장에서는 HTTP 헤더에 세션 ID나 토큰을 실어서 보내준다는 점에선 동일하지만, 서버 측에서는 인증을 위해 암호화를 한다 vs 별도의 저장소를 이용한다 의 차이가 발생한다.
    • 별도의 저장소 관리가 필요없어 간편하다.
    • 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능해 확장성이 뛰어나다.
    • 이미 발급된 토큰에 대해서는 유효기간이 완료될 때까지는 계속 사용이 가능해 악의적으로 이용될 가능성도 있다.
    • Payload는 따로 암호화되지 않아 디코딩으로 누구나 정보를 알아낼 수 있기 때문에 유저의 중요한 정보들은 넣을 수 없다.
    • 길이가 길어 인증에 필요한 요청이 많아질수록 서버의 자원낭비가 발생한다.
profile
H Kim
이전 포스트

모의면접 3주차 - CSS / JavaScript 심화

다음 포스트

[면접] V사 1차 면접

0개의 댓글