네트워크 면접질문 정리

https://github.com/VSFe/Tech-Interview/blob/main/03-NETWORK.md 의 면접질문들에 대한 답을 나름대로 정리한 포스팅

쿠키와 세션

• 쿠키

  • 웹 사이트 접속 시 사용자의 식별을 위해 사용한다.

  • 만료시간이 지나면 자동으로 삭제된다.

• 세션

  • 사용자 데이터를 서버 내의 메모리에 객체로서 저장하는 것

세션 방식의 로그인 과정에 대해 설명해 주세요.

• 클라이언트가 아이디, 비밀번호를 입력하여 로그인을 성공하면,

• 서버는 해당 유저 정보를 담은 세션 객체를 서버내의 메모리에 생성하고 이를 찾기위한 세션 아이디를 만들어 쿠키에 담아 클라이언트에게 보낸다.

• 클라이언트가 서버에 작업을 요청할 때, 세션 아이디가 담긴 쿠키를 같이 보낸다.

• 서버는 쿠키에 담긴 세션 아이디에 대응되는 세션 객체가 있는지 검사하고, 만약 세션 객체가 있다면 클라이언트의 요청에 대한 응답을 제공한다.

HTTP의 특성인 Stateless에 대해 설명해 주세요.

• HTTP 서버는 HTTP 클라이언트에 대한 정보를 유지하지 않는다.

Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

• HTTP 가 stateless 한 특성이 있는 것이고, 내가 제공하는 웹 서비스가 클라이언트의 상태 정보를 유지하고 싶다면 세션을 사용하면 되는 것이다.

• 세션을 이용한 인증 방법은 클라이언트의 상태 정보를 서버가 관리하기에 클라이언트의 추적, 관찰, 관리가 쉽다는 장점이 있고, 반면 세션을 저장하기 위한 서버 메모리가 필요하다는 단점이 있다.

규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

• sticky session

  • 특정 유저가 특정 서버에서 세션을 생성하였다면, 그 유저의 이후 모든 요청은 특정 서버로만 보내지게 된다.

  • load balancer 가 세션을 생성한 서버로 모든 요청을 리다이렉트한다.

  • 특정 서버에 트래픽이 집중될 위험이 있다.

  • 특정 서버에 장애가 발생하면, 해당 서버를 사용하는 사용자들은 세션 정보를 잃어버리게 된다. (가용성 ↓)

• session clustering

  • 특정 서버의 세션 저장소에 세션이 생성, 삭제, 변경되면 변경사항이 다른 모든 서버의 세션 저장소에 복제가 된다.

  • sticky session 대비 가용성이 좋다

  • 특정 서버에 트래픽이 집중될 위험이 없다.

  • 모든 서버가 동일한 세션 객체를 가져야 하기 때문에 많은 메모리가 필요하다.

  • 대규모의 서버가 클러스터링된 경우, 끝없는 변경사항들로 인해 네트워크 트래픽이 증가한다.

    • 소규모 클러스터에서 좋다.

• 세션 저장소 분리

  • 기존 서버의 메모리를 세션 저장소로 사용하지 않고, 모든 서버들이 공유하는 별도의 세션 저장소를 사용한다.

  • 특정 서버가 고장나도, 세션을 잃어 버리지 않는다.

    • 그러나 세션 저장소가 고장나면 모든 서버들의 세션을 잃어버릴 수 있다.

HTTP 응답 코드

• HTTP 응답 코드는 특정 HTTP 요청이 성공적으로 완료되었는지, 혹은 에러가 발생했는지를 알려준다.

• 1xx

  • 정보성 상태 코드

• 2xx

  • 성공 상태 코드

• 3xx

  • 리다이렉션 상태 코드

• 4xx

  • 클라이언트 에러 상태 코드

• 5xx

  • 서버 에러 상태 코드

401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?

• 401 (Unauthorized)

  • 클라이언트가 인증되지 않아 요청을 처리할 수 없음을 알려주는 상태코드

• 403 (Forbidden)

  • 클라이언트의 인증은 되었지만, 해당 클라이언트가 요청을 처리할 수 있는 권한이 없음을 알려주는 상태코드

200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.

• 200 (ok)

  • HTTP 요청을 성공적으로 처리하였을때의 상태코드

  • 일반적으로 GET 요청에 대한 데이터를 응답에 성공적으로 담았을 때 200 상태코드를 사용한다.

• 201 (Created)

  • HTTP 요청을 성공적으로 처리하여, 서버에 새로운 리소스가 생성되었을때의 상태코드

  • HTTP 응답에 응답 헤더 Location이 추가된다.

    • 새로 만들어진 리소스에 접근하기 위한 URL을 값으로 가진다.

  • 일반적으로 POST 요청에 의해 서버에 새로운 리소스가 생성되었을 때 201 상태코드를 사용한다.

필요하다면 저희가 직접 응답코드를 정의해서 사용할 수 있을까요? 예를 들어 285번 처럼요.

• 프로젝트를 함께하는 팀원들의 합의와 필요에 의해 커스텀 응답 코드를 사용할 수 있다.

  • 다만 헷갈리지 않게 문서화를 잘 해놓는 것이 중요하다.

HTTP Method

• 클라이언트가 서버에게 특정 리소스에 수행하길 원하는 행동을 나타낸다.

• 안전, 캐시가능, 멱등성의 3가지 속성을 가진다.

  • 안전 - 호출해도 리소스가 변경되지 않는다.

  • 멱등 - 한 번 호출하나 여러번 호출하나 결과가 똑같다.

  • 캐시가능 - 응답 결과 리소스를 캐싱할 수 있다.

• 대표적으로 GET, POST, PUT, PATCH, DELETE 가 있다.

HTTP Method의 멱등성에 대해 설명해 주세요.

• 한 번 호출하는 것과, 여러번 호출하는 것의 결과가 같은 경우 해당 메서드는 멱등성을 만족한다.

GET과 POST의 차이는 무엇인가요?

• GET

  • 주로 리소스 조회에 사용한다.

  • 서버에 전달하고 싶은 데이터는 쿼리 파라미터를 사용해 전달한다.

  • 안전, 멱등, 캐시가능을 모두 만족한다.

• POST

  • 주로 서버에 데이터를 전달하여 신규 리소스를 등록할 때 사용한다.

  • 서버에 전달하고 싶은 데이터는 message body 를 통해 전달한다.

  • 스펙상 캐시가능을 만족하나, 일반적으로 구현되진 않는다.

POST와 PUT, PATCH의 차이는 무엇인가요?

• POST

  • 서버에 신규 리소스를 등록할 때 사용한다.

  • 캐시 가능을 만족한다.

  • 클라이언트는 만들어진 신규 리소스를 알고 있지 않아도 된다.

• PUT

  • 서버에 있는 리소스를 통째로 대체한다.

  • 리소스가 없는 경우엔 리소스를 생성한다.

  • 클라이언트는 대체하려는 리소스를 알고 있어야 한다.

  • 멱등을 만족한다.

• PATCH

  • 서버에 있는 리소스 중 일부만을 대체한다.

  • 스펙상 캐시가능을 만족하나, 일반적으로 구현되진 않는다.

  • PATCH 가 특정 필드값을 추가하는 방식으로 사용될 수 있기에 멱등은 만족하지 않는다.

HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?

• HTTP 1.0 을 사용하는 서버는 GET 요청에 실린 Body 를 읽지않고 버릴 위험이 있다.

• GET은 캐시 가능해야 하는데, Body를 싣는 경우 캐시 불가능해진다.

  • 일반적으로 Body 가 달라도 요청 URL 이 같으면 동일한 요청이라 생각하여 동일한 캐싱된 응답을 반환하게된다.

  • 이는 올바른 동작이 아니므로 캐시가 불가능해진다.

HTTP

• HyperText Transfer Protocol

• HTML 과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜이다.

• HTTP 클라이언트는 서버에게 웹 페이지를 이루는 객체들을 요청하고, HTTP 서버는 객체들을 제공한다.

• HTTP 서버는 클라이언트에 대한 정보를 유지하지 않는 stateless protocol 이다.

공개키와 대칭키에 대해 설명해 주세요.

• 데이터를 암호화 알고리즘을 이용하여 남들이 해석할 수 없도록 암호화 하는 방식에는 크게 2가지가 있다.

  • 암호화 키를 사용하여 데이터를 암호화한다.

  • 대칭키 방식과 비대칭키 (공개키) 방식이 있다.

• 대칭키 방식

  • 암호화 키와 복호화 키가 같은 방식

  • 따라서 데이터를 전달받는 복호화 하는 쪽은 비밀리에 키를 전달받아야 한다.

  • 키를 전달받는 도중 탈취될 위험성이 있다.

• 공개키 방식

  • 암호화 키와 복호화 키가 달라 비대칭 키 방식으로도 불린다.

  • 공개키 방식에선 공개키와 개인키가 하나의 묶음으로 사용된다.

  • 공개키는 모두에게 공개되는 키이고, 개인키는 자신만 가지고 있는 키이다.

  • 만약 공개키로 암호화를 했다면 개인키로만 복호화할 수 있고,

    • 공개키 암호화

  • 개인키로 암호화했다면 공개키로만 복호화할 수 있다.

    • 전자 서명

  • 키의 크기가 크기 때문에 대칭키 대비 연산시간이 오래걸린다.

왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

• 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 신뢰할 수 있는 기관에서 보증한다.

• 이로써 공격자가 사이트의 가짜 버전을 만드는 것을 방지할 수 있다.

