HTTP와 네트워크 기본

const_yang·2021년 10월 14일

브라우저 작동 원리

클라이언트(웹)-서버(서버) 아키텍처: 2 Tier 아키텍처라고도 한다.
웹은 "요청"하고 서버는 "응답"한다.

클라이언트(웹)-서버(리소스전달)-데이터베이스 아키텍처: 3 Tier 아키텍처
보통 서버는 리소스를 전달하고 데이터베이스라는 창고에 리소스가 저장되어 있다.

프로토콜
서버와 클라이언트 간의 규약; 약속; (ex: HTTP)
API
클라이언트가 서버의 리소스를 요청할 수 있도록 만들어 놓은 Application Programming Interface.
인터페이스란 상호 의사 소통을 위한 접점이라고 생각하면 된다.
서버는 리소스를 어떻게 전달하는지 API 문서를 작성하여 클라이언트가 활용할 수 있도록 한다. (보통 HTTP 프로토콜을 사용하며, 주소 (URL, URI)를 통해 접근할 수 있다.
HTTP API 디자인:
Creat, Read, Update, Delete (CRUD) 행동에 따라 메소드를 사용하는 것이 Best Practice이다

URL & URI

URL
Uniform Resource Locator의 줄임말. scheme + hosts + url-path로 구성.
scheme: 통신 방식 (프로토콜) 결정. 일반적인 웹브라우저에서는 http(s) 사용.
hosts: 웹서버 이름, 도메인, IP
url-path: 루트 디렉토리부터 이미지, 동영상 등의 경로와 파일명
URI
Uniform Resource Identifier의 줄임말. scheme + hosts + url-path + query(bookmark)

query: 웹 서버에 보내는 추가적인 질문

IP & Port

IP: Internet Protocol (IPv4: 네 덩이 숫자로 구분된 IP)

localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC
0.0.0.0, 255.255.255.255 : broadcast address

Port: IP 주소가 가리키는 PC에 접속할 수 있는 통로

22 : SSH
80 : HTTP
443 : HTTPS

DNS(Domain Name System)

IP 주소(도로명주소)와 도메인(서울시청)의 매칭하는지 확인

HTTP messages

Request Response 두 가지 종류의 메시지가 있다. 두 종류 모두 유사한 구조로 되어있다.

메시지 구조

start line(status line): 요청 또는 응답의 상태
HTTP header: 요청을 지정하거나 본문(body)을 설명
empty line: 헤더와 본문을 구분
body: 요청 또는 응답과 관련한 데이터 또는 문서

보통 1, 2번을 head, 4번을 body라고 한다.

Request 메시지

1. start line:
세 가지 요소로 구성

1) HTTP method: GET, PUT, POST, HEAD, OPTIONS 등

2) 요청 컨텍스트:

origin: ?와 쿼리 문자열이 붙는 절대 경로
POST / HTTP 1.1
GET /background.png HTTP/1.0
absolute: 완전한 URL 형식, 프록시에 연결 요청
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
authority: 도메인 이름과 포트 번호
CONNECT developer.mozilla.org:80 HTTP/1.1
asterisk: OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현
OPTIONS 별표 HTTP/1.1

3) HTTP 버전

2. Headers
헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값

1) General header:
메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더

2) Request headers:
fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있음.

3) Representation headers:
body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함

3. Body
Single-resource bodies(단일-리소스 본문)
:헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일

Multiple-resource bodies(다중-리소스 본문)
: 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지님

Responses 메시지

1. status line:
세 가지 요소로 구성
HTTP/1.1 404 Not Found.
1) 현재 프로토콜의 버전(HTTP/1.1)
2) 상태 코드 - 요청의 결과 (200, 302, 404 등)
3) 상태 텍스트 - 상태 코드에 대한 설명

2. Headers
1) General headers
메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더

2) Response headers
위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더

3) Representation headers
body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더

3. Body
모든 응답에 body가 필요하지는 않다 (201, 204와 같은 상태 코드에는 body 필요없음).

Single-resource bodies(단일-리소스 본문)
: 길이가 알려진 단일-리소스 본문.Content-Type, Content-Length로 정의
: 길이를 모르는 단일 파일로 구성된 단일-리소스 본문. Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩

Multiple-resource bodies(다중-리소스 본문)
:다른 정보를 담고 있는 body

Stateless

HTTP는 항상 Stateless (무상태성)이다. 상태를 가지고 있지 않다.

DNS

Domain Name System

사람들이 기억하기 쉬운 도메인 주소를 IP 주소로 변환하는 시스템

도메인 이름의 구조

jonghwan.nice.com.

jonghwan: Sub domain
nice: second-level domain
com: top-level domain
마지막 . : root domain (보통 생략되어 있음)

DNS 과정

1) jonghwan.nice.com.을 입력하면
2) DNS 재귀확인자 (resolver)가 root 서버에게 문의
3) root 서버가 TLD (top-level domain) 서버의 주소로 응답
4) DNS 재귀확인자가 .com TLD 서버에게 문의
5) .com TLD 서버가 권한있는 서버의 주소로 응답
6) DNS 재귀확인자가 권한있는 서버에게 문의
7) 권한있는 서버가 IP 주소로 응답
8) DNS 재귀확인자가 클라이언트에게 IP 주소 전달
9) 클라이언트가 IP 주소를 서버에 요청
10) 서버가 클라이언트에게 해당 IP 주소의 웹페이지로 응답