면접 예상 질문

HTTP

• HTTP 프로토콜에 대해서 설명해주세요.
• HTTP의 요청/응답 모델에 대해 설명해주세요.
• HTTP 메서드중 GET과 POST의 차이점에 대해 설명해주세요.
• HTTP 메서드중 PUT과 PATCH의 차이점에 대해 설명해주세요.
• HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 설명해주세요.
• HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요.
• HTTP의 무상태성(Stateless)에 대해서 설명해주세요.
• HTTP Keep-Alive에 대해서 설명해주세요.
• HTTP 파이프라이닝에 대해서 설명해주세요.
• HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.

HTTPS

• HTTPS에 대해서 설명해주세요.
• SSL/TLS이 뭔가요?
• 대칭키 암호화 방식에 대해 설명해주세요.
• 비대칭키(공개키) 암호화 방식에 대해서 설명해주세요.
• 전자 서명에 대해서 설명해주세요.
• HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.)

DNS

• DNS가 뭔가요?
• DNS 작동 방식에 대해 설명해주세요.
• DNS 질의 종류에 대해 설명해주세요.
• DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?
• DNS 레코드가 무엇인가요?

초기 답변

• HTTP 프로토콜에 대해서 설명해주세요.

HTTP 프로토콜은 웹에서 메시지를 송수신하는데 사용하는 프로토콜입니다. 신뢰성 있는 데이터 전송을 위해서 HTTP/2 버전까지 TCP/IP 기반으로 동작하고 HTTP/3 버전의 경우 QUIC 프로토콜을 사용합니다.

HTTP는 시작절, 헤더, 본문으로 이루어져 있으며, 다음과 같은 구성요소를 가지고 있습니다.

• 버전

• URI

• 메서드

• 상태 코드

• 사유 구절

• 헤더

• 본문

• HTTP의 요청/응답 모델에 대해 설명해주세요.

HTTP의 요청 모델은 다음과 같습니다.

먼저, 시작절에 버전, URI, 메서드가 있습니다.

그다음 헤더가 존재하며 그 다음줄에 본문으로 되어있습니다.

HTTP의 응답 모델은 다음과 같습니다.

시작절에 상태 코드, 사유 구절, 버전이 있습니다.

그다음 헤더가 존재하며 다음 줄에 본문으로 구성되어 있습니다.

• HTTP 메서드중 GET과 POST의 차이점에 대해 설명해주세요.

HTTP 메서드의 GET의 경우 "멱등" 요청으로 서버로 부터 클라이언트가 리소스를 요청하는 경우에 사용합니다. 원칙적으로 요청을 보낼 때 본문을 사용하지 않고, 쿼리와 같은 방식을 URI에 붙여서 사용합니다.

POST 메서드는 "비멱등" 요청으로 클라이언트가 서버로부터 특정 동작을 요구할 때 사용합니다. 요청 본문에 요구되는 데이터를 담아서 보내고, 서버는 해당 데이터를 이용해서 특정 동작을 수행합니다.

• HTTP 메서드중 PUT과 PATCH의 차이점에 대해 설명해주세요.

PUT 메서드는 "멱등" 요청으로 리소스의 대체 혹은 저장을 요청할 때 사용합니다.

PATCH 메서드는 리소스의 수정을 요구할 때 사용합니다. 이것 또한 "멱등" 요청에 해당합니다.

• HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 설명해주세요.

HTTP 상태코드는 100단위 부터 500까지 각자의 단위에서 목적을 가지고 사용합니다.

먼저, 1xx의 경우 정보를 전달하려고 하는 경우에 사용합니다.

2xx의 경우 요청에 대한 동작을 성공적으로 수행했을 때 성공 응답으로 사용합니다.

3xx의 경우 요청에 대한 리다이렉션이 필요한 경우에 사용합니다.

4xx의 경우 클라이언트의 요청이 잘못되었을 경우에 사용합니다.

5xx의 경우 요청을 처리하는 서버에 문제가 생겼을 경우에 사용합니다.

대표적인 상태코드로는 200 성공, 201 created, 300 redirect, 404 Not Found, 401 UnAuthroized, 500 Interval Error, 503 Gateway Error 와 같은 것들이 존재합니다.

• HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요.

HTTP 헤더의 경우, HTTP 메시지에 대한 정보를 알려주기 위해 사용합니다.

이것은 선택적인 것으로 사용해도 되고, 사용하지 않아도 됩니다.

대표적으로 사용되는 것들 중 하나는 Content-Type, Content-Length, Connection, Location등과 같은 것들이 존재합니다.

• HTTP의 무상태성(Stateless)에 대해서 설명해주세요.

HTTP 프로토콜의 특성 중 하나는 서버-클라이언트 통신이라는 점입니다. 서버와 클라이언트가 연결되어 통신을 하는데 이 과정에서 생기는 정보를 서버에 아무런 것도 저장하지 않는 것을 무상태성이라고 합니다.

이러한 특성으로 인해 HTTP를 사용할 경우, 확장성과 유연성을 보장해줍니다.

또한, 저장되어야할 필요가 있는 정보들의 경우 쿠키 혹은 세션을 사용해서 정보를 저장하여 사용합니다.

• HTTP Keep-Alive에 대해서 설명해주세요.

HTTP Keep-Alive는 HTTP/1.0의 확장 기능입니다. HTTP/1.0은 TCP/IP 기반으로 동작하기 때문에 메시지를 송수신하는 과정에 앞서 TCP Connection 작업이 필요합니다. 또한 보안을 위해 TLS도 사용할 경우 해당 Connection 과정은 더욱 길어집니다.

매 요청마다 커넥션을 맺을 경우, 트래픽의 효율이 떨어지기 때문에 HTTP Keep-Alive를 사용해서 이전에 사용했던 커넥션을 재활용하는 식으로 사용합니다.

해당 기능은 기존의 커넥션을 재활용하면서 네트워크의 효율성을 높여주지만 단점이 존재합니다.

1. 명시적으로 Connection 헤더를 작성해줘야 하는 복잡성
2. 멍청한 프록시의 존재로 인한 기능 사용 불가
3. 표준 기능이 아닌 확장 기능이라 모든 서버에서 정상적으로 동작할 것이란 보장이 없다.

이러한 단점을 극복하기 위해 HTTP/2.0에서는 지속 커넥션 기능이 추가되었습니다.

• HTTP 파이프라이닝에 대해서 설명해주세요.

HTTP 파이프라이닝은 HTTP/1.1의 지속 커넥션의 등장으로 사용가능할 수 있게 된 기능입니다.

지속 커넥션을 사용해서 하나의 커넥션을 유지하고 있고, 기존 방식인 요청에 대한 응답이 도착했을 경우에 새로운 요청을 보내는 것이 아닌 요청은 연속적으로 보내서 응답을 순차적으로 받는 방식입니다.

이것을 사용해서 네트워크 트래픽의 효율을 높였습니다.

하지만, 이것은 단점이 존재하는데 HTTP 메시지의 경우 순번을 알 수 없기 때문에 요청을 연속적으로 보낼 때 응답을 순차적으로 보내야하기 때문에 이것으로 인해서 HOLB가 발생합니다.

이것을 극복하기 위해서 HTTP/2.0에선 Multiplexing 기능이 도입되었습니다.

• HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.

먼저, HTTP/1.1의 주요 기능은 다음과 같습니다.

• 병렬 커넥션
• 지속 커넥션
• 파이프라이닝
• 가상 호스팅 지원

이와 같은 기능들이 존재합니다.

HTTP/2는 HTTP/1.1의 단점을 보안하기 위해서 Stream이란 개념이 도입되면서 등장합니다.

