개발자 기술면접 대비 - 네트워크

 

질문 리스트

 

TCP와 UDP의 차이를 설명해주세요.

TCP와 UDP는 모두 전송 계층(Transport Layer) 프로토콜이지만, 통신 방식과 특징이 다릅니다.

TCP(Transmission Control Protocol)
연결지향(Connection-oriented) 프로토콜입니다.
데이터를 보내기 전에 3-way handshake를 통해 연결을 설정하고, 데이터가 올바르게 전달되었는지 확인하는 과정을 거칩니다. 흐름 제어, 오류 검출, 재전송 메커니즘이 내장되어 있어 신뢰성이 매우 높습니다.
대신 통신 오버헤드가 크고 전송 속도가 느릴 수 있습니다.
대표적으로 웹 브라우징(HTTP), 파일 전송(FTP), 이메일(SMTP) 등에 사용됩니다.

UDP(User Datagram Protocol)
비연결성(Connectionless) 프로토콜입니다.
별도의 연결 설정 없이 데이터를 바로 전송하며, 데이터가 제대로 도착했는지 확인하지 않습니다.
오류 검출, 재전송 같은 추가 처리가 없기 때문에 오버헤드가 적고 전송 속도가 빠릅니다.
주로 실시간성이 중요한 스트리밍, VoIP, 온라인 게임 같은 분야에서 사용됩니다.

TCP 3-way handshake란 무엇인가요?

TCP 3-way handshake는 클라이언트와 서버가 신뢰성 있는 연결을 맺기 위해 사용하는 3단계의 초기 연결 절차입니다. 통신을 시작하기 전에 서로 연결을 준비하고, 양쪽 모두 통신할 준비가 되었음을 확인하는 과정을 말합니다.

과정은 다음과 같습니다.
1. SYN (Synchronize)
클라이언트가 서버에 연결을 요청합니다. 이때 클라이언트는 자신의 초기 Sequence Number(SEQ)를 설정하고, SYN 플래그를 설정한 패킷을 서버로 전송합니다.

2. SYN-ACK (Synchronize + Acknowledgment)
서버는 클라이언트의 요청을 받고, 자신의 초기 Sequence Number를 설정한 뒤, 클라이언트의 SYN 요청에 대한 응답으로 SYN과 ACK 플래그가 모두 설정된 패킷을 클라이언트에게 전송합니다.

3. ACK (Acknowledgment)
클라이언트는 서버로부터 SYN-ACK 응답을 받으면, 이를 수락했다는 의미로 ACK 플래그가 설정된 패킷을 서버로 보냅니다.

이렇게 세 번의 패킷 교환을 통해 양쪽 모두 통신할 준비가 완료되었음을 확인한 후, 실제 데이터 전송이 시작됩니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "3-way handshake를 왜 2번이나 4번이 아니라 3번 하나요?"
  클라이언트와 서버 양쪽 모두 상대방이 자신과 통신할 준비가 되었는지 서로 확인해야 해서 3번이 필요합니다.
• "초기 Sequence Number를 왜 랜덤하게 설정하나요?"
  예측 가능한 SEQ 번호를 사용하면 **세션 하이재킹 공격(예: TCP 세션 가로채기)**에 노출될 수 있어서, 랜덤하게 설정하여 보안성을 높입니다.
• "3-way handshake 중 중간에 패킷이 손실되면 어떻게 하나요?"
  일정 시간 동안 응답이 없으면 재전송하고, 재전송 시도 후에도 실패하면 연결 시도를 포기합니다. (타임아웃)

TCP 4-way handshake란 무엇인가요?

TCP 4-way handshake는 양쪽 모두 데이터 전송을 완료하고, 통신 연결을 정상적으로 종료하기 위해 사용하는 절차입니다. 
연결 수립은 3번의 패킷 교환으로 이루어지지만, 종료는 4번의 패킷 교환이 필요합니다.

절차는 다음과 같습니다.

1. FIN (Finish)
클라이언트가 서버에게 연결을 종료하겠다는 FIN 패킷을 전송합니다. 이때 클라이언트는 더 이상 데이터를 보내지 않겠다는 의사를 표시합니다.

2. ACK
서버는 클라이언트의 FIN 패킷을 수신하고, 이를 수락했다는 의미로 ACK 패킷을 클라이언트에게 전송합니다. (→ 이 시점에서도 서버는 데이터 전송이 가능)

3. FIN
서버가 자신의 데이터 전송이 모두 끝나면, 클라이언트에게 다시 연결을 종료하겠다는 FIN 패킷을 보냅니다.

