[HTTP 완벽 가이드] - HTTP 개관, URL 리소스

Lee Jeong Min·2022년 2월 18일
1

네트워크

목록 보기
9/17
post-thumbnail

네카라쿠배 프론트엔드 2기 동료들과 프론트엔드 스터디를 진행하기로 결정하여 이번주부터 HTTP 완벽가이드 스터디를 진행하게 되어 정리한 내용을 올리게 되었습니다.
Github Organization 주소: https://github.com/FEonTheBlock
Repository 주소: https://github.com/FEonTheBlock/HTTP-Perfect-Guide

1장 HTTP 개관

모든 웹 브라우저, 서버, 애플리케이션은 모두 HTTP를 통해 서로 대화한다.

HTTP: 인터넷의 멀티미디어 배달부

HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하여 전송 중 데이터가 손상되거나 꼬이지 않음을 보장한다.

웹 클라이언트와 서버

MS IE나 Google Chrome과 같은 웹 브라우저는 모두 HTTP 클라이언트이다.

리소스

웹 리소스란 웹에 콘텐츠를 제공하는 모든 것: .html, .word, .jpeg, .avi, 등등...

→ 리소스는 반드시 정적일 필요가 없고 동적 콘텐츠 또한 리소스가 될 수 있다.

미디어타입

HTTP는 웹에서 전송되는 객체에 MIME이라는 타입을 붙인다.

원래 이 MIME이라는 타입이 메일 시스템에서 메시지가 오갈 때 겪는 문제점을 해결하기 위해 사용했는데, 워낙 잘 작동되어 HTTP에서도 사용

MIME 타입은 주 타입부 타입으로 이루어진 문자열 라벨이다.

// image의 MIME타입 예시
Content-type: image/jpeg

// HTML 
text/html
// plain ASCII
text/plain
// JPEG
image/jpeg
// GIF
image/gif

URI

통합 자원 식별자이며 웹 서버 리소스의 이름을 지칭한다. 이 URI는 URLURN으로 나뉜다.

URL → 통합 자원 지시자로 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다.

// ex) 이 URL의 의미는 다음과 같다
http://www.joes-hardware.com/specials/saw-blade.gif

// 'http://': http 프로토콜 사용 (프로토콜, 스킴)
// 'www.joes-hardware.com': 이 주소로 이동하라. (서버, 서버의 인터넷 주소)
// '/spectials/saw-blade.gif': 이것 이라고 불리는 리소스를 가져와라. (리소스, 웹서버의 리소스)

오늘날 대부분의 URI는 URL이다.

URN → 유니폼 리소스 이름으로 콘텐츠를 이루는 한 리소스에 대해 리소스 위치에 영향 받지 않는 유일무이한 이름 역할

// 예시
urn:ietf:rfc:2141

트랜잭션

트랜잭션은 요청(클라이언트 → 서버)과 응답(서버 → 클라이언트)으로 구성된다.

요청의 예시)

GET /specials/saw-blade.gif HTTP/1.0
Host: www.joes-hardware.com

응답의 예시)

HTTP/1.0 200 OK
Content-type: image/gif
Content-length: 8572

메서드

HTTP 메서드: HTTP에서 사용하는 요청 명령, 흔히 사용하는 것으로 GET, PUT, DELETE, POST, HEAD(HTTP 헤더 부분만 보내라)가 있다.

상태코드

응답 메시지의 상태를 나타내는 세 자리 숫자 (200번대, 300번대, 400번대..)

웹페이지는 여러 객체로 이루어질 수 있다.

웹 페이지는 보통 하나의 리소스가 아닌 리소스의 모음이다.

→ HTML의 뼈대를 가져온 후, 첨부된 이미지, 그래픽 조각 등등 HTTP 트랜잭션들을 수행!

메시지

단순한 줄 단위의 문자열로 요청(클라 → 서버) 메시지, 응답(서버 → 클라) 메시지라고 부른다.

메시지의 구성

시작줄 - 헤더(:을 구분으로 하나의 이름과 하나의 값으로 구성) - 본문(요청의 본문은 웹 서버로 데이터를 실어 보내고, 응답의 본문은 클라이언트로 데이터를 반환)

TCP 커넥션

TCP/IP