주요 기능은 다음과 같습니다.

• 멀티플렉싱
• 바이너리 형식 사용
• 스트림 기반 우선순위 제공
• 헤더 압축

이와 같은 기능들을 제공합니다.

하지만, HTTP/1.1과 HTTP/2.0은 여전히 TCP기반으로 동작하고 있기 때문에 다음과 같은 문제점들을 피할 수 없었습니다.

• TCP 오류 검출 방식 및 슬로우 스타트로 인한 모든 스트림 대역폭 감소
• 3RTT에 이르는 Connection 과정

이것을 극복하기 위해 등장한 것이 HTTP/3.0이고 HTTP/3.0은 기존 방식과 다르게 UDP로 구현된 QUIC 프로토콜 위에서 동작합니다.

주요 기능은 다음과 같습니다.

• HTTP/2.0과 TLS와 UDP의 조합
• 빠른 Connection
• 기존 Session Key를 재사용 가능
• 패킷 오류 검출 및 재전송 기능(ARQ)

특히 오류가 검출되더라도 TCP와 같은 Slow Start를 사용하지 않고 RTT를 계산하는 것에 있어서도 각 패킷에 오로지 전송 순서로 순번을 매기는 헤더를 추가하면서 빠른 계산이 가능하게된 것이 특징입니다.

• HTTPS에 대해서 설명해주세요.

HTTPS는 HTTP 프로토콜에 보안을 제공해주기 위해서 SSL/TLS 기능을 추가한 것을 의미합니다.

HTTPS를 사용할 경우 데이터를 암호화하여 전송해주기 때문에 패킷이 탈취되더라도 데이터의 신뢰성을 보장해줍니다.

• SSL/TLS이 뭔가요?

SSL/TLS은 CA(Certificate Authority)으로부터 인증서를 받아서 해당 인증서를 기반으로 데이터를 암호화하여 송수신할 수 있도록 도와주는 프로토콜입니다.

이것을 이용하여 신뢰성 있는 데이터 전송을 가능케 해줍니다.

• 대칭키 암호화 방식에 대해 설명해주세요.

대칭키 암호화 방식은 동일한 키를 사용해서 암호화/복호화 작업을 수행하는 방식을 의미합니다. 공유키를 사용하기 때문에 송수신자간에 공유키를 주고 받는 과정이 요구되고, 하드웨어적으로 동작하여 빠르게 동작할 수 있습니다.

실제로 SSL/TLS의 세션키는 대칭키 암호화 방식을 사용합니다.

• 비대칭키(공개키) 암호화 방식에 대해서 설명해주세요.

비대칭키 암호화 방식은 공개키와 비밀키를 사용하여 동작합니다. modular-n의 항등식을 사용해서 공개키와 비밀키를 생성할 수 있고, 해당 방식은 대칭키 암호화 방식보다 계산을 많이 요구하기 때문에 속도가 느립니다.

해당 방식에서 비밀키를 사용해서 암호화하는 방식의 경우, 암호화 방식이 더 중요한 것이기 때문에 서명에서 사용하고 있는 방식입니다.

비밀키를 사용해서 복호화하는 방식의 경우, 일반적으로 사용하는 암호화된 메시지 송수신 방식으로 볼 수 있습니다.

• 전자 서명에 대해서 설명해주세요.

전자 서명의 경우 웹 상에서 메시지의 신뢰성있는 출처를 보장하기 위해서 사용하는 서명이라고 볼 수 있습니다.

전자 서명의 경우 공개키 암호화 방식을 사용하는데 사용하는 목적이 메시지를 생성하는 사람의 출처에 대한 신뢰성을 보장하는 것이기 때문에 비밀키를 사용해서 메시지를 암호화 하는 것이 특징입니다.

• HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.)

HTTPS의 과정은 우선 TCP Connection이 전부 이루어진 후 이루어 집니다.

SSL/TLS 1.0을 기준으로 설명을 하겠습니다.

먼저, 클라이언트가 사용할 수 있는 암호화 알고리즘의 리스트를 보내고, 필요한 정보들을 담아서 보냅니다.

서버는 클라이언트로부터 받은 알고리즘 리스트중에서 하나를 선택한 후, 그것을 사용해서 공개키와 비밀키를 생성합니다. 이후 클라이언트에게 인증서와 함께 공개키를 담아서 보냅니다.

마지막으로 클라이언트는 공개키를 사용해서 프리마스터 시크릿을 생성하여 그것을 공개키로 암호화 한 후 전송합니다.

서버측과 클라이언트측에서 서로 주고 받은 정보와 프리마스터 시크릿을 사용하여 세션키를 생성후 이후 데이터 전송에서 세션키를 사용해서 데이터는 주고 받습니다.

SSL/TLS 1.3의 경우 SSL Handshake의 동작을 간소화 하였고, 더 확실한 보안 성능을 자랑합니다.

• DNS가 뭔가요?

종단간에 메시지를 주고 받기 위해선 주소가 필요합니다. 해당 주소는 IP 주소로 되어 있고, 이것은 사람들이 기억하기 쉽지 않은 형태로 만들어져 있습니다.

이것을 Name의 방식으로 만들어서 호스트 네임을 부여하여 주소를 사용할 수 있도록 한 것이 DNS입니다.

• DNS 작동 방식에 대해 설명해주세요.

DNS의 경우, 먼저 사용자가 호스트 네임을 가지고 IP주소를 얻어 오기 위해서 로컬 DNS로 요청을 보냅니다.

로컬 DNS 서버는 루트 DNS로 요청을 보내서 그 하위 서버인 Top Level Domain(TLD) 서버의 주소를 받아옵니다.

TLD 서버는 같은 방식으로 책임 서버의 주소를 로컬 DNS 서버에게 알려줍니다.

최종적으로 책임 DNS 서버에서 해당 호소트의 IP 주소를 받아온 후 사용자에게 보내줌으로써 동작이 마무리가 됩니다.

또한, DNS의 경우 캐시 기능을 가지고 있는데 이것은 운영 체제 수준, 브라우저 수준, 로컬 DNS 서버 수준에서 캐시 기능이 동작합니다.

• DNS 질의 종류에 대해 설명해주세요.

잘 모르겠습니다.

• DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?

DNS 서버에게 IP 주소를 요청할 때 UDP를 사용하는 이유는 TCP의 Connection 때문에입니다.

TCP는 3-way handshake 동작을 수행하기 때문에 이것으로 인한 지연(latency)가 발생할 수 있어서 네트워크 트래픽의 효율성을 떨굽니다.

• DNS 레코드가 무엇인가요?

DNS의 레코드의 경우 Type NS와 Type d로 구성되어 있습니다. Type NS의 경우 하위 DNS 서버의 주소를 알려주는 방식이고, Type d의 경우 실제 호스트의 IP 주소를 받아오는 방식입니다.

헷갈림.

부족한 개념 정리

• DNS의 사용 목적
• DNS 질의 종류
• DNS 레코드
• DNS에서 UDP를 사용하는 이유
• HTTPS
• SSL/TLS
• PUT 메서드와 PATCH 메서드의 차이점
• 주요 상태 코드 정리
• HTTP 헤더

DNS 사용 목적

DNS를 사용하는 목적은 크게 보면 두 가지로 볼 수 있습니다.

1. 사용자들이 IP 주소를 기억하기 보다 Domain Name을 기억하는 것이 더 쉽기 때문입니다.
2. 라우터에서 Domain Name을 직접 사용하기에는 가변 길이라 처리하기 힘들기 때문에 IP 주소로 변환해주는 작업이 요구됩니다.

이 두 가지 이유로 인해서 DNS를 사용한다고 보면 됩니다.

