Http가이드 3 - http 메시지

모든 자료 출처 : O’REILLY - HTTP 완벽 가이드

HTTP 메시지

• http 메시지는 무언가를 담아 보내는 소포 와 같은 역할을 한다.

메시지는 다운스트림 으로 흐른다.

• 클라이언트 -> (요청) 서버

  
  flowchart TD
    A[클라이언트] --> B;
    B[프록시1] --> C;
    C[프록시2] --> D;
    D[프록시3] --> E;
    E[(서버)]
  
  

• 서버 (응답) –> 클라이언트

  flowchart TD
  A[(서버)] -->B;
  B[프록시3] -->C;
  C[프록시2] -->D;
  D[프록시1] --> E;
  E[클라이언트]
  
  

• 즉, 요청 과 응답시에는 발송의 주체가 업스트림, 수신의 주체가 다운스트림이 된다.

http 메시지 구성요소

• 헤더
• 메서드
• 요청URL
• 본문 (엔터티 본문)

메서드 (METHOD)

메서드	설명	메시지 본문 여부
GET	서버에서 특정 리소스를 가져온다.	없음
HEAD	서버에서 특정 리소스에 대한 헤더만 가져온다.	없음
POST	서버가 처리해야할 데이터를 보낸다.	있음
PUT	서버에 요청 메시지의 본문을 저장한다.	있음
TRACE	메시지가 Proxy를 거쳐 서버에 도달하는 과정을 추적한다.	없음
OPTIONS	서버가 어떤 METHOD를 수행할 수 있는지 확인한다.	없음
DELETE	서버에서 리소스를 제거한다.	없음

사유구절

• 사유 구절은 응답 시작줄의 마지막 구성요소
• 상태코드에 대한 nametag와 같다.
• 상태코드와 1대1로 대응한다.
• http명세에는 사유구절에 대한 엄격한 규칙이 없다.
• OK, Not Found 와 같은 것이 사유 구절이다.

상태코드 (Status Code)

전체범위	정의된 범위	분류
100-199	100-101	정보
200-299	200-206	성공
300-399	300-305	리다이렉션
400-499	400-415	클라이언트에러
500-599	500-505	서버 에러

• 정의된 범위 가 아닌 범위를 넘어서는 응답코드가 발생 할 수 도 있다.

  • 다른 애플리케이션과 통신시 발생 가능한데, 이때는 개발자가 범위 외의 응답코드를 개방적으로 받아들이는 방향으로 작성해주는 것이 좋다.

성공 상태코드 : 200-299

• 클라이언트가 요청을 보내면, 개발자는 보통 그 요청을 성공시키도록 개발해야 한다.

• 성공 상태 코드의 세부사항

  상태코드	사유구절	의미
  200	OK	정상요청, 본문은 요청된 리소스를 포함
  201	Created	서버 개체(리소스) 생성 요청을 위한 것, 서버는 응답 코드를 보내기전 요청받은 객체를 무조건 생성해야 한다.
  202	Accepted	요청은 정상적으로 수신하였으나, 서버가 그에대한 동작을 하지 않은 상태
  203	Non-Authoritative Information	리소스에 대한 메타정보(헤더)를 검증하지못해 발생하는 코드
  204	No Content	응답메시지가 헤더와 상태를 포함하지만 본문은 포함하지 않는경우, 폼 리프레시에 주로 사용
  205	Reset Content	브라우저에게 현재 페이지의 HTML 폼에 채워진 모든 값을 비우게 한다.
  206	Partial Content	부분 또는 범위 요청에 대한 성공

클라이언트 에러 상태 코드 : 400-499

• 클라이언트는 가끔 서버가 다룰 수 없는 무엇인가를 요청 한다.

• 클라이언트 에러 코드의 세부 명세

  상태코드	사유구절	의미
  400	Bad Request	클라이언트가 잘못된 요청을 보냈다고 말해준다.
  401	UnAuthorized	리소스 응답 전, 클라이언트에게 스스로에 대한 인증을 요구
  403	Forbidden	요청이 서버에 의해 거절되었음을 알려준다.<p>거절의 이유는 숨길수 있다.</p>
  404	Not Found	서버가 요청받은 URL 을 찾을 수 없음을 알려준다.
  405	Method Not Allowed	요청받은 Method에 대해, 지원하지 않는 요청임을 알려준다.

• 위의 것 외에도 클라이언트 에러 코드는 정말 많은데, 나중에 한번 쫙 기술해놓겠다.

