로드 밸런싱(Load Balancing)

로드 밸런싱은 네트워크 트래픽을 여러 서버에 분산시키는 역할을 하는 장치 또는 소프트웨어다.

서버의 부하를 줄이고, 가용성을 높이며, 응답 시간을 개선하는데 도움을 준다.

로드 밸런서의 종류

1. L4 Load Balancer

L4 로드 밸런서는 네트워크 계층에서 작동하며, IP 주소와 포트 정보를 기반으로 트래픽을 분산시켜준다. 그래서 단순하고 빠른 처리가 가능하지만, 패킷의 안쪽 내용까진 볼 수 없기 때문에 트래픽의 내용에 대한 깊은 작업은 제한적이다. 

2. L7 Load Balancer

L7 로드 밸런서는 응용 프로그램 계층에서 작동하며, 패킷의 안쪽 내용까지 보고 로드밸런싱 할 수 있기 때문에 HTTP 헤더, 쿠키, 세션 정보 등을 기반으로 트래픽을 분산시킨다. 그래서 더 복잡하고 세밀한 로드밸런싱 정책을 구현할 수 있지만, 처리에 더 많은 리소스가 필요하다. 즉, L4는 빠르고 자원효율적이지만 L7에 비해서 세심한 작업은 불가능하다.

로드 밸런서 알고리즘

L4와 L7 로드 밸런서는 트래픽을 분산시키는 방법을 결정할 때 알고리즘을 사용한다.

L4 Load Balancer 알고리즘:

1. Round Robin: 각 서버에 순차적으로 연결을 분산시키는 방법이다. 모든 서버가 동일한 처리 능력을 가지고 있을 때 유용하다.
2. Least Connections: 현재 가장 적은 연결을 가진 서버에 새 연결을 할당하는 방법이다. 서버마다 처리 능력이 다를 때 쓰기 좋다.
3. IP Hash: 클라이언트의 IP 주소를 해싱하여 특정 서버에 연결을 할당하는 방법이다. 이 방법은 세션 지속성을 필요로 하는 경우에 좋다.

L7 Load Balancer 알고리즘:

1. URL Hash: 클라이언트의 요청 URL을 해싱하여 특정 서버에 연결을 할당하는 방법이다. 이 방법은 URL 기반의 세션 지속성을 필요로 할 때 효율적이다.
2. HTTP Header: HTTP 헤더의 특정 값(예: 사용자 에이전트, 쿠키 등)을 기반으로 특정 서버에 연결을 할당하는 방법이다.
3. Least Time: 가장 빠른 응답 시간을 가진 서버에 새 연결을 할당하는 방법이다. 이 방법은 서버의 성능과 네트워크 지연 시간을 모두 고려할 때 사용하기 좋다.

더 깊게 알아보고 싶다면, AWS의 로드 밸런싱에 대한 페이지에서 더 자세하고 많은 정보를 알 수 있다.

서브넷 마스크?

서브넷 마스크는 32비트의 숫자로 구성된다. 이 숫자들은 '0'과 '1'로 이루어져 있다.

여기서 '0'의 비트는 호스트 부분을 나타내고, '1'의 비트는 네트워크 부분을 나타내는데, 이를 통해서 서브넷 마스크는 IP 주소를 네트워크 주소와 호스트 주소로 분리시켜준다.

이렇게 IP 주소를 '마스킹'하는 것이기 때문에 '서브넷 마스크' 라고 부른다.

그래서 서브넷이 뭔데?

전 세계에는 수백만 개의 네트워크가 존재하며, 그 규모는 너무나 다양하다.

큰 규모의 네트워크는 관리하기 어렵기 때문에, 이를 작은 조각으로 나누어 관리하는 것이 효율적이다.
그렇게 나뉜 작은 네트워크를 '서브넷' 이라고 한다. 그리고 이러한 과정을 '서브네팅' 이라고 하며, 이를 통해 네트워크 성능을 개선하고 자원을 효율적으로 분배할 수 있다.

서브네팅은 관리의 용이성, 고급 네트워크 보안, 네트워크 트래픽 감소 등 여러 장점을 가지고 있다. 또한, 서브네팅을 통해 인터넷 서비스 업체로부터 추가적인 IP 주소를 받을 필요가 없다. 하지만, 서브네팅을 위해 추가적인 하드웨어가 필요한 경우가 있어, 이로 인한 비용이 발생할 수 있다는 단점도 있다.

서브넷 마스크의 작동 원리

IP 주소는 네트워크 구성요소와 호스트 구성요소로 이뤄져있다. 예를 들어, '192.168.123.132'라는 IP 주소에서 '192.168.123.'는 네트워크를 나타내고, '132'는 네트워크에 연결된 기기를 가리킨다.

IP 주소는 32비트로 구성되고, 이를 십진수 체계로 표현하면 다음과 같다

: '192.168.123.132' = '11000000.10101000.01111011.10000100'.

이 IP 주소의 서브넷 마스크는 네트워크 부분을 반영하며, 다음과 같이 나타낼 수 있다

: '255.255.255.0' = '11111111.11111111.11111111.00000000'.

이 둘을 합치면 다음과 같은 결과를 볼 수 있다

'11000000.10101000.01111011.00000000' (네트워크 주소: '192.168.123.0')
'00000000.00000000.00000000.10000100' (호스트 주소: '000.000.000.132')

여기서 '192.168.123.0'이 서브넷이며, '192.168.123.132'는 대상 주소(서브넷 내 기기)다.

IP 주소 클래스

IP 주소 클래스는 A, B, C로 나뉩니다. 각 클래스마다 기본 서브넷 마스크가 다르며, IP 주소의 첫 세 자리를 확인하여 클래스를 확인할 수 있다.

• 클래스 A: 255.0.0.0의 서브넷 마스크를 이용하며 첫 옥텟(8비트로 구성된 부분)은 0~127로 구성되어 있습니다. 126개의 네트워크를 허용하며 네트워크당 호스트가 거의 1,700만 개에 달한다.
• 클래스 B: 255.255.0.0의 서브넷 마스크를 이용하며 첫 옥텟은 128~191로 구성된다. 클래스 B IP 주소는 중간 규모와 대규모 네트워크에서 이용한다. 클래스 B는 약 1600개의 네트워크를 허용하며 네트워크당 65,000개의 호스트를 허용한다.
• 클래스 C: LAN(Local Area Network)에 이용되며 200만 개의 네트워크를 허용하고 각각 254개의 호스트를 두고 있다. 클래스 C는 255.255.255.0의 서브넷 마스크를 이용하고 첫 옥텟은 192~223으로 구성되어 있다.

서브넷 마스크를 찾는 방법

 서브넷 마스크를 찾는 방법은 운영 체제에 따라 다르다.
 아래는 MacOS, Windows, iOS, Android 운영체제에서 서브넷 마스크를 찾는 방법이다.

• MacOS: 시스템 환경설정 > 네트워크로 이동하세요. 네트워크를 선택하시고 고급을 클릭하세요. TCP/IP 탭을 클릭하시면 서브넷 마스크와 함께 IP 주소를 확인할 수 있습니다.
• Windows: 제어판 > 네트워크 및 인터넷으로 이동하세요. 네트워크 이름을 선택한 후 세부사항을 클릭합니다. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.
• iOS: 설정 > Wi-Fi로 이동하세요. 현재 연결된 네트워크를 확인하시고 ‘i’ 아이콘을 클릭하세요. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.
• Android: 설정 > 연결 > Wi-Fi로 이동하세요. 현재 연결된 네트워크를 탭하세요. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.

프록시

프록시 서버는 원 서버를 대리해서 클라이언트와 통신해 중계 역할을 하는 서버를 말한다.

프록시 서버가 클라이언트와 서버 중간에 있기 때문에 클라이언트는 프록시 서버를 '서버'라고 인식하고, 서버 입장에서는 '클라이언트'로 인식한다.

프록시의 종류

• 리버스 프록시(reverse proxy) :  클라 - 서버 구조에서 서버를 대리해서, 클라이언트 <== 서버 방향의 요청을 중계한다.
• 포워드 프록시(forward proxy) : 클라 - 서버 구조에서 클라이언트를 대리해서, 클라이언트 ==> 서버 방향의 요청을 중계한다.

프록시의 장점

