Code States/TIL

[0316] 웹서비스 개발 기초 - HTTP 기초

ki1111m2 2023. 3. 16. 15:58

학습 목표

HTTP의 기본적인 내용을 학습할 수 있다.

  • HTTP messages의 구조를 설명할 수 있다.
  • HTTP의 동작 방식을 이해할 수 있다.
  • HTTP requests와 responses를 구분할 수 있다.
  • HTTP의 응답 메시지를 찾아볼 수 있다.

HTTP 기초


  • HyperText Transfer Protocol
  • HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜
  • 웹 브라우저와 웹 서버의 소통을 위해 디자인됨
  • 전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면, 서버도 HTTP messages 양식에 맞춰 응답함
  • Stateless(무상태성)
    • HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않음
    • HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않음

HTTP Messages


  • 클라이언트와 서버 사이에서 데이터가 교환되는 방식
  • start line: 요청이나 응답의 상태를 나타내며 항상 첫 번째 줄에 위치함(응답에서는 status line이라고 부름)
  • HTTP headers: 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
  • empty line: 헤더와 본문을 구분하는 빈 줄
  • body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함하며, 요청과 응답의 유형에 따라 선택적으로 사용함
  • 요청(Request)
    • Start line
      • 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냄
      • 요청 대상(일반적으로 URL or URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에서 작성되며, 이 요청 형식은 HTTP method 마다 다름
        • origin 형식: ?와 쿼리 문자열이 붙는 절대 경로. POST, GET, HEAD, OPTIONS 등의 method와 함께 사용함
        • absolute 형식: 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용함
        • authority 형식: 도메인 이름과 포트 번호로 이루어진 URL의 authority component. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있음
        • asterisk 형식: OPTIONS와 함께 별표 하나로 서버 전체를 표현함
      • HTTP 버전에 따라 HTTP message의 구조가 달라지므로, start line에 HTTP 버전을 함께 입력함
    • Headers
      • 기본 구조: 헤더 이름(대소문자 구분이 없는 문자열), 콜론, 값
        • General headers: 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더
        • Request headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더로, User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화하고 Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있음
        • Representation headers: 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더
    • Body
      • 요청의 본문은 HTTP messages 구조의 마지막에 위치함
      • 모든 요청에 body가 필요하지는 않음
        • GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우 등
      • Single-resource bodies(단일-리소스 본문): 헤더 두개(Content-Type & Content-Length)로 정의된 단일 파일로 구성됨
      • Multiple-resource bodies(다중-리소스 본문): 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지니며, 보통 HTML form과 관련이 있음
  • 응답(Responses)
    • Status line
      • 현재 프로토콜의 버전
      • 상태 코드 - 요청의 결과
      • 상태 텍스트 - 상태 코드에 대한 설명
    • Headers
      • 요청 헤더와 동일한 구조를 가지고 있음
        • General headers: 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더
        • Response headers: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vart, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공함
        • Representation headers: 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더
    • Body
      • 요청의 본문은 HTTP messages 구조의 마지막에 위치함
      • 모든 요청에 body가 필요하지는 않음
        • 201, 204와 같은 상태 코드를 가지는 응답 등
      • Single-resource bodies(단일-리소스 본문)
        • 길이가 알려진 단일-리소스 본문: 헤더 두개(Content-Type & Content-Length)로 정의
        • 길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding이 chunked로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있음
      • Multiple-resource bodies(다중-리소스 본문): 서로 다른 정보를 담고 있는 body

Must know concepts


  • HTTP 요청 메서드
    • GET: 특정 리소스의 표시를 요청하며 오직 데이터를 받기만 함
    • HEAD: GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않음
    • POST: 특정 리소스에 엔티티를 제출할 때 쓰이며 종종 서버 상태의 변화나 부작용을 일으킴
    • PUT: 목적 리소스 모든 현재 표시를 요청 payload로 바꿈
    • DELETE: 특정 리소스 삭제
    • CONNECT: 목적 리소스로 식별되는 서버로의 터널을 맺음
    • OPTIONS: 목적 리소스의 통신을 설정하는 데 쓰임
    • TRACE: 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 함
    • PATCH: 리소스의 부분만을 수정하는 데 쓰임
  • HTTP 메시지
    • 요청: 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지
    • 응답: 요청에 대한 서버의 답변
    • ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어있음
    • HTTP 프로토콜 초기 버전과 HTTP/1.1에서는 클라이언트와 서버 사이의 연결을 통해 공개적으로 전달되어 사람이 읽을 수 있었으나 HTTP/2에서는 최적화와 성능 향상을 위해 HTTP 프레임으로 나누어짐
    • 웹 개발자, 웹 마스터가 직접 HTTP 메시지를 텍스트로 작성하는 경우는 드물며 소프트웨어, 브라우저, 프록시, 웹 서버가 작성함
    • 설정 파일(프록시 혹은 서버의 경우), API(브라우저의 경우), 다른 인터페이스를 통해 제공됨
    • HTTP/2의 이진 프레이밍 매커니즘(binary framing mechanism)은 사용중인 API나 설정 파일 등을 변경하지 않아도 되도록 설계 되었기 때문에 사용자가 보고 이해하기 쉬움
  • HTTP/2 프레임
    • HTTP/1.x 메시지는 성능강의 결함 몇가지를 내포하고 있음
      • 본문은 압축이 되지만 헤더는 압축이 되지 않음
      • 연속된 메시지들은 비슷한 헤더 구조를 띄기 마련인데, 그럼에도 불구하고 메시지마다 반복되어 전송됨
      • 다중전송(multiplexing)이 불가능하며 서버 하나에 연결을 여러게 열어야 함
    • HTTP/1.x 메시지를 프레임으로 나누어 스트림에 끼워 넣는 추가적인 단계를 도입함
    • 데이터와 헤더 프레임이 분리 되었기 때문에 헤더를 압축할 수 있음
    • 스트림 여러 개를 하나로 묶을 수 있어서(멀티플렉싱) 기저에서 수행되는 TCP 연결이 좀 더 효율적이게 이루어짐
  • HTTP 상태코드
    • 특정 HTTP 요청이 성공적으로 완료되었는지 알려줌
    • 정보 응답
      • 100 Continue: 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려줌
      • 101 Switching Protocol: 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려줌
      • 102 Processing: 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려줌
      • 103 Early Hints: 주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트(user agent)가 사전 로딩(preloading)을 시작할 수 있도록 함
    • 성공 응답
      • 200 OK: 요청이 성공적으로 되었음
        • GET: 리소스를 불러와서 메시지 바디에 전송됨
        • HEAD: 개체 헤어가 메시지 바디에 있음
        • PUT or POST: 수행 결과에 대한 리소스가 메시지 바디에 전송됨
        • TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있음
      • 201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됨
        • 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옴
      • 202 Accepted: 요청을 수신하였지만 그에 응하여 행동할 수 없음
        • 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않음
        • 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어짐
      • 203 Non-Authoritative Information: 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 하티 복사본에서 모아졌음을 의미
        • 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선함
      • 204 No Content: 요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있음
        • 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있음
      • 205 Reset Content: 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줌
      • 206 Partial Content: 클라이언트에서 복수의 스트림을 분할 다운로드 하고자 범위 헤더를 전송했기 때문에 사용됨
      • 207 Multi-Status: 여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달함
      • 208 Already Reported: DAV에서 사용되며, propstat 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됨
      • 226 IM Used: 서버가 GET 요청에 대한 리소스의 의무를 다 했고, 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용 되었음을 알려줌
    • 리다이렉션 메시지
      • 300 Multiple Choice: 요청에 대해서 하나 이상의 응답이 가능하며 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야 함
      • 301 Moved Permanetly: 요청한 리소스의 URI가 변경되었음을 의미하며, 새로운 URI가 응답에서 주어질 수 있음
      • 302 Found: 요청한 리소스의 URI가 일시적으로 변경도었음을 의미하며 새롭게 변경된 URI는 나중에 만들어질 수 있으므로 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야함
      • 303 See Other: 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때 서버가 클라이언트로 직접 보내는 응답
      • 304 Not Modifide: 캐시를 목적으로 사용되며 클라이언트에게 응답이 수정되지 않았음을 알려줌
      • 305 Use Proxy: 이전 버전의 HTTP 기술 사양에서 정의되었으며, 요청한 응답은 반드시 프록시를 통해서 접속해야 하는 것을 알려줌
      • 306 Unused: 더이상 사용되지 않으며, 현재는 추후 사용을 위해 예약되어 있음
      • 307 Temporary Redirect: 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야 할 때 서버가 클라이언트에 이 응답을 직접 보냄
        • 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다름
      • 308 Permanent Redirect: 리소스가 이제 HTTP 응답 헤더의 Location에 명시된 영구히 다른 URI에 위치하고 있음을 의미함
        • 301 Moved Permanently HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 한다는 점만 다름
    • 클라이언트 에러 응답
      • 400 Bad Request: 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음
      • 401 Unauthorized: “비인증” 요청한 응답을 받기 위해 클라이언트 스스로 반드시 인증을 해야 함
      • 402 Payment Required: 나중에 사용될 것을 대비해 예약됨
      • 403 Forbidden: 콘텐츠에 접근할 권리를 가지고 있지 않음
      • 404 Not Found: 요청받은 리소스를 찾을 수 없음
        • 브라우저에서는 알려지지 않은 URL을 의미함
      • 405 Method Not Allowed: 요청한 메소드는 서버에서 알고있지만, 제거되었고 사용할 수 없음
      • 406 Not Acceptable: 서버가 서버 주도 콘텐츠 협상을 수행한 이후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을 때 웹 서버가 보냄
      • 407 Proxy Authentication: 401과 비슷하지만 프록시에 의해 완료된 인증이 필요함
      • 408 Request Timeout: 요청한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 하며, 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미함
      • 409 Conflict: 요청이 현재 서버의 상태와 충돌될 때 보냄
      • 410 Gone: 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보내며, 클라이언트가 그들의 캐쉬와 리소스에 대한 링크를 지우기를 기대함
      • 411 Length Required: 서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔을 때 서버가 요청을 거절
      • 412 Precondition Failed: 클라이언트의 헤더에 있는 전제조건이 서버의 전제조건에 적절하지 않음
      • 413 Payload Too Large: 요청 엔티티가 서버에서 정의한 한계보다 큼
        • 서버는 연결을 끊거나 Retry-After 헤더 필드를 돌려보낼 것임
      • 414 URI Too Long: 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 긺
      • 415 Unsupported Media Type: 요청한 미디어 포맷은 서버에서 지원하지 않으며 서버는 해당 요청을 거절함
      • 416 Requested Range Not Satisfiable: Range 헤더 필드에 요청한 지정 범위를 만족시킬 수 없음
        • 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있음
      • 417 Expectation Failed: Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음
      • 418 I’m a teapot: 서버는 커피를 찻 주전자에 끓이는 것을 거절함
      • 421 Misdirected Request: 서버로 유도된 요청은 응답을 생성할 수 없음
        • 서버에서 요청 URI와 견결된 스킴과 권한을 구성하여 응답을 생성할 수 없을 때 보내짐
      • 422 Unprocessable Entity: 요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없음
      • 423 Locked: 리소스는 접근하는 것이 잠겨있음
      • 424 Failed Dependency: 이전 요청이 실패하였기 때문에 지금의 요청도 실패함
      • 426 Upgrade Required: 지금이 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 다른 프로토콜로 업그레이드를 하면 처리를 할 수도 있음
      • 428 Precondition Required: 오리진 서버는 요청이 조건적이어야 함
        • 클라이언트가 리소스를 가지고왔다가 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 ‘업데이트 상실’을 예방하기 위한 목적
      • 429 Too Many Requests: 사용자가 지정된 시간에 너무 많은 요청을 보냄
      • 431 Request Header Fields Too Large: 요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않음
      • 451 Unavailable For Legal Reasons: 사용자가 요청한 것은 정부에 의해 검열된 웹 페이지와 같은 불법적인 리소스임
    • 서버 에러 응답
      • 500 Internal Server Error: 서버가 처리 방법을 모르는 상황 발생
      • 501 Not Implemented: 요청 방법은 서버에서 지원되지 않으므로 처리할 수 없음
      • 502 Bad Gateway: 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신함
      • 503 Service Unavailable: 서버가 요청을 처리할 준비가 되지 않음
        • 일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸렸을 때
      • 504 Gateway Timeout: 서버가 게이트웨이 역할을 하고 있으며 적ㅅ에 응답을 받을 수 없을 때 주어짐
      • 505 HTTP Version Not Supported: 요청에 사용된 HTTP 버전은 서버에서 지원되지 않음
      • 506 Variant Also Negotiates: 서버에 내부 구성 오류가 있음
        • 요청을 위한 투명한 컨텐츠 협상이 순환 참조로 이어짐
      • 507 Insufficient Storage: 서버에 내부 구성 오류가 있음
        • 선택한 가변 리소스는 투명한 컨텐츠 협상에 참여하도록 구성되므로 협상 프로세스의 적절한 종료 지점이 아님
      • 508 Loop Detected: 서버가 요청을 처리하는 동안 무한 루프를 감지함
      • 510 Not Extended: 서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요함
      • 511 Network Authentication Required: 클라이언트가 네트워크 액세스를 얻기 위해 인증을 받아야 할 필요가 있음

출처

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages