백엔드 기술 면접 질문(WEB)

Minu Jeong·2022년 8월 13일

브라우저에서 URL치면 발생하는 일

브라우저에 maps.google.com을 입력했을 때 일어나는 일들을 여덟 단계로 정리할 수 있습니다.

브라우저 주소창에 maps.google.com을 입력한다.

브라우저가 maps.google.com의 IP 주소를 찾기 위해 캐시에서 DNS 기록을 확인한다.

만약 요청한 URL(maps.google.com)이 캐시에 없다면, ISP의 DNS 서버가 DNS 쿼리로 maps.google.com을 호스팅하는 서버의 IP 주소를 찾는다.

브라우저가 해당 서버와 TCP 연결을 시작한다.

브라우저가 웹서버에 HTTP 요청을 보낸다.

서버가 요청을 처리하고 응답을 보낸다.

서버가 HTTP 응답을 보낸다.

브라우저가 HTML 컨텐츠를 보여준다.

쿠키, 세션, 토큰

쿠키 개념 및 동작방식

쿠키,

쿠키는 클라이언트 로컬에 저장되는 키 / 값이 포함된 데이터 파일입니다.

인증 유효시간을 명시할 수 있으며, 유효시간 동안은 브라우저가 종료되어도 인증이 유지됩니다.

쿠키는 클라이언트의 상태 정보를 로컬에 저장하고, 저장한 내용을 참조합니다.

클라이언트에 300개까지 쿠키 저장이 가능하며, 도메인당 20개의 값을 가질 수 있습니다. 하나의 쿠키값은 4KB까지 저장할 수 있습니다.

Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있습니다.

쿠키는 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송합니다.

동작 방식
1. 클라이언트가 페이지 요청
2. 서버에서 쿠키를 생성
3. HTTP 헤더에 쿠키를 포함시켜 응답
4. 브라우저가 종료되어도 쿠키 유효시간동안 클라이언트에서 보관
5. 같은 요청 시 HTTP 헤더에 쿠키를 함께 전송
6. 이전 상태 정보를 변경 할 필요가 있다면, 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

세션 개념 및 동작방식

세션,

세션은 쿠키를 기반하고 있지만, 사용자 정보를 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리합니다.

서버에서 클라이언트를 구분하기 위해 세션 ID를 부여하며, 브라우저가 서버에 접속해서 종료될 때까지 인증상태를 유지합니다.

접속 시간에 제한을 두어 일정 시간 응답이 없으면 정보가 유지되지 않게 설정도 가능합니다.

사용자 정보를 서버에 두기 때문에 쿠키보다 보안에는 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 됩니다.

동접자 수가 많은 웹 사이트인 경우, 서버에 과부하를 주게 됨으로 성능 저하의 원인이 됩니다.

클라이언트 Request를 보내면, 서버의 엔진이 클라이언트에게 유일한 ID를 부여합니다. 이 ID가 세션ID 입니다.

동작 방식
1. 클라이언트가 서버에 접속 시 세션 ID를 발급 받음
2. 클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있음
3. 클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청
4. 서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라언트 정보를 가져와서 사용
5. 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답

쿠키와 세션

쿠키와 세션은 비슷합니다. 그 이유는 세션도 결국 쿠키를 사용하기 때문입니다.
가장 큰 차치점은 사용자의 정보가 저장되는 위치입니다. [ 쿠키 : 클라이언트(로컬) | 세션 : 서버 ]
보안 면에서는 세션이 쿠키보다 우수하지만 요청 속도는 세션보다 쿠키가 더 빠릅니다. (세션은 서버의 처리가 필요)

사용자 정보 저장 위치

쿠키 : 클라이언트 (로컬)

세션 : 서버

보안

쿠키 : 쿠키는 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어 보안에 취약합니다.

세션 : 세션은 쿠키를 이용해서 세션ID만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다.

유효시간

쿠키 : 유효시간이 있고 파일로 저장되기 때문에 쿠키를 삭제하지 않는 이상 브라우저가 종료되도 유효시간까지 정보가 남아 있을 수 있습니다. (로컬에서 관리)

세션 : 세션도 유효시간을 설정할 수는 있지만, 브라우저가 종료되면 설정된 유효시간이 만료되지 않았더라도 삭제됩니다. (서버에서 관리)

속도

쿠키 : 쿠키파일에 정보가 있기 때문에 서버에 요청시 속도가 빠릅니다.

세션 : 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다.

토큰

토큰,

유저가 인증에 성공하면 서버는 토큰을 생성해서 클라이언트로 전달합니다.