HTTP는 애플리케이션 계층 프로토콜이라 네트워크 통신은 그 아래 계층인 TCP/IP에게 맡긴다.

  • 오류없는 데이터 전송
  • 순서에 맞는 전달 (데이터는 언제나 보낸 순서대로 도착)
  • 조각나지 않는 데이터 스트림 (언제든 어떤 크기로든 보낼 수 있다.)

→ TCP/IP는 TCP와 IP가 층을 이루는, 패킷 교환 네트워크 프로토콜의 집합이다.

접속, IP 주소 그리고 포트번호

TCP에서 커넥션을 맺기 위해 서버 컴퓨터에 대한 IP주소와 실행 중인 프로그램이 사용중인 포트번호가 필요하다. 즉 URL이 필요 ex) IP: 192. 168. 0. 1, Port: 80

호스트 명(www.naver.com)은 IP 주소에 대한 이해하기 쉬운 형태의 별명으로 이것이 DNS를 통해 IP로 변환!

HTML 리소스를 얻는 순서

  • 서버의 URL에서 호스트명 추출
  • 호스트명을 IP로 변환
  • URL에서 포트번호 추출
  • 주소를 기반으로 웹 서버와 TCP 커넥션
  • 요청
  • 응답
  • 응답 결과로 문서를 보여줌

프로토콜 버전

HTTP/0.9: 심각한 디자인 결함, 구식 클라이언트하고만 같이 사용, GET 메서드만 지원

HTTP/1.0: 처음으로 널리 쓰이기 시작한 HTTP 버전으로, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가

HTTP/1.0+: ‘keep-alive’, 가상 호스팅, 프락시 연결 지원을 (사실상의 표준으로) 포함한 버전

HTTP/1.1: 현재 HTTP 버전(HTTP 설계 구조적 결합 교정, 성능 최적화, 잘못된 기능 제거에 집중)

HTTP/2.0: HTTP1.1의 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜 기반으로 설계가 진행중인 프로토콜

웹의 구성요소

프록시

주로 보안을 위해 사용자를 대신하여 서버에 접근하며 요청과 응답을 필터링한다.

캐시

캐시 프락시는 성능 향상을 위해 자주 찾는 문서의 사본을 저장해둔다.

게이트웨이

다른 서버들의 중개자로 동작, 다른 프로토콜로 변환하기 위해 사용된다.

예시) HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP요청을 받고 FTP 프로토콜을 이용해 문서를 가져옴

터널

두 커넥션 사이에서 데이터를 열어보지 않고 그대로 전달해주는 역할을 한다.

예시) HTTP/SSL 터널은 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송하여 웹 트래픽만 허용하는 사내 방화벽 통과

에이전트

에이전트는 웹 브라우저, HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 자동화된 사용자 에이전트(스파이더, 웹로봇)를 말한다.

2장 URL과 리소스

URL은 인터넷의의 리소스를 가리키는 표준이름이다. 이를 사용하여 전자정보가 어디에 있고 어떻게 접근할 수 있는지 알려준다.

인터넷의 리소스 탐색하기

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키고, URI의 부분집합이다. 또한 HTTP, mailto(이메일), ftp(서버에 올라가 있는 파일), rtsp(비디오 서버에 호스팅하고 있는 영화)와 같이 다른 가용한 프로토콜을 사용할 수 있다.

URL이 있기 전 암흑의 시대 → 리소스에 접근하기 위한 방법이 너무 다르고, 복잡하였음

URL을 사용하여 하나의 인터페이스를 통해 일관된 방식으로 많은 리소스에 접근이 가능하다. 그리고 웹 브라우저는 HTTP 클라이언트이기에 URL을 다루고, 특정 리소스(예: 스킴)를 다루기 위해 별도의 애플리케이션을 사용하기도 한다.

URL 문법

