대학 동기들과 2022/07/06 부터 HTTP 스터디를 진행하기로 하였다.
스터디를 위한 교재는 'HTTP 완벽 가이드', 일명 다람쥐 책
이다.
7,8월 두 달간 최대한 빠르게 1회독을 해보는 것을 목표로 진행한다.
1부인 <HTTP 웹의 기초> 파트에서는 4개의 장에 걸쳐 HTTP의 핵심 기술과 웹의 기초에 대해 다룬다.
1. HTTP 개관
HTTP에 대해 개략적으로 살펴본다.
2. URL과 리소스
통합 자원 지시자(Uniform Resource Locator,URL)의 포맷과 URL이 가리키는 리소스의 다양한 형식에 대해 상세히 다룬다. 더 진화한 지시자 URN에 대해서도 다룬다.
3. HTTP 메시지
HTTP 메시지가 어떻게 웹 콘텐츠를 전송하는지 다룬다.
4. 커넥션 관리
HTTP 커넥션 관리에 대한 오해와 잘못 작성된 규칙 및 동작들을 설명한다.
WWW(월드 와이드 웹)을 지탱하는 가장 중요한 기술 두 가지는 HTML과 HTTP라고 할 수 있다. 둘 중 하나라도 빠지게 된다면 웹은 성립하지 않는다. 즉, 이 둘만 있다면 어떻게는 웹이 구성된다는 소리이다.
지난 25년간 HTTP가 사용되어 왔으며, 여러 웹 개발을 위한 프레임워크들이 유행에 따라 바뀌어 왔지만,HTTP를 이용해 서버, 캐시, 프락시 등 모든 웹의 구성 요소들이 소통한다는 점은 변하지 않는다.
HTTP는 웹(WWW)에서 사용되는 통신 프로토콜이다. 주로 웹 브라우저와 웹 서버 사이에서의 쌍방향 통신에 사용된다.
HTTP는 신뢰성 있는 데이터 전송 프로토콜(TCP)
을 사용하기 때문에 온전하고, 순서가 제대로 된 패킷을 전송 받을 것을 보장한다.
클라이언트(웹브라우저)는 HTTP 객체(index.html)를 요청하면 서버에서는 요청받은 객체를 찾아 HTTP 응답으로 보내준다.
웹 서버는 웹 리소스를 관리하고 제공한다. 웹 리소스는 HTML파일, 사진, 동영상 파일 등의 정적 파일
일 수도 있고, 요청에 따라 다른 데이터를 보내주는 동적 컨테츠
일 수도 있다. 즉, 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.
주타입/부타입
으로 이루어진 문자열 라벨이다.URI(Uniform Resource Identifier, 통합 자원 식별자)
라고 한다. 인터넷 상의 우편물 주소 같은 것이다. 리소스를 고유하게 식별하고 위치를 지정할 수 있다.프로토콜, 서버 리소스
를 명시한다.URL 표준 포맷
http://www.joes-hardware.com/specials/saw-blade.gif
- URL의 첫 번째 부분은 Scheme(스킴) 이라고 부른다. 리소스에 접근하기 위해 사용되는프로토콜
을 서술한다. http, https 등
- 두 번째 부분은인터넷 주소
를 제공한다. www.joes-hardware.com 부분
- 마지막은 웹 서버의 리소스를 카리킨다. /specials/saw-blade.gif
콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 영향 받지 않는 유일무이한 이름 역할으 한다. URN은 독립적이기 때문에 리소스를 여기저기 옮겨도 영향 받지 않는다. 리소스 이름을 변하기 않게 유지하는 한 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제가 없다.
예를 들어, urn:ietf:rfc:2141
이라는 URN은 'RFC2141' 문서가 어디에 있든 해당 문서를 지칭하는데 사용될 수 있다.
아직 실험 단계이며 널리 채택되지 않았다. URN의 효율적인 동작을 위해서는 URN은 리소스 위치 분석을 위한 인프라 자원이 필요한데 없다.
요청명령
과 요청결과
로 이루어져 있다.
HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 이용해 상호작용이 이루어진다.
메소드
HTTP메서드 | 설명 |
---|---|
GET | 서버에서 클라이언트로 지정한 리소스를 보내라. |
PUT | 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라. |
DELETE | 지정한 리소스를 서버에서 삭제하라. |
POST | 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라. |
HEAD | 지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라 |
상태코드
HTTP상태코드 | 설명 |
---|---|
200 | 좋다. 문서가 바르게 반환되었다. |
302 | 다시 보내라. 다른 곳에 가서 리소스를 가져와라. |
404 | 없음. 리소스를 찾을 수 없다. |
모든 HTTP응답 메시지는 상태코드와 함께 반환된다. 또한 코드에 텍스트로 된 '사유 구절(reason phrase)'도 함께 보낸다. 하지만 사유 구절은 단순히 설명만을 위한 것이다. 즉, 응답 처리에는 상태코드가 사용된다. 상태 코드가 같으면 같은 처리를 한다.
메시지는 요청 메시지
와 응답 메시지
로 이루어진다. 사람이 읽을 수 있는 일반 텍스트로 이루어져 있으며, 세부분으로 이루어진다.
시작줄
메시지의 첫 줄.
요청 - 무엇을 해야 하는지
응답 - 무슨 일이 일어났는지
헤더
시작 줄 다음으로 오는 0개 이상의 헤더 필드
이름 : 값
으로 구성된다.
본문
어떤 종류의 데이터든 들어갈 수 있다. 시작줄과 헤더와는 달리 텍스트 뿐만 아니라 임의의 이진 데이터(이미지, 비디오, 오디오 트랙 등)를 포함할 수 있다.
HTTP는 네트워크 계층 중 애플리케이션 계층의 프로토콜이다. 즉, 애플리케이션 단의 역할이 아닌 네트워크의 핵심적인 동작 부분에 대해서는 하위 계층의 프로토콜에게 맡긴다. 해당 프로토콜은 TCP/IP 프로토콜이다. 처음 소개에서 설명한 것 처럼 TCP 프로토콜은 신뢰성 있는 연결을 보장
하는 프로토콜이며, 다음과 같은 것들을 보장한다.
TCP/IP 프로토콜은 패킷 교환 네트워크 프로토콜의 집합니다. 네트워크와 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해주는 역할을 한다.
실제 연결 부분은 더 하위 계층이 담당한다.
계층적으로 구성되어 각 계층은 다른 계층을 신경쓰지 않아도 된다.
애플리케이션 계층 (HTTP)
전송 계층 (TCP) - 포트 번호(각 프로그램 별로 사용 중)로 식별
네트워크 계층 (IP) - IP 주소로 식별
링크 계층 - MAC 주소로 식별
물리 계층
각 계층을 통해 연결을 할 때 IP주소와 포트번호로 연결을 하게 된다. 하지만 이런 IP주소와 포트번호를 어떻게 알 수 있을까?
바로 URL을 이용하여 알아낼 수 있다.
URL은 IP주소+포트 번호
또는 도메인 이름 또는 호스트 명
으로 이루어 진다. DNS를 통해서 호스트명으로부터 IP를 알 수 있다.
HTTP를 이용해 리소스를 받는 과정을 정리하면 다음과 같다.
HTTP 요청을 보낼 때 TCP 연결을 맺으며, 클라이언트에서 응답을 받으면 TCP 커넥션을 끊는다는 것을 알 수 있다. 여기서 HTTP의 무상태성이라는 특징을 알 수 있다.
HTTP 프로토콜은 계속해서 발전해 왔으며 수 많은 버전이 만들어졌다. 이 중에서 현재 주로 쓰이고 있는 버전은 HTTP/1.1과 HTTP/2.0 이다. 이 책에서는 주로 1.1 버전에 대해서 다루고 있는 것 같다.
HTTP/1.1 버전은 이전의 HTTP 프로토콜의 구조적 결함 교정, 성능 최적화, 잘 못된 기능 제거가 이루어진 버전이다.
HTTP/2.0 버전은 1.1 버전까지의 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계된 버전이다. 주요 특징은 다음과 같다.
HTTP/1.1의 문제점은 다음과 같다.
- 1개의 커넥션 당 1 개의 요청을 처리한다.
- HOL(Head Of Line) 블로킹이 발생할 수 있다.
같은 큐에 있는 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 문제를 말한다.- RTT(Round Trip Time)이 증가한다.
여러 요청을 동시에 보내지 못하기 때문에 3-way-handshake를 매번 다시 해야한다. 이는 RTT를 증가시키는 요인이 된다.- 헤더가 무겁다.
매번 서버 도메인에 관련된 쿠키 정보가 포함되어 보내지는데, 같은 정보를 반복적으로 실어 보내는 것은 비효율 적인다.
인터넷과 상호작용 할 수 있는 웹 애플리케이션의 종류는 다음과 같다.
프락시
클라이언트와 서버 사이에 위치한 HTTP 중개자이다. 웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소이다.
주로 보안을 위해 사용되며, 모든 트래픽 흐름 속에서 신뢰할만한 중개자 역할을 한다.
중개를 하며 요청과 응답을 필터링하는 역할을 한다.
6장에서 계속
캐시
많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
자주 사용하는 문서의 사본을 저장해 두는 특별한 종류의 HTTP 프락시 서버이다.
멀리 떨어진 웹 서버보다 근처의 캐시에서 문서를 다운 받을 수 있다.
7장에서 계속
게이트웨이
다른 애플리케이션과 연결된 중개자로 동작하는 특별한 웹서버이다. 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다.
게이트웨이는 언제나 자신이 리소스를 가지고 있는 진짜 서버인 것 처럼 요청을 다룬다. 이 말은 클라이언트는 게이트웨이와 통신하는지에 대한 여부를 알지 못한다는 뜻이다.
HTTP <--HTTP프로토콜--> HTTP/FTP 게이트웨이 <--FTP프로토콜--> FTP서버
터널
단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
터널은 두 커넥션 사이에서 RAW 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다. 주로 비HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용된다.
클라이언트 => SSL --터널시작-- HTTP with RAW SSL -- HTTP 커넥션 -- HTTP with RAW SSL -- 80번 포트 / 터널 끝 --> SSL / SSL커넥션 --> SSL --> 서버 443포트
에이전트
사용자 에이전트는 자동화된 HTTP 요청을 만드는 준지능적(semi-intelligent) 웹클라이언트 프로그램이다. 웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트이다. 지금까지는 웹 브라우저 하나만 봤지만, HTTP 트랜잭션을 일으키고 컨텐츠를 받아오는 자동화된 사용자 에이전트도 있다. 이러한 '스파이더'나 '웹로봇'과 같은 이름을 가지고 있다.