토큰과 세션의 방식을 비슷한데 차이가 있습니다.

세션 인증에서는 서버가 세션ID를 저장하고 클라이언트가 쿠키로 보낸 세션ID와 대조해서 확인하지만,

토큰을 사용하면 요청을 받은 서버는 토큰이 유효한지만 확인 합니다.

토큰 인증이 세션에 비해 서버에 부하가 덜 합니다.

작동방식
1. 사용자가 아이디와 비밀번호로 로그인을 한다.
2. 서버 측에서 해당 정보를 검증한다.
3. 정보가 정확하다면 서버 측에서 사용자에게 Signed 토큰을 발급한다
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할때마다 해당 토큰을 서버에 함께 전달한다. 이때 HTTP 요청 헤더에 토큰을 포함시킨다.
5. 서버는 토큰을 검증하고, 요청에 응답한다.

토큰 기반 인증

인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 클라이언트 측에서 유효성을 검사를 합니다.
즉, 서버에서 고객의 정보를 유지 하지 않기 때문에 이를 Stateless Server라고 부릅니다.

JWT

JWT는 일반적으로 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authorization)를 위해 사용하는 토큰이다. URL에대해 안전한 문자열로 구성되어 있기 때문에 HTTP 어디든(URL, Header, ...) 위치할 수 있습니다.

JWT의 구조
JWT는 "." 을 기준으로 HEADER / PAYLOAD / SIGNATURE 로 나뉩니다.
HEADER.PAYLOAD.SIGNATURE
Header
JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 Base64 URL-Safe 인코딩된 문자열이다.
헤더(Header)는 JWT를 어떻게 검증(Verify)하는가에 대한 내용을 담고 있다. 즉 alg는 3번째 값인 서명 값을 어떤 알고리즘으로 만들지 적혀 있습니다.
{
    "alg": "ES256",
    "kid": "Key ID"
}
Payload
JWT의 내용이다. 페이로드(Payload)에 있는 속성들을 클레임 셋(Claim Set)이라 부른다.
클레임 셋은 JWT에 대한 내용(토큰 생성자(클라이언트)의 정보, 생성 일시 등)이나 클라이언트와 서버 간 주고 받기로 한 값들로 구성된다.
{ 	
	"iss": "jinho.shin", 
	"iat": "1586364327" 
}
Signature

누군가 JWT를 탈취하여 수정한 후 서버로 보낼 수 있습니다. 이 경우에 대비해 다른 사람이 위변조 했는지 검증하기 위한 부분입니다.

서명은 헤더의 인코딩 값, 정보의 인코딩 값을 합친 후 비밀키로 해쉬를 하여 생성합니다.

서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 성성하고 Base64 URL-Safe로 인코딩한다

완성된 JWT는 헤더의 alg, kid 속성과 공개 키를 이용해 검증할 수 있다. 서명 검증이 성공하면 JWT의 모든 내용을 신뢰할 수 있게되고, 페이로드의 값으로 접근 제어나 원하는 처리를 할 수 있게된다.

장점
인가를 위해 서버가 별도로 저장하는 경우가 없다. 이를 stateless 하다고 표현한다.

단점

데이터 증가에 따른 네트워크 부하 증가
모든 요청에 대해서 토큰이 전송되므로 토큰에 담기는 정보가 증가할 수록 네트워크 부하가 증가합니다. 그래서 보통 약자가 많이 사용됩니다.

Self-contained
토큰 자체에 정보를 담고 있습니다. JWT가 만료시간 전에 탈취당하면 서버에서 할 수 있는 것이 없습니다.
즉, 서버가 토큰에 대한 통제력을 가지고 있지 않습니다.

Stateless
JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능합니다. 토큰을 임의로 삭제하는 것이 불가능하므로 만료 시간을 꼭 넣어 주어야 합니다.

보완점
최초 로그인을 하면,
1) 만료시간이 짧은 Access 토큰
2) 만료시간이 매우 긴 Refresh 토큰
을 모두 부여합니다. 이후에, refresh에 대한 상응 값은 데이터베이스에 저장합니다.
유저의 access 토큰이 기한을 다하면, refresh 토큰을 보내면 저장된 값과 비교하여 맞으면 Access 토큰을 재발급 해준다.

OAuth

OAuth란 특정 애플리케이션이 다른 애플리케이션의 정보에 접근할 수 있는 권한을 관리하는 프로토콜 입니다.

JWT가 과일이라면 OAuth는 과일을 담는 상자라고 볼 수 있다.
JWT는 Token의 한 형식이고, OAuth는 하나의 Framework이다.

여기서 OAuth가 Framework인 이유는
1. 토큰을 요청할 때 사용할 수 있어야하는 요청 및 응답의 순서와 형식만 있다.
2. 각기 다른 시나리오에서 어떤 방식으로 권한 부여 유형을 사용할지 정한다.

물론 Auth Framework를 통해 나온 OAuth Bearer token과 단순한 JWT 토큰은 차이가 있다.
OAuth Token은 어떤 사용자의 정보와 같은 중요한 정보가 있는 토큰이 아니다. 그래서 이 토큰을 사용하는 사용자는 이 토큰이 가지고 있는 정보에 대해서 아는 바가 전혀 없다.
OAuth Token이 가지고 있는 정보는 일련의 랜덤한 문자열인데, 이는 일종의 Pointer로 OAuth Framework로 들어가서 해당 정보가 저장되어 있는 주소를 확인할 수 있는 인식표이다.
물론 이때 토큰이 JWT 유형의 토큰이 될 수도 있다.!

반대로 JWT 토큰은 명확한 정보를 가지고 있는 토큰이다.
토큰의 크기는 300 ~ 500 byte. 혹은 가지고 있는 속성 정보에 따라 더 커지기도 한다.
이 때문에 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없는 문제점이 있고, 토큰이 커지면서 주고 받는 데이터 트래픽 크기에 영향을 미칠 수 있는 단점이 있다.

캐시

데이터나 값을 미리 복사해 임시로 저장해 두는 장소

사이트를 불러 올 때 전에 불러 왔던 사진을 접속 때 마다 불러오면 데이터의 낭비를 일으킨다.
캐시를 통해 클라이언트에 저장해둘 수 있으며 주기적으로 비워줘야한다.

URI, URL, URN에 대해서

URI (Uniform Resource Identifier)
인터넷 자원을 나타내는 고유 식별자 입니다. URI 에 I 가 Identifier 입니다. 인터넷에 있는 자료의 id 이다, 라고 생각하면 좋을 것 같습니다. 다른 자료가 똑같은 이름을 가지고 있으면 안되겠죠? 그래서 URI 는 유일해야합니다.

URL (Uniformed Resource Locator)

프로토콜 포함

해당 자원의 위치, Path를 의미

일반적으로 사이트 도메인을 자주 의미함.

웹 상 뿐만 아니라 컴퓨터 네트워크상의 자원은 모두 나타낼 수 있다.

URN (Uniformed Resource Name)

프로토콜 포함 X

해당 자원의 이름을 의미

독립적인 자원 지시자

Page 이후 부분까지 포함

요약
1. URI 는 네트워크 상 자원을 가리키는 일종의 고유 식별자(ID) 이다.
2. URL, URN 은 URI 에 포함되는 개념이며 URL 은 자원의 위치, URN 은 자원의 이름 을 의미한다.

REST, REST API, RESTful 이란?

REST란 무엇이고, RESTful하게 API를 디자인한다는 것은 무엇인지 설명하시오.

🏻 REST는 Representational State Transfer의 약자입니다. 간단히 말해서 URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는 것입니다. REST의 요소로는 크게 리소스, 메소드, 메세지 3가지 요소로 구성됩니다. 예를 들어 "이름이 Tom인 사용자를 생성한다." 라는 호출이 있을 때 "사용자"는 생성되는 리소스, "생성한다."라는 행위는 메소드, 그리고 "이름이 Tom인 사용자"는 메세지가 됩니다. 즉 리소스는 http://myweb/users라는 형태의 URI로 표현되며, 메소드는 HTTP Post, 메세지는 JSON 문서를 이용해서 표현됩니다. HTTP에는 여러가지 메소드가 있지만 REST에서는 CRUD에 해당하는 4가지의 메소드 GET, POST, PUT, DELETE를 사용합니다. REST는 리소스 지향 아키텍쳐 스타일이라는 정의에 맞게 모든 것을 명사로 표현하며 각 세부 리소스에는 id를 붙입니다.

🏻 Restful하게 API를 디자인한다는 것은 URI를 규칙에 맞게 잘 설계했는지의 여부입니다. 규칙의 항목으로는 아래와 같습니다.
1. 동일한 URI(End point)의 행위에 맞게 POST, GET, DELETE, PATCH등의 메소드를 사용한다.
2. 명사를 사용한다. 리스트를 표현할 때는 복수형을 사용한다.
3. URI Path에 불필요한 파라미터를 넣지 않는다. 즉, 단계를 심플하게 설계한다.

REST API 장점, 단점

