HTTP 📜

HTTP는 HyperText Transfer Protocol의 줄임말로, HTML과 같은 문서를 전송하기 위한 OSI 7단계인 Application Layer 프로토콜입니다. HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었습니다.

---

1. Client - Server 💻

클라이언트는 우리가 사용하는 pc, 모바일을 이용해 어떤 상호작용을 수행하는 영역입니다.
상호작용 과정에서 회원 정보 조회, 결제, 검색 등 로컬에 저장되어있지 않은 데이터를 가져와야 합니다. 즉 어떤 리소스를 요청해야합니다.

그렇다면 이 리소스를 어딘가에서 제공을 받아야하는데, 제공을 하는(serving) 곳은 서버라고 부릅니다.

클라이언트가 필요한 리소스를 서버에 요청을 하고, 서버는 그 요청에 따른 리소스를 건네주기 위해 응답을 줍니다.
즉 클라이언트가 어떤걸 주문하면, 서버는 그 주문에 맞는 리소스를 응답합니다.
이를 2-tier 아키텍처, 클라이언트-서버 아키텍처라고 부릅니다.

3-tier 아키텍처는 2-tier 아키텍처에 데이터베이스가 추가된 형태입니다. 리소스를 저장하는 공간을 서버에 저장하는 것이 아니라 따로 데이터베이스라는 곳에 저장하여 서버도 데이터베이스로 클라이언트에게 응답할 리소스를 요청하고, 데이터베이스는 서버로 그 리소스를 응답합니다.

클라이언트와 서버간 통신을 위해선 먼저 정의된 형태로 요청과 응답을 수행해야 합니다.
즉, 어떤 규정된 약속을 기반으로 통신을 수행해야합니다. 이를 HTTP 프로토콜이라 합니다.
HTTP 프로토콜은 HTTP를 이용한 통신을 위한 규칙들이 담겨있는 통신 규약입니다.

1.1 API

클라이언트가 리소스를 요청할 때 HTTP 프로토콜로 요청하는데, 서버에 어떤 데이터들이 있는지 모르는데 어떻게 서버의 데이터를 받아와서 사용할까요?

API(Application Programming Interface)를 통해 수행할 수 있습니다.
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 어떤 가이드, 인터페이스를 제공해줘야 합니다. 이를 API라고 부릅니다.

1.2 URL ?? URI ??

URL 은 Uniform Resource Locator의 줄임말입니다.
네트워크 상에서 웹 페이지, 이미지 등 파일이 위치한 정보를 나타냅니다.
URL은 Scheme, Hosts, URL-Path로 구분됩니다.

https://velog.io/@shitaikoto
제 velog 주소를 예시로 들어보겠습니다.

Scheme은 통신 방식(프로토콜)입니다. 위 예시로 보면, https가 Scheme이 되겠습니다.
Hosts는 웹 서버의 이름 또는 도메인, IP를 사용합니다. 절대적인 주소라고 할 수 있겠습니다.
위 예시로 보면, velog.io가 Hosts가 되겠습니다.

URL-Path는 웹 서버 또는 도메인에서 지정한 루트 디렉토리로부터 시작하여 웹 페이지, 이미지 등 위치한 경로와 파일명을 나타냅니다.
위 예시로 보면, @shitaikoto가 URL-Path가 되겠습니다.
즉, Hosts인 velog.io(도메인)이 루트 디렉토리가 되는 것이며, Path인 @shitaikoto는 루트 디렉토리 다양한 경로 중 하나가 되겠습니다.

URI는 Uniform Resource Identifier의 줄임말입니다. URI는 URL의 구성요소 + query, bookmark를 포함합니다. query는 웹 서버에 보내는 추가적인 질문입니다.

https://velog.io/search?q=http

velog 통합 검색에 http를 검색해보겠습니다.
여기서, velog.io는 Hosts가, search는 URL-Path가 됩니다.

URI의 구성 요소 중 하나인 query는 위처럼 ? 물음표 뒤에 붙게 됩니다.
http라는 키워드로 검색한 결과를 나타냅니다.

즉, 우리가 평소에 어떤 사이트 주소를 공유하기위해 복사 붙여넣기 하는 그 주소는 URI가 될 수 있고, URL가 될 수 있습니다. URI는 URL을 포함하는 상위 개념입니다. URL은 URI라고 볼 수 있지만, URI는 URL이라고 볼 수 없습니다. 구성 요소의 차이가 있기 때문입니다.

1.3 IP 주소 / 도메인

우린 평소에 도메인 주소로 대부분의 웹 페이지를 접속합니다.
옛날 PC 보급률이 낮았을 땐, 네 덩이로 이루어진 IP주소로 웹 페이지에 접근했습니다. 그러나, PC보급률이 증가하고, 다양한 웹 페이지들이 생겨나면서, 외우기 어려운 IP 주소 대신 사용할 주소가 필요했습니다.

무엇이든 이름이 있는 것이 좋은 것 같습니다.

LOL(리그오브레전드) 에서 정글러가 미드라이너에게 블루 버프를 줘야하는 상황을 가정해보겠습니다.

정글러 A : 미드님, (-20,10) 좌표로 오셔서 버프 드세요.
미드라이너 B : 어디요? (무수한 미아 핑)

미니맵이 없다면, 또는 블루 버프의 위치를 잘 모르는 사람이라면, 위치 파악이 매우 어려울 것입니다.
그러나, 이 좌표에 이름이 있다면 누구나 위치를 쉽게 파악할 수 있습니다.