4. ACK
클라이언트는 서버의 FIN 패킷을 수신하고, 이에 대한 응답으로 ACK 패킷을 서버에 전송합니다. 이로써 양쪽 모두 통신을 종료합니다.

특징적으로, 연결을 끊을 때 송신 방향마다 따로 종료 신호를 주고받기 때문에, 수립(3-way)보다 종료(4-way) 절차가 한 번 더 필요하게 됩니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "왜 연결 종료는 4번이 필요한가요?"
  데이터 송신과 수신은 별도로 관리되기 때문에, 각각의 방향(양방향)에서 독립적으로 FIN → ACK 과정을 거쳐야 합니다.
• "TIME_WAIT 상태는 무엇인가요?"
  클라이언트가 마지막 ACK를 보낸 후 일정 시간 동안 대기하는 상태입니다. 재전송 패킷이나 지연된 패킷을 처리하고, 올바른 연결 종료를 보장하기 위해 필요합니다.
• "4-way handshake 중에 데이터는 전송되나요?"
  첫 번째 FIN 이후로는 클라이언트가 데이터 전송을 중단하지만, 서버는 ACK 이후에도 남은 데이터를 보낼 수 있습니다. (그래서 FIN을 별도로 다시 보냄)

 

TCP TIME_WAIT 상태란 무엇이며, 왜 필요한가요?

TCP에서 TIME_WAIT은 연결을 종료할 때 클라이언트 쪽에서 일정 시간 동안 기다리는 상태를 의미합니다.
4-way handshake가 완료되어 마지막 ACK를 서버에 보내고 나면, 클라이언트는 바로 연결을 닫지 않고, 일정 시간(TCP 표준에서는 2MSL, 약 1~4분) 동안 TIME_WAIT 상태로 대기합니다.

TIME_WAIT이 필요한 이유는 크게 두 가지입니다.
1. 지연된 패킷 처리
네트워크 특성상, 이전 연결에서 전송되었던 패킷이 아직 네트워크 상에 남아있을 수 있습니다. 만약 연결을 즉시 닫고 같은 소켓(포트 번호)을 재사용하면, 이전 연결의 지연된 패킷이 새 연결에 영향을 줄 수 있습니다. TIME_WAIT 상태로 대기함으로써 이런 지연 패킷이 모두 소멸되기를 기다립니다.

2. 정상적인 연결 종료 보장
마지막 ACK 패킷이 서버에 제대로 도달하지 않았을 수도 있습니다. 이 경우 서버는 FIN을 재전송할 수 있고, 클라이언트는 TIME_WAIT 상태에서 이 재전송을 받아 정상적으로 다시 ACK를 보낼 수 있습니다. 이를 통해 연결 종료가 확실히 이루어졌음을 보장합니다.

결론적으로, TIME_WAIT은 TCP 연결의 무결성과 안전한 종료를 보장하기 위한 필수적인 절차입니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "TIME_WAIT이 너무 많으면 어떤 문제가 발생하나요?"
  서버나 클라이언트에서 포트가 고갈될 수 있습니다. 특히 대량의 짧은 연결이 발생하는 경우 TIME_WAIT 소켓이 급증해 리소스 문제가 발생할 수 있습니다.
• "TIME_WAIT을 줄이거나 회피할 방법은 있나요?"
  리눅스 같은 시스템에서는 TIME_WAIT 재사용 (TCP_TW_REUSE)이나 TIME_WAIT 소켓 빠른 삭제 (TCP_TW_RECYCLE) 옵션을 설정할 수 있지만, 부작용(특히 NAT 환경 문제)이 있어 신중하게 사용해야 합니다.

TCP 흐름 제어와 혼잡 제어의 차이를 설명해주세요.

흐름 제어(Flow Control)
송신 측이 너무 많은 데이터를 보내서, 수신 측이 이를 처리하지 못하는 상황을 방지하기 위한 제어입니다.
수신 측의 처리 능력에 맞게 송신 측의 전송 속도를 조절합니다.
TCP에서는 윈도우 크기(Window Size)를 이용해 구현합니다.
수신자는 자신의 버퍼 상태에 따라 윈도우 크기를 조정하여 송신자에게 알려주고, 송신자는 이 값을 기반으로 보낼 수 있는 데이터 양을 결정합니다.

혼잡 제어(Congestion Control)
네트워크 전체의 혼잡 상태를 감지하고, 네트워크에 과부하가 발생하지 않도록 송신 속도를 조절하는 기법입니다. 주로 패킷 손실이나 RTT 지연을 통해 네트워크 혼잡 신호를 감지합니다.
TCP에서는 혼잡 윈도우(Congestion Window, cwnd)를 사용하여, 송신자가 네트워크 상황을 고려해 동적으로 전송량을 늘리거나 줄입니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "TCP에서 혼잡 제어 알고리즘은 어떤 것들이 있나요?"
  Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery 같은 단계적 혼합 알고리즘을 사용합니다.