(1) METHOD 처리방식의 제한
자원 처리 방식에 대해 정의하는 방식이 제한적이다. POST, GET, PATCH, HEAD, PUT, DELETE 를 제공하고 있는데, 만약 메일 보낸다고 한다면 어떤 메소드로 처리하는 것이
맞을까? 무언가를 생성하고 있는가? 데이터를 가져오는가? 수정하는가? 삭제하는가?

(2) 표준의 부재
공식화된 API 가이드가 존재하지 않으며, 개발자들이 쌓아올린 약속들을 바탕으로 구성되었고, 사용되고 있다. 표준이 없다는 것은 아직 더 발전하고 확장될 수 있다는 가능성을
의미하지만, 한편으로는 명확한 표준이 필요하다.

REST API에서 stateless의 장단점

REST API에서 stateless의 장점과 단점은 무엇입니까?

stateless의 장점:

stateless를 통해 API를 수백만 명의 동시 사용자로 확장할 수 있습니다. 세션과 관련된 의존 항목이 없기 때문에 모든 서버에 배치할 수 있습니다

서버는 각 클라이언트가 어플리케이션에서 "위치"를 알고 있습니다. 필요한 모든 정보가 요청마다 발송되기 때문입니다

stateless를 통해 REST API는 서버 측 동기화와 관련된 모든 복잡성을 제거합니다

stateless의 단점:

고객이 요청할 때마다 추가 정보를 보내야 함

데이터 중복 전송은 네트워크 성능을 저하시킬 수 있음

stateless는 서버측의 응용 프로그램 행위 제어도 감소

HTTP 1,2,3의 차이

HTTP 1.1

비연결지향(connectionless)
클라이언트가 서버에 리소스 요청한 후 응답 받으면 연결을 끊어버리는 특징이다.
서버에 부담을 주지 않도록 클라이언트 요청을 처리하면 연결을 끊어 서버의 부담을 줄인다. 하지만 리소스를 요청할 때마다 새롭게 연결해야 되므로 오버헤드 비용이 발생한다. (RTT 증가, 네트워크 성능 저하)
오버 헤드 해결 방법:

요청 헤더 connection:keep-alive 속성으로 지속적 연결 상태(persistent connection)을 유지한다.

요청을 할 때마다 연결하지 않고 기존의 연결을 재사용하는 방식으로 HTTP/1.1부터는 지속적 연결 상태가 기본이고 해제하기 위해서는 명시적으로 요청 헤더를 수정해야 한다.

파이프라이닝: http/1.1의 connection 당 하나의 요청 처리를 개선하는 방법 중 파이프라이닝이 존재한다. connection을 통해 다수개의 파일을 요청/응답 받는 기법

무상태성 (stateless)

각각의 요청은 독립적이라고 여겨지는 특성으로 서버는 클라이언트의 상태를 유지하지 않는다.

요청이 처리되면 연결이 끊어지기 때문에 클라이언트의 이전 상태를 알 수 없다. connectless로부터 파생되는 특징이다.

클라이언트가 과거에 로그인을 해도 로그 정보를 유지할 수 없다. 웹 서비스를 하기위해서 쿠키나 세션 또는 토큰 방식의 OAuth 및 JWT가 사용된다.

동시 전송이 불가능하고 요청과 응답이 순차적으로 이루어진다. HTTP문서 안 다수의 리소스를 처리하려면 Latency(대기시간)이 길어진다

HTTP/1.1 단점

HOL (Head of Line) blocking: 특정 응답의 지연
http/1.1의 connection 당 하나의 요청 처리를 개선하는 방법 중 파이프라이닝이 존재
connection을 통해 다수개의 파일을 요청/응답 받는 기법

RTT (round trip time) 증가
하나의 connection에 하나의 요청을 처리하면서 매 요청별로 connection이 연결되기 때문에 TCP 상에서 동작하는 HTTP 특성상 3- way handshake가 반복적으로 일어나 불필요한 RTT 증가와 네트워크 지연을 일으켜 성능을 저하시킨다

무거운 header 구조 (ex. 쿠키)
헤더에 많은 메타 정보를 저장한다
매 요청시마다 중복된 header값을 전송하게 되며 해당 domain에 설정된 cookie 정보도 매 요청시 마다 헤더에 포함되어 전송된다
전송하는 값보다 헤더 값이 더 큰 경우도 있다.

HTTP 3.0 과 HTTP 2.0 비교

구분 HTTP 2.0 HTTP 3.0
헤더압축 가능 가능
스트림 전송 가능 가능
멀티플렉싱 가능 가능
기반프로토콜 TCP UDP
속도 상대적으로 느림 상대적으로 빠름
암호화 지원 지원
CPU 부하 감소 증가

