Section 2 - Unit 4 : [네트워크] 웹 애플리케이션 작동원리 Review

Review 에서는 학습한 내용을 다시금 기록합니다.
Unit Review는 학습한 내용 중 기존에 알고 있었지만 정확하게 이해하지 못하던 정보와 새롭게 알게된 정보를 기록합니다. 추가적인 설명을 요하는 부분은 댓글로 남겨주세요.
Section Review는 전반적인 Section을 되돌아보고 학습했던 시간과 과정, 내용을 총괄하여 기록합니다.

<<웹 애플리케이션 작동원리>>

---

네트워크를 만드는 기술

* TCP / IP 기본

- LAN과 WAN

• 유/무선에 관계 없이 라우터에 연결 되어있지 않다면 네트워크에 연결할 수 없다.
• 좁은 범위에서 연결된 네트워크를 LAN(Local Area Network)라고 부른다. 동네의 네트워크를 생각하면 된다.
• 이런 LAN들이 모여 세계의 네트워크를 구성하는 WAN(Wide Area Network)가 구성된다.

- 인터 네트워킹(inter networking)

• 네트워크의 확장 방식은 두 가지가 있다.
  • 하나의 네트워크 자체를 확장한다.
  • 네트워크와 네트워크를 연결한다.
• 이 때, 네트워크와 네트워크를 연결하는 것을 인터 네트워킹이라고 한다.
• 인터 네트워킹은 다음과 같은 장점이 있다.
  • 고장의 영향이 광범위하게 전파되지 않는다. 사실, 광범위하게 전파되면 인터 네트워킹 자체가 무용지물이다.
  • 마찬가지로 불필요한 통신이 네트워크 전체로 확산되지 않는다. 이걸 못 막으면 인터 네트워킹을 쓸 필요가 없다.
  • 개별 네트워크는 각자 방침에 따라 관리 가능하다. 안되면, 중앙에서 통제하는 사람의 입맛대로 돌아가는데..
• Internet이 전 세계적 인터 네트워킹의 예시다.

- 프로토콜

• 프로토콜은 둘 이상의 통신 개체 간 소통을 위해 지정한 약속으로, 교환되는 메시지 포맷과 순서뿐 아니라, 메시지의 송수신과 다른 이벤트에 따른 행동들을 정의한다.
• 프로토콜이 정의되어 있지 않다면, 네트워크에 접속하는 컴퓨터마다 다른 언어를 사용할 것이고, 그러면 당연히 소통이되지 않을 것이다.
• 현재는 주로 TCP /IP 프로토콜을 사용한다.

- TCP/IP

• TCP/IP는 인터넷 프로토콜 스위트로, 프로토콜들의 집합이다.
• TCP/IP는 4layer 또는 5layer로 구성되어 OSI 7 layer를 대체한다.

• Application Layer
  • User와 애플리케이션 간의 소통을 담당한다.
  • UI를 포함하여 메일, 파일 다운로드 등의 다양한 서비스를 제공한다.
  • HTTP, SMPT, DNS, FTP 등의 프로토콜이 있다.
• Transport Layer
  • IP와 애플리케이션을 중개하고 이들 간 데이터의 전송을 담당한다.
  • TCP와 UDP가 모두 존재한다.
• Internet Layer
  • 네트워크 주소를 기반으로 서로 다른 네트워크 간 데이터의 전송을 담당한다.
  • IP, ARP, IGMP, ICMP 등이 있다.
• Network Access Layer
  • 컴퓨터를 물리적으로 네트워크에 연결하여 데이터의 전송이 가능하게 한다.
  • Internet Layer 와 달리 같은 네트워크 내에서 데이터를 전송한다.
  • 데이터를 전송하고 싶은 IP 주소가 네트워크에 연결되어 있는지 확인하고 전송한다.
  • Ehernet, Wifi 등이 있다.

- 주소

• 모든 네트워크 장비는 각각의 IP 주소가 할당된다.
• 현재는 xxx.xxx.xxx.xxx 의 형태로 IP 주소를 나타내는 IPv4를 사용한다.
• 0.0.0.0, 255.255.255.255 은 로컬 네트워크에 접속된 모든 장치와 소통하는 broadcast address이다. 서버에서 접근 가능 IP 주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근할 수 있다.
• IP 주소만으로는 네트워크 상에서 송수신이 불가능하다. 제조 단계에서 기기에 할당된 고유한 번호인 MAC주소와 IP주소를 조합해야 통신이 가능하다.
• 내가 향하고자 하는 최종 목적지의 주소가 IP 주소라면, MAC 주소는 해당 주소까지 가기 위해 거치는 내 바로 옆의 노드들의 주소다.
• ARP를 사용하면, 내가 목표로 하는 IP 주소를 가진 기기의 MAC 주소를 알 수 있다. 데이터가 원하는 목적지 노드에 도달했으면 해당 네트워크에 속한 모든 PC에 목표 IP 주소를 가진 PC의 MAC 주소를 요청하고, 목표 IP 주소를 가진 PC는 이에 응답한다.

- 패킷

• 통신 방식에는 서킷 스위칭 방식과 패킷 스위칭 방식 두 가지가 있다.
  • 서킷 스위칭 : 두 호스트 간의 데이터 통신을 위한 회선을 미리 배정받고 이 회선을 통해 통신한다. 이미 정해진 회선을 둘만 이용하기 때문에 데이터의 안정성이 보장된다. 주로 전화 시스템에 사용된다.
  • 패킷 스위칭 : 원본 데이터를 패킷이라는 단위로 자르고 라우터에 전송한다. 따라서, 하나의 라우터를 여러 호스트가 공유할 수 있다.
• 하나의 패킷은 헤더와 페이로드로 구성되어 있다.
  • 헤더 : 어떤 데이터의 몇 번째 패킷인지의 정보와 송신자의 정보, 수신자의 정보가 들어있다.
  • 페이로드 : 실제 데이터가 담겨있다.

 

* IP

- IP 주소 구조

• IP 주소는 네트워크 파트와 호스트 파트로 나뉜다.

• 네트워크 상에서 데이터 통신을 할 때, 같은 로컬 네트워크 내에서 여러 호스트들을 오고간다면, 굳이 해당 네트워크에서 나와서 다시 찾아올 필요가 없다. 해당 네트워크 내에서만 돌아다니면 된다.
• 이렇게 효율적인 통신을 위해 일정한 규칙에 따라 장치들을 하나의 그룹으로 묶는 것이 서브넷의 개념이다.
• 서브넷 마스크는 이 서브넷을 구분하는 방법 중 하나이다.
• 다시 말해, 서브넷 마스크는 전체 IP 주소 중 어디까지가 네트워크 파트인지를 구분하는 방법이다.

- IP 주소의 할당과 관리

• 전체 IP 주소에서 호스트 파트를 변경해 가며 IP 주소를 할당한다.
• 호스트 파트가 0으로만 이루어져있다면 (000, 000.000 등), 이는 네트워크 주소로 해당 네트워크를 의미한다.
• 호스트 파트가 1로만 이루어져있다면 (255, 255.255 등), 이는 브로드캐스트 주소로 ARP와 같은 기능을 하기 위해 사용한다. 

- IP 프로토콜의 한계

• 비연결성 : 패킷을 받을 대상이 없거나 특정한 이유로 서비스 불능 상태에 빠져도 상대의 상태를 알 수 없기 때문에 패킷을 그대로 전송한다.
• 비신뢰성 : 송신 과정에서 패킷 loss가 일어나도 송신측에서는 이를 알 수 없다.

 

* TCP / UDP

- TCP/IP 4계층 모델

• TCP와 UDP는 Transport Layer에서 Application Layer와 Internet Layer를 중개하는 역할을 한다.
• TCP
  • 데이터 통신이 reliable 하다. 데이터의 순서도 지켜진다.
  • flow control이 가능해 송신자는 수신자의 수용량보다 초과해서 데이터를 보낼 수 없다.
  • congestion control이 가능해 네트워크의 과부화를 막을 수 있다.
  • 데이터의 수신이 완료될 때까지 연결이 유지되어 패킷 loss 등이 발생했을 때 빠르게 대처 가능하다.
