굳건하게

안녕하세요, 여행벌입니다.

오늘은 가상호스트, 프록시, 게이트웨이, 터널에 대해서 정리해보겠습니다.

[ 가상호스트 (Virtual Host) ]

 HTTP/1.1 부터 하나의 HTTP 서버에 여러 개의 웹 사이트를 띄우는 가상 호스트 기술이 가능해졌다. 즉, 하나의 웹 서버로 여러 웹 사이트를 운영할 수 있다. 같은 IP 주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있으므로 HTTP 리퀘스트를 보내는 경우에 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야 한다.

naver.com / mail.naver.com / comic.naver.com 는 모두 같은 IP 주소(네이버가 운영하는 서버) 지만 호스트명, 도메인 명을 다르게!!

[ 프록시 (Proxy) ]

 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송한다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 프록시, 그 중계 기능을 하는 것을 프록시 서버라고 부른다.

 주로 보안을 위해 사용되어 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 해준다. ( 회사 내부망에서 외부로 요청하는 내용들이 신뢰할만한 요청인지 프록시에서 확인해 액세스 제한 등을 할 수 있다. )

[ 게이트웨이 (Gateway) ]

 게이트웨이도 프록시와 마찬가지로 서버와 클라이언트의 중계 역할을 하는 프로그램이다. 게이트웨이의 경우에는 리퀘스트를 전달하는 서버가 HTTP 이외의 서비스를 제공하는 서버다. 즉, HTTP 트래픽을 다루는 다른 프로토콜로 변환하기 위해 게이트 웨이를 사용한다. 또, 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높이는 역할도 한다.

[ 터널 (Tunnel) ]

 터널은 요구에 따라서 다른 서버와의 통신 경로를 확립한다. 이때, 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 터널을 사용한다. 터널 자체는 HTTP 리퀘스트를 해석하려하지 않고 그냥 다음 서버로 중계한다.

안녕하세요, 여행벌입니다.

오늘은 클라이언트의 요청에 따른 응답 상태를 나타내주는 상태코드에 대해서 정리해보도록 하겠습닏.ㅏ

[ HTTPNetwork 상태코드 ]

상태코드는 클라이언트가 보낸 요청의 처리 상태를 리스폰스에서 알려주는 기능입니다. 상태코드를 통해 서버가 리퀘스트를 정상적으로 처리했는지, 결과가 에러였는지를 알 수 있습니다.

[ 1xx (Informational) ]

100번 대 상태코드는 "요청이 수신되어 처리중"이라는 뜻으로 거의 사용되지 않습니다.

[ 2xx (Success) ]

200번 대 상태코드는 "리퀘스트를 정상적으로 처리했음" 이라는 뜻입니다.

• 200 OK

  클라이언트가 보낸 리퀘스트를 서버가 정상 처리한 상황입니다. 리스폰스에서 상태 코드와 함께 되돌아 오는 정보는 메소드에 따라 다르고, GET 메소드의 경우에는 리퀘스트 된 리소스에 대응하는 엔티티가 보내지고, HEAD 메소드의 경우에는 리퀘스트된 리소스에 대응하는 엔티티 헤더 필드가 메시지 바디를 동반하지 않고 되돌아옵니다.

• 201 Created

  클라이언트가 보낸 리퀘스트를 서버가 정상 처리하여 새로운 리소스가 생성된 상황입니다. 생성된 리소스는 리스폰스의 Location 헤더 필드로 식별해줍니다.

• 202 Accepted

  클라이언트가 보낸 리퀘스트가 접수되었으나 아직 처리가 완료되지않은 상황입니다. 배치 처리 같은 곳에서 사용되는 코드입니다.( 요청 접수 후 1시간 뒤에 요청을 처리하는 배치 프로세스 등 )

• 204 No Content

  서버가 리퀘스트를 받아서 처리하는데 성공했지만 리스폰스에 보낼 데이터가 없어서 엔티티 바디를 포함하지 않는 상황입니다. 클라이언트에서 서버에 정보를 보내는 것으로 족하고, 클라이언트에 대해서 새로운 정보를 보낼 필요가 없는 경우에 사용됩니다.

• 206 Partial Content

  Range에 의해서 범위가 지정된 리퀘스트에 의해서 서버가 부분적 GET 리퀘스트를 받은 상황입니다. 리스폰스에는 Content-Range로 지정된 범위의 엔티티가 포함되게 됩니다.

