HTTP 프로토콜이란?

 

1. HTTP 프로토콜이란?

 

HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.

애플리케이션 레벨의 프로토콜로 TCP/IP위에서 작동한다.

HTTP는 어떤 종류의 데이터든지 전송할 수 있도록 설계돼 있다. 

HTTP로 보낼 수 있는 데이터는 HTML문서, 이미지, 동영상, 오디오, 텍스트 문서 등 여러종류가 있다.

하이퍼텍스트 기반으로(Hypertext) 데이터를 전송하겠다(Transfer) = 링크기반으로 데이터에 접속하겠다는 의미이다.

 

 

1.1 작동방식

 

HTTP는 서버/클라이언트 모델을 따른다. 

클라이언트에서 요청(request)를 보내면 서버는 요청을 처리해서 응답(response)한다.

 

 

클라이언트 : 

서버에 요청하는 클라이언트 소프트웨어(IE, Chrome, Firefox, Safari ...)가 설치된 컴퓨터를 이용한다. 

클라이언트는 URI를 이용해서 서버에 접속하고, 데이터를 요청할 수 있다.

 

서버 : 

클라이언트의 요청을 받아서, 요청을 해석하고 응답을 하는 소프트웨어가 설치된 컴퓨터(Apache, nginx, IIS, lighttpd) 등이 서버 소프트웨어다.

 

웹서버는 보통 표준포트인 80번 포트로 서비스한다.

 

1.2 Connectionless & Stateless

 

HTTP는 Connectionless 방식으로 작동한다. 

서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버린다. 

기본적으로는 자원 하나에 대해서 하나의 연결을 만든다. 

이런 작동방식은 각각 아래의 장점과 단점을 가진다

 

장점 : 

불특정 다수를 대상으로 하는 서비스에 적합한 방식이다. 

수십만명이 웹 서비스를 사용하더라도 접속유지는 최소한으로 할 수 있기 때문에, 더 많은 유저의 요청을 처리할 수 있다.

 

단점 : 

연결을 끊어버리기 때문에, 클라이언트의 이전 상태를 알 수가 없다. 

이러한 HTTP의 특징을 stateless라고 하는데, Connectionless 로 부터 파생되는 특징이라고 할 수 있다. 

클라이언트의 이전 상태 정보를 알 수 없게 되면, 웹 서비스를 하는데 당장에 문제가 생긴다. 

클라이언트가 과거에 로그인을 성공하더라도 로그 정보를 유지할 수가 없다. HTTP는 cookie를 이용해서 이 문제를 해결하고 있다.

 

Cookie는 클라이언트와 서버의 상태 정보를 담고 있는 정보조각이다. 

로그인을 예로 들자면, 클라이언트가 로그인에 성공하면, 

서버는 로그인 정보를 자신의 데이터베이스에 저장하고 동일한 값을 cookie형태로 클라이언트에 보낸다. 

 

첫 요청 시 :

클라이언트 로그인 성공 then 서버 로그인정보를 자신의 DB에 저장 

(서버는 cookie를 키로하는 값을 데이터베이스에 저장하는 방식으로 "세션"을 유지한다)

and then return 쿠키 to 클라이언트 

 

클라이언트는 다음 번 요청때 cookie를 서버에 보내는데, 

서버는 cookie 값으로 자신의 데이터베이스를 조회해서 로그인 여부를 확인할 수 있다. 

 

두번쨰 요청 시 :

클라이언트 request(cookie) to server then 서버는 자신의 DB 조회 and then 로그인여부 확인

 

 

1.3 URI(Uniform Resource Identifiers)

 

 

클라이언트 소프트웨어(IE, Chrome, Firefox, Safari ...)는 URI를 이용하여 자원의 위치를 찾는다. 

 

URI는 HTTP와는 독립된 다른 체계다. 

HTTP는 전송 프로토콜이고, URI는 자원의 위치를 알려주기 위한 프로토콜이다. 

 

Uniform Resource Identifiers 의 줄임로, World Wide Web 상에서 접근하고자 하는 자원의 위치를 나타내기 위해서 사용한다. 

자원은 HTML문서, 이미지, 동영상, 오디오, 텍스트 문서 등 모든 것이 될 수 있다. 

 

웹페이지의 위치를 나타내기 위해서 사용하는 https://www.dcinside.com/index.php 등이 URI의 예다.

 

https://www.dcinside.com/index.php 를 분해하여 분석해보자.   https : 자원에 접근하기 위해서 https 프로토콜을 사용한다.   www.dcinside.com : 자원의 인터넷 상에서의 위치는 www.dcinside.com이다.  도메인은 ip 주소로 변환되므로, ip 주소로 서버의 위치를 찾을 수 있다.   index.php : 요청할 자원의 이름이다.

 

 

이렇게 "프로토콜", "위치", "자원명"으로 어디에 있던지 자원에 접근할 수 있다.

https://www.dcinside.com/index.php 이라고 하면 https 프로토콜을 사용할거고 도메인(ip주소)는 이거구 그 ip주소에 있는 index.php를 요청합니다. 

가 되는 것이다.

 

1.4 Method(메서드)

 

메서드는 요청의 종류를 서버에게 알려주기 위해서 사용한다. 

