HTTP 개관

오늘 부터 나는 http에 대해 공부할 예정이다.
[HTTP 완벽 가이드]라는 책을 가지고 공부를 할 예정이며,
책을 가지고 공부하는 것을 더불어 조금 더 자세하게 공부할 예정이다.
1장당 일주일동안 공부할 예정이다.  책 한권을 보는데 5달 정도 걸릴 것같다.
* 이글에 나오는 비유는 전적으로 저한테 맞춰있는 비유이기 때문에 이해가 되지 않을 가능성이 있습니다.
저는 이에 대해 책임을 지지 않습니다. 저는 공부목적으로 작성하는거지 기술 소개 목적으로 작성하는 것이 아님을 명시합니다.
내가 책으로만 공부해봤는데 그렇게 까지 도움은 되지 않았다. 왜냐하면 책 이외의 내용은 학습하기 어려웠기 때문이다.
하지만 책은 베이스로 두고, 이것을 첨언할 수 있는 내용들을 인터넷에서 검색해서 추가할 예정이다.

http를 공부하면서 다음과 같은 것을 학습해야 된다고 한다.
1. 얼마나 많은 클라이언트와 서버가 통신하는지?
2. 리소스(웹 콘텐츠)가 어디서 오는지?
3. 웹 트랜잭션이 어떻게 동작하는지?
4. HTTP 통신을 위해 사용하는 메시지의 형식은 어떤것이 있는지?
5. HTTP 기저의 TCP 네트워크 전송은 어떤식으로 되는지?
6. 여러 종류의 HTTP 프로토콜이 존재하는지?
7. 인터넷 곳곳에 설치된 다양한 HTTP 구성요소는 어떤것이 있는지?

http는 신뢰성이 있는 전송 프로토콜이기 때문에 지구 반대편으로 오더라도 전송 중 손상되거나 꼬이지 않는다.
이렇게 해서 웹이 만들어지는 것인가... 
웹이라는게 http의 집합체이니까.

결국 상품이 손상되지 않기 때문에 도착지는 상품을 정상적으로 배달할 수 있는건가..
그러면 어째서 http는 신뢰성있는 프로토콜이라고 할 수 있을까?

추후 학습할지도 모르겠지만, 지금은 그렇구나라고 생각하자. 

배달지를 웹 클라이언트라고 하고
출발지를 웹 서버라고 한다.

여기서에서는 웹 서버에서 데이터를 저장하고 웹 클라이언트가 요청한 데이터를 전송한다.
그러면 웹서버는 데이터를 어떤식으로 웹 클라이언트로 전달하는 것일까?

이를 리소스라고 부르며, 리소스는 웹 콘텐츠의 원천이라고 한다.
이제 부터 리소스에 어떤것이 존재하는지 자세하게 살펴보자.

미디어 타입

HTTP는 웹에서 전송되는 객체에 각각 데이터 포맷 라벨을 붙여지는데 이것을 "MIME 타입"이라고 부른다.
어떻게 보면 웹 브라우저와 웹 서버간의 일종의 약속인 것이다.
굳이!!(비유가 거지같지만ㅎ) 비유하자면, http는 배달부이고, 웹 서버는 쇼핑몰이고, 웹 클라이언트가 고객이라고 가정하고,
쇼핑몰에서 바로 살수도 있지만,
배달을 통해 물건을 받을 수 있습니다.
하지만 아무런 정보 없이는 배달을 할 수 없습니다.
어떠한 정보를 배달하시는 분께 알려줘야 필요가 있습니다.
제 생각에는 이것이 미디어 타입이라 생각이 들고,
HTTP에서는 이러한 미디어 타입을 MIME타입으로 이용하는 것 같습니다.

이것을 만들게 된 이유는 각기 다른 전자메일 시스템 사이에서 메시지가 오갈 때 격는 문제점을 해결하기위해 만들어 졌다고 한다.
이렇게 해서 이메일에서의 문제를 해결 했기 때문에, 다른 웹 콘텐츠에 대해서도 붙이게 된것이 그 연유입니다.
생각해보니, 각자 다른 방법으로 배달하게 되면 쇼핑몰이나 고객들에게 큰 혼란을 줄수 있을 것 같다는 생각이 들었습니다. 왜냐하면, 각자 다른 것?을 작성하게 되니 배달 부 입장에서는 그 수많은 정보 패턴을 파악할 필요가 있다고 생각했습니다.

