[기술면접] 2. 네트워크: CS 기술면접 대비 자료와 예상 문답

OSI 7계층이란?

1. 물리 계층: 데이터 전송을 위한 전기적, 물리적 매체를 제어합니다.
2. 데이터 링크 계층: 물리적 연결을 통해 데이터를 전송하며, 오류 검출 및 수정 기능을 제공합니다.
3. 네트워크 계층: IP 주소를 기반으로 데이터 패킷을 목적지까지 라우팅합니다.
4. 전송 계층: TCP/UDP 프로토콜을 통해 신뢰성 있는 데이터 전송과 오류 복구를 담당합니다.
5. 세션 계층: 통신 세션을 설정하고 관리하며, 세션 유지와 종료를 제어합니다.
6. 표현 계층: 데이터 형식을 변환(압축, 암호화)하고, 서로 다른 시스템 간 호환성을 보장합니다.
7. 응용 계층: 사용자와 직접 상호작용하는 애플리케이션의 서비스(예: HTTP, FTP)를 제공합니다.

예상 질문

• 전송 계층에서 TCP와 UDP의 차이점은 무엇인가요?
  • 답변: TCP는 연결 지향적이며 신뢰성 있는 데이터 전송을 보장하고, UDP는 비연결형으로 빠른 데이터 전송에 중점을 둡니다. TCP는 데이터의 순서와 신뢰성을 보장하지만 속도가 느리고, UDP는 속도가 빠르지만 데이터 전송의 신뢰성은 낮습니다.

심화 질문

• OSI 모델이 실제 네트워크 구현에서 어떻게 사용되나요?
  • 답변: OSI 모델은 네트워크 설계의 기본 개념을 제공하며, 실제 구현에서는 TCP/IP 모델이 널리 사용됩니다. OSI 모델은 네트워크 프로토콜과의 호환성을 위한 참조 모델로 자주 활용됩니다.

TCP/IP 4계층이란?

1. 네트워크 인터페이스 계층: 물리적 네트워크를 통해 데이터를 전송합니다.
2. 인터넷 계층: IP 주소를 사용해 데이터 패킷을 목적지로 라우팅하며, 경로 설정을 관리합니다.
3. 전송 계층: TCP 또는 UDP 프로토콜을 통해 데이터 전송의 신뢰성과 흐름을 제어합니다.
4. 응용 계층: HTTP, FTP 등 애플리케이션 프로토콜을 통해 네트워크 응용 프로그램을 지원합니다.

예상 질문

• TCP/IP의 전송 계층에서 흐름 제어가 어떻게 이루어지나요?
  • 답변: TCP는 송신자가 수신자의 네트워크 상태를 확인하여, 수신자가 처리할 수 있는 만큼의 데이터를 송신하는 흐름 제어 메커니즘을 지원합니다. 이를 통해 네트워크 혼잡을 줄이고 데이터 손실을 방지합니다.

심화 질문

• TCP/IP 모델의 인터넷 계층과 OSI 모델의 네트워크 계층 간의 차이점은 무엇인가요?
  • 답변: TCP/IP 인터넷 계층은 라우팅과 패킷 전달을 담당하며, OSI 모델의 네트워크 계층과 비슷한 역할을 하지만 TCP/IP 모델은 더 실무적인 접근을 강조합니다. 또한 TCP/IP는 여러 계층이 통합되어 있는 구조입니다.

DNS란 무엇인가?

DNS는 도메인 이름을 IP 주소로 변환하는 시스템입니다. 사용자가 기억하기 쉬운 도메인 이름을 입력하면, DNS가 해당 도메인에 맞는 IP 주소를 반환하여 네트워크 연결을 가능하게 합니다.

예상 질문

• DNS의 주요 구성 요소는 무엇인가요?
  • 답변: DNS는 도메인 이름을 IP 주소로 변환하는 시스템이며, 주요 구성 요소로는 도메인 네임스페이스, DNS 서버(루트, TLD, 권한 DNS), 레코드(A, CNAME, MX) 등이 있습니다.

심화 질문

• DNS 서버가 과부하를 겪을 때 어떤 현상이 발생할 수 있나요?
  • 답변: DNS 서버가 과부하 상태가 되면, 도메인 이름을 IP 주소로 변환하는 과정이 느려지거나 실패할 수 있으며, 이는 웹사이트 접속 지연이나 실패로 이어질 수 있습니다. 이를 방지하기 위해 DNS 캐싱과 부하 분산 기술이 사용됩니다.

도메인 이름으로 실제 IP를 어떻게 찾을 수 있는가?

사용자가 도메인 이름을 입력하면 먼저 로컬 DNS 서버에서 캐시를 확인합니다. 캐시가 없으면 루트 DNS 서버, TLD DNS 서버, 권한 있는 DNS 서버로 순차적으로 요청이 전송되고, 최종적으로 도메인의 IP 주소가 반환됩니다. 반환된 IP 주소는 로컬 DNS 서버와 클라이언트에 캐시되어 빠르게 연결이 가능합니다.

