HTTP

웹개발에 있어 가장 기본적인 사항이지만

다시 한번 복습하고 이를 정리하기 위해 HTTP에 대하여 작성합니다.

 

먼저 인터넷에서 통신은 어떻게 이루어 질까요

물론 여러 가지 방법이 있기는 하지만 가장 보편화된 방식은

Client - Server 방식을 활용합니다.

여기서 Client는 다른 서버가 될 수도 있고 저희 컴퓨터가 될 수도 있습니다.

즉, Client는 서버에 특정 정보 혹은 액션을 요청하는 컴퓨터 입니다.

Server는 Client의 요청을 대기하고 요청이 오면 그에 맞는 정보와 액션을 수행하는 컴퓨터 입니다.

 

그렇다면 Client는 대체 어떻게 Server에게 요청을 할 수 있을까요? 

인터넷망은 매우 복잡하고 서로 얽혀 있습니다.

이중에서 Client는 Server의 위치를 알야아 하고 해당 위치로 요청을 보내야 합니다.

이를 위해서 IP (Internet Protocol)를 활용합니다.

 

IP, Internet Protocol

각각의 인터넷 장비에는 IP라는 고유 번호가 담겨져 있으며 우리는 이를 이용해서 Server와 통신합니다.

하지만 IP만으로는 통신에 한계가 있습니다.

IP는 비연결성, 비신뢰성이라는 특징이 있습니다.

비연결성이란 패킷을 받을 대상이 없거나 서비스가 불능 상태여도 패킷을 전송합니다.

패킷은 데이터를 효율적으로 보내기 위하여 데이터를 분할한 것입니다.

비신뢰성이란 중간에 패킷이 사라지거나 패킷이 순서대로 안와도 이를 보장하지 않는 다는 것입니다.

 

이를 위하여 TCP나 UDP를 활용하게 됩니다.

TCP는 출발지, 목적지의 포트, 전송 제어, 순서, 검증 정보 등 여러 정보들을 담고 있으며 IP 패킷에 담겨져 전송됩니다.

이러한 점 때문에 TCP/IP라고 부르는 것이죠

 

TCP, Transmission Control Porotocol

TCP의 특징

1) 연결지향 - TCP 3 way handshake

2) 데이터 전달을 보증합니다.

3) 데이터의 순서를 보장합니다.

4) 신뢰할 수 있는 프로토콜입니다.

 

이러한 점 때문에 대부분의 경우 TCP를 사용합니다.

TCP 3way handshake

TCP 3way handshake는 가상회선을 수립하는 단계입니다. 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정입니다. SYN, ACK 패킷을 주고받으며, 임의의 난수로 SYN 플래그를 전송하고, ACK 플래그에는 1을 더한값을 전송합니다. 정확한 순서는 SYN(n) -> ACK(n + 1), SYN(m) -> ACK(m + 1) 순으로 일어납니다.

 

 

UDP, User Datagram Protocol

UDP의 특징

1) 해당 프로토콜이 지원하는 기능이 거의 없습니다.

2) 연결지향이 아니며 3 way handshake를 하지 않습니다.

3) 데이터의 전달을 보증하지 않습니다.

4) 데이터의 순서를 보장하지 않습니다.

 

이러한 특징 때문에 데이터의 전달과 순서가 보장되니는 않지만 빠르다는 장점을 갖고 있습니다.

이러한 점 때문에 스트리밍이나 소켓 등 실시간이 중요한 서비스에서 많이 사용되는 프로토콜입니다,

허나 UDP도 개발자의 역량에 따라 TCP처럼 전달과 순서를 보장 받을 수 있다고 합니다.

실제로 구글에서 개발된 QUIC 프로토콜은 UDP를 기반으로 통신하고 TCP 처럼 데이터의 보장을 받을 수 있습니다.

HTTP 3.0은 QUIC 프로토콜 기반으로 움직이게 됩니다.

 

 

DNS, Domain Name System

우리는 네이버를 사용할때 https://naver.com 이라는 주소를 입력하지 200.200.200.2 이러한 IP 주소를 입력하지 않습니다.

그 이유는 네이버가 DNS 서비스를 활용하고 있기 때문입니다.

DNS는 도메인 네임 시스템으로 도메인 명을 IP 주소로 변환해주는 시스템 입니다.

이러한 DNS 덕분에 우리는 IP 주소를 직접 검색하지 않으며 서버를 여러대 두더라도 하나의 Domain을 통하여 서비스를 운영할 수 있습니다.

 

 

URI, URL, URN

위 세가지는 웹에서 리소스를 식별하는데 사용되는 용어입니다.

 

URI, Uniform Resource Identifier

URI는 리소스를 고유하게 식별하는 문자열입니다. URI는 리소스의 위치, 이름 또는 둘 다를 포함할 수 있습니다. URI는 인터넷에서 리소스를 식별하는 데 사용되며, URL과 URN은 URI의 하위 개념입니다.

즉, 특정 데이터를 찾기 위한 주소나 이름입니다. 물건을 찾기 위해 이름을 사용하는 것과 같은 개념입니다.

 

URL, Uniform Resource Locator

URL은 리소스의 위치를 나타내는 형식입니다. URL은 프로토콜(Protocol)과 네트워크 주소로 구성되며, 특정 리소스의 위치를 가리킵니다. 예를 들어, "https://www.example.com/index.html"은 HTTPS 프로토콜을 사용하고, www.example.com 서버의 index.html 파일을 가리키는 URL입니다. URL은 인터넷에서 리소스의 위치를 식별하는 데 사용됩니다.

즉, 특정 데이터의 위치를 뜻합니다. 물건이 어디에 위치해 두었는지 알려주는 주소입니다.

 

URN, Uniform Resource Name

URN은 리소스의 이름을 나타내는 형식입니다. URN은 리소스의 위치와는 독립적으로 리소스를 식별합니다. URN은 특정 리소스의 이름을 나타내며, 리소스가 이동하더라도 식별 정보는 유지됩니다. 예를 들어, "urn:isbn:0-486-27557-4"는 ISBN(국제 표준 도서번호)을 사용하여 책의 식별자를 나타내는 URN입니다. URN은 인터넷에서 리소스의 이름을 식별하는 데 사용됩니다.

즉, 특정 데이터 그 자체의 이름입니다. 물건의 위치가 어디에 있든 물건의 이름은 동일하게 유지되는 것이라고 보면 됩니다.

 

 

브라우저에 naver.com을 치면 발생하는 일 

브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, 

OS에 전송 요청을 합니다. 이 때, Domain으로 요청을 보낼 수 없기 때문에 DNS Lookup을 수행합니다.

DNS 룩업 과정은 크롬의 경우 브라우저 → hosts 파일 → DNS Cache의 순서로 도메인에 매칭되는 ip를 찾습니다.

만약 이 과정에서도 찾지 못한다면 DNS 서버에 직접 질의하게 됩니다.

이를 통하여 획득한 IP를 토대로 TCP연결 준비를 합니다 ( 3 way handshake ) 이후

http request가 서버로 전송되고 이에 대응하는 response로 html 파일 혹은 데이터를 수신받게 됩니다.

이에 브라우저가 수신한 html 파일을 토대로 렌더링을 시작하여 naver home을 띄우게 됩니다.

여기서 naver나 google 규모의 서비스의 경우 필수적으로 GSLB가 구축되어 있습니다. 

GSLB란 Global server load balancing으로, 

서버를 지리적으로 분산시켜서 지리적 한계를 해결 하거나 부하를 분산하는데 많이 사용됩니다.

만약 네이버 데이터 센터가 서울과 부산에 모두 존재한다는 가정하에

서울 데이터 센터가 화재같은 재해 상황에 놓일시

부산 측 데이터 센터로 요청을 보내게끔 합니다.

 

이는 Health Check 과정이 있기 때문에 가능합니다.

주기적으로 로드밸런서 측에서 서버가 현재 정상적인 동작을 하는지 일정 시간 주기에 맞춰서 요청을 보내고 응답값을 보고 

현재 서버의 상태를 관찰하게 됩니다.

 

혹은 여러 서버를 둔 다음에 라운드 로빈 방식 같은 알고리즘을 통하여

트래픽을 분산하는데도 사용이 됩니다.

 

만약 여러 서버를 둔 경우 세션 측면에서 문제가 발생할 수 있기에 

보통 따로 관리할 수 있는 세션 공유 메모리 데이터 베이스를 사용하게됩니다.

가장 보편적으로 사용되는 제품은 Redis입니다. 

 

보통 CDN ( Content Delivery Network ) 서버를 이용하게 됩니다.

CDN이란 콘텐츠를 효율적으로 전달하기 위해 서버를 지리적으로 분산시켜서 사용자의 위치에 대한 제약 없이 빠른 콘텐츠 제공을 위해 구성되는 네트워크 시스템입니다.

 

이제 이 글의 주제인 HTTP 입니다.

 

 

HTTP, HyperText Transfer Protocol

저희가 가장 많이 사용하는 프로토콜인 HTTP 입니다.

HTTP는 HTML, Text, Image, 음성, 영상, 파일, JSON, XML등 거의 모든 형태의 데이터를 전송할 수 있습니다.

(HTTP헤더의 Content-Type을 통해 데이터의 형태를 구분합니다)

서버간 데이터를 주고 받을때도 대부분 HTTP를 사용하게됩니다.

 

HTTP의 특징

1) HTTP는 기본적으로 클라이언트 서버의 구조입니다.

   - Request와 Response로 이루어집니다.

   - 클라이언트는 서버에 요청을 보내고, 이에 대한 응답을 기다립니다.

   - 서버는 요청에 대한 결과를 만들어서 응답하게 됩니다.

