HTTP/네트워크 기초

KoEunseo·2022년 8월 4일
0

CS

목록 보기
1/8

Client Server Architecture

2티어 아키텍처라고도 불리는 설계 방식
상품정보와 같은 resource가 존재하는 곳(서버)과 resource를 사용하는 앱(클라이언트)을 분리시킨 것.
2티어 아키텍처에 데이터베이스가 추가되면 3티어 아키텍처라고 부른다.

클라이언트 :: 플랫폼에 따라 구분

웹 플랫폼에서의 클라이언트: 웹사이트, 웹앱. 브라우저를 통해 이용
스마트폰/태블릿 플랫폼
데스크탑 앱

서버 :: 용도에 따라 구분

파일서버: 파일을 제공하는 앱
웹서버: 웹사이트에서 필요로 하는 정보 제공하는 앱
메일 서버: 메일을 주고받을 수 있도록 도와주는 앱
데이터베이스 서버: 데이터제공자로서 일종의 서버


클라이언트-서버 통신과 API

프로토콜: 통신 규약
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP(프로토콜) 을 이용해서 통신한다.

주요 프로토콜

영어로 되어있기 때문에 어떤 단어의 약자인지, 무슨 뜻인지 생각해보면 이해하기 쉽다.

OSI 7 Layers ::

1계층: Physical, 물리계층. 전기신호를 주고받는다.(리피터: 전기신호를 증폭. 원래 신호로 복원한다.)
2계층: Data Link, 인접 시스템 간 데이터를 전송한다.(브리지)
3계층: Network, 단말 간 데이터 전송을 위해 최적의 경로를 제공한다.(라우터)
4계층: Transport, 종단시스템 간 투명한 데이터(신뢰성있는) 전송.
5계층: Session, 대화...라고 했는데ㅎ
6계층: Presentation, 표현계층. 데이터의 형식을 어떻게 표현하느냐 하는 문제. 보안관련.
7계층: Application, 응용계층. 사용자와 네트워크 간 연결, 데이터 생성.


7계층(응용계층) 프로토콜

HTTP(HyperText Transfer Protocol): html, json 등의 정보 주고받음
HTTPS : 뒤에 붙은 s가 Secure(보안)
FTP(File Transfer..): 말그대로 파일전송
SMTP(Simple Mail..): 아니지만 send mail 이라고 생각하면 이해하기 쉽다.
SSH: CLI환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP: 윈도우 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket: 실시간 통신, Push등을 지원하는 프로토콜

4계층(전송계층) 프로토콜

TCP: HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜. 연결형 서비스로 양방향으로 작동한다.
UDP: 비연결형 서비스. 단방향으로 작동하기 때문에 단순하고 빠르지만 신뢰성이 낮다.


API :: Application Programming Interface

라이브러리를 쉽게 이용할 수 있도록 규칙 등을 정의해놓은 인터페이스
인터페이스: 의사소통이 가능하도록 만들어진 접점

API 예시

요청: 아메리카노 두잔 헤이즐넛 시럽 넣고
url: /coffee/americano?quentity=2&syrup=hazelnet
HTTP API
메서드로 CRUD(Create, Read, Update, Delete)작업 요청

요청 URL 디자인 사용하는 메서드
모든 사용자 Read /users GET
새 사용자 Create /users POST
1번 사용자 정보 Update /users/1 PUT
1번 사용자 정보 Delete users/1 DELETE
1번 사용자 정보 Read /users/1 GET

브라우저의 작동 원리

file://127.0.0.1/Users/username/Desktop/

127.0.0.1은 로컬 PC를 나타낸다.

URL: Uniform Resource Locator

네트워크상에서 파일이 위치한 정보를 나타낸다.
scheme, hosts, url-path로 구분한다.

URI: Uniform Resource Identifier

url을 포함하는 상위 개념이 uri이다.
url + query, fragment

부분 명칭 설명
file://, http://, https:// scheme 통신 프로토콜
127.0.0.1, www.google.comhosts파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000port웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktopurl-path루트 디렉토리로부터 파일 위치까지 경로
q=JavaScriptquery웹 서버에 전달하는 추가 질문
(+) fragment: 일종의 북마크 기능. URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤 이동 가능.

IP address :: Internet Protocol address

네트워크에 연결된 특정 PC의 주소

nslookup codestates.com
코드스테이츠의 IPv4주소를 확인할 수 있다.

IPv4

IPv4는 8비트씩 총 32비트(4바이트)로 표시한다.
0.0.0.0 ~ 255.255.255.255 : 2의 32승인 43억개

  • localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC.
  • 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소. 서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근할 수 있다.
    IPv4 주소가 동나서 대신 IPv6로 가는 추세이다.