로컬 DNS 서버 -> 캐시 확인 -> (캐시가 없을 경우) 루트 DNS 서버, TLD DNS 서버, 권한 있는 DNS서버 순으로 요청 -> 도메인 IP 주소 반환

예상 질문

• DNS 요청의 과정에서 캐싱이란 무엇인가요?
  • 답변: DNS 캐싱은 최근 조회된 도메인의 IP 주소를 로컬 DNS 서버나 클라이언트가 저장하여, 같은 도메인에 대한 요청이 있을 때 빠르게 응답할 수 있도록 하는 메커니즘입니다. 이를 통해 요청 시간을 단축하고 서버 부하를 줄일 수 있습니다.

심화 질문

• DNS의 보안 문제와 그 해결 방안은 무엇인가요?
  • 답변: DNS는 DNS 스푸핑이나 캐시 포이즈닝 같은 공격에 취약할 수 있습니다. 이를 방지하기 위해 DNSSEC(DNS Security Extensions) 같은 기술을 사용해 데이터의 무결성과 인증을 보장하며, 보안 수준을 강화합니다.

TCP와 UDP의 차이

• TCP는 연결 지향형 프로토콜로, 신뢰성 있는 데이터 전송을 보장합니다. 데이터를 전송하기 전에 연결을 설정하고, 데이터가 올바르게 도착했는지 확인하며, 흐름 제어와 오류 검출을 지원합니다.
• UDP는 비연결형 프로토콜로, 빠른 데이터 전송이 가능하지만, 데이터 전송의 신뢰성은 보장하지 않습니다. 데이터 손실이나 순서가 뒤바뀌는 경우에도 추가적인 복구 과정이 없습니다.
• TCP는 주로 웹 브라우징, 이메일 등에서 사용되며, UDP는 스트리밍, 게임 등 빠른 전송이 중요한 애플리케이션에 사용됩니다.

예상 질문

• TCP와 UDP 중 게임 애플리케이션에 더 적합한 프로토콜은 무엇인가요?
  • 답변: UDP는 데이터 전송의 속도가 중요한 온라인 게임에서 주로 사용됩니다. 실시간 통신에서 일부 패킷 손실이 발생해도 전체 흐름에 큰 영향을 미치지 않기 때문에 빠른 전송이 중요한 상황에서 UDP가 적합합니다.

심화 질문

• TCP가 사용되는 경우와 UDP가 사용되는 경우를 비교해 주세요
  • 답변: TCP는 신뢰성 있는 데이터 전송이 중요한 웹 브라우징, 파일 전송, 이메일 서비스에 사용됩니다. 반면, UDP는 실시간성이 중요한 스트리밍, 온라인 게임, VoIP 통신에 적합합니다.

TCP 헤더

TCP 헤더는 여러 필드를 포함하여 데이터 전송을 관리합니다. 주요 필드로는 출발지 포트와 목적지 포트, 순서 번호, 확인 응답 번호, 헤더 길이, 플래그(ACK, SYN, FIN), 윈도 크기 등이 있습니다. 이러한 필드를 통해 TCP는 신뢰성 있는 연결을 설정하고 데이터를 효율적으로 전송하며, 오류가 발생할 경우 이를 처리할 수 있습니다.

예상 질문

• TCP 헤더의 플래그 필드에서 SYN, ACK, FIN의 역할은 무엇인가요?
  • 답변: SYN은 연결 설정을, ACK는 데이터 수신 확인을, FIN은 연결 종료를 의미합니다.

심화 질문

• TCP 헤더의 윈도 크기 필드의 역할은 무엇인가요?
  • 답변: 윈도 크기 필드는 송신자가 수신자에게 전송할 수 있는 데이터 양을 지정하여, 흐름 제어를 관리하는 데 사용됩니다.

MTU란 무엇인가?

MTU(Maximum Transmission Unit)는 네트워크 상에서 한 번에 전송할 수 있는 최대 데이터 패킷의 크기를 의미합니다. MTU는 데이터 전송의 효율성과 성능에 큰 영향을 미치며, 지나치게 큰 패킷을 전송하려고 할 경우 패킷을 분할하는 패킷 분할이 발생할 수 있습니다. MTU는 네트워크 환경에 따라 다르게 설정될 수 있습니다.

예상 질문

• MTU가 지나치게 크거나 작을 경우 어떤 문제가 발생할 수 있나요?
  • 답변: MTU가 지나치게 크면 패킷이 분할되어 성능이 저하될 수 있고, 지나치게 작으면 불필요한 오버헤드가 발생하여 네트워크 효율이 떨어집니다.