구분	HTTP 2.0	HTTP 3.0
헤더압축	가능	가능
스트림 전송	가능	가능
멀티플렉싱	가능	가능
기반프로토콜	TCP	UDP
속도	상대적으로 느림	상대적으로 빠름
암호화	지원	지원
CPU 부하	감소	증가

HTTP

HyperText Transfer Protocol 또는 HyperTexT Protocol의 약자.
최초 개발시 HTTP의 의미는 하이퍼텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로 즉, HTTP는 서버와 클라이언트의 사이에서 어떻게 메시지를 교환할지를 정해놓은 규칙을 지칭합니다.

HTTP 응답코드

HTTP 통신을 기반으로 하고있는데, 통신을 할 때, 그 결과를 알려주기위해서 HTTP 상태코드라는 것을 사용합니다. 클라이언트가 보낸 요청의 처리 상태를 알려주는 기능을 함.

1xx - 요청이 수신되어 처리중
잘 사용하지않는다.

2xx - 정상 처리됨

200 - ok(정상적으로 잘 처리해서 반환 한 경우)

201 - created(post등으로 서버에서 자원을 생성한 경우)

202 - accepted(요청이 접수되었으나 처리가 안된 경우 - 배치 처리 같은 곳에서 사용한다.)

204 - no content(성공적으로 수행했는데, 응답 페이로드 본문에 보낼게 없는 경우)

3xx - 요청을 완료하려면 추가 행동이 필요

웹 브라우저는 3xx 응답 결과에 Location header가 있으면 그 위치로 자동으로 이동한다.

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동(301,308), 원래의 URL을 사 용하지않아서 검색 엔즌 등에서도 변경을 인지한다.

일시 리다이렉션 - 일시적인 변경(302,307,303), URI가 일시적으로 변경. 따라서 검색 엔진 등에서 URL을 변경하면 안된다. 302를 가장 많이 쓰는데, 303과 307을 권장함

특수 리다이렉션 - 결과 대신 캐시를 사용(300,304),

PRG (Post/Redirect/Get) - Post했을 때, 이미 있으면 302 로 Location 주면서 일시적으로 리다이렉션하게해서 중복 주문과 같은 오류를 방지할 수 있다.

300 - multiple choices(거의 안씀)

301 - Moved Permanently
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음.

308 - Permanent Redirect
301과 기능은 같지만 리다이텍트시 요청 메서드와 본문을 유지한다.

302 - Found
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. 301이랑 똑같다.

303 - See Other
리다이렉트시 요청 메서드가 GET으로 변경된다.

307 - Temporary Redirect
302와 기능이 같음. 리다이렉트시 요청 메서드와 본문이 유지된다. 요청 메서드 변경은 절대 불가능

304 - Not Modified
캐시를 목적으로 사용. 클라이언트에게 리소스가 수정되지않았음을 알려줌. 캐시에 있는게 써도되는건지 물어본거에 써도 된다고 알려줌. 바디메세지를 포함하면 안된다.(로컬캐시를 사용해야하기 때문이다)

4xx - 클라이언트 오류가 나서 서버가 요청을 처리할 수 없음.(잘못된 문법 등등)
오류의 원인이 클라이언트에 있는 경우를 의미

400 - Bad Request
요청이 잘못된 것(요청 구문이나 API 스펙이 안맞은 경우) 백엔드에서 철저하게 다 막아줘야한다.

401 - Unauthorized
인증이 안된 경우. WWW-Authenticate 헤더와 함꼐 인증 방법을 설명
인증(누구인지 확인) 인가(권한부여, ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한)

403 - Forbidden
요청은 이해했으나, 승인은 거부한 경우. 인증은 됐지만, 인가가 안된 경우

404 - Not Found
요청 리소스가 서버에 없음. 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때.

405 Method Not Allowed
요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다. 예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다. 필수적인 메소드인 GET과 HEAD는 제거될 수 없으며 이 에러 코드를 리턴할 수 없습니다.

5xx - 서버 문제, 서버가 정상 요청을 처리하지 못하는 경우.

서버 문제(디비 접근이 불가능하거나 NullPointerException이 터지는 경우 등등)

503 - Service Unavailable
섭다하고 작업할 때 보여주는거. Retry-After헤더로 공지사항도 띄워줄 수 있음.

서버에서 문제가 터졌을 때, 500대 에러를 만들어야함. 데이터 숨기거나 할거는 다 400대로 던져야한다.