<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
  • 스킴: 사용할 프로토콜로 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보(어떤 프로토콜을 사용하여 리소스를 요청할지 알려줌)
  • 호스트와 포트: 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알려줌(HTTP의 기본 포트는 80)
  • 사용자 이름과 비밀번호: FTP가 좋은 예시
    ftp:anonymous:my_password@ftp.prep.ai.mit.edu/pub/gnu → 여기서 @는 URL로 부터 사용자 이름과 비밀번호 컴포넌트를 분리한다.
  • 경로: 리소스가 서버의 어디에 있는지 알려준다. ‘/’ 문자를 기준으로 경로조각으로 나뉜다.
  • 파라미터: 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용, 또한 각 조각 자체 파라미터를 가질 수 있다.
    예시) ;type=d , http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
  • 질의 문자열: 웹 데이터베이스 게이트웨이에 질의하는데 사용, 편의상 많은 게이트웨이가 ‘&’로 나뉜 ‘이름=값' 쌍 형식의 질의 문자열을 원한다.
    예시) ?item=1200, ?item=1200&color=red&size=small
  • 프래그먼트: 리소스 내의 조각을 가리킬 수 있는 프래그먼트 컴포넌트를 제공한다. 일반적으로 HTTP 서버는 객체 일부가 아닌 전체만 다루기 때문에 클라이언트는 서버에 프래그먼트를 전달하지 않는다. → 브라우저(에이전트)가 식별자를 이용하여 객체 일부를 보여줌
    예시) #drillls

단축 URL

상대 URL

URL은 상대 URL과 절대 URL로 나뉜다.

  • 절대 URL: http부터해서 스킴, 호스트, 포트, 경로까지 다 적어주는것
  • 상대 URL: 기저(base)URL을 사용하여, URL의 일부를 가지고 리소스의 위치를 찾아냄. 상대 URL은 프래그먼트나 URL 일부이며 브라우저 같은 애플리케이션은 상대 URL과 절대 URL 간에 상호 변환을 할 수 있어야 한다. → 상대 url의 장점은 문서 집합의 위치를 변경하더라도 새로운 기저 URL에 의해 해석되어 위치 변경시에도 잘 동작한다.
    ex) ./hammer.html

URL확장

  • 호스트명 확장: 휴리스틱만 사용하여 호스트명에 ‘www.’와 ‘.com’을 붙여서 만든다.
  • 히스토리 확장: 과거 URL기록을 이용하여 URL 입력시, 완결된 형태의 URL을 보여준다.

안전하지 않은 문자

안전한 전송: 정보가 유실될 위험 없이 URL을 전송하는 것을 의미

→ 이를 위해 작고 일반적으로 안전한 알파벳 문자만 포함, 이스케이프 기능을 추가하여 안전하지 않은 문자를 안전한 문자로 인코딩할 수 있게 함

URL 문자 집합

7비트 US-ASCII 문자 집합을 사용

인코딩 체계

안전하지 않은 문자를 퍼센티지 기호(%)로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 ‘이스케이프' 문자로 바꾼다.

ex) ~%7, 빈 문자%20 , %%25

문자 제한

몇몇 문자는 URL내에 특별한 의미로 예약되어 있어 다른 용도로 사용하려면 그 전에 반드시 인코딩 해야한다.

  • %: 이스케이프 토큰
  • /: 경로 세그먼트를 나누는 용도
  • 그외: ., .., #, ?, ;, :, $, +, @ & =등등..

스킴의 바다

http: 일반 URl 포맷을 지키는 하이퍼텍스트 전송 프로토콜 스킴

https: 커넥션의 양 끝단에서 암호화하기 위해 넷스케이프세 개발한 보안 소켓 계층 (기본 포트값 443)

mailto: 이메일 주소를 가리킨다.

ftp: 파일 전송 프로토콜

rtsp, rtspu: 실시간 스트리밍 프로토콜

file: 주어진 호스트 기기에서 바로 접근할 수 있는 파일들을 나타냄

news: 특정 문서나 뉴스 그룹에 접근하는데 사용

telnet: 대화형 서비스에 접근

미래

URL은 인터넷 프로토콜 간에 공유할 수 있는 일관된 작명 규칙 제공 → 그러나 리소스가 옮겨지면 URL을 더는 사용할 수 없는 것이 단점!

그래서 URN(실제 객체의 이름 사용)이라는 새로운 표준 작업에 착수.

지속통합자원지시자(PURL)을 사용하면 URL로 URN기능 제공가능(리소스 위치 중개 서버를 두고, 해당 리소스를 우회적으로 제공)

→ 지속해서 새로운 표준이 적용되어 URL을 대체하려고 적용중이다.

profile
It is possible for ordinary people to choose to be extraordinary.

0개의 댓글