• 또한 인증기관의 개인키로 암호화되었기 때문에, 인증기관의 공개키로 해독이 되지 않는다면 중간에 위변조되었음을 알 수 있다.

SSL과 TLS의 차이는 무엇인가요?

• 둘 모두 두 디바이스간의 보안 연결을 수립하는 통신 프로토콜이다.

• SSL (Secure Sockets Layer) 이 먼저 나와 사용되었고, 현재는 SSL 의 결함들을 보완한 TLS (Transport Layer Security) 를 사용한다.

• 현재 표준은 TLS이지만 SSL, TLS 를 혼용해서 부른다.

소켓 vs 웹 소켓

• 두 프로세스간의 통신은 소켓에 메시지를 보냄으로써 이루어진다.

  • 즉, 소켓은 네트워크 상에서 연결된 두 프로세스간의 통신 링크의 엔드포인트이다.

• 소켓은 트랜스포트 계층과 애플리케이션 계층 사이에서 동작한다.

• 반면 웹 소켓은 애플리케이션 계층 프로토콜 중 하나인 HTTP 위에서 동작한다.

  • 즉, 웹 소켓은 애플리케이션내에서 동작한다.

  • HTTP 클라이언트와 HTTP 서버는 양방향의 실시간 통신을 할 수 있다.

소켓과 포트의 차이가 무엇인가요?

• 포트는 디바이스 내의 프로세스를 식별하는 숫자이다.

• 소켓은 포트 번호와 호스트 IP 주소로 조합되는 통신 링크의 엔드포인트이다. (UDP 기준)

• 서로다른 디바이스들은 같은 포트번호를 가질 수 있다.

• 그러다 서로다른 디바이스들이 같은 소켓을 가질 순 없다.

여러 소켓이 있다고 할 때, 그 소켓의 포트 번호는 모두 다른가요?

• 그렇지 않다.

• TCP 방식에서 서버는 TCP 3-way handshaking 을 위한 환영 소켓이 있고, TCP 3-way handshaking 을 마치면 해당 클라이언트에만 연결되는 연결 소켓을 따로 만든다.

• 이때 환영 소켓과 새로 생성되는 연결 소켓은 포트 번호 80으로 같다.

• 따라서 TCP 방식에선 (호스트 IP 주소, 포트 번호) 튜플로 소켓을 식별할 수 없으므로 (출발지 IP 주소, 출발지 포트번호, 목적지 IP 주소, 목적지 포트번호) 의 4가지 정보를 모두 사용하여 소켓을 식별한다.

HTTP/1.1과 HTTP/2의 차이점은 무엇인가요?

• HTTP/1.1 은 지속 연결을 사용한다.

  • 만약 하나의 지속적인 TCP 연결을 사용하는 경우, HOL (Head of Line) 블로킹 문제가 발생할 수 있다.

    • 비디오와 같은 크기가 큰 객체 때문에, 덩치 큰 객체의 뒤에 있는 많은 수의 작은 객체들이 기다리게 되는 것

  • HTTP/1.1 은 HOL 블로킹 문제를 해결하기 위해 여러개의 병렬 TCP 연결을 열었다.

    • 이를 통해 크기가 작은 객체들이 덩치가 큰 객체뒤에서 기다리지 않고 빠르게 전달되었다.

    • 그러나 여러개의 병렬 TCP 연결은 인터넷상의 불공정성을 야기한다.

    • TCP 혼잡 제어는 모든 개별적인 TCP 연결이 대역폭을 공평하게 갖도록 나눠주는데 하나의 클라이언트가 여러개의 TCP 연결을 사용하면 더이상 공평하지 않다.

• HTTP/2 의 주요 목표는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결을 제거하는 것이다.

  • 이를 통해 목표한대로 TCP 혼잡 제어를 할 수 있다.

  • 오직 하나의 TCP 연결만을 사용하면서도 HOL 블로킹을 피하기 위해서

    • 각 객체를 작은 프레임으로 나누고

    • 하나의 TCP 연결을 통해 객체들을 이루는 작은 프레임을 객체별로 한 개씩 보낸다.

    • 예를 들어 비디오 객체가 1000프레임, 작은 객체가 2프레임으로 이루어져 있다하면

    • 기존 HTTP/1.1 방식에서 작은 객체는 1002 프레임이 보내져야 전송이 완료되지만

    • HTTP/2 방식에서 작은 객체는 4프레임이 보내지면 전송이 완료된다.

  • 따라서 HTTP/2 핵심 기능은 HTTP 메시지를 독립된 프레임들로 쪼개 골고루 보내고, 받는 쪽에선 프레임들을 재조립하는 기능이다.

HOL Blocking 에 대해 설명해 주세요.

• Head of Line 블로킹

• 비디오와 같은 크기가 큰 객체때문에, 덩치 큰 객체의 뒤에 있는 많은 수의 작은 객체들이 전송되지 못하고 기다리게 되는 것

• 이를 해결하기위해 HTTP/1.1 에선 병렬 TCP 연결을 사용하고, HTTP/2 에선 객체를 작은 프레임으로 쪼개 골고루 보내는 방식을 사용한다.

HTTP/3.0의 주요 특징에 대해 설명해 주세요.

• HTTP/2.0 의 등장으로 애플리케이션 계층에서 HTTP 의 HOL 은 해결하였으나, 전송 계층에서의 TCP HOL 은 해결하지 못했다.

  • TCP 는 패킷이 유실되거나 오류가 있으면 재전송을 하는데, 이때 TCP는 패킷의 순서를 보장해야하기 때문에 재전송되는 패킷에 지연이 발생하면 다른 패킷들은 전송되지 못한다.

• 또한 TCP 자체의 핸드쉐이크 과정에서 발생하는 지연시간 역시 오버헤드가 되었다.

• 따라서 TCP의 한계를 극복하기 위해 UDP 기반의 QUIC 프로토콜을 만들어내고, 해당 프로토콜을 이용하는 HTTP 버전이 바로 HTTP/3 이다.

• HTTP/3.0 의 주요특징은 다음과 같다.

  • TCP + TLS 를 사용한 이전 HTTP 버전은 여러번의 핸드쉐이크가 필요한데 반해, HTTP/3.0 은 연결 설정에 1 RTT 만 소요된다.

    • 연결 설정에 필요한 정보와 데이터를 같이 보낸다.

  • UDP 기반의 QUIC 을 사용하기에 TCP HOL 이 발생하지 않는다.

    • 하나의 UDP Connection 안에서 데이터를 전송하는 스트림들을 독립적으로 다중화하여, 스트림 중 하나의 데이터에 손실이 발생해도, 다른 스트림의 데이터 전달을 차단하지 않는다.

TCP와 UDP

• UDP

  • 트랜스포트 계층이 해야하는 최소한의 역할인 multiplexing & demultiplexing 과 간단한 오류 검사 기능 이외엔 특별한 기능을 제공하지 않는다.

  • 송수신하는 트랜스포트 계층 개체들간의 핸드쉐이크를 수행하지 않는 비연결형 프로토콜이다.

  • 8바이트 헤더를 갖는다.

  • TCP 대비 빠르고 자유도가 높다.

    • 애플리케이션 레벨에서 데이터에 대한 정교한 제어를 하고 싶은 경우에 주로 사용한다.

• TCP

  • 데이터를 보내기 전 3-way handshake 하는 연결 지향형 프로토콜이다.

    • 호스트들은 연결 상태를 유지한다.

  • 신뢰적인 데이터 전송 프로토콜이다.

    • 전송된 데이터는 손상되거나 손실되지 않는다.

    • 수신자가 데이터를 잘 받아 ACK를 보낼때까지 계속해서 재전송한다.

    • 모든 데이터는 전송된 순서 그대로 전달받는다.

  • 일반적으로 20바이트 헤더를 갖는다.

  • 송신자가 수신자의 버퍼를 overflow 시키지 않도록 흐름 제어 서비스를 제공한다.

  • 링크가 복잡한 경우 혼잡 제어 메커니즘에 의해 전송률이 제어된다.

Checksum이 무엇인가요?

• 송신된 자료의 무결성을 검사하기 위한 방법

• 기본적인 메시지 구성 요소를 사용한 계산값을 체크섬 바이트로 사용한다.

• 체크섬 바이트를 구하는 간단한 방법

  • 데이터의 메시지 구성 요소들을 모두 더한다.

  • 체크섬 바이트 범위를 벗어나는 최상위 비트(캐리 니블)들은 버린다.

  • 그 후, 해당 수의 2의 보수를 구하면 그게 바로 체크섬 바이트이다.

• 수신측은 체크섬 바이트와 전달받은 데이터의 메시지 구성 요소들을 모두 합한 값을 더한다.

  • 결과물의 캐리 니블을 버린다.

  • 결과물이 0이면 오류가 없는 것

  • 그러나 오류가 있어도 우연히 결과물이 0이 될 수도 있다.

TCP와 UDP 중 어느 프로토콜이 Checksum을 수행할까요?

• 두 방식 모두 오류 검출 필드를 포함시켜 무결성 검사를 제공한다.

• UDP의 경우 체크섬 필드를 이용해 세그먼트의 오류 검출은 가능하나, 오류를 회복하기 위한 어떠한 서비스도 제공하지 않는다.

TCP가 신뢰성을 보장하는 방법에 대해 설명해 주세요.

