HTTP(HyperText Transfer Protocol)

BANGJH·2020년 1월 30일
0

TIL

목록 보기
2/5

HTTP란?

클라이언트와 웹 서버간에 데이터를 주고 받는 것을 텍스트 기반으로 하겠다는 약속이다.
이렇게 약속했기 때문에 모든 프로그램이 이에 맞춰 개발하고 정보를 교환한다.

웹에서만 사용하는 것으로 TCP/IP기반으로 한 지점에서 다른 지점으로 요청과 응답을 전송.

웹서버란?

웹서버는 하드웨어, 소프트웨어 혹은 두 개 모두를 의미할 수 있다.

-하드웨어적 측면
웹서버는 웹사이트의 컴포넌트 파일들을 저장하는 컴퓨터.
(컴포넌트 파일은 HTML문서, images, CSS, JS 파일등이 있다)
그리고 이 파일들을 최종 소비자의 디바이스에 전달.
웹서버는 인터넷에 연결되어 있고, 도메인 네임을 통해 접속한다.

-소프트웨어적 측면
웹서버는 기본적으로 웹 사용자가 어떻게 호스트 파일들에 접근하는지를 관리.
브라우저가 웹 서버에서 불려진 파일을 필요로 할 때, 브라우저는 HTTP를 통해 파일을 요청.
요청이 올바른 웹 서버(하드웨어)에 도달하였을 때, HTTP 서버(software)는 요청된 문서를 HTTP를 이용해 보내준다.

HTTP의 비연결성이란?

클라이언트와 서버가 한 번 연결을 맞은 후,
클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질이다.

비연결성 장점

HTTP는 왜 한 번 맺은 연결을 끊어버릴까?
HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다.
만약 서버에서 다수의 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 된다.
따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있으므로 비연결성을 갖는다.

비연결성 단점

서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해,
매번 연결(socket(port))을 시도/해제의 과정을 거쳐야하는 단점이 있다.

위의 문제에 대한 해결책으로 HTTP의 KeepAlive 속성을 사용할 수 있다.

KeepAlive란?

정의된 시간 내(Keep Alive time out)에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있는 속성.
http에서 생각하면 Keep Alive time out내에 client가 request를 재 요청하면 연결(socket(port))을 새로 시도하는게 아니라 이미 열려(socket(port))있는 곳에 연결한다.

요청(request)이란?

클라이언트가 웹 서버에 연락하는 것을 요청이라고 한다.
요청을 보낼 때는 요청에 대한 정보를 담아서 보낸다.

요청의 종류

  • GET : 자료를 요청할 때
  • POST : 자료의 생성을 요청할 때
  • PUT : 자료의 수정을 요청할 때
  • DELETE : 자료의 삭제를 요청할 때

요청의 정보(헤더)

  • Host
    - 서버의 도메인 네임(반드시 존재해야함)

  • User-Agent
    - 어떤 사용자가 어떤 클라이언트를 통해 요청을 보냈는지

  • Accept
    - 클라이언트가 허용할 수 있는 파일 형식(MIME TYPE)

    • 여러 타입을 콤마(,)로 동시에 적어줄 수도 있고 *로 텍스트면 다 좋아라고 할 수도 있다.
  • Cookie
    - 웹 서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의 정보를 이름-값 쌍으로 웹 서버에 전송한다.

  • Origin
    - POST같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지를 나타낸다. 이때 보낸 주소와 받는 주소가 다르면 CORS문제가 발생하기도 한다.

  • Upgrade-Insecure-Requests

  • Cache-Control
    .
    .

CORS(cross-origin resource sharing)란?

서로 다른 사이트라도 Http Request를 가능하게 하는 규약이다.
HTTP 요청은 기본적으로 Cross-Site Http Requests가 가능하지만 자바스크립트(Fetch API,XMLHttpRequest) 로 다른 웹페이지에 접근할 때는 Same Origin Policy로 인해 요청이 불가능하다.

이러한 API를 사용하는 응용 프로그램들은 올바른 CORS헤더가 포함된 다른 출처로 부터의 응답을 제외하고 동일한 출처의 리소스만 요청할 수 있다.

즉, 자바스크립트 내에서 발생하는 Cross-Site Http Requests는 프로토콜, 호스트, 포트가 같아야지 요청이 가능하다.

하지만 외부 호출이 많아지고 여러 도메인에 대규모로 구성되는 웹 프로젝트가 많아 지면서 Same Origin Policy가 불편하게 되는데 그래서 웹 브라우저에서 외부 도메인 서버와 통신하기 위한 방식을 표준화한 스펙이 CORS이다.

포트번호?

