매주 화 금 20시, 일요일 14시 미팅
9월 6일(일) 첫 미팅 시작
해야할 일
subject 내용
번역본
42seoul-translation/subject_ko
HTTP 서버를 C++ 로 작성한다.
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성된다.
클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부른다.
클라이언트: 사용자 에이전트
사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구입니다. 이 역할은 주로 브라우저에 의해 수행된다. 엔지니어들과 자신들의 애플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램들은 예외이다.브라우저는 항상 요청을 보내는 개체로 서버가 될 수 없다.
웹 페이지는 하이퍼텍스트 문서로, 표시된 텍스트의 일부는 사용자가 사용자 에이전트를 제어하고 웹을 돌아다닐 수 있도록 새로운 웹 페이지를 가져오기 위해 실행(보통 마우스 클릭에 의해)될 수 있는 링크임을 뜻한다. 브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고 HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시한다.
웹 서버
통신 채널의 반대편에는 클라이언트에 의한 요청에 대한 문서를 제공하는 서버가 존재한다. 서버는 사실 상 논리적으로 단일 기계로 로드(로드 밸런싱) 혹은 그때 그때 다른 컴퓨터(캐시, DB 서버, e-커머스 서버 등과 같은)들의 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 소프트웨어의 복잡한 부분을 공유하는 서버들의 집합일 수도 있다.
프록시(proxy)
웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달한다. 여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않는다. 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시라고 부른다.
아래와 같은 다양한 기능을 수행할 수 있다.
HTTP 특징
간단하다.
HTTP는 사람이 읽을 수 있으며 간단하게 고안되었고 HTTP 메세지를 프레임별로 캡슐화하여 간결함을 유지한다. HTTP 메시지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽고 초심자의 진입장벽을 낮췄다.
확장성
HTTP 헤더는 확장하고 실험하기 쉽게 만들어져있다. 클라이언트와 서버만 헤더에 대하여 합의하면 새로운 기능 추가가 가능하다.
상태가 없지만 세션은 있다.
HTTP 는 stateless 로 상태를 저장하지 않아 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에 연결 고리가 없다.
이는 사용자가 페이지와 상호작용 해야할 때 문제가 된다. 하지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해준다. 헤더 확장성을 사용하여 동일한 문맥 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가된다.
HTTP와 연결
연결은 전송 계층(transfer layer)에서 제어되므로 근본적으로 HTTP 영역 밖이다. HTTP 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존한다.
HTTP 흐름
TCP 연결을 연다. TCP 연결은 요청을 보내거나(혹은 여러개의 요청) 응답을 받는데 사용된다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있다.
HTTP 메시지를 전송한다. HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직접 읽는게 불가능하지만 원칙은 동일하다.
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
서버에 의해 전송된 응답을 읽는다.
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
연결을 닫거나 다른 요청들을 위해 재사용한다.
HTTP Method
HTTP request
GET
, POST
같은 동사나 OPTIONS
나 HEAD
와 같은 명사입니다. 일반적으로, 클라이언트는 리소스를 가져오거나(GET
을 사용하여) HTML 폼의 데이터를 전송(POST
를 사용하여)하려고 하지만, 다른 경우에는 다른 동작이 요구될 수도 있습니다.http://
), 도메인 (여기서는 developer.mozilla.org
), 또는 TCP 포트 (여기서는 80
)인 요소들을 제거한 리소스의 URL입니다.POST
와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문과 유사한 본문.HTTP response
HTTP 헤더
HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줍니다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론 ':' 다음에 오는 값(줄 바꿈 없이)으로 이루어져있습니다. 값 앞에 붙은 빈 문자열은 무시됩니다.
rfc(Request for Comments) 7230 to 7235 (http 1.1)에 따라 작성해야 한다
RFC : 컴퓨터 네트워크 공학 등에서 인터넷 기술에 적용 가능한 새로운 연구, 혁신, 기법 등을 아우르는 메모
인터넷국제표준화기구(IETF)는 일부 RFC를 인터넷 표준으로 받아들이기도 한다.
RFC 번역 사이트
다음의 기능을 작성한다.
◦ Accept-Charsets
클라이언트 자신이 원하는 문자 집합
◦ Accept-Language
클라이언트 자신이 원하는 가능한 언어
◦ Allow
해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타낸다.
때론, HTTP 요청 메시지의 HTTP 메소드 options(웹서버측 제공 HTTP 메소드에 대한 질의) 에 대한 응답용 항목으로 사용된다.
Ex) Allow: GET, HEAD
405 Mrthod Not Allowed 에러와 함께 웹 서버에서 제공 가능한 HTTP 메서드는 GET, HEAD 뿐임을 알린다.
◦ Authorization
인증 토큰을 서버로 보낼 때 사용하는 헤더
"토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자" 를 전송
◦ Content-Language
해당 개체와 가장 잘 어울리는 사용자 언어
◦ Content-Length
◦ Content-Location
◦ Content-Type
◦ Date
◦ Host
◦ Last-Modified
◦ Location
◦ Referer
◦ Retry-After
◦ Server
◦ Transfer-Encoding
◦ User-Agent
◦ WWW-Authenticate
사용 가능한 함수