HTTP의 이해

HTTP의 기본적인 방식과구조에 대해서 정리한 내용입니다.

HTTP(Hypertext Transfer Protocol)

HTTP라는 이름에서 알 수 있듯이 Hypertext 문서를 전송(transfer)하기 위한 규약(Protocol)이다. 규약이 필요한 이유는 간단하다. HTTP통신을 사람 간의 대화라고 생각한다면, 나와 대화할 사람과 일단 만나서 서로를 확인해야 하고, 서로 이해할 수 있는 방식을 사용해야 할 것이다. 그리고이런 조건과 규약들을 흔히 프로토콜이라고 부른다.

HTTP와 HTTPS의 차이(TLS)

가장 큰 차이라고 한다면, TLS를 사용여부라고 할 수 있다.

클라이언트-서버 모델

어떤 리소스에 대하여 요청자와 제공자의 관계라고 이해할 수 있다. 클라이언트는 리소스를 요청하는 역할인데 이때 요청은 url을 통해 이뤄지게 된다.

stateless와 stateful

HTTP의 요청은 각각이 독립적이며 연속적이지 않다. 때문에 요청마다 알려줘야 한다. state를 알려주기 위한 방법은

  1. 요청과 응답을 통해 주고받는 쿠키 방식

  2. 서버에서 관리하는 쿠키 등으로 key를 관리하는 세션 방식

  3. 웹 브라우저에서 제공하는 기능(localStorage 등)

HTTP Cookie와 HTTP Session

HTTP Cookie는 클라이언트의 상태를 서버에 전달하기 위해 저장하는 수단으로 사용되며, HTTP Session의 경우에는 쿠키와 공유하는 key를 서버에서 자체적으로 저장하기 위해서 사용한다. 둘의 차이는 Cookie의 경우에는 비교적 공개적인 저장소이기 때문에 민감한 정보나 보안이 필요한 정보는 저장해선 안되지만, 세션의 경우에는 서버에서만 보관하기 때문에 비교적 보안적으로 안전하다. 쿠키와 세션은 기능적으로 밀접한 관련이 있는데, 서로 값을 주고받으며 클라이언트의 상태를 주고받는 경우가 많기 때문이다.

HTTP 메시지 구조

  • 클라이언트와 서버 간에 주고받는 내용이다.

  • HTTP에서는 사람이 읽을 수 있는 형태로 주고받게 된다. 사람이 읽을 수 있기 때문데 얻는 이득 중의 하나는 디버깅이 쉬워진다는 점이 있다. 스트리밍과 같은 binary 통신은 사람이 읽기 힘든 형태로 주고받게 된다. binary가 효율이 더 좋은 편이지만, HTTP에서는

  • 요청과 응답의 구조가 거의 동일하다.

    • start line : method, url, protocol

    • headers : 헤더정보

    • 빈 줄

    • body

      • 요청에서는 없을 수 있지만, 응답에서는 body가 필수적이다.

      • 응답에서의 body의 크기는 매 응답마다 사이즈를 알 수가 없다.

      • 이것은 언제 전송이 종료되는지에 대한 판단을 어렵게 할 수 있는데, 이를 해결하기 위해서 header에 Contetn-Length라는 항목을 추가하여 body사이즈를 알 수 있도록 해준다.

      • 꼭 사람이 읽어야 하는 형태일 필요가 없다. 왜냐하면, 이미지나 영상과 같은 바이너리 형태의 파일전송도 가능하기 때문이다.

      • 한번에 전송할 수 있는 파일의 갯수도 여러개일 수가 있는데, 이런 파일 업로드에 쓰이는 형태가 multipart/form-data이다.

HTTP 요청(Reuqest)와 응답(Response)

HTTP 요청 메서드(HTTP request methods)

  • header의 첫째줄에 요청 메서드 정보가 들어간다.

  • GET(READ)

    • 멱등성이 보장돼야 한다. 멱등성은 동일한 요청에 대해서 동일한 결과값이 나오는 성질을 말한다.

    • a라는 이미지를 요청헀지만, 첫번째 요청과 두번째 요청의 값이 다르다면 멱등성이 보장되지 않는다는 의미이다.

  • HEAD(GET without body)

    • body없이(응답의 내용없이) 요청하고 싶은 경우에 사용한다.

    • 캐시만료 여부, 권한확인 여부, 서버의 상태 체크 등의 용도로 사용할 수 있다.

  • POST

    • GET과는 다르게 멱등성이 보장되지 않는다.

    • 예를들어, 회원가입을 최초로 하게 된다면 "회원가입 성공"이라는 메시지를 응답으로 받을 수 있겠지만, 두번째 가입을 시도한다면 첫번째 응답과는 달리 "이미 가입된 정보입니다"라는 응답을 받을 수 있다.

    • Collection Pattern에서 Create로 사용한다.

  • DELETE : 삭제

  • OPTIONS : 헤더정보, 가능 메서드 정보 등의 여러가지 지원 요소들을 확인할 수 있다. ajax요청을 보면 options가 먼저 요청되는 것을 볼 수 있다.

  • PUT

    • 리소스를 수정할 때, 일부가 아닌 전체를 변경한다. overwrite와 비슷하다.

    • overwrite = update (+create)

  • PATCH

    • 부분적으로 update가 가능하다

  • PUT과의 차이점

    • PUT 메서드에서의 update는 요청에 포함된 데이터로 overwrite하기 때문에, 포함된 데이터 정보를 그대로 덮어쓰기한다.

    • PATCH 메서드의 경우는 덮어쓰기할 모든 데이터를 보내지 않더라도, 일부분만 보낸다면 그 부분만 변경된다.

    • 예) 이름 : 아이언맨, 나이 : 30세, 성별 : 남자 <- 이 데이터에서 이름만 스파이더맨으로 변경하려고 한다면 보내야하는 데이터는 메서드별로 아래와 같다.

    • PUT

      • 이름 : 스파이더맨, 나이 : 30세, 성별 : 남자

    • PATCH

      • 이름 : 스파이더맨

HTTP 응답 상태 코드(HTTP response status code)

  1. 1xx → 정보 ⇒ 우리가 직접 쓰는 일은 드믐.

  2. 2xx → 성공 ⇒ 200 OK, 201 Created, 204 No Content

  3. 3xx → 리다이렉션 ⇒ 304 Not Modified가 특수한 형태로 자주 보임.

  4. 4xx → 클라이언트 쪽 문제 ⇒ 404 Not Found

  5. 5xx → 서버 쪽 문제 ⇒ 500 Internal Server Error

멱등성

  • https://developer.mozilla.org/ko/docs/Glossary/Idempotent

  • 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말한다.

  • 올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지며, POST 메서드는 그렇지 않다. 모든 안전한 메서드는 멱등성도 가진다.

리다이렉션

  • https://developer.mozilla.org/ko/docs/Web/HTTP/Redirections

  • URL 리다이렉션 혹은 URL 포워딩은 페이지 단위의 실제 리소스, 폼 혹은 전체 웹 애플리케이션이 다른 URL에 위치하고 있는 상태에서 링크를 존속시키는 기술입니다. HTTP는 많은 목표를 위해 사용되는 이런 동작을 수행하기 위해 특별한 종류의 응답인 HTTP 리다이렉트를 제공한다.

  • HTTP 리다이렉트는 3xx 상태 코드를 지닌 응답.

  • 대부분의 경우, 리다이렉션은 사용자에게는 보이지 않는데다가, 적은 성능 저하를 일으킴

  • 특수 리다이렉션

    • 304 (수정되지 않음)은 (오랜된)로컬에 캐시된 복사본으로 페이지를 리다이렉트 시킨다.

PreviousREADMENextHTTP client

Last updated