정글러 A : 미드님 블루 ㄱㄱ
미드라이너 B : ㄳㄳ

블루 버프의 정확한 좌표 위치를 모르더라도, 그 대략적 위치의 이름을 알고있기 때문에 누구나 접근할 수 있습니다.

다양한 웹 사이트들도 사용자를 위해 자신의 웹 사이트를 나타내는 도메인 이름을 비용을 지불하여 사용하고 있습니다. 그렇다면, 구입한 도메인 이름과 웹 사이트의 IP 주소를 연동시켜야 사용자가 접속할 수 있게 됩니다. 어떻게 매칭할까요?

브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해선, 해당 도메인 이름과 매칭된 IP주소를 확인해야 합니다. 네트워크는 이를 위한 서버가 존재합니다. 이를 DNS(Domain Name System)이라 합니다. 호스트의 도메인 이름을 IP주소로 변환하거나, IP 주소를 도메인 이름으로 변환하는 데이터베이스 시스템입니다.

예를 들어, 브라우저의 검색창에 naver.com 를 입력하면, 이 요청은 DNS에서 IP주소를 찾습니다. 그리고, 이 IP주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 합니다.

---

2. HTTP Message 📝

HTTP Message는 클라이언트 - 서버 간 데이터가 교환되는 방식입니다. 클라이언트는 서버로 HTTP Message를 통해 리소스를 요청(Requests)하며, 서버는 클라이언트로 HTTP Message를 통해 응답(Responses)합니다.

상세한 HTTP Message의 구조는 MDN 을 참고했습니다.

서버로부터 응답받은 HTTP Message의 Header에는 HTTP 상태 코드가 포함되어 있는 경우가 있습니다.

MDN HTTP 상태 코드

이 상태 코드를 확인하는 것으로 리소스 요청에 있어 어떤 문제가 있는지 파악할 수 있습니다.
예를 들어, 400번 대의 상태 코드를 응답받은 경우, 이는 클라이언트 측에서 발생한 에러입니다. 그렇기 때문에, 클라이언트 측에서 코드를 잘못 작성하지 않았는지 확인할 수 있습니다.

500번대의 상태 코드라면, 서버 측에서 발생한 에러이기 때문에 리소스를 요청받은 서버에서 문제를 해결하는 것으로 에러를 핸들링할 수 있습니다.

---

3. AJAX ⚽

(네덜란드 축구 클럽 아약스 아님)

Ajax(Asynchronous JavaScript and XML, 에이잭스)는 비동기적인 웹 애플리케이션의 제작을 위해 아래와 같은 조합을 이용하는 웹 개발 기법입니다. - 출처

카카오톡을 예시로 들어보겠습니다. 우리가 누군가에게 카카오톡 메세지를 보냈습니다. 메세지를 보내고 창을 닫으면, 카카오톡 채팅 내역이 업데이트 됩니다. 이 때, 단순하게 한 명에게만 메세지를 보냈는데, 지금까지 보냈던 모든 기록들이 다시 업데이트 된다면 어떻게 될까요? 사용자 경험 측면에서, 메세지를 보내는 일은 굉장히 중요한 일이 아니고서야 하기 귀찮은 일이 될 것입니다.

하지만, 카카오톡은 하나의 애플리케이션 으로서, 한 사람에게 카톡 메세지를 보내는 것으로 그 사람과의 대화 내역만 업데이트 될 뿐, 전체 페이지를 새로 업데이트하지 않습니다. 즉, 사용자는 오랜 기다림 없이 쾌적하게 카카오톡을 사용할 수 있습니다.

이러한 관점을 웹에도 적용시켜, 웹 페이지가 아닌 웹 애플리케이션으로 기능하게 하는 것이 매우 중요해졌습니다.

서버와 자유롭게 통신하기 위해 XMLHttpRequest(XHR)을 사용하고,
Javascript와 DOM을 이용해 연속적인 기능 동작을 구현하는 것을 AJAX 개념을 적용한 웹 개발이라 볼 수 있으며, AJAX를 통해 동적인 웹 앱을 개발할 수 있습니다.

3.1 SSR / CSR

SSR은 Server Side Rendering의 줄임말입니다. 웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링합니다.

CSR은 Client Side Rendering 을 의미합니다. 일반적으로 CSR은 SSR의 반대로 여겨집니다. SSR이 서버 측에서 페이지를 렌더링한다면, CSR은 클라이언트에서 페이지를 렌더링합니다.

브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보냅니다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보냅니다. 클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꿉니다.

CSR과 SSR의 주요 차이점은 페이지가 렌더링되는 위치입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링합니다. 브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리합니다.

인터랙티브한 웹 앱을 제작할 경우, CSR를 이용해 강력한 사용자 경험(빠른 동적 렌더링)을 제공할 수 있습니다.

웹 페이지가 사용자와 상호작용이 적은 경우, SSR을 사용할 수 있습니다. 또한, 웹 페이지의 첫 화면 렌더링이 빠르게 필요할 경우에도 단일 파일 용량이 작은 SSR이 적합합니다.

---

HTTP와 관련된 학습 내용을 정리해보았습니다. 수정해야할 부분이 있다면 댓글로 피드백 부탁드립니다! 긴 글 읽어주셔서 감사드립니다! 🙏