다시 돌아와서 MIME타입은 사선 (/)으로 구분된 주 타입과 부 타입으로 이루어진다.
대표적으로 HTML => text/html
                  ASCII => text/plain
                  JPEG => image/jpeg
                   GIF    => image/gif 등등 이 있습니다.

MIME 타입의 전체 목록 - HTTP | MDN

이글을 보면 mime타입의 전체를 알 수 있습니다.
사실 이것을 왜 사용하는지 헷갈렸는데 생각해보니 반드시 필요한거라고 생각합니다.

URI

생각해봅시다.
미디어 타입으로 어느정도 파일이 어떤 파일인지 알았다면,
실질적으로 어떤것을 배달할것인 알 필요가 있다.
같은 과일이라고 해서 모든 과일이 사과가 아닌것 처럼...
이것을 URI이라고 부르는데 
Uniform Resource Idenifier 통합 자원 리소스라고 한다.
이름에서도 알 수 있듯이 어떤 리소스인지 알 수 있게 하는 것이라 할 수 있다.

여기서 의문이 드는게 미디어 타입을 사용하지 않고 URI만 사용해도 되는것이 아닐까?
물론 이렇게해도 데이터는 전달 할수 도 있을지 모르지만,
전송할때 오가는 문제점을 줄이기 위해 미디어 타입을 사용하는 것이기 때문에
최대한 문제를 줄이기 위해서는 미디어 타입도 사용하는 것이 좋을 것 같다.

아무튼 URI애는 총 2가지 방법으로 구분 지을 수 있다.

URL

UR까지는 같은데 마지막이 다른 것으로 봐서 L에 뭔가 힌트가 있는 것 같다.
L은 locator의 약자로 위치를 뜻한다.
그러니까 이것은 데이터의 위치를 말하고 있는것이라 해석 할 수 있다.
예를들어 www.abc/hello/123이라고 한다면,
웹상에서 abc를 찾고 그리고 그곳에서 hello라는 공간을 찾고 또 그 안에서 123을 찾아가라는 뜻으로 해석이 되어진다.

그림을 그려보면 이렇게 되는 것 같다.
사실 URL은 앞에 스킴이라는것이 붙여지는데 이는 리소스에 접근하기 위해 사용되는 프로토콜로 서술 할 수 있다.
http:// 이런식으로 작성되어진다.
위에서 한짓을 ftp에서도 적용해보자.
ftp://joe:tools4u@ftp.jes-hardware.com/locking-pliers.gif
이를 해석하면 ftp라는 프로토콜을 사용하고,
joe:tools4u로 ftp에 접속을 한다.
그리고 나서 jes-hardware.com을 찾고 그곳에서 locking-pilers.gif를 찾으면 된다.
이것도 그려보면

현 시점에서 URL이 URI입니다. 그러니까 결국은 이 둘을 동일시 시켜도 상관없다는 뜻입니다. 
물론, 미래에는 어떻게 될지는 아무도 모릅니다. 현재로써는 그렇다는 겁니다.
그래도 URN도 알아봅시다.

URN

참고 : RFC 2141
이것 또한 N으로 그 의미를 알수 있는데,
이름을 통해 구별하는 특징을 가지고 있다.
책의 설명을 빌리자면, URN의 장점은 리소스가 어디에 있던 리소스가 이름만 바뀌지 않는다면 아무런 문제 없이 동작한다고 한다.
결국은 URL처럼 프로토콜에 의존적이지 않고, 이름을자기고 검색이 가능하게 한다는 것인데...
이를 가능하기 위해서는 리소스의 위치를 분석하기 위해 인프라 자원이 필요한데 이러한 이유때문에 URN의 채택이 늦춰지고 있다고 한다.
아쉽게도 현재도 실험상태라고 한다.
만약, 이것이 상용화가 된다면 어떻게 될지 상상도 되지 않는다.

트랜잭션

트랜잭션은 어떠한 시스템관의 상호작용 관계라고 한다.
HTTP 트랜잭션은 요청 명령과 응답결과로 구성되어있다.
요청 명령 : 클라이언트 -> 서버
응답 명령 : 서버 -> 클라이언트

이러한 상호작용은 메서드를 통해 이뤄진다.

메서드