• 신뢰적인 데이터 전송 프로토콜인 Go-Back-N 프로토콜과 Selective Repeat 프로토콜의 혼합 방식을 사용하여 신뢰성을 보장한다.

  • 누적 확인 응답과 단일 재전송 타이머를 사용하는 GBN 의 특징과 재전송이 필요한 패킷만 선택적으로 재전송하는 SR의 특징을 모두 가진다.

• TCP는 단일 재전송 타이머를 사용하여 ACK 세그먼트를 받지 못한 가장 오래된 세그먼트가 타이머를 사용하고 있다.

  • 만약 타임아웃이 발생하면 해당 세그먼트를 재전송한다.

• TCP는 누적 확인 응답을 사용한다.

  • 수신측은 제대로 받지 못한 세그먼트 중 가장 작은 Sequence number 를 ACK 넘버로 담아 보낸다.

  • 송신측은 ACK 넘버와 일치하는 Sequence number 를 가진 세그먼트 만을 재전송한다.

TCP의 혼잡 제어 처리 방법에 대해 설명해 주세요.

• 종단간의 혼잡 제어 방식을 채택한다.

  • 네트워크 혼잡 정도와 유무를 각 호스트가 추측하는 방식

• 송신측은 손실 이벤트가 발생하면 전송률을 줄인다.

• 송신측은 확인 응답이 제때 잘 도착하면 네트워크가 쾌적하다고 판단하여 전송률을 높인다.

왜 HTTP는 TCP를 사용하나요?

• TCP 가 제공하는 신뢰적인 데이터 전송 서비스를 사용하기 위해 TCP를 사용한다.

그렇다면, 왜 HTTP/3 에서는 UDP를 사용하나요? 위에서 언급한 UDP의 문제가 해결되었나요?

• UDP는 TCP 대비 빠르고 가볍다.

  • TCP의 혼잡 제어 메커니즘에 의해 전송률이 제어되지 않고

  • 연결 상태를 유지하지 않기때문에 TCP 대비 많은 클라이언트를 수용할 수 있으며

  • 헤더도 작고,

  • 3 way-handshake 도 수행하지 않아 빠르다.

• 애플리케이션 계층에서 신뢰적인 데이터 전송을 하도록 커스터마이징 함으로써, TCP와 UDP 의 장점을 모두 살릴 수 있다.

그런데, 브라우저는 어떤 서버가 TCP를 쓰는지 UDP를 쓰는지 어떻게 알 수 있나요?

• 네트워크 계층의 IPv4 데이터그램의 헤더 중에 Upper-layer protocol 필드가 있다.

• 해당 필드에서 IP 데이터그램의 데이터 부분 (세그먼트) 이 전달될 목적지의 트랜스포트 계층 프로토콜을 명시한다.

  • TCP = 6, UDP = 17

• 해당 필드값을 확인함으로써, 브라우저는 서버가 어떤 트랜스포트 계층을 사용하는지 알 수 있다.

본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?

• 사용자가 굉장히 많아서, 커스터마이징하는 노력을 들여서라도 성능을 최적화하고 싶다면 UDP를 사용할 것이다.

• 그렇지 않다면 TCP를 사용할 것이다.

DHCP

• Dynamic Host Configuration Protocol

• 호스트가 ISP로부터 개별 IP 주소를 동적으로 할당받는 방법

• DHCP를 통해 최초로 네트워크에 접속한 호스트는 IP 주소 할당 뿐 아니라 서브넷 마스크, 첫 번째 홉 라우터 주소, 로컬 DNS 서버 주소같은 네트워크 정보를 얻는다.

• 호스트가 빈번하게 접속하고 떠나는 네트워크 환경에서 유용하다.

• 클라이언트-서버 프로토콜이다.

  • 서브넷내에 DHCP 서버가 존재한다.

  • 방금 네트워크에 새롭게 접속한 호스트가 클라이언트이다.

DHCP는 몇 계층 프로토콜인가요?

• 애플리케이션 계층 프로토콜이다.

DHCP는 어떻게 동작하나요?

• DHCP discover message

  • 새롭게 도착한 호스트는 포트 67번으로 UDP 패킷을 서브넷에 broadcast로 보낸다.

• DHCP offer message

  • DHCP discover message 를 받은 DHCP 서버는 호스트에게 제공할 IP 주소, IP 주소 임대 기간, 서브넷 마스크, DHCP 서버 IP, DHCP discover message 의 트랜잭션 ID를 포함한 offer message 를 서브넷에 broadcast로 보낸다.

• DHCP request message

  • 호스트는 하나이상의 DHCP offer message 중 적절한 것을 선택한 뒤, 최적의 제안을 한 DHCP 서버주소를 포함한 응답 메시지를 서브넷에 broadcast로 보낸다.

  • 이를 통해 다른 DHCP 서버들은 자신의 제안이 거절되었음을 알 수 있다.

• DHCP ACK message

  • DHCP 서버는 DHCP 요청 메시지를 확인한 후 응답 메시지를 서브넷에 broadcast 로 보낸다.

• 호스트가 DHCP ACK message 를 받으면, 호스트는 서버가 제안한 IP 주소를 임대기간동안 사용할 수 있다.

• 구현 방식에 따라 DHCP 서버가 DHCP 클라이언트에게 보내는 모든 메시지는 Unicast로 전달될 수 있다.

  • 이때 srcIP 는 DHCP 서버 IP, dstIP는 클라이언트에게 제안한 IP인 yiaddr 이 된다.

  • DHCP 서버는 클라이언트의 MAC 주소를 알기에 Unicast로 보낼 수 있다.

DHCP에서 UDP를 사용하는 이유가 무엇인가요?

• TCP 대비 속도가 빠르고 효율적이다.

  • 빠른 동적 IP 할당이 가능하다.

• TCP 대비 리소스 요구 사항이 낮다.

  • 비연결 프로토콜이기 때문에 메모리 사용량과 CPU 사용률을 줄일 수 있다.

• 자체적으로 broadcast 와 multicast를 지원한다.

• 단순하고 구현이 쉬워 DHCP 서버와 클라이언트를 간단한 코드로 구현할 수 있다.

DHCP에서, IP 주소 말고 추가로 제공해주는 정보가 있나요?

• 호스트에게 제공할 IP 주소 이외에도 네트워크 정보를 추가로 제공해준다.

  • IP 주소 임대기간

  • 서브넷 마스크

  • DHCP 서버 IP

  • DHCP discover message 트랜잭션 id

  • 첫 번째 홉 라우터 주소 (default gate way IP)

  • 로컬 DNS 서버 주소

IP 주소

• 호스트나 라우터가 데이터그램을 보내려면 링크를 통해 보낸다.

  • 이때 호스트, 라우터와 링크 사이의 경계를 인터페이스라 한다.

• IP 주소는 이러한 인터페이스를 식별하는 주소이다.

• 호스트는 일반적으로 하나의 인터페이스를 갖기에 하나의 IP 주소를 갖고, 라우터는 여러개의 인터페이스를 갖기에 여러개의 IP 주소를 갖는다.

IPv6는 IPv4의 주소 고갈 문제를 해결하기 위해 만들어졌지만, 아직도 수많은 기기가 IPv4를 사용하고 있습니다. 고갈 문제를 어떻게 해결할 수 있을까요?

• DHCP 와 NAT 를 미봉책으로 사용하고 있다.

• DHCP 를 사용함으로써 ISP는 서비스 가입자 수보다 적은 Public IP로 서비스를 운영할 수 있다.

• NAT 를 사용함으로써 특정 기관 안의 여러개의 호스트들이 하나의 Public IP 만을 가지고 외부 네트워크와 통신할 수 있다.

IPv4와 IPv6의 차이에 대해 설명해 주세요.

• IPv4

  • 옵션 필드를 사용하지 않는 경우, 20바이트의 헤더 길이를 갖는다.

  • IP 주소 길이는 32비트 (4바이트) 이고, 일반적으로 각 바이트를 . 으로 끊은 뒤 십진수로 표기한다.

• IPv6

  • 40바이트의 헤더 길이를 갖는다.

    • IP 주소 길이가 길어 IPv4 대비 헤더의 길이가 길지만, 여러 필드가 제거되어 실제 내용은 간소화되었다.

      • 패킷 단편화 및 재결합을 위한 필드 제거

      • 헤더 체크섬 필드 제거

      • 옵션 필드 제거

  • IP 주소 길이는 128비트 (16바이트) 이고, 일반적으로 2 바이트씩 : 으로 끊은 뒤 16진수로 표기한다.

IPv4를 사용하는 장비와 IPv6를 사용하는 같은 네트워크 내에서 통신이 가능한가요? 가능하다면 어떤 방법을 사용하나요?

• 만약 IPv6 장비가 IPv4 프로토콜을 처리할 수 있도록 듀얼 스택을 지원한다면 IPv6 장비는 IPv4 장비와 통신할 수 있다.

  • 그러나 IPv6 장비가 IPv4 주소도 할당받게 되므로, IPv4 주소 고갈 문제 해결엔 큰 도움이 되지 않는다.

• 두 IPv6 장비 사이에 IPv4 장비가 끼어있는 경우, IPv6 패킷을 IPv4 패킷 속에 캡슐화하여 전달하는 터널링을 사용하여 IPv6 장비끼리는 통신할 수 있다.

  • 그러나 IPv6 장비와 IPv4 장비는 서로 통신할 수 없다.

IP가 송신자와 수신자를 정확하게 전송되는 것을 보장해 주나요?