또한, 추가적인 이점은 DNS를 사용할 경우 중복 웹 서버 같은 중복 서버 사이에 부하를 분산하는 부하 분산 기능을 사용할 수 있는 이점이 존재합니다.

DNS 질의

DNS의 질의는 2가지 종류가 있습니다.

1. 재귀적 질의(Recursive Query)
2. 반복적 질의(Iterative Query)

이에 대해서 설명해보자면 다음과 같습니다.

1. 재귀적 질의(Recursive Query)
   • 클라이언트(DNS 클라이언트, 종종 '리졸버'라고 불림)가 DNS 서버에 도메인 이름에 대한 질의를 합니다.
   • 이 경우, DNS 서버는 요청받은 도메인 이름의 IP 주소를 찾을 때까지 여러 DNS 서버에 질의를 반복합니다.
   • 최종 결과를 찾으면, 그 결괄르 클라이언트에게 반환합니다.
2. 반복적 질의(Iterative Query)
   • 클라이언트가 DNS 서버에 도메인 이름에 대한 질의를 합니다.
   • 서버는 요청받은 정보를 직접 알고 있는 경우에만 응답하며, 그렇지 않은 경우 클라이언트(로컬 DNS 서버)에게 다른 DNS 서버의 주소를 알려줍니다.
   • 클라이언트는 이후 해당 DNS 서버에 직접 질의를 합니다.

결국 해당 두 방식의 차이점은 리졸버가 로컬 DNS 서버로 요청을 보낸 후, 캐싱되어 있는 정보가 없다면 로컬 DNS가 하나의 요청만 보내서 모든 과정을 거친 후 결과를 받아오는 재귀적 질의 방식과 로컬 DNS가 반복적으로 질의를 보내는 반복적 질의인 것으로 로컬 DNS 서버가 몇번의 질의를 보내냐에 차이가 존재합니다.

DNS 레코드

DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 자원 레코드(resource record, RR)을 저장합니다.

간단하게 말하자면, DNS 레코드는 DNS 데이터베이스 내의 정보 단위로, 다양한 타입이 있으며 각각 다른 목적으로 사용됩니다.

DNS 레코드의 대표적인 유형들은 다음과 같은 것들이 있습니다.

1. A 레코드(Adress Record)
   • 도메인 이름을 IPv4로 변환합니다.
2. AAAA 레코드(IPv6 Adress Record)
   • 도메인 이름을 IPv6로 변환합니다.
3. CNAME 레코드(Canonical Name Record)
   • 하나의 도메인 이름을 다른 도메인 이름으로 매핑합니다.(별칭)
4. MX 레코드(Mail Exchange Record)
   • 도메인의 이메일을 처리하는 서버의 주소를 지정합니다.
5. NS 레코드(Name Server Record)
   • 해당 도메인을 위한 DNS 서버의 주소를 나타냅니다.

DNS에서 UDP를 사용하는 이유

DNS에서 UDP를 사용하는 이유는 다음과 같습니다.

1. 간소화된 프로토콜: UDP는 TCP에 비해 더 간단한 프로토콜입니다. TCP에서 제공하는 기능들은 추가적인 오버헤드를 유발하기 때문에 이러한 기능들이 없는 간소화된 프로토콜인 UDP를 사용함으로써 처리가 더 빠르고 간단합니다.
2. 낮은 오버헤드: UDP는 TCP보다 헤더가 작아 패킷 오버헤드가 작습니다. DNS 질의와 응답은 대체로 작은 데이터 패킷으로, UDP의 작은 헤더는 이러한 짧은 메시지 전송에 더 적합합니다.
3. 비연결 지향성: UDP는 비연결 지향적 프로토콜로, 통신을 시작하기 전에 연결을 설정할 필요가 없습니다. 빠른 처리 시간을 가능하게 합니다.
4. 상태 정보 불필요: UDP는 상태 정보를 유지할 필요가 없습니다. DNS 서버는 매우 많은 수의 클라이언트로부터 동시에 질의를 받을 수 있으며, UDP를 사용함으로써 각 연결에 대한 상태 정보를 유지할 필요가 없어 서버의 부담을 줄일 수 있습니다.
5. 확장성: DNS 서비스는 전 세계적으로 방대한 양의 질의를 처리해야 합니다. UDP의 간소함과 효율성은 이러한 대규모 처리에 더 적합하며, 서버 자원을 효율적으로 사용할 수 있습니다.

간단하게 정리를 해보자면, 간소화된 프로토콜로 낮은 오버헤드를 가지고 이로 인해서 빠른 전송이 가능합니다. 또한 비연결 지향적 프로토콜이기 때문에 초기 연결 지연을 피할 수 있고 서버의 부담을 줄이며 확장성에도 좋습니다.

하지만, DNS도 TCP 통신 방식을 사용하는 경우가 있습니다.

예를 들어, DNS 응답이 UDP 패킷 크기 제한을 초과하는 경우나 DNSSEC(DNS Security Extension)와 같이 보안을 강화해야하는 상황에서는 TCP가 사용됩니다. TCP는 데이터의 무결성과 순서를 보장하는 장점을 가지고 있기 때문입니다.

⚡️ DNS는 UDP를 사용하면서 어떻게 응답을 보장할 수 있을까? ⚡️

1. 시간 초과 및 재시도: 클라이언트는 DNS 요청에 대한 응답을 일정 시간 내에 받지 못하면 요청을 재시도합니다. 이는 대부분의 DNS 클라이언트 소프트웨어(리졸버)에서 자동으로 수행합니다.
2. TCP 사용: 일부 경우에는 DNS 쿼리가 TCP를 사용하여 전송됩니다.
3. 추가 DNS 서버 사용: 많은 시스템과 네트워크는 다수의 DNS 서버를 구성합니다. 하나의 서버로부터 응답을 받지 못한 경우, 다른 서버에 요청을 보내어 신뢰성을 높입니다.

HTTPS

HTTPS는 웹 통신의 보안을 강화하기 위해 사용되는 프로토콜입니다. 기본적으로 HTTP 프로토콜의 보안 버전이며, SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터 전송을 암호화합니다.

HTTPS의 주요 목적은 인터넷을 통해 전송되는 데이터의 기밀성과 무결성을 보장하는 것입니다.

신뢰성이라는 단어보단 확실히 기밀성이란 단어를 사용해야함

HTTPS의 주요 특징

1. 데이터 암호화
2. 데이터 무결성
3. 인증: 클라이언트는 SSL/TLS 인증서를 통해 서버의 정체성을 확인할 수 있습니다. 이 인증서는 신뢰할 수 있는 제 3자 기관(CA)에 의해 발급됩니다.
4. 포트 번호: HTTPS는 일반적으로 TCP 포트 443을 사용합니다.

SSL/TLS

SSL과 TLS는 암호화 프로토콜로, 인터넷 상에서 데이터를 안전하게 전송하기 위해 설계되었습니다.
SSL은 이전 버전이며, TLS는 SSL의 후속 버전입니다.

SSL/TLS의 주요 기능
1. 암호화: 클라이언트와 서버 간의 통신에 대해 종단 간 암호화를 제공하여 데이터를 보호합니다.
2. 핸드셰이크 프로토콜: SSL/TLS는 핸드셰이크 과정을 통해 서버와 클라이언트 간의 통신을 설정합니다. 이 과정에서는 암호화 방법, 세션 키 교환, 서버 인증 등이 수행됩니다.
3. 세션 관리: 암호화된 세션의 생성, 유지, 종료를 관리합니다.

PUT 메서드와 PATCH 메서드의 차이점

