BlogJob

프론트엔드 면접 질문 리스트 - Network

Network 인터뷰 질문 리스트

, , ,

면접!

프론트엔드 면접 준비를 위한 질문 리스트 정리

Network

아래질문 리스트를 기반으로 면접 질문 & 답변 목록을 작성할 예정이고, 지속적으로 보충 or 보수할 계획입니다.

업데이트 날짜

  • 2020-10-26
  • 2021-07-20
    • network 질문 목록 수정

질문 목록

  1. HTTP와 HTTPS의 정의와 차이점은 무엇인가
  2. HTTP 메서드는 무엇이 있으며 어떤 요청이 있을때 사용하나
  3. GET, POST 방식의 차이점은 무엇인가
  4. POST과 PUT의 차이점은 무엇인가
  5. PUT과 PATCH의 차이
  6. TCP와 UDP는 무엇이며 차이점은 무엇인가
  7. TCP 3-WAY-HANDSHAKE
  8. DNS ROUND ROBIN 방식인이란
  9. Http 1.1과 2.0는 무엇이며 의 차이는 무엇인가
  10. 프록시의 정의와 기능은 무엇인가
  11. HTTP 통신에서 사용자의 상태를 파악할 수 있는 방법은 무엇이 있는가 - Cookie, Session, Auth with Token

1. HTTP와 HTTPS의 정의와 차이점은 무엇인가

HTTP 정의

HTTP란 Hyper Text Transper Protocol의 약자로, 서버와 클라이언트가 서로 정보를 주고받을 수 있는 프로토콜입니다. TCP/IP 위에서 동작하며 well-known 포트인 80번 포트를 사용하여 통신합니다. HTTP 통신의 특징은 비연결성(Connectionless), 무상태성(Stateless) 프로토콜이라는 점입니다.

  1. 비연결성 (Connectionless)

    비연결이란 클라이언트가 서버에게 리소스를 요청한 후 응답을 받으면 연결을 끊는다는 의미로 지속적으로 연결을 유지할시 서버의 부담이 가중될 수 있으나 리소스를 요청할 때마다 연결해야 하는 오버헤드(Overhead) 비용이 발생합니다. 이를 위해 Connection: keep-alive 속성으로 지속적 연결 상태(Persistent connection)를 유지할 수 있으며 기존의 연결을 재사용할 수 있습니다.

  2. 무상태성 (Stateless)
    무상태성이란 서버가 클라이언트의 요청을 각각 독립적으로 여겨 클라이언트의 요청을 식별할 수 없다는 뜻입니다. 이를 위해서 쿠키, 세션 또는 토큰 방식의 OAuth 및 JWT를 사용해 각 클라이언트가 어떤 상태이며 어디서 왔는지 식별 가능한 상태를 보충할 수 있습니다.

HTTPS 정의

HTTPS란 (HyperText Transfer Protocol over TLS/SSL)의 약자로, 기존의 HTTP를 SSL 또는 TLS로 암호화한 프로토콜입니다. TCP의 연결이 이루어진 후 TLS를 통해 암호화 설정이 되고 통신을 하는 방식으로, 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 대칭키 / 공개키 암호화를 지원하고 있다. 암호화 전송에 필요한 개념으로는 암화화, 복호화, 키 등이 있으며 암호화에는 공개키 / 개인키, 대칭키 / 비대칭키 암호화 및 인증기관이 있습니다.

암호화 전송에 필요한 개념

  1. 암호화: 어떤 정보를 암호화된 정보로 바꾸는 것
  2. 복호화: 암호화된 정보를 다시 원래 정보로 바꾸는 것
  3. 키: 암호화, 복호화할 때 쓰는 비밀번호
  4. HTTPS는 공통 키 방식과 비대칭 키 방식을 같이 사용합니다