• IP 프로토콜은 패킷이 송신 순서대로 수신됨을 보장하지도 않고, 패킷이 목적지에 도착하는 것도 보장하지 않으며, 보장된 최소 대역폭도 없이 데이터 전달에만 최선을 다하는 best-effort service 이다.

IPv4에서 수행하는 Checksum과 TCP에서 수행하는 Checksum은 어떤 차이가 있나요?

• IPv4 에서 수행하는 체크섬은 IPv4 패킷 헤더의 오류를 감지하는 헤더 체크섬으로, 헤더 체크섬과 일치하지 않는 모든 패킷을 삭제하여 패킷이 트랜스포트 계층으로 도달하지 못하도록 한다.

• TCP 는 TCP pseudo 헤더 (IP 헤더), TCP 헤더, TCP payload 모두 체크섬을 수행한다.

  • TCP pseudo 헤더는 TCP 세그먼트를 IP 헤더와 연결하는데 사용되며, 체크섬 계산 중에만 사용하고 실제 TCP 세그먼트의 일부로 전송되지는 않는다.

    • 체크섬을 통해 중간 과정에서 IP 헤더의 주요 필드가 부적절하게 수정되었는지 체크할 수 있다.

    • IP 패킷 헤더의 source IP, destination IP, Protocol, Length 와 같은 값들로 이루어진다.

TTL(Hop Limit)이란 무엇인가요?

• Time-to-live

• IP 패킷 헤더의 필드 중 하나이다.

• 라우터가 데이터그램을 처리할 때마다 1씩 감소한다.

• TTL 필드가 0이 되면 라우터가 해당 데이터그램을 폐기한다.

  • 이를 통해 데이터그램이 네트워크에서 무한히 순환하지 않도록 한다.

IP 주소와 MAC 주소의 차이에 대해 설명해 주세요.

• IP 주소는 통신을 위해 인터넷 프로토콜을 사용하는 장치와 네트워크 링크 사이의 인터페이스를 식별하기 위한 식별자이다.

  • 언제든 변경이 가능한 논리 주소이다.

• MAC 주소는 장치를 식별하는 고유한 하드웨어 주소이다.

  • 변경할 수 없는 물리적 주소이다.

OSI 7계층

• 인터넷 구조는 매우 복잡하다

  • 한번에 통으로 이해하기 어렵다.

• OSI 7계층은 인터넷의 다양한 프로토콜을 7개의 계층으로 계층화하는 모델이다.

  • 인터넷의 다양한 프로토콜을 계층화하여 특정 부분만을 논의하고 다른 부분을 단순화할 수 있다.

  • 또한 특정 계층이 제공하는 서비스의 구현을 변경하는 것이 쉽다.

    • 상위 계층에 같은 서비스를 제공하고, 하위 계층의 같은 서비스를 이용한다면 특정 계층의 구현이 바뀌어도 시스템의 나머지 부분이 변하지 않는다.

• Physical Layer

  • 물리적 통신 매체를 통해 데이터 (전자 신호) 를 전송하는 계층

• Data Link Layer

  • 물리 계층을 통해 송수신되는 정보의 오류와 흐름을 관리하는 계층

    • 데이터의 오류 제어 및 흐름 제어 수행

• Network Layer

  • 송신 호스트에서 수신 호스트로 데이터 패킷을 전달하는 기능을 제공하는 계층

    • 포워딩과 라우팅 수행

• Transport Layer

  • 각기 다른 호스트에서 동작하는 애플리케이션 프로세스간에 논리적인 통신 서비스를 제공하는 계층

  • 네트워크 계층이 제공하는 호스트 대 호스트 전달 서비스를 프로세스 대 프로세스 전달 서비스로 확장하는 계층이다.

    • 네트워크에서 전달받은 데이터를 소켓을 통해 프로세스로 전달하고 (demultiplexing)

    • 프로세스의 데이터를 소켓을 통해 네트워크로 전달한다. (multiplexing)

• Session Layer

  • 호스트 프로세스간에 세션을 생성, 유지, 종료하는데 필요한 여러 기능을 제공하는 계층
    • 세션이란, 네트워크 상에서 양 종단간 일회용 논리적 연결이다.

• Presentation Layer

  • 네트워크 상의 여러 시스템들이 사용하는 다른 데이터 표현 방식들을 하나의 통일된 구문 형식으로 변환시키는 기능을 수행하는 계층

• Application Layer

  • 종단 시스템에서 동작하는, 사용자 관점의 인터페이스 (네트워크 애플리케이션) 를 제공하는 계층

  • 메시지를 사용해 서로 다른 위치의 애플리케이션과 통신한다.

Transport Layer와, Network Layer의 차이에 대해 설명해 주세요.

• Network Layer는 호스트 대 호스트 전달 서비스를 제공한다.

• Transport Layer 는 호스트 대 호스트 전달 서비스를 프로세스 대 프로세스 전달 서비스로 확장한다.

  • 네트워크에서 전달받은 데이터를 프로세스로 전달하는 demultiplexing 과

  • 프로세스의 데이터를 네트워크로 전달하는 multiplexing 을 수행한다.

L3 Switch와 Router의 차이에 대해 설명해 주세요.

• 스위치는 포워딩을 수행한다.

  • 패킷이 입력 링크로 들어오면 해당 패킷을 적절한 출력 링크로 이동시킨다.

  • 매우 짧은 시간 동안, 하드웨어적으로 실행된다.

• 라우터는 라우팅을 수행한다.

  • 송신자가 수신자에게 패킷을 전송할 때 최적의 패킷 이동 경로를 계산 및 결정한다.

  • 상대적으로 긴 시간을 갖고 소프트웨어적으로 실행된다.

각 Layer는 패킷을 어떻게 명칭하나요? 예를 들어, Transport Layer의 경우 Segment라 부릅니다.

• Application Layer 는 Message 라 부른다.

• Transport Layer 는 TCP segment, 혹은 UDP Datagram 이라 부른다.

• Network Layer 는 IP Datagram 이라 부른다.

• Datalink Layer 는 Frame 이라 부른다.

• Physical Layer 는 Bits 라 부른다.

ARP에 대해 설명해 주세요.

• 같은 네트워크 대역 (LAN) 에서 통신을 하기위해 필요한 MAC 주소를, IP 주소를 이용해 알아오는 프로토콜이다.

  • MAC 주소는 데이터 링크 계층에서 데이터를 보내기 위해 사용된다.

• LAN 내의 디바이스들은 IP 주소와 MAC 주소를 일대일 매칭한 ARP 테이블을 갖고 있다.

• ARP를 사용해, ARP 테이블을 만드는 과정은 다음과 같다.

  • 목적지 IP주소는 알지만, 목적지 MAC 주소를 모르는 경우 송신 호스트는 목적지 MAC 주소를 알기위해 ARP Request 를 LAN 영역에 broadcasst 한다.

  • 목적지 IP 주소가 담긴 ARP Request 를 받은 목적지 호스트는 자신의 MAC 주소를 담은 ARP Response 를 송신 호스트에 날린다.

    • 목적지 IP 가 아닌 다른 호스트들은 ARP Request 패킷을 그냥 버린다.

  • 송신 호스트는 ARP Response 를 통해 ARP 테이블을 작성할 수 있다.

  • 이후, 목적지 MAC 주소로 데이터를 전달할 수 있다.

3-Way Handshake

• 클라이언트가 서버와 TCP 연결을 맺기 위해 필요한 시작 과정

  • 시작 과정에서 주고 받는 TCP 세그먼트는 애플리케이션 계층 데이터를 포함하지 않는다.

1. 클라이언트는 서버에게 SYN 세그먼트를 송신한다.

   • SYN 비트 1, ACK 비트 0
   • 임의의 순서 번호를 순서 번호 필드에 삽입

2. 서버는 SYN 세그먼트를 받으면 연결에 필요한 TCP 버퍼와 변수를 할당한 후 SYNACK 세그먼트를 클라이언트에게 보낸다.

   • SYN 비트 1, ACK 비트 1
   • 클라이언트의 순서 번호 + 1 을 확인 응답 필드에 삽입
   • 임의의 순서 번호를 순서 번호 필드에 삽입

3. 클라이언트가 SYNACK 세그먼트를 받으면 연결에 필요한 TCP 버퍼와 변수를 할당한 후 ACK 세그먼트를 서버에게 보낸다.

   • SYN 비트 0, ACK 비트 1
   • 서버의 순서 번호+1 을 확인 응답 필드에 삽입
   • 클라이언트의 순서 번호+1 을 순서 번호 필드에 삽입

• 위 과정이 모두 끝나면 TCP 연결이 수립되어 각 호스트들은 서로에게 TCP 세그먼트를 보낼 수 있다.

ACK, SYN 같은 정보는 어떻게 전달하는 것 일까요?

• TCP 세그먼트의 헤더에서 SYN 비트와 ACK 비트를 사용하여 정보를 전달한다.

2-Way Handshaking 를 하지않는 이유에 대해 설명해 주세요.

• 클라이언트는 서버로부터 SYN 세그먼트에 대한 ACK 응답을 제대로 받았다.

  • 클라이언트 입장에서 서버와 신뢰적인 연결 수립 여부 확인

• 서버는 클라이언트로부터 SYN 세그먼트에 대한 ACK 응답을 제대로 받지 못하게 된다.

  • 서버 입장에서 클라이언트와 신뢰적인 연결 수립 여부 확인 불가

• 따라서 클라이언트와 서버 모두 신뢰적인 연결 수립이 제대로 되었는지 확인하기 위해서는 3-way handshake가 최소조건이다.