1. PUT 메서드
   • 용도: 자원의 전체를 대체하거나 업데이트하거나, 지정된 URI에 새 자원을 생성하는 데 사용됩니다.
   • 작동 방식: 'PUT' 메서드는 해당 URI의 전체 자원을 요청 본문의 내용으로 대체합니다. 기존 자원이 존재하면 업데이트하고, 존재하지 않으면 새로 생성합니다.
   • 전체성: 'PUT' 요청은 대상 자원의 전체를 갱신해야 합니다. 일부분만 업데이트하면, 나머지 부분은 기본값이나 null로 설정될 수 있습니다.
2. PATCH 메서드
   • 용도: 자원의 일부분만 수정하는 데 사용합니다.
   • 작동 방식: 'PATCH' 메서드는 대상 자원의 일부만을 변경합니다. 전체 자원을 대체하는 것이 아니라, 제공된 데이터로 일부분만 업데이트합니다.
   • 효율성: 'PATCH'는 네트워크 대역폭을 절약하고 효율성을 높일 수 있습니다. 특히 변경해야 할 데이터가 작은 경우에 유용합니다.

⚡️ GET 방식에서 파라미터 담아 보내기 ⚡️

1. 쿼리 스트링(Query String)
2. 경로 값(Path Value)

주요 상태 코드 정리

상태 코드를 표로 정리하자면 다음과 같습니다.

전체 범위	정의된 범위	분류
100-199	100-101	정보
200-299	200-206	성공
300-399	300-305	리다이렉션
400-499	400-415	클라이언트 에러
500-599	500-505	서버 에러

대표적으로 사용되는 상태 코드는 다음과 같습니다.

• 200: OK
• 201: Created
• 303: See Other
• 400: Bad Request
• 401: Unauthorized
• 403: Forbidden
• 404: Not Found
• 500: Internal Server Error
• 502: Bad Gateway

HTTP 헤더

HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줍니다.

헤더는 크게 다섯 가지로 분류됩니다.

• 일반 헤더(General Headers)
• 요청 헤더(Request Headers)
• 응답 헤더(Response Headers)
• 엔터티 헤더(Entity Headers)
• 확장 헤더(Extension Headers)

대표 적인 헤더에 대해 각 항목별로 몇 가지만 살펴보자.

일반 헤더

• Connection
• Date
• MIME-Version

요청 헤더

• Client-IP
• Accept 관련 헤더(Accept)
• 조건부 요청 헤더(If-xxxxx)
• 요청 보안 헤더(Authorization)

응답 헤더

• Age
• 협상 헤더(Accept-Range)
• 응답 보안 헤더(Set-Cookie)

엔터티 헤더

• Allow
• Location
• 콘텐츠 헤더(Content-xxxxx)

이와 같은 것들이 있습니다.

답변 정리 및 개념 확장

HTTP

• HTTP 프로토콜에 대해서 설명해주세요.

위에서 제시한 답변은 나쁘지 않습니다. 다시 한번만 정리하고 넘어가겠습니다.

HTTP 프로토콜은 웹 통신에서 데이터(메시지)를 전달하기 위해서 사용하는 프로토콜입니다. 핵심적인 단어는 웹, 메시지, 전달 프로토콜이라는 점입니다.

HTTP 프로토콜의 대표적인 특징은 신뢰성을 보장해주는 프로토콜이라는 점에서 TCP기반의 HTTP/1.x나 HTTP/2 그리고 UDP를 사용하는 HTTP/3이든 신뢰성을 보장해준다는 점입니다.

추가적으로 보안을 위해서 SSL/TLS 암호화 프로토콜과 같이 쓰인다는 점이 특징입니다.

HTTP의 기본 모델은 정해져 있으므로 거기서 사용되는 구성요소까지 설명하는 것은 나쁘지 않아 보입니다.

• HTTP의 요청/응답 모델에 대해 설명해주세요.

해당 답변은 괜찮습니다. 넘어가겠습니다.

• HTTP 메서드중 GET과 POST의 차이점에 대해 설명해주세요.

GET과 POST의 주요 차이점은 "멱등"과 "비멱등"이라는 점에서 확실히 구분됩니다.

GET 방식은 리소스를 조회하는 것을 목적으로 사용하고, POST 방식은 요청에 데이터를 전달하여 특정 동작(리소스를 저장하거나 업데이트)을 수행하도록 요구할 때 사용합니다.

GET 방식은 기본적으로 데이터를 본문에 담지 않는 것이 표준이며, 파라미터를 보낼 필요가 있을 경우에는 "Query String" 혹은 "Path Value"를 사용해서 보내도록 합니다.

GET 방식을 브라우저에 캐싱될 수 있지만, POST 방식은 브라우저에 캐생되지 않습니다.

• HTTP 메서드중 PUT과 PATCH의 차이점에 대해 설명해주세요.

PUT과 PATCH의 주요 차이점은 리소스를 얼마나 많이 변화시키는가 즉, 정도의 차이입니다.

PUT은 기본적으로 리소스 전체에 대한 업데이트 혹은 저장을 요구할 때 사용합니다.
PATCH는 리소스의 일부분만 변경하려고 하는 경우에 사용합니다.

PUT 메서드는 리소스 전체에 대한 업데이트를 요구하기 때문에 만약, 리소스의 일부분만 데이터로 보내고 나머지를 보내지 않았다면, 나머지 값들은 기본 값 혹은 null값으로 대체되게 됩니다.

PATCH 메서드는 리소스의 일부분 즉, 필요한 부분의 데이터만 전송하면 되기 때문에 오버헤드 측면에서 PUT 보다 효율적일 수 있습니다.

• HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 설명해주세요.

해당 설명도 나쁘지 않아 보입니다. 하지만 수정해야 될 부분이 있죠.

먼저, HTTP 상태 코드에 대한 설명을 하지 않았는데 HTTP 상태 코드는 요청에 대한 처리 결과를 정해놓은 숫자로 알려주는 용도로 사용합니다.

• 1xx는 정보를 전달하려고 할 때 사용하는 것이 맞습니다.
• 2xx는 성공 응답
• 3xx는 리다이렉션 응답
• 4xx는 클라이언트 에러 응답
• 5xx는 서버 에러 응답

추가적으로 대표적인 상태 코드를 정리하자면 다음과 같습니다.

• 200: OK

• 201: Created

• 303: See Other

• 400: Bad Request

• 401: Unauthorized

• 403: Forbidden

• 404: Not Found

• 500: Interval Server Error

• 503: Bad Gateway

• HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요.

해당 답변은 좋지 않다고 생각합니다. 정의부터 그에 대한 설명까지 바꿀 필요가 있습니다.

먼저, HTTP 헤더에 대한 설명으로 메시지에 대한 정보 전달은 좋지 않습니다. 이것은 어찌보면 본문에 대한 설명으로도 가능합니다.

HTTP 헤더는 송수신자가 메시지를 주고 받을 때 추가적인 정보(부수적인 정보)를 전달하기 위해 사용합니다.

여기서 핵심적인 단어는 "추가적인 정보"라는 점입니다.

HTTP 헤더에는 5가지 종류가 있습니다.

1. 일반 헤더
2. 요청 헤더
3. 응답 헤더
4. 엔티티 헤더
5. 확장 헤더

대표적인 것들은 다음과 같이 정리를 해볼 수 있습니다.

1. 요청 헤더
   • Connection
   • Date
   • MIME-Version
2. 요청 헤더
   • Client-IP
   • 보안 요청 헤더(Authorization)
   • Accept 관련 헤더
   • 조건부 요청 헤더
3. 응답 헤더
   • 보안 응답 헤더
   • 협상 헤더
   • Age
4. 엔티티 헤더
   • Allow
   • Location
   • Content 관련 헤더

이 정도로 정리할 수 있습니다.

• HTTP의 무상태성(Stateless)에 대해서 설명해주세요.

해당 답변은 좋아 보입니다. 꼬리 질문으로 확장성과 유연성에 대해 질문이 들어올 수 있지만, 그때 가서 대답하면 되고 추가적으로 단점으로 독립적인 처리로 인한 추가 매커니즘이 있다는 점만 염두해 두고 있다면 괜찮을 것 같습니다.

• HTTP Keep-Alive에 대해서 설명해주세요.

해당 답변은 충분하다고 생각합니다.

하지만 마지막에 적혀있는 지속 커넥션이 HTTP/2부터 도입되었다는 설명은 틀렸습니다.

지속 커넥션은 HTTP/1.1에서 도입되었고, 이와 더불어 파이프라이닝 기능까지 추가된 것이 특징입니다.

• HTTP 파이프라이닝에 대해서 설명해주세요.

해당 답변은 좋다고 생각합니다.

파이프라이닝에서 중요하게 강조해야되는 점은 요청은 연속적으로 보내며, 응답은 순차적으로 처리되어야 한다는 점입니다.

이로 인해서 HOLB이 발생한다는 점이 치명적인 단점이고 이것으로 인해 HTTP/2의 멀티플렉싱 기능 도입으로 이어졌다는 것임을 기억해야합니다.

• HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.

해당 답변도 순차적으로 이어지면서 잘 설명 했다고 생각합니다.

다시 한번 정리를 해본다는 차원에서 적어보겠습니다.

HTTP/1.1은 기존에 HTTP/1.0의 단점들을 보완하기 위해 등장한 것이로 이때까지만 해도 요청에 대한 응답을 순차적으로 하나씩 처리를 해야 했기 때문에 매우 동작이 느렸습니다.

HTTP/1.1의 주요 특징은 다음과 같습니다.

• 병렬 커넥션
• 지속 커넥션
• 파이프라이닝
• 가상 호스팅 기능 제공

이러한 기능들을 제공하고 있었지만, 여전히 문제가 있었습니다.

HTTP/1.1은 여러 요청들을 연속적으로 보냄으로써 레이턴시를 줄이려고 노력했으나, 서버 측에서 순차적으로 요청들을 처리해야된다는 점에서 HOLB 문제를 피할 수 없었습니다. 또한, 헤더를 텍스트 기반 방식으로 인코딩 하여 전송하기 때문에 오버헤드적인 측면에서도 문제를 무시할 수 없었습니다.

이것을 극복하기 위해 나온 것이 HTTP/2로 스트림이라는 개념이 도입됩니다.

HTTP/2의 주요 특징은 다음과 같습니다.

• 스트림 기반의 전송 방식
• 멀티플렉싱
• 바이너리 방식의 인코딩
• 헤더 압축

이와 같은 동작들이 추가되면서, TCP/IP 4계층 Application 수준에서 발생하던 HOLB 문제를 피할 수 있었습니다.

하지만, 여전히 TCP 기반으로 동작하고 있었기 때문에 다음과 같은 문제점들을 안고 있었습니다.

• TCP와 SSL/TLS의 사용으로 인한 연결 레이턴시 문제
• 네트워크 환경 변화에 따른 재연결 문제
• 패킷 손실로 인한 모든 스트림 대역폭 감소 문제
• TCP 수준에서 발생하는 HOLB 문제

이러한 문제점들을 해결하기 위해서 UDP 기반의 QUIC 프로토콜을 사용하는 HTTP/3이 등장했습니다.

HTTP/3의 주요 특징들은 다음과 같습니다.

• UDP 기반의 QUIC 프로토콜 사용
• 연결 레이턴시 감소
• "독립 스트림" 사용
• Connection ID 사용
• 보안 강화

이와 같이 정리를 할 수 있겠네요.

HTTPS

• HTTPS에 대해서 설명해주세요.

해당 설명은 적합하지는 않아 보입니다. 정의가 명확해보이지 않는 것은 물론 가장 큰 문제는 "데이터의 신뢰성"을 보장해준다는 표현입니다.

데이터의 신뢰성을 보장해주는 것은 TCP 차원에서 제공해주는 것이고, 여기서 말하는 신뢰성이라고 함은 패킷의 순서를 보장해준다거나, 패킷이 수신자측까지 도달하는 것 등 온전하게 도달할 수 있다는 것을 의미합니다. HTTPS는 이러한 목적으로 사용하는 것이 아닙니다.

먼저, HTTPS는 웹 통신에 보안을 강화하기 위해 사용하는 프로토콜입니다.

중요 단어로, 웹 통신, 보안, 프로토콜이라는 점이겠죠.

HTTPS의 사용 목적은 데이터의 기밀성과 무결성 보장입니다. 단어가 생각나지 않을 수 있지만 외부로 데이터가 노출되는 것을 방지하는 기밀성과 데이터가 신뢰할 수 있는 송신자로부터 왔는지에 대한 무결성을 보장해주는 것이 목적인 것입니다.

HTTPS는 SSL/TLS라는 암호화 프로토콜을 사용한다는 점이고, 주요 특징으로는 다음과 같은 것들은 언급하면 됩니다.

• SSL/TLS를 이용한 데이터의 암호화

• 데이터의 무결성을 보장

• CA로부터 인증서를 발급받아 송신자의 신원 확인을 통한 인증

• TCP Port 443 사용

• SSL/TLS이 뭔가요?

해당 설명은 중간 과정을 너무 생략했습니다.

SSL/TLS는 암호화 프로토콜로, 데이터를 암호화하는데 사용되는 프로토콜입니다.

SSL/TLS는 CA로부터 받아온 인증서를 활용하여 공개키 방식과 세션키 방식을 이용해서 데이터를 암호화하여 전송합니다.

SSL/TLS의 주요 특징은 다음과 같습니다.

1. 해당 프로토콜을 사용한 데이터 암호화
2. TLS 핸드셰이킹
3. SSL/TLS 소켓 생성 및 관리

SSL(Secure Sockets Layer)가 이전 버전이며, TLS(Transfer Layer Security)가 후속 버전입니다.

SSL/TLS 1.2까지는 2RTT 과정을 통해 핸드셰이킹 과정이 이루어졌으며, SSL/TLS 1.3은 1RTT 시간동안 이루어집니다.

• 대칭키 암호화 방식에 대해 설명해주세요.

해당 설명은 나쁘진 않아 보이지만 추가적인 설명을 더 넣어줄 수 있을 것 같습니다.

대칭키 암호화 방식은 동일한 키를 사용해서 암호화/복호화 작업을 수행합니다. 대표적인 예시로 사용되는 것이 AES(Advanced Encrpytion Standard)와 DES(Data Encryption Standard)가 있습니다.
대칭키 암호화 방식은 하드웨어적으로 동작하기 때문에 빠른 속도의 성능을 보여줍니다.

실제로 SSL/TLS에서 해당 키 방식을 사용하고 있다는 부분도 괜찮은 것 같습니다.

키를 공유하기 위해서 비대칭키를 사용하는 방식을 언급하는 것은 옵션일 것 같습니다.

• 비대칭키(공개키) 암호화 방식에 대해서 설명해주세요.

해당 답변도 나쁘지 않아보입니다.

RSA 알고리즘을 사용해서 modular-n 항등식 특징과 소수의 곱을 통해서 공개키와 비밀키를 생성한다는 설명을 추가해도 괜찮을 것 같습니다.

특히, 계산이 느리기 때문에 이 단점을 극복하기 위해서 SSL/TLS에서는 세션키를 공유하기 위한 수단으로 활용한다는 점을 언급해도 좋을 것 같고,
비밀키에 대한 사용처에 따라 서명인지, 암호화인지 구분하는 설명은 좋은 것 같습니다.

• 전자 서명에 대해서 설명해주세요.

해당 설명도 괜찮아 보입니다.

전자 서명을 사용할 때 공개키를 사용하는 방식과 비밀키는 송신자측에서 사용한다는 점을 언급하는 것은 좋습니다.

이때, 해시 방식을 사용해서 증명해야되는 서명을 압축해서 암호화 한다는 점을 언급해도 좋을 것 같습니다.

• HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.)

해당 답변도 괜찮아 보입니다.

하지만 다시 한번 정리를 하겠습니다.

HTTPS의 암호화 과정은 SSL/TLS의 핸드셰이킹 과정을 통해 이루어집니다.

SSL/TLS 1.3과 이전 버전은 방식에 차이가 존재하며, 여기서는 SSL/TLS 1.3 이전 버전 방식으로 설명을 하겠습니다.

먼저, TCP Connection이 완료된 후, 클라이언트는 ClientHello를 보냅니다. 해당 메시지에서는 클라이언트가 지원하는 암호화 알고리즘 리스트와 세션 ID, 랜덤 바이트 문자열, TLS 버전 등과 같은 정보들이 담겨 있습니다.

이후 서버는 해당 리스트에서 하나를 선택한 후 공개키 방식으로 공개키와 비밀키를 생성합니다. 그리고 ServerHello를 클라이언트에게 전송합니다.
해당 메시지에는 인증서가 담겨있고, 추가적으로 공개키, 랜덤 바이트 문자열, 선택한 암호화 알고리즘과 같은 정보들이 담겨있습니다.

클라이언트는 해당 응답을 받은 후, 프리마스터 시크릿을 생성합니다. 이후, 서버에게 프리마스터 시크릿을 서버에서 보내준 공개키로 암호화한 후 전송합니다.

마지막으로 서버와 클라이언트는 주고 받은 정보를 이용해서 세션키를 생성한 후, 데이터 전송에 활용하면서 통신을 시작합니다.

SSL/TLS 1.3은 클라이언트가 공개키, 비밀키를 생성해서 자신이 비밀키를 사용한다는 방식에서 차이가 있고 이로 인해서 2RTT의 수행 동작을 1RTT로 줄였습니다.

DNS

• DNS가 뭔가요?

해당 설명은 DNS가 무엇인지에 대한 설명은 했지만, 목적이 빠졌습니다.

네트워크에서 사용하는 주소 체계는 IP 주소 방식으로 IPv4 기준 32비트 숫자로 이루어져 있습니다. 이것은 사용자들이 기억하기 어려운 형태로 되어있고 직관적이지 못합니다.

따라서, 호스트 네임을 IP 주소에 매칭하여 활용하고 이것을 위해서 사용하는 것이 Domain Name System, DNS입니다.

DNS는 위에서 말했다싶히 사용자들에게 편의성을 제공해주기 위해서 사용하고, 라우터에서는 가변 길이 주소를 사용하기 힘들기 때문에 데이터 전송 과정에서 목적지를 설정할 때는 IP 주소로 변환하기 위해서 사용됩니다.

또한, DNS는 부하 분산 기능을 제공할 수 있다는 이점을 가지고 있습니다.

• DNS 작동 방식에 대해 설명해주세요.

해당 설명은 괜찮습니다.

추가적으로 클라이언트 DNS를 종종 '리졸버'라고 부르기도 한다는 점을 기억하고 있으면 괜찮을 것 같습니다.

분산되어 있는 구조를 활용함으로써, "단일 장애 지점"으로 인한 문제를 피할 수 있고, 로드 밸런싱은 물론 관리하기 편하다는 이점을 가지게 됩니다.

• DNS 질의 종류에 대해 설명해주세요.

DNS의 질의 방식에는 두 종류가 있습니다.

재귀적 질의와 순환적 질의가 있습니다.

둘 다 공통적으로 클라이언트 DNS(리졸버)가 로컬 DNS 서버로 호스트 네임을 보낸다는 동작은 일치합니다.

하지만 재귀적 질의의 경우 로컬 DNS 서버가 Root Domain Server로 요청을 보내면서 모든 요청은 DNS 분산 데이터베이스 서버에서 이루어집니다. 따라서, 로컬 DNS 서버는 최종 결과만 받아오게 됩니다.

이와 다르게 순환적 질의는 로컬 DNS 서버가 요청을 각 분산 DNS 서버로 보내고 응답을 받아오는 형태로 동작합니다. 따라서, 로컬 DNS 서버는 여러번의 요청을 보내게 됩니다.

• DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?

해당 답변은 조금 모자라보이네요.

분명 DNS 서버가 UDP를 사용하는 주요 이유 중 하나는 연결 레이턴시 발생으로 인한 것이 크긴 합니다.

하지만, 그 뿐만이 아니라 UDP는 경량 프로토콜이기 때문에 낮은 오버헤드를 가지고 있어서 낮은 데이터 전송에 효율적인 특징을 가지고 있습니다. 이것은 DNS 요청 방식에 알맞습니다.

또한, UDP 자체가 확장성이 좋기 때문에 아주 넓게 분산되어 사용하는 DNS 서버에서 활용하기 적합합니다.

마지막으로, Connection을 맺지 않기에 연결 상태를 저장하지 않는다는 점에서 유용합니다.

그렇다고 무조건 UDP만 사용하는 것도 아닙니다.

만약, 데이터의 크기가 UDP 패킷 크기를 초과했다면 TCP를 활용해야 합니다. 또한 보안적인 문제를 예방하기 위해 DNSSEC(DNS Security Extension)을 사용할 경우에도 TCP를 이용합니다.

• DNS 레코드가 무엇인가요?

Type d가 아니라 Type A이고, 그 외에도 좀 더 설명을 할 필요가 있습니다.

DNS 레코드는 분산 DNS 데이터베이스에 저장되는 데이터의 저장 단위로, 호스트 이름(도메인 이름)과 ip 주소의 매핑 정보를 가지고 있습니다.

다음과 같은 것들이 있습니다.

• Type A: Domain Name -> IPv4
• Type AAAA: Domain Name -> IPv6
• Type NS: Domain Name -> Next Domain Server Address
• Type MX: Domain Name -> 호스트의 이메일 주소
• Type CNAME: Domain Name -> Canonical Domain Name(별칭)

이렇게 답변할 수 있을 것 같습니다.

답변 추상화 시키기

HTTP

• HTTP 프로토콜에 대해서 설명해주세요.

HTTP 프로토콜은 웹에서 메시지(정보)를 전달하기 위해서 사용하는 전송 프로토콜입니다.

HTTP 프로토콜은 신뢰성 있는 데이터 전송을 보장하기 위해서 사용합니다.

HTTP 프로토콜의 구조는 요청줄, 헤더, 본문으로 이루어져 있으며 해당 구조를 통해서 정보를 주고 받습니다.

• HTTP의 요청/응답 모델에 대해 설명해주세요.

HTTP 요청 모델은 다음과 같습니다.

먼저, 요청줄에 메서드, URI, 버전 번호가 담깁니다. 이후 헤더와 본문이 나옵니다.

HTTP 응답 모델은 다음과 같습니다.

요청줄에 버전 번호, 상태 코드, 사유 구절이 담깁니다. 이후 헤더와 본문이 나옵니다.

• HTTP 메서드중 GET과 POST의 차이점에 대해 설명해주세요.

HTTP 메서드의 GET 방식과 POST 방식의 주요 차이점은 "멱등"인지 "비멱등" 요청인지로 구분됩니다.