즉, 비즈니스 로직 상의 예외케이스는 500대를 던지면 안된다.
500대를 내는거는 쿼리에 문제가 있거나 디비에 문제가 있거나 널포인트가 뜬다거나하는 상황에서 사용한다.

HTTPS

HTTP VS HTTPS

HTTP

HTTP는 Hypertext Transfer Protocol의 약자로 서로 다른 시스템들 사이에서 통신을 주고받게 해주는 가장 기초적인 통신 규약을 의미한다.

HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시가 오가는 서비스들(전자상거래, 전자메일, 사내문서)에 사용하기 힘들다.

HTTPS

HTTP와 반대로 HTTPS는 Hypertext Transfer Protocol over Secure Socket Layer의 약자로 HTTP에 보안 기능이 추가가 된 형태라고 보면 된다.

넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다.

HTTP는 서버에서 브러우저로 전송되는 정보가 암호화되지 않기 때문에 데이터가 해커에 의해 쉽게 도난당할 수 있다는 것이 특징이다. 하지만 HTTPS는 SSL(보안 소켓 계층)을 사용함으로써 이 문제를 해결했다. SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결이 일어나도록 도와주어 민감한 정보가 도난당하지 않게 이를 방지해주는 역할을 한다.

HTTPS의 원리
공개 키 방식(Public Key Infrastructure)은 두 개의 키를 갖게 되며, A키로 암호화 하면 B키로 복호화가 가능하며, 반대로 B키로 암호화를 하면 A키로 복호화를 할 수 있다. 여기서 두 개의 키 중 하나는 공개 키(public key)이고 다른 하나는 비공개 키(private key)가 된다. 비공개 키는 private한 사용자가 가지고 있게 되며, 공개 키는 타인에게 공개되는 키이다. 유저가 공개 키를 이용하여 데이터를 암호화한 뒤, 비공개 키의 소유자에게 전달하면, 비공개 키의 소유자는 비공개 키로 복호화 하여 그 데이터를 얻는 간단한 원리이다.

SSL
SSL은 전자상거래에서의 데이터 보안을 위해서 개발한 통신 레이어다. SSL은 표현 계층의 프로토콜로 응용 계층 아래에 있기 때문에, 어떠한 응용 계층의 데이터라도 암호화해서 보낼 수 있다.

SSL 동작방식

SSL 인증서를 발급받고자 하는 A업체는 인증된 CA(Certificate Authority)기관에 A의 공개키와 사이트 정보를 전달한다.

CA는 검증을 거친 후에 CA 개인키로 'A 공개키와 사이트 정보'를 암호하여 인증서를 생성한다. 이 인증서는 A업체로 전달된다.

인증된 CA기관의 공개키는 웹브라우저에 저장되어 있다. A사이트에 접속하고자 하는 PC B는 A사이트에 요청을 한다.

요청(Agent Hello)하는 과정에서 A는 B에게 '랜덤한데이터 + 사용가능 암호화방식 + 세션 아이디'를 전달한다. 이에 대한 응답(Server Ack)에서 B는 '랜덤한 데이터 + 사용가능 암호화방식 + 인증서)를 전달한다.

handshake간에 주고 받은 랜덤한 데이터를 조합하여 pre master secret이라는 키를 생성한다(pre master secret는 대칭키로 실제 데이터 통신에 쓰일 키이다).

B는 브라우저에 내재되어 있는 CA 공개키로 인증서를 복호화한다(CA의 개인키로 암호화 - 공개키로 복호화 : 공개키 방식). 이 과정에서 B는 A의 공개키와 사이트 정보를 얻을 수 있다.

위 단계에서 인증서가 믿을 수 있고 인증된 것임을 확인할 수 있다(CA 공개키로 복호화가 됐기 때문).

사용자B에게는 현재 대칭키로 쓰일 pre master key와 A의 공개키가 있다. pre master key를 A공개키로 암호화하여 A사이트로 전송한다.

A는 자신의 개인키로 보내온 패킷을 복호화하여 pre master key를 얻는다.

pre master key는 일련의 과정을 거쳐서 master key > session key를 생성하고, 이는 통신을 위한 대칭키로 사용된다.

간략
1. handshake 과정의 랜덤한 데이터로 pre master secret 생성
2. 인증서 복호화(CA 공개키 - 브라우저 내저)로 사이트 공개키 획득
3. 사이트 공개키로 pre master secret 암호화 후, 사이트 전달
4. 사이트 개인키로 복호화 후, pre master secret 획득
5. 일련의 과정을 거쳐서 master secret > session key 생성
6. session 키로 대칭키 방식으로 정보 송수신

HSTS란