1. 로드 밸런싱: 프록시 서버는 여러 백엔드 서버 간의 트래픽을 분산시키는 로드 밸런싱 역할을 할 수 있다. 그래서 더욱 안정적인 서비스를 제공하는데 도움이 된다.
2. 캐싱: 프록시 서버는 자주 사용되는 웹 콘텐츠를 캐시하여 응답 시간을 엄청나게 단축시킬 수 있다. 그래서 원 서버의 리소스를 덜 잡아먹을 수 있고, 네트워크 사용량을 절약해 결국 서비스 제공자 입장에서 서비스 유지 비용을 아낄 수 있다.
3. 보안: 프록시 서버는 웹 애플리케이션 방화벽(WAF) 역할을 하여 원 서버를 외부 공격으로부터 보호할 수 있다. 그리고 사용자의 IP 주소를 숨기거나 SSL/TLS 암호화를 구현해 클라이언트와 서버 간의 통신 보안을 강화할 수 있다. Ddos와 같은 트래픽 부하 공격에게서도 원 서버를 보호해줄 수 있다.
4. 압축: 프록시 서버는 웹 콘텐츠를 압축하여 클라이언트에게 전송할 수 있다. 그래서 데이터 전송 시간이 단축되고, 대역폭 사용량이 감소한다.
5. 지역 제한 우회: 프록시 서버를 사용하면 특정 지역에서만 접근 가능한 웹 콘텐츠에 대한 접근을 우회할 수 있다. 사용자는 프록시 서버를 통해 해당 지역에서 차단된 웹사이트에 접속할 수 있다.(ㅎㅎㅎㅎ...)
6. 성능 모니터링 및 로깅: 프록시 서버를 사용하면 웹 트래픽에 대한 로그를 수집하고, 성능 모니터링을 통해 시스템의 개선점을 찾을 수 있다.

로드 밸런서(Load Balancer)

규모가 큰 서비스의 경우에는 서버 한 대로 모든 서비스를 수용하는 것이 불가능하다. 또한 서버 1대로 서비스를 제공하는 것에 문제가 없다고 하더라고 서비스의 시스템을 단일 서버에 구축하면 해당 서버에 문제가 발생했을 때, 서비스를 제공하는데 제한이 될 수 있다.

그래서 서비스 가용성(availability)를 높이기 위해서 1개 서비스는 보통 여러대의 서버로 구성한다. 여기서 각 서버는 ip주소가 달라서 같은 서비스를 이용하더라도 다른 ip로 접속하는 경우가 생길 수 밖에 없는데, 여기서 1개의 서버가 문제가 생겼다면 해당 서버를 통해 서비스를 이용하던 사용자들에게 서비스 장애가 생길 수 있다. 이문제를 로드 밸런서를 사용해 해결할 수 있다.

로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청을 분산시켜 부하를 분산시킨다.

프록시 캐시

 프록시 캐시는 프록시 서버에서 원 서버가 제공하는 서비스 내용 중 일부를 저장해둬서 사용자가 해당 서비스 내용을 요청하면, 프록시 서버에서 바로 해당 서비스를 제공할 수 있도록 하는 저장공간을 말한다.

 즉, 프록시 서버가 작동하는 과정에서 프록시 서버 - 원 서버 사이의 통신시간을 절약해 훨씬 빠른 서비스 반응속도를 보여줄 수 있다.

이 프록시 캐시와 관련된 캐시 헤더는

• Cache-Control: public 
  • 응답이 public 캐시에 저장될 수 있다.
• Cache-Control: private
  • 응답이 private 캐시에 저장되어야한다.(특정 사용자만 사용할 수 있어야한다.)
• Cache-Control: s-maxage
  • 프록시 캐시 전용 max-age
• Age: 60 (HTTP 헤더)
  
  • 원 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

이고, 캐시를 무효화할 수 있는 헤더는

• Cache-Control: no-cache 
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용한다.
• Cache-Control: no-store 
  • 데이터에 민감한 정보가 있으므로 저장하면 안된다.
• Cache-Control: must-revalldate 
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야한다.
  • 원 서버 접근 실패 시 반드시 오류가 발생해야한다. 504오류(Gateway Timeout)
  • must-revalldate는 캐시 유효 시간이라면 캐시를 사용한다.
• Pragma:no-cache
  • HTTP 1.0 하위 호환

참고 : https://simplicable.com/IT/proxy-server

HTTP?

HTTP(HyperText Transfer Protocol)는 웹 상에서 문서, 이미지, 동영상 등의 데이터를 주고받는 데 사용되는 프로토콜이다. 클라이언트(웹 브라우저)와 서버 간에 요청(request)과 응답(response) 방식으로 통신을 한다.

HTTP가 어떻게 작동하는지 실제로 통신을 하면서 알아보고 싶다면 postman과 같은 소프트웨어를 사용하는 것도 좋다.

https://www.postman.com/

HTTP의 버전으로는 크게 HTTP/1.0, HTTP/1.1, HTTP/2, HTTP/3 가 있다. 이번 글에서는 이 버전들의 차이점에 대한 내용을 작성했다.

HTTP/1.0, HTTP/1.1

 HTTP/1.0은 HTTP의 초기 버전으로, 간단한 요청-응답 모델을 사용해 만들어졌다. 이 버전에서는 각 요청에 대해 별도의 TCP 연결을 생성하고 사용한 후 종료하는 방식을 사용했다. 

그래서 많은 연결이 생성되고 종료되는 오버헤드가 발생해 시스템의 자원을 낭비하는 문제가 있었다.

HTTP/1.1은 지속적인 연결(persistent connection)을 도입하여 연결 생성 및 종료에 대한 오버헤드를 줄였다. 또한, 파이프라이닝 기능을 통해 여러 요청을 동시에 처리할 수 있게 되어 시스템 자원 낭비를 훨씬 줄였다.

HTTP/2

HTTP/2는 다중화(multiplexing) 기능을 도입하여 여러 요청과 응답을 동시에 하나의 연결에서 처리할 수 있다.

 그래서 페이지 로드시간이 더욱 단축되었고, 헤더 압축 기능을 도입하여 데이터 전송량을 줄여 성능을 향상시켰다. HTTP/2는 이전 버전에 비해 보안성도 향상되었으며, 주로 HTTP에서 암호화를 통해 보안성을 강화한 HTTPS와 함께 사용된다.

HTTP/3

HTTP/3는 HTTP/2의 성능 향상을 이어받아, 더욱 향상된 통신 효율성과 속도를 가진다.

 HTTP/3의 가장 큰 특징은 기존의 TCP 대신 QUIC(Quick UDP Internet Connections) 프로토콜을 사용한다는 점이다. QUIC는 기존 TCP보다 더 낮은 지연 시간을 가지며, 패킷 손실 시에도 연결의 성능 저하가 덜하다는 장점이 있다.

 물론 암호화와 보안 기능을 기본적으로 제공하고, 이전 버전의 HTTP/2보다 강화된 보안성을 가진. 대부분의 최신 웹 브라우저와 웹 서버는 이미 HTTP/3를 지원하고 있습니다.

결론적으로, HTTP/3는 웹 통신의 더욱 향상된 성능과 보안성을 제공하며, 성능면에서도 우수하다. 그래서 최신 브라우저들은 대부분 HTTP/3을 지원한다. 

참고 : https://www.cloudflare.com/ko-kr/learning/ddos/glossary/hypertext-transfer-protocol-http/

https://ko.wikipedia.org/wiki/HTTP/3

소켓

 소켓은 네트워크에서 두 대의 디바이스 간의 데이터 송수신을 위한 통신 엔드포인트(도착점, 시작점)이라고 할 수 있다.

 즉, 소켓은 클라이언트-서버 모델에서 클라이언트와 서버 사이에 데이터를 전송할 수 있는 통신 경로를 제공해주는 일종의 톨게이트같은 역할을 한다.

 보통 인터넷 프로토콜(IP), 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP)을 사용하여 소켓 통신을 사용한다.

 한가지 예시를 들어보자.

 이메일을 전송할 때, 송신자의 컴퓨터와 수신자의 메일 서버 사이에는 소켓이 만들어져 이메일 데이터가 전달된다. 소켓을 통해 두 기기는 안전하고 효율적으로 통신을 할 수 있다.

포트

포트는 네트워크에서 특정 소프트웨어에 데이터를 전달하기 위한 통신 채널을 식별하는 번호다. 포트 번호는 0부터 65535까지의 범위를 가지며, 일반적으로 잘 알려진 포트 번호와 동적 포트 번호로 나뉜다.

예를 들어, HTTP 통신은 기본적으로 80번 포트를 사용하며, HTTPS 통신은 443번 포트를 사용한다.

 즉, ip주소가 우리나라의 도로명 주소라면, 포트번호는 아파트의 동 호수라고 볼 수 있다.

소켓과 포트, 둘의 차이점

 소켓은 데이터 통신을 위한 통신 엔드포인트로, 컴퓨터와 서버 간의 연결을 가능하게 하는 기능을 한다.

 그러나 포트는 특정 프로세스나 서비스에 데이터를 전달하기 위한 통신 채널을 식별하는 번호다.

 소켓은 통신 경로를 제공하고 관리하는 역할을 하며, 포트는 통신 과정에서 데이터가 어떤 프로세스나 서비스에 도달해야 하는지를 구분한다.

 즉, 소켓이 아파트 입구의 도로라고 한다면, 포트는 아파트의 동호수라고 할 수 있다.

참고 : https://www.geeksforgeeks.org/difference-between-socket-and-port/

https://www.ibm.com/docs/ko/ssw_ibm_i_73/rzab6/rzab6soxoverview.htm

 HTTP 기반의 서버를 생성하는 소프트웨어인 nginx를 사용해, 웹 서버(Web Server)를 생성하여 정적 웹페이지 호스팅할 수 있다.

nginx 설치

먼저 nginx를 사용하기 위해서 apt get 명령어를 사용해 nginx를 설치해준다.

sudo apt-get update

sudo apt-get install nginx

설치를 완료했다면

sudo nginx -v

명령어로 설치된 nginx의 버전을 확인할 수 있다.

nginx 로 정적 콘텐츠 호스팅하기

nginx의 환경 설정파일 nginx.conf

일반적으로 환경 설정 파일은 관리자가 편집하거나 프로그램을 분석할 수 있는 텍스트 파일을 말한다.

nginx도 nginx.conf라는 텍스트 파일에 여러 가지 값을 지정해 프로그램의 작동 방법을 결정 할 수 있다.

nginx.conf 파일의 내용은 아래와 같다.