GET 메서드는 리소스를 조회하기 위한 목적으로 사용되며 "멱등" 요청에 해당합니다.

POST 메서드는 리소스를 저장하거나 업데이트하기 위한 목적으로 사용되며 "비멱등" 요청에 해당합니다.

GET 메서드에서 파라미터를 전달하고 싶다면 "Query String" 혹은 "Path Value"를 사용할 수 있습니다. 기본적으로 요청 본문을 사용하지 않는 것이 특징입니다.

이와 반대로 POST 메서드는 본문에 데이터를 담습니다.

마지막으로, "멱등" 요청의 경우 브라우저에 캐싱될 수 있지만, "비멱등" 요청의 경우는 브라우저에 캐싱되지 않습니다.

• HTTP 메서드중 PUT과 PATCH의 차이점에 대해 설명해주세요.

HTTP 메서드의 PUT 메서드와 PATCH 메서드의 주요 차이점은 리소스를 얼마나 변화시킬지에 대한 정도의 차이입니다.

PUT 메서드의 경우 리소스의 전체를 대체하거나 저장하기 위해서 사용합니다.

PATCH 메서드의 경우 리소스의 일부분을 수정하기 위해서 사용합니다.

PUT 메서드는 리소스의 전체를 대체하기 때문에, 만약 리소스의 일부분만 본문에 담아서 보낸다면 나머지 부분은 기본값 혹은 null 값으로 저장될 수 있습니다.

PATCH 메서드는 수정이 필요한 리소스의 일부분만 전송하면 되기 때문에 오버헤드 측면에서 절약적입니다.

• HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 설명해주세요.

HTTP 상태 코드는 요청에 대한 응답의 결과를 클라이언트에게 알려주기 위해서 사용합니다. 상태 코드는 응답 결과가 약속되어 있는 숫자로 매핑되어 있습니다.

1xx의 경우 정보 전달, 2xx의 경우 성공 응답, 3xx의 경우 리다이렉션 응답, 4xx의 경우 클라이언트 에러 응답, 5xx의 경우 서버 에러 응답으로 활용됩니다.

대표적으로 사용되는 상태 코드는 200 OK, 201 Created, 303 See Other, 400 Bad Request, 401 Unauthroized, 403 Forbidden, 404 Not Found, 500 Interval Server Error, 503 Bad Gateway 등이 있습니다.

• HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요.

HTTP 헤더은 웹 통신에서 메시지 전송 과정에서 필요한 부가적인 정보를 전달하기 위해서 사용합니다.

HTTP 헤더는 5가지 종류가 존재합니다.

일반 헤더, 요청 헤더, 응답 헤더, 엔티티 헤더, 확장 헤더가 있습니다.

대표적으로 일반 헤더에는 Connection, Date와 같은 것들이 있습니다.
요청 헤더에는 Client-IP, 조건부 요청 헤더, Accept 관련 헤더, 요청 보안 헤더 등이 있습니다.
응답 헤더에는 Age, 협상 헤더, 응답 보안 헤더 등이 있습니다.
엔티티 헤더에는 Allow, Location, Content 관련 헤더 등이 있습니다.

• HTTP의 무상태성(Stateless)에 대해서 설명해주세요.

HTTP 무상태성은 세션에 대한 정보를 서버측에서 저장하지 않는다는 것을 의미합니다.

HTTP는 연결 기반 프로토콜이라서 클라이언트와 서버간의 통신으로 사용되는 이 과정에서 이루어지는 정보를 서버측에서 저장하지 않습니다.

이로 인해서, 확장성과 유연성을 보장해줍니다.

단점으로는 이러한 독립적인 처리로 인해 추가적인 매커니즘이 요구될 수 있다는 점입니다.

만약, 저장할 정보가 있다면 사용자의 쿠키나 세션을 활용할 수 있습니다.

• HTTP Keep-Alive에 대해서 설명해주세요.

HTTP Keep-Alive는 HTTP/1.0의 확장 기능으로 나온 것으로 HTTP에서 사용하는 TCP는 3-way handshake과정을 요구하기 때문에 이로 인해서 연결 지연(레이턴시)가 발생할 수 있습니다. 만약, SSL/TLS 암호화 프로토콜도 같이 사용한다면 더욱 연결 레이턴시는 길어질 것입니다.

이것을 위해서 기존에 Connection을 재활용하기 위해서 해당 기능을 제공합니다.

하지만, 이것은 단점이 존재하는데 연결을 하기 위해서 항상 헤더에 Connection을 담아서 보내야 하고, 멍청한 프록시가 있다면 이것을 인식하지 못하여 연결 과정에서 문제가 발생할 수 있습니다.

또한 해당 기능은 확장 기능으로 표준화 기능이 아니기 때문에 네트워크 장치들이 인식하지 못하는 상황이 발생할 수 있습니다.

• HTTP 파이프라이닝에 대해서 설명해주세요.

HTTP 파이프라이닝은 HTTP/1.1에서 지속 커넥션 기능이 추가되면서 가능하게 된 기능입니다.

HTTP 파이프라이닝은 지속 커넥션위에서 사용되며, 이전 HTTP 요청/응답 방식은 이전 요청에 대한 응답이 도착한 후에 다음 요청을 보낼 수 있었습니다.
이로 인해서 지연이 발생하는데 요청을 연속적으로 보낼 수 있도록 지원하는 것이 파이프라이닝입니다.

하지만, 서버에서 응답을 순차적으로 처리해야된다는 점에서 여전히 Head Of Line Blocking 문제가 존재합니다.

• HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요.

HTTP/1.1은 HTTP/1.0의 전송 지연 문제를 해결하기 위해서 나왔습니다.

대표적인 특징으로 병렬 커넥션, 지속 커넥션, 파이프라이닝, 가상 호스팅 지원 등이 있습니다.

하지만, 여전히 Head Of Line Blocking 문제가 존재하고, 텍스트 기반 인코딩 방식을 사용한다는 점에서 오버헤드가 크다는 문제를 안고 있습니다.

이를 해결하기 위해 HTTP/2가 나왔습니다.

HTTP/2의 대표적인 특징으로는 스트림 기반 전송 방식, 멀티플렉싱, 바이너리 인코딩 방식, 헤더 압축 등과 같은 기능들을 제공합니다.

여전히 TCP를 사용함으로써 문제를 안고 있었는데, 먼저 TCP 사용으로 인한 Head Of Line Blocking 문제가 남아있습니다. 이것은 TCP 처리 방식에서 발생하는 문제입니다. 또한, 하나의 커넥션안에서 여러 스트림을 사용한다는 점에서 문제가 생길 수 있습니다. 네트워크 환경이 변경 되었을 때 재연결을 해야되는 문제도 존재합니다.

이것을 해결하기 위해 UDP 기반의 QUIC 프로토콜을 사용하는 HTTP/3이 등장합니다.

HTTP/3의 대표적인 특징으로 QUIC 프로토콜을 사용한다는 점, 연결 레이턴시를 줄였다는 점, "독립 스트림"을 사용한다는 것과 네트워크 환경 변화에도 재연결을 사용하지 않게 해주는 Connection ID의 도입 마지막으로 보안까지 강화했다는 특징을 가지고 있습니다.

HTTPS

• HTTPS에 대해서 설명해주세요.

HTTPS는 웹 통신에서 보안을 강화하기 위한 보안 프로토콜로, HTTP 통신에서 메시지를 전달하는 과정에서 메시지의 기밀성과 무결성을 보장해주기 위해서 사용합니다.

