[Network/네트워크] CS 질문 정리

728x90

🙋‍♀️ 공부하는 과정에 있습니다. 틀린 부분에 대한 지적은 언제든 환영합니다.

OSI 7 계층과 TCP/IP 4계층

Q. OSI 7계층과 TCP/IP 4계층의 차이점에 대해서 설명해보세요.

간결함이 큰 차이
TCP/IP는 구분이 모호한 전송-세션-표현 등을 그룹화한 이점이 있습니다.
반대로, SSL과 같은 HTTPS 통신을 설명하려면 OSI 7계층이 좀 더 유리할 수 있습니다.

TCP/IP는 실제 인터넷 통신을 반영하기에 현실적이며, 인터넷 개발 이후 계속 표준화되어 신뢰성이 우수합니다.
반면, OSI 모델은 계층을 정확히 구분한 표준이긴 하나 실질적으로 적용되는 예시가 적어 신뢰성이 보장되지 못 합니다.

Q. OSI 7계층과 그 존재이유, TCP/IP 계층에 대해 설명해보세요.

OSI계층은 네트워크 통신을 구성하는 요소들 7개의 계층로 표준화 한 것입니다.
표준화 한것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기에 용이해집니다.
실제로 대부분 사용하는 것은 TCP/IP 4계층입니다.

Q. 웹 서버 소프트웨어(Apache, Nginx)는 OSI 7계층 중 어디서 작동하는지 설명해보세요.

웹 서버는 HTTP 프로토콜을 사용해 html 데이터를 클라이언트에 제공하는 서버입니다.
HTTP 프로토콜은 OSI 7계층인 Application Layer에 위치해 있습니다.
브라우저와 서버 사이에 정보를 주고받기 위해 사용하며, Apache, Nginx는 웹 서버 중의 하나이므로 Applicaion 계층에서 작동합니다.

Q. 웹 서버 소프트웨어(Apache, Nginx)의 서버 간 라우팅 기능은 OSI 7계층 중 어디서 작동하는지 설명해보세요.

라우터는 다른 네트워크와 통신하기 위해 사용하는 장치로, 현재의 네트워크에서 다른 네트워크로 패킷을 전송합니다.
따라서 서버 간 라우팅 기능은 네트워크 계층에서 동작합니다.

쿠키와 세션

Q. 세션을 사용하면 좋은데 왜 쿠키를 사용할까요?

세션은 서버에 저장된다. 서버의 자원을 사용하기 때문에 한계가 있고, 이로 인해 속도가 느려질 수 있습니다.
자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행하여 사용하면 서버 자원의 낭비를 방지하고 웹 사이트의 속도를 높일 수 있습니다.

Q. 쿠키와 세션의 차이

Q. 요청이 많이 몰렸을 때, 어떻게 처리하는 것이 좋을까요?

세션으로 처리하는 것이 좋습니다.
세션은 서버 측에서 클라이언트의 정보를 저장하는 방식입니다. 클라이언트가 서버에 접속하면 서버는 세션 ID를 생성하고 이를 쿠키에 저장하여 클라이언트에게 전송합니다. 클라이언트는 이 세션 ID를 이용하여 서버와 통신합니다. 세션은 클라이언트와 서버 간의 통신에서 생성되고, 서버에서 관리되므로 보안성이 높습니다. 또한, 세션ID만 보내기 때문에 세션의 크기가 커도 네트워크 부하가 거의 없습니다.

Q. 쿠키와 세션/ 캐시의 차이점

쿠키와 세션은 정보를 저장하는데에 사용되며, 사용자 인증을 도와줍니다.캐시는 웹 페이지의 구성요소를 저장하여 웹 페이지가 빠르게 렌더링 될 수 있도록 돕습니다.

Q. 세션기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.

세션 기반 인증 : 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 Stateful한 구조를 가짐
토큰 기반 인증 : 상태 정보를 서버에 저장하지 않으므로 Stateless한 구조를 가짐

Stateful한 세션 기반 인증을 사용하게 되면, 서버에 부담이 상대적으로 많이 가기 때문에 확장성이 낮습니다.
또한 해커가 훔친 쿠키를 이용하여 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없습니다. (세션 하이재킹 공격)

= 단일 도메인 : 세션 기반 인증 / 아니면 토큰 기반 인증
세션을 관리할 때 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어있기 때문에 여러 도메인에서 관리하는 것은 어려움(CORS문제)

Q. JWT의 구조에 대해서 설명해주세요.