[ 3xx (Redirection) ]

300번 대 상태코드는 "요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요함" 이라는 뜻입니다. 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동합니다.

• 301 Moved Permanently ( 영구 리다이렉션 )

  리퀘스트된 리소스의 URI 가 영구적으로 변경된 상황입니다. 원래의 URL 를 사용하면 안되고, 새로운 URI를 사용해야한다는 것을 나타내고 있습니다. 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있습니다.

• 308 Permanent Redirect ( 영구 리다이렉션 )

  301과 기능 면에서는 동일하나 리다이렉트시 요청 메서드와 본문을 유지해준다. 즉, POST 로 처음에 요청을 보내면 리다이렉트시에도 POST를 유지해준다.

• 302 Found ( 일시적인 리다이렉션 )

  리퀘스트된 리소스의 URI가 변경되어있기 때문에 새로운 URI를 참조해 주길 바란다는 의미로 301과 달리 영구적으로 변경된 상황이 아니라 이동하는 곳의 URI는 앞으로도 이동 가능성이 있습니다. 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있습니다.

• 303 See Other ( 일시적인 리다이렉션 )

  302와 기능 면에서는 동일하나 리다이렉트시 요청 메서드가 무조건 GET으로 변경됩니다. 즉, 리퀘스트에 대한 리소스는 다른 URI에 있기 때문에 GET 메소드를 사용해서 얻어야 한다는 뜻입니다.

• 307 Temporary Redirect ( 일시적인 리다이렉션 )

  302와 기능 면에서는 동일하나 리다이렉트시 요청 메서드와 본문을 유지해야됩니다. 즉, POST로 요청할 시 POST로 리다이렉트 해줍니다.

처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이였으나 웹 브라우저들이 대부분 GET 으로 바꾸어버렸다.

--> 모호한 302를 대신하는 명확한 303, 307이 등장!

• 304 Not Modified

  클라이언트가 조건부 리퀘스트를 했을 때 리소스에 대한 액세스는 허락하지만, 조건이 충족되지 않음을 표시합니다. 304를 되돌려 줄 경우에는 리스폰스 바디에 어떤 것도 포함되어 있어서는 안됩니다. 캐시를 목적으로 사용되고 3xx에 분류되어 있디만 리다이렉트와는 관계가 없습니다.

참고!

301, 302 상태코드의 사양은 POST 메소드를 GET 메소드로 바꾸는 것을 허용하지 않았지만 대부분의 브라우저가 그렇게 구현을 해놓아서, GET 으로 변하고 본문이 제거될 수 있다고 스펙이 변경되었습니다.

[ 4xx (Client Error) ]

400번 대 상태코드는 클라이언트의 원인으로 에러가 발생했음을 나타냅니다. 클라이언트의 요청에 잘못된 문법이 포함되어있는 등 오류의 원인이 클라이언트에 있는 상황입니다. 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 재시도를 해도 똑같이 실패합니다.

• 400 Bad Request

  요청 구문, 메시지 등등 리퀘스트 구문이 잘못되었음을 나타냅니다. 이 에러가 발생한 경우, 리퀘스트 내용을 재검토해서 재송신해야합니다.

• 401 Unauthorized

  해당 리소스에 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았음을 나타냅니다. 401 오류 발생시 응답에 WWW_Authenticate 헤더와 함께 구체적인 인증 방법을 명시해줍니다.

• 403 Forbidden

  리퀘스트된 리소스의 액세스가 거부되었음을 나타냅니다. 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우에 발생하고 서버 측은 거부의 이유를 엔티티 바디에 기재해서 유저 측에 표시합니다. ( 로그인은 했지만, 내 계정 권한으로 접근할 수 없는 정보를 접근하는 경우 )

• 404 Not Found

  리퀘스트한 리소스가 서버 상에 없는 경우 혹은 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶은 경우에 발생합니다.

[ 5xx (Server Error) ]

500번 대 상태코드는 서버 문제로 오류가 발생했음을 나타냅니다. 서버에 문제가 있기 때문에 재시도하면 성공할 수도 있습니다.

• 500 Internal Server Error

  리퀘스트를 처리하는 도중에 서버 내부 문제로 오류가 발생한 경우입니다.