다음은 요청에 사용할 수 있는 메서드들이다.

 

GET : 정보를 요청하기 위해서 사용한다. (SELECT)

POST : 정보를 밀어넣기 위해서 사용한다. (INSERT)

PUT : 정보를 업데이트하기 위해서 사용한다. (UPDATE)

DELETE : 정보를 삭제하기 위해서 사용한다. (DELETE)

 

HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.

OPTIONS : 웹서버가 지원하는 메서드의 종류를 요청한다.

TRACE : 클라이언트의 요청을 그대로 반환한다. 예컨데 echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다.

 

각 용도에 맞는 메서드가 준비돼 있음에도 GET과 POST만으로도 모든 종류의 요청을 표현할 수 있다.

 

명시적으로 메서드를 사용하지 않아도 웹 서비스 개발에 큰 문제는 없지만

Restful API 서버의 경우에는 GET, POST, DELETE, PUT을 명시적으로 구분한다. 

 

자원의 위치 뿐만 아니라 자원에 할 일 까지 명확히 명시할 수 있기 때문에, 

Open API 서버를 만들기 위해서 널리 사용한다. 

 

1.5 요청데이터 포맷

 

1. 요청 메서드 : GET, PUT, POST, PUSH, OPTIONS 등의 요청 방식이 온다. ( GET )

2. 요청 URI : 요청하는 자원의 위치를 명시한다. ( URI )

 

3. HTTP 프로토콜 버전 : 웹 브라우저가 사용하는 프로토콜 버전이다.( HTTP/1.1 )

 

1.6 응답헤더 포맷

 

프로토콜과 응답코드 : ( HTTP/1.1 200 OK )

날짜 : ( Date: Sun, 12 Aug 2018 11:30:00 GMT )

서버 프로그램및 스크립트 정보 : ( Apache/2.2.4 (Unix) PHP/5.2.0 ) 

응답헤더에는 다양한 정보를 추가할 수가 있다. 

컨텐츠의 마지막 수정일

캐쉬 제어 방식.

컨텐츠 길이.

 

Keep Alive기능 설정

 

1.7 응답코드

 

2xx 성공

서버가 요청을 성공적으로 처리했음을 의미한다.

 

코드번호	설명	비고
200	성공	서버가 요청을 제대로 처리했다.

 

4xx 요청 오류

클라이언트 요청에 오류가 있음을 의미한다.

 

코드번호	설명	비고
400	잘못된 요청	주로 헤더 포멧이 HTTP 규약에 맞지 않을 경우
403	금지	서버가 요청을 거부하고 있다.
404	찾을 수 없음	요청한 자원이 서버에 존재하지 않는다.

 

1.8 Keep Alive 

 

HTTP 1.1 부터는 keep-alive 기능을 지원한다.

HTTP는 하나의 연결에 하나의 요청을 하는 것을 기준으로 설계가 됐다. 

요즘 웹 서비스의 경우 간단한 페이지라고 해도 수십개의 데이터(문서, image, css, js)가 있기 마련인데, 

HTTP의 원래 규격대로라면 웹페이지를 하나 표시하기 위해서는

연결을 맺고 끝는 과정을 수십번을 반복해야 한다. 

 

당연히 비효율적일 수 밖에 없다. 

연결을 맺고 끝는 것은 TCP 통신 과정에서 가장 많은 비용이 소비되는 작업이기 때문이다.

예를들어 HTML로 표현된 문서를 다운로드 받는다고 가정해 보자. 

이 문서에는 20개 정도의 image, css, js 파일이 있다. 

 

Keep alive를 지원하지 않을 경우 다음과 같은 과정을 거친다.

 

1.  웹 서버에 연결한다.  HTML 문서를 다운로드 한다.  웹 서버 연결을 끊는다.

2.  HTML 문서의 image, css, javascript 링크들을 읽어서 다운로드해야할 경로를 저장한다.  웹 서버에 연결한다.   첫번째 이미지를 다운로드  연결을 끊는다.

3.  웹 서버에 연결한다.  두번째 이미지를 다운로드  연결을 끊는다.

 

 

모든 링크를 다운로드 할 때까지 반복한다.

 

Keep-alive 설정을 하면, 지정된 시간동안 연결을 끊지 않고 요청을 계속해서 보낼 수 있다.

 

1.  웹 서버에 연결한다.  HTML 문서를 다운로드 한다.  Image, css, javascript 들을 다운로드 한다.  모든 문서를 다운로드 받았다면 연결을 끊는다.

 

 

Connection: Keep-Alive 

Keep-Alive:timeout=5, max=200

 

연결을 keep-alive 상태로 유지한다.

하나의 연결당 5초동안 유지한다. Keep-alive 연결은 최대 200개까지 허용한다. 

 

keep-alive는 하나의 연결로 여러 요청을 처리하기 때문에 효율적이긴 하지만, 

연결이 그만큼 길어지기 때문에 동시간대 연결이 늘어난다. 운영체제에 있어서 연결은 "유한한 자원"이다. 

연결을 다 써버리면, 서버는 더 이상 연결을 받을 수 없게 된다.

Max 값을 이용해서 keep-alive 연결을 제한하는 이유다.

 

포스트 작성에 도움을 준 사이트 : https://www.joinc.co.kr