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.

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

[Network] 20. HTTP(s) 프로토콜에서 바이너리 데이터를 전송하는 방식에 대해 설명해주세요. #70

Open
leezzangmin opened this issue Nov 15, 2022 · 1 comment
Labels
NETWORK 네트워크 질문

Comments

@leezzangmin
Copy link
Collaborator

20. HTTP(s) 프로토콜에서 바이너리 데이터를 전송하는 방식에 대해 설명해주세요.

키워드

HTTP, HTTPS, 네트워크,


@leezzangmin leezzangmin added the NETWORK 네트워크 질문 label Nov 15, 2022
@leezzangmin leezzangmin self-assigned this Nov 15, 2022
@leezzangmin
Copy link
Collaborator Author

바이너리 데이터를 텍스트기반인 HTTP 프로토콜에 보내려면 방법이 두 가지가 있다.

  1. MIME 타입으로 바이너리 데이터를 그대로 보내기
  2. Base64,ASCII 등으로 인코딩하여 바이너리 데이터를 텍스트로 변환하여 보내기
  • 장점: 안전하게 전송 가능
  • 단점: 데이터 용량이 증가(base64)

MIME (Multipurpose internet mail extensions)

MIME은 마임이라고 읽으며 텍스트기반 프로토콜에서 바이너리 데이터(예를 들어 이미지, 동영상, 파일)를 전송하기 위해 HTTP의 Context-Type 헤더에 데이터 타입을 명시하여 사용한다.
image

인코딩하여 전송

보통 Base64 인코딩을 쓴다.
Base64 는 Binary 데이터를 아스키 코드 일부와 일대일로 매칭되는 문자열로 단순 치환되는 인코딩 방식이다.
Base64는 6bit당 2bit의 OverHead의 발생으로 기존 데이터보다 30%이상 길어지게 되며 여기에 Encoding, Decoding의 로직까지 추가되므로 성능에도 영향을 끼칠 수 있다. 이러한 단점에도 Base64를 사용하는 이유는 무엇일까.
Base64를 사용하는 가장 큰 이유는 Binary 데이터를 텍스트 기반 규격으로 다룰 수 있기 때문이다. JSON과 같은 문자열 기반 데이터 안에 이미지 파일등을 Web에서 필요로 할때 Base64로 인코딩하면 UTF-8과 호환 가능한 문자열을 얻을 수 있다. 끝에 '='과 같은 패딩 기호가 있다면 이는 구분자로써 사용되므로 대부분 Base64로 생각할 수 있다.
기존 ASCII 코드는 시스템간 데이터를 전달하기에 안전하지 않다. 모든 Binary 데이터가 ASCII 코드에 포함되지 않으므로 제대로 읽지 못한다. 반면 Base64는 ASCII 중 제어문자와 일부 특수문자를 제외한 53개의 안전한 출력 문자만 이용하므로 데이터 전달에 더 적합하다.
Base64는 Binary 데이터를 문자로 변환하는데 영향을 받지 않는 공통 ASCII 코드 영역의 문자로만 이루어진 문자열로 바꾸는 Encoding이다. 문자 그대로 64진법(2^6)을 사용하며 Binary 데이터를 6bit 씩 나누고 해당하는 문자를 위의 색인표에서 맞게 치환하는 과정을 거친다. 6bit cut을 진행함에 있어서 모든 문자열이 3개씩 이쁘게 떨어지면 좋겠지만, 아닌 경우도 왕왕 존재하기 마련이다. 그런 경우를 대비해 padding을 하는데 남는자리에 = 기호를 통해서 채워주는 개념이다.
image



기존 HTTP 1.1 메시지는 평문(Plain Text)을 사용하고, 개행을 통해 본문과 헤더를 구분 하였다면, HTTP/2 버전부터는 바이너리 프레이밍 계층을 사용해 인코딩된 요청과 응답의 멀티플렉싱을 지원합니다. HTTP 메시지를 바이너리 형태의 프레임으로 나누고 이를 전송 후 받은 쪽에서 다시 조립합니다. 요청과 응답이 동시에 이루어지니 하나의 연결에 여러 요청과 응답이 뒤섞여 있습니다. 프레이밍 작업은 서버와 클라이언트(브라우저)에서 해주기 때문에 큰 변경사항을 고려하지 않아도 됩니다. 바이너리 프레이밍과 멀티플렉싱을 이용해 여러 개의 연결 없이 병렬 처리도 할 수 있고 파이프라이닝과 달리 HOL문제를 해결한 것입니다.

HTTP/1.x에서는 클라이언트가 병렬 요청을 하는 경우 TCP 연결이 여러쌍 이루어져야 한다.
반면 HTTP/2에서는 이런 제한 없이 전체 요청 및 응답 다중화를 지원한다.
클라이언트와 서버가 HTTP 메시지를 독립된 프레임으로 분리하고 다른 쪽에서 다시 조립한다. 단일 TCP 연결에서도 병렬 요청과 응답이 가능해진다.
바이너리 프레이밍 계층을 사용함으로 볼 수 있는 효과는

  • HOL 해결
  • 다수의 TCP 커넥션 점유 문제 해결
  • 속도 개선 -> 비용절감

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NETWORK 네트워크 질문
Projects
None yet
Development

No branches or pull requests

1 participant