암호화에 사용되는 키

  1. 공개키 / 개인키 암호화

    • 공개키: 모두가 볼 수 있는 키
    • 개인키: 소유자만이 가지고 있는 키로 암/복호화에 사용됨
    • 공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. => 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
    • 개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다. => 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

  2. 대칭키 / 비대칭키 암호화

    • 대칭키: 서버와 클라이언트가 암호화/복호화에 동일한 비밀키를 사용하는 방식, 키를 공유하는데 어려움이 있으나 속도가 빠르다.
    • 비대칭키: 서버와 클라이언트가 암호화/복호화에 각각 다른 비밀키를 사용하는 방식, 공개키를 통해서 암호화를 하고 비밀키를 통해서 복호화를 한다. 공개키는 공개해도 상관없으니 키 관리에 어려움이 없으나, 속도가 느리다.

  3. 인증기관

    • 클라이언트가 접속을 요청한 서버가 의도한 서버가 맞는지 인증해주는 역할을 하는 보증된 기업들이다. 클라이언트는 서버에 요청을 해서 CA가 발급한 인증서를 받은 뒤 CA의 공개키로 복호화하여 신뢰할 만한 인증서인지 검증한다. CA의 공개키로 복호화되는 암호화는 오직 CA의 비밀키로 암호화한 경우밖에 없기 때문에 복호화되면 신뢰할 만한 것이다.

동작방식

HTTPS는 대칭키 암호화를 사용 하며 다음과 같은 과정을 거친다.

  1. 클라이언트가 서버에게 접속요청을 하면 서버는 CA에서 발급받은 인증서를 보낸다. 인증서에는 CA의 비밀키로 암호화된 사이트정보와 공개키가 들어있다.
  2. 클라이언트는 인증서를 받아 CA의 공개키로 복호화하여 접속요청한 서버가 신뢰할만한지 검증한다.
  3. 복호화가 되면 인증서가 신뢰할 만하기 때문에 데이터를 주고받을 대칭키를 생성한다.
  4. 대칭키를 서버의 공개키로 암호화하여 서버에게 전송한다.
  5. 서버는 자신의 비밀키로 클라이언트가 보낸 대칭키를 복호화한 뒤 그 대칭키를 통해 데이터를 주고받는다.

HTTP와 HTTPS 차이

  1. HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다.
  2. HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리다. (오늘날에는 거의 차이를 못느낄 정도이다.)
  3. HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생하다.

그렇다면 언제 HTTP를 쓰고, 언제 HTTPS를 쓰는 것이 좋겠는가? 개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 단순한 정보 조회 등만을 처리하고 있다면 HTTP를 이용하면 된다.

2. HTTP 메서드는 무엇이 있으며 어떤 요청이 있을때 사용하나

HTTP 메서드는 클라이언트가 서버에 요청하는 방법을 정의한 것으로 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. HTTP 메서드에는 GET, POST, PUT, DELETE, PATCH 등이 있습니다.

  1. GET: 서버에게 리소스 조회를 요청한다. (READ, 조회)
  2. POST: HTTP 본문(body)에 생성할 데이터를 삽입하여 서버에게 전송한다. (CREATE, 생성)
  3. PUT: HTTP 본문(body)에 서버에게 수정할 데이터를 삽입하여 전송한다. (UPDATE, 수정)
  4. DELETE: 서버에게 리소스 삭제를 요청한다. (DELETE, 삭제)
  5. PATCH: PUT과 비슷하지만 일부만 수정한다는 점에서 다르다.
  6. OPTIONS: 웹서버에서 지원되는 메소드의 종류를 확인할때 사용합니다.

3. GET, POST 방식의 차이점은 무엇인가