심화 질문

• MTU의 크기를 조정할 때 고려해야 할 요소는 무엇인가요?
  • 답변: MTU 크기를 조정할 때는 네트워크 대역폭, 전송 지연, 패킷 손실 가능성 등을 고려해야 하며, 적절한 크기를 설정해야 패킷 분할을 최소화하고 네트워크 성능을 최적화할 수 있습니다.

3-way hand shake, 4-way hand shake

• 3-way handshake는 TCP 연결을 설정하는 과정입니다. 먼저 클라이언트가 SYN 패킷을 서버에 전송해 연결 요청을 합니다. 서버는 이를 수락하며 SYN-ACK 패킷을 클라이언트에 응답하고, 마지막으로 클라이언트가 ACK 패킷을 서버로 전송해 연결이 완료됩니다.
• 4-way handshake는 TCP 연결을 종료하는 과정입니다. 먼저 클라이언트 또는 서버가 FIN 패킷을 보내 연결 종료를 요청하고, 상대방은 이를 수락하는 ACK 패킷을 전송합니다. 이후 상대방도 FIN 패킷을 보내고, 마지막으로 ACK 패킷을 보내며 연결이 종료됩니다.

예상 질문

• 3-way handshake 과정에서 SYN-ACK 패킷이 실패할 경우 어떻게 되나요?
  • 답변: SYN-ACK 패킷이 실패할 경우, 클라이언트는 일정 시간 동안 다시 SYN 패킷을 보내 연결을 재시도합니다. 연결이 성립되지 않으면 타임아웃이 발생합니다.

심화 질문

• 4-way handshake 과정에서 양방향의 FIN 패킷이 모두 필요한 이유는 무엇인가요?
  • 답변: 4-way handshake는 양쪽 모두 안전하게 연결을 종료할 수 있도록 보장하기 위한 과정입니다. 양방향의 FIN 패킷을 통해 각각의 송신자가 더 이상 보낼 데이터가 없음을 상대방에게 확인시킵니다.

HTTP 프로토콜이란?

HTTP(HyperText Transfer Protocol)는 클라이언트와 서버 간에 웹 페이지와 같은 리소스를 주고받기 위해 사용되는 애플리케이션 계층 프로토콜입니다. 주로 HTML 문서나 이미지, 동영상 등 다양한 데이터 형식을 전송하며, 비연결형이고 상태를 유지하지 않는 특성을 가집니다. 기본적으로 포트 80을 사용합니다.

예상 질문

• HTTP는 비연결형이라는 말의 의미는 무엇인가요?
  • 답변: 비연결형은 요청과 응답이 이루어진 후에 연결을 유지하지 않고 끊어지는 방식입니다. 각 요청은 독립적으로 처리되며, 이전 요청의 상태를 기억하지 않습니다.

심화 질문

• HTTP의 비연결형 특성을 극복하기 위한 방법에는 어떤 것이 있나요?
  • 답변: 쿠키와 세션을 사용해 HTTP의 상태를 유지하지 않는 특성을 보완할 수 있습니다. 이를 통해 사용자의 세션 정보를 서버에 저장하여 상태를 유지할 수 있습니다.

HTTP와 HTTPS의 차이

• HTTP는 데이터를 암호화하지 않고 전송하는 반면,
• HTTPS(HyperText Transfer Protocol Secure)는 SSL/TLS를 사용해 데이터를 암호화하여 전송합니다. HTTPS는 보안성을 강화하여 중간자 공격과 도청을 방지합니다. 기본적으로 포트 443을 사용합니다.

예상 질문

• HTTPS의 암호화 방식은 어떻게 이루어지나요?
  • 답변: HTTPS는 대칭키 암호화와 비대칭키 암호화를 결합하여 데이터를 안전하게 전송합니다. 클라이언트와 서버 간에 SSL/TLS 핸드셰이크가 이루어진 후, 대칭키를 사용해 데이터를 암호화합니다.

심화 질문

• HTTP와 HTTPS 간의 성능 차이는 왜 발생하나요?
  • 답변: HTTPS는 암호화 및 복호화 작업이 추가되기 때문에 HTTP에 비해 성능이 약간 저하될 수 있습니다. 그러나 하드웨어 가속과 최적화 기술을 통해 성능 차이를 줄일 수 있습니다.

HTTPS가 동작하는 방식

HTTPS는 SSL/TLS 프로토콜을 사용해 보안 통신을 설정합니다. 클라이언트가 서버에 접속을 시도하면, 서버는 SSL 인증서를 클라이언트에 전송합니다. 클라이언트는 인증서를 검증한 후, 대칭키를 생성하고 이를 서버의 공개키로 암호화하여 서버에 전송합니다. 이후 서버는 비대칭키로 대칭키를 복호화하고, 대칭키를 사용해 데이터를 암호화하여 안전하게 통신합니다.