Header, Payload, Signature로 이루어져 있습니다.

Q. 쿠키와 JWT의 차이점

가장 큰 차이점은 '보안'입니다. 쿠키는 전송하는 도중에 도난당할 위험이 있습니다. JWT는 서명으로 인증되며, 토큰을 변조하려면 서명을 변경해야 하므로 쿠키보다 안전합니다.

DNS와 웹 통신 흐름

Q. 웹 통신의 큰 흐름

사용자가 웹 브라우저에 주소창을 친다.
브라우저는 캐싱된 DNS 기록을 통해 대응되는 ip 주소가 있는지 확인한다.
요청한 URL 캐시가 없다면 ISP의 DNS 서버는 IP주소를 찾기 위하여 DNS query를 시작한다.
DNS가 웹 브라우저에게 찾는 사이트의 IP주소를 응답한다
IP주소를 받으면 TCP 통신을 시작한다(3-way hankshake)
HTTP 프로토콜인 GET요청을 통해 서버에게 웹 페이지를 요구한다.
웹 어플리케이션 서버(WAS)와 데이터 베이스에서 우선 웹 페이지 작업처리를 한다
- 웹 서버 : 정적인 컨텐츠(HTML, CSS, IMAGES 등)를 요청 받아 처리하여 제공하는 서버
- WAS : 동적인 컨텐츠(JSP, ASP, PHP 등)를 요청받아 처리하여 제공하는 서버, 주로 DB서버와 함께 사용
WAS에서의 작업 처리 결과들을 웹 서버로 전송한다
웹 서버는 웹 브라우저에게 html 문서 결과를 응답한다
웹브라우저는 html 컨텐츠를 표시한다

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

Domain Name System
도메인 이름과 IP 주소를 저장하고 있는 분산 데이터 베이스로 웹사이트를 위한 주소록 같은 개념입니다.
DNS는 브라우저가 인터넷 자원을 로드할 수 있도록 도메인 이름을 IP주소로 변환해줍니다.

Q. URL과 URI의 차이점

URI : 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스
URL : 흔히 웹주소라고 불림, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약

Q. 도메인과 URL의 차이점

웹 주소인 URL에는 도메인 이름과 전송 프로토콜 및 경로등의 정보가 포함되어 있습니다.
도메인 : 해당 서버의 주소
URL : 해당 서버의 주소 + 하위 디렉토리까지 포함하는 의미

Q. DNS의 경우 도메인 이름 구조 기반의 검색과정

'www.google.com' 주소에 대해 검색할 때,

DNS recursor가 루트 DNS 서버에 요청
com 도메인 TLS 서버로 리다이렉트
google.com 책임 DNS 서버로 리다이렉트
최종적으로 DNS기록에서 'www.google.com' 에 매칭되는 IP주소 찾기
찾은 주소를 DNS recursor로 보내기

Q. 공인IP와 사설IP차이

공인 IP
- 전세계에서 유일한 IP로 ISP(인터넷 서비스 공급자)가 제공하는 IP주소
- 외부에 공개되어 있기 때문에 인터넷에 연결된 다른 장비로부터 접근 가능
- 방화벽 같은 보안 설정 필요
사설 IP
- 어떤 네트워크 안에서 사용되는 IP주소
- IPv4의 부족으로 인해 모든 네트워크가 공인 IP를 사용하는 것이 불가능하기 때문에 네트워크 라우터를 통해 할당받는 가상의 주소
- 별도의 설정없이 외부 접근 불가

HTTP

Q. HTTP 프로토콜이란?

서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜
애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동합니다.
Method, Path, Version, Header, Body 등으로 구성됩니다.

Q. HTTP 메소드의 멱등성이란?

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다.

Q. HTTP와 HTTPS의 차이

HTTP는 HyperText Transfer Protocol의 약자
사용자 웹 브라우저가 웹 서버에 HTML같은 문서를 요청할 때의 규칙입니다.
HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있습니다.
HTTP + 암호화 = HTTPS
HTTPS는 암호화/복호화 하는 과정 때문에 비교적 속도가 느리고, 인증서 발급과 유지하기 위한 추가 비용이 발생합니다.
개인 정보와 같은 민감한 데이터를 주고받아야한다면 HTTPS를 이용해야하지만, 단순 정보 조회만 처리하고 있다면 HTTP를 사용합니다.

Q. HTTPS에 대해서 설명하고 SSL(TLS) Handshake에 대해서 설명해보세요.