SYN Flooding 에 대해 설명해 주세요.

• 서버가 클라이언트의 SYN 세그먼트를 받으면, 연결에 필요한 TCP 버퍼와 변수를 할당한다.

  • 만약 클라이언트가 서버가 보낸 SYNACK 에 대한 ACK를 보내지 않으면 일정시간 후에, 서버는 절반만 열린 연결을 종료하고 할당된 자원들을 회수한다.

• 공격자들은 이러한 점을 노려 3-way handshake의 마지막 단계를 완료하지 않은 상태에서 무수한 SYN 세그먼트를 보낸다.

  • 서버의 연결 자원이 무수한 반쪽 연결에 할당되어 소진됨에 따라, 정상적인 클라이언트들의 서비스도 방해받는다.

• 대부분의 운영체제에서 지원하는 SYN 쿠키를 사용해 SYN Flood Attack을 방어할 수 있다.

  • 서버는 SYN 세그먼트를 받으면 반쪽짜리 TCP 연결에 자원할당을 하지 않는다.

    • 서버의 비밀번호, SYN 세그먼트의 출발지 IP, 목적지 IP, 포트번호들을 조합하여 만든 해시값을 서버의 초기 TCP 순서 번호로 사용한다.

  • 정상적인 클라이언트는 서버로부터 받은 초기 TCP 순서 번호에 1을 더한값을 확인 응답 필드에 삽입하여 ACK로 보낸다.

  • 서버는 서버의 비밀번호, ACK 세그먼트의 출발지 IP, 목적지 IP, 포트번호들을 조합하여 만든 해시값에 1을 더한 값이 ACK 세그먼트의 확인 응답 필드값과 같은지 비교한다.

    • 같다면 그제서야 TCP 연결을 위한 자원을 할당한다.

  • SYN Flood Attack을 위한 가짜 SYN에 대해 서버가 어떤 자원도 할당하지 않으므로 SYN Flood Attack을 방어할 수 있다.

위 질문과 모순될 수 있지만, 3-Way Handshake의 속도 문제 때문에 이동 수를 줄이는 0-RTT 기법을 많이 적용하고 있습니다. 어떤 방식으로 가능한 걸까요?

• TCP의 본질적인 속도 문제를 해결하기 위해 UDP 기반의 새로운 신뢰성 프로토콜인 QUIC이 만들어졌다.

• QUIC 프로토콜에서 서버를 처음 방문한 클라이언트는 Initial 1-RTT 과정을 거친다.

  • 클라이언트는 CHLO(Client Hello) 메시지를 보낸다.

  • 서버는 REJECT 메시지에 서버의 공개키를 포함한 서버 정보, 인증서 체인 정보, 서버 정보를 개인키로 서명한 정보와 서버가 바라본 클라이언트의 IP주소와 시간을 전달한다.

  • 이후 클라이언트는 데이터를 포함한 Complete CHLO를 전송하고, SHLO(Server Hello) 메시지를 받는 과정에서 디피-헬만 키 교환 알고리즘을 사용해 대칭 세션키를 만들어 사용한다.

• 만약 한번 방문한적 있던 서버를 재접속하는 경우, 클라이언트는 0-RTT 과정을 거친다.

  • 클라이언트는 Complete CHLO를 데이터와 함께 전송한다.

  • 일정시간내에 서버에 유효한 요청을 보내는 경우 서버는 SHLO 메시지를 보낸다.

  • 요청이 유효하지 않은 경우엔 다시 1-RTT 과정을 거친다.

4-Way Handshake

• 클라이언트와 서버가 맺은 TCP 연결을 종료하기 위해 필요한 과정
  • 연결이 종료되면서, 각 호스트가 할당한 자원은 회수된다.

1. 클라이언트는 서버에게 FIN 세그먼트를 보낸다.

   • FIN 비트 1

2. FIN 세그먼트를 수신한 서버는 ACK 세그먼트를 클라이언트에게 보낸다.

3. 서버는 FIN 세그먼트를 클라이언트에게 보낸다.

4. FIN 세그먼트를 수신한 클라이언트는 ACK 세그먼트를 서버에게 보낸 뒤 일정시간 대기 후 연결을 종료한다.

패킷이 4-way handshake 목적인지 어떻게 파악할 수 있을까요?

• TCP 세그먼트의 FIN 플래그 비트가 1이면 4-way handshake 목적임을 파악할 수 있다.

빨리 끊어야 할 경우엔, (즉, 4-way Handshake를 할 여유가 없다면) 어떻게 종료할 수 있을까요?

• 연결상의 문제를 발견한 호스트가 RST 세그먼트를 전송함으로써 abrupt connection relesase가 수행된다.

  • 존재하지 않는 TCP 연결에 대해 SYN 세그먼트가 아닌 세그먼트가 수신되거나

  • 유효하지 않은 헤더가 있는 세그먼트가 수신되거나

  • 연결을 유지하기에 자원이 부족하거나

  • 상대 호스트에 연결할 수 없는 경우 수행된다.

• 송신자는 패킷을 보내고 연결을 종료하고, 수신자는 패킷을 받으면 바로 연결을 종료한다.

4-Way Handshake 과정에서 중간에 한쪽 네트워크가 강제로 종료된다면, 반대쪽은 이를 어떻게 인식할 수 있을까요?

• TCP는 응답을 받지 못한 세그먼트에 대해 타이머를 갖고 있다.

• 따라서 4-way handshake 과정에서 한쪽 네트워크가 강제로 종료됨으로써 오랜시간 응답을 받지 못하게 되면 타임아웃이 발생한다.

  • 이를 통해 반대쪽이 문제를 인식할 수 있다.

왜 종료 후에 바로 끝나지 않고, TIME_WAIT 상태로 대기하는 것 일까요?

• TCP 서버가 FIN 세그먼트보다 일찍 보낸 데이터 세그먼트가 네트워크 혼잡에 의해 더 늦게 도착할 수 있기때문에

• TCP 클라이언트는 TCP 서버에 ACK 세그먼트를 보내고도 일정시간 대기후에 연결을 종료한다.

www.github.com을 브라우저에 입력하고 엔터를 쳤을 때, 네트워크 상 어떤 일이 일어나는지

• 네트워크에 처음 호스트를 연결하면, IP 주소 없이 아무것도 할 수 없다.

• 따라서 DHCP 서버로부터 IP 주소를 획득하기 위해 DHCP 프로토콜을 실행한다.

  • DHCP 클라이언트는 DHCP 서버로부터 DHCP ACK 메시지를 받음으로써, 서버가 제안한 IP 주소를 임대기간동안 사용할 수 있다.

• 웹 브라우저에 URL을 입력하면 DNS 프로토콜을 통해 호스트 이름을 IP주소로 변환해야 한다.

  • DNS 질의 메시지를 UDP 세그먼트 안에 넣는다.

  • UDP 세그먼트는 앞선 DHCP offer 메시지에서 알아낸 DNS 서버 IP 주소를 목적지로 하는 IP 데이터그램 안에 넣는다.

  • DHCP offer 메시지를 통해 디폴트 게이트웨이 라우터 IP 주소는 알아냈지만 MAC 주소는 모르기에 ARP 프로토콜을 통해 MAC 주소를 알아낸다.

  • IP 데이터그램은 알아낸 디폴트 게이트웨이 라우터 MAC 주소를 목적지로 하는 이더넷 프레임 안에 넣는다.

  • 이더넷 프레임을 디폴트 게이트웨이 라우터로 전송함으로써 결과적으로 DNS 서버로 DNS 질의 메시지를 보낼 수 있다.

    • IP 목적지 주소가 가리키는 호스트 (DNS 서버) 와 MAC 주소가 가리키는 호스트 (디폴트 게이트웨이 라우터) 는 다르다.

  • 디폴트 게이트웨이 라우터는 DNS 질의 메시지가 포함된 이더넷 프레임을 받아서 IP 데이터그램을 추출한다.

  • 라우터는 DNS 서버 IP 주소를 포워딩 테이블에서 찾아서 다음 목적지 라우터로 전송되는 이더넷 프레임에 IP 데이터그램을 다시 넣고 전송한다.

  • 여러 라우터를 거쳐 DNS 서버에 DNS 질의가 포함된 IP 데이터그램이 도착한다.

  • DNS 서버는 DNS 질의 메시지를 추출한 후 www.github.com에 해당하는 IP 주소를 포함하는 DNS 레코드를 찾는다.

  • DNS 서버는 호스트 이름에 대한 IP 주소 정보를 포함한 DNS 응답 메시지를 만들어 UDP 세그먼트에 넣은 후 클라이언트를 목적지로 하는 IP 데이터그램에 넣어 전송한다.

  • 결과적으로 클라이언트는 DNS 응답 메시지로부터 www.github.com에 해당하는 IP 주소를 추출한다.

• 클라이언트는 HTTP 메시지를 www.github.com에 보내는 데 사용할 TCP 소켓을 생성한다.

  • 클라이언트 호스트는 www.github.com 서버와 TCP 3-way handshake를 수행하여 연결을 맺는다.

• 클라이언트는 TCP 소켓을 통해 HTTP 요청 메시지를 보낸다

  • 서버는 HTTP 응답 메시지를 보냄으로써 www.github.com 콘텐츠를 보낸다.

• 브라우저는 HTTP 응답 메시지를 읽어 웹 페이지를 출력한다.