• 503 Service Unavailable

  서버가 일시적인 과부하 또는 예정된 작업으로 현재 리퀘스트를 처리할 수 없는 경우입니다. Retry-After 헤더필드로 얼마 뒤에 복구되는지 보낼 수 있습니다.

이상으로, Response StatusCode 정리를 마치겠습니다.

안녕하세요, 여행벌입니다.

오늘은 HTTP 프로토콜 메소드에 이어서 HTTP 프로토콜의 정보에 해당하는 메시지에 대해서 알아보겠습니다.

[ HTTP 메시지 ]

HTTP 프로토콜에서 교환하는 정보를 HTTP메시지라고 부릅니다. 리퀘스트 측 HTTP메시지를 리퀘스트 메시지, 리스폰스 측 HTTP메시지를 리스폰스 메시지라고 부르고 다음과 같은 형태를 유지한다.

시작라인 / 메시지헤더 / CRLF(개행) / 메시지바디 순으로 이루어져있으며 메시지바디는 없을 수도 있습니다. 저번 포스팅에서 다뤘던 GET 메소드는 대부분 메시지 바디가 없습니다.

• 시작 라인 : 시작라인은 리퀘스트에서는 리퀘스트라인, 리스폰스에서는 상태라인 이라고 불립니다.
  • 리퀘스트라인 : 리퀘스트에 사용하는 메소드 / 리퀘스트 URI / HTTP 버전이 포함.
  • 상태라인 : 리스폰스 결과를 나타내는 상태코드와 설명 / HTTP 버전이 포함.
• 헤더 필드 : HTTP 전송에 필요한 모든 부가정보가 담겨있는 곳으로, 리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포함됩니다.
• 바디 필드 : 실제 전송할 데이터를 담고 있는 필드로 HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터가 들어갈 수 있다.

[ HTTP 인코딩 ]

 HTTP로 데이터를 전송할 경우 그대로 전송할 수도 있지만, 인코딩을 실시함으로써 전송 효율을 높일 수 있습니다. 전송할 때 인코딩을 하면 CPU 등의 리소스는 많이 사용하지만 더 효율적으로 데이터를 전송할 수 있습니다.