일반적으로 HTTPS를 강제하게 될 때 서버측에서 302 Redirect 를 이용하여 전환시켜 줄 수 있습니다. 하지만 이것이 취약점 포인트로 작용될 수 있습니다.

302 Redirect를 이용한 HTTPS 접속 유도

하여 클라이언트 (브라우저) 에게 HTTPS를 강제 하도록 하는 것이 권장되는데, 이것이 HSTS (HTTP Strict Transport Security) 입니다. 클라이언트 (브라우저)에서 강제 하기 때문에 Plain Text (HTTP) 를 이용한 연결 자체가 최초부터 시도되지 않으며 클라이언트 측에서 차단된다는 장점이 있습니다.

HSTS (HTTP Strict Transport Security) 를 이용한 HTTPS 접속유도

사용자가 최초로 사이트에 접속시도를 하게 되면 웹서버는 HSTS 설정에 대한 정보를 브라우저에게 응답하게 됩니다. 브라우저는 이 응답을 근거로 일정시간 (max-age) 동안 HSTS 응답을 받은 웹사이트에 대해서 https 접속을 강제화 하게 됩니다.

max-age 가 63072000초로써 rsec.kr은 최초 접속후 2년동안 브라우저에서 HTTPS접속이 강제화 됩니다.

SSL Stripping이란?

SSL Strip은, SSL 통신을 하고있는 네트워크 상에서 SSL 암호 프로토콜을 사용하지 못 하게 평문으로 전송되는 HTTP 프로토콜로 바꾸어 전송하는 공격기법 입니다.

이를 방지하기 위한 방법으로는,
게이트웨이이의 MAC address를 정적으로 세팅하는 것이 있습니다.

GET과 POST의 차이

POST
POST라는 영어 단어는 부치다, 제출하다라는 뜻을 가지고 있습니다. 예를 들어 우리가 어디에 서류를 제출하는 것은 우리에 대한 정보를 제출하여 추가하기 위함입니다. 이러한 상황과 유사하게 POST 방식은 데이터를 서버로 제출하여 추가 또는 수정하기 위해서 데이터를 전송하는 방식입니다.

POST의 특징

URL에 데이터를 노출하지 않고 요청한다.

데이터를 Body에 포함시킨다.

URL에 데이터가 노출되지 않아서 기본 보안은 되어있다.

전송하는 길이에 제한이 없다.

GET
영어 GET은 가져오다라는 뜻을 가진 단어입니다. 우리가 필요한 정보를 얻기 위해 도서관에서 책을 빌려 가져오는(GET)상황과 유사하게 GET은 어떠한 정보를 가져와서 조회하기 위해서 사용되는 방식입니다.

GET의 특징

URL에 데이터를 포함시켜 요청한다.

데이터를 헤더에 포함하여 전송한다.

URL에 데이터가 노출되어 보안에 취약하다.

전송하는 길이에 제한이 있다.

정리

GET 방식은 주소 뒤에 쿼리스트링이 그대로 전달되어 보안성이 떨어지고 전송속도는 빠름
-> Get은 주로 웹 브라우저가 웹 서버에 데이터를 요청할 때 사용

POST 방식은 주소가 전달 될 때 인코딩하여 전달되어 보안성이 높지만 전송속도가 느리다
-> Post는 웹 브라우저가 웹 서버에 데이터를 전달하기 위해 사용

HTTP 멱등성

멱등성이란, 수학에서 사용하는 용어에서 유래한 것으로. 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 뜻한다.

이 멱등성을 HTTP Method에 적용하면 다음과 같은 의미를 가진다. 동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 가지고, 서버의 상태도 동일하게 남을 때 해당 HTTP Method가 멱등성을 가진다고 한다.

HTTP Method의 멱등성에서 알아두어야 할 점이 있다. 결과가 의미하는 것이 응답 상태코드가 아닌 서버의 상태라는 것이다. 예를 들어, 똑같은 요청을 했을 때 응답하는 상태코드가 바뀌더라도 서버의 상태가 항상 같은 상태라면 멱등성이 있다고 판단한다.

우리가 흔히 사용하는 HTTP Method는 GET, POST, PUT, PATCH, DELETE가 있다. HTTP 스펙에 명시된 것에 의하면, GET, PUT, DELETE는 멱등성을 가지도록, POST와 PATCH는 멱등성을 가지지 않도록 구현해야 한다.

CORS란?