• "흐름 제어와 혼잡 제어는 동시에 작동하나요?"
  네, TCP에서는 흐름 제어(Window Size)와 혼잡 제어(Cwnd)를 둘 다 고려해서, 실제 전송 가능한 데이터 양을 min(Window Size, Cwnd)로 결정합니다.
• "네트워크 혼잡이란 정확히 무엇인가요?"
  라우터나 스위치 등 네트워크 장비가 패킷을 감당하지 못하고 지연되거나 손실이 발생하는 상황을 의미합니다.

TCP 혼잡 제어 알고리즘에 대해 설명해주세요.

TCP 혼잡 제어는 네트워크에 패킷이 과도하게 몰리는 혼잡 상태를 방지하기 위해 송신 측 전송 속도를 동적으로 조절하는 기법입니다.
이를 위해 여러 알고리즘이 단계적으로 동작합니다. 대표적인 흐름은 다음과 같습니다.

1. Slow Start (느린 시작)
연결이 처음 시작되거나 패킷 손실이 발생한 이후, 송신자는 혼잡 윈도우(Congestion Window, cwnd)를 매우 작은 값(보통 1 MSS)으로 설정하고 시작합니다.
이후 매 RTT(Round Trip Time)마다 cwnd를 2배씩 지수적으로 증가시킵니다. 이 과정을 통해 네트워크 상태를 빠르게 탐색합니다.

2. Congestion Avoidance (혼잡 회피)
cwnd가 일정 임계값(Threshold, ssthresh)에 도달하면, 이제부터는 지수 증가를 멈추고 선형적으로(1 MSS씩) 증가합니다. 이를 통해 네트워크 과부하 없이 천천히 전송 속도를 높입니다.

3. Fast Retransmit (빠른 재전송)
수신자가 동일한 ACK를 3번 이상 중복해서 보내면, 송신자는 타임아웃을 기다리지 않고 손실을 예상하여 바로 재전송합니다. 이를 통해 패킷 손실을 더 빠르게 감지하고 복구할 수 있습니다.

4. Fast Recovery (빠른 복구)
Fast Retransmit가 발생한 경우, Slow Start로 돌아가지 않고 ssthresh를 절반으로 줄이고 cwnd도 절반으로 줄인 뒤, 혼잡 회피 단계로 곧바로 넘어갑니다.
이렇게 하면 네트워크에 불필요하게 급격한 속도 감소를 방지할 수 있습니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "Slow Start가 무조건 좋은가요?"
  초기에 지수적으로 빠르게 증가하기 때문에, 네트워크 혼잡이 이미 있는 경우 추가적인 혼잡을 유발할 수 있습니다.
• "Fast Retransmit과 일반 타임아웃 재전송의 차이는 무엇인가요?"
  Fast Retransmit은 중복 ACK 기반으로 빠르게 재전송하고, 일반 타임아웃은 지정된 시간 동안 응답이 없을 때 발생합니다.
• "TCP Reno와 TCP NewReno의 차이는 무엇인가요?"
  NewReno는 Fast Recovery를 더 최적화하여, 다수 패킷 손실이 발생해도 더 효율적으로 복구합니다.

HTTP 기본 구조에 대해 설명해주세요.

HTTP(HyperText Transfer Protocol)는 클라이언트와 서버가 요청과 응답을 통해 데이터를 주고받는 비연결성, 비상태성 프로토콜입니다.

HTTP 통신은 기본적으로 Request와 Response 두 가지 메시지로 이루어집니다.

요청(Request) 구조
1. Request Line
요청 메서드(GET, POST 등), 요청 URL, HTTP 버전을 포함합니다.
예: GET /index.html HTTP/1.1

2. Request Headers
요청에 대한 추가 정보를 전달합니다.
예: Host, User-Agent, Accept, Authorization 같은 키-값 쌍 형태입니다.

3. Blank Line
헤더와 바디를 구분하는 빈 줄입니다.

4. Request Body
POST, PUT 요청처럼 서버로 전송할 실제 데이터를 담습니다. (ex: 폼 데이터, JSON)

응답(Response) 구조
1.Status Line
HTTP 버전, 상태 코드(예: 200 OK, 404 Not Found)와 상태 메시지를 포함합니다.
예: HTTP/1.1 200 OK

2. Response Headers
응답에 대한 부가 정보를 제공합니다.
예: Content-Type, Content-Length, Set-Cookie 등이 있습니다.

3. Blank Line
헤더와 바디를 구분하는 빈 줄입니다.

