[기타]HTTP 프로토콜

HTTP 프로토콜

원문을 토대로 개념을 정리하고자 작성하였습니다. 문제시 삭제하겠습니다.

원출처 : https://www.joinc.co.kr/w/Site/Network_Programing/AdvancedComm/HTTP

HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜입니다. 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동합니다. 가장 성공적인 인터넷 프로토콜입니다.

HTTP는 어떤 종류의 데이터든지 전송할 수 있도록 설계되어 있습니다. 인터넷상에 흔히 볼수 있는 HTML로 작성된 문서는 HTTP로 보낼 수 있는 데이터의 한 종류일 뿐입니다. 이미지, 동영상, 오디오, 텍스트 문서 등 종류를 가리지 않는다..고 합니다.

HTTP는 서버/클라이언트 모델을 따르며 클라이언트에서 요청(request)를 보내면 서버는 요청을 처리해서 응답(response)합니다.

클라이언트 : '요청자', 서버에 요청하는 클라이언트 소프트웨어가 설치된 컴퓨터. 클라이언트 소프트웨어를 '웹 브라우저' 라고 하며 chrome, IE, Mozilla FireFox 등이 있습니다.

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

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

HTTP는 Connectless 방식으로 작동합니다. 서버에 연결하고, 요총해서 응답을 받으면 연결을 끊어버립니다. 기본적으로 자원 하나에 대해서 하나의 연결을 만드는데 이런 작동방식은 각각 다음과 같은 장점과 단점을 가집니다.

· 장점 : 불특정 다수를 대상으로 하는 서비스에 적합한 방식입니다. 수십만명이 웹 서비스를 사용하더라도 접속유지는 최소한으로 할 수 있기 때문에, 더 많은 유저의 요청을 처리할 수 있습니다.

· 단점 : 연결을 끊어버리기 때문에, 클라이언트의 이전 상태를 알 수가 없습니다. 이러한 HTTP의 특징을 stateless라고 하는데, Connectless로 부터 파생되는 특징이라고 할 수 있습니다. 클라이언트의 이전 상태 정보를 알 수 없게 되면 웹 서비스를 하는데 당장에 문제가 생깁니다. 예컨데, 클라이언트가 과거에 로그인을 성공하더라도 로그 정보를 유지할 수가 없습니다. HTTP는 cookie를 이용해 이 문제를 해결하고 있습니다.

(생각해보니까 cookie의 활용을 관찰하면 헨델과 그래텔이 생각나네요. 과거 상태를 기억하기 위한 단서.. 이지만 cookie의 변형이 일어났을때는 문제가 발생합니다.)

Cookie는 클라이언트와 서버의 상태 정보를 담고 있는 정보조각이다. 로그인을 예로 들자면, 클라이언트가 로그인에 성공하면, 서버는 로그인 정보를 자신의 데이터베이스에 저장하고 동일한 값을 cookie 형태로 클라이언트에 보냅니다. 클라이언트는 다음 번 요청때 cookie를 서버에 보내는데, 서버는 cookie 값으로 자신의 데이터베이스를 조회해서 로그인 여부를 확인할 수 있습니다. 세부적인 내용은 Session에서 다루겠습니다.

클라이언트 프로그램(이하 웹 브라우저)은 URI를 이용하여 자원의 위치를 찾습니다. URI는 HTTP와 독립된 다른 체계입니다. HTTP는 전송 프로토콜이고, URI는 자원의 위치를 알려주기 위한 프로토콜입니다. Uniform Resource Identifiers 의 줄입으로, WWW상에서 접근하고자 하는 자원의 위치를 나타내기 위해 사용합니다. 자원은 "문서", "이미지", "동영상", "프로그램", "이메일" 등 모든 것이 될 수 있습니다. 메일을 받을 때 상대의 위치를 나타내기 위해서 사용하는 email:dream@joinc.co.kr, 웹페이지의 위치를 나타내기 위해서 사용하는 http://www.naver.com 등이 URI의 예입니다.

URI는 "프로토콜", "위치", "자원명"으로 자원에 접근할 수 있습니다.

메서드는 요청의 종류를 서버에게 알려주기 위해서 사용합니다. 다음은 요청에 사용할 수 있는 메서드 들입니다.

· GET : 정보를 요청하기 위해서 사용합니다.

· POST : 정보를 밀어넣기 위해서 사용합니다.

· PUT : 정보를 업데이트하기 위해서 사용합니다.

· DELETE : 정보를 삭제하기 위해서 사용합니다.

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

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

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

보통 웹 서비스들은 GET과 POST 만을 이용해서 개발합니다. DELETE나 PUT등이 필요한 요청에도 GET과 POST를 사용하는데, 예를들어 게시판에서 특정 레코드를 삭제 할때도 GET으로 표현합니다.

각 용도에 맞는 메서드가 준비돼 있음에도 이렇게 사용하는 이유는

1. GET과 POST만으로도 모든 종류의 요청을 표현할 수 있어서

2. 편하개 개발하고 싶어서

3. 웹 브라우저로 DELETE, HEAD등을 보내는 form이 없어서 입니다.

이렇게 명시적으로 메서드를 사용하지 않아도 웹 서비스 개발에 큰 문제는 없지만, 가능하면 CRUD를 명시하는게 좋지 않을까요?

그렇습니다. Restful API 서버의 경우에는 GET, POST, DELETE, PUT을 명시적으로 구분합니다. 자원의 위치뿐만 아니라 자원에 할 일 까지 명확히 명시할 수 있기 때문에, Open API 서버를 만들기 위해서 널리 사용합니다. 아래는 사용 예시입니다.

· GET api.joinc.co.kr/user/list : 유저 목록을 가져온다.

· POST api.joinc.co.kr/user/create : 유저를 생성한다. 생성에 필요한 유저 정보는 POST 데이터 형식으로 전달할 수 있다.

· PUT api.joinc.co.kr/user/123 : 유저 ID가 123인 유저의 정보를 업데이트 한다

· DELETE api.joinc.co.kr/user/123 : 유저 ID가 123인 유저를 삭제한다.

웹 브라우저는 웹 서버에 데이터를 "요청"하는 "클라이언트 프로그램"입니다. 요청은 서버가 인식할 수 있는 약속된 형식(HTTP 형식)을 따라야 합니다.

요청 데이터는 "HEADER"와 "BODY"로 구성됩니다.

헤더에는 요청과 요청에 대한 메타정보들이 들어있습니다.