웹과 네트워크 면접 질문

HTTP 프로토콜

• HyperText Transfer Protocol: 텍스트 기반의 통신 규약
• 인터넷에서 데이터를 주고받을 수 있는 프로토콜을 의미한다.
• 클라이언트 요청에 응답을 한 후 연결을 끊는 Connectionless 특징을 갖고 있습니다. 또한 연결이 끊기면 상태 정보를 유지하지 않는 Stateless한 특성이 있습니다.
  → HTTP 프로토콜이 상태를 유지하는 방법으로 쿠키와 세션이 있습니다.

 

 

HTTP 메서드

• GET 요청은 서버에 데이터를 요 - CRUD로 따지면 R(읽기)
• POST 요청은 서버에 데이터를 생성하는 것을 요청 - CRUD로 따지면 C(생성)
• PUT 요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성, 주로 전체 자원을 업데이트 하는데 쓰입니다. - CRUD로 따지면 C, U (생성, 수정)
  
• DELETE 요청은 서버에 데이터를 삭제할 것을 요청 - CRUD로 따지면 D(삭제)
• PATCH 요청은 서버에 존재하는 데이터를 일부 수정 - CRUD로 따지면 U(수정)

 

 

GET, POST 차이

GET

• GET은 서버에 데이터를 요청할 때 사용합니다.
• GET은 브라우저에 캐싱이 됩니다.
• GET 방식은 데이터가 HTTP Request Message의 Header에 url 이 담겨서 전송됩니다. 파라미터를 보낼 시 url 상에 데이터를 붙여 request를 보내게 되기 때문에 전송할 수 있는 데이터의 크기가 제한적이고 보안이 필요한 데이터는 GET 방식이 적절하지 않습니다.

 

POST

• 서버에 데이터를 생성하기 위해 요청할 때 사용합니다.
• 브라우저에 캐싱이 되지 않습니다.
• POST 방식의 데이터는 HTTP Request Message의 Body 부분에 담겨서 전송됩니다.
• 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다 크다
• 보안면에서 GET 방식보다 안전하다.

 

 

HTTP 상태코드

• 1xx (정보) : 요청받았으며, 프로세스가 계속 진행
• 2xx (성공) : 요청 성공
• 3xx (리다이렉션) : 요청 완료를 위해 추가 작업 조치 필요
• 4xx (클라이언트 오류) : 요청의 문법이 잘못되었거나 요청 처리를 할 수 없음
• 5xx (서버 오류) : 요청은 유효하지만 서버에서 처리할 수 없음

 

• 200(OK): 요청이 성공으로 처리됨.
• 201(Created): 요청에 따라 데이터가 생성, 수정되었음.
• 400(Bad Request): 요청이 잘못되었음. (요청 데이터 내용 등)
• 401(Unauthorized): 인증이 되지 않은 경우
• 403(Forbidden): 권한이 없는 경우
• 404(Not Found): 요청받은 리소스를 찾을 수 없음
• 500(Internal Server Error): 서버에서 에러가 났을 경우, 예측하지 못하는 모든 에
• 503(Service Unavailable): 서버가 요청을 처리할 준비가 되지 않음.

 

 

HTTP 요청 흐름

1. 브라우저에 www.youtube.com을 입력한다
2. 브라우저는 캐싱된 DNS 기록이 존재하는지 확인합니다.
   (자신의 로컬 hosts파일 / 브라우저 캐시 / OS캐시 / Router캐시 / ISP캐시)
   존재하지 않는다면 DNS 서버를 통해 해당 URL을 IP주소로 변환합니다.
3. 라우터의 라우팅을 통해 네트워크 경로를 알아냅니다.
4. 실질적인 통신을 하기 위해 논리 주소인 IP주소를 물리 주소인 MAC 주소로 변환해야 합니다. 네트워크 내에서 ARP를 브로드 캐스팅하면 해당 IP주소를 가지고 있는 노드는 MAC 주소를 응답합니다.
5. TCP 연결(3-way-handshake)하고 유튜브 서버에게 요청합니다.
6. 유튜브 서버는 HTTP 요청을 보고 데이터를 패킷 및 TCP 번호로 준비한다.
7. 유튜브 서버는 상태코드와 함께 응답을 보내줍니다.
8. 웹 페이지에 표시한다.

 

 