서버 에러상태 코드 : 500-599

• 클라이언트가 올바른 요청을 보냈음에도, 서버자체에서 에러가 발생하는 경우가 있다.

상태코드	사유구절	의미
500	Internal Server Error	서버가 요청을 처리할 수 앖게 만드는 에러를 만났을 때 사용
501		Not Implemented	클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용
502	Bad Gateway	<p>프록시나 게이트웨이 처럼 행동하는 서버가</p><p>요청 응담 연쇄에있는 다음 링크로 부터 가짜응답을 접했을때 사용 한다.</p>
503	Service Unavailable	현재는 서버가 처리할 수 없지만, 나중에 처리가 가능함을 의미할때 사용
504	Geteway Timeout	다른 서버에 요청을 보내고 응답 대기시간을 초과한 경우에 발생, 주체는 게이트웨이나 프록시 이다.
505	HTTP Version Not Supported	서버가 지원할수 없거나, 지원하지 않으려고 하는 버전의 프로토콜로 요청을 받았을 때 사용한다.

• 실제로 505 코드를 업무중에 맞닥뜨린적이 있는데 그에 대해 맨 밑에 작성하겠다.

헤더

• 헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기위해 함께 사용된다.

요청 헤더

• 요청하는 사용자(주로 클라이언트) 가 요청 메세지를 보낼때 사용하는 헤더에 대해 기술한다.

일반헤더

• 메시지에 대한 아주 기본적인 정보를 제공한다.
• 메시지가 어떤 종류이든 상관없이 유용한 정보를 제공한다.

헤더	설명
Connection	클라이언트와 서버가 요청 및 응답 연결에 대한 옵션을 정할 수 있게 해준다.
Date	메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공한다.
MIME-Version	발송자가 사용한 MIME의 버전을 알려준다.
Trailer Chunked transfer	인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열한다.
Transfer-Encoding	안전한 전송을 위해, 메시지에 어떤 인코딩이 적용되었는지 알려준다.
Upgrade	발송자가 업그레이드하길 원하는 새버전이나 프로토콜을 알려준다.
Via	메시지가 어떤 중개자(게이트웨이, 프록시)를 거쳐왔는지 보여준다.

일반 캐시 헤더

• 로컬 복사본으로 캐시할 수 있도록 해주는 헤더
• HTTP/1.0 이상 부터 도입되었다.
• 최신 버전의 HTTP 는 매우 풍부한 캐시 매개변수 집합을 가지고 있다.

헤더	설명
Cache-Control	메시지와 함께 캐시 지시자를 전달하기위해 사용된다.
Pragma	메시지오 ㅏ함께 지시자를 전달하는 또 다른 방법이다. 캐시에 국한되지 않는다.

요청 헤더

• 요청 메시지에서만 의미를 갖는다.
• 클라이언트의 정보나 능력치에 대한 정보를 준다.
• 서버는 요청 헤더의 정보를 기반으로 더 나은 응답을 주기위해 사용할 수 있다.

헤더	설명
Client-IP	클라이언트 컴퓨터의 IP 주소를 제공
From	클라이언트 사용자의 메일주소 제공
Host	요청의 대상이 되는 서버의 호스트명과 포트를 제공
Referer	현재의 요청 URI가 들어있었던 문서의 URL을 제공
UA-Color	클라이언트 기기의 색상능력에 대한 정보 제공
UA-CPU	클라이언트 기기의 CPU 종류나 제조사를 제공
UA-Disp	클라리언트 기기의 디스플레이능력에 대한 정보를 제공
UA-OS	클라이언트 기기에서 동작중인 운영체제의 이름과 버전을 제공
UA-Pixels	클라이언트 긱ㅣ디스플레이에 대한 픽셀정보를 제공
User-Agent	요청을 보낸 애플리케이션의 이름을 제공

• 요청 헤더는 확실히 클라이언트 의 정보에 대해 많은 것을 제공하는 것을 확인할 수 있다.
• SSR (Server Side Rendering) 시에는 이런 요청헤더를 가지고 최적화된 렌더링을 제공하는 것인지 궁금해졌다.

Accept 관련 헤더

• 클라이언트는 Accept 관련 헤더 를 통해 서버에게 클라이언트의 선호와 능력을 알려줄 수 있다.
• 원치 않는 것 또한 서버에게 알려줄수 있다.
• 서버는 이 정보를 통해 무엇을 보낼것인가에 대한 최적화된 결정을 내릴수 있도록 해야한다.
• Accept 관련 헤더 는 서버와 클라이언트 모두에게 유익한 헤더이다.

