HTTP 프로토콜이란?
HTTP(HyperText Transfer Protocol)란 인터넷에서 하이퍼텍스트 문서인 HTML로 만든 웹페이지를 전송하기 위해 사용되는 어플리케이션 계층 프로토콜입니다. HTTP는 주로 전송 계층의 TCP를 사용하여 데이터를 교환하며 기본적으로 80번 포트를 사용합니다.
HTTP 프로토콜의 특징
웹 페이지는 객체(objects)들로 구성 됩니다. -> 객체는 HTML 파일, JPEG 이미지, java applet, 오디오 파일 등입니다. 웹 페이지는 보통 참조 객체들이 포함된 기본 HTML 파일이며 각 객체는 URL로 참조합니다.
HTTP는 TCP를 사용 합니다. -> 클라이언트는 소켓을 만들고 서버의 80번 포트에 TCP 연결 요청 후에 서버가 요청을 수락하면 브라우저와 서버 사이에 HTTP 메시지를 교환하고 TCP를 닫는 과정을 수행합니다.
HTTP는 비상태(stateless) 입니다. -> 상태(state)를 유지하는 프로토콜은 복잡하며 서버나 클라이언트가 다운되면 정보의 일관성을 잃게 되므로 서버는 클라이언트의 과거 요청에 대한 정보를 유지하지 않습니다. 그래서 쿠키(cookie) 혹은 웹 캐시를 사용합니다.
최근에는 대부분 지속 연결(persistent) HTTP을 사용 합니다. -> 지속 연결을 통해 한번의 TCP 연결을 통해 여러 객체를 전송합니다.
비지속 연결 HTTP vs 지속 연결 HTTP
비지속 연결(non-persistent) HTTP
비지속 연결은 한 TCP 연결을 통해 최대 한 객체만 전송하고 그 후 연결을 해제하는 과정을 수행합니다. 그러므로, 여러 객체를 받으려면 여러 연결이 필요합니다.
비지속 연결 HTTP의 과정
1a. HTTP 클라이언트가 HTTP 서버에게 연결을 요청합니다.
1b. HTTP 서버는 80번 포트에서 TCP 연결을 기다림. 연결을 "수락"하고 클라이언트에게 알립니다.
2. HTTP 클라이언트는 TCP 소켓을 통해 HTTP 요청 메시지를 보냄. 이 메시지는 클라이언트가 someDepartment/index.html이라는 객체가 필요함을 알려줍니다.
3. HTTP 서버는 요청 메시지를 받고, 응답 메시지에 요청된 객체를 담아서 소켓으로 보냅니다.
4. HTTP 서버는 TCP 연결을 닫습니다.
5. HTTP 클라이언트는 html 파일이 포함된 응답 메시지를 받아서 html을 표시. html 파일을 파싱하여 10개의 jpeg 객체가 참조됨을 알게 됩니다.
6. 1-5 과정이 10개의 jpeg 객체에 대해 각각 수행됩니다. (비 지속 연결이므로 연결하고 끊고를 반복)
RTT(round-trip time) -> 작은 패킷이 클라이언트에서 서버까지 갔다가 돌아오는 데에 걸리는 시간
비지속연결 HTTP의 응답 시간
1. TCP 연결 설립에 RTT가 소요
2. HTTP 요청과 HTTP 응답의 처음 몇바이트가 돌아오는 데에 RTT 소요
3. 파일 전송 시간
-> 총 걸리는 시간 = 2RTT + 파일 전송 시간
-> 즉, 데이터를 주고받을 때 마다 연결 및 연결 해제를 하기 때문에 비지속 연결 HTTP는 시간적 낭비가 많습니다.
지속 연결(persistent) HTTP
지속 연결은 한 TCP 연결을 통해 여러 객체를 전송합니다 (최근에는 대부분 지속연결을 사용)
-> 비지속 연결 HTTP를 사용하면 객체당 2RTT가 필요하고, 각 TCP 연결에 따른 OS의 과부하, 브라우저는 참조된 객체를 가져오기 위해 TCP 여러 개를 병렬적으로 연결하게 되는 단점이 생깁니다.
지속 연결 HTTP의 특징
- 서버는 응답을 보내고도 연결을 닫지 않습니다. (여러번의 전송을하고 데이터를 받을때에도 한번의 연결만 해도 됩니다.)
- 같은 클라이언트/서버 사이의 이후 HTTP 메시지들은 이 연결을 통해 전송합니다.
- 클라이언트는 참조된 객체를 발견하면 바로 요청합니다.
- 모든 참조 객체들에 대해 RTT 정도만 필요합니다.
HTTP 요청(request) 메시지
두 종류의 HTTP 메시지: 요청(request), 응답(response)
HTTP 요청(request) 메시지: ASCII (사람이 읽을 수 있는 포맷)
각각의 라인의 끝에는 carriage return으로 라인을 끝낸다는 표시를 해주어야 합니다.
request line -> (메소드 종류 GET, POST 등) (request URL) (HTTP version)
header lines -> 다양한 헤더 필드들이 존재합니다. HOST(URL), User-Agent(웹 브라우저 종류), Accept(받아들일 수 있는 포멧), Accept-Language(받아들일 수 있는 언어), Accept-Encoding(받아들일 수 있는 인코딩 형식), Accept-Charset(받아들일 수 있는 캐릭터셋), Keep-Alive(지속 연결일 때 connection이 얼마동안 지속될 수 있는지), Connection(지속연결 여부) 등등이 있습니다.
header의 끝에는 carriage retrn이 존재하고, 그 아래에는 body가 올 것입니다.
메소드 종류
HTTP/1.0
- GET
- POST
- HEAD
-> 요청된 객체의 헤더만 전송. (버전, 상태 등의 헤더 필드 확인 목적)
HTTP/1.1
- GET, POST, HEAD
- PUT, PATCH -> PUT은 객체 Body 파일을 URL 필드에 지정한 경로상에 업로드, PATCH는 일부분만 업데이트
- DELETE -> URL 필드에 저장된 파일을 지웁니다.
- TRACE, CONNECT, OPTIONS
HTTP 응답(response) 메시지
status line -> (protocol) (status code) (status phrase)
header lines -> Date(날짜), Server(서버 종류), Last-Modified(요청한 객체가 마지막으로 언제 수정되었는지), ETag(웹 캐시 유효성 검사), Accept-Ranges(클라이언트가 서버에 대한 객체를 부분 요청 할 때 사용), Content-Length(객체 길이), Keep-Alive(지속 연결일 때 connection이 얼마동안 지속될 수 있는지), Connection(지속연결 여부), Content-Type(자원의 형식)
Carriage return
Body(데이터, e.g. 요청된 HTML 파일, 이미지)
HTTP 응답(response)의 상태 코드(status codes)
상태 코드가 서버에서 클라이언트로의 응답 메시지 첫 번째 줄에 표시됩니다.
200 OK -> 요청이 성공했고, 요청된 객체가 이 메시지 뒤에 보내집니다.
301 Moved Permanently -> 요청된 객체가 이동되었고, 새 위치는 이 메시지 뒤에 표시되어 있습니다. (URL redirection)
400 Bad Request -> 서버가 요청을 이해할 수 없습니다.
404 Not Found -> 요청한 문서가 서버에 없습니다.
505 HTTP Version Not Supported -> HTTP 버전이 안맞습니다.
-> 일반적으로 400번대는 클라이언트의 문제, 500번대는 서버의 문제입니다.
업로드 방식
POST 방식
- 웹 페이지에는 종종 서식 입력이 포함되어 있습니다.
- 입력은 개체의 body를 통해서 서버로 업로드 됩니다. (데이터가 복잡할 경우 POST 방식으로 body에 추가)
URL 방식
- GET 방식을 사용합니다.
- 입력은 요청 라인의 URL 필드를 통해 업로드 됩니다
e.g) www.somesite.com/animalsearch?monkeys&banana (데이터가 간단할 경우 GET 방식의 URL에 추가)
References
James Kurose, Keith W Ross, "Computer Networking: A Top-Down Approach", Pearson(2016)