HTTPS는 암호화된 네트워크 프로토콜이고 주고 받는 패킷 내 데이터가 암호화 되어있어 안전합니다.
이를 사용하기 위해서는 인증기관(CA)로 부터 SSL 인증서를 받아야합니다.
SSL Handshake는 송신자와 수신자가 암호화된 데이터를 교환하기 위한 일련의 협상 과정을 의미합니다.
협상과정에는 SSL 인증서 전달, 대칭키(비밀키) 전달, 암호화 알고리즘 결정, SSL/TLS 프로토콜 결정 등이 포함됩니다.
SSL 통신 원리
1. 클라이언트가 서버에 접속하면 서버 인증서를 전송받습니다.
2. 클라이언트는 받은 서버 인증서를 분석하여 신뢰할 수 있는 인증서인지 검토 후, 서버의 공개 키를 추출합니다.
3. 클라이언트가 세션키로 사용할 임의의 메세지를 서버의 공개키로 암호화하여 서버에 전송합니다.
4. 서버에서는 자신의 개인키로 세션키를 복호화하여 그 키를 사용하여 대칭키 암호방식으로 메시지를 암호화하여 클라이언트와 통신하게 됩니다.

Q. HTTP1 vs HTTP2

HTTP1의 문제점
- HOL(Head Of Line) Blocking : 컴퓨터 네트워킹에서 패킷 대기열이 존재 할 때, 앞선(Head) 패킷이 지연될 때 발생하는 성능 저하 현상
- RTT(Round Trip Time) 증가 (양방향 지연) : 패킷 왕복 시간의 지연 발생
- 헤더 크기의 비대 : 쿠키 등과 같은 메타데이터에 의해 헤더가 비대해짐
HTTP2의 해결법
SPDY : 2010년 전반기에 구글에서 구현한 프로토콜, 웹 페이지 로드 대기 시간을 줄이기 위해 나옴
- 이진 프로토콜(binary) :
  - HTTP/1.1은 텍스트 기반 프로토콜로 아스키코드로 작성, 읽기는 편하지만 데이터가 커진다.
  - HTTP/2는 데이터를 바이너리로 변환해서 전송하기 때문에 파싱이 더 빠르고, 오류 발생 가능성이 낮다.
- 응답 다중화(Multiplexed Streams) :
  - TCP 하나의 연결 내에서 하나의 요청을 처리할 수 있었고 요청에 대한 응답이 순차적으로 처리되어야 했던 것을 해결
  - 하나의 TCP 연결에 여러 개의 요청을 처리할 수 있는데 이것은 스트림(stream), 메세지(message), 프레임(frame)이라는 단위로 세분화했기 때문
- Stream Prioritization : 리소스간 의존관계(우선순위)를 설정하여 브라우저의 렌더링이 늦어지는 문제를 방지
- HTTP 헤더 데이터 압축(Header Data Compression) :
  - 이전 Header의 내용과 중복되는 필드를 재전송 하지 않도록 하여, 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축
  - 변경된 부분만 다시 보내는 허프만 코딩(Huffman Coding) 기법을 사용하는 HPACK이라는 Header 압축방식을 이용
- Server Push :
  - 클라이언트의 요청을 예상하여 클라이언트 캐쉬에 요청할 것 같은 데이터(리소스)를 미리 넣어둠
  - HTML 문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음
  - ex) 기존에는 HTML과 css 모두 요청해야 받을 수 있었다면 HTTP/2에서는 HTML을 요청하고 응답할 때 서버가 css 파일도 푸시하여 먼저 줄 수 있음

Q. 대칭키와 비대칭키

대칭키 : 하나의 키로 데이터를 암호화하고 복호화, 키가 노출되면 보안에 치명적, 비용이 적게 듦
비대칭키 : 공개 키와 개인 키로 암호화 및 복호화 수행, 개인 키는 비밀 키 혹은 비공개 키라고도 불립니다. 보안성은 좋지만 구현이 어렵고 속도가 느림

Q. HTTP의 비연결성을 해결하기 위한 방법

