[네트워크] 웹 애플리케이션 작동 원리

1. 웹애플리케이션에 대한 이해

특정 기기에 설치해서 사용하는 애플리케이션을 네이티브 애플리케이션(Native-application)이라고 한다.

네이티브 애플리케이션은 Apple iOS, Android OS, Windows와 같은 특정 실행 환경에 종속된다.

웹 브라우저를 통해 접근이 가능한 애플리케이션을 웹애플리케이션이라고 한다.

 

2. 네트워크를 만드는 기술

2-1. TCP/IP 기본

LAN과 WAN

우리의 컴퓨터는 인터넷 제공업체에서 제공한 인터넷 라우터를 통해 연결되어 있다.

유선이 되었든 무선이든 라우터에 연결이 되어있지 않다면 인터넷을 사용할 수 없다.

이러한 좁은 범위에서 연결된 네트워크를 LAN(Local Area Network)이라고 부른다.

그리고 수많은 LAN들이 모여 세계의 네트워크를 구성하는 WAN(Wide Area Network)이 된다.

 

인터네트워킹(internetworking)

네트워크를 확장하는 방식은 크게 두 가지 방법이 있다.

• 한 네크워크를 확장하는 방법
• 네트워크와 네트워크를 연결하는 방법

여기서 두 번째 방법인 여러 네트워크를 연결하는 것을 인터네트워킹이라고 하며 전 세계적으로 인터네트워킹하는 것이 바로 우리가 사용하는 인터넷(The Internet)이다.

 

인터네트워킹의 장점

1. 네트워크의 일부에서 고장이 나도 영향이 광범위하게 퍼지지 않는다.
2. 불필요한 통신이 네트워크 전체로 확산하지 않는다.
3. 개별 네트워크를 각각의 방침에 따라 관리가 가능하다.

 

프로토콜(protocol)

컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계를 프로토콜이라고 한다.

쉽게 말하자면, 인터넷에 연결되어 있는 컴퓨터들끼리 소통을 하기 위한 약속이라고 생각하면 된다.

그렇다면 프로토콜이 왜 필요할까?

예를 들어, 가전제품 제조사마다 전원 연결부를 다르게 만들어서 판매하는 상황을 생각해보자.

아마 제품을 구입할 때마다 전기 기술자를 불러서 콘센트를 바꿔 달아야 할 것이다.

이처럼 인터넷 통신도 마찬가지로 어느 컴퓨터든 일관되게 네트워크를 사용할 수 있게 하는 공통 언어가 필요하다.

 

TCP/IP

인터넷 통신 스위트(Internet Protocol Suite)는 인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 쓰이는 통신 규약의 모음이다.

이 모음은 다른 컴퓨터나 다른 운영체제, 다른 회선간의 통신이 가능하게 해준다.

인터넷이 처음 시작하던 시기에 정의되어 현재까지 표준으로 사용하고 있는 TCP(Transmission Control Protocol)와 IP(Internet Protocol)에서 가져와 TCP/IP라고 부른다.

TCP/IP 4계층 : OSI 7계층 이론을 실제 사용하는 인터넷 표준

데이터가 계층모델을 통해 상대에게 도달하는 흐름

그럼 각 Layer의 요소가 네트워크 세계에서 실제로 어떻게 사용되는지 알아보자.

 

주소(address)

TCP/IP 구조에서 컴퓨터를 식별하기 위해 사용되는 주소를 IP 주소라고 한다.

컴퓨터나 휴대전화, 서버, 인터넷 라우터 등 네트워크 장비에 각각의 IP 주소가 할당되는데 이 때 IP 주소에는 private 주소와 public 주소가 포함된다.

LAN 네트워크 내부에서 사용되는 것이 Private IP 주소이고, 인터넷에서 사용되는 것이 Public IP 주소다.

인터넷에 연결된 모든 PC는 IP 주소체계를 따라 192.xxx.xxx.xxx 과 같은 네 덩이의 숫자로 구분되며 이런 형식의 주소체계를 IPv4라고 한다.

 

MAC 주소

IP address만 가지고는 네트워크 상에서 송수신이 가능하지는 않다. 각 네트워크 기기는 처음부터 제조사에서 할당하는 고유 시리얼인 MAC 주소를 IP 주소와 조합해야만 네트워크를 통한 통신이 가능하다.

같은 LAN에 속한 기기끼리 통신을 할 때는 우선 상대방의 MAC 주소를 파악해야 하는데 이 때 사용하는 것이 ARP(address resolution protocol)이다.

ARP란 MAC 주소를 파악하기 위해 네트워크 전체에 브로드캐스트를 통해 패킷을 보내고, 해당 IP를 가지고 있는 컴퓨터가 자신의 MAC 주소를 Response 하게 됨으로써 통신할 수 있게 해주는 프로토콜이다.

패킷

기기 간의 통신에는 회선 교환(Circuit Switching) 방식과 패킷 교환(Packet Switching) 두 가지 방식이 있다.

통신 회선을 설명하여 데이터 교환을 하는 회선교환 방식은 주로 음성전화 시스템에 사용된다.

전화는 일대일로 데이터를 교환하고, 통화 중에는 다른 상대와 통화가 불가능하다.

하지만 컴퓨터 네트워크는 여러 상대와 통신이 가능해야 하기 때문에 회선 교환 방식은 비효율적이다.

그래서 생겨난 것이 패킷 교환 방식이다.

패킷 교환 방식은 원본 데이터를 패킷(packet)이라고 하는 작은 단위로 나누고, 여러 회선을 공용해 통신을 주고 받는 방식을 말한다.

하나의 패킷은 헤더와 페이로드로 구성되어 있고, 헤더에는 데이터의 정보, 보내는 곳, 최종 목적지에 대한 정보 등이 들어있다.

 

2-2. IP

IPv4 주소는 10진수로 표기되어 있지만, 그 실체는 마침표로 구분된 4개의 8비트 필드로 되어 있다.

각 8비트 필드는 IPv4 주소에서 1바이트를 나타내며 옥텟이라고 한다.

즉 IPv4 주소는 4개의 옥텟으로 이루어지며 각각을 1옥텟, 2옥텟, 3옥텟, 4옥텟이라고 부른다.

IP 주소는 네트워크 주소와 호스트 주소 두 부분으로 나뉜다.

네트워크 주소는 호스트들을 모은 네트워크를 지칭하는 주소이며 호스트 주소는 하나의 네트워크 내에 존재하는 호스트를 구분하기 위한 주소다.

예를 들어 **아파트 101동 202호에서 **아파트 101동이 네트워크 주소, 식별이 가능한 202호가 호스트 주소라고 할 수 있다.

그리고 IPv4에서 네트워크 주소가 어디까지인지 나타내는 것이 서브넷 마스크다.

• IP 주소 : 192.168.1.1
• 서브넷 마스크 : 255.255.255.0
• 네트워크 주소 : 192.168.1.0
• 브로드캐스트 주소 : 192.168.1.255

 

앞서 MAC 주소와 달리, IP 주소는 처음부터 주어지는 것이 아니라 할당이 되는 것이라고 배웠다.

위와 같은 예라면, 호스트 주소는 8자리로 이루어진 2진수이므로, 할당할 수 없는 시작(0)과 끝 숫자(255)를 제외한 번호로 할당이 가능하다.

• 호스트 주소가 0으로만 이루어진 것은 네트워크 주소로 그 네트워크를 의미한다.
• 호스트 주소가 1로만 이루어진 것은 브로드캐스트 주소로 ARP와 같은 기능을 사용하기 위해 사용한다.

IP 프로토콜의 한계

IP 프로토콜은 패킷을 받을 대상이 없거나 특정한 이유로 서비스 불능 상태에 빠져도 데이터를 받을 상대의 상태 파악이 불가능하기 때문에 패킷을 그대로 전송하는 비연결성 문제가 있다.

또한 중간에 패킷이 사라지더라도 보내는 기기 측에서는 알 수 있는 방법이 없고 보내는 기기 측에서 의도한 순서대로 데이터가 도착하지 않을 수도 있다.

그리고 한 IP에서 여러 애플리케이션이 작동하는 경우 특정할 수 없는 한계가 있다.

이러한 한계를 극복하기 위해 사용하는 것이 TCP와 UDP이다.

 

2-3. TCP, UDP

TCP와 UDP는 TCP/IP 4계층 모델을 기준으로 IP 프로토콜의 계층인 인터넷 계층의 상위에서 동작을 한다.

전송계층에 속하는 TCP와 UDP는 2계층에서 동작하는 IP와 4계층에서 동작하는 애플리케이션을 중개하는 역할을 한다.

데이터 신뢰성을 필요로 하는 애플리케이션은 TCP로, 빠른 속도와 실시간 통신이 중요한 애플리케이션은 UDP로 구분해서 사용한다.

특히 웹애플리케이션에서 많이 사용하는 HTTP의 경우 모든 데이터를 제대로 송수신 해야 하는 특성 상, TCP를 사용한다.

 

TCP 3-way handshake

TCP 3-way handshake는 양 끝단의 기기의 신뢰성 있는 데이터 통신을 위해, TCP 방식이 연결을 설정하는 방식이다.

마치 전화를 거는 것 같이 연결을 설정하는 이 방식은 세 단계를 통해 연결 설정을 한다.

• Step 1 (SYN) : 처음으로 sender는 receiver와 연결 설정을 위해 segment를 랜덤으로 설정된 SYN(Synchronize Sequence Number)와 함께 보낸다. 이 요청은 receiver에게 sender가 통신을 시작하고 싶다고 알린다.
• Step 2 (SYN/ACK) : receiver는 받은 요청을 바탕으로 SYN/ACK 신호 세트를 응답한다. ACK 응답으로 보내는 segment가 유효한 SYN 요청을 받았는지를 의미한다.
• Step 3(ACK) : 마지막 단계에서 sender는 받은 ACK를 receiver에게 전송을 하면서 신뢰성 있는 연결이 성립되었다는 사실을 sender와 receiver 양쪽에서 알 수 있고, 실제 데이터 전송이 시작된다.

SYN(Synchronization) : 연결 요청, 세션을 설정하는 데 사용되며 초기에 시퀀스 번호를 보낸다. ACK(Acknowledgement) : 보낸 시퀀스 번호에 TCP 계층에서의 길이 또는 양을 더한 것과 같은 값을 ACK에 포함하여 전송한다.

UDP

TCP처럼 가상의 회선을 설정해 신뢰성을 보장하면 당연히 좋은데 왜 UDP를 사용할까?

예를 들어 게임을 하다가 궁극기를 사용해야 할 때, 보이스톡을 할 때 약간의 지연시간이 발생하고 또 그 지연시간이 매번 다르다면 어떨까?

아래와 같은 이유로 많은 애플리케이션 개발자들은 UDP를 사용한다.

• 애플리케이션의 정교한 제어가 가능하다. TCP의 경우 receiver가 전송 받을 준비가 될 때까지 세그먼트를 반복적으로 재전송한다. 실시간 전송에 대한 요구가 큰 애플리케이션들은 높은 latency를 지양하므로 약간의 데이터 손실을 감수하는 대신 이를 보완하기 위해 애플리케이션에 추가 기능을 구현할 수 있다.
• 연결 설정에 무관하다. TCP 3-way handshake가 없는 UDP는 예비과정 없이 바로 전송을 시작하며 설정 단계에서 발생하는 지연이 없는 만큼 반응속도가 빠르다. 또한, TCP가 신뢰성을 위해 많은 파라미터와 정보 전달이 필요함에 비해 UDP는 연결설정 관리를 하지 않기 때문에 어떠한 파라미터도 기록하지 않는다. 이 때문에 서버에서도 더 많은 클라이언트를 수용이 가능하다.

💡 만약 DNS 서버가 TCP 방식에서 동작한다면 속도 측면에서 부적합할 것이다. 또한 도메인 네임을 IP로 변경함으로 항상 많은 클라이언트를 수용하는 DNS 서버에는 정보 기록을 최소화하는 UDP가 알맞다.

 

2-4. PORT

포트번호는 대상 IP 기기의 특정 어플리케이션을 특정하는 번호로 TCP와 UDP 둘 다 포트번호를 사용한다.

이렇게 한 서버 인스턴스에서 웹 서버와 메일 서버 두 개를 동시에 실행 중이라고 가정해보자.

IP 주소만으로는 어느 서버로 요청을 보내는지 알 수 없기 때문에 포트 번호를 사용해 receiver를 특정하는 것이다.

포트 번호는 0~65,535를 사용할 수 있고 그 중에서 0~1,023의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.

이 중 자주 사용되는 Well-known port는 다음과 같다.

 

2-5. URL, DNS

URL(Uniform Resource Locator)은 웹에 게시된 어떤 자원을 찾기 위한 브라우저에서 사용되는 메카니즘이다.

브러우저의 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타낸다.

예를 들어, https://codestates.com:443사이트에 접속하게 되면, codestates.com 주소가 가리키는 서버의 기본 폴더를 뜻한다.

CLI 환경에서 폴더와 파일의 위치를 찾아 이동하듯이, 슬래시(/)를 이용해 서버의 폴더에 진입하거나 파일을 요청할 수 있다.

그러나 기본적인 보안의 일환으로 외부에서 직접 접근이 가능한 경우는 거의 없다.

URI(Uniform Resource Identifier)는 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함한다.

 

Domain name

만약 웹사이트의 주소를 https://142.250.207.78/weather/index.html 처럼 IP 주소로만 작성해서 이용해야 한다면 매우 불편할 것이다.

호스트 이름과 도메인 이름으로 바꾸어 아래처럼 기억하기 쉬운 이름을 사용할 수 있다.

만약 IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 볼 수 있다.

그렇다면 도메인은 어떻게 관리되고 있을까?

ICANN이라는 비영리 단체에서 4억개에 달하는 도메인을 관리하고 있다.

그 밖의 조직으로 Registry와 Registrar가 있다.

Registry는 최상위 도메인(TLD) 관리 기관으로 각 도메인 정보의 데이터베이스를 관리한다.

Registrar는 중개 등록업체로 Registry의 데이터베이스에 직접 도메인 정보를 등록한다.

 

최상위 도메인은 일반 최상위 도메인(gTLD; generic Top Level Domain)과 국가 최상위 도메인(ccTLD; country code Top Level Domain) 두 종류로 나뉜다.

💡 gTLD는 .com, .net, .org, .edu, .gov, .int, .mil 등이 있다.
ccTLD는 .kr, .co.kr, .or.kr, .go.kr, .ac.kr 등이 있다.

 

DNS

네트워크 상에 존재하는 모든 PC는 IP 주소가 있지만, 모든 IP 주소가 도메인 이름을 가지는 것은 아니다.

로컬 PC를 나타내는 127.0.0.1은 localhost로 사용할 수 있지만 그 외의 모든 도메인 이름은 일정 기간 동안 대여해서 사용한다.

브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해서는 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 필요한데 이 역할을 수행하는 서버가 DNS다.

DNS(Domain Name System)는 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행하도록 개발된 데이터베이스 시스템이다.

 

3. 웹을 구성하는 기술

3-1. 웹(WEB)

웹(WEB)은 인터넷에서 제공되는 하이퍼텍스트 시스템이다.

💡 하이퍼텍스트란?
문서 안에 다른 문서의 위치 정보 등을 포함하여 문서 간의 정보를 서로 연관 지어 참조할 수 있는 문서

 

3-2. 클라이언트-서버 아키텍처

웹에서 제공되는 서비스는 주로 서비스를 이용하는 클라이언트와 서비스를 제공하는 서버로 나뉜다.

이러한 구조를 클라이언트-서버 아키텍처, 다른 말로는 2티어 아키텍처라고 한다.

일반적으로 서버는 리소스를 전달해주는 역할만 담당한다. 리소스를 저장하는 공간을 별도로 마련해두는데 이 공간을 데이터베이스라고 한다.

이렇게 기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

 

클라이언트는 보통 플랫폼에 따라 구분되는데, 브라우저를 통해 주로 이용하는 웹 플랫폼에서 클라이언트는 웹사이트 또는 웹 앱이라고 부른다.

서버는 무엇을 하느냐에 따라 종류가 달라진다. 파일 서버는 파일을 제공하는 앱, 웹 서버는 웹사이트에서 필요로 하는 정보들을 제공하는 앱, 메일 서버는 메일을 주고 받을 수 있도록 도와주는 앱이다.

 

3-3. 웹 애플리케이션 아키텍처

웹사이트와 웹 애플리케이션의 차이가 뭘까?

 

웹 애플리케이션은 아래와 같은 특징이 있다.

• 데스크탑 애플리케이션처럼 상호작용이 가능하다.
• 특정 기능을 가지고 있다.(정보 검색 등)
• 정보나 자료 등의 콘텐츠 관리 시스템과 함께 작동한다.

 

웹 개발 영역에서 웹사이트라고 하면 일반적으로 정적 페이지들의 집합체를 의미한다.

여기서 웹사이트가 동적 페이지를 포함하게 된다면 웹 애플리케이션이 된다.

이렇듯 오늘날 만들어지는 대부분의 웹사이트들은 엄밀히 말하자면 웹 애플리케이션들이다.

 

웹 애플리케이션 아키텍처는 클라이언트-서버 간의 연결에 대한 설명 방법이라고 할 수 있다.

조금 더 기술적으로 풀어보면, 유저가 웹브라우저에서 요청을 하면 애플리케이션의 다양한 요소들이 상호작용을 하고, 이러한 요소들이 상호작용을 유지할 수 있도록 서로를 결부시키는 뼈대를 웹 애플리케이션 아키텍처라고 한다.

 

3-4. 웹 애플리케이션의 요청 흐름

https://urclass.codestates.com 로 접속한다고 생각해 보자

• 브라우저에 https://urclass.codestates.com 를 입력한다.
• 브라우저는 URL을 입력 받으면 서버의 주소를 찾기 위해 DNS 서버에 요청을 보낸다.
• IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보낸다. 이미 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져온다.
• 웹서버에 요청이 도착 한다.
• 웹서버는 저장소에 요청을 보내 페이지 관련 데이터들을 가져온다.
• 정보들은 가져오는 중에 비지니스 로직이 작용한다.
• 비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있다.
• 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답한다.
• 요청들이 브라우저에 응답으로 돌아왔을 때, web page 화면에서 출력된다.

 

웹 애플리케이션은 크게 두 가지 영역으로 나눌 수 있다.

• 유저 인터페이스 요소 : 웹 애플리케이션의 기능적인 부분 외적인 요소들이다.
• 구조 요소 : 웹 애플리케이션의 전체적인 구조를 담당하며 웹 브라우저, 클라이언트, 웹 애플리케이션 서버, 데이터베이스로 이루어져 있다.

 

웹 애플리케이션의 구조는 다양한 단계와 계층으로 나뉘지만 이 중 가장 널리 사용되는 3-Tier Architecture을 살펴보자.

• Presentation Layer : 이 계층은 유저와 브라우저 등을 이용해 직접적으로 접촉을 한다. Web Server가 이 영역에 포함되며, 유저 인터페이스 요소들을 포함한다.
• Application Layer : Business Layer, Business Logic 혹은 Domain Logic이라고 불리기도 하는 이 영역은 유저의 요청을 브라우저로부터 받아서 처리를 한다. Application Server가 이 계층에 포함되며 데이터 접근을 위한 경로를 규격화하는 등의 과정이 이 계층에 작성이 된다.
• Data Access Layer : Persistence Layer라고도 불리는 이 계층은 애플리케이션의 데이터 저장소에 접근하여 데이터를 불러오거나 저장을 담당한다. Application Layer는 이 계층과 밀접한 연관을 가지고 있다. 이 단계를 통해 Application Layer의 로직들은 어느 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장할지를 결정한다.

 

3-5. 웹 애플리케이션의 구현

웹 애플리케이션을 구성할 때는 아래 세 가지 방식을 사용한다.

• Single Page Application 말 그대로 하나의 페이지를 사용하는 애플리케이션이다. 서버로부터 새로운 페이지를 가져오는 것이 아닌, 하나의 페이지에서 내용을 동적으로 변경함으로써 사용자 웹앱을 의미한다.
• Microservice Architecture 작은 서비스 여러 개가 모여서 하나의 시스템을 제공하는 아키텍처를 의미한다. 각 애플리케이션의 기능 요소들이 독립적으로 설계된다는 특징이 있다.
• Serverless Architecture 말 그대로 서버가 없다라는 뜻이다. 하지만 실제로 서버가 없는 구조는 아니고 서버에서 처리하는 작업을 클라우드 기반의 서비스로 처리해서 서비스 구축 및 관리 비용을 줄이는 구조다.

 

Cookie와 Session

HTTP는 데이터를 요청하고 요청에 대한 응답을 전송하는 무상태성의 프로토콜이다.

예를 들어 특정 쇼핑몰에 접속하여 쇼핑을 한다고 가정했을 때 일부 물품만 결제를 진행하거나 장바구니에 상품을 담아놓고 추후에 구매한다던지 하는 기능을 실현하기 위해서는 무상태성의 특징을 가지고 있는 HTTP 프로토콜만 가지고는 불가능하다.

이를 위해 필요한 기능이 쿠키와 세션이다.

 

쿠키는 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 한다.

세션은 서버에 Session-Id라는 고유 아이디를 할당해서 유저를 식별한다. 단순하고 유출이 되면 안 되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭해서 저장해 관리한다.

주로 세션 정보는 쿠키에서, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적이다.

 

3-6. SSR과 CSR

SSR(Server Side Rendering)

브라우저가 서버의 URI로 GET 요청을 보내면 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다.

그리고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다.

서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링했기 때문에 Server Side Rendering 이라고 불린다.

웹 페이지를 살펴보던 사용자가 브라우저의 다른 경로로 이동하면 어떻게 될까?

다른 경로로 이동할 때마다 서버는 이 작업을 다시 수행해야 한다.

 

CSR(Client Side Rendering)

일반적으로 CSR은 SSR의 반대로 여겨진다. SSR이 서버 측에서 페이지를 렌더링한다면, CSR은 클라이언트에서 페이지를 렌더링한다.

웹 개발에서 사용하는 대표적인 클라이언트는 웹 브라우저다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지와 JavaScript 파일을 보낸다.

클라이언트가 웹 페이지를 받으면 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꿔준다.

 

만약 웹 페이지에 필요한 내용이 데이터베이스에 저장된 데이터인 경우에는 어떻게 해야 할까?

브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링을 해야 하며 이를 위해 API가 사용된다.

웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 해소한다.

 

💡 [예시]
SSR : 온라인에서 가구를 주문했을 때 배송 출발지에서 조립을 완료한 상태로 보내는 것

CSR : 모든 부품이 최대한 나뉘어 운송이 쉬운 상태로 배송이 된 다음 집에서 조립을 하는 것

 

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

 

SEO가 우선순위인 경우, 첫 화면 렌더링이 빨라야하거나 웹 페이지가 사용자와 상호 작용이 적은 경우 등에 SSR을 사용한다.

반대로 SEO가 우선순위가 아니거나, 사이트에 풍부한 상호 작용이 있는 경우, 웹 애플리케이션을 제작하는 경우 등에 CSR을 사용한다.

 

다만 SSR을 사용하는 경우 애플리케이션 유지비용이 높고, 일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있다는 단점이 있다.

CSR을 사용하는 경우 느린 렌더링 속도로 사용자 경험이 안 좋아질 수 있고 search engine bots와 상성이 좋지 않다는 단점이 있다.

 

💡 SSR 사용 예시 : 네이버 블로그
CSR 사용 예시 : 아고다

 

4. HTTP

4-1. HTTP Messages

HTTP(HyperText Transfer Protocol)는 HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이다.

HTTP messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다. HTTP messages에는 요청(Requests)과 응답(Responses) 두 가지 유형이 있다.

요청과 응답은 다음과 같은 유사한 구조를 가진다.

1. start line : start line에는 요청이나 응답의 상태를 나타내며 항상 첫 번째 줄에 위치한다. 응답에서는 status line이라고 부른다.
2. HTTP headers : 요청을 지정하거나 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
3. empty line : 헤더와 본문을 구분하는 빈 줄
4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함하며 유형에 따라 선택적으로 사용한다.

이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 한다.

 

요청(Requests)

Start line

Start line에는 세 가지 요소가 있다.

1. 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다. 예를 들어, method는 리소스를 받아야 하고 POST method는 데이터를 서버로 전송한다.
2. 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다. 이 요청 형식은 HTTP method마다 다르다.
3. HTTP 버전에 따라 HTTP message의 구조가 달라진다. 따라서 start line에 HTTP 버전을 함께 입력한다.

 

Headers

헤더 이름(대소문자 구분이 없는 문자열), 콜론(:), 값을 입력한다.

여러 종류의 헤더가 있지만 다음과 같이 그룹을 나눌 수 있다.

• General headers : 메세지 전체에 적용되는 헤더로 body를 통해 전송되는 데이터와는 관련이 없다.
• Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함한다.
• Representation headers : body에 담긴 리소스의 정보를 포함한다.

Body

HTTP messages 구조의 마지막에 위치하며 모든 요청에 body가 필요하지는 않다.

GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 body가 필요하지 않지만 POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 body를 사용한다.

body는 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성되는 Single-resource bodies와 여러 파일로 구성되는 Multiple-resource bodies로 나눌 수 있다.

 

응답

Status line

응답의 첫 줄은 아래 세 가지 정보를 포함하며 HTTP/1.1 404 Not Found. 와 같이 작성된다.

1. 현재 프로토콜의 버전(HTTP/ 1.1)
2. 상태 코드 - 요청의 결과를 나타낸다(200, 302, 404 등)
3. 상태 텍스트 - 상태 코드에 대한 설명

Headers

요청의 헤더와 동일한 구조를 가지고 있으며 마찬가지로 아래처럼 나눌 수 있다.

• General headers : 메세지 전체에 적용되는 헤더로 body를 통해 전송되는 데이터와는 관련이 없다.
• Request headers : 위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적인 정보를 갖는다.
• Representation headers : body에 담긴 리소스의 정보를 포함한다.

Body

요청의 바디와 동일하다.

 

Stateless

HTTP의 가장 큰 특징으로 상태를 가지지 않는다는 뜻이다. HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.