4.Response Body
실제 응답 데이터(HTML, JSON, 이미지 등)가 포함됩니다.

HTTP는 기본적으로 요청과 응답 1:1 매칭 구조이며,
연결이 유지되지 않는 비연결성(stateless) 특성 때문에 추가적으로 쿠키나 세션 등을 사용하여 상태를 관리합니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "HTTP는 비상태성인데, 상태를 어떻게 유지하나요?"
  쿠키(Cookie), 세션(Session), 토큰(Token)을 사용해서 상태를 관리합니다.
• "GET과 POST 메서드의 차이는 무엇인가요?"
  GET은 URL에 데이터를 담아 전송하고, POST는 Body에 데이터를 담아 전송합니다. GET은 캐싱 가능하지만, POST는 캐싱되지 않습니다.
• "HTTP 버전별 차이(1.0 vs 1.1 vs 2 vs 3)는 무엇인가요?"
  HTTP/1.1은 Keep-Alive 지원, HTTP/2는 멀티플렉싱 지원, HTTP/3는 QUIC 프로토콜 사용 등 다양한 개선이 있습니다.

HTTP 메서드(GET, POST, PUT, DELETE 등)에 대해 설명해주세요.

 

1. GET
서버로부터 리소스를 조회할 때 사용하는 메서드입니다.
요청 데이터는 주로 URL 쿼리스트링(예: /items?id=1)에 포함되며,
조회의 경우, 서버에 부작용을 일으키지 않는 안전한(Safe) 메서드로 간주됩니다.

2. POST
서버에 리소스를 생성하거나, 서버 상태를 변경할 때 사용하는 메서드입니다.
요청 데이터는 Body에 담아서 전송합니다.
서버 상태를 바꿀 수 있기 때문에 Safe하지 않으며, 주로 폼 제출, 회원가입, 로그인 등에 사용됩니다.

3. PUT
서버의 리소스를 수정하거나 새로 생성할 때 사용하는 메서드입니다.
요청 본문(Body)에 전체 데이터를 담아 전송하며,
지정한 리소스를 데이터로 대체(덮어쓰기) 하는 것이 원칙이며, 기존 데이터가 없으면 생성합니다.

4. DELETE
서버의 리소스를 삭제할 때 사용하는 메서드입니다.
성공 시 서버에서 해당 리소스가 제거됩니다.

각 메서드는 RESTful API 설계에서
GET = 조회 (Read)
POST = 생성 (Create)
PUT = 수정 (Update)
DELETE = 삭제 (Delete)
처럼 CRUD 개념과 매칭되어 사용되는 것이 일반적입니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "PATCH 메서드는 무엇인가요?"
  PATCH는 PUT과 비슷하지만, 전체 대체가 아니라 리소스의 일부만 수정할 때 사용합니다.
• "POST와 PUT은 언제 구분해서 써야 하나요?"
  POST는 '서버가 리소스 위치를 정하는' 생성,
  PUT은 '클라이언트가 리소스 위치를 정해서' 수정/생성할 때 사용합니다.
• "GET 요청에도 Body를 보낼 수 있나요?"
  HTTP 표준상 GET 요청에는 Body를 보내지 않는 것이 원칙입니다. 대부분의 서버/라이브러리도 이를 지원하지 않습니다.

 

HTTP 상태코드에 대해 설명해주세요.

HTTP 상태코드는 클라이언트의 요청에 대해 서버가 어떤 결과를 응답했는지를 나타내는 3자리 숫자입니다.

첫 번째 숫자에 따라 의미가 구분됩니다.
1xx (Informational) : 요청을 받았고, 작업을 계속하고 있다는 의미입니다.
2xx (Success) : 요청이 성공적으로 처리되었음을 의미합니다.
3xx (Redirection) : 요청 완료를 위해 추가 조치(리다이렉션)가 필요함을 의미합니다.
4xx (Client Error) : 클라이언트 요청에 오류가 있음을 의미합니다.
5xx (Server Error) : 서버 측에서 요청을 처리하는 도중 오류가 발생했음을 의미합니다.

대표적인 상태코드는 다음과 같습니다.
200 OK : 요청이 성공적으로 처리되었습니다. (ex: 정상 페이지 조회)
301 Moved Permanently : 요청한 리소스가 영구적으로 다른 URL로 이동했습니다. 
401 Unauthorized : 인증이 제대로 이루어지지 않았음을 의미합니다. (ex: 로그인 필요)
403 Forbidden : 권한이 없어서 요청을 거부한 경우입니다. (ex: 접근 금지 페이지)
500 Internal Server Error : 서버 내부에서 예기치 않은 오류가 발생해 요청을 처리할 수 없음
404 Not Found : 요청한 리소스를 찾을 수 없음여기에 질문 10번 입력