CORS란 Cross-Origin Resource Sharing의 약자로, 출처가 다른 리소스도 공유할 수 있도록 하는 정책을 말합니다. 보안상의 이유로 원칙적으로는 오직 출처가 동일한 리소스만 공유할 수 있습니다. (Same-Origin Policy)
클라이언트가 요청메세지의 Origin헤더 해당 출처를 적어보내고, 그 응답으로 서버로부터 받은 응답메세지의 Access-Control-Allow-Origin의 내용을 자신이 보냈던 Origin헤더 내용을 비교해본 후 유효한 응답인지 아닌지를 결정하는 메커니즘으로 동작합니다.

CORS 해결방법

Access-Control-Allow-Origin 응답 헤더 세팅

서버측 응답에서 접근 권한을 주는 헤더를 추가하여 해결

cors 모듈 사용

아무 옵션없이 설정하면 모든 cross-origin 요청에 대해 응답이므로, 특정 도메인이나 특정 요청에만 응답하게 옵션을 설정하는 것이 좋다.

특정 도메인 접근 허용

특정 요청 접근 허용

JSON, XML의 차이

XML(eXtensible Markup Language)

HTML과 매우 비슷한 문자 기반의 마크업 언어이다

사람과 기계가 동시에 읽기 편한 구조로되어있다.

HTML처럼 데이터를 보여주는 목적이 아닌 데이터를 저장하고 전달하는 목적으로 만들어졌다.

XML 태그는 HTML 태그 처럼 미리 정의 되어 있지 않고, 사용자가 직접 정의할 수 있다

JSON(JavaScript Object Notation)

브라우저 통신을 위한 속성-값 또는 키-값 쌍으로 이루어진 데이터 포맷

JSON과 XML 공통점

데이터를 저장하고 전달하기 위해 고안되었다

기계 뿐아니라 사람도 쉽게 읽을 수 있다.

계층적인 데이터 구조를 가진다

다양한 프로그래밍 언어에 의해 파싱될 수 있다

XMLHttpRequest 객체를 이용하여 서버로부터 데이터를 전송받을 수 있다.

JSON과 XML의 차이점

MIME이란?

MIME이란?
Multipurpose Internet Mail Extensions의 약자로 간략히 말씀을 드리면 파일 변환을 뜻한다고할 수 있습니다.
MIME는 이메일과 함께 동봉할 파일을 텍스트 문자로 전환해서 이메일 시스템을 통해 전달하기 위해 개발되었기 때문에 이름에 Internet Mail Extension 입니다 그렇지만 현재는 웹을 통해서 여러형태의 파일 전달하는데 쓰이고 있습니다.

AWS란?

아마존닷컴에서 개발한 클라우드 컴퓨팅 플랫폼이다.

Amazon Web Services는 아마존(Amazon)에서 제공하는 클라우드 서비스로, 네트워킹을 기반으로 가상 컴퓨터와 스토리지, 네트워크 인프라 등 다양한 서비스를 제공하고 있다.

비즈니스와 개발자가 웹 서비스를 사용하여 확장 가능하고 정교한 애플리케이션 구축하도록 지원하여 준다.

현재 소규모 법인(회사) 및 개인 을 포함한 다양한 사용자들이 사용하고 있으며, 클라우드 컴퓨팅의 장점을 이용하기 위해 많은 거대 기업에서도 활용하고 있다.

Minu Jeong

사용자에게 유용한 서비스를 만들고싶어요 :)

이전 포스트

백엔드 기술 면접 질문(스프링)

다음 포스트

백엔드 기술 면접 질문(WEB)

브라우저에서 URL치면 발생하는 일

브라우저에서 URL치면 발생하는 일

쿠키, 세션, 토큰

쿠키 개념 및 동작방식

세션 개념 및 동작방식

쿠키와 세션

토큰

토큰 기반 인증

JWT

OAuth

캐시

캐시

URI, URL, URN에 대해서

URI, URL, URN에 대해서

REST, REST API, RESTful 이란?

REST란 무엇이고, RESTful하게 API를 디자인한다는 것은 무엇인지 설명하시오.

REST API 장점, 단점

REST API에서 stateless의 장단점

HTTP 1,2,3의 차이

HTTP 1,2,3의 차이

HTTP

HTTP 응답코드

HTTP 응답코드

HTTPS

HTTP VS HTTPS

SSL 동작방식

HSTS란

SSL Stripping이란?

GET과 POST의 차이

GET과 POST의 차이

HTTP 멱등성

HTTP 멱등성

CORS란?

CORS란?

CORS 해결방법

JSON, XML의 차이

JSON, XML의 차이

MIME이란?

MIME이란?

AWS란?

AWS란?

백엔드 기술 면접 질문(스프링)

백엔드 기술 면접 질문(디자인패턴)

0개의 댓글