DNS 쿼리를 통해 얻어진 IP는 어디를 가리키고 있나요?

• 호스트 이름을 소유한 웹 사이트의 서버 호스트를 가리킨다.

Web Server와 Web Application Server의 차이에 대해 설명해 주세요.

• 웹 서버는 정적 콘텐츠를 제공한다.

  • 정적 콘텐츠는 변화가 없는 데이터로 어떤 클라이언트에게든 동일한 데이터를 반환한다.

• WAS는 비즈니스 로직을 통해 동적 콘텐츠를 제공한다.

  • 동적 콘텐츠는 자주 변경되는 데이터로 클라이언트의 요청에 따라 각각 다른 형태의 데이터를 반환한다.

URL, URI, URN은 어떤 차이가 있나요?

• URI

  • Uniform Resource Identifier

  • 네트워크의 자원을 식별하는 방법

  • URL, URN을 포함하는 개념

• URL

  • Uniform Resource Locator

  • 네트워크 자원에 위치를 지정하여 식별하는 방법

  • 프로토콜://호스트:포트/경로?파라미터 형태로 이루어진다.

• URN

  • Uniform Resource Name

  • 네트워크 자원에 이름을 부여하여 식별하는 방법

DNS

• Domain Name System

• 호스트를 식별하는 방법은 IP 주소이지만, 사람들은 IP 주소를 외우기 힘들다.

• 대신 외우기 쉬운 호스트 이름을 선호한다.

• 이러한 선호차이를 절충하기 위해 호스트 이름을 IP 주소로 변환해주는 시스템이 DNS이다.

• DNS는 DNS 서버들의 계층 구조로 구현된 분산 데이터베이스이다.

  • 루트 DNS 서버, TLD 서버, Authoriative DNS 서버 순으로 계층을 이룬다.

  • 상위 계층 DNS 서버는 하위 계층 DNS 서버의 IP 주소를 갖고 있다.

• 로컬 DNS 서버는 DNS 서버 계층 구조엔 속하지 않는다.

  • 주로 ISP들이 로컬 DNS 서버를 갖는다.

  • 호스트의 DNS 질의는 로컬 DNS 서버가 받아 처리하거나 DNS 서버 계층으로 질의를 전달한다.

• DNS 서버는 DNS 레코드를 갖는다.

  • Type=A 레코드는 호스트 이름에 대한 IP 주소 매핑을 제공한다.

  • Type=NS 레코드는 호스트 이름에 대한 IP 주소를 얻을 수 있는 방법을 아는 하위 DNS 서버의 호스트 이름을 제공한다.

  • DNS 질의 메시지를 받은 DNS 서버는 Type=A DNS 레코드를 메시지에 담아 응답한다.

DNS는 몇 계층 프로토콜인가요?

• DNS는 애플리케이션 계층 프로토콜이다.

UDP와 TCP 중 어떤 것을 사용하나요?

• UDP를 사용한다.

• TCP 대비 빨라 더 많은 클라이언트들을 수용할 수 있다.

• DNS 메시지는 패킷 사이즈가 작다

  • 따라서 TCP의 헤더는 큰 오버헤드이다.

  • 또한 UDP 세그먼트가 유실되어도 그냥 다시 전달하면 된다.

• DNS는 호스트 간 연결 상태를 유지할 필요가 없다.

  • TCP의 연결 상태 유지가 필요없다.

DNS Recursive Query, Iterative Query가 무엇인가요?

• 요청 호스트가 로컬 DNS 서버에게 보내는 DNS 질의는 DNS Recursive Query 이다.

  • 요청 호스트 입장에서 로컬 DNS 서버에게만 DNS 질의를 보내면, 로컬 DNS 서버가 알아서 여러번의 질의를 통해 요청 호스트가 원하는 결과 (매핑되는 IP 주소) 를 반환하기 때문이다.

• 로컬 DNS 서버가 DNS 질의 메시지 속 호스트 이름과 매핑되는 IP 주소를 찾기 위해 DNS 서버 계층 구조안의 DNS 서버들에게 반복적으로 질의하는 것이 DNS Iterative Query 이다.

  • 로컬 DNS 서버가 호스트 이름과 매핑되는 DNS 레코드를 갖고 있지 않다면

  • 로컬 DNS 서버는 루트 DNS 서버에 질의하여 호스트 이름에 대한 책임을 가진 TLD 서버의 IP 주소를 알아낸다.

  • 로컬 DNS 서버는 다시 TLD 서버에 질의하여 호스트 이름에 대한 IP 주소를 알고있는 책임 DNS 서버의 IP 주소를 알아낸다.

  • 로컬 DNS 서버는 마지막으로 책임 DNS 서버에 질의하여 호스트 이름에 대한 IP 주소를 알아낸다.

DNS 쿼리 과정에서 손실이 발생한다면, 어떻게 처리하나요?

• 클라이언트는 일정 시간동안 DNS 응답 메시지를 받지 못한다면 패킷 재전송을 시도한다.

• 재전송 이후에도 DNS 응답 메시지를 받지 못한다면 다른 DNS 서버에 쿼리를 보내거나 응답 에러를 반환한다.

DNS 레코드 타입 중 A, CNAME, AAAA의 차이에 대해서 설명해주세요.

• A 레코드

  • (호스트 이름, IP, A, TTL) 로 이루어져 있다.

  • 호스트 이름과 서버의 IP 주소가 직접 매핑되는 레코드

• CNAME 레코드

  • (호스트 이름, 호스트 별칭, CNAME, TTL) 로 이루어져 있다.

  • 호스트 이름을 또 다른 호스트 별칭으로 이중 매핑하는 레코드

  • 호스트 이름과 매핑되는 IP 주소가 자주 변경되는 환경에서 유용하다.

• AAAA 레코드

  • A 레코드의 IPv6 버전

  • 호스트 이름에 IPv6 주소가 매핑되어 있는 레코드

hosts 파일은 어떤 역할을 하나요? DNS와 비교하였을 때 어떤 것이 우선순위가 더 높나요?

• hosts 파일은 기존에 매핑되어 있는 IP와 도메인을 호스트가 임의로 변경하기 위해 사용된다.

• IP 매핑에 우선순위는 다음과 같다.

  • 브라우저 DNS 캐시 확인

  • hosts 파일 확인

  • 로컬 DNS 서버에 질의

• 따라서 DNS 서버에 질의하는 것보다 우선순위가 높다

SOP 정책

• Same-origin policy

• 한 origin에서 로드된 문서나 스크립트가 다른 origin의 리소스와 상호작용할 수 없도록 제한하는 정책

• origin 이란 프로토콜, 포트, 호스트의 조합이다.

  • 두 URL의 프로토콜, 포트, 호스트가 동일하다면 두 URL의 origin은 같다.

• site는 프로토콜, 루트 도메인(도메인 이름 + 최상위 도메인)의 조합이다.

  • 서브 도메인이나 포트 번호는 포함하지 않는다.

CORS 정책이 무엇인가요?

• Cross-origin resource sharing

• origin이 다른 서버간의 리소스 공유를 허용하는 정책

  • 프론트 서버와 백엔드 서버가 분리되면서 생겨남

  • 리소스를 제공하는 서버는, 리소스 호출이 허용된 origin과 HTTP 메서드, 헤더를 명시해줌으로써 cors 가능

Preflight에 대해 설명해 주세요.

• 브라우저에서 실제 요청을 보내기전에 요청이 가능한 상태인지 점검하기 위해 보내는 예비 요청

• OPTIONS 메서드를 사용하여 헤더에 origin, 실제 요청 메서드와 같은 정보를 보낸다.

• 서버로부터 리소스 호출이 허용된 origin과 메서드, 헤더 정보를 가져온다.

• 브라우저는 서버의 응답을 바탕으로 자신의 본 요청이 안전하다고 판단하면 본 요청을 보낸다.

• Preflight request는 일정 시간 캐싱된다.

Stateless와 Connectionless

• Stateless

  • 서버가 클라이언트 상태를 보존하지 않는다.

  • 서버 확장성이 높다

  • 클라이언트를 식별하기 위해선, 클라이언트가 추가적인 데이터를 전송해야 한다.

• Connectionless

  • 클라이언트가 요청에 대한 응답을 받으면 바로 TCP 연결을 끊는다.

  • 사용자가 많더라도 실제 동시 처리 요청을 적게 가져갈 수 있다.

  • TCP/IP 연결을 매 요청시마다 새로 맺어야 함으로 3-way handshake 오버헤드가 커진다.

  • 하나의 웹 페이지에 동반되는 JS, CSS, 이미지와 같은 추가 리소스 다운로드마다 3-way handshake 오버헤드가 발생한다.

왜 HTTP는 Stateless 구조를 채택하고 있을까요?

• 서버가 클라이언트 상태를 보존하지 않음으로써 서버 확장이 용이하다.

• 각 요청이 독립성을 가지므로 서버의 개발과 유지 보수가 단순해진다.

Connectionless의 논리대로면 성능이 되게 좋지 않을 것으로 보이는데, 해결 방법이 있을까요?

• HTTP 1.1의 지속 연결을 사용함으로써 해결할 수 있다.

• 처음에만 TCP 3-way handshaking을 통해 클라이언트와 서버간의 TCP 연결을 맺은 후, 모든 요청/응답 쌍을 해당 TCP 연결을 통해 보낸다.

• 이후, 일정 시간동안 클라이언트가 요청을 하지 않으면 서버는 TCP 커넥션을 닫는다.

