개발일지
HTTP,HTTPS,DNS 정리 본문
HTTP 프로토콜에 대해서
HTTP는 HyperText Transfer Protocol의 약자로, 웹 브라우저와 웹 서버 간에 데이터를 주고받기 위한 통신 규약입니다. 쉽게 말해, 우리가 웹사이트를 방문할 때 브라우저가 서버에 요청을 보내고, 서버가 웹페이지를 응답으로 보내주는 그 과정이 HTTP를 통해 이루어집니다. 예를 들어, 여러분이 브라우저에 http:www.google.com 을 입력하면, 브라우저는 HTTP 요청을 서버로 보내고, 서버는 이 요청에 맞는 웹페이지를 응답으로 보냅니다.
HTTP는 마치 우리가 물건을 주문할 때와 비슷하다고 생각함 온라인 쇼핑몰에 접속해 물건을 고르는 것이 "요청(request)"이고, 물건이 우리 집에 배송되는 것이 "응답(response)"이라고 할 수 있습니다
HTTP의 요청/응답 모델에 대해서
HTTP 요청/응답 모델은 클라이언트와 서버 간의 통신 패턴을 설명하는 개념이다. 클라이언트는 웹 브라우저처럼 정보를 요청하는 쪽이고, 서버는 이 요청에 응답을 보내는 쪽입니다. 이 모델은 웹에서의 모든 통신의 기본이라고 할 수 있다
위의 예시에서 요청이 주문 응답이 배송이라고 할때 주문과 배송은 독립적인 행위이다 주문을 여러번 한다면 쇼핑몰은 각각의 주문에 대해 개별적으로 배송을 처리한다. 이처럼, HTTP의 각 요청은 다른 요청과 상관없이 처리한다
HTTP 메서드 중 GET과 POST의 차이점에 대해서
GET 메서드
GET 메서드는 주로 서버에서 데이터를 조회할 때 사용, 이때 요청 데이터는 URL에 포함되어 서버로 전송되며, 브라우저나 캐시 서버에 의해 캐시될 수 있다.
POST 메서드
POST 메서드는 서버에 데이터를 전송하거나 새로운 리소스를 생성할 때 사용, 데이터는 요청 본문에 포함되어 전송되며, GET 메서드와 달리 URL에 포함되지 않기 때문에 캐싱되지 않는다.
HTTP 메서드 중 PUT과 PATCH의 차이점에 대해서
PUT 메서드
PUT 메서드는 리소스를 완전히 대체하는 데 사용, 사용자의 프로필 정보를 업데이트할 때 사용한다 만약 해당 리소스가 존재하지 않으면, PUT 요청은 새로운 리소스를 생성할 수 있다.
PATCH 메서드
PATCH 메서드는 리소스를 부분적으로 수정하는 데 사용, 사용자의 이메일 주소만 변경할 때 사용한다.
HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇 가지 설명해주세요.
HTTP 상태 코드는 서버가 클라이언트의 요청에 대한 결과를 숫자와 설명으로 나타내는 것 상태 코드는 클라이언트가 보낸 요청이 성공했는지, 실패했는지, 또는 추가 조치가 필요한지를 알수 있다.
상태 코드 예시:
- 200 OK: 요청이 성공적으로 처리되었음을 나타냅니다.
- 404 Not Found: 요청한 리소스를 찾을 수 없음을 의미합니다.
- 500 Internal Server Error: 서버에서 요청을 처리하는 중에 오류가 발생했음을 나타냅니다
HTTP 헤더
HTTP 헤더는 클라이언트와 서버가 서로 정보를 주고받을 때, **추가적인 정보(메타데이터)**를 포함하는 부분이다. 헤더는 요청 또는 응답의 시작 부분에 위치하며, 본문과는 별개로 처리 쉽게 말해, 헤더는 요청이나 응답에 대한 부가 설명을 담고 있는 메모 같은 것이라고 생각할 수 있다. 예를 들어, 요청의 유형, 데이터 형식, 인증 정보 등을 포함할 수 있다.
알고 있는 HTTP 헤더 예시:
- Authorization 헤더
- 클라이언트가 서버에 인증 정보를 제공할 때 사용됩니다. 보통은 사용자 이름과 비밀번호나 토큰 같은 것을 포함해 보호된 리소스에 접근할 때 사용하죠.
- 예시: Authorization: Bearer <token> (토큰 기반 인증)
- 비유: 만약 여러분이 비밀번호로 잠겨 있는 문을 열고 싶다면, 그 문을 열 수 있는 열쇠(토큰)를 보여줘야 하겠죠? 이 열쇠를 보여주는 것이 바로 Authorization 헤더입니다.
- Content-Type 헤더
- 서버나 클라이언트가 전송하는 데이터의 형식을 알려줍니다. 예를 들어, JSON, HTML, XML 등 다양한 데이터 형식이 있을 수 있어요.
- 예시: Content-Type: application/json
- 비유: 여러분이 책을 빌릴 때 그 책이 소설인지, 만화책인지, 또는 과학책인지 알려주는 것처럼, Content-Type 헤더는 서버나 클라이언트에게 "내가 보내는 데이터가 어떤 형식이야!"라고 알려주는 역할을 합니다.
- User-Agent 헤더
- 클라이언트가 서버에 요청을 보낼 때, 자신이 어떤 브라우저나 기기를 사용하고 있는지 알려주는 헤더입니다.
- 예시: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
- 비유: 마치 여러분이 누군가에게 자신을 소개할 때 "나는 누구입니다."라고 말하는 것과 비슷합니다. 서버에게 "나는 이런 브라우저를 사용하고 있어!"라고 알려주는 거죠.
HTTP의 무상태성(Stateless)에 대해서 설명
HTTP의 무상태성이란, 서버가 클라이언트의 각 요청을 독립적으로 처리하며, 이전 요청의 상태나 정보를 기억하지 않는다는 것을 의미합니다. 다시 말해, 클라이언트가 서버로 보내는 각 HTTP 요청은 이전 요청과는 완전히 별개이며, 서버는 그 요청만으로 필요한 모든 정보를 처리해야 한다
왜 HTTP가 무상태 프로토콜로 설계되었나요?
HTTP의 무상태성은 확장성과 단순성을 높이기 위해 고안되었습니다. 서버가 클라이언트의 상태를 관리하지 않음으로써, 더 많은 클라이언트의 요청을 효율적으로 처리할 수 있습니다. 서버는 요청마다 필요한 자원만 할당하면 되기 때문에 복잡한 상태 관리가 필요 없고, 더 많은 사용자 요청을 처리할 수 있어요.
무상태성의 장점
- 확장성: 서버가 클라이언트의 상태를 관리하지 않으므로, 클라이언트 수가 증가하더라도 서버의 부하가 크게 늘어나지 않습니다.
- 단순성: 요청을 처리하는 로직이 단순해집니다. 각 요청이 독립적으로 처리되므로, 특정 요청이 실패하더라도 다른 요청에 영향을 미치지 않습니다.
- 유연성: 클라이언트는 여러 서버에 요청을 분산하여 보낼 수 있습니다. 서버 간의 상태 동기화가 필요 없으므로 서버를 유연하게 구성할 수 있어요.
무상태성의 단점
무상태성은 서버가 클라이언트의 상태를 기억하지 않기 때문에, 클라이언트가 서버와의 상호작용을 유지하려면 매 요청마다 필요한 모든 정보를 포함해야 합니다. 예를 들어, 사용자가 웹사이트에 로그인했을 때, 이후의 모든 요청에 사용자의 인증 정보가 포함되어야 합니다. 이를 보완하기 위해 세션 쿠키, 토큰 등의 방법으로 상태를 관리합니다.
HTTP Keep-Alive에 대해서 설명해주세요.
HTTP Keep-Alive는 HTTP/1.1에서 도입된 기능으로, 하나의 TCP 연결을 통해 여러 HTTP 요청과 응답을 연속적으로 주고받을 수 있게 해주는 옵션입니다. 기본적으로 HTTP는 요청을 보낸 후 응답을 받고 나면 TCP 연결을 종료합니다. 하지만 Keep-Alive를 사용하면, 클라이언트와 서버 간의 연결을 유지하여 동일한 연결을 통해 추가적인 요청과 응답을 주고받을 수 있습니다.
이해한 예시:
- 전화 끊지 않기: 마치 누군가와 전화 통화를 할 때, 매번 전화를 끊고 다시 거는 대신 전화를 끊지 않고 대화를 이어가는 것과 같습니다. Keep-Alive는 이처럼 한 번 연결된 상태를 유지하면서 여러 번의 요청과 응답을 처리하는 거죠. 이 덕분에 통화 연결에 걸리는 시간이 줄어들고, 대화가 더 매끄럽게 이어집니다.
장점:
- 성능 향상: 각 요청마다 새로운 TCP 연결을 설정하고 종료하는 오버헤드가 줄어듭니다.
- 네트워크 효율성: 동일한 연결을 통해 여러 요청을 처리하므로, 네트워크 리소스가 절약됩니다.
- 부하 감소: 서버는 매 요청마다 새로운 연결을 설정할 필요가 없기 때문에, 동시에 더 많은 요청을 처리할 수 있습니다.
단점:
- 리소스 소비: 연결을 유지하는 동안 서버와 클라이언트 모두 일정량의 리소스를 사용합니다. 많은 클라이언트가 Keep-Alive 연결을 유지하면 서버의 자원이 고갈될 수 있습니다.
- 복잡한 연결 관리: 서버는 일정 시간 동안 비활성화된 Keep-Alive 연결을 종료해야 하므로, 연결 상태를 관리하는 로직이 필요합니다.
HTTP 파이프라이닝
HTTP 파이프라이닝은 HTTP/1.1에서 도입된 기술로, 클라이언트가 서버에 여러 HTTP 요청을 보낼 때 응답을 기다리지 않고 연속적으로 보낼 수 있는 기능입니다. 이는 네트워크 효율성을 높이기 위한 방법 중 하나입니다.
HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해
1. HTTP/1.1의 특징 및 한계
특징:
- 지속 연결 (Persistent Connection): HTTP/1.1에서는 Keep-Alive 헤더가 기본으로 설정되어 있어, 여러 요청이 하나의 TCP 연결에서 처리될 수 있습니다.
- 파이프라이닝 (Pipelining): 여러 HTTP 요청을 순차적으로 보내되, 첫 번째 요청의 응답을 기다리지 않고 다음 요청을 보내는 방식입니다.
- 캐싱 및 콘텐츠 협상: HTTP/1.1은 캐싱 메커니즘과 콘텐츠 협상(예: 언어, 인코딩 등)을 지원하여 웹 페이지 로드 속도를 높이고, 클라이언트의 요구에 맞게 콘텐츠를 제공합니다.
한계:
- 단일 요청/응답 지연: 하나의 연결에서 한 번에 하나의 요청/응답만 처리할 수 있기 때문에, 동시에 여러 자원을 요청할 때 지연이 발생할 수 있습니다.
- 헤더 오버헤드: 모든 요청에 대해 완전한 헤더를 전송해야 하며, 이는 작은 자원에 대해서도 큰 오버헤드를 발생시킬 수 있습니다.
2. HTTP/2의 개선점과 특징
특징:
- 멀티플렉싱 (Multiplexing): 하나의 연결에서 여러 요청과 응답을 병렬로 처리할 수 있어, HTTP/1.1에서의 지연 문제를 해결합니다.
- 헤더 압축: 헤더 데이터를 압축하여 전송하기 때문에, 헤더 오버헤드가 줄어들고 전송 속도가 빨라집니다.
- 서버 푸시 (Server Push): 서버는 클라이언트가 요청하지 않은 리소스도 미리 클라이언트에게 보낼 수 있습니다. 예를 들어, 웹 페이지 로딩을 가속화할 수 있습니다.
- 이진 프로토콜 (Binary Protocol): 텍스트 기반이 아닌 이진 형식으로 데이터를 전송하여, 데이터 처리가 더 효율적으로 이루어집니다.
한계:
- 보안 의존성: HTTP/2는 SSL/TLS에 의존적이며, 대부분의 브라우저는 암호화된 연결(HTTPS)에서만 HTTP/2를 지원합니다.
- 헤드 오브 라인 블로킹 (Head-of-Line Blocking) 문제: 멀티플렉싱으로 인해 일부 해결되었지만, TCP 레벨에서 발생하는 문제는 여전히 존재합니다.
3. HTTP/3의 혁신적 변화와 특징
특징:
- QUIC 프로토콜 사용: HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용하여, 연결 설정과 데이터 전송을 병렬로 처리할 수 있습니다. 이를 통해 지연 시간이 크게 줄어듭니다.
- 헤드 오브 라인 블로킹 문제 해결: QUIC은 패킷 손실이 발생해도 다른 스트림에 영향을 주지 않아, HTTP/2에서 발생하던 문제를 해결합니다.
- 내장된 보안: QUIC은 TLS 1.3을 프로토콜 자체에 내장하여 보안성을 강화하고, 빠르게 암호화된 연결을 설정할 수 있습니다.
- 빠른 연결 설정: 첫 번째 데이터 패킷을 보내는 시점에서 연결을 설정하므로, 기존 TCP와 TLS 연결보다 훨씬 빠르게 데이터를 전송할 수 있습니다.
한계:
- 네트워크 지원: QUIC이 UDP를 기반으로 하기 때문에, 모든 네트워크 환경에서 완벽하게 지원되지 않을 수 있습니다.
- 구현 복잡성: 기존 인프라와의 호환성 및 구현 복잡성이 있습니다.
HTTPS란 무엇인가?
HTTP의 보안 버전입니다. 웹 브라우저와 웹 서버 간의 데이터 통신을 암호화하여, 중간에 누군가가 데이터를 가로채거나 변경하지 못하도록 보호합니다. 이는 특히 비밀번호, 신용카드 정보와 같은 민감한 데이터를 보호하는 데 필수적입니다.
HTTPS는 어떻게 작동하나
HTTPS는 SSL(보안 소켓 계층) 또는 **TLS(전송 계층 보안)**라는 보안 프로토콜을 사용해 데이터를 암호화합니다. 그 과정은 다음과 같아요:
- 클라이언트 요청: 사용자가 HTTPS로 시작하는 웹사이트에 접속하면, 브라우저가 서버에 HTTPS 연결을 요청해요.
- 서버 인증서 전송: 서버는 SSL/TLS 인증서를 클라이언트(브라우저)에게 전송합니다. 이 인증서에는 서버의 공개 키와 서버의 신뢰성을 보증하는 **인증 기관(CA)**의 서명이 포함되어 있어요.
- 인증서 검증: 브라우저는 이 인증서가 신뢰할 수 있는지 확인해요. 서버가 정말 안전한지 확인하는 과정이죠.
- 세션 키 생성: 브라우저는 서버의 공개 키를 사용해 세션 키라는 대칭 키를 암호화하여 서버에 전송합니다. 서버는 자신의 비공개 키로 이를 복호화하여 세션 키를 얻습니다. 이제 이 세션 키로 데이터를 암호화해 통신합니다.
- 암호화된 통신: 브라우저와 서버 간의 모든 데이터는 이 세션 키로 암호화되어 전송됩니다. 덕분에 데이터는 안전하게 보호됩니다.
SSL/TLS란 무엇인가?
SSL/TLS는 웹상에서 데이터를 안전하게 전송하기 위한 보안 프로토콜이에요. SSL은 초기에 사용되었고, 현재는 그 후속 버전인 TLS가 대부분의 웹 통신에서 사용되고 있습니다. 사실 요즘엔 사람들이 "SSL"이라고 말할 때, 실제로는 "TLS"를 의미하는 경우가 많아요.
SSL/TLS의 주요 기능
- 암호화 (Encryption): SSL/TLS는 데이터를 암호화하여 전송합니다. 덕분에 데이터가 전송 중에 가로채지더라도, 내용을 알아낼 수 없도록 보호해 줍니다.
- 인증 (Authentication): 서버는 SSL/TLS 인증서를 사용해 자신이 신뢰할 수 있는 서버임을 클라이언트에게 증명합니다.
- 데이터 무결성 (Integrity): SSL/TLS는 데이터가 전송 중에 변경되지 않도록 보호합니다. 데이터가 변조되면 이를 감지할 수 있어요.
대칭키와 비대칭키 암호화 방식
대칭키 암호화
대칭키 암호화에서는 하나의 키로 데이터를 암호화하고 복호화해요. 송신자와 수신자가 같은 키를 사용하기 때문에 매우 효율적입니다.
- 장점: 속도가 빠르고, 대량의 데이터를 효율적으로 처리할 수 있어요.
- 단점: 키를 안전하게 공유하고 관리하는 것이 어렵습니다. 키가 유출되면 문제가 생길 수 있어요.
비대칭키 암호화
비대칭키 암호화에서는 두 개의 키(공개 키와 개인 키)를 사용해 데이터를 보호합니다. 공개 키로 암호화된 데이터는 개인 키로만 복호화할 수 있으며, 그 반대도 가능해요.
- 장점: 보안성이 뛰어나며, 인증 기능도 제공해요.
- 단점: 대칭키 암호화에 비해 연산 속도가 느리고, 리소스가 많이 소모됩니다.
전자 서명은 무엇인가?
전자 서명은 디지털 문서에 서명할 때 사용하는 데이터로, 문서의 무결성과 서명자의 신원을 보장해 줍니다. 전자 서명은 서명자의 개인 키로 생성되며, 누구나 서명자의 공개 키를 이용해 서명을 검증할 수 있어요.
HTTPS 암호화 과정 (SSL Handshake)
HTTPS를 통해 안전한 통신이 이루어지기까지는 SSL Handshake라는 절차가 필요해요. 이 과정에서 클라이언트와 서버가 서로 신뢰할 수 있는 연결을 설정하게 됩니다.
- 클라이언트 헬로: 브라우저가 서버에 연결을 요청합니다. 이 요청에는 브라우저가 지원하는 암호화 알고리즘과 무작위 숫자가 포함돼요.
- 서버 헬로: 서버는 클라이언트의 요청을 받아들여, 선택한 암호화 알고리즘과 인증서를 클라이언트에게 전송합니다.
- 인증서 검증: 클라이언트는 서버가 보낸 인증서를 검증하고, 서버의 신뢰성을 확인합니다.
- 세션 키 생성: 클라이언트는 서버의 공개 키를 사용해 세션 키를 암호화해 서버에 전송합니다.
- 암호화된 통신: 클라이언트와 서버는 세션 키를 사용해 데이터를 암호화하여 안전하게 통신합니다.
DNS가 뭔가요?
DNS는 인터넷의 전화번호부와 같습니다. 사용자가 웹 브라우저에 도메인 이름을 입력하면, DNS가 이를 해당하는 IP 주소로 변환하여 사용자가 요청한 서버와 연결될 수 있도록 합니다. 이 과정이 없으면, 사용자는 웹사이트에 접근하기 위해 각 서버의 IP 주소를 직접 기억해야 합니다.
DNS 작동 방식 단계별 설명
- 도메인 이름 요청: 사용자가 웹 브라우저에 도메인 이름을 입력하면, 이 요청은 먼저 사용자의 컴퓨터에서 가까운 로컬 DNS 리졸버로 전달됩니다. 이 리졸버는 ISP(인터넷 서비스 제공자) 또는 기업 네트워크 내에 위치할 수 있습니다.
- 캐시 확인: 로컬 DNS 리졸버는 먼저 캐시에 저장된 도메인 이름과 IP 주소 쌍을 확인합니다. 만약 캐시에 해당 도메인 이름이 있다면, 리졸버는 즉시 해당 IP 주소를 반환합니다. 그렇지 않으면, 다음 단계로 넘어갑니다.
- 루트 DNS 서버 쿼리: 캐시에 데이터가 없으면, 로컬 DNS 리졸버는 루트 DNS 서버로 쿼리를 보냅니다. 루트 DNS 서버는 도메인의 최상위 수준인 TLD(Top-Level Domain) 서버에 대한 정보를 제공합니다. 예를 들어, ".com"이나 ".org"와 같은 TLD를 처리하는 서버의 위치를 알려줍니다.
- TLD DNS 서버 쿼리: 루트 DNS 서버가 제공한 정보를 바탕으로, 로컬 DNS 리졸버는 해당 TLD 서버에 쿼리를 보냅니다. TLD 서버는 요청된 도메인에 대한 권한을 가진 **권한 DNS 서버(Authoritative DNS Server)**의 위치를 반환합니다.
- 권한 DNS 서버 쿼리: 로컬 DNS 리졸버는 최종적으로 권한 DNS 서버에 쿼리를 보냅니다. 이 서버는 도메인 이름에 대응하는 IP 주소를 가지고 있으며, 이를 리졸버에게 반환합니다.
- IP 주소 반환: 로컬 DNS 리졸버는 받은 IP 주소를 사용자에게 반환합니다. 이제 사용자의 웹 브라우저는 이 IP 주소로 접속하여, 요청한 웹사이트나 서비스에 접근할 수 있게 됩니다.
DNS 질의의 종류는?
DNS에는 크게 세 가지 종류의 질의 방식이 있어요. 각각의 방식이 조금씩 다르기 때문에, 간단하게 설명하겠습니다.
- 재귀적 질의 (Recursive Query): 클라이언트가 DNS 리졸버에게 특정 도메인에 대한 IP 주소를 요청할 때, 리졸버는 자신이 최종 답변을 얻을 때까지 다른 DNS 서버에 재귀적으로 질의합니다. 클라이언트는 최종 IP 주소 또는 오류 메시지를 받을 때까지 기다립니다. 사용자가 웹사이트에 접속할 때 보통 사용하는 방식입니다.
- 반복적 질의 (Iterative Query): 클라이언트가 DNS 서버에 질의하면, 해당 DNS 서버는 자신의 캐시에 답이 없을 경우, 다음으로 물어볼 수 있는 DNS 서버의 주소를 반환합니다. 클라이언트는 이 정보를 바탕으로 직접 다른 DNS 서버에 질의하며, 원하는 답을 얻을 때까지 이 과정을 반복합니다.
- 역방향 질의 (Reverse Query): 일반적인 질의가 도메인 이름을 IP 주소로 변환하는 것이라면, 역방향 질의는 IP 주소를 입력하여 해당 주소에 매핑된 도메인 이름을 찾는 방식입니다. 이는 주로 네트워크 디버깅이나 로그 분석 시 사용됩니다.
DNS는 UDP를 사용할까?
DNS 요청을 처리할 때는 주로 UDP라는 프로토콜을 사용하는데요, 그 이유는 속도와 효율성 때문이에요.
- 속도: UDP는 데이터를 보낼 때 미리 연결을 설정할 필요가 없어서, 빠르게 전송할 수 있어요. DNS 요청은 보통 작은 크기의 데이터라서, TCP의 복잡한 연결 설정을 거치지 않고도 충분히 빠르게 처리할 수 있습니다.
- 오버헤드 감소: TCP는 연결을 설정하고 유지하는 과정에서 오버헤드가 발생하지만, UDP는 이런 과정이 없어서 네트워크 리소스를 절약할 수 있어요.
- 낮은 오류율: DNS 요청은 실패할 확률이 적고, 만약 실패해도 간단히 다시 요청하면 되기 때문에 UDP의 간단한 전송 방식이 더 적합합니다.