• UDP
  • 일단 위의 기능은 다 안된다. 그럼 왜 쓸까?
  • 속도가 TCP에 비해 빠르고 단순하다. 예를 들어, 음악이나 영상의 스트리밍 서비스를 이용할 때는, 화질을 유지하기 위해 중간중간 버퍼링이 걸리는 것보다, 잠깐 화질이나 음질이 나빠지더라도 끊기지 않는 것이 중요하다. 이럴 때 UDP를 사용한다.

- TCP 3-way hanshake

• TCP연결은 세 단계를 거쳐 설정된다. 이 세 단계를 3-way handshaking이라 한다.

• 먼저, sender는 reciever에게 연결하고 싶다는 메시지와 SYN(Synchronize Sequence Number)를 보낸다.
• receiver는 이에 응답한다. 이 때, ACK는 받은 SYN이 유효했는지를 의미한다.
• sender는 ACK를 보내고 TCP 연결이 이뤄진다.

 

* PORT

• IP 프로토콜만으로는 어느 애플리케이션에서 데이터를 요구하는 지 알 수 없다.
• 예를 들어, 카카오톡을 켜고 메일을 보내면서 음악을 들으면, 수신 받아온 데이터는 도대체 어느 애플리케이션에 들어가야 하는지 알 수 없다.
• 따라서 우리는 무언가 애플리케이션마다 특정한 번호를 할당해줘야 한다. 이것이 포트번호다.
• 당연히 이미 사용중인 PORT는 다른 애플리케이션이 사용할 수 없다.
• 포트 번호는 0~ 65535까지 사용할 수 있으며 이 중 0~1023번은 이미 지정되어 시스템에서 사용한다.

- 자주 사용되는 Well-known PORT

 

* URL, DNS

- URL

• URL(Uniform Resource Locator)는 웹에 게시된 자원을 찾기 위해 브라우저에서 사용하는 메커니즘이다.
• 다시 말해, 인터넷 상에서 HTML, 이미지 등의 리소스의 위치를 특정하기 위한 서식이다.
• URL은 크게 scheme - hosts - url-path - query로 구분된다.

• scheme : 통신 방식(프로토콜)을 결정한다. 일반적인 웹 브라우저는 http(s)를 사용한다.
• hosts : 웹 서버의 이름이나 도메인, IP 주소를 사용하여 주소를 나타낸다.
• url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등의 리소스가 위치한 경로와 파일명을 나타낸다.
• query : 웹 서버에 보내는 추가 요구사항이다.

- Domain name

• 모든 웹 사이트의 주소를 IP주소로 외워서 사용하기는 어렵다.
• 따라서 웹 사이트는 도메인 이름을 할당받아 사용한다.
• 예를 들어, 구글의 IP 주소는 142.250.204.110이다. 그러나 우리는 주소창에 google.com을 입력해 구글에 접속한다.

- DNS

• 그러면, 할당 받은 도메인 이름과 IP 주소는 어떻게 매핑시킬까. DNS가 이를 담당한다.
• DNS(Domain Name System)는 일종의 분산DB 시스템이다.
• DNS는 여러 서버에 분산되어 있다. 이는 트래픽 처리를 분산해 성능 이슈가 발생하지 않도록 하기 위함이다. 또한, 하나의 DNS만 존재한다면, 해당 DNS에 문제가 생겼을 때, 지구 상의 어느 누구도 google.com을 이용할 수 없다.
• DNS는 여러 계층으로 존재한다. 

• 도메인 이름을 IP주소로 전환하는 방법은 반복질의와 재귀질의가 있다. 재귀질의는 Root Server에 지나친 부하가 걸리기 때문에 쓰지 않는다.

---

웹을 구성하는 기술

* 웹

• 웹은 인터넷에서 제공하는 하이퍼텍스트 시스템이다.
• 이 때 사용되는 하이퍼텍스트는 운영체제나 애플리케이션에 종속적이면 안된다. 웹을 하나 만들어놓으면, 내가 맥에서 해당 웹에 접속하던, 윈도우에서 접속하던 동일하게 작동해야 한다.
• 이를 해결하기 위해 하이퍼텍스트 언어인 HTML을 사용한다. HTML은 브라우저만 있으면 모두가 동일한 정보를 볼 수 있게 해준다.

 

