HTTP 프로토콜 (HyperText Transfer Protocol)
: 웹에서 클라이언트와 서버 간의 데이터를 요청하고 응답하는 무상태성 프로토콜
- 무상태성 프로토콜 : 각 요청이 독립적으로 처리되며, 이전 요청의 상태를 저장하지 않는 통신 방식. 즉, 서버는 클라이언트가 보낸 각각의 요청을 별개의 요청으로 취급하고, 이전 요청의 정보를 기억하지 않습니다.
HTTP의 요청/응답 모델
: 클라이언트 - 서버 구조에서 웹 상의 데이터가 교환되는 방식
HTTP 요청
: 클라이언트가 서버에 특정 작업을 요청할 때 보내는 메세지
요청의 구성요소
- 요청 라인 (Request Line) : HTTP 메서드(GET, POST 등), 요청하는 리소스의 경로(URL), HTTP 버전을 포함합니다.
- 헤더 (Header) : 요청의 부가적인 정보를 담고있는 메타데이터. 콘텐츠 유형(Content-Type), 인코딩 방식, 인증 정보 등을 포함합니다.
- 본문 (Body) : 주로 POST, PUT, PATCH 요청에서 사용되며, 서버에 전달하고자 하는 데이터를 포함합니다.
HTTP 응답
: 서버가 클라이언트의 요청을 처리한 후 결과를 응답 형태로 반환
응답의 구성요소
- 상태 라인 (Status Lint) : HTTP 버전, 상태 코드 (ex. 200 ok, 404 Noe Found), 상태 메세지가 포함됩니다. 상태 코드는 요청의 성공 여부나 오류 유형을 나타냅니다.
- 헤더 (Header) : 응답의 부가적인 정보를 담은 메타데이터. 콘텐츠 유형, 서버 정보, 캐싱 정책 등의 정보가 포함됩니다.
- 본문 (Body) : 클라이언트가 요청한 리소스의 실제 데이터를 담고있습니다. HTML 문서, 이미지 파일, JSON 데이터 등이 포함됩니다.
요청과 응답의 순환 과정
- 클라이언트가 서버에 요청을 보냅니다. (Request)
- 서버가 요청을 처리하여 응답을 돌려줍니다. (Response)
HTTP 메서드 - GET vs POST
GET 메서드
: 서버에서 데이터를 조회(요청)할 때 사용됩니다.
- URL의 쿼리 스트링을 통해 데이터나 조건을 서버에 전달하는 방식
- 데이터 조회가 주 목적이므로 서버의 상태를 변경하지 않습니다.
POST 메서드
: 서버에 데이터를 추가할 때 사용합니다.
- HTTP 요청의 본문(Body)에 데이터를 포함하여 전송합니다.
- 서버의 데이터나 상태를 변경하는 작업에 사용죕니다.
HTTP 메서드 - PUT vs PATCH
PUT 메서드
: 전체 데이터를 수정할 때 사용됩니다.
- 클라이언트가 보낸 데이터로 서버 데이터 전체를 덮어쓰기 합니다. 데이터의 모든 필드를 새 데이터로 업데이트 하며, 일부 필드만 변경하더라도 전체 데이터가 다시 저장됩니다.
PATCH 메서드
: 데이터의 일부 필드를 수정할 때 사용됩니다.
- 클라이언트가 보낸 데이터로 서버 데이터의 특정 부분만 업데이트 합니다. 전체 데이터를 덮어쓰지 않고 필요한 필드만 선택적으로 변경합니다.
HTTP 상태 코드
: 클라이언트가 보낸 요청에 대한 서버의 응답 결과를 숫자로 나타낸 코드.
상태 코드는 3자리 숫자로 이루어져 있으며, 첫 자리에 따라 5종류로 나뉩니다.
1xx (정보 응답)
: 요청이 처리 중임을 나타내는 정보 상태입니다.
- 클라이언트가 요청을 계속해도 되는지를 알려주는 용도로 사용됩니다.
ex. - 100 Continue (요청을 계속해도 됨)
2xx (성공)
: 요청이 성공적으로 처리되었음을 나타냅니다.
ex.
- 200 OK : 요청이 성공적으로 완료되어 데이터를 반환함.
- 201 Created : 요청이 성공적으로 완료되었으며, 새로운 리소스가 생성됨.
- 204 Not Content : 요청이 성공적으로 처리되었지만, 응답 본문이 없음.
리소스 : 서버에 저장된 특정 데이터
3xx (리다이렉션)
: 요청된 리소스가 다른 위치로 이동했거나, 추가 작업(리다이렉트 등)이 필요함을 나타냅니다.
ex.
- 301 Moved Permanently : 요청한 리소스가 영구적으로 다른 URL로 이동됨.
- 302 Found : 요청한 리소스가 임시적으로 다른 URL에 있음.
- 304 Not Modified : 클라이언트가 캐시된 데이터를 사용해도 됨.
4xx (클라이언트 오류)
: 클라이언트 측에서 잘못된 요청을 보냈음을 나타냅니다.
ex.
- 400 Bad Request : 요청 구문이 잘못되었거나 잘못된 형식으로 요청함.
- 401 Unauthorized : 인증이 필요한 요청이나, 유효한 인증 정보가 없음.
- 403 Forbidden : 요청이 서버에 의해 거부됨.(권한 없음)
- 404 Not Found : 요청한 리소스를 찾을 수 없음.
5xx (서버 오류)
: 서버에서 요청을 처리하는 중에 오류가 발생했음을 나타냅니다.
ex.
- 500 Internal Server Error : 서버 내부에서 오류가 발생함.
- 502 Bad Gateway : 서버가 잘못된 게이트웨이로부터 응답을 받음
- 503 Service Unavailable : 서버가 일시적으로 과부하 상태이거나 유지 보수 중이라서 요청을 처리할 수 없음.
HTTP 헤더
: 클라이언트와 서버가 요청 및 응답을 주고받을 때 전송되는 부가 정보를 담고 있는 필드
HTTP 헤더를 통해 데이터 형식을 지정할 수 있고, 보안을 설정할 수 있으며, 캐싱 및 속도 개선, 리소스 위치 지정을 할 수 있습니다.
일반 헤더
: 요청과 응답 모두에 공통으로 사용될 수 있는 정보가 담깁니다.
요청 헤더
: 클라이언트가 서버에 요청을 보낼 때 추가하는 정보. 서버가 요청을 이해하고 처리할 수 있도록 도움을 줍니다.
응답 헤더
: 서버가 클라이언트에 응답을 보낼 때 추가하는 정보. 응답에 대한 부가적인 내용을 설명합니다.
엔티티 헤더
: 메시지 본문에 포함된 리소스에 대한 정보(파일 크기, 데이터 형식 등)을 나타냅니다.
HTTP 무상태성
: 서버가 클라이언트의 상태를 저장하지 않는 것. 즉, 각각의 요청이 독립적으로 처리되며, 이전 요청의 정보를 기억하지 않는다는 의미
HTTP Keep-Allive
: 클라이언트와 서버 간의 연결을 지속적으로 유지하여, 하나의 TCP 연결 내에서 여러 요청과 응답을 처리할 수 있게 해주는 기능
HTTP 파이프라이닝
: 클라이언트가 응답을 기다리지 않고 여러 개의 요청을 보내는 방식.
- HTTP 요청의 전송 효율을 높이고 지연 시간을 줄여줍니다.
HTTP/1.1, HTTP/2, HTTP/3
HTTP/1.1
: HTTP 프로토콜의 표준화된 첫 번째 버전
- Persistent Connections (Keep-Alive) : 연결이 지속적으로 유지되며, 여러 요청을 하나의 연결에서 처리할 수 있어 성능이 개선되었습니다.
- 파이프라이닝 (Pipelining) : 클라이언트가 응답을 기다리지 않고 여러 요청을 연속으로 전송할 수 있습니다. 하지만 서버가 순차적으로 응답을 처리해야하기 때문에 HOL Blocking 문제가 발생할 수 있습니다.
HOL Blocking (Head Of Blocking)
: 연속된 요청 간에 헤더의 많은 중복이 생긴다는 문제.
앞의 요청에 대한 응답이 늦어지면 뒤의 모든 요청들은 모두 blocking되어 응답이 지연됩니다.
HTTP/2
: 성능 최적화와 속도 개선을 목표로 HTTP/1.1의 단점을 보완한 버전
- 멀티플렉싱(Multiplexing) : 단일 연결에서 여러 요청과 응답을 동시에 처리할 수 있게 되어 HOL Blocking 문제를 개선했습니다. 각 요청이 독립적으로 처리되므로 응답 지연이 줄어듭니다.
- 헤더 압축 : HTTP 헤더 정보를 HPACK 방식으로 압축전송하여 전송 효율성을 높였습니다.
- 서버 푸시 : 서버가 클라이언트의 요청 없이도 필요한 리소스를 미리 전송할 수 있어, 리소스 요청을 줄려 페이지 로딩 시간을 개선합니다.
- 이진 프레이밍 (Binary Framing) : 데이터가 텍스트가 아닌 이진 형식으로 전송되어 데이터 처리가 더욱 효율적입니다.
HTTP/3
: TCP 위에서 돌아가는 HTTP/2와는 달리, UDP 가빈의 QUIC 프로토콜을 사용하는 HTTP 버전
- QUIC 프로토콜 : TCP 대신 UDP 기반의 QUIC 프로토콜을 사용하여, 연결 설정 시간이 짧고 네트워크 혼잡에 강합니다. TCP 연결에 비해 더욱 데이터를 빠르게 주고받을 수 있습니다.
- 연결 복구 및 이동성 : QUIC는 연결이 끊겨도 세션을 복구할 수 있어 모바일 환경에서 네트워크 변경 (WI-FI -> 데이터 로 변환) 시에도 연결이 유지됩니다
- HOL Blocking 해결 : TCP의 stream은 하나의 chain으로 연결되는 것과 달리, 각 stream당 독립된 stream chain을 구성하여 TCP의 HOL Blocking을 해결했습니다.
- HTTP/1.1: Keep-Alive와 파이프라이닝을 통해 여러 요청을 하나의 연결에서 처리하지만, 헤드-오브-라인 블로킹 문제가 존재.
- HTTP/2: 멀티플렉싱, 헤더 압축, 서버 푸시로 성능을 개선하였으며, 텍스트가 아닌 이진 형식을 사용.
- HTTP/3: UDP 기반의 QUIC을 사용하여 연결 복구가 빠르고, 불안정한 네트워크에서도 성능이 향상됨.
HTTPS
: HTTP에 보안 기능(SSL/TLS 암호화)을 추가한 프로토콜. 데이터의 기밀성, 무결성, 인증성을 보장하여 안전하게 통신할 수 있도록 합니다.
SSL/TLS
: 인터넷 상에서 데이터를 안전하게 전송하기 위해 개발된 암호화 프로토콜. SSL/TLS는 데이터 기밀성, 인증, 무결성 보호 기능을 제공하며 핸드셰이크 과정을 통해 안전한 암호화 연결을 설정합니다.
- SSL은 초기 버전, TLS는 SSL을 개선한 최신 버전입니다.
대칭키 암호화 방식이란
: 데이터를 암호화하고 복호화할 때, 하나의 동일한 대칭키(비밀 키)를 사용하는 암호화 방식입니다.
- 빠른 암호화/복호화 속도 및 간단한 구조를 가지고 있지만 키를 안전하게 공유 및 관리 하는 것이 번거롭습니다.
비대칭키(공개 키) 암호화 방식이란
: 데이터를 암호화하고 복호화할 때 서로 다른 두 개의 키(공개 키, 비밀 키)를 사용하는 암호화 방식입니다.
- 공개 키는 자유롭게 공개된 키, 비밀 비는 개인만 가지고 있는 키
- 키 관리엔 용이하나 속도가 느리다는 단점 존재
전자 서명
: 비대칭키 암호화를 사용하여 디지털 환경에서 데이터의 작성자 신원과 무결성을 보장하기 위해 생성된 디지털 서명.
- 문서가 인증된 작성자로부터 왔으며, 전송 과정에서 내용이 변조되지 않았음을 보장
HTTPS 암호화 과정
: HTTPS는 HTTP와 SSL/TLS 프로토콜이 결합된 것이기 때문에, 데이터를 주고받기 전에 SSL Handshake를 통해 안전한 연결을 설정합니다.
SSL Handshake : 클라이언트와 서버 간에 안전한 연결을 설정하기 위해 수행되는 초기 협상 과정
1. SLL Handshake 시작 : 클라이언트 Hello
- HTTPS 통신을 시작하기 위해 클라이언트가 서버에 ClientHello 메시지를 전송합니다.
- 메시지에는 클라이언트가 지원하는 SSL/TLS 버전, 사용할 수 있는 암호화 알고리즘 목록, 클라이언트에서 생성한 랜덤 데이터가 포함됩니다.
2. 서버 Hello
- 서버는 ServerHello 메시지를 통해 클라이언트 요청에 응답합니다.
- 서버는 클라이언트의 옵션 중에서 가장 높은 SSL/TLS 버전과 암호화 알고리즘을 선택하고, 서버에서 생성한 랜덤 데이터를 함께 전송합니다.
3. 서버 인증서 전송
- 서버는 자신의 신원을 확인하기 위해 디지털 인증서를 클라이언트에 전송합니다. 서버의 공개키, 신뢰할 수 있는 인증 기관(CA)의 서명이 포함되어 있습니다.
- 클라이언트는 이 인증서를 확인하여 신뢰할 수 있는 서버인지, 유효한 인증서인지 검증합니다.
4. Pre-Master Secret 생성 및 공유
- 클라이언트는 서버의 공개 키를 사용하여 Pre-Master Secret 이라는 임시 암호화 데이터를 생성하고 이를 서버에 전송합니다.
- 서버는 자신의 비밀 키를 사용하여 이 Pre-Master Secret를 복호화하고 동일한 값을 얻습니다.
5. 세션 키 생성
- 클라이언트와 서버는 서로 공유한 두 개의 랜덤 데이터와 Pre-Master Secret을 사용하여 세션 키를 생성합니다.
- 세션 키는 암호화된 통신에서 데이터를 보호하는 데 사용됩니다.
6. Change Cipher Spec 및 Finished 메시지 교환
- 클라이언트와 서버는 ChangeCipherSpec 메시지를 통해 암호화 설정을 변경했음을 알리고, Finished 메시지를 전송하여 SSL Handshake가 무사히 완료되었음을 확인합니다.
7. SSL Handshake 완료 및 HTTPS 암호화 통신 시작
- SSL Hansshake가 완료되면, 클라이언트와 서버는 서로 암호화된 데이터 통신을 시작합니다.
- 세션 키를 사용하여 대칭키 암호화 방식으로 데이터를 주고 받으며, 모든 HTTP 요청과 응답은 암호화됩니다.
8. 암호화된 데이터 전송
- HTTPS 통신에서는 모든 HTTP 요청과 응답을 세션 키로 암호화하여 전송합니다.
9. 연결 종료 및 세션 키 삭제
- 클라이언트와 서버 간의 통신이 끝나면, 세션 키는 삭제됩니다.
- 다음에 다시 연결할 때는 새로운 SSL Handshake가 수행되고 새로운 세션 키가 생성됩니다.
DNS (Domain Name System)
: 도메인 이름을 IP 주소로 변환해주는 시스템
- 사용자가 이해하기 쉬운 주소인 도메인 이름(google.com)을 해당 도메인에 해당하는 IP 주소로 찾아 사용자에게 제공해줍니다
DNS의 작동 방식
- 사용자가 도메인 이름을 입력
- Local DNS 서버에게 도메인에 해당하는 IP 주소를 요청
- Root DNS 서버에게 도메인에 해당하는 IP 주소를 요청
- TLD 네임 서버에게 도메인에 해당하는 IP 주소를 요청
- Authoritative DNS 서버에게 도메인에 해당하는 IP 주소를 요청
- IP 주소 반환 및 캐싱
- 해당 도메인 접속 완료
Local DNS 서버 (기지국 DNS 서버) : 기지국 DNS 서버. 인터넷을 사용하기 위해선 IP를 할당해주는 통신사(KT, SKT, LG...)에 등록하게 되는데, 컴퓨터의 LAN선을 통해 인터넷이 연결되면, 가입했던 각 통신사의 기지국 DNS 서버가 등록되게 된다. (KT를 사용하면 KT DNS...)
Root DNS 서버 (루트 네임 서버) : 인터넷의 도메인 네임 시스템의 루트 존. ICANN이 직접 관리하는 절대 존엄 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할
TLD(Top-Level Domain, 최상위 도메인) DNS 서버 : 도메인 등록 기관이 관리하는 서버. 도메인 네임의 가장 마지막 부분을 말한다. Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 한다.
Authoritative DNS 서버 : 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버 (ex. google.com DNS 서버에는 'www.google.com'의 IP 주소가 있다
DNS 질의
재귀 질의
- 클라이언트가 Local DNS 서버에게 특정 도메인의 IP 주소를 요청할 때 사용하는 방식
- 클라이언트가 example.com의 IP 주소를 요청하면, 로컬 DNS 서버가 루트 서버, TLD 서버, 권한이 있는 서버를 거쳐 최종적으로 IP 주소를 찾아 클라이언트에 반환합니다.
반복 질의
- 클라이언트가 요청을 보내면 DNS 서버가 최종 IP 주소를 찾지 않고, 단계별로 다음 DNS 서버의 주소를 알려주는 방식
- 클라이언트가 로컬 DNS 서버에 질의하면, 로컬 서버는 루트 서버의 주소를 알려주고, 클라이언트는 다시 루트 서버에 요청을 보냅니다. 루트 서버는 TLD 서버 주소를 알려주고, 클라이언트가 그 TLD 서버로 질의하는 식으로 반복됩니다.
순방향 질의
- 도메인 이름을 IP 주소로 변환하는 질의 방식
- 사용자가 example.com과 같은 도메인 이름을 입력하면, DNS 서버는 해당 도메인의 IP 주소를 찾아 반환합니다.
역방향 질의
- IP 주소를 도메인 이름으로 변환하는 질의 방식
- 특정 IP 주소에 대해 해당하는 도메인 이름을 요청합니다.
DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?
: 빠른 속도, DNS의 간단한 요청-응답 구조, 낮은 오버헤드 때문입니다.
- 속도 : UDP는 TCP와 달리 연결을 설정하거나 해제하는 과정(3-way Handshake)이 없기 때문에 TCP보다 요청-응답 속도가 빠릅니다.
- DNS의 간단한 요청-응답 구조 : DNS는 단순한 요청과 응답을 주고 받기 때문에, 패킷 손실 시 재전송하거나 다시 질의하는 방식으로 대응할 수 있습니다
- 낮은 오버헤드 : TCP는 3-way Handshake 등 연결 설정에 오버헤드가 발생하지만, UDP는 이러한 과정이 없어 효율적입니다.
DNS 레코드
: 도메인 이름과 관련된 다양한 정보를 저장하는 데이터 파일
- 도메인이 어느 IP 주소로 연결되는지, 이메일 서버가 어디에 있는지 등 도메인에 대한 중요한 설정을 정의합니다.
참고문헌
https://zu-techlog.tistory.com/113
https://kanoos-stu.tistory.com/46
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90