HTTP / HTTPS 

HTTP

HTTP는 평문 통신이다. TCP/IP 특성상 패킷을 수집하는 것만으로 도청이 가능하며, 통신 상대를 확인하지 않기 때문에 위장이 가능하고 완전성을 증명할 수 없기 때문에 변조가 가능하다.

보안 방법은 통신 자체를 암호화(SSL, TLS)하거나, 콘텐츠(HTTP 메시지에 포함되는 콘텐츠)를 암호화 하는 것이다.

도청이 가능한 문제, 사용자를 확인할 수 없다는 문제, 정확성을 보장할 수 없다는 문제를 모두 해결할 방안으로 나온 것이 HTTPS이다.

 

HTTPS = HTTP + SSL
HTTP에서 SSL 개념을 더해 보안이 강화된 프로토콜입니다. 기존 HTTP는 TCP와 직접 통신했지만, HTTPS는 HTTP와 TCP 사이에 SSL 끼워져있습니다. SSL 프로토콜을 통해 암호화함으로써 안전하게 데이터를 전송할 수 있습니다.
SSL의 원리: 대칭키와 공개키 방식 두 암호화 방식을 사용한다.

 

차이점

HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷이 가로채질 위험이 있습니다. 보안 취약점을 보완하기 위해 나온 것이 HTTPS입니다. 중간에 암호화 계층을 거쳐서 패킷을 암호화합니다.

 

 

HTTP 1.0 / 2.0 / 3.0 차이

• HTTP/0.9
  사용 가능한 메서드는 GET이 유일
  HTTP 헤더가 없기 때문에 전송은 HTML 문서만 가능
  응답은 오로지 파일 내용 자체로 구성( 상태 혹은 오류 코드가 존재하지 않았음)
• HTTP/1.0
  HTTP 헤더 개념 도입
  HTML 파일들 외에 다른 문서들을 전송하는 기능 추가(Content-type)
  상태 코드 주입( 응답 시작 부분에 상태 코드가 붙게 되면서 브라우저가 요청 성공 실패 여부를 알 수 있음)
  POST 메서드 추가
• HTTP/1.1 -  표준 프로토콜
  첫 번째 표준 버전이며, 메서드에 OPTION, PUT, DELETE, TRACE가 추가되었음
  기존 모델의 단점을 해결하고자 1번 열린 커넥션을 재사용하는 Persitent Connection이라는 개념과
  여러 개의 HTTP 요청을 할 수 있는 HTTP Piplelining이라는 개념이 도입되었다.
  Connection당 하나의 요청을 처리 하도록 설계되어 있어 동시전송이 불가능하고 요청과 응답이 순차적으로 이루어지게 됩니다. 때문에 요청할 리소스 개수에 비례해서 대기시간이 길어집니다.
• HTTP/2.0
  HTTP 메시지를 바이너리 형태의 프레임으로 나누고 TCP 연결 하나로 여러 요청과 응답들을
  병렬적으로 보내는 특징을 가지며 순서가 뒤섞이더라도 수신 측에서 재조립한다.
  따라서 여러 개의 연결 없이 병렬 처리도 가능해지며 HOLB문제도 해결
• HTTP/3.0
  HTTP 3.0 버전은 UDP를 기반으로 하는 QUIC 프로토콜을 사용
  QUIC 프로토콜을 사용함으로써 새로운 연결에 대한 HandShake로 인한 Latency를 감소
  QUIC 프로토콜 : TCP가 가지는 문제점을 해결하고자 구글이 개발한 UDP 기반의 프로토콜

 

 

 

TCP / UDP 차이

TCP

• TCP는 연결 지향형 프로토콜입니다. 3-way-handshake를 통해 연결을 수립하여 신뢰도를 확보하여 순서를 보장합니다. 대신 UDP보다 속도가 느립니다.
• 흐름제어, 오류제어, 순서 중요함, 오류시 재전송. 종단간에 신뢰성 있는 바이트 스트림을 전송 하도록 특별히 설계되었다. TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어진다. 