예상 질문

• HTTPS에서 사용하는 SSL 인증서는 무엇인가요?
  • 답변: SSL 인증서는 서버의 신원을 검증하고, 서버와 클라이언트 간에 안전한 암호화된 통신을 설정하기 위해 사용됩니다. 인증 기관(CA)에 의해 발급됩니다.

심화 질문

• SSL/TLS 핸드셰이크 과정에서 어떤 정보가 오가나요?
  • 답변: SSL/TLS 핸드셰이크 과정에서는 클라이언트와 서버 간에 인증서 정보, 암호화 방식, 대칭키 교환 등의 정보가 교환됩니다. 이 과정을 통해 안전한 통신 채널이 설정됩니다.

HTTP 1.0과 1.1의 차이

• HTTP 1.0은 각 요청마다 새로운 연결을 설정하는 비연결형 프로토콜입니다.
• HTTP 1.1에서는 Persistent Connection(연결 지속)이 추가되어, 여러 요청을 하나의 연결로 처리할 수 있습니다. 또한 Chunked Transfer Encoding을 지원하여 콘텐츠 길이를 미리 알 수 없는 경우에도 데이터를 전송할 수 있습니다.

예상 질문

• HTTP 1.1에서 Keep-Alive는 어떤 역할을 하나요?
  • 답변: HTTP 1.1의 Keep-Alive 기능은 하나의 TCP 연결을 통해 여러 요청과 응답을 처리하여, 연결을 지속적으로 유지하고 성능을 향상시킵니다.

심화 질문

• HTTP 1.1에서 Chunked Transfer Encoding은 언제 사용되나요?
  • 답변: Chunked Transfer Encoding은 서버가 콘텐츠의 전체 길이를 미리 알 수 없을 때, 데이터를 조각으로 나누어 전송하는 방식입니다. 이는 스트리밍 콘텐츠 전송에 유용합니다.

HTTP2란?

HTTP2는 HTTP 1.1의 성능을 개선한 버전으로, 멀티플렉싱을 지원하여 하나의 연결에서 여러 요청과 응답을 동시에 처리할 수 있습니다. 헤더 압축을 통해 네트워크 대역폭 사용을 최적화하며, 서버 푸시 기능을 통해 클라이언트가 요청하기 전에 필요한 리소스를 미리 전송할 수 있습니다.

예상 질문

• HTTP2에서 멀티플렉싱은 어떻게 작동하나요?
  • 답변: 멀티플렉싱은 하나의 TCP 연결을 통해 여러 개의 요청과 응답을 동시에 전송할 수 있는 기능으로, 대기 시간을 줄이고 성능을 향상시킵니다.

심화 질문

• HTTP2에서 서버 푸시는 어떤 상황에서 유용하게 사용되나요?
  • 답변: 서버 푸시는 클라이언트가 특정 리소스를 요청하기 전에 미리 필요한 리소스를 전송하는 방식으로, 웹 페이지 로드 시간을 줄이는 데 유용합니다.

HTTP 헤더 구조

HTTP 헤더는 요청 및 응답에 대한 메타데이터를 포함하며, 헤더 필드와 값의 쌍으로 이루어집니다. 요청 헤더에는 Host, User-Agent, Accept 등의 필드가 포함되며, 응답 헤더에는 Content-Type, Content-Length, Set-Cookie 등의 필드가 포함됩니다.

예상 질문

• HTTP 요청 헤더와 응답 헤더의 차이점은 무엇인가요?
  • 답변: 요청 헤더는 클라이언트가 서버에 요청할 때 필요한 정보를 제공하고, 응답 헤더는 서버가 클라이언트에 응답할 때 전송되는 데이터를 설명하는 정보를 포함합니다.

심화 질문

• HTTP 헤더에서 캐시 관련 필드는 어떤 역할을 하나요?
  • 답변: Cache-Control, Expires 등의 필드는 브라우저 캐시를 제어하여, 클라이언트가 서버에 재요청하지 않고 캐시된 데이터를 사용할 수 있도록 설정합니다.

keep-alive 헤더

Keep-Alive 헤더는 HTTP 1.1에서 연결을 지속시켜 여러 요청을 하나의 TCP 연결로 처리하는 역할을 합니다. 이를 통해 연결 설정과 해제에 드는 오버헤드를 줄여 네트워크 성능을 개선할 수 있습니다.

예상 질문

• Keep-Alive 헤더의 기본적인 동작 방식은 무엇인가요?
  • 답변: Keep-Alive 헤더는 클라이언트와 서버 간의 연결을 일정 시간 유지하여, 여러 요청을 동일한 연결에서 처리하고, 불필요한 연결 재설정을 방지합니다.

심화 질문