HTTP/1.1, HTTP/2, HTTP/3의 차이점을 설명해주세요.

HTTP/1.1, HTTP/2, HTTP/3는 웹 통신 프로토콜의 발전 단계를 나타냅니다.
각 버전은 주로 성능 개선과 네트워크 혼잡 완화에 중점을 두고 발전해왔습니다.

HTTP/1.1
가장 널리 사용되는 전통적인 버전입니다.
하나의 TCP 연결에 대해 한 번에 하나의 요청/응답만 처리할 수 있습니다.
(HOL Blocking 문제: Head of Line Blocking)
이를 해결하기 위해 'Keep-Alive' 옵션으로 연결을 재사용하고, 'Pipelining' 기능도 추가했지만 여전히 한계가 있었습니다.

HTTP/2
하나의 TCP 연결 안에서 Multiplexing(다중 요청/응답 동시 처리)을 지원합니다.
요청/응답을 프레임 단위로 분해하여 전송하기 때문에, 하나의 연결에서 여러 스트림을 병렬 처리할 수 있습니다.
또한 Header Compression(HPACK) 기능으로 중복되는 헤더 정보를 압축해 트래픽을 줄였습니다.
그러나 TCP 위에서 동작하기 때문에, 여전히 하단 TCP 계층에서의 HOL Blocking 문제는 완전히 해결되지 않았습니다.

HTTP/3
최신 버전으로, TCP 대신 QUIC 프로토콜을 기반으로 동작합니다. (UDP 기반)
QUIC은 TLS 1.3을 내장하고 있어 보안 통신이 기본이고,
패킷 손실이 발생해도 연결 전체가 막히지 않고, 손실된 스트림만 재전송할 수 있어 진정한 HOL Blocking 해결을 이뤘습니다.
핸드셰이크 과정도 간소화되어 연결 속도가 훨씬 빨라졌습니다.

HTTP와 HTTPS의 차이를 설명해주세요.

HTTP와 HTTPS는 둘 다 클라이언트와 서버가 요청과 응답을 주고받는 프로토콜이지만,
가장 큰 차이점은 데이터를 암호화하는지 여부입니다.

HTTP(HyperText Transfer Protocol)
데이터를 암호화하지 않고 평문(Plain Text)으로 전송합니다.
따라서 통신 중간에 공격자가 패킷을 가로채면 요청/응답의 내용을 쉽게 볼 수 있습니다. 
보안성이 없습니다.

HTTPS(HyperText Transfer Protocol Secure)
HTTP에 SSL/TLS 프로토콜을 추가하여 통신 내용을 암호화합니다.
클라이언트와 서버 사이에 TLS 핸드셰이크 과정을 거쳐 세션 키를 안전하게 교환한 후, 이 세션 키를 사용해 모든 HTTP 데이터를 암호화합니다.
이 과정을 통해 데이터 도청(스니핑), 변조, 위조를 방지할 수 있습니다.
추가로 HTTPS는 데이터 암호화뿐 아니라 서버 인증, 데이터 무결성 보장 역할도 함께 수행합니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "HTTPS 통신 과정은 어떻게 이루어지나요?"
  클라이언트가 서버의 SSL 인증서를 받고 검증한 후, TLS 핸드셰이크 과정을 통해 세션 키를 공유하고, 이후 모든 데이터는 이 세션 키로 암호화해서 주고받습니다.
• "HTTPS를 쓰면 무조건 안전한가요?"
  통신 구간은 안전하지만, 서버나 클라이언트 자체가 해킹당하면 여전히 정보 유출 가능성은 존재합니다.
• "HTTPS를 사용하면 왜 검색엔진 SEO 점수도 좋아지나요?"
  구글은 HTTPS 사용 사이트를 안전한 사이트로 간주하여 검색 랭킹을 우선시합니다.

CORS란 무엇인가요?

CORS는 Cross-Origin Resource Sharing의 약자로, 
서로 다른 출처(origin) 간의 리소스 공유를 제어하는 보안 정책입니다.

웹 브라우저는 기본적으로 동일 출처 정책(Same-Origin Policy)를 적용합니다.
동일 출처 정책이란, 스킴(protocol), 호스트(domain), 포트(port)가 모두 같은 경우에만 리소스 요청을 허용하는 정책입니다. 이는 악성 사이트가 사용자의 정보를 무단으로 요청하거나 훔치는 것을 방지하기 위한 보안 기능입니다.

하지만 실제 서비스에서는 API 서버와 프론트 서버가 다른 도메인에 있을 때처럼, 서로 다른 출처 간 요청이 필요한 경우가 많습니다.
이때 필요한 것이 CORS입니다.