HTTP의 비연결성은 네트워크 자원의 효율성을 높이기는 하지만, 클라이언트와 서버 간의 상태 정보를 유지하지 않기 때문에 상태관리가 어렵다는 단점이 존재합니다.
이는 HTTP/1.1에서 지원하는 keep-alive라는 기능을 통해 해결할 수 있습니다. keep-alive는 하나의 TCP 연결을 유지하여 여러 요청 및 응답을 처리할 수 있도록 하는 기능입니다. 즉, 한 번의 TCP 연결로 여러 요청을 보낼 수 있으므로 네트워크 지연 및 연결 설정 오버헤드를 줄일 수 있습니다.
HTTP/1.1에서는 keep-alive가 기본적으로 활성화되어 있으며, 일정 시간 동안 비활성화된 연결을 종료하는 keep-alive 타임아웃 기능도 제공합니다. 또한, HTTP/2부터는 기본적으로 모든 요청과 응답이 동일한 TCP 연결을 통해 처리되므로 keep-alive 기능이 더욱 발전된 형태로 구현되었습니다.
따라서, HTTP의 비연결성을 해결하려면 keep-alive 기능을 활성화하여 하나의 TCP 연결로 여러 요청을 처리하도록 하면 됩니다.

Q. HTTP의 무상태를 해결하기 위한 방법

HTTP의 무상태성은 클라이언트와 서버 간의 상태 정보를 유지하지 않는 것을 의미합니다. 이는 서버 측에서 클라이언트의 이전 요청 상태를 파악하지 못하고, 각각의 요청을 독립적으로 처리하는 것을 의미합니다.
이를 해결하기 위해서는 상태 정보를 유지하는 방법이 필요합니다.
쿠키는 클라이언트에 저장되는 작은 데이터 조각으로, 서버에서 생성된 값을 클라이언트에 저장하여 다음 요청 시에도 해당 값이 유지되도록 합니다. 이를 통해 클라이언트의 상태를 서버에서 유지하지 않아도 되므로, 무상태 특징을 보완할 수 있습니다.
세션은 클라이언트와 서버 간의 일시적인 상태를 유지하기 위한 방법입니다. 클라이언트가 서버에 요청을 보내면, 서버는 해당 클라이언트에 대한 고유한 세션 ID를 생성하여 저장합니다. 이후 클라이언트는 이 세션 ID를 쿠키나 URL 매개변수 등을 통해 서버에 전달하면, 서버는 해당 클라이언트의 세션 정보를 찾아 사용합니다. 이를 통해 서버는 클라이언트의 상태를 일시적으로 유지하면서, 클라이언트와의 연결을 끊을 수 있으므로, 무상태 특징을 보완할 수 있습니다.

Q. HTTP 0.9 버전의 가장 큰 특징

HTTP 0.9는 HTTP 프로토콜의 초기 버전으로 매우 단순한 형식을 가지고 있습니다.
요청 메시지는 HTTP 메서드와 요청 URI만 포함하고 있으며, 헤더 등의 추가 정보는 제공되지 않습니다.
응답 메시지 또한 단순한 HTML 문서만 포함하고 있습니다.

Q. TTL이란?

TTL은 Time To Live의 약자로, 네트워크에서 데이터 패킷이나 DNS 레코드 등이 유효한 시간을 나타내는 값입니다. TTL 값은 해당 데이터가 네트워크에서 전달되는 동안 경유하는 라우터의 수나 시간에 따라 감소하며, TTL 값이 0이 되면 해당 데이터는 폐기됩니다.
데이터 패킷의 경우, TTL은 IP 프로토콜에서 사용되며, 각 라우터에서 패킷이 전달될 때마다 TTL 값을 1씩 감소시킵니다. 따라서, TTL 값이 출발지에서부터 목적지까지 패킷이 전달되는 최대 횟수를 제한하며, 패킷이 무한히 네트워크를 돌아다니는 것을 방지합니다.
DNS 레코드의 경우, TTL은 DNS 서버에서 캐시에 저장되는 시간을 나타내며, TTL 값이 만료되면 해당 DNS 레코드는 더 이상 사용되지 않습니다. 이를 통해 DNS 캐시가 오래된 정보를 계속 사용하는 것을 방지하고, 최신 정보를 유지할 수 있습니다.
따라서, TTL은 네트워크에서 데이터의 유효 기간을 제한하고, 불필요한 데이터 전송을 방지하며, 최신 정보를 유지하는 데에 중요한 역할을 합니다

Q. www.google.com을 주소창에 쳤을 때 화면이 나오기까지의 과정을 네트워크 관점으로 설명해 주세요.

Q. HTTP status code에 대해서 설명해주세요.

Q. HTTP/3이 왜 나오게 되었는지, 그에 따른 QUIC부분에 대해서 TCP의 문제점을 어떻게 해결했는지 설명해주세요.

TCP와 UDP

Q. TCP와 UDP의 특징과 차이점