2) 무상태 프로토콜입니다 (Stateless), 즉 비연결성입니다.

   - 서버가 클라이언트의 상태를 보존하지 않는 다는 뜻입니다.

   - 이를 통하여 서버의 확장성을 높일 수 있습니다 (Scale Out, 트래픽에 따라 서버의 댓수를 높이는 기술)

   - 무상태이기 대문에 클라이언트가 자신을 나타내기 위해 추가적은 데이터를 전송하게 됩니다.

   - 연결을 계속 유지하게 되면 서버의 자원이 낭비되는 등 여러가지 단점이 존재하기 때문에 HTTP는 응답이 종료된 후 클라이언트와의 연결을 끊습니다.
이렇나 점 때문에 TCP 3 way handshake를 계속해서 맺고 끊고를 반복하거나

HTML, JS, CSS등 이미 받은 자원을 계속해서 받게 됩니다.

이러한 점을 해결하기 위해 현재는 HTTP/2, HTTP/3에서는 지속 연결 등 여러 방법을 통하여 비효율을 최소화 하고 있습니다.

 

HTTP Method

HTTP는 하나의 URI를 통하여 서버가 여러 기능을 수행할 수 있도록 Method로 구분하도록 합니다.

HTTP의 메소드는 GET, POST, PUT, PATCH, DELETE, OPTION 등이 있습니다.

즉 단순하게 말하자면 URI를 통하여 자원을 식별 및 지정하고 메소드를 통하여 해당 자원에 대한 등록, 수정, 삭제 등 여러 액션을 취할 수 있도록 하는 것입니다.

 

각각의 메소드가 뜻하는 내용은 다음과 같습니다.

GET: 리소스를 조회합니다.

POST: 리소스를 등록합니다.

PUT: 리소스를 대체 하거나 없다면 생성합니다, 

PATCH: 리소스의 일부분을 변경합니다, PUT과의 차이점은 PUT은 일부분만 수정할 경우 다른 데이터는 모두 null이나 빈값으로 대체합니다. 다른 리소스로 판단을 한다는 것이죠

DELETE: 리소스를 삭제합니다.

 

여기서  Request Parameter(Query Parameter)는 GET과 POST 메소드에서만 사용할 수 있고

Request Body는 POST, PUT, PATCH에서 활용할 수 있습니다.

물론 설정을 통하면 다른 메소드에서도 활용 가능하게 됩니다.

 

그 외의 다른 메소드들입니다.

HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 

OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)

CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

물론 GET,POST, PUT 등 HTTP 메소드는 이를 식별하고 활용하기 위한 표시이지 그 의미와 다르게 수행해도 문제가 되지는 않습니다.

예를 들어 게시판의 게시물을 조회하는데 GET 메소드를 활용하지만 조회수 증가를 위하여 리소스의 수정이 이루어 지는 것 처럼요

하지만 이러한 것은 GET메소드의 멱등성을 위배하기 때문에 완벽한 방법이라고 할 수 는 없습니다.

 

멱등, Idempotent

멱등성은 해당 메소드가 한번 호츨하든 두번 호출하든 100번 호츨하든 결과가 똑같은지에 대한 유무 입니다.

멱등성을 가지는 메소드들은 GET, PUT, DELETE 가 있습니다.

GET: 몇번을 조회하든 같은 결과가 조회되게 됩니다.

PUT: 결과를 대체하게 됩니다. 같은 요청을 보내면 여러번을 해도 결과는 똑같습니다.

DELETE: 결과를 삭제합니다. 같은 요청을 보내면 여러번 해도 삭제된 결과는 똑같습니다.

POST의 경우 두번 이상 호출 하면 새로운 게시물이 2번 생기거나 등 같은 결과가 나오지 않기 때문에 멱등하다 할 수 없습니다.

 

멱등은

자동 복구 메커니즘이나

서버가 정상응답을 못주었을때 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단하는데 있어 활용되게 됩니다.

 

HTTP 상태 코드, HTTP Status Code

서버는 HTTP Request에 대한 결과에 대해 Response를 보내야 합니다.

Body를 통해서도 보낼수는 있으나

보다 더 빠르게, 간단하게 이를 식별하기 위해 HTTP에서는 결과에 대한 값을 특정 Code로 나타내게 됩니다.

 

이 Code들은 정수형태로 되어 있고 100번대 부터 500번대 까지 여러 코드로 나누어져 있습니다.

물론 위 코드들을 모두 외울 필요는 없습니다.

 

다만 몇번대인지에 따라서 그 코드의 의미가 달라지기 때문에 100,200,300,400,500 번대가 전반적으로 무엇을 뜻하는지만 아시면 됩니다.

 

1xx (Informational): 요청이 수신되어 처리중 

2xx (Successful): 요청 정상 처리 

3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 

4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 

5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 

 

이렇게 HTTP에 대한 기본적인 내용에 대한 이야기가 끝났습니다.

우리 웹개발자에게 있어서는 HTTP는 떼려야 뗄 수 없는 프로토콜입니다.