CORS는 서버가 '이 출처(origin)는 요청을 허용한다'고 명시적으로 응답 헤더에 허용 정책을 설정함으로써, 브라우저가 교차 출처 요청을 허용하게 해주는 메커니즘입니다.

구체적으로, 서버는 응답 헤더에 Access-Control-Allow-Origin을 설정하여 허용할 출처를 지정합니다. 브라우저는 이 응답을 보고, 요청을 허용할지 차단할지 결정합니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "Preflight Request란 무엇인가요?"
  브라우저가 실제 요청을 보내기 전에, OPTIONS 메서드를 사용해 서버에 사전 요청을 보내는 과정입니다. 이 과정에서 서버가 CORS 정책을 응답합니다. 복잡한 요청(PUT, DELETE 등)이나 특수 헤더가 있을 때 발생합니다.
• "CORS를 해결하려면 클라이언트에서 설정하면 되나요?"
  아니요, CORS 정책은 서버에서 응답 헤더를 설정해야 합니다. 클라이언트는 CORS를 무시하거나 우회할 수 없습니다.
• "CORS를 허용하면 보안에 문제가 생기나요?"
  모든 출처(*)를 허용하거나 민감한 API를 CORS로 개방하면 악성 사이트가 사용자의 인증 상태를 악용할 위험이 있습니다. 민감한 API는 CORS를 제한적으로 설정하고, 인증/인가 절차를 강화해야 합니다.

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

OSI 7계층은 네트워크 통신을 단계별로 분리해, 각 단계가 독립적으로 동작하면서 전체 시스템을 효율적으로 설계할 수 있도록 만든 모델입니다.

7계층 (응용 계층, Application Layer)
사용자와 가장 가까운 계층으로, 웹 브라우저, 메신저 등 응용 프로그램이 사용하는 프로토콜이 동작합니다. (예: HTTP, FTP, SMTP)

6계층 (표현 계층, Presentation Layer)
데이터의 표현 방식(문자 인코딩, 암호화, 압축 등)을 변환합니다. (예: JPEG, SSL/TLS)

5계층 (세션 계층, Session Layer)
통신 세션을 생성, 관리, 종료합니다. (예: 로그인 세션 유지, NetBIOS)

4계층 (전송 계층, Transport Layer)
데이터의 신뢰성 있는 전송을 보장합니다. 포트를 기반으로 통신하고, 오류 검출 및 재전송 기능을 합니다. (예: TCP, UDP)

3계층 (네트워크 계층, Network Layer)
데이터를 목적지까지 최적 경로로 전달합니다. IP 주소를 이용하며, 라우팅 기능을 수행합니다. (예: IP, ICMP)

2계층 (데이터 링크 계층, Data Link Layer)
물리적 네트워크 상에서 오류 없이 데이터를 전송합니다. MAC 주소 기반 통신을 담당합니다. (예: Ethernet, Switch)

1계층 (물리 계층, Physical Layer)
실제 전기 신호, 광신호를 통해 비트 단위 데이터를 전송합니다. 하드웨어 장비가 동작하는 계층입니다. (예: 케이블, 허브, 리피터)

왜 OSI 모델은 계층을 나눴나요?

OSI 모델은 복잡한 네트워크 통신을 구조적으로 관리하기 위해 계층을 나눴습니다.

계층화의 목적
1) 복잡성 감소
전체 네트워크 시스템을 작은 단계별 문제로 나누어 쉽게 설계하고 이해할 수 있게 합니다.

2) 표준화와 상호 운용성 향상
계층별로 명확한 역할과 인터페이스를 정의하여, 서로 다른 제조업체나 시스템 간에도 호환이 가능하도록 합니다.

3) 유연성과 독립성 확보
한 계층의 변경이 다른 계층에 영향을 주지 않게 만들어, 시스템 확장이나 유지보수가 쉬워집니다.

TCP 초기 Sequence Number를 랜덤하게 설정하는 이유는 무엇인가요?

이유는 보안 공격을 방지하기 위해서입니다.

만약 ISN이 예측 가능한 값으로 설정된다면, 공격자가 이를 추측하여 TCP 세션을 하이재킹하거나, 세션을 가로채는 TCP 세션 하이재킹(Session Hijacking) 공격이 가능해집니다.

랜덤한 ISN을 사용하면 공격자가 정확한 시퀀스 번호를 알아내기 어렵기 때문에, 이런 공격을 예방할 수 있습니다.

또한, 랜덤 ISN은 동일한 IP/포트 조합에서 이전 연결의 남은 패킷(지연 패킷)과 현재 연결을 혼동하는 것을 방지하는 데도 도움이 됩니다

