Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HTTP 웹 기본 지식 - 7 #39

Closed
Brandnew-one opened this issue Jun 18, 2023 · 1 comment
Closed

HTTP 웹 기본 지식 - 7 #39

Brandnew-one opened this issue Jun 18, 2023 · 1 comment
Assignees
@Brandnew-one
Labels
CS

Comments

@Brandnew-one
Copy link
Owner

HTTP 헤더 - 1

  • field-name: field-value (띄워쓰기 허용)
  • HTTP 전송에 필요한 모든 부가정보
  • 필요시 임의의 헤더 추가 가능
    • 유저 기기에 대한 정보를 헤더에 실어서 통신 했던 경험

HTTP 헤더 분류

RFC2616(과거)

  • General 헤더: 메시지 전체에 적용되는 정보
  • Request 헤더: 요청 정보
  • Response 헤더: 응답 정보
  • Entity 헤더: 엔티디 바디 정보
HTTP/1.1 200 OK // 시작라인
Content-Type: text/html;charset=UTF-8 // 엔티디 헤더
Content-Length: 3423

<html> // 엔티디 본문
...
</html>

HTTP 메시지 구조를 공부하면서 살펴봤듯이 시작라인, 헤더, 공백, 본문 구조로 구성되어 있다.

엔티디 헤더는 메시지 본문을 통해 전달하는 데이터를 해석할 수 있는 정보들을 제공한다.

RFC723x

2014년 이후로 HTTP 표준이 바뀌면서 위의 구조에서 Entity가 Representation으로 대체되는 큰 차이점이 발생했다. (완전히 1:1 대응되는 개념은 아님)

사실 둘의 정확한 차이점을 파악할 정도로 깊게 공부하지는 못했지만 간단하게 정리해보자면

Entity는 클라이언트와 서버간 주고 받는 데이터의 본질에 더 가까운 느낌인데 사실 해당 데이터를 어떻게 표현해서 주고 받을지 서로 약속하고 각자의 내부적은 로직을 통해 해당 데이터를 처리하면 되기 떄문에 클라이언트 서버간 데이터를 주고 받을 때 내부적으로 각자 해당 데이터를 어떤 형식으로 저장하고 있건 json 타입으로 주고 받는다는 약속을 한다. 정도의 느낌으로 받아들였는데 해당 내용은 좀 더 공부하다가 알게되는 내용이 있으면 정리해야겠다.

HTTP/1.1 200 OK // 시작라인
Content-Type: text/html;charset=UTF-8 // 표현 헤더
Content-Length: 3423

<html> // 표현 데이터
...
</html>

표현헤더

  • Content-Type: 표현 데이터의 형식

HTTP 메서드 활용을 정리하면서 정리했던 부분은 간단하게 다시 짚고 넘어가보자.

Content-Type은 HTTP 요청 또는 응답의 본문(content)의 표현 데이터 형식을 설명하고 MIME 타입을 이용해 미디어 타입을 명시한다.

  • Content-Encoding: 표현 데이터 인코딩

표현 데이터를 압축하기 위해서 사용

데이터를 읽는 쪽에서 인코딩 헤더의 정보를 이용해서 압축 해제 [ex) gzip, deflate, identity]

  • Content-Language: 표현 데이터의 자연언어

표현 데이터의 자연언어를 표현 [ex) ko, en, en-US]

  • Content-Length: 표현 데이터의 길이

바이트 단위, 전송 코딩을 사용하면 Cotent-Length를 사용하면 안됨 → 조금만 내리시면 해당 내용 정리

협상

클라이언트가 선호하는 표현 요청이라는 문장만 보면 정확하게 이해하기 힘들 수 있는데 예제를 들어서 같이 이해해보자

Untitled Untitled 1

위의 그림처럼 다국어를 지원하는 서버에서 클라이언트에 응답을 줄 때 요청시 협상 헤더를 사용하지 않으면 기본으로 지원하는 영어로 응답을 받게된다.

협상과 우선순위

  • Quality Values가 높을수록 우선순위
Untitled 2
  • 구체적일수록 우선순위
Accept: text/*, text/plain, text/plain;format=flowed, **/*

1)* text/plain;format=flowed
2) text/plain
3) text/*
4) **/**
q값을 따로 명시하지 않아도 구체적인 값이 우선순위를 가진다.

클라이언트가 서버로 받을 응답 값을 때 선호하는 형식을 지정하는 것이기 때문에 요청시에만 사용된다.

전송방식

  • 단순전송
    • Content에 대한 길이를 알고 있을 때 사용 한번에 요청하고 한번에 받음
  • 압축전송
    • Content-Encoding을 통해서 어떻게 압축되었는지를 표현해야한다.
  • 분할전송
    • Content-Length를 보내면 안된다.
Untitled 3
  • 범위전송
    • 범위를 지정해서 요청(이미지 같이 큰 파일을 받을 때 중간부터 다시 받는 경우 생각)

일반정보

  • Form
    • 유저 에이전트의 이메일 정보
  • Referer
    • 현재 요청된 페이지의 이전 웨 페이지 주소
    • 유입 경로를 분석할 수 있음
  • User-Agent
    • 클라이언트의 애플리케이션 정보 (서버로그에 Postman, Alamofire까지 찍히던거 생각)
    • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
  • Server
    • 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
  • Date
    • 메시지가 발생한 날짜와 시간

특별한 정보

  • Host
    • 요청한 호스트 정보
    • 하나의 IP주소에 여러 도메인이 적용되어 있을 수 있기 때문에 필수
    • 요청에서 사용
  • Location
    • 30x 응답 결과를 통해 리다익레트 시키는 경우 사용
    • 201에서 리소스 생성 위치를 알려줄 떄 사용
  • Retry-After
    • 유저 에이전트가 다음 요청을 하기전까지 기다려야 하는 시간
  • Authorization
    • 클라이언트 인증 정보를 서버에 전달할 때 사용
    • 401에서 유저 인증 실패시 WWW-Authenticate로 인증 방법에 대해 알려줌

쿠키

쿠키는 서버가 클라이언트에게 보내는 작은 데이터 조각

쿠키에 대해 이해하기 위해서는 쿠키를 왜 사용하는지를 먼저 이해할 필요가 있다.

HTTP 특성을 다시 들여다 보면

  • 클라이언트 - 서버 구조
  • 무상태, 비연결성

무상태(Stateless), 서버는 클라이언트의 상태를 저장하고 있지 않기 때문에 클라이언트는 이전 상태에 대한 정보를 함께 서버에 보내야 하는 불편함이 있었지만 스케일 아웃이 쉬워진다고 정리한바 있다.

그럼 이전 상태에 대한 정보를 서버에 넘기는 방법에는 무엇이 있을까?

간단하게 모든 요청에 이전 상태 정보를 넘길 수 있다. 하지만 웹 브라우저를 닫은 경우에는 어떻게 처리해야 할까?

이런 문제들을 간단하게 해결하기 위해 나온것이 쿠키이다.

Untitled 4

먼저 서버에서 클라이언트로 쿠키를 전달한다.

Untitled 5

이후 클라이언트에서 서버로 요청을 보낼 때, 쿠키에 있는 정보를 포함해서 보낸다.

쿠키 - 생명주기

그럼 웹 브라우저가 닫히면 쿠키는 어떻게 될까? 또 클라이언트에 저장된 쿠키는 언제까지 저장되는걸까?

서버에서 처음 클라이언트에게 쿠키를 보내줄 때 쿠키의 만료일을 설정할 수 있다.

Set-Cookie: expire=Sat,26-Dec-2020 04:39:23 GMT // 만료일이 되면 삭제
Set-Cookie: max-age=3600 // 3600초 이후 삭제
  • 세션 쿠키: 만료날짜를 생략하면 브라우저가 종료될 때 까지 유지
  • 영속 쿠키: 만료날짜를 입력하면 해당 날짜까지 유지

서버에서 만료일을 설정한다고 해서 클라이언트에서 쿠키 만료일이 되면 어떻게 자동으로 삭제할까?라는 의문이 들어서 검색했는데 브라우저의 쿠키 정책에 따라서 다를 수 있다고 한다.

쿠키 - 도메인, 경로

클라이언트에 저장된 쿠키 정보는 항상 서버에 전송되는데 현재 웹 사이트가 아닌 다른 사이트에서 받아 저장한 쿠키도 함께 전송되는걸까? (당연히 그러면 안되겠죠?)

domain=example.org // 문서 기준 도메인, 서브 도메인 포함 -> dev.example.org
domain(empty) // 해당 도메인에서만 접근 가능

도메인값을 적어주지 않더라도 기본적으로 해당 쿠키를 보내준 도메인에 요청을 보낼 때만 해당 쿠키를 사용한다.

쿠키 - 보안

항상 서버에 전송되는 값이기 때문에 보안에 취약하다. 최소한의 정보만 보내야 한다.

  • Secure를 적용하면 https인 경우에만 전송
  • HttpOnly: HTTP 전송에만 사용
  • SameSite: 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송
@Brandnew-one Brandnew-one self-assigned this Jun 18, 2023
@Brandnew-one
Copy link
Owner Author

업로드 과정에는 Content-Type을 항상 Muiltipart/form-data를 사용하는걸까?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Brandnew-one Brandnew-one

Labels
CS
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Brandnew-one