GET

  • GET 은 서버로부터 정보를 조회하기 위해 설계된 메소드입니다. GET은 요청을 전송할 때 필요한 데이터를 Body에 담지 않고, 쿼리스트링을 통해 전송 합니다.

    • 쿼리스트링 이란?

      URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터를 쿼리스트링이라고 부릅니다. 만약, 요청 파라미터가 여러 개이면 &로 연결합니다.

  • GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있습니다.

    • js, css, 이미지 같은 정적 컨텐츠는 데이터양이 크고, 변경될 일이 적어서 반복해서 동일한 요청을 보낼 필요가 없습니다. 정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시해두고, 동일한 요청이 발생할 때 서버로 요청을 보내지 않고 캐시된 데이터를 사용합니다. 그래서 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시돼 컨텐츠를 변경해도 내용이 바뀌지 않는 경우가 종종 발생합니다. 이 때는 브라우저의 캐시를 지워주면 다시 컨텐츠를 조회하기 위해 서버로 요청을 보내게 됩니다.

  • 데이터가 Header의 URI에 담겨서 전송되므로 데이터 크기가 제한적이며 데이터가 사용자에게 그대로 노출되어 보안이 필요한 경우 적절하지 않다. GET 요청은 캐싱이 가능하므로 데이터가 사용자에게 노출되어도 상관없다면 적극적으로 활용하는게 좋다.

  • 요약

    • 데이터를 전달할 때 URL에 데이터를 포함시켜 요청
    • 데이터를 Header에 포함시켜 전송
    • URL에 데이터가 노출되어 보안에 취약
    • 전송하는 길이에 제한이 있음

POST

  • POST 는 리소스를 생성/변경하기 위해 설계되었기 때문에 GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송합니다. HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송 할 수 있습니다.
    • 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송 할 수 있습니다. 이처럼 POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전 하다고 생각할 수 있지만, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송 해야 합니다.
  • 데이터의 크기가 GET 방식보다 현저하게 크며 데이터가 일반 사용자에게 노출되지 않으므로 안정적으로 데이터를 전송할 수 있다. POST는 대부분 데이터의 변경을 위해서 사용한다.
  • 요약
    • URL에 데이터를 노출하지 않고 요청
    • 데이터를 Body에 포함시겨 전송
    • URL에 데이터가 노출되지 않아 기본보안은 되어있음
    • 전송하는 길이에 제한이 없음

4. POST와 PUT의 차이점은 무엇인가

주요 차이점은 다음과 같습니다.

구분 POST PUT
개념 HTTP body에 생성할 데이터를 삽입하여 서버에게 전송합니다.
CREATE 또는 INSERT의 개념. 생성		 HTTP body에 수정할 데이터를 삽입하여 서버에게 전송한다.
UPDATE 의 개념. 수정
멱등화 멱등화 하지 않음
즉, 동일한 리소스 주소로 다수의 요청을 전송하는 경우, 매번 새로운 리소스가 생성되기 때문에 멱등하지 않는다.		 멱등화 함
즉, 동일한 리소스 주소로 다수의 요청을 전송하는 경우, 새로운 리소스가 생성되는 것이 아니라 요청에 명시된 동일한 리소스를 수정하기 때문에 여러번 요청해도 멱등하다.

5. PUT과 PATCH의 차이

주요 차이점은 다음과 같습니다.

구분 PUT PATCH
개념 해당 자원의 전체를 교체한다. 해당 자원의 일부를 수정한다.
멱등화 멱등화 함
즉, 자원 전체를 변경하기 때문에 동일 자원에 대해서 동일하게 PUT을 처리하는 경우, 멱등하게 처리된다.		 멱등화 하지 않음
즉, 자원의 일부를 변경하기 때문에 멱등성을 보장할 수 없다.

멱등(idempotent)함 이란 같은 작업을 계속 반복해도 같은 결과가 나오는 경우 를 의미한다. 동일한 자원에 대한 GET 요청이라면 클라이언트에 반환되는 모든 응답은 동일해야 한다. 특정 자원에 대한 DELETE 의 경우도 자원은 더이상 이용할 수 없어야 하며, DELETE 요청을 재전송 할지라도 자원은 여전히 사용할 수 없는 상태여야 한다.

6. TCP와 UDP는 무엇이며 차이점은 무엇인가

TCP

