오늘
- HTTP
- 네트워크를 만드는 기술
- 웹을 구성하는 기술
시작하기 전
웹 애플리케이션이란?
웹 애플리케이션을 보기 전 네이티브 애플리케이션Native-application에 대해 보자.
네이티브 애플리케이션은 특정 기기에서 다운받아 사용하는 애플리케이션이다.
EX ) 핸드폰에 무언가를 다운받아 설치한다.
즉 Window나 Android OS, Apple iOS 같이 특정 실행환경에 종속되게 된다.
아이폰에 깔리는 어플이 안드로이드나 윈도우 같은 다른 환경에서는 실행시킬 수 없는 것처럼.
| 네이티브 애플리케이션의 장점 | 단점 |
|---|---|
| 웹애플리케이션보다 빠르다 | 웹애플리케이션에 비해 개발비가 더 들어간다 (아이폰과 안드로이드 간의 멀티 플랫폼 개발 등). |
| 애플리케이션이 설치된 기기의 시스템/기기의 리소스에 접근이 용이.(GPS 기능이나 카메라) | 빠른 업데이트가 힘들다. |
| 인터넷 없이 사용 가능하다. | 앱스토어에 승인 받기가 힘들고 비용이 발생한다. |
| 웹애플리케이션에 비해 안전하다.(모바일의 경우 앱스토어에 승인을 받아야 함) |
추가설명
장점
- 인터넷 없이 사용 가능하다라는 건 어플 실행은 가능하다는 뜻이다. 그리고 인터넷이 필요없는 어플들이 존재하기 때문이다. (계산기...등등)
- 안전하다 라는 것은 이미 어플 검수를 다 끝마친 상태에서 스토어에 올라가기 때문에 웹 어플리케이션에 비교하면 안전하다는 의미.
단점
- 개발비가 많이 든다는 것은 특정 기기에 맞게 특정 언어를 사용해서 개발을 해야하기 때문. 이유는 각각의 호환성 때문인데 (예로 들면 아이폰이라면 애플에서 사용하는 언어로 개발하고, 안드로이드라면 거기에 맞게 개발을 해야한다. 그런데 그 언어를 잘 활용하려면 그 분야에 맞는 사람을 고용해야하고 그런 식으로 되면 웹 애플리케이션에 비해서 비용이 많이 나간다는 의미.)
- 빠른 업데이트가 힘든 이유는 업데이트를 한다는 것은 버전이 새로 나온다는 뜻이고 그럼 그 버전이 적용된 어플을 스토어에 올려야 한다. 그럼 또 다시 검수를 받아야 하고 이 과정이 웹 애플리케이션에 비교해해서 힘들다는 것.
웹 애플리케이션
웹 애플리케이션은 웹 사이트에서 업그레이드...? 라고 할까
웹 사이트는 하이퍼텍스트 링크를 걸어 웹 페이지들을 모아 둔 것이였다. 아래 사진 참조.
옛날 사이트를 구경하고 싶다면? https://web.archive.org/
그래서 이런 웹 사이트에 사용자가 원하는 동작을 할 수 있게해주고, 사용자와 대화하는 식의 기능을 넣은 것을 웹 애플리케이션이라고 한다.
웹 애플리케이션은 웹 브라우저를 통해 접근이 가능한 애플리케이션이다.
정적인 웹사이트의 한계를 벗어나 다양한 동적인 응답을 웹 브라우저라는 소프트웨어를 통해 가능하게 한 애플리케이션.
아래 사진 참조.
이렇게 인스타그램처럼 상대방의 피드에 좋아요를 누르고, 댓글을 달고, 저장하는 등.
이런 기능들이 웹 애플리케이션 이라고 할 수 있겠다.
만약 인스타그램이 웹 사이트라고 한다면 사진도 링크를 타고 넘어가야 볼 수 있고, 댓글 또한 하이퍼텍스트를 누르면 링크를 타고 넘어가는 식으로 되겠지.
| 웹 애플리케이션의 장점 | 단점 |
|---|---|
| 브라우저를 통해 실행되기 때문에 설치나 다운로드가 필요 없다. | 인터넷이 없으면 사용이 안된다. |
| 업데이트 등의 유지관리가 쉽다. | 네이티브 애플리케이션에 비해 속도가 느리다. |
| 네이티브 애플리케이션에 비해 만들기가 비교적 간편하다. | 애플리케이션 스토어에서 관리되지 않기 때문에 사용자 접근성이 떨어진다. |
| 애플리케이션 스토어 승인이 필요 없다. | 질적으로나 보안상 위험에 노출되기가 쉽다. |
추가설명
장점
- 업데이트 등의 유지관리는 네이티브 애플리케이션처럼 새로 검수를 받고, 기다리는 과정이 없다는 의미.
단점
- 속도가 느리다는 의미는 이미 어플에 동작이나 파일이 저장이 되어있는 네이티브에 비하면 속도가 느리다는 의미이다.
- 접근성이 떨어진다는 것은 네이티브의 경우 스토어에 원하는 것을 검색하면 바로 나오지만 웹 애플리케이션의 경우 사이트의 주소를 알고있지 않은 이상 검색 엔진에 최소 1번에서 여러번 검색을 해서 들어와야하기 때문에 네이티브에 비교하면 접근성이 떨어진다.
- 보안에 대한 것은 네이티브처럼 검수를 하고 사용하는 것이 아니기 때문에 아무래도 위험성이 높아진다.
네트워크를 만드는 기술
LAN / WAN
컴퓨터를 인터넷과 연결할 때 선만 꽃는다고 연결되지는 않을 것이다.
보통 LAN선을 공유기에 꽃고 그 공유기가 본인이 쓰는 통신사에 등록이 되어있다면 연결이 될 것이다.
LAN과 WAN은 두 개 다 네트워크를 연결해주지만 차이가 있다.
LAN(Local Area Network) 은 좁은 범위에서의 연결된 네트워크고 WAN(Wide Area Network) 은 넓은 범위에서 연결된 네트워크다.
프로토콜(protocol)
프로토콜이란 어느 컴퓨터든 일관되게 네트워크를 사용할 수 있는 공통언어다.
만약 전자제품들의 전원코드가 다 다르다면? 아마 하나하나 새로 설치를 해야 할 것이다.
컴퓨터도 모두가 각기 다른 언어를 쓴다면 우리는 메모장에 저장이라도 해야겠지...
그래서 프로토콜이라는 공통언어를 쓰고, 헷갈리지 않게 하는 것.
IP
만약 ㅁㅁ 도서관에 가고 싶다면 그 도서관의 위치를 알아야 갈 수 있을 것이다.
네트워크 상에서는 ㅁㅁ도서관에 근무하는 A사서의 컴퓨터에 접속하려면 A사서의 PC를 가르키는 주소를 알아야 한다.
네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address) IP 주소 라고 한다.
IPv4란 Internet Protocol version 4 를 줄인말로, ip주소의 4번째 버전이라는 뜻이다.
위에 사진이 터미널에서 코드스테이츠 와 네이버의 IP주소다.
아래 사이트에 들어가면 본인 컴퓨터의 네트워크 접속 정보를 확인 할 수 있다.
https://ko.infobyip.com/
인터넷 보급률이 낮았던 초기에는 이 버전(IPv4, IP version 4)으로 네트워크에 연결된 PC에 주소를 할당하는 일이 가능했다. 그러나 개인 PC의 보급으로 전 세계의 누구나 PC를 이용해 인터넷에 접속하고, 각종 서비스를 위해 서버를 생산하면서 IPv4로 할당할 수 있는 PC가 한계를 넘어서게 되었고, 이를 위해 세상에 나오게 된 것이 IPv6(IP version 6) 이다. IPv6는 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현할 수 있다.
하지만 IPv6 가 등장하고 오랜 시간이 지났음에도 불구하고 이를 메인으로 사용하지 않는 이유는 아직도 IPv4가 사용 할만 하기 때문.
서브넷 마스크(subnet mask)
IPv4 주소는 OOO.OOO.OOO.OOO 의 형식으로 되어 있다.
10진수로 표기되어 있지만, 그 실체는 마침표로 구분된 4개의 8비트 필드(8자리 2진수 4개)로 되어있음.
IP 주소는 네트워크부와 호스트부로 나뉘는데, 네트워크부는 어떤 네트워크인지를 알 수 있는 정보이고, 호스트부는 그 네트워크 안의 특정 컴퓨터를 지칭하는 정보 이다.
IPv4 주소에서 네트워크부가 어디까지인지 나타내는 것이 서브넷 마스크이다.
IP 주소: 168.126.63.1
서브넷 마스크: 255.255.255.0
네트워크 주소: 168.126.63.0
브로드캐스트 주소: 168.126.63.255
TCP / UDP
TCP와 UDP는 IP 4계층 모델을 기준으로 상위에서 동작한다.
전송계층에 속하는 TCP와 UDP는 2계층에서 동작하는 IP 와 4계층에서 동작하는 애플리케이션(http 등)을 중개하는 역할을 담당.
| TCP | UDP | |
|---|---|---|
| 서비스타입 | 연결지향적 프로토콜 | 데이타그램 지향적 프로토콜 |
| 신뢰성 | 데이터 전송 표적 기기까지의 전송을 보장한다. | 표적 기기까지의 전송이 보장 되지 않는다. |
| 속도 | UDP와 비교했을 때 느리다. | TCP와 비교했을 때 빠르고, 단순하며 효율적인 속도. |
| 순서보장 | 순서가 보장 된다. | 순서가 보장 되지 않는다. |
웹애플리케이션에서 많이 사용하는 HTTP의 경우 모든 데이터를 제대로 송수신이 가능해야 하는 특성상, TCP를 사용한다.
TCP 3-way handshake 는 양 끝단의(end to end) 기기의 신뢰성 있는 데이터 통신을 위해, TCP 방식이 연결을 설정하는 방식
- (SYN): 처음으로, sender는 receiver와 연결 설정을 위해, segment를 랜덤으로 설정된 SYN(Synchronize Sequence Number)와 함께 보낸다. 이 요청은 receiver에게 sender가 통신을 시작하고 싶다고 알림.
- (SYN / ACK): receiver 는 받은 요청을 바탕으로 SYN/ACK 신호 세트를 응답한다. Acknowledgement(ACK) 응답으로 보내는 segment가 유효한 SYN요청을 받았는지를 의미한다.
- (ACK): 마지막 단계에서, sender는 받은 ACK를 receiver에게 전송을 하면서, 신뢰성 있는 연결이 성립되었다는 사실을 sender와 receiver 양쪽에서 알 수 있고, 실제 데이터 전송이 시작되게 된다.
UDP 는 애플리케이션 개발자들이 많이 사용한다. 아래 같은 상황 때문.
- 온라인 게임 LOL 을 플레이하던 중, 결정적 순간에 기술을 사용해야 하는데 항상 조금 지연시간이 있다. 근데 지연시간이 매번 조금씩 달라서 타이밍을 잡기가 힘들다.
- 카카오톡으로 보이스 톡을 하는데, 내가 말하고 상대방이 말 할 때마다 지연시간이 조금씩 발생하면서 싱크가 맞지가 않는다.
UDP를 사용하면?
- 애플리케이션의 정교한 제어가 가능하다: TCP의 경우 receiver가 전송 받을 준비가 될 때까지 세그먼트를 반복적으로 재전송한다. 실시간 전송에 대한 요구가 큰 애플리케이션 들은 높은 latency를 지양하므로 약간의 데이터 손실을 감수. 대신 개발자 스스로가 이를 보완하기 위해 애플리케이션에 추가 기능을 구현할 수 있다.
- 연결설정에 무관하다.: TCP 3-way handshake 가 없는 UDP는 예비과정 없이 바로 전송을 시작한다. 설정단계에서 발생하는 지연이 없는 만큼, 반응속도가 빠르다. 또한, TCP 가 신뢰성을 위해 많은 파라미터와 정보 전달이 필요함과 비교해 UDP는 연결설정 관리를 하지 않기 때문에 어떠한 파라미터도 기록하지 않는다. 이때문에 서버에서도 TCP와 비교에 더 많은 클라이언트를 수용이 가능하다.
PORT
TCP와 UDP 둘 다 포트번호를 사용한다.
포트번호는 대상 IP 기기의 특정 어플리케이션(connection endpoint)을 특정하는 번호다.
자주 사용 되는 Well-known port
| Port NO. | 프로토콜 name | Transport protocol | description |
|---|---|---|---|
| 80 | HTTP | TCP | 웹서버 접속 |
| 443 | HTTPS | TCP | 웹서버 접속(ssl) |
| 110 | POP3 | TCP | 메일 읽기 |
| 25 | SMTP | TCP | 메일서버간 메일 전송 |
| 22 | SSH | TCP | 컴퓨터 원격 로그인 |
| 53 | DNS | UDP | DNS 질의 |
| 123 | NTP | TCP | 시간 동기화 |
URL / DNS
URL(Uniform Resource Locator) 은 웹에 게시된 어떤 자원을 찾기 위한 브라우저에서 사용되는 메카니즘이다.
크롬 브라우저에 (window 사용자 기준)
file://localhost/C:\Users/username\Desktop\ 를 입력해보자.
username은 본인의 컴퓨터 계정 이름으로 변경해서 넣어줘야 한다.
그렇다면 본인의 컴퓨터 폴더로 들어가질 것이다.
URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함하고 있다. query는 웹 서버에 보내는 추가적인 질문.
http://www.google.com:80/search?q=Java 를 브라우저 검색창에 입력하면 구글에서 java를 검색한 결과가 나올 것이다.
브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다. URI는 URL을 포함하는 상위개념. 따라서, 'URL은 URI다.' 는 참이고, 'URI는 URL이다.' 는 거짓.
| 부분 | 명칭 | 설명 |
|---|---|---|
| file:// , http:// , https:// | scheme | 통신 프로토콜 |
| 127.0.0.1, www.google.com | hosts | 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP |
| :80, :443, :3000 | port | 웹 서버에 접속하기 위한 통로 |
| /search, /Users/username/Desktop | url-path | 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로 |
| q=Java | query | 웹 서버에 전달하는 추가 질문 |
Domain name
출처 : 코드스테이츠 유어클래스
웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소가 있다. 만약 IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 볼 수 있다.
여기에서 코드스테이츠의 IP주소는 3.35.107.186 이고, 도메인 이름은 codestates.com 이다.
그리고 주소창에 IP주소(3.35.107.186) 를 입력하면 코드스테이츠 창으로 이동할 수 있다.
웹을 구성하는 기술
출처 : https://server-talk.tistory.com/291
웹에서 제공되는 서비스는 주로 서비스를 이용하는 (클라이언트) 와 서비스 제공쪽(서버)으로 나뉜다. 이러한 구조를 클라이언트-서버 아키텍처라고 부른다.
웹 애플리케이션 아키텍처
웹 애플리케이션 아키텍처란? 애플리케이션 내부의 상호간에 소통하는지 설명하는 것.
우리가 웹사이트에 들어갈 때, 웹 애플리케이션은 이런식으로 작동한다는 것을 간단하게 그림으로 이해 할 수 있다.
보통 클라이언트는 사용자. 즉 컴퓨터를 이용하는 우리가 되겠다.
웹 애플리케이션은 인터넷에 공개되는 순간부터 글로벌 네트워크의 막대한 트래픽에 노출 될 수 있음.
- 신뢰성(reliability)
- 확장성(scalability)
- 보안성(security)
- 견고성(robustness)
위 4가지 요소를 고려해야함.
웹 애플리케이션의 요청흐름
https://naver.com로 접속한다고 생각해보자.
우리가 https://naver.com 이라고 입력하면 컴퓨터는 다음과 같은 흐름으로 동작한다.
- 입력받은 URL의 서버주소를 찾기 위해 DNS 서버에 요청을 보냄.
- IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보냄.(이때 한번이라도 방문을 한적이 있다면 캐시 메모리에 방문 기록이 있을테니 캐시 메모리에 있는 주소를 가져옴.)
- 웹서버에 요청이 도착.
- 웹서버는 저장소에 요청을 보내 페이지 관련 데이터들을 가져옴.
- 정보들은 가져오는 중에 비지니스 로직이 작용합니다.
- 비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있습니다.
- 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답합니다.
- 요청들이 브라우저에 응답으로 돌아왔을 때, web page 화면에서 출력됩니다.
모든 애플리케이션은 client-side와 server-side로 작동. 유저가 요청을 하면 크게 두 가지 프로그램이 작동함.
- 유저의 입력에 따라 브라우저에서 작동하는 프로그램 (위의 예제에서 naver 검색한 부분)
- HTTP 요청에 따라 요청 처리하는 프로그램 (naver를 입력하고 그 뒤에 작동하는 모든 부분)
Client-side 는 주로 HTML, CSS, and JavaScript 의 언어를 조합해 사용하여 개발을 진행. 개발되는 코드는 브라우저에 의해 분석되어 처리됨. 그리고 서버와의 소통은 HTTP 요청을 통해 이루어짐.
Server-side 는 주로 Java, Python, JavaScript, C#, PHP, Ruby on Rails 등 서버사이드에서 실행 가능하고 HTTP 요청에 응답할 수 있는 언어들이 사용됨.
웹 애플리케이션의 3단계 계층 구조
웹 애플리케이션의 구조는 다양하지만 크게 3단계로 볼 수 있다.
위 사진처럼 3단계로 나누어 지는 경우 Web Application Three 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 의 로직들은 어느 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장할지를 더 최적화 할 수 있음.
웹 애플리케이션 구현방식
- Single Page Application
- Microservice architecture
- Serverless Architectures
Single Page Application
웹 페이지에서 일부분만 바꾸고 싶다면?
Single Page Application 에서는 유저의 입력과 요청에 의한 콘텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고 현재 페이지에서 이루어짐.
또, 필수적인 요소만을 요청함. 그리고 이러한 점은 페이지가 새로 고침 되는 것을 방지해 유저 경험을 극대화시킴.이러한 기능을 위해 AJAX, Asynchronous JavaScript, 그리고 XML 이 주로 사용된다.
Microservice architecture
작고 가벼운 특정한 한가지 기능에 집중한 웹 애플리케이션을 의미한다.
각 애플리케이션의 기능 요소들은 상호간에 의존적으로 설계되지 않는다. 따라서 개발단계에서도 그리고 개발 완성이후로도 같은 개발 언어를 사용할 필요가 없다.
Serverless Architectures
개발자가 웹 애플리케이션의 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식.
SSR과 CSR
SSR = Server Side Rendering
출처 : https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8
렌더링이 서버에서 일어남.
서버는 즉시 렌더링 가능한 HTML파일을 만든다. HTML파일이 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어었기 때문에 HTML은 즉시 렌더링된다.
※ 하지만 Javascript가 읽히기 전이기 때문에 사이트 자체는 조작 불가능.
클라이언트가 javascfipt를 다운받는다. 다운 받아지고 있는 사이에 유저는 컨텐츠를 볼 수 있지만 사이트를 조작할 수 없다. 브라우저가 javascript프레임워크를 실행한다.
내가 조립식 컴퓨터를 사서 그쪽에서 조립을 다해서 보내주는 것. 완성본.
CSR = Client Side Rendering
출처 : https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8
렌더링이 클라이언트 쪽에서 일어남.
서버는 요청을 받으면, 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.
한마디로 내가 조립식 컴퓨터를 샀는데 그쪽에서 부품만 보내주고 내가 직접 조립을 해서 완성하는 방식인 것이다.
CSR / SSR 차이점
페이지가 렌더링되는 위치.
SSR은 서버에서 페이지를 렌더링. CSR은 브라우저에서(클라이언트) 페이지를 렌더링한다.
SEO란?
SEO(Search engine optimization) = 검색엔진 최적화
네이버나 구글에 키워드를 넣고 검색하면 대부분 상위 노출된 페이지를 먼저 클릭한다.
이때 검색엔진 결과 페이지에서 웹 사이트, 웹 페이지의 상위 노출도를 높이는 작업이 SEO다.
이런식으로 상위에 노출되게 해주는 것.
SSR은 언제쓰이는가?
SEO가 우선순위인 경우, 일반적으로 사용.
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR이 적합.
웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있다.
- 단점
자원이용이 서버에 집중되기 때문에 애플리케이션 유지비용이 높다.
일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있다.
CSR은 언제쓰이는가?
SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있다.
사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공함.
웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있다.
-단점
느린 렌더링 속도로 사용자 경험이 안 좋아 질 수 있음. 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 때문에 사용자에 따라서 경험이 달라질 수 있다.
위에서 설명했듯 search engine bots 와 상성이 안좋다. Javascript가 렌더링해야 하는 정보들은 Google 과 같은 search engine index에 포함이 안될 가능성이 매우 높다.
SSR 예시
네이버 블로그
네이버 공식블로그의 네트워크 탭을 보면 html 파일에 제목이 똑같이 담긴 것을 볼 수 있다.
따라서 구글, 네이버 같은 검색엔진 크롤러가 html에 접근하여 쉽게 내용을 가져 갈 수 있다.
블로그 같은 경우는 특히 검색엔진에 최대한 노출되는 게 유리하고, 다른 웹사이트에 비해 사용자와 상호작용이 많지 않기 때문에 SSR이 합리적인 선택으로 보인다.
CSR 예시
아고다
HTML이 빈 페이지이기 때문에 검색엔진 최적화(SEO)를 하기에는 SSR에 불리하다.
구글에서 이러한 부분을 보완하기 위해 삽입된 자바스크립트 코드를 분석, 실행시켜 크롤링을 하고 있다.
SSR에서는 서버에서 렌더링을 해야 하기 때문에 상호작용(interaction)이 많아질수록 서버에 부담이 많은 반면, CSR에서는 서버가 클라이언트에 필요한 데이터만 넘겨주기 때문에 부담이 적다. 그리고 SPA(Single Page Application)를 기반으로 화면의 일부만 받아온 데이터로 변경해 주기 때문에 빠른 렌더링으로 User Experience(사용자 경험)에 유리하다.
CORS (Cross-Origin Resource Sharing)
CORS란 프로토콜, 도메인, 포트번호를 비교해서 같은지 확인하는 보안기술.
한마디로 Origin이 같은지를 확인하는 것인데
Origin이란
출처 : https://evan-moon.github.io/2020/05/21/about-cors/
서버의 위치를 찾아가기 위해 필요한 가장 기본적인 것들을 합쳐 놓은 것.
앞에서 얘기한 프로토콜, 도메인, 포트번호가 여기에 포함이 된다.
origin이 달라도 내가 설정을 잡아주면 허용해 줄 수 있다.
HTTP
HTTP = HyperText Transfer Protocol.
HTML과 같은 문서를 전송하기 위한 Application Layer프로토콜이다.
전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답한다. HTTP는 특정 상태를 유지하지 않는 특징이 있다.
HTTP의 특징: Stateless(무상태성)
HTTP Messages
HTTP messages 는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다. HTTP messages에는 다음과 같은 두 가지 유형이 있다.
요청(Requests)
응답(Responses)
출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
요청과 응답은 유사한 구조를 가진다.
- start line : start line에는 요청이나 응답의 상태를 나타낸다. 항상 첫번째 줄에 위치. 응답에서는 status line이라고 부름.
- HTTP headers : 요청을 지정하거나 메세지에 포함된 본문을 설명하는 헤더의 집합.
- empty line : 헤더와 본문을 구분하는 빈칸
- body(본문) : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함함. 요청과 응답에 따라 선택적으로 사용. (필수는 아님)
사진에서 start line과 HTTP headers를 묶어 요청이나 응답에 헤드(head)라고 하고, payload는 body라고 이야기 함.
요청(Requests)
Start line
클라이언트가 서버에게 보내는 메세지.
- 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냄. 예를 들어 GET method는 리소스를 받아야 하고, POST method는 데이터를 서버로 전송한다.
- 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성. 이 요청 형식은 HTTP method 마다 다름.
origin 형식 : ?와 쿼리 문자열이 붙는 절대 경로이다. POST, GET, HEAD, OPTIONS 등의 method와 함께 사용.
POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0
absolute 형식 : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용.
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 authority component. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있다.
CONNECT developer.mozilla.org:80 HTTP/1.1
asterisk 형식 : OPTIONS 와 함께 별표() 하나로 서버 전체를 표현.
OPTIONS * HTTP/1.1 - HTTP 버전에 따라 HTTP message의 구조가 달라짐. 따라서 start line에 HTTP 버전을 함께 입력함.
Headers
요청의 Headers는 기본 구조를 따름. 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력. 값은 헤더에 따라 다르다. 여러 종류의 헤더가 있고, 다음과 같이 그룹을 나눌 수 있다.
- General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더.
- Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다.
- Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더.
Body
요청의 본문은 HTTP messages 구조의 마지막에 위치. 모든 요청에 body가 필요하지는 않음. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않는다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용. body는 다음과 같이 두 종류로 나눌 수 있다.
응답 (Responses)
Status line
- 현재 프로토콜의 버전(HTTP/1.1)
- 상태 코드 - 요청의 결과를 나타냅니다. (200, 302, 404 등)
- 상태 텍스트 - 상태 코드에 대한 설명
Headers
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있다. 대소문자 구분 없는 문자열과 콜론(:), 값을 입력한다. 값은 헤더에 따라 다르다. 요청의 헤더와 마찬가지로 몇 그룹으로 나눌 수 있다.
내용은 요청과 같다.
Body
응답의 본문은 HTTP messages 구조의 마지막에 위치. 모든 응답에 body가 필요하지는 않는다. 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다. 응답의 body는 다음과 같이 두 종류로 나눌 수 있다.
Statelsee 무상태성
가장 큰 특징이다.
출처 : 코드스테이츠 유어클래스
위 사진을 봤을 때 현재 클라이언트가 google.com을 입력한 것을 알 수 있음.
이 때 DNS가 도메인 주소를 IP주소로 변경해줌. DNS resolver에서 이전에 접속한 기록이 있는지 확인한다. 있다면 캐시 메모리에 저장이 되어 있을 것.
없다면 ISP NameServer에서 root 주소를 찾음. 이제 재귀과정을 통해 google의 IP주소를 찾게 됨.
그리고 get을 통해 IP주소를 입력하고 구글의 HTTP를 받음. HTTP resolver에서 HTTP를 찾고 진짜 google의 IP주소를 찾게됨. 이제 200(성공) 응답을 돌려줌.
.com 은 최상위 도메인으로 .com 서버에서 관리. .com서버에서 google이라는 도메인이 있는지 확인하는 것이다.