Q. UDP는 항상 신뢰성을 보장하지 않나요?

UDP도 신뢰성을 UDP자체에서 보장하지 않는 것 뿐이지, 개발자가 직접 신뢰성을 보장하도록 할 수 있음
HTTP/3의 경우, UDP 기반의 QUIC이라는 프로토콜 사용
UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있음

Q. Connection Timeout과 Read Timeout의 차이점

Connection Timeout : 초기 연결을 할 때에 대한 시간 초과가 난 상황
Read Timeout : 데이터를 읽는 동안 대기하는 시간 초과, 서버에서 데이터를 받아오는데 시간초과가 난 경우

Connection Time은 클라이언트가 서버에 접속하기 위해 걸리는 시간을 의미합니다. 클라이언트가 서버와 연결하는 과정에서 발생하는 네트워크 지연, TCP/IP 핸드셰이크, SSL 핸드셰이크 등이 포함됩니다. Connection Time은 서버 응답 시간(Response Time)과는 다르며, 단순히 클라이언트와 서버 간의 연결 설정 시간을 측정합니다.
Read Time은 클라이언트가 서버로부터 데이터를 읽어오는 데 걸리는 시간을 의미합니다. 이는 서버가 클라이언트 요청에 대한 응답을 보내는 시간, 데이터 전송 속도, 클라이언트가 데이터를 처리하는 시간 등에 의해 영향을 받습니다.
Connection Time과 Read Time은 서로 다른 측면에서 네트워크 성능을 측정하며, 둘 다 중요한 지표입니다. Connection Time이 길다면 서버와의 연결 설정에 문제가 있을 수 있으며, Read Time이 길다면 서버의 처리 속도가 느린 것일 수도 있습니다. 따라서, 성능 개선을 위해 이러한 지표를 모니터링하고 개선하는 것이 필요합니다.

Q. TCP 3,4 way handshake에 대해 설명해보세요.

TCP 3way handshake는 가상회선을 수립하는 단계입니다.
클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정입니다. SYN, ACK 패킷을 주고받으며, 임의의 난수로 SYN 플래그를 전송하고, ACK 플래그에는 1을 더한값을 전송합니다.
정확한 순서는 SYN(n) -> ACK(n + 1), SYN(m) -> ACK(m + 1) 순으로 일어납니다.

TCP 4way handshake는 TCP연결을 해제하는 단계로, 클라이언트는 서버에게 연결해제를 통지하고 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 최종적으로 연결이 해제됩니다.
단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트 측에서는 일정시간 대기하는 TIME_WAIT 상태가 있는데, 혹시나 패킷이 나중에 도착할 수 있기 때문입니다.

Q. 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?

이러한 현상에 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정시간(Default: 240sec)동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT 과정)

Q. TCP의 연결 성립 과정과 연결 해제 과정의 단계수가 차이 나는 이유는?

Client가 데이터 전송을 마쳤다고 해도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후 자신도 FIN메세지를 보내기 때문이다.

Q. 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유는?

Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다.
따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다.
Server측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다.
이런 문제의 발생 가능성을 낮추기 위해 ISN을 난수로 설정한다.

Q. TIME WAIT의 존재 이유

TIME WAIT은 소켓이 바로 소멸되지 않고 일정 시간 유지되는 상태입니다.
지연 패킷이나 두장치간의 접속 오류같은 의도치 않은 에러로 인해 연결이 데드락에 빠지는 문제점을 방지하는데 사용됩니다.

Q. TCP 통신에서 지연 패킷이 발생했을 때 서버는 이것을 어떻게 처리하나요?

재전송 타이머 :
- 재전송 타이머를 실행합니다. 이 타이머는 일정 시간이 지나면 재전송을 시도하도록 TCP에게 알려줍니다.
빠른 재전송 :
- 빠른 재전송은 일정 시간 내에 중복되는 ACK을 수신하면 재전송을 시도합니다.
혼잡 제어 :
- 네트워크 혼잡을 감지하고, 데이터 전송 속도를 줄여 혼잡을 줄이는 혼잡 제어(Congestion Control) 알고리즘을 사용합니다. 이 알고리즘은 패킷 손실 또는 ACK 지연을 통해 혼잡 상황을 감지하고, 데이터 전송 속도를 조절하여 혼잡을 해소합니다.
수신 윈도우 조절 :
- TCP는 수신 윈도우(Receive Window)를 사용하여 수신 측의 처리 속도를 고려하여 데이터를 전송합니다. 따라서, 패킷이 지연되면, 수신 윈도우의 크기가 조절되어 송신 측의 전송 속도가 조절됩니다.