• Keep-Alive 헤더의 한계는 무엇인가요?
  • 답변: Keep-Alive는 모든 요청을 동일한 연결로 처리하지만, 연결을 오래 유지할 경우 서버 리소스가 많이 사용될 수 있으며, 이를 적절히 관리하지 않으면 리소스 누수가 발생할 수 있습니다.

HTTP GET과 POST의 차이

• GET은 서버로부터 데이터를 요청하는 데 사용되며, 요청 데이터는 URL에 포함됩니다.
• POST는 서버에 데이터를 전송하는 데 사용되며, 요청 데이터는 본문(body)에 포함되어 전송됩니다.
• GET은 주로 조회 작업에, POST는 데이터 생성이나 수정에 사용됩니다.

예상 질문

• GET과 POST 중 보안이 더 좋은 방식은 무엇인가요?
  • 답변: POST가 GET보다 보안 측면에서 유리합니다. GET은 URL에 데이터가 포함되기 때문에 로그나 캐시에 남을 수 있지만, POST는 본문에 데이터를 포함하여 전송합니다.

심화 질문

• GET과 POST는 상태를 어떻게 다르게 처리하나요?
  • 답변: GET은 주로 멱등성을 가지며, 동일한 요청을 여러 번 보내도 같은 결과를 얻을 수 있습니다. 반면, POST는 멱등성이 없으며, 여러 번 요청하면 그에 따라 다른 결과를 얻을 수 있습니다.

쿠키와 세션의 차이

• 쿠키는 클라이언트 측에 저장되는 작은 데이터로, 서버가 클라이언트를 식별하는 데 사용됩니다.
• 세션은 서버 측에서 유지되며, 클라이언트의 상태를 추적하고 사용자 정보를 유지하는 데 사용됩니다.
• 쿠키는 브라우저에 저장되고, 세션은 서버에서 세션 ID를 통해 클라이언트를 식별합니다.

예상 질문

• 쿠키와 세션 중 보안이 더 중요한 것은 무엇인가요?
  • 답변: 세션이 서버 측에 저장되기 때문에, 쿠키보다 보안성이 더 높습니다. 그러나 세션이 유출될 경우에도 보안 위험이 발생할 수 있습니다.

심화 질문

• 쿠키가 만료되면 세션은 어떻게 처리되나요?
  • 답변: 쿠키가 만료되면 클라이언트는 더 이상 서버에 세션 ID를 전송할 수 없으므로, 서버 측에서 해당 세션을 무효화하게 됩니다.

세션 기반 인증과 토큰 기반 인증의 차이

세션 기반 인증은 사용자가 로그인하면 서버가 세션을 생성하고, 이 세션 정보를 서버 측에 저장한 후, 세션 ID를 클라이언트에 쿠키로 저장합니다. 이후 클라이언트는 요청할 때마다 세션 ID를 서버에 보내어, 서버가 이 ID를 통해 사용자의 세션 정보를 확인하고 인증을 처리합니다. 세션은 서버 메모리에 저장되기 때문에 서버 부하가 발생할 수 있으며, 확장성 측면에서 제한적일 수 있습니다.

토큰 기반 인증은 사용자가 로그인하면 서버가 JWT(JSON Web Token)와 같은 토큰을 발급하고, 클라이언트는 이 토큰을 저장하여 요청 시마다 HTTP 헤더에 포함시켜 보냅니다. 서버는 토큰을 검증하여 사용자를 인증합니다. 토큰은 무상태성을 가지며, 서버에 저장되지 않고 자체적으로 사용자 정보와 만료 시간 등을 포함하고 있어, 서버 확장성과 성능 측면에서 더 유리합니다.

주요 차이점

1. 저장 위치
   • 세션 기반 인증: 서버 측에서 세션을 저장하며, 클라이언트는 세션 ID를 쿠키로 저장합니다.
   • 토큰 기반 인증: 클라이언트 측에서 토큰을 저장하고 서버는 토큰을 별도로 저장하지 않습니다.
2. 확장성
   • 세션 기반 인증: 서버에서 세션을 유지하기 때문에 확장성이 떨어지며, 서버 간 세션 동기화가 필요할 수 있습니다.
   • 토큰 기반 인증: 서버 확장성이 뛰어나며, 무상태성 덕분에 서버 간 동기화가 필요 없습니다.
3. 상태 관리
   • 세션 기반 인증: 서버가 사용자 상태를 유지합니다.
   • 토큰 기반 인증: 무상태성을 가지며, 서버는 상태를 유지하지 않고 매 요청마다 토큰을 검증합니다.
4. 보안
   • 세션 기반 인증: 세션 탈취 위험이 있으며, 세션 ID가 유출될 경우 보안 문제가 발생할 수 있습니다.
   • 토큰 기반 인증: 토큰이 클라이언트 측에 저장되므로, 토큰 탈취에 대한 보안 대책이 필요하며, 주로 HTTPS를 사용해 안전성을 보장합니다.