신뢰성과 순차적인 전달이 필요한 경우 사용한다. TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어진다. TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

  • 특징

    • 연결형 서비스
    • 가상회선 방식으로 패킷을 교환한다.
    • 전송 순서를 보장
    • 수신여부를 확인한다.
    • 1대1 통신이다.
    • 신뢰성이 높다
    • 속도는 상대적으로 UDP에 비해 느리다.
    • 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
    • 흐름제어 및 혼잡제어를 제공.

  • Q) 흐름제어(Flow Control)와 혼잡제어(Congestion Control)이란?

    흐름제어 는 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것입니다. 예를 들어 송신하는 곳에서 감당이 안되는 수준으로 데이터를 빠르게 많이 보내면 수신자에서 문제가 발생하기 때문입니다. 혼잡제어 는 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것입니다. 만약 정보의 소통량이 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막습니다.

UDP

비연결형 프로토콜이며 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. UDP를 사용하는 것에는 DNS가 있다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.

  • 특징
    • 비연결형 서비스이다.
    • 데이터그램 방식으로 패킷 교환
    • 전송 순서가 바뀔 수 있다.
    • 수신 여부를 확인하지 않는다.
    • 1대1 or 1대N or N대N 통신이다.
    • 신뢰성이 낮다.
    • 속도가 상대적으로 TCP에 비해 빠르다

7. TCP 3-WAY-HANDSHAKE

  • Client는 Server에 접속 요청 메세지(SYN)을 전송하고 SYN_SEND 상태가 된다.
  • Server는 SYN 요청을 받고 Client에 요청을 수락(SYN+ACK)하고 SYN_RECEIVED 상태가 된다.
  • Client는 Server에게 수락 확인(ACK)를 보내고 Server는 ESTABLISHED 상태가 된다.

8. DNS ROUND ROBIN 방식

DNS를 이용해서 하나의 서비스에 여러 대의 서버를 분산 시키는 방법이다. 동일한 이름으로 여러 레코드를 등록 시키면 질의 할 때마다 다른 결과를 반환하며, 이 동작을 이용함으로써 여러 대의 서버에 처리를 분산 시킬 수 가 있다. 단점은 아래와 같다.

  • 서버의 수 만큼 공인 IP 주소가 필요하다.
  • DNS 질의 결과 캐싱으로 인해 균등하게 분산되지 않는다.
  • 서버가 다운되어도 확인이 어렵다.

9. Http 1.1과 2.0의 차이는

http 1.1

http 2.0

  • 기존 HTTP/1.x 버전의 성능향상에 초점을 맞춘 프로토콜
  • HTTP 메시지 전송 방식의변화
    • 바이너리 프레이밍 계층 사용
      • 파싱, 전송속도 증가, 오류발생 가능성 감소
  • 스트림을통한 양방향 전송을 통해 요청과 응답 멀티플렉싱이 가능
    • Head of Line Blocking 해결
  • Stream Prioritization
    • 리소스간 우선 순위를 설정 가능.
  • 서버 푸시 가능.
  • Header 압축. 헤더의 크기를 줄여 페이지 로드시간 감소.

http 1.1와 http 2.0의 차이

10. 프록시 서버의 기능

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

HTTP 통신으로 사용자의 인증 상태 또는 사용자 식별을 할 수 있는 방법으로는 Cookie, Session, Token 기반의 인증방법이 있습니다. 이 방법들은 HTTP 프로토콜의 특성인 비상태성(Stateless)을 보완하기 위해 개발된 방법들로 전통적 방법으로는 그리고 전통적 방법으로는 Cookie, Session 기반의 사용자 인증 방법이 있으며 Cookie, Session의 단점과 한계를 보완해 사용자 인증 상태 및 식별자를 보다 안전하고 효율적으로 관리하는 방법이 Token 기반의 인증방법 입니다.

Cookie와 Session

Cookie와 Session은 HTTP의 특성인 Stateless를 보완하기 위해 등장한 개념으로, 사용자가 특정 페이지를 이동하거나 로그인 상태를 기억해야할때 HTTP 통신의 header에 담아 전송하기 위한 목적을 가지고 있습니다.