UDP

UDP는 비연결형 프로토콜입니다. TCP와 다르게 데이터를 주고 받을 때 데이터의 순서를 보장하지 않고 데이터가 상대방에게 온전히 전달되지 않아도 재전송을 하지 않습니다. 신뢰성이 떨어진다는 단점이 있지만 데이터 수신 여부를 확인하지 않기 때문에 속도가 빠릅니다.

(CheckSum 필드를 통해 최소한의 오류만 검출한다.)

(만약 클라이언트 timeout이 발생하면 다시 보낸다.)

 

 

3-way-handshake

TCP 네트워크에서 가상 회선을 수립하는 단계입니다. 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정이다.  

4-way-handshake는 TCP 연결을 해제하는 단계입니다. 클라이언트는 서버에게 연결 해제를 통지하고 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 최종적으로 연결이 해제된다.

 

 

CORS(Cross Origin Resource Sharing)

서로 다른 도메인 간에 자원 공유를 의미합니다. 기본적으로 보안상의 이유 때문에 출처가 다른 서버의 자원을 요청하면 CORS에러가 발생합니다. CORS 에러는 헤더를 통하여 다른 origin의 리소스에 접근을 허용하는 방법으로 해결이 가능합니다.

 

Access-Control-Allow-Origin: 특정 브라우저가 리소스에 접근이 가능하도록 허용합니다.

Access-Control-Allow-Method: 특정 HTTP Method만 리소스에 접근이 가능하도록 허용합니다.

Access-Control-Expose-Headers: 자바스크립트에서 헤더에 접근할 수 있도록 허용합니다.

credentials: 쿠키 등의 인증 정보를 전달할 수 있습니다.

 

 

CSRF(Cross-Site Request forgery)

사이트 간 요청 위조의 약자로, 사용자가 의도한 요청이 아닌 공격자가 의도한 행위를 하게하는 공격 방법이다.

• CSRF 공격 방지
  • 요청 헤더에서 referrer를 확인하여 도메인이 일치하는지 확인하는 방법
    같은 도메인에서 들어오는 접속을 허용하고 다른 도메인에서 호출할 때는 차단한다.
  • 상태를 변화시키는 POST, PUT 요청인 경우 csrf 토큰이 포함시켜야만 요청 처리하는 방법

 

 

OSI 7 계층

• OSI 7 계층은 네트워크 통신을 구성하는 요소들 7개의 계층으로 표준화한 것이다.
• 표준화하는 것의 장점으로는 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기 용이해진다.
• 계층 설명
  • 7 계층(응용 계층)
    사용자에게 통신을 위한 서비스 제공. 인터페이스 역할
  • 6 계층(표현 계층)
    데이터의 형식(Format)을 정의하는 계층 (코드 간의 번역을 담당)
  • 5 계층(세션 계층)
    컴퓨터끼리 통신을 하기 위해 세션을 만드는 계층
  • 4 계층(전송 계층)
    TCP와 UDP 프로토콜을 통해 통신 활성화하여 데이터의 전송을 담당하는 계층 (단위 :세그먼트) (ex. TCP, UDP)
  • 3 계층(네트워크 계층)
    라우터를 통해 IP를 기반으로 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층 (단위 :패킷) (ex. Router)
  • 2 계층(데이터링크 계층)
    송/수신 확인, MAC Address로 통신한다. (단위 :프레임) (ex. 이더넷)
  • 1 계층(물리 계층)
    데이터를 전기 신호로 변환해서 전송하는 계층 (단위 :bit) (장비: 케이블,리피터,허브)

 

 

TCP/IP 계층

통신에 실제 사용되는 계층(프로토콜 스택).

1,2 계층이 1 계층, 5,6,7 계층이 4 계층으로 운영된다.

• 네트워크 엑세스 계층
  물리적인 계층으로 데이터가 어떻게 전송되는 지를 정의한 계층
• 인터넷 계층
  IP주소를 사용하고 라우팅을 통해 데이터를 목적지까지 전달하는 계층