예상 질문

• 세션 기반 인증에서 서버 부하가 발생하는 이유는 무엇인가요?
  • 답변: 세션 기반 인증에서는 서버가 각 사용자의 세션 정보를 메모리에 저장하여 인증을 처리하기 때문에, 많은 사용자가 접속할수록 서버 메모리가 소모되며 부하가 발생합니다.

심화 질문

• 토큰 기반 인증의 무상태성은 어떻게 확장성을 지원하나요?
  • 답변: 토큰 기반 인증에서는 서버가 상태를 저장하지 않고, 매 요청마다 토큰을 검증하여 인증을 처리하기 때문에, 여러 서버 간 세션 동기화가 필요하지 않으며 확장성이 뛰어납니다.

웹브라우저에서 서버로 요청 시 동작 방식

사용자가 웹 브라우저에 URL을 입력하면 브라우저는 먼저 DNS 서버에 도메인 이름을 전송해 IP 주소를 조회합니다. IP 주소가 확인되면 브라우저는 해당 서버로 HTTP 또는 HTTPS 요청을 보냅니다. 서버는 요청을 처리하고, HTML 또는 리소스를 브라우저로 응답합니다. 이후 브라우저는 받은 데이터를 렌더링 엔진을 통해 화면에 표시합니다.

DNS 서버에 도메인 이름 전송 -> IP 주소 조회 -> 해당 서버로 HTTP/HTTPS 요청 -> 서버에서 요청 처리 및 응답 -> 브라우저에서 렌더링

예상 질문

• 브라우저가 서버에 보낸 요청이 중간에서 가로채지지 않도록 보장하는 방법은 무엇인가요?
  • 답변: HTTPS를 사용하여 요청과 응답을 SSL/TLS로 암호화하면, 중간자 공격으로부터 데이터를 보호할 수 있습니다.

심화 질문

• DNS 조회 후 IP 주소를 찾을 수 없을 때 브라우저는 어떻게 처리하나요?
  • 답변: 브라우저는 DNS 조회 실패로 인해 서버에 연결할 수 없으며, 404 Not Found와 같은 에러 페이지를 사용자에게 표시합니다.

CORS란?

CORS(Cross-Origin Resource Sharing)는 다른 도메인에서 요청하는 리소스에 대해 브라우저가 접근을 허용하는 방식입니다. 기본적으로 웹 브라우저는 보안상의 이유로 동일 출처 정책(Same-Origin Policy)을 따르기 때문에, 다른 도메인의 요청을 차단하지만, CORS 헤더를 통해 이러한 제한을 완화할 수 있습니다.

예상 질문

• CORS가 필요한 이유는 무엇인가요?
  • 답변: CORS는 웹 보안을 강화하기 위한 방법으로, 허용된 도메인에서만 자원을 요청할 수 있도록 제한하여 중간자 공격이나 CSRF 공격을 방지합니다.

심화 질문

• CORS 오류가 발생하면 어떻게 해결할 수 있나요?
  • 답변: 서버 측에서 Access-Control-Allow-Origin 헤더를 설정하여 특정 도메인에 대한 접근 권한을 부여할 수 있습니다. 이를 통해 CORS 문제를 해결할 수 있습니다.

웹 서버와 웹 어플리케이션 서버(WAS)의 차이

• 웹 서버는 주로 정적 콘텐츠(HTML, 이미지, CSS 파일 등)를 클라이언트에 제공하는 역할을 하고,
• 웹 애플리케이션 서버(WAS)는 동적 콘텐츠(데이터베이스 질의 처리, 비즈니스 로직 실행 등)를 처리하는 역할을 합니다.
• 웹 서버는 요청을 전달하고, WAS는 실제 비즈니스 로직을 수행한 후, 결과를 웹 서버를 통해 클라이언트에 전달합니다.

예상 질문

• 웹 서버와 WAS를 따로 사용하는 이유는 무엇인가요?
  • 답변: 웹 서버와 WAS를 분리함으로써 시스템의 성능과 확장성을 향상시킬 수 있습니다. 웹 서버는 정적 콘텐츠를 빠르게 처리하고, WAS는 복잡한 비즈니스 로직을 담당합니다.

심화 질문

• 웹 서버와 WAS의 역할을 합칠 수 없는 이유는 무엇인가요?
  • 답변: 각각의 역할을 나누어 서버 부하를 분산시키고, 유지 보수와 확장성을 개선할 수 있기 때문에 역할 분리가 이루어집니다. 또한, 이로 인해 시스템의 안정성과 성능이 향상됩니다.

REST API