Cookie 란 웹 서버가 브라우저에게 지시해 웹 브라우저에 저장되는 데이터로써 서버가 클라이언트의 요청을 식별하는데 사용되고, Session이란 브라우저가 서버에 연결되어 있는 동안 서버측에 저장되고 유지되는 데이터의 집합으로, 사용자가 웹 사이트에 방문해 서버에 요청을 보내게 되면, 사용자의 정보를 서버에 저장하고 그 정보의 식별자를 Set-Cookie 헤더에 담아 클라이언트에게 전송합니다.

이 둘의 차이점은 Cookie의 경우 서버에서 전송된 민감한 정보를 포함한 모든 사용자의 정보를 브라우저의 쿠키에 저장해야하지만, Session의 경우 사용자 정보에 대한 식별자만을 전달해 인증하면 되기 때문에 서버에 접근하는 트래픽양이 증가해도 Cookie와 비교했을때 상대적으로 적은 부하를 일으킬 수 있으나 이 또한 서버의 메모리를 차지하고 있는 리소스이기 때문에 부하가 늘어나면 서버에서 사용자의 정보를 조회하는 과부하가 늘어날 수 있다는 단점이 있습니다.

또한, Cookie의 경우 브라우저에 사용자의 정보가 기록되기 때문에 위변조의 가능성이 높아 보안에 취약하며, 세션 또한 세션키가 중간에 탈취 당할 수 있기 때문에 보안에 완벽하다고 할 수 없습니다.

Token

Token 기반의 사용자 인증 방식은 Cookie와 Session의 문제점을 보완하기 위해 도입됐으며 핵심은 암호화 알고리즘을 통해 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 방식입니다. Token은 서버에서 정한 암호화 알고리즘과 치환하기 위한 여러 값들을 기반으로 사용자 정보를 의미를 알 수 없는 문자열 형태로 치환하기 때문에 중간에 탈취 당했다 하더라고 암호화 되어있어 공격자가 치환되기 전의 데이터를 알아내는 것은 매우 어렵습니다. Token 기반의 대표적인 인증 방식으로는 JWT가 있습니다.

JWT

JWT란 JSON Web Token의 약자로, 사용자가 로그인 요청을 전송하면 서버는 JSON 기반의 사용자의 정보를 생성하며 이를 기반으로 암호화된 토큰을 발행합니다. 따라서, JWT는 토큰 자체가 의미를 갖는 Claim 기반의 토큰 방식이며 여기서 Claim이란 권한으로 사용자에 대한 프로퍼티 또는 속성을 의미합니다. 또한, 발행된 토큰은 사용자의 정보를 서버측 또는 브라우저에 저장하는 것이 아닌 자체가 의미를 갖는 토큰이므로 보안성 강화를 위해 토큰의 유효시간을 설정해 탈취되었다 하더라도 이미 무의미한 토큰이 되도록 합니다.

JWT의 가장 큰 특징은 다음과 같습니다.

  • JWT 자체가 암호화된 JSON 기반의 문자열 데이터
  • 토큰 자체가 Claim(권한) 기반이라는 점
  • 토큰을 HTTP 헤더에 추가해 통신하기 때문에 따로 보관하지 않으며 서버에 부하가 발생시키지 않음
  • 토큰 탈취로 인한 보안성 강화를 토큰에 대한 유효시간을 설정해 일정주기로 갱신

JWT의 구조는 Header, Payload, Signature (서명)으로 구성되어 있으며

  • Header: 토큰의 타입과 해싱 알고리즘을 명시. JWT를 어떻게 검증하는가(Verify) 하는가에 대한 내용을 담고 있음
  • Payload: 토큰에 대한 내용으로써 Claim Set이라고 부르며 JWT에 대한 토큰 생성자의 정보, 생성 일시와 같은 JWT에 대한 내용을 담고 있음
  • Signature (서명): Header의 인코딩 값과 Payload의 인코딩 값을 `. (dot) 을 구분자로 해서 연결 및 병합한 후 문자열을 서명한 값

참조

Share