PORT

ip주소가 가리키는 pc에 접속할 수 있는 통로를 의미한다.
이미 사용중인 포트는 중복해서 사용할 수 없다.
포트번호는 0~65535까지 사용할 수 있다.
그중 0~1024번까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져있다.

  • 22 : SSH
  • 80 : HTTP
  • 443: HTTPS
  • 3000: 임시포트
    :80이나 :443은 생략이 가능하다.
    그외 포트는 반드시 URI에 포함되어야한다.

DNS :: Domain Name System

모든 IP주소가 도메인을 가지는 것은 아니다. 도메인은 일정기간동안 대여해 사용한다.
해당 도메인 이름과 매칭된 IP주소를 확인하는 서버를 DNS라고 한다.


크롬 브라우저 에러 읽기

전체 에러 메시지 목록
chrome://network-errors/

Error MessageDescription
"Aw, Snap!" ("앗, 이런!")Chrome 브라우저에서 페이지를 로드하는 데 문제가 발생했습니다.
ERR_NAME_NOT_RESOLVED호스트 이름(웹 주소)이 존재하지 않습니다.
ERR_INTERNET_DISCONNECTED사용 중인 기기가 인터넷에 연결되지 않았습니다.
ERR_CONNECTION_TIMED_OUT
ERR_TIMED_OUT
페이지에 연결하는 데 시간이 너무 오래 걸립니다. 인터넷 연결이 너무 느리거나, 웹페이지에 접속한 사용자가 많아서 발생할 수 있습니다.
ERR_CONNECTION_RESET웹페이지 연결을 방해하는 요소가 어딘가에 발생했습니다.
ERR_NETWORK_CHANGED웹페이지를 로드하는 중에 기기의 네트워크 연결이 해제되었거나, 새로운 네트워크에 연결되었습니다.
ERR_CONNECTION_REFUSED웹페이지에서 Chrome 브라우저의 연결을 허용하지 않았습니다.
ERR_CACHE_MISS웹페이지로부터 이전에 입력한 정보를 다시 한번 제출하도록 요청받았습니다.
ERR_EMPTY_RESPONSE웹페이지에서 데이터를 전혀 전송하지 않았으며, 데이터를 전송할 서버가 다운되었을 수 있습니다.
ERR_SSL_PROTOCOL_ERROR페이지에서 전송된 데이터를 Chrome 브라우저가 해석하지 못했습니다.
ERR_BAD_SSL_CLIENT_AUTH_CERT클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다.

HTTP 개요

HTTP Messages

클라이언트와 서버 사이에서 데이터가 교환되는 방식.
요청과 응답 두가지 유형이 있다.
HTTP Messages는 인터페이스에서 자동으로 완성되기 때문에 개발자가 작성할 필요가 거의 없다.

요청과 응답의 구조는 유사하다.
1. Head: start line
요청이나 응답의 상태를 나타낸다. 응답에서는 status line
2. Head: HTTP headers
요청을 지정하거나 메세지에 포함된 본문을 설명하는 헤더의 집합
3. empty line
헤더와 본문을 구분함
4. payload: body
요청 혹은 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용

Stateless

HTTP는 상태를 가지지 않는다. 클라이언트나 서버의 상태를 확인하거나 추적하지 않는다.

HTTP Requests

클라이언트가 서버에 보내는 메세지

Start line

1. HTTP method

수행할 작업이나 방식을 설명. (GET, PUT, POST..)
GET 메서드는 리소스를 받아야하고 POST 메서드는 데이터를 서버로 전송함

2. 절대 경로

  • origin 형식
    ?와 쿼리 문자열이 붙는 절대경로. GET POST HEAD OPTIONS 사용
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
  • absolute 형식
    완전한 URL형식. 프록시에 연결하는경우 대부분 GET메서드와 사용함
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
  • authority 형식
    도메인 이름과 포트 번호로 이루어진 URL 일부분. HTTP 터널을 구축하는 경우 CONNECT와 함께 사용할 수 있다.
CONNECT developer.mozilla.org:80 HTTP/1.1
  • asterisk 형식
    OPTIONS 와 함께 * 하나로 서버 전체 표현
OPTIONS * HTTP/1.1

3. HTTP 버전

HTTP 버전에 따라 HTTP message 구조가 달라지기 때문에 start line에 버전을 같이 입력해준다.

Headers

요청의 Headers는 기본구조를 따른다. 헤더이름, 콜론, 값을 입력한다. 값은 헤더에 따라 다르다.

  • General headers
    메세지 전체에 적용되는 헤더. body를 통해 전송되는 데이터와는 관련이 없다.
  • Request headers
    fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함한다. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화한다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다.
  • Representation headers
    (이전에는 Entity headers) body에 담긴 리소스의 정보를 포함하는 헤더

body

요청의 본문은 HTTP messages 구조의 마지막에 위치한다. 모든 요청에 바디가 필요한 건 아니다. 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다. POST 나 PUT과같은 일부 요청은 데이터를 업데이트하기 위해 사용한다.

  • Single-resource bodies: 헤더 두개로 정의된 단일 파일
  • Multiple-resource bodies: 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다. 보통 HTML form과 관련이 있다.

HTTP Responses

서버가 클라이언트에게 보내는 메세지

Status line

응답의 첫줄.

HTTP/1.1 404 Not Found
  1. 현재 프로토콜의 버전(HTTP/1.1)
  2. 상태 코드: 요청의 결과(200m 302, 404..)
  3. 상태 텍스트: 상태 코드에 대한 설명

Headers

요청 헤더와 동일한 구조.

  • General headers:
    메세지 전체에 적용되는 헤더. 바디를 통해 전송되는 데이터와는 관련이 없다.
  • Response headers:
    응답에 대한 부가적인 정보(위치, 서버 자체에 대한 정보)를 갖는다. Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공함
  • Representation headers:
    바디에 담긴 리소스의 정보(콘텐츠 길리, MIME타입..)를 포함.

Body

응답의 본문은 메세지 마지막에 위치한다. 역시 모든 응답에 필요하지는 않다.

  • Single-resource bodies:
    • 길이가 알려진 달일-리소스 본문은 두개의 헤더로 정의.
    • 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked로 설정되어있음. 파일은 chunk로 나뉘어 인코딩되어있다.
  • Multiple-resource bodies:
    서로 다른 정보를 담고 있는 body.

브라우저의 작동원리

AJAX

Asynchronous JavaScript XMLHttpRequest
비동기적으로 필요한 부분만 데이터를 받아와 화면에 보일 수 있다.

AJAX의 두가지 핵심 기술

Javascript와 DOM, Fetch
Fetch를 이용하면 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있다.
자바스크립트에서 돔을 사용해 조작할 수 있기 때문에 Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다.

XHR Fetch

Fetch 예제

fetch('http://52.78.213.9:3000/messages')
  .then (function(res) {
    return response.json();
  })
  .then(function(json){...})

Fetch이전에는 XHR(XML Http Request)를 사용했다.
XHR은 Cross-Site 이슈 등의 불편함이 있었음.

XHR 예제

var xhr = new XMLHttpRequest();
xhr.open('get', 'http://52.78.213.9:3000/messages');
xhr.onreadystatechange = function(){
	if(xhr.readyState !== 4) return;
	// readyState 4: 완료
	if(xhr.status === 200) {
        // status 200: 성공
		console.log(xhr.responseText); // 서버로부터 온 응답
	} else {
		console.log('에러: ' + xhr.status); // 요청 도중 에러 발생
	}
}
xhr.send(); // 요청 전송

AJAX 장단점

서버에서 HTML을 완성해서 보내주지 않아도 렌더링이 가능하다.
표준화된 방법.
유저 중심의 상호작용이 가능한 애플리케이션 개발
필요한 데이터를 텍스트 형태(JSON)로 보내면 되기 때문에 대역폭(데이터크기가)이 작다.

SEO에 불리하다. 사이트의 정보를 긁어가기 어려움.
뒤로가기 버튼 문제. AJAX는 이전 상태를 기억하지 않기 때문에 뒤로가기 기능을 구현하기 위해서 별도의 History API를 사용해야 한다.


SSR vs CSR

Server Side Rendering

웹페이지를 서버에서 렌더링한다.
서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링하기 때문에 서버사이드 렌더링이라고 한다.
브라우저의 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 수행한다.

  • SEO가 우선순위인 경우
  • 웹 페이지의 첫화면 렌더링이 빠르게 필요한 경우
  • 웹페이지가 사용자와 상호작용이 적은 경우

Client Side Rendering

클라이언트(대표적으로 웹 브라우저)에서 페이지를 렌더링한다.
브라우저의 요청을 서버로 보내면 서버는 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다. 이때 웹페이지ㅘ 함께 자바스크립트 파일을 보낸다.
브라우저의 다른 경로로 이동할 때 서버가 웹페이지를 다시 보내지 않는다. 브라우저가 경로에 따라 페이지를 다시 렌더링한다.

  • SEO가 우선순위가 아닌경우
  • 사이트에 풍부한 상호작용이 있는 경우. (빠른 라우팅)
  • 웹 애플리케이션을 제작하는 경우. (빠른 동적 렌더링)

0개의 댓글