REST API(Representational State Transfer API)는 HTTP 프로토콜을 기반으로 하는 웹 서비스 설계 아키텍처입니다. HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 리소스를 처리하며, URL을 통해 리소스를 식별하고, 각 요청에 대해 적절한 HTTP 상태 코드로 응답합니다. REST는 무상태성을 가지며, 클라이언트와 서버 간의 통신이 독립적으로 이루어집니다.

예상 질문

• REST API에서 무상태성이란 무엇인가요?
  • 답변: 무상태성은 서버가 클라이언트의 이전 요청 상태를 기억하지 않으며, 각 요청이 독립적으로 처리된다는 의미입니다. 따라서 요청 시 필요한 모든 정보를 포함해야 합니다.

심화 질문

• REST API가 상태를 유지해야 하는 경우에는 어떻게 처리하나요?
  • 답변: 상태를 유지해야 하는 경우, 세션이나 토큰 기반 인증(예: JWT)을 사용해 클라이언트 상태를 추적할 수 있습니다.

API Gateway란?

API Gateway는 여러 마이크로서비스로 이루어진 시스템에서 클라이언트 요청을 중앙에서 관리하고 분배하는 역할을 하는 서버입니다. 인증, 로드 밸런싱, 속도 제한, 캐싱 등 다양한 기능을 수행하며, 클라이언트는 API Gateway를 통해 일관된 인터페이스로 여러 서비스를 호출할 수 있습니다.

예상 질문

• API Gateway의 주요 기능은 무엇인가요?
  • 답변: API Gateway는 요청 분배, 인증 및 권한 부여, 캐싱, 모니터링, 로깅 등의 기능을 수행하며, 여러 마이크로서비스 간의 통신을 중앙집중화합니다.

심화 질문

• API Gateway의 성능 저하가 발생할 경우 시스템에 미치는 영향은 무엇인가요?
  • 답변: API Gateway의 성능이 저하되면 모든 서비스의 응답 시간이 느려지며, 이는 전체 시스템의 병목 현상을 초래할 수 있습니다.

API Gateway가 다운되면 모든 API를 사용 못할지도 모르는데, 어떤 방안을 마련해야 할까?

API Gateway가 다운되면 모든 서비스가 중단될 수 있기 때문에, 이를 방지하기 위해 고가용성 아키텍처를 구축해야 합니다. 로드 밸런서를 사용해 여러 API Gateway 인스턴스에 트래픽을 분산시키고, 오토스케일링을 설정하여 트래픽 증가에 따라 인스턴스를 자동으로 추가할 수 있도록 해야 합니다. 또한 페일오버 기능을 통해 장애 발생 시 백업 서버로 전환할 수 있는 환경을 마련해야 합니다.

예상 질문

• API Gateway 장애를 대비하기 위한 핵심 요소는 무엇인가요?
  • 답변: 고가용성을 위해 다중 인스턴스 배포, 로드 밸런싱, 오토스케일링, 페일오버와 같은 방안이 필수적입니다.

심화 질문

• API Gateway에서 페일오버와 로드 밸런싱은 어떻게 다르게 작동하나요?
  • 답변: 로드 밸런싱은 정상적으로 작동하는 여러 인스턴스 간에 트래픽을 분산시키는 기능이며, 페일오버는 장애가 발생한 경우에만 백업 시스템으로 전환하는 기능입니다.

JWT 토큰이란?

• JWT(JSON Web Token)는 JSON 포맷을 사용하여 정보(Claims)를 안전하게 전송하는 방식입니다. JWT는 세 부분으로 나뉘며,
• 헤더(Header), 페이로드(Payload), 서명(Signature)로 구성됩니다. 각각의 부분은 Base64 URL-safe encoding으로 인코딩되며, 토큰은 주로 HTTP 헤더에 포함되어 전송됩니다.
• JWT는 서버에 상태를 저장하지 않고 사용자의 인증 상태를 유지할 수 있어, 무상태성을 갖는 토큰 기반 인증 방식입니다.

구성 요소

• Header: 토큰의 타입(JWT)과 사용된 암호화 알고리즘(예: HMAC, RSA)을 명시합니다.
• Payload: 사용자 정보와 같은 Claims가 들어가는 부분입니다. Claims에는 Registered Claims(표준 클레임), Public Claims(커스텀 클레임), Private Claims(특정 응용을 위한 클레임)가 포함될 수 있습니다.
• Signature: 헤더와 페이로드를 비밀키 또는 공개키로 서명하여 위변조를 방지하는 역할을 합니다.

JWT의 장점

• 무상태성: 서버가 상태를 저장하지 않기 때문에 확장성이 좋습니다.
• 범용성: 다양한 환경에서 사용 가능하며, OAuth와 같은 인증 시스템에 자주 사용됩니다.
• 안전성: 서버에서 서명된 토큰을 발급하므로, 서명이 검증되지 않으면 조작된 토큰을 감지할 수 있습니다.