HTTP는 여러 종류의 요청 메서드를 갖게되고,
메서드는 서버에서 어떤 동작이 취해야 하는지 알려준다.
대표적으로 GET, PUT, DELETE, POST, HEAD로 구분되어진다.

근데 서버는 클라이언트가 어떤 요청을 했는지 메서드를 통해 알수 있다는 것인데,
만약, 클라이언트의 요청이 정상적으로 갔는지 확인하는 방법은 없는 것일까?
예를들어 어떤 웹 콘텐츠라는 것이 존재하지 않은 경우, 서버는 그것이 무엇인지 알 필요가 있다.
이러한 것들을 상태 코드라고 한다.

상태코드

HTTP상태 코드는 3자리 숫자를 통해 서버가 처한 상태가 무엇인지 알 수 있다.
예를들어 200이라는 상태코드가 들어왔을때, 서버는 성공이라는 것을 알 수 있다.

지금까지 학습한 내용을 정리해보자.
서버는 URL을 통해 웹 콘텐츠가 어느 위치에 존재하는지 검색을 하게 된다.
물론, 이 콘텐츠가 어떤 콘텐츠인지 알수 있게 미디어 타입을 명시해 준다.
그런데 서버는 이 콘텐츠에 어떻게 접근을 해야할지 생각해야 한다.
이것은 클라이언트가 어떤것을 원하는지 알아야 한다. 예를들면 그 콘텐츠를 가져올지, 만들지, 수정할지, 삭제할지 결정해야 한다.
이것을 메서드라고 부른다. 막상 클라이언트의 요청을 서버가 들어줬음에도 불구하고,
성공 할 수 도, 실패 할 수 도 있다. 만약에 실패했는데 서버가 그 사실을 모른다면 이렇게 응답을 받은 클라이언트는 당황할지도 모른다.
원하는 결과가 아니기 때문이다.
그전에 서버는 클라이언트에 응답을 보내기전에 이 콘텐츠의 상태를 알 수 있어야 한다. 이것이 바로 상태 코드이다.

중요한 사실은 웹페이지는 웹 콘텐츠를 하나씩 전달 하는것은 절대 아니다. 하나씩 보내면 그게 웹 페이지일까?
어떨때는 html, css, js, 이미지 등등을 한번에 보낼 필요가 있다.
즉, 뭉텅이로 보낼 필요가 있다고 생각한다.

근데 생각해보면, 어떻게 수 많은 웹 콘텐츠를 전달 할 수 있는 것일까?
이러한 사실은 http 메시지를 확인하면 알 수 있다.

메시지

메시지는 다음 3가지로 구성되어 있다.

시작줄 : 요청이라면 무엇을 해야하는지, 응답이라면 무슨일이 일어났는지 나타낸다. 
헤더 : 요청혹은 응답이 어떤식으로 전달할지에 작성이 되어있으며, 쌍점(:)으로 구분되고, 필요한 모든 헤더가 추가된다.
마지막 헤더는 빈줄로 끝난다고 한다. 
본문 : 요청 본문은 웹 서버로 데이터를 실어 보내며, 응답 본문은 클라이언트로 데이터를 반환한다. 본문은 텍스트일 수도 있지만 
이진 데이터 일 수 도 있다.

어떻게 http는 이런 동작을 할 수 있는 것일까?
지금까지 공부한걸로 이해하면 클라이언트 -> 서버가 요청이라면 요청을 받은 서버는 클라이언트에게 잘 전달을 받았다는 응답을 보내야 된다.
그런데 클라이언트가 제대로 응답을 받았는지 아닌지 서버는 알 필요가 있다.

TCP 커넥터

http는 tcp커넥터라는 것을 이용해서 전송을 하는데 자세히 알아보자.
생각해보면 둘다 프로토콜인데,
다른 역할을 가지고 있다는 것은 뭔가 광범위한 무언가는 하기 어렵다는 것인가...
솔직히 잘모르겠다.
이제 와서 하는 이야기이지만 http와 tcp가 어떻게 다른건지 잘모르겠다. 
하지만 하나 확실한것은 역할은 서로 다르다는것이다.

더 자세하게 알아 보자.

TCP/IP