헤더	설명
Accept	서버에게 서버가 보내도 되는 미디어 종류를 말해준다.
Accept-Charset	서버가 보내도 되는 문자 집합을 말해준다.
Acceot-Encoding	서버가 보내도 되는 인코딩을 말해준다.
Accept-Language	서버가 보내도 되는 언어를 말해준다.
TE	서버가 보내도 되는 확장 전송 코딩을 말해준다.

• Accept 관련 헤더 는 확실히 서버 가 받는 정보인것을 알 수 있다.
• 요청하는 클라이언트의 선호응답 알려주기 위해 필히 사용하는 것이 좋을 것 같다.

요청 보안 헤더

• HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있다.
• 클라이언트가 리소스에 접근하기전에 자신을 인증하여 트랜잭션을 안전하게 하는데 목적이 있다.

헤더	설명
Authorization	클라이언트가 서버에서 제공하는 인증 그 자체에 대한 정보를 담고 있다.
Cookie	클라이언트가 서버에게 토큰을 전달할 때 사용한다. 온전한 보안 헤더는 아니지만, 보안에 충분히 영향을 줄수 있다.
Cookie2	요청자가 지원하는 쿠키의 버전을 알려줄때 사용

응답 헤더

• 응답 메세지는 반드시 응답 헤더를 갖는다.

• 응답 헤더는 클라이언트가 응답을 잘 다루고 더 나은 요청을 할 수 있도록 도와준다.

• 기본 응답 헤더

헤더	설명
Age	응답 소요 시간
Public	서버가 특정 리소스에 대해 지원하는 요청 Method의 목록
Retry-After	현재 리소스가 사용불가능한 상태일 때 사용, 언제 가능한지에 대한 날짜 또는 시간
Server	서버 애플리케이션의 이름과 버전
Title	HTML 문서에서 주어진 것과 같은 제목
Warning	사유 구절보다 더 자세한 메세지를 담는다.

응답 보안 헤더

• 요청 보안 헤더 에 대한 응답 헤더 이다.

헤더	설명
Proxy-Authenticate	프락시에서 클라이언트로 보낸 인증요구 목록
Set-Cookie	온전한 보안헤더는 아니다, 다만 보안에 충분히 영향을 줄 수 있다.<p>서버가 클라이언트를 인증 할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용</p>
Set-Cookie2	Set-Cookie 와 비슷하게 RFC 2965로 정의된 쿠키
WWW-Authenticate	서버에서 클라이언트로 보낸 인증 요구의 목록

엔터티 헤더

• 메시지의 수신자에게 서버가 다루고 있는것이 무엇인지 말해준다.

헤더	설명
Allow	이 엔터티에 대해 수행될 수 있는 요청 메서드를 나열
Location	클라이언트에게 엔터티가 실제로 어디에 위치하고 있는지 말해준다.

콘텐츠 헤더

• 엔터티 헤더 에 대한 구체적인 정보를 제공한다.

헤더	설명
Content-Base	본문에서 사용된 상대 URL을 계산하기 위한 기저 URL
Content-Encoding	본문에 적용된 인코딩
Content-Language	본문을 이해하는데 가장 적절한 자연어
Content-Length	본문의 길이 또는 크기
Content-Location	리소스의 실제 위치
Content-MD5	본문의 MD5 체크섬(Checksum)
Content-Range	전체 리소스에 대해 응답하는 엔터티가 해당하는 범위를 바이트 단위로 표현
Content-Type	본문이 어떤 종류의 객체인지에 대한 정보

느낀점

• 네트워크 응답과 요청사이에 이렇게 많은 정보가 필요한지 처음알게 되었다.
• 메세지 하나를 전송하는데도 상당히 세부적인 수준의 정보가 클라이언트와 서버에게 필요한것 같다.
• 옛날에 505 상태 코드를 만난적이 있는데, 내가 설치한 서버와 접속하고자 하는 클라이언트의 프로토콜 버전이 맞지 않았었던 것이 기억났다. 그래서 다 밀고 다시 설치했었다 ㅎㅎ
• 네트워크를 자세히 공부하다보니 클라이언트와 서버 사이드에 대한 이해도도 같이 더 증가하는 것 같다.