RESTful API란 무엇인가요?

RESTful API는 REST 원칙을 준수하여 설계된 API를 의미합니다.

REST(Representational State Transfer)는 자원을 'URI(Uniform Resource Identifier)'로 표현하고,
HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 자원에 대한 행위를 명확히 구분하여 요청하는 아키텍처 스타일입니다.

특징
1. 자원의 표현(Resource-Based)
서버의 데이터를 고유한 URI로 식별합니다. (예: /users/1 → 1번 유저 자원)

2. 표준 HTTP 메서드 사용(Method-Based)
CRUD 작업을 HTTP 메서드로 명확히 표현합니다.
GET → 조회, POST → 생성, PUT → 수정, DELETE → 삭제

3. 무상태성(Stateless)
서버는 클라이언트의 이전 요청 상태를 저장하지 않고, 각 요청은 독립적으로 처리됩니다.

4. 클라이언트-서버 분리(Client-Server Separation)
클라이언트와 서버가 명확히 역할을 분리하여, 서버는 데이터 제공에 집중하고, 클라이언트는 UI/UX를 담당합니다.

5. 계층화(Layered System)
요청과 응답은 중간 계층(프록시, 게이트웨이 등)을 거칠 수 있으며, 클라이언트는 직접 서버와 연결된 것처럼 작동합니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "RESTful하지 않은 API란 무엇인가요?"
  URI에 동사가 포함되거나, HTTP 메서드를 제대로 구분하지 않고 단순히 POST만 사용하는 경우 비RESTful하다고 볼 수 있습니다. (예: /createUser 대신 /users + POST)
• "REST와 RESTful은 다르나요?"
   REST는 아키텍처 스타일 자체를 의미하고, RESTful은 그 스타일을 잘 지킨 시스템을 의미합니다.
• "RESTful API의 단점은 없나요?"
   복잡한 트랜잭션 처리나 실시간 연결에는 REST가 적합하지 않을 수 있어, 이럴 땐 WebSocket이나 gRPC 같은 대안이 사용됩니다.

TCP FIN 패킷보다 ACK 패킷이 늦게 도착하는 상황 정리

TCP 연결 종료 과정(4-way handshake)에서는 일반적으로 클라이언트가 FIN을 보내고, 
서버가 ACK를 보낸 후, 서버가 다시 자신의 FIN을 보냅니다.

그런데 네트워크 지연이나 패킷 전송 순서 변경 등으로 인해, 클라이언트가 보낸 FIN 패킷이 서버에 먼저 도착하고, 서버가 이에 대해 ACK를 보내는 과정에서 ACK가 네트워크 지연 등으로 늦게 도착할 수 있습니다.

즉, 클라이언트는 FIN을 보내놓고 상대방의 ACK를 바로 받지 못하는 상황이 발생할 수 있습니다.

이런 경우에도 TCP 프로토콜은 신뢰성 있는 통신을 보장하기 위해 재전송 메커니즘을 갖추고 있습니다. 만약 클라이언트가 일정 시간 동안 ACK를 받지 못하면, 클라이언트는 FIN 패킷을 재전송하여 연결 종료를 다시 시도합니다.
그리고 서버가 재전송된 FIN에 대해 ACK를 다시 보내주면 정상적으로 연결 종료가 이루어집니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "FIN 패킷 재전송은 몇 번이나 하나요?"
  시스템마다 다르지만, TCP는 일반적으로 몇 번(예: 5번) 재전송 후에도 실패하면 연결 종료를 포기합니다. (타임아웃)
• "TIME_WAIT은 이런 상황과 관련 있나요?"
  네, 클라이언트는 마지막 ACK를 보낸 뒤에도 TIME_WAIT 상태로 일정 시간 대기하여, 지연된 FIN 재전송에 대응할 수 있도록 합니다.
• "이런 상황이 현실에서 자주 발생하나요?"
  극심한 네트워크 지연이나 패킷 손실이 있는 환경에서는 드물지만 실제로 발생할 수 있습니다. 특히 무선 네트워크 환경에서 가능성이 높습니다.

 

DNS 동작 원리에 대해 설명해주세요.

DNS(Domain Name System)는 사람이 읽을 수 있는 도메인 이름(ex: google.com)을 서버가 이해할 수 있는 IP 주소로 변환하는 시스템입니다.

웹 브라우저가 도메인 이름으로 서버 접속할 때, DNS를 통해 IP 주소를 조회하는 과정을 거칩니다.

순서
1. 브라우저 캐시 조회
사용자가 접속한 적 있는 사이트라면, 브라우저 내부 캐시에서 IP 주소를 먼저 확인합니다.

2. OS 캐시(DNS Resolver 캐시) 조회
브라우저에 없으면 운영체제(OS) 레벨의 DNS 캐시를 확인합니다.

3. 로컬 DNS 서버(Recursive Resolver) 문의
OS 캐시에도 없으면, 설정된 로컬 DNS 서버(보통 ISP 제공)에 요청을 보냅니다.

4. 로컬 DNS 서버의 캐시 확인
로컬 DNS 서버가 과거에 저장한 캐시가 있다면 바로 IP 주소를 반환합니다.

5. 권한 있는 서버(Authoritative Server)까지 조회
캐시에도 없다면, 루트 DNS 서버 → 최상위 도메인 서버(.com, .net 등) → 권한 있는 도메인 서버 순서로 재귀적 또는 반복적으로 조회를 이어갑니다.
최종적으로 권한 있는 서버에서 정확한 IP 주소를 받아옵니다.

6. IP 주소 응답
로컬 DNS 서버가 IP 주소를 받아 클라이언트에게 전달하고, 요청은 해당 IP로 접속하여 웹페이지를 요청합니다.

이 과정은 사용자가 입력한 도메인을 IP로 해석하고, 서버까지 빠르게 연결하는 데 필수적입니다.

🔥 추가 심화 대비 (추가로 물어볼 수 있는 질문)

• "Recursive query와 Iterative query의 차이는?"
  Recursive query는 클라이언트가 요청하면 DNS 서버가 최종 IP까지 찾아오는 방식이고, Iterative query는 DNS 서버가 '나는 몰라, 저기 가서 물어봐' 하며 단계별로 넘기는 방식입니다.
• "권한 있는 DNS 서버(Authoritative Server)는 무엇인가요?"
  특정 도메인에 대한 최종 공식 정보를 가지고 있는 서버입니다. (예: naver.com 도메인 소유자가 운영하는 DNS 서버)
• "DNS 캐시 타임(Time-To-Live, TTL)은 무엇인가요?"
  DNS 레코드는 TTL 설정을 통해 캐시 지속 시간을 정할 수 있고, TTL이 만료되면 다시 DNS 조회를 합니다.

공인 IP와 사설 IP의 차이를 설명해주세요.

공인 IP와 사설 IP는 IP 주소의 사용 범위에 따라 구분됩니다.

공인 IP(Public IP)
인터넷 상에서 고유하게 식별 가능한 IP 주소입니다.
전 세계적으로 유일해야 하며, 인터넷 서비스 제공자(ISP)나 클라우드 업체를 통해 발급받아 사용합니다. 서버나 웹사이트처럼 외부에서 접근 가능한 시스템은 공인 IP를 사용합니다.

사설 IP(Private IP)
내부 네트워크(기업, 가정, 사무실 등)에서만 사용되는 IP 주소입니다.
인터넷에서는 직접 사용될 수 없고, 보통 라우터나 NAT(Network Address Translation)를 통해 공인 IP로 변환하여 인터넷에 접속합니다.
주로 내부 장비 식별(PC, 프린터 등)에 사용되며, 자원 절약과 보안성 향상 목적도 있습니다.

사설 IP 대역은 RFC1918 규격에 따라 다음과 같이 예약되어 있습니다:
10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255"

 

API Gateway란 무엇인가요?

API Gateway는 클라이언트와 백엔드 서비스 사이에 위치하여, 클라이언트 요청을 적절한 서비스로 라우팅하고, 여러 공통 기능을 중앙 집중식으로 처리하는 중간 서버입니다.

대규모 시스템에서는 서비스가 여러 개로 나뉘어(Microservices) 운영되기 때문에, 클라이언트가 각각의 서비스를 직접 호출하게 하면 복잡하고 비효율적입니다.

1. 라우팅
클라이언트 요청을 적절한 백엔드 서비스로 분배합니다.

2. 인증/인가 처리
로그인, 토큰 검증 같은 인증 절차를 공통으로 처리합니다.

3. 로깅, 모니터링
모든 API 호출을 수집하고 모니터링할 수 있도록 지원합니다.

4. 로드 밸런싱
백엔드 서비스 간 부하를 분산시킵니다.

5. 요청/응답 변환
클라이언트 요구사항에 맞게 데이터 포맷을 변환하거나 통합할 수 있습니다.

6. 보안 기능 제공
SSL 종료(TLS Termination), IP 차단, CORS 설정 등을 중앙 집중식으로 관리합니다.

결과적으로, API Gateway는 클라이언트 입장에서는 '하나의 입구'를 제공하고, 서버 관리자는 시스템을 더 깔끔하고 안전하게 유지할 수 있게 도와줍니다.