SOP와 CORS

Q. SOP의 개념은 무엇이고, CORS가 나오게 된 배경과 개념을 설명해주세요.

SOP(Same-Origin Policy)는 웹 브라우저의 보안 기능 중 하나로, 다른 출처(Origin)에서 로드된 문서나 스크립트에서 자원을 공유하는 것을 제한하는 정책입니다.
- 출처란 도메인, 포트, 프로토콜의 조합으로 구성되며, 이 조합이 다르면 다른 출처로 판단합니다.
하지만, 이러한 SOP의 제한 때문에 Ajax나 웹 API를 이용해 다른 출처의 데이터를 가져오는 것이 어렵게 되어, CORS(Cross-Origin Resource Sharing)라는 기술이 등장하게 되었습니다. CORS는 SOP의 제한을 우회하여, 다른 출처의 리소스를 가져오는 것을 허용하는 메커니즘입니다.

Q. CORS란 무엇이며 이것에 대하여 설명해보세요.

CORS는 서로 다른 도메인간에 자원을 공유하는 것
대개는 프론트엔드 개발시에 로컬에서 API 서버에 요청을 보낼 때 흔하게 발생
프론트의 경우에는 Request Header에 CORS 관련 옵션을 넣어주고, 서버의 경우에는 Response Header에 프론트의 요청을 허용한다는 내용을 넣어주면 됩니다.
preflight request는 실제 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다. OPTIONS 메서드로 요청하며 CORS를 허용하는지 확인합니다. CORS가 허용된 웹서버라면 사용 가능한 리소스를 헤더에 담아 응답합니다.

Q. 왜 preflight 요청을 해야할까?

프리플라이트 요청을 통해 서버는 요청이 실행되기 전에 검사하고 허용 여부를 표시할 기회를 얻을 수 있기 때문이다.
서버가 다른 출처에서 허용하지 않는 특정 요청을 차단함으로써 서버를 보호
서버는 개발될 때 허용하는 요청 및 헤더의 종류를 변경할 수 있음

Q. 간단한 요청과 인증된 요청에서 Access-Control-Allow-Origin의 차이점은 무엇인가요?

Access-Control-Allow-Origin 헤더가 추가되면 해당 도메인에서 자원 접근이 가능해집니다. 이 헤더는 CORS에서 도메인 간 리소스 공유를 허용하기 위한 것입니다.
간단한 요청(Simple Request)은 GET, HEAD, POST 중에 하나의 메서드를 사용하고, 추가적인 요청 헤더를 가지지 않아야 합니다. 이 경우, 서버에서는 요청 헤더 중 Origin 헤더를 확인하고, 이 헤더에 대해 허용된 도메인이면 응답에 Access-Control-Allow-Origin 헤더를 추가합니다. 따라서 간단한 요청에서는 서버 측에서 인증 처리를 하지 않고도 다른 도메인에서 자원 접근이 가능합니다.
인증된 요청(Authenticated Request)은 위 조건을 만족하지 않는 경우입니다. 예를 들어 요청 메서드가 PUT이거나 DELETE, Content-Type이 application/json 등의 요청 헤더를 가지는 경우입니다. 이 경우, 서버에서는 먼저 해당 요청이 인증되었는지 확인하고, 인증이 되었을 경우에만 Access-Control-Allow-Origin 헤더를 응답에 추가합니다. 따라서 인증된 요청에서는 서버 측에서 인증 처리를 거친 후에 다른 도메인에서 자원 접근이 가능해집니다.

REST API

Q. HTTP의 4가지 method를 설명해주세요.

GET :
- 서버에 존재하는 정보를 요청
- 일반적으로 Request Body는 입력하지 않음
- 레거시 시스템의 경우 요청을 받아들이지 않을 수 있음
- 캐싱을 수행하기 때문에 캐싱되지 않는 요청은 GET 요청이 맞지 않을 수 있음
POST :
- 서버에 정보를 생성하는 것을 요청
- 예전 HTTP 통신은 POST 요청으로 데이터 삭제, 수정도 form요청으로 같이 수행함
- 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않음
- 보통 Request Body에 요청하는 데이터를 담아 전송합니다.
PUT : 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성합니다. CRUD로 따지면 C,U입니다.
PATCH : 서버에 존재하는 데이터를 일부 수정합니다. CRUD로 따지면 U입니다.

Q. GET과 POST의 차이