책을 읽어보니 http는 네트워크 통신의 핵심적인 세부사항에 대해서는 신경 쓰지 않는다고 한다.
대신 더 신중한 tcp/ip에 그것을 위임한다고 한다.
결국 http는 웹콘텐츠가 서버와 클라이언트에서 어떤식으로 동작하는지 짐작할 수 있는 것이지만,
이게 네트워크 전반적으로 동작하지 않는다는 점이 크다.
결국, 나 혼자 웹을 사용한다고 한다면 http만 사용해도 문제 없겠지만,
여럿이서 함께 사용한다면, http만 사용하는 것은 어쩌면 힘들지도 모르겠다.

아무튼 tcp는 다음과 같은 것을 제공한다고 한다.
1. 오류 없는 데이터 전송
2. 순서에 맞는 전달 (랜덤 전달 금지)
3. 조각나지 않은 데이터 스트림 (크기 상관 무)

" TCP 커넥터을 맺는것은 다른 회사 사무실에 있는 누군가에게 전화를 거는 것과 비슷하다.
먼저 회사의 번호를 누른다. 이렇게 하면 그 회사로 연결이 된다. 그 다음에는 전화를 걸고자하는 상대방이 
쓰는 번호를 누른다."

책에서는 위와 같이 설명하고 있다.
생각해보면 클라이언트와 서버는 어떻게 통신을 할까를 생각을 해야 한다.
방법은 총 2가지
1. ip주소로 접속 하는 방법
2. DNS + URL로 접속 하는 방법
2번째 같은 경우
  포트번호를 추가할 수도 있다.

그림을 그려서 설명하고는 싶지만 굳이 지금할 필요는 없을 것 같다.
이제 http프로토콜이 어떤식으로 발전을 했는지 알아보자.

프로토콜 버전

가장 초기에 생성된 버전은
http/0.9버전으로 이름에도 알수 있듯이 프로토타입이라고 한다.
내가 알기로는 이때는 get밖에 없었다고 한다.(post도 있었나 ... ㅎㅎ)
이 버전은 심각한 결함이 존재 했기 때문에
http 최초의 상용화 버전인 http/1.0이 세상으로 나왔다.
이때도 많은 것들이 발전했지만, 딱히 잘 정의된 명세가 아니다.

http/1.0+라는것이 등장했다.
1.0에대해 기능을 추가한 것이라 생각이 든다.

http/1.1 버전 드디어 이 버전이 나왔다.
현 http프로토콜의 생태계를 담당하는 역할을 하는 녀석으로
이때 성능이 많이 상향 되었다고 한다.

http/2.0 
1.1때의 문제점을 개선하고자 구글의 SPDY프로토콜을 기반으로 설계되었다.

이제 http/3.0까지 나온 시점이다. 물론 대세는 1.1이다.
하지만 언제 2.0,3.0이 http의 대세가 될지는 아무도 모른다.
여기에서는 간략하게 알아봤다.
사실 특징을 설명한게 아니라 이런것이 있다는 정도로 알았으면 좋겠다.

마지막으로 웹의 구성 요소를 알아보면서 마치려고 한다.

웹의 구성요소

  프락시 : 클라이언트와 서버 사이에 위치한 http 중재자
  캐시 : 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고(이것도 프락시)
  게이트 웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버
  터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
  에이전트 : 자동화된 HTTP 요청을 만드는 준지능적 웹클라이언트

이 모든것은 책을 공부하면서 자세하게 공부할 예정이기 때문에 이쯤에서 끝내도 될것 같다.
초반에 비해 막판은 힘이 많이 빠진 것 같지만, 아무튼 밑에 자료는 HTTP 완벽 가이드라는 책에서 나온 자료를 링크해 두었다.
참고로 참고자료에서 발췌한것은 없다. 하지만 나중에 생겨도..

참고자료
https://www.w3.org/Protocols/   
https://www.ietf.org/rfc/rfc2616.txt  
https://www.ietf.org/rfc/rfc1945.txt  
http://w3.org/Protocols/HTTP/AsImplemented.html
https://www.w3.org/Protocols/WhyHTTP.html  
https://www.w3.org/History.html  
https://www.w3.org/DesignIssues/Architecture.html   
https://www.w3.org/    
https://datatracker.ietf.org/doc/html/rfc2396    
https://datatracker.ietf.org/doc/html/rfc2412   
https://datatracker.ietf.org/doc/html/rfc2046    
https://datatracker.ietf.org/doc/html/draft-ietf-wrec-taxonomy-06