TCP의 keep-alive와 HTTP의 keep-alive의 차이는 무엇인가요?

• TCP의 keep-alive는 비정상 종료된 상대 호스트를 구분해내기 위해 사용한다.

  • 4-way handshake 없이 상대 호스트는 비정상 종료되었는데

  • 한 쪽 호스트는 연결이 되어있는 줄 알고 TCP 소켓을 열어두고 데이터를 지속적으로 보내는 문제가 발생할 수 있다.

  • 이러한 유령 세션을 감지하기 위해 일정 시간 간격으로 payload가 없는 데이터를 전송하여 TCP 연결이 유효한 지 검사한다.

    • 데이터에 대한 ack가 오지 않는다면 TCP 연결을 종료한다.

• HTTP의 keep-alive는 HTTP1.0+ 버전에서 지속 연결을 하기위해 사용한다.

  • Connection: Keep-Alive 헤더를 추가하면 사용할 수 있다.

  • keep-alive 옵션을 지원하지 않는 멍청한 프록시 문제때문에 표준 헤더는 아니다.

  • HTTP1.1 이상부터는 기본적으로 지속 연결이기 때문에 더이상 사용하지 않는다.

라우터 내의 포워딩 과정

• 라우터 내의 포워딩 과정이란 입력 링크로 들어온 패킷을 적절한 출력 링크로 실제로 전달하는 기능이다.

• 입력 포트로 들어온 이더넷 프레임에서 IP 패킷을 추출한다.

• IP 패킷의 목적지 IP 주소를 바탕으로 라우터의 포워딩 테이블에서 출력 포트를 찾는다.

  • 포워딩 테이블은 라우터 프로세서가 라우팅 프로토콜을 통해 계산하거나 원격 SDN 컨트롤러에서 수신된다.

  • 포워딩 테이블은 IP 주소의 prefix만 갖고, longest prefix matching rule에 의해 패킷이 전달될 출력 포트를 찾는다.

• 스위치 구조에 의해 입력 포트에서 출력 포트로 실제 패킷이 전달된다.

• 출력 포트는 큐잉된 IP 패킷을 가져와 이더넷 프레임안에 넣고 출력 링크로 전송한다.

라우팅과 포워딩의 차이는 무엇인가요?

• 포워딩

  • 패킷이 라우터의 입력 링크로 들어오면, 해당 패킷을 적절한 출력 링크로 이동시키는 것

  • 매우 짧은 시간 동안, 하드웨어적으로 실행된다.

• 라우팅

  • 송신자가 수신자에게 패킷을 전송할 때 최적의 패킷 이동 경로를 결정하는 것

  • 상대적으로 긴 시간을 갖고 소프트웨어적으로 실행된다.

라우팅 알고리즘에 대해 설명해 주세요.

• 라우팅 알고리즘의 목표는 송신자부터 수신자까지의 최적의 네트워크 경로를 찾는 것이다.

• 링크 상태 라우팅 알고리즘

  • 중앙 집중형 라우팅 알고리즘으로 네트워크 전체에 대한 완전한 정보를 가지고 출발지와 목적지 사이 최소 비용 경로를 계산한다.

  • 각 노드가 자신과 직접 연결된 링크의 비용과 이웃 노드 정보를 담은 링크 상태 패킷을 네트워크상의 다른 모든 노드로 브로드캐스트한다.

    • 이를 통해 모든 노드는 네트워크에 대해 동일하고 완벽하게 알게 된다.

  • 트래픽 부하의 변동에 따라 링크 비용이 변하게 되면 oscillation 문제가 발생할 수 있다.

    • 트래픽이 골고루 분산되지 않고 한쪽으로만 몰리면서 경로가 진동하는 현상

    • 모든 라우터가 동시적으로 LS 알고리즘을 수행하는 경우 발생한다.

• 거리 벡터 라우팅 알고리즘

  • 분산 라우팅 알고리즘으로 각 라우터들에 의해 반복적이고 분산된 방식으로 최소 비용 경로를 계산한다.

  • 각 노드는 이웃 노드로부터 정보를 받고 계산을 수행한 뒤 계산된 결과를 이웃 노드에게 배포한다.

  • 이웃 노드가 더이상 정보를 교환하지 않을때까지 프로세스가 지속된다.

  • 모든 노드가 동시에 동작할 필요없다.

  • 정확히 알고있는 인접한 이웃 노드까지의 경로 비용 + 이웃 노드에서 도착지 노드까지의 경로 비용 추정치 = 거리벡터

    • 이웃 노드로부터 경로 비용 추정치를 갱신한 정보를 받을때마다 자신의 거리벡터를 갱신한다.

  • 자신의 거리 벡터가 갱신되었다면 이웃 노드에게 자신의 거리 벡터 정보를 보낸다.

  • 이러한 거리 벡터의 갱신이 멈출때까지 정보 교환 반복을 통해 거리 벡터값은 최소 비용으로 수렴한다.

  • 더이상 이웃 노드로부터 정보를 받지 않아 거리 벡터 갱신이 끝날 때, 그때의 거리 벡터가 결정된 최소 비용이다.

  • 최소 비용 거리 벡터를 알아냄으로써 각 라우터는 목적지까지 가기 위한 이웃 노드를 결정할 수 있다.

  • 링크 비용이 증가하는 경우 링크 비용의 증가가 천천히 비효율적으로 알려지는 무한 계수 문제가 발생할 수 있다.

    • 이웃을 2개만 가지는 노드로 이루어진 경우, 포이즌 리버스를 사용해 무한 계수 문제를 해결할 수 있지만, 이웃을 3개 이상 가지는 노드를 포함한 루프는 이를 해결할 수 없다.

포워딩 테이블의 구조에 대해 설명해 주세요.

• 라우터의 입력 포트로 들어온 IP 패킷이 어떤 출력 포트로 전달되어야 하는지 알려주는 테이블

• 포워딩 테이블의 각 엔트리는 prefix mask와 다음 출력 포트로 이루어져있다.

  • 목적지 IP 주소와 매칭되는 longest prefix mask를 찾을때까지 길이가 긴 mask부터 차례대로 순회한다.

로드밸런서

• 애플리케이션을 이용하는 네트워크 트래픽을 균등하게 분산시켜 모든 리소스 서버가 동일하게 사용되도록 하는 장치

• 클라이언트의 인터넷 트래픽을 제어함으로써 여러가지 이점이 있다.

  • 장애가 발생한 서버를 자동으로 감지하고, 클라이언트 트래픽을 사용 가능한 서버로 리디렉션함으로써 애플리케이션 가용성을 높인다.

  • 특정 서버에만 트래픽이 몰리는 현상을 방지함으로써 애플리케이션 성능을 높이고 확장을 용이하게 한다.

  • DDoS와 같은 서비스 거부 공격을 처리함으로써 애플리케이션 보안성을 높인다.

L4 로드밸런서와, L7 로드밸런서의 차이에 대해 설명해 주세요.

• L4 로드밸런서

  • 네트워크 계층 정보와 트랜스포트 계층 정보를 바탕으로 스케줄링 알고리즘을 통해 부하를 분산한다.

• L7 로드밸런서

  • HTTP 헤더, 쿠키, SSL 세션 ID와 같은 요청 콘텐츠를 확인하여 트래픽을 리디렉션한다.

  • 요청의 세부적인 사항을 바탕으로 서버를 분류하여 요청을 분산시킬 수 있다.

    • 결제 담당 서버

    • 회원가입 담당 서버 등으로 분리

로드밸런서 알고리즘에 대해 설명해 주세요.

• 클라이언트 요청을 보내기에 가장 적합한 서버를 결정하기 위한 알고리즘

• 정적 로드 밸런싱

  • 현재 서버 상태와 무관하게 고정된 규칙을 가진 알고리즘

  • 라운드 로빈 방식

  • 가중치 기반 라운드 로빈 방식

  • IP 해시 방식

• 동적 로드 밸런싱

  • 현재 서버 상태를 검사한다음 트래픽을 적절하게 배포하는 알고리즘

  • 최소 연결 방법

    • 가장 연결이 적은 서버에 트래픽을 보낸다.

  • 가중치 기반 최소 연결 방법

  • 최소 응답 시간 방법

  • 리소스 기반 방법

로드밸런싱 대상이 되는 장치중 일부 장치가 문제가 생겨 접속이 불가능하다고 가정해 봅시다. 이 경우, 로드밸런서가 해당 장비로 요청을 보내지 않도록 하려면 어떻게 해야 할까요?

• 로드밸런서는 서버들에 대한 주기적인 상태 확인을 통해 장애 여부를 판단해야 한다.

로드밸런서 장치를 사용하지 않고, DNS를 활용해서 유사하게 로드밸런싱을 하는 방법에 대해 설명해 주세요.

• 별도의 로드밸런서 장치 없이 DNS를 이용해 트래픽을 분산할 수 있다.

• 하나의 호스트 이름에 여러개의 서버가 연결되어 있는 경우 하나의 호스트 이름에 대해 여러개의 IP 주소 집합을 갖는다.

• DNS는 DNS 질의 메시지의 결과인 IP 주소 집합을 각 응답마다 순서를 바꿔가며 순환식으로 보낸다.

  • 클라이언트는 주로 IP 주소 집합의 첫 번째 IP 주소로 요청을 보내기에 트래픽이 분산되는 효과가 있다.

  • DNS 라운드 로빈

서브넷 마스크와, 게이트웨이