Q. PUT과 PATCH의 차이

PUT과 PATCH 모두 HTTP 메소드 중 데이터 수정에 사용되는 메소드입니다.
PUT은 리소스 전체를 교체하는 데 사용되며, PATCH는 리소스의 일부분을 수정하는 데 사용됩니다. PUT은 대체 작업이며, PATCH는 변경 작업이라고 할 수 있습니다. 이러한 차이점 때문에 PUT은 전체 업데이트 작업에 사용되고, PATCH는 부분적인 업데이트 작업에 사용됩니다.

Q. REST method의 5가지 중 멱등성을 보장하는 메소드는 무엇이고 이유는 무엇인가요?

REST API의 5가지 메소드 중에서 멱등성(idempotence)을 보장하는 메소드는 GET, PUT, DELETE입니다.
멱등성은 같은 요청을 여러 번 보내도 항상 같은 결과가 나오는 특성을 말합니다. 멱등성이 보장되면, 클라이언트가 네트워크 문제 등으로 인해 요청을 다시 보낼 때, 서버에서 중복된 작업을 수행하지 않고도 안전하게 요청을 처리할 수 있습니다.

POST와 PATCH 메소드는 멱등성을 보장하지 않습니다. POST는 새로운 리소스를 생성하는 메소드로, 같은 요청을 여러 번 보내면 서로 다른 리소스를 생성하게 됩니다. PATCH는 리소스의 일부를 수정하는 메소드로, 같은 요청을 여러 번 보내면 수정 작업이 반복 수행될 수 있습니다.

Q. REST와 RESTful의 정의와 그에 대한 설명해 주세요.

REST(Representational State Transfer)는 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일입니다. REST는 클라이언트와 서버 간 통신 방식을 규정하며, 자원을 식별하고 상태를 전송하는 방식으로 동작합니다. REST는 HTTP 프로토콜을 기반으로 하며, 자원(Resource), 행위(Verb), 표현(Representations)으로 구성됩니다.
RESTful은 REST를 따르는 웹 서비스를 구현하는 방식을 말합니다. RESTful 웹 서비스는 REST의 원칙을 따르며, HTTP 프로토콜을 이용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행합니다. RESTful 웹 서비스는 URI(Uniform Resource Identifier), HTTP 메소드, MIME 타입 등을 이용하여 자원을 식별하고, 상태를 전송합니다.

Q. RESTful 웹 서비스의 단점은 무엇인가요?

안티패턴으로 설계될 가능성이 높음
- REST API의 안티패턴: REST API의 특징을 이해하지 못하고 REST 사상에 어긋나는 패턴을 적용한 API들
  - ex) HTTP Method의 잘못된 사용 : Update, Delete 기능을 POST로 대체하여 사용
  - HTTP Response code 2,3개만 활용
표준규약이 없음
RDBMS의 표현에 적합하지 않음
- REST API는 리소스를 표현할 때 나열하기 용이한 형태(Json, XML 등)를 사용해서 적합하지 않을 수있음

Q. RESTful이란 무엇이며, 이것에 대해 아는대로 설명해보세요.

REST 원칙
1) HTTP URI를 통해 자원(Resource)를 명시하고
2) HTTP Method(POST,GET,PUT,DELETE)를 통해
3) 해당 자원(URI)에 대한 CRUD OPERATION을 적용함을 의미합니다.
이러한 규칙을 지켜 설계된 API는 REST API라고 부릅니다.

사람이 읽을 수 있는 API라는 것이 특징입니다.
HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영합니다. 별도의 인프라 구축이 필요없습니다.

단점으로는 명확한 표준이 존재하지 않는다는 점, RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점
REST API가 분산환경에 적합하지 않다는 점이 있습니다.(멱등성을 보장하기 힘들기 때문)

프록시 서버

Q. 프록시 서버가 필요한 이유

분산처리( 캐시사용, 로드 밸런싱)를 통한 전송 시간 절약, 외부 트래픽을 줄임으로써 병목현상 방지
요청과 응답 필터링을 통해 보안을 강화할 수 있음 방화벽으로 사용하기도 함

Q. 프록시 서버 사용 시 페이지의 내용과 데이터 값이 계속 바뀌면?

실제 서버에서 응답할 때 캐시 만료 기한을 설정
프록시 서버로 사용자가 요청했을 때 요청한 시각이 프록시에서 다운받은 시간에서 만료한 기간 이내면 프록시에서 다운로드 할 것이고, 그렇지 않으면 다시 실제 서버로 요청하게 됩니다.