HTTPS의 주요 특징으로는 데이터의 암호화 작업을 통해서 데이터의 기밀성을 보장해준다는 점과 데이터의 변경 또는 손실의 발생을 막아주는 데이터 무결성 보장, Certificate Authority로 부터 받은 인증서를 통해 송신자를 인증할 수 있는 기능 마지막으로 TCP Port 443을 사용한다는 특징을 가지고 있습니다.

• SSL/TLS이 뭔가요?

SSL/TLS는 암호화 프로토콜로, 데이터를 암호화할 때 사용합니다.

SSL/TLS는 CA로부터 받아온 인증서를 활용하여 공개키와 대칭키의 방식 둘 다 사용하고, 실제로 데이터를 암호화할 떄는 세션키 즉, 대칭키를 활용하여 암호화 작업을 수행합니다.

SSL/TLS가 가지고 있는 특징은 먼저 암호화 작업을 수행한다는 점과 TLS 핸드셰이킹 과정이 요구된다는 점 그리고 SSL/TLS 소켓의 생성과 관리를 한다는 특징을 가지고 있습니다.

SSL은 이전 버전이고, TLS는 후속 버전입니다.

• 대칭키 암호화 방식에 대해 설명해주세요.

대칭키 암호화 방식은 데이터의 암호화/복호화 작업을 같은 키로 수행하는 방식입니다.

대칭키 암호화 방식은 기본적으로 하드웨어 적으로 동작하기 때문에 공개키 방식보다 더 빠른 속도의 성능을 가지고 있으며, 실제로 SSL/TLS에서 해당 키를 가지고 데이터 암호화/복호화 작업을 수행합니다.

대표적인 알고리즘으로 AES, DES가 존재합니다.

• 비대칭키(공개키) 암호화 방식에 대해서 설명해주세요.

비대칭키 암호화 방식은 데이터 암호화/복호화 작업 각각 다른 키로 수행을 하는 방식을 의미합니다.

modular-n 항등식 특징과 소수 부분 곱 방식을 이용한 RSA 알고리즘을 키를 생성합니다.

비대칭키 암호화 방식은 대칭키보다 요구되는 계산 작업이 많기 때문에 속도적인 측면에서는 더 느립니다.

비대칭키 암호화 방식에서 비밀키를 어디에서 활용하는냐에 따라 암호화/복호화 방식인지 서명 방식인지 나뉘는데 만약, 서버에서 비밀키를 사용하여 데이터를 암호화 할 경우 서명이라고 하고, 클라이언트가 비밀키를 활용해서 복호화 작업을 진행한다면 일반적인 암호화/복호화 방식으로 볼 수 있습니다.

• 전자 서명에 대해서 설명해주세요.

전자 서명은 웹 통신에서 메시지의 출처에 대한 신뢰성을 확인하기 위해서 사용합니다.

전자 서명은 비밀키 암호화 방식을 통해서 수행되며, 비밀키를 사용해서 서버에서 데이터를 암호화 하는 것이 특징입니다.

또한, 해당 과정에서 오버헤드를 줄이기 위해서 해싱 기법을 같이 사용합니다.

• HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.)

SSL/TLS의 경우 핸드셰이킹 과정을 요구하는데 SSL/TLS 1.3 이전 버전의 경우 2RTT동안 이루어지고, SSL/TLS 1.3 버전은 1RTT 동안 이루어집니다.

여기서는, SSL/TLS 1.3 이전버전으로 설명을 하겠습니다.

먼저, 해당 핸드셰이크는 TCP Connection이 완료된 후 진행됩니다.

클라이언트가 먼저 ClientHello를 보내는데 해당 메시지에는 클라이언트가 사용할 수 있는 암호화 알고리즘 리스트, 랜덤 문자열 바이트, 세션 ID, TLS 버전 등이 담겨있습니다.

서버는 리스트로부터 알고리즘을 선택한 후, 다시 클라이언트에게 ServerHello를 보냅니다. 해당 메시지에는 인증서가 담겨있고, 선택한 암호화 알고리즘, 랜덤 바이트 문자열, 그리고 해당 알고리즘을 통해 생성한 공개키가 담겨있습니다.

클라이언트는 프리마스터 시크릿을 생성하여 이것을 공개키로 암호화하여 다시 서버에게 보냅니다.

마지막으로 주고 받은 데이터를 활용하여 세션키 즉, 대칭키를 만들어서 이것을 데이터 암호화/복호화할 때 사용합니다.

이것으로 핸드셰이킹 과정은 마무리가 됩니다.

SSL/TLS 1.3 버전의 경우 클라이언트가 비밀키를 사용한다는 점에서 차이를 보여줍니다.

DNS

• DNS가 뭔가요?

DNS는 Domain Name System으로 호스트 네임을 IP 주소로 바꿔주는 것을 의미합니다.

사용자들은 IP 주소를 기억하기 쉽지 않아서 이것을 호스트 네임으로 매칭하여 활용할 필요가 있었고, 라우터는 가변 길이 방식인 호스트 네임을 사용하기 힘들기 때문에 DNS를 사용합니다.

추가적으로 DNS는 트래픽 분산 기능을 수행할 수 있기 때문에 이점이 있습니다.

• DNS 작동 방식에 대해 설명해주세요.

DNS 작동 방식은 우선 클라이언트 DNS 즉 '리졸버'가 로컬 DNS 서버로 요청을 보내면서 시작합니다.

로컬 DNS 서버는 순차적으로 Root DNS 서버, TLD DNS 서버, 책임 DNS 서버에 질의를 해가며 호스트 네임을 IP 주소로 바꿔옵니다. 최종적으로 로컬 DNS가 클라이언트 DNS에게 IP 주소를 주면서 마무리가 됩니다.

기본적으로 UDP 기반으로 동작하고 캐싱 기능을 가지고 있기 때문에 빠른 성능을 보여줍니다.

• DNS 질의 종류에 대해 설명해주세요.

DNS 질의에는 두가지 종류가 있습니다.

재귀적 질의와 순차적 질의 두가지가 있습니다.

동작 순서로 차이점을 확인해보자면, 먼저 리졸버에서 로컬 DNS 서버로 호스트 네임을 보내는 것을 일치합니다.

재귀적 질의의 경우, 로컬 DNS 서버가 Root DNS 서버로 질의를 보내면서 각 계층 DNS 서버에서 모든 처리가 이루어진 후 최종 응답을 로컬 DNS 서버로 보내는 방식으로 동작합니다.

순차적 질의의 경우, 로컬 DNS 서버가 각 계층 DNS 서버와 요청/응답 통신을 하면서 이루어지기 때문에 로컬 DNS 서버에서 여러번의 요청을 보내게 됩니다.

• DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?

DNS가 UDP를 사용하는 가장 큰 이유는 TCP Connection으로 인한 연결 지연(레이턴시)입니다.

또한, UDP는 TCP보다 경량 프로토콜로 가지고 있는 기능들이 더 적기 때문에 더 낮은 오버헤드를 가지고 있어서 낮은 데이터 전송에서 유용합니다.

TCP랑 다르게 별도의 Connection을 맺을 필요가 없고, 이로 인해서 세션 정보 유지가 불필요합니다.

마지막으로 UDP는 TCP보다 확장성 측면에서 더 좋기 때문에 수 많은 질의를 처리해야하는 DNS에서 사용하기 적합합니다.

• DNS 레코드가 무엇인가요?

DNS 레코드는 분산 DNS 데이터베이스에서 저장하는 정보 단위로, 호스트 네임과 IP 주소를 매핑하는 정보를 가지고 있습니다.

대표적인 DNS 레코드로 Type A, Type AAAA, Type MX, Type CNAME, Type NS와 같은 것들이 있습니다.

참고한 자료

• 네트워크: 하향식 접근
• HTTP 완벽 가이드