• 서브넷

  • 중간 라우터 없이 호스트 인터페이스들이 라우터 인터페이스와 연결되거나, 라우터 인터페이스와 라우터 인터페이스가 연결된 고립된 네트워크

• 서브넷 마스크

  • 서브넷 마스크란 클래스리스기반 IP 주소에서 서브넷 주소와 호스트 주소를 구분하기 위한 구분자이다.

  • 서브넷 주소 자리수까지는 2진수 숫자 1로 표현하고, 그 외의 호스트 주소 자릿수들은 숫자 0으로 표현한다.

• 게이트웨이

  • 한 서브넷에서 다른 서브넷으로 패킷을 이동시키기 위해 거쳐야 하는 지점

  • 라우터는 실제 장치를 의미하는데 반해, 게이트웨이는 개념적인 단어이다.

서브넷 마스크의 표현 방식에 대해 설명해 주세요.

• 서브넷 주소 자리수까지는 2진수 숫자 1로 표현하고, 그 외의 호스트 주소 자릿수들은 숫자 0으로 표현한다.

• 예를 들어 상위 24비트까지가 서브넷 주소이고, 나머지 8비트가 호스트 주소라면 서브넷 마스크는 255.255.255.0이고 /24 로도 표현할 수 있다.

NAT에 대해 설명해 주세요.

• Network Address Translation

• IPv4 주소 고갈 문제를 대처하기 위해 도입한 주소 할당 방식

  • private network의 여러대의 호스트가 외부로 드러나는 하나의 public IP를 갖도록 한다.

  • private network내의 호스트들이 글로벌 인터넷과 통신하기 위해 NAT를 사용한다.

  • NAT 가능 라우터는 여러대의 호스트들이 있는 private network와 외부로의 네트워크를 연결한다.

• NAT 동작 과정

  • private network내의 호스트가 외부 세계의 서버에 요청을 날린다.

  • NAT 가능 라우터는 해당 요청을 받아 임의의 포트번호를 생성한 뒤 (NAT 라우터 public IP, 임의로 생성된 포트 번호) : (요청 호스트 IP, 요청 호스트 포트번호) 를 NAT 변환 테이블에 저장한다.

  • 외부 세계의 서버에는 NAT 라우터 public IP와 임의 생성된 포트 번호를 사용하여 요청을 날린다.

  • 서버는 NAT 가능 라우터에게 응답 메시지를 보낸다.

  • NAT 가능 라우터는 NAT 변환 테이블에서 응답 메시지의 목적지 포트 번호와 매핑되는 호스트를 찾고, 해당 호스트에게 응답 메시지를 보낸다.

• NAT는 3계층 장치인 NAT 라우터가 호스트가 보낸 메시지의 포트번호를 확인하고 조작한다는 점에서 layer violation이다.

멀티플렉싱과 디멀티플렉싱에 대해 설명해 주세요.

• 네트워크 계층이 제공하는 호스트 대 호스트 전달 서비스를 프로세스 대 프로세스 전달 서비스로 확장하는 것을 의미한다.

• 프로세스는 소켓을 통해 네트워크에서 프로세스로 데이터를 전달받고, 프로세스의 데이터를 네트워크로 전달한다.

  • 각 소켓은 프로세스의 포트 번호를 할당 받는다.

• 네트워크 계층을 통해 전달받은 트랜스포트 계층 세그먼트의 헤더를 읽고 세그먼트의 데이터를 적절한 수신 소켓으로 전달하는 작업을 demultiplexing이라 한다.

• 애플리케이션이 소켓에 전달한 데이터를 모아 적절한 헤더를 붙여 세그먼트로 캡슐화한 것을 네트워크 계층으로 전달하는 작업을 multiplexing이라 한다.

XSS

• Cross Site Scripting의 약자

• 공격자는 스크립트를 별다른 필터링 없이 실행하는 취약한 웹 사이트를 찾은 뒤, 공격을 위한 스크립트를 포함한 URL을 사용자에게 노출시킨다.

• 사용자가 URL을 클릭하면, 취약한 웹 사이트의 서버에 공격 스크립트가 포함된 클라이언트 요청을 전송하고, 서버는 공격 스크립트를 포함하여 응답하게 된다.

• 이를 통해 클라이언트의 쿠키 정보 및 세션 아이디나 시스템 관리자 권한을 획득할 수 있다.

CSRF랑 XSS는 어떤 차이가 있나요?

• Cross Site Request Forgery의 약자

• 공격자는 보안이 취약한 서버에 로그인한 사용자가 공격을 위한 스크립트를 포함한 URL을 클릭하도록 유도한다.

• 공격 스크립트는 사용자의 로그인 정보를 가지고 서버로 요청된다.

• 서버는 공격 스크립트를 인증된 사용자로부터 온 요청이라 생각하고 처리함으로써 사용자 계정에 대한 비정상적인 조작을 할 수 있다.

• XSS는 클라이언트의 브라우저에서 발생하는 문제이고, CSRF는 서버에서 발생하는 문제이다.

XSS는 프론트엔드에서만 막을 수 있나요?

• 서버에서 쿠키를 발급할 때 httpOnly 설정을 통해 공격자가 자바스크립트로 조회하지 못하도록 막을 수 있다.

• 서버단에서 입력으로 들어온 스크립트를 실행하기 위한 문자열 (<, >) 등을 필터링하거나 HTML 엔티티로 변환하여 막을 수 있다.

출처

여러대의 서버에서 세션 관리
https://hyuntaeknote.tistory.com/

401 vs 403
https://www.permit.io/blog/401-vs-403-error-whats-the-difference

GET with body
https://stackoverflow.com/questions/5216567/is-this-statement-correct-http-get-method-always-has-no-message-body

공개키 대칭키
https://velog.io/@ann0905/HTTPS-1.%EC%95%94%ED%98%B8%ED%99%94%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC%EB%8C%80%EC%B9%AD%ED%82%A4-%EA%B3%B5%EA%B0%9C%ED%82%A4#-%EB%8C%80%EC%B9%AD%ED%82%A4symmetric-key-%EB%B0%A9%EC%8B%9D

HTTPS 동작 과정
https://golf-dev.tistory.com/72

https://aws-hyoh.tistory.com/entry/HTTPS-%ED%86%B5%EC%8B%A0%EA%B3%BC%EC%A0%95-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3SSL-Handshake

소켓 vs 웹 소켓
https://choo.oopy.io/6bd233ef-79fe-408c-b993-8cf8351460ec#55c5e343-067e-4439-824e-e6e333937b0a

HTTP/3.0
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-30-%ED%86%B5%EC%8B%A0-%EA%B8%B0%EC%88%A0-%EC%9D%B4%EC%A0%9C%EB%8A%94-%ED%99%95%EC%8B%A4%ED%9E%88-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

https://bentist.tistory.com/36

dhcp using tcp
https://www.baeldung.com/cs/dhcp-udp-tcp

IPv6, IPv4 통신
https://m.blog.naver.com/wnrjsxo/221201136479

IPv4 checksum vs TCP checksum
https://networkengineering.stackexchange.com/questions/52936/difference-between-ip-checksum-and-tcp-checksum

TCP Pseudo Header
https://www.oreilly.com/library/view/windows-server-2008/9780735624474/ch10s06.html

세션 계층
http://www.ktword.co.kr/test/view/view.php?no=465

표현 계층
http://www.ktword.co.kr/test/view/view.php?no=430

응용 계층
http://www.ktword.co.kr/test/view/view.php?no=468

패킷 이름
https://www.omnisecu.com/tcpip/names-of-data-packets-at-different-layers-of-tcpip-model.php?expand_article=1

ARP
https://aws-hyoh.tistory.com/70

https://www.youtube.com/watch?v=LDsp-Xb168E

TCP connection termination
https://www.geeksforgeeks.org/tcp-connection-termination/

Web Server, WAS
https://aws.amazon.com/ko/compare/the-difference-between-web-server-and-application-server/
https://cceeun.tistory.com/68

DNS record
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EB%A0%88%EC%BD%94%EB%93%9C-%EC%A2%85%EB%A5%98-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC

hosts (/etc/hosts)
https://insoobaik.tistory.com/102

SOP
https://dongwooklee96.github.io/post/2021/03/23/sopsame-origin-policy-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C.html

same origin, same site
https://velog.io/@minjae-mj/%ED%98%B8%EC%8A%A4%ED%8A%B8-%EB%84%A4%EC%9E%84%EA%B3%BC-%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%84%A4%EC%9E%84

CORS
https://docs.tosspayments.com/resources/glossary/cors
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

Keep-Alive
https://blog.naver.com/whdgml1996/222153047879

로드 밸런서
https://aws.amazon.com/ko/what-is/load-balancing/
https://m.post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903

서브넷 마스크
https://medium.com/@su_bak/%EC%84%9C%EB%B8%8C%EB%84%B7-%EB%A7%88%EC%8A%A4%ED%81%AC-subnet-mask-%EB%9E%80-398ecdfd5c0d

게이트웨이
https://hstory0208.tistory.com/entry/Gateway%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4%EB%9E%80-Router%EB%9D%BC%EC%9A%B0%ED%84%B0%EB%9E%80-%EA%B0%81-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

XSS
https://4rgos.tistory.com/1

CSRF
https://devscb.tistory.com/123

XSS, CSRF
https://velog.io/@haizel/XSS%EC%99%80CSRF-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EB%B0%8F-%EB%8C%80%EC%9D%91-%EB%B0%A9%EC%95%88