예상 질문

• JWT는 왜 무상태성인가요?
  • 답변: JWT는 인증 상태를 토큰 자체에 포함하기 때문에, 서버에서 별도로 세션을 저장하지 않아도 요청마다 클라이언트가 토큰을 보내어 인증 상태를 유지할 수 있습니다.

심화 질문

• JWT 토큰이 탈취되었을 경우 어떻게 대처해야 하나요?
  • 답변: 토큰이 탈취되었을 경우 토큰의 만료 시간을 짧게 설정하거나, 토큰 무효화 기능을 사용하여 더 이상 사용할 수 없도록 해야 합니다. HTTPS를 사용하여 전송 중 탈취를 방지할 수 있습니다.

대칭키, 비대칭키 암호화 방식에 대해 설명

• 대칭키 암호화는 데이터를 암호화하고 복호화할 때 동일한 키를 사용하는 방식입니다. 암호화와 복호화에 사용하는 비밀키는 양쪽 모두에게 공유되며, 빠른 속도로 데이터를 암호화할 수 있는 장점이 있습니다. 하지만 키가 노출될 경우 보안 위험이 크며, 키를 안전하게 관리하는 것이 중요합니다. AES, DES 등이 대칭키 암호화 방식의 대표적인 알고리즘입니다.
• 비대칭키 암호화는 서로 다른 두 개의 키(공개키와 비밀키)를 사용하는 방식입니다. 공개키는 누구나 사용할 수 있고 데이터를 암호화할 수 있지만, 비밀키는 소유자만이 가지고 있으며 복호화할 수 있습니다. 이 방식은 키 교환이 안전하며, SSL/TLS 프로토콜에서 자주 사용됩니다. 대표적인 비대칭키 암호화 방식으로는 RSA와 ECDSA가 있습니다.

차이점

• 대칭키 암호화는 같은 키를 사용해 빠르게 암호화와 복호화를 수행하지만, 키의 안전한 공유가 중요합니다.
• 비대칭키 암호화는 키 공유의 보안 문제를 해결했지만, 상대적으로 암호화 속도가 느립니다.

예상 질문

• 대칭키 암호화의 단점은 무엇인가요?
  • 답변: 대칭키 암호화의 단점은 키 관리가 어렵다는 점입니다. 키가 노출되면 암호화된 데이터를 누구나 복호화할 수 있기 때문에, 키 교환이 보안 문제의 핵심입니다.

심화 질문

• 비대칭키 암호화는 대칭키 암호화보다 왜 느린가요?
  • 답변: 비대칭키 암호화는 수학적 연산이 복잡하여 대칭키 암호화보다 속도가 느립니다. 따라서 보통 대칭키로 데이터를 암호화하고, 그 대칭키를 비대칭키로 교환하는 방식이 자주 사용됩니다.

Connection Timeout과 Read Timeout의 차이

• Connection Timeout은 클라이언트가 서버와의 연결을 시도할 때, 연결을 설정하는 시간이 일정 시간 내에 완료되지 않으면 타임아웃을 발생시키는 설정입니다. 즉, 서버와의 TCP 연결이 설정되지 않으면 일정 시간이 지나 요청이 실패로 처리됩니다. 이는 서버가 응답하지 않거나 네트워크가 불안정한 경우 발생할 수 있습니다.
• Read Timeout은 서버와의 연결이 성공한 후, 클라이언트가 서버로부터 데이터를 받는 데 걸리는 시간을 의미합니다. 즉, 서버가 요청을 받았지만 일정 시간 내에 응답 데이터를 전송하지 않으면 타임아웃이 발생합니다. 이는 서버의 처리 지연 또는 네트워크 문제로 인해 발생할 수 있습니다.

차이점

• Connection Timeout은 연결을 시도하는 과정에서 발생하며, 서버에 연결되지 않으면 타임아웃을 발생시킵니다.
• Read Timeout은 연결이 성공한 이후 데이터 수신이 일정 시간 내에 이루어지지 않을 때 발생합니다.

예상 질문

• Connection Timeout은 주로 어떤 상황에서 발생하나요?
  • 답변: Connection Timeout은 서버가 과부하 상태이거나, 네트워크가 끊어졌을 때 발생할 수 있습니다. 클라이언트는 일정 시간 내에 서버에 연결하지 못해 타임아웃이 발생합니다.

심화 질문

• Read Timeout을 짧게 설정했을 때 발생할 수 있는 문제는 무엇인가요?
  • 답변: Read Timeout을 너무 짧게 설정하면, 서버가 응답을 보내는 시간이 걸리는 경우에도 타임아웃 에러가 발생할 수 있습니다. 특히 대규모 데이터 처리나 네트워크 속도가 느린 환경에서는 더 긴 시간이 필요할 수 있습니다.