* 웹 애플리케이션 아키텍처

웹 애플리케이션의 구조

- 웹 애플리케이션 아키텍처란?

• 웹 애플리케이션은 다음과 같은 특징이 있다.
  • 데스크탑 애플리케이션처럼 상호작용이 가능하다.
  • 특정 기능을 지니고 있다 (정보 검색 등).
  • 정보나 자료 등의 컨텐츠 관리 시스템과 함께 작동한다.
• 웹 사이트는 정적 페이지들의 집합체다. 웹 사이트에 동적 페이지가 포함되면 이는 이미 웹 애플리케이션이다.
• 따라서 오늘 날 만들어지는 대부분의 웹 사이트는 엄밀히 이야기하면 웹 애플리케이션이 된다.
• 웹 애플리케이션 아키텍처는 애플리케이션 내부 요소들의 소통 방법을 설명한다.
• 유저가 어떤 요청을 보내면, 애플리케이션의 여러 요소들이 상호작용한다. 웹 애플리케이션 아키텍처는 이런 요소들의 상호작용을 유지시켜준다.
• 이 때, 유저의 요청은 다양하다. 그리고 이런 다양한 요청마다 알맞은 응답을 서버는 보내야 한다. 따라서 웹 애플리케이션 서버를 설계할 때는, 많은 요소들을 외부 애플리케이션과 공유하게 설계한다.
• 웹 애플리케이션은 다음과 같은 요소들을 고려하여 설계해야 한다.
  • 신뢰성
  • 확장성
  • 보안성
  • 견고성

 

* 웹 애플리케이션의 요청 흐름

- 웹 애플리케이션의 3단계 계층 구조 (Web Application Three Tier Architecture)

• 웹 애플리케이션의 구조는 크게 3단계로 나눌 수 있다.
  • Presentation Layer : 브라우저 등을 통해 유저와 직접 소통한다. Web server, UI 요소 등을 포함한다.
  • Application Layer : 흔히 비즈니스 로직, 도메인 로직이라고도 불린다. 브라우저로부터 유저의 요청을 받아 처리한다. Application server가 이 영역에 포함된다. 
  • Data access Layer : 애플리케이션의 DB에 접근해 데이터를 불러오거나 저장한다. 이 Layer를 통해 Application Layer 의 로직들은 어느 DB에 접근해서 데이터를 가져오거나 저장할지를 최적화 할 수 있다.
• 주 3계층에 속하지 않는 구성 요소들은 다음과 같다
  • Cross-cutting: 이 요소들은 주로 보안, 통신, 운영 관리등을 위한 요소들이다.
  • Third-party integrations: 제 3의 API 서비스를 이용하는 것을 의미한다. 예를 들어, OAuth 2.0을 이용한 소셜 로그인, PG 사를 이용한 결재기능 등이 여기에 속한다.

 

* 웹 애플리케이션의 구현

- 웹 애플리케이션 구현방식

• Single Page Application
  • 유저의 입력이나 요청에 의한 데이터 최신화가 새로운 페이지를 불러오지 않고 현재 페이지 내에서 이뤄진다.
  • 이는 유저 요청을 반영하기 위한 필수적인 데이터만을 요청함으로써 이뤄진다. 이를 통해 페이지의 새로 고침을 방지하고 UX를 극대화시킨다.
  • 해당 기능을 구현하기 위해 AJAX, Asynchronous JavaScript, XML이 주로 사용된다.
• Microservice Architecture
  • 작고 가벼운 한 가지 기능에 집중한 웹 애플리케이션을 의미한다.
  • 각 애플리케이션의 기능 요소들은 상호간에 의존적으로 설계되지 않는다. 따라서 개발단계에서도 그리고 개발 완성 이후로도 같은 개발 언어를 사용할 필요가 없다.
  • 따라서 기능 개발에 유연성을 더 갖게 되고. 개발 과정의 전반적인 속도와 생산성이 향상 된다.
• Serverless Architecture
  • 개발자가 웹 애플리케이션의 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식이다.
  • 개발자가 기본적인 서버나 기반 기능들에 걱정할 필요 없이 특정기능의 개발에 집중 할 수 있게 한다.

- 웹 애플리케이션 구현 기술

• HTTP
  • HTTP는 웹 브라우저 상에서 클라이언트-서버 간의 통신을 담당하는 프로토콜이다.
  • 클라이언트의 데이터 요청과 서버의 응답을 반복하여 웹 애플리케이션을 작동시킨다.

- Cookie와 Session

• 쿠키
  • 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 한다.
  • 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 작동하게 도와준다.
  • 인가, 장바구니, 추천시스템 등에 주로 사용된다.
• 세션
  • stateless한 상태인 HTTP에서 우리는 로그인이 유지된 채로 웹 애플리케이션을 이용할 수 있다. 이는 세션이 있기에 가능하다.
  • 우리가 로그인을 하는 시점에 랜덤한 세션 ID가 생성되고, 이는 쿠키를 통해 클라이언트에 설정된다.
  • 세션이 유지되는 동안, 세션 ID를 통해 유저를 파악한다.
  • 우리가 어떤 사이트에서 아무 행동도 하지 않고 있으면 '세션이 만료되었습니다.' 와 함께 로그아웃이 되는 것을 생각해보면 이해가 쉽다.

- 사용자 인증

• 인증은 말 그대로 자신이 누구인지를 식별하는 과정이다.
• 어떤 서비스에 회원가입하면 자신의 정보를 해당 서비스의 DB에 저장하고 로그인을 통해 자신이 해당 유저임을 인증한다.

 

* SSR과 CSR

- SSR (Server Side Rendering)

• 서버 단계에서 웹 페이지를 렌더링한다. 
• 클라이언트에서 요청을 보내면, 서버는 응답할 웹 페이지 파일을 렌더링해서 보낸다. 보내진 웹 페이지는 클라이언트 단계에서 완전히 렌더링 된다.
• SEO가 우선순위인 경우, 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 웹 페이지가 사용자와 상호작용이 적은 경우에 일반적으로 SSR 을 사용한다.
• 자원 이용이 서버에 집중되기 때문에 애플리케이션의 유지 비용이 높다.

- CSR

• 클라이언트 단계에서 웹 페이지가 렌더링 된다.
• 클라이언트가 요청을 보내면 서버는 웹 페이지를 렌더링 하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 전송한다. 이 때, 서버는 웹 페이지와 JavaScript 파일을 함께 보낸다.
• 클라이언트는 전달받은 JavaScript를 통해 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.
• SEO가 우선순위가 아닌 경우, 사이트에 상호 작용이 많은 경우, 웹 애플리케이션을 제작하는 경우에 일반적으로 CSR을 사용한다.
• 모든 렌더링 부하가 클라이언트에 집중되어있기 때문에 렌더링 속도가 늦어 UX가 나빠질 수 있다.

---

HTTP

* HTTP Messages

• HTTP messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다. Request와 Response의 두 가지 유형이 있다.

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

- Request

• request line
  • 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD, OPTIONS)을 설명하는 HTTP method를 담는다.
  • HTTP 버전을 담는다.
  • 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로를 담는다.
• headers

• body
  • 모든 request에 body가 필요하지는 않다.
  • POST, PUT 과 같이 데이터를 입력하는 경우에 body가 필요하다.

- Response

• status line
  • request의 결과를 담는다.
  • HTTP 버전을 담는다.
  • 상태 텍스트를 담는다.
• headers

• body
  • 모든 response에 body가 필요한 것은 아니다.

- Stateless

• stateless는 HTTP가 가지는 가장 큰 특징 중 하나다.
• 서버는 클라이언트의 지난 요청에 대한 어떤 정보도 저장하지 않는다.
• 예를 들어, 서버는 장바구니에 상품을 담으라는 요청에 응답한 뒤로는 유저가 장바구니에 상품을 담으라는 요청을 했다는 사실을 모른다.
• 그럼에도 우리는 로그인을 유지하고, 장바구니에 담긴 상품을 유지해야 한다. 이는 쿠키, 세션, 캐시 등을 이용해 구현한다.