user www-data; #웹 서버가 실행되는 사용자를 설정한다. 기본값은 'www-data'.
worker_processes auto; #동시에 처리할 워커 프로세스의 개수를 설정한다. 'auto'는 시스템의 CPU 코어 수에 따라 자동으로 할당.
pid /run/nginx.pid; #nginx 프로세스 ID 파일의 위치를 설정한다.
include /etc/nginx/modules-enabled/*.conf; #활성화된 모듈의 설정 파일을 불러온다.

# 이벤트 처리에 대한 설정 블록이다.
# 워커 프로세스당 연결 수를 정의하는 worker_connections와 같은 설정이 포함된다.
events { 
    worker_connections 768;
    # multi_accept on;
}

# HTTP 서버에 대한 전체 설정 블록이다.
# 기본 설정, SSL 설정, 로깅 설정, Gzip 설정 등이 포함된다.
http {
    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types; #지원되는 MIME 타입을 포함하는 파일의 위치를 지정한다.
    default_type application/octet-stream; #MIME 타입이 지정되지 않은 경우 기본값으로 사용되는 타입이다.

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #사용할 SSL 프로토콜을 설정한다. SSLv3는 POODLE 취약점 때문에 사용하지 않는다.Dropping SSLv3, ref: POODLE 
    ssl_prefer_server_ciphers on; #SSL/TLS 연결 시 서버 측이 지정한 암호 스위트를 클라이언트 측보다 우선시하는지 여부를 설정한다.

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log; #접근 로그 파일의 위치를 지정한다.
    error_log /var/log/nginx/error.log; #에러 로그 파일의 위치를 지정해준다.

    ##
    # Gzip Settings
    ##

    gzip on; #Gzip 압축 기능을 활성화한다.

    # gzip_vary on; # Gzip 압축 여부에 따라 Vary 헤더를 설정하는 옵션. 기본값은 'off'.
    # gzip_proxied any; # 프록시된 요청에 대해 Gzip 압축을 적용할 조건을 설정합니다. 'any'는 모든 프록시 요청에 압축을 적용합니다.
    # gzip_comp_level 6; #  Gzip 압축 수준을 설정. 1(최소)부터 9(최대)까지 설정할 수 있으며, 기본값은 1.
    # gzip_buffers 16 8k; #  Gzip 압축에 사용되는 버퍼의 개수와 크기를 설정.
    # gzip_http_version 1.1; # Gzip 압축을 적용할 HTTP 버전을 설정. 기본값은 1.0.
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    #Gzip 압축을 적용할 MIME 타입을 설정한다. 기본적으로 텍스트와 애플리케이션 타입에 대해 압축이 적용된다.
    
    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf; #추가 설정 파일들을 포함하는 디렉토리다.
    include /etc/nginx/sites-enabled/*; #활성화된 사이트 설정 파일들을 포함하는 디렉토리다. /etc/nginx/sites-available/에 있는 설정 파일들을 여기에 심볼릭 링크로 연결하여 사용한다.
}

설정파일 작성

웹 서비스를 호스팅하기 위해서는 위의 nginx.conf 파일에다 제공할 웹서버의 정보를 담는 server 블록과 제공할 웹페이지의 소스 위치를 담는 location블록을 생성해줘야한다.

server {
	listen 80; #읽어올 포트 
	server_name your_domain.com www.your_domain.com;#서버 도메인 이름

	location / {
	    root /var/www/mywebsite; #제공할 웹페이지의 위치
		index index.html; #인덱스 파일 이름
	}
 }
 ```

위는 server블록과 location블록 작성의 예시이다.

변경사항 적용 및 웹 서버 생성

설정 파일 링크를 생성한다

$ sudo ln -s /etc/nginx/sites-available/mywebsite /etc/nginx/sites-enabled/

nginx를 재시작한다.

$ sudo systemctl restart nginx

여기까지 문제없이 실행했다면 nginx.conf에서 작성했던대로 웹서버를 생성하고 정적 웹페이지를 호스팅한다.

HTTP 응답 코드는 HTTP 요청에 대한 서버의 응답을 나타내는 3자리 숫자를 말한다.

이 숫자는 해당 요청이 성공했는지, 실패했는지, 그리고 어떤 종류의 오류가 발생했는지를 나타낸다.

응답코드는 크게 5개 분류로 나뉘는데 100, 200, 300, 400, 500번대이다.

상태코드의 분류별 특징

• 100번대 (처리 중) : 이 코드는 요청이 수신되었으며 처리가 계속되고 있다는 것을 말해준다. 일반적으로 클라이언트의 추가 작업이 필요하다. 예를 들어 101 Switching Protocols는 서버와 클라이언트 간의 프로토콜을 변경했다는 뜻이다.

• 200번대 (성공): 200번대 응답 코드는 성공적으로 처리되었음을 나타낸다. 예를 들어, 200 OK는 요청이 성공적으로 처리되었다는 것을 나타내며, 201 Created는 새로운 리소스가 성공적으로 생성되었다는 것을 나타낸다.

• 300번대 (리다이렉션): 300번대 응답 코드는 리다이렉션을 말한다. 즉, 요청한 리소스가 다른 위치에 있고, 새로운 위치로 이동하도록하는 요청이다. 예를 들어, 301 Moved Permanently는 요청한 리소스가 영구적으로 새로운 URL로 이동되었다는 것을 나타내며, 302 Found는 요청한 리소스가 일시적으로 새로운 URL로 이동되었다는 것을 말한다.

• 400번대 (클라이언트 오류): 400번대 응답 코드는 클라이언트 오류를 나타낸다. 즉, 클라이언트가 요청한 것이 잘못되었거나 부적절한 경우에 볼 수 있다. 예를 들어, 400 Bad Request는 클라이언트가 유효하지 않은 요청을 보냈다는 것을 나타내며, 401 Unauthorized는 클라이언트가 인증되지 않았다는 것을 나타낸다.

• 500번대 (서버 오류): 500번대 응답 코드는 서버 오류를 말해준다. 즉, 서버에서 요청을 처리하는 동안 문제가 발생한 경우다. 예를 들어, 500 Internal Server Error는 서버에서 오류가 발생했다는 것을 나타내며, 503 Service Unavailable은 서버가 일시적으로 사용 불가능하다는 것을 말해준다.

각 응답 코드는 위처럼 분류된다.

세부 상태코드 의미

1xx - Informational (정보)

2xx - Successful (성공)

3xx - Redirection (리디렉션)

4xx - Client Error (클라이언트 오류)

5xx - Server Error (서버 오류)

 HTTP 응답 코드는 클라이언트와 서버 간의 통신에서 중요한 역할을 한다. 그래서 이러한 응답 코드의 세부 내용을 이해하고 적절히 대응하는 것이 중요하다.

 물론 이 외에도 많은 상태코드들이 있다. 이외의 상태코드에 대해서는 아래 링크를 통해 확인하면 좋을 것 같다.

참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTP의 메소드

HTTP 프로토콜은 다양한 메소드를 지원하고 있다. 이 중에서도 가장 많이 사용되는 메소드는 GET, POST, PUT, DELETE, 등이 있는데, 이 중에서 GET과 POST는 각각 읽기(read)와 생성(create)과 관련된 메소드로, PUT과 DELETE는 각각 수정(update)과 삭제(delete)와 관련된 메소드다.

이와 같은 HTTP 메소드들은 대부분 CRUD 작업과 관련이 있다. 

CRUD(create/read/update/delete)

CRUD는 데이터베이스에서 자주 사용되는 개념으로, 데이터를 생성(Create), 읽기(Read), 수정(Update), 삭제(Delete)하는 기본적인 작업을 의미합니다.

이를 위해서 데이터베이스는 다양한 쿼리문을 제공한다.

아래는 각각의 CRUD에 해당하는 쿼리문 예시다.

• CREATE (생성)

DB에서 새로운 데이터를 추가할 때 CREATE 쿼리문을 사용한다. CREATE 쿼리문은 어떤 데이터베이스를 사용하느냐에 따라 다르지만 대부분 다음과 비슷한 구문을 갖는다.

INSERT INTO <테이블 이름> (<컬럼1>, <컬럼2>, ... <컬럼n>) VALUES (<값1>, <값2>, ... <값n>);

여기서 <테이블 이름>은 데이터를 추가할 테이블의 이름이며, <컬럼>은 새로 추가하려는 레코드의 각 필드를 나타낸다.

<값>은 새로 추가하려는 레코드의 각 필드에 들어갈 실제 값을 말한다.

예를 들어, users라는 테이블에서 새로운 사용자를 추가하려면 다음과 같은 쿼리문을 사용하면 된다.

INSERT INTO users (name, email, age) VALUES ('John', 'john@example.com', 30);

• READ (읽기)

DB에서 레코드를 검색하려면 READ 쿼리문을 사용한다. READ 쿼리문은 보통 다음과 같은 구문을 갖는다.

SELECT <컬럼1>, <컬럼2>, ... <컬럼n> FROM <테이블 이름> WHERE <조건>;

여기서 <컬럼>은 검색하려는 레코드의 각 필드를 나타낸다. <테이블 이름>은 데이터를 검색할 테이블의 이름이며, <조건>은 검색할 레코드를 선택하는 조건이다.

예를 들어, users라는 테이블에서 이메일이 'john@example.com'인 사용자를 찾으려면 다음과 같은 쿼리문을 사용한다.

SELECT name, email, age FROM users WHERE email='john@example.com';

• UPDATE (갱신)

DB에서 레코드를 갱신하려면 UPDATE 쿼리문을 사용합니다. UPDATE 쿼리문은 다음과 같은 구문을 갖는다.

UPDATE <테이블 이름> SET <컬럼1>=<값1>, <컬럼2>=<값2>, ... <컬럼n>=<값n> WHERE <조건>;

여기서 <컬럼>은 변경하려는 레코드의 각 필드를 나타낸다. <테이블 이름>은 데이터를 검색할 테이블의 이름이며, <조건>은 변할 레코드를 선택하는 조건이다.

예를 들어, "Customers"라는 테이블에서 "CustomerID"가 1인 레코드의 "ContactName"을 "John Smith"에서 "Peter Lee"로 바꾸는 쿼리문은 아래와 같다.

UPDATE Customers SET ContactName = 'Peter Lee' WHERE CustomerID = 1;

• DELETE (삭제)

DB에서 테이블에서 레코드를 삭제합니다. DELETE 쿼리문은 다음과 같은 구조를 가진다.

DELETE FROM <테이블 이름> WHERE <조건>;

예를 들어, "Customers"라는 테이블에서 "CustomerID"가 2인 레코드를 삭제하려면 다음과 같이 쿼리문을 작성하면 된다.

DELETE FROM Customers WHERE CustomerID = 2;

HTTP 메소드와 CRUD

이러한 관점에서 HTTP 메소드와 CRUD를 짝지어 봤다.

• GET: Read
• POST: Create
• PUT: Update
• DELETE: Delete

이렇게 메소드와 CRUD를 적절하게 짝지은 이유는 각각의 메소드가 수행하는 작업과 CRUD의 개념이 비슷하기 때문이다. 예를 들어, GET 메소드는 데이터를 읽어오는(read) 용도로 사용되기 때문에, CRUD의 Read 작업과 매칭된다.

마찬가지로, POST 메소드는 새로운 데이터를 생성(create)하기 위해 사용되기 때문에, CRUD의 Create 작업과 매칭된다.

POST와 PUT은 모두 데이터를 생성 또는 수정하는 용도로 사용된다.

그러나 POST는 새로운 데이터를 생성하는 데 사용되며, 서버가 해당 데이터의 위치를 결정한다. 반면, PUT은 특정 리소스를 업데이트하는 데 사용된다.

PUT은 리소스의 URI를 지정하고 해당 리소스의 내용을 업데이트한다. 즉, POST는 서버가 데이터 위치를 결정하지만, PUT은 클라이언트가 명시적으로 리소스 위치를 지정한다는 차이가 있다.

따라서, POST와 PUT은 크게 다른 용도로 사용되며, 사용 시에 목적에 따라 적절한 메소드를 선택해야 한다.

Chrome이나 Safari같은 웹브라우저의 검색창에 http://google.com 을 검색하면 브라우저는 입력된 URL의 프로토콜(http)을 파싱해서 어떤 프로토콜인지 확인하고, "http" 프로토콜을 사용하여 "google.com" 도메인에 대한 HTTP 요청을 생성한다.

그렇다면 이 과정은 어떻게 될까?

   1. 로컬 DNS 캐시에서 검색

 먼저 브라우저는 로컬 DNS 캐시에서 "google.com" 도메인 이름과 관련된 IP 주소를 찾는다.
 로컬 DNS 캐시는 이전에 방문한 도메인 이름의 IP 주소를 저장한다. 만약 캐시에 해당 도메인 이름의 IP 주소가 있으면, 브라우저는 바로 해당 IP 주소로 HTTP 요청을 보낸다.

   2. 로컬 DNS 서버에서 검색

 만약 로컬 DNS 캐시에 해당 도메인 이름의 IP 주소가 없으면, 브라우저는 로컬 컴퓨터에 설정된 기본 DNS 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다.
 로컬 DNS 서버는 이를 받아들이고, 자신이 가지고 있는 DNS 캐시에서 "google.com" 도메인 이름과 관련된 IP 주소를 찾는다.

   3. 로컬 DNS 서버에서 검색

 만약 로컬 DNS 서버에도 해당 도메인 이름의 IP 주소가 없으면, 로컬 DNS 서버는 인터넷에서 가장 높은 계층에 위치한 루트 DNS 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다.
 루트 DNS 서버는 이를 받아들이고, "com" 도메인 이름을 관리하는 TLD(Top-Level Domain) DNS 서버의 IP 주소를 알려준다.

   4. TLD DNS 서버에서 검색

 로컬 DNS 서버는 TLD DNS 서버의 IP 주소를 받은 후, 해당 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다.
 TLD DNS 서버는 이를 받아들이고, "google.com" 도메인 이름을 관리하는 DNS 서버의 IP 주소를 알려준다.

   5. 도메인 이름을 관리하는 DNS 서버에서 검색

로컬 DNS 서버는 마지막으로 "google.com" 도메인 이름을 관리하는 DNS 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다. 이 DNS 서버는 "google.com" 도메인 이름에 대한 IP 주소를 알려준다.

   6. 로컬 DNS 서버에 도메인 저장

로컬 DNS 서버는 해당 정보를 자신의 DNS 캐시에 저장하고, 해당 정보를 웹 브라우저에게 반환한다. 웹브라우저는 반환받은 IP주소를 바탕으로 해당 도메인의 웹 페이지를 불러온다.

 이런 기나긴 여정을 통해서 google.com의 웹 페이지가 사용자의 화면에 보일 수 있는 것이다.
 물론 "6. 로컬 DNS 서버에 도메인 저장"  에서 유추할 수 있듯이 이미 한번 질의과정을 거쳐 로컬 DNS 서버의 캐시에 도메인이 저장된 경우에는 위와 같은 질의 과정이 필요없다.

참고 : https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/