Q. 프록시 서버를 설명하고, 사용 사례에 대해 설명해보세요.

프록시 서버란 서버 앞단에 둬서 캐싱, 로깅, 데이터 분석을 서버보다 먼저하는 서버
이를 통해 포트 번호를 바꿔서 사용자가 실제 서버의 포트에 접근하지 못하게 할 수 있으며 공격의 DDOS 공격을 차단하거나 CDN을 프록시 서버로 달아서 캐싱 처이를 용이하게 할 수 있습니다.
nginx로 Node.js로 이루어진 서버의 앞단에 둬서 버퍼 오버플로우를 해결하거나 CloudFlare를 둬서 캐싱, 로그 분석 등을 하는 사용 사레가 있습니다.

Q. VPN과 프록시의 차이는?

보안기능입니다.
VPN은 보안기능이 탑재되어 있지만 Proxy는 보안성이 취약한 단점이 있습니다.
VPN의 용도는 중간에 공용망을 사용하더라도 사설망처럼 이용하는 것이기 때문에 공용망에서도 암호화되어서 통신이 이루어집니다.라서 중간 정보를 탈취당할 염려가 적습니다.
Proxy는 공용으로 사용하고 있는 서버이기 때문에 보안성이 없다는 단점이 있습니다. 하지만 IP주소를 바꾸어 우회하는 목적으로 많이 사용하고 있으며 가치가 없는 정보를 편하게 이용하려고 한다면 Proxy를 이용하는 것도 괜찮은 방법입니다.

L4, L7 스위치, 로드밸런싱

Q. 로드밸런싱이란?

하나의 서버로 안정적으로 서비스를 제공하기 어려워 Scale Out 할 경우 클라이언트에게 다수의 서버 선택지를 주는것이 아닌 글로벌 서버 주소를 제공하고 요청받은 트래픽을 적절히 분산해주는 기술

Q. L4 로드밸런싱과 L7 로드밸런싱의 장단점?

L4 로드밸런싱의 경우 패킷 페이로드까지 접근하지 않아 속도가 빠르고 자원 효율이 좋으며 비용이 저렴하지만 세밀한 로드밸런싱이 어렵고 서버와의 4계층 연결이 끊어지지 않는 이상 장애를 판단하기 어렵습니다.

L7 로드밸런싱의 경우 비정상 트래픽을 판단할 수 있고 정교한 로드밸런싱이 가능하지만 비용이 크고 속도와 자원 효율성이 감소합니다.

Q. 로드밸런싱 알고리즘 중 라운드로빈 방식의 장단점?

패킷을 요청받은 각 서버에 순서대로 할당하기때문에 알고리즘이 간단합니다.
하지만 이경우 특정 서버에 장애가 발생해 성능이 저하될 경우 처리속도가 느려질 가능성이 있습니다.

Q. 로드밸런서의 개념과 프록시의 개념과 차이점

로드 밸런서(Load Balancer)와 프록시(Proxy)는 모두 네트워크에서 사용되는 중간 매개체입니다. 그러나 각각의 역할과 기능이 다릅니다.로드 밸런서는 여러 대의 서버에 대한 트래픽을 분산하여 처리할 수 있도록 도와주는 장치나 소프트웨어입니다. 이는 높은 가용성(High Availability)와 확장성(Scalability)을 제공하기 위해 사용됩니다. 로드 밸런서는 클라이언트 요청을 받아서 이를 여러 대의 서버에 분산시키는 역할을 수행합니다. 이는 서버의 부하를 분산시켜서 전체적인 성능을 향상시키고, 장애 발생 시 다른 서버로 요청을 전달하여 시스템의 가용성을 유지합니다.
반면, 프록시는 클라이언트와 서버 사이에서 동작하여 클라이언트가 직접 서버에 접근하는 것을 막고, 대신 프록시 서버를 통해 요청을 전달합니다. 이를 통해 클라이언트의 보안을 강화하고, 네트워크 속도를 향상시킬 수 있습니다. 또한, 프록시는 캐시를 사용하여 이전에 요청된 정보를 저장하고, 동일한 요청이 발생할 때 이를 즉시 제공함으로써 네트워크 대역폭을 절약할 수 있습니다.
따라서 로드 밸런서는 서버의 부하를 분산시키기 위해 사용되는 반면, 프록시는 클라이언트와 서버 사이에서 동작하여 네트워크 속도를 향상시키고, 보안을 강화하기 위해 사용됩니다