두 대 이상의 컴퓨터가 통신을 할 때 데이터를 목적지까지 전달해주는 것은 IP주소에 의해 결정이 되고
목적지 서버에 도달한 정보를 어느 응용프로그램에서 처리해 줄 것인지를 결정하는데 사용하는 것이 바로 포트번호.

응답(response)이란?

서버가 요청에 대한 응답을 클라이언트로 보내는 것

응답 헤더
  • Server
    - 웹 서버 정보
  • Access-Control-Allow-Origin
    - 요청 Host와 응답 Host가 다르면 CORS에러가 발생하는데 서버에서 응답 메시지 Access-Control-Allow-Origin헤더에 프론트 주소를 넣어주면 발생하지 않음.
  • Allow
    - ex) Allow:GET : GET요청만 받겠다.

무상태(Stateless)이란?

위의 비연결성으로 인해 서버는 클라이언트를 식별할 수가 없다. 이를 무상태(Stateless)라고 한다.

식별할 수 없다는 것은 예를 들어 네이버로 생각하면 메인페이지에서 로그인을 한 다음 어떠한 배너를 클릭해서 다른 페이지로 갔을 때 로그인이 유지가 안 된다는 것이다. 왜냐하면 현재 클라이언트를 식별할 수 없기 때문이다.

이러한 문제를 해결하기 위해 나온 것이 쿠키, 세션, JWT, OAuth등이 다.

쿠키(Cookie)란?

위에서 말한 클라이언트의 상태를 식별할 수 없는 것을 해결하기 위해 나온 기술.

클라이언트(브라우저)측에서 관리되는 기록 정보 파일이다.
쿠키에는 유효한 인증 시간을 명시할 수 있으며 시간이 정해지면 브라우저를 끄더라도 인증은 유지된다.

쿠키의 구성요소

  • Name
    - 각각의 쿠키를 구별할 이름

  • Value

    • 쿠키의 저장된 값
  • Expires
    - 쿠키의 유지 시간

    • ex) expires="Wdy, DD−Mon−YYYY HH:MM:SS GMT"
      • 쿠키에 만료일이 포함되있으면 영구적 쿠키로 간주
        • Max-Age를 통해 지정된 만료일이 되면 디스크에서 쿠키가 제거
  • Domain
    - 쿠키가 사용되는 도메인을 지정

    • ex) domain=nesoy.github.io
      • 이 값이 현재 도메인과 일치하지 않을 경우 브라우저에서 거부.
  • Path
    - 쿠키를 반환할 경로

    • ex) path=/
      • 도메인의 루트 경로로 이동할 경우 쿠키가 전송

쿠키의 흐름

1) 클라이언트가 웹 서버에 페이지를 요청
2) 요청할 때 쿠키가 없으면 웹 서버는 쿠키를 생성하고 HTTP 헤더에 쿠키를 포함시켜 응답
3) 요청할 때 쿠키가 있으면 쿠키를 HTTP 헤더에 포함시켜 요청
4) 웹 서버에서 쿠키를 읽어서 이전 상태 정보를 변경할 필요가 있을 경우 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답.

세션(Session)이란?

세션은 쿠키를 기반으로 하고 있지만 쿠키와는 달리 클라이언트(브라우저)가 아닌 서버 측에서 관리한다.
session-id로 식별자로 클라이언트를 구분.
session-id는 웹 서버와 클라이언트의 메모리에 저장된다.
이때 클라이언트 메모리에 사용되는 쿠키 타입은 세션 종료시에 종료되는 'Memory Cookie'가 사용된다.

세션 흐름

1) 클라이언트가 웹서버에 접속을(http 요청) 시도한다

2) 웹 서버는 접근한 클라이언트의 request-field인 cookie를 확인해 클라이언트가 session-id를 보내왔는지 확인한다.

3) 만약 클라이언트에서 보내온 session-id가 없다면, 웹 서버는 session-id를 생성해 클라이언트에 response-field인 set-cookie값으로 session-id를 발행한다.

4) 서버로부터 발행된 session-id는 웹 서버와 클라이언트 메모리에 저장된다. 클라이언트 메모리에 사용되는 쿠키 타입은 세션 종료시에 같이 소멸되는 "Memory Cookie"가 사용된다.

생각해봐야 할 것

  • 보통 웹 서버를 트래픽 분산 때문에 병렬로 구성하게 되는데 이를 로드 밸런싱을 통해 여러 서버로 분산 처리를 하게 되는데 session-id를 그러면 어떻게 처리하는 걸까?

    	- 병렬로 처리된 여러 서버들이 동일한 세션 정보를 가지도록 동기화 하는 과정이 필요하다.
profile
안녕하세요 신입 웹개발자입니다.

0개의 댓글