• 메시지 : HTTP 통신의 기본 단위로 옥텟시퀀스(Octet sequence)로 구성되고 통신을 통해서 전송.
• 엔티티 : 리퀘스트랑 리스폰스의 페이로드(Payload, 부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성.

 HTTP 메시지 바디는 리퀘스트랑 리스폰스에 관한 엔티디 바디를 운반해줍니다. 인코딩을 한다는 것은 엔티티 정보를 인코딩을 해서 메시지 바디에 실어서 보낸다는 뜻입니다.

참고!

콘텐츠 코딩(Content Codings)

엔티티에 적용하는 인코딩을 가리키는 용어로 엔티티 정보를 유지한 채로 압축을 해줍니다. 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩을 해서 이용합니다.

[ 청크 전송 코딩(Chunked transfer Coding) ]

 HTTP 통신에서는 리퀘스트했었던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않습니다. 그래서 사이즈가 큰 데이터를 전송하는 경우에는 데이터를 분할해서 조금씩 브라우저에 표시하는 청크 전송 코딩을 이용해야합니다.

청크 전송 코딩은 엔티티 바디를 청크 단위로 분해해서 전송합니다.

[ 여러 데이터를 보내는 멀티파트 ]

 메일의 경우에는 메일의 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있습니다. MIME( Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장 사양 ) 은 이미지, 텍스트, 영상 등 다양한 데이터의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법과 데이터 종류는 나타내는 방법등을 규정하고 있습니다. 이 MIME 의 확장 사양에 있는 Multipart 라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 HTTP 에서도 사용해 하나의 메시지 바디 내부에 엔티티를 여러 개 포함해서 보낼 수 있습니다.

multipart/form-data : Web 폼으로부터 파일 업로드에 사용됩니다.

multipart/byteranges : 상태코드 206 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용됩니다.

[ 레인지 리퀘스트(Range Request) ]

 HTTP 통신에서 커넥션이 끊어지게 되면 엔티티 정보를 처음부터 다시 전달받아야합니다. 따라서, 문제가 생겼을 때 이전에 전달받은 범위 뒤에서부터 전달을 다시 받는 레인지 리퀘스트가 등장했습니다. 이름 그대로 엔티티의 범위를 지정해서 해당 범위 만을 리퀘스트 하는 방법입니다.

[ 콘텐츠 네고시에이션(Content Negotiation) ]

 같은 콘텐츠(내용)이지만 여러 개의 페이지를 지닌 웹 페이지가 있습니다. ( 구글 영어판, 한국어판 ) 이러한 웹 페이지에서 같은 URI에 액세스할 때에 적절한 웹 페이지를 표시해주는 구조를 콘텐츠 네고시에이션이라 합니다.

콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 적합한 리소스를 판단합니다.

Accept / Accept-Cahrset / Accept-Encoding / Accept-Language / Content-Language

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic

안녕하세요, 여행벌입니다.

오늘은 HTTP 에서 지원해주는 다양한 메소드에 대해서 정리해보겠습니다.

[ HTTP 메소드 ]

HTTP 는 다양한 메소드를 지원해줍니다.

• GET : 리소스 조회
• POST : 요청 데이터 처리
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제
• HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 기능 옵션을 설명
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

[ GET 메소드 ]

GET 메소드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구하는 메소드입니다. 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과입니다.

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많으므로 사용 X
• ( 최근 스펙에서는 바디에 데이터를 넣는 것을 허용했지만, 실무에서는 사용 X )

[ POST 메소드 ]

POST 메소드는 엔티티를 전송하고 엔티티 처리를 요구하는 메소드입니다. POST 메소드는 GET메소드와 함께 가장 많이 사용되는 메소드로 GET 메소드는 아니지만 어떤 메소드를 사용해야될 지 모르겠으면 POST 메소드를 사용하는 것도 하나의 방법입니다.

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청 (정식스펙)

[ PUT 메소드 ]

PUT 메소드는 리소스가 있다면 완전히 대체하고, 리소스가 없다면 새롭게 생성해주는 메소드로 파일을 전송하기 위해서 사용됩니다. 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정된 곳에 보존하도록 요구합니다. 우리가 알고있는 덮어쓰기랑 동작 방식이 같습니다.

• 리소스가 있으면 대체 없으면 생성 ( 완전히 대체 )
• PUT은 클라이언트가 리소스 위치를 알고 URI 를 지정한다.

[ PATCH 메소드 ]

PATCH 메소드는 리소스의 일부분만 교체하는 메소드입니다.

• 리소스 부분 변경

[ DELETE 메소드 ]

DELETE 메소드는 파일을 삭제하기 위해 사용합니다. PUT 메소드와는 반대로 동작하며 리쉐크트 URI로 지정된 리소스의 삭제를 요구합니다.

• 리소스 제거

[ HEAD 메소드 ]

HEAD 메소드는 GET과 같은 기능이지만 메시지 바디는 돌려주지 않습니다.

• 리소스 조회

[ OPTIONS 메소드 ]

OPTIONS 메소드는 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용합니다.

• 사용 가능한 메소드 조사

[ TRACE 메소드 ]

TRACE 메소드는 Web 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킵니다. 리퀘스트를 보낼 때 "Max-Forwards" 라는 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 그 수치를 줄여갑니다. 클라이언트는 TRACE 메소드를 사용함으로써, 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 등을 조사할 수 있습니다.

• 경로 추적

[ CONNECT 메소드 ]

CONNECT 메소드는 프록시에 터널 접속 확립을 요함으로써, TCP 통신을 터널링 시키기 위해서 사용됩니다.

• 프록시에의 터널링 요구

[ HTTP 메소드 속성 ]

- 안전 (Safe)

: 호출해도 리소스를 변경하지 않는 메소드를 안전하다고 한다. 계속 호출해서 장애가 나는 경우는 고려하지않고, 해당 리소스가 변하는지만 고려한다.

- 멱등 (Idempotent)

: 몇 번 호출하든 결과가 똑같은 메소드를 멱등하다고 한다. 서버가 정상 응답을 하지 못했을 때, 멱등한 메소드는 자동적으로 다시 호출하도록 복구 메커니즘을 만드는데 사용한다. 또, POST는 멱등이 아니다. 결제하는 경우를 생각해보면 POST는 2번 호출하면 중복 결제가 된다.

- 캐시가능 (Cacheable)

: 응답 결과 리소스를 캐시해서 사용해도 되는 메소드를 캐시가능하다고 한다.

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic