HTTP
클라이언트-서버 콘셉트를 이해할 수 있다.
클라이언트-서버 아키텍처를 이해할 수 있다.
HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.
API의 개념을 이해할 수 있다.
브라우저의 작동 원리를 이해할 수 있다.
보이지 않는 곳의 통신을 이해할 수 있다.
URL과 URI의 차이를 이해할 수 있다.
IP 주소와 PORT에 대해 이해할 수 있다.
DNS와 IP 주소의 관계를 설명할 수 있다.
크롬 브라우저의 에러 메시지를 통해 문제를 파악할 수 있다.
보이는 곳의 통신을 이해할 수 있다.
AJAX의 개념을 이해할 수 있다.
SSR과 CSR의 차이를 이해할 수 있다.
HTTP messages의 구조를 설명할 수 있다.
HTTP의 동작 방식을 이해할 수 있다.
HTTP requests와 responses를 구분할 수 있다.
HTTP의 응답 메시지를 찾아볼 수 있다.
Self Guided Lessons (Advanced)
How the internet works
클라이언트-서버 아키텍처
2티어 아키텍처
- 서버 : 상품 정보 같은 리소스가 존재하는 곳
- 상품 목록..
- 클라이언트 : 리소스를 사용하는 앱
- 결제, 상품 조회, 기타 기능
- 플랫폼에 따라 구분됨
-> 브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라 부름
-> iOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼
-> 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱
3티어 아키텍처 -기존 2티어 아키텍처에 데이터베이스가 추가된 형태
- 데이터베이스 : 리소스를 저장하는 공간
- 창고
- 파일 서버 - 파일을 제공하는 앱
- 웹 서버 - 웹사이트에서 필요로 하는 정보들을 제공하는 앱
- 메일 서버 - 메일을 주고 받을 수 있도록 도와주는 앱
- 데이터베이스
HTTP를 이용한 클라이언트-서버 통신과 API
클라이언트와 서버 간의 통신은 요청과 응답으로 구성됨
프로토콜
통신 규약, 즉 약속입니다. 손님이 주문을 받는 사람에게 대뜸 찾아가, 외계어로 주문을 할 수 없듯, 주문을 하기 위해서는 꼭 지켜야 하는 약속이 몇가지 존재합니다.
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눕니다. HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부릅니다.-"규약"HTTP 만의 규칙이 있음
OSI 7 Layers
-해당 프로토콜이 어떤 계층(layer)에 속해있는지
API(Application Programming Interface)
Interface의 사전적 의미 "의사소통이 가능"하도록 만들어진 "접점" 이 의미에 따메뉴판도 인터페이스
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공 / 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스
인터넷에 있는 데이터를 요청할 때: HTTP라는 프로토콜을 사용, 주소(URL, URI)를 통해 접근
Query String
HTTP 요청에는 메소드라는 것이 존재
GET, POST, PUT(또는 PATCH), DELETE
HTTP 메소드는 리소스를 이용해 하려는 행동에 맞게 적절하게 써야 한다
GET
-특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.
HEAD
-GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
POST
-특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.
PUT
-목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.
DELETE
특정 리소스를 삭제합니다.
MDN "HTTP 요청 메서드"
URL과 URI
URI는 URL을 포함하는 상위개념
URL : Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보
URI : Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함
브라우저의 검색창을 클릭하면 나타나는 주소
부분 명칭 설명
file://, http://, https:// scheme 통신 프로토콜
127.0.0.1, www.google.com hosts 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000 port 웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktop url-path 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로
q=JavaScript query 웹 서버에 전달하는 추가 질문
IP와 포트
IP address(Internet Protocol address, IP 주소) : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
네 덩이의 숫자로 구분된 IP 주소체계를 IPv4라고 합니다. IPv4는 Internet Protocol version 4의 줄임말로, IP 주소체계의 네 번째 버전을 뜻합니다.
localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC
0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소입니다. 서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근할 수 있습니다.
IPv6(IP version 6) : 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현
PORT(포트) : 그 주소에 진입할 수 있는 정해진 통로
22 : SSH
80 : HTTP
443: HTTPS
도메인과 DNS
Domain name
웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소, 한눈에 파악하기 힘든 IP 주소를 보다 분명하게 나타낼 수 있습니다.
(ex) IP 주소는 3.34.153.168 이고, 도메인 이름은 codestates.com)
DNS
모든 도메인 이름은 일정 기간 동안 대여하여 사용
Domain Name System의 줄임말로, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템
만약 브라우저의 검색창에 naver.com을 입력한다면, 이 요청은 DNS에서 IP 주소(125.209.222.142)를 찾습니다. 그리고 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 합니다.
크롬 브라우저 에러
Aw, Snap! (앗, 이런!)
HTTP Messages
HyperText Transfer Protocol의 줄임말
HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜
클라이언트와 서버 사이에서 데이터가 교환되는 방식
HTTP의 주요 특징: Stateless(무상태성)
ex)만약 쇼핑몰에서 카트에 담기 버튼을 눌렀을 때, 카트에 담긴 상품 정보(상태)를 저장해둬야 합니다. 그러나 HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않습니다
요청(Requests)
클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지
start line : 요청이나 응답의 상태 나타냄
항상 첫 번째 줄에 위치.
- 첫번째 HTTP method - 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명
- 두번째로 오는 요청 타겟 - 주로 URL이나 URI 또는 프로토콜, 포트, 도메인의 절대 경로, 요청 컨텍스트에 의해 작성됨. 이 요청 타겟포맷은 HTTP method 마다 다름(origin,absolute,authority,asterisk)
- 마지막으로 HTTP 버전
HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
대소문자 구분 없는 문자열과 콜론(:), 값을 입력
General 헤더: 메시지 전체에 적용됨(ex) Via)
Request 헤더: 요청 내용을 수정 -> 요청의 내용을 좀 더 구체화 시킴(User-Agent(en-US), Accept-Type, Accept-Language), 컨텍스를 제공(Referer), 조건에 따른 제약 사항을 가함(If-None)
Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.
empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.
Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일
Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련
응답(Responses)
요청에 대한 서버의 답변
Status line : 상태 줄
1. 프로토콜의 버전(보통 HTTP/1.1)
2. 상태 코드 - 요청의 성공여부 (200, 302, 404 등)
3. 상태 텍스트 - 상태 코드에 대한 짧은 설명
Headers
Body
모든 응답에 본문이 들어가지는 x. 201, 204과 같은 상태 코드를 가진 응답에는 보통 본문이 없다
이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)
길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.
서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듬
SPA를 만드는 기술: AJAX
SSR
Server Side Rendering
브라우저가 서버의 URI로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송. 그리고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링됨. 서버에서 웹 페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링했기 때문에 Server Side Rendering
ex) SEO(Search Engine Optimization) 가 우선순위인 경우, 웹페이지가 사용자와 상호작용 적은 경우
CSR
Client Side Rendering
SSR의 반대
웹 개발에서 사용하는 대표적인 클라이언트는 웹 브라우저
웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청
브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링합니다. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일(브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리)
ex) SEO 가 우선순위가 아닌 경우, 사이트에 풍부한 상호 작용이 있는 경우, 웹 애플리케이션을 제작하는 경우