• 전송 계층
  EndPoint 간 신뢰성 있는 데이터 전송을 담당하는 계층
  패킷의 수신을 확인하고 올바른 순서로 패킷이 전달되도록 보장합니다.
• APPLICATION 계층
  사용자로부터 데이터를 입력받고 처리된 데이터를 보여주는 사용자 응용프로그램 인터페이스 계층

 

 

DNS란?

도메인 이름으로 IP 주소를 알아내는 서비스이다.

인터넷은 컴퓨터를  IP주소로 식별합니다. 하지만 사람이 숫자를 기억하기 힘들기 때문에 DNS를 사용하여 호스트의 도메인 이름을 기반으로 IP주소를 취득할 수 있습니다.

 

 

도메인 이름으로 IP 찾는 흐름

 

 

 

 

MTU

네트워크에 연결된 장치가 받아들일 수 있는 최대 데이터 패킷 크기를 말합니다.
MTU가  크면 커다란 크기의 패킷을 처리할 수 없는 라우터를 만났을 때 재전송해야 하거나 분할로 인해 대기 시간이 늘어나 비효율 적입니다.

MTU가 너무 작으면 상대적으로 오버헤드가 너무 커지게 됩니다.

 

 

ISP

Internet Service Provider로 다양한 회선 상품을 제공하며 기업마다 서비스가 다르다.

 

VPN

Virtual Private Network, 가설사설망으로 ISP에 정보를 넘겨주지 않고 익명성을 유지하여 인터넷에 접속할 수 있다.

 

 

 

쿠키와 세션

HTTP 프로토콜은 Stateless 특성이 있어 서버는 클라이언트가 누구인지 매번 확인을 해주어야 합니다. 이를 보안하는 방법으로 쿠키가 있습니다.

 

쿠키와 세션의 가장 큰 차이점은 정보가 저장되는 위치입니다. 쿠키는 웹 브라우저 즉 클라이언트 측에, 세션은 서버 측에 저장되고 관리됩니다. 어디에 저장해야 할지는 정보의 특성에 따라 달라집니다. 사용자의 편의를 위하되 보안에 문제가 생기지 않을 만한 정보는 쿠키에 저장하고, 다른 누군가에게 노출되면 안되는 정보는 세션에 저장합니다.

그렇다고 데이터를 모두 세션에 저장하게 된다면 접속자가 많을 때 서버에 부담이 커지게 됩니다. 따라서 개발자가 적절하게 분배하여 저장해주어야 합니다.

 

쿠키

• 서버가 사용자의 웹 브라우저(로컬)에 저장하는 데이터
• 데이터 형태는 Key-Value 한 쌍이 String 형태로 저장된다.
• 쿠키는 로그인 유지 시간, 아이디 저장 등 보안이 중요하지 않은 정보들을 저장한다.
• 서버가 데이터를 갖고있는 것이 아닌 웹이 갖고있기 때문에 보안이 취약하다.

세션

• 쿠키를 기반으로 하여, 사용자 정보 파일을 서버에 저장하고 관리한다.
• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증 상태를 유지한다.

 

 

세션 / 토큰 차이

• 세션 기반 인증방식
  
  • 세션 정보를 서버 측에 저장하여 사용자를 검증하는 방식이다. Stateful한 구조를 갖는다.
    • 서버에 과부화를 줄 수가 있다.
    • 보안 문제가 있다.(세션 하이재킹 공격)
• 토큰 기반 인증방식
  • 토큰을 발급하여 서버 측 DB에 저장하지 않고, 클라이언트 측에 저장합니다.
  • 클라이언트가 서버에 요청 시 토큰을 함께보내도록 하여 유효성 검사를 합니다.

 

로드밸런싱을 위해 서버를 scale-out하면서 사용자가 상태를 유지하기 위해서는 서로 다른 서버간의 세션 동기화 작업이 필요해졌습니다. 스티키 세션, 세션 클러스터링, 세션 스토리지 분리 같은 방안이 나왔지만 비용과 번거로움이 문제였습니다. 이로 인해 Token 기반 인증 방식이 나오게 되었고 이로 인해 서버 확장이 용이해졌습니다.

 

 

JWT

JSON 포맷을 이용하는 웹 토큰으로 인증에 필요한 정보들을 암호화시킨 토큰입니다. 클라이언트가 토큰을 전달할 때는 HTTP 헤더(Bearer)에 실어 전달합니다.

• Header, Payload, Signature로 구성된다. 구분자는 점(.)이다.
  • Header: 토큰 타입 및 알고리즘 방식
  • Payload: 토큰에 담을 정보를 지니고 있습니다. JSON 형태로 이루어진 한 쌍의 정보를 Claim이라 합니다.
  • Signature: 인코딩된 Header와 Payload를 더한 뒤 비밀키로 암호화한 것으로 토큰의 위변조 여부 확인

 

• 장점
  • 인증 정보에 대한 별도의 저장소가 필요없다.
  • JWT는 자체적으로 모든 정보를 지니고 있다. (전달할 정보와 서명 등)

 

• 단점
  • 토큰의 길이가 길어, 인증 요청이 많아지면 네트워크 부하 위험이 있다.
  • Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
  • 토큰이 탈취 당하면 발급 되면 유효기간이 만료될 때까지 계속 사용될 위험이 있다.

 

• 대처
  1. 유효기한을 짧게 설정 : 토큰이 탈취 당해도 유효기간이 짧으면 피해를 최소화할 수 있다. 사용자가 로그인을 자주해야 하는 불편 사항이 있다.
  2. RefreshToken : Access Token 보다 긴 유효 기간을 가진 Refresh Token을 발급한다. Access Token이 만료 되었을 경우 Refresh Token을 사용하여 Access Token의 재발급을 요청하는 방식이다. 이 방식은 Access Token의 유효기간을 짧게 설정하여도 사용자에게 불편함을 주지 않고 서버가 강제로 Refresh Token을 만료시킬 수 있다.
     하지만 서버가 Refresh Token을 별도로 저장하고 있어야하기 때문에 JWT의 장점을 완전히 누릴 수 없다.

 

 

 

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

• 웹 서버는 HTTP 요청을 받아 정적인 웹 페이지 형태로 응답을 처리해 반환하는 프로그램입니다. 예로는 Nginx와 Apache 등이 있습니다.
• 반면 웹 어플리케이션 서버는 요청을 받으면 로직을 처리하여 동적 컨텐츠를 제공하는 역할을 합니다. 
• 웹 어플리케이션 서버 앞에 웹 서버를 둬서 정적인 컨텐츠를 처리하고, 웹 어플리케이션 서버는 동적인 컨텐츠를 수행하도록 기능을 분배하여 서버의 부담을 줄일 수 있습니다.

 

 

 

REST API란?

REST는 HTTP 기반으로 자원에 접근 방식을 정해놓은 아키텍처 스타일입니다.

HTTP 메서드와 URI를 통해 행위와 자원을 명시합니다.

REST 설계 규칙에 따라 개발한 API를 Rest API라고 합니다.

 

 

 

API Gateway란?

• 서비스로 전달되는 모든 API 요청의 관문 역할을 하는 서버입니다. 시스템의 아키텍처를 내부로 숨기고 외부의 요청에 대한 응답만을 적절한 형태로 응답합니다. 
• 클라이언트 요청을 일과적으로 처리할 수 있고, 시스템의 부하를 분산시키는 로드 밸런서의 역할을 할 수 있습니다.

 

 

로드 밸런싱

컴퓨터 네트워크의 기술로 2개 이상의 CPU 저장장치 같은 컴퓨터 자원들에게 부하를 나누어 할당하는 것을 의미합니다.

서버 부하를 처리하기 위한 방법으로는 기존에 갖고 있는 성능을 압그레이드하는 scale-up 방법과 여러 대의 서버를 더 증설하는 scale-out 방법이 있습니다.

 

 

OAuth

사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해서 접근 권한을 부여할 수 있는 공통적인 수단입니다. 카카오, 네이버, 구글 로그인를 예로 들 수 있습니다.