🌐 ziinsun

241206 - 네트워크

16 min read

  1. HTTP 메서드
  2. RESTful
  3. CORS
  4. OSI 7계층, TCP/IP 4계층
  5. 서버 간 라우팅

1. HTTP 메서드

HTTP 메서드의 역할

  • 클라이언트와 서버 간의 통신에서 요청의 목적을 명확히 하기 위해 사용
  • 각각의 메서드는 특정한 작업을 수행하며, RESTful API 설계를 위한 중요한 역할

GET

  • 리소스 조회
  • 서버에서 데이터를 가져오기 위한 요청

POST

  • 리소스 생성
  • 서버에 데이터를 전송하여 새로운 리소스 생성

PUT

  • 리소스 전체 업데이트
  • 리소스의 모든 데이터를 교체

PATCH

  • 리소스 부분 업데이트
  • 리소스의 일부 데이터만 수정

DELETE

  • 리소스 삭제
  • 서버에서 특정 리소스를 제거

NOTE

HTTP 메서드의 역할은 무엇인가요?

클라이언트와 서버 간의 요청 목적을 명확히 전달하는 데 있습니다. 각 메서드는 특정한 작업을 정의하며, RESTful API 설계를 위해 필요합니다.

NOTE

API 설계 시 하나의 HTTP 메서드로 여러 작업을 수행하면 어떤 문제가 발생하나요?

단일 책임 원칙을 위반하기 때문에 가독성과 유지보수성이 떨어지고 RESTful 설계를 위반하였기 때문에 메서드의 명확한 역할이 불분명해집니다.

2. RESTful

RESTful이란

  • REST 아키텍쳐 스타일을 따르는 API 설계 방식
  • 리소스를 효율적으로 관리하고 통신할 수 있도록 설계된 아키텍쳐 원칙
  1. 리소스 중심 설계 : URL을 통해 리소스 식별
  2. HTTP 메서드 활용 : GET, POST, PUT, PATCH, DELETE
  3. 표준 상태코드 사용 : 200 OK, 201 Created, 404 Not Found
  4. 무상태성 : 요청 간 클라이언트의 상태를 서버가 저장하지 않음
  5. 표현 계층
  6. 캐싱 가능
  7. 서버-클라이언트 분리

NOTE

REST와 RESTful의 차이를 설명하세요

REST는 아키텍쳐 스타일이며, RESTful은 REST의 원칙을 준수하여 설계된 API 입니다.

NOTE

RESTful API의 주요 구성 요소를 설명하세요

리소스를 식별하는 URI, 리소스의 동작을 정의하는 HTTP 메서드, 요청 결과를 전달하는 HTTP 상태코드, 요청과 응답 데이터를 포함한 헤더와 본문이 있습니다.

NOTE

RESTful 설계에서 URI를 정의할 때 주요 원칙은 무엇인가요?

리소스를 명확하게 식별할 수 있도록 설계하고, 동사가 아닌 명사로 표현하고, 계층 구조를 표현해야 합니다.

3. CORS

CORS란 무엇인가

Cross-Origin Resource Sharing

  • 교차 출처 리소스 공유
  • 웹 브라우저가 다른 출처의 리소스를 요청할 수 있도록 허용하는 보안 기능
  • 기본적으로는 동일 출처 정책을 적용하여 다른 출처에서 리소스 요청을 차단
  • CORS는 이런 제한을 완화해 안전하게 리소스를 공유할 수 있게 함

원인

  • 서버가 요청 출처를 허용하지 않음
  • 클라이언트 요청에 인증 정보가 포함되어 있는데 서버에서 Access-Control-Allow-Credentials를 설정하지 않음 해결방법
  • 서버에 적절한 Access-Control-* 헤더 추가
  • 특정 출처만 허용하거나 모든 출처(*) 허용

Access-Control-Allow-Origin : 응답을 허용할 출처 지정 Access-Control-Allow-Credentials : 클라이언트의 인증 정보를 포함한 요청을 허용할지 여부(T/F) Access-Control-Allow-Methods와 Access-Control-Allow-Headers : 허용할 HTTP 메서드/헤더 지정

NOTE

CORS 오류가 발생했을 때 어떤 점을 확인해야 하나요?

서버가 Access-Control-Allow-Origin 헤더를 올바르게 반환하는지 확인하고, 요청에 Access-Control-Allow-Methods/Headers가 필요한지 확인합니다. 만약 인증정보를 포함하는 요청을 보낼 때는 Cretentials가 true로 설정되었는지 확인합니다.

4. OSI 7계층, TCP/IP 4계층

OSI 계층과 그 존재이유, TCP/IP 4계층이란

각 계층은 하위 계층 기능을 이용하고, 상위 계층에 기능을 제공 일반적으로 상위 계층의 프로토콜은 소프트웨어, 하위계층은 하드웨어로 구현

NOTE

OSI 7계층에 대해 아는대로 설명해주세요

OSI 7 계층 모델은 네트워크 통신 과정을 이해하기 쉽게 단계별로 구분하여, 문제 발생 시 특정 계층만 집중적으로 다룰 수 있도록 설계되었습니다.

물리적으로 신호를 변환하는 물리계층, 물리계층에서 송수신된 데이터의 오류를 검출하고 교정하는 데이터 링크 계층, 데이터 패킷의 라우팅과 경로 선택이 이루어지는 네트워크 계층,  두 호스트간 신뢰성 있는 데이터 전송을 보장하는 전송 계층, 두 시스템간 통신 세션을 관리하는 세션 계층, 서로 다른 시스템간의 통신을 위해 변환, 압축, 암호화를 담당하는 표현 계층, 사용자와 직접 상호작용하여 서비스에 접근할 있게 하는 응용(어플리케이션) 계층이 있습니다.

  • OSI 모델이 실무적으로 이용하기 복잡해서 등장한 모델
  • OSI 모델보다 간단하고 실용적인 접근방식
  • 응용+전송+세션 = 응용
  • 전송 = 전송
  • 네트워크 = 인터넷
  • 데이터 링크 + 물리 = 링크

5. 서버 간 라우팅

웹 서버 소프트웨어(Apache, Nginx)의 서버 간 라우팅 기능은 OSI 7계층 중 어디서 작동하는지?

서버 간 라우팅

  • 여러 서버가 상호작용하거나 요청을 다른 서버로 전달하는 과정
  • 하나의 웹 서버가 다른 서버에 리버스 프록시를 설정하여 요청을 전달하거나 로드 밸런서를 사용해 여러 서버 간 트래픽을 분배하는 방식
  • 리버스 프록시 : Nginx나 Apache
  • 로드 밸런싱
  • API 게이트웨이

NOTE

웹 서버 소프트웨어(Apache, Nginx)의 서버 간 라우팅 기능은 OSI 7계층 중 어디에서 작동하는가?

웹 서버 소프트웨어인 Apache나 Nginx는 주로 OSI 모델의 7계층 (응용 계층)에서 작동합니다. 이들 서버는 클라이언트와 직접적으로 상호작용하며 HTTP(S)와 같은 응용 프로토콜을 처리합니다. 웹 서버는 요청을 받아서 적절한 응답을 생성하고, 필요할 경우 다른 서버로 요청을 전달하거나, 리버스 프록시를 통해 서버 간의 요청을 라우팅합니다.

NOTE

API 게이트웨이와 리버스 프록시의 차이점은 무엇인가요?

리버스 프록시는 클라이언트의 요청을 받아서 서버로 전달하는 역할만 수행합니다. 반면 API 게이트웨이는 리버스 프록시의 역할을 포함하여서도 인증, 로깅, 로드밸런싱, 캐싱 등 부가적인 기능을 제공합니다.

NOTE

HTTP메서드를 잘못 매핑했을 때 발생할 수 있는 문제 상황들에 대해 말씀해주세요.

  1. 잘못된 메서드로 요청을 보냈을 때 서버는 해당 URL에서 지정된 메서드만 허용합니다. 잘못된 메서드로 요청을 보내면 서버는 HTTP 405 Method Not Allowed 상태 코드를 반환합니다.
  2. 메서드에 따라 의도하지 않은 동작 발생 잘못된 메서드 매핑이 응답으로 이어질 경우, 의도하지 않은 동작이 발생할 수 있습니다. 예를 들어, DELETE를 사용해야 할 API에 GET을 매핑했다면, 클라이언트는 데이터를 조회하는 줄 알지만 실제로는 데이터를 삭제할 수도 있습니다.
  3. RESTful 원칙 위반 HTTP 메서드는 RESTful 설계에서 중요한 역할을 합니다. 메서드를 잘못 매핑하면 RESTful API 설계의 일관성을 해칩니다. 예를 들어: 리소스를 조회하는 작업에 POST를 매핑한다면, 클라이언트가 서버의 상태를 변경한다고 오해할 수 있습니다. 반대로, 리소스를 생성하는 작업에 GET을 사용하면 데이터 조회처럼 보이지만 실제로는 새로운 리소스가 생성됩니다.
  4. 보안 문제 잘못 매핑된 메서드로 인해 보안 취약점이 생길 수 있습니다. 예를 들어, GET 요청으로 리소스를 삭제할 수 있다면, 단순히 링크 클릭이나 악의적인 스크립트로 서버의 데이터를 삭제하는 문제가 발생할 수 있습니다 (CSRF 공격 등).
  5. API 클라이언트와의 불일치 API 사용자는 문서화된 메서드에 따라 요청을 보내기 때문에, 잘못된 매핑은 클라이언트와 서버 간의 동작 불일치를 초래합니다. 결과적으로 클라이언트는 올바른 요청을 보냈다고 생각하지만, 서버가 예상과 다른 응답을 반환하거나 요청이 실패합니다.

NOTE

RESTful API 설계에서 “무상태성”이 시스템 설계에 미치는 영향을 설명하고, 상태를 유지해야 하는 경우 어떻게 처리하나요?

무상태성의 장점:

서버가 클라이언트의 상태를 저장하지 않으므로 스케일 아웃(서버 확장)이 용이합니다. 각 요청은 독립적이며, 시스템이 복잡하지 않습니다. 상태를 유지해야 하는 경우:

인증/인가: 일반적으로 JWT(Json Web Token) 또는 세션 쿠키를 사용합니다. JWT는 클라이언트에 상태를 저장하는 방식이며, 서버의 무상태성을 유지합니다. 세션 쿠키는 서버에 상태를 저장하며, 무상태성 원칙에서 벗어날 수 있습니다. 서드파티 인증(OAuth2): 액세스 토큰을 사용해 상태를 관리합니다. 분산 캐싱: Redis와 같은 외부 캐시 시스템을 사용해 상태를 유지합니다. 예: 클라이언트의 진행 중인 작업 상태를 Redis에 저장하고 일정 시간 후 만료 처리합니다. 상태를 유지해야 하는 경우에도 가능한 한 무상태성을 유지하려 노력하는 것이 중요하며, 상태 저장이 필수적일 때에는 외부 시스템에 의존하여 서버 간 부하를 최소화합니다.

NOTE

Access-Control-Allow-Credentials와 보안상의 딜레마를 해결하기 위한 설계는 무엇인가?

Access-Control-Allow-Credentials: true는 클라이언트가 쿠키나 인증 헤더를 포함한 요청을 서버에 보낼 수 있도록 허용합니다. 하지만 이 설정은 특정 출처의 신뢰성을 악용한 공격(예: CSRF)에 취약합니다.

문제점:

  1. *와 동시 사용 불가:
    • Access-Control-Allow-Origin: *와 함께 사용하면 브라우저에서 오류가 발생.
  2. CSRF 취약점:
    • 클라이언트의 쿠키 기반 인증이 활성화되어 있을 경우 악성 사이트가 인증된 사용자로 가장하여 요청 가능.

보안 대안:

  1. 정확한 출처 지정:

    • Access-Control-Allow-Origin에 신뢰할 수 있는 특정 출처만 명시.
    http
코드 복사
Access-Control-Allow-Origin: <https://trusteddomain.com>

  2. CSRF 방지 토큰 사용:

    • 서버는 클라이언트가 요청 시마다 함께 보내는 CSRF 토큰을 검증.
    • CSRF 토큰은 세션과 무관하게 요청마다 고유해야 함.

  3. SameSite 쿠키 설정:

    • 쿠키에 SameSite=Strict 또는 SameSite=Lax를 설정하여 쿠키가 외부 출처에서 전송되지 않도록 제한.

  4. JWT 사용 시 Bearer 토큰으로 대체:

    • 쿠키 대신 Authorization 헤더에 Bearer 토큰을 사용하여 인증.

Graph View